On Thu, 23 Dec 2010 20:28:19 -0700, Grant Likely
wrote:
> On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote:
> > I understand your concerns, but I'm not sure how to satisfy them without
> > crippling the design's ability to accomodate my use-case. I can't pass a
> > GPIO line per spi_boa
dw_spi driver in upstream only supports PIO mode, and this patch
will support it to cowork with the Designware dma controller used
on Intel Moorestown platform, at the same time it provides a general
framework to support dw_spi core to cowork with dma controllers on
other platforms
It has been tes
Acked-by: Grant Likely
Signed-off-by: Feng Tang
---
drivers/spi/dw_spi.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/dw_spi.c b/drivers/spi/dw_spi.c
index 25238a8..b50bf5b 100644
--- a/drivers/spi/dw_spi.c
+++ b/drivers/spi/dw_spi.c
@@ -941,7 +941,
The SPI polling loop timeout only works with HZ=100 as the loop was
actually too short.
Also add appropriate cpu_relax() in the busy wait loops...
Acked-by: Grant Likely
Signed-off-by: Arjan van de Ven
Signed-off-by: Alan Cox
---
drivers/spi/dw_spi.c |9 ++---
1 files changed, 6 inser
On Wed, Dec 22, 2010 at 11:13:59PM +0100, Linus Walleij wrote:
> This variable is a bool but defined an int and defined completely
> backwards. This makes the code more readable.
>
> Signed-off-by: Linus Walleij
Merged for -next, thanks.
g.
> ---
> drivers/spi/amba-pl022.c | 24 ++--
On Wed, Dec 22, 2010 at 11:13:48PM +0100, Linus Walleij wrote:
> Signed-off-by: Linus Walleij
Merged for -next, thanks.
g.
> ---
> drivers/spi/amba-pl022.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/spi/amba-pl022.c b/drivers/spi/amba-pl022.c
On Wed, Dec 22, 2010 at 11:13:37PM +0100, Linus Walleij wrote:
> The sglen return by the dma_map_sg() should be passed to the DMA
> engine, not the one passed in. If we one day have a DMA mapper
> that can coalesce entries, this will bug due to a too large
> number of entries being passed in.
>
>
On Wed, Dec 22, 2010 at 11:13:07PM +0100, Linus Walleij wrote:
> The struct device for the DMA engine is the apropriate one to use
> when mapping/unmapping buffers. This is because the memory which
> is addressable by DMA is determined by the DMA engine rather than
> the device.
>
> Reported-by: R
On Mon, Dec 20, 2010 at 10:13 AM, Sebastian Andrzej Siewior
wrote:
> This was fixed by David Lamparter in v2.6.36-rc5 3486008
> ("spi: free children in spi_unregister_master, not siblings") and broken
> again in v2.6.37-rc1~2^2~4 during the merge of 2b9603a0 ("spi: enable
> spi_board_info to be re
On Fri, Dec 24, 2010 at 11:40:50AM +0900, Tomoya MORINAGA wrote:
> It seems spi_topcliff_pch of linux-2.6.37-rc6 degraded by previous patch.
> In fact, data transfer fails on evaluation board testing.
> I found like the following register miss-setting line.
> Using this patch, I have confirmed data
On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote:
> On Thu, 23 Dec 2010 17:37:12 -0700, Grant Likely
> wrote:
> > On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari wrote:
> > > The reason I left this up to the board is it's easy to foresee cases
> > > where you want a non-trivial mapping bet
Sorry, I forget to add "--CCs"
It seems spi_topcliff_pch of linux-2.6.37-rc6 degraded by previous patch.
In fact, data transfer fails on evaluation board testing.
I found like the following register miss-setting line.
Using this patch, I have confirmed data transfer can work well.
Signed-off-by:
It seems spi_topcliff_pch of linux-2.6.37-rc6 degraded by previous patch.
In fact, data transfer fails on evaluation board testing.
I found like the following register miss-setting line.
Using this patch, I have confirmed data transfer can work well.
Signed-off-by: Tomoya MORINAGA
---
drivers/sp
On Thu, 23 Dec 2010 17:37:12 -0700, Grant Likely
wrote:
> On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari wrote:
> > The reason I left this up to the board is it's easy to foresee cases
> > where you want a non-trivial mapping between logical CS numbers and CS
> > pin states. In my case, I using a 2
On Thu, Nov 25, 2010 at 09:05:00AM +0100, Uwe Kleine-König wrote:
> On Thu, Nov 25, 2010 at 12:03:43PM +0800, Jason Wang wrote:
> > It is reasonable, looks fine to me. :-)
> >
> > Jason.
> I'll interpret this as an Ack.
So will I. :-)
applied for -next
g.
-
On Thu, Dec 23, 2010 at 4:09 PM, Ben Gamari wrote:
> On Thu, 23 Dec 2010 14:38:57 -0700, Grant Likely
> wrote:
>> On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari wrote:
>> > This mechanism is in large part stolen from the s3c64xx-spi module. To
>> > use this functionality, one simply must define a
On Tue, Nov 23, 2010 at 05:53:31PM +0800, Feng Tang wrote:
>
>
> On Tue, 23 Nov 2010 14:48:39 +0800
> Linus Walleij wrote:
>
> > This is much better than last time but I still have questions...
> >
> > 2010/11/18 Alan Cox :
> >
> > > + /* 1. Init rx channel */
> > > + rxs = &dw_dm
On Thu, 23 Dec 2010 14:38:57 -0700, Grant Likely
wrote:
> On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari wrote:
> > This mechanism is in large part stolen from the s3c64xx-spi module. To
> > use this functionality, one simply must define a set_level function to
> > set the CS state and a omap2_mcs
On Wed, Nov 24, 2010 at 04:49:47PM -0800, Kevin Hilman wrote:
> Gregory CLEMENT writes:
>
> > As request by Grant Likely, there is no more cover letter. Full changelog
> > is following.
> > I am still reluctant to add this changelog in the patch description, as it
> > adds no value to
> > the p
On Tue, Dec 21, 2010 at 10:56 AM, Ben Gamari wrote:
> This mechanism is in large part stolen from the s3c64xx-spi module. To
> use this functionality, one simply must define a set_level function to
> set the CS state and a omap2_mcspi_csinfo struct for each chip select in
> the board file.
>
> Eac
* Ben Gamari [101221 09:56]:
> This mechanism is in large part stolen from the s3c64xx-spi module. To
> use this functionality, one simply must define a set_level function to
> set the CS state and a omap2_mcspi_csinfo struct for each chip select in
> the board file.
>
> Each spi_board_info.contr
On Thu, Dec 23, 2010 at 12:12:10PM +0100, Richard Genoud wrote:
> The check on cpu_is_mx25 and cpu_is_mx35 was made twice.
> This is obviously wrong.
> Anyway, this patch won't change the previous behaviour which is
> SPI_IMX_VER_0_7 for mx25 and mx35.
>
> Signed-off-by: Richard Genoud
applied,
On Thu, Dec 23, 2010 at 03:29:34PM +0100, Uwe Kleine-König wrote:
> On Thu, Dec 23, 2010 at 12:12:10PM +0100, Richard Genoud wrote:
> > The check on cpu_is_mx25 and cpu_is_mx35 was made twice.
> > This is obviously wrong.
> obviously wrong but no wrong behaviour. Your patch only makes the code
> c
On Thu, Dec 23, 2010 at 12:12:09PM +0100, Richard Genoud wrote:
> On imx25 soc, MX25_INT_CSPI3 is 0
> (cf arch/arm/plat-mxc/include/mach/mx25.h).
> So, the test (spi_imx->irq <= 0) returned an error
> for this platform.
> This patch corrects this behaviour.
>
> Signed-off-by: Richard Genoud
> ---
2010/12/23 Uwe Kleine-König :
> On Thu, Dec 23, 2010 at 12:12:10PM +0100, Richard Genoud wrote:
>> The check on cpu_is_mx25 and cpu_is_mx35 was made twice.
>> This is obviously wrong.
> obviously wrong but no wrong behaviour. Your patch only makes the code
> consistent, but IMHO it doesn't qualify
On Thu, Dec 23, 2010 at 12:12:10PM +0100, Richard Genoud wrote:
> The check on cpu_is_mx25 and cpu_is_mx35 was made twice.
> This is obviously wrong.
obviously wrong but no wrong behaviour. Your patch only makes the code
consistent, but IMHO it doesn't qualify as a bugfix.
> Anyway, this patch wo
Anybody?
Thanks
On Dec 21, 2010, at 11:46 PM, Damjan Marion wrote:
>
>
> Hi,
>
> I'm trying to adopt and clean up driver which is originally written for
> 2.6.24 kernel, and it provides support for SPI on specific ARM system-on-chip
> device.
>
> As this code is never submitted to official
The check on cpu_is_mx25 and cpu_is_mx35 was made twice.
This is obviously wrong.
Anyway, this patch won't change the previous behaviour which is
SPI_IMX_VER_0_7 for mx25 and mx35.
Signed-off-by: Richard Genoud
---
drivers/spi/spi_imx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On imx25 soc, MX25_INT_CSPI3 is 0
(cf arch/arm/plat-mxc/include/mach/mx25.h).
So, the test (spi_imx->irq <= 0) returned an error
for this platform.
This patch corrects this behaviour.
Signed-off-by: Richard Genoud
---
drivers/spi/spi_imx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions
--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC da
30 matches
Mail list logo
