w100 fb driver

w100 fb driver

[Richard Purdie]

I've been working on creating support for the Sharp SL-C7xx series as part 
of a wider effort to create support for the whole Zaurus range of PDAs under 
linux 2.6. The C7xx's contain the ATI w100 video chip which doesn't have 
mainstream kernel support at present.

Sharp did release a driver against 2.4.18 and I've ported this across to the 
2.6 series. I've also made some fairly large changes to the driver to tidy 
it up and create support for certain video modes Sharp never enabled.

I'd like to discuss whether it'd be possible to include this driver in a 
future kernel? The driver is available at: 
http://www.rpsys.net/openzaurus/w100-r1.patch .

I'm aware the corgi_backlight file included above is out of place and it 
will be moved into the arch/arm/mach-pxa folder. I'm also aware some fb 
changes made in 2.6.10-rc2 need to be applied to this file. Are there any 
other problems with the driver as it stands that would prevent its 
inclusion, or areas in the driver that it would be advisable to 
change/improve?

If the driver would be acceptable, what method of submission is preferred? 
(the sourceforge pages seem inactive)

Thanks,

Richard



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: w100 fb driver

[Antonino A. Daplas]

On Saturday 20 November 2004 00:51, Richard Purdie wrote:
> I've been working on creating support for the Sharp SL-C7xx series as part
> of a wider effort to create support for the whole Zaurus range of PDAs
> under linux 2.6. The C7xx's contain the ATI w100 video chip which doesn't
> have mainstream kernel support at present.
>
> Sharp did release a driver against 2.4.18 and I've ported this across to
> the 2.6 series. I've also made some fairly large changes to the driver to
> tidy it up and create support for certain video modes Sharp never enabled.
>
> I'd like to discuss whether it'd be possible to include this driver in a
> future kernel? The driver is available at:
> http://www.rpsys.net/openzaurus/w100-r1.patch .
>
> I'm aware the corgi_backlight file included above is out of place and it
> will be moved into the arch/arm/mach-pxa folder. I'm also aware some fb
> changes made in 2.6.10-rc2 need to be applied to this file. Are there any

Not much, but you may need to insert this before initialization:

if (fb_get_options("w100fb", NULL))
	return -ENODEV;

> other problems with the driver as it stands that would prevent its
> inclusion, or areas in the driver that it would be advisable to
> change/improve?

Should be okay, just wondering why not use the kernel i2c algo's instead of
using your own.

Can't comment on backlight support as I don't know a thing about that.

Preferrably, comments should be enclosed in /* */, rather than //

>
> If the driver would be acceptable, what method of submission is preferred?
> (the sourceforge pages seem inactive)

Submit patch inline to this list and CC me.  Preferrably break the patch
down into several, hopefully standalone patches.  Add a changelog, and a
signed-off line.

Referring you to this link on patch submission:

http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

Tony





-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: w100 fb driver

[Richard Purdie]

Antonino A. Daplas:
[re: inclusion of the w100 driver in the kernel]
> Should be okay, just wondering why not use the kernel i2c algo's instead
> of using your own.

The kernel's i2c algo's require two way communication and expect the data to
be ack'ed. In this case, we have no way to read the data back from the spp
interface so we can't implement all the functions the kernel interface would
need.

> Submit patch inline to this list and CC me.  Preferrably break the patch
> down into several, hopefully standalone patches.  Add a changelog, and a
> signed-off line.

That sounds fine. I've taken your comments (and those made by Geert 
Uytterhoeven) onboard and revised the driver. For various reasons, I've 
moved the driver over the to new device structure which allows me to pass a 
structure with some hardware specific details to the driver. This means I 
need to include the header file elsewhere in the kernel. Should/can I move 
that file to drivers/video in whole or in part (or do something else)?

An updated version of the driver is at:

http://www.rpsys.net/openzaurus/arm/w100-r1.patch

(its using two header files until I know which approach is preferred)

Thanks,

Richard 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: w100 fb driver

[Antonino A. Daplas]

On Thursday 25 November 2004 23:19, Richard Purdie wrote:
> Antonino A. Daplas:
> [re: inclusion of the w100 driver in the kernel]
>
> > Should be okay, just wondering why not use the kernel i2c algo's instead
> > of using your own.
>
> The kernel's i2c algo's require two way communication and expect the data
> to be ack'ed. In this case, we have no way to read the data back from the
> spp interface so we can't implement all the functions the kernel interface
> would need.
>
> > Submit patch inline to this list and CC me.  Preferrably break the patch
> > down into several, hopefully standalone patches.  Add a changelog, and a
> > signed-off line.
>
> That sounds fine. I've taken your comments (and those made by Geert
> Uytterhoeven) onboard and revised the driver. For various reasons, I've
> moved the driver over the to new device structure which allows me to pass a
> structure with some hardware specific details to the driver. This means I
> need to include the header file elsewhere in the kernel. Should/can I move
> that file to drivers/video in whole or in part (or do something else)?

The current placement is fine.

Place things that are used or have the potential to be used by other kernel
subsystems in include/video (ie register definitions) and those that should
be private to the driver in include/video.

>
> An updated version of the driver is at:
>
> http://www.rpsys.net/openzaurus/arm/w100-r1.patch
>
> (its using two header files until I know which approach is preferred)

Nothing wrong with using 2 headers.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: w100 fb driver

[Geert Uytterhoeven]

On Fri, 19 Nov 2004, Richard Purdie wrote:
> made in 2.6.10-rc2 need to be applied to this file. Are there any other
> problems with the driver as it stands that would prevent its inclusion, or
> areas in the driver that it would be advisable to change/improve?

Can you please match the implementation of w100fb_check_var() with its comments
(`If a value doesn't fit, round it up, if it's too big, return -EINVAL.')?

And some more C99-style initializers never hurt.

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


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8