> Date: Fri, 9 Sep 2005 11:33:52 +0100 (BST)
> From: Mark Underwood <[EMAIL PROTECTED]>
>
> ...
> > That implies whoever is registering is actually
> > going and creating the
> > SPI devices ... and doing it AFTER the controller
> > driver is registered.
> > I actually have issues with each of thos
> Date: Fri, 9 Sep 2005 11:40:39 -0600
> From: Grant Likely <[EMAIL PROTECTED]>
>
> On 9/8/05, David Brownell <[EMAIL PROTECTED]> wrote:
> > That implies whoever is registering is actually going and creating the
> > SPI devices ... and doing it AFTER the controller driver is registered.
> > I actua
--- Grant Likely <[EMAIL PROTECTED]> wrote:
> On 9/8/05, David Brownell <[EMAIL PROTECTED]>
> wrote:
> > That implies whoever is registering is actually
> going and creating the
> > SPI devices ... and doing it AFTER the controller
> driver is registered.
> > I actually have issues with each of t
On 9/8/05, David Brownell <[EMAIL PROTECTED]> wrote:
> That implies whoever is registering is actually going and creating the
> SPI devices ... and doing it AFTER the controller driver is registered.
> I actually have issues with each of those implications.
>
> However, I was also aiming to suppor
--- David Brownell <[EMAIL PROTECTED]> wrote:
> > Date: Wed, 7 Sep 2005 19:38:43 +0100 (BST)
> > From: Mark Underwood <[EMAIL PROTECTED]>
> > ...
> >
> > I see several posabiltiys of how SPI devices could
> be
> > connected to an adapter.
>
> Certainly, and all are addressed cleanly by the kind
> Date: Wed, 7 Sep 2005 19:38:43 +0100 (BST)
> From: Mark Underwood <[EMAIL PROTECTED]>
> ...
>
> I see several posabiltiys of how SPI devices could be
> connected to an adapter.
Certainly, and all are addressed cleanly by the kind of
configuration scheme I showed.
> 1) All SPI devices are hardw
--- David Brownell <[EMAIL PROTECTED]> wrote:
> > With my subsystem that would look like:
> >
> > static const struct spi_cs_table
> > platform_spi1_cs_table[] = {
> > {
> > .name = "touchscreen",
> > .cs_no = 1,
> > .platform_data = NULL,
> > .flags = SPI_CS_IDLE_HIGH,
> > .cs_data
> With my subsystem that would look like:
>
> static const struct spi_cs_table
> platform_spi1_cs_table[] = {
> {
> .name = "touchscreen",
> .cs_no = 1,
> .platform_data = NULL,
> .flags = SPI_CS_IDLE_HIGH,
> .cs_data = 0,
> },
> {
> .name = "flash",
> .cs_no = 3,
> .platfor
--- David Brownell <[EMAIL PROTECTED]> wrote:
> > > > I did think about doing this but the problem
> is how do
> > > > you know bus 2 is the bus you think it is?
> > >
> > > The numbering is board-specific, but in most
> cases
> > > that can be simplified to being SOC-specific.
> ...
> > >
> >
> > > I did think about doing this but the problem is how do
> > > you know bus 2 is the bus you think it is?
> >
> > The numbering is board-specific, but in most cases
> > that can be simplified to being SOC-specific. ...
> >
> > Hotpluggable SPI controllers are not common, but
> > that's where
--- David Brownell <[EMAIL PROTECTED]> wrote:
> > > @@ -193,6 +193,34 @@
> > >
> > > #ifdef CONFIG_OMAP_OSK_MISTRAL
> > >
> > > +#include
> > > +
> > > +struct ads7864_info {/* FIXME put in standard
> header */
> > > + u16 pen_irq, busy; /* GPIO lines */
> > > + u
> > @@ -193,6 +193,34 @@
> >
> > #ifdef CONFIG_OMAP_OSK_MISTRAL
> >
> > +#include
> > +
> > +struct ads7864_info { /* FIXME put in standard header */
> > + u16 pen_irq, busy; /* GPIO lines */
> > + u16 x_ohms, y_ohms;
> > +};
> > +
> > +static struct ads7
Hi Mark,
you've mentioned the code that you're working on several times, but no
one in LKML has ever seen a single line of code from you. Will you
please be so kind to share a piece of you SPI subsystem?
TIA!
Mark Underwood wrote:
--- David Brownell <[EMAIL PROTECTED]> wrote:
Date: Wed
--- David Brownell <[EMAIL PROTECTED]> wrote:
> > Date: Wed, 31 Aug 2005 08:59:44 +0100 (BST)
> > From: Mark Underwood <[EMAIL PROTECTED]>
> >
> > --- David Brownell wrote:
> >
> > > The last couple times SPI frameworks came up
> here, some of the feedback
> > > included "make it use the driver m
> Date: Wed, 31 Aug 2005 08:59:44 +0100 (BST)
> From: Mark Underwood <[EMAIL PROTECTED]>
>
> --- David Brownell wrote:
>
> > The last couple times SPI frameworks came up here, some of the feedback
> > included "make it use the driver model properly; don't be like I2C".
> >
> > In hopes that it'll
--- David Brownell <[EMAIL PROTECTED]> wrote:
> The last couple times SPI frameworks came up here,
> some of the feedback
> included "make it use the driver model properly;
> don't be like I2C".
>
> In hopes that it'll be useful, here's a small SPI
> core with driver model
> support driven from
16 matches
Mail list logo
