Re: i2c: introduce i2c helper i2c_find_client_by_name()

[Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]


> 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.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]