linux-amlogic.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Jernej Škrabec" <jernej.skrabec@siol.net>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Neil Armstrong <narmstrong@baylibre.com>
Cc: jonas@kwiboo.se, robert.foss@linaro.org,
	dri-devel@lists.freedesktop.org,
	linux-amlogic@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, hverkuil-cisco@xs4all.nl
Subject: Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver
Date: Sat, 17 Apr 2021 08:31:39 +0200	[thread overview]
Message-ID: <9525152.Q8VVBrNj5Z@jernej-laptop> (raw)
In-Reply-To: <96b9e144-0791-4c19-3e3c-b0e9efb86138@baylibre.com>

CC Hans Verkuil

Dne petek, 16. april 2021 ob 13:38:59 CEST je Neil Armstrong napisal(a):
> 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.

I'm in favour of Neil's solution. Currently we have only one exception.

> 
> 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.

Note that we still need DT property for disabling CEC. I have one Allwinner H3 
board where board designer decided to use GPIO CEC implementation instead of 
DW HDMI one (vendor Linux doesn't implement DW HDMI CEC driver). Other H3 
boards happily use DW HDMI CEC.

Best regards,
Jernej

> 
> Neil
> 
> >> 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(-)





_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  reply	other threads:[~2021-04-17  6:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16  9:27 [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver Neil Armstrong
2021-04-16  9:27 ` [PATCH 1/2] drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC driver Neil Armstrong
2021-04-16  9:27 ` [PATCH 2/2] drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver Neil Armstrong
2021-04-16  9:58 ` [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of " Laurent Pinchart
2021-04-16 11:38   ` Neil Armstrong
2021-04-17  6:31     ` Jernej Škrabec [this message]
2021-04-20 15:13     ` Hans Verkuil
2021-04-20 15:19       ` Neil Armstrong
2021-04-20 22:49         ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9525152.Q8VVBrNj5Z@jernej-laptop \
    --to=jernej.skrabec@siol.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jonas@kwiboo.se \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=robert.foss@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).