copy_from_user in drivers/video/fbmem.c

copy_from_user in drivers/video/fbmem.c

[Adrian Cox]

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/

Re: copy_from_user in drivers/video/fbmem.c

[Geert Uytterhoeven]

On Fri, 16 Jun 2000, Adrian Cox wrote:
> 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/

Re: [linux-fbdev] Re: copy_from_user in drivers/video/fbmem.c

[James Simmons]

> > 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/

CTFB 0.30 now availiable (CT65554...CT69000)

[Thomas H?henleitner]

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 <linuxppc-dev@lists.linuxppc.org> mailing
list, please reply thru Linux Frame Buffer Device Development
<linux-fbdev@vuser.vu.union.edu>  or directly)

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CTFB 0.30 now availiable (CT65554...CT69000)

[Adrian Cox]

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/

Re: [linux-fbdev] CTFB 0.30 now availiable (CT65554...CT69000)

[James Simmons]

> Dounload dir: www.visuelle.maschinen.de/ctfb/

Check your server. I couldn't contact it.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] CTFB 0.30 now availiable (CT65554...CT69000)

[Geert Uytterhoeven]

On Mon, 19 Jun 2000, James Simmons wrote:
> > Dounload dir: www.visuelle.maschinen.de/ctfb/
>
> Check your server. I couldn't contact it.

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/

Re: [linux-fbdev] CTFB 0.30 now availiable (CT65554...CT69000)

[James Simmons]

> On Mon, 19 Jun 2000, James Simmons wrote:
> > > Dounload dir: www.visuelle.maschinen.de/ctfb/
> >
> > Check your server. I couldn't contact it.
>
> s/visuelle.maschinen/visuelle-maschinen/ (from looking at the email address)

Yep. Its worked :-)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] CTFB 0.30 now availiable (CT65554...CT69000)

[Thomas H?henleitner]

Am Mon, 19 Jun 2000 schrieb Geert Uytterhoeven:
> On Mon, 19 Jun 2000, James Simmons wrote:
> > > Dounload dir: www.visuelle.maschinen.de/ctfb/
> >
> > Check your server. I couldn't contact it.
>
> s/visuelle.maschinen/visuelle-maschinen/ (from looking at the email address)
>

Pleas try again. May be the server was down. Adrian Cox could get it.
I just did

wget http://www.visuelle-maschinen.de/ctfb/ctfb0.30.tgz
wget http://www.visuelle-maschinen.de/ctfb/ctfb_addons0.30.tgz

successfully. If you still have trouble I'll send it to you directly.

Thomas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CTFB 0.30 now availiable (CT65554...CT69000)

[Thomas H?henleitner]

Am Mon, 19 Jun 2000 schrieb Adrian Cox:
> 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

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/

Re: [linux-fbdev] CTFB 0.30 now availiable (CT65554...CT69000)

[James Simmons]

> Pleas try again. May be the server was down. Adrian Cox could get it.
> I just did
>
> wget http://www.visuelle-maschinen.de/ctfb/ctfb0.30.tgz
> wget http://www.visuelle-maschinen.de/ctfb/ctfb_addons0.30.tgz
>
> successfully. If you still have trouble I'll send it to you directly.

I got it now thanks to Geert. You have alot of files for ctfb.

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/

name space pollution Was Re: [linux-fbdev] CTFB 0.30 now availiable (CT65554...CT69000)

[Thomas H?henleitner]

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/

Re: name space pollution Was Re: [linux-fbdev] CTFB 0.30 now availiable (CT65554...CT69000)

[James Simmons]

> 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/