Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 19 December 2011 11:58, Guennadi Liakhovetski <g.liakhovetski@xxxxxx> wrote:
> On Mon, 19 Dec 2011, javier Martin wrote:
>
>> On 19 December 2011 11:41, Guennadi Liakhovetski <g.liakhovetski@xxxxxx> wrote:
>> > On Mon, 19 Dec 2011, Laurent Pinchart wrote:
>> >
>> >> Hi Guennadi,
>> >>
>> >> On Monday 19 December 2011 11:13:58 Guennadi Liakhovetski wrote:
>> >> > On Mon, 19 Dec 2011, Laurent Pinchart wrote:
>> >> > > On Monday 19 December 2011 09:09:34 Guennadi Liakhovetski wrote:
>> >> > > > On Mon, 19 Dec 2011, Laurent Pinchart wrote:
>> >> > > > > On Friday 16 December 2011 10:50:21 Guennadi Liakhovetski wrote:
>> >> > > > > > On Fri, 16 Dec 2011, Scott Jiang wrote:
>> >> > > > > > > >> How about this implementation? I know it's not for soc, but I
>> >> > > > > > > >> post it to give my idea.
>> >> > > > > > > >> Bridge knows the layout, so it doesn't need to query the
>> >> > > > > > > >> subdevice.
>> >> > > > > > > >
>> >> > > > > > > > Where from? AFAIU, we are talking here about subdevice inputs,
>> >> > > > > > > > right? In this case about various inputs of the TV decoder. How
>> >> > > > > > > > shall the bridge driver know about that?
>> >> > > > > > >
>> >> > > > > > > I have asked this question before. Laurent reply me:
>> >> > > > > > > > >> ENUMINPUT as defined by V4L2 enumerates input connectors
>> >> > > > > > > > >> available on the board. Which inputs the board designer
>> >> > > > > > > > >> hooked up is something that only the top-level V4L driver
>> >> > > > > > > > >> will know. Subdevices do not have that information, so
>> >> > > > > > > > >> enuminputs is not applicable there.
>> >> > > > > > > > >>
>> >> > > > > > > > >> Of course, subdevices do have input pins and output pins,
>> >> > > > > > > > >> but these are assumed to be fixed. With the s_routing ops
>> >> > > > > > > > >> the top level driver selects which input and output pins
>> >> > > > > > > > >> are active. Enumeration of those inputs and outputs
>> >> > > > > > > > >> wouldn't gain you anything as far as I can tell since the
>> >> > > > > > > > >> subdevice simply does not know which inputs/outputs are
>> >> > > > > > > > >> actually hooked up. It's the top level driver that has that
>> >> > > > > > > > >> information (usually passed in through board/card info
>> >> > > > > > > > >> structures).
>> >> > > > > >
>> >> > > > > > Laurent, right, I now remember reading this discussion before. But
>> >> > > > > > I'm not sure I completely agree:-) Yes, you're right - the board
>> >> > > > > > decides which pins are routed to which connectors. And it has to
>> >> > > > > > provide this information to the driver in its platform data. But -
>> >> > > > > > I think, this information should be provided not to the bridge
>> >> > > > > > driver, but to respective subdevice drivers, because only they
>> >> > > > > > know what exactly those interfaces are good for and how to report
>> >> > > > > > them to the bridge or the user, if we decide to also export this
>> >> > > > > > information over the subdevice user-space API.
>> >> > > > > >
>> >> > > > > > So, I would say, the board has to tell the subdevice driver: yes,
>> >> > > > > > your inputs 0 and 1 are routed to external connectors. On input 1
>> >> > > > > > I've put a pullup, it is connected to connector of type X over a
>> >> > > > > > circuit Y, clocked from your output Z, if the driver needs to know
>> >> > > > > > all that. And the subdev driver will just tell the bridge only
>> >> > > > > > what that one needs to know - number of inputs and their
>> >> > > > > > capabilities.
>> >> > > > >
>> >> > > > > That sounds reasonable.
>> >> > > >
>> >> > > > Good, this would mean, we need additional subdevice operations along
>> >> > > > the lines of enum_input and enum_output, and maybe also g_input and
>> >> > > > g_output?
>> >> > >
>> >> > > What about implementing pad support in the subdevice ? Input enumeration
>> >> > > could then be performed without a subdev operation.
>> >> >
>> >> > soc-camera doesn't support pad operations yet.
>> >>
>> >> soc-camera doesn't support enum_input yet either, so you need to implement
>> >> something anyway ;-)
>> >>
>> >> You wouldn't need to call a pad operation here, you would just need to iterate
>> >> through the pads provided by the subdev.
>> >
>> > tvp5150 doesn't implement it either yet. So, I would say, it is a better
>> > solution ATM to fix this functionality independent of the pad-level API.
>>
>> I agree,
>> I cannot contribute to implement pad-level API stuff since I can't
>> test it with tvp5150.
>>
>> Would you accept a patch implementing only S_INPUT?
>
> Sorry, maybe I'm missing something, but how would it work? I mean, how can
> we accept from the user any S_INPUT request with index != 0, if we always
> return only 0 in reply to ENUM_INPUT? Ok, G_INPUT we could implement
> internally in soc-camera: return 0 by default, then remember last set
> input number per soc-camera device / subdev. But ENUM_INPUT?...

It clearly is not a complete solution but at least it allows setting
input 0 in broken drivers such as tvp5150 which have input 1 enabled
by default, while soc-camera assumes input 0 is enabled.


-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux