"Richard B. Johnson" wrote:
> On Fri, 3 Nov 2000, Jeff Garzik wrote:
> > "Richard B. Johnson" wrote:
> > > (3) With the new kernel, I can't access screen memory anymore. When
> > > testing software drivers for hardware that I don't have, I usually use
> > > the screen-regen buffer to emulate the shared memory window.
> > >
> > > Here is a snippet of code:
> > >
> > > // info->mem = 0xb8000 what they actually are
> > > // info->mem_len = 0x4000
> > >
> > > if((info->vxi_iomem = ioremap(info->mem, info->mem_len)) == NULL)
> > > {
> > > printk(KERN_ALERT "%s: Can't allocate shared memory\n", devname);
> > > (void)unregister_chrdev(info->major, info->dev);
> > > kfree(info->tmp_buf);
> > > kfree(info);
> > > return -ENOMEM;
> > > }
> > > info->vxi_base = (UNIV *) bus_to_virt(UL info->vxi_iomem);
> > > ||||||||||||||
> > > This pointer should point to the beginning of the screen buffer.
> > > It always has before.
> > >
> > > When accessing this from a module, I get;
> > > Unable to handle kernel paging requist at virtual address 800b8304.
> >
> > bug 1) ioremap returns a cookie, not a bus address. therefore, calling
> > ioremap output to bus_to_virt is incorrect.
> >
>
> So explain?? What do you mean a cookie?
ioremap returns a value that ideally should only be passed on to other
MMIO functions: iounmap, readb, readw, readl, writeb, writew, writel,
memcpy_toio, memcpy_fromio, etc.
Think of ioremap as returning a token which can be passed back into the
above list of functions. You should never dereference ioremap'd memory
directly...
> > bug 2) what are you doing with vxi_base? I don't have the rest of your
> > code here, but I'm willing to bet that you are directly de-referencing
> > memory, instead of using {read,write}[bwl] / memcpy_{to,from}io. Read
> > linux/Documentation/IO-mapping.txt for more info.
> >
>
> Nope. It's copied, using memcpy_to/from_io, into a kmalloc()ed buffer.
As long as you are passing ioremap'd address to memcpy_to/from_io,
that's ok.
> However, there is a section, of 0x800 dwords that are accessed as
> registers (directly).
>
> This will be a real bitch, if necessary, with the real device because
> I have to reference 0x800 dwords as device registers.
> And if I can't do that, I am totally screwed, and will have to stay
> with a version that allows it. I can just imagine code that references
> these registers using an obscure macro. It just won't be maintainable
> and I don't intend to live with the code for the product lifetime.
Well, ioremap returns a virtual address, which is directly accessible to
the local CPU. Maybe (as a hack) you can completely ignore what I said
above, and directly de-reference the ioremap'd memory. ie. eliminate
info->vxi_base altogether.
But if you are going to eliminate info->vxi_base, it seems like that
would flush out all direct de-refs, whether they are buried in an
obscure macro or not. And if you find all that crap, you might as well
use readb/writel at that point...
info->registers[0x7FF] = newvalue;
becomes
writel(newvalue, &info->registers[0x7FF]);
and
regval = info->registers[0x7FF];
becomes
regval = readl(&info->registers[0x7FF]);
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft | -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
