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
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 bu
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 enumerat
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()"?
Wo
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 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.
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
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_adapte
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
> drive
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
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
>
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
On Wed, 2008-06-04 at 10:43 -0500, Scott Wood wrote:
> > I just posted a patch for the FSL I2C driver to check for cell-index. I'm
> > under
> > the impression that cell-index is the standard for enumerating devices in
> > the
> > device tree.
>
> No, it's the standard for correlating devices w
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
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 perspectiv
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
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 abl
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 tha
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
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
On Thu, 05 Jun 2008 10:50:20 -0500
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
>
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 th
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
> devi
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 numb
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 dr
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
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 s
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
com
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 alias
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 cel
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
>>
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 disagr
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 sub
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
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?
>
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 orde
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 t
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
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 ca
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
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>;
>>
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) dev
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-
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 (wh
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
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 adap
Grant Likely wrote:
> [EMAIL PROTECTED] {
> #size-cells = <1>;
> #address-cells = <1>;
> ranges = <0 0xe 0x1000>;
> [EMAIL PROTECTED] {
> cell-index = <0>;
> regs = <0 0x100>;
> }
> [EMAIL PROTECTED] {
>
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. T
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 foun
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: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 i
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 infor
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.
Not
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
> resorti
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-i
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
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,
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
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, a
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 re
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
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 th
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.
>
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 now? Currently I2C doesn't work at all on 4xx since
> >
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
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 th
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
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,
>
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
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) che
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 i
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 use
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 p
74 matches
Mail list logo