Re: about p3_ioremap and pata_platform

[Paul M. <pau...@re...>]

(Adding the list to CC, as this might be of general interest..)

On Fri, Mar 23, 2007 at 11:27:18AM +0900, Nobuhiro Iwamatsu wrote:
> Paul Mundt wrote:
> > On Fri, Mar 23, 2007 at 10:34:23AM +0900, Nobuhiro Iwamatsu wrote:
> >> devm_ioremap() calls ioremap on the inside.
> >> When the translated address is specified for offset of the argument with
> >> p3_ioremap(), it tries to do ioremap again.
> >>
> > This is due to the resource type, if you want to inhibit the ioremap(),
> > use IORESOURCE_IO.
> > 
> > Here's an example of what I've done for the Algo 7760 board (ignore the
> > p3_ioremap() size, I was using this to debug something):
> 
> Thank you very much.
> 
> I thought that you thought that did not use IORESOURCE_IO.
> 
> You want to delete board delicated I/O operations code( boards/xx/io.c),
> don't you ?
> 
Correct. I'll elaborate on this, both IORESOURCE_IO and IORESOURCE_MEM
are fully supported, though only IORESOURCE_MEM is subjected to regular
ioremap() behaviour. For IORESOURCE_IO, we treat these as PIO and don't
actually do any direct remapping. Note however that even a P1 address
will be ioremap()'ed in to a P2 one, there will just be no page tables.

The only reason to use IORESOURCE_MEM is if we _want_ to ioremap(),
whether for page tables in the P3 case, or just for the P1->P2
conversion.

In this case however, special care has to be taken for the PTE flag in
order to do the area assignment properly, so we have to do the remapping
ourselves _prior_ to handing it off to the driver. As far as the driver
is concerned, it's just a regular PIO address, as there's no remapping
that's required. On SH everything is effectively MMIO anyways, so we
don't really have to do anything "special" in the I/O routines (ie,
posted writes, write barriers, etc.) so the only difference between
IORESOURCE_IO and IORESOURCE_MEM is whether it's remapped.

In the past we have had this port2addr abuse, which would "trap" writes
to bogus addresses (usually x86 legacy ones) and "fix" them up to point
to where things actually sat in memory. It's _this_ that we want to be
rid of completely. These sorts of things have also been responsible for
fixing up access sizes for certain registers bound by a certain bus
width, but hiding this in the I/O routines is nonsense. If we can't do an
8-bit read due to a CF slot being wired up for only 16-bit access, then
the driver should never be attempting an 8-bit read in the first place.
Papering over it in the I/O routines is not only not a solution, but it
also introduces a lot of extra overhead that we really don't need.

Boards are slowly getting better at this, and drivers are slowly being
fixed. The long-term goal is of course to be rid of all of this
board-specific I/O crap and rip all of that out of the machvec.

The PCC bits are unfortunately something the boards will have to deal
with on their own prior to handing off the regions to the drivers. This
sucks, but we really don't want to push this logic down to the drivers,
since it's only going to be the board designer that knows where PCMCIA/CF
have been allocated, and it's only these PTE bits that differ.

PTEA has always been a kludge, and at least the later (SH-X2 and up)
parts have recycled it for something far more reasonable.

Likewise, I'm loathe to add in "special" ioremap() hacks to inhibit
page-table mapping for any more of these cases, it's already too much of
a nuisance as it is. So, if you can't handle an ioremap(), don't use
IORESOURCE_MEM.

For the access size problems, we have IORESOURCE_BITS that can be used,
which allows for the ISA PnP access size flags to be reused. ie:

	#define IORESOURCE_MEM_TYPE_MASK        (3<<3)
	#define IORESOURCE_MEM_8BIT             (0<<3)
	#define IORESOURCE_MEM_16BIT            (1<<3)
	#define IORESOURCE_MEM_8AND16BIT        (2<<3)
	#define IORESOURCE_MEM_32BIT            (3<<3)

This doesn't help for Area 5/6 selection, but we can probably recycle a
bit or two for that, as well. There are likely not enough users that care
about the PCC selection to make pushing it out of the board-specific code
worthwhile, though.