lkml.org 
[lkml]   [1998]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Accessing MMIO PCI space - crossplatform
Hello.
First of all, thanks go to every guru who replied...
Jamie Lokier wrote:
> > b) readl/writel should not do anything with address
> I agree, and also address should be an ioaddr_t abstraction. (You can't
> use it for anything else).
Yes, that's true. On alpha, it cannot be void*, it must be "wider" (voila,
I've found why matroxfb has still some glitches)
> - With pagetable walking, you can no longer assume
> virt_to_bus(addr+N) == virt_to_bus(addr)+N.
You can assume it if you KNOW that you are accessing continuous space.
If above is not valid, with current code you'll get fault or you overwrite
some unwanted memory... If above is not valid in general, device writters
can check for this situation and program scatter-gather right (or make
continuous copy)).
> > e) that means:
> > 1) clear readl/writel interface that passed address must
> > be obtained from ioremap (so first example fro IO-mapping.txt -
> > - readl(0xC0000) - is wrong). On ia32, ioremap can return
> > virtual address and readl/writel are simple reading/writting (no
> > playing with PAGE_OFFSET), on alpha, ioremap can return bus
> > address and readl/writel are complicated function as they are
> > now.
> I suggest an ioaddr_t abstraction. Then whatever representation is best
> can be used, and it will help us find the places in drivers that need
> changing.
OK.
> > f) it must be done before 2.2, because of otherwise it is not possible
> > to have more than 1.8 GB of memory in an Intel box (you can have
> > it... but you cannot use it as system memory) (I know that no one
> > real user uses ia32 this time, but there are such)
> No way. 2.2 must be released this year!
Yes...
> 2GB+ is not _that_ important that it's worth delaying the other X million
> users.
Then comments containing 2GB or 0x70000000 in include/asm-i386/page.h should
be changed to 1.9GB resp. 0x80000000. It is safe... If you boot with
mem=2000M
> A relatively simple change that may make it work, if you stick to known
> ok drivers, is +PAGE_OFFSET instead of |PAGE_OFFSET where that is
> written. (And its inverse). That can't go into the mainstream kernel
> yet though because it will break some drivers even with <2GB.
This does not work at all! If address goes through ioremap(), it must
not be modified (on ia32). There is only one correct way for ia32:
#define __io_virt(x) (void*)(((unsigned long)(x) >= PAGE_OFFSET)?:((unsigned long)(x) + PAGE_OFFSET))
But it is a bit slow and contains conditional jump :-( You can arange
code right way to help ia32 jump prediction, but...
> Don't worry about not squeezing in your most desired feature at this
> stage. Get into the habit of helping releases out the door, so that 2.4
> won't take too long and will have your favourite features.
I'm helping best I can do ;-) This whole problem is because of I want
to be "crossplatform" and I want to use "highest" abstraction level
as possible.
> > So unless someone has more correct solution (please, please), I have to use
> > #ifdef __alpha__
> > #define mga_readl(x) readl(x)
> > #else
> > #define mga_readl(x) (*(volatile u_int32_t*)(x))
> > #endif
Philip Blundell wrote something like:
> Can you switch matrox to little endian mode?
Yes I can, but in this case, you cannot use PPC XFree for Matrox (accessing
/dev/mem does not swap bytes, so there was no idea, why not use nice hardware
features of chip (chip can do two htons in parallel on 32-bit data if you
are accessing fb with 16bit color depth... so it is at least twice faster
than writting words instead of dwords) (because of PCI bridge will not
(must not?) merge them together).
and also:
> Why #ifdef __alpha__, why not #ifndef __ppc__ ?
And Jammie continues:
> The PPC case is the anomaly isn't it? readl() should work fine on most
> things.
> You could check for PPC and include a #warning, so it will get fixed
> when it is possible as well as getting the PPC folks to think about the
> issue.
It is (as Jakub said) also case on sparcs... On ia32, it does not work
for 2GB... So __alpha__s and __arm__s left :-( I'll add __arm__...
(I'm not complaining, I can live with this. I hope Linus so. Wrote down
for 2.3 tasklist).
> Try my suggestion (+PAGE_OFFSET, -PAGE_OFFSET instead of |PAGE_OFFSET
> and &~PAGE_OFFSET). A few people have noted it. Note that some drivers
> that work with <2GB will break.
Every correct driver will break! Drivers which do not break must be fixed
(by using ioremap) to break :-)
> > P.P.S.: For Dave and/or Jakub (and others): On __sparc__, __sparc64__
> > (one PCI sparc is probably coming here next year) and other non-listed
> > ports (__m68k__), what is better, safe and working -
> > (*(volatile u_int32_t*)(x)) or readl(x) ?
> Use readl() until told otherwise, because that's documented. Or refuse
> to compile (#error) except on architectures you know about if you're paranoid.
Never-ever #error... PPC is one of my primary targets...

Philip Blundell also wrote:
> You should never use memcpy if you want particular memory access size...
We are talking about graphics device... There are tons of data to be moved
to/from display. Currently I'm able to draw 850K chars per second (8x16
character cell, 8bpp). It is problematic without PCI burst mode
(14MBps character data + 17MBps accelerator commands = 31MBps). And some
hardware can initiate bursts only from memcpy :-(
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz

P.S.: Excuse my late reply, but there was night here.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.043 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site