[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200415104214.ndkkxfnufkxgu53r@gilmour.lan>
Date: Wed, 15 Apr 2020 12:42:14 +0200
From: Maxime Ripard <maxime@...no.tech>
To: Jernej Škrabec <jernej.skrabec@...l.net>
Cc: Chen-Yu Tsai <wens@...e.org>, David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
dri-devel <dri-devel@...ts.freedesktop.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/sun4i: hdmi ddc clk: Fix size of m divider
On Mon, Apr 13, 2020 at 06:09:08PM +0200, Jernej Škrabec wrote:
> Dne ponedeljek, 13. april 2020 ob 16:12:39 CEST je Chen-Yu Tsai napisal(a):
> > On Mon, Apr 13, 2020 at 6:11 PM Chen-Yu Tsai <wens@...e.org> wrote:
> > > On Mon, Apr 13, 2020 at 5:55 PM Jernej Skrabec <jernej.skrabec@...l.net>
> wrote:
> > > > m divider in DDC clock register is 4 bits wide. Fix that.
> > > >
> > > > Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@...l.net>
> > >
> > > Reviewed-by: Chen-Yu Tsai <wens@...e.org>
> >
> > Cc stable?
>
> I don't think it's necessary:
> 1. It doesn't change much (anything?) for me when reading EDID. I don't think
> it's super important to have precise DDC clock in order to properly read EDID.
> 2. No matter if it has "Cc stable" tag or not, it will be eventually picked
> for stable due to fixes tag.
>
> This was only small observation when I was researching EDID readout issue on
> A20 board, but sadly, I wasn't able to figure out why reading it sometimes
> fails. I noticed similar issue on SoCs with DE2 (most prominently on OrangePi
> PC2 - H5), but there was easy workaround - I just disabled video driver in U-
> Boot. However, if A20 display driver gets disabled in U-Boot, it totally
> breaks video output on my TV when Linux boots (no output). I guess there is
> more fundamental problem with clocks than just field size. I think we should
> add more constraints in clock driver, like preset some clock parents and not
> allow to change parents when setting rate, but carefully, so simplefb doesn't
> break. Such constraints should also solve problems with dual head setups.
I disagree here. Doing all sorts of special case just doesn't scale,
and we'll never have the special cases sorted out on all the boards
(and it's a nightmare to maintain).
Especially since it's basically putting a blanket over the actual
issue and looking the other way. If there's something wrong with how
we deal with (re)parenting, we should fix that. It impacts more than
just DRM, and all the SoCs.
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists