[PATCH 0/3]: Sparc OF I2C support.

[PATCH 0/3]: Sparc OF I2C support.

[David Miller]

I'm working on some drivers for I2C bus support on some of my sparc64
workstations (for lm-sensor and eeprom type devices sitting behind
them) so I went back to trying to get of_i2c.c usable on sparc.

Mostly straightforward stuff _except_ for the I2C address encoding.

What I2C IEEE1275 device binding was used to write that code in
of_i2c.c?  Is it some PowerPC specific thing?  Was it "invented"
by the embedded folks (I hope not)?

On sparc, the encoding is either 1 cell or 2 cell.

If it's one cell, it's just the device address.

If it's two cells, it's a bus number (for I2C controllers that
can manage multiple I2C bus segments, think PCI domains) in the
first cell and the device address in the second cell.

And, furthermore, the device address is shifted up 1 bit higher
than the Linux I2C layer expects.  It includes the low direction
bit, bit 0, so we have to shift it down by 1 bit before we give
it to the Linux I2C layer.

Does PowerPC really encode these things differently?  And if so what
IEEE1275 I2C device binding specification covers that?

If PowerPC really does encode the device address in the same format as
the Linux I2C layer expects, that's OK and I used some property tests
and ifdefs to make it all work out.  What I did in these patches is:

1) Check the #address-cells property.  If not present, assume the value
   is "1".  Only accept values of "1" and "2".

2) When CONFIG_SPARC, shift the device address down by one bit before
   giving it to the Linux I2C layer.

I haven't added support to the I2C layer for the bus number yet, that
will come later.

The first patch in this series add the powerpc-compat IRQ probing
interfaces, mostly straightforward stuff as we precompute these
IRQs in of_device objects so we just search for the of_device corresponding
to the device node and return the interrupt, if any.  Dispost is a NOP.

The second patch deals with the addressing issues described above and
lets it be compiled on non-ppc systems.

The third patch adds device modaliases for a couple of I2C chip devices
I've seen on my SunBlade2500 workstation.  More will come later as I
flesh out my I2C sparc64 drivers which are not being posted here yet.
I have a fully functional Sun pcf8584 I2C bus driver.

Signed-off-by: David S. Miller <davem@davemloft.net>

Re: [PATCH 0/3]: Sparc OF I2C support.

[Scott Wood]

On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
> Mostly straightforward stuff _except_ for the I2C address encoding.
> 
> What I2C IEEE1275 device binding was used to write that code in
> of_i2c.c?  Is it some PowerPC specific thing?  Was it "invented"
> by the embedded folks (I hope not)?

Yes, it was "invented".  There was no documented i2c OF binding that I
could find, and AFAIR nobody came forward with examples of existing
practice at the time.

> And, furthermore, the device address is shifted up 1 bit higher
> than the Linux I2C layer expects.  It includes the low direction
> bit, bit 0, so we have to shift it down by 1 bit before we give
> it to the Linux I2C layer.

Yuck.

> 2) When CONFIG_SPARC, shift the device address down by one bit before
>    giving it to the Linux I2C layer.

Maybe we should distinguish by the type of I2C bus node instead.

-Scott

Re: [PATCH 0/3]: Sparc OF I2C support.

[David Miller]

From: Scott Wood <scottwood@freescale.com>
Date: Thu, 21 Aug 2008 11:32:56 -0500

> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
> > 2) When CONFIG_SPARC, shift the device address down by one bit before
> >    giving it to the Linux I2C layer.
> 
> Maybe we should distinguish by the type of I2C bus node instead.

How so?  If a Sparc and a PowerPC system use similar I2C
controllers, we risk double matches.

If you guys created this format in your compressed openfirmware
trees, is it possible for you to "fix" it to match what Sparc
systems following the proper bindings do?

This way we won't need any of these ifdefs at all.

Don't PowerMACs and such have I2C controllers and devices?
How do they encode these I2C client device reg properties?

Re: [PATCH 0/3]: Sparc OF I2C support.

[Scott Wood]

David Miller wrote:
>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
>>> 2) When CONFIG_SPARC, shift the device address down by one bit before
>>>    giving it to the Linux I2C layer.
>> Maybe we should distinguish by the type of I2C bus node instead.
> 
> How so?  If a Sparc and a PowerPC system use similar I2C
> controllers, we risk double matches.

It's not really an instruction-set architecture issue, it's a binding 
issue.  What if a non-OF embedded SPARC comes along that copies i2c from 
a PowerPC DTS file, or we come across a real-OF PowerPC that does it the 
SPARC way?

