[{"id":1762344,"web_url":"http://patchwork.ozlabs.org/comment/1762344/","msgid":"","list_archive_url":null,"date":"2017-09-03T23:23:09","subject":"Re: [PATCH 01/10] dmaengine: sun6i: Correct setting of clock\n\tautogating register for A83T/H3","submitter":{"id":61837,"url":"http://patchwork.ozlabs.org/api/people/61837/","name":"Andre Przywara","email":"andre.przywara@arm.com"},"content":"On 03/09/17 23:40, Stefan Brüns wrote:\n> The H83T uses a compatible string different from the A23, but requires\n\n A83T\n\n> the same clock autogating register setting.\n> \n> The H3 also requires setting the clock autogating register, but has\n> the register at a different offset.\n> \n> Some currently available SoCs not yet supported by the sun6i-dma driver\n> will require new compatible strings. These SoCs either follow the A23\n> register model (e.g. V3s) or the H3 register model (A64, R40), so a new\n> variable is added to the config struct to group SoCs with common register\n> models.\n\nAs mentioned in that other mail, using the actual properties as names\nhere instead of grouping them to rather arbitrary groups seems more\nuseful and future-proof to me and should be easier to read.\nIn this case this should simplify this patch:\nsun8i_a23_dma_cfg = {\n \t.nr_max_channels = 8,\n \t.nr_max_requests = 24,\n \t.nr_max_vchans = 37,\n+\t.auto_clock_gate = 0x20,\n...\n-\tif (of_device_is_compatible(pdev->dev.of_node,\n-\t\t\t\t \"allwinner,sun8i-a23-dma\"))\n-\t\twritel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);\n+\tif (sdc->cfg->auto_clock_gate)\n+\t\twritel(SUN8I_DMA_GATE_ENABLE,\n+\t\t sdc->base + sdc->cfg->auto_clock_gate);\n\n> Signed-off-by: Stefan Brüns \n> ---\n> drivers/dma/sun6i-dma.c | 34 +++++++++++++++++++++++++++++++---\n> 1 file changed, 31 insertions(+), 3 deletions(-)\n> \n> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> index a2358780ab2c..1d9b3be30d22 100644\n> --- a/drivers/dma/sun6i-dma.c\n> +++ b/drivers/dma/sun6i-dma.c\n> @@ -48,6 +48,9 @@\n> #define SUN8I_DMA_GATE\t\t0x20\n> #define SUN8I_DMA_GATE_ENABLE\t0x4\n> \n> +#define SUNXI_H3_SECURITE_REG\t\t0x20\n\ntypo?\t SUNXI_H3_SECURITY_REG ?\n\nCheers,\nAndre.\n\n> +#define SUNXI_H3_DMA_GATE\t\t0x28\n> +#define SUNXI_H3_DMA_GATE_ENABLE\t0x4\n> /*\n> * Channels specific registers\n> */\n> @@ -90,6 +93,21 @@\n> #define NORMAL_WAIT\t8\n> #define DRQ_SDRAM\t1\n> \n> +/*\n> + * DMA Controller generations\n> + *\n> + * Newer SoC generations changed or added some register definitions:\n> + * - A23 added a clock gate register\n> + * - H3 has a different offset for the clock gating register,\n> + * the burst length field has a different offset in the channel\n> + * configuration register, also additional burst lengths/widths.\n> + */\n> +enum dmac_variant {\n> +\tDMAC_VARIANT_A31,\n> +\tDMAC_VARIANT_A23,\n> +\tDMAC_VARIANT_H3,\n> +};\n> +\n> /*\n> * Hardware channels / ports representation\n> *\n> @@ -101,6 +119,7 @@ struct sun6i_dma_config {\n> \tu32 nr_max_channels;\n> \tu32 nr_max_requests;\n> \tu32 nr_max_vchans;\n> +\tenum dmac_variant dmac_variant;\n> };\n> \n> /*\n> @@ -998,6 +1017,7 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {\n> \t.nr_max_channels = 16,\n> \t.nr_max_requests = 30,\n> \t.nr_max_vchans = 53,\n> +\t.dmac_variant = DMAC_VARIANT_A31,\n> };\n> \n> /*\n> @@ -1009,23 +1029,29 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {\n> \t.nr_max_channels = 8,\n> \t.nr_max_requests = 24,\n> \t.nr_max_vchans = 37,\n> +\t.dmac_variant = DMAC_VARIANT_A23,\n> };\n> \n> static struct sun6i_dma_config sun8i_a83t_dma_cfg = {\n> \t.nr_max_channels = 8,\n> \t.nr_max_requests = 28,\n> \t.nr_max_vchans = 39,\n> +\t.dmac_variant = DMAC_VARIANT_A23,\n> };\n> \n> /*\n> * The H3 has 12 physical channels, a maximum DRQ port id of 27,\n> * and a total of 34 usable source and destination endpoints.\n> + * It also supports additional burst lengths and bus widths,\n> + * and the burst length fields have different offsets.\n> */\n> \n> static struct sun6i_dma_config sun8i_h3_dma_cfg = {\n> \t.nr_max_channels = 12,\n> \t.nr_max_requests = 27,\n> \t.nr_max_vchans = 34,\n> +\t.dmac_variant = DMAC_VARIANT_H3,\n> +};\n> };\n> \n> static const struct of_device_id sun6i_dma_match[] = {\n> @@ -1177,11 +1203,13 @@ static int sun6i_dma_probe(struct platform_device *pdev)\n> \t/*\n> \t * sun8i variant requires us to toggle a dma gating register,\n> \t * as seen in Allwinner's SDK. This register is not documented\n> -\t * in the A23 user manual.\n> +\t * in the A23 user manual, but appears in e.g. the H83T manual.\n> +\t * For the H3, H5 and A64, the register has a different location\n> \t */\n> -\tif (of_device_is_compatible(pdev->dev.of_node,\n> -\t\t\t\t \"allwinner,sun8i-a23-dma\"))\n> +\tif (sdc->cfg->dmac_variant == DMAC_VARIANT_A23)\n> \t\twritel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);\n> +\telse if (sdc->cfg->dmac_variant == DMAC_VARIANT_H3)\n> +\t\twritel(SUNXI_H3_DMA_GATE_ENABLE, sdc->base + SUNXI_H3_DMA_GATE);\n> \n> \treturn 0;\n> \n> \n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xlpz01ll1z9t0F\n\tfor ;\n\tMon, 4 Sep 2017 09:26:52 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753193AbdICX0u (ORCPT\n\t);\n\tSun, 3 Sep 2017 19:26:50 -0400","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:52878 \"EHLO\n\tfoss.arm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1753111AbdICX0u (ORCPT );\n\tSun, 3 Sep 2017 19:26:50 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 920CA2B;\n\tSun, 3 Sep 2017 16:26:49 -0700 (PDT)","from [192.168.3.22] (usa-sjc-mx-foss1.foss.arm.com\n\t[217.140.101.70])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tBCD743F58F; Sun, 3 Sep 2017 16:26:47 -0700 (PDT)"],"Subject":"Re: [PATCH 01/10] dmaengine: sun6i: Correct setting of clock\n\tautogating register for A83T/H3","To":"=?utf-8?q?Stefan_Br=C3=BCns?= ,\n\tlinux-sunxi@googlegroups.com","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-2-stefan.bruens@rwth-aachen.de>","Cc":"devicetree@vger.kernel.org, dmaengine@vger.kernel.org,\n\tVinod Koul ,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tMaxime Ripard ,\n\tChen-Yu Tsai , Rob Herring ,\n\tCode Kipper ","From":"=?utf-8?q?Andr=C3=A9_Przywara?= ","Organization":"ARM Ltd.","Message-ID":"","Date":"Mon, 4 Sep 2017 00:23:09 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<20170903224100.17893-2-stefan.bruens@rwth-aachen.de>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762346,"web_url":"http://patchwork.ozlabs.org/comment/1762346/","msgid":"<1526a6b4-1962-256d-1ada-ef9c7d95e6b1@arm.com>","list_archive_url":null,"date":"2017-09-03T23:37:58","subject":"Re: [PATCH 08/10] dmaengine: sun6i: Add support for Allwinner A64\n\tand compatibles","submitter":{"id":61837,"url":"http://patchwork.ozlabs.org/api/people/61837/","name":"Andre Przywara","email":"andre.przywara@arm.com"},"content":"Hi,\n\nOn 03/09/17 23:40, Stefan Brüns wrote:\n> The A64 SoC has the same dma engine as the H3 (sun8i), with a\n> reduced amount of physical channels. To allow future reuse of the\n> compatible, leave the channel count etc. in the config data blank\n> and retrieve it from the devicetree.\n> \n> Signed-off-by: Stefan Brüns \n> ---\n> drivers/dma/sun6i-dma.c | 12 ++++++++++++\n> 1 file changed, 12 insertions(+)\n> \n> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> index bd4c2e4a759b..4fae7ffad549 100644\n> --- a/drivers/dma/sun6i-dma.c\n> +++ b/drivers/dma/sun6i-dma.c\n> @@ -1076,6 +1076,16 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {\n> \t.nr_max_vchans = 34,\n> \t.dmac_variant = DMAC_VARIANT_H3,\n> };\n> +\n> +/*\n> + * The A64 binding uses the number of dma channels from the\n> + * device tree node.\n> + */\n> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {\n> +\t.nr_max_channels = 0,\n> +\t.nr_max_requests = 0,\n\nBut this does not work with the \"dma-requests\" property being optional\naccording to the binding spec? Either we put the value for the A64 in\nhere (and thus force the R40 and others to specify this in the DT) or we\nmap the \"0\" from struct config to DMA_CHAN_MAX_DRQ in the probe function.\n\n> +\t.nr_max_vchans = 0,\n> +\t.dmac_variant = DMAC_VARIANT_H3,\n> };\n> \n> static const struct of_device_id sun6i_dma_match[] = {\n> @@ -1083,6 +1093,7 @@ static const struct of_device_id sun6i_dma_match[] = {\n> \t{ .compatible = \"allwinner,sun8i-a23-dma\", .data = &sun8i_a23_dma_cfg },\n> \t{ .compatible = \"allwinner,sun8i-a83t-dma\", .data = &sun8i_a83t_dma_cfg },\n> \t{ .compatible = \"allwinner,sun8i-h3-dma\", .data = &sun8i_h3_dma_cfg },\n> +\t{ .compatible = \"allwinner,sun50i-a64-dma\", .data = &sun50i_a64_dma_cfg },\n> \t{ /* sentinel */ }\n> };\n> MODULE_DEVICE_TABLE(of, sun6i_dma_match);\n> @@ -1090,6 +1101,7 @@ MODULE_DEVICE_TABLE(of, sun6i_dma_match);\n> static int sun6i_dma_probe(struct platform_device *pdev)\n> {\n> \tconst struct of_device_id *device;\n> +\tstruct device_node *np = pdev->dev.of_node;\n\nIs this some rebase/split artefact?\n\nCheers,\nAndre.\n\n> \tstruct sun6i_dma_dev *sdc;\n> \tstruct resource *res;\n> \tint ret, i;\n> \n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xlqJ51zlbz9t2y\n\tfor ;\n\tMon, 4 Sep 2017 09:41:41 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753037AbdICXlj (ORCPT\n\t);\n\tSun, 3 Sep 2017 19:41:39 -0400","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:52948 \"EHLO\n\tfoss.arm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1753013AbdICXli (ORCPT );\n\tSun, 3 Sep 2017 19:41:38 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7A08515A2;\n\tSun, 3 Sep 2017 16:41:38 -0700 (PDT)","from [192.168.3.22] (usa-sjc-mx-foss1.foss.arm.com\n\t[217.140.101.70])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t8E0263F58F; Sun, 3 Sep 2017 16:41:36 -0700 (PDT)"],"Subject":"Re: [PATCH 08/10] dmaengine: sun6i: Add support for Allwinner A64\n\tand compatibles","To":"=?utf-8?q?Stefan_Br=C3=BCns?= ,\n\tlinux-sunxi@googlegroups.com","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-9-stefan.bruens@rwth-aachen.de>","Cc":"devicetree@vger.kernel.org, dmaengine@vger.kernel.org,\n\tVinod Koul ,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tMaxime Ripard ,\n\tChen-Yu Tsai , Rob Herring ,\n\tCode Kipper ","From":"=?utf-8?q?Andr=C3=A9_Przywara?= ","Organization":"ARM Ltd.","Message-ID":"<1526a6b4-1962-256d-1ada-ef9c7d95e6b1@arm.com>","Date":"Mon, 4 Sep 2017 00:37:58 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<20170903224100.17893-9-stefan.bruens@rwth-aachen.de>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762348,"web_url":"http://patchwork.ozlabs.org/comment/1762348/","msgid":"","list_archive_url":null,"date":"2017-09-03T23:44:54","subject":"Re: [PATCH 07/10] dmaengine: sun6i: Retrieve channel count/max\n\trequest from devicetree","submitter":{"id":61837,"url":"http://patchwork.ozlabs.org/api/people/61837/","name":"Andre Przywara","email":"andre.przywara@arm.com"},"content":"Hi,\n\nOn 03/09/17 23:40, Stefan Brüns wrote:\n> To avoid introduction of a new compatible for each small SoC/DMA controller\n> variation, move the definition of the channel count to the devicetree.\n> \n> The number of vchans is no longer explicit, but limited by the highest\n> port/DMA request number. The result is a slight overallocation for SoCs\n> with a sparse port mapping.\n> \n> Signed-off-by: Stefan Brüns \n> ---\n> drivers/dma/sun6i-dma.c | 35 ++++++++++++++++++++++++++++++++++-\n> 1 file changed, 34 insertions(+), 1 deletion(-)\n> \n> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> index c69dadb853d2..bd4c2e4a759b 100644\n> --- a/drivers/dma/sun6i-dma.c\n> +++ b/drivers/dma/sun6i-dma.c\n> @@ -42,6 +42,9 @@\n> \n> #define DMA_STAT\t\t0x30\n> \n> +/* Offset between DMA_IRQ_EN and DMA_IRQ_STAT limits number of channels */\n> +#define DMA_MAX_CHANNELS\t(DMA_IRQ_CHAN_NR * 0x10 / 4)\n> +\n> /*\n> * sun8i specific registers\n> */\n> @@ -65,7 +68,8 @@\n> #define DMA_CHAN_LLI_ADDR\t0x08\n> \n> #define DMA_CHAN_CUR_CFG\t0x0c\n> -#define DMA_CHAN_CFG_SRC_DRQ(x)\t\t((x) & 0x1f)\n> +#define DMA_CHAN_MAX_DRQ\t\t0x1f\n> +#define DMA_CHAN_CFG_SRC_DRQ(x)\t\t((x) & DMA_CHAN_MAX_DRQ)\n> #define DMA_CHAN_CFG_SRC_IO_MODE\tBIT(5)\n> #define DMA_CHAN_CFG_SRC_LINEAR_MODE\t(0 << 5)\n> #define DMA_CHAN_CFG_SRC_BURST_A31(x)\t(((x) & 0x3) << 7)\n> @@ -1173,6 +1177,35 @@ static int sun6i_dma_probe(struct platform_device *pdev)\n> \tsdc->num_vchans = sdc->cfg->nr_max_vchans;\n> \tsdc->max_request = sdc->cfg->nr_max_requests;\n> \n> +\tret = of_property_read_u32(np, \"dma-channels\", &sdc->num_pchans);\n> +\tif (ret && !sdc->num_pchans) {\n> +\t\tdev_err(&pdev->dev, \"Can't get dma-channels.\\n\");\n> +\t\treturn ret;\n> +\t}\n> +\n> +\tif (sdc->num_pchans > DMA_MAX_CHANNELS) {\n> +\t\tdev_err(&pdev->dev, \"Number of dma-channels out of range.\\n\");\n> +\t\treturn -EINVAL;\n> +\t}\n> +\n> +\tret = of_property_read_u32(np, \"dma-requests\", &sdc->max_request);\n> +\tif (ret && !sdc->max_request) {\n> +\t\tdev_info(&pdev->dev, \"Missing dma-requests, using %u.\\n\",\n> +\t\t\t DMA_CHAN_MAX_DRQ);\n\nMmmh, is this mapping of \"!sdc->max_request\" -> DMA_CHAN_MAX_DRQ\nimplemented somewhere else? Or is it just missing here:\n\t\tsdc->max_request = DMA_CHAN_MAX_DRQ;\n\nOtherwise this is looking good, thanks for picking up the DT property\napproach!\n\nCheers,\nAndre.\n\n> +\t}\n> +\n> +\tif (sdc->max_request > DMA_CHAN_MAX_DRQ) {\n> +\t\tdev_err(&pdev->dev, \"Value of dma-requests out of range.\\n\");\n> +\t\treturn -EINVAL;\n> +\t}\n> +\n> +\t/*\n> +\t * If the number of vchans is not specified, derive it from the\n> +\t * highest port number, at most one channel per port and direction.\n> +\t */\n> +\tif (!sdc->num_vchans)\n> +\t\tsdc->num_vchans = 2 * (sdc->max_request + 1);\n> +\n> \tsdc->pchans = devm_kcalloc(&pdev->dev, sdc->num_pchans,\n> \t\t\t\t sizeof(struct sun6i_pchan), GFP_KERNEL);\n> \tif (!sdc->pchans)\n> \n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xlqS85XhPz9sNq\n\tfor ;\n\tMon, 4 Sep 2017 09:48:40 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753037AbdICXsf (ORCPT\n\t);\n\tSun, 3 Sep 2017 19:48:35 -0400","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:53004 \"EHLO\n\tfoss.arm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1753019AbdICXse (ORCPT );\n\tSun, 3 Sep 2017 19:48:34 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7EAE415A2;\n\tSun, 3 Sep 2017 16:48:34 -0700 (PDT)","from [192.168.3.22] (usa-sjc-mx-foss1.foss.arm.com\n\t[217.140.101.70])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t925303F58F; Sun, 3 Sep 2017 16:48:32 -0700 (PDT)"],"Subject":"Re: [PATCH 07/10] dmaengine: sun6i: Retrieve channel count/max\n\trequest from devicetree","To":"=?utf-8?q?Stefan_Br=C3=BCns?= ,\n\tlinux-sunxi@googlegroups.com","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-8-stefan.bruens@rwth-aachen.de>","Cc":"devicetree@vger.kernel.org, dmaengine@vger.kernel.org,\n\tVinod Koul ,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tMaxime Ripard ,\n\tChen-Yu Tsai , Rob Herring ,\n\tCode Kipper ","From":"=?utf-8?q?Andr=C3=A9_Przywara?= ","Organization":"ARM Ltd.","Message-ID":"","Date":"Mon, 4 Sep 2017 00:44:54 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<20170903224100.17893-8-stefan.bruens@rwth-aachen.de>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762352,"web_url":"http://patchwork.ozlabs.org/comment/1762352/","msgid":"<2286861.ip18xhFNEq@pebbles.site>","list_archive_url":null,"date":"2017-09-04T00:12:07","subject":"Re: [PATCH 07/10] dmaengine: sun6i: Retrieve channel count/max\n\trequest from devicetree","submitter":{"id":67055,"url":"http://patchwork.ozlabs.org/api/people/67055/","name":"Stefan Brüns","email":"stefan.bruens@rwth-aachen.de"},"content":"On Montag, 4. September 2017 01:44:54 CEST André Przywara wrote:\n> Hi,\n> \n> On 03/09/17 23:40, Stefan Brüns wrote:\n> > To avoid introduction of a new compatible for each small SoC/DMA\n> > controller\n> > variation, move the definition of the channel count to the devicetree.\n> > \n> > The number of vchans is no longer explicit, but limited by the highest\n> > port/DMA request number. The result is a slight overallocation for SoCs\n> > with a sparse port mapping.\n> > \n> > Signed-off-by: Stefan Brüns \n> > ---\n> > \n> > drivers/dma/sun6i-dma.c | 35 ++++++++++++++++++++++++++++++++++-\n> > 1 file changed, 34 insertions(+), 1 deletion(-)\n> > \n> > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> > index c69dadb853d2..bd4c2e4a759b 100644\n> > --- a/drivers/dma/sun6i-dma.c\n> > +++ b/drivers/dma/sun6i-dma.c\n> > @@ -42,6 +42,9 @@\n> > \n> > #define DMA_STAT\t\t0x30\n> > \n> > +/* Offset between DMA_IRQ_EN and DMA_IRQ_STAT limits number of channels\n> > */\n> > +#define DMA_MAX_CHANNELS\t(DMA_IRQ_CHAN_NR * 0x10 / 4)\n> > +\n> > \n> > /*\n> > \n> > * sun8i specific registers\n> > */\n> > \n> > @@ -65,7 +68,8 @@\n> > \n> > #define DMA_CHAN_LLI_ADDR\t0x08\n> > \n> > #define DMA_CHAN_CUR_CFG\t0x0c\n> > \n> > -#define DMA_CHAN_CFG_SRC_DRQ(x)\t\t((x) & 0x1f)\n> > +#define DMA_CHAN_MAX_DRQ\t\t0x1f\n> > +#define DMA_CHAN_CFG_SRC_DRQ(x)\t\t((x) & DMA_CHAN_MAX_DRQ)\n> > \n> > #define DMA_CHAN_CFG_SRC_IO_MODE\tBIT(5)\n> > #define DMA_CHAN_CFG_SRC_LINEAR_MODE\t(0 << 5)\n> > #define DMA_CHAN_CFG_SRC_BURST_A31(x)\t(((x) & 0x3) << 7)\n> > \n> > @@ -1173,6 +1177,35 @@ static int sun6i_dma_probe(struct platform_device\n> > *pdev)> \n> > \tsdc->num_vchans = sdc->cfg->nr_max_vchans;\n> > \tsdc->max_request = sdc->cfg->nr_max_requests;\n> > \n> > +\tret = of_property_read_u32(np, \"dma-channels\", &sdc->num_pchans);\n> > +\tif (ret && !sdc->num_pchans) {\n> > +\t\tdev_err(&pdev->dev, \"Can't get dma-channels.\\n\");\n> > +\t\treturn ret;\n> > +\t}\n> > +\n> > +\tif (sdc->num_pchans > DMA_MAX_CHANNELS) {\n> > +\t\tdev_err(&pdev->dev, \"Number of dma-channels out of range.\\n\");\n> > +\t\treturn -EINVAL;\n> > +\t}\n> > +\n> > +\tret = of_property_read_u32(np, \"dma-requests\", &sdc->max_request);\n> > +\tif (ret && !sdc->max_request) {\n> > +\t\tdev_info(&pdev->dev, \"Missing dma-requests, using %u.\\n\",\n> > +\t\t\t DMA_CHAN_MAX_DRQ);\n> \n> Mmmh, is this mapping of \"!sdc->max_request\" -> DMA_CHAN_MAX_DRQ\n> implemented somewhere else? Or is it just missing here:\n> \t\tsdc->max_request = DMA_CHAN_MAX_DRQ;\n\nWell spotted, that assignment is actually missing.\n\nWith this line added, your comment for patch 8/10 should also be addressed \n(regarding the default value).\n \n> Otherwise this is looking good, thanks for picking up the DT property\n> approach!\n> \n> Cheers,\n> Andre.\n> \n\nKind regards,\n\nStefan","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xlqzZ3J7tz9sNr\n\tfor ;\n\tMon, 4 Sep 2017 10:12:26 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753124AbdIDAML convert rfc822-to-8bit (ORCPT\n\t);\n\tSun, 3 Sep 2017 20:12:11 -0400","from mail-out-1.itc.rwth-aachen.de ([134.130.5.46]:62337 \"EHLO\n\tmail-out-1.itc.rwth-aachen.de\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1753036AbdIDAML (ORCPT\n\t); Sun, 3 Sep 2017 20:12:11 -0400","from rwthex-w2-b.rwth-ad.de ([134.130.26.159])\n\tby mail-in-1.itc.rwth-aachen.de with ESMTP; 04 Sep 2017 02:12:09 +0200","from pebbles.site (92.225.242.208) by rwthex-w2-b.rwth-ad.de\n\t(2002:8682:1a9f::8682:1a9f) with Microsoft SMTP Server (TLS) id\n\t15.0.1320.4; Mon, 4 Sep 2017 02:12:08 +0200"],"X-IronPort-AV":"E=Sophos;i=\"5.41,472,1498514400\"; d=\"scan'208\";a=\"11607973\"","From":"Stefan Bruens ","To":"=?iso-8859-1?q?Andr=E9?= Przywara ","CC":", ,\n\t, Vinod Koul ,\n\t, ,\n\tMaxime Ripard ,\n\tChen-Yu Tsai , Rob Herring ,\n\tCode Kipper ","Subject":"Re: [PATCH 07/10] dmaengine: sun6i: Retrieve channel count/max\n\trequest from devicetree","Date":"Mon, 4 Sep 2017 02:12:07 +0200","Message-ID":"<2286861.ip18xhFNEq@pebbles.site>","In-Reply-To":"","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-8-stefan.bruens@rwth-aachen.de>\n\t","MIME-Version":"1.0","Content-Transfer-Encoding":"8BIT","Content-Type":"text/plain; charset=\"iso-8859-1\"","X-Originating-IP":"[92.225.242.208]","X-ClientProxiedBy":"rwthex-w1-a.rwth-ad.de (2002:8682:1a9c::8682:1a9c) To\n\trwthex-w2-b.rwth-ad.de (2002:8682:1a9f::8682:1a9f)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762354,"web_url":"http://patchwork.ozlabs.org/comment/1762354/","msgid":"<5368262.YgOfWCUmp3@pebbles.site>","list_archive_url":null,"date":"2017-09-04T00:13:15","subject":"Re: [PATCH 08/10] dmaengine: sun6i: Add support for Allwinner A64\n\tand compatibles","submitter":{"id":67055,"url":"http://patchwork.ozlabs.org/api/people/67055/","name":"Stefan Brüns","email":"stefan.bruens@rwth-aachen.de"},"content":"On Montag, 4. September 2017 01:37:58 CEST André Przywara wrote:\n\n> > @@ -1090,6 +1101,7 @@ MODULE_DEVICE_TABLE(of, sun6i_dma_match);\n> > \n> > static int sun6i_dma_probe(struct platform_device *pdev)\n> > {\n> > \n> > \tconst struct of_device_id *device;\n> > \n> > +\tstruct device_node *np = pdev->dev.of_node;\n> \n> Is this some rebase/split artefact?\n> \n> Cheers,\n> Andre.\n> \n\nYes, that one should be in patch 7/10 ...\n\nKind regards,\n\nStefan","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xlr0c16Gsz9s8J\n\tfor ;\n\tMon, 4 Sep 2017 10:13:20 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753056AbdIDANS convert rfc822-to-8bit (ORCPT\n\t);\n\tSun, 3 Sep 2017 20:13:18 -0400","from mail-out-1.itc.rwth-aachen.de ([134.130.5.46]:15592 \"EHLO\n\tmail-out-1.itc.rwth-aachen.de\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1753046AbdIDANS (ORCPT\n\t); Sun, 3 Sep 2017 20:13:18 -0400","from rwthex-w2-b.rwth-ad.de ([134.130.26.159])\n\tby mail-in-1.itc.rwth-aachen.de with ESMTP; 04 Sep 2017 02:13:16 +0200","from pebbles.site (92.225.242.208) by rwthex-w2-b.rwth-ad.de\n\t(2002:8682:1a9f::8682:1a9f) with Microsoft SMTP Server (TLS) id\n\t15.0.1320.4; Mon, 4 Sep 2017 02:13:15 +0200"],"X-IronPort-AV":"E=Sophos;i=\"5.41,472,1498514400\"; d=\"scan'208\";a=\"11608015\"","From":"Stefan Bruens ","To":"=?iso-8859-1?q?Andr=E9?= Przywara ","CC":", ,\n\t, Vinod Koul ,\n\t, ,\n\tMaxime Ripard ,\n\tChen-Yu Tsai , Rob Herring ,\n\tCode Kipper ","Subject":"Re: [PATCH 08/10] dmaengine: sun6i: Add support for Allwinner A64\n\tand compatibles","Date":"Mon, 4 Sep 2017 02:13:15 +0200","Message-ID":"<5368262.YgOfWCUmp3@pebbles.site>","In-Reply-To":"<1526a6b4-1962-256d-1ada-ef9c7d95e6b1@arm.com>","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-9-stefan.bruens@rwth-aachen.de>\n\t<1526a6b4-1962-256d-1ada-ef9c7d95e6b1@arm.com>","MIME-Version":"1.0","Content-Transfer-Encoding":"8BIT","Content-Type":"text/plain; charset=\"iso-8859-1\"","X-Originating-IP":"[92.225.242.208]","X-ClientProxiedBy":"rwthex-w2-b.rwth-ad.de (2002:8682:1a9f::8682:1a9f) To\n\trwthex-w2-b.rwth-ad.de (2002:8682:1a9f::8682:1a9f)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762461,"web_url":"http://patchwork.ozlabs.org/comment/1762461/","msgid":"<20170904070620.3lpkmq6nt2qrgwah@flea>","list_archive_url":null,"date":"2017-09-04T07:06:20","subject":"Re: [PATCH 01/10] dmaengine: sun6i: Correct setting of clock\n\tautogating register for A83T/H3","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"On Mon, Sep 04, 2017 at 12:23:09AM +0100, André Przywara wrote:\n> On 03/09/17 23:40, Stefan Brüns wrote:\n> > The H83T uses a compatible string different from the A23, but requires\n> \n> A83T\n> \n> > the same clock autogating register setting.\n> > \n> > The H3 also requires setting the clock autogating register, but has\n> > the register at a different offset.\n> > \n> > Some currently available SoCs not yet supported by the sun6i-dma driver\n> > will require new compatible strings. These SoCs either follow the A23\n> > register model (e.g. V3s) or the H3 register model (A64, R40), so a new\n> > variable is added to the config struct to group SoCs with common register\n> > models.\n> \n> As mentioned in that other mail, using the actual properties as names\n> here instead of grouping them to rather arbitrary groups seems more\n> useful and future-proof to me and should be easier to read.\n> In this case this should simplify this patch:\n> sun8i_a23_dma_cfg = {\n> \t.nr_max_channels = 8,\n> \t.nr_max_requests = 24,\n> \t.nr_max_vchans = 37,\n> +\t.auto_clock_gate = 0x20,\n> ...\n> -\tif (of_device_is_compatible(pdev->dev.of_node,\n> -\t\t\t\t \"allwinner,sun8i-a23-dma\"))\n> -\t\twritel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);\n> +\tif (sdc->cfg->auto_clock_gate)\n> +\t\twritel(SUN8I_DMA_GATE_ENABLE,\n> +\t\t sdc->base + sdc->cfg->auto_clock_gate);\n\nI agree.\n\nMaxime","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xm19Q2bC6z9s82\n\tfor ;\n\tMon, 4 Sep 2017 17:06:34 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752624AbdIDHGc (ORCPT\n\t);\n\tMon, 4 Sep 2017 03:06:32 -0400","from mail.free-electrons.com ([62.4.15.54]:33655 \"EHLO\n\tmail.free-electrons.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752536AbdIDHGc (ORCPT\n\t); Mon, 4 Sep 2017 03:06:32 -0400","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 77EC22081C; Mon, 4 Sep 2017 09:06:29 +0200 (CEST)","from localhost (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr\n\t[90.63.216.87])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id 470E1207F9;\n\tMon, 4 Sep 2017 09:06:19 +0200 (CEST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT,\n\tURIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0","Date":"Mon, 4 Sep 2017 09:06:20 +0200","From":"Maxime Ripard ","To":"=?iso-8859-1?q?Andr=E9?= Przywara ","Cc":"Stefan =?iso-8859-1?q?Br=FCns?= ,\n\tlinux-sunxi@googlegroups.com, devicetree@vger.kernel.org, \n\tdmaengine@vger.kernel.org, Vinod Koul , \n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, \n\tChen-Yu Tsai , Rob Herring , \n\tCode Kipper ","Subject":"Re: [PATCH 01/10] dmaengine: sun6i: Correct setting of clock\n\tautogating register for A83T/H3","Message-ID":"<20170904070620.3lpkmq6nt2qrgwah@flea>","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-2-stefan.bruens@rwth-aachen.de>\n\t","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"iatbwsmpe4tb2w4b\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170714 (1.8.3)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762483,"web_url":"http://patchwork.ozlabs.org/comment/1762483/","msgid":"<20170904074355.niloziky42aki7bg@flea>","list_archive_url":null,"date":"2017-09-04T07:43:55","subject":"Re: [PATCH 05/10] dmaengine: sun6i: Move number of\n\tpchans/vchans/request to device struct","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"On Mon, Sep 04, 2017 at 12:40:56AM +0200, Stefan Brüns wrote:\n> Preparatory patch: If the same compatible is used for different SoCs which\n> have a common register layout, but different number of channels, the\n> channel count can no longer be stored in the config. Store it in the\n> device structure instead.\n> \n> Signed-off-by: Stefan Brüns \n\nAs stated already, we already are going to have a different\ncompatible, and this is not something that will change from one\ninstance to the other. Having code is therefore:\n A) Making the code more complex\n B) For no particular reason.\n\nMaxime","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xm20p0WGwz9s7c\n\tfor ;\n\tMon, 4 Sep 2017 17:44:10 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753292AbdIDHoI (ORCPT\n\t);\n\tMon, 4 Sep 2017 03:44:08 -0400","from mail.free-electrons.com ([62.4.15.54]:34312 \"EHLO\n\tmail.free-electrons.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751949AbdIDHoH (ORCPT\n\t); Mon, 4 Sep 2017 03:44:07 -0400","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 022D420A35; Mon, 4 Sep 2017 09:44:05 +0200 (CEST)","from localhost (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr\n\t[90.63.216.87])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id C6EC320A0D;\n\tMon, 4 Sep 2017 09:43:54 +0200 (CEST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT\n\tshortcircuit=ham autolearn=disabled version=3.4.0","Date":"Mon, 4 Sep 2017 09:43:55 +0200","From":"Maxime Ripard ","To":"Stefan =?iso-8859-1?q?Br=FCns?= ","Cc":"linux-sunxi@googlegroups.com, devicetree@vger.kernel.org,\n\tdmaengine@vger.kernel.org, Vinod Koul ,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tChen-Yu Tsai , Rob Herring ,\n\tCode Kipper ,\n\tAndre Przywara ","Subject":"Re: [PATCH 05/10] dmaengine: sun6i: Move number of\n\tpchans/vchans/request to device struct","Message-ID":"<20170904074355.niloziky42aki7bg@flea>","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-6-stefan.bruens@rwth-aachen.de>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"hs4nqmfrjcgcpunc\"","Content-Disposition":"inline","In-Reply-To":"<20170903224100.17893-6-stefan.bruens@rwth-aachen.de>","User-Agent":"NeoMutt/20170714 (1.8.3)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762494,"web_url":"http://patchwork.ozlabs.org/comment/1762494/","msgid":"<20170904075924.jufrqijrtxcqvztd@flea>","list_archive_url":null,"date":"2017-09-04T07:59:24","subject":"Re: [PATCH 02/10] dmaengine: sun6i: Correct burst length field\n\toffsets for H3","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"On Mon, Sep 04, 2017 at 12:40:53AM +0200, Stefan Brüns wrote:\n> For the H3, the burst lengths field offsets in the channel configuration\n> register differs from earlier SoC generations.\n> \n> Using the A31 register macros actually configured the H3 controller\n> do to bursts of length 1 always, which although working leads to higher\n> bus utilisation.\n> \n> Signed-off-by: Stefan Brüns \n> ---\n> drivers/dma/sun6i-dma.c | 28 +++++++++++++++++++++-------\n> 1 file changed, 21 insertions(+), 7 deletions(-)\n> \n> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> index 1d9b3be30d22..f1a139f0102f 100644\n> --- a/drivers/dma/sun6i-dma.c\n> +++ b/drivers/dma/sun6i-dma.c\n> @@ -68,13 +68,15 @@\n> #define DMA_CHAN_CFG_SRC_DRQ(x)\t\t((x) & 0x1f)\n> #define DMA_CHAN_CFG_SRC_IO_MODE\tBIT(5)\n> #define DMA_CHAN_CFG_SRC_LINEAR_MODE\t(0 << 5)\n> -#define DMA_CHAN_CFG_SRC_BURST(x)\t(((x) & 0x3) << 7)\n> +#define DMA_CHAN_CFG_SRC_BURST_A31(x)\t(((x) & 0x3) << 7)\n> +#define DMA_CHAN_CFG_SRC_BURST_H3(x)\t(((x) & 0x3) << 6)\n> #define DMA_CHAN_CFG_SRC_WIDTH(x)\t(((x) & 0x3) << 9)\n> \n> #define DMA_CHAN_CFG_DST_DRQ(x)\t\t(DMA_CHAN_CFG_SRC_DRQ(x) << 16)\n> #define DMA_CHAN_CFG_DST_IO_MODE\t(DMA_CHAN_CFG_SRC_IO_MODE << 16)\n> #define DMA_CHAN_CFG_DST_LINEAR_MODE\t(DMA_CHAN_CFG_SRC_LINEAR_MODE << 16)\n> -#define DMA_CHAN_CFG_DST_BURST(x)\t(DMA_CHAN_CFG_SRC_BURST(x) << 16)\n> +#define DMA_CHAN_CFG_DST_BURST_A31(x)\t(DMA_CHAN_CFG_SRC_BURST_A31(x) << 16)\n> +#define DMA_CHAN_CFG_DST_BURST_H3(x)\t(DMA_CHAN_CFG_SRC_BURST_H3(x) << 16)\n> #define DMA_CHAN_CFG_DST_WIDTH(x)\t(DMA_CHAN_CFG_SRC_WIDTH(x) << 16)\n> \n> #define DMA_CHAN_CUR_SRC\t0x10\n> @@ -554,11 +556,17 @@ static int set_config(struct sun6i_dma_dev *sdev,\n> \tif (dst_width < 0)\n> \t\treturn dst_width;\n> \n> -\t*p_cfg = DMA_CHAN_CFG_SRC_BURST(src_burst) |\n> -\t\tDMA_CHAN_CFG_SRC_WIDTH(src_width) |\n> -\t\tDMA_CHAN_CFG_DST_BURST(dst_burst) |\n> +\t*p_cfg = DMA_CHAN_CFG_SRC_WIDTH(src_width) |\n> \t\tDMA_CHAN_CFG_DST_WIDTH(dst_width);\n> \n> +\tif (sdev->cfg->dmac_variant == DMAC_VARIANT_H3) {\n> +\t\t*p_cfg |= DMA_CHAN_CFG_SRC_BURST_H3(src_burst) |\n> +\t\t\t DMA_CHAN_CFG_DST_BURST_H3(dst_burst);\n> +\t} else {\n> +\t\t*p_cfg |= DMA_CHAN_CFG_SRC_BURST_A31(src_burst) |\n> +\t\t\t DMA_CHAN_CFG_DST_BURST_A31(dst_burst);\n> +\t}\n> +\n\nI guess we have two options to support that properly. We could either\nhave a different function that would generate that register value\nbased on the parameters we have, or duplicate the set_config function\nentirely, with function pointer stored in the configuration.\n\nI think I prefer the former, as it reduces the code duplication.\n\nMaxime","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xm2Lg0S4Nz9s8J\n\tfor ;\n\tMon, 4 Sep 2017 17:59:38 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753280AbdIDH7h (ORCPT\n\t);\n\tMon, 4 Sep 2017 03:59:37 -0400","from mail.free-electrons.com ([62.4.15.54]:34745 \"EHLO\n\tmail.free-electrons.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751949AbdIDH7g (ORCPT\n\t); Mon, 4 Sep 2017 03:59:36 -0400","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 8435A20A2F; Mon, 4 Sep 2017 09:59:33 +0200 (CEST)","from localhost (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr\n\t[90.63.216.87])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id 4F5A420970;\n\tMon, 4 Sep 2017 09:59:23 +0200 (CEST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT,\n\tURIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0","Date":"Mon, 4 Sep 2017 09:59:24 +0200","From":"Maxime Ripard ","To":"Stefan =?iso-8859-1?q?Br=FCns?= ","Cc":"linux-sunxi@googlegroups.com, devicetree@vger.kernel.org,\n\tdmaengine@vger.kernel.org, Vinod Koul ,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tChen-Yu Tsai , Rob Herring ,\n\tCode Kipper ,\n\tAndre Przywara ","Subject":"Re: [PATCH 02/10] dmaengine: sun6i: Correct burst length field\n\toffsets for H3","Message-ID":"<20170904075924.jufrqijrtxcqvztd@flea>","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-3-stefan.bruens@rwth-aachen.de>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"xoyxyd4ub5zg7sc5\"","Content-Disposition":"inline","In-Reply-To":"<20170903224100.17893-3-stefan.bruens@rwth-aachen.de>","User-Agent":"NeoMutt/20170714 (1.8.3)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762497,"web_url":"http://patchwork.ozlabs.org/comment/1762497/","msgid":"<20170904080025.eilcinu4ennj5fmb@flea>","list_archive_url":null,"date":"2017-09-04T08:00:25","subject":"Re: [PATCH 04/10] dmaengine: sun6i: Enable additional burst\n\tlengths/widths on H3","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"On Mon, Sep 04, 2017 at 12:40:55AM +0200, Stefan Brüns wrote:\n> The H3 supports bursts lengths of 1, 4, 8 and 16 transfers, each with\n> a width of 1, 2, 4 or 8 bytes.\n> \n> The register value for the the width is log2-encoded, change the\n> conversion function to provide the correct value for width == 8.\n> \n> Signed-off-by: Stefan Brüns \n> ---\n> drivers/dma/sun6i-dma.c | 12 +++++++++++-\n> 1 file changed, 11 insertions(+), 1 deletion(-)\n> \n> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> index c5644bd0f91a..335a8ec88b0b 100644\n> --- a/drivers/dma/sun6i-dma.c\n> +++ b/drivers/dma/sun6i-dma.c\n> @@ -263,8 +263,12 @@ static inline s8 convert_burst(u32 maxburst)\n> \tswitch (maxburst) {\n> \tcase 1:\n> \t\treturn 0;\n> +\tcase 4:\n> +\t\treturn 1;\n> \tcase 8:\n> \t\treturn 2;\n> +\tcase 16:\n> +\t\treturn 3;\n> \tdefault:\n> \t\treturn -EINVAL;\n> \t}\n> @@ -272,7 +276,7 @@ static inline s8 convert_burst(u32 maxburst)\n> \n> static inline s8 convert_buswidth(enum dma_slave_buswidth addr_width)\n> {\n> -\treturn addr_width >> 1;\n> +\treturn ilog2(addr_width);\n> }\n> \n> static size_t sun6i_get_chan_size(struct sun6i_pchan *pchan)\n> @@ -1152,6 +1156,12 @@ static int sun6i_dma_probe(struct platform_device *pdev)\n> \t\t\t\t\t\t BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);\n> \tsdc->src_burst_lengths\t\t\t= BIT(1) | BIT(8);\n> \tsdc->dst_burst_lengths\t\t\t= BIT(1) | BIT(8);\n> +\tif (sdc->cfg->dmac_variant == DMAC_VARIANT_H3) {\n> +\t\tsdc->slave.src_addr_widths |= BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);\n> +\t\tsdc->slave.dst_addr_widths |= BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);\n> +\t\tsdc->src_burst_lengths |= BIT(4) | BIT(16);\n> +\t\tsdc->dst_burst_lengths |= BIT(4) | BIT(16);\n> +\t}\n\nThe rest looks good, but that should be stored in the sun6i_dma_config\nstructure too.\n\nThanks!\nMaxime","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xm2NF5J1Tz9s72\n\tfor ;\n\tMon, 4 Sep 2017 18:01:01 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753280AbdIDIBA (ORCPT\n\t);\n\tMon, 4 Sep 2017 04:01:00 -0400","from mail.free-electrons.com ([62.4.15.54]:34816 \"EHLO\n\tmail.free-electrons.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751949AbdIDIA7 (ORCPT\n\t); Mon, 4 Sep 2017 04:00:59 -0400","by mail.free-electrons.com (Postfix, from userid 110)\n\tid EBC9020A2F; Mon, 4 Sep 2017 10:00:56 +0200 (CEST)","from localhost (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr\n\t[90.63.216.87])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id 9797A21F23;\n\tMon, 4 Sep 2017 10:00:24 +0200 (CEST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT,\n\tURIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0","Date":"Mon, 4 Sep 2017 10:00:25 +0200","From":"Maxime Ripard ","To":"Stefan =?iso-8859-1?q?Br=FCns?= ","Cc":"linux-sunxi@googlegroups.com, devicetree@vger.kernel.org,\n\tdmaengine@vger.kernel.org, Vinod Koul ,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tChen-Yu Tsai , Rob Herring ,\n\tCode Kipper ,\n\tAndre Przywara ","Subject":"Re: [PATCH 04/10] dmaengine: sun6i: Enable additional burst\n\tlengths/widths on H3","Message-ID":"<20170904080025.eilcinu4ennj5fmb@flea>","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-5-stefan.bruens@rwth-aachen.de>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"huxm5lncrvognyil\"","Content-Disposition":"inline","In-Reply-To":"<20170903224100.17893-5-stefan.bruens@rwth-aachen.de>","User-Agent":"NeoMutt/20170714 (1.8.3)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762689,"web_url":"http://patchwork.ozlabs.org/comment/1762689/","msgid":"<3533197.81BdoSVRz8@sbruens-linux>","list_archive_url":null,"date":"2017-09-04T14:30:59","subject":"Re: [PATCH 05/10] dmaengine: sun6i: Move number of\n\tpchans/vchans/request to device struct","submitter":{"id":67055,"url":"http://patchwork.ozlabs.org/api/people/67055/","name":"Stefan Brüns","email":"stefan.bruens@rwth-aachen.de"},"content":"On Montag, 4. September 2017 09:43:55 CEST Maxime Ripard wrote:\n> On Mon, Sep 04, 2017 at 12:40:56AM +0200, Stefan Brüns wrote:\n> > Preparatory patch: If the same compatible is used for different SoCs which\n> > have a common register layout, but different number of channels, the\n> > channel count can no longer be stored in the config. Store it in the\n> > device structure instead.\n> > \n> > Signed-off-by: Stefan Brüns \n> \n> As stated already, we already are going to have a different\n> compatible, and this is not something that will change from one\n> instance to the other. Having code is therefore:\n> A) Making the code more complex\n> B) For no particular reason.\n\nIf the dma channel count (which is a standard dma binding, likely for a \nreason) goes into the devicetree, it has to be moved out of the config.\n\nThe R40 (which has register manuals available) has the same register layout as \nthe A64, but *does* have a different channel count. So you think it is a good \nidea to introduce a new compatible again?\n\nIf you had been half as picky when merging the H3 and A83T support, we would \nnot have this mess now.\n\nThere is also the H6, where there is no register manual available yet, but I \nbet it has the H3 (and A64, H5, R40) register layout, but unlikely the same \nnumber of DMA channels *and* the same number of ports.\n\nRegards,\n\nStefan\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xmC2J4rQ8z9s7h\n\tfor ;\n\tTue, 5 Sep 2017 00:31:04 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753848AbdIDObD convert rfc822-to-8bit (ORCPT\n\t);\n\tMon, 4 Sep 2017 10:31:03 -0400","from mail-out-1.itc.rwth-aachen.de ([134.130.5.46]:37916 \"EHLO\n\tmail-out-1.itc.rwth-aachen.de\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1753811AbdIDObC (ORCPT\n\t); Mon, 4 Sep 2017 10:31:02 -0400","from rwthex-s2-b.rwth-ad.de ([134.130.26.155])\n\tby mail-in-1.itc.rwth-aachen.de with ESMTP; 04 Sep 2017 16:31:00 +0200","from rwthex-w2-b.rwth-ad.de (2002:8682:1a9f::8682:1a9f) by\n\trwthex-s2-b.rwth-ad.de (2002:8682:1a9b::8682:1a9b) with Microsoft\n\tSMTP Server (TLS) id 15.0.1320.4; Mon, 4 Sep 2017 16:30:59 +0200","from rwthex-w2-b.rwth-ad.de ([fe80::200c:2ee4:85cf:8127]) by\n\trwthex-w2-b.rwth-ad.de ([fe80::200c:2ee4:85cf:8127%21]) with mapi id\n\t15.00.1320.000; Mon, 4 Sep 2017 16:30:59 +0200"],"X-IronPort-AV":"E=Sophos;i=\"5.41,475,1498514400\"; d=\"scan'208\";a=\"11732468\"","From":"=?iso-8859-1?q?Br=FCns=2C_Stefan?= ","To":"Maxime Ripard ","CC":"\"linux-sunxi@googlegroups.com\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"dmaengine@vger.kernel.org\" ,\n\tVinod Koul ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tChen-Yu Tsai , Rob Herring ,\n\tCode Kipper ,\n\tAndre Przywara ","Subject":"Re: [PATCH 05/10] dmaengine: sun6i: Move number of\n\tpchans/vchans/request to device struct","Thread-Topic":"[PATCH 05/10] dmaengine: sun6i: Move number of\n\tpchans/vchans/request to device struct","Thread-Index":"AQHTJVQiHWxigx6IpESEb/WdFlPCf6KkqKqA","Date":"Mon, 4 Sep 2017 14:30:59 +0000","Message-ID":"<3533197.81BdoSVRz8@sbruens-linux>","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-6-stefan.bruens@rwth-aachen.de>\n\t<20170904074355.niloziky42aki7bg@flea>","In-Reply-To":"<20170904074355.niloziky42aki7bg@flea>","Accept-Language":"en-US, de-DE","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-ms-exchange-messagesentrepresentingtype":"1","x-ms-exchange-transport-fromentityheader":"Hosted","x-originating-ip":"[78.35.13.203]","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-ID":"<625A3A4542C11445B4DBEC50806D6BE1@rwth-ad.de>","Content-Transfer-Encoding":"8BIT","MIME-Version":"1.0","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762702,"web_url":"http://patchwork.ozlabs.org/comment/1762702/","msgid":"<2223782.bf3lvqWUP7@sbruens-linux>","list_archive_url":null,"date":"2017-09-04T14:47:24","subject":"Re: [PATCH 02/10] dmaengine: sun6i: Correct burst length field\n\toffsets for H3","submitter":{"id":67055,"url":"http://patchwork.ozlabs.org/api/people/67055/","name":"Stefan Brüns","email":"stefan.bruens@rwth-aachen.de"},"content":"On Montag, 4. September 2017 09:59:24 CEST Maxime Ripard wrote:\n> On Mon, Sep 04, 2017 at 12:40:53AM +0200, Stefan Brüns wrote:\n> > For the H3, the burst lengths field offsets in the channel configuration\n> > register differs from earlier SoC generations.\n> > \n> > Using the A31 register macros actually configured the H3 controller\n> > do to bursts of length 1 always, which although working leads to higher\n> > bus utilisation.\n> > \n> > Signed-off-by: Stefan Brüns \n> > ---\n> > \n> > drivers/dma/sun6i-dma.c | 28 +++++++++++++++++++++-------\n> > 1 file changed, 21 insertions(+), 7 deletions(-)\n> > \n> > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> > index 1d9b3be30d22..f1a139f0102f 100644\n> > --- a/drivers/dma/sun6i-dma.c\n> > +++ b/drivers/dma/sun6i-dma.c\n> > @@ -68,13 +68,15 @@\n> > \n> > #define DMA_CHAN_CFG_SRC_DRQ(x)\t\t((x) & 0x1f)\n> > #define DMA_CHAN_CFG_SRC_IO_MODE\tBIT(5)\n> > #define DMA_CHAN_CFG_SRC_LINEAR_MODE\t(0 << 5)\n> > \n> > -#define DMA_CHAN_CFG_SRC_BURST(x)\t(((x) & 0x3) << 7)\n> > +#define DMA_CHAN_CFG_SRC_BURST_A31(x)\t(((x) & 0x3) << 7)\n> > +#define DMA_CHAN_CFG_SRC_BURST_H3(x)\t(((x) & 0x3) << 6)\n> > \n> > #define DMA_CHAN_CFG_SRC_WIDTH(x)\t(((x) & 0x3) << 9)\n> > \n> > #define DMA_CHAN_CFG_DST_DRQ(x)\t\t(DMA_CHAN_CFG_SRC_DRQ(x) << 16)\n> > #define DMA_CHAN_CFG_DST_IO_MODE\t(DMA_CHAN_CFG_SRC_IO_MODE << 16)\n> > #define DMA_CHAN_CFG_DST_LINEAR_MODE\t(DMA_CHAN_CFG_SRC_LINEAR_MODE << 16)\n> > \n> > -#define DMA_CHAN_CFG_DST_BURST(x)\t(DMA_CHAN_CFG_SRC_BURST(x) << 16)\n> > +#define DMA_CHAN_CFG_DST_BURST_A31(x)\t(DMA_CHAN_CFG_SRC_BURST_A31(x) <<\n> > 16) +#define DMA_CHAN_CFG_DST_BURST_H3(x)\t(DMA_CHAN_CFG_SRC_BURST_H3(x)\n> > << 16)> \n> > #define DMA_CHAN_CFG_DST_WIDTH(x)\t(DMA_CHAN_CFG_SRC_WIDTH(x) << 16)\n> > \n> > #define DMA_CHAN_CUR_SRC\t0x10\n> > \n> > @@ -554,11 +556,17 @@ static int set_config(struct sun6i_dma_dev *sdev,\n> > \n> > \tif (dst_width < 0)\n> > \t\n> > \t\treturn dst_width;\n> > \n> > -\t*p_cfg = DMA_CHAN_CFG_SRC_BURST(src_burst) |\n> > -\t\tDMA_CHAN_CFG_SRC_WIDTH(src_width) |\n> > -\t\tDMA_CHAN_CFG_DST_BURST(dst_burst) |\n> > +\t*p_cfg = DMA_CHAN_CFG_SRC_WIDTH(src_width) |\n> > \n> > \t\tDMA_CHAN_CFG_DST_WIDTH(dst_width);\n> > \n> > +\tif (sdev->cfg->dmac_variant == DMAC_VARIANT_H3) {\n> > +\t\t*p_cfg |= DMA_CHAN_CFG_SRC_BURST_H3(src_burst) |\n> > +\t\t\t DMA_CHAN_CFG_DST_BURST_H3(dst_burst);\n> > +\t} else {\n> > +\t\t*p_cfg |= DMA_CHAN_CFG_SRC_BURST_A31(src_burst) |\n> > +\t\t\t DMA_CHAN_CFG_DST_BURST_A31(dst_burst);\n> > +\t}\n> > +\n> \n> I guess we have two options to support that properly. We could either\n> have a different function that would generate that register value\n> based on the parameters we have, or duplicate the set_config function\n> entirely, with function pointer stored in the configuration.\n> \n> I think I prefer the former, as it reduces the code duplication.\n\nDuplicating \"set_config\" would also mean duplicating sun6i_dma_prep_dma_memcpy \n- there are two hunks which change setting of the burst length register value.\n\nA function pointer in the config would work.\n\nKind regards,\n\nStefan\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xmCPF5K76z9t2R\n\tfor ;\n\tTue, 5 Sep 2017 00:47:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753751AbdIDOr2 convert rfc822-to-8bit (ORCPT\n\t);\n\tMon, 4 Sep 2017 10:47:28 -0400","from mail-out-2.itc.rwth-aachen.de ([134.130.5.47]:32801 \"EHLO\n\tmail-out-2.itc.rwth-aachen.de\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1753621AbdIDOr1 (ORCPT\n\t); Mon, 4 Sep 2017 10:47:27 -0400","from rwthex-s2-b.rwth-ad.de ([134.130.26.155])\n\tby mail-in-2.itc.rwth-aachen.de with ESMTP; 04 Sep 2017 16:47:25 +0200","from rwthex-w2-b.rwth-ad.de (2002:8682:1a9f::8682:1a9f) by\n\trwthex-s2-b.rwth-ad.de (2002:8682:1a9b::8682:1a9b) with Microsoft\n\tSMTP Server (TLS) id 15.0.1320.4; Mon, 4 Sep 2017 16:47:24 +0200","from rwthex-w2-b.rwth-ad.de ([fe80::200c:2ee4:85cf:8127]) by\n\trwthex-w2-b.rwth-ad.de ([fe80::200c:2ee4:85cf:8127%21]) with mapi id\n\t15.00.1320.000; Mon, 4 Sep 2017 16:47:24 +0200"],"X-IronPort-AV":"E=Sophos;i=\"5.41,475,1498514400\"; d=\"scan'208\";a=\"11738967\"","From":"=?iso-8859-1?q?Br=FCns=2C_Stefan?= ","To":"Maxime Ripard ","CC":"\"linux-sunxi@googlegroups.com\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"dmaengine@vger.kernel.org\" ,\n\tVinod Koul ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tChen-Yu Tsai , Rob Herring ,\n\tCode Kipper ,\n\tAndre Przywara ","Subject":"Re: [PATCH 02/10] dmaengine: sun6i: Correct burst length field\n\toffsets for H3","Thread-Topic":"[PATCH 02/10] dmaengine: sun6i: Correct burst length field\n\toffsets for H3","Thread-Index":"AQHTJVQjjowTXsWGTEqsv7sWe72pDaKkrUEA","Date":"Mon, 4 Sep 2017 14:47:24 +0000","Message-ID":"<2223782.bf3lvqWUP7@sbruens-linux>","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-3-stefan.bruens@rwth-aachen.de>\n\t<20170904075924.jufrqijrtxcqvztd@flea>","In-Reply-To":"<20170904075924.jufrqijrtxcqvztd@flea>","Accept-Language":"en-US, de-DE","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-ms-exchange-messagesentrepresentingtype":"1","x-ms-exchange-transport-fromentityheader":"Hosted","x-originating-ip":"[78.35.13.203]","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-ID":"","Content-Transfer-Encoding":"8BIT","MIME-Version":"1.0","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1765422,"web_url":"http://patchwork.ozlabs.org/comment/1765422/","msgid":"<20170908143710.rhz6x3i776zrhbzo@flea.lan>","list_archive_url":null,"date":"2017-09-08T14:37:10","subject":"Re: [PATCH 05/10] dmaengine: sun6i: Move number of\n\tpchans/vchans/request to device struct","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"On Mon, Sep 04, 2017 at 02:30:59PM +0000, Brüns, Stefan wrote:\n> On Montag, 4. September 2017 09:43:55 CEST Maxime Ripard wrote:\n> > On Mon, Sep 04, 2017 at 12:40:56AM +0200, Stefan Brüns wrote:\n> > > Preparatory patch: If the same compatible is used for different SoCs which\n> > > have a common register layout, but different number of channels, the\n> > > channel count can no longer be stored in the config. Store it in the\n> > > device structure instead.\n> > > \n> > > Signed-off-by: Stefan Brüns \n> > \n> > As stated already, we already are going to have a different\n> > compatible, and this is not something that will change from one\n> > instance to the other. Having code is therefore:\n> > A) Making the code more complex\n> > B) For no particular reason.\n> \n> If the dma channel count (which is a standard dma binding, likely for a \n> reason) goes into the devicetree, it has to be moved out of the config.\n>\n> The R40 (which has register manuals available) has the same register layout as \n> the A64, but *does* have a different channel count. So you think it is a good \n> idea to introduce a new compatible again?\n> \n> If you had been half as picky when merging the H3 and A83T support, we would \n> not have this mess now.\n> \n> There is also the H6, where there is no register manual available yet, but I \n> bet it has the H3 (and A64, H5, R40) register layout, but unlikely the same \n> number of DMA channels *and* the same number of ports.\n\nThe thing is that this kind of things usually grow organically until\nyou can't just add a simple if case any more.\n\nI'm sorry you were at the tipping point, but I'm sure you also\nunderstand that adding more to the mess until the next one shows up\nisn't viable either.\n\nThat being said, thinking a bit more on that one, if you add to the\nbinding that we need to have both the current SoC compatible (to\nworkaround any variation / bugs we might encounter in the future) and\nthe \"generation\" one (to avoid adding one for each new IP), plus the\nmandatory dma-channels / dma-requests properties, that would work for\nme.\n\nMaxime","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xpfzs0lzCz9sBd\n\tfor ;\n\tSat, 9 Sep 2017 00:37:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755930AbdIHOhN (ORCPT\n\t);\n\tFri, 8 Sep 2017 10:37:13 -0400","from mail.free-electrons.com ([62.4.15.54]:52203 \"EHLO\n\tmail.free-electrons.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1755880AbdIHOhL (ORCPT\n\t); Fri, 8 Sep 2017 10:37:11 -0400","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 0F8F620A5B; Fri, 8 Sep 2017 16:37:09 +0200 (CEST)","from localhost (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr\n\t[90.63.216.87])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id D876320A57;\n\tFri, 8 Sep 2017 16:37:08 +0200 (CEST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT,\n\tURIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0","Date":"Fri, 8 Sep 2017 16:37:10 +0200","From":"Maxime Ripard ","To":"=?iso-8859-1?q?Br=FCns=2C?= Stefan ","Cc":"\"linux-sunxi@googlegroups.com\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"dmaengine@vger.kernel.org\" ,\n\tVinod Koul ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tChen-Yu Tsai , Rob Herring ,\n\tCode Kipper ,\n\tAndre Przywara ","Subject":"Re: [PATCH 05/10] dmaengine: sun6i: Move number of\n\tpchans/vchans/request to device struct","Message-ID":"<20170908143710.rhz6x3i776zrhbzo@flea.lan>","References":"<20170903224100.17893-1-stefan.bruens@rwth-aachen.de>\n\t<20170903224100.17893-6-stefan.bruens@rwth-aachen.de>\n\t<20170904074355.niloziky42aki7bg@flea>\n\t<3533197.81BdoSVRz8@sbruens-linux>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"i5qul5ppysoi43r7\"","Content-Disposition":"inline","In-Reply-To":"<3533197.81BdoSVRz8@sbruens-linux>","User-Agent":"NeoMutt/20170714 (1.8.3)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]