From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757505AbcILJ4c (ORCPT ); Mon, 12 Sep 2016 05:56:32 -0400 Received: from down.free-electrons.com ([37.187.137.238]:50712 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756905AbcILJ4b (ORCPT ); Mon, 12 Sep 2016 05:56:31 -0400 Date: Mon, 12 Sep 2016 11:56:19 +0200 From: Maxime Ripard To: Chen-Yu Tsai Cc: Icenowy Zheng , Daniel Vetter , David Airlie , Thierry Reding , Thomas Petazzoni , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linux-sunxi@googlegroups.com" , Rob Herring , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 0/7] drm/sun4i: Introduce A33 display driver Message-ID: <20160912095619.GI9449@lukather> References: <20160901153204.11217-1-maxime.ripard@free-electrons.com> <18951472779805@web6g.yandex.ru> <20160902190605.GF6313@lukather> <20160905203707.GF8596@lukather> <20160906185452.GI9040@lukather> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Rmm1Stw9KgbdL9/H" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Rmm1Stw9KgbdL9/H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Sep 07, 2016 at 12:49:58PM +0800, Chen-Yu Tsai wrote: > On Wed, Sep 7, 2016 at 2:54 AM, Maxime Ripard > wrote: > > On Tue, Sep 06, 2016 at 10:50:09AM +0800, Chen-Yu Tsai wrote: > >> >> The implementation might be along the lines of > >> >> > >> >> 1. having multiple output ports, each for a different interface t= ype. > >> >> (Some platforms go this route) > >> >> > >> >> Or > >> >> > >> >> 2. having a DT property describe what the output interface is. > >> >> > >> >> The RGB/TCON driver would then setup the registers accordingly. > >> > > >> > Hmmm, yeah, we would need to adjust the bindings too... > >> > > >> > I guess I'd prefer 1), but that would also be the most invasive > >> > solution. I'm not sure how the DT maintainers feel about that. > >> > >> I wonder if the TCON could use its 2 channels simultaneously? > > > > No, it's mutually exclusive. >=20 > I don't see how though. Are you referring to the IO_Map_Sel bit? Yes. > I assume that only controls the external output pins though. As far as I know, channel 1 has no external pins, it's always one of the blocks using the channel 1 that have external pins. > >> Like output to one LCD, then mirror through HDMI/VGA? > >> The first option would be able to cover this better? > > > > Even if it wasn't exclusive, that wouldn't be possible > > unfortunately. Or rather, this would be possible if the LCD and the > > HDMI screen had the same timings, which is very unlikely. >=20 > What about an LCD-VGA bridge + HDMI in mirror mode on sun6i? > That should work. The same resolution doesn't mean you have the same timings. The porches and sync length might be different, in which case you'll have to have a different pixel clock and different register set ups. > >> In addition we'll have to rework the TV encoder binding as well. > >> > >> The 2 TV encoders (on the A20) each have four DACs, which map > >> onto 4 external pins. The address space includes a not so easy > >> to use mux. More importantly, the binding needs to specify which > >> pin is used for what signal (RGB, YUV, S/Video, composite). > >> There seems to be an implicit rule that 1 pin is always used > >> for composite, and the 3 others RGB, though. > > > > I'm not sure why we would need to rework this one though. We have no > > way to detect whether the screen is connected or not on either > > connectors, and we can't have both output running at the same time for > > the same reason than mention above. >=20 > I would like to add connector nodes. At least we can specify stuff > like what DAC outputs are used for which connector, what type of > connector, and a ddc bus for VGA connectors. I haven't worked out > the details though. The DAC really don't matter. It's purely internal to the driver itself, it doesn't change from one SoC to the other, so it doesn't really make sense to have it in the DT. And is there any design that uses an i2c bus for DDC together with the TV Encoder? Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --Rmm1Stw9KgbdL9/H Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJX1nvCAAoJEBx+YmzsjxAgmFgP/3tvh9bBa4N2+cPH0YwF+VaS YlsGWaBYgibmgSEFu1t66kpg4w0PNzI4+7BH1hx9Wa5Heo8wIFYmMXVY8ojO1yZ7 J5vB+yS0D5YLLd5UgGGH/Xa4osscxDnqueeJV9+F6pwh8s7GIrwS5xr8vS64FTeW if583YwiZ+mek6qvcpx2Yr0pzD2/42np0ggjj3pxQLAPDYtsPFQB0qMj9fqz7khZ nEzCAp1/axYmoEKYMAwBvnoS08QxSoIvYzL9QJ1bbJ1q5gN7wmyctHQA9wabjLEk IDd7icKSd7qZfyrVOTOwZU+a+6JvYMPyoabnsHNZx3wJxuu2SUDzBhV7OlipQFHT toerzDlW5eCWWq4xLsOOL80+5WnGqG4rXKiDoj0UYQzeemAbMFGc07qIb+ezw0Q0 uaviPEHqUiWgDdOpUMhitUS1QgocLqsnixmH/fOhupi4ic4fFu2dqJU1Ltp3/e90 T+smo6yOUGTHpLbKN6mAKdlDmTtAjnLPxRLKlYb//NeESIVGassyS6uqQl1KZdV+ YMB3Werf1/EqS3ODoUeGZJNKsKIZZWXIDHmP6hBMZvNvkQziCZ1uk7Ax3ya3o7qR pISm8V4EUILLRXDztKNnqIj1ZBwCzwIcZLPATKtnh7tag2FEIGilcND6n7IH1T0V aZvZT6AL6SOWYCuuhTf6 =KMj0 -----END PGP SIGNATURE----- --Rmm1Stw9KgbdL9/H--