Thread (16 messages) 16 messages, 4 authors, 2008-12-11

Re: [PATCH 2/4 v2] i.MX31: Image Processing Unit DMA and IRQ drivers

From: Guennadi Liakhovetski <hidden>
Date: 2008-12-10 13:49:22
Also in: lkml

On Wed, 10 Dec 2008, Dmitry Krivoschekov wrote:
Hi,

Guennadi Liakhovetski wrote:
quoted
From: Guennadi Liakhovetski <redacted>

i.MX3x SoCs contain an Image Processing Unit, consisting of a Control
Module (CM), Display Interface (DI), Synchronous Display Controller (SDC),
Asynchronous Display Controller (ADC), Image Converter (IC), Post-Filter
(PF), Camera Sensor Interface (CSI), and an Image DMA Controller (IDMAC).
CM contains, among other blocks, an Interrupt Generator (IG) and a Clock
and Reset Control Unit (CRCU). This driver serves IDMAC and IG. They are
supported over dmaengine and irq-chip APIs respectively.

IDMAC is a specialised DMA controller, its DMA channels cannot be used for
general-purpose operations, even though it might be possible to configure
a memory-to-memory channel for memcpy operation. This driver will not work
with generic dmaengine clients, clients, wishing to use it must use
respective wrapper structures, they also must specify which channels they
require, as channels are hard-wired to specific IPU functions.

Signed-off-by: Guennadi Liakhovetski <redacted>
---
 arch/arm/plat-mxc/include/mach/ipu.h  |  180 ++++
 arch/arm/plat-mxc/include/mach/mx31.h |  139 +++-
 drivers/mfd/Kconfig                   |   16 +
 drivers/mfd/Makefile                  |    4 +-
 drivers/mfd/ipu/Makefile              |    5 +
 drivers/mfd/ipu/ipu_idmac.c           | 1617 +++++++++++++++++++++++++++++++++
 drivers/mfd/ipu/ipu_intern.h          |  172 ++++
 drivers/mfd/ipu/ipu_irq.c             |  277 ++++++
why do you think drivers/mfd is an appropriate location for this driver?
IPU is on-chip device, but it is not a separate multifunction device so
it should not be placed in drivers/mfd.

arch/arm/plat-mxc/ or drivers/video/ipu seem better places for this driver.
I am not sure drivers/mxc is the best place for it, but I am against both 
arch/arm (well, mildly, it is now preferred to put arch-specific drivers 
under drivers/) and drivers/video - I'm going to submit a camera driver 
shortly, which goes under drivers/media/video and will use the ipu driver, 
and should not depend on drivers/video. I was thinking about 
drivers/media/ipu... But eventually decided for mfd as it is 
multifunctional (no, it is not separate, is this a requirement?) - it is 
currently providing an IRQ and a DMA driver. But I don't use the mfd API 
atm. If we decide to keep it there, I can add it, if necessary / if it 
provides any advantages for this case.

In general, I am open to ideas in this respect.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help