All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Gao <bin_gao@linux.intel.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Bin Gao <bin.gao@linux.intel.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	linux-i2c@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: i2c: introduce i2c helper i2c_find_client_by_name()
Date: Fri, 21 Jun 2013 17:27:49 -0700	[thread overview]
Message-ID: <51C4EF85.7010607@linux.intel.com> (raw)
In-Reply-To: <20130619101348.GE2950@katana>

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


WARNING: multiple messages have this Message-ID (diff)
From: Bin Gao <bin_gao-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Cc: Bin Gao <bin.gao-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Andy Shevchenko
	<andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: i2c: introduce i2c helper i2c_find_client_by_name()
Date: Fri, 21 Jun 2013 17:27:49 -0700	[thread overview]
Message-ID: <51C4EF85.7010607@linux.intel.com> (raw)
In-Reply-To: <20130619101348.GE2950@katana>

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

  reply	other threads:[~2013-06-22  0:27 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-06 18:33 i2c: introduce i2c helper i2c_find_client_by_name() Bin Gao
2013-06-06 18:33 ` Bin Gao
2013-06-06 20:32 ` Andy Shevchenko
2013-06-06 20:32   ` Andy Shevchenko
2013-06-06 21:26   ` Bin Gao
2013-06-06 21:26     ` Bin Gao
2013-06-09 19:53     ` Andy Shevchenko
2013-06-09 19:53       ` Andy Shevchenko
2013-06-11 17:11       ` Bin Gao
2013-06-14  7:29         ` Andy Shevchenko
2013-06-14  7:29           ` Andy Shevchenko
2013-06-14 19:00           ` Bin Gao
2013-06-14 19:00             ` Bin Gao
2013-06-19 10:13             ` Wolfram Sang
2013-06-19 10:13               ` Wolfram Sang
2013-06-22  0:27               ` Bin Gao [this message]
2013-06-22  0:27                 ` Bin Gao
2013-06-23 12:43                 ` Wolfram Sang
2013-06-23 12:43                   ` Wolfram Sang
2013-07-05 19:55 ` Mark Brown
2013-07-12 10:54   ` Andy Shevchenko
2013-07-12 10:54     ` Andy Shevchenko
2013-07-12 11:00     ` Wolfram Sang
2013-07-12 11:00       ` Wolfram Sang
2013-07-12 11:02       ` Laurent Pinchart
2013-07-12 11:02         ` Laurent Pinchart
2013-07-12 11:29       ` Andy Shevchenko
2013-07-12 11:29         ` Andy Shevchenko
2013-07-12 11:35         ` Laurent Pinchart
2013-07-12 11:35           ` Laurent Pinchart
2013-07-12 11:56           ` Andy Shevchenko
2013-07-12 11:56             ` Andy Shevchenko

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=51C4EF85.7010607@linux.intel.com \
    --to=bin_gao@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=bin.gao@linux.intel.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wsa@the-dreams.de \
    /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.