Re: [PATCH v2 3/3] media: dt-bindings: vpif: new optional property
From: Sekhar Nori <hidden>
Date: 2017-03-01 15:41:43
Also in:
linux-arm-kernel, lkml
On Tuesday 28 February 2017 07:56 PM, Rob Herring wrote:
On Mon, Feb 27, 2017 at 11:36 PM, Sekhar Nori [off-list ref] wrote:quoted
On Tuesday 28 February 2017 04:22 AM, Rob Herring wrote:quoted
On Wed, Feb 22, 2017 at 02:43:47PM +0100, Bartosz Golaszewski wrote:quoted
Add an optional property - enable-gpios - which can be used to specify the GPIOs that must be requested to select the vpif functionality. Signed-off-by: Bartosz Golaszewski <redacted> --- Documentation/devicetree/bindings/media/ti,da850-vpif.txt | 7 +++++++ 1 file changed, 7 insertions(+)diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt index df7182a..23c5405 100644 --- a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt +++ b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt@@ -13,6 +13,9 @@ Required properties: - reg: physical base address and length of the registers set for the device; - interrupts: should contain IRQ line for the VPIF +Optional properties: +- enable-gpios: phandle of the GPIOs used to select the vpif functionalityWhat does this control exactly? The GPIOs belong in the node they are connected to and having GPIOs routed to this block seems strange.The DA850 EVM board implements on-board muxing which lets the video input (via VPIF) to be routed to a TVP5147 (video decoder) for composite input or to a camera header. There are other mux options which use the same VPIF SoC pins (RMII ethernet or character LCD). There is a three-to-eight demux on the board which drives enable signals to buffers letting you choose from these options. From your response, it looks like you want the enable-gpios property to be in the TVP5147 or camera node. That does make sense to me.Well, seems like they should be part of a mux node. I'd suggest you look at the video-multiplexer binding under review[1]. Though for other non video functions, that would be some sort of board level pin mux control. There's a new mux binding too, maybe that would work. In any case, it shouldn't be the VPIF driver controlling the GPIOs directly.
Yeah, since there are non-video functions involved, we need a more generic mux binding. I see the work Peter Rosin is doing[1]. Its not in linux-next yet, but seems quite near merging. [1] https://lkml.org/lkml/2017/2/8/394 Thanks, Sekhar