If we do come across two systems that claim their i2c bus nodes are 
compatible but use different bindings, *then* we'll find some 
out-of-band information to disambiguate.

> If you guys created this format in your compressed openfirmware
> trees, is it possible for you to "fix" it to match what Sparc
> systems following the proper bindings do?

Possibly, though it'll cause some pain when old trees are used with a 
kernel that expects the new binding.

You mentioned having an actual binding document for I2C on Open 
Firmware; is it available online anywhere?

> Don't PowerMACs and such have I2C controllers and devices?
> How do they encode these I2C client device reg properties?

As far as I can tell from poking around 
http://penguinppc.org/historical/dev-trees-html/, they don't include reg 
at all for i2c clients.

-Scott

Re: [PATCH 0/3]: Sparc OF I2C support.

[David Miller]

From: Scott Wood <scottwood@freescale.com>
Date: Thu, 21 Aug 2008 16:35:02 -0500

> David Miller wrote:
> > If you guys created this format in your compressed openfirmware
> > trees, is it possible for you to "fix" it to match what Sparc
> > systems following the proper bindings do?
> 
> Possibly, though it'll cause some pain when old trees are used with a 
> kernel that expects the new binding.
> 
> You mentioned having an actual binding document for I2C on Open 
> Firmware; is it available online anywhere?

It's a Sun internal document I got from a Sun employee, I'll ask
if there is a way I can at least share it with you privately so
you can use it as a reference.

> > Don't PowerMACs and such have I2C controllers and devices?
> > How do they encode these I2C client device reg properties?
> 
> As far as I can tell from poking around 
> http://penguinppc.org/historical/dev-trees-html/, they don't include reg 
> at all for i2c clients.

That actually simplifies things for us, thanks for checking.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Jon Smirl]

On 8/21/08, David Miller <davem@davemloft.net> wrote:
>
>  I'm working on some drivers for I2C bus support on some of my sparc64
>  workstations (for lm-sensor and eeprom type devices sitting behind
>  them) so I went back to trying to get of_i2c.c usable on sparc.
>
>  Mostly straightforward stuff _except_ for the I2C address encoding.
>
>  What I2C IEEE1275 device binding was used to write that code in
>  of_i2c.c?  Is it some PowerPC specific thing?  Was it "invented"
>  by the embedded folks (I hope not)?
>
>  On sparc, the encoding is either 1 cell or 2 cell.
>
>  If it's one cell, it's just the device address.
>
>  If it's two cells, it's a bus number (for I2C controllers that
>  can manage multiple I2C bus segments, think PCI domains) in the
>  first cell and the device address in the second cell.
>
>  And, furthermore, the device address is shifted up 1 bit higher
>  than the Linux I2C layer expects.  It includes the low direction
>  bit, bit 0, so we have to shift it down by 1 bit before we give
>  it to the Linux I2C layer.
>
>  Does PowerPC really encode these things differently?  And if so what
>  IEEE1275 I2C device binding specification covers that?
>
>  If PowerPC really does encode the device address in the same format as
>  the Linux I2C layer expects, that's OK and I used some property tests
>  and ifdefs to make it all work out.  What I did in these patches is:
>
>  1) Check the #address-cells property.  If not present, assume the value
>    is "1".  Only accept values of "1" and "2".
>
>  2) When CONFIG_SPARC, shift the device address down by one bit before
>    giving it to the Linux I2C layer.

How do you deal with a 10-bit address i2c device? Is it multiplied by two too?

Here's the i2c spec,
http://www.semiconductors.philips.com/acrobat_download/literature/9398/39340011.pdf
 It says the basic addresses are 7 bit.

>  I haven't added support to the I2C layer for the bus number yet, that
>  will come later.
>
>  The first patch in this series add the powerpc-compat IRQ probing
>  interfaces, mostly straightforward stuff as we precompute these
>  IRQs in of_device objects so we just search for the of_device corresponding
>  to the device node and return the interrupt, if any.  Dispost is a NOP.
>
>  The second patch deals with the addressing issues described above and
>  lets it be compiled on non-ppc systems.
>
>  The third patch adds device modaliases for a couple of I2C chip devices
>  I've seen on my SunBlade2500 workstation.  More will come later as I
>  flesh out my I2C sparc64 drivers which are not being posted here yet.
>  I have a fully functional Sun pcf8584 I2C bus driver.
>
>  Signed-off-by: David S. Miller <davem@davemloft.net>
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 0/3]: Sparc OF I2C support.

[David Miller]

From: "Jon Smirl" <jonsmirl@gmail.com>
Date: Thu, 21 Aug 2008 17:53:02 -0400

