On 6/19/2013 3:13 AM, Wolfram Sang wrote:
Even you prefer to extend v4l2, you still need this helper.
The idea is just to move the unregister/register from a specific ISP driver
to v4l2.
I think you misunderstood my pionts somehow. Let me clarfiy a little bit:
Current solution:
1. Platform codes(on top of DT/ACPI5/SFI) don't call i2c_register_board_info(),
instead, prepare a table(kind of platform data) that has all camera i2c device information.
2. ISP driver registers devices listed in the table to i2c core - this makes sure
v4l2 takes over these devices.
The problem with this solution is that when a camera device runs on both ACPI5 and
SFI, the platform codes will get a bit complicated and it's difficult to ensure one
binary kernel runs on both platforms(ACPI5 and SFI).
(To extend v4l2 with this solution doen't resolve my problem)
Solution I'm suggesting:
1. Let the platform codes call i2c_register_board_info() anyway.
2. Since ISP driver knows which camera devices it supports, so it simply unregisters
those devices (get the client by the introduced helper), then register it within v4l2.
This solution ensure one binary kernel can run on both platforms.
(To extend v4l2 with this solution could not be feasible, the device table is
ISP driver specific, not v4l2 specific)
I also wonder about the need to unregister. I have to admit I don't know
much about I2C handling in v4l2. But if it requires unregistering from
i2c core and registering to v4l2 core, then it sounds to me like we
could check if there is a more fundamential cleanup needed? Deferring
for now, looks like an issue worth looking at, yet there are other
things in the queue first.
Platform codes are supposed to call i2c_register_board_info() or
i2c_new_device() to register devices, we don't want to change this.
Not sure v4l2 can still take over the devices without
unregistering/registering. Need look deeply into the v4l2 code...
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
