All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
To: Huang Shijie <b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Vinod Koul <vinod.koul-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	djbw-b10kYP2dOMg@public.gmane.org,
	khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org,
	ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org,
	w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
	cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org,
	dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	lrg-l0cyMroinI0@public.gmane.org,
	broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org,
	perex-/Fr2/VpizcU@public.gmane.org,
	tiwai-l3A5Bk7waGM@public.gmane.org,
	shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
	Huang Shijie <shijie8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Fabio Estevam
	<fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
Subject: Re: [PATCH] dma: add new DMA control commands
Date: Thu, 18 Oct 2012 10:16:06 +0200	[thread overview]
Message-ID: <201210181016.06782.marex@denx.de> (raw)
In-Reply-To: <507FB495.7050104-KZfg59tc24xl57MIdRCFDg@public.gmane.org>

Dear Huang Shijie,

> 于 2012年10月18日 15:14, Marek Vasut 写道:
> > Dear Huang Shijie,
> > 
> > Why such massive CC ?
> > 
> >> 于 2012年10月18日 14:18, Vinod Koul 写道:
> >>> Why cant you do start (prepare clock etc) when you submit the
> >>> descriptor to dmaengine. Can be done in tx_submit callback.
> >>> Similarly remove the clock when dma transaction gets completed.
> >> 
> >> I ever thought this method too.
> >> 
> >> But it will become low efficient in the following case:
> >>     Assuming the gpmi-nand driver has to read out 1024 pages in one
> >> 
> >> _SINGLE_ read operation.
> >> The gpmi-nand will submit the descriptor to dmaengine per page.
> > 
> > It will? Then GPMI NAND is flat our broken ... again.
> 
> yes.
> 
> Please read the NAND chip spec about the comand READ PAGE(00h-30h) and
> the code
> nand_do_read_ops(). The nand chip limits us only read one page out one
> time. So the driver will submit the descriptor to dmaengine per page.

So we can't stream data from the chip? About time to adjust the MTD framework to 
allow that. Maybe implement a command queue?

> >> So with
> >> your method,
> >> the system will repeat the enable/disable dma clock 1024 time.
> > 
> > Yes, it is the driver that's wrong.
> 
> not the driver.
> 
> >> At every
> >> enable/disable dma clock,
> >> the system has to enable the clock chain and it's parents ...
> >> 
> >> But with this patch, we only need to enable/disable dma clock one time,
> >> just at we select the nand chip.
> > 
> > You are fixing a driver problem at a framework level, wrong.
> > 
> > So, check how the MXS SPI driver handles descriptor chaining. Indeed, the
> > Sigmatel screwed the DMA stuff good. But if you analyze the SPI driver,
> > you'll notice a few important points that might come handy when you fix
> > the GPMI NAND driver properly.
> > 
> > The direction to take here is:
> > 1) Implement DMA chaining into the GPMI NAND driver
> 
> How can i implement the DMA chain if the nand chip READ-PAGE command
> gives us the one page limit?

This smells like a time to extend the MTD api ?

> thanks
> Huang Shijie
> 
> > 2) You might need to do one PIO transfer to reconfigure the IP registers
> > between each segment of the DMA chain (just as MXS SPI does it)
> > 3) You might run out of DMA descriptors when doing too long chains -- so
> > you might need to fix that part of the mxs DMA driver.

Best regards,
Marek Vasut

WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex@denx.de>
To: Huang Shijie <b32955@freescale.com>
Cc: alsa-devel@alsa-project.org, tiwai@suse.de,
	artem.bityutskiy@linux.intel.com, perex@perex.cz,
	linux-mtd@lists.infradead.org, linux-i2c@vger.kernel.org,
	Huang Shijie <shijie8@gmail.com>,
	linux@arm.linux.org.uk, cjb@laptop.org, lrg@ti.com,
	ben-linux@fluff.org, linux-arm-kernel@lists.infradead.org,
	Fabio Estevam <fabio.estevam@freescale.com>,
	Vinod Koul <vinod.koul@linux.intel.com>,
	broonie@opensource.wolfsonmicro.com, linux-mmc@vger.kernel.org,
	w.sang@pengutronix.de, linux-kernel@vger.kernel.org, djbw@fb.com,
	khali@linux-fr.org, shawn.guo@linaro.org, dwmw2@infradead.org
Subject: Re: [PATCH] dma: add new DMA control commands
Date: Thu, 18 Oct 2012 10:16:06 +0200	[thread overview]
Message-ID: <201210181016.06782.marex@denx.de> (raw)
In-Reply-To: <507FB495.7050104@freescale.com>

