linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Timur Tabi <timur@freescale.com>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org, kumar.gala@freescale.com
Subject: Re: [PATCH] i2c-mpc: use the cell-index property to enumerate the I2C adapters
Date: Thu, 1 Dec 2011 14:54:13 -0600	[thread overview]
Message-ID: <4ED7E975.6090704@freescale.com> (raw)
In-Reply-To: <4ED7CA64.2080503@freescale.com>

Scott Wood wrote:
> On 12/01/2011 11:33 AM, Timur Tabi wrote:
>> An I2C device tree node can contain a 'cell-index' property that can be
>> used to enumerate the I2C devices.  If such a property exists, use it
>> to specify the I2C adapter number.
> 
> Didn't we decide a long time ago that this was a bad idea?

I don't see what's wrong with it.

>> This feature is necessary for the Freescale PowerPC audio drivers (e.g.
>> on the P1022DS).  The "machine driver" needs to know the adapter number
>> for each I2C adapter, but it only has access to the device tree.
>> Previously, the I2C nodes always appeared in cell-index order, so the
>> dynamic numbering coincided with the cell-index property.  With commit
>> ab827d97 ("powerpc/85xx: Rework P1022DS device tree"), the I2C nodes are
>> unintentionally reversed in the device tree, and so the machine driver
>> guesses the wrong I2C adapter number.
> 
> What specifically do you need this number for?  What does it represent?

Well, I thought the above paragraph explained it pretty well.

Audio drivers come in sets of four -- machine, ssi, dma, and codec.  The machine driver needs to know which ssi is connected to which codec and which DMA channel(s) it needs to use.  So I extract all this information from the device tree.  

The individual drivers, however, register only with their own subsystem.  So the codec driver, for example, doesn't know anything about device trees -- it just registers as an i2c driver.  That means that the machine driver has to guess what name the codec driver will use when it registers.  In this case, that's the i2c device name, which include the I2C adapter number (adap->nr).  That means that given a device tree node, I need to know what the actual bus number is.

An alternative approach is to create a function like this:

	struct i2c_adapter *i2c_adapter_from_node(struct device_node *np);

I could then just use adap->nr directly.

-- 
Timur Tabi
Linux kernel developer at Freescale

  reply	other threads:[~2011-12-01 20:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-01 17:33 [PATCH] i2c-mpc: use the cell-index property to enumerate the I2C adapters Timur Tabi
2011-12-01 18:41 ` Scott Wood
2011-12-01 20:54   ` Timur Tabi [this message]
2011-12-01 21:29     ` Scott Wood
2011-12-01 21:46       ` Timur Tabi
2011-12-01 21:52         ` Scott Wood
2011-12-01 21:55           ` Grant Likely
2011-12-01 21:59             ` Timur Tabi
2011-12-01 21:59           ` Timur Tabi
2011-12-01 22:05             ` Scott Wood
2011-12-01 22:10               ` Timur Tabi

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=4ED7E975.6090704@freescale.com \
    --to=timur@freescale.com \
    --cc=kumar.gala@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.com \
    /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).