> >  2) When CONFIG_SPARC, shift the device address down by one bit before
> >    giving it to the Linux I2C layer.
> 
> How do you deal with a 10-bit address i2c device? Is it multiplied by two too?

Yes.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Benjamin Herrenschmidt]

On Thu, 2008-08-21 at 11:32 -0500, Scott Wood wrote:
> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
> > Mostly straightforward stuff _except_ for the I2C address encoding.
> > 
> > What I2C IEEE1275 device binding was used to write that code in
> > of_i2c.c?  Is it some PowerPC specific thing?  Was it "invented"
> > by the embedded folks (I hope not)?
> 
> Yes, it was "invented".  There was no documented i2c OF binding that I
> could find, and AFAIR nobody came forward with examples of existing
> practice at the time.

Well, there were examples in the powermac code :-)

> > And, furthermore, the device address is shifted up 1 bit higher
> > than the Linux I2C layer expects.  It includes the low direction
> > bit, bit 0, so we have to shift it down by 1 bit before we give
> > it to the Linux I2C layer.
> 
> Yuck.

Apple does the same. IE. I take the address from "reg" and shift it
right by one bit before passing it to linux.

> > 2) When CONFIG_SPARC, shift the device address down by one bit before
> >    giving it to the Linux I2C layer.
> 
> Maybe we should distinguish by the type of I2C bus node instead.

Or fix the embedded stuff :-)

Ben.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Benjamin Herrenschmidt]

> It's not really an instruction-set architecture issue, it's a binding 
> issue.  What if a non-OF embedded SPARC comes along that copies i2c from 
> a PowerPC DTS file, or we come across a real-OF PowerPC that does it the 
> SPARC way?

Like PowerMac ? :-)

Apple additionally have different ways of representing multiple busses
on one controller though. On some machines, they just use bits 0xF00 of
the address as the bus number, which is a bit gross, and on some, they
have sub-nodes i2c-bus@NN under the controller.

But at least the address encoding (shifted by 1 bit) is common with sparc
and I think is a fairly common way of representing i2c addresses.

> As far as I can tell from poking around 
> http://penguinppc.org/historical/dev-trees-html/, they don't include reg 
> at all for i2c clients.

Most of the device-trees on penguinppc.org are obsolete. i2c is mostly
used in the device-tree for newer stuff such as G5s.

Ben.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Benjamin Herrenschmidt]

On Thu, 2008-08-21 at 14:45 -0700, David Miller wrote:
> > As far as I can tell from poking around 
> > http://penguinppc.org/historical/dev-trees-html/, they don't include
> reg 
> > at all for i2c clients.
> 
> That actually simplifies things for us, thanks for checking.

Unfortunately, while that may be true for old stuff, most recent
powermacs do. Encoding is mostly like sparc though (see other mails).

Ben.

Re: [PATCH 0/3]: Sparc OF I2C support.

[David Miller]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 22 Aug 2008 08:05:50 +1000

> On Thu, 2008-08-21 at 14:45 -0700, David Miller wrote:
> > > As far as I can tell from poking around 
> > > http://penguinppc.org/historical/dev-trees-html/, they don't include
> > reg 
> > > at all for i2c clients.
> > 
> > That actually simplifies things for us, thanks for checking.
> 
> Unfortunately, while that may be true for old stuff, most recent
> powermacs do. Encoding is mostly like sparc though (see other mails).

Thanks for the clarification.  The bus encoding seems different
but we can solve that too.

I've started a dialogue between Scott and the openfirmware Sun
folks I know so that hopefully Scott can get a copy of the I2C
bindings Sun uses and we can sort all of this out.

Re: [PATCH 0/3]: Sparc OF I2C support.

[David Miller]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 22 Aug 2008 08:05:02 +1000

> Apple additionally have different ways of representing multiple busses
> on one controller though. On some machines, they just use bits 0xF00 of
> the address as the bus number, which is a bit gross, and on some, they
> have sub-nodes i2c-bus@NN under the controller.

Ok, Sun uses a 2-cell scheme.  We can handle both cases of reg
encoding quite easily:

1) If there is a single cell, tread bits 8 and above as bus number.
   They will be zero on Sparc.

2) If there are two cells, first cell is bus number.

For the hierarchical case, I'm not so sure how to handle it.

Also, last night, I posted patches to the I2C list to add bus
addressing support to the I2C code and the PCF algo implementation.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Benjamin Herrenschmidt]

> Thanks for the clarification.  The bus encoding seems different
> but we can solve that too.
> 
> I've started a dialogue between Scott and the openfirmware Sun
> folks I know so that hopefully Scott can get a copy of the I2C
> bindings Sun uses and we can sort all of this out.

Sure. Currently the powermac stuff isn't too relevant because I
use my own infrastructure (not a huge thing, but I have a special
layer of low level polled i2c drivers that I can use early during
boot or during low level suspend/resume with IRQs off etc... that
hooks up on to the main linux i2c stack etc...)

So I'll let you guys come up with something, and we can later see if
there's any interest in moving some of the pmac stuff over to it.

Ben.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Benjamin Herrenschmidt]

On Thu, 2008-08-21 at 15:28 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Fri, 22 Aug 2008 08:05:02 +1000
> 
> > Apple additionally have different ways of representing multiple busses
> > on one controller though. On some machines, they just use bits 0xF00 of
> > the address as the bus number, which is a bit gross, and on some, they
> > have sub-nodes i2c-bus@NN under the controller.
> 
> Ok, Sun uses a 2-cell scheme.  We can handle both cases of reg
> encoding quite easily:
> 
> 1) If there is a single cell, tread bits 8 and above as bus number.
>    They will be zero on Sparc.

Depends if you want also to handle 10-bit addresses... though the
support for that could be enabled by an explicit property
10-bit-addresses in the controller node...  But as I said before, I
wouldn't worry too much about powermac for now, it's not using this code
and may never do.

> 2) If there are two cells, first cell is bus number.
> 
> For the hierarchical case, I'm not so sure how to handle it.
> 
> Also, last night, I posted patches to the I2C list to add bus
> addressing support to the I2C code and the PCF algo implementation.

Ben.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Grant Likely]

On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <scottwood@freescale.com> wrote:
> David Miller wrote:
>>>
>>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
>> If you guys created this format in your compressed openfirmware
>> trees, is it possible for you to "fix" it to match what Sparc
>> systems following the proper bindings do?
>
> Possibly, though it'll cause some pain when old trees are used with a kernel
> that expects the new binding.

Ugh, more like loads of pain.  There are deployed platforms using the
embedded 'invented' bindings.  I don't think it is an option to break
compatibility with older trees.  If there is some backwards
compatibility code then I'm all for migrating to the same binding as
Sparc and PowerMac

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH 0/3]: Sparc OF I2C support.

[David Miller]

From: "Grant Likely" <grant.likely@secretlab.ca>
Date: Thu, 21 Aug 2008 17:14:57 -0600

> On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <scottwood@freescale.com> wrote:
> > David Miller wrote:
> >>>
> >>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
> >> If you guys created this format in your compressed openfirmware
> >> trees, is it possible for you to "fix" it to match what Sparc
> >> systems following the proper bindings do?
> >
> > Possibly, though it'll cause some pain when old trees are used with a kernel
> > that expects the new binding.
> 
> Ugh, more like loads of pain.  There are deployed platforms using the
> embedded 'invented' bindings.  I don't think it is an option to break
> compatibility with older trees.  If there is some backwards
> compatibility code then I'm all for migrating to the same binding as
> Sparc and PowerMac

You could even put the detection and reg property fixups in the device
tree expander.  This way generic code in drivers/of/of_i2c.c doesn't
need to know about this huge mistake.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Jon Smirl]

On 8/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <scottwood@freescale.com> wrote:
>  > David Miller wrote:
>  >>>
>  >>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
>
> >> If you guys created this format in your compressed openfirmware
>  >> trees, is it possible for you to "fix" it to match what Sparc
>  >> systems following the proper bindings do?
>  >
>  > Possibly, though it'll cause some pain when old trees are used with a kernel
>  > that expects the new binding.
>
>
> Ugh, more like loads of pain.  There are deployed platforms using the
>  embedded 'invented' bindings.  I don't think it is an option to break
>  compatibility with older trees.  If there is some backwards
>  compatibility code then I'm all for migrating to the same binding as
>  Sparc and PowerMac

Has anything really been deployed? These bindings are only a few months old.


-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 0/3]: Sparc OF I2C support.

[Josh Boyer]

On Thu, 2008-08-21 at 16:32 -0700, David Miller wrote:
> From: "Grant Likely" <grant.likely@secretlab.ca>
> Date: Thu, 21 Aug 2008 17:14:57 -0600
> 
> > On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <scottwood@freescale.com> wrote:
> > > David Miller wrote:
> > >>>
> > >>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
> > >> If you guys created this format in your compressed openfirmware
> > >> trees, is it possible for you to "fix" it to match what Sparc
> > >> systems following the proper bindings do?
> > >
> > > Possibly, though it'll cause some pain when old trees are used with a kernel
> > > that expects the new binding.
> > 
> > Ugh, more like loads of pain.  There are deployed platforms using the
> > embedded 'invented' bindings.  I don't think it is an option to break
> > compatibility with older trees.  If there is some backwards
> > compatibility code then I'm all for migrating to the same binding as
> > Sparc and PowerMac
> 
> You could even put the detection and reg property fixups in the device
> tree expander.  This way generic code in drivers/of/of_i2c.c doesn't
> need to know about this huge mistake.

