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 a
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 r
> 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 resourc
> 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-R
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 gett
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 f
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 chec
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
interval
> 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
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 compile
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 coo
>
>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 a
> - 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, port&0x
>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 address
>> > 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, wh
> > > 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 unsubscr
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
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 i
> [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 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
[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 cal
> "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 addres
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
> "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
[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 f
>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 sinc
34 matches
Mail list logo
