lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 6 Aug 2015 11:16:37 +0100 From: Liviu Dudau <Liviu.Dudau@....com> To: Russell King - ARM Linux <linux@....linux.org.uk> Cc: David Airlie <airlied@...ux.ie>, "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Mark Rutland <Mark.Rutland@....com>, Jon Medhurst <tixy@...aro.org>, Arnd Bergmann <arnd@...db.de>, Pawel Moll <Pawel.Moll@....com>, Ian Campbell <ijc+devicetree@...lion.org.uk>, Catalin Marinas <Catalin.Marinas@....com>, Sudeep Holla <Sudeep.Holla@....com>, Will Deacon <Will.Deacon@....com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>, Kumar Gala <galak@...eaurora.org>, Olof Johansson <olof@...om.net> Subject: Re: [PATCH 3/4] arm64: Juno: Add HDLCD support to the Juno boards. On Wed, Aug 05, 2015 at 10:48:54PM +0100, Russell King - ARM Linux wrote: > On Wed, Aug 05, 2015 at 08:03:12PM +0100, Liviu Dudau wrote: > > I have to confess that I am not entirely up to speed with the TDA19988 > > situation at the moment. Andrew Jackson was dealing with that and > > working with Jean to get that in the upstream, but his contract has > > ended and he has moved to other things. > > Umm, I'm the maintainer for TDA998x: > > NXP TDA998X DRM DRIVER > M: Russell King <rmk+kernel@....linux.org.uk> > S: Supported > F: drivers/gpu/drm/i2c/tda998x_drv.c > F: include/drm/i2c/tda998x.h > > It would be nice if people worked with the actual maintainers of things > rather than random other people... Sorry, it was my mistake, I have blindly followed the get_maintainers.pl generated list of email rather than engage my brain and realise that part of the patch also affects TDA19988 driver. > > > > Also, the whole question of representing connectors in a DRM model is > > > yet to be established. Yes, DT should describe the hardware, but we > > > don't yet know _how_ to describe physical connectors with stuff > > > implemented on top of DRM yet, and we have nothing that makes use of > > > this. > > > > Please help me understand the current situation: you have added > > support for components that the video drivers can use and the bindings > > for that are described in Documentation/devicetree/bindings/media/video-interfaces.txt. > > No. I added the component helpers, which are entirely firmware agnostic. > The media bindings were created by others, and through development done > by Pengutronix, they were factored out of media into common DT code and > re-used for the IMX DRM driver. The binding document which describes > that work is not the one you refer to above, but this one: > > Documentation/devicetree/bindings/graph.txt > > This started them as a basis for DRM drivers on ARM - but it's never been > officially "adopted" as a method to describe DRM drivers - it's only what > some drivers are using. It ought to be nailed down as a way to ensure > inter-operability between components though, but no one has really made > that decision. OK, I'm interested on whom do I need to talk to in order for the official "adoption" to happen here. > > > According to that document my patch should be compliant once I add the > > reg= property. Is that something that cannot be used with tda998x driver > > or is there any other reason why you think the patch is not compliant? > > Jean's proposal to add audio support to the TDA998x driver does it via > this change to the binding spec: > > +Optional nodes: > + > + - port: up to three ports. > + The ports are defined according to [1]. > + > + Video port. > + There may be only one video port. > + This one must contain the following property: > + > + - port-type: must be "rgb" > + > + and may contain the optional property: > + > + - reg: 24 bits value which defines how the video controller > + output is wired to the TDA998x input (video pins) > + When absent, the default value is <0x230145>. > + > + Audio ports. > + There may be one or two audio ports. > + These ones must contain the following properties: > + > + - port-type: must be "i2s" or "spdif" > + > + - reg: 8 bits value which defines how the audio controller > + output is wired to the TDA998x input (audio pins) > + > +[1] Documentation/devicetree/bindings/graph.txt > > (That's not a particularly precise definition, but it's what we have at > the moment.) > > > If you are referring to connecting an encoder with a HDMI connector, I > > have tested that and it seems to work, although my situation is simple > > because there are no options in my setup: one HDLCD connects to one > > TDA19988 which connects to one HDMI output. > > Right now, the TDA998x will ignore the additional information, but that > won't be the case with Jean's audio work (see the above binding > information.) Yes, I have seen that patchset. I will apply it to my tree and send an updated version with the port-type property when I send v2. Best regards, Liviu > > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net. > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists