Hi Timur,
Anyone know when of_i2c.c is going to come online replace what's in
fsl_soc.c?
There is a patch being prepared to convert i2c-mpc from a platform driver to an
of_platform driver
making the fsl_soc.c code obsolete. See:
http://patchwork.ozlabs.org/linuxppc/patch?id=18898
Thanks,
Benjamin Herrenschmidt wrote:
No, the fabric driver should get to its device node in a way or another,
and from there, find a pointer (via a phandle) to it's codec, and match
that to an i2c device.
If the current infrastructure doesn't allow that kind of matching, it
needs to be fixed.
Hi Ben,
On Fri, 06 Jun 2008 14:16:23 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2008-06-05 at 09:48 +0200, Jean Delvare wrote:
As far as I am concerned, it's really up to the maintainers and users
of this platform. All I am asking for is that you do not call
i2c_add_numbered_adapter() on
On Fri, Jun 6, 2008 at 12:21 AM, Jean Delvare [EMAIL PROTECTED] wrote:
Hi Ben,
On Fri, 06 Jun 2008 14:16:23 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2008-06-05 at 09:48 +0200, Jean Delvare wrote:
As far as I am concerned, it's really up to the maintainers and users
of this platform.
On Fri, 2008-06-06 at 08:21 +0200, Jean Delvare wrote:
We could certainly add a busname field to struct i2c_devinfo and
implement i2c_register_board_info_by_name() if it seems to be worth
the
extra code and memory. I am open to the idea if it solves a problem
with no other clean solution.
David Gibson wrote:
Aliases aren't trivially reversible, but it shouldn't be too hard to
write a helper function which will do the scan and parse you describe.
How about I submit a patch adding a function called of_get_aliased_index()?
--
Timur Tabi
Linux Kernel Developer @ Freescale
On Friday 06 June 2008, Timur Tabi wrote:
David Gibson wrote:
Aliases aren't trivially reversible, but it shouldn't be too hard to
write a helper function which will do the scan and parse you describe.
How about I submit a patch adding a function called
of_get_aliased_index()?
Would be
Well, I just don't see the point of having two different properties
that say the
same thing. I'm not an IEE 1275 purist, so I don't think we should
be hampered
by old node definitions. I especially don't like having a property
specifically
for indexing I2C nodes that can't be used to
Aliases can also provide a reasonable way of enumerating devices, if
reg isn't suitable on its own.
Yes. In almost all cases, drivers and subsystems do not need this at
all though. In OF, one device points to another by putting the
phandle
of that pointed-to device in some property (and
On Thursday 05 June 2008, Sean MacLennan wrote:
On Wed, 4 Jun 2008 22:05:55 -0500
Josh Boyer [EMAIL PROTECTED] wrote:
I'm not proposing we remove that. I'm just proposing that it can be
derived from something other than an index property. Fill it in
using a static integer that gets
On Thu, 5 Jun 2008 08:22:00 +0200, Stefan Roese wrote:
On Thursday 05 June 2008, Sean MacLennan wrote:
On Wed, 4 Jun 2008 22:05:55 -0500
Josh Boyer [EMAIL PROTECTED] wrote:
I'm not proposing we remove that. I'm just proposing that it can be
derived from something other than an index
On Thu, 5 Jun 2008 10:45:42 +0200
Stefan Roese [EMAIL PROTECTED] wrote:
On Thursday 05 June 2008, Jean Delvare wrote:
Maybe it is time to remove the index, or maybe we should go back to
using both a static and the index. But at the time we decided to
enforce an index.
So what
Josh Boyer wrote:
From a device tree perspective, index and cell-index are both
incorrect. The IIC macros don't share register blocks with anything,
are enumerated as unique instances per macro in the device tree, and
should be able to be distinguished by regs and/or unit address.
I think
Josh Boyer wrote:
seems to be a more distinct definition of what this is. But I have no
idea how well that would go over, and it would probably need to be
changed in all the fsl boards as well.
Which would end up breaking backwards compatibility with older device trees.
Like I said earlier,
Stefan Roese wrote:
So what should we do now? Currently I2C doesn't work at all on 4xx since the
driver expects the index property and no dts sets this property. Personally
I would like to move to using cell-index here, since this seems to be more
common. But I could also life with
On Thu, Jun 5, 2008 at 9:13 AM, Timur Tabi [EMAIL PROTECTED] wrote:
Josh Boyer wrote:
From a device tree perspective, index and cell-index are both
incorrect. The IIC macros don't share register blocks with anything,
are enumerated as unique instances per macro in the device tree, and
Grant Likely wrote:
if you need explicit indexing then use an alias. My opinion however
is that explicit indexing is unnecessary and is just an artifact of
current i2c subsystem internals. There is already enough information
in the device tree to match i2c devices with i2c busses without
Hi Timur,
In situations where it doesn't matter which I2C bus is #1 and which one is #2,
then I think the code should just initialize idx based on the order the nodes
are found in the tree.
In situations where it does matter, then we should use cell-index.
that's what I did in i2c-cpm, as
I think we should just expand the definition of cell-index to include
standard
device enumeration for when it's needed. The original definition is
too
limited, IMHO.
nak
if you need explicit indexing then use an alias. My opinion however
is that explicit indexing is unnecessary and is just
Jochen Friedrich wrote:
Hi Timur,
In situations where it doesn't matter which I2C bus is #1 and which one is
#2,
then I think the code should just initialize idx based on the order the nodes
are found in the tree.
In situations where it does matter, then we should use cell-index.
Hi Grant,
if you need explicit indexing then use an alias. My opinion however
is that explicit indexing is unnecessary and is just an artifact of
current i2c subsystem internals. There is already enough information
in the device tree to match i2c devices with i2c busses without
resorting
if you need explicit indexing then use an alias. My opinion however
is that explicit indexing is unnecessary and is just an artifact of
current i2c subsystem internals. There is already enough information
in the device tree to match i2c devices with i2c busses without
resorting to indexes.
On Thu, Jun 5, 2008 at 9:52 AM, Jochen Friedrich [EMAIL PROTECTED] wrote:
Hi Grant,
if you need explicit indexing then use an alias. My opinion however
is that explicit indexing is unnecessary and is just an artifact of
current i2c subsystem internals. There is already enough information
On Thu, Jun 5, 2008 at 9:43 AM, Timur Tabi [EMAIL PROTECTED] wrote:
Grant Likely wrote:
if you need explicit indexing then use an alias. My opinion however
is that explicit indexing is unnecessary and is just an artifact of
current i2c subsystem internals. There is already enough
Segher Boessenkool wrote:
Sounds to me like both simply need to use adapter-nr.
How can a non-I2C driver get the adapter structure for another driver that is an
I2C driver?
For access to
Linux-internal data structures (and that is what this index is), you
shouldn't have to go via the
On Thu, Jun 5, 2008 at 9:50 AM, Timur Tabi [EMAIL PROTECTED] wrote:
Jochen Friedrich wrote:
Hi Timur,
In situations where it doesn't matter which I2C bus is #1 and which one is
#2,
then I think the code should just initialize idx based on the order the
nodes
are found in the tree.
In
Grant Likely wrote:
That is still Linux internal artifacts leaking out. Don't encode that
data into the device tree.
The I2C bus number is *not* an internal artifact. On Freescale parts, the one
I2C adapter is specifically designated I2C1, and the 2nd one is specifically
designated I2C2.
On Thu, 05 Jun 2008 11:13:23 -0500
Timur Tabi [EMAIL PROTECTED] wrote:
Grant Likely wrote:
That is still Linux internal artifacts leaking out. Don't encode that
data into the device tree.
The I2C bus number is *not* an internal artifact. On Freescale parts, the one
I2C adapter is
Hi Timur,
It's a little late for that. I'm okay with coming up with a new property to
provide system-level indexing, but it needs to be the same property name for
each type of device. I don't want linux,i2c-index and linux,dma-index and
linux,ssi-index, etc. I also don't understand why we
On Thu, Jun 05, 2008 at 11:09:16AM -0500, Timur Tabi wrote:
The fabric driver doesn't have access to any I2C structures when it starts
looking for the codec driver. The fabric driver is like an OF platform
driver,
in that it's OF-aware and machine-specific. By parsing the device tree (which
On Thu, Jun 5, 2008 at 10:22 AM, Jochen Friedrich [EMAIL PROTECTED] wrote:
Hi Timur,
It's a little late for that. I'm okay with coming up with a new property to
provide system-level indexing, but it needs to be the same property name for
each type of device. I don't want linux,i2c-index and
Josh Boyer wrote:
And it does. It does so by the unique regs properties and
unit-names. You can assign the index that the i2c subsystem needs
based on probe order, like I already said.
The probe order is not sufficient on platforms that specifically enumerate their
I2C (or whatever)
On Thu, Jun 5, 2008 at 10:18 AM, Timur Tabi [EMAIL PROTECTED] wrote:
Grant Likely wrote:
[EMAIL PROTECTED] {
#size-cells = 1;
#address-cells = 1;
ranges = 0 0xe 0x1000;
[EMAIL PROTECTED] {
cell-index = 0;
regs = 0
On Thu, Jun 5, 2008 at 10:25 AM, Timur Tabi [EMAIL PROTECTED] wrote:
Josh Boyer wrote:
And it does. It does so by the unique regs properties and
unit-names. You can assign the index that the i2c subsystem needs
based on probe order, like I already said.
The probe order is not sufficient
Grant Likely wrote:
2) for i2c purposes, explicit enumeration is not needed or desired.
All the necessary data is already present in the device tree in that
i2c device nodes are children of i2c bus nodes. The i2c bus numbers
should be dynamically assigned.
NACK. For ASoC driver, they
Scott Wood wrote:
No, it's not. It can determine that it's at address 0x4f on the i2c bus
at 0xe0003100. This is exactly how the ethernet phy lookup is done.
But how does the fabric driver know whether e0003100 is I2C1 or I2C2?
And how does the codec driver, which sees only I2C information,
Timur Tabi wrote:
Scott Wood wrote:
No, it's not. It can determine that it's at address 0x4f on the i2c bus
at 0xe0003100. This is exactly how the ethernet phy lookup is done.
But how does the fabric driver know whether e0003100 is I2C1 or I2C2?
It shouldn't have to care.
And how does
On Thu, 05 Jun 2008 11:25:23 -0500
Timur Tabi [EMAIL PROTECTED] wrote:
Josh Boyer wrote:
And it does. It does so by the unique regs properties and
unit-names. You can assign the index that the i2c subsystem needs
based on probe order, like I already said.
The probe order is not
Josh Boyer wrote:
I don't understand this statement. Are your I2C macros hot-pluggable?
Can you dynamically add/remove an I2C engine on your hardware somehow?
Are you mucking about with the DTB and randomly moving around the I2C
node blobs so they probe order differs from boot to boot?
If
On Thu, 05 Jun 2008 13:35:18 -0500
Timur Tabi [EMAIL PROTECTED] wrote:
Josh Boyer wrote:
I don't understand this statement. Are your I2C macros hot-pluggable?
Can you dynamically add/remove an I2C engine on your hardware somehow?
Are you mucking about with the DTB and randomly moving
On Thu, Jun 5, 2008 at 12:27 PM, Josh Boyer [EMAIL PROTECTED] wrote:
On Thu, 05 Jun 2008 11:25:23 -0500
Timur Tabi [EMAIL PROTECTED] wrote:
Josh Boyer wrote:
And it does. It does so by the unique regs properties and
unit-names. You can assign the index that the i2c subsystem needs
On Thu, 5 Jun 2008 12:46:39 -0600
Grant Likely [EMAIL PROTECTED] wrote:
(And I'm talking about I2C, not DMA. I don't care about DMA because
this conversation will go off into the weeds if we start talking about
cell-index and every possible device out there.)
I need to disagree here.
On Thu, Jun 5, 2008 at 12:56 PM, Josh Boyer [EMAIL PROTECTED] wrote:
On Thu, 5 Jun 2008 12:46:39 -0600
Grant Likely [EMAIL PROTECTED] wrote:
In Timur's case, it is absolutely appropriate to use cell-index and/or
a phandle to make sure it gets the correct DMA registers (which is
what
On Thu, 5 Jun 2008 13:14:00 -0600
Grant Likely [EMAIL PROTECTED] wrote:
On Thu, Jun 5, 2008 at 12:56 PM, Josh Boyer [EMAIL PROTECTED] wrote:
On Thu, 5 Jun 2008 12:46:39 -0600
Grant Likely [EMAIL PROTECTED] wrote:
In Timur's case, it is absolutely appropriate to use cell-index and/or
a
Grant Likely wrote:
No; use an alias in the aliases node. That is what aliases is designed
for. Something like 'index' is a reinvention of the wheel.
Do aliases work in reverse? That is, if I have a pointer to a device node, can
I look up its alias directly? Or do I have to scan the
No; use an alias in the aliases node. That is what aliases is
designed
for. Something like 'index' is a reinvention of the wheel.
Do aliases work in reverse? That is, if I have a pointer to a device
node, can
I look up its alias directly? Or do I have to scan the aliases node
and do a
On Thu, 5 Jun 2008 08:22:00 +0200
Stefan Roese [EMAIL PROTECTED] wrote:
So what should we do now? Currently I2C doesn't work at all on 4xx
since the driver expects the index property and no dts sets this
property. Personally I would like to move to using cell-index here,
since this seems to
On Thu, Jun 05, 2008 at 10:45:42AM +0200, Stefan Roese wrote:
On Thursday 05 June 2008, Jean Delvare wrote:
Maybe it is time to remove the index, or maybe we should go back to
using both a static and the index. But at the time we decided to
enforce an index.
So what should we do
On Thu, 5 Jun 2008 13:14:00 -0600
Grant Likely [EMAIL PROTECTED] wrote:
No; use an alias in the aliases node. That is what aliases is
designed for. Something like 'index' is a reinvention of the wheel.
If we really want to get rid of the index, I like the alias method. I
mainly write
On Thu, Jun 05, 2008 at 11:40:37AM -0500, Timur Tabi wrote:
Grant Likely wrote:
2) for i2c purposes, explicit enumeration is not needed or desired.
All the necessary data is already present in the device tree in that
i2c device nodes are children of i2c bus nodes. The i2c bus numbers
On Thu, Jun 05, 2008 at 02:16:41PM -0500, Timur Tabi wrote:
Grant Likely wrote:
No; use an alias in the aliases node. That is what aliases is designed
for. Something like 'index' is a reinvention of the wheel.
Do aliases work in reverse? That is, if I have a pointer to a
device node,
On Thu, 5 Jun 2008 17:37:16 -0400
Sean MacLennan [EMAIL PROTECTED] wrote:
On Thu, 5 Jun 2008 08:22:00 +0200
Stefan Roese [EMAIL PROTECTED] wrote:
So what should we do now? Currently I2C doesn't work at all on 4xx
since the driver expects the index property and no dts sets this
property.
On Thu, Jun 05, 2008 at 06:52:25AM -0500, Josh Boyer wrote:
On Thu, 5 Jun 2008 10:45:42 +0200
Stefan Roese [EMAIL PROTECTED] wrote:
On Thursday 05 June 2008, Jean Delvare wrote:
Maybe it is time to remove the index, or maybe we should go back to
using both a static and the index.
On Wed, Jun 04, 2008 at 09:19:42PM -0500, Josh Boyer wrote:
On Wed, 4 Jun 2008 10:43:51 -0500
Scott Wood [EMAIL PROTECTED] wrote:
On Wed, Jun 04, 2008 at 10:24:15AM -0500, Timur Tabi wrote:
Stefan Roese wrote:
I'm wondering what is currently recommended in the I2C device tree
From a device tree perspective, index and cell-index are both
incorrect. The IIC macros don't share register blocks with anything,
are enumerated as unique instances per macro in the device tree, and
should be able to be distinguished by regs and/or unit address.
Does anyone disagree with
On Fri, Jun 06, 2008 at 04:40:20AM +0200, Segher Boessenkool wrote:
From a device tree perspective, index and cell-index are both
incorrect. The IIC macros don't share register blocks with anything,
are enumerated as unique instances per macro in the device tree, and
should be able to be
On Wed, Jun 4, 2008 at 8:41 PM, David Gibson [EMAIL PROTECTED] wrote:
On Wed, Jun 04, 2008 at 09:19:42PM -0500, Josh Boyer wrote:
On Wed, 4 Jun 2008 10:43:51 -0500
Scott Wood [EMAIL PROTECTED] wrote:
On Wed, Jun 04, 2008 at 10:24:15AM -0500, Timur Tabi wrote:
Stefan Roese wrote:
I'm
On Wed, 2008-06-04 at 21:19 -0500, Josh Boyer wrote:
So if possible, I'd like to eliminate the *index stuff all together
from the 4xx driver. The private data structure contains an idx
parameter, but this can be populated based on probe order or something.
From a device tree perspective,
On Thu, 2008-06-05 at 09:48 +0200, Jean Delvare wrote:
As far as I am concerned, it's really up to the maintainers and users
of this platform. All I am asking for is that you do not call
i2c_add_numbered_adapter() on an adapter with an automatically
generated number. This function must only be
On Thu, 2008-06-05 at 10:13 -0500, Timur Tabi wrote:
Josh Boyer wrote:
From a device tree perspective, index and cell-index are both
incorrect. The IIC macros don't share register blocks with anything,
are enumerated as unique instances per macro in the device tree, and
should be able
On Thu, 2008-06-05 at 10:43 -0500, Timur Tabi wrote:
Grant Likely wrote:
if you need explicit indexing then use an alias. My opinion however
is that explicit indexing is unnecessary and is just an artifact of
current i2c subsystem internals. There is already enough information
in the
On Thu, 2008-06-05 at 10:45 +0200, Stefan Roese wrote:
Full ack from me. So I suggest to use cell-index if available and
otherwise
use an incremented number, same as the FSL i2c driver does now:
http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057254.html
If nobody objects I'll send a
On Thu, 5 Jun 2008 22:07:31 -0600
Grant Likely [EMAIL PROTECTED] wrote:
The fallback is to just let the i2c layer auto-assign an ID. The only
reason I can think of to want to assign a specific id to an i2c bus is
so that a userspace application can reference a specific bus. The
drivers
I'm wondering what is currently recommended in the I2C device tree nodes? The
current IBM I2C driver (i2c-ibm_iic.c) checks index and most FSL dts files
use cell-index. Some 4xx dts files implement cell-index some have no
index at all.
So what should be used here. Please advise and I'll
Stefan Roese wrote:
I'm wondering what is currently recommended in the I2C device tree nodes? The
current IBM I2C driver (i2c-ibm_iic.c) checks index and most FSL dts files
use cell-index. Some 4xx dts files implement cell-index some have no
index at all.
So what should be used here.
On Wed, Jun 04, 2008 at 10:24:15AM -0500, Timur Tabi wrote:
Stefan Roese wrote:
I'm wondering what is currently recommended in the I2C device tree nodes?
The
current IBM I2C driver (i2c-ibm_iic.c) checks index and most FSL dts
files
use cell-index. Some 4xx dts files implement
On Wed, 4 Jun 2008 10:43:51 -0500
Scott Wood [EMAIL PROTECTED] wrote:
On Wed, Jun 04, 2008 at 10:24:15AM -0500, Timur Tabi wrote:
Stefan Roese wrote:
I'm wondering what is currently recommended in the I2C device tree nodes?
The
current IBM I2C driver (i2c-ibm_iic.c) checks index and
On Wed, 4 Jun 2008 21:19:42 -0500
Josh Boyer [EMAIL PROTECTED] wrote:
From a device tree perspective, index and cell-index are both
incorrect. The IIC macros don't share register blocks with anything,
are enumerated as unique instances per macro in the device tree, and
should be able to be
On Wed, 4 Jun 2008 22:54:32 -0400
Sean MacLennan [EMAIL PROTECTED] wrote:
On Wed, 4 Jun 2008 21:19:42 -0500
Josh Boyer [EMAIL PROTECTED] wrote:
From a device tree perspective, index and cell-index are both
incorrect. The IIC macros don't share register blocks with anything,
are
On Wed, 4 Jun 2008 22:05:55 -0500
Josh Boyer [EMAIL PROTECTED] wrote:
I'm not proposing we remove that. I'm just proposing that it can be
derived from something other than an index property. Fill it in
using a static integer that gets incremented for each new device
found. It's not like we
70 matches
Mail list logo
