From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jernej =?utf-8?B?xaBrcmFiZWM=?= Subject: Re: Re: [PATCH v3 09/24] drm/sun4i: Don't skip TCONs if they don't have channel 0 Date: Thu, 05 Jul 2018 22:03:35 +0200 Message-ID: <1699738.FoQmAThxyL@jernej-laptop> References: <20180625120304.7543-1-jernej.skrabec@siol.net> <20180705070358.7ng4shuo3pxp62q6@flea> Reply-To: jernej.skrabec-gGgVlfcn5nU@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: <20180705070358.7ng4shuo3pxp62q6@flea> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Maxime Ripard Cc: Chen-Yu Tsai , Rob Herring , David Airlie , Gustavo Padovan , Maarten Lankhorst , Sean Paul , Mark Rutland , dri-devel , devicetree , linux-arm-kernel , linux-kernel , linux-clk , linux-sunxi List-Id: devicetree@vger.kernel.org Dne =C4=8Detrtek, 05. julij 2018 ob 09:03:58 CEST je Maxime Ripard napisal(= a): > On Sun, Jul 01, 2018 at 11:11:06PM +0800, Chen-Yu Tsai wrote: > > On Sun, Jul 1, 2018 at 4:27 PM, Jernej =C5=A0krabec =20 wrote: > > > Dne =C4=8Detrtek, 28. junij 2018 ob 08:24:34 CEST je Chen-Yu Tsai nap= isal(a): > > >> On Thu, Jun 28, 2018 at 12:45 PM, Jernej =C5=A0krabec > > >>=20 > > >> wrote: > > >> > Dne =C4=8Detrtek, 28. junij 2018 ob 03:51:31 CEST je Chen-Yu Tsai= =20 napisal(a): > > >> >> On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec > > >> >> > > >> >=20 > > >> > wrote: > > >> >> > TV TCONs (channel 1 only) are always connected to TV or HDMI > > >> >> > encoder. > > >> >> > Because of that, all output endpoints on such TCON node will po= int > > >> >> > to a > > >> >> > encoder which is part of component framework. > > >> >> >=20 > > >> >> > Correct current graph traversing algorithm in such way that it > > >> >> > doesn't > > >> >> > skip output enpoints with id 0 on TV TCONs. > > >> >>=20 > > >> >> No. Our bindings say that endpoint 0 _is_ channel 0. For TCONs th= at > > >> >> don't > > >> >> have channel 0, it must be skipped. > > >> >=20 > > >> > I'm not sure where this is stated. I read TCON binding again. Can = you > > >> > please point me to it? > > >>=20 > > >> https://elixir.bootlin.com/linux/latest/source/Documentation/devicet= ree > > >> /bind ings/display/sunxi/sun4i-drm.txt#L169 > > >>=20 > > >> Our TCON driver still expects RGB or LVDS panel / bridges on endpoin= t > > >> 0. > > >=20 > > > Yes, but that can only happen on TCON which has channel 0. TV TCONs > > > (those > > > with channel 1 only) can't have panels or bridges connected to them, > > > because they are internally always connected to either HDMI or TV > > > encoder or both. Actually, R40 is the only SoC, where same TV TCON ca= n > > > be connected to TV encoder or HDMI. Others have specialized TV TCONs, > > > which are connect to only one encoder. > > >=20 > > > IMO TV TCONs are really just stripped down LCD TCONs to support one (= or > > > max > > > two) specific encoder. > >=20 > > I agree. We've seen these first in the H3, and the reverse, TCONs only > > with > > LCD, on the A23/A33. > >=20 > > >> So I guess this was sort of implied historically. It's no longer tru= e. > > >> This is something we should probably fix. > > >=20 > > > Fixed in what way? You mean update bindings to mention that TCON outp= ut > > > endpoint 0 is reserved for panels or bridges? > >=20 > > Either that, or have the drm driver look at other endpoints. I guess we > > should ask Maxime if this is already done or not, since the DSI driver > > isn't endpoint 0 in the A33 dtsi. >=20 > The DSI driver isn't really a good example for this, since the panel > isn't described as part of the OF graph, but DSI binding require that > it's a child of the DSI controller node. So should be new behaviour reverted? I mean ignoring endpoint 0 on TV TCONs= . For me, it doesn't make sense to check for panel or bridges on TV TCONs,=20 because they are never exposed on physical pins. They are always connected = to=20 TVE or HDMI encoder internally. >=20 > > >> In practice our drivers don't look at it (yet), but rely on the > > >> downstream > > >> encoder type to determine which channel to use. > > >>=20 > > >> But please add the "allwinner,tcon-channel" property as specified in > > >> the binding. > > >=20 > > > It's my understanding of TCON binding documentation that property > > > "allwinner,tcon-channel" is needed only if TCON supports both channel= s. > > > TV > > > TCON clearly supports only channel 1. In that case, there is no doubt= to > > > which channel output endpoint belongs. > > >=20 > > > If that's not true, dt bindings documentation should be reworded to > > > contain > > > word "needed" or something similar. Currently, no DT for newer SoC > > > contains > > > that property (for example, A83T, H3, H5 or even A33). >=20 > Yeah, but that's mainly because we have a single output enabled for > each channel on those newer SoCs. When / if we enable the RGB and LVDS > output for example, we will have to set this. So just to be clear, before I send follow up series, I have to add=20 "allwinner,tcon-channel" property to DT, because both TV TCONs can be=20 connected to either TVE or HDMI (trough TCON TOP)? BTW, since this property is not used at all in the code, why not just simpl= y=20 deprecate it and remove it from existing DTs? I noticed this is standard=20 practice for obsolete properties. Best regards, Jernej >=20 > > > On A33 this is even more interesting, since tcon0 has only channel > > > 0 and has DSI output endpoint with number 1. According to TCON > > > binding docs, if "allwinner,tcon-channel" is not preset, endpoint > > > number represent channel. So, that would mean DSI needs channel 1 > > > on tcon which supports clearly only channel 0. So either there > > > TCON bindings documentation needs updates or DT for A33 has to be > > > updated. > >=20 > > Maxime? You did the A33 DSI stuff. >=20 > I guess it's missing on the A33 DSI endpoint. >=20 > Maxime --=20 You received this message because you are subscribed to the Google Groups "= linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout.