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: [02/15] ARM: pxa: add dma slave map From: Robert Jarzmik Message-Id: <87tvss48ti.fsf@belgarion.home> Date: Tue, 03 Apr 2018 17:18:49 +0200 To: Arnd Bergmann Cc: Daniel Mack , Haojian Zhuang , Bartlomiej Zolnierkiewicz , Tejun Heo , Vinod Koul , Mauro Carvalho Chehab , Ulf Hansson , Ezequiel Garcia , Boris Brezillon , David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Cyrille Pitchen , Nicolas Pitre , Samuel Ortiz , Greg Kroah-Hartman , Jaroslav Kysela , Takashi Iwai , Liam Girdwood , Mark Brown , Russell King , Linux ARM , Linux Kernel Mailing List , IDE-ML , dmaengine@vger.kernel.org, Linux Media Mailing List , linux-mmc , linux-mtd , Networking , devel@driverdev.osuosl.org, alsa-devel@alsa-project.org List-ID: QXJuZCBCZXJnbWFubiA8YXJuZEBhcm5kYi5kZT4gd3JpdGVzOgoKPj4gKyAgICAgICB7ICJzbWM5 MTF4LjAiLCAicngiLCBQRE1BX0ZJTFRFUl9QQVJBTShMT1dFU1QsIC0xKSB9LAo+PiArICAgICAg IHsgInNtYzkxMXguMCIsICJ0eCIsIFBETUFfRklMVEVSX1BBUkFNKExPV0VTVCwgLTEpIH0sCj4+ ICsgICAgICAgeyAic21jOTF4LjAiLCAiZGF0YSIsIFBETUFfRklMVEVSX1BBUkFNKExPV0VTVCwg LTEpIH0sCj4KPiBUaGlzIG9uZSBpcyBpbnRlcmVzdGluZywgYXMgeW91IGFyZSBkZWFsaW5nIHdp dGggYW4gb2ZmLWNoaXAgZGV2aWNlLAo+IGFuZCB0aGUgY2hhbm5lbCBudW1iZXIgaXMgJy0nMS4g SG93IGRvZXMgdGhpcyBldmVuIHdvcms/IERvZXMgaXQKPiBtZWFuCgpUaGlzIHJlbGllcyBvbiBw eGFfZG1hLCBpbiB3aGljaCB0aGUgIi0xIiBmb3IgYSByZXF1ZXN0b3IgbGluZSBtZWFucyAibm8K cmVxdWVzdG9yIiBvciBzYWlkIGluIGFub3RoZXIgd2F5ICJhbHdheXMgcmVxdWVzdGluZyIuIEFz IGEgY29uc2VxdWVuY2UsIGFzIHNvb24KYXMgdGhlIERNQSBkZXNjcmlwdG9ycyBhcmUgcXVldWVk LCB0aGUgdHJhbnNmZXIgYmVnaW5zLCBhbmQgaXQgaXMgc3VwcG9zZWQKaW1wbGljaXRlbHkgdGhh dCB0aGUgRklGTyBvdXRwdXQgYXZhaWxhYmlsaXR5IGlzIGF0IGxlYXN0IGFzIHF1aWNrIGFzIHRo ZSBzeXN0ZW0KYnVzIGFuZCB0aGUgRE1BIHNpemUgaXMgcGVyZmVjdGx5IGZpdCBmb3IgdGhlIEZJ Rk8gYXZhaWxhYmxlIGJ5dGVzLgoKVGhpcyBpcyB3aGF0IGhhcyBiZWVuIHRoZSB1bmRlcmx5aW5n IG9mIERNQSB0cmFuc2ZlcnMgb2Ygc21jOTF4KHgpIG9uIHRoZSBQWEEKcGxhdGZvcm1zLCB3aGVy ZSB0aGUgc21jOTF4KHMpIGFyZSBkaXJlY3RseSB3aXJlZCBvbiB0aGUgc3lzdGVtIGJ1cyAodGhl IHNhbWUKYnVzIGhhdmluZyBEUkFNLCBTUkFNLCBJTy1tYXBwZWQgZGV2aWNlcykuCgo+Cj4+ICsg ICAgICAgLyogUFhBMjV4IHNwZWNpZmljIG1hcCAqLwo+PiArICAgICAgIHsgInB4YTI1eC1zc3Au MCIsICJyeCIsIFBETUFfRklMVEVSX1BBUkFNKExPV0VTVCwgMTMpIH0sCj4+ICsgICAgICAgeyAi cHhhMjV4LXNzcC4wIiwgInR4IiwgUERNQV9GSUxURVJfUEFSQU0oTE9XRVNULCAxNCkgfSwKPj4g KyAgICAgICB7ICJweGEyNXgtbnNzcC4xIiwgInJ4IiwgUERNQV9GSUxURVJfUEFSQU0oTE9XRVNU LCAxNSkgfSwKPj4gKyAgICAgICB7ICJweGEyNXgtbnNzcC4xIiwgInR4IiwgUERNQV9GSUxURVJf UEFSQU0oTE9XRVNULCAxNikgfSwKPj4gKyAgICAgICB7ICJweGEyNXgtbnNzcC4yIiwgInJ4Iiwg UERNQV9GSUxURVJfUEFSQU0oTE9XRVNULCAyMykgfSwKPj4gKyAgICAgICB7ICJweGEyNXgtbnNz cC4yIiwgInR4IiwgUERNQV9GSUxURVJfUEFSQU0oTE9XRVNULCAyNCkgfSwKPj4gKyAgICAgICB7 ICJweGEtcGNtLWF1ZGlvIiwgIm5zc3AyX3J4IiwgUERNQV9GSUxURVJfUEFSQU0oTE9XRVNULCAx NSkgfSwKPj4gKyAgICAgICB7ICJweGEtcGNtLWF1ZGlvIiwgIm5zc3AyX3R4IiwgUERNQV9GSUxU RVJfUEFSQU0oTE9XRVNULCAxNikgfSwKPj4gKyAgICAgICB7ICJweGEtcGNtLWF1ZGlvIiwgIm5z c3AzX3J4IiwgUERNQV9GSUxURVJfUEFSQU0oTE9XRVNULCAyMykgfSwKPj4gKyAgICAgICB7ICJw eGEtcGNtLWF1ZGlvIiwgIm5zc3AzX3R4IiwgUERNQV9GSUxURVJfUEFSQU0oTE9XRVNULCAyNCkg fSwKPj4gKwo+PiArICAgICAgIC8qIFBYQTI3eCBzcGVjaWZpYyBtYXAgKi8KPj4gKyAgICAgICB7 ICJweGEtcGNtLWF1ZGlvIiwgInNzcDNfcngiLCBQRE1BX0ZJTFRFUl9QQVJBTShMT1dFU1QsIDY2 KSB9LAo+PiArICAgICAgIHsgInB4YS1wY20tYXVkaW8iLCAic3NwM190eCIsIFBETUFfRklMVEVS X1BBUkFNKExPV0VTVCwgNjcpIH0sCj4+ICsgICAgICAgeyAicHhhMjd4LWNhbWVyYS4wIiwgIkNJ X1kiLCBQRE1BX0ZJTFRFUl9QQVJBTShISUdIRVNULCA2OCkgfSwKPj4gKyAgICAgICB7ICJweGEy N3gtY2FtZXJhLjAiLCAiQ0lfVSIsIFBETUFfRklMVEVSX1BBUkFNKEhJR0hFU1QsIDY5KSB9LAo+ PiArICAgICAgIHsgInB4YTI3eC1jYW1lcmEuMCIsICJDSV9WIiwgUERNQV9GSUxURVJfUEFSQU0o SElHSEVTVCwgNzApIH0sCj4+ICsKPj4gKyAgICAgICAvKiBQWEEzeHggc3BlY2lmaWMgbWFwICov Cj4+ICsgICAgICAgeyAicHhhLXBjbS1hdWRpbyIsICJzc3A0X3J4IiwgUERNQV9GSUxURVJfUEFS QU0oTE9XRVNULCAyKSB9LAo+PiArICAgICAgIHsgInB4YS1wY20tYXVkaW8iLCAic3NwNF90eCIs IFBETUFfRklMVEVSX1BBUkFNKExPV0VTVCwgMykgfSwKPj4gKyAgICAgICB7ICJweGEyeHgtbWNp LjEiLCAicngiLCBQRE1BX0ZJTFRFUl9QQVJBTShMT1dFU1QsIDkzKSB9LAo+PiArICAgICAgIHsg InB4YTJ4eC1tY2kuMSIsICJ0eCIsIFBETUFfRklMVEVSX1BBUkFNKExPV0VTVCwgOTQpIH0sCj4+ ICsgICAgICAgeyAicHhhM3h4LW5hbmQiLCAiZGF0YSIsIFBETUFfRklMVEVSX1BBUkFNKExPV0VT VCwgOTcpIH0sCj4+ICsgICAgICAgeyAicHhhMnh4LW1jaS4yIiwgInJ4IiwgUERNQV9GSUxURVJf UEFSQU0oTE9XRVNULCAxMDApIH0sCj4+ICsgICAgICAgeyAicHhhMnh4LW1jaS4yIiwgInR4Iiwg UERNQV9GSUxURVJfUEFSQU0oTE9XRVNULCAxMDEpIH0sCj4+ICt9Owo+Cj4gU2luY2UgbW9yZSB0 aGFuIGhhbGYgdGhlIGVudHJpZXMgaW4gaGVyZSBhcmUgY2hpcCBzcGVjaWZpYywgbWF5YmUgaXQg d291bGQgYmUKPiBiZXR0ZXIgdG8gc3BsaXQgdGhhdCB0YWJsZSBpbnRvIHRocmVlIGFuZCBoYXZl IGEgY29weSBmb3IgZWFjaCBvbmUgaW4KPiBhcmNoL2FybS9tYWNoLXB4YS9weGF7MjV4LjI3eC4z eHh9LmM/Ck1tbWgsIHRvZGF5IHRoZSBzcGxpdCBpcyA6CiAtIDE2IGNvbW1vbiBlbnRyaWVzCiAt IDEwIHB4YTI1eCBzcGVjaWZpYyBlbnRyaWVzCiAtIDUgcHhhMjd4IHNwZWNpZmljIGVudHJpZXMK IC0gNyBweGEzeHggc3BlY2lmaWMgZW50cmllcwogPT4gdG90YWwgb2YgMzggbGluZXMKCkFmdGVy IHRoZSBzcGxpdCB3ZSdsbCBoYXZlIDoKIC0gMjYgcHhhMjV4IHNwZWNpZmljIGVudHJpZXMKIC0g MjEgcHhhMjd4IHNwZWNpZmljIGVudHJpZXMKIC0gMjMgcHhhM3h4IHNwZWNpZmljIGVudHJpZXMK ID0+IHRvdGFsIG9mIDcwIGxpbmVzCgpUaGF0IGRvdWJsZXMgdGhlIG51bWJlciBvZiBsaW5lcywg bm90IGNvdW50aW5nIHRoZSBkZWNsYXJhdGlvbnMsIGFuZCBhbWVuZGluZyBvZgpweGEyeHhfc2V0 X2RtYWNfaW5mbygpLgoKSWYgeW91IHRoaW5rIGl0J3Mgd29ydGggaXQsIHdoYXQgaXMgdGhlIGRy aXZpbmcgYmVuZWZpdCBiZWhpbmQgPwoKPiBEb2VzIHRoYXQgbWVhbiBpdCdzIGFjdHVhbGx5IGEg bWVtb3J5LXRvLW1lbW9yeSB0cmFuc2ZlciB3aXRoIGEgZGV2aWNlIGJlaW5nCj4gb24gdGhlIGV4 dGVybmFsIFNSQU0gaW50ZXJmYWNlPwpJJ20gdGFraW5nIHRoaXMgaXMgdGhlIGZvbGxvdyB1cCB0 byB0aGUgIi0xIiBxdWVzdGlvbiA6MAoKQ2hlZXJzLgo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Jarzmik Subject: Re: [PATCH 02/15] ARM: pxa: add dma slave map Date: Tue, 03 Apr 2018 17:18:49 +0200 Message-ID: <87tvss48ti.fsf@belgarion.home> References: <20180402142656.26815-1-robert.jarzmik@free.fr> <20180402142656.26815-3-robert.jarzmik@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: (Arnd Bergmann's message of "Tue, 3 Apr 2018 08:51:37 +0200") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Arnd Bergmann Cc: Ulf Hansson , alsa-devel@alsa-project.org, Jaroslav Kysela , IDE-ML , Networking , linux-mtd , devel@driverdev.osuosl.org, Boris Brezillon , Vinod Koul , Richard Weinberger , Takashi Iwai , Russell King , Linux Kernel Mailing List <"linux-kerne l"@vger.kernel.org>, Marek Vasut , Ezequiel Garcia , Linux Media Mailing List , Samuel Ortiz , Bartlomiej Zolnierkiewicz , Haojian Zhuang , dmaengine@vger.kernel.org, Mark Brown , Mauro Carvalho Chehab List-Id: linux-ide@vger.kernel.org Arnd Bergmann writes: >> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) }, > > This one is interesting, as you are dealing with an off-chip device, > and the channel number is '-'1. How does this even work? Does it > mean This relies on pxa_dma, in which the "-1" for a requestor line means "no requestor" or said in another way "always requesting". As a consequence, as soon as the DMA descriptors are queued, the transfer begins, and it is supposed implicitely that the FIFO output availability is at least as quick as the system bus and the DMA size is perfectly fit for the FIFO available bytes. This is what has been the underlying of DMA transfers of smc91x(x) on the PXA platforms, where the smc91x(s) are directly wired on the system bus (the same bus having DRAM, SRAM, IO-mapped devices). > >> + /* PXA25x specific map */ >> + { "pxa25x-ssp.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) }, >> + { "pxa25x-ssp.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) }, >> + { "pxa25x-nssp.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >> + { "pxa25x-nssp.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >> + { "pxa25x-nssp.2", "rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >> + { "pxa25x-nssp.2", "tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >> + { "pxa-pcm-audio", "nssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >> + { "pxa-pcm-audio", "nssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >> + { "pxa-pcm-audio", "nssp3_rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >> + { "pxa-pcm-audio", "nssp3_tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >> + >> + /* PXA27x specific map */ >> + { "pxa-pcm-audio", "ssp3_rx", PDMA_FILTER_PARAM(LOWEST, 66) }, >> + { "pxa-pcm-audio", "ssp3_tx", PDMA_FILTER_PARAM(LOWEST, 67) }, >> + { "pxa27x-camera.0", "CI_Y", PDMA_FILTER_PARAM(HIGHEST, 68) }, >> + { "pxa27x-camera.0", "CI_U", PDMA_FILTER_PARAM(HIGHEST, 69) }, >> + { "pxa27x-camera.0", "CI_V", PDMA_FILTER_PARAM(HIGHEST, 70) }, >> + >> + /* PXA3xx specific map */ >> + { "pxa-pcm-audio", "ssp4_rx", PDMA_FILTER_PARAM(LOWEST, 2) }, >> + { "pxa-pcm-audio", "ssp4_tx", PDMA_FILTER_PARAM(LOWEST, 3) }, >> + { "pxa2xx-mci.1", "rx", PDMA_FILTER_PARAM(LOWEST, 93) }, >> + { "pxa2xx-mci.1", "tx", PDMA_FILTER_PARAM(LOWEST, 94) }, >> + { "pxa3xx-nand", "data", PDMA_FILTER_PARAM(LOWEST, 97) }, >> + { "pxa2xx-mci.2", "rx", PDMA_FILTER_PARAM(LOWEST, 100) }, >> + { "pxa2xx-mci.2", "tx", PDMA_FILTER_PARAM(LOWEST, 101) }, >> +}; > > Since more than half the entries in here are chip specific, maybe it would be > better to split that table into three and have a copy for each one in > arch/arm/mach-pxa/pxa{25x.27x.3xx}.c? Mmmh, today the split is : - 16 common entries - 10 pxa25x specific entries - 5 pxa27x specific entries - 7 pxa3xx specific entries => total of 38 lines After the split we'll have : - 26 pxa25x specific entries - 21 pxa27x specific entries - 23 pxa3xx specific entries => total of 70 lines That doubles the number of lines, not counting the declarations, and amending of pxa2xx_set_dmac_info(). If you think it's worth it, what is the driving benefit behind ? > Does that mean it's actually a memory-to-memory transfer with a device being > on the external SRAM interface? I'm taking this is the follow up to the "-1" question :0 Cheers. -- Robert From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752068AbeDCPTK (ORCPT ); Tue, 3 Apr 2018 11:19:10 -0400 Received: from smtp03.smtpout.orange.fr ([80.12.242.125]:40044 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751457AbeDCPTG (ORCPT ); Tue, 3 Apr 2018 11:19:06 -0400 X-ME-Helo: belgarion X-ME-Auth: amFyem1pay5yb2JlcnRAb3JhbmdlLmZy X-ME-Date: Tue, 03 Apr 2018 17:19:04 +0200 X-ME-IP: 86.201.130.131 From: Robert Jarzmik To: Arnd Bergmann Cc: Daniel Mack , Haojian Zhuang , Bartlomiej Zolnierkiewicz , Tejun Heo , Vinod Koul , Mauro Carvalho Chehab , Ulf Hansson , Ezequiel Garcia , Boris Brezillon , David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Cyrille Pitchen , Nicolas Pitre , Samuel Ortiz , Greg Kroah-Hartman , Jaroslav Kysela , Takashi Iwai , Liam Girdwood , Mark Brown , Russell King , Linux ARM , Linux Kernel Mailing List , IDE-ML , dmaengine@vger.kernel.org, Linux Media Mailing List , linux-mmc , linux-mtd , Networking , devel@driverdev.osuosl.org, alsa-devel@alsa-project.org Subject: Re: [PATCH 02/15] ARM: pxa: add dma slave map References: <20180402142656.26815-1-robert.jarzmik@free.fr> <20180402142656.26815-3-robert.jarzmik@free.fr> X-URL: http://belgarath.falguerolles.org/ Date: Tue, 03 Apr 2018 17:18:49 +0200 In-Reply-To: (Arnd Bergmann's message of "Tue, 3 Apr 2018 08:51:37 +0200") Message-ID: <87tvss48ti.fsf@belgarion.home> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Arnd Bergmann writes: >> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) }, > > This one is interesting, as you are dealing with an off-chip device, > and the channel number is '-'1. How does this even work? Does it > mean This relies on pxa_dma, in which the "-1" for a requestor line means "no requestor" or said in another way "always requesting". As a consequence, as soon as the DMA descriptors are queued, the transfer begins, and it is supposed implicitely that the FIFO output availability is at least as quick as the system bus and the DMA size is perfectly fit for the FIFO available bytes. This is what has been the underlying of DMA transfers of smc91x(x) on the PXA platforms, where the smc91x(s) are directly wired on the system bus (the same bus having DRAM, SRAM, IO-mapped devices). > >> + /* PXA25x specific map */ >> + { "pxa25x-ssp.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) }, >> + { "pxa25x-ssp.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) }, >> + { "pxa25x-nssp.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >> + { "pxa25x-nssp.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >> + { "pxa25x-nssp.2", "rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >> + { "pxa25x-nssp.2", "tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >> + { "pxa-pcm-audio", "nssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >> + { "pxa-pcm-audio", "nssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >> + { "pxa-pcm-audio", "nssp3_rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >> + { "pxa-pcm-audio", "nssp3_tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >> + >> + /* PXA27x specific map */ >> + { "pxa-pcm-audio", "ssp3_rx", PDMA_FILTER_PARAM(LOWEST, 66) }, >> + { "pxa-pcm-audio", "ssp3_tx", PDMA_FILTER_PARAM(LOWEST, 67) }, >> + { "pxa27x-camera.0", "CI_Y", PDMA_FILTER_PARAM(HIGHEST, 68) }, >> + { "pxa27x-camera.0", "CI_U", PDMA_FILTER_PARAM(HIGHEST, 69) }, >> + { "pxa27x-camera.0", "CI_V", PDMA_FILTER_PARAM(HIGHEST, 70) }, >> + >> + /* PXA3xx specific map */ >> + { "pxa-pcm-audio", "ssp4_rx", PDMA_FILTER_PARAM(LOWEST, 2) }, >> + { "pxa-pcm-audio", "ssp4_tx", PDMA_FILTER_PARAM(LOWEST, 3) }, >> + { "pxa2xx-mci.1", "rx", PDMA_FILTER_PARAM(LOWEST, 93) }, >> + { "pxa2xx-mci.1", "tx", PDMA_FILTER_PARAM(LOWEST, 94) }, >> + { "pxa3xx-nand", "data", PDMA_FILTER_PARAM(LOWEST, 97) }, >> + { "pxa2xx-mci.2", "rx", PDMA_FILTER_PARAM(LOWEST, 100) }, >> + { "pxa2xx-mci.2", "tx", PDMA_FILTER_PARAM(LOWEST, 101) }, >> +}; > > Since more than half the entries in here are chip specific, maybe it would be > better to split that table into three and have a copy for each one in > arch/arm/mach-pxa/pxa{25x.27x.3xx}.c? Mmmh, today the split is : - 16 common entries - 10 pxa25x specific entries - 5 pxa27x specific entries - 7 pxa3xx specific entries => total of 38 lines After the split we'll have : - 26 pxa25x specific entries - 21 pxa27x specific entries - 23 pxa3xx specific entries => total of 70 lines That doubles the number of lines, not counting the declarations, and amending of pxa2xx_set_dmac_info(). If you think it's worth it, what is the driving benefit behind ? > Does that mean it's actually a memory-to-memory transfer with a device being > on the external SRAM interface? I'm taking this is the follow up to the "-1" question :0 Cheers. -- Robert From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Jarzmik Subject: Re: [PATCH 02/15] ARM: pxa: add dma slave map Date: Tue, 03 Apr 2018 17:18:49 +0200 Message-ID: <87tvss48ti.fsf@belgarion.home> References: <20180402142656.26815-1-robert.jarzmik@free.fr> <20180402142656.26815-3-robert.jarzmik@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Ulf Hansson , alsa-devel@alsa-project.org, Jaroslav Kysela , IDE-ML , Networking , linux-mtd , devel@driverdev.osuosl.org, Boris Brezillon , Vinod Koul , Richard Weinberger , Takashi Iwai , Russell King , Linux Kernel Mailing List <"linux-kerne l"@vger.kernel.org>, Marek Vasut , Ezequiel Garcia , Linux Media Mailing List , Samuel Ortiz , Bartlomiej Zolnierkiewicz , Haojian Zhuang , dmaengine@vger.kernel.org, Mark Brown , Mauro Carvalho Chehab , To: Arnd Bergmann Return-path: In-Reply-To: (Arnd Bergmann's message of "Tue, 3 Apr 2018 08:51:37 +0200") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" List-Id: netdev.vger.kernel.org Arnd Bergmann writes: >> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) }, > > This one is interesting, as you are dealing with an off-chip device, > and the channel number is '-'1. How does this even work? Does it > mean This relies on pxa_dma, in which the "-1" for a requestor line means "no requestor" or said in another way "always requesting". As a consequence, as soon as the DMA descriptors are queued, the transfer begins, and it is supposed implicitely that the FIFO output availability is at least as quick as the system bus and the DMA size is perfectly fit for the FIFO available bytes. This is what has been the underlying of DMA transfers of smc91x(x) on the PXA platforms, where the smc91x(s) are directly wired on the system bus (the same bus having DRAM, SRAM, IO-mapped devices). > >> + /* PXA25x specific map */ >> + { "pxa25x-ssp.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) }, >> + { "pxa25x-ssp.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) }, >> + { "pxa25x-nssp.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >> + { "pxa25x-nssp.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >> + { "pxa25x-nssp.2", "rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >> + { "pxa25x-nssp.2", "tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >> + { "pxa-pcm-audio", "nssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >> + { "pxa-pcm-audio", "nssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >> + { "pxa-pcm-audio", "nssp3_rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >> + { "pxa-pcm-audio", "nssp3_tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >> + >> + /* PXA27x specific map */ >> + { "pxa-pcm-audio", "ssp3_rx", PDMA_FILTER_PARAM(LOWEST, 66) }, >> + { "pxa-pcm-audio", "ssp3_tx", PDMA_FILTER_PARAM(LOWEST, 67) }, >> + { "pxa27x-camera.0", "CI_Y", PDMA_FILTER_PARAM(HIGHEST, 68) }, >> + { "pxa27x-camera.0", "CI_U", PDMA_FILTER_PARAM(HIGHEST, 69) }, >> + { "pxa27x-camera.0", "CI_V", PDMA_FILTER_PARAM(HIGHEST, 70) }, >> + >> + /* PXA3xx specific map */ >> + { "pxa-pcm-audio", "ssp4_rx", PDMA_FILTER_PARAM(LOWEST, 2) }, >> + { "pxa-pcm-audio", "ssp4_tx", PDMA_FILTER_PARAM(LOWEST, 3) }, >> + { "pxa2xx-mci.1", "rx", PDMA_FILTER_PARAM(LOWEST, 93) }, >> + { "pxa2xx-mci.1", "tx", PDMA_FILTER_PARAM(LOWEST, 94) }, >> + { "pxa3xx-nand", "data", PDMA_FILTER_PARAM(LOWEST, 97) }, >> + { "pxa2xx-mci.2", "rx", PDMA_FILTER_PARAM(LOWEST, 100) }, >> + { "pxa2xx-mci.2", "tx", PDMA_FILTER_PARAM(LOWEST, 101) }, >> +}; > > Since more than half the entries in here are chip specific, maybe it would be > better to split that table into three and have a copy for each one in > arch/arm/mach-pxa/pxa{25x.27x.3xx}.c? Mmmh, today the split is : - 16 common entries - 10 pxa25x specific entries - 5 pxa27x specific entries - 7 pxa3xx specific entries => total of 38 lines After the split we'll have : - 26 pxa25x specific entries - 21 pxa27x specific entries - 23 pxa3xx specific entries => total of 70 lines That doubles the number of lines, not counting the declarations, and amending of pxa2xx_set_dmac_info(). If you think it's worth it, what is the driving benefit behind ? > Does that mean it's actually a memory-to-memory transfer with a device being > on the external SRAM interface? I'm taking this is the follow up to the "-1" question :0 Cheers. -- Robert From mboxrd@z Thu Jan 1 00:00:00 1970 From: robert.jarzmik@free.fr (Robert Jarzmik) Date: Tue, 03 Apr 2018 17:18:49 +0200 Subject: [PATCH 02/15] ARM: pxa: add dma slave map In-Reply-To: (Arnd Bergmann's message of "Tue, 3 Apr 2018 08:51:37 +0200") References: <20180402142656.26815-1-robert.jarzmik@free.fr> <20180402142656.26815-3-robert.jarzmik@free.fr> Message-ID: <87tvss48ti.fsf@belgarion.home> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Arnd Bergmann writes: >> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) }, > > This one is interesting, as you are dealing with an off-chip device, > and the channel number is '-'1. How does this even work? Does it > mean This relies on pxa_dma, in which the "-1" for a requestor line means "no requestor" or said in another way "always requesting". As a consequence, as soon as the DMA descriptors are queued, the transfer begins, and it is supposed implicitely that the FIFO output availability is at least as quick as the system bus and the DMA size is perfectly fit for the FIFO available bytes. This is what has been the underlying of DMA transfers of smc91x(x) on the PXA platforms, where the smc91x(s) are directly wired on the system bus (the same bus having DRAM, SRAM, IO-mapped devices). > >> + /* PXA25x specific map */ >> + { "pxa25x-ssp.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) }, >> + { "pxa25x-ssp.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) }, >> + { "pxa25x-nssp.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >> + { "pxa25x-nssp.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >> + { "pxa25x-nssp.2", "rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >> + { "pxa25x-nssp.2", "tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >> + { "pxa-pcm-audio", "nssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >> + { "pxa-pcm-audio", "nssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >> + { "pxa-pcm-audio", "nssp3_rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >> + { "pxa-pcm-audio", "nssp3_tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >> + >> + /* PXA27x specific map */ >> + { "pxa-pcm-audio", "ssp3_rx", PDMA_FILTER_PARAM(LOWEST, 66) }, >> + { "pxa-pcm-audio", "ssp3_tx", PDMA_FILTER_PARAM(LOWEST, 67) }, >> + { "pxa27x-camera.0", "CI_Y", PDMA_FILTER_PARAM(HIGHEST, 68) }, >> + { "pxa27x-camera.0", "CI_U", PDMA_FILTER_PARAM(HIGHEST, 69) }, >> + { "pxa27x-camera.0", "CI_V", PDMA_FILTER_PARAM(HIGHEST, 70) }, >> + >> + /* PXA3xx specific map */ >> + { "pxa-pcm-audio", "ssp4_rx", PDMA_FILTER_PARAM(LOWEST, 2) }, >> + { "pxa-pcm-audio", "ssp4_tx", PDMA_FILTER_PARAM(LOWEST, 3) }, >> + { "pxa2xx-mci.1", "rx", PDMA_FILTER_PARAM(LOWEST, 93) }, >> + { "pxa2xx-mci.1", "tx", PDMA_FILTER_PARAM(LOWEST, 94) }, >> + { "pxa3xx-nand", "data", PDMA_FILTER_PARAM(LOWEST, 97) }, >> + { "pxa2xx-mci.2", "rx", PDMA_FILTER_PARAM(LOWEST, 100) }, >> + { "pxa2xx-mci.2", "tx", PDMA_FILTER_PARAM(LOWEST, 101) }, >> +}; > > Since more than half the entries in here are chip specific, maybe it would be > better to split that table into three and have a copy for each one in > arch/arm/mach-pxa/pxa{25x.27x.3xx}.c? Mmmh, today the split is : - 16 common entries - 10 pxa25x specific entries - 5 pxa27x specific entries - 7 pxa3xx specific entries => total of 38 lines After the split we'll have : - 26 pxa25x specific entries - 21 pxa27x specific entries - 23 pxa3xx specific entries => total of 70 lines That doubles the number of lines, not counting the declarations, and amending of pxa2xx_set_dmac_info(). If you think it's worth it, what is the driving benefit behind ? > Does that mean it's actually a memory-to-memory transfer with a device being > on the external SRAM interface? I'm taking this is the follow up to the "-1" question :0 Cheers. -- Robert