On Wednesday 31 July 2013 16:33:22 Mark Rutland wrote:
> On Wed, Jul 31, 2013 at 03:57:13PM +0100, Marc Dietrich wrote:
> > Am Mittwoch, 31. Juli 2013, 15:13:14 schrieb Mark Rutland:
> > > On Mon, Jul 29, 2013 at 10:59:26PM +0100, Stephen Warren wrote:
> > > > (Also Cc'ing the DT binding maintainers and hence quoting this in
> > > > full)
> > >
> > > Cheers.
> > >
> > > > On 07/27/2013 07:23 AM, Marc Dietrich wrote:
> > > > > Hi,
> > > > >
> > > > > this is an RFC for an mfd device introduced here [1]. I didn't got
> > > > > much
> > > > > response, except from Stephen, but that bothered me enough already
> > > > > ;-)
> > > > >
> > > > > I'm going describe the hw again shortly, for a more complete
> > > > > description, see [1]. What we have here is an EC which communicates
> > > > > to
> > > > > the host cpu (NVIDIA Tegra) via I2C. The unusual part is that the EC
> > > > > is
> > > > > I2C master while the host cpu is the slave. The EC has several ports
> > > > > to
> > > > > connect peripherals like keyboard, mouse, ... and also to control
> > > > > some
> > > > > system states (suspend, low bat, power key, ...). Ok, so much for
> > > > > the
> > > > > hardware description, now the binding. I think I integrated all
> > > > > comments made by Stephen in [2].
> > > > >
> > > > > i2c-slave@7000c500 {
> > > > >
> > > > > compatible = "nvidia,tegra20-i2c-slave", "simple-bus";
> > > >
> > > > Thinking more about this, I don't think simple-bus is appropriate
> > > > here,
> > > > for the same reasons that i2c-master bindings don't specify simple-bus
> > > > here.
> > > >
> > > > "simple-bus" is usually used in a case where the node in question is
> > > > pretty much just a simple aggregation of some child nodes, and the
> > > > child
> > > > nodes are the same "type" of node as the node that is the simple-bus.
> > > > For example, when grouping a variety of memory-mapped peripherals
> > > > together to provide some structure to a larger memory-mapped bus,
> > > > perhaps with a "ranges" property etc. to do some remapping. In this
> > > > case, the child nodes are basically independent of the simple-bus
> > > > node,
> > > > just relying on it for a bit of DT parsing, but not at run-time.
> > >
> > > I'd expect any simple-bus node to be completely ignorable - if it
> > > *requires* any configuration to child nodes to be usable, or child node
> > > require any information from the bus (other than some addresss
> > > translation via the ranges property), then the node is clearly not
> > > compatible with the simple-bus concept.
> > >
> > > If you need to instantiate child nodes as Linux platform devices, this
> > > should be done in the driver for the bus. Relying on simple-bus to do
> > > this is a hack.
> >
> > ok, I'll rip this off from both nodes. I guess I should use
> > of_platform_populate instead and keeping the compatible node in the childs
> > - right?
>
> I believe that would be a correct way of handling this.
Great. Thinking about a really generic dt representation of an i2c bus (with
multi-slave, slave and master controllers can act in parallel), something like
this came into my mind:
i2c@xxxxxxx {
compatible = "nvidia,tegra-i2c", "simple-bus"; /* This time it is
truly a simple bus, because there is no higher control instance */
... common master/slave resources ...
master {
compatible = "nvidia,tegra-i2c-master";
... resources ??? ....
client1@xx {
...
};
client2@xx {
...
};
...
}
slave1@xxx {
compatible = "nvidia,tegra-i2c-slave";
... resources ??? ...
client1@xx {
...
};
};
slave2@xxx {
compatible = "nvidia,tegra-i2c-slave";
... resources ??? ...
client1@xx {
...
};
};
....
};
Marc
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
