linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* I2C mux and device tree
@ 2008-10-25  9:02 Felix Radensky
  2008-10-27 20:33 ` Scott Wood
  0 siblings, 1 reply; 3+ messages in thread
From: Felix Radensky @ 2008-10-25  9:02 UTC (permalink / raw)
  To: linuxppc-embedded

Hi,

I run linux-2.6.26 on custom 460EX based board.
This platform has PCA9548 I2C mux on I2C bus 0.
I was wondering how can I describe the mux itself
and devices behind it (e.g RTC and temperature sensors)
in the device tree.

If this is impossible at the moment, what other means
exist to work with devices behind the mux ? I have
found the pca954x patch and related virtual i2c patch
and was able to integrate them intro my kernel. The
question is - how do I tell the kernel to search for RTC
at specific virtual bus and address ? Can I use platform
data for this purpose ?

Thanks a lot.

Felix.
 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: I2C mux and device tree
  2008-10-25  9:02 I2C mux and device tree Felix Radensky
@ 2008-10-27 20:33 ` Scott Wood
  2008-10-27 22:33   ` Felix Radensky
  0 siblings, 1 reply; 3+ messages in thread
From: Scott Wood @ 2008-10-27 20:33 UTC (permalink / raw)
  To: Felix Radensky; +Cc: linuxppc-dev@ozlabs.org list, linuxppc-embedded@ozlabs.org

[added linuxppc-dev for a wider audience]

Felix Radensky wrote:
> I run linux-2.6.26 on custom 460EX based board.
> This platform has PCA9548 I2C mux on I2C bus 0.
> I was wondering how can I describe the mux itself
> and devices behind it (e.g RTC and temperature sensors)
> in the device tree.

Describe it as a node that is both an i2c client and an i2c controller.

The Sun i2c binding says that i2c devices should have two reg cells, the 
first being the bus number within the controller, and the second being a 
shifted-left-by-one i2c bus address (as opposed to the one-cell 
non-shifted address we currently use, because the Sun binding wasn't 
known to us at the time).

We could extend of_register_i2c_devices to understand two-cell 
addresses, and call it once for each sub-bus with the bus number as a 
parameter.

> If this is impossible at the moment, what other means
> exist to work with devices behind the mux ? I have
> found the pca954x patch and related virtual i2c patch
> and was able to integrate them intro my kernel.

You'll have to update it to be a new-style i2c device, unless there's a 
newer version floating around that what a quick google search turned up.

-Scott

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: I2C mux and device tree
  2008-10-27 20:33 ` Scott Wood
@ 2008-10-27 22:33   ` Felix Radensky
  0 siblings, 0 replies; 3+ messages in thread
From: Felix Radensky @ 2008-10-27 22:33 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list, linuxppc-embedded@ozlabs.org

Hi, Scott

Scott Wood wrote:
> [added linuxppc-dev for a wider audience]
>
> Felix Radensky wrote:
>> I run linux-2.6.26 on custom 460EX based board.
>> This platform has PCA9548 I2C mux on I2C bus 0.
>> I was wondering how can I describe the mux itself
>> and devices behind it (e.g RTC and temperature sensors)
>> in the device tree.
>
> Describe it as a node that is both an i2c client and an i2c controller.
>
> The Sun i2c binding says that i2c devices should have two reg cells, 
> the first being the bus number within the controller, and the second 
> being a shifted-left-by-one i2c bus address (as opposed to the 
> one-cell non-shifted address we currently use, because the Sun binding 
> wasn't known to us at the time).
>
> We could extend of_register_i2c_devices to understand two-cell 
> addresses, and call it once for each sub-bus with the bus number as a 
> parameter.
>
That would be nice.
I have everything working now, using platform data and 
i2c_register_board_info() in board setup
code. But it would be great to have everything defined in device tree.
>> If this is impossible at the moment, what other means
>> exist to work with devices behind the mux ? I have
>> found the pca954x patch and related virtual i2c patch
>> and was able to integrate them intro my kernel.
>
> You'll have to update it to be a new-style i2c device, unless there's 
> a newer version floating around that what a quick google search turned 
> up.
>
The latest version uses new-style i2c device, see
http://www.mail-archive.com/i2c%40lm-sensors.org/msg01538.html

Unfortunately it was not accepted.
> -Scott
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-10-27 23:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-25  9:02 I2C mux and device tree Felix Radensky
2008-10-27 20:33 ` Scott Wood
2008-10-27 22:33   ` Felix Radensky

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).