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] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 30 Nov 2015 07:51:42 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Peter Ujfalusi <peter.ujfalusi@...com>
Cc:	vinod.koul@...el.com, arnd@...db.de, andy.shevchenko@...il.com,
	linux-mmc@...r.kernel.org, nsekhar@...com,
	linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org,
	dmaengine@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to
 request a channel

Hi,

* Peter Ujfalusi <peter.ujfalusi@...com> [151130 05:49]:
> 
> For each dmaengine driver an array of DMA device, slave and the parameter
> for the filter function needs to be added:
> 
> static struct dma_filter_map da830_edma_map[] = {
> 	DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
> 	DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
> 	DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
> 	DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
> 	DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
> 	DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
> 	DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
> 	DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
> 	DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
> 	DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
> 	DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
> 	DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> };

FYI, if the EDMA_CTRL_CHAN above is just the evtmux registers, those
can be handled with the pinctrl framework. It seems that would allow
leaving out some of the built-in look up data, and have the mux parts
handled by a proper device driver. Below is a sample from the dm81xx
platform for reference.

SoC dtsi file:

evtmux: pinmux@f90 {
	compatible = "pinctrl-single";
	reg = <0xf90 0x40>;
	#address-cells = <1>;
	#size-cells = <0>;
	pinctrl-single,register-width = <8>;
	pinctrl-single,function-mask = <0x1f>;
};

Board specific dts file:

&evtmux {
	sd2_edma_pins: pinmux_sd2_edma_pins {
	pinctrl-single,pins = <
		8 1     /* use SDTXEVT1 for EDMA instead of MCASP0TX */
		9 2     /* use SDRXEVT1 for EDMA instead of MCASP0RX */
		>;
	};
};

Dynamic muxing of these channels can be done too using the pinctrl
framework named modes, but probably is not a good idea in the case of
SD card and MaASP in case something goes wrong :)

Regards,

Tony
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