From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934121AbdCUVNF (ORCPT ); Tue, 21 Mar 2017 17:13:05 -0400 Received: from anholt.net ([50.246.234.109]:43308 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934093AbdCUVND (ORCPT ); Tue, 21 Mar 2017 17:13:03 -0400 From: Eric Anholt To: Michael Zoran , linux-kernel@vger.kernel.org Cc: gregkh@linuxfoundation.org, devel@driverdev.osuosl.org, linux-rpi-kernel@lists.infradead.org, Stefan Wahren Subject: Re: Eric Anholt offically announces support of VC4 without access to expander on the RPI 3 In-Reply-To: <1490123377.11105.38.camel@crowfest.net> References: <20170317152221.8381-1-mzoran@crowfest.net> <20170317152221.8381-2-mzoran@crowfest.net> <294780758.583819.1489843404003@email.1und1.de> <1489898563.1536.1.camel@crowfest.net> <456494443.511096.1489919984010@email.1und1.de> <1489923494.4316.1.camel@crowfest.net> <1687987180.514561.1489934830943@email.1und1.de> <1489941033.13607.3.camel@crowfest.net> <87a88fsw0t.fsf@eliezer.anholt.net> <1490071342.11105.22.camel@crowfest.net> <874lym3567.fsf@eliezer.anholt.net> <1490123377.11105.38.camel@crowfest.net> User-Agent: Notmuch/0.22.2+1~gb0bcfaa (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 21 Mar 2017 14:12:52 -0700 Message-ID: <87k27i1gh7.fsf@eliezer.anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Zoran writes: > On Tue, 2017-03-21 at 10:34 -0700, Eric Anholt wrote: >> Michael Zoran writes: >>=20 >> > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote: >> > > Michael Zoran writes: >> > >=20 >> > > > > > Since the API is completely documented, I see no reason we >> > > > > > or >> > > > > > anybody >> > > > > > couldn't essentially rewrite the driver while it's in >> > > > > > staging.=C2=A0=C2=A0I >> > > > > > just >> > > > > > think it would be best for everyone if the new version was >> > > > > > a >> > > > > > drop >> > > > > > in >> > > > > > replacement for the original version.=C2=A0=C2=A0Essential an >> > > > > > enhancement >> > > > > > rather >> > > > > > then a competitor. >> > > > >=20 >> > > > > I think my comments weren't fundamental changes, but you >> > > > > surely >> > > > > mean >> > > > > the devicetree ABI? I like to see this driver ASAP out of >> > > > > staging >> > > > > and >> > > > > i'm not interested to maintain 2 functional identical driver >> > > > > only >> > > > > to >> > > > > keep compability with the Foundation tree. Currently i'm >> > > > > afraid >> > > > > that >> > > > > we build up many drivers in staging, which need a complete >> > > > > rewrite >> > > > > later if they should come out of staging. It would be nice if >> > > > > we >> > > > > could avoid the situation we have with the thermal driver. >> > > > >=20 >> > > > > Stefan >> > > >=20 >> > > > The API I'm talking about here is the mailbox API that is used >> > > > to >> > > > talk >> > > > to the firmware.=C2=A0=C2=A0The numbers and structures to pass are >> > > > documented.=C2=A0 >> > > > Nothing prevents anybody from rewriting this driver and >> > > > submitting >> > > > it >> > > > to the appropriate subsystems.=C2=A0=C2=A0It's certainly small eno= ugh. >> > > >=20 >> > > > If you really want working thermal or cpu speed drivers today, >> > > > nothing >> > > > stops anybody from submitting the downstream drivers after >> > > > doing >> > > > some >> > > > minor touchups and submitting them to staging.=C2=A0=C2=A0That wou= ld at >> > > > least >> > > > get >> > > > things working while people argue about what the correct DT >> > > > nodes >> > > > should be. >> > > >=20 >> > > > I would also like to point out that the RPI 3 has been out for >> > > > over >> > > > a >> > > > year and nobody has been able to get working video out of it >> > > > through >> > > > VC4 on a mainline tree.=C2=A0=C2=A0At least until now.=C2=A0=C2=A0= So I'm not sure >> > > > the >> > > > best >> > > > way to go is for the expander driver to go under the GPIO >> > > > subtree. >> > >=20 >> > > Excuse me?=C2=A0=C2=A0Display works fine on my Pi3.=C2=A0=C2=A0VC4 u= ses DDC to probe >> > > for >> > > connection when the GPIO line isn't present in the DT. >> >=20 >> > Just a FYI, Eric Anholt has offically announced support for VC4 for >> > HDMI on mainline Linus build without any support from the expander >> > on >> > the RPI 3.=C2=A0=C2=A0 >> >=20 >> > Sounds like this particular driver isn't needed then, correct? >>=20 >> That's the HDMI audio that just landed.=C2=A0=C2=A0HDMI has been working= on the >> pi3 since 9d44abbbb8d530e8cc97d71ffcbc0ff3b5553c62. >>=20 >> In the absence of a GPIO line for hotplug detect, we use DDC, which >> is >> slower and throws an error in dmesg when the probe happens but HDMI >> is >> disconnected.=C2=A0=C2=A0As such, having a GPIO driver would improve thi= ngs for >> people. > > > Would a non DT based solution be outside the realm of possibilities? I > wrote a very simple library that emulates vcgencmd from the kernel.=20 > One of the commands for vcgencmd is to query the HDMI hotplug status.=20 > It's sort of semi documentated on the web. The vcgencmd library works, > but I haven't tested if the virtualized hotplug info from the command > output is correct in all cases. > > What I'm thinking is I could package this in a single file library that > would get put in upstream, but it would only support 1 command only. To > query the virtual hotplug status. > > The only thing is you would need to take a dependency from VC4 to > vchiq/vc04_services. It would get VC4 working better on upstream, but > it would mean taking a dependency from VC4 to vc04_services and the > stagging tree(with all that imples). > > I think this may be a better solution then arguing with the DT folks on > this expander driver that isn't being directly controlled. > > What do you think? Not interested. We should expose the full GPIO expander using the firmware's GPIO expander interfaces, which is a more generally useful solution. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAljRl1QACgkQtdYpNtH8 nuglthAAqAKERMoaDo+4mgu4tBPtiaptA29G+bOc613BvaPdorCZH60WakqbwqFY u0S+eziMtSX7ZoRUmbwFj8Ibq9Ruu+nPiUT1gRgC7v/sYRMjvXfST9b4iVT0fYiP RRu41MDd+j74dEnZomKgazKij0ThHxn7UxIw6bHceJ3pqKjx1lQNyxDVS88Nboq4 PNXVtI3LmeItT/3SSiKZx8FMFSyTq4UG9b2eDgYqcYYdf11w3FMkMKCQybQPPjfK Rs2XcoHyP7zVBqGODsnzsDhy/62giQWs4o+CJfsJZQWrTOD+9gvF9EaAqg9ByHx6 AqxfHSOsIZhziNYD+C3I9wDdHaZ8hr7QurZqh6yJhrFJdTmWpXXZJE7MZGef3iI+ 5IeldKyZxajhlPiMDOe5/1yvVLvD7fxkMV4kl1hqJv0FeYs9SFcr6UZQSH5o19Nh 9q8aw3vN2FgnMlbIiXf4zfrdatIBwfjbR7RlY6e6Ir0yxFop1itpYevExRDQEWtI emkc30+MghmTjWho+HC23euPWMsE3vDJzFoDfCKBbtBEvN+XJgM7883qbw/Dm1y0 E2wRt9l7bORpR8hVm7dckLd5a/5nzTyXyyWt7BqUdG94Z1KvabLiguNhQNXZlCMV VL015rD2rfjLKCX2/vUpER2e4Qg0GKZM7kwH3p0IIIr266HrXVc= =4ibw -----END PGP SIGNATURE----- --=-=-=--