Hi Jianpeng Ma,
On 8/1/2013 10:18 AM, majianpeng wrote:
> We found a problem when we removed a working sd card that the irqaction
> of omap_hsmmc can sleep to 3.6s. This cause our watchdog to work.
> In func omap_hsmmc_reset_controller_fsm, it should watch a 0->1
> transition.It used
Hi Jianpeng Ma,
On 8/1/2013 10:18 AM, majianpeng wrote:
We found a problem when we removed a working sd card that the irqaction
of omap_hsmmc can sleep to 3.6s. This cause our watchdog to work.
In func omap_hsmmc_reset_controller_fsm, it should watch a 0-1
transition.It used loops_per_jiffy
e. I
> wonder is this is really what we should be doing though - breaking out
> of the loop, I mean.
So yes, we have to break the loop as the caller is not interested
in processing any further commands.
In i2c/algos/i2c-algo-bit.c, bit_xfer() works exactly the same way:
break the loop
On 7/16/2013 5:03 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 16, 2013 at 04:19:35PM +0800, Hein Tibosch wrote:
>> Hi Vikram,
>>
>> On a OMAP4460, i2c-bus-3:
>>
>> A driver (lm75) is causing many 'timeout waiting for bus ready' errors.
>> SDA rem
ill follow after the
last command.
Thanks, Hein
Signed-off-by: Hein Tibosch
---
drivers/i2c/busses/i2c-omap.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..2f7a712 100644
--- a/drivers/
after the
last command.
Thanks, Hein
Signed-off-by: Hein Tibosch hein_tibo...@yahoo.es
---
drivers/i2c/busses/i2c-omap.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..2f7a712 100644
On 7/16/2013 5:03 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 16, 2013 at 04:19:35PM +0800, Hein Tibosch wrote:
Hi Vikram,
On a OMAP4460, i2c-bus-3:
A driver (lm75) is causing many 'timeout waiting for bus ready' errors.
SDA remains high (as it should), but SCL remains low after a NACK
problem as i2c-omap,
and will need the same change.
Grygorii, if you submit the patch, please add my
Signed-off-by: Hein Tibosch hein_tibo...@yahoo.es
cause you were earlier to notice and fix this problem.
Hein
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi Arnd,
On 7/5/2013 11:51 PM, Arnd Bergmann wrote:
> The em_x270_mci_setpower() and em_x270_usb_hub_init() functions
> call regulator_enable(), which may return an error that must
> be checked.
>
> This changes the em_x270_usb_hub_init() function to bail out
> if it fails, and changes the
Hi Arnd,
On 7/5/2013 11:51 PM, Arnd Bergmann wrote:
The em_x270_mci_setpower() and em_x270_usb_hub_init() functions
call regulator_enable(), which may return an error that must
be checked.
This changes the em_x270_usb_hub_init() function to bail out
if it fails, and changes the
which supports AVR32, ARM and
>>>>> Intel (ACPI case) platforms.
>>>>>
>>>>> We may do that option invisible to user
>>>> Yup
>>>>> and then use
>>>>>
>>>>> config DW_DMAC
>>>>>
, let me if you guys are
okay
As far as I know we have at least one developer (Hein Tibosch) with such
board. Let him share his opinion.
diff --git a/drivers/dma/dw/Kconfig b/drivers/dma/dw/Kconfig
index db2b41f..7be1cf8 100644
--- a/drivers/dma/dw/Kconfig
+++ b/drivers/dma/dw/Kconfig
g the Design Configuration Register 1 information and a capability
> property to actually activate this clear-on-write behavior on ISR.
>
> Reported-by: Hein Tibosch
> Signed-off-by: Nicolas Ferre
> ---
> v2: - use DCFG1 bit 23 integration information instead of device tre
On 5/14/2013 3:49 PM, Michal Simek wrote:
> On 05/14/2013 09:31 AM, Hein Tibosch wrote:
>> On 5/14/2013 3:22 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On May 14, 2013, at 3:18 PM, Hein Tibosch wrote:
>>>
>>>> On 5/14/2013 1:52 PM, Jean-Christophe PLA
On 5/14/2013 3:22 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On May 14, 2013, at 3:18 PM, Hein Tibosch wrote:
>
>> On 5/14/2013 1:52 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 08:58 Tue 14 May , Hein Tibosch wrote:
>>>> On 5/14/2013 12:05 AM, Jean-
On 5/14/2013 1:52 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 08:58 Tue 14 May , Hein Tibosch wrote:
>> On 5/14/2013 12:05 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On May 14, 2013, at 12:05 AM, Nicolas Ferre wrote:
>>>
>>>> Commit 749a2b6
On 5/14/2013 1:52 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 08:58 Tue 14 May , Hein Tibosch wrote:
On 5/14/2013 12:05 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On May 14, 2013, at 12:05 AM, Nicolas Ferre nicolas.fe...@atmel.com wrote:
Commit 749a2b6 (net/macb: clear tx/rx
On 5/14/2013 3:22 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On May 14, 2013, at 3:18 PM, Hein Tibosch hein_tibo...@yahoo.es wrote:
On 5/14/2013 1:52 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 08:58 Tue 14 May , Hein Tibosch wrote:
On 5/14/2013 12:05 AM, Jean-Christophe PLAGNIOL
On 5/14/2013 3:49 PM, Michal Simek wrote:
On 05/14/2013 09:31 AM, Hein Tibosch wrote:
On 5/14/2013 3:22 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On May 14, 2013, at 3:18 PM, Hein Tibosch hein_tibo...@yahoo.es wrote:
On 5/14/2013 1:52 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 08:58
Configuration Register 1 information and a capability
property to actually activate this clear-on-write behavior on ISR.
Reported-by: Hein Tibosch hein_tibo...@yahoo.es
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
v2: - use DCFG1 bit 23 integration information instead of device tree
when using Cadence MACB/GEM and is breaking other platforms.
>> We are using a new Device Tree compatibility string and a capability
>> property to actually activate this clear-on-write behavior on ISR.
>>
>> Reported-by: Hein Tibosch
>> Signed-off-by: Nicolas Fe
using Cadence MACB/GEM and is breaking other platforms.
We are using a new Device Tree compatibility string and a capability
property to actually activate this clear-on-write behavior on ISR.
Reported-by: Hein Tibosch hein_tibo...@yahoo.es
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
can
Hi Andy, Mika,
On 8 Feb 2013, Andy Shevchenko wrote:
> Some of the platform devices rely on the name of their driver to match with.
> In
> the current implementation, if platform id table is needed, they have to add
> the name to the platform id table which sounds alogical. The patch adjustes
Hi Andy, Mika,
On 8 Feb 2013, Andy Shevchenko wrote:
Some of the platform devices rely on the name of their driver to match with.
In
the current implementation, if platform id table is needed, they have to add
the name to the platform id table which sounds alogical. The patch adjustes
the
Hi Andrew,
On 10/24/2012 7:12 AM, Andrew Morton wrote:
> On Sun, 14 Oct 2012 15:54:13 +0800
> Hein Tibosch wrote:
>
>> The dw_dmac was originally developed for avr32 to be used with the Synopsys
>> DesignWare AHB DMA controller. Starting from 2.6.38, access to the devic
Hi Andrew,
On 10/24/2012 7:12 AM, Andrew Morton wrote:
On Sun, 14 Oct 2012 15:54:13 +0800
Hein Tibosch hein_tibo...@yahoo.es wrote:
The dw_dmac was originally developed for avr32 to be used with the Synopsys
DesignWare AHB DMA controller. Starting from 2.6.38, access to the device's
i/o
Hi Andy,
On 10/15/2012 4:08 AM, Andy Shevchenko wrote:
> On Sun, Oct 14, 2012 at 10:54 AM, Hein Tibosch wrote:
>> From: Hein Tibosch
>>
>> The dw_dmac was originally developed for avr32 to be used with the Synopsys
>> DesignWare AHB DMA controller. Starting from 2.6
From: Hein Tibosch
The dw_dmac was originally developed for avr32 to be used with the Synopsys
DesignWare AHB DMA controller. Starting from 2.6.38, access to the device's i/o
memory was done with the little-endian readl/writel functions(1)
This broke the driver for the avr32 platform, because
From: Hein Tibosch hein_tibo...@yahoo.es
The dw_dmac was originally developed for avr32 to be used with the Synopsys
DesignWare AHB DMA controller. Starting from 2.6.38, access to the device's i/o
memory was done with the little-endian readl/writel functions(1)
This broke the driver
Hi Andy,
On 10/15/2012 4:08 AM, Andy Shevchenko wrote:
On Sun, Oct 14, 2012 at 10:54 AM, Hein Tibosch hein_tibo...@yahoo.es wrote:
From: Hein Tibosch hein_tibo...@yahoo.es
The dw_dmac was originally developed for avr32 to be used with the Synopsys
DesignWare AHB DMA controller. Starting from
he
platform data.
I tested the driver on AVR32 with the atmel-mci driver and it all
worked well.
I also tested the new software emulation of LLP mode by setting
nollp for each channel to true. That also worked as expected.
Tested-by: Hein Tibosch
--
To unsubscribe from this list: send the line &
the new software emulation of LLP mode by setting
nollp for each channel to true. That also worked as expected.
Tested-by: Hein Tibosch hein_tibo...@yahoo.es
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On 9/17/2012 3:39 PM, Andy Shevchenko wrote:
> Here is a patchset that allows to adapt the driver to the hardware
> configuration during probe time. The hardware should have the specific
> optional
> parameters enabled. Otherwise the driver will consider values stored in the
> platform data.
>
>
On 9/17/2012 3:39 PM, Andy Shevchenko wrote:
Here is a patchset that allows to adapt the driver to the hardware
configuration during probe time. The hardware should have the specific
optional
parameters enabled. Otherwise the driver will consider values stored in the
platform data.
On 9/3/2012 4:59 PM, Viresh Kumar wrote:
> On 3 September 2012 14:19, Andy Shevchenko wrote:
>> On Mon, Sep 3, 2012 at 11:30 AM, Viresh Kumar
>> wrote:
>>> Which register are you talking about? This configuration is outside of DMAC
>>> controller and i am not sure if dw DMAC controller can do
On 9/3/2012 4:59 PM, Viresh Kumar wrote:
On 3 September 2012 14:19, Andy Shevchenko andy.shevche...@gmail.com wrote:
On Mon, Sep 3, 2012 at 11:30 AM, Viresh Kumar viresh.ku...@linaro.org
wrote:
Which register are you talking about? This configuration is outside of DMAC
controller and i am
From: Hein Tibosch
v4: now based and tested on 3.6-rc4
The dw_dmac driver was earlier adapted to do 64-bit transfers on the memory
side (see https://lkml.org/lkml/2012/1/18/52)
This works on ARM platforms but for AVR32 (AP700x) the maximum allowed transfer
size is 32-bits.
This patch allows
v3 was based and tested on 3.5.2. the patches didn't apply
to the latest kernel because dw_dmac.c has had some changes since then.
Now it is based and tested on linux-3.6-rc4
From: Hein Tibosch
v4: now based and tested on 3.6-rc4
After some recent changes to dw_dmac, the driver got broken
From: Hein Tibosch
v4: now based and tested on 3.6-rc4
The MCI makes use of the dw_dmac driver when DMA is being used.
Due to recent changes to dw_dmac the MCI+DMA driver was broken because:
- a patch in dw_dmac allowed for 64-bit transfers on the memory side, giving
an illegal value of 3
From: Hein Tibosch
v4: now based and tested on 3.6-rc4
The dw_dmac was originally developed for avr32 to be used with the Synopsys
DesignWare AHB DMA controller. After 2.6.38, access to the device's i/o
memory was done with the little-endian readl/writel functions
(https://patchwork.kernel.org
From: Hein Tibosch hein_tibo...@yahoo.es
v4: now based and tested on 3.6-rc4
The dw_dmac was originally developed for avr32 to be used with the Synopsys
DesignWare AHB DMA controller. After 2.6.38, access to the device's i/o
memory was done with the little-endian readl/writel functions
(https
From: Hein Tibosch hein_tibo...@yahoo.es
v4: now based and tested on 3.6-rc4
The MCI makes use of the dw_dmac driver when DMA is being used.
Due to recent changes to dw_dmac the MCI+DMA driver was broken because:
- a patch in dw_dmac allowed for 64-bit transfers on the memory side, giving
v3 was based and tested on 3.5.2. the patches didn't apply
to the latest kernel because dw_dmac.c has had some changes since then.
Now it is based and tested on linux-3.6-rc4
From: Hein Tibosch hein_tibo...@yahoo.es
v4: now based and tested on 3.6-rc4
After some recent changes to dw_dmac
From: Hein Tibosch hein_tibo...@yahoo.es
v4: now based and tested on 3.6-rc4
The dw_dmac driver was earlier adapted to do 64-bit transfers on the memory
side (see https://lkml.org/lkml/2012/1/18/52)
This works on ARM platforms but for AVR32 (AP700x) the maximum allowed transfer
size is 32-bits
to
limit the size.
Allowable values are:
#define DW_MEM_WIDTH_64 0 /* default */
#define DW_MEM_WIDTH_32 1 /* e.g. for avr32 */
Signed-off-by: Hein Tibosch
Acked-by: Viresh Kumar
---
drivers/dma/dw_dmac.c | 10 +++---
include/linux/dw_dmac.h |3 +++
2 files
, because it needs native-endian
(i.e. big-endian) accessors.
This patch makes the endianness configurable using 'DW_DMAC_BIG_ENDIAN_IO',
which will default be true for AVR32
Signed-off-by: Hein Tibosch
Acked-by: Viresh Kumar
Acked-by: Arnd Bergmann
Reviewed-by: Hans-Christian Egtvedt
---
drivers
register
Signed-off-by: Hein Tibosch
Acked-by: Hans-Christian Egtvedt
---
arch/avr32/mach-at32ap/at32ap700x.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c
b/arch/avr32/mach-at32ap/at32ap700x.c
index 0445c4f..7250c70 100644
(ARM platform), nothing will change and no code has
to be adapted.
The small patch for Atmel (at32ap700x.c) is included here because of its
dependency on the second dw_dmac patch.
Thanks to all for reviewing, both people from Atmel and Linaro
Hein Tibosch (3):
dw_dmac: make driver endianness
-by: Hein Tibosch
---
lib/decompress.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/decompress.c b/lib/decompress.c
index 3d766b7..31a8042 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#ifndef
On 8/31/2012 12:26 PM, Viresh Kumar wrote:
> BTW, Ideally speaking the fix for AVR32 which will enable 32bit mem
> support and enable BIG endian support should have been part of this
> patchset. That code can go through DMA tree as these patches are
> very closely related. Otherwise now you have
On 8/31/2012 12:26 PM, Viresh Kumar wrote:
BTW, Ideally speaking the fix for AVR32 which will enable 32bit mem
support and enable BIG endian support should have been part of this
patchset. That code can go through DMA tree as these patches are
very closely related. Otherwise now you have to
-by: Hein Tibosch hein_tibo...@yahoo.es
---
lib/decompress.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/decompress.c b/lib/decompress.c
index 3d766b7..31a8042 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -14,6 +14,7 @@
#include linux/types.h
(ARM platform), nothing will change and no code has
to be adapted.
The small patch for Atmel (at32ap700x.c) is included here because of its
dependency on the second dw_dmac patch.
Thanks to all for reviewing, both people from Atmel and Linaro
Hein Tibosch (3):
dw_dmac: make driver endianness
register
Signed-off-by: Hein Tibosch hein_tibo...@yahoo.es
Acked-by: Hans-Christian Egtvedt egtv...@samfundet.no
---
arch/avr32/mach-at32ap/at32ap700x.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c
b/arch/avr32/mach-at32ap
, because it needs native-endian
(i.e. big-endian) accessors.
This patch makes the endianness configurable using 'DW_DMAC_BIG_ENDIAN_IO',
which will default be true for AVR32
Signed-off-by: Hein Tibosch hein_tibo...@yahoo.es
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Acked-by: Arnd Bergmann
to
limit the size.
Allowable values are:
#define DW_MEM_WIDTH_64 0 /* default */
#define DW_MEM_WIDTH_32 1 /* e.g. for avr32 */
Signed-off-by: Hein Tibosch hein_tibo...@yahoo.es
Acked-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/dma/dw_dmac.c | 10
for reviewing
Hein Tibosch (2):
drivers/dma/Kconfig| 11 +++
drivers/dma/dw_dmac.c | 10 +++---
drivers/dma/dw_dmac_regs.h | 14 ++
include/linux/dw_dmac.h|3 +++
4 files changed, 35 insertions(+), 3 deletions(-)
--
--
To unsubscribe from this list: send
the size.
Allowable values are:
#define DW_MEM_WIDTH_64 0
#define DW_MEM_WIDTH_32 1 /* e.g. for avr32 */
Signed-off-by: Hein Tibosch
---
drivers/dma/dw_dmac.c | 10 +++---
include/linux/dw_dmac.h |3 +++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git
.
This patch makes the endianness configurable using 'DW_DMAC_BIG_ENDIAN_IO',
which will default be true for AVR32
Signed-off-by: Hein Tibosch
---
drivers/dma/Kconfig| 11 +++
drivers/dma/dw_dmac_regs.h | 14 ++
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git
-by: Hein Tibosch
---
arch/avr32/mach-at32ap/at32ap700x.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c
b/arch/avr32/mach-at32ap/at32ap700x.c
index 0445c4f..7250c70 100644
--- a/arch/avr32/mach-at32ap/at32ap700x.c
+++ b/arch/avr32/mach
-by: Hein Tibosch hein_tibo...@yahoo.es
---
arch/avr32/mach-at32ap/at32ap700x.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c
b/arch/avr32/mach-at32ap/at32ap700x.c
index 0445c4f..7250c70 100644
--- a/arch/avr32/mach-at32ap/at32ap700x.c
.
This patch makes the endianness configurable using 'DW_DMAC_BIG_ENDIAN_IO',
which will default be true for AVR32
Signed-off-by: Hein Tibosch hein_tibo...@yahoo.es
---
drivers/dma/Kconfig| 11 +++
drivers/dma/dw_dmac_regs.h | 14 ++
2 files changed, 25 insertions(+), 0
the size.
Allowable values are:
#define DW_MEM_WIDTH_64 0
#define DW_MEM_WIDTH_32 1 /* e.g. for avr32 */
Signed-off-by: Hein Tibosch hein_tibo...@yahoo.es
---
drivers/dma/dw_dmac.c | 10 +++---
include/linux/dw_dmac.h |3 +++
2 files changed, 10 insertions(+), 3
for reviewing
Hein Tibosch (2):
drivers/dma/Kconfig| 11 +++
drivers/dma/dw_dmac.c | 10 +++---
drivers/dma/dw_dmac_regs.h | 14 ++
include/linux/dw_dmac.h|3 +++
4 files changed, 35 insertions(+), 3 deletions(-)
--
--
To unsubscribe from this list: send
On 8/28/2012 11:23 AM, Viresh Kumar wrote:
> On 27 August 2012 20:28, Hein Tibosch wrote:
>>>> +config DW_DMAC_MEM_64_BIT
>>>> +bool "Allow 64-bit memory transfers"
>>>> +default y if !AVR32
>>>> +depends on DW_DMAC
>&
On 8/28/2012 11:23 AM, Viresh Kumar wrote:
On 27 August 2012 20:28, Hein Tibosch hein_tibo...@yahoo.es wrote:
+config DW_DMAC_MEM_64_BIT
+bool Allow 64-bit memory transfers
+default y if !AVR32
+depends on DW_DMAC
+help
+ Say yes if the DMA controller may do 64-bit
On 8/27/2012 7:14 PM, Hans-Christian Egtvedt wrote:
> Around Mon 27 Aug 2012 16:47:40 +0800 or thereabout, Hein Tibosch wrote:
>> On 8/27/2012 3:03 PM, Hans-Christian Egtvedt wrote:
>>> Brushing up the config items:
>>>
>>> +config DW_DMAC_BIG_ENDIAN_IO
>&
On 8/27/2012 3:03 PM, Hans-Christian Egtvedt wrote:
> I think the English in kconfig could use some brushing up.
>
>> +config DW_DMAC_BE
>
>
> This name isn't that long, so we could skip the abbreviation of big endian;
> DW_DMAC_BIG_ENDIAN_IO or something similar?
>
>> +bool "Synopsys
On 8/27/2012 11:47 AM, Viresh Kumar wrote:
> On 27 August 2012 02:11, Hein Tibosch <mailto:hein_tibo...@yahoo.es>> wrote:
>
> The dw_dmac driver was earlier adapted to do 64-bit transfers
> on the memory side (https://lkml.org/lkml/2012/1/18/52)
> Thi
On 8/27/2012 11:47 AM, Viresh Kumar wrote:
On 27 August 2012 02:11, Hein Tibosch hein_tibo...@yahoo.es
mailto:hein_tibo...@yahoo.es wrote:
The dw_dmac driver was earlier adapted to do 64-bit transfers
on the memory side (https://lkml.org/lkml/2012/1/18/52)
This works on ARM
On 8/27/2012 3:03 PM, Hans-Christian Egtvedt wrote:
I think the English in kconfig could use some brushing up.
+config DW_DMAC_BE
This name isn't that long, so we could skip the abbreviation of big endian;
DW_DMAC_BIG_ENDIAN_IO or something similar?
+bool Synopsys DesignWare AHB DMA
On 8/27/2012 7:14 PM, Hans-Christian Egtvedt wrote:
Around Mon 27 Aug 2012 16:47:40 +0800 or thereabout, Hein Tibosch wrote:
On 8/27/2012 3:03 PM, Hans-Christian Egtvedt wrote:
Brushing up the config items:
+config DW_DMAC_BIG_ENDIAN_IO
+ bool Use big endian I/O register access
.
This patch makes the endianness configurable using 'DW_DMAC_BE',
which will default be true for AVR32
Signed-off-by: Hein Tibosch
---
drivers/dma/Kconfig|8
drivers/dma/dw_dmac_regs.h | 23 +++
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git
limits value for
SRC/DST_TR_WID register
Signed-off-by: Hein Tibosch
---
arch/avr32/mach-at32ap/at32ap700x.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c
b/arch/avr32/mach-at32ap/at32ap700x.c
index 0445c4f..e7202af 100644
--- a/arch
the size.
Allowable values for dw_dma_slave::max_mem_width are:
0 : leave it up to dw_dmac (64 bits)
1 : 16-bits
2 : 32-bits
Signed-off-by: Hein Tibosch
---
drivers/dma/dw_dmac.c |8
include/linux/dw_dmac.h |3 +++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git
configurable through Kconfig,
for AVR32 it will become big-endian
2. making the maximum memory transfer width configurable
It can be set in the code within arch
For non-avr32 (ARM) platforms, nothing has to be changed.
Thanks to Viresh and Arnd for reviewing
Hein Tibosch (2):
dw_dmac: make
configurable through Kconfig,
for AVR32 it will become big-endian
2. making the maximum memory transfer width configurable
It can be set in the code within arch
For non-avr32 (ARM) platforms, nothing has to be changed.
Thanks to Viresh and Arnd for reviewing
Hein Tibosch (2):
dw_dmac: make
the size.
Allowable values for dw_dma_slave::max_mem_width are:
0 : leave it up to dw_dmac (64 bits)
1 : 16-bits
2 : 32-bits
Signed-off-by: Hein Tibosch hein_tibo...@yahoo.es
---
drivers/dma/dw_dmac.c |8
include/linux/dw_dmac.h |3 +++
2 files changed, 11 insertions(+), 0
limits value for
SRC/DST_TR_WID register
Signed-off-by: Hein Tibosch hein_tibo...@yahoo.es
---
arch/avr32/mach-at32ap/at32ap700x.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c
b/arch/avr32/mach-at32ap/at32ap700x.c
index 0445c4f
.
This patch makes the endianness configurable using 'DW_DMAC_BE',
which will default be true for AVR32
Signed-off-by: Hein Tibosch hein_tibo...@yahoo.es
---
drivers/dma/Kconfig|8
drivers/dma/dw_dmac_regs.h | 23 +++
2 files changed, 31 insertions(+), 0
On 8/21/2012 10:15 PM, Havard Skinnemoen wrote:
> On Tue, Aug 21, 2012 at 1:31 AM, Arnd Bergmann
> wrote:
>> On Tuesday 21 August 2012, Viresh Kumar wrote:
Is AVR32 a big-endian system? Probably big-endian, that's why values are
> getting
> swapped. And dw_dmac is the standard one,
On 8/21/2012 10:15 PM, Havard Skinnemoen wrote:
On Tue, Aug 21, 2012 at 1:31 AM, Arnd Bergmann arnd.bergm...@linaro.org
wrote:
On Tuesday 21 August 2012, Viresh Kumar wrote:
Is AVR32 a big-endian system? Probably big-endian, that's why values are
getting
swapped. And dw_dmac is the standard
On 8/21/2012 5:05 PM, Arnd Bergmann wrote:
> It should be easy to tell from the object code whether this happened
> or not. If it did, then we can investigate why gcc did that, otherwise
> something else caused the strange byte swap.
>
> The safe way to define the readl() function in asm/io.h is
On 8/21/2012 2:35 PM, Viresh Kumar wrote:
> On 21 August 2012 11:42, Hein Tibosch <mailto:hein_tibo...@yahoo.es>> wrote:
>
> On 8/21/2012 12:42 PM, viresh kumar wrote:
> > A!! Firstly we can't use __raw* for architectures >= ARMv6. It is
>
other the lists with the first preparations of this
patch.
> On Sun, Aug 19, 2012 at 9:36 PM, Hein Tibosch wrote:
>> dw_dmac:
>> - After 2.6.39, the registers were accessed using readl/writel
>> in stead of the __raw_readl and __raw_writel causing a 16-bit
>> swap of
with the first preparations of this
patch.
On Sun, Aug 19, 2012 at 9:36 PM, Hein Tibosch hein_tibo...@yahoo.es wrote:
dw_dmac:
- After 2.6.39, the registers were accessed using readl/writel
in stead of the __raw_readl and __raw_writel causing a 16-bit
swap of all values (little endian access
On 8/21/2012 2:35 PM, Viresh Kumar wrote:
On 21 August 2012 11:42, Hein Tibosch hein_tibo...@yahoo.es
mailto:hein_tibo...@yahoo.es wrote:
On 8/21/2012 12:42 PM, viresh kumar wrote:
A!! Firstly we can't use __raw* for architectures = ARMv6. It is
not
only for endianess
On 8/21/2012 5:05 PM, Arnd Bergmann wrote:
It should be easy to tell from the object code whether this happened
or not. If it did, then we can investigate why gcc did that, otherwise
something else caused the strange byte swap.
The safe way to define the readl() function in asm/io.h is to
88 matches
Mail list logo