Dear Huang Shijie,

> 于 2012年10月18日 15:14, Marek Vasut 写道:
> > Dear Huang Shijie,
> > 
> > Why such massive CC ?
> > 
> >> 于 2012年10月18日 14:18, Vinod Koul 写道:
> >>> Why cant you do start (prepare clock etc) when you submit the
> >>> descriptor to dmaengine. Can be done in tx_submit callback.
> >>> Similarly remove the clock when dma transaction gets completed.
> >> 
> >> I ever thought this method too.
> >> 
> >> But it will become low efficient in the following case:
> >>     Assuming the gpmi-nand driver has to read out 1024 pages in one
> >> 
> >> _SINGLE_ read operation.
> >> The gpmi-nand will submit the descriptor to dmaengine per page.
> > 
> > It will? Then GPMI NAND is flat our broken ... again.
> 
> yes.
> 
> Please read the NAND chip spec about the comand READ PAGE(00h-30h) and
> the code
> nand_do_read_ops(). The nand chip limits us only read one page out one
> time. So the driver will submit the descriptor to dmaengine per page.

So we can't stream data from the chip? About time to adjust the MTD framework to 
allow that. Maybe implement a command queue?

> >> So with
> >> your method,
> >> the system will repeat the enable/disable dma clock 1024 time.
> > 
> > Yes, it is the driver that's wrong.
> 
> not the driver.
> 
> >> At every
> >> enable/disable dma clock,
> >> the system has to enable the clock chain and it's parents ...
> >> 
> >> But with this patch, we only need to enable/disable dma clock one time,
> >> just at we select the nand chip.
> > 
> > You are fixing a driver problem at a framework level, wrong.
> > 
> > So, check how the MXS SPI driver handles descriptor chaining. Indeed, the
> > Sigmatel screwed the DMA stuff good. But if you analyze the SPI driver,
> > you'll notice a few important points that might come handy when you fix
> > the GPMI NAND driver properly.
> > 
> > The direction to take here is:
> > 1) Implement DMA chaining into the GPMI NAND driver
> 
> How can i implement the DMA chain if the nand chip READ-PAGE command
> gives us the one page limit?

This smells like a time to extend the MTD api ?

> thanks
> Huang Shijie
> 
> > 2) You might need to do one PIO transfer to reconfigure the IP registers
> > between each segment of the DMA chain (just as MXS SPI does it)
> > 3) You might run out of DMA descriptors when doing too long chains -- so
> > you might need to fix that part of the mxs DMA driver.

Best regards,
Marek Vasut

WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] dma: add new DMA control commands
Date: Thu, 18 Oct 2012 10:16:06 +0200	[thread overview]
Message-ID: <201210181016.06782.marex@denx.de> (raw)
In-Reply-To: <507FB495.7050104@freescale.com>

Dear Huang Shijie,

> ? 2012?10?18? 15:14, Marek Vasut ??:
> > Dear Huang Shijie,
> > 
> > Why such massive CC ?
> > 
> >> ? 2012?10?18? 14:18, Vinod Koul ??:
> >>> Why cant you do start (prepare clock etc) when you submit the
> >>> descriptor to dmaengine. Can be done in tx_submit callback.
> >>> Similarly remove the clock when dma transaction gets completed.
> >> 
> >> I ever thought this method too.
> >> 
> >> But it will become low efficient in the following case:
> >>     Assuming the gpmi-nand driver has to read out 1024 pages in one
> >> 
> >> _SINGLE_ read operation.
> >> The gpmi-nand will submit the descriptor to dmaengine per page.
> > 
> > It will? Then GPMI NAND is flat our broken ... again.
> 
> yes.
> 
> Please read the NAND chip spec about the comand READ PAGE(00h-30h) and
> the code
> nand_do_read_ops(). The nand chip limits us only read one page out one
> time. So the driver will submit the descriptor to dmaengine per page.

So we can't stream data from the chip? About time to adjust the MTD framework to 
allow that. Maybe implement a command queue?

> >> So with
> >> your method,
> >> the system will repeat the enable/disable dma clock 1024 time.
> > 
> > Yes, it is the driver that's wrong.
> 
> not the driver.
> 
> >> At every
> >> enable/disable dma clock,
> >> the system has to enable the clock chain and it's parents ...
> >> 
> >> But with this patch, we only need to enable/disable dma clock one time,
> >> just at we select the nand chip.
> > 
> > You are fixing a driver problem at a framework level, wrong.
> > 
> > So, check how the MXS SPI driver handles descriptor chaining. Indeed, the
> > Sigmatel screwed the DMA stuff good. But if you analyze the SPI driver,
> > you'll notice a few important points that might come handy when you fix
> > the GPMI NAND driver properly.
> > 
> > The direction to take here is:
> > 1) Implement DMA chaining into the GPMI NAND driver
> 
> How can i implement the DMA chain if the nand chip READ-PAGE command
> gives us the one page limit?

This smells like a time to extend the MTD api ?

> thanks
> Huang Shijie
> 
> > 2) You might need to do one PIO transfer to reconfigure the IP registers
> > between each segment of the DMA chain (just as MXS SPI does it)
> > 3) You might run out of DMA descriptors when doing too long chains -- so
> > you might need to fix that part of the mxs DMA driver.

Best regards,
Marek Vasut

WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex@denx.de>
To: Huang Shijie <b32955@freescale.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>,
	djbw@fb.com, khali@linux-fr.org, ben-linux@fluff.org,
	w.sang@pengutronix.de, cjb@laptop.org, dwmw2@infradead.org,
	lrg@ti.com, broonie@opensource.wolfsonmicro.com, perex@perex.cz,
	tiwai@suse.de, shawn.guo@linaro.org,
	artem.bityutskiy@linux.intel.com, linux-kernel@vger.kernel.org,
	linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
	linux-mtd@lists.infradead.org, alsa-devel@alsa-project.org,
	linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
	Huang Shijie <shijie8@gmail.com>,
	Fabio Estevam <fabio.estevam@freescale.com>,
	artem.bityutskiy@linux.intel.com
Subject: Re: [PATCH] dma: add new DMA control commands
Date: Thu, 18 Oct 2012 10:16:06 +0200	[thread overview]
Message-ID: <201210181016.06782.marex@denx.de> (raw)
In-Reply-To: <507FB495.7050104@freescale.com>

Dear Huang Shijie,

> 于 2012年10月18日 15:14, Marek Vasut 写道:
> > Dear Huang Shijie,
> > 
> > Why such massive CC ?
> > 
> >> 于 2012年10月18日 14:18, Vinod Koul 写道:
> >>> Why cant you do start (prepare clock etc) when you submit the
> >>> descriptor to dmaengine. Can be done in tx_submit callback.
> >>> Similarly remove the clock when dma transaction gets completed.
> >> 
> >> I ever thought this method too.
> >> 
> >> But it will become low efficient in the following case:
> >>     Assuming the gpmi-nand driver has to read out 1024 pages in one
> >> 
> >> _SINGLE_ read operation.
> >> The gpmi-nand will submit the descriptor to dmaengine per page.
> > 
> > It will? Then GPMI NAND is flat our broken ... again.
> 
> yes.
> 
> Please read the NAND chip spec about the comand READ PAGE(00h-30h) and
> the code
> nand_do_read_ops(). The nand chip limits us only read one page out one
> time. So the driver will submit the descriptor to dmaengine per page.

So we can't stream data from the chip? About time to adjust the MTD framework to 
allow that. Maybe implement a command queue?

> >> So with
> >> your method,
> >> the system will repeat the enable/disable dma clock 1024 time.
> > 
> > Yes, it is the driver that's wrong.
> 
> not the driver.
> 
> >> At every
> >> enable/disable dma clock,
> >> the system has to enable the clock chain and it's parents ...
> >> 
> >> But with this patch, we only need to enable/disable dma clock one time,
> >> just at we select the nand chip.
> > 
> > You are fixing a driver problem at a framework level, wrong.
> > 
> > So, check how the MXS SPI driver handles descriptor chaining. Indeed, the
> > Sigmatel screwed the DMA stuff good. But if you analyze the SPI driver,
> > you'll notice a few important points that might come handy when you fix
> > the GPMI NAND driver properly.
> > 
> > The direction to take here is:
> > 1) Implement DMA chaining into the GPMI NAND driver
> 
> How can i implement the DMA chain if the nand chip READ-PAGE command
> gives us the one page limit?

This smells like a time to extend the MTD api ?

> thanks
> Huang Shijie
> 
> > 2) You might need to do one PIO transfer to reconfigure the IP registers
> > between each segment of the DMA chain (just as MXS SPI does it)
> > 3) You might run out of DMA descriptors when doing too long chains -- so
> > you might need to fix that part of the mxs DMA driver.

Best regards,
Marek Vasut

  parent reply	other threads:[~2012-10-18  8:16 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-18  5:32 [PATCH] dma: add new DMA control commands Huang Shijie
2012-10-18  5:32 ` Huang Shijie
2012-10-18  5:32 ` Huang Shijie
2012-10-18  5:32 ` Huang Shijie
2012-10-18  6:18 ` Vinod Koul
2012-10-18  6:18   ` Vinod Koul
2012-10-18  6:18   ` Vinod Koul
2012-10-18  6:45   ` Huang Shijie
2012-10-18  6:45     ` Huang Shijie
2012-10-18  6:45     ` Huang Shijie
2012-10-18  6:45     ` Huang Shijie
     [not found]     ` <507FA595.4020507-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2012-10-18  7:14       ` Marek Vasut
2012-10-18  7:14         ` Marek Vasut
2012-10-18  7:14         ` Marek Vasut
2012-10-18  7:14         ` Marek Vasut
2012-10-18  7:49         ` Huang Shijie
2012-10-18  7:49           ` Huang Shijie
2012-10-18  7:49           ` Huang Shijie
2012-10-18  7:49           ` Huang Shijie
     [not found]           ` <507FB495.7050104-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2012-10-18  8:16             ` Marek Vasut [this message]
2012-10-18  8:16               ` Marek Vasut
2012-10-18  8:16               ` Marek Vasut
2012-10-18  8:16               ` Marek Vasut
2012-10-18  8:29               ` Huang Shijie
2012-10-18  8:29                 ` Huang Shijie
2012-10-18  8:29                 ` Huang Shijie
2012-10-18  8:29                 ` Huang Shijie
2012-11-09 15:29                 ` Artem Bityutskiy
2012-11-09 15:29                   ` Artem Bityutskiy
2012-11-09 15:29                   ` Artem Bityutskiy
2012-10-18  8:49               ` Huang Shijie
2012-10-18  8:49                 ` Huang Shijie
2012-10-18  8:49                 ` Huang Shijie
2012-10-18  8:49                 ` Huang Shijie
     [not found]                 ` <507FC290.10205-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2012-10-18  8:49                   ` Marek Vasut
2012-10-18  8:49                     ` Marek Vasut
2012-10-18  8:49                     ` Marek Vasut
2012-10-18  8:49                     ` Marek Vasut
2012-10-18  9:13                     ` Huang Shijie
2012-10-18  9:13                       ` Huang Shijie
2012-10-18  9:13                       ` Huang Shijie
2012-10-18  9:13                       ` Huang Shijie
     [not found]                       ` <507FC827.40601-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2012-10-18 10:51                         ` Marek Vasut
2012-10-18 10:51                           ` Marek Vasut
2012-10-18 10:51                           ` Marek Vasut
2012-10-18 10:51                           ` Marek Vasut
     [not found]                           ` <201210181251.15116.marex-ynQEQJNshbs@public.gmane.org>
2012-10-18 15:11                             ` Huang Shijie
2012-10-18 15:11                               ` Huang Shijie
2012-10-18 15:11                               ` Huang Shijie
2012-10-18 15:11                               ` Huang Shijie
2012-10-18  8:52     ` Russell King - ARM Linux
2012-10-18  8:52       ` Russell King - ARM Linux
2012-10-18  8:52       ` Russell King - ARM Linux
     [not found]       ` <20121018085208.GR21164-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2012-10-18  9:10         ` Huang Shijie
2012-10-18  9:10           ` Huang Shijie
2012-10-18  9:10           ` Huang Shijie
2012-10-18  9:10           ` Huang Shijie
2012-10-18  9:29     ` Jassi Brar
2012-10-18  9:29       ` Jassi Brar
2012-10-18  9:29       ` Jassi Brar
2012-10-18 15:18       ` Huang Shijie
2012-10-18 15:18         ` Huang Shijie
2012-10-18 15:18         ` Huang Shijie
2012-10-18 15:25         ` Jassi Brar
2012-10-18 15:25           ` Jassi Brar
2012-10-18 15:25           ` Jassi Brar

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=201210181016.06782.marex@denx.de \
    --to=marex-ynqeqjnshbs@public.gmane.org \
    --cc=alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org \
    --cc=artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
    --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org \
    --cc=djbw-b10kYP2dOMg@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=lrg-l0cyMroinI0@public.gmane.org \
    --cc=perex-/Fr2/VpizcU@public.gmane.org \
    --cc=shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=shijie8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=tiwai-l3A5Bk7waGM@public.gmane.org \
    --cc=vinod.koul-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    /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: link
Be 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.