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 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 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, 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
28 matches
Mail list logo