Huge?  I'd say mistake, but not necessarily huge.  I mean nobody other
than you (at least in the context of this conversation) had access to
the IEEE1275 proposed binding so it wasn't like there was tons to go on.

Have patience with the embedded people that are both new to OpenFirmware
and trying to make stuff work at the same time.  I think the
devicetree-discuss list will help here as new bindings are proposed.  I
hope you're subscribed.

josh

Re: [PATCH 0/3]: Sparc OF I2C support.

[Grant Likely]

On Thu, Aug 21, 2008 at 5:45 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 8/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>> Ugh, more like loads of pain.  There are deployed platforms using the
>>  embedded 'invented' bindings.  I don't think it is an option to break
>>  compatibility with older trees.  If there is some backwards
>>  compatibility code then I'm all for migrating to the same binding as
>>  Sparc and PowerMac
>
> Has anything really been deployed? These bindings are only a few months old.

It was over a year ago when support for i2c devices in the device tree
was merged.

See commit id d13ae8620dfdedfa7e9ab6d1eec294adc0516065.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Jon Smirl]

On 8/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Aug 21, 2008 at 5:45 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>  > On 8/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>
> >> Ugh, more like loads of pain.  There are deployed platforms using the
>  >>  embedded 'invented' bindings.  I don't think it is an option to break
>  >>  compatibility with older trees.  If there is some backwards
>  >>  compatibility code then I'm all for migrating to the same binding as
>  >>  Sparc and PowerMac
>  >
>  > Has anything really been deployed? These bindings are only a few months old.
>
>
> It was over a year ago when support for i2c devices in the device tree
>  was merged.

I see, the old support needed the drivers to be built-in. The newer
code dynamically loads the correct i2c driver and set its parameters.

Did the old code use anything besides compatible? It would have been
using the older i2c system that probed for the address.

>
>  See commit id d13ae8620dfdedfa7e9ab6d1eec294adc0516065.
>
>
>  g.
>
>  --
>  Grant Likely, B.Sc., P.Eng.
>  Secret Lab Technologies Ltd.
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 0/3]: Sparc OF I2C support.

[David Miller]

From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date: Thu, 21 Aug 2008 21:15:37 -0400

> Huge?  I'd say mistake, but not necessarily huge.  I mean nobody other
> than you (at least in the context of this conversation) had access to
> the IEEE1275 proposed binding so it wasn't like there was tons to go on.

I guess all the PowerMAC G5 systems out there and their device trees
were locked up in a highly secure vault somewhere :-)

> Have patience with the embedded people that are both new to
> OpenFirmware and trying to make stuff work at the same time.  I
> think the devicetree-discuss list will help here as new bindings are
> proposed.  I hope you're subscribed.

Why not ask the people who actually work on the standards?  That's who
I go to when I want to know something about openfirmware issues.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Grant Likely]

On Thu, Aug 21, 2008 at 9:53 PM, David Miller <davem@davemloft.net> wrote:
>> Have patience with the embedded people that are both new to
>> OpenFirmware and trying to make stuff work at the same time.  I
>> think the devicetree-discuss list will help here as new bindings are
>> proposed.  I hope you're subscribed.
>
> Why not ask the people who actually work on the standards?  That's who
> I go to when I want to know something about openfirmware issues.

You mean email them privately?  Outside of a public forum?  That
doesn't help much when it comes to discussing/debating issues and
learning from other peoples conversations.

As far as I can tell there aren't any other active mailing lists
purposed for discussing device tree bindings.
http://openfirmware.org, http://firmworks.com, and
http://playground.sun.com/1275/ don't list any mailing lists and the
last meeting shown on playground.sun.com was scheduled for 1999.
openbios.org has a mailing list which seems to be idle except for SVN
commit messages and doesn't seem to be used for discussing bindings.
We need a place to discuss these issues that I don't see anywhere
else.  Please correct me if I'm missing a list.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH 0/3]: Sparc OF I2C support.

[David Miller]

From: "Grant Likely" <grant.likely@secretlab.ca>
Date: Thu, 21 Aug 2008 22:18:56 -0600

