| 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
| ||
|
Date: Mon, 17 Aug 2015 09:11:07 +0800
From: Shawn Lin <shawn.lin@...k-chips.com>
To: Heiko Stübner <heiko@...ech.de>
Cc: shawn.lin@...k-chips.com, jh80.chung@...sung.com,
ulf.hansson@...aro.org, Vineet.Gupta1@...opsys.com,
Wei Xu <xuwei5@...ilicon.com>,
Joachim Eastwood <manabian@...il.com>,
Alexey Brodkin <abrodkin@...opsys.com>,
Kukjin Kim <kgene@...nel.org>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Russell King <linux@....linux.org.uk>,
Zhangfei Gao <zhangfei.gao@...aro.org>,
Jun Nie <jun.nie@...aro.org>,
Ralf Baechle <ralf@...ux-mips.org>,
Govindraj Raja <govindraj.raja@...tec.com>,
Arnd Bergmann <arnd@...db.de>, dianders@...omium.org,
linux-samsung-soc@...r.kernel.org, linux-mips@...ux-mips.org,
linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-rockchip@...ts.infradead.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH v5 1/9] mmc: dw_mmc: Add external dma interface
support
在 2015/8/15 6:13, Heiko Stübner 写道:
> Hi Shawn,
>
> Am Freitag, 14. August 2015, 16:34:35 schrieb Shawn Lin:
>> DesignWare MMC Controller can supports two types of DMA
>> mode: external dma and internal dma. We get a RK312x platform
>> integrated dw_mmc and ARM pl330 dma controller. This patch add
>> edmac ops to support these platforms. I've tested it on RK312x
>> platform with edmac mode and RK3288 platform with idmac mode.
>>
>> Signed-off-by: Shawn Lin <shawn.lin@...k-chips.com>
>
> judging by your "from", I guess you're running this on some older Rockchip soc
> without the idma? Because I tried testing this on a Radxa Rock, but only got
> failures, from the start (failed to read card status register). In PIO mode
> everything works again.
>
>
> I guess I overlooked just some tiny detail, but to me the dma channel ids seem
> correct after all. Maybe you have any hints what I'm doing wrong?
>
Thanks, HeiKo.
yes, I'm running a quite older low-end Rockchip soc w/o idma.
Hmm... from your failure to read CSR, I think generic DMA of Radxa Rock
was not runing properly. Your dma channel ids is correct, but it
certainly work on my platform。 I will try to find a Radxa Rock to
re-test my patch ASAP.
> diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
> index 4497d28..92d7156 100644
> --- a/arch/arm/boot/dts/rk3xxx.dtsi
> +++ b/arch/arm/boot/dts/rk3xxx.dtsi
> @@ -217,6 +217,8 @@
> interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>;
> clock-names = "biu", "ciu";
> + dmas = <&dmac2 1>;
> + dma-names = "rx-tx";
> fifo-depth = <256>;
> status = "disabled";
> };
> @@ -227,6 +229,8 @@
> interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cru HCLK_SDIO>, <&cru SCLK_SDIO>;
> clock-names = "biu", "ciu";
> + dmas = <&dmac2 3>;
> + dma-names = "rx-tx";
> fifo-depth = <256>;
> status = "disabled";
> };
> @@ -237,6 +241,8 @@
> interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>;
> clock-names = "biu", "ciu";
> + dmas = <&dmac2 4>;
> + dma-names = "rx-tx";
> fifo-depth = <256>;
> status = "disabled";
> };
>
>
> [...]
>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index fcbf552..e01ead3 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -2517,8 +2642,23 @@ static void dw_mci_cleanup_slot(struct dw_mci_slot
>> *slot, unsigned int id) static void dw_mci_init_dma(struct dw_mci *host)
>> {
>> int addr_config;
>> + int trans_mode;
>> + struct device *dev = host->dev;
>> + struct device_node *np = dev->of_node;
>> +
>> + /* Check tansfer mode */
>> + trans_mode = SDMMC_GET_TRANS_MODE(mci_readl(host, HCON));
>> + if (trans_mode == 0) {
>> + trans_mode = TRANS_MODE_IDMAC;
>> + } else if (trans_mode == 1 || trans_mode == 2) {
>> + trans_mode = TRANS_MODE_EDMAC;
>> + } else {
>> + trans_mode = TRANS_MODE_PIO;
>> + goto no_dma;
>> + }
>> +
>> /* Check ADDR_CONFIG bit in HCON to find IDMAC address bus width */
>> - addr_config = (mci_readl(host, HCON) >> 27) & 0x01;
>> + addr_config = SDMMC_GET_ADDR_CONFIG(mci_readl(host, HCON));
>>
>> if (addr_config == 1) {
>> /* host supports IDMAC in 64-bit address mode */
>
> I guess the idmac address size checking block
>
> /* Check ADDR_CONFIG bit in HCON to find IDMAC address bus width */
> addr_config = SDMMC_GET_ADDR_CONFIG(mci_readl(host, HCON));
>
> if (addr_config == 1) {
> /* host supports IDMAC in 64-bit address mode */
> host->dma_64bit_address = 1;
> dev_info(host->dev, "IDMAC supports 64-bit address mode.\n");
> if (!dma_set_mask(host->dev, DMA_BIT_MASK(64)))
> dma_set_coherent_mask(host->dev, DMA_BIT_MASK(64));
> } else {
> /* host supports IDMAC in 32-bit address mode */
> host->dma_64bit_address = 0;
> dev_info(host->dev, "IDMAC supports 32-bit address mode.\n");
> }
>
> could either live inside the trans_mode == 0 conditional above or get its own
> if (trans_mode == 0) conditional. Either way I guess it should not talk about
> idmac when either pio or extdmac are used.
>
>
> Thanks
> Heiko
>
>
>
--
Shawn Lin
--
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