[RFC PATCH 0/4] PIO drivers and cache coherency

[Catalin Marinas <catalin.marinas@arm.com>]

Hi,

There were a couple of threads recently about PIO drivers and cache
coherency for page cache pages. I'll try to quickly summarise some of
the discussions and current API issues and propose some improvements
(please correct if I got it wrong). I'm assuming the key people are on
linux-arch but if I missed anyone please cc them.

In the ARM case, a PIO driver writes the data to a page cache page
dirtying the D-cache. This may cause either aliases with the user
mapping (if the hardware has such thing) or just incoherency with the
I-cache on Harvard architectures.

Two examples are the ISP1760 HCD driver and the libata-sff library for
PIO sector transfers. Without any changes to these drivers, rootfs on a
USB stick or CompactFlash (via pata-platform) cannot be used (it usually
fails in /sbin/init with illegal instruction).

Based on the Documentation/cachetlb.txt document, my first approach was
to use flush_dcache_page() in the corresponding drivers, though with
some drawbacks and this doesn't seem to be a popular choice.

These two examples actually have different ways of accessing the
transfer buffer. The HCD driver receives a pointer via
urb->transfer_buffer while libata-sff uses a page structure.

One of the proposals was to always use the kmap API even if the page
isn't a highmem one (or if the kernel doesn't support highmem) and do
the cache flushing in these functions. There may be performance
penalties with this approach on some architectures and for some drivers
the kmap() is called in upper layers (the HCD case).

Another proposal was to extend the kmap API with information about the
direction of the transfer so that it can be implemented more
efficiently (functions like kmap_pio_*). This approach requires the page
structure to always be available for passing to the kmap_pio_* functions
but that's not possible on HCD devices (and upper layers like USB mass
storage do not know whether the driver is going to use DMA or PIO).

IMHO, what we need is something that resembles the DMA API. Another
opinion (James Bottomley's) is that such API would be closer to the kmap
API. Any other suggestions are welcome.

My proposal is for a PIO mapping API similar to the DMA API that
architectures can implement as they like to deal with such situations.
The first patch is an example specification of such API intended to
start a discussion around it rather than a final proposal.

The second patch is a light-weight ARM implementation of such APIs.  It
is incomplete in the sense that it doesn't do additional checks for
highmem pages (that may be flushed via kunmap_atomic). It also doesn't
deal with D-cache aliasing correctly.

The third and fourth patches show example usages of such API in the HCD
and libata cases.

Regards.


Catalin Marinas (4):
      pio-mapping: Add generic support for PIO mapping API
      pio-mapping: Add ARM support for the PIO mapping API
      pio-mapping: Use the PIO mapping API in libata-sff.c
      pio-mapping: Use the PIO mapping API in the ISP1760 HCD driver


 arch/arm/Kconfig                   |    3 ++
 arch/arm/include/asm/pio-mapping.h |   52 +++++++++++++++++++++++++++++++
 drivers/ata/libata-sff.c           |   10 ++++--
 drivers/usb/host/isp1760-hcd.c     |    9 +++++
 include/linux/pio-mapping.h        |   61 ++++++++++++++++++++++++++++++++++++
 5 files changed, 131 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/include/asm/pio-mapping.h
 create mode 100644 include/linux/pio-mapping.h

-- 
Catalin