> On Thu, Aug 21, 2008 at 9:53 PM, David Miller <davem@davemloft.net> wrote:
> >> Have patience with the embedded people that are both new to
> >> OpenFirmware and trying to make stuff work at the same time.  I
> >> think the devicetree-discuss list will help here as new bindings are
> >> proposed.  I hope you're subscribed.
> >
> > Why not ask the people who actually work on the standards?  That's who
> > I go to when I want to know something about openfirmware issues.
> 
> You mean email them privately?  Outside of a public forum?  That
> doesn't help much when it comes to discussing/debating issues and
> learning from other peoples conversations.

You can CC: them on the discussion to get their input, whatever
is appropriate.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Mitch Bradley]

Hi, I wrote most of 1275.

Mitch Bradley  (wmb@firmworks.com)

David Miller wrote:
> From: "Grant Likely" <grant.likely@secretlab.ca>
> Date: Thu, 21 Aug 2008 22:18:56 -0600
>
>   
>> On Thu, Aug 21, 2008 at 9:53 PM, David Miller <davem@davemloft.net> wrote:
>>     
>>>> Have patience with the embedded people that are both new to
>>>> OpenFirmware and trying to make stuff work at the same time.  I
>>>> think the devicetree-discuss list will help here as new bindings are
>>>> proposed.  I hope you're subscribed.
>>>>         
>>> Why not ask the people who actually work on the standards?  That's who
>>> I go to when I want to know something about openfirmware issues.
>>>       
>> You mean email them privately?  Outside of a public forum?  That
>> doesn't help much when it comes to discussing/debating issues and
>> learning from other peoples conversations.
>>     
>
> You can CC: them on the discussion to get their input, whatever
> is appropriate.
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@ozlabs.org
> https://ozlabs.org/mailman/listinfo/devicetree-discuss
>
>   

Re: [PATCH 0/3]: Sparc OF I2C support.

[Grant Likely]

On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley <wmb@firmworks.com> wrote:
> Hi, I wrote most of 1275.
>
> Mitch Bradley  (wmb@firmworks.com)

Hi Mitch,

What is your suggestion.  Where should we be discussing new device
tree bindings?  Whether it be real Open Firmware, or flattened device
tree, or something in between

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Grant Likely]

On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley <wmb@firmworks.com> wrote:
>> Hi, I wrote most of 1275.
>>
>> Mitch Bradley  (wmb@firmworks.com)
>
> Hi Mitch,
>
> What is your suggestion.  Where should we be discussing new device
> tree bindings?  Whether it be real Open Firmware, or flattened device
> tree, or something in between

