On Tue, Apr 20, 2021 at 05:19:52PM +0200, Neil Armstrong wrote: > On 20/04/2021 17:13, Hans Verkuil wrote: > > On 16/04/2021 13:38, Neil Armstrong wrote: > >> On 16/04/2021 11:58, Laurent Pinchart wrote: > >>> Hi Neil, > >>> > >>> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote: > >>>> This adds DW-HDMI driver a glue option to disable loading of the CEC > >>>> sub-driver. > >>>> > >>>> On some SoCs, the CEC functionality is enabled in the IP config bits, > >>>> but the > >>>> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit > >>>> is set > >>>> but the DW-HDMI CEC signal is not connected to a physical pin, leading > >>>> to some > >>>> confusion when the DW-HDMI CEC controller can't communicate on the bus. > >>> > >>> If we can't trust the CEC config bit, would it be better to not use it > >>> at all, and instead let each platform glue logic tell whether to enable > >>> CEC or not ? > >> > >> Actually, the CEC config bit is right, the HW exists and should be > >> functional, but > >> this bit doesn't tell if the CEC signal is connected to something. > >> > >> This lies in the IP integration, like other bits under the > >> "amlogic,meson-*-dw-hdmi" > >> umbrella. > >> > >> The first attempt was by Hans using DT, but adding a property in DT for a > >> vendor > >> specific compatible doesn't make sense. Another idea would be to describe > >> the > >> CEC signal endpoint like we do for video signal, but I think this is out > >> of scope and > >> this solution is much simpler and straightforward, and it's more an > >> exception than > >> a general use case to solve. > > > > While a DT property might not make sense in this particular case, I still > > believe that it is a perfectly valid approach in general: whether or not > > the CEC pin is connected is at the hardware level decision, it is not > > something that software can detect. If the designer of the board didn't > > connect it, then the only place you can define that is in the device tree. > > Agreed, we need to define a smart way to declare CEC bus relationship in DT, > the side > effect would be to handle this particular case.
I wonder if it would make sense to use the OF graph bindings to describe the connection between the CEC controller and the CEC "device" (which I assume in most cases will be a DT node for a physical connector). Or is this overkill ? > > Anyway, for meson I am fine with this solution. At least it prevents > > creating > > a non-functioning cec device. So for this series: > > > > Acked-by: Hans Verkuil <hverkuil-ci...@xs4all.nl> > > Thanks, > > Applying this serie to drm-misc-next > > >>>> Jernej Skrabec (1): > >>>> drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC > >>>> driver > >>>> > >>>> Neil Armstrong (1): > >>>> drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver > >>>> > >>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > >>>> drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 + > >>>> include/drm/bridge/dw_hdmi.h | 2 ++ > >>>> 3 files changed, 4 insertions(+), 1 deletion(-) -- Regards, Laurent Pinchart
