From: Matt Sealey <hidden> Date: 2008-01-13 22:50:33
Hi guys,
I know the I2C stuff is up in the air (I cannot pinpoint the documentation
for it) and have not found any CAN bus documentation for device trees.
I want to update the firmware tree to add these but, am basically looking
for those docs, or someone to go over a few points.. is there some kind of
tree standard I should be looking at, or some patch I missed which has
a driver which implements something that looks at a compatible tree?
--
Matt Sealey [off-list ref]
Genesi, Manager, Developer Relations
From: Grant Likely <hidden> Date: 2008-01-14 00:35:11
On 1/13/08, Matt Sealey [off-list ref] wrote:
Hi guys,
I know the I2C stuff is up in the air (I cannot pinpoint the documentation
for it) and have not found any CAN bus documentation for device trees.
I want to update the firmware tree to add these but, am basically looking
for those docs, or someone to go over a few points.. is there some kind of
tree standard I should be looking at, or some patch I missed which has
a driver which implements something that looks at a compatible tree?
I think some consensus has been achieved for describing i2c busses and
their attached devices, but I don't think booting-without-of.txt has
been updated with the details yet. I need to look into that more.
I don't think anyone has tackled CAN. Best bet is to draft a tree in
the way you think it should be described and post it to the list.
That will give a starting point for us to discuss it and come to
consensus.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
From: Olof Johansson <hidden> Date: 2008-01-14 04:42:16
On Sun, Jan 13, 2008 at 05:35:09PM -0700, Grant Likely wrote:
On 1/13/08, Matt Sealey [off-list ref] wrote:
quoted
Hi guys,
I know the I2C stuff is up in the air (I cannot pinpoint the documentation
for it) and have not found any CAN bus documentation for device trees.
I want to update the firmware tree to add these but, am basically looking
for those docs, or someone to go over a few points.. is there some kind of
tree standard I should be looking at, or some patch I missed which has
a driver which implements something that looks at a compatible tree?
I think some consensus has been achieved for describing i2c busses and
their attached devices, but I don't think booting-without-of.txt has
been updated with the details yet. I need to look into that more.
I think simple devices might have been agreed upon (but it's been a
while since it was covered). Muxed busses probably hasn't. Either that
or I completely missed the emails.
-Olof
From: Wolfgang Grandegger <hidden> Date: 2008-01-14 08:10:01
Grant Likely wrote:
On 1/13/08, Matt Sealey [off-list ref] wrote:
quoted
Hi guys,
I know the I2C stuff is up in the air (I cannot pinpoint the documentation
for it) and have not found any CAN bus documentation for device trees.
I want to update the firmware tree to add these but, am basically looking
for those docs, or someone to go over a few points.. is there some kind of
tree standard I should be looking at, or some patch I missed which has
a driver which implements something that looks at a compatible tree?
I think some consensus has been achieved for describing i2c busses and
their attached devices, but I don't think booting-without-of.txt has
been updated with the details yet. I need to look into that more.
I don't think anyone has tackled CAN. Best bet is to draft a tree in
the way you think it should be described and post it to the list.
That will give a starting point for us to discuss it and come to
consensus.
For MSCAN on the MPC5200 we currently have:
mscan@900 {
device_type = "mscan";
compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <0>;
interrupts = <2 11 0>;
interrupt-parent = <&mpc5200_pic>;
reg = <900 80>;
};
mscan@980 {
device_type = "mscan";
compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <1>;
interrupts = <2 12 0>;
interrupt-parent = <&mpc5200_pic>;
reg = <980 80>;
};
The only thing missing is a property defining the routing of the CAN
signals, CAN 1 on I2C1 pins or CAN 2 on TMR01 pins. I think it does not
make sense to describe CAN devices on the CAN bus like for I2C.
Wolfgang.
From: Grant Likely <hidden> Date: 2008-01-14 14:28:33
On 1/14/08, Wolfgang Grandegger [off-list ref] wrote:
Grant Likely wrote:
quoted
On 1/13/08, Matt Sealey [off-list ref] wrote:
quoted
Hi guys,
I know the I2C stuff is up in the air (I cannot pinpoint the documentation
for it) and have not found any CAN bus documentation for device trees.
I want to update the firmware tree to add these but, am basically looking
for those docs, or someone to go over a few points.. is there some kind of
tree standard I should be looking at, or some patch I missed which has
a driver which implements something that looks at a compatible tree?
I think some consensus has been achieved for describing i2c busses and
their attached devices, but I don't think booting-without-of.txt has
been updated with the details yet. I need to look into that more.
I don't think anyone has tackled CAN. Best bet is to draft a tree in
the way you think it should be described and post it to the list.
That will give a starting point for us to discuss it and come to
consensus.
For MSCAN on the MPC5200 we currently have:
mscan@900 {
device_type = "mscan";
compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <0>;
interrupts = <2 11 0>;
interrupt-parent = <&mpc5200_pic>;
reg = <900 80>;
};
mscan@980 {
device_type = "mscan";
compatible = "mpc5200b-mscan","mpc5200-mscan";
cell-index = <1>;
interrupts = <2 12 0>;
interrupt-parent = <&mpc5200_pic>;
reg = <980 80>;
};
The only thing missing is a property defining the routing of the CAN
signals, CAN 1 on I2C1 pins or CAN 2 on TMR01 pins. I think it does not
make sense to describe CAN devices on the CAN bus like for I2C.
I don't think that pin routing matters much for the device tree.
Ideally, firmware should be responsible for port_config, and as long
as it is already configured, the CAN device can find it's devices.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
From: Scott Wood <hidden> Date: 2008-01-14 19:04:08
On Sun, Jan 13, 2008 at 10:42:16PM -0600, Olof Johansson wrote:
I think simple devices might have been agreed upon (but it's been a
while since it was covered). Muxed busses probably hasn't. Either that
or I completely missed the emails.
I posted something in one of the i2c device tree threads a while ago:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036353.html
Basically, you just have a node that is both an i2c device and an i2c
controller, and the mux driver binds to it and registers the subordinate
buses as new i2c controllers.
-Scott
From: David Gibson <hidden> Date: 2008-01-14 23:21:04
On Mon, Jan 14, 2008 at 09:10:01AM +0100, Wolfgang Grandegger wrote:
Grant Likely wrote:
quoted
On 1/13/08, Matt Sealey [off-list ref] wrote:
quoted
Hi guys,
I know the I2C stuff is up in the air (I cannot pinpoint the documentation
for it) and have not found any CAN bus documentation for device trees.
I want to update the firmware tree to add these but, am basically looking
for those docs, or someone to go over a few points.. is there some kind of
tree standard I should be looking at, or some patch I missed which has
a driver which implements something that looks at a compatible tree?
I think some consensus has been achieved for describing i2c busses and
their attached devices, but I don't think booting-without-of.txt has
been updated with the details yet. I need to look into that more.
I don't think anyone has tackled CAN. Best bet is to draft a tree in
the way you think it should be described and post it to the list.
That will give a starting point for us to discuss it and come to
consensus.
For MSCAN on the MPC5200 we currently have:
mscan@900 {
device_type = "mscan";
These device_type entries should not be here.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson