From: khilman@baylibre.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 0/5] davinci: VPIF: add DT support
Date: Thu, 08 Dec 2016 16:25:40 -0800 [thread overview]
Message-ID: <m2oa0maqyj.fsf@baylibre.com> (raw)
In-Reply-To: <CABxcv=nrDACjfjStNPky5_y5zXBpzLZyO3g9WuOz95C6b_bgOg@mail.gmail.com> (Javier Martinez Canillas's message of "Wed, 7 Dec 2016 17:03:13 -0300")
Hi Javier,
Javier Martinez Canillas <javier@dowhile0.org> writes:
> On Wed, Dec 7, 2016 at 3:30 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> Prepare the groundwork for adding DT support for davinci VPIF drivers.
>> This series does some fixups/cleanups and then adds the DT binding and
>> DT compatible string matching for DT probing.
>>
>> The controversial part from previous versions around async subdev
>> parsing, and specifically hard-coding the input/output routing of
>> subdevs, has been left out of this series. That part can be done as a
>> follow-on step after agreement has been reached on the path forward.
>
> I had a similar need for another board (OMAP3 IGEPv2), that has a
> TVP5151 video decoder (that also supports 2 composite or 1 s-video
> signal) attached to the OMAP3 ISP.
>
> I posted some RFC patches [0] to define the input signals in the DT,
> and AFAICT Laurent and Hans were not against the approach but just had
> some comments on the DT binding.
>
> Basically they wanted the ports to be directly in the tvp5150 node
> instead of under a connectors sub-node [1] and to just be called just
> a (input / output) port instead of a connector [2].
>
> Unfortunately I was busy with other tasks so I couldn't res-pin the
> patches, but I think you could have something similar in the DT
> binding for your case and it shouldn't be hard to parse the ports /
> endpoints in the driver to get that information from DT and setup the
> input and output pins.
Thanks for pointing that out. I did see this in Hans' reply to one of
my earlier versions. Indeed I think this could be useful in solving my
problem.
>> With is version, platforms can still use the VPIF capture/display
>> drivers, but must provide platform_data for the subdevs and subdev
>> routing.
>>
>
> I guess DT backward compatibility isn't a big issue on this platform,
> since support for the platform is quite recently and after all someone
> who wants to use the vpif with current DT will need platform data and
> pdata-quirks anyways.
That's correct.
> So I agree with you that the input / output signals lookup from DT
> could be done as a follow-up.
Thanks. I'll happily add the input/output signals once they're agreed
upon. In the mean time, at least we can have a usable video capture on
this platform, and it's at least a step in the right direction for DT
support.
Thanks for the review,
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@baylibre.com>
To: Javier Martinez Canillas <javier@dowhile0.org>
Cc: "Hans Verkuil" <hverkuil@xs4all.nl>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
"Sakari Ailus" <sakari.ailus@iki.fi>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"Sekhar Nori" <nsekhar@ti.com>,
"Axel Haslam" <ahaslam@baylibre.com>,
"Bartosz Gołaszewski" <bgolaszewski@baylibre.com>,
"Alexandre Bailon" <abailon@baylibre.com>,
"David Lechner" <david@lechnology.com>,
"Patrick Titiano" <ptitiano@baylibre.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v6 0/5] davinci: VPIF: add DT support
Date: Thu, 08 Dec 2016 16:25:40 -0800 [thread overview]
Message-ID: <m2oa0maqyj.fsf@baylibre.com> (raw)
In-Reply-To: <CABxcv=nrDACjfjStNPky5_y5zXBpzLZyO3g9WuOz95C6b_bgOg@mail.gmail.com> (Javier Martinez Canillas's message of "Wed, 7 Dec 2016 17:03:13 -0300")
Hi Javier,
Javier Martinez Canillas <javier@dowhile0.org> writes:
> On Wed, Dec 7, 2016 at 3:30 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> Prepare the groundwork for adding DT support for davinci VPIF drivers.
>> This series does some fixups/cleanups and then adds the DT binding and
>> DT compatible string matching for DT probing.
>>
>> The controversial part from previous versions around async subdev
>> parsing, and specifically hard-coding the input/output routing of
>> subdevs, has been left out of this series. That part can be done as a
>> follow-on step after agreement has been reached on the path forward.
>
> I had a similar need for another board (OMAP3 IGEPv2), that has a
> TVP5151 video decoder (that also supports 2 composite or 1 s-video
> signal) attached to the OMAP3 ISP.
>
> I posted some RFC patches [0] to define the input signals in the DT,
> and AFAICT Laurent and Hans were not against the approach but just had
> some comments on the DT binding.
>
> Basically they wanted the ports to be directly in the tvp5150 node
> instead of under a connectors sub-node [1] and to just be called just
> a (input / output) port instead of a connector [2].
>
> Unfortunately I was busy with other tasks so I couldn't res-pin the
> patches, but I think you could have something similar in the DT
> binding for your case and it shouldn't be hard to parse the ports /
> endpoints in the driver to get that information from DT and setup the
> input and output pins.
Thanks for pointing that out. I did see this in Hans' reply to one of
my earlier versions. Indeed I think this could be useful in solving my
problem.
>> With is version, platforms can still use the VPIF capture/display
>> drivers, but must provide platform_data for the subdevs and subdev
>> routing.
>>
>
> I guess DT backward compatibility isn't a big issue on this platform,
> since support for the platform is quite recently and after all someone
> who wants to use the vpif with current DT will need platform data and
> pdata-quirks anyways.
That's correct.
> So I agree with you that the input / output signals lookup from DT
> could be done as a follow-up.
Thanks. I'll happily add the input/output signals once they're agreed
upon. In the mean time, at least we can have a usable video capture on
this platform, and it's at least a step in the right direction for DT
support.
Thanks for the review,
Kevin
next prev parent reply other threads:[~2016-12-09 0:25 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-07 18:30 [PATCH v6 0/5] davinci: VPIF: add DT support Kevin Hilman
2016-12-07 18:30 ` Kevin Hilman
2016-12-07 18:30 ` [PATCH v6 1/5] [media] davinci: VPIF: fix module loading, init errors Kevin Hilman
2016-12-07 18:30 ` Kevin Hilman
2016-12-09 10:07 ` Sakari Ailus
2016-12-09 10:07 ` Sakari Ailus
2016-12-16 9:44 ` Hans Verkuil
2016-12-16 9:44 ` Hans Verkuil
2016-12-16 23:39 ` Kevin Hilman
2016-12-16 23:39 ` Kevin Hilman
2016-12-17 0:47 ` [PATCH v6.1 " Kevin Hilman
2016-12-17 0:47 ` Kevin Hilman
2016-12-07 18:30 ` [PATCH v6 2/5] [media] davinci: vpif_capture: remove hard-coded I2C adapter id Kevin Hilman
2016-12-07 18:30 ` Kevin Hilman
2016-12-09 10:20 ` Sakari Ailus
2016-12-09 10:20 ` Sakari Ailus
2016-12-07 18:30 ` [PATCH v6 3/5] [media] davinci: vpif_capture: fix start/stop streaming locking Kevin Hilman
2016-12-07 18:30 ` Kevin Hilman
2016-12-07 18:30 ` [PATCH v6 4/5] [media] dt-bindings: add TI VPIF documentation Kevin Hilman
2016-12-07 18:30 ` Kevin Hilman
2016-12-07 18:30 ` [PATCH v6 5/5] [media] davinci: VPIF: add basic support for DT init Kevin Hilman
2016-12-07 18:30 ` Kevin Hilman
2016-12-07 20:03 ` [PATCH v6 0/5] davinci: VPIF: add DT support Javier Martinez Canillas
2016-12-07 20:03 ` Javier Martinez Canillas
2016-12-09 0:25 ` Kevin Hilman [this message]
2016-12-09 0:25 ` Kevin Hilman
2016-12-16 9:47 ` Hans Verkuil
2016-12-16 9:47 ` Hans Verkuil
2016-12-17 0:49 ` Kevin Hilman
2016-12-17 0:49 ` Kevin Hilman
2017-01-27 17:22 ` Kevin Hilman
2017-01-27 17:22 ` Kevin Hilman
2017-01-30 9:33 ` Hans Verkuil
2017-01-30 9:33 ` Hans Verkuil
2017-01-03 9:03 ` Sekhar Nori
2017-01-03 9:03 ` Sekhar Nori
2017-01-03 9:12 ` Laurent Pinchart
2017-01-03 9:12 ` Laurent Pinchart
2017-01-04 11:32 ` Sekhar Nori
2017-01-04 11:32 ` Sekhar Nori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2oa0maqyj.fsf@baylibre.com \
--to=khilman@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.