* Re: [PATCH v8 5/5] dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
From: James Morse @ 2020-05-29 16:11 UTC (permalink / raw)
To: Rob Herring, chenzhou
Cc: Thomas Gleixner, Ingo Molnar, Catalin Marinas, Will Deacon,
dyoung, Baoquan He, Arnd Bergmann, John.p.donnelly, pkushwaha,
Simon Horman, Hanjun Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, Linux Doc Mailing List, linux-kernel@vger.kernel.org,
kexec
In-Reply-To: <20200526211800.GA352001@bogus>
Hi guys,
On 26/05/2020 22:18, Rob Herring wrote:
> On Fri, May 22, 2020 at 11:24:11AM +0800, chenzhou wrote:
>> On 2020/5/21 21:29, Rob Herring wrote:
>>> On Thu, May 21, 2020 at 3:35 AM Chen Zhou <chenzhou10@huawei.com> wrote:
>>>> Add documentation for DT property used by arm64 kdump:
>>>> linux,low-memory-range.
>>>> "linux,low-memory-range" is an another memory region used for crash
>>>> dump kernel devices.
>>>> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
>>>> index 45e79172a646..bfe6fb6976e6 100644
>>>> --- a/Documentation/devicetree/bindings/chosen.txt
>>>> +++ b/Documentation/devicetree/bindings/chosen.txt
>>>> +linux,low-memory-range
>>>> +----------------------
>>>> +This property (arm64 only) holds a base address and size, describing a
>>>> +limited region below 4G. Similar to "linux,usable-memory-range", it is
>>>> +an another memory range which may be considered available for use by the
>>>> +kernel.
>>> Why can't you just add a range to "linux,usable-memory-range"? It
>>> shouldn't be hard to figure out which part is below 4G.
>> The comments from James:
>> Won't this break if your kdump kernel doesn't know what the extra parameters are?
>> Or if it expects two ranges, but only gets one? These DT properties should be treated as
>> ABI between kernel versions, we can't really change it like this.
>>
>> I think the 'low' region is an optional-extra, that is never mapped by the first kernel. I
>> think the simplest thing to do is to add an 'linux,low-memory-range' that we
>> memblock_add() after memblock_cap_memory_range() has been called.
>> If its missing, or the new kernel doesn't know what its for, everything keeps working.
>
>
> I don't think there's a compatibility issue here though. The current
> kernel doesn't care if the property is longer than 1 base+size. It only
> checks if the size is less than 1 base+size.
Aha! I missed that.
> And yes, we can rely on
> that implementation detail. It's only an ABI if an existing user
> notices.
>
> Now, if the low memory is listed first, then an older kdump kernel
> would get a different memory range. If that's a problem, then define
> that low memory goes last.
This first entry would need to be the 'crashkernel' range where the kdump kernel is
placed, otherwise an older kernel won't boot. The rest can be optional extras, as long as
we are tolerant of it being missing...
I'll try and look at the rest of this series on Monday,
Thanks,
James
^ permalink raw reply
* Re: [PATCH dt-schema] Fix interrupt controllers with interrupt-map
From: Geert Uytterhoeven @ 2020-05-29 16:02 UTC (permalink / raw)
To: Rob Herring; +Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CAL_JsqJOPd2txkz298Rs12N+keJNYg2_qjCc-3vDwtL5iNXZmA@mail.gmail.com>
Hi Rob,
On Fri, May 29, 2020 at 5:54 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Thu, May 28, 2020 at 7:23 AM Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > When an interrupt controller has an "interrupt-map" property, an "is
> > valid under each of" error is triggered.
> >
> > Fix this by allowing "interrupt-controller" and "interrupt-map" to
> > coexist, in both the interrrupts meta-schema and the
> > interrupt-controller schema.
>
> But both should not be present. If 'interrupt-controller' is present,
Why not?
> the Linux irq parsing code will ignore 'interrupt-map'. Seems like
> that's backwards, but this parsing code is older than dirt and we'd
> probably break some 1990s machine changing it.
That's fine. rza1_irqc_parse_map() parses the interrupt-map itself,
to map from downstream to upstream interrupts.
Cfr. the original bindings at
https://lore.kernel.org/linux-devicetree/20190502123220.3016-2-geert+renesas@glider.be/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
* Re: [PATCH] ARM: dts: imx53: ppd: alarm LEDs use kernel LED interface
From: Pavel Machek @ 2020-05-29 16:02 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Rob Herring, devicetree, linux-kernel, kernel,
Ian Ray, Samu Nuutamo
In-Reply-To: <20200529140555.ozlvz4egihkvo3aw@earth.universe>
[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]
Hi!
> ping?
Well, I thought that we maybe do not need standard LEDs on medical hardware.
> On Fri, Apr 24, 2020 at 02:44:23PM +0200, Sebastian Reichel wrote:
> > Hi,
> >
> > On Fri, Apr 24, 2020 at 11:32:26AM +0200, Pavel Machek wrote:
> > > On Thu 2020-04-16 16:51:23, Sebastian Reichel wrote:
> > > > From: Ian Ray <ian.ray@ge.com>
> > > >
> > > > Use kernel LED interface for the alarm LEDs.
> > >
> > > Could we get these changes cced to LED maintainers?
> >
> > Sorry, you are not turning up via get_maintainer.pl and usually
> > subsystem maintainers are not CC'd for every DT device instance.
> > E.g. I do not want to be always CC'd for DT board file containing
> > a battery/charger. I'm quite surprised you want to be CC'd for
> > them, just looking at ARM DT files there are over 1000 instances
> > of leds.
Well, we have mess in the naming; I'd like to clear it up.
> > > > + alarm1 {
> > > > + label = "alarm:red";
> > > > + gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> > > > + };
> > >
> > > So... What is function of these leds, and can we get naming more
> > > consistent with rest of the kernel?
> >
> > The device is a medical patient monitor and these are alarm LEDs
> > informing about critical device or patient status. They are
> > referenced by their color (those are discrete LEDs, not a
> > multi-color one) basically everywhere. The only exception is
> > "silenced", which means that audible alarm is surpressed. I
> > don't think we have something comparable for any of those LEDs
> > in the mainline tree.
Actually, we have "platform:*:mute" LEDs, that could be used for
"silenced".
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* [PATCHv4 2/2] dt-bindings: snps,dw-apb-ssi: add optional reset property
From: Dinh Nguyen @ 2020-05-29 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: dinguyen, devicetree, linux-spi, broonie, robh+dt, Sergey.Semin,
fancer.lancer, andriy.shevchenko, lars.povlsen, liang.j.jin
In-Reply-To: <20200529155806.16758-1-dinguyen@kernel.org>
Add optional reset property.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
v4: rebased to linux-next 20200529
v3: no change
v2: actually document the "resets" and "reset-names" optional properties
---
Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
index 020e3168ee41..0f21407a7ea3 100644
--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
@@ -25,6 +25,9 @@ Optional properties:
device. Supported values are 2 or 4 (the default).
- dmas : Phandle + identifiers of Tx and Rx DMA channels.
- dma-names : Contains the names of the DMA channels. Must be "tx" and "rx".
+- resets : contains an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names : must contain "spi"
Child nodes as per the generic SPI binding.
@@ -40,5 +43,7 @@ Example:
num-cs = <2>;
cs-gpios = <&gpio0 13 0>,
<&gpio0 14 0>;
+ resets = <&rst SPIM0_RST>;
+ reset-names = "spi";
};
--
2.17.1
^ permalink raw reply related
* [PATCHv4 1/2] spi: dw: add reset control
From: Dinh Nguyen @ 2020-05-29 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: dinguyen, devicetree, linux-spi, broonie, robh+dt, Sergey.Semin,
fancer.lancer, andriy.shevchenko, lars.povlsen, liang.j.jin
Add mechanism to get the reset control and deassert it in order to bring
the IP out of reset.
Signed-off-by: Liang Jin J <liang.j.jin@ericsson.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
v4: no change
v3: allow for other failures
remove tab for rstc reset_control
v2: use _get_optional_exclusive
put IP back into reset if there was an error in probe function
---
drivers/spi/spi-dw-mmio.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
index 0894b4c09496..a1b87d4606ba 100644
--- a/drivers/spi/spi-dw-mmio.c
+++ b/drivers/spi/spi-dw-mmio.c
@@ -19,6 +19,7 @@
#include <linux/acpi.h>
#include <linux/property.h>
#include <linux/regmap.h>
+#include <linux/reset.h>
#include "spi-dw.h"
@@ -29,6 +30,7 @@ struct dw_spi_mmio {
struct clk *clk;
struct clk *pclk;
void *priv;
+ struct reset_control *rstc;
};
#define MSCC_CPU_SYSTEM_CTRL_GENERAL_CTRL 0x24
@@ -224,6 +226,14 @@ static int dw_spi_mmio_probe(struct platform_device *pdev)
if (ret)
goto out_clk;
+ /* find an optional reset controller */
+ dwsmmio->rstc = devm_reset_control_get_optional_exclusive(&pdev->dev, "spi");
+ if (IS_ERR(dwsmmio->rstc)) {
+ ret = PTR_ERR(dwsmmio->rstc);
+ goto out_clk;
+ }
+ reset_control_deassert(dwsmmio->rstc);
+
dws->bus_num = pdev->id;
dws->max_freq = clk_get_rate(dwsmmio->clk);
@@ -257,6 +267,8 @@ static int dw_spi_mmio_probe(struct platform_device *pdev)
clk_disable_unprepare(dwsmmio->pclk);
out_clk:
clk_disable_unprepare(dwsmmio->clk);
+ reset_control_assert(dwsmmio->rstc);
+
return ret;
}
@@ -268,6 +280,7 @@ static int dw_spi_mmio_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
clk_disable_unprepare(dwsmmio->pclk);
clk_disable_unprepare(dwsmmio->clk);
+ reset_control_assert(dwsmmio->rstc);
return 0;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH dt-schema] Fix interrupt controllers with interrupt-map
From: Rob Herring @ 2020-05-29 15:54 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: devicetree
In-Reply-To: <20200528132323.30288-1-geert+renesas@glider.be>
On Thu, May 28, 2020 at 7:23 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> When an interrupt controller has an "interrupt-map" property, an "is
> valid under each of" error is triggered.
>
> Fix this by allowing "interrupt-controller" and "interrupt-map" to
> coexist, in both the interrrupts meta-schema and the
> interrupt-controller schema.
But both should not be present. If 'interrupt-controller' is present,
the Linux irq parsing code will ignore 'interrupt-map'. Seems like
that's backwards, but this parsing code is older than dirt and we'd
probably break some 1990s machine changing it.
Rob
^ permalink raw reply
* Re: [PATCH v5 09/11] dmaengine: dw: Initialize min and max burst DMA device capability
From: Andy Shevchenko @ 2020-05-29 15:48 UTC (permalink / raw)
To: Serge Semin
Cc: Vinod Koul, Viresh Kumar, Dan Williams, Serge Semin,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, dmaengine, linux-kernel
In-Reply-To: <20200529144054.4251-10-Sergey.Semin@baikalelectronics.ru>
On Fri, May 29, 2020 at 05:40:52PM +0300, Serge Semin wrote:
> According to the DW APB DMAC data book the minimum burst transaction
> length is 1 and it's true for any version of the controller since
> isn't parametrised in the coreAssembler so can't be changed at the
> IP-core synthesis stage. The maximum burst transaction can vary from
> channel to channel and from controller to controller depending on a
> IP-core parameter the system engineer activated during the IP-core
> synthesis. Let's initialise both min_burst and max_burst members of the
> DMA controller descriptor with extreme values so the DMA clients could
> use them to properly optimize the DMA requests. The channels and
> controller-specific max_burst length initialization will be introduced
> by the follow-up patches.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-mips@vger.kernel.org
> Cc: devicetree@vger.kernel.org
>
> ---
>
> Changelog v4:
> - This is a new patch suggested by Andy.
>
> Changelog v5:
> - Introduce macro with extreme min and max burst length supported by the
> DW DMA controller.
> - Initialize max_burst length capability with extreme burst length supported
> by the DW DMAC IP-core.
> ---
> drivers/dma/dw/core.c | 2 ++
> include/linux/platform_data/dma-dw.h | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> index ceded21537e2..4887aa2fc73c 100644
> --- a/drivers/dma/dw/core.c
> +++ b/drivers/dma/dw/core.c
> @@ -1229,6 +1229,8 @@ int do_dma_probe(struct dw_dma_chip *chip)
> dw->dma.device_issue_pending = dwc_issue_pending;
>
> /* DMA capabilities */
> + dw->dma.min_burst = DW_DMA_MIN_BURST;
> + dw->dma.max_burst = DW_DMA_MAX_BURST;
> dw->dma.src_addr_widths = DW_DMA_BUSWIDTHS;
> dw->dma.dst_addr_widths = DW_DMA_BUSWIDTHS;
> dw->dma.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV) |
> diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
> index f3eaf9ec00a1..369e41e9dcc9 100644
> --- a/include/linux/platform_data/dma-dw.h
> +++ b/include/linux/platform_data/dma-dw.h
> @@ -12,6 +12,8 @@
>
> #define DW_DMA_MAX_NR_MASTERS 4
> #define DW_DMA_MAX_NR_CHANNELS 8
> +#define DW_DMA_MIN_BURST 1
> +#define DW_DMA_MAX_BURST 256
>
> /**
> * struct dw_dma_slave - Controller-specific information about a slave
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [Linux-stm32] [PATCH v8 08/10] drm: stm: dw-mipi-dsi: let the bridge handle the HW version check
From: Philippe CORNU @ 2020-05-29 15:45 UTC (permalink / raw)
To: Adrian Ratiu, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
Laurent Pinchart
Cc: Jernej Skrabec, Heiko Stuebner, Adrian Pop, Jonas Karlman,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Andrzej Hajda, linux-imx@nxp.com, kernel@collabora.com,
linux-stm32@st-md-mailman.stormreply.com, Arnaud Ferraris,
Yannick FERTRE, Benjamin GAIGNARD
In-Reply-To: <20200427081952.3536741-9-adrian.ratiu@collabora.com>
Hi Adrian,
and thank you very much for the patchset.
Thank you also for having tested it on STM32F769 and STM32MP1.
Sorry for the late response, Yannick and I will review it as soon as
possible and we will keep you posted.
Note: Do not hesitate to put us in copy for the next version
(philippe.cornu@st.com, yannick.fertre@st.com)
Regards,
Philippe :-)
On 4/27/20 10:19 AM, Adrian Ratiu wrote:
> The stm mipi-dsi platform driver added a version test in
> commit fa6251a747b7 ("drm/stm: dsi: check hardware version")
> so that HW revisions other than v1.3x get rejected. The rockchip
> driver had no such check and just assumed register layouts are
> v1.3x compatible.
>
> Having such tests was a good idea because only v130/v131 layouts
> were supported at the time, however since adding multiple layout
> support in the bridge, the version is automatically checked for
> all drivers, compatible layouts get picked and unsupported HW is
> automatically rejected by the bridge, so there's no use keeping
> the test in the stm driver.
>
> The main reason prompting this change is that the stm driver
> test immediately disabled the peripheral clock after reading
> the version, making the bridge read version 0x0 immediately
> after in its own probe(), so we move the clock disabling after
> the bridge does the version test.
>
> Tested on STM32F769 and STM32MP1.
>
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Reported-by: Adrian Pop <pop.adrian61@gmail.com>
> Tested-by: Adrian Pop <pop.adrian61@gmail.com>
> Tested-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
> ---
> New in v6.
> ---
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 12 +++---------
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index 2e1f2664495d0..7218e405d7e2b 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -402,15 +402,6 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
> goto err_dsi_probe;
> }
>
> - dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
> - clk_disable_unprepare(pclk);
> -
> - if (dsi->hw_version != HWVER_130 && dsi->hw_version != HWVER_131) {
> - ret = -ENODEV;
> - DRM_ERROR("bad dsi hardware version\n");
> - goto err_dsi_probe;
> - }
> -
> dw_mipi_dsi_stm_plat_data.base = dsi->base;
> dw_mipi_dsi_stm_plat_data.priv_data = dsi;
>
> @@ -423,6 +414,9 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
> goto err_dsi_probe;
> }
>
> + dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
> + clk_disable_unprepare(pclk);
> +
> return 0;
>
> err_dsi_probe:
>
^ permalink raw reply
* Re: [PATCH 3/4] pinctrl: bcm2835: Match BCM7211 compatible string
From: Florian Fainelli @ 2020-05-29 15:44 UTC (permalink / raw)
To: Stefan Wahren, linux-kernel
Cc: Linus Walleij, Rob Herring, Ray Jui, Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Geert Uytterhoeven, Matti Vaittinen,
open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <291609c0-f1ec-2626-8bfa-cf25a9e45365@i2se.com>
On 5/29/2020 6:11 AM, Stefan Wahren wrote:
> Hi Florian,
>
> Am 28.05.20 um 21:21 schrieb Florian Fainelli:
>> The BCM7211 SoC uses the same pinconf_ops as the ones defined for the
>> BCM2711 SoC, match the compatible string and use the correct set of
>> options.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/pinctrl/bcm/pinctrl-bcm2835.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> index 06bd2b70af3c..e8ad1824c6b3 100644
>> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> @@ -1137,6 +1137,10 @@ static const struct of_device_id bcm2835_pinctrl_match[] = {
>> .compatible = "brcm,bcm2711-gpio",
>> .data = &bcm2711_plat_data,
>> },
>> + {
>> + .compatible = "brcm,bcm7211-gpio",
>> + .data = &bcm2711_pinconf_ops,
>
> this doesn't look safe. Maybe bcm2711_plat_data?
Whoops you are right, I sent an incorrect version.
>
> Looks like the original patch series based on a older version. Please
> double check this still applies since the introduction of 58 GPIO
> support for BCM2711.
We can use bcm2711_plat_data, thanks Stefan.
--
Florian
^ permalink raw reply
* [PATCH v5 02/11] dt-bindings: dma: dw: Add max burst transaction length property
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Rob Herring
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Andy Shevchenko, linux-mips, dmaengine, devicetree,
linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
This array property is used to indicate the maximum burst transaction
length supported by each DMA channel.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-mips@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Move $ref to the root level of the properties. So do with the
constraints.
- Set default max-burst-len to 256 TR-WIDTH words.
Changelog v3:
- Add more details into the property description about what limitations
snps,max-burst-len defines.
---
.../bindings/dma/snps,dma-spear1340.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
index e7611840a7cf..20870f5c14dd 100644
--- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
@@ -120,6 +120,21 @@ properties:
enum: [0, 1]
default: 1
+ snps,max-burst-len:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Maximum length of the burst transactions supported by the controller.
+ This property defines the upper limit of the run-time burst setting
+ (CTLx.SRC_MSIZE/CTLx.DST_MSIZE fields) so the allowed burst length
+ will be from 1 to max-burst-len words. It's an array property with one
+ cell per channel in the units determined by the value set in the
+ CTLx.SRC_TR_WIDTH/CTLx.DST_TR_WIDTH fields (data width).
+ items:
+ maxItems: 8
+ items:
+ enum: [4, 8, 16, 32, 64, 128, 256]
+ default: 256
+
snps,dma-protection-control:
$ref: /schemas/types.yaml#definitions/uint32
description: |
--
2.26.2
^ permalink raw reply related
* [PATCH v5 06/11] dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
Full multi-block transfers functionality is enabled in DW DMA
controller only if CHx_MULTI_BLK_EN is set. But LLP-based transfers
can be executed only if hardcode channel x LLP register feature isn't
enabled, which can be switched on at the IP core synthesis for
optimization. If it's enabled then the LLP register is hardcoded to
zero, so the blocks chaining based on the LLPs is unsupported.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Add comment about why hardware accelerated LLP list support depends
on both MBLK_EN and HC_LLP configs setting.
- Use explicit bits state comparison operator.
Changelog v3:
- Move the patch to the head of the series.
---
drivers/dma/dw/core.c | 11 ++++++++++-
drivers/dma/dw/regs.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 21cb2a58dbd2..33e99d95b3d3 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1178,8 +1178,17 @@ int do_dma_probe(struct dw_dma_chip *chip)
*/
dwc->block_size =
(4 << ((pdata->block_size >> 4 * i) & 0xf)) - 1;
+
+ /*
+ * According to the DW DMA databook the true scatter-
+ * gether LLPs aren't available if either multi-block
+ * config is disabled (CHx_MULTI_BLK_EN == 0) or the
+ * LLP register is hard-coded to zeros
+ * (CHx_HC_LLP == 1).
+ */
dwc->nollp =
- (dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
+ (dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0 ||
+ (dwc_params >> DWC_PARAMS_HC_LLP & 0x1) == 1;
} else {
dwc->block_size = pdata->block_size;
dwc->nollp = !pdata->multi_block[i];
diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
index 3fce66ecee7a..1ab840b06e79 100644
--- a/drivers/dma/dw/regs.h
+++ b/drivers/dma/dw/regs.h
@@ -125,6 +125,7 @@ struct dw_dma_regs {
/* Bitfields in DWC_PARAMS */
#define DWC_PARAMS_MBLK_EN 11 /* multi block transfer */
+#define DWC_PARAMS_HC_LLP 13 /* set LLP register to zero */
/* bursts size */
enum dw_dma_msize {
--
2.26.2
^ permalink raw reply related
* [PATCH v5 04/11] dmaengine: Introduce max SG list entries capability
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Dan Williams
Cc: Serge Semin, Serge Semin, Andy Shevchenko, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, Rob Herring, linux-mips,
devicetree, dmaengine, linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
Some devices may lack the support of the hardware accelerated SG list
entries automatic walking through and execution. In this case a burden of
the SG list traversal and DMA engine re-initialization lies on the
DMA engine driver (normally implemented by using a DMA transfer completion
IRQ to recharge the DMA device with a next SG list entry). But such
solution may not be suitable for some DMA consumers. In particular SPI
devices need both Tx and Rx DMA channels work synchronously in order
to avoid the Rx FIFO overflow. In case if Rx DMA channel is paused for
some time while the Tx DMA channel works implicitly pulling data into the
Rx FIFO, the later will be eventually overflown, which will cause the data
loss. So if SG list entries aren't automatically fetched by the DMA
engine, but are one-by-one manually selected for execution in the
ISRs/deferred work/etc., such problem will eventually happen due to the
non-deterministic latencies of the service execution.
In order to let the DMA consumer know about the DMA device capabilities
regarding the hardware accelerated SG list traversal we introduce the
max_sg_list capability. It is supposed to be initialized by the DMA engine
driver with 0 if there is no limitation for the number of SG entries
atomically executed and with non-zero value if there is such constraints,
so the upper limit is determined by the number set to the property.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
Changelog v4:
- Fix of->if typo. It should be definitely of.
---
drivers/dma/dmaengine.c | 1 +
include/linux/dmaengine.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index b332ffe52780..ad56ad58932c 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -592,6 +592,7 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
caps->directions = device->directions;
caps->min_burst = device->min_burst;
caps->max_burst = device->max_burst;
+ caps->max_sg_nents = device->max_sg_nents;
caps->residue_granularity = device->residue_granularity;
caps->descriptor_reuse = device->descriptor_reuse;
caps->cmd_pause = !!device->device_pause;
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 0c7403b27133..a7e4d8dfdd19 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -467,6 +467,9 @@ enum dma_residue_granularity {
* should be checked by controller as well
* @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
+ * @max_sg_nents: max number of SG list entries executed in a single atomic
+ * DMA tansaction with no intermediate IRQ for reinitialization. Zero
+ * value means unlimited number of entries.
* @cmd_pause: true, if pause is supported (i.e. for reading residue or
* for resume later)
* @cmd_resume: true, if resume is supported
@@ -481,6 +484,7 @@ struct dma_slave_caps {
u32 directions;
u32 min_burst;
u32 max_burst;
+ u32 max_sg_nents;
bool cmd_pause;
bool cmd_resume;
bool cmd_terminate;
@@ -773,6 +777,9 @@ struct dma_filter {
* should be checked by controller as well
* @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
+ * @max_sg_nents: max number of SG list entries executed in a single atomic
+ * DMA tansaction with no intermediate IRQ for reinitialization. Zero
+ * value means unlimited number of entries.
* @residue_granularity: granularity of the transfer residue reported
* by tx_status
* @device_alloc_chan_resources: allocate resources and return the
@@ -844,6 +851,7 @@ struct dma_device {
u32 directions;
u32 min_burst;
u32 max_burst;
+ u32 max_sg_nents;
bool descriptor_reuse;
enum dma_residue_granularity residue_granularity;
--
2.26.2
^ permalink raw reply related
* [PATCH v5 05/11] dmaengine: Introduce DMA-device device_caps callback
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Dan Williams
Cc: Serge Semin, Serge Semin, Andy Shevchenko, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, Rob Herring, linux-mips,
devicetree, dmaengine, linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
There are DMA devices (like ours version of Synopsys DW DMAC) which have
DMA capabilities non-uniformly redistributed between the device channels.
In order to provide a way of exposing the channel-specific parameters to
the DMA engine consumers, we introduce a new DMA-device callback. In case
if provided it gets called from the dma_get_slave_caps() method and is
able to override the generic DMA-device capabilities.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinod and
Andy in the framework of DW DMA burst and LLP capabilities.
Changelog v5:
- Add in-line comment at the point of the device_caps callback invocation.
- Add doc-comment for the device_caps member of struct dma_device.
---
drivers/dma/dmaengine.c | 10 ++++++++++
include/linux/dmaengine.h | 4 ++++
2 files changed, 14 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ad56ad58932c..ed1fd376f1a5 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -599,6 +599,16 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
caps->cmd_resume = !!device->device_resume;
caps->cmd_terminate = !!device->device_terminate_all;
+ /*
+ * DMA engine device might be configured with non-uniformly
+ * distributed slave capabilities per device channels. In this
+ * case the corresponding driver may provide the device_caps
+ * callback to override the generic capabilities with
+ * channel-specific ones.
+ */
+ if (device->device_caps)
+ device->device_caps(chan, caps);
+
return 0;
}
EXPORT_SYMBOL_GPL(dma_get_slave_caps);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index a7e4d8dfdd19..298b721c8b9f 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -799,6 +799,8 @@ struct dma_filter {
* be called after period_len bytes have been transferred.
* @device_prep_interleaved_dma: Transfer expression in a generic way.
* @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address
+ * @device_caps: May be used to override the generic DMA slave capabilities
+ * with per-channel specific ones
* @device_config: Pushes a new configuration to a channel, return 0 or an error
* code
* @device_pause: Pauses any transfer happening on a channel. Returns
@@ -899,6 +901,8 @@ struct dma_device {
struct dma_chan *chan, dma_addr_t dst, u64 data,
unsigned long flags);
+ void (*device_caps)(struct dma_chan *chan,
+ struct dma_slave_caps *caps);
int (*device_config)(struct dma_chan *chan,
struct dma_slave_config *config);
int (*device_pause)(struct dma_chan *chan);
--
2.26.2
^ permalink raw reply related
* [PATCH v5 07/11] dmaengine: dw: Set DMA device max segment size parameter
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
Maximum block size DW DMAC configuration corresponds to the max segment
size DMA parameter in the DMA core subsystem notation. Lets set it with a
value specific to the probed DW DMA controller. It shall help the DMA
clients to create size-optimized SG-list items for the controller. This in
turn will cause less dw_desc allocations, less LLP reinitializations,
better DMA device performance.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- This is a new patch created in place of the dropped one:
"dmaengine: dw: Add LLP and block size config accessors".
Changelog v3:
- Use the block_size found for the very first channel instead of looking for
the maximum of maximum block sizes.
- Don't define device-specific device_dma_parameters object, since it has
already been defined by the platform device core.
---
drivers/dma/dw/core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 33e99d95b3d3..fb95920c429e 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1229,6 +1229,13 @@ int do_dma_probe(struct dw_dma_chip *chip)
BIT(DMA_MEM_TO_MEM);
dw->dma.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+ /*
+ * For now there is no hardware with non uniform maximum block size
+ * across all of the device channels, so we set the maximum segment
+ * size as the block size found for the very first channel.
+ */
+ dma_set_max_seg_size(dw->dma.dev, dw->chan[0].block_size);
+
err = dma_async_device_register(&dw->dma);
if (err)
goto err_dma_register;
--
2.26.2
^ permalink raw reply related
* [PATCH v5 09/11] dmaengine: dw: Initialize min and max burst DMA device capability
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
According to the DW APB DMAC data book the minimum burst transaction
length is 1 and it's true for any version of the controller since
isn't parametrised in the coreAssembler so can't be changed at the
IP-core synthesis stage. The maximum burst transaction can vary from
channel to channel and from controller to controller depending on a
IP-core parameter the system engineer activated during the IP-core
synthesis. Let's initialise both min_burst and max_burst members of the
DMA controller descriptor with extreme values so the DMA clients could
use them to properly optimize the DMA requests. The channels and
controller-specific max_burst length initialization will be introduced
by the follow-up patches.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v4:
- This is a new patch suggested by Andy.
Changelog v5:
- Introduce macro with extreme min and max burst length supported by the
DW DMA controller.
- Initialize max_burst length capability with extreme burst length supported
by the DW DMAC IP-core.
---
drivers/dma/dw/core.c | 2 ++
include/linux/platform_data/dma-dw.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index ceded21537e2..4887aa2fc73c 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1229,6 +1229,8 @@ int do_dma_probe(struct dw_dma_chip *chip)
dw->dma.device_issue_pending = dwc_issue_pending;
/* DMA capabilities */
+ dw->dma.min_burst = DW_DMA_MIN_BURST;
+ dw->dma.max_burst = DW_DMA_MAX_BURST;
dw->dma.src_addr_widths = DW_DMA_BUSWIDTHS;
dw->dma.dst_addr_widths = DW_DMA_BUSWIDTHS;
dw->dma.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV) |
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index f3eaf9ec00a1..369e41e9dcc9 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -12,6 +12,8 @@
#define DW_DMA_MAX_NR_MASTERS 4
#define DW_DMA_MAX_NR_CHANNELS 8
+#define DW_DMA_MIN_BURST 1
+#define DW_DMA_MAX_BURST 256
/**
* struct dw_dma_slave - Controller-specific information about a slave
--
2.26.2
^ permalink raw reply related
* [PATCH v5 11/11] dmaengine: dw: Initialize max_sg_nents capability
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
Multi-block support provides a way to map the kernel-specific SG-table so
the DW DMA device would handle it as a whole instead of handling the
SG-list items or so called LLP block items one by one. So if true LLP
list isn't supported by the DW DMA engine, then soft-LLP mode will be
utilized to load and execute each LLP-block one by one. The soft-LLP mode
of the DMA transactions execution might not work well for some DMA
consumers like SPI due to its Tx and Rx buffers inter-dependency. Let's
initialize the max_sg_nents DMA channels capability based on the nollp
flag state. If it's true, no hardware accelerated LLP is available and
max_sg_nents should be set with 1, which means that the DMA engine
can handle only a single SG list entry at a time. If noLLP is set to
false, then hardware accelerated LLP is supported and the DMA engine
can handle infinite number of SG entries in a single DMA transaction.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
Changelog v4:
- Use explicit if-else statement when assigning the max_sg_nents field.
---
drivers/dma/dw/core.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 588b9bae827c..9dee5fa65153 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1059,6 +1059,18 @@ static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
caps->max_burst = dwc->max_burst;
+
+ /*
+ * It might be crucial for some devices to have the hardware
+ * accelerated multi-block transfers supported, aka LLPs in DW DMAC
+ * notation. So if LLPs are supported then max_sg_nents is set to
+ * zero which means unlimited number of SG entries can be handled in a
+ * single DMA transaction, otherwise it's just one SG entry.
+ */
+ if (dwc->nollp)
+ caps->max_sg_nents = 1;
+ else
+ caps->max_sg_nents = 0;
}
int do_dma_probe(struct dw_dma_chip *chip)
--
2.26.2
^ permalink raw reply related
* [PATCH v5 10/11] dmaengine: dw: Introduce max burst length hw config
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
IP core of the DW DMA controller may be synthesized with different
max burst length of the transfers per each channel. According to Synopsis
having the fixed maximum burst transactions length may provide some
performance gain. At the same time setting up the source and destination
multi size exceeding the max burst length limitation may cause a serious
problems. In our case the DMA transaction just hangs up. In order to fix
this lets introduce the max burst length platform config of the DW DMA
controller device and don't let the DMA channels configuration code
exceed the burst length hardware limitation.
Note the maximum burst length parameter can be detected either in runtime
from the DWC parameter registers or from the dedicated DT property.
Depending on the IP core configuration the maximum value can vary from
channel to channel so by overriding the channel slave max_burst capability
we make sure a DMA consumer will get the channel-specific max burst
length.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Discard dwc_get_maxburst() accessor. It's enough to have a clamping
guard against exceeding the hardware max burst limitation.
Changelog v3:
- Override the slave channel max_burst capability instead of calculating
the minimum value of max burst lengths and setting the DMA-device
generic capability.
Changelog v5:
- Clamp the dst and src burst lengths in the generic dwc_config() method
instead of doing that in the encode_maxburst() callback.
- Define max_burst with u32 type in struct dw_dma_platform_data.
- Perform of_property_read_u32_array() directly into the platform data
max_burst member.
Changelog v6:
- Move DW_DMA_MAX_BURST macro definition to the previous patch.
---
drivers/dma/dw/core.c | 10 ++++++++++
drivers/dma/dw/of.c | 5 +++++
drivers/dma/dw/regs.h | 2 ++
include/linux/platform_data/dma-dw.h | 3 +++
4 files changed, 20 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 4887aa2fc73c..588b9bae827c 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -791,6 +791,11 @@ static int dwc_config(struct dma_chan *chan, struct dma_slave_config *sconfig)
memcpy(&dwc->dma_sconfig, sconfig, sizeof(*sconfig));
+ dwc->dma_sconfig.src_maxburst =
+ clamp(dwc->dma_sconfig.src_maxburst, 0U, dwc->max_burst);
+ dwc->dma_sconfig.dst_maxburst =
+ clamp(dwc->dma_sconfig.dst_maxburst, 0U, dwc->max_burst);
+
dw->encode_maxburst(dwc, &dwc->dma_sconfig.src_maxburst);
dw->encode_maxburst(dwc, &dwc->dma_sconfig.dst_maxburst);
@@ -1051,7 +1056,9 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
{
+ struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
+ caps->max_burst = dwc->max_burst;
}
int do_dma_probe(struct dw_dma_chip *chip)
@@ -1194,9 +1201,12 @@ int do_dma_probe(struct dw_dma_chip *chip)
dwc->nollp =
(dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0 ||
(dwc_params >> DWC_PARAMS_HC_LLP & 0x1) == 1;
+ dwc->max_burst =
+ (0x4 << (dwc_params >> DWC_PARAMS_MSIZE & 0x7));
} else {
dwc->block_size = pdata->block_size;
dwc->nollp = !pdata->multi_block[i];
+ dwc->max_burst = pdata->max_burst[i] ?: DW_DMA_MAX_BURST;
}
}
diff --git a/drivers/dma/dw/of.c b/drivers/dma/dw/of.c
index 9e27831dee32..1474b3817ef4 100644
--- a/drivers/dma/dw/of.c
+++ b/drivers/dma/dw/of.c
@@ -98,6 +98,11 @@ struct dw_dma_platform_data *dw_dma_parse_dt(struct platform_device *pdev)
pdata->multi_block[tmp] = 1;
}
+ if (of_property_read_u32_array(np, "snps,max-burst-len", pdata->max_burst,
+ nr_channels)) {
+ memset32(pdata->max_burst, DW_DMA_MAX_BURST, nr_channels);
+ }
+
if (!of_property_read_u32(np, "snps,dma-protection-control", &tmp)) {
if (tmp > CHAN_PROTCTL_MASK)
return NULL;
diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
index 1ab840b06e79..76654bd13c1a 100644
--- a/drivers/dma/dw/regs.h
+++ b/drivers/dma/dw/regs.h
@@ -126,6 +126,7 @@ struct dw_dma_regs {
/* Bitfields in DWC_PARAMS */
#define DWC_PARAMS_MBLK_EN 11 /* multi block transfer */
#define DWC_PARAMS_HC_LLP 13 /* set LLP register to zero */
+#define DWC_PARAMS_MSIZE 16 /* max group transaction size */
/* bursts size */
enum dw_dma_msize {
@@ -284,6 +285,7 @@ struct dw_dma_chan {
/* hardware configuration */
unsigned int block_size;
bool nollp;
+ u32 max_burst;
/* custom slave configuration */
struct dw_dma_slave dws;
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 369e41e9dcc9..4f681df85c27 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -44,6 +44,8 @@ struct dw_dma_slave {
* @data_width: Maximum data width supported by hardware per AHB master
* (in bytes, power of 2)
* @multi_block: Multi block transfers supported by hardware per channel.
+ * @max_burst: Maximum value of burst transaction size supported by hardware
+ * per channel (in units of CTL.SRC_TR_WIDTH/CTL.DST_TR_WIDTH).
* @protctl: Protection control signals setting per channel.
*/
struct dw_dma_platform_data {
@@ -58,6 +60,7 @@ struct dw_dma_platform_data {
unsigned char nr_masters;
unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
unsigned char multi_block[DW_DMA_MAX_NR_CHANNELS];
+ u32 max_burst[DW_DMA_MAX_NR_CHANNELS];
#define CHAN_PROTCTL_PRIVILEGED BIT(0)
#define CHAN_PROTCTL_BUFFERABLE BIT(1)
#define CHAN_PROTCTL_CACHEABLE BIT(2)
--
2.26.2
^ permalink raw reply related
* [PATCH v5 01/11] dt-bindings: dma: dw: Convert DW DMAC to DT binding
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Rob Herring, Andy Shevchenko
Cc: Serge Semin, Serge Semin, Rob Herring, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, linux-mips, dmaengine,
devicetree, linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
Modern device tree bindings are supposed to be created as YAML-files
in accordance with dt-schema. This commit replaces the Synopsis
Designware DMA controller legacy bare text bindings with YAML file.
The only required prorties are "compatible", "reg", "#dma-cells" and
"interrupts", which will be used by the driver to correctly find the
controller memory region and handle its events. The rest of the properties
are optional, since in case if either "dma-channels" or "dma-masters" isn't
specified, the driver will attempt to auto-detect the IP core
configuration.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-mips@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Move $ref to the root level of the properties. So do do with the
constraints.
- Discard default settings defined out of the property enum constraint.
- Replace "additionalProperties: false" with "unevaluatedProperties: false"
property.
- Remove a label definition from the binding example.
---
.../bindings/dma/snps,dma-spear1340.yaml | 161 ++++++++++++++++++
.../devicetree/bindings/dma/snps-dma.txt | 69 --------
2 files changed, 161 insertions(+), 69 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
delete mode 100644 Documentation/devicetree/bindings/dma/snps-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
new file mode 100644
index 000000000000..e7611840a7cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/snps,dma-spear1340.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys Designware DMA Controller
+
+maintainers:
+ - Viresh Kumar <vireshk@kernel.org>
+ - Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+allOf:
+ - $ref: "dma-controller.yaml#"
+
+properties:
+ compatible:
+ const: snps,dma-spear1340
+
+ "#dma-cells":
+ const: 3
+ description: |
+ First cell is a phandle pointing to the DMA controller. Second one is
+ the DMA request line number. Third cell is the memory master identifier
+ for transfers on dynamically allocated channel. Fourth cell is the
+ peripheral master identifier for transfers on an allocated channel.
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description: AHB interface reference clock.
+ const: hclk
+
+ dma-channels:
+ description: |
+ Number of DMA channels supported by the controller. In case if
+ not specified the driver will try to auto-detect this and
+ the rest of the optional parameters.
+ minimum: 1
+ maximum: 8
+
+ dma-requests:
+ minimum: 1
+ maximum: 16
+
+ dma-masters:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ Number of DMA masters supported by the controller. In case if
+ not specified the driver will try to auto-detect this and
+ the rest of the optional parameters.
+ minimum: 1
+ maximum: 4
+
+ chan_allocation_order:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ DMA channels allocation order specifier. Zero means ascending order
+ (first free allocated), while one - descending (last free allocated).
+ default: 0
+ enum: [0, 1]
+
+ chan_priority:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ DMA channels priority order. Zero means ascending channels priority
+ so the very first channel has the highest priority. While 1 means
+ descending priority (the last channel has the highest priority).
+ default: 0
+ enum: [0, 1]
+
+ block_size:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: Maximum block size supported by the DMA controller.
+ enum: [3, 7, 15, 31, 63, 127, 255, 511, 1023, 2047, 4095]
+
+ data-width:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: Data bus width per each DMA master in bytes.
+ items:
+ maxItems: 4
+ items:
+ enum: [4, 8, 16, 32]
+
+ data_width:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ deprecated: true
+ description: |
+ Data bus width per each DMA master in (2^n * 8) bits. This property is
+ deprecated. It' usage is discouraged in favor of data-width one. Moreover
+ the property incorrectly permits to define data-bus width of 8 and 16
+ bits, which is impossible in accordance with DW DMAC IP-core data book.
+ items:
+ maxItems: 4
+ items:
+ enum:
+ - 0 # 8 bits
+ - 1 # 16 bits
+ - 2 # 32 bits
+ - 3 # 64 bits
+ - 4 # 128 bits
+ - 5 # 256 bits
+ default: 0
+
+ multi-block:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ LLP-based multi-block transfer supported by hardware per
+ each DMA channel.
+ items:
+ maxItems: 8
+ items:
+ enum: [0, 1]
+ default: 1
+
+ snps,dma-protection-control:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ Bits one-to-one passed to the AHB HPROT[3:1] bus. Each bit setting
+ indicates the following features: bit 0 - privileged mode,
+ bit 1 - DMA is bufferable, bit 2 - DMA is cacheable.
+ default: 0
+ minimum: 0
+ maximum: 7
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - "#dma-cells"
+ - reg
+ - interrupts
+
+examples:
+ - |
+ dma-controller@fc000000 {
+ compatible = "snps,dma-spear1340";
+ reg = <0xfc000000 0x1000>;
+ interrupt-parent = <&vic1>;
+ interrupts = <12>;
+
+ dma-channels = <8>;
+ dma-requests = <16>;
+ dma-masters = <4>;
+ #dma-cells = <3>;
+
+ chan_allocation_order = <1>;
+ chan_priority = <1>;
+ block_size = <0xfff>;
+ data-width = <8 8>;
+ multi-block = <0 0 0 0 0 0 0 0>;
+ snps,max-burst-len = <16 16 4 4 4 4 4 4>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
deleted file mode 100644
index 0bedceed1963..000000000000
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ /dev/null
@@ -1,69 +0,0 @@
-* Synopsys Designware DMA Controller
-
-Required properties:
-- compatible: "snps,dma-spear1340"
-- reg: Address range of the DMAC registers
-- interrupt: Should contain the DMAC interrupt number
-- dma-channels: Number of channels supported by hardware
-- dma-requests: Number of DMA request lines supported, up to 16
-- dma-masters: Number of AHB masters supported by the controller
-- #dma-cells: must be <3>
-- chan_allocation_order: order of allocation of channel, 0 (default): ascending,
- 1: descending
-- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
- increase from chan n->0
-- block_size: Maximum block size supported by the controller
-- data-width: Maximum data width supported by hardware per AHB master
- (in bytes, power of 2)
-
-
-Deprecated properties:
-- data_width: Maximum data width supported by hardware per AHB master
- (0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
-
-
-Optional properties:
-- multi-block: Multi block transfers supported by hardware. Array property with
- one cell per channel. 0: not supported, 1 (default): supported.
-- snps,dma-protection-control: AHB HPROT[3:1] protection setting.
- The default value is 0 (for non-cacheable, non-buffered,
- unprivileged data access).
- Refer to include/dt-bindings/dma/dw-dmac.h for possible values.
-
-Example:
-
- dmahost: dma@fc000000 {
- compatible = "snps,dma-spear1340";
- reg = <0xfc000000 0x1000>;
- interrupt-parent = <&vic1>;
- interrupts = <12>;
-
- dma-channels = <8>;
- dma-requests = <16>;
- dma-masters = <2>;
- #dma-cells = <3>;
- chan_allocation_order = <1>;
- chan_priority = <1>;
- block_size = <0xfff>;
- data-width = <8 8>;
- };
-
-DMA clients connected to the Designware DMA controller must use the format
-described in the dma.txt file, using a four-cell specifier for each channel.
-The four cells in order are:
-
-1. A phandle pointing to the DMA controller
-2. The DMA request line number
-3. Memory master for transfers on allocated channel
-4. Peripheral master for transfers on allocated channel
-
-Example:
-
- serial@e0000000 {
- compatible = "arm,pl011", "arm,primecell";
- reg = <0xe0000000 0x1000>;
- interrupts = <0 35 0x4>;
- dmas = <&dmahost 12 0 1>,
- <&dmahost 13 1 0>;
- dma-names = "rx", "rx";
- };
--
2.26.2
^ permalink raw reply related
* [PATCH v5 08/11] dmaengine: dw: Add dummy device_caps callback
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
Since some DW DMA controllers (like one installed on Baikal-T1 SoC) may
have non-uniform DMA capabilities per device channels, let's add
the DW DMA specific device_caps callback to expose that specifics up to
the DMA consumer. It's a dummy function for now. We'll fill it in with
capabilities overrides in the next commits.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
---
drivers/dma/dw/core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index fb95920c429e..ceded21537e2 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1049,6 +1049,11 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
dev_vdbg(chan2dev(chan), "%s: done\n", __func__);
}
+static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
+{
+
+}
+
int do_dma_probe(struct dw_dma_chip *chip)
{
struct dw_dma *dw = chip->dw;
@@ -1214,6 +1219,7 @@ int do_dma_probe(struct dw_dma_chip *chip)
dw->dma.device_prep_dma_memcpy = dwc_prep_dma_memcpy;
dw->dma.device_prep_slave_sg = dwc_prep_slave_sg;
+ dw->dma.device_caps = dwc_caps;
dw->dma.device_config = dwc_config;
dw->dma.device_pause = dwc_pause;
dw->dma.device_resume = dwc_resume;
--
2.26.2
^ permalink raw reply related
* [PATCH v5 00/11] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar
Cc: Serge Semin, Serge Semin, Alexey Malahov, Maxim Kaurkin,
Pavel Parkhomenko, Ramil Zaripov, Ekaterina Skachko, Vadim Vlasov,
Alexey Kolotnikov, Thomas Bogendoerfer, Arnd Bergmann,
Andy Shevchenko, Rob Herring, linux-mips, dmaengine, devicetree,
linux-kernel
Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
with currently implemented in the kernel DW DMAC driver, but there are some
peculiarities which must be taken into account in order to have the device
fully supported.
First of all traditionally we replaced the legacy plain text-based dt-binding
file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
channels, which alas have different max burst length configuration.
In particular first two channels may burst up to 128 bits (16 bytes) at a time
while the rest of them just up to 32 bits. We must make sure that the DMA
subsystem doesn't set values exceeding these limitations otherwise the
controller will hang up. In third currently we discovered the problem in using
the DW APB SPI driver together with DW DMAC. The problem happens if there is no
natively implemented multi-block LLP transfers support and the SPI-transfer
length exceeds the max lock size. In this case due to asynchronous handling of
Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
the DMAC to asynchronously execute the transfers we'd have to at least warn
the user of the possible errors. In forth it's worth to set the DMA device max
segment size with max block size config specific to the DW DMA controller. It
shall help the DMA clients to create size-optimized SG-list items for the
controller. This in turn will cause less dw_desc allocations, less LLP
reinitializations, better DMA device performance.
Finally there is a bug in the algorithm of the nollp flag detection.
In particular even if DW DMAC parameters state the multi-block transfers
support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
by the driver true multi-block LLP functionality unusable. This happens cause'
if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
contiguous multi-block transfers will be only supported. We must take the
flag into account when detecting the LLP support otherwise the driver just
won't work correctly.
This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4
Changelog v2:
- Rearrange SoBs.
- Move $ref to the root level of the properties. So do do with the
constraints in the DT binding.
- Replace "additionalProperties: false" with "unevaluatedProperties: false"
property in the DT binding file.
- Discard default settings defined out of property enum constraint.
- Set default max-burst-len to 256 TR-WIDTH words in the DT binding.
- Discard noLLP and block_size accessors.
- Set max segment size of the DMA device structure with the DW DMA block size
config.
- Print warning if noLLP flag is set.
- Discard max burst length accessor.
- Add comment about why hardware accelerated LLP list support depends
on both MBLK_EN and HC_LLP configs setting.
- Use explicit bits state comparison operator in noLLP flag setting.
Link: https://lore.kernel.org/dmaengine/20200508105304.14065-1-Sergey.Semin@baikalelectronics.ru/
Changelog v3:
- Use the block_size found for the very first channel instead of looking for
the maximum of maximum block sizes.
- Don't define device-specific device_dma_parameters object, since it has
already been defined by the platform device core.
- Add more details into the property description about what limitations
snps,max-burst-len defines.
- Move commit fb7e3bbfc830 ("dmaengine: dw: Take HC_LLP flag into account for
noLLP auto-config") to the head of the series.
- Add a new patch "dmaengine: Introduce min burst length capability" as a
result of the discussion with Vinod and Andy regarding the burst length
capability.
- Add a new patch "dmaengine: Introduce max SG list entries capability"
suggested by Andy.
- Add a new patch "dmaengine: Introduce DMA-device device_caps callback" as
a result of the discussion with Vinud and Andy in the framework of DW DMA
burst and LLP capabilities.
- Add a new patch "dmaengine: dw: Add dummy device_caps callback" as a
preparation commit before setting the max_burst and max_sg_nents
DW DMA capabilities.
- Override the slave channel max_burst capability instead of calculating
the minimum value of max burst lengths and setting the DMA-device
generic capability.
- Add a new patch "dmaengine: dw: Initialize max_sg_nents with nollp flag".
This is required to fix the DW APB SSI issue of the Tx and Rx DMA
channels de-synchronization.
Link: https://lore.kernel.org/dmaengine/20200526225022.20405-1-Sergey.Semin@baikalelectronics.ru/
Changelog v4:
- Use explicit if-else statement when assigning the max_sg_nents field.
- Clamp the dst and src burst lengths in the generic dwc_config() method
instead of doing that in the encode_maxburst() callback.
- Define max_burst with u32 type in struct dw_dma_platform_data.
- Perform of_property_read_u32_array() with the platform data
max_burst member passed directly.
- Add a new patch "dmaengine: dw: Initialize min_burst capability",
which initializes the min_burst capability with 1.
- Fix of->if typo. It should be definitely "of" in the max_sg_list
capability description.
Link: https://lore.kernel.org/dmaengine/20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru
Changelog v5:
- Introduce macro with extreme min and max burst lengths supported by the
DW DMA controller. Define them in the patch with default min and max burst
length iintializations.
- Initialize max_burst length capability with extreme burst length supported
by the DW DMAC IP-core.
- Move DW_DMA_MAX_BURST macro definition to the patch "dmaengine: dw:
Initialize min and max burst DMA device capability".
- Add in-line comment at the point of the device_caps callback invocation.
- Add doc-comment for the device_caps member of struct dma_device
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: dmaengine@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (11):
dt-bindings: dma: dw: Convert DW DMAC to DT binding
dt-bindings: dma: dw: Add max burst transaction length property
dmaengine: Introduce min burst length capability
dmaengine: Introduce max SG list entries capability
dmaengine: Introduce DMA-device device_caps callback
dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config
dmaengine: dw: Set DMA device max segment size parameter
dmaengine: dw: Add dummy device_caps callback
dmaengine: dw: Initialize min and max burst DMA device capability
dmaengine: dw: Introduce max burst length hw config
dmaengine: dw: Initialize max_sg_nents capability
.../bindings/dma/snps,dma-spear1340.yaml | 176 ++++++++++++++++++
.../devicetree/bindings/dma/snps-dma.txt | 69 -------
drivers/dma/dmaengine.c | 12 ++
drivers/dma/dw/core.c | 48 ++++-
drivers/dma/dw/of.c | 5 +
drivers/dma/dw/regs.h | 3 +
include/linux/dmaengine.h | 16 ++
include/linux/platform_data/dma-dw.h | 5 +
8 files changed, 264 insertions(+), 70 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
delete mode 100644 Documentation/devicetree/bindings/dma/snps-dma.txt
--
2.26.2
^ permalink raw reply
* [PATCH v5 03/11] dmaengine: Introduce min burst length capability
From: Serge Semin @ 2020-05-29 14:40 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Dan Williams
Cc: Serge Semin, Serge Semin, Andy Shevchenko, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, Rob Herring, linux-mips,
devicetree, dmaengine, linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
Some hardware aside from default 0/1 may have greater minimum burst
transactions length constraints. Here we introduce the DMA device
and slave capability, which if required can be initialized by the DMA
engine driver with the device-specific value.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
---
drivers/dma/dmaengine.c | 1 +
include/linux/dmaengine.h | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index d31076d9ef25..b332ffe52780 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -590,6 +590,7 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
caps->src_addr_widths = device->src_addr_widths;
caps->dst_addr_widths = device->dst_addr_widths;
caps->directions = device->directions;
+ caps->min_burst = device->min_burst;
caps->max_burst = device->max_burst;
caps->residue_granularity = device->residue_granularity;
caps->descriptor_reuse = device->descriptor_reuse;
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index e1c03339918f..0c7403b27133 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -465,6 +465,7 @@ enum dma_residue_granularity {
* Since the enum dma_transfer_direction is not defined as bit flag for
* each type, the dma controller should set BIT(<TYPE>) and same
* should be checked by controller as well
+ * @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
* @cmd_pause: true, if pause is supported (i.e. for reading residue or
* for resume later)
@@ -478,6 +479,7 @@ struct dma_slave_caps {
u32 src_addr_widths;
u32 dst_addr_widths;
u32 directions;
+ u32 min_burst;
u32 max_burst;
bool cmd_pause;
bool cmd_resume;
@@ -769,6 +771,7 @@ struct dma_filter {
* Since the enum dma_transfer_direction is not defined as bit flag for
* each type, the dma controller should set BIT(<TYPE>) and same
* should be checked by controller as well
+ * @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
* @residue_granularity: granularity of the transfer residue reported
* by tx_status
@@ -839,6 +842,7 @@ struct dma_device {
u32 src_addr_widths;
u32 dst_addr_widths;
u32 directions;
+ u32 min_burst;
u32 max_burst;
bool descriptor_reuse;
enum dma_residue_granularity residue_granularity;
--
2.26.2
^ permalink raw reply related
* Re: [PATCH 3/3] ARM: dts: r8a7742-iwg21d-q7: Sound DMA support via DVC on DTS
From: Geert Uytterhoeven @ 2020-05-29 14:36 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Magnus Damm, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590611013-26029-4-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Wed, May 27, 2020 at 10:24 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Enable sound with DMA support on carrier board.
>
> DMA transfer uses DVC
>
> DMA DMApp
> [MEM] -> [SRC] -> [DVC] -> [SSIU] -> [SSI]
>
> DMA DMApp
> [MEM] <- [DVC] <- [SRC] <- [SSIU] <- [SSI]
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
To the best of my (limited) auto knowledge...
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
* Re: [PATCH 2/3] ARM: dts: r8a7742-iwg21d-q7: Enable SGTL5000 audio codec
From: Geert Uytterhoeven @ 2020-05-29 14:36 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Magnus Damm, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <CAMuHMdUORdW4EcDLsS0gF9nhQpmOQqceJQzkLXUb9BPs5Av9ig@mail.gmail.com>
On Fri, May 29, 2020 at 4:35 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Magnus,
Whoops, too much gmail-auto-guessing-completion.
Sorry for that.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
* Re: [PATCH 2/3] ARM: dts: r8a7742-iwg21d-q7: Enable SGTL5000 audio codec
From: Geert Uytterhoeven @ 2020-05-29 14:35 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Magnus Damm, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590611013-26029-3-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Magnus,
On Wed, May 27, 2020 at 10:24 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> This patch enables SGTL5000 audio codec on the carrier board.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
* Re: [PATCH 2/3] sdhci: sparx5: Add Sparx5 SoC eMMC driver
From: Lars Povlsen @ 2020-05-29 14:11 UTC (permalink / raw)
To: Adrian Hunter
Cc: Ulf Hansson, SoC Team, Microchip Linux Driver Support, linux-mmc,
devicetree, linux-arm-kernel, linux-kernel, Alexandre Belloni,
Lars Povlsen
In-Reply-To: <87sgfoozt8.fsf@soft-dev15.microsemi.net>
Lars Povlsen writes:
> Adrian Hunter writes:
>
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On 20/05/20 2:14 pm, Lars Povlsen wrote:
>>>
>>> Lars Povlsen writes:
>>>
>>>> Adrian Hunter writes:
>>>>
>>>>> On 13/05/20 4:31 pm, Lars Povlsen wrote:
>>>>>> This adds the eMMC driver for the Sparx5 SoC. It is based upon the
>>>>>> designware IP, but requires some extra initialization and quirks.
>>>>>>
>>>>>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>>>>>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>>>>>> ---
>>> {Snip]
>>>>>> +};
>>>>>> +
>>>>>> +static const struct sdhci_pltfm_data sdhci_sparx5_pdata = {
>>>>>> + .quirks = 0,
>>>>>> + .quirks2 = SDHCI_QUIRK2_HOST_NO_CMD23 | /* Card quirk */
>>>>>
>>>>> If this is a card quirk then it should be in drivers/mmc/core/quirks.h not here.
>>>>
>>>
>>> Adrian, I had a go at changing the controller quirk to a card quirk.
>>>
>>> Unfortunately, SDHCI_QUIRK2_HOST_NO_CMD23 does not directly translate to
>>> MMC_QUIRK_BLK_NO_CMD23, as for 'do_rel_wr' in mmc_blk_rw_rq_prep(), it
>>> will *still* use MMC_SET_BLOCK_COUNT (cmd23), causing the issue.
>>>
>>> We are using a ISSI "IS004G" device, and so I have gone through the
>>> motions of adding it to quirks.h. The comment before the list of devices
>>> using MMC_QUIRK_BLK_NO_CMD23 suggest working around a performance issue,
>>> which is not exactly the issue I'm seeing. I'm seeing combinations of
>>> CMD_TOUT_ERR, DATA_CRC_ERR and DATA_END_BIT_ERR whenever a cmd23 is
>>> issued.
>>>
>>> I have not been able to test the controller with another eMMC device
>>> yet, but I expect its not the controller at fault.
>>>
>>> So, I'm a little bit in doubt of how to proceed - either keep the quirk
>>> as a controller quirk - or make a *new* card quirk (with
>>> SDHCI_QUIRK2_HOST_NO_CMD23 semantics)?
>>>
>>> Anybody else have had experience with ISSI eMMC devices?
>>>
>>> I have also tried to use DT sdhci-caps-mask, but MMC_CAP_CMD23 is not
>>> read from the controller just (unconditionally) set in sdhci.c - so that
>>> doesn't fly either.
>>>
>>> Any suggestions?
>>
>> It is up to you. In the future, you may want to distinguish devices that
>> have this problem from ones that do not.
>>
>> If you are not sure it is the ISSI eMMC, and maybe not the host controller,
>> then might it be the board? Perhaps make SDHCI_QUIRK2_HOST_NO_CMD23
>> conditional on the particular compatibility string?
>>
>> At a minimum, change the "/* Card quirk */" comment to a fuller explanation.
>>
>
> Adrian, I'm getting a board ready with another eMMC device, and we're
> also trying to contact ISSI for info.
>
> My hope is to at least verify whether this is a controller or a card
> issue one way or the other. Then, I'll choose an appropriate solution
> for it.
>
> Thank you for your advice so far.
>
I was able to try on a board with another eMMC card (panasonic), so that
clearly casts the suspicion on the controller, and ISSI is in the clear.
I reintroduced the original SDHCI_QUIRK2_HOST_NO_CMD23 quirk, with a
"Controller issue" comment.
I will refresh the series shortly.
Cheers,
> ---Lars
>
>>>
>>>> Yes, its supposedly a card quirk. I'll see to use the card quirks
>>>> methods in place.
>>>>
>>>
--
Lars Povlsen,
Microchip
^ 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