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@xxxxxxxxxxxxxx>
> >
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
