New Linux Drivers - Configure question

New Linux Drivers - Configure question

[Modular Forms Boy]

I am working on a new framebuffer driver for an LCD controller that's
custom to the PowerPC embedded world.  As such, it's architecture
dependent.  Where should I place the driver in the tree, and how should I
set up the proper Configure options?  Where do I put checks for #ifdef
CONFIGURE_blah_blah_blah?

Yours truly,
David Eger

Re: New Linux Drivers - Configure question

[Chakir Ettayebi]

yes 


On Mon, 18 Jun 2001, Modular Forms Boy wrote:

> 
> I am working on a new framebuffer driver for an LCD controller that's
> custom to the PowerPC embedded world.  As such, it's architecture
> dependent.  Where should I place the driver in the tree, and how should I
> set up the proper Configure options?  Where do I put checks for #ifdef
> CONFIGURE_blah_blah_blah?
> 
> Yours truly,
> David Eger
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: New Linux Drivers - Configure question

[James Simmons]

> I am working on a new framebuffer driver for an LCD controller that's
> custom to the PowerPC embedded world.  As such, it's architecture
> dependent.  Where should I place the driver in the tree, and how should I
> set up the proper Configure options?  Where do I put checks for #ifdef
> CONFIGURE_blah_blah_blah?

Hi!

   You would place it in drivers/video. If you look at the Config.in
file in the linux/drivers/video directory you will see 

if [ "$CONFIG_PPC" = "y" ]; then
 bool '  Open Firmware frame buffer device support' CONFIG_FB_OF
 ...
fi

Just add you driver in that section. Also you have to alter fbmem.c. You
need to add something like 

extern int xxxmydriverfb_init(void);
extern int xxxmydriverfb_setup(char*);

and further down in the file. 

#ifdef CONFIG_FB_MYDRIVER
        { "myfbdriver", xxxmydriverfb_init, xxxmydriverfb_setup },
#endif

When you look at this file you will see what I mean. If you have any
further questions just go to http://www.linux-fbdev.org. In this email you
will see the address for our mailing list. On our web site it gives you
info about joining the mailing list.

readl() / writel() on PowerPC

[David T Eger]

I have been working on a driver for a PowerPC PCI card/framebuffer device,
and noticed that the standard readl() and writel() for this platform to
byte swapping, since PowerPC runs big-endian.  However, at least for my
hardware it's *really* not needed, and should just do a regular load
store, as is done for CONFIG_APUS.  Looking at another driver
(drivers/char/bttv.h) I notice that Mr. Metzler redefines his read and
write routines for PowerPC as well to do simple loads and stores to IO
regions.

Am I missing something?  Is there some reason that readl() and
writel() should byte-swap by default?

Re: readl() / writel() on PowerPC

[David Schleef]

On Mon, Jul 02, 2001 at 08:22:55PM -0400, David T Eger wrote:
> 
> I have been working on a driver for a PowerPC PCI card/framebuffer device,
> and noticed that the standard readl() and writel() for this platform to
> byte swapping, since PowerPC runs big-endian.  However, at least for my
> hardware it's *really* not needed, and should just do a regular load
> store, as is done for CONFIG_APUS.  Looking at another driver
> (drivers/char/bttv.h) I notice that Mr. Metzler redefines his read and
> write routines for PowerPC as well to do simple loads and stores to IO
> regions.


I believe you are looking for __raw_readl(), __raw_writel().



dave...

Re: readl() / writel() on PowerPC

[James Simmons]

> I have been working on a driver for a PowerPC PCI card/framebuffer device,
> and noticed that the standard readl() and writel() for this platform to
> byte swapping, since PowerPC runs big-endian.  However, at least for my
> hardware it's *really* not needed, and should just do a regular load
> store, as is done for CONFIG_APUS.  Looking at another driver
> (drivers/char/bttv.h) I notice that Mr. Metzler redefines his read and
> write routines for PowerPC as well to do simple loads and stores to IO
> regions.
> 
> Am I missing something?  Is there some reason that readl() and
> writel() should byte-swap by default?

Use the fb_writeX/fb_readX functions in fbcon.h. They take care of these
issues.

P.S
   Watchout for userland programs. You can NOT use memset on the
framebuffer on PPC due to caching issues. Use have to use tricks similar
to what is done in fbcon.h with fb_memset.
   

Re: readl() / writel() on PowerPC

[Paul Mackerras]

David T Eger writes:

> Am I missing something?  Is there some reason that readl() and
> writel() should byte-swap by default?

readl()/writel() are defined to access PCI memory space in units of 32
bits.  PCI is by definition little-endian, PowerPC is (natively at
least) big-endian, hence the byte-swap.  Same for inl/outl etc., but
not insl/outsl - they don't swap because they are typically used for
transferring arrays of bytes, just doing it 4 bytes at a time (2 at a
time for insw/outsw).

You can use __raw_readl/__raw_writel if you don't want byte-swapping,
but they also don't give you any barriers.  Thus if you do

	__raw_writel(v, addr);
	x = __raw_readl(addr);

it is quite possible for the read to hit the device before the write.
If you want to prevent that you need to put an iobarrier_rw() call in
between the read and the write.  You don't need a barrier between
successive writes unless you want to prevent any potential
store-gathering from happening, because PowerPC's don't reorder writes
to I/O regions.

Paul.