Thread (1 message) 1 message, 1 author, 2012-10-08

Re: [PATCH 05/14] media: add a V4L2 OF parser

From: Guennadi Liakhovetski <hidden>
Date: 2012-10-08 16:00:45
Also in: linux-media, linux-sh

On Mon, 8 Oct 2012, Guennadi Liakhovetski wrote:
On Mon, 8 Oct 2012, Hans Verkuil wrote:
quoted
On Mon October 8 2012 17:15:53 Guennadi Liakhovetski wrote:
[snip]
quoted
quoted
No, I don't think there is a way to get a device pointer from a DT node.
Not a device pointer, but the i2c bus and i2c address. With that information
you can get the i2c_client, and with that you can get the subdev pointer.
How? How can you get a client pointer from adapter and i2c device address? 
I haven't found anything suitable in i2c.h.
Ok, you could use of_find_i2c_device_by_node(), but the second argument 
remains - if you need notifiers in one case, I don't think it makes sense 
to implement multiple methods.

Thanks
Guennadi
quoted
If there is no way to get that information from the proposed V4L2 DT, then
it needs to be modified since a bridge driver really needs to know which
subdevs it has to register with the v4l2_device struct. That information is
also board specific so it should be part of the DT.
quoted
quoted
In my view you cannot do a proper initialization unless you have both the
bridge driver and all subdev drivers loaded and instantiated. They need one
another. So I am perfectly fine with letting the probe function do next to
nothing and postponing that until register() is called. I2C and actual probing
to check if it's the right device is a bad idea in general since you have no
idea what a hardware access to an unknown i2c device will do. There are still
some corner cases where that is needed, but I do not think that that is an
issue here.

It would simplify things a lot IMHO. Also note that the register() op will
work with any device, not just i2c. That may be a useful property as well.
And what if the subdevice device is not yet instantiated by OF by the time 
your bridge driver probes?
That is where you still need to have a bus notifier mechanism. You have to be
able to wait until all dependent drivers are loaded/instantiated,
No, drivers are not the problem, as you say, you can load them. Devices 
are the problem. You don't know when they will be registered.
quoted
or
alternatively you have to be able to load them explicitly. But this should
be relatively easy to implement in a generic manner.
So, if you need notifiers anyway, why not use them in all cases instead of 
mixing multiple methods?

Thanks
Guennadi
quoted
I still think this sucks (excuse my language), but I see no way around it as
long as there is no explicit probe order one can rely on.

Regards,

	Hans
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help