Re: [PATCH 2/3] arm64: dts: ti: k3-j721e-main.dtsi: Add DSS node

[Tomi Valkeinen]

On 27/04/2020 14:15, Tomi Valkeinen wrote:
> On 27/04/2020 14:10, Jyri Sarha wrote:
> > On 27/04/2020 13:51, Tomi Valkeinen wrote:
> > > On 27/04/2020 13:37, Jyri Sarha wrote:
> > > > On 27/04/2020 13:09, Tero Kristo wrote:
> > > > > > +ÂÂÂÂÂÂÂ status = "disabled";
> > > > >
> > > > > Again, why disabled by default?
> > > >
> > > > tidss device is not functional without a defined video-port. The driver
> > > > is not implemented in a way that it would handle a broken configuration
> > > > gracefully.
> > >
> > > Then we need to fix it. The driver should handle the case where there
> > > are no ports defined just fine.
> >
> > Just by reading the code, I would say that currently the probe would
> > fail with returned -ENOMEM after calling drm_vblank_init() with zero CRTCs.
> >
> > So should the probe fail gracefully and silently, or should we try to
> > register a DRM device with no CRTCs? Is that even possible?
>
> My first thought is that the driver should exit probe silently with ENODEV if there are no outputs 
> defined (but, of course, with EPROBE_DEFER if there are outputs which haven't been probed yet).
>
> It gets a bit more complex if we ever support writeback, as that can be used as mem-to-mem without 
> any displays, but I think we can ignore that for now.

In any case, that's not the reason for status = "disabled", so that discussion is not related to 
these patches as such.

The reason to have DSS disabled is just to prevent pointless driver probing. When a board dts or a 
DT overlay adds a display, the DSS DT node has to be modified anyway to add the DT graph and the 
panel/bridge data. So one can as well add the single line of "status = enabled" there.

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki