On Tue, 3 Jul 2001, David Howells wrote:
> > The question I think being ignored here is. Why not leave things as is. The
> > multiple bus stuff is a port specific detail hidden behind readb() and
> > friends.
>
> This isn't so much for the case where the address generation is done by a
> simple
On Tue, 3 Jul 2001, David Howells wrote:
> * It should make drivers easier to write: they don't have to worry about
>whether a resource refers to memory or to I/O or to something more exotic.
>
> * It makes some drivers more flexible. For example, the ne2k-pci driver has
>to be set at
On Tue, 3 Jul 2001, David Howells wrote:
The question I think being ignored here is. Why not leave things as is. The
multiple bus stuff is a port specific detail hidden behind readb() and
friends.
This isn't so much for the case where the address generation is done by a
simple addition.
On Tue, 3 Jul 2001, David Howells wrote:
* It should make drivers easier to write: they don't have to worry about
whether a resource refers to memory or to I/O or to something more exotic.
* It makes some drivers more flexible. For example, the ne2k-pci driver has
to be set at
>> I'm more concerned about having all that space mapped permanently in
>> kernel virtual space. I'd prefer mapping on-demand, and that would
>> require a specific ioremap for IOs.
>
>I have no problem with the idea of a function to indicate which I/O maps you
>are and are not using. But passing
> I'm more concerned about having all that space mapped permanently in
> kernel virtual space. I'd prefer mapping on-demand, and that would
> require a specific ioremap for IOs.
I have no problem with the idea of a function to indicate which I/O maps you
are and are not using. But passing
> For example, one board I've got doesn't allow you to do a straight
> memory-mapped I/O access to your PCI device directly, but have to reposition a
> window in the CPU's memory space over part of the PCI memory space first, and
> then hold a spinlock whilst you do it.
What does this prove.
David Howells wrote:
> Of course, however, this still requires cookie decoding to be done in readb
> and writeb (even on the i386). So why not use resource struct?
IMHO that makes the operation too heavyweight on architectures where
that level of abstraction is not needed.
--
Jeff Garzik
> I also point out that using ioremap for PIO adds flexibility while
> keeping most drivers relatively unchanged. Everyone uses a base address
> anyway, so whether its obtained directly (address from PCI BAR) or
> indirectly (via ioremap), you already store it and use it.
I see what you're
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >
> > > > > You pass a single cookie to the readb code
> > > > > Odd platforms decode it
> > > >
> > > > Last time I checked, ioremap didn't work for inb() and outb().
> > >
> > > It should :)
> >
> > it doesnt need to.
> >
I also point out that using ioremap for PIO adds flexibility while
keeping most drivers relatively unchanged. Everyone uses a base address
anyway, so whether its obtained directly (address from PCI BAR) or
indirectly (via ioremap), you already store it and use it.
Further, code lacking ioremap
David Howells wrote:
>
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > Russell King wrote:
> > >
> > > On Mon, Jul 02, 2001 at 05:56:56PM +0100, Alan Cox wrote:
> > > > Case 1:
> > > > You pass a single cookie to the readb code
> > > > Odd platforms decode it
> > >
> > > Last time I
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Russell King wrote:
> >
> > On Mon, Jul 02, 2001 at 05:56:56PM +0100, Alan Cox wrote:
> > > Case 1:
> > > You pass a single cookie to the readb code
> > > Odd platforms decode it
> >
> > Last time I checked, ioremap didn't work for inb() and
Russell King <[EMAIL PROTECTED]> wrote:
> They _ARE_ different, because people connect these chips in many different
> ways. For example:
Also hence the mess in serial.c. On the board I'm currently dealing with, the
PC16550 chip is connected to the memory space with registers at 4-byte
> David Howells wrote:
> > For example, one board I've got doesn't allow you to do a straight
> > memory-mapped I/O access to your PCI device directly, but have to
> > reposition a window in the CPU's memory space over part of the PCI memory
> > space first, and then hold a spinlock whilst you
David Howells wrote:
> For example, one board I've got doesn't allow you to do a straight
> memory-mapped I/O access to your PCI device directly, but have to reposition a
> window in the CPU's memory space over part of the PCI memory space first, and
> then hold a spinlock whilst you do it.
> The question I think being ignored here is. Why not leave things as is. The
> multiple bus stuff is a port specific detail hidden behind readb() and
> friends.
This isn't so much for the case where the address generation is done by a
simple addition. That could be optimised away by the
David Howells wrote:
For example, one board I've got doesn't allow you to do a straight
memory-mapped I/O access to your PCI device directly, but have to reposition a
window in the CPU's memory space over part of the PCI memory space first, and
then hold a spinlock whilst you do it.
Yuck.
The question I think being ignored here is. Why not leave things as is. The
multiple bus stuff is a port specific detail hidden behind readb() and
friends.
This isn't so much for the case where the address generation is done by a
simple addition. That could be optimised away by the compiler
Jeff Garzik [EMAIL PROTECTED] wrote:
Alan Cox wrote:
You pass a single cookie to the readb code
Odd platforms decode it
Last time I checked, ioremap didn't work for inb() and outb().
It should :)
it doesnt need to.
pci_find_device returns the io
I also point out that using ioremap for PIO adds flexibility while
keeping most drivers relatively unchanged. Everyone uses a base address
anyway, so whether its obtained directly (address from PCI BAR) or
indirectly (via ioremap), you already store it and use it.
I see what you're getting
Russell King [EMAIL PROTECTED] wrote:
They _ARE_ different, because people connect these chips in many different
ways. For example:
Also hence the mess in serial.c. On the board I'm currently dealing with, the
PC16550 chip is connected to the memory space with registers at 4-byte
intervals
David Howells wrote:
For example, one board I've got doesn't allow you to do a straight
memory-mapped I/O access to your PCI device directly, but have to
reposition a window in the CPU's memory space over part of the PCI memory
space first, and then hold a spinlock whilst you do it.
David Howells wrote:
Of course, however, this still requires cookie decoding to be done in readb
and writeb (even on the i386). So why not use resource struct?
IMHO that makes the operation too heavyweight on architectures where
that level of abstraction is not needed.
--
Jeff Garzik |
Jeff Garzik [EMAIL PROTECTED] wrote:
Russell King wrote:
On Mon, Jul 02, 2001 at 05:56:56PM +0100, Alan Cox wrote:
Case 1:
You pass a single cookie to the readb code
Odd platforms decode it
Last time I checked, ioremap didn't work for inb() and outb().
It
David Howells wrote:
Jeff Garzik [EMAIL PROTECTED] wrote:
Russell King wrote:
On Mon, Jul 02, 2001 at 05:56:56PM +0100, Alan Cox wrote:
Case 1:
You pass a single cookie to the readb code
Odd platforms decode it
Last time I checked, ioremap didn't work for
I also point out that using ioremap for PIO adds flexibility while
keeping most drivers relatively unchanged. Everyone uses a base address
anyway, so whether its obtained directly (address from PCI BAR) or
indirectly (via ioremap), you already store it and use it.
Further, code lacking ioremap
I'm more concerned about having all that space mapped permanently in
kernel virtual space. I'd prefer mapping on-demand, and that would
require a specific ioremap for IOs.
I have no problem with the idea of a function to indicate which I/O maps you
are and are not using. But passing resource
For example, one board I've got doesn't allow you to do a straight
memory-mapped I/O access to your PCI device directly, but have to reposition a
window in the CPU's memory space over part of the PCI memory space first, and
then hold a spinlock whilst you do it.
What does this prove. PA-RISC
I'm more concerned about having all that space mapped permanently in
kernel virtual space. I'd prefer mapping on-demand, and that would
require a specific ioremap for IOs.
I have no problem with the idea of a function to indicate which I/O maps you
are and are not using. But passing resource
Alan Cox wrote:
>
> > > > You pass a single cookie to the readb code
> > > > Odd platforms decode it
> > >
> > > Last time I checked, ioremap didn't work for inb() and outb().
> >
> > It should :)
>
> it doesnt need to.
>
> pci_find_device returns the io address and can return a
>
>Can you give me an idea of what sort of cookie decoding a PPC/PMac would need
>and why - Im working off things like pa-risc so I dont have a full picture.
Each domain provide an IO space (size depends on the bridge, recent Apple
UniNorth hosts have 16Mb per domain).
That IO space can be in
> - Parsing of this cookie on each inx/outx access, which can
> take a bit of time (typically looking up the host bridge)
It depends on the implementation obviously, but its typically something like
take lock
writew(port&0x, port&0x);
writew(data,
>Last time I checked, ioremap didn't work for inb() and outb().
ioremap itself cannot work for inb/outb as they are different
address spaces with potentially overlapping addresses, I don't
see how a single function would handle both... except if we
pass it a struct resource instead of the
>> > Last time I checked, ioremap didn't work for inb() and outb().
>>
>> It should :)
>
>it doesnt need to.
>
>pci_find_device returns the io address and can return a cookie, ditto
>isapnp etc
Yes, but doing that require 2 annoying things:
- Parsing of this cookie on each inx/outx access,
> > > You pass a single cookie to the readb code
> > > Odd platforms decode it
> >
> > Last time I checked, ioremap didn't work for inb() and outb().
>
> It should :)
it doesnt need to.
pci_find_device returns the io address and can return a cookie, ditto
isapnp etc
-
To
Russell King wrote:
>
> On Mon, Jul 02, 2001 at 05:56:56PM +0100, Alan Cox wrote:
> > Case 1:
> > You pass a single cookie to the readb code
> > Odd platforms decode it
>
> Last time I checked, ioremap didn't work for inb() and outb().
It should :)
--
Jeff Garzik | "I
On Mon, Jul 02, 2001 at 05:56:56PM +0100, Alan Cox wrote:
> Case 1:
> You pass a single cookie to the readb code
> Odd platforms decode it
Last time I checked, ioremap didn't work for inb() and outb().
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
> Because if we just pass in this one extra piece of information which is
> normally already available in the driver, we can avoid a whole lot of ugly
> cruft in the out-of-line functions by plugging in the correct out-of-line
> function to match the resource.
Case 1:
You pass a single
[EMAIL PROTECTED] said:
> The question I think being ignored here is. Why not leave things as
> is.
Because if we just pass in this one extra piece of information which is
normally already available in the driver, we can avoid a whole lot of ugly
cruft in the out-of-line functions by plugging
> [EMAIL PROTECTED] said:
> > I think the second #define should be:
> > #define res_readb(res, adr) readb(res->start+adr)
> > for consistency.
>
> You're right that it should be consistent. But it doesn't really matter
> whether we pass an offset within the resource, or whether we continue
[EMAIL PROTECTED] said:
> I think the second #define should be:
> #define res_readb(res, adr) readb(res->start+adr)
> for consistency.
You're right that it should be consistent. But it doesn't really matter
whether we pass an offset within the resource, or whether we continue to
pass
> #ifdef OUT_OF_LINE_MMIO
> #define res_readb(res, adr) (res->access_ops->readb(res, adr)
> #else
> #define res_readb(res, adr) readb(adr)
> #endif
I think the second #define should be:
#define res_readb(res, adr) readb(res->start+adr)
for consistency.
David
-
To unsubscribe from
[EMAIL PROTECTED] said:
> But it's going to cost for the ones who do not support this.
You don't need to make it out-of-line for all cases - or indeed in any case
where it isn't out-of-line already. Some architectures may have only IO
calls out-of-line (many already do). Some may have MMIO
Because if we just pass in this one extra piece of information which is
normally already available in the driver, we can avoid a whole lot of ugly
cruft in the out-of-line functions by plugging in the correct out-of-line
function to match the resource.
Case 1:
You pass a single
You pass a single cookie to the readb code
Odd platforms decode it
Last time I checked, ioremap didn't work for inb() and outb().
It should :)
it doesnt need to.
pci_find_device returns the io address and can return a cookie, ditto
isapnp etc
-
To unsubscribe from
Last time I checked, ioremap didn't work for inb() and outb().
It should :)
it doesnt need to.
pci_find_device returns the io address and can return a cookie, ditto
isapnp etc
Yes, but doing that require 2 annoying things:
- Parsing of this cookie on each inx/outx access, which can
Last time I checked, ioremap didn't work for inb() and outb().
ioremap itself cannot work for inb/outb as they are different
address spaces with potentially overlapping addresses, I don't
see how a single function would handle both... except if we
pass it a struct resource instead of the
On Mon, Jul 02, 2001 at 05:56:56PM +0100, Alan Cox wrote:
Case 1:
You pass a single cookie to the readb code
Odd platforms decode it
Last time I checked, ioremap didn't work for inb() and outb().
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
Russell King wrote:
On Mon, Jul 02, 2001 at 05:56:56PM +0100, Alan Cox wrote:
Case 1:
You pass a single cookie to the readb code
Odd platforms decode it
Last time I checked, ioremap didn't work for inb() and outb().
It should :)
--
Jeff Garzik | I respect faith,
Can you give me an idea of what sort of cookie decoding a PPC/PMac would need
and why - Im working off things like pa-risc so I dont have a full picture.
Each domain provide an IO space (size depends on the bridge, recent Apple
UniNorth hosts have 16Mb per domain).
That IO space can be in any
Alan Cox wrote:
You pass a single cookie to the readb code
Odd platforms decode it
Last time I checked, ioremap didn't work for inb() and outb().
It should :)
it doesnt need to.
pci_find_device returns the io address and can return a cookie, ditto
isapnp etc
- Parsing of this cookie on each inx/outx access, which can
take a bit of time (typically looking up the host bridge)
It depends on the implementation obviously, but its typically something like
take lock
writew(port0x, port0x);
writew(data,
[EMAIL PROTECTED] said:
I think the second #define should be:
#define res_readb(res, adr) readb(res-start+adr)
for consistency.
You're right that it should be consistent. But it doesn't really matter
whether we pass an offset within the resource, or whether we continue to
pass the
[EMAIL PROTECTED] said:
I think the second #define should be:
#define res_readb(res, adr) readb(res-start+adr)
for consistency.
You're right that it should be consistent. But it doesn't really matter
whether we pass an offset within the resource, or whether we continue to
The
#ifdef OUT_OF_LINE_MMIO
#define res_readb(res, adr) (res-access_ops-readb(res, adr)
#else
#define res_readb(res, adr) readb(adr)
#endif
I think the second #define should be:
#define res_readb(res, adr) readb(res-start+adr)
for consistency.
David
-
To unsubscribe from this list:
[EMAIL PROTECTED] said:
The question I think being ignored here is. Why not leave things as
is.
Because if we just pass in this one extra piece of information which is
normally already available in the driver, we can avoid a whole lot of ugly
cruft in the out-of-line functions by plugging in
[EMAIL PROTECTED] said:
But it's going to cost for the ones who do not support this.
You don't need to make it out-of-line for all cases - or indeed in any case
where it isn't out-of-line already. Some architectures may have only IO
calls out-of-line (many already do). Some may have MMIO
> "David" == David Howells <[EMAIL PROTECTED]> writes:
David> Jes Sorensen <[EMAIL PROTECTED]> wrote:
>> Have you considered the method used by the 8390 Ethernet driver?
>> For each device, add a pointer to the registers and a register
>> shift.
David> And also flags to specify which
Jes Sorensen <[EMAIL PROTECTED]> wrote:
> > "David" == David Woodhouse <[EMAIL PROTECTED]> writes:
>
> David> Having per-resource I/O methods would help us to remove some of
> David> the cruft which is accumulating in various non-x86 code. Note
> David> that the below is the _core_ routines
Jes Sorensen [EMAIL PROTECTED] wrote:
David == David Woodhouse [EMAIL PROTECTED] writes:
David Having per-resource I/O methods would help us to remove some of
David the cruft which is accumulating in various non-x86 code. Note
David that the below is the _core_ routines for _one_ board -
David == David Howells [EMAIL PROTECTED] writes:
David Jes Sorensen [EMAIL PROTECTED] wrote:
Have you considered the method used by the 8390 Ethernet driver?
For each device, add a pointer to the registers and a register
shift.
David And also flags to specify which address space the I/O
> "David" == David Woodhouse <[EMAIL PROTECTED]> writes:
David> Having per-resource I/O methods would help us to remove some of
David> the cruft which is accumulating in various non-x86 code. Note
David> that the below is the _core_ routines for _one_ board - I'm not
David> even including
[EMAIL PROTECTED] said:
> PCI memory (and sometimes I/O) writes are posted, Since x86 memory
> writes are also parallelisable instructions and since the CPU merely
> has to retire the writes in order your stall basically doesnt exist.
True. I can envisage a situation where the overhead of the
>Also on an i386, the actual I/O instruction itself is going to take a
>comparatively long time anyway, given the speed differential between CPU
>and external buses.
PCI memory (and sometimes I/O) writes are posted, Since x86 memory writes are
also parallelisable instructions and
In conjunction with David Woodhouse ([EMAIL PROTECTED]) and Arjan Van De Ven
([EMAIL PROTECTED]), I've come up with a way to abstract I/O accesses in the
Linux kernel whilst trying to keep overheads minimal. These would be
particularly useful on many non-i386 platforms.
Any comments would be
In conjunction with David Woodhouse ([EMAIL PROTECTED]) and Arjan Van De Ven
([EMAIL PROTECTED]), I've come up with a way to abstract I/O accesses in the
Linux kernel whilst trying to keep overheads minimal. These would be
particularly useful on many non-i386 platforms.
Any comments would be
Also on an i386, the actual I/O instruction itself is going to take a
comparatively long time anyway, given the speed differential between CPU
and external buses.
PCI memory (and sometimes I/O) writes are posted, Since x86 memory writes are
also parallelisable instructions and since
[EMAIL PROTECTED] said:
PCI memory (and sometimes I/O) writes are posted, Since x86 memory
writes are also parallelisable instructions and since the CPU merely
has to retire the writes in order your stall basically doesnt exist.
True. I can envisage a situation where the overhead of the
David == David Woodhouse [EMAIL PROTECTED] writes:
David Having per-resource I/O methods would help us to remove some of
David the cruft which is accumulating in various non-x86 code. Note
David that the below is the _core_ routines for _one_ board - I'm not
David even including the extra
70 matches
Mail list logo
