>> Well, they aren't supposed to :-) The problem at this point is
>> more due
>> to the fact that for things that haven't been specified by
>> official OF
>> bindings, people are going all over trying to define their own and
>> sometimes conflicting bindings and then changing them.
>
> I think
> As I wrote a couple of times already, it's a perfectly acceptable
> approach to have "constructors" (what you call oftree-interpreter)
> that
> generate platform devices from the OF tree.
Yes, lots of the "glue" code could be made into some
helper library. Also, while that glue code might be
> Is there a reason why there is sooo much interaction of the
> platform code with the oftree?
Yes. Since the decision has been made to require a device
tree for every platform, arch/powerpc is in the luxury
position that we can actually exploit the benefits of _having_
a tree for every platform.
>> Hmm, as I stated above: Handling the SPI slave devices is done in
>> the SPI
>> framework. But including this data into the dts sounds better than
>> including
>> it into the BSP. Is there some documentation around how to
>> describe such a
>> SPI bus with its devices in the dts?
>
> I don
On Mon, 2007-07-16 at 08:51 +0200, Robert Schwebel wrote:
> On Sun, Jul 15, 2007 at 06:48:53AM +1000, Benjamin Herrenschmidt wrote:
> > Your approach would work I suppose though it's a bit ugly.
>
> Speaking of uggly, I'm still wondering why this oftree stuff for powerpc
> must be s compli
On Mon, 2007-07-16 at 09:19 +0200, Robert Schwebel wrote:
> I think it is a fundamental thing: the "we just have to wait long
> enough, until oftree definitions have settled" proposal just isn't
> right. It may be right for big irons, being well defined. But for the
> embedded processors, too less
On Mon, Jul 16, 2007 at 05:09:12PM +1000, Benjamin Herrenschmidt wrote:
> As I wrote a couple of times already, it's a perfectly acceptable
> approach to have "constructors" (what you call oftree-interpreter) that
> generate platform devices from the OF tree.
Great!
> > mapping. Is there a reason
On Mon, 2007-07-16 at 08:51 +0200, Robert Schwebel wrote:
> On Sun, Jul 15, 2007 at 06:48:53AM +1000, Benjamin Herrenschmidt wrote:
> > Your approach would work I suppose though it's a bit ugly.
>
> Speaking of uggly, I'm still wondering why this oftree stuff for powerpc
> must be s compli
On Sun, Jul 15, 2007 at 06:48:53AM +1000, Benjamin Herrenschmidt wrote:
> Your approach would work I suppose though it's a bit ugly.
Speaking of uggly, I'm still wondering why this oftree stuff for powerpc
must be s complicated. If you come from the ARM-linux world like we
do, the whole po
> Hmm, as I stated above: Handling the SPI slave devices is done in the SPI
> framework. But including this data into the dts sounds better than including
> it into the BSP. Is there some documentation around how to describe such a
> SPI bus with its devices in the dts?
I don't think so, I dou
Hi Ben,
On Saturday 14 July 2007 22:48, Benjamin Herrenschmidt wrote:
> On Sat, 2007-07-14 at 18:31 +0200, Juergen Beisert wrote:
> > Hi,
> >
> > I'm trying to use the drivers/spi/mpc52xx_psc_spi.c as an open firmware
> > device (ARCH=powerpc). This device needs some platform specific data (the
>
On Sat, 2007-07-14 at 18:31 +0200, Juergen Beisert wrote:
> Hi,
>
> I'm trying to use the drivers/spi/mpc52xx_psc_spi.c as an open firmware device
> (ARCH=powerpc). This device needs some platform specific data (the devices
> connected to the SPI bus and how to drive the chipselects to these devic
12 matches
Mail list logo
