public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* IXP4xx repetitive 16-bit/32-bit I/O macros/inlines.
@ 2009-11-08 18:49 Krzysztof Halasa
  2009-11-08 20:24 ` Karl Hiramoto
  0 siblings, 1 reply; 3+ messages in thread
From: Krzysztof Halasa @ 2009-11-08 18:49 UTC (permalink / raw)
  To: linux-arm-kernel, lkml

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: IXP4xx repetitive 16-bit/32-bit I/O macros/inlines.
  2009-11-08 18:49 IXP4xx repetitive 16-bit/32-bit I/O macros/inlines Krzysztof Halasa
@ 2009-11-08 20:24 ` Karl Hiramoto
  2009-11-08 21:07   ` Krzysztof Halasa
  0 siblings, 1 reply; 3+ messages in thread
From: Karl Hiramoto @ 2009-11-08 20:24 UTC (permalink / raw)
  To: Krzysztof Halasa; +Cc: linux-arm-kernel, lkml

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
>   


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: IXP4xx repetitive 16-bit/32-bit I/O macros/inlines.
  2009-11-08 20:24 ` Karl Hiramoto
@ 2009-11-08 21:07   ` Krzysztof Halasa
  0 siblings, 0 replies; 3+ messages in thread
From: Krzysztof Halasa @ 2009-11-08 21:07 UTC (permalink / raw)
  To: Karl Hiramoto; +Cc: linux-arm-kernel, lkml

Karl Hiramoto <karl@hiramoto.org> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-11-08 21:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-08 18:49 IXP4xx repetitive 16-bit/32-bit I/O macros/inlines Krzysztof Halasa
2009-11-08 20:24 ` Karl Hiramoto
2009-11-08 21:07   ` Krzysztof Halasa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox