On Sat, May 24, 2008 at 11:45 AM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Saturday 24 May 2008, Grant Likely wrote:
>> > Isn't the same true for drivers/of/gpio.c or drivers/of/of_i2c.c, as well?
>>
>> I would argue 'yes!'
>
> ... all the more reason to have the SPI glue go there too,
> matc
On Saturday 24 May 2008, Grant Likely wrote:
> > Isn't the same true for drivers/of/gpio.c or drivers/of/of_i2c.c, as well?
>
> I would argue 'yes!'
... all the more reason to have the SPI glue go there too,
matching the ACPI/PCI precedent as well as those others!
___
On Saturday 24 May 2008, Grant Likely wrote:
> >>> > +++ b/drivers/spi/spi_of.c
> >>>
> >>> I think better placement for this is drivers/of, no?
> >>
> >> Yes please.
> >
> > Okay, I wasn't sure. Will do.
>
> I'm having second thoughts about this. I think this code is more SPI
> centric than it
On Sat, May 24, 2008 at 11:14 AM, Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> Grant Likely schrieb:
>> On Sat, May 24, 2008 at 12:26 AM, Grant Likely
>> <[EMAIL PROTECTED]> wrote:
>>> On Thu, May 22, 2008 at 8:05 PM, David Brownell <[EMAIL PROTECTED]> wrote:
On Wednesday 21 May 2008, Anton V
Grant Likely schrieb:
> On Sat, May 24, 2008 at 12:26 AM, Grant Likely
> <[EMAIL PROTECTED]> wrote:
>> On Thu, May 22, 2008 at 8:05 PM, David Brownell <[EMAIL PROTECTED]> wrote:
>>> On Wednesday 21 May 2008, Anton Vorontsov wrote:
> +++ b/drivers/spi/spi_of.c
I think better placement for t
On Sat, May 24, 2008 at 12:26 AM, Grant Likely
<[EMAIL PROTECTED]> wrote:
> On Thu, May 22, 2008 at 8:05 PM, David Brownell <[EMAIL PROTECTED]> wrote:
>> On Wednesday 21 May 2008, Anton Vorontsov wrote:
>>> > +++ b/drivers/spi/spi_of.c
>>>
>>> I think better placement for this is drivers/of, no?
>>
On Friday 23 May 2008, Grant Likely wrote:
> Very good point. Okay, so we cannot assume any correlation between
> the number of CS lines and the number of child nodes to the SPI bus.
That wasn't what I was implying ... all the devices hooked
up to a given chipselect should be viewed as a single (
On Thu, May 22, 2008 at 8:05 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 21 May 2008, Anton Vorontsov wrote:
>> > +++ b/drivers/spi/spi_of.c
>>
>> I think better placement for this is drivers/of, no?
>
> Yes please.
Okay, I wasn't sure. Will do.
g.
--
Grant Likely, B.Sc., P.En
On Thu, May 22, 2008 at 8:26 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 21 May 2008, Grant Likely wrote:
>> > spi-controller {
>> >#address-cells = 2;
>> >#size-cells = 0;
>> >[EMAIL PROTECTED],f000 { reg = < 0 f000 >; } // CS 0, SPI address
>> > f000
>> >
On Wed, May 21, 2008 at 7:16 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Friday 16 May 2008, Grant Likely wrote:
>> In my mind; platform_data and the device tree are all about the same
>> thing: representation. In other words, how to describe the
>> configuration of the hardware independent
On Wednesday 21 May 2008, Grant Likely wrote:
> > spi-controller {
> > #address-cells = 2;
> > #size-cells = 0;
> > [EMAIL PROTECTED],f000 { reg = < 0 f000 >; } // CS 0, SPI address f000
> > [EMAIL PROTECTED],f000 { reg = < 1 f000 >; } // CS 1, SPI address f000
> > [
On Wednesday 21 May 2008, Anton Vorontsov wrote:
> > +++ b/drivers/spi/spi_of.c
>
> I think better placement for this is drivers/of, no?
Yes please.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Friday 16 May 2008, Grant Likely wrote:
> In my mind; platform_data and the device tree are all about the same
> thing: representation. In other words, how to describe the
> configuration of the hardware independent of the driver itself.
Platform_data isn't what I'd call independent of drivers
On Wed, May 21, 2008 at 1:11 PM, Segher Boessenkool
<[EMAIL PROTECTED]> wrote:
>> Ok, elegance apart:-) You can use the SPI-bridge construct to also
>> describe simple SPI-chipselect configurations. But is it really a good
>> idea? Wouldn't it be better to handle these two cases separately?
>
> It
Ok, elegance apart:-) You can use the SPI-bridge construct to also
describe simple SPI-chipselect configurations. But is it really a good
idea? Wouldn't it be better to handle these two cases separately?
It would be best to handle all these things that are specific to
a certain SPI controller (l
On Fri, May 16, 2008 at 01:36:13PM -0600, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> This patch adds support for populating an SPI bus based on data in the
> OF device tree. This is useful for powerpc platforms which use the
> device tree instead of discrete code for describ
On Tue, May 20, 2008 at 9:26 AM, Guennadi Liakhovetski
<[EMAIL PROTECTED]> wrote:
> On Mon, 19 May 2008, Grant Likely wrote:
>
>> I'm not so fond of this approach. cs-parent doesn't seem to make much
>> sense to me. It might be better to have a cs-handler property on the
>> SPI bus node instead o
On Mon, 19 May 2008, Grant Likely wrote:
> I'm not so fond of this approach. cs-parent doesn't seem to make much
> sense to me. It might be better to have a cs-handler property on the
> SPI bus node instead of on the SPI slave nodes, but even then it
> leaves a number of questions about what it
On Mon, 19 May 2008 21:19:50 +0400
Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 07:09:00PM +0200, Gary Jennejohn wrote:
[snip extraneous content]
> > My problem was, and is, that there's no generic GPIO support for powerpc.
> > At least, not that I'm aware of. Please tell
On Mon, May 19, 2008 at 10:30 AM, Guennadi Liakhovetski
<[EMAIL PROTECTED]> wrote:
> On Mon, 19 May 2008, Grant Likely wrote:
>> But that is Linux internal
>> details; this discussion is about device tree bindings.
>>
>> Note that I did say that drivers can define additional properties for
>> suppo
On Mon, May 19, 2008 at 07:09:00PM +0200, Gary Jennejohn wrote:
> On Mon, 19 May 2008 09:57:21 -0600
> "Grant Likely" <[EMAIL PROTECTED]> wrote:
>
> > On Mon, May 19, 2008 at 7:17 AM, Guennadi Liakhovetski
> > <[EMAIL PROTECTED]> wrote:
> > > On Fri, 16 May 2008, Grant Likely wrote:
> > >
> > >> +
On Mon, 19 May 2008 09:57:21 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 7:17 AM, Guennadi Liakhovetski
> <[EMAIL PROTECTED]> wrote:
> > On Fri, 16 May 2008, Grant Likely wrote:
> >
> >> +However, the binding does not attempt to define the specific method
> >> fo
On Mon, 19 May 2008, Grant Likely wrote:
> On Mon, May 19, 2008 at 7:17 AM, Guennadi Liakhovetski
> <[EMAIL PROTECTED]> wrote:
> > On Fri, 16 May 2008, Grant Likely wrote:
> >
> >> +However, the binding does not attempt to define the specific method
> >> for
> >> +assigning chip select nu
On Mon, May 19, 2008 at 7:17 AM, Guennadi Liakhovetski
<[EMAIL PROTECTED]> wrote:
> On Fri, 16 May 2008, Grant Likely wrote:
>
>> +However, the binding does not attempt to define the specific method for
>> +assigning chip select numbers. Since SPI chip select configuration is
>> +flexi
On Fri, 16 May 2008, Grant Likely wrote:
> +However, the binding does not attempt to define the specific method for
> +assigning chip select numbers. Since SPI chip select configuration is
> +flexible and non-standardized, it is left out of this binding with the
> +assumption that
On Fri, May 16, 2008 at 4:49 PM, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> On Fri, May 16, 2008 at 04:14:23PM -0600, Grant Likely wrote:
>> > Maybe this code could do something like
>> > spi->dev.platform_data = nc->data;
>> > and board code would fill nc->data at early stages? This needs to be
On Fri, May 16, 2008 at 04:14:23PM -0600, Grant Likely wrote:
> On Fri, May 16, 2008 at 4:03 PM, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> > On Fri, May 16, 2008 at 01:36:13PM -0600, Grant Likely wrote:
> >> + /* Store a pointer to the node in the device structure */
> >> +
On Fri, May 16, 2008 at 4:03 PM, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> On Fri, May 16, 2008 at 01:36:13PM -0600, Grant Likely wrote:
>> + /* Store a pointer to the node in the device structure */
>> + of_node_get(nc);
>> + spi->dev.archdata.of_node = nc;
>
On Fri, May 16, 2008 at 01:36:13PM -0600, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> This patch adds support for populating an SPI bus based on data in the
> OF device tree. This is useful for powerpc platforms which use the
> device tree instead of discrete code for describ
On Fri, 16 May 2008 13:36:13 -0600 Grant Likely wrote:
> diff --git a/Documentation/powerpc/booting-without-of.txt
> b/Documentation/powerpc/booting-without-of.txt
> index 1d2a772..452c242 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of
On Fri, May 16, 2008 at 2:47 PM, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Fri, 16 May 2008 13:36:13 -0600 Grant Likely wrote:
>
>> diff --git a/Documentation/powerpc/booting-without-of.txt
>> b/Documentation/powerpc/booting-without-of.txt
>> index 1d2a772..452c242 100644
>> --- a/Documentation
From: Grant Likely <[EMAIL PROTECTED]>
This patch adds support for populating an SPI bus based on data in the
OF device tree. This is useful for powerpc platforms which use the
device tree instead of discrete code for describing platform layout.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
--
32 matches
Mail list logo