...and along those lines: is there a place for documenting new
bindings?  Lacking anything better, those of us in PowerPC-Linux-land
have been adding documentation to Documentation/powerpc/dts-bindings/*
in the Linux kernel tree.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH 0/3]: Sparc OF I2C support.

[David Miller]

From: "Grant Likely" <grant.likely@secretlab.ca>
Date: Thu, 21 Aug 2008 22:34:31 -0600

> On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
> > On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley <wmb@firmworks.com> wrote:
> >> Hi, I wrote most of 1275.
> >>
> >> Mitch Bradley  (wmb@firmworks.com)
> >
> > Hi Mitch,
> >
> > What is your suggestion.  Where should we be discussing new device
> > tree bindings?  Whether it be real Open Firmware, or flattened device
> > tree, or something in between
> 
> ...and along those lines: is there a place for documenting new
> bindings?  Lacking anything better, those of us in PowerPC-Linux-land
> have been adding documentation to Documentation/powerpc/dts-bindings/*
> in the Linux kernel tree.

In a discussion I am having with Greg Onufer, David K. and Tayfun
at Sun, Greg said the some of the newer binding documents are
being published on the opensolaris site, and he is trying to
get some of the older cases (like this I2C one) published there
too.

Re: [PATCH 0/3]: Sparc OF I2C support.

[Mitch Bradley]

David Miller wrote:
> From: "Grant Likely" <grant.likely@secretlab.ca>
> Date: Thu, 21 Aug 2008 22:34:31 -0600
>
>   
>> On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely
>> <grant.likely@secretlab.ca> wrote:
>>     
>>> On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley <wmb@firmworks.com> wrote:
>>>       
>>>> Hi, I wrote most of 1275.
>>>>
>>>> Mitch Bradley  (wmb@firmworks.com)
>>>>         
>>> Hi Mitch,
>>>
>>> What is your suggestion.  Where should we be discussing new device
>>> tree bindings?  Whether it be real Open Firmware, or flattened device
>>> tree, or something in between
>>>       
>> ...and along those lines: is there a place for documenting new
>> bindings?  Lacking anything better, those of us in PowerPC-Linux-land
>> have been adding documentation to Documentation/powerpc/dts-bindings/*
>> in the Linux kernel tree.
>>     
>
> In a discussion I am having with Greg Onufer, David K. and Tayfun
> at Sun, Greg said the some of the newer binding documents are
> being published on the opensolaris site, and he is trying to
> get some of the older cases (like this I2C one) published there
> too.
>
>   

This collection of mailing lists is as good a place as any to discuss 
new bindings.  I don't know how many Sun people are on the lists, but we 
might be able to persuade various Sun people to lurk on one or more of 
them;  I lurk on devicetree-discuss.

The opensolaris site seems as good as anywhere for publishing the 
bindings, especially if they can pull over the old ones from e.g. 
playground.sun.com .

Another possible site might be openbios.org .

Re: [PATCH 0/3]: Sparc OF I2C support.

[Josh Boyer]

On Thu, 21 Aug 2008 20:53:05 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> Date: Thu, 21 Aug 2008 21:15:37 -0400
> 
> > Huge?  I'd say mistake, but not necessarily huge.  I mean nobody other
> > than you (at least in the context of this conversation) had access to
> > the IEEE1275 proposed binding so it wasn't like there was tons to go on.
> 
> I guess all the PowerMAC G5 systems out there and their device trees
> were locked up in a highly secure vault somewhere :-)

Apple has done silly things in their device trees before.  I wouldn't
hold them up as an excellent example.

> > Have patience with the embedded people that are both new to
> > OpenFirmware and trying to make stuff work at the same time.  I
> > think the devicetree-discuss list will help here as new bindings are
> > proposed.  I hope you're subscribed.
> 
> Why not ask the people who actually work on the standards?  That's who
> I go to when I want to know something about openfirmware issues.

Honestly, I don't know.  And from what I can tell, there _aren't_
people who actively work on the standards anymore.  Mitch is active
elsewhere and could be a great resource but aside from him I have no
idea who to contact.

josh

Re: [PATCH 0/3]: Sparc OF I2C support.

[David Miller]

From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date: Fri, 22 Aug 2008 06:50:48 -0400

> On Thu, 21 Aug 2008 20:53:05 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> 
> > From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > Date: Thu, 21 Aug 2008 21:15:37 -0400
> > 
> > > Huge?  I'd say mistake, but not necessarily huge.  I mean nobody other
> > > than you (at least in the context of this conversation) had access to
> > > the IEEE1275 proposed binding so it wasn't like there was tons to go on.
> > 
> > I guess all the PowerMAC G5 systems out there and their device trees
> > were locked up in a highly secure vault somewhere :-)
> 
> Apple has done silly things in their device trees before.  I wouldn't
> hold them up as an excellent example.

Sure, I agree, and Sun has too.

But it's always a good idea to go look thoroughly at what existing
systems are doing before pulling the switch and inventing one's own
OF binding from scratch.

Right?

> I have no idea who to contact.

Simply ask :-)

I listen on here too and if I had seen such a query I would have
tossed some feelers around tothe people I know.  I know various OF
ninjas at Sun :)

Re: [PATCH 0/3]: Sparc OF I2C support.

[Scott Wood]

On Thu, Aug 21, 2008 at 10:39:40PM -0400, Jon Smirl wrote:
> I see, the old support needed the drivers to be built-in. The newer
> code dynamically loads the correct i2c driver and set its parameters.
> 
> Did the old code use anything besides compatible?

Yes.

> It would have been using the older i2c system that probed for the
> address.

No, it wouldn't have.  It used glue code to generate i2c_board_info
structs.

> >  See commit id d13ae8620dfdedfa7e9ab6d1eec294adc0516065.

As shown in the above commit id. :-)

-Scott

RE: [PATCH 0/3]: Sparc OF I2C support.

[Yoder Stuart]

=20

> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Mitch Bradley
> Sent: Friday, August 22, 2008 12:19 AM
> To: David Miller
> Cc: linuxppc-dev@ozlabs.org; sparclinux@vger.kernel.org;=20
> devicetree-discuss@ozlabs.org; Wood Scott
> Subject: Re: [PATCH 0/3]: Sparc OF I2C support.
>=20
>=20
>=20
> David Miller wrote:
> > From: "Grant Likely" <grant.likely@secretlab.ca>
> > Date: Thu, 21 Aug 2008 22:34:31 -0600
> >
> >  =20
> >> On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely
> >> <grant.likely@secretlab.ca> wrote:
> >>    =20
> >>> On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley=20
> <wmb@firmworks.com> wrote:
> >>>      =20
> >>>> Hi, I wrote most of 1275.
> >>>>
> >>>> Mitch Bradley  (wmb@firmworks.com)
> >>>>        =20
> >>> Hi Mitch,
> >>>
> >>> What is your suggestion.  Where should we be discussing new device
> >>> tree bindings?  Whether it be real Open Firmware, or=20
> flattened device
> >>> tree, or something in between
> >>>      =20
> >> ...and along those lines: is there a place for documenting new
> >> bindings?  Lacking anything better, those of us in=20
> PowerPC-Linux-land
> >> have been adding documentation to=20
> Documentation/powerpc/dts-bindings/*
> >> in the Linux kernel tree.
> >>    =20
> >
> > In a discussion I am having with Greg Onufer, David K. and Tayfun
> > at Sun, Greg said the some of the newer binding documents are
> > being published on the opensolaris site, and he is trying to
> > get some of the older cases (like this I2C one) published there
> > too.
> >
> >  =20
>=20
> This collection of mailing lists is as good a place as any to discuss=20
> new bindings.  I don't know how many Sun people are on the=20
> lists, but we=20
> might be able to persuade various Sun people to lurk on one=20
> or more of=20
> them;  I lurk on devicetree-discuss.
>=20
> The opensolaris site seems as good as anywhere for publishing the=20
> bindings, especially if they can pull over the old ones from e.g.=20
> playground.sun.com .
>=20
> Another possible site might be openbios.org .

I agree that the linuxppc-dev and devicetree-discuss mailing
lists are probably the best place to discuss bindings.  (I'm
not aware of other good options).

Once there is consensus as to what a binding should be, and publishing
is needed-- for general, common bindings some single place is needed.
Something that is ideally authoritative, with a committed organization
behind it.  One suggestion would be the power.org and follow on
versions of the ePAPR.  ePAPR 1.0 is out now and currently is a base
document-- defines the flat device tree concept, and basically extracts
the relevant parts of 1275 for how this is used in the embedded space.

There are a few bindings specified in the ePAPR, based on the old
Open Firmware working group stuff:
   -cpu
   -interrupt controllers
   -PCI
   -network devices
   -DCR devices
   -serial devices

ePAPR doc is at:
http://www.power.org/resources/downloads/

It's obvious that more bindings are needed, and the expecation from
those who worked on the ePAPR (most or all of which are on this
mailing list) was that as bindings are codified they could be
added to the ePAPR.

The best way to publish bindings will be on the web.  I've been
looking into getting power.org to host a wiki-based site
that could be used as a repository for bindings.  We could have
both an area for general bindings and company specific ones.
I've made some progress here and actually have a sandbox wiki
that I'm playing with.

Stuart Yoder
Freescale

Re: [PATCH 0/3]: Sparc OF I2C support.

[Josh Boyer]

On Fri, Aug 22, 2008 at 09:00:09AM -0700, Yoder Stuart wrote:
>There are a few bindings specified in the ePAPR, based on the old
>Open Firmware working group stuff:
>   -cpu
>   -interrupt controllers
>   -PCI
>   -network devices
>   -DCR devices

Er, I don't think that one is based on the old workgroup.  DCR is only
applicable to PowerPC 4xx devices, and those have never had open firmware.

>The best way to publish bindings will be on the web.  I've been
>looking into getting power.org to host a wiki-based site
>that could be used as a repository for bindings.  We could have
>both an area for general bindings and company specific ones.
>I've made some progress here and actually have a sandbox wiki
>that I'm playing with.

That sounds good, but I have one suggestion.  Use the wiki for
submission and discussion of new binding proposals, but once they
are agreed upon put them in a static webpage somewhere until they
are incorporated into the next ePAPR revision.  Wikis are awesome
for changing stuff, but you don't want people to go back and change
a binding that has already been approved (for whatever definition
of approved we come up with.)

Also, you might want to have some kind of Licensing or copyright
assignment for all wiki contributions.  Talk to your legal team or
the power.org legal team about that if you haven't already.

josh

Re: [PATCH 0/3]: Sparc OF I2C support.

[Grant Likely]

On Thu, Aug 21, 2008 at 8:39 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 8/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>> It was over a year ago when support for i2c devices in the device tree
>>  was merged.
>
> I see, the old support needed the drivers to be built-in. The newer
> code dynamically loads the correct i2c driver and set its parameters.
>
> Did the old code use anything besides compatible? It would have been
> using the older i2c system that probed for the address.

I think you're confusing binding with implementation.  The binding is
the layout of data in the device tree.  The implementation uses that
data.  Your right that the current implementation is new, but it
replaces older implementation that uses the same binding.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.