[PATCH 02/10] support 88pm8606 in 860x driver

Samuel Ortiz sameo at linux.intel.com
Mon Dec 7 06:39:28 EST 2009


Hi Haojian

On Mon, Dec 07, 2009 at 02:34:58AM -0500, Haojian Zhuang wrote:
> On Mon, Nov 30, 2009 at 5:19 AM, Samuel Ortiz <sameo at linux.intel.com> wrote:
> > Hi Haojian,
> >
> > On Sun, Nov 29, 2009 at 08:43:45PM -0500, Haojian Zhuang wrote:
> >> > On the other hand if it is impossible from a HW point of view to have a
> >> > platform design where you'd have either a single 8806 or a single 8807, then 2
> >> > things:
> >> > - Your driver design would be ok.
> >> [Haojian]: Great Thanks :)
> >> > - Those chip designs are really bad as it should be one and only one single
> >> > (and in particular only use one single i2c address space and id)
> >> [Haojian]: I agree this opinion that the same functionality logic
> >> should be placed into one chip and using single i2c address. If same
> >> functionality logic can be in one chip, the driver could be simpler
> >> without glue logic.
> >> >
> >> > Cheers,
> >> > Samuel.
> >> >
> >> >
> >> Hi Samuel,
> >>
> >> I tried to add some comments of the chip's background. Up to now, I
> >> can't find a better idea to handle this driver without mixed structure
> >> since usb charger linkes them tightly. If there's a better prototype
> >> to handle this, I'll adopt it.
> > Thanks for the explanations, I appreciate.
> > Only the board definition can describe what's the relationship between your
> > 8806 and 8807, so here is what I propose: Add an i2c address to your 880x
> > platform data, and have only a 8806 definition on your board specific file.
> > Then from the 880x driver, you check for the platform data i2c address. If
> > it's a valid one, that means we are expecting a 8807 to be present on the
> > board and thus we can instantiate this i2c device by calling i2c_new_device().
> > That will give you a link to your 8807 i2c client from your 8806. The
> > advantage of that solution is to keep the 880x driver board and design
> > neutral while avoiding any static definitions.
> > Waiting for your feedback.
> >
> Hi Samuel,
> 
> Excuse me to response late. If I implement i2c_new_device(), I should
> have to create adapter, algorithm and so on. It means that I have to
> implement i2c-pxa.c duplicately in mfd driver. Is it right?
I dont think so, no. i2c_new_device should be called at i2c probe time. Your
8806 is probed, and you then check the corresponding platform data. If there
is a valid additional 8807 i2c address, it means that your platform comes with
a 8807. You then need to call i2c_new_device(), on the same adapter as your
8806 is sitting in, i.e. i2c_client->adapter. You would build the 8807
board_info structure from your platform data i2c address.
Jean does that make sense from an i2c point of view ? Please let me know if
you need more background on this issue.


> And you want to us i2c_new_device(). Does it mean that there's only
> 8607 device and address in platform driver and mfd driver
> distinguishing 8606 from platform data?
That's correct, yes. As I said, the only place where you can correctly
describe the relationship between your 8806 and 8807 is your platform data.

Cheers,
Samuel.

> Thanks
> Haojian

-- 
Intel Open Source Technology Centre
http://oss.intel.com/



More information about the linux-arm-kernel mailing list