On 3/9/2026 9:15 PM, Ben Dooks wrote: > On 26/02/2026 07:27, Akhil P Oommen wrote: >> On 2/25/2026 7:52 PM, Ben Dooks wrote: >>> I am currently looking at an SA8295P based device which has six eDP/DP >>> outputs and thus is configuring two of the qcom,sc8280xp-mdss devices. >>> >>> This is failing as the device registration as the first one binds the >>> two output channel devices and the adreno_gpu to it, followed by then >>> attempting to do the same with the next which fails as the aggregagte >>> device code can't handle this and leaves the gpu unbound. >>> >>> Fixing the aggregate device to then just causes the bind to fail as >>> the adreno_gpu is already bound to the first mdss with -EBUSY from >>> the irq code in the driver bind. >>> >>> The two driver binds are as follows: >>> >>>>> [ 43.009894] adreno 3d00000.gpu: adreno_bind() bind as dev >>>>> [ 43.020697] msm_dpu ae01000.display-controller: adreno_bind() bind >>>>> as master >>>>> [ 43.076995] adreno 3d00000.gpu: supply vdd not found, using dummy >>>>> regulator >>>>> [ 43.105257] adreno 3d00000.gpu: supply vddcx not found, using >>>>> dummy regulator >>>>> [ 43.208582] msm_dpu ae01000.display-controller: bound 3d00000.gpu >>>>> (ops a3xx_ops) >>>>> [ 43.233368] [drm:dpu_kms_hw_init:1173] dpu hardware >>>>> revision:0x80000000 >>>>> [ 43.343842] [drm] Initialized msm 1.13.0 for ae01000.display- >>>>> controller on minor >>>> [ 46.013271] adreno 3d00000.gpu: adreno_bind() bind as dev >>>> [ 46.024075] msm_dpu 22001000.display-controller: adreno_bind() bind >>>> as master >>>> [ 46.038039] genirq: Flags mismatch irq 243. 00000004 (gpu-irq) vs. >>>> 00000004 (gpu-irq) >>>> [ 46.051349] adreno 3d00000.gpu: error -EBUSY: request_irq(243) >>>> irq_handler 0x0 gpu-irq >>> >>> Looking into the adreno_bind() it then passes the drm instance from the >>> msm_dpu into the msm_gpu_init() and then I am not sure where that all >>> gets used to try and work out if we can make the resources local to >>> the adreno_gpu device and then have the two display controllers share >>> this. >>> >>> Is there anyone looking into this? I have posted an RFC for the >>> aggregate device issue, but not sure how to deal with the adreno_gpu >>> side (and having other hw issues which means I can't even get the >>> driver to work with just one mdss node). >> >> I am not sure if binding a component to multiple masters is the right >> direction. >> >> I believe Dmitry (CC'ed) is exploring support for multi-DPU systems and >> the direction is to decouple gpu and display. >> >> https://lore.kernel.org/dri-devel/20260223-seperate_gpu_kms-v1-1- >> [email protected]/ >> Could you please check if this patch helps? > > I've applied those and it does seem to be binding a device now. > > Not had a chance to actually check display output yet as we may well > be moving to a different project. > > I did notice there is no firmware for the zap-shader node in the > device tree, which has: > > gpu@3d00000 { > zap-shader { > firmware-name = "qcom/sa8295p/a690_zap.mbn"; > }; > }; > > this isn't in the linux-firmware repo, who should we ask at qcom to see > if this firmware is going to be released or where it can be found. >
I am not familiar with the Automotive software releases, but this firmware should be present somewhere in the image that was provided with your board. If you are contracted to do this work by Qcom, then the PoC from the QC product team should be able to help you out with the necessary firmware blobs. https://mysupport.qualcomm.com/supportforums/ As a last option, maybe try the above forum. It is IoT oriented, so not sure if it would be helpful for Auto chipsets. -Akhil.
