2007/9/19, Alan Cox <[EMAIL PROTECTED]>:
> > If you use ioport_map/unmap, then you really *should* access them with the
> > proper iomem accessors (ioread/iowrite). The fact that it may happen to
> > work (when using the default lib/iomap.c implementation, at least) on
> > some architectures and wi
On Tue, 18 Sep 2007, Jeff Garzik wrote:
>
> Easy enough... 'pcimap' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
This is wrong.
You must not put it in lib/iomap.c, since that file is only compiled for
architectures that use CONFIG_GENERIC_IOMAP.
So you need
Benjamin Herrenschmidt wrote:
On Tue, 2007-09-18 at 16:21 -0400, Jeff Garzik wrote:
A new pci_mmio_map() helper, to be used with 100% MMIO hardware, might
help eliminate confusion.
Maybe not the best name in theory but at least would show that it
relates to existing ioremap would be pci_iorem
On Wed, 19 Sep 2007, Benjamin Herrenschmidt wrote:
>
> Also, I've been told that modern x86 chipsets have the ability to remap
> IO space in the CPU physical address space. Is that true ? That would
> allow even x86 to get rid of the condition and just use some magic
> offset at map time.
I've
On Tue, 18 Sep 2007, Linus Torvalds wrote:
>
> I just think that proliferation of IO interfaces is a bad idea.
Side note: just allowing readl/writel on the iomap'ed pointers obviously
avoids that proliferation, but iomap really is architecture-specific, so
not only will different architectur
On Tue, 2007-09-18 at 16:21 -0400, Jeff Garzik wrote:
> A new pci_mmio_map() helper, to be used with 100% MMIO hardware, might
> help eliminate confusion.
Maybe not the best name in theory but at least would show that it
relates to existing ioremap would be pci_ioremap()
Ben.
-
To unsubscribe
On Tue, 2007-09-18 at 13:30 -0700, Linus Torvalds wrote:
> Quite frankly, if performance is a _real_ reason to avoid
> ioread*/iowrite*, I'll happily accept read*/write*, but it would be
> needed
> to be backed up by real numbers. Can you even measure it?
>
Also, I've been told that modern x86
> If you use ioport_map/unmap, then you really *should* access them with the
> proper iomem accessors (ioread/iowrite). The fact that it may happen to
> work (when using the default lib/iomap.c implementation, at least) on
> some architectures and with the current implementation still doesn't me
On Tue, 2007-09-18 at 12:03 -0700, Linus Torvalds wrote:
>
> On Tue, 18 Sep 2007, Luis R. Rodriguez wrote:
> >
> > Alright, here is the same patch inline with s/recommended/required/
> > language:
>
> Well, the thing is, I'm not at all sure that I agree with this.
>
> If you use ioport_map/unm
On Tue, 18 Sep 2007, Jeff Garzik wrote:
>
> Most new hardware is MMIO-only, making ioread32() only for drivers that care
> about legacy IO support, something that is being slowly phased out. e.g.
> legacy IDE, legacy 10/100 mbps ethernet NICs with the dual MMIO/PIO register
> spaces.
Hey, I th
Linus Torvalds wrote:
The old situation with SATA drivers that had
if (iomem)
writel(..)
else
outl(..)
in the cases that needed it (and used hardcoded writel/outl in the cases
that didn't) was an example of code that "in theory" is faster. But
d
On Tue, 18 Sep 2007, Luis R. Rodriguez wrote:
>
> ACK but do we really need to benchmark this if we *know* we are
> creating unnecessary branches? How about Jeff's suggestion of
> introducing pci_mmio_map() ?
Here's the counter-argument:
- the run-time expense of this is basically *zero*
-
On 9/18/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 18 Sep 2007, Luis R. Rodriguez wrote:
> >
> > An extra branch is created on MMIO-only devices on read/writes on the
> > IO_COND macro using this interface -- or is this optimized out?
>
> Umm. Does anybody actually have any perform
On Tue, 18 Sep 2007, Luis R. Rodriguez wrote:
>
> An extra branch is created on MMIO-only devices on read/writes on the
> IO_COND macro using this interface -- or is this optimized out?
Umm. Does anybody actually have any performance numbers?
The thing is, those things are *cheap* compared to
Linus Torvalds wrote:
Why do people insist on
using the old interfaces (and matching them with the new setup)?
readl/writel is [slightly] faster, and possibility of using even-write
__raw_writel() exists, in the old interface...
...but pci_iomap() is a bus-friendly wrapper that handles a f
On 9/18/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 18 Sep 2007, Luis R. Rodriguez wrote:
> >
> > ACK -- driver developers use this just to save themselves a few lines
> > from calling pci_resource_start() and friends. How about having an
> > inline which does what pci_iomap() does
On Tue, 18 Sep 2007, Luis R. Rodriguez wrote:
>
> ACK -- driver developers use this just to save themselves a few lines
> from calling pci_resource_start() and friends. How about having an
> inline which does what pci_iomap() does except it doesn't call
> ioport_map() ? I am just not sure where
On 9/18/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 18 Sep 2007, Luis R. Rodriguez wrote:
> >
> > Alright, here is the same patch inline with s/recommended/required/
> > language:
>
> Well, the thing is, I'm not at all sure that I agree with this.
>
> If you use ioport_map/unmap, t
On Tue, 18 Sep 2007, Luis R. Rodriguez wrote:
>
> Alright, here is the same patch inline with s/recommended/required/ language:
Well, the thing is, I'm not at all sure that I agree with this.
If you use ioport_map/unmap, then you really *should* access them with the
proper iomem accessors (io
On 9/18/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Sep 2007 16:22:07 -0400
> "Luis R. Rodriguez" <[EMAIL PROTECTED]> wrote:
>
> > This patch updates the pci_iomap() kernel-doc to make it clarify the
> > case when read*()/write*() can be called over ioread*/iowrite*(). When
> > driver writ
On Mon, 17 Sep 2007 16:22:07 -0400
"Luis R. Rodriguez" <[EMAIL PROTECTED]> wrote:
> This patch updates the pci_iomap() kernel-doc to make it clarify the
> case when read*()/write*() can be called over ioread*/iowrite*(). When
> driver writers read this documenation sometimes it is assumed you just
This patch updates the pci_iomap() kernel-doc to make it clarify the
case when read*()/write*() can be called over ioread*/iowrite*(). When
driver writers read this documenation sometimes it is assumed you just
*need* to use ioread*()/iorwrite*(). We have an exception so lets just
clarify this is n
22 matches
Mail list logo
