From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [v5,2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC From: Vinod Koul Message-Id: <20180301125649.GH15443@localhost> Date: Thu, 1 Mar 2018 18:26:49 +0530 To: Sean Wang Cc: dan.j.williams@intel.com, robh+dt@kernel.org, mark.rutland@arm.com, dmaengine@vger.kernel.org, devicetree@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Randy Dunlap , Fengguang Wu , Julia Lawall List-ID: T24gVGh1LCBNYXIgMDEsIDIwMTggYXQgMDY6Mjc6MDFQTSArMDgwMCwgU2VhbiBXYW5nIHdyb3Rl Ogo+IE9uIFRodSwgMjAxOC0wMy0wMSBhdCAxMzo1MyArMDUzMCwgVmlub2QgS291bCB3cm90ZToK PiA+IE9uIFN1biwgRmViIDE4LCAyMDE4IGF0IDAzOjA4OjMwQU0gKzA4MDAsIHNlYW4ud2FuZ0Bt ZWRpYXRlay5jb20gd3JvdGU6Cj4gPiAKPiA+ID4gQEAgLTAsMCArMSwxMDU0IEBACj4gPiA+ICsv LyBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMAo+ID4gLy8gQ29weXJpZ2h0IC4uLgo+ ID4gCj4gPiBUaGUgY29weXJpZ2h0IGxpbmUgbmVlZHMgdG8gZm9sbG93IFNQRFggdGFnIGxpbmUK PiA+IAo+IAo+IG9rYXksIEkgd2lsbCBtYWtlIGl0IHJlb3JkZXIgYW5kIGJlIHNvbWV0aGluZyBs aWtlIHRoYXQKPiAKPiAvLyBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMAo+IC8qCj4g ICogQ29weXJpZ2h0IChjKSAyMDE3LTIwMTggTWVkaWFUZWsgSW5jLgo+ICAqIEF1dGhvcjogU2Vh biBXYW5nIDxzZWFuLndhbmdAbWVkaWF0ZWsuY29tPgo+ICAqCj4gICogRHJpdmVyIGZvciBNZWRp YVRlayBIaWdoLVNwZWVkIERNQSBDb250cm9sbGVyCj4gICoKPiAgKi8KCkl0IG5lZWRzIHRvIGJl OgoKLy8gU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAKLy8gQ29weXJpZ2h0IChjKSAy MDE3LTIwMTggTWVkaWFUZWsgSW5jLgoKLyoKICogd2hhdGV2ZXIgZWxzZSB5b3Ugd2FudAogKi8K ClRoZSBmaXJzdCB0d28gbGluZXMgYXJlIGluIEM5OSBzdHlsZSBjb21tZW50IGFuZCBuZWVkIHRv IGhhdmUgU1BEWCB0YWcgYW5kCkNvcHlyaWdodCBpbmZvCgo+IHRoZSBwb2ludCBpcyBJIGxlYXJu ZWQgZnJvbSBvdGhlciBzdWJzeXN0ZW0gbWFrZXMgdGhlIGRyaXZlciBuYW1lIGJlCj4gc2FtZSB3 aXRoIHRoZSBtb2R1bGUgbmFtZSB3aXRoIEtCVUlMRF9NT0ROQU1FLgo+IAo+IElmIHlvdSByZWFs bHkgZG9uJ3QgbGlrZSBpdCwgSSBjYW4ganVzdCBjaGFuZ2UgaXQgaW50byAKPiAKPiAjZGVmaW5l IE1US19ETUFfREVWICJtdGstaHNkbWEiCgpJdCBpcyB1c2VkIG9ubHkgb25jZSwgd2h5IG5vdCB1 c2UgS0JVSUxEX01PRE5BTUUgZGlyZWN0bHk/Cgo+IAo+ID4gPiArCj4gPiA+ICsjZGVmaW5lIE1U S19IU0RNQV9VU0VDX1BPTEwJCTIwCj4gPiA+ICsjZGVmaW5lIE1US19IU0RNQV9USU1FT1VUX1BP TEwJCTIwMDAwMAo+ID4gPiArI2RlZmluZSBNVEtfSFNETUFfRE1BX0JVU1dJRFRIUwkJQklUKERN QV9TTEFWRV9CVVNXSURUSF9VTkRFRklORUQpCj4gPiAKPiA+IFVuZGVmaW5lZCBidXN3aWR0aD8/ Cgo/PwoKPiA+ID4gKy8qKgo+ID4gPiArICogc3RydWN0IG10a19oc2RtYV9wZGVzYyAtIFRoaXMg aXMgdGhlIHN0cnVjdCBob2xkaW5nIGluZm8gZGVzY3JpYmluZyBwaHlzaWNhbAo+ID4gPiArICoJ CQkgICAgZGVzY3JpcHRvciAoUEQpIGFuZCBpdHMgcGxhY2VtZW50IG11c3QgYmUga2VwdCBhdAo+ ID4gPiArICoJCQkgICAgNC1ieXRlcyBhbGlnbm1lbnQgaW4gbGl0dGxlIGVuZGlhbiBvcmRlci4K PiA+ID4gKyAqIEBkZXNjWzEtNF06CQkgICAgVGhlIGNvbnRyb2wgcGFkIHVzZWQgdG8gaW5kaWNh dGUgaGFyZHdhcmUgaG93IHRvCj4gPiAKPiA+IHBscyBhbGlnbiB0byA4MGNoYXIgb3IgbGVzc2Vy Cj4gPiAKPiAKPiB3ZWlyZCwgaXQgc2VlbXMgdGhlIGxpbmUgaXMgYWxyZWFkeSB3aXRoIDgwIGNo YXIgYW5kIHBhc3MgdGhlCj4gY2hlY2twYXRjaC5wbC4gb3IgZG8gSSBtaXN1bmRlcnN0YW5kIHNv bWV0aGluZyA/CgpPa2F5IHBsZWFzZSBjaGVjay4gV2l0aCB0ZXh0IGl0IGhlbHBzIHRvIHdyYXAg YmVmb3JlIHRoYXQKCj4gPiA+ICsJLyoKPiA+ID4gKwkgKiBVcGRhdGluZyBpbnRvIGhhcmR3YXJl IHRoZSBwb2ludGVyIG9mIFRYIHJpbmcgbGV0cyBIU0RNQSB0byB0YWtlCj4gPiA+ICsJICogYWN0 aW9uIGZvciB0aG9zZSBwZW5kaW5nIFBEcy4KPiA+ID4gKwkgKi8KPiA+ID4gKwltdGtfZG1hX3dy aXRlKGhzZG1hLCBNVEtfSFNETUFfVFhfQ1BVLCByaW5nLT5jdXJfdHB0cik7Cj4gPiA+ICsKPiA+ ID4gKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZoc2RtYS0+bG9jaywgZmxhZ3MpOwo+ID4gPiAr Cj4gPiA+ICsJcmV0dXJuICFodmQtPmxlbiA/IDAgOiAtRU5PU1BDOwo+ID4gCj4gPiB5b3UgYWxy ZWFkeSB3cm90ZSBhbmQgc3RhcnRlZCB0eG4sIHNvIHdoeSB0aGlzPwo+ID4gCj4gCj4gaXQncyBw b3NzaWJsZSBqdXN0IHBhcnRpYWwgdmlydHVhbCBkZXNjcmlwdG9yIGZpdHMgaW50byBoYXJkd2Fy ZSBhbmQKPiB0aGVuIHJldHVybiAtRU5PU1BDLiBBbmQgaXQgd2lsbCBzdGFydCBpdCB0byBjb21w bGV0ZSB0aGUgcmVtYWluaW5nIHBhcnQKPiBhcyBzb29uIGFzIHBvc3NpYmxlIHdoZW4gc29tZSBy b29tcyBpcyBiZWluZyBmcmVlZC4KCkVpdGhlciB3YXlzIHlvdSBoYXZlIGlzc3VlZCB0aGUgZGVz Y3JpcHRvciwgc28geW91IHN1Y2NlZWQgcmlnaHQ/Cgo+ID4gc2hvdWxkbid0IHdlIGNoZWNrIGlm IG5leHQgaXMgaW4gcmFuZ2UsIHdlIGNhbiBjcmFzaCBpZiB3ZSBnZXQgYmFkIHZhbHVlCj4gPiBm cm9tIGhhcmR3YXJlLi4KPiAKPiBva2F5LCB0aGVyZSBhcmUgY2hlY2tzIGZvciBuZXh0IHdpdGgg ZGRvbmUgYml0IGNoZWNrIGFuZCBudWxsIGNoZWNrIGluCj4gdGhlIGNvcnJlc3BvbmRpbmcgZGVz Y3JpcHRvciBhcyB0aGUgZm9sbG93aW5nLgoKd2hhdCBpZiB5b3UgZ2V0IGJhZCBuZXh0IHZhbHVl Cgo+IAo+ID4gPiArCQlyeGQgPSAmcGMtPnJpbmcucnhkW25leHRdOwoKcmVzdWx0aW5nIGluIGJh ZCByZWYgaGVyZQo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Koul Subject: Re: [PATCH v5 2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC Date: Thu, 1 Mar 2018 18:26:49 +0530 Message-ID: <20180301125649.GH15443@localhost> References: <20180301082329.GD15443@localhost> <1519900021.8089.136.camel@mtkswgap22> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1519900021.8089.136.camel@mtkswgap22> Sender: linux-kernel-owner@vger.kernel.org To: Sean Wang Cc: dan.j.williams@intel.com, robh+dt@kernel.org, mark.rutland@arm.com, dmaengine@vger.kernel.org, devicetree@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Randy Dunlap , Fengguang Wu , Julia Lawall List-Id: linux-mediatek@lists.infradead.org On Thu, Mar 01, 2018 at 06:27:01PM +0800, Sean Wang wrote: > On Thu, 2018-03-01 at 13:53 +0530, Vinod Koul wrote: > > On Sun, Feb 18, 2018 at 03:08:30AM +0800, sean.wang@mediatek.com wrote: > > > > > @@ -0,0 +1,1054 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > // Copyright ... > > > > The copyright line needs to follow SPDX tag line > > > > okay, I will make it reorder and be something like that > > // SPDX-License-Identifier: GPL-2.0 > /* > * Copyright (c) 2017-2018 MediaTek Inc. > * Author: Sean Wang > * > * Driver for MediaTek High-Speed DMA Controller > * > */ It needs to be: // SPDX-License-Identifier: GPL-2.0 // Copyright (c) 2017-2018 MediaTek Inc. /* * whatever else you want */ The first two lines are in C99 style comment and need to have SPDX tag and Copyright info > the point is I learned from other subsystem makes the driver name be > same with the module name with KBUILD_MODNAME. > > If you really don't like it, I can just change it into > > #define MTK_DMA_DEV "mtk-hsdma" It is used only once, why not use KBUILD_MODNAME directly? > > > > + > > > +#define MTK_HSDMA_USEC_POLL 20 > > > +#define MTK_HSDMA_TIMEOUT_POLL 200000 > > > +#define MTK_HSDMA_DMA_BUSWIDTHS BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED) > > > > Undefined buswidth?? ?? > > > +/** > > > + * struct mtk_hsdma_pdesc - This is the struct holding info describing physical > > > + * descriptor (PD) and its placement must be kept at > > > + * 4-bytes alignment in little endian order. > > > + * @desc[1-4]: The control pad used to indicate hardware how to > > > > pls align to 80char or lesser > > > > weird, it seems the line is already with 80 char and pass the > checkpatch.pl. or do I misunderstand something ? Okay please check. With text it helps to wrap before that > > > + /* > > > + * Updating into hardware the pointer of TX ring lets HSDMA to take > > > + * action for those pending PDs. > > > + */ > > > + mtk_dma_write(hsdma, MTK_HSDMA_TX_CPU, ring->cur_tptr); > > > + > > > + spin_unlock_irqrestore(&hsdma->lock, flags); > > > + > > > + return !hvd->len ? 0 : -ENOSPC; > > > > you already wrote and started txn, so why this? > > > > it's possible just partial virtual descriptor fits into hardware and > then return -ENOSPC. And it will start it to complete the remaining part > as soon as possible when some rooms is being freed. Either ways you have issued the descriptor, so you succeed right? > > shouldn't we check if next is in range, we can crash if we get bad value > > from hardware.. > > okay, there are checks for next with ddone bit check and null check in > the corresponding descriptor as the following. what if you get bad next value > > > > + rxd = &pc->ring.rxd[next]; resulting in bad ref here -- ~Vinod From mboxrd@z Thu Jan 1 00:00:00 1970 From: vinod.koul@intel.com (Vinod Koul) Date: Thu, 1 Mar 2018 18:26:49 +0530 Subject: [PATCH v5 2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC In-Reply-To: <1519900021.8089.136.camel@mtkswgap22> References: <20180301082329.GD15443@localhost> <1519900021.8089.136.camel@mtkswgap22> Message-ID: <20180301125649.GH15443@localhost> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Mar 01, 2018 at 06:27:01PM +0800, Sean Wang wrote: > On Thu, 2018-03-01 at 13:53 +0530, Vinod Koul wrote: > > On Sun, Feb 18, 2018 at 03:08:30AM +0800, sean.wang at mediatek.com wrote: > > > > > @@ -0,0 +1,1054 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > // Copyright ... > > > > The copyright line needs to follow SPDX tag line > > > > okay, I will make it reorder and be something like that > > // SPDX-License-Identifier: GPL-2.0 > /* > * Copyright (c) 2017-2018 MediaTek Inc. > * Author: Sean Wang > * > * Driver for MediaTek High-Speed DMA Controller > * > */ It needs to be: // SPDX-License-Identifier: GPL-2.0 // Copyright (c) 2017-2018 MediaTek Inc. /* * whatever else you want */ The first two lines are in C99 style comment and need to have SPDX tag and Copyright info > the point is I learned from other subsystem makes the driver name be > same with the module name with KBUILD_MODNAME. > > If you really don't like it, I can just change it into > > #define MTK_DMA_DEV "mtk-hsdma" It is used only once, why not use KBUILD_MODNAME directly? > > > > + > > > +#define MTK_HSDMA_USEC_POLL 20 > > > +#define MTK_HSDMA_TIMEOUT_POLL 200000 > > > +#define MTK_HSDMA_DMA_BUSWIDTHS BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED) > > > > Undefined buswidth?? ?? > > > +/** > > > + * struct mtk_hsdma_pdesc - This is the struct holding info describing physical > > > + * descriptor (PD) and its placement must be kept at > > > + * 4-bytes alignment in little endian order. > > > + * @desc[1-4]: The control pad used to indicate hardware how to > > > > pls align to 80char or lesser > > > > weird, it seems the line is already with 80 char and pass the > checkpatch.pl. or do I misunderstand something ? Okay please check. With text it helps to wrap before that > > > + /* > > > + * Updating into hardware the pointer of TX ring lets HSDMA to take > > > + * action for those pending PDs. > > > + */ > > > + mtk_dma_write(hsdma, MTK_HSDMA_TX_CPU, ring->cur_tptr); > > > + > > > + spin_unlock_irqrestore(&hsdma->lock, flags); > > > + > > > + return !hvd->len ? 0 : -ENOSPC; > > > > you already wrote and started txn, so why this? > > > > it's possible just partial virtual descriptor fits into hardware and > then return -ENOSPC. And it will start it to complete the remaining part > as soon as possible when some rooms is being freed. Either ways you have issued the descriptor, so you succeed right? > > shouldn't we check if next is in range, we can crash if we get bad value > > from hardware.. > > okay, there are checks for next with ddone bit check and null check in > the corresponding descriptor as the following. what if you get bad next value > > > > + rxd = &pc->ring.rxd[next]; resulting in bad ref here -- ~Vinod