From: Adrian Cox <hidden> Date: 2000-06-16 09:31:15
I've just ported the chips driver in 2.2 to the 69030 (now Asiliant, was
Intel, was C&T). I've found that writing to the frame buffer device
fails, because the underlying method in fbmem.c uses copy_from_user(),
and on PowerPC copy_from_user() cannot copy into uncached space.
Which do people think is wrong:
Is copy_from_user() on PPC wrong, because it can't write to uncached
space.
Is fbmem.c wrong, because it tries to use copy_from_user() to memory
mapped IO?
- Adrian Cox, AG Electronics
ps. On the 7400 this is fairly academic, as writing sequentially to a
cache line allocates it without the need for dcbz.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
I've just ported the chips driver in 2.2 to the 69030 (now Asiliant, was
Intel, was C&T). I've found that writing to the frame buffer device
fails, because the underlying method in fbmem.c uses copy_from_user(),
and on PowerPC copy_from_user() cannot copy into uncached space.
Which do people think is wrong:
Is copy_from_user() on PPC wrong, because it can't write to uncached
space.
Is fbmem.c wrong, because it tries to use copy_from_user() to memory
mapped IO?
Congratulations! You found a bug in fbmem.c! Fbmem.c should not use direct
memory accesses to access the frame buffer, but must use fb_writel() and
friends instead.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: James Simmons <hidden> Date: 2000-06-16 14:04:22
quoted
Which do people think is wrong:
Is copy_from_user() on PPC wrong, because it can't write to uncached
space.
Is fbmem.c wrong, because it tries to use copy_from_user() to memory
mapped IO?
Congratulations! You found a bug in fbmem.c! Fbmem.c should not use direct
memory accesses to access the frame buffer, but must use fb_writel() and
friends instead.
Let me guess, fb_write and fb_read. I have seen problems also with using
memset on a mmap framebuffer on the PPC. Geert I like to suggest we move
fb_write, fb_read, and fb_memset to fb.h so userland apps can use them.
Also I have though about having generic functions for register access
based on what is in atyfb.c for userland to use as well. Something like.
static inline u32 ld_le32(unsigned int regindex, struct fb_info *info);
etc.
Actually this problem is more general. We really should have a generic
access MMIO region function. I believe some sound cards can be mmapped as
well.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Thomas H?henleitner <hidden> Date: 2000-06-19 10:15:23
The driver works now quite well with my hw.
Check the ctfb_README for limits and features.
What about a merge with the old chipsfb.o?
Dounload dir: www.visuelle.maschinen.de/ctfb/
Thomas
(I am not a member of LinuxPPC-Dev [off-list ref] mailing
list, please reply thru Linux Frame Buffer Device Development
[off-list ref] or directly)
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Adrian Cox <hidden> Date: 2000-06-19 11:11:43
Thomas Hhenleitner wrote:
The driver works now quite well with my hw.
Check the ctfb_README for limits and features.
What about a merge with the old chipsfb.o?
I'm working on my 69030 driver as a separate driver currently, because
of the requirement to use memory mapped IO and avoid all fixed IO
addresses, which makes it incompatible with the 65550. I did look at
your driver, but I decided to base mine on the existing chipsfb.c
because I needed PowerPC support, and because the coding style of your
driver was quite different to existing frame buffer drivers.
My priorities are:
1) Not assume any BIOS setup, as BIOS setup only occurs on x86 hosts,
and only on the primary display.
2) Avoid use of the big-endian region in the chip, while still
supporting big-endian hosts. This is necessary to support the
twin-pipeline mode of the 69030 in future.
3) Support multiple displays. This requires use of memory mapping.
- Adrian Cox, AG Electronics
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
s/visuelle.maschinen/visuelle-maschinen/ (from looking at the email address)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Thomas H?henleitner <hidden> Date: 2000-06-19 17:31:06
Am Mon, 19 Jun 2000 schrieb Adrian Cox:
Thomas Hhenleitner wrote:
quoted
The driver works now quite well with my hw.
Check the ctfb_README for limits and features.
What about a merge with the old chipsfb.o?
I'm working on my 69030 driver as a separate driver currently, because
of the requirement to use memory mapped IO and avoid all fixed IO
addresses, which makes it incompatible with the 65550. I did look at
your driver, but I decided to base mine on the existing chipsfb.c
because I needed PowerPC support, and because the coding style of your
driver was quite different to existing frame buffer drivers.
My priorities are:
1) Not assume any BIOS setup, as BIOS setup only occurs on x86 hosts,
and only on the primary display.
2) Avoid use of the big-endian region in the chip, while still
supporting big-endian hosts. This is necessary to support the
twin-pipeline mode of the 69030 in future.
3) Support multiple displays. This requires use of memory mapping.
- Adrian Cox, AG Electronics
Where can I get the source of your driver to have a look at it?
Is the CT69030 availiable? The last I heard about it was, that it was cacelled.
Thomas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Thomas H?henleitner <hidden> Date: 2000-06-20 09:03:42
Am Mon, 19 Jun 2000 schrieb James Simmons:
I got it now thanks to Geert. You have alot of files for ctfb.
It's a matter of taste. A file overview is in ctfb_README. And no big deal to
merge them into one monolitc block if it should go into the kernel sources.
By the way I have here a question:
If we have several submodules as parts of a framebuffer we have some symbols
within the namespace of this framebuffer. When we compile it as a separate
module for modprobe there is no problem. But when we compile it as part of the
kernel these frambuffer specific symbols are polluting the kernel namespace. Is
there an elegant way to make the framebuffer specific symbols invisible for the
kernel after we have our xxxfb.o?
Thomas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: James Simmons <hidden> Date: 2000-06-20 23:40:32
If we have several submodules as parts of a framebuffer we have some symbols
within the namespace of this framebuffer. When we compile it as a separate
module for modprobe there is no problem. But when we compile it as part of the
kernel these frambuffer specific symbols are polluting the kernel namespace. Is
there an elegant way to make the framebuffer specific symbols invisible for the
kernel after we have our xxxfb.o?
Hum? I don't know. Anyone? I usually don't think about namespace
pollution. I just makes sure I bizarre names so they don't conflict with
anything else.
Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.
James Simmons [jsimmons@linux-fbdev.org] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/