--- David Brownell <[email protected]> wrote:
> > > @@ -193,6 +193,34 @@
> > >
> > > #ifdef CONFIG_OMAP_OSK_MISTRAL
> > >
> > > +#include <linux/spi.h>
> > > +
> > > +struct ads7864_info { /* FIXME put in standard
> header */
> > > + u16 pen_irq, busy; /* GPIO lines */
> > > + u16 x_ohms, y_ohms;
> > > +};
> > > +
> > > +static struct ads7864_info mistral_ts_info = {
> > > + .pen_irq = OMAP_GPIO_IRQ(4),
> > > + .busy = /* GPIO */ 6,
> > > + .x_ohms = 419,
> > > + .y_ohms = 486,
> > > +};
> > > +
> > > +static const struct spi_board_info
> mistral_boardinfo[] = {
> > > +{
> > > + /* MicroWire CS0 has an ads7846e with
> touchscreen and
> > > + * other sensors. It's currently glued into
> some OMAP
> > > + * touchscreen support that ignores the driver
> model.
> > > + */
> > > + .driver_name = "ads7846",
> > > + .platform_data = &mistral_ts_info,
> > > + .max_speed_hz = 2000000,
> > > + .bus_num = 2, /* spi2 == microwire */
> >
> > 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. In this case I numbered the
> SPI-capable controllers
> (from 1..7, not included in this patch) and this one
> came out "2". The
> consistency matters, not the actual (nonzero)
> numbers.
>
> Hotpluggable SPI controllers are not common, but
> that's where that sysfs
> API to define new devices would really hit the spot.
> That would be how the
> kernel learns about "struct spi_board_info"
> structures associated with some
> dynamically assigned bus_num. Likely some
> convention for dynamically
> assigned IDs would help, like "they're all
> negative".
>
> (What I've seen a bit more often is that expansion
> cards will be wired
> for SPI, so the thing that's vaguely hotplug-ish is
> that once you know
> what card's hooked up, you'll know the SPI devices
> it has. Then the
> question is how to tell the kernel about them ...
> same solution, which
> again must work without hardware probing.)
>
This is why I decided to pass the cs table as platform
data when an adapter is registered. This way you don't
have to try to find out an adapters bus number as the
adapter has the cs table in it, but because it was
passed in as platform data it still abstracts that
from the adapter driver. Simple, yet effective :)
Have you looked at the patch which I sent?
http://www.ussg.iu.edu/hypermail/linux/kernel/0509.0/0817.html
I would appreciate any comments on this approach.
>
> > This would
> > work for SPI adapters that are platform devices,
> but
> > what about hot-plug devices like PCI and USB (we
> are
> > thinking of actually making a USB to SPI converter
> so
> > customers can try out some of our SPI devices on a
> PC
>
> Some of the microcontrollers that talk both USB
> (slave) and SPI (master)
> will even run Linux for you. :)
Yes, but not on a 8051 bassed Cypress USB chip ;)
>
> - Dave
>
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |