sdm845 mdss reset LLM answer

Yes — **adding an MDSS reset is very likely to fix this**, and on SDM845-class bring-up it’s often the *cleanest* solution.

But let’s be precise about *why* and *how* so you don’t introduce subtle regressions.

---

## 1) Why reset works here

Right now the hardware state is:

> MDSS is **already actively scanning out** a framebuffer programmed by the bootloader.

When Linux attaches the SMMU:

* That old physical address (`0x9d400000`) is still in SSPP registers
* No IOVA mapping exists
  → **translation faults**

### What reset does

An MDSS reset will:

* Clear SSPP source addresses
* Disable fetch engines
* Reset VBIF clients
* Drop any in-flight transactions

👉 In effect:

> It guarantees **no DMA happens until Linux explicitly programs valid buffers**

---

## 2) Why this is the *correct* fix (not just a workaround)

Compared to alternatives:

| Approach                  | Quality                              |
| ------------------------- | ------------------------------------ |
| Mapping splash into IOMMU | ❌ hack                               |
| Ignoring faults           | ❌ noisy, unsafe long-term            |
| Delaying attach           | ⚠️ fragile                           |
| **Reset MDSS**            | ✅ correct hardware ownership handoff |

This aligns with upstream expectations:

> Drivers must assume hardware may be left in an arbitrary state by firmware.

---

## 3) Where to apply the reset

You want the reset to happen **before any IOMMU-backed access is possible**.

### Ideal location:

Inside MDSS probe/init path, before enabling pipes:

* `dpu_kms_hw_init()`
* or earlier in MDSS bind sequence

---

## 4) How to implement it (SDM845 specifics)

You typically have a reset line in DT:

```dts
display-subsystem@ae00000 {
    resets = <&dispcc MDSS_CORE_BCR>;
    reset-names = "core";
};
```

Then in driver:

```c
reset_control_assert(mdss->core_reset);
udelay(10);   // or usleep_range
reset_control_deassert(mdss->core_reset);
```

### Important details

* Use **assert + short delay + deassert**
* Do this **before enabling clocks/pipes**
* Make sure clocks required for reset are enabled if needed

---

## 5) Things to watch out for

### ⚠️ 1. Clock/reset ordering

On Qualcomm:

* Some resets require clocks ON
* Others don’t

If reset silently fails → you’ll still see faults

---

### ⚠️ 2. Partial reset vs full reset

Some platforms expose multiple resets:

* `mdss_core`
* `mdss_bus`
* `mdss_iface`

👉 Prefer **full MDSS core reset** if available

---

### ⚠️ 3. Interaction with bootloader splash

Reset will:

* Kill the splash framebuffer instantly

So:

* Expect a **brief black screen** before DRM takes over

(This is normal and acceptable upstream)

---

### ⚠️ 4. Runtime PM / re-init paths

Make sure reset is only done at:

* initial probe
* not during runtime resume (unless intended)

---

## 6) How to verify it fixed the issue

After adding reset:

### Expected:

* ❌ No more:

  ```
  arm-smmu ... Unhandled context fault
  ```
* ✅ Clean transition:

  * simplefb → DRM
* ✅ No accesses to `0x9d4xxxx`

---

## 7) If reset alone doesn’t fix it

Then the issue is slightly deeper:

* Some block (VBIF client) not covered by reset
* Or re-enabled too early

In that case:

👉 Combine reset with:

* Explicit SSPP disable
* or dummy buffer programming

---

## 8) Bottom line

> **Yes — adding an MDSS reset is not only helpful, it’s the most correct and robust fix for your issue.**

It ensures:

* No stale bootloader state
* No illegal DMA before mappings exist
* Clean ownership handoff from firmware → kernel
~okias/sdm845 mdss reset LLM answer
