From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934691AbcIFSy7 (ORCPT ); Tue, 6 Sep 2016 14:54:59 -0400 Received: from down.free-electrons.com ([37.187.137.238]:40905 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932874AbcIFSyy (ORCPT ); Tue, 6 Sep 2016 14:54:54 -0400 Date: Tue, 6 Sep 2016 20:54:52 +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: <20160906185452.GI9040@lukather> References: <20160901153204.11217-1-maxime.ripard@free-electrons.com> <18951472779805@web6g.yandex.ru> <20160902190605.GF6313@lukather> <20160905203707.GF8596@lukather> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JIpyCmsTxyPLrmrM" 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 --JIpyCmsTxyPLrmrM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 type. > >> (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. >=20 > I wonder if the TCON could use its 2 channels simultaneously? No, it's mutually exclusive. > 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. > And you still need to add outgoing endpoints for the HDMI block. Indeed. > In addition we'll have to rework the TV encoder binding as well. >=20 > 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. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --JIpyCmsTxyPLrmrM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXzxD8AAoJEBx+YmzsjxAgd5YQAMIhOKPLAyFZgVWdFvRtZDGP /arxb6XUo/0/mcjUwNRD2hVsI3gAwdvh44yc+RCAzVsDaKnF6ScOdBHubmcAqKZa bdLEr3Af0JbwNwLRpch8pYkTj0x4ojinjEmB7IlCPj339bTHhPfO1mk9h0JUbHCb yBhEHlXQy5AtqJW5Sn/cVvCv2t46pr9103rLPMcY+1E8OJrFCeJ+Sg3wdQM1DeKG 5YVF4wAYADkmajeBizfDk4SDI++Qnqld46V8sVPwIakgDeQ1D4X5xO0skerRInwq sa0evUvkt45c7v7QOmbITPeCyeLIkjnek2L5BOy8wk2rUpq3J8hD/Qu/7fES+55B KmpEgwEBL4eJEwlFSP2BJIqBLd3A3o5WFhOXUEGbF9jZHlqFLzh45JQWnyRDhwLO m59JRp44b13pOc5ZiPLe8K7up0RazZQRZ7/2W6E+/ofKbl1TYB1oRfCYT7Qh/EkM Cm7xrWc6GbzF6DWf8PH4GlT993slvmq72RSpPqqziIM1XG/rraUOdCzicpQ62l4m IrtyfQJkXaHcfqv6MzHaK91S/39YjaxVxMVcLZyN2o1twoueDs4FDnqNjb3Ppi0T bfRdJFXcAenBI1/MKSgVPbJsgb99F7ooKR3ymvm55uF0Bgs3ncjHMJO86RNJS/yh wDKhyXkCEAc0HOTo1eHR =sGSJ -----END PGP SIGNATURE----- --JIpyCmsTxyPLrmrM--