linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 8/8] ARM: omap_hsmmc: remove platform data dma_mask and initialization
Date: Wed, 18 Apr 2012 14:34:25 -0700	[thread overview]
Message-ID: <20120418213425.GS21106@atomide.com> (raw)
In-Reply-To: <20120418211606.GU25053@n2100.arm.linux.org.uk>

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120418 14:19]:
> On Wed, Apr 18, 2012 at 02:01:44PM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120418 13:28]:
> > > I'd like to have the same thing happen on OMAP1 as well (it's actually
> > > quite simple to do) and it means that this DMA engine implementation
> > > detail is (correctly) hidden from the drivers - provided there's no
> > > dependencies on each individual scatterlist entry back to the peripheral
> > > driver.
> > 
> > That would be nice. If the DMA engine driver can't dynamically adjust the
> > frame size for each SG entry, then maybe we can work around that by not doing
> > DMA for entries that are below the frame sizes?
> 
> I don't think it has to in this case, though I am thinking that we
> may have to adjust the frame size for other peripherals.
> 
> In the case of the OMAP1 MMC driver, let me pull out that chunk of code
> again:
> 
>         frame = data->blksz;
>         if (cpu_is_omap15xx() && frame > 32)
>                 frame = 32;
>         else if (frame > 64)
>                 frame = 64;
>         frame >>= 1;
>         if (!(data->flags & MMC_DATA_WRITE)) {
>                 buf = 0x800f | ((frame - 1) << 8);
>         } else {
>                 buf = 0x0f80 | ((frame - 1) << 0);
>         }
>         OMAP_MMC_WRITE(host, BUF, buf);
> 
> Nothing there depends on the size of an individual scatterlist entry -
> the dependencies for the frame size are the smaller of the FIFO size
> and the data block size.  I believe we can cope with that quite well on
> a per-transfer basis, and I _think_ we can get away with writing this
> BUF register just once per transfer (similar to what happens for PIO
> transfers.)

OK, let's see if that works :)
 
> However, this is going to be rather hit and miss for me - all I can do
> is create a patch and check that it builds.  I have no way (that I know
> of) to test this change as I don't have any OMAP1 nor OMAP2 hardware.

I can certainly test it on at least for 1710 on 770 and 2420 on N800.

Regards,

Tony

  reply	other threads:[~2012-04-18 21:34 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-18 10:09 [RFC 0/8] DMA engine conversion for omap_hsmmc Russell King - ARM Linux
2012-04-18 10:10 ` [PATCH 1/8] ARM: OMAP: fix DMA vs memory ordering Russell King
2012-04-18 10:15   ` Felipe Balbi
2012-04-18 10:17     ` Russell King - ARM Linux
2012-04-18 10:18       ` Felipe Balbi
2012-04-18 10:26         ` Russell King - ARM Linux
2012-04-20 22:22   ` Tony Lindgren
2012-04-23 14:19     ` Russell King - ARM Linux
2012-04-23 14:27       ` Tony Lindgren
2012-04-23 14:35         ` Shilimkar, Santosh
2012-04-18 10:10 ` [PATCH 2/8] dmaengine: amba-pl08x: ensure physical channels are properly held Russell King
2012-04-18 10:19   ` Russell King - ARM Linux
2012-04-27 20:38     ` Linus Walleij
2012-04-27 21:41       ` Russell King - ARM Linux
2012-04-18 10:11 ` [PATCH 3/8] dmaengine: split out virtual channel DMA support from sa11x0 driver Russell King
2012-04-24 10:35   ` Laxman Dewangan
2012-04-24 10:50     ` Russell King - ARM Linux
2012-04-24 10:57       ` Laxman Dewangan
2012-04-18 10:11 ` [PATCH 4/8] dmaengine: add OMAP DMA engine driver Russell King
2012-04-18 10:11 ` [PATCH 5/8] mmc: omap_hsmmc: release correct resource Russell King
2012-04-20 22:23   ` Tony Lindgren
2012-04-20 22:59     ` Chris Ball
2012-04-21  2:35       ` Chris Ball
2012-04-21  9:48         ` Russell King - ARM Linux
2012-04-22 15:20           ` Chris Ball
2012-04-18 10:12 ` [PATCH 6/8] mmc: omap_hsmmc: add DMA engine support Russell King
2012-04-18 18:11   ` Tony Lindgren
2012-04-18 19:09     ` Russell King - ARM Linux
2012-04-18 19:53       ` Tony Lindgren
2012-04-18 10:12 ` [PATCH 7/8] mmc: omap_hsmmc: remove private DMA API implementation Russell King
2012-04-18 10:12 ` [PATCH 8/8] ARM: omap_hsmmc: remove platform data dma_mask and initialization Russell King
2012-04-18 15:23   ` T Krishnamoorthy, Balaji
2012-04-18 15:29     ` Russell King - ARM Linux
2012-04-18 15:35       ` T Krishnamoorthy, Balaji
2012-04-18 18:19         ` Tony Lindgren
2012-04-18 19:10           ` Russell King - ARM Linux
2012-04-18 19:55             ` Tony Lindgren
2012-04-18 19:42         ` Russell King - ARM Linux
2012-04-18 20:02           ` Tony Lindgren
2012-04-18 20:24             ` Russell King - ARM Linux
2012-04-18 21:01               ` Tony Lindgren
2012-04-18 21:16                 ` Russell King - ARM Linux
2012-04-18 21:34                   ` Tony Lindgren [this message]
2012-04-18 21:36                   ` Russell King - ARM Linux
2012-04-19  1:39                     ` Tony Lindgren
2012-04-19 17:43                       ` Russell King - ARM Linux
2012-04-19 18:07                         ` Tony Lindgren
2012-04-20 15:10                           ` Russell King - ARM Linux
2012-04-20 15:26                             ` Tony Lindgren
2012-04-20 15:37                               ` Russell King - ARM Linux
2012-04-20 16:43                                 ` Tony Lindgren
2012-04-20 22:09                                   ` Russell King - ARM Linux
2012-04-20 22:21                                     ` Tony Lindgren
2012-04-20 16:50                                 ` Tony Lindgren
2012-04-23 14:14                                   ` Russell King - ARM Linux
2012-04-23 14:30                                     ` Tony Lindgren
2012-04-23 14:34                                       ` Russell King - ARM Linux
2012-04-23 11:46 ` [RFC 0/8] DMA engine conversion Russell King - ARM Linux
2012-04-23 12:32   ` Shilimkar, Santosh
2012-04-23 15:27     ` Shubhrajyoti

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=20120418213425.GS21106@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).