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
>&
: 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
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
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
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/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
it prefix.
Signed-off-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
#inclu
(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
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
--- a
2 platform, 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 Eg
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
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.kerne
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 in
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 broke
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 the
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 12
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 device&#x
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 pxamci_
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
>
supports AVR32, ARM and
>>>>> Intel (ACPI case) platforms.
>>>>>
>>>>> We may do that option invisible to user
>>>> Yup
>>>>> and then use
>>>>>
>>>>> config DW_DMAC
>>>>>
oblem, a STOP will 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
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.
>&g
atch starts to make a lot more sense. 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
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_jif
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
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 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 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
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 tree
&
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, c
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
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 a
width 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
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(-
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)
> This works
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 DesignW
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 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.
>
> A
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 &
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
>> sw
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
> not
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
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, be
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
44 matches
Mail list logo
