[PATCH] drm/sun4i: Workaround TCON TOP conflict between DE0 and DE1

[John Watts]

Hey everyone,

I'm not sure exactly where to add this but I discussed some of this with
Parthiban on #linux-sunxi a few days ago, so I want to write it down
before I work on the next version of the patch.

I had assumed for some reason in my mind that DE0 and DE1 here referred
to mixers, but they actually refer to chips that have multiple DEs. It
looks like at least with the A133 it has two DEs instead of two mixers.

This can be found by looking at the Allwinner BSP: SUN50IW10 requires
CONFIG_INDEPENDENT_DE and has a device tree with an extra reg and clock:

<0x0 0x06800000 0x0 0x3fffff>,/*de1*/
<&clk_dpss_top1>

However the tcon-top code seems to conflate mixers and DE in the
mainline code and the Allwinner code. So ... It seems like 'DE0' and
'DE1' really do mean mixers in this case. It's probably best to note
that down.

I thought a bit more about how to solve this properly- setting two
mixers to the same output is something people probably won't do in
practice, so the only way you could really arrive at this bugged state
is by setting it as the default state. This patch may be the correct
solution after all.

John Watts

On Sat, Nov 09, 2024 at 01:15:16AM +1100, John Watts wrote:
> On Fri, Nov 08, 2024 at 07:36:16PM +0530, Parthiban wrote:
> > To add, 0x20 will be DE0 <--> LCD0 and DE1 <--> TV0. Below note (copied from
> > R40) states the priority of the DE selection, which fails to work? Not sure,
> > may be disabling CORE1_SCLK_GATE and CORE1_HCLK_GATE in de2-clk helps.
> > 
> > With A133 following the same as T113 with single mixer without TV, still
> > sets 0x20 in vendor kernel.
> > 
> > copied from R40:
> > Note: The priority of DE0 is higher than DE1.
> > If TCON_LCD0 selects DE0 and DE1 as source at the same time, then
> > DE0 will be used for the source of TCON_LCD0.
> 
> Hi there,
> 
> Yes that was a pretty bad typo, I meant to say DE1 to TV0
> The prioritization seems broken in the T113 at least, it's racy from
> what I see in testing. I should note this in the patch too.
> 
> I looked at the datasheets and kernel code briefly: I can't seem to
> figure out what SCLK/HCLK gating does and I don't think the kernel
> touches these registers which are gated by default.
> 
> > Thanks,
> > Parthiban
> 
> John Watts