Anybody using 32-bit PATA/SATA transfers on IXP4xx? :-)
Long story, mostly with PCI in mind:
- readb/readw/readl, writeb/writew/writel macros are value-preserving
- __raw_* are order-preserving (i.e., strings are preserved)
but the repetitive versions (outs[wl], ins[wl], ioread*_rep,
iowrite*_rep) are supposed to preserve order as well (while lacking the
__raw_ prefix).
Comments?
Is it worth it to change the names to __raw_*, or maybe to some other
variant like native_*, to avoid confusion? It's really confusing.
There aren't many users in the tree (I'd also change readl() and friends
to something like read_le32, but it would be massive, comments welcome).
Or perhaps we should have *_le32, *_be32, _order32? It should be
something the compiler can optimize out if used with le32_to_cpu etc.
--- a/arch/arm/mach-ixp4xx/include/mach/io.h
+++ b/arch/arm/mach-ixp4xx/include/mach/io.h
@@ -311,7 +311,7 @@ static inline void
__ixp4xx_outsl(u32 io_addr, const u32 *vaddr, u32 count)
{
while (count--)
- outl(*vaddr++, io_addr);
+ outl(cpu_to_le32(*vaddr++), io_addr);
}
static inline u8
@@ -366,7 +366,7 @@ static inline void
__ixp4xx_insl(u32 io_addr, u32 *vaddr, u32 count)
{
while (count--)
- *vaddr++ = inl(io_addr);
+ *vaddr++ = le32_to_cpu(inl(io_addr));
}
#define PIO_OFFSET 0x10000UL
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> Anybody using 32-bit PATA/SATA transfers on IXP4xx? :-)
>
Yes, on HPT371 IDE chip on the PCI bus to interface to compact flash
to store logs. For what it's worth I've only ever been able to make PIO
work, I've never had any luck with the IDE DMA modes. It hasn't been a
high enough priority to investigate further.
> Long story, mostly with PCI in mind:
> - readb/readw/readl, writeb/writew/writel macros are value-preserving
> - __raw_* are order-preserving (i.e., strings are preserved)
> but the repetitive versions (outs[wl], ins[wl], ioread*_rep,
> iowrite*_rep) are supposed to preserve order as well (while lacking the
> __raw_ prefix).
>
> Comments?
>
> Is it worth it to change the names to __raw_*, or maybe to some other
> variant like native_*, to avoid confusion? It's really confusing.
> There aren't many users in the tree (I'd also change readl() and friends
> to something like read_le32, but it would be massive, comments welcome).
>
> Or perhaps we should have *_le32, *_be32, _order32? It should be
> something the compiler can optimize out if used wi
*_le32, *_be32, _order32 sounds like a good idea.
> th le32_to_cpu etc.
>
>
> --- a/arch/arm/mach-ixp4xx/include/mach/io.h
> +++ b/arch/arm/mach-ixp4xx/include/mach/io.h
> @@ -311,7 +311,7 @@ static inline void
> __ixp4xx_outsl(u32 io_addr, const u32 *vaddr, u32 count)
> {
> while (count--)
> - outl(*vaddr++, io_addr);
> + outl(cpu_to_le32(*vaddr++), io_addr);
> }
>
> static inline u8
> @@ -366,7 +366,7 @@ static inline void
> __ixp4xx_insl(u32 io_addr, u32 *vaddr, u32 count)
> {
> while (count--)
> - *vaddr++ = inl(io_addr);
> + *vaddr++ = le32_to_cpu(inl(io_addr));
> }
>
> #define PIO_OFFSET 0x10000UL
>
Karl Hiramoto <[email protected]> writes:
>> Anybody using 32-bit PATA/SATA transfers on IXP4xx? :-)
> Yes, on HPT371 IDE chip on the PCI bus to interface to compact flash
> to store logs.
$ grep inherits drivers/ata/pata_hpt37x.c
.inherits = &ata_bmdma_port_ops,
.inherits = &hpt370_port_ops,
.inherits = &ata_bmdma_port_ops,
.inherits = &hpt372_port_ops,
Looks like 16-bit port_ops.
> For what it's worth I've only ever been able to make
> PIO work, I've never had any luck with the IDE DMA modes. It hasn't
> been a high enough priority to investigate further.
Interesting. I have no issues with DMA modes, with VIA VT6421A (this
chip seems to have other critical problems), with CS5536 (PATA) and with
SIL3512 (the patch has to be applied in big-endian mode, and another
patch to sata_sil.c must be applied because IXP4xx can't do 8/16-bit
PCI MMIO read).
--
Krzysztof Halasa