Re: [PATCH 8/8] ARM: omap_hsmmc: remove platform data dma_mask and initialization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [120418 14:19]:
> On Wed, Apr 18, 2012 at 02:01:44PM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux