No need to explicitly set the cell's platform_data/data_size.
In this case, move the various platform_data pointers
to driver_data. All of the clients which make use of it
are also changed.
Signed-off-by: Andres Salomon
---
drivers/dma/timb_dma.c |2 +-
drivers/gpio/timbgpio.c
On Wed, 2 Feb 2011 13:01:52 -0800
Russ Gorby wrote:
> SPI master controller driver for the Intel MID platform Medfield
> This driver uses the Penwell SSP controller and configures it to
> be a SPI device (spibus 3). This bus supports a single device -
> the 3G SPI modem that can operate up to 25
On Wed, 2 Feb 2011 13:01:52 -0800
Russ Gorby wrote:
> SPI master controller driver for the Intel MID platform Medfield
> This driver uses the Penwell SSP controller and configures it to
> be a SPI device (spibus 3). This bus supports a single device -
> the 3G SPI modem that can operate up to 25
On Wed, Feb 02, 2011 at 01:01:52PM -0800, Russ Gorby wrote:
> SPI master controller driver for the Intel MID platform Medfield
> This driver uses the Penwell SSP controller and configures it to
> be a SPI device (spibus 3). This bus supports a single device -
> the 3G SPI modem that can operate up
SPI master controller driver for the Intel MID platform Medfield
This driver uses the Penwell SSP controller and configures it to
be a SPI device (spibus 3). This bus supports a single device -
the 3G SPI modem that can operate up to 25Mhz.
Signed-off-by: Russ Gorby
---
drivers/spi/Kconfig
Hello SPI maintainers,
I am sending a patch for the (new) intel_mid_ssp_spi driver for
consideration for inclusion in the Linux Kernel. This is a SPI master
controller driver that is being used for the intel MID platform (Medfield).
It uses the on-board Bulverde SSP controller configured for SPI (s
Some platform attributes (e.g. max_hz, use_dma) were being intuited
from the modem type. These things should be specified by the platform
data.
Added max_hz, use_dma to ifx_modem_platform_data definition,
replaced is_6160 w/ modem_type, and changed clients accordingly
Signed-off-by: Russ Gorby
-
Hello all,
I am sending a patch for the ifx6x60 driver to expand the
information available via the platform data structure.
I'd like these to be considred for inclusion into the Linux Kernel.
Additional patches will follow that will depend on these changes
so I'd like to iron these out first.
Pa
right now the platform device and its platform data is included in one big
struct which requires its custom ->release function. The problem with the
release function within the driver is that it might be called after the
driver was removed because someone was holding a reference to it and it
was no
On Wed, Feb 2, 2011 at 4:31 AM, Bernhard Walle wrote:
> Add the compat_ioctl for operations on /dev/spi* so that 32 bit
> userspace applications can access SPI. As far as I can see all data
> structure are already prepared for that, so no additional conversion has
> to be done.
>
> My use case is
On Wed, Feb 2, 2011 at 2:37 AM, Arnd Bergmann wrote:
> On Wednesday 02 February 2011, Grant Likely wrote:
>> On Tue, Feb 01, 2011 at 10:02:46AM +0100, Bernhard Walle wrote:
>> > Add the compat_ioctl for operations on /dev/spi* so that 32 bit
>> > userspace applications can access SPI. As far as I
On Wednesday 02 February 2011, Bernhard Walle wrote:
> Add the compat_ioctl for operations on /dev/spi* so that 32 bit
> userspace applications can access SPI. As far as I can see all data
> structure are already prepared for that, so no additional conversion has
> to be done.
>
> My use case is M
McSPI runtime conversion.
Changes involves:
1) remove clock framework apis to use runtime framework apis.
2) context restore from runtime resume which is a callback for get_sync.
3) Remove SYSCONFIG(sysc) register handling
(a) Remove context save and restore of sysc reg and remove soft rese
From: Charulatha V
Update omap3 hwmod data file with McSPI info.
Signed-off-by: Charulatha V
Signed-off-by: Govindraj.R
Acked-by: Grant Likely
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280
1 files changed, 280 insertions(+), 0 deletions(-)
diff --git a/
From: Charulatha V
Update the 2430 hwmod data file with McSPI info.
Signed-off-by: Charulatha V
Signed-off-by: Govindraj.R
Acked-by: Grant Likely
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219
1 files changed, 219 insertions(+), 0 deletions(-)
diff --git
From: Charulatha V
Update the omap2420 hwmod data with the McSPI info.
Add a device attribute structure which will be used
for passing number of chipselects from hwmod data.
Add revision macros to be passed from rev field from
hwmod.
Signed-off-by: Charulatha V
Signed-off-by: Govindraj.R
Acked
From: Charulatha V
Cleans up all base address definitions for omap_mcspi
and adapts the device registration and driver to hwmod framework.
Changes involves:
1) Removing all base address macro defines.
2) Using omap-device layer to register device and utilizing data from
hwmod data file for bas
Changes invloves:
1) Addition of hwmod data for omap2/3/4.
2) McSPI driver hwmod adaptation with cleanup of base address
macros and using omap-device API's.
3) Runtime Conversion of McSPI driver.
Changes from v5:
---
Rebased on top of 2.6.38-rc3 as per Kevin's comme
From: Benoit Cousson
Update omap4 hwmod file with McSPI info.
Signed-off-by: Benoit Cousson
Signed-off-by: Charulatha V
Signed-off-by: Govindraj.R
Acked-by: Grant Likely
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 267
1 files changed, 267 insertions(+), 0
Am 02.02.2011 12:15, schrieb Arnd Bergmann:
> On Wednesday 02 February 2011, Bernhard Walle wrote:
>> Add the compat_ioctl for operations on /dev/spi* so that 32 bit
>> userspace applications can access SPI. As far as I can see all data
>> structure are already prepared for that, so no additional c
Add the compat_ioctl for operations on /dev/spi* so that 32 bit
userspace applications can access SPI. As far as I can see all data
structure are already prepared for that, so no additional conversion has
to be done.
My use case is MIPS with N32 userspace ABI and toolchain, and that was
also the p
Add the compat_ioctl for operations on /dev/spi* so that 32 bit
userspace applications can access SPI. As far as I can see all data
structure are already prepared for that, so no additional conversion has
to be done.
My use case is MIPS with N32 userspace ABI and toolchain, and that was
also the p
On Wednesday 02 February 2011, Bernhard Walle wrote:
> Add the compat_ioctl for operations on /dev/spi* so that 32 bit
> userspace applications can access SPI. As far as I can see all data
> structure are already prepared for that, so no additional conversion has
> to be done.
>
> My use case is M
From: Bernhard Walle
Add the compat_ioctl for operations on /dev/spi* so that 32 bit
userspace applications can access SPI. As far as I can see all data
structure are already prepared for that, so no additional conversion has
to be done.
My use case is MIPS with N32 userspace ABI and toolchain,
Add the compat_ioctl for operations on /dev/spi* so that 32 bit
userspace applications can access SPI. As far as I can see all data
structure are already prepared for that, so no additional conversion has
to be done.
My use case is MIPS with N32 userspace ABI and toolchain, and that was
also the p
On Wednesday 02 February 2011, Grant Likely wrote:
> On Tue, Feb 01, 2011 at 10:02:46AM +0100, Bernhard Walle wrote:
> > Add the compat_ioctl for operations on /dev/spi* so that 32 bit
> > userspace applications can access SPI. As far as I can see all data
> > structure are already prepared for tha
26 matches
Mail list logo
