OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: jcabrer on October 28, 2005, 03:22:58 pm
-
I just had a peek at the changelog for Linux kernel 2.6.14. Here is the condensed version for anyone interested in the Zaurus-specific changes:
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 13 01:25:35 2005 -0700
[PATCH] SharpSL: Add an input keyboard driver for Zaurus cxx00 series
Add a input driver for the keyboard found on the Zaurus Cxx00 series (Spitz,
Akita, Borzoi). Its based on corgikbd but there are enough subtle differences
to justify a separate driver.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 13 01:25:34 2005 -0700
[PATCH] SharpSL: Add new ARM PXA machines Spitz and Borzoi with partial Akita Support
Add the platform support code for two new Sharp Zaurus Models, Spitz
(SL-C3000) and Borzoi (SL-C3100).
This patch also adds most of the foundations for Akita (SL-C1000) Support.
The missing link for Akita is the driver for its I2C io expander. Once this
has been finished, the missing Kconfig option and machine declaration can
easily be added to this code.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 13 01:25:33 2005 -0700
[PATCH] SharpSL: Abstract model specifics from Corgi Backlight driver
Separate out the Sharp Zaurus c7x0 series specific code from the Corgi
backlight driver. Abstract model/machine specific functions to corgi_lcd.c
via sharpsl.h
This enables the driver to be used by the Zaurus cxx00 series.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 13 01:25:33 2005 -0700
[PATCH] SharpSL: Abstract c7x0 specifics from Corgi Touchscreen driver
Separate out the Sharp Zaurus c7x0 series specific code from the Corgi
Touchscreen driver. Use the new functions in corgi_lcd.c via sharpsl.h for
hsync handling and pass the IRQ as a platform device resource. Move a
function prototype into the w100fb header file where it belongs.
This enables the driver to be used by the Zaurus cxx00 series.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 13 01:25:32 2005 -0700
[PATCH] SharpSL: Add cxx00 support to the Corgi LCD driver
The same LCD is present on both the Sharp Zaurus c7x0 series and the cxx00 but
with different framebuffer drivers (w100fb vs. pxafb). This patch adds
support for the cxx00 series to the LCD driver. It also adds some LCD to
touchscreen interface logic needed by the touchscreen driver to prevent
interference problems, the idea being to keep all the ugly code in one place
leaving the drivers themselves clean. sharpsl.h is used to provide the
abstraction.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 13 01:25:30 2005 -0700
[PATCH] SharpSL: Abstract c7x0 specifics from Corgi SSP
Sharp's newer range of Zaurus clamshell handhelds, the cxx00's are similar to
the c7x0 series yet different. This patch series abstracts the differences
and generates a set of common drivers that support both series of devices. It
then adds machine support for Spitz (SL-C3000) and Borzoi (SL-C3100). Hooks
for Akita (SL-C1000) differences are also added. The I2C driver for its IO
expander is the only missing piece.
This patch:
Separate out the Sharp Zaurus c7x0 series specific code from corgi_ssp.c so
that other models such as the cxx00's can share it. Create sharpsl.h which
will be used to abstract machine/model specifics.
This enables the driver to be used by the Zaurus cxx00 series.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Fri Sep 9 13:10:03 2005 -0700
[PATCH] pxafb: Add hsync time reporting hook
To solve touchscreen interference problems devices like the Sharp Zaurus
SL-C3000 need to know the length of the horitzontal sync pulses. This patch
adds a hook to pxafb so the touchscreen driver can function correctly.
Author: David Brownell <david-b@pacbell.net>
Date: Wed Aug 31 09:54:20 2005 -0700
[PATCH] USB: usbnet (7/9) module for CDC Ethernet
Makes the CDC Ethernet support live in a separate driver module.
This module is a bit special since it exports utility functions
that are reused by the the Zaurus and RNDIS drivers, but it's
not "core" like usbnet itself.
Author: David Brownell <david-b@pacbell.net>
Date: Wed Aug 31 09:52:45 2005 -0700
[PATCH] USB: usbnet (2/9) module for simple network links
This patch creates the first of several separate "minidriver" modules
for "usbnet". This one handles only the very simplest hardware, which
can be handled almost entirely by the "usbnet" core.
- Move device-specific bits into new "cdc_subset.c" driver,
shrinking "usbnet" by a bunch;
- Export the functions needed to support this minidriver
(with EXPORT_SYMBOL_GPL);
- Update Kconfig and kbuild accordingly.
This one handles about a dozen different device types, with the most
notable ones being Gumstix and most Linux-based PDAs (except Zaurus
running that ancient code from Sharp).
Author: David Brownell <david-b@pacbell.net>
Date: Wed Aug 31 09:52:31 2005 -0700
[PATCH] USB: usbnet (1/9) clean up framing
This starts to prepare the core of "usbnet" to know less about various
framing protocols that map Ethernet packets onto USB, so "minidrivers"
can be modules that just plug into the core.
- Remove some framing-specific code that cluttered the core:
* net->hard_header_len records how much space to preallocate;
now drivers that add their own framing (Net1080, GeneLink,
Zaurus, and RNDIS) will have smoother TX paths. Even for
the drivers (Zaurus, Net1080) that need trailers.
* defines new dev->hard_mtu, using this "hardware" limit to
check changes to the link's settable "software" mtu.
* now net->hard_header_len and dev->hard_mtu are set up in the
driver bind() routines, if needed.
- Transaction ID is no longer specific to the Net1080 framing;
RNDIS needs one too.
- Creates a new "usbnet.h" header with declarations that are shared
between the core and what will be separate modules.
- Plus a couple other minor tweaks, like recognizing -ESHUTDOWN
means the keventd work should just shut itself down asap.
The core code is only about 1/3 of this large file. Splitting out the
minidrivers into separate modules (e.g. ones for ASIX adapters,
Zaurii and similar, CDC Ethernet, etc), in later patches, will
improve maintainability and shrink typical runtime footprints.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 6 15:19:03 2005 -0700
[PATCH] w100fb: Rewrite for platform independence
The code w100fb was based on was horribly Sharp SL-C7x0 specific and there
was little else that could be done as I had no access to anything else with
a w100 in it. There is no real documentation about this chipset available.
Ian Molton has access to other platforms with the w100 (Toshiba e-series)
and so between us, we've improved w100fb and made it platform independent.
Ian Molton also added support for the very similar w3220 and w3200
chipsets.
There are a lot of changes here and it nearly amounts to a rewrite of the
driver but it has been extensively tested and is being used in preference
to the original driver in the Zaurus community. I'd therefore like to
update the mainline code to reflect this.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 6 15:19:02 2005 -0700
[PATCH] Corgi touchscreen: Fix a pmu bug
Corgi Touchscreen bugfix. If the PMU isn't running, the register needs to
be set to a sane value rather than reusing some random value.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 6 15:19:02 2005 -0700
[PATCH] Corgi Touchscreen: Code cleanup / fixes
Clean up some Corgi Touchscreen logic and merge the repeat calls to
w100fb_blanking() in anticipation of the w100fb patch.
Fix a pm_message_t reference.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 6 15:19:01 2005 -0700
[PATCH] Corgi Touchscreen: Allow the driver to share the PMU
The Corgi Touchscreen driver uses the PMU as an accurate timing source which
conflicts with its usage for performance monitoring. This patch allows it to
be shared with other users such as oprofile.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 6 15:19:00 2005 -0700
[PATCH] Corgi Keyboard: Code tidying
The input system handles key state tracking so there's no need for the driver
to do so as well. Also tidy up some comment formatting and remove a now
unneeded function.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 6 15:18:59 2005 -0700
[PATCH] Corgi Keyboard: Add some power management code
Add some power management code to the corgi keyboard driver so that only one
power event gets reported within any reasonable time frame and the driver
doesn't enter an infinte loop due to key repeat.
Author: Richard Purdie <rpurdie@rpsys.net>
Date: Tue Sep 6 15:18:59 2005 -0700
[PATCH] Corgi Keyboard: Fix a couple of compile errors
Fix a couple of compile errors in the corgi keyboard driver.
Author: Pavel Machek <pavel@ucw.cz>
Date: Tue Sep 6 15:16:45 2005 -0700
[PATCH] Support powering sharp zaurus sl-5500 LCD up and down
This adds support for powering Zaurus's video up and down. PDA without
screen is kind of useless, so it is quite important... I'll have to figure
out how to really control the frontlight, because LCD without that is quite
hard to read.
-
There's a lot about touch screens in there. My 860 touch screen is mis-calibrated towards the top right. I thought it was faulty hardware but could it be something to do with a duff touch screen driver?
Oh, and why call these machines by names of dogs and things? What could be more confusing, when you can just refer to the device by the mode number printed on it?
-
Oh, and why call these machines by names of dogs and things? What could be more confusing, when you can just refer to the device by the mode number printed on it?
I agree and we are trying to get rid of it in pdaXrom systems etc.
-
Oh, and why call these machines by names of dogs and things? What could be more confusing, when you can just refer to the device by the mode number printed on it?
That's Sharp's doing I'm afraid.
Si
-
Yes - thats Sharp names (look in /proc/cpuinfo for example).
In OE we united c700/750/760/860 into one c7x0 machine because they are nearly the same hardware-wise (basically they are two models: corgi (c700) and rest but this difference is small enough to let them all unify in 2.6 kernel).
-
And calling something that is clearly writable 'Read Only Memory' isn't confusing?
-
name is ok - i think this time is time for koen and hrw migration to progressive pdaXrom OS
-
sashz: I tried pdaX rc11 on my c760 and found twm not comfortable (matchbox-wm was missing).
Why I tried? wanted to look at pcmcia config files.
-
I tried pdaX rc11 on my c760 and found twm not comfortable (matchbox-wm was missing).
Strange, you are the first to report this. did you format the user partition?
btw, pdaxrom uses openbox and not matchbox-wm, it uses the matchbox panel and desktop.
-
Oh dear - look what I've started!
Thanks for explaining the origin of the doggies. It maybe gives me someone else to blame, but it doesn't solve the problem
-
And calling something that is clearly writable 'Read Only Memory' isn't confusing?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=101452\"][{POST_SNAPBACK}][/a][/div]
It might be a little unfortunate a term, but no, I don't think it's confusing. It quite clearly describes the part of the computer's memory which is not intended to be changed during operation. The fact that it is stuck on a chip which is writable under special circumstances is irrelevant, and objecting on these grounds is displaying nothing more than pedantry.
A PROM (remember those?), an EPROM or an EEPROM are clearly writeable, but are still considered to be read-only memories.
-
Strange, you are the first to report this. did you format the user partition?
No - I left /home/ as it was - as I wrote I flashed pdaX just for few files. Maybe some files left from GPE testing on my Z and that was thing which made twm appear... but why twm was at all included is weird for me.
-
And calling something that is clearly writable 'Read Only Memory' isn't confusing?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=101452\"][{POST_SNAPBACK}][/a][/div]
It might be a little unfortunate a term, but no, I don't think it's confusing. It quite clearly describes the part of the computer's memory which is not intended to be changed during operation. The fact that it is stuck on a chip which is writable under special circumstances is irrelevant, and objecting on these grounds is displaying nothing more than pedantry.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=101463\"][{POST_SNAPBACK}][/a][/div]
'Special conditions'? What 'special conditions'? If yo turn on your Z and do a 'echo "I am writable" > /writeable' (as root) it *is* going to succeed. jffs2 behaves like a normal filesystem and is writeable without 'special conditions', under normal circumstances, during normal operation. If it wasn't, you wouldn't be able to save your networking config for example.
Thank you for proving my point about it being confusing
If you still think I'm wrong, you really should start calling SD and CF card 'ROM' too, since those use the same NAND chips....
-
Going slightly off topic I'm afraid (sorry)
I fear that the word ROM has now entered the vernacular with regard to the Zaurus at least and that people will call what should be called something like 'flash image' - as it's an image which will be applied to the flash - a 'ROM'.
It's difficult in any case because people often talk about having a 'ROM' (for a game, etc.) when what they really mean is a ROM image.
I would like it if we all changed to using something a little more correct but I don't know what (if for no other reasons than that it will make it easier for newbies to understand, plus I'd like to keep using English properly . Any ideas? - flash image? I don't know - this can be confusing though depending on context as it's also a verb.
Si
-
I use "distro" when talking about Cacko "ROM", pdaXrom, OpenZaurus.
I use "image" when talking about "something which is going to be flashed into flash".
-
Hmmm. A pdax thread on kernel goodies (presumably 2.6) filled with OZ guys (who have 2.6 and likely something to say about it ) discoursing on language and reference. Very entertaining
But no useable 2.6 based Rom for my Tosa yet (sorry, I couldn't resist)
-
Koen - we all know your opinions... :-)
hrw - i agree - basically the pdaXrom word was choosen a long time ago and we kinda like it - it would be weird with pdaX or pdaXdistro.
Some day we might change our name but right now we are more focused on fixing things that what we should call our distro/rom/software blah.
-
Yes - if the worst thing pdaXrom's detractors can find to complain about is its name, then it can't be doing badly at all!
ROM = operating system might be rather quaint, but its meaning is pretty obvious to me. I'm a pretty good pedant myself but occasionally I like to listen to an expert.
-
But no useable 2.6 based Rom for my Tosa yet (sorry, I couldn't resist)
All it needs is more people testing & patching, etc. RP has done most/almost all of the work and he had a c7x0 machine therefore the support for this is the best.
Hmmm. A pdax thread on kernel goodies (presumably 2.6) filled with OZ guys (who have 2.6 and likely something to say about it ) discoursing on language and reference. Very entertaining
Yes, a bit random isn't it . If you do have questions about 2.6.x then I'm sure we'll be happy to answer them, I'm all for cross-pollination.
Si
-
I would like it if we all changed to using something a little more correct but I don't know what (if for no other reasons than that it will make it easier for newbies to understand, plus I'd like to keep using English properly .
[div align=\"right\"][a href=\"index.php?act=findpost&pid=101520\"][{POST_SNAPBACK}][/a][/div]
Using standard, and presumably correct, terminology and phraseology is one sure way of enabling all to understand exactly what is being referenced and/or discussed. Although someone new to, and presumably unfamiliar with, the subject matter may not initially fully comprehend, they are enabled to search and learn quickly and accurately using the standard terminology. Use of standard and correct terminology also goes a long way toward avoiding confusion when interactively seeking help from others such as via IRC, e-mail, or even forums such as these.
As much as I wish we would all use correct standard terminology, phraseology and nomenclature in all our technical discussions, I don't believe for even a moment that we will.
And now, we return you to our regularly-scheduled program, already in progress....
-
hrw - i agree - basically the pdaXrom word was choosen a long time ago and we kinda like it - it would be weird with pdaX or pdaXdistro.[div align=\"right\"][a href=\"index.php?act=findpost&pid=101531\"][{POST_SNAPBACK}][/a][/div]
But pdaXnandflashepromkernelimageandjffs2rootfilesystem has such a nice "ring" to it
-
hrw - i agree - basically the pdaXrom word was choosen a long time ago and we kinda like it - it would be weird with pdaX or pdaXdistro.[div align=\"right\"][a href=\"index.php?act=findpost&pid=101531\"][{POST_SNAPBACK}][/a][/div]
But pdaXnandflashepromkernelimageandjffs2rootfilesystem has such a nice "ring" to it
[div align=\"right\"][a href=\"index.php?act=findpost&pid=101662\"][{POST_SNAPBACK}][/a][/div]
that would be pmtXnandflashepromkernelimageandjffs2rootfilesystem
-
Hmmm. A pdax thread on kernel goodies (presumably 2.6) filled with OZ guys (who have 2.6 and likely something to say about it ) discoursing on language and reference. Very entertaining
But no useable 2.6 based Rom for my Tosa yet (sorry, I couldn't resist)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=101528\"][{POST_SNAPBACK}][/a][/div]
I really should have posted this elsewhere, but I spend all my time in the pdaXrom forum, and that's where I concentrate my efforts. As for how I feel about this getting so far off topic? Well, I feel badly, but not too bad