[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1449649091-9848-1-git-send-email-peter.ujfalusi@ti.com>
Date: Wed, 9 Dec 2015 10:18:09 +0200
From: Peter Ujfalusi <peter.ujfalusi@...com>
To: <vinod.koul@...el.com>, <arnd@...db.de>, <tony@...mide.com>
CC: <linux-arm-kernel@...ts.infradead.org>,
<linux-omap@...r.kernel.org>, <devicetree@...r.kernel.org>,
<balbi@...com>, <linux-kernel@...r.kernel.org>, <nsekhar@...com>
Subject: [PATCH for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit
Hi,
Based on the discussion regarding to (convert am33xx to use the new eDMA
bindings):
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
This two patch will convert the new eDMA binding to not use 16bit arrays for
memcpy channel selection and for marking slots reserved.
The '/bits/ 16' seams to be causing confusion so it is probably better to just
use standard type for the arrays.
The new bindings for the eDMA is introduced for 4.4 and we do not have users of
it, which means that we can still change it w/o the risk of breaking anything
and we do not need to maintain the compatibility with 16bit arrays.
The changes in the eDMA driver is local to the DT parsing and should not
conflict with other changes (like the filter function mapping support). Hrm,
there might be trivial conflict in the include/linux/platform_data/edma.h with
the "dmaengine 'universal' API".
Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches are
going to be handled? I would like to send the updated am33xx/am437x conversion
for 4.5 based on these changes.
Thanks and regards,
Peter
---
Peter Ujfalusi (2):
dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit
type
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit
type
Documentation/devicetree/bindings/dma/ti-edma.txt | 10 ++---
drivers/dma/edma.c | 53 +++++++++++++++--------
include/linux/platform_data/edma.h | 2 +-
3 files changed, 40 insertions(+), 25 deletions(-)
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists