Hi Sagar,
I have some comments on it.
On Wed, 27 Apr 2016 17:58:04 -0600
Sagar Dharia wrote:
[..]
> diff --git a/drivers/slimbus/slim-core.c b/drivers/slimbus/slim-core.c
> new file mode 100644
> index 000..6024f74
> --- /dev/null
> +++ b/drivers/slimbus/slim-core.c
Hi Sagar,
I have some comments on it.
On Wed, 27 Apr 2016 17:58:04 -0600
Sagar Dharia wrote:
[..]
> diff --git a/drivers/slimbus/slim-core.c b/drivers/slimbus/slim-core.c
> new file mode 100644
> index 000..6024f74
> --- /dev/null
> +++ b/drivers/slimbus/slim-core.c
> @@ -0,0 +1,684 @@
>
On Thu, Apr 28, 2016 at 06:49:23PM +0200, Arnd Bergmann wrote:
> On Thursday 28 April 2016 17:39:20 Mark Brown wrote:
> > It's not just platforms that use these things though - there's things
> > like the SolarFlare NICs where the firmware update mechanism essentially
> > involves exposing a SPI
On Thu, Apr 28, 2016 at 06:49:23PM +0200, Arnd Bergmann wrote:
> On Thursday 28 April 2016 17:39:20 Mark Brown wrote:
> > It's not just platforms that use these things though - there's things
> > like the SolarFlare NICs where the firmware update mechanism essentially
> > involves exposing a SPI
On Thursday 28 April 2016 17:39:20 Mark Brown wrote:
> > I don't think we have merge new platform support on any
> > architecture that would need this in the past years and
> > stuff like spi_board_info and i2c_board_info is only really
> > used on really old machines (but not going away any time
On Thursday 28 April 2016 17:39:20 Mark Brown wrote:
> > I don't think we have merge new platform support on any
> > architecture that would need this in the past years and
> > stuff like spi_board_info and i2c_board_info is only really
> > used on really old machines (but not going away any time
On Thu, Apr 28, 2016 at 04:59:02PM +0200, Arnd Bergmann wrote:
> My comment this time was for the particular driver, but I'd
> still also maintain that a new subsystem in general should not
> start out by addressing the needs of traditional board files.
I certainly wouldn't insist that people
On Thu, Apr 28, 2016 at 04:59:02PM +0200, Arnd Bergmann wrote:
> My comment this time was for the particular driver, but I'd
> still also maintain that a new subsystem in general should not
> start out by addressing the needs of traditional board files.
I certainly wouldn't insist that people
On Thursday 28 April 2016 15:38:01 Mark Brown wrote:
> On Thu, Apr 28, 2016 at 02:33:41PM +0200, Arnd Bergmann wrote:
> > On Thursday 28 April 2016 12:53:37 Mark Brown wrote:
> > I don't foresee mobile phones with ACPI using this subsystem, but even
> > if we got them, it would be a horrible idea
On Thursday 28 April 2016 15:38:01 Mark Brown wrote:
> On Thu, Apr 28, 2016 at 02:33:41PM +0200, Arnd Bergmann wrote:
> > On Thursday 28 April 2016 12:53:37 Mark Brown wrote:
> > I don't foresee mobile phones with ACPI using this subsystem, but even
> > if we got them, it would be a horrible idea
On Thu, Apr 28, 2016 at 02:33:41PM +0200, Arnd Bergmann wrote:
> On Thursday 28 April 2016 12:53:37 Mark Brown wrote:
> > On Thu, Apr 28, 2016 at 12:00:26PM +0200, Arnd Bergmann wrote:
> > > This looks like an artifact of ancient pre-DT times. I'd say kill it off
> > > before
> > > someone
On Thu, Apr 28, 2016 at 02:33:41PM +0200, Arnd Bergmann wrote:
> On Thursday 28 April 2016 12:53:37 Mark Brown wrote:
> > On Thu, Apr 28, 2016 at 12:00:26PM +0200, Arnd Bergmann wrote:
> > > This looks like an artifact of ancient pre-DT times. I'd say kill it off
> > > before
> > > someone
On Thursday 28 April 2016 12:53:37 Mark Brown wrote:
> On Thu, Apr 28, 2016 at 12:00:26PM +0200, Arnd Bergmann wrote:
> > On Wednesday 27 April 2016 17:58:04 Sagar Dharia wrote:
>
> > > +int slim_add_device(struct slim_controller *ctrl, struct slim_device
> > > *sbdev)
>
> > This looks like an
On Thursday 28 April 2016 12:53:37 Mark Brown wrote:
> On Thu, Apr 28, 2016 at 12:00:26PM +0200, Arnd Bergmann wrote:
> > On Wednesday 27 April 2016 17:58:04 Sagar Dharia wrote:
>
> > > +int slim_add_device(struct slim_controller *ctrl, struct slim_device
> > > *sbdev)
>
> > This looks like an
On Thu, Apr 28, 2016 at 12:00:26PM +0200, Arnd Bergmann wrote:
> On Wednesday 27 April 2016 17:58:04 Sagar Dharia wrote:
> > +int slim_add_device(struct slim_controller *ctrl, struct slim_device
> > *sbdev)
> This looks like an artifact of ancient pre-DT times. I'd say kill it off
> before
>
On Thu, Apr 28, 2016 at 12:00:26PM +0200, Arnd Bergmann wrote:
> On Wednesday 27 April 2016 17:58:04 Sagar Dharia wrote:
> > +int slim_add_device(struct slim_controller *ctrl, struct slim_device
> > *sbdev)
> This looks like an artifact of ancient pre-DT times. I'd say kill it off
> before
>
On Wednesday 27 April 2016 17:58:04 Sagar Dharia wrote:
> +/**
> + * slim_driver_register: Client driver registration with slimbus
> + * @drv:Client driver to be associated with client-device.
> + * This API will register the client driver with the slimbus
> + * It is called from the driver's
On Wednesday 27 April 2016 17:58:04 Sagar Dharia wrote:
> +/**
> + * slim_driver_register: Client driver registration with slimbus
> + * @drv:Client driver to be associated with client-device.
> + * This API will register the client driver with the slimbus
> + * It is called from the driver's
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-codec.
SLIMbus uses Time-Division-Multiplexing to accommodate
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-codec.
SLIMbus uses Time-Division-Multiplexing to accommodate
20 matches
Mail list logo