public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: "Stefan Brüns" <stefan.bruens@rwth-aachen.de>
Cc: linux-sunxi@googlegroups.com,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Chen-Yu Tsai <wens@csie.org>,
	devicetree@vger.kernel.org, dmaengine@vger.kernel.org,
	Vinod Koul <vinod.koul@intel.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64
Date: Fri,  1 Sep 2017 01:31:35 +0100	[thread overview]
Message-ID: <20170901003135.10058-1-andre.przywara@arm.com> (raw)
In-Reply-To: <20170830233609.13855-4-stefan.bruens@rwth-aachen.de>

Hi,

On 31/08/17 00:36, Stefan Brüns wrote:
> The A64 SoC has the same dma engine as the H3 (sun8i), with a
> reduced amount of physical channels. Add the proper config data
> and compatible string to support it.

...

> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 5f4eee4513e5..6a17c5d63582 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
>  	.nr_max_vchans   = 34,
>  	.dmac_variant    = DMAC_VARIANT_H3,
>  };
> +
> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {
> +	.nr_max_channels = 8,
> +	.nr_max_requests = 27,
> +	.nr_max_vchans   = 38,
> +	.dmac_variant    = DMAC_VARIANT_H3,
>  };
>  
>  static const struct of_device_id sun6i_dma_match[] = {
> @@ -1075,6 +1081,7 @@ static const struct of_device_id sun6i_dma_match[] = {
>  	{ .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg },
>  	{ .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg },
>  	{ .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
> +	{ .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg },
>  	{ /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, sun6i_dma_match);

I was wondering if should use the opportunity to expose those values as
DT properties instead of hard-wiring them to a compatible string in the
driver every time we add support for a new SoC?
We could introduce a new compatible string (say: "allwinner,sunxi-dma"),
then describe properties for the number of channels and requests and
vchans and parse those from the DT at probe time.
With this we might be able to support future SoCs without Linux *driver*
changes, by just providing the right DT. This would have worked already
for instance for the A83T support, which just changed those values.

For instance with this quick patch below (just compile tested, and without
your refactoring).
The DT node would then read something like:
	dma: dma-controller@01c02000 {
		compatible = "allwinner,sun50i-a64-dma",
			     "allwinner,sunxi-dma";
		reg = <0x01c02000 0x1000>;
		interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
		clocks = <&ccu CLK_BUS_DMA>;
		resets = <&ccu RST_BUS_DMA>;
		#dma-cells = <1>;
		allwinner,max_channels = <8>;
		allwinner,max_requests = <27>;
		allwinner,max_vchans = <38>;
	};

Cheers,
Andre.

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index a2358780ab2c..5ae8032f2065 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -1033,6 +1033,7 @@ static const struct of_device_id sun6i_dma_match[] = {
 	{ .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg },
 	{ .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg },
 	{ .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
+	{ .compatible = "allwinner,sunxi-dma", .data = NULL },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, sun6i_dma_match);
@@ -1051,7 +1052,43 @@ static int sun6i_dma_probe(struct platform_device *pdev)
 	device = of_match_device(sun6i_dma_match, &pdev->dev);
 	if (!device)
 		return -ENODEV;
-	sdc->cfg = device->data;
+	if (!device->data) {
+		struct sun6i_dma_config *config;
+
+		config = devm_kmalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
+		if (!config)
+			return -ENOMEM;
+
+		ret = of_property_read_u32(pdev->dev.of_node,
+					   "allwinner,max_channels",
+					   &config->nr_max_channels);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"missing allwinner,max_channels property\n");
+			return ret;
+		}
+
+		ret = of_property_read_u32(pdev->dev.of_node,
+					   "allwinner,max_requests",
+					   &config->nr_max_requests);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"missing allwinner,max_requests property\n");
+			return ret;
+		}
+
+		ret = of_property_read_u32(pdev->dev.of_node,
+					   "allwinner,max_vchans",
+					   &config->nr_max_vchans);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"missing allwinner,max_vchans property\n");
+			return ret;
+		}
+		sdc->cfg = config;
+	} else {
+		sdc->cfg = device->data;
+	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	sdc->base = devm_ioremap_resource(&pdev->dev, res);
-- 
2.14.1

  parent reply	other threads:[~2017-09-01  0:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-30 23:36 [PATCH 0/3] dmaengine: Fix DMA on current allwinner SoCs, add A64 support Stefan Brüns
2017-08-30 23:36 ` [PATCH 1/3] dmaengine: sun6i: Correct DMA support on H3 Stefan Brüns
2017-08-31 14:51   ` Maxime Ripard
2017-09-01  3:04     ` Stefan Bruens
2017-09-01 13:35       ` Maxime Ripard
2017-09-01 14:42         ` Brüns, Stefan
2017-09-04  6:50           ` Maxime Ripard
2017-08-30 23:36 ` [PATCH 2/3] arm64: allwinner: a64: Add device node for DMA controller Stefan Brüns
2017-09-11 22:00   ` Rob Herring
2017-08-30 23:36 ` [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64 Stefan Brüns
2017-08-31 11:44   ` Code Kipper
2017-08-31 14:52   ` Maxime Ripard
2017-08-31 16:35     ` [linux-sunxi] " Code Kipper
2017-09-01  0:31   ` Andre Przywara [this message]
2017-09-01  1:19     ` Stefan Bruens
2017-09-01 22:32       ` André Przywara
2017-09-02  0:38         ` Stefan Bruens
2017-09-02  2:02         ` Stefan Bruens
2017-09-03 23:14           ` André Przywara
2017-09-01  6:04     ` Maxime Ripard
2017-09-01 22:35       ` André Przywara
2017-09-04  7:04         ` Maxime Ripard
2017-09-04  8:14           ` André Przywara
2017-09-08 14:39             ` Maxime Ripard
2017-09-08 14:57               ` Andre Przywara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170901003135.10058-1-andre.przywara@arm.com \
    --to=andre.przywara@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=robh+dt@kernel.org \
    --cc=stefan.bruens@rwth-aachen.de \
    --cc=vinod.koul@intel.com \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox