linux-kernel - Re: [PATCH] dmaengine: imx-sdma: Add DMA event remapping for imx6sx-sdma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 27 Apr 2015 09:09:34 +0200
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	Nicolin Chen <nicoleotsuka@...il.com>
Cc:	vinod.koul@...el.com, fabio.estevam@...escale.com,
	b38343@...escale.com, robh+dt@...nel.org, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, dan.j.williams@...el.com,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	dmaengine@...r.kernel.org
Subject: Re: [PATCH] dmaengine: imx-sdma: Add DMA event remapping for
 imx6sx-sdma

On Mon, Apr 20, 2015 at 10:34:33AM -0700, Nicolin Chen wrote:
> Hi Sascha,
> 
> Thank you for the comments.
> 
> On Mon, Apr 20, 2015 at 11:45:41AM +0200, Sascha Hauer wrote:
> > On Tue, Apr 14, 2015 at 10:39:11PM -0700, Nicolin Chen wrote:
> > > The SDMA on imx6sx has a few DMA event remapping configurations
> > > inside the GPR (General Purpose Register) of that SoC. When users
> > > want to use a non-default DMA event, they need to configure the
> > > GPR register. So this patch gives an interface of the GPR and
> > > implements it in the SDMA driver so as to finish the DMA event
> > > remapping.
> > > 
> > > Signed-off-by: Nicolin Chen <nicoleotsuka@...il.com>
> 
> > > diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
> > > index dc8d3aa..03315a6 100644
> > > --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
> > > +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
> > > @@ -8,6 +8,7 @@ Required properties:
> > >        "fsl,imx51-sdma"
> > >        "fsl,imx53-sdma"
> > >        "fsl,imx6q-sdma"
> > > +      "fsl,imx6sx-sdma"
> > >    The -to variants should be preferred since they allow to determine the
> > >    correct ROM script addresses needed for the driver to work without additional
> > >    firmware.
> > > @@ -19,6 +20,14 @@ Required properties:
> > >  - fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM
> > >    scripts firmware
> > >  
> > > +Optional properties:
> > > +- fsl, sdma-event-remap : List of one or more DMA event remapping
> > > +  configurations. Its format: <&gpr addr shift val>
> > > +	gpr : the gpr phandle
> > > +	addr : the register address of the GPR
> > > +	shift : the bit shift of the GPR register
> > > +	val : the value of that bit
> > 
> > This binding allows arbitrary register writes to the GPR register space.
> > I don't think we want to allow that. A binding for this if necessary at
> > all must be higher level.
> 
> I was actually wondering where could be the best place to put this in.
> But I couldn't figure out a better place than this driver while being
> worried about the violation as you mentioned.
> 
> But what could be that higher level?

This gpr register effectivly increases the number of event IDs
available by muxing them with existing event IDs. Looking at the SDMA
event mapping table we have:

0 UART6 UART6 Rx FIFO; controlled by IOMUXC register GPR0[0]
1 ADC1 / I2C4 ADC1 DMA request ;Muxed I2C4 DMA event by IOMUXC register GPR0[1]
  ADC1 DMA request
2 IOMUX / CSI2 Muxed with external DMA pad #1, controlled by IOMUXC
  register GPR0[20].
...
47 UART6 UART6 Tx FIFO; controlled by IOMUXC register GPR0[19]

So I would extend that list by additional entries for the muxed dma
events. event 48 then means event 0 alternative, with GPR0[0] set to 1.

BTW. Using defines for the SDMA events like done nowadays for clocks and
other stuff would improve readability, especially when the list of dma
events gets extended by non obvious numbers which do not directly map
to hardware numbers.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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/