linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sameo@linux.intel.com (Samuel Ortiz)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/10] support 88pm8606 in 860x driver
Date: Mon, 30 Nov 2009 11:19:44 +0100	[thread overview]
Message-ID: <20091130101943.GA3696@sortiz.org> (raw)
In-Reply-To: <771cded00911291743u76688d24ja40a30472ebd6af8@mail.gmail.com>

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.

Cheers,
Samuel.
 
> Thanks
> Haojian

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

  reply	other threads:[~2009-11-30 10:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-13  8:54 [PATCH 02/10] support 88pm8606 in 860x driver Haojian Zhuang
2009-11-20 15:02 ` Samuel Ortiz
2009-11-22  0:25   ` Haojian Zhuang
2009-11-27 14:58     ` Samuel Ortiz
2009-11-30  1:43       ` Haojian Zhuang
2009-11-30 10:19         ` Samuel Ortiz [this message]
2009-12-07  7:34           ` Haojian Zhuang
2009-12-07 11:39             ` Samuel Ortiz
2009-12-07 12:15               ` Jean Delvare
2009-12-07 12:47                 ` Haojian Zhuang
2009-12-07 13:38                   ` Jean Delvare
2009-12-07 13:59                     ` Samuel Ortiz
2009-12-09 13:07                       ` Haojian Zhuang

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=20091130101943.GA3696@sortiz.org \
    --to=sameo@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).