* [PATCH 0/3] arm64/clk: update Marvell Armada CP110 system controller driver
From: Thomas Petazzoni @ 2016-12-13 12:41 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This small set of commits updates the Marvell Armada CP110 system
controller driver, its Device Tree binding, and Device Tree
representation, to take into account two new things:
- The clock driver now handles clock n?9 (GOP) as a child of clock
n?18 (controls SD/MMC and GOP)
- The DT representation is adjusted to name clock n?18 "sd-mmc-gop"
instead of just "sd-mmc".
This set of commits is some preparation work to add networking support
for Marvell Armada 7K/8K.
I would expect patches 1 and 2 to be taken by the clock maintainers,
and patch 3 be taken by the Marvell EBU maintainers.
Thanks,
Thomas
Thomas Petazzoni (3):
dt-bindings: arm: update Armada CP110 system controller binding
clk: mvebu: adjust clock handling for the CP110 system controller
arm64: dts: marvell: adjust name of sd-mmc-gop clock in syscon
.../devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 6 +++---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 2 +-
drivers/clk/mvebu/cp110-system-controller.c | 6 ++++--
4 files changed, 9 insertions(+), 7 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] dt-bindings: arm: update Armada CP110 system controller binding
From: Thomas Petazzoni @ 2016-12-13 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481632880-9198-1-git-send-email-thomas.petazzoni@free-electrons.com>
It turns out that in the CP110 HW block present in Marvell Armada
7K/8K SoCs, gatable clock n?18 not only controls SD/MMC, but also the
GOP block. This commit updates the Device Tree binding for this piece
of hardware accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
.../devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
index 30c5469..07dbb35 100644
--- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
@@ -45,7 +45,7 @@ The following clocks are available:
- 1 15 SATA
- 1 16 SATA USB
- 1 17 Main
- - 1 18 SD/MMC
+ - 1 18 SD/MMC/GOP
- 1 21 Slow IO (SPI, NOR, BootROM, I2C, UART)
- 1 22 USB3H0
- 1 23 USB3H1
@@ -65,7 +65,7 @@ Required properties:
"cpm-audio", "cpm-communit", "cpm-nand", "cpm-ppv2", "cpm-sdio",
"cpm-mg-domain", "cpm-mg-core", "cpm-xor1", "cpm-xor0", "cpm-gop-dp", "none",
"cpm-pcie_x10", "cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor", "cpm-sata",
- "cpm-sata-usb", "cpm-main", "cpm-sd-mmc", "none", "none", "cpm-slow-io",
+ "cpm-sata-usb", "cpm-main", "cpm-sd-mmc-gop", "none", "none", "cpm-slow-io",
"cpm-usb3h0", "cpm-usb3h1", "cpm-usb3dev", "cpm-eip150", "cpm-eip197";
Example:
@@ -78,6 +78,6 @@ Example:
gate-clock-output-names = "cpm-audio", "cpm-communit", "cpm-nand", "cpm-ppv2", "cpm-sdio",
"cpm-mg-domain", "cpm-mg-core", "cpm-xor1", "cpm-xor0", "cpm-gop-dp", "none",
"cpm-pcie_x10", "cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor", "cpm-sata",
- "cpm-sata-usb", "cpm-main", "cpm-sd-mmc", "none", "none", "cpm-slow-io",
+ "cpm-sata-usb", "cpm-main", "cpm-sd-mmc-gop", "none", "none", "cpm-slow-io",
"cpm-usb3h0", "cpm-usb3h1", "cpm-usb3dev", "cpm-eip150", "cpm-eip197";
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] clk: mvebu: adjust clock handling for the CP110 system controller
From: Thomas Petazzoni @ 2016-12-13 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481632880-9198-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds support for the GOP_DP gatable clock found in the
CP110 system controller. This clock is controlled by bit 9, and has
clock 18 as its parent. Therefore, clock 18 is in fact not only
controlling SD/MMC, but also GOP, but it is renamed as SD_MMC_GOP
accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/clk/mvebu/cp110-system-controller.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mvebu/cp110-system-controller.c b/drivers/clk/mvebu/cp110-system-controller.c
index f2303da..3c91cab 100644
--- a/drivers/clk/mvebu/cp110-system-controller.c
+++ b/drivers/clk/mvebu/cp110-system-controller.c
@@ -66,6 +66,7 @@ enum {
#define CP110_GATE_SDIO 4
#define CP110_GATE_XOR1 7
#define CP110_GATE_XOR0 8
+#define CP110_GATE_GOP_DP 9
#define CP110_GATE_PCIE_X1_0 11
#define CP110_GATE_PCIE_X1_1 12
#define CP110_GATE_PCIE_X4 13
@@ -73,7 +74,7 @@ enum {
#define CP110_GATE_SATA 15
#define CP110_GATE_SATA_USB 16
#define CP110_GATE_MAIN 17
-#define CP110_GATE_SDMMC 18
+#define CP110_GATE_SDMMC_GOP 18
#define CP110_GATE_SLOW_IO 21
#define CP110_GATE_USB3H0 22
#define CP110_GATE_USB3H1 23
@@ -309,9 +310,10 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
parent = ppv2_name;
break;
case CP110_GATE_SDIO:
+ case CP110_GATE_GOP_DP:
of_property_read_string_index(np,
"gate-clock-output-names",
- CP110_GATE_SDMMC, &parent);
+ CP110_GATE_SDMMC_GOP, &parent);
break;
case CP110_GATE_XOR1:
case CP110_GATE_XOR0:
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: marvell: adjust name of sd-mmc-gop clock in syscon
From: Thomas Petazzoni @ 2016-12-13 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481632880-9198-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adjusts the names of gatable clock #18 of the Marvell Armada
CP110 system controller. This clock not only controls SD/MMC, but also
the GOP (Group Of Ports) used for networking. So the clock is renamed to
{cpm,cps}-sd-mmc-gop instead of {cpm,cps}-sd-mmc.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index 602e2c2..895babc 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -74,7 +74,7 @@
"cpm-gop-dp", "none", "cpm-pcie_x10",
"cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor",
"cpm-sata", "cpm-sata-usb", "cpm-main",
- "cpm-sd-mmc", "none", "none",
+ "cpm-sd-mmc-gop", "none", "none",
"cpm-slow-io", "cpm-usb3h0", "cpm-usb3h1",
"cpm-usb3dev", "cpm-eip150", "cpm-eip197";
};
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 6bf9e24..db99646 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -74,7 +74,7 @@
"cps-gop-dp", "none", "cps-pcie_x10",
"cps-pcie_x11", "cps-pcie_x4", "cps-pcie-xor",
"cps-sata", "cps-sata-usb", "cps-main",
- "cps-sd-mmc", "none", "none",
+ "cps-sd-mmc-gop", "none", "none",
"cps-slow-io", "cps-usb3h0", "cps-usb3h1",
"cps-usb3dev", "cps-eip150", "cps-eip197";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v4 8/9] PM / Domains: Support IRQ safe PM domains
From: Geert Uytterhoeven @ 2016-12-13 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477347668-41901-9-git-send-email-lina.iyer@linaro.org>
Hi Lina,
On Tue, Oct 25, 2016 at 12:21 AM, Lina Iyer <lina.iyer@linaro.org> wrote:
> Generic Power Domains currently support turning on/off only in process
> context. This prevents the usage of PM domains for domains that could be
> powered on/off in a context where IRQs are disabled. Many such domains
> exist today and do not get powered off, when the IRQ safe devices in
> that domain are powered off, because of this limitation.
>
> However, not all domains can operate in IRQ safe contexts. Genpd
> therefore, has to support both cases where the domain may or may not
> operate in IRQ safe contexts. Configuring genpd to use an appropriate
> lock for that domain, would allow domains that have IRQ safe devices to
> runtime suspend and resume, in atomic context.
>
> To achieve domain specific locking, set the domain's ->flag to
> GENPD_FLAG_IRQ_SAFE while defining the domain. This indicates that genpd
> should use a spinlock instead of a mutex for locking the domain. Locking
> is abstracted through genpd_lock() and genpd_unlock() functions that use
> the flag to determine the appropriate lock to be used for that domain.
>
> Domains that have lower latency to suspend and resume and can operate
> with IRQs disabled may now be able to save power, when the component
> devices and sub-domains are idle at runtime.
>
> The restriction this imposes on the domain hierarchy is that non-IRQ
> safe domains may not have IRQ-safe subdomains, but IRQ safe domains may
> have IRQ safe and non-IRQ safe subdomains and devices.
>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Kevin Hilman <khilman@kernel.org>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/base/power/domain.c | 111 ++++++++++++++++++++++++++++++++++++++++----
> include/linux/pm_domain.h | 10 +++-
> 2 files changed, 110 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 1ad42f2..07ed835 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -74,11 +74,70 @@ static const struct genpd_lock_ops genpd_mtx_ops = {
> +static inline bool irq_safe_dev_in_no_sleep_domain(struct device *dev,
> + struct generic_pm_domain *genpd)
> +{
> + bool ret;
> +
> + ret = pm_runtime_is_irq_safe(dev) && !genpd_is_irq_safe(genpd);
> +
> + /* Warn once for each IRQ safe dev in no sleep domain */
This comment is not correct, as dev_warn_once() will print the warning once,
not once per device. Hence users will not be informed if there are multiple
IRQ safe devices.
> + if (ret)
> + dev_warn_once(dev, "PM domain %s will not be powered off\n",
> + genpd->name);
BTW, I'm seeing messages like:
sh_cmt ffca0000.timer: PM domain always-on will not be powered off
and
sh_cmt e6138000.timer: PM domain c5 will not be powered off
on various Renesas SoCs, and wanted to know if there was more than one
IRQ safe device preventing a PM domain power down (answer: there isn't).
Note that the above are OK, as both "always-on" and "c5" are always-on
PM domains.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ARM: dts: vexpress: Support GICC_DIR operations
From: Marc Zyngier @ 2016-12-13 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <903fb243-7ab1-211f-e29f-27ab00a4aa01@arm.com>
On 13/12/16 12:16, Sudeep Holla wrote:
>
>
> On 12/12/16 17:35, Marc Zyngier wrote:
>> [+Sudeep]
>>
>> On 10/12/16 20:13, Christoffer Dall wrote:
>>> The GICv2 CPU interface registers span across 8K, not 4K as indicated in
>>> the DT. Only the GICC_DIR register is located after the initial 4K
>>> boundary, leaving a functional system but without support for separately
>>> EOI'ing and deactivating interrupts.
>>>
>>> After this change the system support split priority drop and interrupt
>>> deactivation.
>>>
>>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>>> ---
>>> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
>>> index 0205c97..2e0cf39 100644
>>> --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
>>> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
>>> @@ -126,7 +126,7 @@
>>> #address-cells = <0>;
>>> interrupt-controller;
>>> reg = <0 0x2c001000 0 0x1000>,
>>> - <0 0x2c002000 0 0x1000>,
>>> + <0 0x2c002000 0 0x2000>,
>>> <0 0x2c004000 0 0x2000>,
>>> <0 0x2c006000 0 0x2000>;
>>> interrupts = <1 9 0xf04>;
>>>
>>
>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>
>
> Thanks Marc, I see couple of other instances of this like tc2 and rtsm
> model on arm64. Do they need to be fixed too ? I guess so. If so I will
> fixup this to patch add tc1. And add another one for rtsm.
Yes, that'd be good.
> Also I see loads of gic-400 compatible dts(mainly rockchip and renasas)
> having just 4k. Are they left like this intentionally ? I remember you
> fixing most of the DTS when you found this issue initially.
I still have these patches stashed somewhere (I remember sunxi being one
of the offender as well). I also need to come up with a software
workaround enabling the 8kB region with the old DT (because it is likely
that KVM will stop working on them if we merge Christoffer's timer patches).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 3/9] ARM: dts: dra72: Add separate dtsi for tps65917
From: Lokesh Vutla @ 2016-12-13 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <045e8200-69bd-8590-1da4-96235444db4c@ti.com>
On Tuesday 13 December 2016 06:10 PM, Roger Quadros wrote:
> +Tomi, Kishon, Carlos
>
> Hi,
>
> On 21/10/16 13:38, Lokesh Vutla wrote:
>> dra72-evm-common.dtsi consolidates dra72-evm.dts and dra72-evm-revc.dts
>> which also include tps65917 pmic support as both the evms uses the same
>> pmic. But, dra71-evm has mostly similar features with a different pmic.
>> In order to exploit dra72-evm-common.dtsi, creating a separate dtsi
>> for tps65915 support and including it in respective board files.
>>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> ---
>> arch/arm/boot/dts/dra72-evm-common.dtsi | 128 ----------------------------
>> arch/arm/boot/dts/dra72-evm-revc.dts | 21 +++--
>> arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 134 ++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/dra72-evm.dts | 14 ++--
>> 4 files changed, 154 insertions(+), 143 deletions(-)
>> create mode 100644 arch/arm/boot/dts/dra72-evm-tps65917.dtsi
>>
>
> This patch breaks USB XHCI and boot on dra72-evm (both revC and non revC)
>
> I'll explain why below.
>
> [ 13.625167] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> [ 13.632557] pgd = ede10000
> [ 13.635390] [00000000] *pgd=00000000
> [ 13.639145] Internal error: : 1406 [#1] SMP ARM
> [ 13.643893] Modules linked in: xhci_plat_hcd(+) xhci_hcd usbcore omapfb dwc3 cfbfillrect snd_soc_davinci_mcasp cfbimgblt cfbcopyarea udc_core connector_hdmi encoder_tpd12s015 snd_soc_edma m25p80 snd_soc_simpe
> [ 13.695557] CPU: 0 PID: 440 Comm: modprobe Not tainted 4.9.0-rc1 #1050
> [ 13.702399] Hardware name: Generic DRA72X (Flattened Device Tree)
> [ 13.708786] task: edb5c040 task.stack: edd10000
> [ 13.713540] PC is at _raw_spin_unlock_irqrestore+0x0/0x44
> [ 13.719219] LR is at xhci_hub_control+0xc2c/0x15e0 [xhci_hcd]
> [ 13.725242] pc : [<c07df718>] lr : [<bf486300>] psr: a0000093
> [ 13.725242] sp : edd118c0 ip : c0e306b4 fp : 00000000
> [ 13.737278] r10: 00000000 r9 : 60000013 r8 : edf28218
> [ 13.742753] r7 : edf28000 r6 : 00000000 r5 : 00000000 r4 : edf2a000
> [ 13.749593] r3 : 00000000 r2 : 00000000 r1 : 60000013 r0 : edf28218
Hmm.. Thanks for catching it. I remember it was booting when I tested,
not sure how I missed this :(. usb2_phy1 & 2, mmc and dss supplies needs
to be added in dra72-evm-tps65917.dtsi file.
Tony,
Do you want me to resend this patch or fixup patch on top of this?
Thanks and regards,
Lokesh
^ permalink raw reply
* [PATCH 0/9] dmaengine: stm32-dma: Bug fixes and improvements series
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds bug fixes reported by devices using STM32 DMA and some
improvements mainly linked to dmaengine framework evolution.
M'boumba Cedric Madianga (9):
dmaengine: stm32-dma: Set correct args number for DMA request from DT
dmaengine: stm32-dma: Fix typo in Kconfig
dt-bindings: stm32-dma: Fix typo regarding DMA client binding
dmaengine: stm32-dma: Fix null pointer dereference in stm32_dma_tx_status
dmaengine: stm32-dma: Rework starting transfer management
dmaengine: stm32-dma: Fix residue computation issue in cyclic mode
dmaengine: stm32-dma: Add error messages if xlate fails
dmaengine: stm32-dma: Add synchronization support
dmaengine: stm32-dma: Add max_burst support
.../devicetree/bindings/dma/stm32-dma.txt | 5 +-
drivers/dma/Kconfig | 2 +-
drivers/dma/stm32-dma.c | 103 +++++++++++++--------
3 files changed, 66 insertions(+), 44 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/9] dmaengine: stm32-dma: Set correct args number for DMA request from DT
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-1-git-send-email-cedric.madianga@gmail.com>
This patch sets the right number of arguments to be used for DMA clients
which request channels from DT.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
---
drivers/dma/stm32-dma.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 3688d08..a884b85 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -972,21 +972,18 @@ static struct dma_chan *stm32_dma_of_xlate(struct of_phandle_args *dma_spec,
struct stm32_dma_chan *chan;
struct dma_chan *c;
- if (dma_spec->args_count < 3)
+ if (dma_spec->args_count < 4)
return NULL;
cfg.channel_id = dma_spec->args[0];
cfg.request_line = dma_spec->args[1];
cfg.stream_config = dma_spec->args[2];
- cfg.threshold = 0;
+ cfg.threshold = dma_spec->args[3];
if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) || (cfg.request_line >=
STM32_DMA_MAX_REQUEST_ID))
return NULL;
- if (dma_spec->args_count > 3)
- cfg.threshold = dma_spec->args[3];
-
chan = &dmadev->chan[cfg.channel_id];
c = dma_get_slave_channel(&chan->vchan.chan);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/9] dmaengine: stm32-dma: Fix typo in Kconfig
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-1-git-send-email-cedric.madianga@gmail.com>
As STM32 DMA driver is only used as buit-in driver, it couldn't be used as
module.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 263495d..96da57a 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -458,7 +458,7 @@ config STM32_DMA
help
Enable support for the on-chip DMA controller on STMicroelectronics
STM32 MCUs.
- If you have a board based on such a MCU and wish to use DMA say Y or M
+ If you have a board based on such a MCU and wish to use DMA say Y
here.
config S3C24XX_DMAC
--
1.9.1
^ permalink raw reply related
* [PATCH 3/9] dt-bindings: stm32-dma: Fix typo regarding DMA client binding
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-1-git-send-email-cedric.madianga@gmail.com>
Only four cells are required for dma client binding not five.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
---
Documentation/devicetree/bindings/dma/stm32-dma.txt | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt b/Documentation/devicetree/bindings/dma/stm32-dma.txt
index 70cd13f..4408af6 100644
--- a/Documentation/devicetree/bindings/dma/stm32-dma.txt
+++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt
@@ -40,8 +40,7 @@ Example:
DMA clients connected to the STM32 DMA controller must use the format
described in the dma.txt file, using a five-cell specifier for each
-channel: a phandle plus four integer cells.
-The four cells in order are:
+channel: a phandle to the DMA controller plus the following four integer cells:
1. The channel id
2. The request line number
@@ -61,7 +60,7 @@ The four cells in order are:
0x1: medium
0x2: high
0x3: very high
-5. A 32bit mask specifying the DMA FIFO threshold configuration which are device
+4. A 32bit mask specifying the DMA FIFO threshold configuration which are device
dependent:
-bit 0-1: Fifo threshold
0x0: 1/4 full FIFO
--
1.9.1
^ permalink raw reply related
* [PATCH 4/9] dmaengine: stm32-dma: Fix null pointer dereference in stm32_dma_tx_status
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-1-git-send-email-cedric.madianga@gmail.com>
chan->desc is always set to NULL when a DMA transfer is complete.
As a DMA transfer could be complete during the call of stm32_dma_tx_status,
we need to be sure that chan->desc is not NULL before using this variable
to avoid a null pointer deference issue.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
---
drivers/dma/stm32-dma.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index a884b85..3056ce7 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -880,7 +880,7 @@ static enum dma_status stm32_dma_tx_status(struct dma_chan *c,
struct virt_dma_desc *vdesc;
enum dma_status status;
unsigned long flags;
- u32 residue;
+ u32 residue = 0;
status = dma_cookie_status(c, cookie, state);
if ((status == DMA_COMPLETE) || (!state))
@@ -888,16 +888,12 @@ static enum dma_status stm32_dma_tx_status(struct dma_chan *c,
spin_lock_irqsave(&chan->vchan.lock, flags);
vdesc = vchan_find_desc(&chan->vchan, cookie);
- if (cookie == chan->desc->vdesc.tx.cookie) {
+ if (chan->desc && cookie == chan->desc->vdesc.tx.cookie)
residue = stm32_dma_desc_residue(chan, chan->desc,
chan->next_sg);
- } else if (vdesc) {
+ else if (vdesc)
residue = stm32_dma_desc_residue(chan,
to_stm32_dma_desc(vdesc), 0);
- } else {
- residue = 0;
- }
-
dma_set_residue(state, residue);
spin_unlock_irqrestore(&chan->vchan.lock, flags);
--
1.9.1
^ permalink raw reply related
* [PATCH 5/9] dmaengine: stm32-dma: Rework starting transfer management
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-1-git-send-email-cedric.madianga@gmail.com>
This patch reworks the way to manage transfer starting.
Now, starting DMA is only allowed when the channel is not busy.
Then, stm32_dma_start_transfer is declared as void.
At least, after each transfer completion, we start the next transfer if a
new descriptor as been queued in the issued list during an ongoing
transfer.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
---
drivers/dma/stm32-dma.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 3056ce7..adb846c 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -421,7 +421,7 @@ static void stm32_dma_dump_reg(struct stm32_dma_chan *chan)
dev_dbg(chan2dev(chan), "SFCR: 0x%08x\n", sfcr);
}
-static int stm32_dma_start_transfer(struct stm32_dma_chan *chan)
+static void stm32_dma_start_transfer(struct stm32_dma_chan *chan)
{
struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
struct virt_dma_desc *vdesc;
@@ -432,12 +432,12 @@ static int stm32_dma_start_transfer(struct stm32_dma_chan *chan)
ret = stm32_dma_disable_chan(chan);
if (ret < 0)
- return ret;
+ return;
if (!chan->desc) {
vdesc = vchan_next_desc(&chan->vchan);
if (!vdesc)
- return -EPERM;
+ return;
chan->desc = to_stm32_dma_desc(vdesc);
chan->next_sg = 0;
@@ -471,7 +471,7 @@ static int stm32_dma_start_transfer(struct stm32_dma_chan *chan)
chan->busy = true;
- return 0;
+ dev_dbg(chan2dev(chan), "vchan %p: started\n", &chan->vchan);
}
static void stm32_dma_configure_next_sg(struct stm32_dma_chan *chan)
@@ -552,15 +552,13 @@ static void stm32_dma_issue_pending(struct dma_chan *c)
{
struct stm32_dma_chan *chan = to_stm32_dma_chan(c);
unsigned long flags;
- int ret;
spin_lock_irqsave(&chan->vchan.lock, flags);
- if (!chan->busy) {
- if (vchan_issue_pending(&chan->vchan) && !chan->desc) {
- ret = stm32_dma_start_transfer(chan);
- if ((!ret) && (chan->desc->cyclic))
- stm32_dma_configure_next_sg(chan);
- }
+ if (vchan_issue_pending(&chan->vchan) && !chan->desc && !chan->busy) {
+ dev_dbg(chan2dev(chan), "vchan %p: issued\n", &chan->vchan);
+ stm32_dma_start_transfer(chan);
+ if (chan->desc->cyclic)
+ stm32_dma_configure_next_sg(chan);
}
spin_unlock_irqrestore(&chan->vchan.lock, flags);
}
--
1.9.1
^ permalink raw reply related
* [PATCH 6/9] dmaengine: stm32-dma: Fix residue computation issue in cyclic mode
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-1-git-send-email-cedric.madianga@gmail.com>
This patch resolves the residue computation issue detected in cyclic mode.
Now, in cyclic mode, we increment next_sg variable as soon as a period is
transferred instead of after pushing a new sg request.
Then, we take into account that after transferring a complete buffer,
the next_sg variable is equal to 0.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
---
drivers/dma/stm32-dma.c | 39 ++++++++++++++++++++++++++-------------
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index adb846c..ba929a9 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -500,8 +500,6 @@ static void stm32_dma_configure_next_sg(struct stm32_dma_chan *chan)
dev_dbg(chan2dev(chan), "CT=0 <=> SM1AR: 0x%08x\n",
stm32_dma_read(dmadev, STM32_DMA_SM1AR(id)));
}
-
- chan->next_sg++;
}
}
@@ -510,6 +508,7 @@ static void stm32_dma_handle_chan_done(struct stm32_dma_chan *chan)
if (chan->desc) {
if (chan->desc->cyclic) {
vchan_cyclic_callback(&chan->desc->vdesc);
+ chan->next_sg++;
stm32_dma_configure_next_sg(chan);
} else {
chan->busy = false;
@@ -846,26 +845,40 @@ static struct dma_async_tx_descriptor *stm32_dma_prep_dma_memcpy(
return vchan_tx_prep(&chan->vchan, &desc->vdesc, flags);
}
+static u32 stm32_dma_get_remaining_bytes(struct stm32_dma_chan *chan)
+{
+ u32 dma_scr, width, ndtr;
+ struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
+
+ dma_scr = stm32_dma_read(dmadev, STM32_DMA_SCR(chan->id));
+ width = STM32_DMA_SCR_PSIZE_GET(dma_scr);
+ ndtr = stm32_dma_read(dmadev, STM32_DMA_SNDTR(chan->id));
+
+ return ndtr << width;
+}
+
static size_t stm32_dma_desc_residue(struct stm32_dma_chan *chan,
struct stm32_dma_desc *desc,
u32 next_sg)
{
- struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
- u32 dma_scr, width, residue, count;
+ u32 residue = 0;
int i;
- residue = 0;
+ /*
+ * In cyclic mode, for the last period, residue = remaining bytes from
+ * NDTR
+ */
+ if (chan->desc->cyclic && next_sg == 0)
+ return stm32_dma_get_remaining_bytes(chan);
+ /*
+ * For all other periods in cyclic mode, and in sg mode,
+ * residue = remaining bytes from NDTR + remaining periods/sg to be
+ * transferred
+ */
for (i = next_sg; i < desc->num_sgs; i++)
residue += desc->sg_req[i].len;
-
- if (next_sg != 0) {
- dma_scr = stm32_dma_read(dmadev, STM32_DMA_SCR(chan->id));
- width = STM32_DMA_SCR_PSIZE_GET(dma_scr);
- count = stm32_dma_read(dmadev, STM32_DMA_SNDTR(chan->id));
-
- residue += count << width;
- }
+ residue += stm32_dma_get_remaining_bytes(chan);
return residue;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 7/9] dmaengine: stm32-dma: Add error messages if xlate fails
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-1-git-send-email-cedric.madianga@gmail.com>
This patch adds some error messages when a slave device fails to request a
channel.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
---
drivers/dma/stm32-dma.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index ba929a9..35639f6 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -975,27 +975,36 @@ static struct dma_chan *stm32_dma_of_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma)
{
struct stm32_dma_device *dmadev = ofdma->of_dma_data;
+ struct device *dev = dmadev->ddev.dev;
struct stm32_dma_cfg cfg;
struct stm32_dma_chan *chan;
struct dma_chan *c;
- if (dma_spec->args_count < 4)
+ if (dma_spec->args_count < 4) {
+ dev_err(dev, "Bad number of cells\n");
return NULL;
+ }
cfg.channel_id = dma_spec->args[0];
cfg.request_line = dma_spec->args[1];
cfg.stream_config = dma_spec->args[2];
cfg.threshold = dma_spec->args[3];
- if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) || (cfg.request_line >=
- STM32_DMA_MAX_REQUEST_ID))
+ if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) ||
+ (cfg.request_line >= STM32_DMA_MAX_REQUEST_ID)) {
+ dev_err(dev, "Bad channel and/or request id\n");
return NULL;
+ }
chan = &dmadev->chan[cfg.channel_id];
c = dma_get_slave_channel(&chan->vchan.chan);
- if (c)
- stm32_dma_set_config(chan, &cfg);
+ if (!c) {
+ dev_err(dev, "No more channel avalaible\n");
+ return NULL;
+ }
+
+ stm32_dma_set_config(chan, &cfg);
return c;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 8/9] dmaengine: stm32-dma: Add synchronization support
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-1-git-send-email-cedric.madianga@gmail.com>
Implement the new device_synchronize() callback to allow proper
synchronization when stopping a channel.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
---
drivers/dma/stm32-dma.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 35639f6..b7be43a 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -403,6 +403,13 @@ static int stm32_dma_terminate_all(struct dma_chan *c)
return 0;
}
+static void stm32_dma_synchronize(struct dma_chan *c)
+{
+ struct stm32_dma_chan *chan = to_stm32_dma_chan(c);
+
+ vchan_synchronize(&chan->vchan);
+}
+
static void stm32_dma_dump_reg(struct stm32_dma_chan *chan)
{
struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
@@ -1068,6 +1075,7 @@ static int stm32_dma_probe(struct platform_device *pdev)
dd->device_prep_dma_cyclic = stm32_dma_prep_dma_cyclic;
dd->device_config = stm32_dma_slave_config;
dd->device_terminate_all = stm32_dma_terminate_all;
+ dd->device_synchronize = stm32_dma_synchronize;
dd->src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
--
1.9.1
^ permalink raw reply related
* [PATCH 9/9] dmaengine: stm32-dma: Add max_burst support
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-1-git-send-email-cedric.madianga@gmail.com>
This patch sets the max_burst value supported by the STM32 DMA
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
---
drivers/dma/stm32-dma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index b7be43a..49f86ca 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -114,6 +114,7 @@
#define STM32_DMA_MAX_CHANNELS 0x08
#define STM32_DMA_MAX_REQUEST_ID 0x08
#define STM32_DMA_MAX_DATA_PARAM 0x03
+#define STM32_DMA_MAX_BURST 16
enum stm32_dma_width {
STM32_DMA_BYTE,
@@ -1084,6 +1085,7 @@ static int stm32_dma_probe(struct platform_device *pdev)
BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
dd->directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
dd->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+ dd->max_burst = STM32_DMA_MAX_BURST;
dd->dev = &pdev->dev;
INIT_LIST_HEAD(&dd->channels);
--
1.9.1
^ permalink raw reply related
* [RFC v2 PATCH 0/3] Fix dma_alloc_coherent() and friends for NOMMU
From: Vladimir Murzin @ 2016-12-13 13:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
It seem that addition of cache support for M-class cpus uncovered
latent bug in DMA usage. NOMMU memory model has been treated as being
always consistent; however, for R/M classes of cpu memory can be
covered by MPU which in turn might configure RAM as Normal
i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
friends, since data can stuck in caches now or be buffered.
This patch set is trying to address the issue by providing region of
memory suitable for consistent DMA operations. It is supposed that such
region is marked by MPU as non-cacheable. Since we have MPU support in
Linux for R-class only and M-class setting MPU in bootloader, proposed
interface to advertise such memory is via "memdma=size at start" command
line option, to avoid clashing with normal memory (which usually comes
from dts) it'd be safer to use it together with "mem=" command line
option. Meanwhile, I'm open to suggestions for the better way telling
Linux of such memory.
For configuration without cache support (like Cortex-M3/M4) dma
operations are forced to be coherent and wired with dma-noop. Such
decision is made based on cacheid global variable. In case cpu
supports caches and no coherent memory region is given - dma is
disallowed. Probably, some other important checks are missing, so I'll
all my ears :)
To make life easier NOMMU dma operations are kept in separate
compilation unit.
Thanks!
Changelog:
RFC v1 -> RFC v2
- s/dmac_unmap_area/dmac_map_area in __dma_page_cpu_to_dev()
- removed unrelated changes in nommu.c
Vladimir Murzin (3):
ARM: NOMMU: introduce dma operations for noMMU
ARM: NOMMU: set ARM_DMA_MEM_BUFFERABLE for M-class cpus
ARM: dma-mapping: remove traces of NOMMU code
arch/arm/include/asm/dma-mapping.h | 3 +-
arch/arm/mm/Kconfig | 2 +-
arch/arm/mm/Makefile | 5 +-
arch/arm/mm/dma-mapping-nommu.c | 262 ++++++++++++++++++++++++++++++++++++
arch/arm/mm/dma-mapping.c | 26 +---
arch/arm/mm/mm.h | 3 +
arch/arm/mm/nommu.c | 6 +
7 files changed, 278 insertions(+), 29 deletions(-)
create mode 100644 arch/arm/mm/dma-mapping-nommu.c
--
1.7.9.5
^ permalink raw reply
* [RFC v2 PATCH 1/3] ARM: NOMMU: introduce dma operations for noMMU
From: Vladimir Murzin @ 2016-12-13 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636704-18948-1-git-send-email-vladimir.murzin@arm.com>
R/M classes of cpus can have momory covered by MPU which in turn might
configure RAM as Normal i.e. bufferable and cacheable. It breaks
dma_alloc_coherent() and friends, since data can stuck in caches now
or be buffered.
This patch introduces the way to specify region of memory (via
"memdma=size at start" command line option) suitable for consistent DMA
operations. It is supposed that such region is marked by MPU as
non-cacheable.
For configuration without cache support (like Cortex-M3/M4) dma
operations are forced to be coherent and wired with dma-noop. Such
decision is made based on cacheid global variable. In case cpu
supports caches and no coherent memory region is given - dma is
disallowed.
Reported-by: Alexandre Torgue <alexandre.torgue@st.com>
Reported-by: Andras Szemzo <sza@esh.hu>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/dma-mapping.h | 3 +-
arch/arm/mm/Makefile | 5 +-
arch/arm/mm/dma-mapping-nommu.c | 262 ++++++++++++++++++++++++++++++++++++
arch/arm/mm/mm.h | 3 +
arch/arm/mm/nommu.c | 6 +
5 files changed, 275 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/mm/dma-mapping-nommu.c
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index bf02dbd..559faad 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -20,7 +20,8 @@ static inline struct dma_map_ops *__generic_dma_ops(struct device *dev)
{
if (dev && dev->archdata.dma_ops)
return dev->archdata.dma_ops;
- return &arm_dma_ops;
+
+ return IS_ENABLED(CONFIG_MMU) ? &arm_dma_ops : &dma_noop_ops;
}
static inline struct dma_map_ops *get_dma_ops(struct device *dev)
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 2ac7988..5796357 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -2,9 +2,8 @@
# Makefile for the linux arm-specific parts of the memory manager.
#
-obj-y := dma-mapping.o extable.o fault.o init.o \
- iomap.o
-
+obj-y := extable.o fault.o init.o iomap.o
+obj-y += dma-mapping$(MMUEXT).o
obj-$(CONFIG_MMU) += fault-armv.o flush.o idmap.o ioremap.o \
mmap.o pgd.o mmu.o pageattr.o
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
new file mode 100644
index 0000000..f92d98a
--- /dev/null
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -0,0 +1,262 @@
+/*
+ * Based on linux/arch/arm/mm/dma-mapping.c
+ *
+ * Copyright (C) 2000-2004 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * DMA uncached mapping support.
+ */
+
+#include <linux/export.h>
+#include <linux/mm.h>
+#include <linux/dma-mapping.h>
+#include <linux/scatterlist.h>
+#include <linux/genalloc.h>
+
+#include <asm/cachetype.h>
+#include <asm/cacheflush.h>
+#include <asm/outercache.h>
+
+#include "dma.h"
+
+unsigned long dma_start __initdata;
+unsigned long dma_size __initdata;
+
+static struct gen_pool *dma_pool;
+
+static void *arm_nommu_dma_alloc(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp,
+ unsigned long attrs)
+{
+ void *ptr;
+
+ if (!dma_pool)
+ return NULL;
+
+ ptr = (void *)gen_pool_alloc(dma_pool, size);
+ if (ptr) {
+ *dma_handle = __pa(ptr);
+ dmac_flush_range(ptr, ptr + size);
+ outer_flush_range(__pa(ptr), __pa(ptr) + size);
+ }
+
+ return ptr;
+}
+
+static void arm_nommu_dma_free(struct device *dev, size_t size,
+ void *cpu_addr, dma_addr_t dma_addr,
+ unsigned long attrs)
+{
+ gen_pool_free(dma_pool, (unsigned long)cpu_addr, size);
+}
+
+static void __dma_page_cpu_to_dev(dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ dmac_map_area(__va(handle), size, dir);
+
+ if (dir == DMA_FROM_DEVICE)
+ outer_inv_range(handle, handle + size);
+ else
+ outer_clean_range(handle, handle + size);
+}
+
+static void __dma_page_dev_to_cpu(dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ if (dir != DMA_TO_DEVICE) {
+ outer_inv_range(handle, handle + size);
+ dmac_unmap_area(__va(handle), size, dir);
+ }
+}
+
+static dma_addr_t arm_nommu_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ dma_addr_t handle = page_to_phys(page) + offset;
+
+ __dma_page_cpu_to_dev(handle, size, dir);
+
+ return handle;
+}
+
+static void arm_nommu_dma_unmap_page(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ __dma_page_dev_to_cpu(handle, size, dir);
+}
+
+
+static int arm_nommu_dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ int i;
+ struct scatterlist *sg;
+
+ for_each_sg(sgl, sg, nents, i) {
+ sg_dma_address(sg) = sg_phys(sg);
+ sg_dma_len(sg) = sg->length;
+ __dma_page_cpu_to_dev(sg_dma_address(sg), sg_dma_len(sg), dir);
+ }
+
+ return nents;
+}
+
+static void arm_nommu_dma_unmap_sg(struct device *dev, struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir, unsigned long attrs)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, nents, i)
+ __dma_page_dev_to_cpu(sg_dma_address(sg), sg_dma_len(sg), dir);
+}
+
+static void arm_nommu_dma_sync_single_for_device(struct device *dev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ __dma_page_cpu_to_dev(handle, size, dir);
+}
+
+static void arm_nommu_dma_sync_single_for_cpu(struct device *dev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ __dma_page_cpu_to_dev(handle, size, dir);
+}
+
+static void arm_nommu_dma_sync_sg_for_device(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, nents, i)
+ __dma_page_cpu_to_dev(sg_dma_address(sg), sg_dma_len(sg), dir);
+}
+
+static void arm_nommu_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, nents, i)
+ __dma_page_dev_to_cpu(sg_dma_address(sg), sg_dma_len(sg), dir);
+}
+
+struct dma_map_ops arm_nommu_dma_ops = {
+ .alloc = arm_nommu_dma_alloc,
+ .free = arm_nommu_dma_free,
+ .map_page = arm_nommu_dma_map_page,
+ .unmap_page = arm_nommu_dma_unmap_page,
+ .map_sg = arm_nommu_dma_map_sg,
+ .unmap_sg = arm_nommu_dma_unmap_sg,
+ .sync_single_for_device = arm_nommu_dma_sync_single_for_device,
+ .sync_single_for_cpu = arm_nommu_dma_sync_single_for_cpu,
+ .sync_sg_for_device = arm_nommu_dma_sync_sg_for_device,
+ .sync_sg_for_cpu = arm_nommu_dma_sync_sg_for_cpu,
+};
+EXPORT_SYMBOL(arm_nommu_dma_ops);
+
+static struct dma_map_ops *arm_nommu_get_dma_map_ops(bool coherent)
+{
+ return coherent ? &dma_noop_ops : &arm_nommu_dma_ops;
+}
+
+void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
+ const struct iommu_ops *iommu, bool coherent)
+{
+ struct dma_map_ops *dma_ops;
+
+ /*
+ * Cahe support for v7m is optional, so can be treated as
+ * coherent if no cache has been detected.
+ */
+ dev->archdata.dma_coherent = (cacheid) ? coherent : true;
+
+ dma_ops = arm_nommu_get_dma_map_ops(dev->archdata.dma_coherent);
+
+ set_dma_ops(dev, dma_ops);
+}
+
+void arch_teardown_dma_ops(struct device *dev)
+{
+}
+
+int dma_supported(struct device *dev, u64 mask)
+{
+ if (cacheid && !dma_pool)
+ return 0;
+
+ return 1;
+}
+
+EXPORT_SYMBOL(dma_supported);
+
+#define PREALLOC_DMA_DEBUG_ENTRIES 4096
+
+static int __init dma_debug_do_init(void)
+{
+ dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
+ return 0;
+}
+core_initcall(dma_debug_do_init);
+
+/*
+ * Initialise the coherent pool for DMA allocations.
+ */
+static int __init dma_pool_init(void)
+{
+ int ret;
+
+ if (cacheid && !dma_size) {
+ pr_warn("DMA: coherent memory region has not been given.\n");
+ return 0;
+ }
+
+ dma_pool = gen_pool_create(PAGE_SHIFT, -1);
+
+ if (!dma_pool)
+ goto out;
+
+ ret = gen_pool_add_virt(dma_pool, (unsigned long)dma_start, (unsigned long)dma_start,
+ dma_size, -1);
+ if (ret)
+ goto destroy_genpool;
+
+ gen_pool_set_algo(dma_pool, gen_pool_first_fit_order_align, NULL);
+
+ pr_info("DMA: coherent memory region 0x%lx - 0x%lx (%lu KiB)\n",
+ dma_start, dma_start + dma_size, dma_size >> 10);
+
+ return 0;
+
+destroy_genpool:
+ gen_pool_destroy(dma_pool);
+ dma_pool = NULL;
+out:
+ pr_err("DMA: failed to allocate coherent memory region\n");
+ return -ENOMEM;
+}
+
+postcore_initcall(dma_pool_init);
+
+/* "memdma=<size>@<address>" parsing. */
+static int __init early_memdma(char *p)
+{
+ if (!p)
+ return -EINVAL;
+
+ dma_size = memparse(p, &p);
+ if (*p == '@')
+ dma_start = memparse(p + 1, &p);
+
+ return 0;
+}
+early_param("memdma", early_memdma);
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index ce727d4..18eb869 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -97,3 +97,6 @@ struct static_vm {
void dma_contiguous_remap(void);
unsigned long __clear_cr(unsigned long mask);
+
+extern unsigned long dma_start __initdata;
+extern unsigned long dma_size __initdata;
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 681cec8..5827e54 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -303,6 +303,12 @@ void __init sanity_check_meminfo(void)
end = memblock_end_of_DRAM();
high_memory = __va(end - 1) + 1;
memblock_set_current_limit(end);
+
+ if (dma_size &&
+ memblock_overlaps_region(&memblock.memory, dma_start, dma_size)) {
+ pr_crit("DMA: coherent memory region overlaps with main memory.\n");
+ dma_size = 0;
+ }
}
/*
--
1.7.9.5
^ permalink raw reply related
* [RFC v2 PATCH 2/3] ARM: NOMMU: set ARM_DMA_MEM_BUFFERABLE for M-class cpus
From: Vladimir Murzin @ 2016-12-13 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636704-18948-1-git-send-email-vladimir.murzin@arm.com>
Now, we have dedicated non-cacheable region for consistent DMA
operations. However, that region can still be marked as bufferable by
MPU, so it'd be safer to have barriers by default.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/mm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 6dffbe4..7f0000d 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -1023,7 +1023,7 @@ config ARM_L1_CACHE_SHIFT
config ARM_DMA_MEM_BUFFERABLE
bool "Use non-cacheable memory for DMA" if (CPU_V6 || CPU_V6K) && !CPU_V7
- default y if CPU_V6 || CPU_V6K || CPU_V7
+ default y if CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7M
help
Historically, the kernel has used strongly ordered mappings to
provide DMA coherent memory. With the advent of ARMv7, mapping
--
1.7.9.5
^ permalink raw reply related
* [RFC v2 PATCH 3/3] ARM: dma-mapping: remove traces of NOMMU code
From: Vladimir Murzin @ 2016-12-13 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636704-18948-1-git-send-email-vladimir.murzin@arm.com>
DMA operations for NOMMU case have been just factored out into
separate compilation unit, so don't keep dead code.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/mm/dma-mapping.c | 26 ++------------------------
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ab77100..d8a755b 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -344,8 +344,6 @@ static void __dma_free_buffer(struct page *page, size_t size)
}
}
-#ifdef CONFIG_MMU
-
static void *__alloc_from_contiguous(struct device *dev, size_t size,
pgprot_t prot, struct page **ret_page,
const void *caller, bool want_vaddr,
@@ -646,22 +644,6 @@ static inline pgprot_t __get_dma_pgprot(unsigned long attrs, pgprot_t prot)
return prot;
}
-#define nommu() 0
-
-#else /* !CONFIG_MMU */
-
-#define nommu() 1
-
-#define __get_dma_pgprot(attrs, prot) __pgprot(0)
-#define __alloc_remap_buffer(dev, size, gfp, prot, ret, c, wv) NULL
-#define __alloc_from_pool(size, ret_page) NULL
-#define __alloc_from_contiguous(dev, size, prot, ret, c, wv, coherent_flag) NULL
-#define __free_from_pool(cpu_addr, size) do { } while (0)
-#define __free_from_contiguous(dev, page, cpu_addr, size, wv) do { } while (0)
-#define __dma_free_remap(cpu_addr, size) do { } while (0)
-
-#endif /* CONFIG_MMU */
-
static void *__alloc_simple_buffer(struct device *dev, size_t size, gfp_t gfp,
struct page **ret_page)
{
@@ -803,7 +785,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
if (cma)
buf->allocator = &cma_allocator;
- else if (nommu() || is_coherent)
+ else if (is_coherent)
buf->allocator = &simple_allocator;
else if (allowblock)
buf->allocator = &remap_allocator;
@@ -852,8 +834,7 @@ static int __arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
- int ret = -ENXIO;
-#ifdef CONFIG_MMU
+ int ret;
unsigned long nr_vma_pages = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long pfn = dma_to_pfn(dev, dma_addr);
@@ -868,7 +849,6 @@ static int __arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
vma->vm_end - vma->vm_start,
vma->vm_page_prot);
}
-#endif /* CONFIG_MMU */
return ret;
}
@@ -887,9 +867,7 @@ int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
-#ifdef CONFIG_MMU
vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
-#endif /* CONFIG_MMU */
return __arm_dma_mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v6] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Dave Martin @ 2016-12-13 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481632529-24218-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Dec 13, 2016 at 12:35:29PM +0000, Ard Biesheuvel wrote:
> Currently, we allow kernel mode NEON in softirq or hardirq context by
> stacking and unstacking a slice of the NEON register file for each call
> to kernel_neon_begin() and kernel_neon_end(), respectively.
>
> Given that
> a) a CPU typically spends most of its time in userland, during which time
> no kernel mode NEON in process context is in progress,
> b) a CPU spends most of its time in the kernel doing other things than
> kernel mode NEON when it gets interrupted to perform kernel mode NEON
> in softirq context
>
> the stacking and subsequent unstacking is only necessary if we are
> interrupting a thread while it is performing kernel mode NEON in process
> context, which means that in all other cases, we can simply preserve the
> userland FPSIMD state once, and only restore it upon return to userland,
> even if we are being invoked from softirq or hardirq context.
>
> So instead of checking whether we are running in interrupt context, keep
> track of the level of nested kernel mode NEON calls in progress, and only
> perform the eager stack/unstack if the level exceeds 1.
Hang on ... we could be in the middle of fpsimd_save_state() for other
reasons, say on the context switch path. Wouldn't we need to take the
lock for those too?
Also, a spinlock can't protect a critical section from code running on
the same CPU... wouldn't it just deadlock in that case?
I still tend to prefer v4 -- there we do a redundant double-save only if
one kernel_neon_begin() interrupts the actual task context save.
Cheers
---Dave
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> v6:
> - use a spinlock instead of disabling interrupts
>
> v5:
> - perform the test-and-set and the fpsimd_save_state with interrupts disabled,
> to prevent nested kernel_neon_begin()/_end() pairs to clobber the state
> while it is being preserved
>
> v4:
> - use this_cpu_inc/dec, which give sufficient guarantees regarding
> concurrency, but do not imply SMP barriers, which are not needed here
>
> v3:
> - avoid corruption by concurrent invocations of kernel_neon_begin()/_end()
>
> v2:
> - BUG() on unexpected values of the nesting level
> - relax the BUG() on num_regs>32 to a WARN, given that nothing actually
> breaks in that case
>
> arch/arm64/include/asm/fpsimd.h | 3 +
> arch/arm64/kernel/fpsimd.c | 77 ++++++++++++++------
> 2 files changed, 58 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> index 50f559f574fe..ee09fe1c37b6 100644
> --- a/arch/arm64/include/asm/fpsimd.h
> +++ b/arch/arm64/include/asm/fpsimd.h
> @@ -17,6 +17,7 @@
> #define __ASM_FP_H
>
> #include <asm/ptrace.h>
> +#include <linux/spinlock.h>
>
> #ifndef __ASSEMBLY__
>
> @@ -37,6 +38,8 @@ struct fpsimd_state {
> u32 fpcr;
> };
> };
> + /* lock protecting the preserved state while it is being saved */
> + spinlock_t lock;
> /* the id of the last cpu to have restored this state */
> unsigned int cpu;
> };
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 394c61db5566..886eea2d4084 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -160,6 +160,7 @@ void fpsimd_flush_thread(void)
> memset(¤t->thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
> fpsimd_flush_task_state(current);
> set_thread_flag(TIF_FOREIGN_FPSTATE);
> + spin_lock_init(¤t->thread.fpsimd_state.lock);
> }
>
> /*
> @@ -220,45 +221,77 @@ void fpsimd_flush_task_state(struct task_struct *t)
>
> #ifdef CONFIG_KERNEL_MODE_NEON
>
> -static DEFINE_PER_CPU(struct fpsimd_partial_state, hardirq_fpsimdstate);
> -static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
> +/*
> + * Although unlikely, it is possible for three kernel mode NEON contexts to
> + * be live at the same time: process context, softirq context and hardirq
> + * context. So while the userland context is stashed in the thread's fpsimd
> + * state structure, we need two additional levels of storage.
> + */
> +static DEFINE_PER_CPU(struct fpsimd_partial_state, nested_fpsimdstate[2]);
> +static DEFINE_PER_CPU(int, kernel_neon_nesting_level);
>
> /*
> * Kernel-side NEON support functions
> */
> void kernel_neon_begin_partial(u32 num_regs)
> {
> - if (in_interrupt()) {
> - struct fpsimd_partial_state *s = this_cpu_ptr(
> - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> + struct fpsimd_partial_state *s;
> + int level;
>
> - BUG_ON(num_regs > 32);
> - fpsimd_save_partial_state(s, roundup(num_regs, 2));
> - } else {
> + preempt_disable();
> +
> + /*
> + * Save the userland FPSIMD state if we have one and if we
> + * haven't done so already. Clear fpsimd_last_state to indicate
> + * that there is no longer userland FPSIMD state in the
> + * registers.
> + */
> + if (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE)) {
> /*
> - * Save the userland FPSIMD state if we have one and if we
> - * haven't done so already. Clear fpsimd_last_state to indicate
> - * that there is no longer userland FPSIMD state in the
> + * Whoever test-and-sets the TIF_FOREIGN_FPSTATE flag should
> + * preserve the userland FP/SIMD state without interruption by
> + * nested kernel_neon_begin()/_end() calls.
> + * The reason is that the FP/SIMD register file is shared with
> + * SVE on hardware that supports it, and nested kernel mode NEON
> + * calls do not restore the upper part of the shared SVE/SIMD
> * registers.
> */
> - preempt_disable();
> - if (current->mm &&
> - !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> - fpsimd_save_state(¤t->thread.fpsimd_state);
> - this_cpu_write(fpsimd_last_state, NULL);
> + if (spin_trylock(¤t->thread.fpsimd_state.lock)) {
> + if (!test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> + fpsimd_save_state(¤t->thread.fpsimd_state);
> + spin_unlock(¤t->thread.fpsimd_state.lock);
> + }
> + }
> + this_cpu_write(fpsimd_last_state, NULL);
> +
> + level = this_cpu_inc_return(kernel_neon_nesting_level);
> + BUG_ON(level > 3);
> +
> + if (level > 1) {
> + s = this_cpu_ptr(nested_fpsimdstate);
> +
> + WARN_ON_ONCE(num_regs > 32);
> + num_regs = min(roundup(num_regs, 2), 32U);
> +
> + fpsimd_save_partial_state(&s[level - 2], num_regs);
> }
> }
> EXPORT_SYMBOL(kernel_neon_begin_partial);
>
> void kernel_neon_end(void)
> {
> - if (in_interrupt()) {
> - struct fpsimd_partial_state *s = this_cpu_ptr(
> - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> - fpsimd_load_partial_state(s);
> - } else {
> - preempt_enable();
> + struct fpsimd_partial_state *s;
> + int level;
> +
> + level = this_cpu_read(kernel_neon_nesting_level);
> + BUG_ON(level < 1);
> +
> + if (level > 1) {
> + s = this_cpu_ptr(nested_fpsimdstate);
> + fpsimd_load_partial_state(&s[level - 2]);
> }
> + this_cpu_dec(kernel_neon_nesting_level);
> + preempt_enable();
> }
> EXPORT_SYMBOL(kernel_neon_end);
>
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv5 00/11] CONFIG_DEBUG_VIRTUAL for arm64
From: Mark Rutland @ 2016-12-13 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481068257-6367-1-git-send-email-labbott@redhat.com>
On Tue, Dec 06, 2016 at 03:50:46PM -0800, Laura Abbott wrote:
> Hi,
>
> This is v5 of the series to add CONFIG_DEBUG_VIRTUAL for arm64. This mostly
> contains minor fixups including adding a few extra headers around and splitting
> things out into a few more sub-patches.
>
> With a few more acks I think this should be ready to go. More testing is
> always appreciated though.
I've given the whole series a go with kasan, kexec, and hibernate (using
test_resume with the disk target), and everything looks happy. So FWIW,
for the series:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Hopefully this can be queued soon for v4.11!
Thanks,
Mark.
^ permalink raw reply
* [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
From: Krzysztof Kozlowski @ 2016-12-13 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b34f49c8-6b37-cabf-2a0f-c8d465c53159@xs4all.nl>
On Tue, Dec 13, 2016 at 2:34 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Try again, this time with Krzysztof's new email address...
>
>
> On 13/12/16 13:20, Hans Verkuil wrote:
>>
>> Hi Krzysztof,
>>
>> This still seems to be broken with the latest 4.9 kernel, right?
>>
>> Has there been any progress on this? Do you have an updated patch series
>> for me to use?
Hi,
I think it is not fixed. Still. I left this work to others. AFAIK,
Peter Chen is working on a new generic approach:
https://lwn.net/Articles/703556/
On top of his patchset, Odroid would need some DTS code as well (and
maybe something in usb3503). However I do not plan to work on this
anymore as I do not have Odroid U3 anymore. Marek and Bartlomiej from
Samsung Poland are in CC-list so maybe they would like to continue the
work?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH V7 4/8] common: DMA-mapping: add DMA_ATTR_PRIVILEGED attribute
From: Robin Murphy @ 2016-12-13 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481567927-14791-5-git-send-email-sricharan@codeaurora.org>
On 12/12/16 18:38, Sricharan R wrote:
> From: Mitchel Humpherys <mitchelh@codeaurora.org>
>
> This patch adds the DMA_ATTR_PRIVILEGED attribute to the DMA-mapping
> subsystem.
>
> Some advanced peripherals such as remote processors and GPUs perform
> accesses to DMA buffers in both privileged "supervisor" and unprivileged
> "user" modes. This attribute is used to indicate to the DMA-mapping
> subsystem that the buffer is fully accessible at the elevated privilege
> level (and ideally inaccessible or at least read-only at the
> lesser-privileged levels).
>
> Cc: linux-doc at vger.kernel.org
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Tested-by: Robin Murphy <robin.murphy@arm.com>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
> ---
> Documentation/DMA-attributes.txt | 10 ++++++++++
> include/linux/dma-mapping.h | 7 +++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
> index 98bf7ac..44c6bc4 100644
> --- a/Documentation/DMA-attributes.txt
> +++ b/Documentation/DMA-attributes.txt
> @@ -143,3 +143,13 @@ So, this provides a way for drivers to avoid those error messages on calls
> where allocation failures are not a problem, and shouldn't bother the logs.
>
> NOTE: At the moment DMA_ATTR_NO_WARN is only implemented on PowerPC.
> +
> +DMA_ATTR_PRIVILEGED
> +------------------------------
> +
> +Some advanced peripherals such as remote processors and GPUs perform
> +accesses to DMA buffers in both privileged "supervisor" and unprivileged
> +"user" modes. This attribute is used to indicate to the DMA-mapping
> +subsystem that the buffer is fully accessible at the elevated privilege
> +level (and ideally inaccessible or at least read-only at the
> +lesser-privileged levels).
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 6f3e6ca..ee31ea1 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -63,6 +63,13 @@
> #define DMA_ATTR_NO_WARN (1UL << 8)
>
> /*
> + * DMA_ATTR_PRIVILEGED: used to indicate that the buffer is fully
> + * accessible at an elevated privilege level (and ideally inaccessible or
> + * at least read-only at lesser-privileged levels).
> + */
> +#define DMA_ATTR_PRIVILEGED (1UL << 8)
Oops, I spoke slightly too soon - there's a value conflict here which
has been missed in the rebase.
Robin
> +
> +/*
> * A dma_addr_t can hold any valid DMA or bus address for the platform.
> * It can be given to a device to use as a DMA source or target. A CPU cannot
> * reference a dma_addr_t directly because there may be translation between
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox