Re: [RFC PATCH] slimbus: Linux driver framework for SLIMbus.

[Jean Delvare <khali@linux-fr.org>]

Hi Russell,

On Mon, 15 Aug 2011 20:37:24 +0100, Russell King wrote:
> On Wed, Aug 10, 2011 at 05:31:28PM -0600, Kenneth Heitke wrote:
> > From: Sagar Dharia <sdharia@codeaurora.org>
> > 
> > SLIMbus (Serial Low Power Interchip Media Bus) is a specification
> > developed by MIPI (Mobile Industry Processor Interface) alliance.
> > SLIMbus is a 2-wire implementation, which is used to communicate with
> > peripheral components like audio. Commonly used digital audio
> > interfaces such as I2S, PCM are intended for point-to-point connection
> > between application processor and single audio device and support one
> > or two channels. Adding more channels or functions is difficult
> > without increasing number of bus structures and hence pin count.
> > In parallel to audio channels, control buses such as I2C are typically
> > used for low-bandwidth control tasks.
> > SLIMbus replaces many digital audio buses and control buses by
> > providing flexible and dynamic bus-bandwidth between data-functions
> > and control-functions.
> > 
> > The framework supports message APIs, channel scheduling for SLIMbus.
> > Message APIs are used for status/control type of communication with a
> > device. Data Channel APIs are used for setting data channels between
> > SLIMbus devices.
> > 
> > Framework supports multiple busses (1 controller per bus) and multiple
> > clients/slave devices per controller.
> 
> This looks like another bus doing the same thing as SPI and I2C.
> 
> We seem to be having a growing number of bus_types which:
> 
> 1. Supply some kind of boardinfo array containing device names against
>    a device.
> struct i2c_board_info {
>         char            type[I2C_NAME_SIZE];
>         unsigned short  flags;
>         unsigned short  addr;
>         void            *platform_data;
>         struct dev_archdata     *archdata;
>         struct device_node *of_node;
>         int             irq;
> };
> struct spi_board_info {
>         char            modalias[SPI_NAME_SIZE];
>         const void      *platform_data;
>         void            *controller_data;
>         int             irq;
>         u32             max_speed_hz;
>         u16             bus_num;
>         u16             chip_select;
>         u8              mode;
> };
> 
> 2. match drivers to this against (i2c) type (spi) modalias.
> 
> 3. drivers contain essentially the same ID structure:
> #define I2C_NAME_SIZE   20
> #define I2C_MODULE_PREFIX "i2c:"
> struct i2c_device_id {
>         char name[I2C_NAME_SIZE];
>         kernel_ulong_t driver_data      /* Data private to the driver */
>                         __attribute__((aligned(sizeof(kernel_ulong_t))));
> };
> #define SPI_NAME_SIZE   32
> #define SPI_MODULE_PREFIX "spi:"
> struct spi_device_id {
>         char name[SPI_NAME_SIZE];
>         kernel_ulong_t driver_data      /* Data private to the driver */
>                         __attribute__((aligned(sizeof(kernel_ulong_t))));
> };
> +#define SLIMBUS_NAME_SIZE      32
> +#define SLIMBUS_MODULE_PREFIX "slim:"
> +struct slim_device_id {
> +       char name[SLIMBUS_NAME_SIZE];
> +       kernel_ulong_t driver_data      /* Data private to the driver */
> +                       __attribute__((aligned(sizeof(kernel_ulong_t))));
> +};

The similarities are certainly due to the fact that spi and i2c were
designed by the same person (David Brownell), and slimbus most probably
was originally cloned from either. I'm glad we don't reinvent the wheel
each time.

> I heard of another bus type at the recent Linaro conference which sounds
> like it's going to do yet again a similar thing.  So it sounds like we're
> heading for about four of these things.
> 
> Is there any way to consolidate this before we end up with four ways of
> solving the same problem?

Each bus type has its own specificity, so I doubt we can make them all
fit in a single model. Of course they have common points, but USB and
PCI also do to some extent, still we don't have a common framework for
these.

At this point I am unsure, what problem you are trying to solve
exactly. The amount of code you refer to above is low, so I see very
little room for improvement. But if you have a concrete proposal, I am
ready to evaluate it.

-- 
Jean Delvare