On 29/06/13 04:44, H Hartley Sweeten wrote:
> This inline helper function is only used to determine the bus width
> of the current transfer (8 or 16 bit). Add a bool flag to the private
> structure and set it appropriately for each transfer.
>
> Signed-off-by: H Hartley Swee
always call ep93xx_spi_chip_setup()
> to configure the hardware for each transfer in the message.
>
> Remove the redundant ep93xx_spi_chp_setup() in ep93xx_spi_process_transfer()
> which just initializes the hardware to the "default" based on the SPI
> device.
>
> S
gt;
> Signed-off-by: H Hartley Sweeten
> Cc: Ryan Mallon
> Cc: Mika Westerberg
> Cc: Mark Brown
> Cc: Grant Likely
> ---
> drivers/spi/spi-ep93xx.c | 64
> +++-
> 1 file changed, 20 insertions(+), 44 deletions(-)
>
w much work is needed. I would like some comments from Hartley and
> Ryan also.
I think if we can modify the amba-pl022 driver, without it turning into
a mess, then we should do that. The ep93xx doesn't really see much
attention, so sharing the code base wherever possible should hopefully
ge
On 16/02/11 08:42, Grant Likely wrote:
> On Tue, Feb 15, 2011 at 03:04:49PM +0800, Thomas Chou wrote:
>> Dear Ryan,
>>
>> On 02/14/2011 10:20 AM, Ryan Mallon wrote:
>>> On 02/14/2011 03:10 PM, Thomas Chou wrote:
>>>> This patch adds a new SPI driver t
On 15/02/11 20:04, Thomas Chou wrote:
> Dear Ryan,
>
> On 02/14/2011 10:20 AM, Ryan Mallon wrote:
>> On 02/14/2011 03:10 PM, Thomas Chou wrote:
>>> This patch adds a new SPI driver to support the Altera SOPC Builder
>>> SPI component. It uses the bitbanging libra
ruct spi_bitbang bitbang;
Is this still true? I had a quick look and can't see anything which
relies on spi_bitbang being the first entry. Things like this should be
using container_of so that position in the struct is irrelevant.
~Ryan
--
Bluewater Systems Ltd - ARM Technology
On 11/23/2010 12:20 AM, Mark Brown wrote:
> On Sun, Nov 21, 2010 at 02:31:38PM -0700, Grant Likely wrote:
>> On Sun, Nov 21, 2010 at 1:02 PM, Ryan Mallon wrote:
>
>>> Currently the code will allow you to install
>>> several peripherals at once, which will lead t
spin_unlock(&ti_ssp_lock);
return -ENODEV;
}
ti_ssp.in_use = 0;
spin_unlock(&ti_ssp_lock);
return 0;
}
This way, the ssp core api functions can take struct ti_ssp * as their
first argument (which can still be an opaqu
t;;
> + gpio->chip.owner = THIS_MODULE;
> + gpio->chip.get = value_get;
> + gpio->chip.set = value_set;
> + gpio->chip.direction_input = direction_in;
> + gpio->chip.direction_output = direction_out;
> +
> + error = gpiochip_add(&
of the
drivers which use the TI-SSP core are single function drivers and having
them in the appropriate directory makes them easier to find.
The SSP core driver could either live in drivers/mfd or drivers/misc
atmel-ssc.c is in drivers/misc for example.
~Ryan
--
Bluewater Systems Ltd - ARM Tec
other solution is to use an externally
drivable signal for the frame (such as a gpio), but this is obviously
not possible on some existing hardware.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
r...@bluewatersy
dn't be too
hard to fix. Any idea where the bulk of the time is being spent?
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
r...@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersy
quest_mem_region(res->start, resource_size(res), pdev->name);
> + if (!res) {
> + dev_err(&pdev->dev, "unable to request iomem resources\n");
> + error = -EBUSY;
> + goto fail_put_clock;
> + }
> +
> + espi->regs
Andrew Morton wrote:
> On Thu, 25 Jun 2009 11:59:47 +1200 Ryan Mallon wrote:
>
>
>> Add support for the non JEDEC SST25L SPI Flash devices.
>>
>> Signed-off-by: Andre Renaud
>> Signed-off-by: Ryan Mallon
>> Acked-by: Linus Walleij
>>
>
&g
H Hartley Sweeten wrote:
> On Wednesday, June 24, 2009 7:06 PM, Ryan Mallon wrote:
>> H Hartley Sweeten wrote:
>>> On Sunday, June 21, 2009 8:59 PM, Ryan Mallon wrote:
> I think you could still support the block erase and chip erase internal
> to the driver for performanc
H Hartley Sweeten wrote:
> On Sunday, June 21, 2009 8:59 PM, Ryan Mallon wrote:
>
>> Add support for the non JEDEC SST25L SPI Flash devices.
>>
>> Signed-off-by: Andre Renaud
>> Signed-off-by: Ryan Mallon
>>
>
>
>> +struct fl
Hi Andrew,
It was suggested I send the following patch via you as David Woodhouse
is currently busy.
Thanks,
~Ryan
Add support for the non JEDEC SST25L SPI Flash devices.
Signed-off-by: Andre Renaud
Signed-off-by: Ryan Mallon
Acked-by: Linus Walleij
diff --git a/drivers/mtd
Linus Walleij wrote:
> 2009/6/23 Ryan Mallon :
>
>> BTW, most of my other patches go via the ARM list, which uses the patch
>> system. Whats the procedure for most other lists, do patches just get
>> collected by the subsection maintainer when they are okay?
>
> Tha
Linus Walleij wrote:
> 2009/6/22 Ryan Mallon :
>
>> Out of curiosity: I'm not too clear on what makes a particular chip
>> hot-pluggable. I think technically the sst25l chip could be put onto a
>> hot-pluggable board or power domain. Can't most devices be mad
Updated patch below:
---
Add support for SST25L (non JEDEC) SPI Flash chips
Signed-off-by: Andre Renaud
Signed-off-by: Ryan Mallon
---
diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index 325fab9..c222514 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/
Baruch Siach wrote:
> Hi Ryan,
>
> On Mon, Jun 22, 2009 at 03:58:51PM +1200, Ryan Mallon wrote:
>> +static int sst25l_erase_block(struct sst25l_flash *flash, u32 offset)
>> +{
>> +u8 command[4];
>> +int err;
>> +
>> +err = sst25l_write_
Add support for the non JEDEC SST25L SPI Flash devices.
Signed-off-by: Andre Renaud
Signed-off-by: Ryan Mallon
---
diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index 325fab9..c222514 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -104,6
23 matches
Mail list logo
