From: Roger Quadros <rogerq@ti.com> To: Ladislav Michl <ladis@linux-mips.org>, Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Tony Lindgren <tony@atomide.com>, Boris Brezillon <boris.brezillon@free-electrons.com>, Kyungmin Park <kyungmin.park@samsung.com>, linux-omap@vger.kernel.org, linux-mtd@lists.infradead.org Subject: Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation Date: Tue, 14 Nov 2017 17:05:20 +0200 [thread overview] Message-ID: <89008152-92e4-7e4a-0953-310a5240d50c@ti.com> (raw) In-Reply-To: <20171113152717.fj2vgga4gzfr3q2b@lenoch> On 13/11/17 17:27, Ladislav Michl wrote: > On Mon, Nov 13, 2017 at 04:36:41PM +0200, Peter Ujfalusi wrote: >> >> >> On 2017-11-13 14:15, Ladislav Michl wrote: >>> On Mon, Nov 13, 2017 at 10:22:12AM +0200, Peter Ujfalusi wrote: >>>> >>>> On 2017-11-10 17:24, Tony Lindgren wrote: >>>>> FYI, the gpio pin for onenand should not be in gpio mode. It should >>>>> be used as external dma request line to automatically trigger new >>>>> transfers like we do for tusb6010 dma. But of course it's possible >>>>> that onenand has other issues too preventing the dma usage. >>>> >>>> My conversion to DMAengine is drop in replacement of the existing >>>> implementation: memcpy w/o hardware synchronization event. >>>> >>>> But I think it should be possible to use HW sync (slave DMA) with the >>>> src/dst_port_window in a similar way we do with the tusb6010. >>> >>> How do you want to synchronize it from OneNAND side? >> >> _if_ the pin used as GPIO interrupt has ext DMA request mode then we can >> switch it, in the DT bindings we give the extDMA request as sync event >> and convert the driver: remove GPIO irq handling and have slave DMA >> setup with port_window to do kind of memcpy with HW synchronization. > > Well, the pin used as GPIO interrupt has this purpose, according to specs: > "The OneNAND INT pin is an output pin function used to notify the Host when > a command has been completed. This provides a hardware method of signaling > the completion of a program, erase, or load operation". > > See for example section 3.9 (and later) of specs: > https://www.abcelectronique.com/composants/telechargement_datasheet.php?id=1089396&part-number=KFH2G16Q2A-DEBx Also see section 7.1 Methods of Determining Interrupt Status. Based on that INT pin is analogous to NAND Read/Busy pin and has nothing to do with DMA. > >> It might be possible... It was possible with tusb6010, but that one was >> already using hw sync with the legacy omap-dma API. > > Based on above, it seems there's long and hard way :) > >>>> But that can be done in a followup series, but what to do in case of old >>>> DT where the dmas/dma-names properties are no there? >>> >>> These will not work anyway as they do not have compatible property. >>> Also note, that DMA is currently not used, yet nobody complained. >> >> ;) >> >>>> Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine. >>>> >>>> Having said that, there might have been a reason why the original >>>> implementation was not using DMA request to trigger the memcpy... The >>>> legacy omap-dma API would have allowed that as you kind of open code >>>> things with much flexibility. >>> >>> That's mainly problem of OneNAND driver itself, not oma-dma. But do we >>> really want to invest more time to this obsolete technology? >>> >>> Of course, I would love to see my 10+ years old boards running faster, >>> but it seems unrealistic to me to get enough manpower to finish this task. >> >> Valid point. I would - for now - only do the DMAengine memcpy conversion >> with the GPIO irq and investigate the slave DMA support after that. > > Here it would be nice to have the same documentation Nokia had at the time > writing support for n8x0 as they clearly used few undocumented features. > Please see section 3.9.5 of above mentioned specs. Seems DMA slave should > be triggered by RDY not INT pin. Correct. For RDY pin usage See 3.7.3 Handshaking Operation "The handshaking feature allows the host system to simply monitor the RDY signal from the device to determine when the initial word of burst data is ready to be read." > > Best regards, > ladis > -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Roger Quadros <rogerq@ti.com> To: Ladislav Michl <ladis@linux-mips.org>, Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Tony Lindgren <tony@atomide.com>, <linux-mtd@lists.infradead.org>, <linux-omap@vger.kernel.org>, Boris Brezillon <boris.brezillon@free-electrons.com>, Kyungmin Park <kyungmin.park@samsung.com> Subject: Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation Date: Tue, 14 Nov 2017 17:05:20 +0200 [thread overview] Message-ID: <89008152-92e4-7e4a-0953-310a5240d50c@ti.com> (raw) In-Reply-To: <20171113152717.fj2vgga4gzfr3q2b@lenoch> On 13/11/17 17:27, Ladislav Michl wrote: > On Mon, Nov 13, 2017 at 04:36:41PM +0200, Peter Ujfalusi wrote: >> >> >> On 2017-11-13 14:15, Ladislav Michl wrote: >>> On Mon, Nov 13, 2017 at 10:22:12AM +0200, Peter Ujfalusi wrote: >>>> >>>> On 2017-11-10 17:24, Tony Lindgren wrote: >>>>> FYI, the gpio pin for onenand should not be in gpio mode. It should >>>>> be used as external dma request line to automatically trigger new >>>>> transfers like we do for tusb6010 dma. But of course it's possible >>>>> that onenand has other issues too preventing the dma usage. >>>> >>>> My conversion to DMAengine is drop in replacement of the existing >>>> implementation: memcpy w/o hardware synchronization event. >>>> >>>> But I think it should be possible to use HW sync (slave DMA) with the >>>> src/dst_port_window in a similar way we do with the tusb6010. >>> >>> How do you want to synchronize it from OneNAND side? >> >> _if_ the pin used as GPIO interrupt has ext DMA request mode then we can >> switch it, in the DT bindings we give the extDMA request as sync event >> and convert the driver: remove GPIO irq handling and have slave DMA >> setup with port_window to do kind of memcpy with HW synchronization. > > Well, the pin used as GPIO interrupt has this purpose, according to specs: > "The OneNAND INT pin is an output pin function used to notify the Host when > a command has been completed. This provides a hardware method of signaling > the completion of a program, erase, or load operation". > > See for example section 3.9 (and later) of specs: > https://www.abcelectronique.com/composants/telechargement_datasheet.php?id=1089396&part-number=KFH2G16Q2A-DEBx Also see section 7.1 Methods of Determining Interrupt Status. Based on that INT pin is analogous to NAND Read/Busy pin and has nothing to do with DMA. > >> It might be possible... It was possible with tusb6010, but that one was >> already using hw sync with the legacy omap-dma API. > > Based on above, it seems there's long and hard way :) > >>>> But that can be done in a followup series, but what to do in case of old >>>> DT where the dmas/dma-names properties are no there? >>> >>> These will not work anyway as they do not have compatible property. >>> Also note, that DMA is currently not used, yet nobody complained. >> >> ;) >> >>>> Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine. >>>> >>>> Having said that, there might have been a reason why the original >>>> implementation was not using DMA request to trigger the memcpy... The >>>> legacy omap-dma API would have allowed that as you kind of open code >>>> things with much flexibility. >>> >>> That's mainly problem of OneNAND driver itself, not oma-dma. But do we >>> really want to invest more time to this obsolete technology? >>> >>> Of course, I would love to see my 10+ years old boards running faster, >>> but it seems unrealistic to me to get enough manpower to finish this task. >> >> Valid point. I would - for now - only do the DMAengine memcpy conversion >> with the GPIO irq and investigate the slave DMA support after that. > > Here it would be nice to have the same documentation Nokia had at the time > writing support for n8x0 as they clearly used few undocumented features. > Please see section 3.9.5 of above mentioned specs. Seems DMA slave should > be triggered by RDY not INT pin. Correct. For RDY pin usage See 3.7.3 Handshaking Operation "The handshaking feature allows the host system to simply monitor the RDY signal from the device to determine when the initial word of burst data is ready to be read." > > Best regards, > ladis > -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
next prev parent reply other threads:[~2017-11-14 15:05 UTC|newest] Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-09 9:11 [PATCH v3 0/7] OMAP2+ OneNAND driver update Ladislav Michl 2017-11-09 9:11 ` Ladislav Michl 2017-11-09 9:12 ` [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support Ladislav Michl 2017-11-09 9:12 ` Ladislav Michl 2017-11-09 17:56 ` Tony Lindgren 2017-11-09 17:56 ` Tony Lindgren 2017-11-09 18:10 ` Ladislav Michl 2017-11-09 18:10 ` Ladislav Michl 2017-11-09 18:26 ` Tony Lindgren 2017-11-09 18:26 ` Tony Lindgren 2017-11-09 18:34 ` Ladislav Michl 2017-11-09 18:34 ` Ladislav Michl 2017-11-09 18:48 ` Tony Lindgren 2017-11-09 18:48 ` Tony Lindgren 2017-11-09 19:10 ` Ladislav Michl 2017-11-09 19:10 ` Ladislav Michl 2017-11-09 21:59 ` Tony Lindgren 2017-11-09 21:59 ` Tony Lindgren 2017-11-09 22:26 ` Ladislav Michl 2017-11-09 22:26 ` Ladislav Michl 2017-11-10 8:12 ` Roger Quadros 2017-11-10 8:12 ` Roger Quadros 2017-11-09 9:13 ` [PATCH v3 2/7] mtd: onenand: omap2: Remove regulator support Ladislav Michl 2017-11-09 9:13 ` Ladislav Michl 2017-11-10 8:17 ` Roger Quadros 2017-11-10 8:17 ` Roger Quadros 2017-11-09 9:14 ` [PATCH v3 3/7] mtd: onenand: omap2: Remove skip initial unlocking support Ladislav Michl 2017-11-09 9:14 ` Ladislav Michl 2017-11-10 8:18 ` Roger Quadros 2017-11-10 8:18 ` Roger Quadros 2017-11-09 9:14 ` [PATCH v3 4/7] mtd: onenand: omap2: Remove partitioning support from platform data Ladislav Michl 2017-11-09 9:14 ` Ladislav Michl 2017-11-10 8:19 ` Roger Quadros 2017-11-10 8:19 ` Roger Quadros 2017-11-10 9:48 ` Ladislav Michl 2017-11-10 9:48 ` Ladislav Michl 2017-11-09 9:15 ` [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation Ladislav Michl 2017-11-09 9:15 ` Ladislav Michl 2017-11-10 8:21 ` Roger Quadros 2017-11-10 8:21 ` Roger Quadros 2017-11-10 9:51 ` Ladislav Michl 2017-11-10 9:51 ` Ladislav Michl 2017-11-10 15:26 ` Tony Lindgren 2017-11-10 15:26 ` Tony Lindgren 2017-11-10 18:19 ` Ladislav Michl 2017-11-10 18:19 ` Ladislav Michl 2017-11-10 18:29 ` Tony Lindgren 2017-11-10 18:29 ` Tony Lindgren 2017-11-11 12:50 ` Ladislav Michl 2017-11-11 12:50 ` Ladislav Michl 2017-11-13 20:10 ` Peter Ujfalusi 2017-11-13 20:10 ` Peter Ujfalusi 2017-11-14 14:47 ` Roger Quadros 2017-11-14 14:47 ` Roger Quadros 2017-11-14 15:03 ` Ladislav Michl 2017-11-14 15:03 ` Ladislav Michl 2017-11-10 8:25 ` Peter Ujfalusi 2017-11-10 8:25 ` Peter Ujfalusi 2017-11-10 10:04 ` Ladislav Michl 2017-11-10 10:04 ` Ladislav Michl 2017-11-10 15:24 ` Tony Lindgren 2017-11-10 15:24 ` Tony Lindgren 2017-11-10 18:26 ` Ladislav Michl 2017-11-10 18:26 ` Ladislav Michl 2017-11-10 18:48 ` Tony Lindgren 2017-11-10 18:48 ` Tony Lindgren 2017-11-10 21:39 ` Ladislav Michl 2017-11-10 21:39 ` Ladislav Michl 2017-11-14 21:53 ` Tony Lindgren 2017-11-14 21:53 ` Tony Lindgren 2017-11-14 22:32 ` Ladislav Michl 2017-11-14 22:32 ` Ladislav Michl 2017-11-15 2:11 ` Tony Lindgren 2017-11-15 2:11 ` Tony Lindgren 2017-11-13 8:22 ` Peter Ujfalusi 2017-11-13 8:22 ` Peter Ujfalusi 2017-11-13 12:15 ` Ladislav Michl 2017-11-13 12:15 ` Ladislav Michl 2017-11-13 14:36 ` Peter Ujfalusi 2017-11-13 14:36 ` Peter Ujfalusi 2017-11-13 15:23 ` Tony Lindgren 2017-11-13 15:23 ` Tony Lindgren 2017-11-13 15:27 ` Ladislav Michl 2017-11-13 15:27 ` Ladislav Michl 2017-11-14 15:05 ` Roger Quadros [this message] 2017-11-14 15:05 ` Roger Quadros 2017-11-14 15:22 ` Ladislav Michl 2017-11-14 15:22 ` Ladislav Michl 2017-11-09 9:16 ` [PATCH v3 6/7] mtd: onenand: omap2: Do not make delay for GPIO OMAP3 specific Ladislav Michl 2017-11-09 9:16 ` Ladislav Michl 2017-11-09 9:17 ` [PATCH v3 7/7] mtd: onenand: omap2: Configure driver from DT Ladislav Michl 2017-11-09 9:17 ` Ladislav Michl
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=89008152-92e4-7e4a-0953-310a5240d50c@ti.com \ --to=rogerq@ti.com \ --cc=boris.brezillon@free-electrons.com \ --cc=kyungmin.park@samsung.com \ --cc=ladis@linux-mips.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=peter.ujfalusi@ti.com \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.