[{"id":1760865,"web_url":"http://patchwork.ozlabs.org/comment/1760865/","msgid":"","list_archive_url":null,"date":"2017-08-31T11:44:05","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":65868,"url":"http://patchwork.ozlabs.org/api/people/65868/","name":"Code Kipper","email":"codekipper@gmail.com"},"content":"On 31 August 2017 at 01:36, 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. Add the proper config data\n> and compatible string to support it.\n>\n> Signed-off-by: Stefan Brüns \n> ---\n> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++++\n> drivers/dma/sun6i-dma.c | 7 +++++++\n> 2 files changed, 11 insertions(+)\n>\n> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi\n> index f96287d3043a..b86019238b77 100644\n> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi\n> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi\n> @@ -494,6 +494,8 @@\n> interrupts = ;\n> clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>;\n> clock-names = \"ahb\", \"mod\";\n> + dmas = <&dma 23>, <&dma 23>;\n> + dma-names = \"rx\", \"tx\";\nHi Stefan,\nthe dtsi parts should be in a separate patch\n\n> pinctrl-names = \"default\";\n> pinctrl-0 = <&spi0_pins>;\n> resets = <&ccu RST_BUS_SPI0>;\n> @@ -509,6 +511,8 @@\n> interrupts = ;\n> clocks = <&ccu CLK_BUS_SPI1>, <&ccu CLK_SPI1>;\n> clock-names = \"ahb\", \"mod\";\n> + dmas = <&dma 24>, <&dma 24>;\n> + dma-names = \"rx\", \"tx\";\n> pinctrl-names = \"default\";\n> pinctrl-0 = <&spi1_pins>;\n> resets = <&ccu RST_BUS_SPI1>;\n> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> index 5f4eee4513e5..6a17c5d63582 100644\n> --- a/drivers/dma/sun6i-dma.c\n> +++ b/drivers/dma/sun6i-dma.c\n> @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {\n> .nr_max_vchans = 34,\n> .dmac_variant = DMAC_VARIANT_H3,\n> };\n> +\n> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {\n> + .nr_max_channels = 8,\n> + .nr_max_requests = 27,\n> + .nr_max_vchans = 38,\n> + .dmac_variant = DMAC_VARIANT_H3,\n> };\n>\n> static const struct of_device_id sun6i_dma_match[] = {\n> @@ -1075,6 +1081,7 @@ static const struct of_device_id sun6i_dma_match[] = {\n> { .compatible = \"allwinner,sun8i-a23-dma\", .data = &sun8i_a23_dma_cfg },\n> { .compatible = \"allwinner,sun8i-a83t-dma\", .data = &sun8i_a83t_dma_cfg },\n> { .compatible = \"allwinner,sun8i-h3-dma\", .data = &sun8i_h3_dma_cfg },\n> + { .compatible = \"allwinner,sun50i-a64-dma\", .data = &sun50i_a64_dma_cfg },\nThis all looks fine...it's similar to my patch here\nhttps://github.com/codekipper/linux-sunxi/commit/8c54d9852dfad6ceb478c579a1213f38fb12fa80\nwhich I've been too lazy to post. I think the binding documentation\nshould go with this patch and this should also be the 1st patch in the\nseries, followed by the dtsi changes.\nBR,\nCK\n> { /* sentinel */ }\n> };\n> MODULE_DEVICE_TABLE(of, sun6i_dma_match);\n> --\n> 2.14.1\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"an6lmkpE\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"r/Z+09X5\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjgX366Ffz9t16\n\tfor ;\n\tThu, 31 Aug 2017 21:44:35 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnNtg-00059W-83; Thu, 31 Aug 2017 11:44:32 +0000","from mail-io0-x242.google.com ([2607:f8b0:4001:c06::242])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnNtb-00051p-B9 for linux-arm-kernel@lists.infradead.org;\n\tThu, 31 Aug 2017 11:44:29 +0000","by mail-io0-x242.google.com with SMTP id m40so3970708ioi.5\n\tfor ;\n\tThu, 31 Aug 2017 04:44:06 -0700 (PDT)","by 10.79.6.216 with HTTP; Thu, 31 Aug 2017 04:44:05 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:\n\tReferences:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=d0zv1k20nqL4LIVO0pzteGFmsnOru+xzk8DlPsdC/Ks=;\n\tb=an6lmkpErYULi2\n\tBCF0bO7n2cDT46yTjkgknGj0Yq5CipFdsMtt7t4SN38e2FAGbA3BAeGVZp6EOyiEW5lEFQYwttlP0\n\ti1CiUF/HYe7aMhfIxZ9KLCje9eq+gqK+uoTjUqI7iq1Yk/EMX/ZrDggp0OqRF8H5jGzxXGzP46Wdg\n\tiI0VjJxBzuUKx3w+jabL6QNNdNebN7g0jBJJV8smp+kMCuKxtJTdgTzZr1/c6tuRXfFQ0uY5yZu+8\n\t98sN5Mclr51xL9F7m9G1a97uF/wtJqqYWbZsBbs4h6IRKL1M2TXjEqYLftDJBXCDznGZspgiy+krR\n\tXCWqSltIvFF8pwX6QYWg==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=JabKohxhV/4qDkYsNGA6sjJrUAX5x5mRK33VluCEZg0=;\n\tb=r/Z+09X58nIobAAne1HOu0yoayiLI3bEMDsvTDAq5dCf0asLzVAKugC9q3SUBrj0/S\n\tWqPWU3j+klG6l+eORsq4jUwrt0983eET/6qnq8L9GxGTJcenwKsNPgh7VMnrdlJh5pJJ\n\tuUcPumxgnLeVBgwy7oh/ZJjtb/zwlQebYCohMveW/r93AcvZNJaHsjoNicm64iiQHL42\n\twRxXKRc9LKADxfBxaM1aoqMKIhPiiYdEuTQxUIovhtnRuDy/t1aGLCrEqzUBErzWefiD\n\tX5rqJHTepwFsRptEf0kp5m1GCsmblSdjy5VwROG5wY4Dp7qifmNr+hDhUpwKwi/qWZWJ\n\tvy8A=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=JabKohxhV/4qDkYsNGA6sjJrUAX5x5mRK33VluCEZg0=;\n\tb=dOQCpxL5XTC8MODAIUI517FY3Kc3sqJ1rvAXbZfQo+0CTgQviaZ8w7drbsgYjlzLX5\n\twFgoeQR33owPLh9WUFOnEuFgVRigOlus99mtughLEfidMS/iMwBWAZ1ONumq3bJYBGfG\n\t6p5SIQazmMA+D+4hOb0krjwUbLW5hr45Ji4R+FIUYakRwxq8yODu2IFnRhn+aWlbxVrJ\n\tJi2HTDeAIl8k/jxp/RhOgjGK7GC462R0svJj+7p8PPpez/z4LZJHKKcyChFklc3Dw9j/\n\tWi7zI2oByoWuSmmRP9HkTUOJ3oTBM1EwLXYgOHwGOkuzKDjUx3BCPPAabt8fDW3wpBnj\n\tMwRQ==","X-Gm-Message-State":"AHYfb5iOVCrup3U/kk6BPoNdVuvB4VylELoXakFjuAnqMSAeuPKHTES6\n\tASTzNSNe8fqtrg0vcCwE63MWQC+ixQ==","X-Google-Smtp-Source":"ADKCNb5ghw/FQn+97aWkEDgXtoqF9d+O+oDX900XMq05waxyfIHEDcXHTA8Z4QsV5YxjLYBsnR+oy7b/o7tv/wxYoxM=","X-Received":"by 10.36.144.195 with SMTP id x186mr451309itd.5.1504179846224;\n\tThu, 31 Aug 2017 04:44:06 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>","References":"<20170830233609.13855-1-stefan.bruens@rwth-aachen.de>\n\t<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>","From":"Code Kipper ","Date":"Thu, 31 Aug 2017 13:44:05 +0200","Message-ID":"","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","To":"=?utf-8?q?Stefan_Br=C3=BCns?= ","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170831_044427_434351_4EEA65C7 ","X-CRM114-Status":"GOOD ( 15.86 )","X-Spam-Score":"-2.0 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.0 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\n\tprovider (codekipper[at]gmail.com)\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree ,\n\tVinod Koul , \n\tlinux-kernel ,\n\tlinux-sunxi ,\n\tRob Herring , dmaengine@vger.kernel.org,\n\tMaxime Ripard , \n\tChen-Yu Tsai ,\n\tlinux-arm-kernel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1761085,"web_url":"http://patchwork.ozlabs.org/comment/1761085/","msgid":"<20170831145246.p4k3uakbn67na3pv@flea.lan>","list_archive_url":null,"date":"2017-08-31T14:52:46","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"On Thu, Aug 31, 2017 at 01:36:09AM +0200, 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. Add the proper config data\n> and compatible string to support it.\n> \n> Signed-off-by: Stefan Brüns \n> ---\n> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++++\n> drivers/dma/sun6i-dma.c | 7 +++++++\n> 2 files changed, 11 insertions(+)\n\nWith what device did you test this? As far as I know, the SPI driver\ndoesn't use DMA at all.\n\nMaxime","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"iCEud8vb\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjljw24rwz9s75\n\tfor ;\n\tFri, 1 Sep 2017 00:53:24 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnQqO-0002BI-RW; Thu, 31 Aug 2017 14:53:20 +0000","from mail.free-electrons.com ([62.4.15.54])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnQqL-00029O-FD for linux-arm-kernel@lists.infradead.org;\n\tThu, 31 Aug 2017 14:53:19 +0000","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 6ADC8209F6; Thu, 31 Aug 2017 16:52:55 +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 3DBB820872;\n\tThu, 31 Aug 2017 16:52:45 +0200 (CEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc:\n\tList-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:\n\tIn-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;\n\tbh=/BWWSIqeHNI7/fzsEnzLSkcIx/p6CAT1m0wZl51jGuM=;\n\tb=iCEud8vbFOV+lMHbWP+gLhthK\n\tRQ4UDm76/uowoYYUrpu8EfMKbJar//eTqibk4A4zNsJjROZ+nmd3MwFvr9vGBPDS5H4qjFTv7PPLC\n\tO8O6zDahxqgWnxXPNSbCL3R3TF4c6LIbxRHa7u82+jAaajFgvi4rh6S11tozPC+kMTxK/xgCsWXy2\n\tX6/u0YWtCn5qGFfCQllBMKNuKZCymUEdhqe+uQTBuuqGTw8KXQrQdYubrYswjNNGPDJst+TxjUe6/\n\tY40Om28irkHMn7Eh98e6TST/jwuNyhVWQCCejHUGkqIDs9dSjcS2AgZTEfHAV4KYKWLdh6itAlTyp\n\tRiIVHGzdA==;","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":"Thu, 31 Aug 2017 16:52:46 +0200","From":"Maxime Ripard ","To":"Stefan =?iso-8859-1?q?Br=FCns?= ","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","Message-ID":"<20170831145246.p4k3uakbn67na3pv@flea.lan>","References":"<20170830233609.13855-1-stefan.bruens@rwth-aachen.de>\n\t<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>","MIME-Version":"1.0","In-Reply-To":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>","User-Agent":"NeoMutt/20170714 (1.8.3)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170831_075317_664976_27DA8EFB ","X-CRM114-Status":"GOOD ( 13.81 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul ,\n\tlinux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com,\n\tRob Herring , dmaengine@vger.kernel.org,\n\tChen-Yu Tsai , linux-arm-kernel@lists.infradead.org","Content-Type":"multipart/mixed;\n\tboundary=\"===============6746864935769580376==\"","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1761176,"web_url":"http://patchwork.ozlabs.org/comment/1761176/","msgid":"","list_archive_url":null,"date":"2017-08-31T16:35:43","subject":"Re: [linux-sunxi] Re: [PATCH 3/3] dmaengine: sun6i: Add support for\n\tAllwinner A64","submitter":{"id":65868,"url":"http://patchwork.ozlabs.org/api/people/65868/","name":"Code Kipper","email":"codekipper@gmail.com"},"content":"On 31 August 2017 at 16:52, Maxime Ripard\n wrote:\n> On Thu, Aug 31, 2017 at 01:36:09AM +0200, 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. Add the proper config data\n>> and compatible string to support it.\n>>\n>> Signed-off-by: Stefan Brüns \n>> ---\n>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++++\n>> drivers/dma/sun6i-dma.c | 7 +++++++\n>> 2 files changed, 11 insertions(+)\n>\n> With what device did you test this? As far as I know, the SPI driver\n> doesn't use DMA at all.\n>\nHi Maxime,\nI've tested this on spdif and i2s on the Pine64.\nBR,\nCK\n> Maxime\n>\n> --\n> Maxime Ripard, Free Electrons\n> Embedded Linux and Kernel engineering\n> http://free-electrons.com\n>\n> --\n> You received this message because you are subscribed to the Google Groups \"linux-sunxi\" group.\n> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.\n> For more options, visit https://groups.google.com/d/optout.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"rEFKRH/d\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"KGKYmKGy\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjp0W20Sbz9s81\n\tfor ;\n\tFri, 1 Sep 2017 02:36:11 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnSRs-0002fy-1n; Thu, 31 Aug 2017 16:36:08 +0000","from mail-io0-x243.google.com ([2607:f8b0:4001:c06::243])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnSRo-0002dx-8A for linux-arm-kernel@lists.infradead.org;\n\tThu, 31 Aug 2017 16:36:06 +0000","by mail-io0-x243.google.com with SMTP id m40so149594ioi.5\n\tfor ;\n\tThu, 31 Aug 2017 09:35:44 -0700 (PDT)","by 10.79.6.216 with HTTP; Thu, 31 Aug 2017 09:35:43 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:\n\tReferences:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=n7/x6cQapZ067T5AlFrpoZLqHOEg5iQ55saT5gZx3p4=;\n\tb=rEFKRH/d5YkP/1\n\tQ57lUnHNUpmYdZ574ObWgSTxk3Vjwxtx4xp8ykBnhXAZDdup3OQ0mczSJpDQ38cnGLow8hzEGf226\n\tK2C1A6Wj1cTC8yDNc750uEn00Dj+gnoRhrNt+H02mAfQZ8j1hjlNe1ChmEWT/NopD0RZxUFqOkpIv\n\t6Ml93OcJvdbXqFspNR9i/OTBmjOYFarHrHVGgyjqPnYxYZnXD34icooc55UjgFMbpX5PyicbaVw/o\n\t/KTEziTqc7Tx0gFQTvdBdYhrb7LxEz0bhgDy3ZKichzclTbzH78ACGNGbAi0p0ZLvnVvdynyZgpDo\n\tUoe1mZ7qT4UHHnuJ8nHA==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=6Ru057Q/XytgNF+Hmr62a1eZpuV4ziSOuw43t4ZtBHQ=;\n\tb=KGKYmKGyIOmmRlx+GGKIo9G4q6J3O1oRWmi9c+vbeDbb9FjZjzNFeYQJYYqiIm7/gN\n\tm+ZnfP2tehGU6DoLp8zewrLz8iybxKb2KsIMQSbwPBn4KoiPzF3zyONAmbmg/vCbefcR\n\ttWHZnz+NwTHZx9ARJmbVZaJPdIFqPvzmpX57k9S1lZTyBwjB1XVfvksqHB9J4mCw0jmh\n\tnXTjgSWYTc9yWhVHFoq0Um2XjEjZF/Q69bGgWVcnfFyaNGaOWOEFvbV4zc+9RY0cO6+s\n\tJ0WIdxJoPxrQ/Dd0c60Xc68jPXxTQYhUxCs/Swui1gSXfWJEbIoFARzpAxchoifedoHr\n\t/asA=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=6Ru057Q/XytgNF+Hmr62a1eZpuV4ziSOuw43t4ZtBHQ=;\n\tb=nvVbjZJw2c2zjm2b1EzOsy7mWPnJNvJJSuQ/2ZcKskioLcKrjL3foTV4sTbtf5pWCl\n\tFxbwlIq9vwiAcIcEzTJ27Mxcl3F4I8QFscCi0nB80+ptC8nXN4+HqeVq2XFQwOAk/Xgh\n\t4h6UfYAxxObFLYbvA+6Dg4Yo1cgAIAniwyGD4jwdSi7roH19KHYmAbdLRjp0PpxIkPfJ\n\tUX3jp0QCENG8Cq2l3RJNpCT7msDIrnVshwoEWx3ndL5sYsb+DyyLlqo2DIYfhxr+wIy4\n\tVLqkyyF8RfXSLQn0NAa6z3Z4Ow/7H0MdOhRMUMzUpDHydeqPALBeJwW1BR6ZxbzjIAck\n\tJICA==","X-Gm-Message-State":"AHPjjUgECQw9Ytqj704LcbbdEiiNmTe9bWiy0ER/OrOAgwM6uDAHV/yF\n\tXSqql9xskROc4BaFxvSsFXZL+kEdVg==","X-Google-Smtp-Source":"ADKCNb4ia0haJ1MzcZyKsHCCMzaF+d8tUGa7r9eSWPKIiZQktwkG17BPVyQsATk4B+ZcfpqT5FiRoXvcf6GutS0dOYs=","X-Received":"by 10.107.32.83 with SMTP id g80mr5373698iog.357.1504197343599; \n\tThu, 31 Aug 2017 09:35:43 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170831145246.p4k3uakbn67na3pv@flea.lan>","References":"<20170830233609.13855-1-stefan.bruens@rwth-aachen.de>\n\t<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<20170831145246.p4k3uakbn67na3pv@flea.lan>","From":"Code Kipper ","Date":"Thu, 31 Aug 2017 18:35:43 +0200","Message-ID":"","Subject":"Re: [linux-sunxi] Re: [PATCH 3/3] dmaengine: sun6i: Add support for\n\tAllwinner A64","To":"Maxime Ripard ","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170831_093604_409322_09B0E1E6 ","X-CRM114-Status":"GOOD ( 16.93 )","X-Spam-Score":"-2.7 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.7 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/,\n\tlow\n\ttrust [2607:f8b0:4001:c06:0:0:0:243 listed in] [list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\n\tprovider (codekipper[at]gmail.com)\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree ,\n\tVinod Koul , linux-kernel\n\t, linux-sunxi\n\t, Rob Herring , \n\tdmaengine@vger.kernel.org, Chen-Yu Tsai , \n\t=?utf-8?q?Stefan_Br=C3=BCns?= ,\n\tlinux-arm-kernel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1761409,"web_url":"http://patchwork.ozlabs.org/comment/1761409/","msgid":"<20170901003135.10058-1-andre.przywara@arm.com>","list_archive_url":null,"date":"2017-09-01T00:31:35","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":61837,"url":"http://patchwork.ozlabs.org/api/people/61837/","name":"Andre Przywara","email":"andre.przywara@arm.com"},"content":"Hi,\n\nOn 31/08/17 00:36, 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. Add the proper config data\n> and compatible string to support it.\n\n...\n\n> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> index 5f4eee4513e5..6a17c5d63582 100644\n> --- a/drivers/dma/sun6i-dma.c\n> +++ b/drivers/dma/sun6i-dma.c\n> @@ -1068,6 +1068,12 @@ 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> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {\n> +\t.nr_max_channels = 8,\n> +\t.nr_max_requests = 27,\n> +\t.nr_max_vchans = 38,\n> +\t.dmac_variant = DMAC_VARIANT_H3,\n> };\n> \n> static const struct of_device_id sun6i_dma_match[] = {\n> @@ -1075,6 +1081,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\nI was wondering if should use the opportunity to expose those values as\nDT properties instead of hard-wiring them to a compatible string in the\ndriver every time we add support for a new SoC?\nWe could introduce a new compatible string (say: \"allwinner,sunxi-dma\"),\nthen describe properties for the number of channels and requests and\nvchans and parse those from the DT at probe time.\nWith this we might be able to support future SoCs without Linux *driver*\nchanges, by just providing the right DT. This would have worked already\nfor instance for the A83T support, which just changed those values.\n\nFor instance with this quick patch below (just compile tested, and without\nyour refactoring).\nThe DT node would then read something like:\n\tdma: dma-controller@01c02000 {\n\t\tcompatible = \"allwinner,sun50i-a64-dma\",\n\t\t\t \"allwinner,sunxi-dma\";\n\t\treg = <0x01c02000 0x1000>;\n\t\tinterrupts = ;\n\t\tclocks = <&ccu CLK_BUS_DMA>;\n\t\tresets = <&ccu RST_BUS_DMA>;\n\t\t#dma-cells = <1>;\n\t\tallwinner,max_channels = <8>;\n\t\tallwinner,max_requests = <27>;\n\t\tallwinner,max_vchans = <38>;\n\t};\n\nCheers,\nAndre.\n\ndiff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\nindex a2358780ab2c..5ae8032f2065 100644\n--- a/drivers/dma/sun6i-dma.c\n+++ b/drivers/dma/sun6i-dma.c\n@@ -1033,6 +1033,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,sunxi-dma\", .data = NULL },\n \t{ /* sentinel */ }\n };\n MODULE_DEVICE_TABLE(of, sun6i_dma_match);\n@@ -1051,7 +1052,43 @@ static int sun6i_dma_probe(struct platform_device *pdev)\n \tdevice = of_match_device(sun6i_dma_match, &pdev->dev);\n \tif (!device)\n \t\treturn -ENODEV;\n-\tsdc->cfg = device->data;\n+\tif (!device->data) {\n+\t\tstruct sun6i_dma_config *config;\n+\n+\t\tconfig = devm_kmalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);\n+\t\tif (!config)\n+\t\t\treturn -ENOMEM;\n+\n+\t\tret = of_property_read_u32(pdev->dev.of_node,\n+\t\t\t\t\t \"allwinner,max_channels\",\n+\t\t\t\t\t &config->nr_max_channels);\n+\t\tif (ret) {\n+\t\t\tdev_err(&pdev->dev,\n+\t\t\t\t\"missing allwinner,max_channels property\\n\");\n+\t\t\treturn ret;\n+\t\t}\n+\n+\t\tret = of_property_read_u32(pdev->dev.of_node,\n+\t\t\t\t\t \"allwinner,max_requests\",\n+\t\t\t\t\t &config->nr_max_requests);\n+\t\tif (ret) {\n+\t\t\tdev_err(&pdev->dev,\n+\t\t\t\t\"missing allwinner,max_requests property\\n\");\n+\t\t\treturn ret;\n+\t\t}\n+\n+\t\tret = of_property_read_u32(pdev->dev.of_node,\n+\t\t\t\t\t \"allwinner,max_vchans\",\n+\t\t\t\t\t &config->nr_max_vchans);\n+\t\tif (ret) {\n+\t\t\tdev_err(&pdev->dev,\n+\t\t\t\t\"missing allwinner,max_vchans property\\n\");\n+\t\t\treturn ret;\n+\t\t}\n+\t\tsdc->cfg = config;\n+\t} else {\n+\t\tsdc->cfg = device->data;\n+\t}\n \n \tres = platform_get_resource(pdev, IORESOURCE_MEM, 0);\n \tsdc->base = devm_ioremap_resource(&pdev->dev, res);","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"FChwERbq\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xk0dr3V8Kz9s7c\n\tfor ;\n\tFri, 1 Sep 2017 10:35:44 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnZvw-0002uF-PR; Fri, 01 Sep 2017 00:35:40 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnZvt-0002rI-Bw for linux-arm-kernel@lists.infradead.org;\n\tFri, 01 Sep 2017 00:35:39 +0000","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 710842B;\n\tThu, 31 Aug 2017 17:35:15 -0700 (PDT)","from slackpad.lan (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t776603F58F; Thu, 31 Aug 2017 17:35:13 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:\n\tMessage-Id:Date:Subject:To:From:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=zkNIynuI3+5D6e/5DMnWY72VBepVWorVbWnHJamtFFc=;\n\tb=FChwERbq7y2m/q\n\tNxmbWYWasamqCH62oAbRdbiRXgVcHLLkpHJP9ZJ8DhwitXjz/MQpfxS2rBi4y8qQlooSBaeAn2Pba\n\tRt7/7FtPC66xqS8z3lftn4MJ9fCb6ZlHYB7oe2XExZOf6I3RGRhK4GE2NABqIgb34DJp++8o0kmif\n\tlKAVH5kUu7NZ8beSffeI3BEdPkN1ewFkagrIYfyML/TeKGcmlp73bZTao2inPESldIfNJF/CZVGEI\n\ttIRaHz9wQ3H4gHPeeD66ywGH4UVE62BLWdv19hfTD8B6e0XkT5FTB3rnu2Y/ts5Ff6IR5ZkspzZ+p\n\th8XEwszGZVX6XuS1h/wA==;","From":"Andre Przywara ","To":"=?utf-8?q?Stefan_Br=C3=BCns?= ","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","Date":"Fri, 1 Sep 2017 01:31:35 +0100","Message-Id":"<20170901003135.10058-1-andre.przywara@arm.com>","X-Mailer":"git-send-email 2.14.1","In-Reply-To":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>","MIME-Version":"1.0","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170831_173537_516896_56872483 ","X-CRM114-Status":"GOOD ( 16.81 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul ,\n\tChen-Yu Tsai , linux-kernel@vger.kernel.org,\n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org,\n\tMaxime Ripard , \n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1761418,"web_url":"http://patchwork.ozlabs.org/comment/1761418/","msgid":"<1837534.s5pz9jWHnV@pebbles.site>","list_archive_url":null,"date":"2017-09-01T01:19:50","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":67055,"url":"http://patchwork.ozlabs.org/api/people/67055/","name":"Stefan Brüns","email":"stefan.bruens@rwth-aachen.de"},"content":"On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:\n> Hi,\n> \n> On 31/08/17 00:36, 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. Add the proper config data\n> > and compatible string to support it.\n> \n> ...\n> \n> > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> > index 5f4eee4513e5..6a17c5d63582 100644\n> > --- a/drivers/dma/sun6i-dma.c\n> > +++ b/drivers/dma/sun6i-dma.c\n> > @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {\n> > \n> > \t.nr_max_vchans = 34,\n> > \t.dmac_variant = DMAC_VARIANT_H3,\n> > \n> > };\n> > \n> > +\n> > +static struct sun6i_dma_config sun50i_a64_dma_cfg = {\n> > +\t.nr_max_channels = 8,\n> > +\t.nr_max_requests = 27,\n> > +\t.nr_max_vchans = 38,\n> > +\t.dmac_variant = DMAC_VARIANT_H3,\n> > \n> > };\n> > \n> > static const struct of_device_id sun6i_dma_match[] = {\n> > \n> > @@ -1075,6 +1081,7 @@ static const struct of_device_id sun6i_dma_match[] =\n> > {> \n> > \t{ .compatible = \"allwinner,sun8i-a23-dma\", .data = &sun8i_a23_dma_cfg \n},\n> > \t{ .compatible = \"allwinner,sun8i-a83t-dma\", .data = &sun8i_a83t_dma_cfg\n> > \t},\n> > \t{ .compatible = \"allwinner,sun8i-h3-dma\", .data = &sun8i_h3_dma_cfg },\n> > \n> > +\t{ .compatible = \"allwinner,sun50i-a64-dma\", .data = &sun50i_a64_dma_cfg\n> > },> \n> > \t{ /* sentinel */ }\n> > \n> > };\n> > MODULE_DEVICE_TABLE(of, sun6i_dma_match);\n> \n> I was wondering if should use the opportunity to expose those values as\n> DT properties instead of hard-wiring them to a compatible string in the\n> driver every time we add support for a new SoC?\n> We could introduce a new compatible string (say: \"allwinner,sunxi-dma\"),\n> then describe properties for the number of channels and requests and\n> vchans and parse those from the DT at probe time.\n> With this we might be able to support future SoCs without Linux *driver*\n> changes, by just providing the right DT. This would have worked already\n> for instance for the A83T support, which just changed those values.\n> \n> For instance with this quick patch below (just compile tested, and without\n> your refactoring).\n> The DT node would then read something like:\n> \tdma: dma-controller@01c02000 {\n> \t\tcompatible = \"allwinner,sun50i-a64-dma\",\n> \t\t\t \"allwinner,sunxi-dma\";\n> \t\treg = <0x01c02000 0x1000>;\n> \t\tinterrupts = ;\n> \t\tclocks = <&ccu CLK_BUS_DMA>;\n> \t\tresets = <&ccu RST_BUS_DMA>;\n> \t\t#dma-cells = <1>;\n> \t\tallwinner,max_channels = <8>;\n> \t\tallwinner,max_requests = <27>;\n> \t\tallwinner,max_vchans = <38>;\n> \t};\n\nFor these 3 properties it likely is a good idea, but we would IMHO still have \nto care for the differences in the register settings:\n\n- A31 does not have a clock autogating register\n- A23 and A83t does have one at offset 0x20\n- A64, H3, H5 and R40 have it at offset 0x28\n\nThere are also the incompatibilities in the \"DMA channel configuration \nregister\" (burst length; burst width; burst length field offset).\n\nWe can either have 3 different compatible strings, or another property for the \nregister model.\n\nFor the aw,max_requests and aw,max_vchans, maybe a bitmask per direction is a \nbetter option - it can encode the allowed DRQ numbers much better (e.g. for \nH3, the highest source DRQ is 24). The DRQ field in the channel configuration \nregister is 5 bits, so the hightest port/DRQ number is 31.\n\nFor aw,max_channels my first thought is - why max? is it variable? is there a \nmin_channels? My suggestion would be (in order of preference): \"aw,channels\", \n\"aw,dma_channels\", \"aw,available_channels\".\n\nKind regards,\n\nStefan","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"TkopXac/\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xk1dR3DM9z9sNr\n\tfor ;\n\tFri, 1 Sep 2017 11:20:25 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnadB-0005ky-Cl; Fri, 01 Sep 2017 01:20:21 +0000","from mail-out-2.itc.rwth-aachen.de ([134.130.5.47])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnad7-0004WF-4p for linux-arm-kernel@lists.infradead.org;\n\tFri, 01 Sep 2017 01:20:19 +0000","from rwthex-w2-b.rwth-ad.de ([134.130.26.159])\n\tby mail-in-2.itc.rwth-aachen.de with ESMTP; 01 Sep 2017 03:19:51 +0200","from pebbles.site (78.49.70.254) 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; Fri, 1 Sep 2017 03:19:51 +0200"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:\n\tMessage-ID:Date:Subject:To:From:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=++alEtRtWjxpLmmek2COHlOhnmzqs38SS1ci8th5nvg=;\n\tb=TkopXac/CcpDYQ\n\tcD1inNFwpji2uiMb31Y7RBF/ej8Y6hEk7qUVAea0NSCMO5A/s4wUbg6C30Hsji1L414RKcDWnt6R6\n\tOw1MVGVEW2gj3Wq2XjbK0s7ljjCk/VREHgqbk6B/EmumWOedM91daxM+cXM7SzLpo9Y3lRdNxwUrS\n\tKT3mt7JABU8XInQgyEqisZ1yLx9Q63PoY1OD2KPtUfk+P70xZiH5PKyZhs+NWmDLeoBu4RtVH2BCK\n\tyU/LlAhQtS6TQe5Rj2dwBL7DqR0oidjJw4Q/qRN88oAHBfGux6/vuembYraTd0wBaTrTLQ2+1P5DX\n\tUdSfUlHtERB1DAYcVGPg==;","X-IronPort-AV":"E=Sophos;i=\"5.41,456,1498514400\"; d=\"scan'208\";a=\"11226828\"","From":"Stefan Bruens ","To":"Andre Przywara ","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","Date":"Fri, 1 Sep 2017 03:19:50 +0200","Message-ID":"<1837534.s5pz9jWHnV@pebbles.site>","In-Reply-To":"<20170901003135.10058-1-andre.przywara@arm.com>","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<20170901003135.10058-1-andre.przywara@arm.com>","MIME-Version":"1.0","X-Originating-IP":"[78.49.70.254]","X-ClientProxiedBy":"rwthex-s2-b.rwth-ad.de (2002:8682:1a9b::8682:1a9b) To\n\trwthex-w2-b.rwth-ad.de (2002:8682:1a9f::8682:1a9f)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170831_182017_487062_0C29277D ","X-CRM114-Status":"GOOD ( 19.70 )","X-Spam-Score":"-4.2 (----)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-4.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\n\tmedium trust [134.130.5.47 listed in list.dnswl.org]\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul ,\n\tChen-Yu Tsai , linux-kernel@vger.kernel.org,\n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org,\n\tMaxime Ripard , \n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1761479,"web_url":"http://patchwork.ozlabs.org/comment/1761479/","msgid":"<20170901060445.vboici7qxfkztp3s@flea>","list_archive_url":null,"date":"2017-09-01T06:04:45","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"On Fri, Sep 01, 2017 at 01:31:35AM +0100, Andre Przywara wrote:\n> Hi,\n> \n> On 31/08/17 00:36, 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. Add the proper config data\n> > and compatible string to support it.\n> \n> ...\n> \n> > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> > index 5f4eee4513e5..6a17c5d63582 100644\n> > --- a/drivers/dma/sun6i-dma.c\n> > +++ b/drivers/dma/sun6i-dma.c\n> > @@ -1068,6 +1068,12 @@ 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> > +static struct sun6i_dma_config sun50i_a64_dma_cfg = {\n> > +\t.nr_max_channels = 8,\n> > +\t.nr_max_requests = 27,\n> > +\t.nr_max_vchans = 38,\n> > +\t.dmac_variant = DMAC_VARIANT_H3,\n> > };\n> > \n> > static const struct of_device_id sun6i_dma_match[] = {\n> > @@ -1075,6 +1081,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> \n> I was wondering if should use the opportunity to expose those values as\n> DT properties instead of hard-wiring them to a compatible string in the\n> driver every time we add support for a new SoC?\n> We could introduce a new compatible string (say: \"allwinner,sunxi-dma\"),\n> then describe properties for the number of channels and requests and\n> vchans and parse those from the DT at probe time.\n> With this we might be able to support future SoCs without Linux *driver*\n> changes, by just providing the right DT. This would have worked already\n> for instance for the A83T support, which just changed those values.\n> \n> For instance with this quick patch below (just compile tested, and without\n> your refactoring).\n> The DT node would then read something like:\n> \tdma: dma-controller@01c02000 {\n> \t\tcompatible = \"allwinner,sun50i-a64-dma\",\n> \t\t\t \"allwinner,sunxi-dma\";\n> \t\treg = <0x01c02000 0x1000>;\n> \t\tinterrupts = ;\n> \t\tclocks = <&ccu CLK_BUS_DMA>;\n> \t\tresets = <&ccu RST_BUS_DMA>;\n> \t\t#dma-cells = <1>;\n> \t\tallwinner,max_channels = <8>;\n> \t\tallwinner,max_requests = <27>;\n> \t\tallwinner,max_vchans = <38>;\n> \t};\n\nWe're still going to need a different compatible anyway, so it's not\nreally like it would change anything.\n\nMaxime","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"uQMsTr7l\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xk7y64KS9z9s8J\n\tfor ;\n\tFri, 1 Sep 2017 16:05:18 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnf4t-0007WZ-8K; Fri, 01 Sep 2017 06:05:15 +0000","from mail.free-electrons.com ([62.4.15.54])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnf4l-0006IT-Hf for linux-arm-kernel@lists.infradead.org;\n\tFri, 01 Sep 2017 06:05:13 +0000","by mail.free-electrons.com (Postfix, from userid 110)\n\tid EFE3420989; Fri, 1 Sep 2017 08:04:44 +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 C49642097E;\n\tFri, 1 Sep 2017 08:04:44 +0200 (CEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc:\n\tList-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:\n\tIn-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;\n\tbh=JCtY7yhGIQ6iFIUnixGyplGm4dIniuZqog1WhuwlKHU=;\n\tb=uQMsTr7lNEp7wVSqoBcRRBlVO\n\tjTVFVzDKVpxPFlQCgGcj9G4Ypj1UuPobPNKB4TDoPIuMrqXc2ftvE1Il+UmUAKOPJy+UUN37iKdIj\n\tsaGHdWt8i5+dGKkxNV53uIFPW5PvcH0OcH70WL14OOir5+3jEyFwY/dA3HvMXjNoP1EOxji+1Lryb\n\tVxsO+ZleZtQ3opKIaq9SkGHN1vGeSlsKsL6qzo/jmvt2ZTd5KAE3XJwLivs0GDueR0ScbB9xPRMWa\n\tbrpgcY1MMETCXNWLTDZ5hkysrh1trsvN/Mz1pTk+ErU68WEWCySvyueYwZqv+NUUOlfgdnozmv0FN\n\tKRzAsQfdQ==;","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":"Fri, 1 Sep 2017 08:04:45 +0200","From":"Maxime Ripard ","To":"Andre Przywara ","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","Message-ID":"<20170901060445.vboici7qxfkztp3s@flea>","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<20170901003135.10058-1-andre.przywara@arm.com>","MIME-Version":"1.0","In-Reply-To":"<20170901003135.10058-1-andre.przywara@arm.com>","User-Agent":"NeoMutt/20170714 (1.8.3)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170831_230507_895645_9AC6FD2C ","X-CRM114-Status":"GOOD ( 23.98 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul , Chen-Yu\n\tTsai , linux-kernel@vger.kernel.org, \n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org, Stefan =?iso-8859-1?q?Br=FCns?=\n\t, linux-arm-kernel@lists.infradead.org","Content-Type":"multipart/mixed;\n\tboundary=\"===============2081514087133377358==\"","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1762018,"web_url":"http://patchwork.ozlabs.org/comment/1762018/","msgid":"","list_archive_url":null,"date":"2017-09-01T22:32:50","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":61837,"url":"http://patchwork.ozlabs.org/api/people/61837/","name":"Andre Przywara","email":"andre.przywara@arm.com"},"content":"Hi,\n\nOn 01/09/17 02:19, Stefan Bruens wrote:\n> On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:\n>> Hi,\n>>\n>> On 31/08/17 00:36, 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. Add the proper config data\n>>> and compatible string to support it.\n>>\n>> ...\n>>\n>>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n>>> index 5f4eee4513e5..6a17c5d63582 100644\n>>> --- a/drivers/dma/sun6i-dma.c\n>>> +++ b/drivers/dma/sun6i-dma.c\n>>> @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {\n>>>\n>>> \t.nr_max_vchans = 34,\n>>> \t.dmac_variant = DMAC_VARIANT_H3,\n>>> \n>>> };\n>>>\n>>> +\n>>> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {\n>>> +\t.nr_max_channels = 8,\n>>> +\t.nr_max_requests = 27,\n>>> +\t.nr_max_vchans = 38,\n>>> +\t.dmac_variant = DMAC_VARIANT_H3,\n>>>\n>>> };\n>>> \n>>> static const struct of_device_id sun6i_dma_match[] = {\n>>>\n>>> @@ -1075,6 +1081,7 @@ static const struct of_device_id sun6i_dma_match[] =\n>>> {> \n>>> \t{ .compatible = \"allwinner,sun8i-a23-dma\", .data = &sun8i_a23_dma_cfg \n> },\n>>> \t{ .compatible = \"allwinner,sun8i-a83t-dma\", .data = &sun8i_a83t_dma_cfg\n>>> \t},\n>>> \t{ .compatible = \"allwinner,sun8i-h3-dma\", .data = &sun8i_h3_dma_cfg },\n>>>\n>>> +\t{ .compatible = \"allwinner,sun50i-a64-dma\", .data = &sun50i_a64_dma_cfg\n>>> },> \n>>> \t{ /* sentinel */ }\n>>> \n>>> };\n>>> MODULE_DEVICE_TABLE(of, sun6i_dma_match);\n>>\n>> I was wondering if should use the opportunity to expose those values as\n>> DT properties instead of hard-wiring them to a compatible string in the\n>> driver every time we add support for a new SoC?\n>> We could introduce a new compatible string (say: \"allwinner,sunxi-dma\"),\n>> then describe properties for the number of channels and requests and\n>> vchans and parse those from the DT at probe time.\n>> With this we might be able to support future SoCs without Linux *driver*\n>> changes, by just providing the right DT. This would have worked already\n>> for instance for the A83T support, which just changed those values.\n>>\n>> For instance with this quick patch below (just compile tested, and without\n>> your refactoring).\n>> The DT node would then read something like:\n>> \tdma: dma-controller@01c02000 {\n>> \t\tcompatible = \"allwinner,sun50i-a64-dma\",\n>> \t\t\t \"allwinner,sunxi-dma\";\n>> \t\treg = <0x01c02000 0x1000>;\n>> \t\tinterrupts = ;\n>> \t\tclocks = <&ccu CLK_BUS_DMA>;\n>> \t\tresets = <&ccu RST_BUS_DMA>;\n>> \t\t#dma-cells = <1>;\n>> \t\tallwinner,max_channels = <8>;\n>> \t\tallwinner,max_requests = <27>;\n>> \t\tallwinner,max_vchans = <38>;\n>> \t};\n> \n> For these 3 properties it likely is a good idea, but we would IMHO still have \n> to care for the differences in the register settings:\n> \n> - A31 does not have a clock autogating register\n> - A23 and A83t does have one at offset 0x20\n> - A64, H3, H5 and R40 have it at offset 0x28\n\nFair enough - I didn't look too closely at your new changes, especially\nwhy it apparently worked before.\nBut as your list shows, we would only need one compatible string per\nline - in the driver - to cover all SoCs (and possibly future SoCs!),\nand do the rest via the properties.\nWe can't use the existing h3 compatible string or touch the already\nexisting SoCs and compatible strings, of course, but I guess\nthe A64, R40 and future SoCs could make use of a new (generic?) string.\n\n> There are also the incompatibilities in the \"DMA channel configuration \n> register\" (burst length; burst width; burst length field offset).\n> \n> We can either have 3 different compatible strings, or another property for the \n> register model.\n\nThe latter is usually frowned upon, using separate compatible strings\nfor each group of SoCs is the way to go here.\n\n> For the aw,max_requests and aw,max_vchans, maybe a bitmask per direction is a \n> better option - it can encode the allowed DRQ numbers much better (e.g. for \n> H3, the highest source DRQ is 24). The DRQ field in the channel configuration \n> register is 5 bits, so the hightest port/DRQ number is 31.\n\nSo looking more closely at the manual and the code my understanding is\nthat nr_max_requests is more or less some rough molly guard to prevent\nwrong settings? Derived from the DRQ table in the manual?\nSo that trying to program port 28 on an H3 would fail?\nBut source port 25 or dest port 26 wouldn't be caught by this check,\nthough they would still be \"illegal\" according to the manual. (Which we\nare not sure of, I guess, it may just not be documented)\nSo I wonder if this nr_max_requests is useful at all, and we should just\ncheck that it fits into 5 bits and assume that the DT has superior\nknowledge of what's allowed and what not.\nNow I see what you mean with the bitmask (to cover those gaps), but I am\nbit sceptical if that is actually useful. After all the DRQ number would\nbe coming from the DT, which we can surely trust.\n\nAnd nr_max_vchans seems to describe the sum of documented DRQs, to just\nlimit the memory allocation? So this could become just 64 to cover all\npossible cases without SoC specific configuration at all?\n\n> For aw,max_channels my first thought is - why max? is it variable? is there a \n> min_channels? My suggestion would be (in order of preference): \"aw,channels\", \n> \"aw,dma_channels\", \"aw,available_channels\".\n\nSure, actually looking at Documentation/devicetree/bindings/dma/dma.txt\nI think we can even use the generic \"dma-channels\" property described\nthere. And possibly the same with \"dma-requests\", should we keep this.\n\nSo summarizing this:\n- We create a new compatible string, which drives an H3 compatible DMA\n(clock autogating at 0x28, 64-bit data width capable). This name could\neither be generic, or actually \"allwinner,sun50i-a64-dma\".\n- This one sets nr_max_requests to 31 and nr_max_vchans to 64.\n- Alternatively we expose those values in the DT as properties.\n- We take the number of DMA channels from the (now required)\n\"dma-channels\" property.\n- We let the A64 (and R40?) use this new binding.\n- Any future SoC which is close enough can then just piggy-back on this.\n- Any future *changes* in the Allwinner DMA device which require driver\nchanges create a new compatible string, but still keep the above\nsemantics. Chances are that there are more than one SoC using this kind\nof new DMA device, so they would work out of the box.\n\nDoes that make sense?\nI am happy to provide the code for that, based on your H3 rework.\n\nCheers,\nAndre.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"bUCeDrmb\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xkYyS1BLxz9s83\n\tfor ;\n\tSat, 2 Sep 2017 08:37:04 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnuYd-0003a8-Tn; Fri, 01 Sep 2017 22:36:59 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnuYZ-0003WF-Tl for linux-arm-kernel@lists.infradead.org;\n\tFri, 01 Sep 2017 22:36:58 +0000","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 0F5B62B;\n\tFri, 1 Sep 2017 15:36: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\t5A7BD3F58F; Fri, 1 Sep 2017 15:36:32 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:References:To:Subject:From:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=eyquG3ceznqHUpnetE49nJ1jFIJauRAjzmsgJgbNu+c=;\n\tb=bUCeDrmb5NMjAt\n\tEZtTJEPlX7gc/SJfzLOzYvEBpISGqbkAG0r0gQRrQDDItU4zl2LxSj51zJrMYNC5ad7xYWxvuPmNH\n\tpZhp0Hw3b/Zh5Gj9tIVcxpzKspe7GRd9QVqKNY0Sschp8ZjHc+nkV4dWKLf8QdimEc5XinAp71iD+\n\twYNFUAdF4o1Ua2CXtDLzDER7cgmESgy2Hb0aO2Lq1Zv5ze6/Mg50OY58fvekmmmedU3twot6TznO7\n\tVkQkVXntGALj0mV8Jn+kB1NiNBxKv9j5nu2zXFjQfwaFiJVAgRdmi/XaruxUCO+XpnqfXBH3tHCZJ\n\ttwTiHCT4pE8P8qXWLpNw==;","From":"=?utf-8?q?Andr=C3=A9_Przywara?= ","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","To":"Stefan Bruens ","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<20170901003135.10058-1-andre.przywara@arm.com>\n\t<1837534.s5pz9jWHnV@pebbles.site>","Organization":"ARM Ltd.","Message-ID":"","Date":"Fri, 1 Sep 2017 23:32:50 +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":"<1837534.s5pz9jWHnV@pebbles.site>","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170901_153656_116546_10B425BA ","X-CRM114-Status":"GOOD ( 30.18 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul ,\n\tChen-Yu Tsai , linux-kernel@vger.kernel.org,\n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org,\n\tMaxime Ripard , \n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1762020,"web_url":"http://patchwork.ozlabs.org/comment/1762020/","msgid":"<743ae23a-372a-762b-c345-b914f09fd718@arm.com>","list_archive_url":null,"date":"2017-09-01T22:35:40","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":61837,"url":"http://patchwork.ozlabs.org/api/people/61837/","name":"Andre Przywara","email":"andre.przywara@arm.com"},"content":"On 01/09/17 07:04, Maxime Ripard wrote:\n> On Fri, Sep 01, 2017 at 01:31:35AM +0100, Andre Przywara wrote:\n>> Hi,\n>>\n>> On 31/08/17 00:36, 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. Add the proper config data\n>>> and compatible string to support it.\n>>\n>> ...\n>>\n>>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n>>> index 5f4eee4513e5..6a17c5d63582 100644\n>>> --- a/drivers/dma/sun6i-dma.c\n>>> +++ b/drivers/dma/sun6i-dma.c\n>>> @@ -1068,6 +1068,12 @@ 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>>> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {\n>>> +\t.nr_max_channels = 8,\n>>> +\t.nr_max_requests = 27,\n>>> +\t.nr_max_vchans = 38,\n>>> +\t.dmac_variant = DMAC_VARIANT_H3,\n>>> };\n>>> \n>>> static const struct of_device_id sun6i_dma_match[] = {\n>>> @@ -1075,6 +1081,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>>\n>> I was wondering if should use the opportunity to expose those values as\n>> DT properties instead of hard-wiring them to a compatible string in the\n>> driver every time we add support for a new SoC?\n>> We could introduce a new compatible string (say: \"allwinner,sunxi-dma\"),\n>> then describe properties for the number of channels and requests and\n>> vchans and parse those from the DT at probe time.\n>> With this we might be able to support future SoCs without Linux *driver*\n>> changes, by just providing the right DT. This would have worked already\n>> for instance for the A83T support, which just changed those values.\n>>\n>> For instance with this quick patch below (just compile tested, and without\n>> your refactoring).\n>> The DT node would then read something like:\n>> \tdma: dma-controller@01c02000 {\n>> \t\tcompatible = \"allwinner,sun50i-a64-dma\",\n>> \t\t\t \"allwinner,sunxi-dma\";\n>> \t\treg = <0x01c02000 0x1000>;\n>> \t\tinterrupts = ;\n>> \t\tclocks = <&ccu CLK_BUS_DMA>;\n>> \t\tresets = <&ccu RST_BUS_DMA>;\n>> \t\t#dma-cells = <1>;\n>> \t\tallwinner,max_channels = <8>;\n>> \t\tallwinner,max_requests = <27>;\n>> \t\tallwinner,max_vchans = <38>;\n>> \t};\n> \n> We're still going to need a different compatible anyway, so it's not\n> really like it would change anything.\n\nWell, not for now, but possibly in the future. And we should start with\nthis at one point. If we would have had this type of binding already for\nH3, we could have added the A64 support without driver changes just by a\nDT change.\n\nCheers,\nAndre.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"Pmpib+/v\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xkZ1X1cjkz9sRV\n\tfor ;\n\tSat, 2 Sep 2017 08:39:44 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnubF-0005ak-6c; Fri, 01 Sep 2017 22:39:41 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnubB-0004zs-Q8 for linux-arm-kernel@lists.infradead.org;\n\tFri, 01 Sep 2017 22:39:39 +0000","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 9407F2B;\n\tFri, 1 Sep 2017 15:39:17 -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\tC9B983F58F; Fri, 1 Sep 2017 15:39:15 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=D6k5lWEglCzl+ECpoIDUwaYYm1+YfhjSxv7JnDwSOcA=;\n\tb=Pmpib+/vzpuWDQ\n\tVfFMsQ0r8e+XqmTvDvRVctm6tIXhI+7gQnVl0vqB59SWHU9j8hO+KxscxpAwIs/is/2U84nRbis2e\n\tQlj1M9CffwfiXfiKq8Mtg58C51efJ3SeV4BgasAScbJb/F3uO6Y6KWb+XGBUEK3U5Uqh7kz1SBtfn\n\t9Prd7MSgIl3yrAfwnDCOli4EGdMW8HPeqxppwZgc1Gu4FpJIqeUY/8+4MPXUqIqwVDbBZfBM+07BT\n\tA5Sb8XxwkU6+mTAk6mhHpc5CsnT5QzWOexBr0xCqRsh3f5A0qMxunpoa9ppcxf3BGLDln12ez9+PN\n\toiYpT7q1EMAQojXVibJg==;","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","To":"Maxime Ripard ","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<20170901003135.10058-1-andre.przywara@arm.com>\n\t<20170901060445.vboici7qxfkztp3s@flea>","From":"=?utf-8?q?Andr=C3=A9_Przywara?= ","Organization":"ARM Ltd.","Message-ID":"<743ae23a-372a-762b-c345-b914f09fd718@arm.com>","Date":"Fri, 1 Sep 2017 23:35:40 +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":"<20170901060445.vboici7qxfkztp3s@flea>","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170901_153937_870495_6C0DEC0A ","X-CRM114-Status":"GOOD ( 17.41 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul , Chen-Yu\n\tTsai , linux-kernel@vger.kernel.org, \n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org, =?utf-8?q?Stefan_Br=C3=BCns?=\n\t, linux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"windows-1252\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1762050,"web_url":"http://patchwork.ozlabs.org/comment/1762050/","msgid":"<1663692.e5KjDkSFRC@pebbles.site>","list_archive_url":null,"date":"2017-09-02T00:38:31","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":67055,"url":"http://patchwork.ozlabs.org/api/people/67055/","name":"Stefan Brüns","email":"stefan.bruens@rwth-aachen.de"},"content":"On Samstag, 2. September 2017 00:32:50 CEST André Przywara wrote:\n> Hi,\n> \n> On 01/09/17 02:19, Stefan Bruens wrote:\n> > On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:\n> >> Hi,\n> >> \n> >> On 31/08/17 00:36, Stefan Brüns wrote:\n[...]\n> > \n> > For these 3 properties it likely is a good idea, but we would IMHO still\n> > have to care for the differences in the register settings:\n> > \n> > - A31 does not have a clock autogating register\n> > - A23 and A83t does have one at offset 0x20\n> > - A64, H3, H5 and R40 have it at offset 0x28\n> \n> Fair enough - I didn't look too closely at your new changes, especially\n> why it apparently worked before.\n> But as your list shows, we would only need one compatible string per\n> line - in the driver - to cover all SoCs (and possibly future SoCs!),\n> and do the rest via the properties.\n> We can't use the existing h3 compatible string or touch the already\n> existing SoCs and compatible strings, of course, but I guess\n> the A64, R40 and future SoCs could make use of a new (generic?) string.\n> \n> > There are also the incompatibilities in the \"DMA channel configuration\n> > register\" (burst length; burst width; burst length field offset).\n> > \n> > We can either have 3 different compatible strings, or another property for\n> > the register model.\n> \n> The latter is usually frowned upon, using separate compatible strings\n> for each group of SoCs is the way to go here.\n> \n> > For the aw,max_requests and aw,max_vchans, maybe a bitmask per direction\n> > is a better option - it can encode the allowed DRQ numbers much better\n> > (e.g. for H3, the highest source DRQ is 24). The DRQ field in the channel\n> > configuration register is 5 bits, so the hightest port/DRQ number is 31.\n> \n> So looking more closely at the manual and the code my understanding is\n> that nr_max_requests is more or less some rough molly guard to prevent\n> wrong settings? Derived from the DRQ table in the manual?\n> So that trying to program port 28 on an H3 would fail?\n> But source port 25 or dest port 26 wouldn't be caught by this check,\n> though they would still be \"illegal\" according to the manual. (Which we\n> are not sure of, I guess, it may just not be documented)\n> So I wonder if this nr_max_requests is useful at all, and we should just\n> check that it fits into 5 bits and assume that the DT has superior\n> knowledge of what's allowed and what not.\n> Now I see what you mean with the bitmask (to cover those gaps), but I am\n> bit sceptical if that is actually useful. After all the DRQ number would\n> be coming from the DT, which we can surely trust.\n> \n> And nr_max_vchans seems to describe the sum of documented DRQs, to just\n> limit the memory allocation? So this could become just 64 to cover all\n> possible cases without SoC specific configuration at all?\n\nYes, thats my understanding as well. Allocating a few excess channels would \nwaste a few kBytes (AFAICS 304 bytes per channel on 64bit).\n \n> > For aw,max_channels my first thought is - why max? is it variable? is\n> > there a min_channels? My suggestion would be (in order of preference):\n> > \"aw,channels\", \"aw,dma_channels\", \"aw,available_channels\".\n> \n> Sure, actually looking at Documentation/devicetree/bindings/dma/dma.txt\n> I think we can even use the generic \"dma-channels\" property described\n> there. And possibly the same with \"dma-requests\", should we keep this.\n> \n> So summarizing this:\n> - We create a new compatible string, which drives an H3 compatible DMA\n> (clock autogating at 0x28, 64-bit data width capable). This name could\n> either be generic, or actually \"allwinner,sun50i-a64-dma\".\n> - This one sets nr_max_requests to 31 and nr_max_vchans to 64.\n> - Alternatively we expose those values in the DT as properties.\n> - We take the number of DMA channels from the (now required)\n> \"dma-channels\" property.\n> - We let the A64 (and R40?) use this new binding.\n> - Any future SoC which is close enough can then just piggy-back on this.\n> - Any future *changes* in the Allwinner DMA device which require driver\n> changes create a new compatible string, but still keep the above\n> semantics. Chances are that there are more than one SoC using this kind\n> of new DMA device, so they would work out of the box.\n> \n> Does that make sense?\n> I am happy to provide the code for that, based on your H3 rework.\n\nSounds good for me. I will send a cleaned up series later.\n\nKind regards,\n\nStefan","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"JIS9awJH\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xkcgG6l5Wz9s76\n\tfor ;\n\tSat, 2 Sep 2017 10:39:06 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnwSl-0006no-AZ; Sat, 02 Sep 2017 00:39:03 +0000","from mail-out-2.itc.rwth-aachen.de ([134.130.5.47])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnwSh-0006Tc-9F for linux-arm-kernel@lists.infradead.org;\n\tSat, 02 Sep 2017 00:39:01 +0000","from rwthex-w2-b.rwth-ad.de ([134.130.26.159])\n\tby mail-in-2.itc.rwth-aachen.de with ESMTP; 02 Sep 2017 02:38:33 +0200","from pebbles.site (77.182.61.44) 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; Sat, 2 Sep 2017 02:38:32 +0200"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:\n\tMessage-ID:Date:Subject:To:From:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=4zV5Mg38KJZDMSJSQ9WZPibr45pGSVlS29nwr/C9/eo=;\n\tb=JIS9awJH9QThkC\n\t4ItWw+b5YUuDFMhR+D8AkDdauVqDA9vElBQ9ubkm0sPjwXsuciOI6yQFT4NVOqW5iKntOwH1oH/wq\n\tQahf3/r8h3AZJpl65+2h5jRHdD2C34WaJSTybJM7rSOiSj+UYgDnNs4obup141muVE8P24dT286ts\n\txe1ZWNmP95tJuSLGcuxYgK5YT1YIwxbxOlfInJguSI0c5EQhZLmmG2N0XBq7S/KTPYrJMYS1THV+R\n\tGiq70sgv31zXfoOjz/puCpWr04sLoDa1efdsqkZLcPf5BtjK8unVwFxauSleRuk0/UMB3sSVLqLsE\n\tXhkA6cCDFw3fWznuC/DQ==;","X-IronPort-AV":"E=Sophos;i=\"5.41,459,1498514400\"; d=\"scan'208\";a=\"11443219\"","From":"Stefan Bruens ","To":"=?iso-8859-1?q?Andr=E9?= Przywara ","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","Date":"Sat, 2 Sep 2017 02:38:31 +0200","Message-ID":"<1663692.e5KjDkSFRC@pebbles.site>","In-Reply-To":"","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<1837534.s5pz9jWHnV@pebbles.site>\n\t","MIME-Version":"1.0","X-Originating-IP":"[77.182.61.44]","X-ClientProxiedBy":"rwthex-s2-a.rwth-ad.de (2002:8682:1a9a::8682:1a9a) To\n\trwthex-w2-b.rwth-ad.de (2002:8682:1a9f::8682:1a9f)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170901_173859_711492_4B6AFA47 ","X-CRM114-Status":"GOOD ( 29.66 )","X-Spam-Score":"-4.2 (----)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-4.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\n\tmedium trust [134.130.5.47 listed in list.dnswl.org]\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul ,\n\tChen-Yu Tsai , linux-kernel@vger.kernel.org,\n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org,\n\tMaxime Ripard , \n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1762063,"web_url":"http://patchwork.ozlabs.org/comment/1762063/","msgid":"<2607878.Us0MSlEf6n@pebbles.site>","list_archive_url":null,"date":"2017-09-02T02:02:12","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":67055,"url":"http://patchwork.ozlabs.org/api/people/67055/","name":"Stefan Brüns","email":"stefan.bruens@rwth-aachen.de"},"content":"On Samstag, 2. September 2017 00:32:50 CEST André Przywara wrote:\n> Hi,\n> \n> On 01/09/17 02:19, Stefan Bruens wrote:\n> > On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:\n> >> Hi,\n> >> \n> >> On 31/08/17 00:36, 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. Add the proper config data\n> >>> and compatible string to support it.\n> >> \n> >> ...\n> >> \n> >>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> >>> index 5f4eee4513e5..6a17c5d63582 100644\n> >>> --- a/drivers/dma/sun6i-dma.c\n> >>> +++ b/drivers/dma/sun6i-dma.c\n> >>> @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg =\n> >>> {\n> >>> \n> >>> \t.nr_max_vchans = 34,\n> >>> \t.dmac_variant = DMAC_VARIANT_H3,\n> >>> \n> >>> };\n> >>> \n> >>> +\n> >>> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {\n> >>> +\t.nr_max_channels = 8,\n> >>> +\t.nr_max_requests = 27,\n> >>> +\t.nr_max_vchans = 38,\n> >>> +\t.dmac_variant = DMAC_VARIANT_H3,\n> >>> \n> >>> };\n> >>> \n[...]\n> > There are also the incompatibilities in the \"DMA channel configuration\n> > register\" (burst length; burst width; burst length field offset).\n> > \n> > We can either have 3 different compatible strings, or another property for\n> > the register model.\n> \n> The latter is usually frowned upon, using separate compatible strings\n> for each group of SoCs is the way to go here.\n\nJust for clarification, I was not talking about a property in the devicetree, \nbut about a struct member in the config data, i.e. the .dmac_variant above.\n\nKind regards,\n\nStefan","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"kmX0AzbY\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xkfWs1GgFz9s0g\n\tfor ;\n\tSat, 2 Sep 2017 12:02:49 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnxlk-0002hl-FX; Sat, 02 Sep 2017 02:02:44 +0000","from mail-out-1.itc.rwth-aachen.de ([134.130.5.46])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnxlf-0002dZ-LK for linux-arm-kernel@lists.infradead.org;\n\tSat, 02 Sep 2017 02:02:42 +0000","from rwthex-w2-b.rwth-ad.de ([134.130.26.159])\n\tby mail-in-1.itc.rwth-aachen.de with ESMTP; 02 Sep 2017 04:02:14 +0200","from pebbles.site (77.182.61.44) 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; Sat, 2 Sep 2017 04:02:13 +0200"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:\n\tMessage-ID:Date:Subject:To:From:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=Fho9NnQOsYVOCwcjArkN4A/hN3M+18gJVGIMHpunY1s=;\n\tb=kmX0AzbYDdzh0H\n\t4w4f9X+bWoZBMXf+JuC6JmY9pTRTnGYHaez6tUZaydaq0hyOiZVDpgsW5K8fLL8VtfqZ6Jlm9Z+l1\n\tj8EpweQFGTbRCi4xUGYOxPxJBqzH9wIeswXhMKGJ8m84HaV/FcGY8tl9I9nVRYWnA4qzFxnhnZCTi\n\t9Wcdi85hnsq1DztTH+ycwUAA7Npjmb0d3AxWeubgOmzf6gfD5mrt5Hu6RWHTcYarvwjrFpZnwxm4K\n\tvZe2IMlU5jJAWW6Id/Z6zVQV7QZbg/aBZuZun7pKCh2SeyCKABSCCgt4gTTdrSEQEAeU7nWha7dQ0\n\tfB8CveUBDH1M+O4T1Rmg==;","X-IronPort-AV":"E=Sophos;i=\"5.41,461,1498514400\"; d=\"scan'208\";a=\"11443706\"","From":"Stefan Bruens ","To":"=?iso-8859-1?q?Andr=E9?= Przywara ","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","Date":"Sat, 2 Sep 2017 04:02:12 +0200","Message-ID":"<2607878.Us0MSlEf6n@pebbles.site>","In-Reply-To":"","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<1837534.s5pz9jWHnV@pebbles.site>\n\t","MIME-Version":"1.0","X-Originating-IP":"[77.182.61.44]","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)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170901_190240_036198_13E557AF ","X-CRM114-Status":"GOOD ( 11.84 )","X-Spam-Score":"-4.2 (----)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-4.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\n\tmedium trust [134.130.5.46 listed in list.dnswl.org]\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul ,\n\tChen-Yu Tsai , linux-kernel@vger.kernel.org,\n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org,\n\tMaxime Ripard , \n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1762342,"web_url":"http://patchwork.ozlabs.org/comment/1762342/","msgid":"","list_archive_url":null,"date":"2017-09-03T23:14:22","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":61837,"url":"http://patchwork.ozlabs.org/api/people/61837/","name":"Andre Przywara","email":"andre.przywara@arm.com"},"content":"On 02/09/17 03:02, Stefan Bruens wrote:\n> On Samstag, 2. September 2017 00:32:50 CEST André Przywara wrote:\n>> Hi,\n>>\n>> On 01/09/17 02:19, Stefan Bruens wrote:\n>>> On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:\n>>>> Hi,\n>>>>\n>>>> On 31/08/17 00:36, 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. Add the proper config data\n>>>>> and compatible string to support it.\n>>>>\n>>>> ...\n>>>>\n>>>>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n>>>>> index 5f4eee4513e5..6a17c5d63582 100644\n>>>>> --- a/drivers/dma/sun6i-dma.c\n>>>>> +++ b/drivers/dma/sun6i-dma.c\n>>>>> @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg =\n>>>>> {\n>>>>>\n>>>>> \t.nr_max_vchans = 34,\n>>>>> \t.dmac_variant = DMAC_VARIANT_H3,\n>>>>> \n>>>>> };\n>>>>>\n>>>>> +\n>>>>> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {\n>>>>> +\t.nr_max_channels = 8,\n>>>>> +\t.nr_max_requests = 27,\n>>>>> +\t.nr_max_vchans = 38,\n>>>>> +\t.dmac_variant = DMAC_VARIANT_H3,\n>>>>>\n>>>>> };\n>>>>> \n> [...]\n>>> There are also the incompatibilities in the \"DMA channel configuration\n>>> register\" (burst length; burst width; burst length field offset).\n>>>\n>>> We can either have 3 different compatible strings, or another property for\n>>> the register model.\n>>\n>> The latter is usually frowned upon, using separate compatible strings\n>> for each group of SoCs is the way to go here.\n> \n> Just for clarification, I was not talking about a property in the devicetree, \n> but about a struct member in the config data, i.e. the .dmac_variant above.\n\nAh, I see. I was indeed talking about device tree nodes.\n\nSo in this case I would lean towards mapping the actual properties to\nmember names in struct sun6i_dma_config, in this case something like:\n\t.auto_clock_gate = 0x28;\n\t.max_burst_width = 16;\n\nThis looks more flexible to me and avoids hard to read code where\nproperty A is used in SoC X and Y, but property B in SoC X and Z, for\ninstance.\nIn the auto clock gate case this would result in an easy-to-read:\n\twritel(SUN8I_DMA_GATE_ENABLE,\n\t sdc->base + sdc->cfg->auto_clock_gate);\n(possibly guarded somehow to catch that A31 case)\n\nSorry for the delay in this answer, I see that you kept the\nDMAC_VARIANT_ style for your new post, and the end result doesn't look\ntoo bad. But maybe still changing this is not too hard now that you have\nmore fine grained patches?\n\nCheers,\nAndre.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"lY4+o8q0\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xlpnc0jz9z9s8J\n\tfor ;\n\tMon, 4 Sep 2017 09:18:36 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1doe9v-00005x-So; Sun, 03 Sep 2017 23:18:31 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1doe9s-0008V4-FC for linux-arm-kernel@lists.infradead.org;\n\tSun, 03 Sep 2017 23:18:30 +0000","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 C105D2B;\n\tSun, 3 Sep 2017 16:18:05 -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\t0D8D73F58F; Sun, 3 Sep 2017 16:18:03 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=YYjcTcnNEPtHm/0/5SGE4CH2qo5eBGManfOGYMKmNwo=;\n\tb=lY4+o8q0Sd+ziS\n\t0WKu2/S62UaCwYrnjdmWC9Pr9/IUNiV4R11SYCSBuXLaOLjciclsXWu1VGDxO2iMMd8hEF2pB6Szu\n\tB3h7E7A1w2oJhgAI1Cb/2m04lEiwA0SvmxTZPIk8MPWIOoJo8x9I1vSF1JDvkqDEJbXuNQHVZCmtW\n\t5e6rikkv8gM7oLM/AqTKEatilndyLWNUhA5qpGBrmVVtw9bMog8gK6vxJigAbuBg1wfwC+qO39ZKZ\n\twMG+wuSc7R/BYB+hWF4tV9qU2xd3yMVubTQZS10kCInhPljygPFrpWUlmen1uEoQgp6j8HWLyvMmA\n\thC0vS6X2eRkB0phGKD2Q==;","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","To":"Stefan Bruens ","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<1837534.s5pz9jWHnV@pebbles.site>\n\t\n\t<2607878.Us0MSlEf6n@pebbles.site>","From":"=?utf-8?q?Andr=C3=A9_Przywara?= ","Organization":"ARM Ltd.","Message-ID":"","Date":"Mon, 4 Sep 2017 00:14:22 +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":"<2607878.Us0MSlEf6n@pebbles.site>","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170903_161828_518930_3653A46A ","X-CRM114-Status":"GOOD ( 14.25 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul ,\n\tChen-Yu Tsai , linux-kernel@vger.kernel.org,\n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org,\n\tMaxime Ripard , \n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"windows-1252\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1762459,"web_url":"http://patchwork.ozlabs.org/comment/1762459/","msgid":"<20170904070415.e6nclz5n23bo7f4v@flea>","list_archive_url":null,"date":"2017-09-04T07:04:15","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"On Fri, Sep 01, 2017 at 11:35:40PM +0100, André Przywara wrote:\n> On 01/09/17 07:04, Maxime Ripard wrote:\n> > On Fri, Sep 01, 2017 at 01:31:35AM +0100, Andre Przywara wrote:\n> >> Hi,\n> >>\n> >> On 31/08/17 00:36, 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. Add the proper config data\n> >>> and compatible string to support it.\n> >>\n> >> ...\n> >>\n> >>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n> >>> index 5f4eee4513e5..6a17c5d63582 100644\n> >>> --- a/drivers/dma/sun6i-dma.c\n> >>> +++ b/drivers/dma/sun6i-dma.c\n> >>> @@ -1068,6 +1068,12 @@ 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> >>> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {\n> >>> +\t.nr_max_channels = 8,\n> >>> +\t.nr_max_requests = 27,\n> >>> +\t.nr_max_vchans = 38,\n> >>> +\t.dmac_variant = DMAC_VARIANT_H3,\n> >>> };\n> >>> \n> >>> static const struct of_device_id sun6i_dma_match[] = {\n> >>> @@ -1075,6 +1081,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> >>\n> >> I was wondering if should use the opportunity to expose those values as\n> >> DT properties instead of hard-wiring them to a compatible string in the\n> >> driver every time we add support for a new SoC?\n> >> We could introduce a new compatible string (say: \"allwinner,sunxi-dma\"),\n> >> then describe properties for the number of channels and requests and\n> >> vchans and parse those from the DT at probe time.\n> >> With this we might be able to support future SoCs without Linux *driver*\n> >> changes, by just providing the right DT. This would have worked already\n> >> for instance for the A83T support, which just changed those values.\n> >>\n> >> For instance with this quick patch below (just compile tested, and without\n> >> your refactoring).\n> >> The DT node would then read something like:\n> >> \tdma: dma-controller@01c02000 {\n> >> \t\tcompatible = \"allwinner,sun50i-a64-dma\",\n> >> \t\t\t \"allwinner,sunxi-dma\";\n> >> \t\treg = <0x01c02000 0x1000>;\n> >> \t\tinterrupts = ;\n> >> \t\tclocks = <&ccu CLK_BUS_DMA>;\n> >> \t\tresets = <&ccu RST_BUS_DMA>;\n> >> \t\t#dma-cells = <1>;\n> >> \t\tallwinner,max_channels = <8>;\n> >> \t\tallwinner,max_requests = <27>;\n> >> \t\tallwinner,max_vchans = <38>;\n> >> \t};\n> > \n> > We're still going to need a different compatible anyway, so it's not\n> > really like it would change anything.\n> \n> Well, not for now, but possibly in the future. And we should start with\n> this at one point. If we would have had this type of binding already for\n> H3, we could have added the A64 support without driver changes just by a\n> DT change.\n\nThat's not true. As usual with these kinds of generic binding\narguments (it's definitely not personal, you're far from the only one\nmaking them), it completely ignores the fact that the IP itself might\nchange from one revision to another, and its behaviour might too.\n\nThe A64 for example moved at least one register off, and has a\ndifferent set of burst size / width.\n\nIt's something you can't account for when you initially define the\nbinding, unless you describe all the registers, plus all their\nparameters and the way you interact with them, which isn't going to\nhappen if you want to keep your sanity.\n\nAnd obviously, while maintaining the stability of the binding of those\nhundreds properties.\n\nOr, you can base all this on the compatible, and be done with it once\nand for all.\n\nMaxime","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"Zx9+8DzI\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xm17Y5cRBz9s7m\n\tfor ;\n\tMon, 4 Sep 2017 17:04:57 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dolRF-0000Sj-Rs; Mon, 04 Sep 2017 07:04:53 +0000","from mail.free-electrons.com ([62.4.15.54])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dolRB-0000OW-BQ for linux-arm-kernel@lists.infradead.org;\n\tMon, 04 Sep 2017 07:04:51 +0000","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 57EC5209A0; Mon, 4 Sep 2017 09:04:24 +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 29F0F2098B;\n\tMon, 4 Sep 2017 09:04:14 +0200 (CEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc:\n\tList-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:\n\tIn-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;\n\tbh=mYc+v/gNEg6/dMWfjOgLoktD6Sj0V6ZfeYHkQAotSr8=;\n\tb=Zx9+8DzIlw9Z0lT+YLrKGOADH\n\t7nuDgilLYEhjfq1Yuo9L8eYGc6D/VcqJphJeIv1s8RsUsTrOnMHarWRO5caKiO8rIbLvELKXwDvfN\n\tqempLK1VOEPy7WkbyM5qQEjlPPYIb4IVKXJyDt1FkqVxjwCb37RbYDqNNLCT2ALV0qqbEPU0ED7sa\n\thKfMiryFqer71sP8wsHqREtC5ZaIYQ2KrQWuOapf7tmXjNEbS5LJWcdn/Syssn7UAWlcnSzM/rUoO\n\t2WMONJ0/LOC4HoQV3mPsN2X00kM9+LLiXrJ28QjMFI1Pei2zTPyzDT+Y/ThU32NRmJrtebzQ+hlhs\n\tzHQJb9l3w==;","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:04:15 +0200","From":"Maxime Ripard ","To":"=?iso-8859-1?q?Andr=E9?= Przywara ","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","Message-ID":"<20170904070415.e6nclz5n23bo7f4v@flea>","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<20170901003135.10058-1-andre.przywara@arm.com>\n\t<20170901060445.vboici7qxfkztp3s@flea>\n\t<743ae23a-372a-762b-c345-b914f09fd718@arm.com>","MIME-Version":"1.0","In-Reply-To":"<743ae23a-372a-762b-c345-b914f09fd718@arm.com>","User-Agent":"NeoMutt/20170714 (1.8.3)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170904_000449_695022_29892F41 ","X-CRM114-Status":"GOOD ( 27.57 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul , Chen-Yu\n\tTsai , linux-kernel@vger.kernel.org, \n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org, Stefan =?iso-8859-1?q?Br=FCns?=\n\t, linux-arm-kernel@lists.infradead.org","Content-Type":"multipart/mixed;\n\tboundary=\"===============0026038018820359217==\"","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1762514,"web_url":"http://patchwork.ozlabs.org/comment/1762514/","msgid":"","list_archive_url":null,"date":"2017-09-04T08:14:52","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":61837,"url":"http://patchwork.ozlabs.org/api/people/61837/","name":"Andre Przywara","email":"andre.przywara@arm.com"},"content":"Salut,\n\nOn 04/09/17 08:04, Maxime Ripard wrote:\n> On Fri, Sep 01, 2017 at 11:35:40PM +0100, André Przywara wrote:\n>> On 01/09/17 07:04, Maxime Ripard wrote:\n>>> On Fri, Sep 01, 2017 at 01:31:35AM +0100, Andre Przywara wrote:\n>>>> Hi,\n>>>>\n>>>> On 31/08/17 00:36, 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. Add the proper config data\n>>>>> and compatible string to support it.\n>>>>\n>>>> ...\n>>>>\n>>>>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c\n>>>>> index 5f4eee4513e5..6a17c5d63582 100644\n>>>>> --- a/drivers/dma/sun6i-dma.c\n>>>>> +++ b/drivers/dma/sun6i-dma.c\n>>>>> @@ -1068,6 +1068,12 @@ 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>>>>> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {\n>>>>> +\t.nr_max_channels = 8,\n>>>>> +\t.nr_max_requests = 27,\n>>>>> +\t.nr_max_vchans = 38,\n>>>>> +\t.dmac_variant = DMAC_VARIANT_H3,\n>>>>> };\n>>>>> \n>>>>> static const struct of_device_id sun6i_dma_match[] = {\n>>>>> @@ -1075,6 +1081,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>>>>\n>>>> I was wondering if should use the opportunity to expose those values as\n>>>> DT properties instead of hard-wiring them to a compatible string in the\n>>>> driver every time we add support for a new SoC?\n>>>> We could introduce a new compatible string (say: \"allwinner,sunxi-dma\"),\n>>>> then describe properties for the number of channels and requests and\n>>>> vchans and parse those from the DT at probe time.\n>>>> With this we might be able to support future SoCs without Linux *driver*\n>>>> changes, by just providing the right DT. This would have worked already\n>>>> for instance for the A83T support, which just changed those values.\n>>>>\n>>>> For instance with this quick patch below (just compile tested, and without\n>>>> your refactoring).\n>>>> The DT node would then read something like:\n>>>> \tdma: dma-controller@01c02000 {\n>>>> \t\tcompatible = \"allwinner,sun50i-a64-dma\",\n>>>> \t\t\t \"allwinner,sunxi-dma\";\n>>>> \t\treg = <0x01c02000 0x1000>;\n>>>> \t\tinterrupts = ;\n>>>> \t\tclocks = <&ccu CLK_BUS_DMA>;\n>>>> \t\tresets = <&ccu RST_BUS_DMA>;\n>>>> \t\t#dma-cells = <1>;\n>>>> \t\tallwinner,max_channels = <8>;\n>>>> \t\tallwinner,max_requests = <27>;\n>>>> \t\tallwinner,max_vchans = <38>;\n>>>> \t};\n>>>\n>>> We're still going to need a different compatible anyway, so it's not\n>>> really like it would change anything.\n>>\n>> Well, not for now, but possibly in the future. And we should start with\n>> this at one point. If we would have had this type of binding already for\n>> H3, we could have added the A64 support without driver changes just by a\n>> DT change.\n> \n> That's not true. As usual with these kinds of generic binding\n> arguments (it's definitely not personal, you're far from the only one\n> making them), it completely ignores the fact that the IP itself might\n> change from one revision to another, and its behaviour might too.\n\nNot arguing that, and I totally see that those cases indeed require a\nnew compatible string.\n\n> The A64 for example moved at least one register off, and has a\n> different set of burst size / width.\n\nBut that is only compared to the original A23/A31 model? AFAICT compared\nto the H3 DMA it's really only the number of supported DMA channels that\nhas changed. For which we don't even need to invent a property name.\nMy point was that as the driver is *at the moment* all those different\ncompatible strings behaved the same (apart from the missing A23 clock\ngating), see commits f008db8c00c1 and 3a03ea763a67. The differences we\ncoded in struct sun6i_dma_config were more or less artificial.\nNow thanks to Stefan we learned that the H3 is more different than we\nthought, so this argument doesn't hold anymore (but see below).\n\n> It's something you can't account for when you initially define the\n> binding, unless you describe all the registers, plus all their\n> parameters and the way you interact with them, which isn't going to\n> happen if you want to keep your sanity.\n\nI agree on that.\n\n> And obviously, while maintaining the stability of the binding of those\n> hundreds properties.\n> \n> Or, you can base all this on the compatible, and be done with it once\n> and for all.\n\nWhat I am after is to cover SoCs which *don't* have differences in their\nregister layout, for instance A83T, H3, A64, R40.\nIn an ideal world we could have reused the H3 compatible string,\nadjusting the number of channels for each SoC in the DT.\n\nSo I see that having a generic compatible name will not fly, as we now\nhave differences which should not be modelled by DT properties.\nBut I still think we should try to cover those non-register differences\n(number of channels) with a DT property, to allow reusing the existing\ndriver code whenever possible. As is stands with this series, the R40\nsupport should just be a matter of:\n\tcompatible = \"allwinner,sun8i-r40-dma\",\n\t\t \"allwinner,sun50i-a64-dma\";\n\nI am aware that future SoCs might require new compatibles (I actually\nhope that they introduce 64-bit memory addresses at some point), but\nhaving the \"dma-channels\" DT parsing code in should then reduce the\nfrequency of driver changes (for SoCs just copying existing DMA IP).\n\nCheers,\nAndre.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"QxsolagN\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xm2n20lS5z9s82\n\tfor ;\n\tMon, 4 Sep 2017 18:19:02 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1domaw-00033y-V2; Mon, 04 Sep 2017 08:18:58 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1domat-0002z1-8y for linux-arm-kernel@lists.infradead.org;\n\tMon, 04 Sep 2017 08:18:56 +0000","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 294F380D;\n\tMon, 4 Sep 2017 01:18: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\t2AA733F483; Mon, 4 Sep 2017 01:18:31 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=fwmpTMiSMtk65J+SwP/+sr76o0uWZ8g28ehMTmEXZ6Y=;\n\tb=QxsolagNN3SaYz\n\tfK3eRSvKsbpWfX+fB8fqYT66v4q2P+Hd8L0BqNCiDy8iFq4DMfHD5LpaE8V1htJCIO5t/ozIL4Bit\n\tlccnJ4hc4UL5X6p4gq2BhF2/PYTL1mHxvXskHuB/mQzuSRJI7kWN/8eVHqN1mmcp2/WJsiKXtLIFY\n\tjy+bUBR18JFPGOKpYencj7/jHcNunFAZcUcg70Y4kbG+egz41kNMegNK3aIXNBQW/1oHCZ/Z738zi\n\taVlMrx6lIgeRIyisc2YW74osRUGVQO8Cj4B9amfetTjWHsRhjUTS7gzJW1aVr49CocpV0hI31lqo2\n\t6axxQRbWtvs0H75Okjdw==;","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","To":"Maxime Ripard ","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<20170901003135.10058-1-andre.przywara@arm.com>\n\t<20170901060445.vboici7qxfkztp3s@flea>\n\t<743ae23a-372a-762b-c345-b914f09fd718@arm.com>\n\t<20170904070415.e6nclz5n23bo7f4v@flea>","From":"=?utf-8?q?Andr=C3=A9_Przywara?= ","Organization":"ARM Ltd.","Message-ID":"","Date":"Mon, 4 Sep 2017 09:14:52 +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":"<20170904070415.e6nclz5n23bo7f4v@flea>","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170904_011855_339408_71D60598 ","X-CRM114-Status":"GOOD ( 27.14 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul , Chen-Yu\n\tTsai , linux-kernel@vger.kernel.org, \n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org, =?utf-8?q?Stefan_Br=C3=BCns?=\n\t, linux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"windows-1252\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1765424,"web_url":"http://patchwork.ozlabs.org/comment/1765424/","msgid":"<20170908143913.6ga64ssakvk2mjis@flea.lan>","list_archive_url":null,"date":"2017-09-08T14:39:13","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"Hi,\n\nOn Mon, Sep 04, 2017 at 09:14:52AM +0100, André Przywara wrote:\n> > And obviously, while maintaining the stability of the binding of those\n> > hundreds properties.\n> > \n> > Or, you can base all this on the compatible, and be done with it once\n> > and for all.\n> \n> What I am after is to cover SoCs which *don't* have differences in their\n> register layout, for instance A83T, H3, A64, R40.\n> In an ideal world we could have reused the H3 compatible string,\n> adjusting the number of channels for each SoC in the DT.\n> \n> So I see that having a generic compatible name will not fly, as we now\n> have differences which should not be modelled by DT properties.\n> But I still think we should try to cover those non-register differences\n> (number of channels) with a DT property, to allow reusing the existing\n> driver code whenever possible. As is stands with this series, the R40\n> support should just be a matter of:\n> \tcompatible = \"allwinner,sun8i-r40-dma\",\n> \t\t \"allwinner,sun50i-a64-dma\";\n\nI just suggested the exact same thing, and then saw your mail, so I\nguess we have an agreement :)\n\nMaxime","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"CRd9XCoF\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpg2b03QPz9sBd\n\tfor ;\n\tSat, 9 Sep 2017 00:39:51 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqKRg-00013X-1n; Fri, 08 Sep 2017 14:39:48 +0000","from mail.free-electrons.com ([62.4.15.54])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqKRa-0000z6-0r for linux-arm-kernel@lists.infradead.org;\n\tFri, 08 Sep 2017 14:39:45 +0000","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 01DB620A58; Fri, 8 Sep 2017 16:39:13 +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 D07E32092C;\n\tFri, 8 Sep 2017 16:39:12 +0200 (CEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc:\n\tList-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:\n\tIn-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;\n\tbh=wm+qs/JehyeXGeo0+mMKz7kzeu0YrwKprFMeljAaYJs=;\n\tb=CRd9XCoFZJwJxCZI0VSOqYDxx\n\tEuoC0jtUF3yxofhH1bo+0zh02Si6dATJ+jsFW0c829YNAcrwOloEfGeGKpWdwuctJyMfYvZ2GJ3rG\n\tz3PfjimXgX22KCtZuxl+RBShx1hyw4GCvMdZXEtzcVt0x0WvTLwpRXSn0LUiMlRiYxHNCNaWj6etC\n\tfDk9L320XETRch5z4x2LB9EJ8zPZdoehIYeiAjWLFtW0ayJ7rNwQpl12BRYIsQWPjJCOP59k9LAP9\n\taKOQjMK0iqLwlKr9PnO5NhkpwZ+OqMwaB2wAK6il15sHPrL13HDPKyKCw9TO7VA6cpOzYUXfEpc4/\n\tbN7z4kCIg==;","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":"Fri, 8 Sep 2017 16:39:13 +0200","From":"Maxime Ripard ","To":"=?iso-8859-1?q?Andr=E9?= Przywara ","Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","Message-ID":"<20170908143913.6ga64ssakvk2mjis@flea.lan>","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<20170901003135.10058-1-andre.przywara@arm.com>\n\t<20170901060445.vboici7qxfkztp3s@flea>\n\t<743ae23a-372a-762b-c345-b914f09fd718@arm.com>\n\t<20170904070415.e6nclz5n23bo7f4v@flea>\n\t","MIME-Version":"1.0","In-Reply-To":"","User-Agent":"NeoMutt/20170714 (1.8.3)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170908_073943_674430_1BB61CDD ","X-CRM114-Status":"GOOD ( 17.28 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul , Chen-Yu\n\tTsai , linux-kernel@vger.kernel.org, \n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org, Stefan =?iso-8859-1?q?Br=FCns?=\n\t, linux-arm-kernel@lists.infradead.org","Content-Type":"multipart/mixed;\n\tboundary=\"===============5484233701364633444==\"","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1765436,"web_url":"http://patchwork.ozlabs.org/comment/1765436/","msgid":"<4c4ea0f7-3df3-7ab4-100d-c8545211d582@arm.com>","list_archive_url":null,"date":"2017-09-08T14:57:03","subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","submitter":{"id":61837,"url":"http://patchwork.ozlabs.org/api/people/61837/","name":"Andre Przywara","email":"andre.przywara@arm.com"},"content":"Hi Maxime,\n\nOn 08/09/17 15:39, Maxime Ripard wrote:\n> Hi,\n> \n> On Mon, Sep 04, 2017 at 09:14:52AM +0100, André Przywara wrote:\n>>> And obviously, while maintaining the stability of the binding of those\n>>> hundreds properties.\n>>>\n>>> Or, you can base all this on the compatible, and be done with it once\n>>> and for all.\n>>\n>> What I am after is to cover SoCs which *don't* have differences in their\n>> register layout, for instance A83T, H3, A64, R40.\n>> In an ideal world we could have reused the H3 compatible string,\n>> adjusting the number of channels for each SoC in the DT.\n>>\n>> So I see that having a generic compatible name will not fly, as we now\n>> have differences which should not be modelled by DT properties.\n>> But I still think we should try to cover those non-register differences\n>> (number of channels) with a DT property, to allow reusing the existing\n>> driver code whenever possible. As is stands with this series, the R40\n>> support should just be a matter of:\n>> \tcompatible = \"allwinner,sun8i-r40-dma\",\n>> \t\t \"allwinner,sun50i-a64-dma\";\n> \n> I just suggested the exact same thing, and then saw your mail, so I\n> guess we have an agreement :)\n\nYes, I was thinking so as well.\nSince my DeLorean is in the garage ;-) we have no other choice than\ndoing so.\nMy original suggestion for a generic name was based on my naive reading\nof the existing code, which *looked like* it would be all compatible.\nBut as we know better now, this is the way to go.\n\nMerci,\nAndré","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"GVHlxFpN\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=infradead.org header.i=@infradead.org\n\theader.b=\"pQu/Vjmm\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpgRQ0Wrgz9s81\n\tfor ;\n\tSat, 9 Sep 2017 00:57:54 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqKj5-0004lJ-Tr; Fri, 08 Sep 2017 14:57:47 +0000","from merlin.infradead.org ([2001:8b0:10b:1231::1])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqKim-0004Wo-Hl for linux-arm-kernel@bombadil.infradead.org;\n\tFri, 08 Sep 2017 14:57:28 +0000","from foss.arm.com ([217.140.101.70])\n\tby merlin.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqKij-00048b-J1 for linux-arm-kernel@lists.infradead.org;\n\tFri, 08 Sep 2017 14:57:26 +0000","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 B266780D;\n\tFri, 8 Sep 2017 07:57:02 -0700 (PDT)","from [192.168.67.35] (usa-sjc-imap-foss1.foss.arm.com\n\t[10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t0C2AA3F3E1; Fri, 8 Sep 2017 07:57:00 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=Z2/+ll8cXjqOkYsub/ceaCbl7Bdu2VDEKzFLdygPDsI=;\n\tb=GVHlxFpNH74qhL\n\tKnUVCiMdWQPSPTMVxRbMG9c1rvVLYIWbZZxdH6n1+i5+/FnUNAtNViaPNgyxZKq4Qlwkw+tWr2OTh\n\tOKAOiV/u+kVA0qCGiv/0/q8AO2Tqe0ybOOPMC4wHaSqtCQr2MV+W0KfyzTYHcHy/cRKbi+cmPu45F\n\tR6UPS1qGSsw4TyXtLZIHpDxGcLcA9NkwgQ03GVHOWOWnvfA+S5FqTHN0cbusz5q1Iwoh7VEqB58BU\n\tC4d4aBS65DsHOAx2ODlUwXLKPgAs7ERZXlijiyAdpXSqzQQ5raimFto4U0gcekT1yv4K1KvKML2IP\n\tzBoRw+vfZ8bx9/O82Yew==;","v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=merlin.20170209;\n\th=Content-Transfer-Encoding:Content-Type:\n\tIn-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender\n\t:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:\n\tResent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:\n\tList-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;\n\tbh=gN1yCjoTduayvpW6/4RH9BxVkZkMY3HybqlEhKtp+gg=;\n\tb=pQu/VjmmIKEYqMajhc88GKBWph\n\tY6Y5P6Ls/NladbafDukbvgx4dZ+KekWm6giq+gbofBE1WwYpQuWVgvGcfLW1bU+hhdEZY7fwqVlcE\n\tFy+GMp6Gpjq/ocdcynzRQGXlfsl8kVd0AnWnlxV3FMD+1Lmk4wD0w5e8Fyvr5dAhbGwZsrAoVY1mk\n\tFXzAs9LKE3DBk3xTFwA/AKljSaN+z2bDElSY2Glyo1dNmPQujp3YTJkxQiOhjZY4xxHx3Jv/L+t8N\n\t54C8H1Oa1xSjJVAIdI7ICdiuY0KhgdG4cdHJNi4xRNzyYLF1u6qEUfmuMY2Hf7YbrYfoxEdqTfgrs\n\tR8OI6Jig==;"],"Subject":"Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64","To":"Maxime Ripard ","References":"<20170830233609.13855-4-stefan.bruens@rwth-aachen.de>\n\t<20170901003135.10058-1-andre.przywara@arm.com>\n\t<20170901060445.vboici7qxfkztp3s@flea>\n\t<743ae23a-372a-762b-c345-b914f09fd718@arm.com>\n\t<20170904070415.e6nclz5n23bo7f4v@flea>\n\t\n\t<20170908143913.6ga64ssakvk2mjis@flea.lan>","From":"Andre Przywara ","Message-ID":"<4c4ea0f7-3df3-7ab4-100d-c8545211d582@arm.com>","Date":"Fri, 8 Sep 2017 15:57:03 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170908143913.6ga64ssakvk2mjis@flea.lan>","Content-Language":"en-GB","X-Spam-Note":"CRM114 invocation failed","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on merlin.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"devicetree@vger.kernel.org, Vinod Koul , Chen-Yu\n\tTsai , linux-kernel@vger.kernel.org, \n\tlinux-sunxi@googlegroups.com, Rob Herring ,\n\tdmaengine@vger.kernel.org, =?utf-8?q?Stefan_Br=C3=BCns?=\n\t, linux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"windows-1252\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}}]