From: Scott Wood <scottwood@freescale.com>
To: Timur Tabi <timur@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 15:29:18 -0600 [thread overview]
Message-ID: <4ED7F1AE.70806@freescale.com> (raw)
In-Reply-To: <4ED7E975.6090704@freescale.com>
On 12/01/2011 02:54 PM, Timur Tabi wrote:
> 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.
Obviously, since you're suggesting doing it. :-P
Did you search for the old discussions?
How is this going to interact with other i2c buses (e.g. on a board
FPGA) that might have a conflicting static numbering scheme? Have you
ensured that no dynamic bus registrations (e.g. an i2c bus on a PCI
device) can happen before the static SoC i2c buses are added?
Global numberspaces of this sort are usually the wrong answer. Look at
the mess it made with IRQ numbers, and the gymnastics we go through to
virtualize 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.
All you said was "needs to know the adapter number", nothing about why.
> 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.
If there isn't a way to get a "struct device" from "struct device_node",
we should add it. From that you should be able to look up the sysfs
name -- no need to mess around with adap->nr as an intermediary.
-Scott
next prev parent reply other threads:[~2011-12-01 21:31 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
2011-12-01 21:29 ` Scott Wood [this message]
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=4ED7F1AE.70806@freescale.com \
--to=scottwood@freescale.com \
--cc=kumar.gala@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=timur@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).