From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752082AbcFURsc (ORCPT ); Tue, 21 Jun 2016 13:48:32 -0400 Received: from mail-sn1nam02on0083.outbound.protection.outlook.com ([104.47.36.83]:51905 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751704AbcFURs3 convert rfc822-to-8bit (ORCPT ); Tue, 21 Jun 2016 13:48:29 -0400 X-Greylist: delayed 4175 seconds by postgrey-1.27 at vger.kernel.org; Tue, 21 Jun 2016 13:46:53 EDT Authentication-Results: spf=pass (sender IP is 149.199.60.100) smtp.mailfrom=xilinx.com; vger.kernel.org; dkim=none (message not signed) header.d=none;vger.kernel.org; dmarc=bestguesspass action=none header.from=xilinx.com; From: Punnaiah Choudary Kalluri To: Vinod Koul CC: Appana Durga Kedareswara Rao , "robh+dt@kernel.org" , "pawel.moll@arm.com" , "mark.rutland@arm.com" , "ijc+devicetree@hellion.org.uk" , "galak@codeaurora.org" , Michal Simek , Soren Brinkmann , "dan.j.williams@intel.com" , "moritz.fischer@ettus.com" , "laurent.pinchart@ideasonboard.com" , "luis@debethencourt.com" , Srikanth Vemula , Anirudha Sarangi , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "dmaengine@vger.kernel.org" Subject: RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support Thread-Topic: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support Thread-Index: AQHRu9aa/Mk2DOm0lEW3HgxwAAJbb5/dGQ2AgAGbUwCAB7y9AIABu6uAgAIhXACAAPL0AIAIZ8CAgACHp9D//4iDAIAAiFbQ Date: Tue, 21 Jun 2016 17:29:42 +0000 Message-ID: <03CA77BA8AF6F1469AEDFBDA1322A7B74A18BB82@XAP-PVEXMBX02.xlnx.xilinx.com> References: <1464765839-29018-1-git-send-email-appanad@xilinx.com> <1464765839-29018-2-git-send-email-appanad@xilinx.com> <20160607070841.GJ16910@localhost> <20160613055012.GC16910@localhost> <20160615165004.GC16910@localhost> <20160621154103.GA16910@localhost> <03CA77BA8AF6F1469AEDFBDA1322A7B74A18BAE8@XAP-PVEXMBX02.xlnx.xilinx.com> <20160621163854.GF16910@localhost> In-Reply-To: <20160621163854.GF16910@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.230.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-RCIS-Action: ALLOW X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.0.0.1202-22404.005 X-TM-AS-User-Approved-Sender: Yes;Yes X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:149.199.60.100;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(189002)(199003)(24454002)(93886004)(586003)(356003)(189998001)(23726003)(110136002)(55846006)(4326007)(11100500001)(46406003)(86362001)(2906002)(81156014)(8936002)(92566002)(6116002)(19580395003)(7696003)(1720100001)(47776003)(3846002)(8676002)(2900100001)(106116001)(15975445007)(102836003)(106466001)(7846002)(81166006)(2920100001)(5890100001)(551934003)(2950100001)(76176999)(97756001)(5250100002)(87936001)(33656002)(5003600100003)(63266004)(6806005)(8746002)(54356999)(7736002)(50986999)(50466002)(107986001)(5001870100001);DIR:OUT;SFP:1101;SCL:1;SRVR:BL2NAM02HT009;H:xsj-pvapsmtpgw02;FPR:;SPF:Pass;PTR:xapps1.xilinx.com,unknown-60-100.xilinx.com;MX:1;A:1;CAT:NONE;LANG:en;CAT:NONE; X-MS-Office365-Filtering-Correlation-Id: 10f9c640-8931-451d-e9a5-08d399f9a673 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(8251501002);SRVR:BL2NAM02HT009; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192813158149592)(189271028609987); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(13018025)(13023025)(13017025)(8121501046)(13015025)(13024025)(5005006)(3002001)(10201501046)(6055026);SRVR:BL2NAM02HT009;BCL:0;PCL:0;RULEID:;SRVR:BL2NAM02HT009; X-Forefront-PRVS: 098076C36C X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2016 17:29:50.5392 (UTC) X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.60.100];Helo=[xsj-pvapsmtpgw02] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT009 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Tue, Jun 21, 2016 at 04:19:38PM +0000, Punnaiah Choudary Kalluri wrote: > > > > > > > > mode Earlier In the driver this configuration is read from the > > > > > > > > device-tree But as per lars and your suggestion moved it as > runtime > > > config > > > > > parameters. > > > > > > > > > > > > > > If sg mode is available why would anyone _not_ want it? > > > > > > > > > > > > > > I do not think there is point to have this > > > > > > > > > > > > You mean always keep the device in SG mode and provide an > option > > > For > > > > > > simple dma mode if user want to use simple DMA mode?? > > > > > > > > > > Yes, why would anyone want to use single if sg is available? > > > > > > If you have sg mode always enabled, but sg_list is size 1, that its > > > essentially a single > > > > > > > True. As we said, simple mode ha few additional features like write only > > And read only dma. So, if user want then here is the provision. > > > > > Btw SPI is a slave case, not a memcpy! > > > > > > > Correct. We are working on slave dma support and will patch to this driver. > > And in slave cases, you can use slave config to pass the values which are > required, so we dont need this custome interface! > Ok agree with you for the scenario that I have mentioned above. Other simple dma mode feature that I missed to explain is configuring the Dma descriptors. It provides a register interface for configuring the dma transaction. So, no need to maintain the descriptors in memory and it will be useful for the system that are in crunch of memory. How do you want us to handle this case? > > > > > > > > > > > > > > > > > > > > > > src_issue: > > > > > > > > Tells outstanding transaction on SRC. > > > > > > > > > > > > > > This should be read only then, right? > > > > > > > > > > > > It is a Read/Write register > > > > > > http://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq- > > > ultrascal > > > > > > e-registers.html By default it is configured for Max transactions. > > > > > > If user want to limit it they can limit it using this config option. > > > > > > > > > > And why would they want that? > > > > > > > > Could be that there are certain IPs that my not support burst operations > or > > > > May not support all burst lengths it will be helpful. > > > > Since IP is providing the feature, we are exploring it to the user. > > > > > > > > > > > > > > > > > Burst_len: > > > > > > > > Configures the burst length of the src and dst transfers... > > > > > > > > > > > > > > Hmmm, but you are on memcpy, so that should be programmed > for > > > > > throughput? > > > > > > > > > > > > Yes... > > > > > > > > > > So max burst lengths then, why would anyone configure lesser? > > > > > > > > Depends on the destination and source IPs. > > > > > > Not for memory copy > > > > > > > Depends on the system and how source and destination IPs are > interconnected. > > Sometimes there is a limitation from interconnection also. > > Also some flash controllers providing linear access to NAND or NOR > memories may > > Have limitation in burst length but still user can use memory copy with > desired burst > > Length. > > Some of those cases are treated as slave for obvious reasons. > > Please check existing solutions before inventing new ones. Everyone thinks > that their hardware and thereby driver is a novel case, but on closer > inspection that is usually not the case, different falvour yes, novel no! > > Okay I am convince now this is not right approach. Please remove this > custom interface and then implement slave for required slave scenarios! > Assume controller is having 8 channels and four of them are used for slave Dma and others are for memcpy. Controller didn't have the per channel priority control but providing the rate control Mechanism. So, I need some interface for configuring the rate control per channel at run time irrespective Of whether the channel is allocated for slave dma or memcpy dma. Is it wrong having the configurable dma parameters for dma memcpy operation? We are exposing the Hw capabilities to the user for better dma transaction management. > > > > > > This email and any attachments are intended for the sole use of the named > recipient(s) and contain(s) confidential information that may be proprietary, > privileged or copyrighted under applicable law. If you are not the intended > recipient, do not read, copy, or forward this email message or any > attachments. Delete this email message and any attachments immediately. > > Really! > My apologies :) Thanks, Punnaiah > > -- > ~Vinod