Apm_emulation and proper suspend
Greetings, I'm reworking a couple of apm drivers and for whatever reason it doesn't seem to update my /proc/apm_bios. I was under the impression that it should do that when apm_bios was catted? Currently I have a value that never change. I export my get_power_status.. function properly but doesn't seem to touch it. I noticed that Richard had the extern int (void..apm_get_power) (...) declare an extra time (once in apm-emulation.h and another inside sharpsl.c), is that needed? Also, is apm the "brains" behind the suspend/resume interactions? By that I mean, should suspend be initiated through apm functions in order to be proper? I've tried to find examples but the best source of suspend related code is Richards code on sharp machines. I've understod the proper way to suspend going from apm_request_suspend -> all devices suspend -> ready -> arch specific code -> off. Best wishes Kristoffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Apm_emulation and proper suspend
Greetings, I'm reworking a couple of apm drivers and for whatever reason it doesn't seem to update my /proc/apm_bios. I was under the impression that it should do that when apm_bios was catted? Currently I have a value that never change. I export my get_power_status.. function properly but doesn't seem to touch it. I noticed that Richard had the extern int (void..apm_get_power) (...) declare an extra time (once in apm-emulation.h and another inside sharpsl.c), is that needed? Also, is apm the brains behind the suspend/resume interactions? By that I mean, should suspend be initiated through apm functions in order to be proper? I've tried to find examples but the best source of suspend related code is Richards code on sharp machines. I've understod the proper way to suspend going from apm_request_suspend - all devices suspend - ready - arch specific code - off. Best wishes Kristoffer -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Current git very broken on the Dreamcast
On Sat, 16 Feb 2008 19:59:48 + Adrian McMenamin <[EMAIL PROTECTED]> wrote: > > On Sat, 2008-02-16 at 19:48 +, Adrian McMenamin wrote: > > On Sat, 2008-02-16 at 18:38 +, Adrian McMenamin wrote: > > > Will seek to bisect this, but I have just updated my sources to the > > > latest git and it is not booting at all on the Dreamcast. > > > > > > [EMAIL PROTECTED]:~/gdrom-dev$ git bisect good > > e036eaa681a17f71b64f6d9040fe60623919 is first bad commit > > commit e036eaa681a17f71b64f6d9040fe60623919 > > Author: Magnus Damm <[EMAIL PROTECTED]> > > Date: Thu Feb 14 13:52:43 2008 +0900 > > > > Reverting this commit *will* let my Dreamcast boot - can it be rolled > back pending further testing for a patch please? > Just had a look at the patch. If that patch made your dreamcast not boot then you had somekind of io_base that was used in in/out. Perhaps its better to adjust your PORT defines than work around the issue? > Adrian > > - > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Current git very broken on the Dreamcast
On Sat, 16 Feb 2008 19:59:48 + Adrian McMenamin <[EMAIL PROTECTED]> wrote: > > On Sat, 2008-02-16 at 19:48 +, Adrian McMenamin wrote: > > On Sat, 2008-02-16 at 18:38 +, Adrian McMenamin wrote: > > > Will seek to bisect this, but I have just updated my sources to the > > > latest git and it is not booting at all on the Dreamcast. > > > > > > [EMAIL PROTECTED]:~/gdrom-dev$ git bisect good > > e036eaa681a17f71b64f6d9040fe60623919 is first bad commit > > commit e036eaa681a17f71b64f6d9040fe60623919 > > Author: Magnus Damm <[EMAIL PROTECTED]> > > Date: Thu Feb 14 13:52:43 2008 +0900 > > > > Reverting this commit *will* let my Dreamcast boot - can it be rolled > back pending further testing for a patch please? Since you know the cause I'm sure Magnus will have some ideas about why it broke, so just hold on for him to reply. > > Adrian > > - > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Current git very broken on the Dreamcast
On Sat, 16 Feb 2008 18:38:00 + Adrian McMenamin <[EMAIL PROTECTED]> wrote: > Will seek to bisect this, but I have just updated my sources to the > latest git and it is not booting at all on the Dreamcast. > > With early printk on, I get nothing more than this before an instant > reboot: I haven't tested anything after 2.6.24 vanilla which works fine. A bisect sounds like a good idea since you got pretty much zero clues. > > [0.00] Linux version 2.6.25-rc2-10953-g52065cd > ([EMAIL PROTECTED]) (gcc version 3.4.6) #511 PREEMPT Sat Feb 16 18:31:43 > GMT 2008 > [0.00] console [sercon0] enabled > [0.00] Booting machvec: Sega Dreamcast > > > - > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Current git very broken on the Dreamcast
On Sat, 16 Feb 2008 18:38:00 + Adrian McMenamin [EMAIL PROTECTED] wrote: Will seek to bisect this, but I have just updated my sources to the latest git and it is not booting at all on the Dreamcast. With early printk on, I get nothing more than this before an instant reboot: I haven't tested anything after 2.6.24 vanilla which works fine. A bisect sounds like a good idea since you got pretty much zero clues. [0.00] Linux version 2.6.25-rc2-10953-g52065cd ([EMAIL PROTECTED]) (gcc version 3.4.6) #511 PREEMPT Sat Feb 16 18:31:43 GMT 2008 [0.00] console [sercon0] enabled [0.00] Booting machvec: Sega Dreamcast - To unsubscribe from this list: send the line unsubscribe linux-sh in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Current git very broken on the Dreamcast
On Sat, 16 Feb 2008 19:59:48 + Adrian McMenamin [EMAIL PROTECTED] wrote: On Sat, 2008-02-16 at 19:48 +, Adrian McMenamin wrote: On Sat, 2008-02-16 at 18:38 +, Adrian McMenamin wrote: Will seek to bisect this, but I have just updated my sources to the latest git and it is not booting at all on the Dreamcast. [EMAIL PROTECTED]:~/gdrom-dev$ git bisect good e036eaa681a17f71b64f6d9040fe60623919 is first bad commit commit e036eaa681a17f71b64f6d9040fe60623919 Author: Magnus Damm [EMAIL PROTECTED] Date: Thu Feb 14 13:52:43 2008 +0900 Reverting this commit *will* let my Dreamcast boot - can it be rolled back pending further testing for a patch please? Since you know the cause I'm sure Magnus will have some ideas about why it broke, so just hold on for him to reply. Adrian - To unsubscribe from this list: send the line unsubscribe linux-sh in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Current git very broken on the Dreamcast
On Sat, 16 Feb 2008 19:59:48 + Adrian McMenamin [EMAIL PROTECTED] wrote: On Sat, 2008-02-16 at 19:48 +, Adrian McMenamin wrote: On Sat, 2008-02-16 at 18:38 +, Adrian McMenamin wrote: Will seek to bisect this, but I have just updated my sources to the latest git and it is not booting at all on the Dreamcast. [EMAIL PROTECTED]:~/gdrom-dev$ git bisect good e036eaa681a17f71b64f6d9040fe60623919 is first bad commit commit e036eaa681a17f71b64f6d9040fe60623919 Author: Magnus Damm [EMAIL PROTECTED] Date: Thu Feb 14 13:52:43 2008 +0900 Reverting this commit *will* let my Dreamcast boot - can it be rolled back pending further testing for a patch please? Just had a look at the patch. If that patch made your dreamcast not boot then you had somekind of io_base that was used in in/out. Perhaps its better to adjust your PORT defines than work around the issue? Adrian - To unsubscribe from this list: send the line unsubscribe linux-sh in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
I made a mistake on the latest patch I sent,
if (IS_ERR(bllcd->lcd_device)) {
+ ret = PTR_ERR(bllcd->bl_device);
+ backlight_device_unregister(bllcd->bl_device);
+ printk(KERN_ERR "lcd :failed to register device\n");
+ kfree(bllcd);
+ return ret;
+ }
should ofcourse read
if (IS_ERR(bllcd->lcd_device)) {
+ ret = PTR_ERR(bllcd->lcd_device);
+ backlight_device_unregister(bllcd->bl_device);
+ printk(KERN_ERR "lcd :failed to register device\n");
+ kfree(bllcd);
+ return ret;
+ }
Its fixed now for me. Going to test that mdelay issue now.
On Wed, 6 Feb 2008 19:31:55 +
Russell King - ARM Linux <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 06, 2008 at 08:21:28PM +0100, Kristoffer Ericson wrote:
> > Oh, and thanks for all the feedback people! (and for doing it nicely)
>
> I'm afraid you missed one - and there's a better fix for one of the other
> points I made... 8)
>
> > +static int jornada_bl_probe(struct platform_device *pdev)
> > +{
> > + struct bllcd_device *bllcd;
>
> int ret;
>
> > +
> > + bllcd = kzalloc(sizeof(*bllcd), GFP_KERNEL);
> > + if (bllcd == NULL)
> > + return -ENOMEM;
> > +
> > + /* bl driver - name must match fb driver name */
> > + bllcd->bl_device = backlight_device_register(S1D_DEVICENAME,
> > + >dev, NULL, _bl_ops);
> > +
> > + if (IS_ERR(bllcd->bl_device)) {
>
> ret = PTR_ERR(bllcd->bl_device);
>
> > + kfree(bllcd);
> > + printk(KERN_ERR "bl :failed to register device\n");
> > + return -ENODEV;
>
> delete the line above, and then swap the two remaining lines.
>
> return ret;
>
> > + }
> > +
> > + /* lcd driver */
> > + bllcd->lcd_device = lcd_device_register(S1D_DEVICENAME,
> > + >dev, NULL, _lcd_ops);
> > + if (IS_ERR(bllcd->lcd_device)) {
> > + backlight_device_unregister(bllcd->bl_device);
>
> ret = PTR_ERR(bllcd->lcd_device);
>
> > + kfree(bllcd);
> > + printk(KERN_ERR "lcd :failed to register device\n");
> > + return -ENODEV;
>
> delete the line above, and then swap the two remaining lines.
>
> return ret;
>
> The reason for swapping the two lines is that it _might_ give gcc a
> chance to optimise the two paths.
>
> > +static struct platform_driver jornada_bl_driver = {
> > + .probe = jornada_bl_probe,
> > + .remove = jornada_bl_remove,
> > +#ifdef CONFIG_PM
> > + .suspend = jornada_bl_suspend,
> > + .resume = jornada_bl_resume,
> > +#endif
> > + .driver = {
> > + .name = "jornada_bllcd",
>
> You missed this one - which currently is: tab space space space space.
> It should be two tabs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
ATTEMPT #4.
---
Fixed issues as suggested by Russell below.
diff --git a/drivers/video/backlight/jornada720_bllcd.c
b/drivers/video/backlight/jornada720_bllcd.c
new file mode 100644
index 000..f3c3f26
--- /dev/null
+++ b/drivers/video/backlight/jornada720_bllcd.c
@@ -0,0 +1,290 @@
+/*
+ *
+ * Backlight and LCD Driver for HP Jornada 720
+ * Copyright (C) 2007 Kristoffer Ericson <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * or any later version as published by the Free Software Foundation.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Kristoffer Ericson <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("HP Jornada 710/720/728 Backlight/LCD Driver");
+MODULE_LICENSE("GPL");
+
+/* Contrast */
+#define LCD_MAX_CONTR 0xff
+#define LCD_DEF_CONTR 0x80
+/* Brightness */
+#define BL_MAX_BRIGHT 0xff
+#define BL_DEF_BRIGHT 0x19
+
+struct bllcd_device {
+ struct backlight_device *bl_device;
+ struct lcd_device *lcd_device;
+};
+
+/*
+ * BACKLIGHT HANDLING ROUTINES
+ */
+static int jornada_bl_get_brightness(struct backlight_device *dev)
+{
+ int ret;
+
+ /* check if backlight is on */
+ if (!(PPSR & PPC_LDD1))
+ return BL_MAX_BRIGHT;
+
+ jornada_ssp_start();
+ if (jornada_ssp_inout(GETBRIGHTNESS) == -ETIMEDOUT) {
+ printk(KERN_ERR "bl :get brightness timeout\n");
+ ret = -1;
+ } else
+ ret = jornada_ssp_inout(TXDUMMY);
+
+ jornada_ssp_end();
+
+ /* 0 is max brightness */
+ return BL_MAX_BRIGHT - ret;
+}
+
+static int jornada_bl_update_status(struct backlight_device *dev)
+{
+ int ret = 0;
+ int value;
+
+ jornada_ssp_start();
+
+ if (dev->props.power != FB_BLANK_UNBLANK ||
+ dev->props.fb_blank != FB_BLANK_UNBLANK) {
+ ret = jornada_ssp_inout(BRIGHTNESSOFF);
+ if (ret == -ETIMEDOUT) {
+ printk(KERN_ERR "bl : brightness off timeout\n");
+ /* backlight off */
+ PPSR &= ~PPC_LDD1;
+ PPDR |= PPC_LDD1;
+ }
+ } else { /* backlight on */
+ PPSR |= PPC_LDD1;
+ /* send setbrightness cmd */
+ ret = jornada_ssp_inout(SETBRIGHTNESS);
+ if (ret != TXDUMMY) {
+ printk(KERN_ERR "bl :set brightness timeout\n");
+ } else {
+ /* cmd accepted */
+ value = BL_MAX_BRIGHT - dev->props.brightness;
+ if (jornada_ssp_byte(value) == TXDUMMY)
+ ret = value;
+ else
+ printk(KERN_ERR "bl :set brightness failed\n");
+ }
+ }
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+/*
+ * LCD HANDLING FUNCTIONS
+ */
+static int jornada_lcd_set_contrast(struct lcd_device *pdev, int contrast)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(SETCONTRAST);
+
+ if (ret == -ETIMEDOUT)
+ printk(KERN_ERR "lcd :set contrast timeout\n");
+ else
+ ret = jornada_ssp_byte(contrast);
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+static int jornada_lcd_set_power(struct lcd_device *pdev, int power)
+{
+ if (power != FB_BLANK_UNBLANK) {
+ /* turn off LCD */
+ PPSR &= ~PPC_LDD2;
+ PPDR |= PPC_LDD2;
+ } else {
+ /* turn on LCD */
+ PPSR |= PPC_LDD2;
+ }
+
+ return 0;
+}
+
+static int jornada_lcd_get_power(struct lcd_device *pdev)
+{
+ if (PPSR & PPC_LDD2)
+ return FB_BLANK_UNBLANK;
+ else
+ return FB_BLANK_POWERDOWN;
+}
+
+static int jornada_lcd_get_contrast(struct lcd_device *pdev)
+{
+ int ret;
+
+ /* Don't set contrast on off powerd LCD */
+ if (jornada_lcd_get_power(pdev) != FB_BLANK_UNBLANK)
+ return 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(GETCONTRAST);
+ if (ret != -ETIMEDOUT)
+ ret = jornada_ssp_inout(TXDUMMY);
+ else {
+ printk(KERN_ERR "lcd :get contrast timeout\n");
+ ret = -1;
+ }
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+static struct backlight_ops jornada_bl_ops = {
+ .get_brightness = jornada_bl_get_brightness,
+ .update_status = jornada_bl_update_status,
+};
+
+static struct lcd_ops jornada_lcd_ops = {
+ .get_contrast = jornada_lcd_get_contrast,
+ .set_contrast = jorn
Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
Attempt #3 :
Changes :
-
* removed JORN.. prefixes except from functions.
* removed file location in head
* fixed (hope) indent issues
* do not exceed 80 chars per line
* added extra checks if driver allocation fails
* return -1 instead of (MAX + 1)
...and probably alot more.
Patch:
* builds
* passes checkpatch.pl (only complaining about signoff-tag)
Oh, and thanks for all the feedback people! (and for doing it nicely)
Only thing not adress so far is richards mdelay question, need to do a quick
test before I can answer that.
/Kristoffer
diff --git a/drivers/video/backlight/jornada720_bllcd.c
b/drivers/video/backlight/jornada720_bllcd.c
new file mode 100644
index 000..0adbc49
--- /dev/null
+++ b/drivers/video/backlight/jornada720_bllcd.c
@@ -0,0 +1,287 @@
+/*
+ *
+ * Backlight and LCD Driver for HP Jornada 720
+ * Copyright (C) 2007 Kristoffer Ericson <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * or any later version as published by the Free Software Foundation.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Kristoffer Ericson <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("HP Jornada 710/720/728 Backlight/LCD Driver");
+MODULE_LICENSE("GPL");
+
+/* Contrast */
+#define LCD_MAX_CONTR 0xff
+#define LCD_DEF_CONTR 0x80
+/* Brightness */
+#define BL_MAX_BRIGHT 0xff
+#define BL_DEF_BRIGHT 0x19
+
+struct bllcd_device {
+ struct backlight_device *bl_device;
+ struct lcd_device *lcd_device;
+};
+
+/*
+ * BACKLIGHT HANDLING ROUTINES
+ */
+static int jornada_bl_get_brightness(struct backlight_device *dev)
+{
+ int ret;
+
+ /* check if backlight is on */
+ if (!(PPSR & PPC_LDD1))
+ return BL_MAX_BRIGHT;
+
+ jornada_ssp_start();
+ if (jornada_ssp_inout(GETBRIGHTNESS) == -ETIMEDOUT) {
+ printk(KERN_ERR "bl :get brightness timeout\n");
+ ret = -1;
+ } else
+ ret = jornada_ssp_inout(TXDUMMY);
+
+ jornada_ssp_end();
+
+ /* 0 is max brightness */
+ return BL_MAX_BRIGHT - ret;
+}
+
+static int jornada_bl_update_status(struct backlight_device *dev)
+{
+ int ret = 0;
+ int value;
+
+ jornada_ssp_start();
+
+ if (dev->props.power != FB_BLANK_UNBLANK ||
+ dev->props.fb_blank != FB_BLANK_UNBLANK) {
+ ret = jornada_ssp_inout(BRIGHTNESSOFF);
+ if (ret == -ETIMEDOUT) {
+ printk(KERN_ERR "bl : brightness off timeout\n");
+ /* backlight off */
+ PPSR &= ~PPC_LDD1;
+ PPDR |= PPC_LDD1;
+ }
+ } else { /* backlight on */
+ PPSR |= PPC_LDD1;
+ /* send setbrightness cmd */
+ ret = jornada_ssp_inout(SETBRIGHTNESS);
+ if (ret != TXDUMMY) {
+ printk(KERN_ERR "bl :set brightness timeout\n");
+ } else {
+ /* cmd accepted */
+ value = BL_MAX_BRIGHT - dev->props.brightness;
+ if (jornada_ssp_byte(value) == TXDUMMY)
+ ret = value;
+ else
+ printk(KERN_ERR "bl :set brightness failed\n");
+ }
+ }
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+/*
+ * LCD HANDLING FUNCTIONS
+ */
+static int jornada_lcd_set_contrast(struct lcd_device *pdev, int contrast)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(SETCONTRAST);
+
+ if (ret == -ETIMEDOUT)
+ printk(KERN_ERR "lcd :set contrast timeout\n");
+ else
+ ret = jornada_ssp_byte(contrast);
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+static int jornada_lcd_set_power(struct lcd_device *pdev, int power)
+{
+ if (power != FB_BLANK_UNBLANK) {
+ /* turn off LCD */
+ PPSR &= ~PPC_LDD2;
+ PPDR |= PPC_LDD2;
+ } else {
+ /* turn on LCD */
+ PPSR |= PPC_LDD2;
+ }
+
+ return 0;
+}
+
+static int jornada_lcd_get_power(struct lcd_device *pdev)
+{
+ if (PPSR & PPC_LDD2)
+ return FB_BLANK_UNBLANK;
+ else
+ return FB_BLANK_POWERDOWN;
+}
+
+static int jornada_lcd_get_contrast(struct lcd_device *pdev)
+{
+ int ret;
+
+ /* Don't set contrast on off powerd LCD */
+ if (jornada_lcd_get_power(pdev) != FB_BLANK_UNBLANK)
+ return 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(GETCONTRAST);
+ if (ret != -ETIMEDOUT)
+
Re: 2.6.24-git15 Keyboard Issue?
On Wed, 6 Feb 2008 14:54:21 +0100 (CET) Jiri Kosina <[EMAIL PROTECTED]> wrote: > On Wed, 6 Feb 2008, Chris Holvenstot wrote: > > > On this system I am using a PS2 Keyboard - and let me stress that it is > > only occasionaly that it happens - I have had 2.6.24-git15 up for about > > 2 hours now and have only seen it about a dozen times. I also note one > > other thing - although my system is lightly loaded - at this time of day > > I am pretty much just using email on an AMD 64 X2 4600+ with 2 gigs of > > of memory - I have noticed several times that I will be typing away and > > nothing is appearing on the screen - and a few seconds later - boom - > > there it all is. > > It could be some timing problem. Does this happen also in console, or > only when running X? > > Could you please try to > > - boot with 'nohpet' kernel parameter > - taskset -p 0x0002 if this is a multi-CPU/core > machine and you are experiencing the problems only in X > Perhaps something to CC linux-input on? > Thanks, > > -- > Jiri Kosina > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
Oki, here is attempt #2 (btw, new mail or just keep thread?)
Tested to build and checkpatch.
diff --git a/drivers/video/backlight/jornada720_bllcd.c
b/drivers/video/backlight/jornada720_bllcd.c
new file mode 100644
index 000..e911a5e
--- /dev/null
+++ b/drivers/video/backlight/jornada720_bllcd.c
@@ -0,0 +1,286 @@
+/*
+ * drivers/video/backlight/jornada720_bllcd.c
+ *
+ * Backlight and LCD Driver for HP Jornada 720
+ * Copyright (C) 2007 Kristoffer Ericson <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * or any later version as published by the Free Software Foundation.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Kristoffer Ericson <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("HP Jornada 710/720/728 Backlight/LCD Driver");
+MODULE_LICENSE("GPL");
+
+#define JORNADA_LCD_MAX_CONTRAST 0xff
+#define JORNADA_LCD_DEFAULT_CONTRAST 0x80
+#define JORNADA_BL_MAX_BRIGHTNESS 0xff
+#define JORNADA_BL_DEFAULT_BRIGHTNESS 0x19
+
+struct jornada_bllcd_device {
+ struct backlight_device *jorn_backlight_device;
+ struct lcd_device *jorn_lcd_device;
+};
+
+/*
+ * BACKLIGHT HANDLING ROUTINES
+ */
+static int jornada_bl_get_brightness(struct backlight_device *dev)
+{
+ int ret;
+
+ /* check if backlight is on */
+ if (!(PPSR & PPC_LDD1))
+ return JORNADA_BL_MAX_BRIGHTNESS;
+
+ jornada_ssp_start();
+ if (jornada_ssp_inout(GETBRIGHTNESS) == -ETIMEDOUT) {
+ printk(KERN_ERR "jornada720_bl: GetBrightness failed\n");
+ ret = JORNADA_BL_MAX_BRIGHTNESS + 1;
+ } else
+ ret = jornada_ssp_inout(TXDUMMY);
+
+ jornada_ssp_end();
+
+ /* 0 is max brightness */
+ return (JORNADA_BL_MAX_BRIGHTNESS - ret);
+}
+
+static int jornada_bl_update_status(struct backlight_device *dev)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ if (dev->props.power != FB_BLANK_UNBLANK ||
+ dev->props.fb_blank != FB_BLANK_UNBLANK) {
+ ret = jornada_ssp_inout(BRIGHTNESSOFF);
+ if (ret == -ETIMEDOUT)
+ printk(KERN_ERR "jornada720_bl: \
+ BrightnessOff timeout\n");
+ /* backlight off */
+ PPSR &= ~PPC_LDD1;
+ PPDR |= PPC_LDD1;
+
+ } else { /* backlight on */
+ PPSR |= PPC_LDD1;
+ if ((jornada_ssp_inout(SETBRIGHTNESS)) == TXDUMMY) {
+ /* send brightness value (0 is max, 255 lowest) */
+ if (jornada_ssp_byte(JORNADA_BL_MAX_BRIGHTNESS -
+dev->props.brightness) != -ETIMEDOUT)
+ ret = (JORNADA_BL_MAX_BRIGHTNESS -
+ dev->props.brightness);
+ } else
+ printk(KERN_ERR "jornada720_bl: \
+ SetBrightness timeout\n");
+ }
+ jornada_ssp_end();
+
+ return ret;
+}
+
+/*
+ * LCD HANDLING FUNCTIONS
+ */
+static int jornada_lcd_set_contrast(struct lcd_device *pdev, int contrast)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(SETCONTRAST);
+
+ if (ret == -ETIMEDOUT)
+ printk(KERN_ERR "jornada_lcd: failure to set contrast\n");
+else
+ ret = jornada_ssp_byte(contrast);
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+static int jornada_lcd_set_power(struct lcd_device *pdev, int power)
+{
+ if (power != FB_BLANK_UNBLANK) {
+ /* turn off LCD */
+ PPSR &= ~PPC_LDD2;
+ PPDR |= PPC_LDD2;
+ } else {
+ /* turn on LCD */
+ PPSR |= PPC_LDD2;
+ }
+
+ return 0;
+}
+
+static int jornada_lcd_get_power(struct lcd_device *pdev)
+{
+ if (PPSR & PPC_LDD2)
+ return FB_BLANK_UNBLANK;
+ else
+ return FB_BLANK_POWERDOWN;
+}
+
+static int jornada_lcd_get_contrast(struct lcd_device *pdev)
+{
+ int ret;
+
+ /* Don't set contrast on off powerd LCD */
+ if (jornada_lcd_get_power(pdev) != FB_BLANK_UNBLANK)
+ return 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(GETCONTRAST);
+ if (ret != -ETIMEDOUT)
+ ret = jornada_ssp_inout(TXDUMMY);
+ else {
+ printk(KERN_ERR "jornada_lcd: getcontrast failed!\n");
+ ret = JORNADA_BL_MAX_BRIGHTNESS + 1;
+ }
+
+ jornada_ssp_end();
+
+
Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
On Wed, 06 Feb 2008 13:34:12 +0100
Roel Kluin <[EMAIL PROTECTED]> wrote:
> Kristoffer Ericson wrote:
> > Greetings,
> >
> > Richard I've cleaned up the driver by checking with checkpatch.pl as
> > Russell suggested. I would appreciate it if you could
> > look through the patch again and give comments since the patch looks
> > somewhat different.
> >
> > I can add patch for Kconfig/Makefile later on but suspect there will be
> > some changes required before that.
> >
> > Oh and to answer your question regarding MAX/MIN values of the backlight, 0
> > = max and 255 = min. So we simply turn it around
> > by returning 255 - value. Same thing when we need to set value.
> >
> > Best wishes
> > Kristoffer Ericson
> >
> > diff --git a/drivers/video/backlight/jornada720_bllcd.c
> > b/drivers/video/backlight/jornada720_bllcd.c
> > new file mode 100644
> > index 000..4967b86
> > --- /dev/null
> > +++ b/drivers/video/backlight/jornada720_bllcd.c
> > @@ -0,0 +1,284 @@
> > +/*
> > + * drivers/video/backlight/jornada720_bllcd.c
> > + *
> > + * Backlight and LCD Driver for HP Jornada 720
> > + * Copyright (C) 2007 Kristoffer Ericson <[EMAIL PROTECTED]>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2
> > + * or any later version as published by the Free Software Foundation.
> > + *
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +MODULE_AUTHOR("Kristoffer Ericson <[EMAIL PROTECTED]>");
> > +MODULE_DESCRIPTION("HP Jornada 710/720/728 Backlight/LCD Driver");
> > +MODULE_LICENSE("GPL");
> > +
> > +#define JORNADA_LCD_MAX_CONTRAST 0xff
> > +#define JORNADA_LCD_DEFAULT_CONTRAST 0x80
> > +#define JORNADA_BL_MAX_BRIGHTNESS 0xff
> > +#define JORNADA_BL_DEFAULT_BRIGHTNESS 0x19
> > +
> > +struct jornada_bllcd_device {
> > + struct backlight_device *jorn_backlight_device;
> > + struct lcd_device *jorn_lcd_device;
> > +};
> > +
> > +/*
> > + * BACKLIGHT HANDLING ROUTINES
> > + */
> > +static int jornada_bl_get_brightness(struct backlight_device *dev)
> > +{
> > + int ret;
> > +
> > + /* check if backlight is on */
> > + if (!(PPSR & PPC_LDD1))
> > + return 255;
> return JORNADA_BL_MAX_BRIGHTNESS;
>
Agreed.
> > +
> > + jornada_ssp_start();
> > + if (jornada_ssp_inout(GETBRIGHTNESS) == -ETIMEDOUT) {
> > + printk(KERN_ERR "jornada720_bl: GetBrightness failed\n");
> > + ret = 256;
> ret = JORNADA_BL_MAX_BRIGHTNESS + 1;
> > + } else
> > + ret = jornada_ssp_inout(TXDUMMY);
> > +
> > + jornada_ssp_end();
> > +
> > + /* 0 is max brightness */
> > + return (255 - ret);
> return (JORNADA_BL_MAX_BRIGHTNESS - ret);
Agreed.
> > +}
> > +
> > +static int jornada_bl_update_status(struct backlight_device *dev)
> > +{
> > + int ret = 0;
> > +
> > + jornada_ssp_start();
> > +
> > + if (dev->props.power != FB_BLANK_UNBLANK ||
> > + dev->props.fb_blank != FB_BLANK_UNBLANK) {
> > + ret = jornada_ssp_inout(BRIGHTNESSOFF);
> > + if (ret == -ETIMEDOUT)
> > + printk(KERN_ERR "jornada720_bl:
> > + BrightnessOff timeout\n");
> > + else {
else isn't needed here. It should simply tell "didn't work, turning off
backlight".
> > + /* backlight off */
> > + PPSR &= ~PPC_LDD1;
> > + PPDR |= PPC_LDD1;
> > + }
> > + } else {/* backlight on */
> > + PPSR |= PPC_LDD1;
>
> missing curly bracket
No, bad formatting essentially. Should make it clear that PPSR |= PPC_LDD1 is
related to the lines below
>
> > +
> > + if ((jornada_ssp_inout(SETBRIGHTNESS)) == TXDUMMY) {
> > + /* send brightness value (0 is max, 255 lowest) */
> > + if (jornada_ssp_byte(255 - dev->props.brightness) != -ETIMEDOUT)
> > + ret = (255 - dev->props.brightness);
>
> similarly JORNADA_BL_MAX_BRIGHTNESS in the three lines above
>
Agreed. And formatting is wrong for t
Re: Resolved (sort of): Unable to access PCMCIA with O2 Micro OZ711MP1/MS1
On Wed, 06 Feb 2008 09:02:11 +0100 "Mader, Alexander (N-MSR)" <[EMAIL PROTECTED]> wrote: > Kristoffer Ericson schrieb: > > "Mader, Alexander (N-MSR)" wrote: > >> On a Fujitsu Siemens Celsius H240 a 2.6.22-3-amd64 kernel from Debian > >> testing is in use. PCMCIA utilities for Linux 2.6 version 014-4 are > >> installed. I could supply the output of lspci and lshal. > > > > Assuming debian has alot of patches applied, it would be interesting to see > > if this bug exist on vanilla 2.6.24. Would probably get alot more attention > > from > > pcmcia guru's. > > Hello, > > obviously this is the case. This morning I tried a different non-cardbus > PCMCIA card and it worked, which in turn was the case for the other test > candidates, NICs and CF adapters: they all are accessible right now. In > the moment I am trying to find out which update caused the improvement. Glad to hear its working. If you are eager to see what patch caused the bug (debian or vanilla) you can always do a bisect. Or simply run through 2.6.20 -> 2.6.24 vanilla kernels and see where it worked and when it didn't. > > Thank you very much for your attention and, please, excuse me for > bothering you. > no worries. > Best regards, Alexander. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Resolved (sort of): Unable to access PCMCIA with O2 Micro OZ711MP1/MS1
On Wed, 06 Feb 2008 09:02:11 +0100 Mader, Alexander (N-MSR) [EMAIL PROTECTED] wrote: Kristoffer Ericson schrieb: Mader, Alexander (N-MSR) wrote: On a Fujitsu Siemens Celsius H240 a 2.6.22-3-amd64 kernel from Debian testing is in use. PCMCIA utilities for Linux 2.6 version 014-4 are installed. I could supply the output of lspci and lshal. Assuming debian has alot of patches applied, it would be interesting to see if this bug exist on vanilla 2.6.24. Would probably get alot more attention from pcmcia guru's. Hello, obviously this is the case. This morning I tried a different non-cardbus PCMCIA card and it worked, which in turn was the case for the other test candidates, NICs and CF adapters: they all are accessible right now. In the moment I am trying to find out which update caused the improvement. Glad to hear its working. If you are eager to see what patch caused the bug (debian or vanilla) you can always do a bisect. Or simply run through 2.6.20 - 2.6.24 vanilla kernels and see where it worked and when it didn't. Thank you very much for your attention and, please, excuse me for bothering you. no worries. Best regards, Alexander. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
On Wed, 06 Feb 2008 13:34:12 +0100
Roel Kluin [EMAIL PROTECTED] wrote:
Kristoffer Ericson wrote:
Greetings,
Richard I've cleaned up the driver by checking with checkpatch.pl as
Russell suggested. I would appreciate it if you could
look through the patch again and give comments since the patch looks
somewhat different.
I can add patch for Kconfig/Makefile later on but suspect there will be
some changes required before that.
Oh and to answer your question regarding MAX/MIN values of the backlight, 0
= max and 255 = min. So we simply turn it around
by returning 255 - value. Same thing when we need to set value.
Best wishes
Kristoffer Ericson
diff --git a/drivers/video/backlight/jornada720_bllcd.c
b/drivers/video/backlight/jornada720_bllcd.c
new file mode 100644
index 000..4967b86
--- /dev/null
+++ b/drivers/video/backlight/jornada720_bllcd.c
@@ -0,0 +1,284 @@
+/*
+ * drivers/video/backlight/jornada720_bllcd.c
+ *
+ * Backlight and LCD Driver for HP Jornada 720
+ * Copyright (C) 2007 Kristoffer Ericson [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * or any later version as published by the Free Software Foundation.
+ *
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/backlight.h
+#include linux/lcd.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/fb.h
+#include linux/device.h
+#include asm/hardware.h
+#include asm/arch/jornada720.h
+#include video/s1d13xxxfb.h
+
+MODULE_AUTHOR(Kristoffer Ericson [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(HP Jornada 710/720/728 Backlight/LCD Driver);
+MODULE_LICENSE(GPL);
+
+#define JORNADA_LCD_MAX_CONTRAST 0xff
+#define JORNADA_LCD_DEFAULT_CONTRAST 0x80
+#define JORNADA_BL_MAX_BRIGHTNESS 0xff
+#define JORNADA_BL_DEFAULT_BRIGHTNESS 0x19
+
+struct jornada_bllcd_device {
+ struct backlight_device *jorn_backlight_device;
+ struct lcd_device *jorn_lcd_device;
+};
+
+/*
+ * BACKLIGHT HANDLING ROUTINES
+ */
+static int jornada_bl_get_brightness(struct backlight_device *dev)
+{
+ int ret;
+
+ /* check if backlight is on */
+ if (!(PPSR PPC_LDD1))
+ return 255;
return JORNADA_BL_MAX_BRIGHTNESS;
Agreed.
+
+ jornada_ssp_start();
+ if (jornada_ssp_inout(GETBRIGHTNESS) == -ETIMEDOUT) {
+ printk(KERN_ERR jornada720_bl: GetBrightness failed\n);
+ ret = 256;
ret = JORNADA_BL_MAX_BRIGHTNESS + 1;
+ } else
+ ret = jornada_ssp_inout(TXDUMMY);
+
+ jornada_ssp_end();
+
+ /* 0 is max brightness */
+ return (255 - ret);
return (JORNADA_BL_MAX_BRIGHTNESS - ret);
Agreed.
+}
+
+static int jornada_bl_update_status(struct backlight_device *dev)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ if (dev-props.power != FB_BLANK_UNBLANK ||
+ dev-props.fb_blank != FB_BLANK_UNBLANK) {
+ ret = jornada_ssp_inout(BRIGHTNESSOFF);
+ if (ret == -ETIMEDOUT)
+ printk(KERN_ERR jornada720_bl:
+ BrightnessOff timeout\n);
+ else {
else isn't needed here. It should simply tell didn't work, turning off
backlight.
+ /* backlight off */
+ PPSR = ~PPC_LDD1;
+ PPDR |= PPC_LDD1;
+ }
+ } else {/* backlight on */
+ PPSR |= PPC_LDD1;
missing curly bracket
No, bad formatting essentially. Should make it clear that PPSR |= PPC_LDD1 is
related to the lines below
+
+ if ((jornada_ssp_inout(SETBRIGHTNESS)) == TXDUMMY) {
+ /* send brightness value (0 is max, 255 lowest) */
+ if (jornada_ssp_byte(255 - dev-props.brightness) != -ETIMEDOUT)
+ ret = (255 - dev-props.brightness);
similarly JORNADA_BL_MAX_BRIGHTNESS in the three lines above
Agreed. And formatting is wrong for those if (... show be moved a tab further.
+ } else
+ printk(KERN_ERR jornada720_bl: SetBrightness timeout\n);
+ }
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+/* LCD HANDLING FUNCTIONS
+ == */
+static int jornada_lcd_set_contrast(struct lcd_device *pdev, int contrast)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(SETCONTRAST);
+
+ if (ret == -ETIMEDOUT)
+ printk(KERN_INFO jornada_lcd: failure to set contrast\n);
+else
+ ret = jornada_ssp_byte(contrast);
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+static int jornada_lcd_set_power(struct lcd_device *pdev, int power)
+{
+ if (power != FB_BLANK_UNBLANK) {
+ /* turn off LCD */
+ PPSR = ~PPC_LDD2;
+ PPDR
Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
Oki, here is attempt #2 (btw, new mail or just keep thread?)
Tested to build and checkpatch.
diff --git a/drivers/video/backlight/jornada720_bllcd.c
b/drivers/video/backlight/jornada720_bllcd.c
new file mode 100644
index 000..e911a5e
--- /dev/null
+++ b/drivers/video/backlight/jornada720_bllcd.c
@@ -0,0 +1,286 @@
+/*
+ * drivers/video/backlight/jornada720_bllcd.c
+ *
+ * Backlight and LCD Driver for HP Jornada 720
+ * Copyright (C) 2007 Kristoffer Ericson [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * or any later version as published by the Free Software Foundation.
+ *
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/backlight.h
+#include linux/lcd.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/fb.h
+#include linux/device.h
+#include asm/hardware.h
+#include asm/arch/jornada720.h
+#include video/s1d13xxxfb.h
+
+MODULE_AUTHOR(Kristoffer Ericson [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(HP Jornada 710/720/728 Backlight/LCD Driver);
+MODULE_LICENSE(GPL);
+
+#define JORNADA_LCD_MAX_CONTRAST 0xff
+#define JORNADA_LCD_DEFAULT_CONTRAST 0x80
+#define JORNADA_BL_MAX_BRIGHTNESS 0xff
+#define JORNADA_BL_DEFAULT_BRIGHTNESS 0x19
+
+struct jornada_bllcd_device {
+ struct backlight_device *jorn_backlight_device;
+ struct lcd_device *jorn_lcd_device;
+};
+
+/*
+ * BACKLIGHT HANDLING ROUTINES
+ */
+static int jornada_bl_get_brightness(struct backlight_device *dev)
+{
+ int ret;
+
+ /* check if backlight is on */
+ if (!(PPSR PPC_LDD1))
+ return JORNADA_BL_MAX_BRIGHTNESS;
+
+ jornada_ssp_start();
+ if (jornada_ssp_inout(GETBRIGHTNESS) == -ETIMEDOUT) {
+ printk(KERN_ERR jornada720_bl: GetBrightness failed\n);
+ ret = JORNADA_BL_MAX_BRIGHTNESS + 1;
+ } else
+ ret = jornada_ssp_inout(TXDUMMY);
+
+ jornada_ssp_end();
+
+ /* 0 is max brightness */
+ return (JORNADA_BL_MAX_BRIGHTNESS - ret);
+}
+
+static int jornada_bl_update_status(struct backlight_device *dev)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ if (dev-props.power != FB_BLANK_UNBLANK ||
+ dev-props.fb_blank != FB_BLANK_UNBLANK) {
+ ret = jornada_ssp_inout(BRIGHTNESSOFF);
+ if (ret == -ETIMEDOUT)
+ printk(KERN_ERR jornada720_bl: \
+ BrightnessOff timeout\n);
+ /* backlight off */
+ PPSR = ~PPC_LDD1;
+ PPDR |= PPC_LDD1;
+
+ } else { /* backlight on */
+ PPSR |= PPC_LDD1;
+ if ((jornada_ssp_inout(SETBRIGHTNESS)) == TXDUMMY) {
+ /* send brightness value (0 is max, 255 lowest) */
+ if (jornada_ssp_byte(JORNADA_BL_MAX_BRIGHTNESS -
+dev-props.brightness) != -ETIMEDOUT)
+ ret = (JORNADA_BL_MAX_BRIGHTNESS -
+ dev-props.brightness);
+ } else
+ printk(KERN_ERR jornada720_bl: \
+ SetBrightness timeout\n);
+ }
+ jornada_ssp_end();
+
+ return ret;
+}
+
+/*
+ * LCD HANDLING FUNCTIONS
+ */
+static int jornada_lcd_set_contrast(struct lcd_device *pdev, int contrast)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(SETCONTRAST);
+
+ if (ret == -ETIMEDOUT)
+ printk(KERN_ERR jornada_lcd: failure to set contrast\n);
+else
+ ret = jornada_ssp_byte(contrast);
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+static int jornada_lcd_set_power(struct lcd_device *pdev, int power)
+{
+ if (power != FB_BLANK_UNBLANK) {
+ /* turn off LCD */
+ PPSR = ~PPC_LDD2;
+ PPDR |= PPC_LDD2;
+ } else {
+ /* turn on LCD */
+ PPSR |= PPC_LDD2;
+ }
+
+ return 0;
+}
+
+static int jornada_lcd_get_power(struct lcd_device *pdev)
+{
+ if (PPSR PPC_LDD2)
+ return FB_BLANK_UNBLANK;
+ else
+ return FB_BLANK_POWERDOWN;
+}
+
+static int jornada_lcd_get_contrast(struct lcd_device *pdev)
+{
+ int ret;
+
+ /* Don't set contrast on off powerd LCD */
+ if (jornada_lcd_get_power(pdev) != FB_BLANK_UNBLANK)
+ return 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(GETCONTRAST);
+ if (ret != -ETIMEDOUT)
+ ret = jornada_ssp_inout(TXDUMMY);
+ else {
+ printk(KERN_ERR jornada_lcd: getcontrast failed!\n);
+ ret = JORNADA_BL_MAX_BRIGHTNESS + 1
Re: 2.6.24-git15 Keyboard Issue?
On Wed, 6 Feb 2008 14:54:21 +0100 (CET) Jiri Kosina [EMAIL PROTECTED] wrote: On Wed, 6 Feb 2008, Chris Holvenstot wrote: On this system I am using a PS2 Keyboard - and let me stress that it is only occasionaly that it happens - I have had 2.6.24-git15 up for about 2 hours now and have only seen it about a dozen times. I also note one other thing - although my system is lightly loaded - at this time of day I am pretty much just using email on an AMD 64 X2 4600+ with 2 gigs of of memory - I have noticed several times that I will be typing away and nothing is appearing on the screen - and a few seconds later - boom - there it all is. It could be some timing problem. Does this happen also in console, or only when running X? Could you please try to - boot with 'nohpet' kernel parameter - taskset -p 0x0002 pid_of_Xserver if this is a multi-CPU/core machine and you are experiencing the problems only in X Perhaps something to CC linux-input on? Thanks, -- Jiri Kosina -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
Attempt #3 :
Changes :
-
* removed JORN.. prefixes except from functions.
* removed file location in head
* fixed (hope) indent issues
* do not exceed 80 chars per line
* added extra checks if driver allocation fails
* return -1 instead of (MAX + 1)
...and probably alot more.
Patch:
* builds
* passes checkpatch.pl (only complaining about signoff-tag)
Oh, and thanks for all the feedback people! (and for doing it nicely)
Only thing not adress so far is richards mdelay question, need to do a quick
test before I can answer that.
/Kristoffer
diff --git a/drivers/video/backlight/jornada720_bllcd.c
b/drivers/video/backlight/jornada720_bllcd.c
new file mode 100644
index 000..0adbc49
--- /dev/null
+++ b/drivers/video/backlight/jornada720_bllcd.c
@@ -0,0 +1,287 @@
+/*
+ *
+ * Backlight and LCD Driver for HP Jornada 720
+ * Copyright (C) 2007 Kristoffer Ericson [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * or any later version as published by the Free Software Foundation.
+ *
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/backlight.h
+#include linux/lcd.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/fb.h
+#include linux/device.h
+#include asm/hardware.h
+#include asm/arch/jornada720.h
+#include video/s1d13xxxfb.h
+
+MODULE_AUTHOR(Kristoffer Ericson [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(HP Jornada 710/720/728 Backlight/LCD Driver);
+MODULE_LICENSE(GPL);
+
+/* Contrast */
+#define LCD_MAX_CONTR 0xff
+#define LCD_DEF_CONTR 0x80
+/* Brightness */
+#define BL_MAX_BRIGHT 0xff
+#define BL_DEF_BRIGHT 0x19
+
+struct bllcd_device {
+ struct backlight_device *bl_device;
+ struct lcd_device *lcd_device;
+};
+
+/*
+ * BACKLIGHT HANDLING ROUTINES
+ */
+static int jornada_bl_get_brightness(struct backlight_device *dev)
+{
+ int ret;
+
+ /* check if backlight is on */
+ if (!(PPSR PPC_LDD1))
+ return BL_MAX_BRIGHT;
+
+ jornada_ssp_start();
+ if (jornada_ssp_inout(GETBRIGHTNESS) == -ETIMEDOUT) {
+ printk(KERN_ERR bl :get brightness timeout\n);
+ ret = -1;
+ } else
+ ret = jornada_ssp_inout(TXDUMMY);
+
+ jornada_ssp_end();
+
+ /* 0 is max brightness */
+ return BL_MAX_BRIGHT - ret;
+}
+
+static int jornada_bl_update_status(struct backlight_device *dev)
+{
+ int ret = 0;
+ int value;
+
+ jornada_ssp_start();
+
+ if (dev-props.power != FB_BLANK_UNBLANK ||
+ dev-props.fb_blank != FB_BLANK_UNBLANK) {
+ ret = jornada_ssp_inout(BRIGHTNESSOFF);
+ if (ret == -ETIMEDOUT) {
+ printk(KERN_ERR bl : brightness off timeout\n);
+ /* backlight off */
+ PPSR = ~PPC_LDD1;
+ PPDR |= PPC_LDD1;
+ }
+ } else { /* backlight on */
+ PPSR |= PPC_LDD1;
+ /* send setbrightness cmd */
+ ret = jornada_ssp_inout(SETBRIGHTNESS);
+ if (ret != TXDUMMY) {
+ printk(KERN_ERR bl :set brightness timeout\n);
+ } else {
+ /* cmd accepted */
+ value = BL_MAX_BRIGHT - dev-props.brightness;
+ if (jornada_ssp_byte(value) == TXDUMMY)
+ ret = value;
+ else
+ printk(KERN_ERR bl :set brightness failed\n);
+ }
+ }
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+/*
+ * LCD HANDLING FUNCTIONS
+ */
+static int jornada_lcd_set_contrast(struct lcd_device *pdev, int contrast)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(SETCONTRAST);
+
+ if (ret == -ETIMEDOUT)
+ printk(KERN_ERR lcd :set contrast timeout\n);
+ else
+ ret = jornada_ssp_byte(contrast);
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+static int jornada_lcd_set_power(struct lcd_device *pdev, int power)
+{
+ if (power != FB_BLANK_UNBLANK) {
+ /* turn off LCD */
+ PPSR = ~PPC_LDD2;
+ PPDR |= PPC_LDD2;
+ } else {
+ /* turn on LCD */
+ PPSR |= PPC_LDD2;
+ }
+
+ return 0;
+}
+
+static int jornada_lcd_get_power(struct lcd_device *pdev)
+{
+ if (PPSR PPC_LDD2)
+ return FB_BLANK_UNBLANK;
+ else
+ return FB_BLANK_POWERDOWN;
+}
+
+static int jornada_lcd_get_contrast(struct lcd_device *pdev)
+{
+ int ret;
+
+ /* Don't set contrast on off powerd LCD */
+ if (jornada_lcd_get_power(pdev) != FB_BLANK_UNBLANK)
+ return 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(GETCONTRAST);
+ if (ret
Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
ATTEMPT #4.
---
Fixed issues as suggested by Russell below.
diff --git a/drivers/video/backlight/jornada720_bllcd.c
b/drivers/video/backlight/jornada720_bllcd.c
new file mode 100644
index 000..f3c3f26
--- /dev/null
+++ b/drivers/video/backlight/jornada720_bllcd.c
@@ -0,0 +1,290 @@
+/*
+ *
+ * Backlight and LCD Driver for HP Jornada 720
+ * Copyright (C) 2007 Kristoffer Ericson [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * or any later version as published by the Free Software Foundation.
+ *
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/backlight.h
+#include linux/lcd.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/fb.h
+#include linux/device.h
+#include asm/hardware.h
+#include asm/arch/jornada720.h
+#include video/s1d13xxxfb.h
+
+MODULE_AUTHOR(Kristoffer Ericson [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(HP Jornada 710/720/728 Backlight/LCD Driver);
+MODULE_LICENSE(GPL);
+
+/* Contrast */
+#define LCD_MAX_CONTR 0xff
+#define LCD_DEF_CONTR 0x80
+/* Brightness */
+#define BL_MAX_BRIGHT 0xff
+#define BL_DEF_BRIGHT 0x19
+
+struct bllcd_device {
+ struct backlight_device *bl_device;
+ struct lcd_device *lcd_device;
+};
+
+/*
+ * BACKLIGHT HANDLING ROUTINES
+ */
+static int jornada_bl_get_brightness(struct backlight_device *dev)
+{
+ int ret;
+
+ /* check if backlight is on */
+ if (!(PPSR PPC_LDD1))
+ return BL_MAX_BRIGHT;
+
+ jornada_ssp_start();
+ if (jornada_ssp_inout(GETBRIGHTNESS) == -ETIMEDOUT) {
+ printk(KERN_ERR bl :get brightness timeout\n);
+ ret = -1;
+ } else
+ ret = jornada_ssp_inout(TXDUMMY);
+
+ jornada_ssp_end();
+
+ /* 0 is max brightness */
+ return BL_MAX_BRIGHT - ret;
+}
+
+static int jornada_bl_update_status(struct backlight_device *dev)
+{
+ int ret = 0;
+ int value;
+
+ jornada_ssp_start();
+
+ if (dev-props.power != FB_BLANK_UNBLANK ||
+ dev-props.fb_blank != FB_BLANK_UNBLANK) {
+ ret = jornada_ssp_inout(BRIGHTNESSOFF);
+ if (ret == -ETIMEDOUT) {
+ printk(KERN_ERR bl : brightness off timeout\n);
+ /* backlight off */
+ PPSR = ~PPC_LDD1;
+ PPDR |= PPC_LDD1;
+ }
+ } else { /* backlight on */
+ PPSR |= PPC_LDD1;
+ /* send setbrightness cmd */
+ ret = jornada_ssp_inout(SETBRIGHTNESS);
+ if (ret != TXDUMMY) {
+ printk(KERN_ERR bl :set brightness timeout\n);
+ } else {
+ /* cmd accepted */
+ value = BL_MAX_BRIGHT - dev-props.brightness;
+ if (jornada_ssp_byte(value) == TXDUMMY)
+ ret = value;
+ else
+ printk(KERN_ERR bl :set brightness failed\n);
+ }
+ }
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+/*
+ * LCD HANDLING FUNCTIONS
+ */
+static int jornada_lcd_set_contrast(struct lcd_device *pdev, int contrast)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(SETCONTRAST);
+
+ if (ret == -ETIMEDOUT)
+ printk(KERN_ERR lcd :set contrast timeout\n);
+ else
+ ret = jornada_ssp_byte(contrast);
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+static int jornada_lcd_set_power(struct lcd_device *pdev, int power)
+{
+ if (power != FB_BLANK_UNBLANK) {
+ /* turn off LCD */
+ PPSR = ~PPC_LDD2;
+ PPDR |= PPC_LDD2;
+ } else {
+ /* turn on LCD */
+ PPSR |= PPC_LDD2;
+ }
+
+ return 0;
+}
+
+static int jornada_lcd_get_power(struct lcd_device *pdev)
+{
+ if (PPSR PPC_LDD2)
+ return FB_BLANK_UNBLANK;
+ else
+ return FB_BLANK_POWERDOWN;
+}
+
+static int jornada_lcd_get_contrast(struct lcd_device *pdev)
+{
+ int ret;
+
+ /* Don't set contrast on off powerd LCD */
+ if (jornada_lcd_get_power(pdev) != FB_BLANK_UNBLANK)
+ return 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(GETCONTRAST);
+ if (ret != -ETIMEDOUT)
+ ret = jornada_ssp_inout(TXDUMMY);
+ else {
+ printk(KERN_ERR lcd :get contrast timeout\n);
+ ret = -1;
+ }
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+static struct backlight_ops jornada_bl_ops = {
+ .get_brightness = jornada_bl_get_brightness,
+ .update_status = jornada_bl_update_status,
+};
+
+static struct lcd_ops jornada_lcd_ops = {
+ .get_contrast = jornada_lcd_get_contrast
Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
I made a mistake on the latest patch I sent,
if (IS_ERR(bllcd-lcd_device)) {
+ ret = PTR_ERR(bllcd-bl_device);
+ backlight_device_unregister(bllcd-bl_device);
+ printk(KERN_ERR lcd :failed to register device\n);
+ kfree(bllcd);
+ return ret;
+ }
should ofcourse read
if (IS_ERR(bllcd-lcd_device)) {
+ ret = PTR_ERR(bllcd-lcd_device);
+ backlight_device_unregister(bllcd-bl_device);
+ printk(KERN_ERR lcd :failed to register device\n);
+ kfree(bllcd);
+ return ret;
+ }
Its fixed now for me. Going to test that mdelay issue now.
On Wed, 6 Feb 2008 19:31:55 +
Russell King - ARM Linux [EMAIL PROTECTED] wrote:
On Wed, Feb 06, 2008 at 08:21:28PM +0100, Kristoffer Ericson wrote:
Oh, and thanks for all the feedback people! (and for doing it nicely)
I'm afraid you missed one - and there's a better fix for one of the other
points I made... 8)
+static int jornada_bl_probe(struct platform_device *pdev)
+{
+ struct bllcd_device *bllcd;
int ret;
+
+ bllcd = kzalloc(sizeof(*bllcd), GFP_KERNEL);
+ if (bllcd == NULL)
+ return -ENOMEM;
+
+ /* bl driver - name must match fb driver name */
+ bllcd-bl_device = backlight_device_register(S1D_DEVICENAME,
+ pdev-dev, NULL, jornada_bl_ops);
+
+ if (IS_ERR(bllcd-bl_device)) {
ret = PTR_ERR(bllcd-bl_device);
+ kfree(bllcd);
+ printk(KERN_ERR bl :failed to register device\n);
+ return -ENODEV;
delete the line above, and then swap the two remaining lines.
return ret;
+ }
+
+ /* lcd driver */
+ bllcd-lcd_device = lcd_device_register(S1D_DEVICENAME,
+ pdev-dev, NULL, jornada_lcd_ops);
+ if (IS_ERR(bllcd-lcd_device)) {
+ backlight_device_unregister(bllcd-bl_device);
ret = PTR_ERR(bllcd-lcd_device);
+ kfree(bllcd);
+ printk(KERN_ERR lcd :failed to register device\n);
+ return -ENODEV;
delete the line above, and then swap the two remaining lines.
return ret;
The reason for swapping the two lines is that it _might_ give gcc a
chance to optimise the two paths.
+static struct platform_driver jornada_bl_driver = {
+ .probe = jornada_bl_probe,
+ .remove = jornada_bl_remove,
+#ifdef CONFIG_PM
+ .suspend = jornada_bl_suspend,
+ .resume = jornada_bl_resume,
+#endif
+ .driver = {
+ .name = jornada_bllcd,
You missed this one - which currently is: tab space space space space.
It should be two tabs.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
Greetings,
Richard I've cleaned up the driver by checking with checkpatch.pl as Russell
suggested. I would appreciate it if you could
look through the patch again and give comments since the patch looks somewhat
different.
I can add patch for Kconfig/Makefile later on but suspect there will be some
changes required before that.
Oh and to answer your question regarding MAX/MIN values of the backlight, 0 =
max and 255 = min. So we simply turn it around
by returning 255 - value. Same thing when we need to set value.
Best wishes
Kristoffer Ericson
diff --git a/drivers/video/backlight/jornada720_bllcd.c
b/drivers/video/backlight/jornada720_bllcd.c
new file mode 100644
index 000..4967b86
--- /dev/null
+++ b/drivers/video/backlight/jornada720_bllcd.c
@@ -0,0 +1,284 @@
+/*
+ * drivers/video/backlight/jornada720_bllcd.c
+ *
+ * Backlight and LCD Driver for HP Jornada 720
+ * Copyright (C) 2007 Kristoffer Ericson <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * or any later version as published by the Free Software Foundation.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Kristoffer Ericson <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("HP Jornada 710/720/728 Backlight/LCD Driver");
+MODULE_LICENSE("GPL");
+
+#define JORNADA_LCD_MAX_CONTRAST 0xff
+#define JORNADA_LCD_DEFAULT_CONTRAST 0x80
+#define JORNADA_BL_MAX_BRIGHTNESS 0xff
+#define JORNADA_BL_DEFAULT_BRIGHTNESS 0x19
+
+struct jornada_bllcd_device {
+ struct backlight_device *jorn_backlight_device;
+ struct lcd_device *jorn_lcd_device;
+};
+
+/*
+ * BACKLIGHT HANDLING ROUTINES
+ */
+static int jornada_bl_get_brightness(struct backlight_device *dev)
+{
+ int ret;
+
+ /* check if backlight is on */
+ if (!(PPSR & PPC_LDD1))
+ return 255;
+
+ jornada_ssp_start();
+ if (jornada_ssp_inout(GETBRIGHTNESS) == -ETIMEDOUT) {
+ printk(KERN_ERR "jornada720_bl: GetBrightness failed\n");
+ ret = 256;
+ } else
+ ret = jornada_ssp_inout(TXDUMMY);
+
+ jornada_ssp_end();
+
+ /* 0 is max brightness */
+ return (255 - ret);
+}
+
+static int jornada_bl_update_status(struct backlight_device *dev)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ if (dev->props.power != FB_BLANK_UNBLANK ||
+ dev->props.fb_blank != FB_BLANK_UNBLANK) {
+ ret = jornada_ssp_inout(BRIGHTNESSOFF);
+ if (ret == -ETIMEDOUT)
+ printk(KERN_ERR "jornada720_bl:
+ BrightnessOff timeout\n");
+ else {
+ /* backlight off */
+ PPSR &= ~PPC_LDD1;
+ PPDR |= PPC_LDD1;
+ }
+ } else {/* backlight on */
+ PPSR |= PPC_LDD1;
+
+ if ((jornada_ssp_inout(SETBRIGHTNESS)) == TXDUMMY) {
+ /* send brightness value (0 is max, 255 lowest) */
+ if (jornada_ssp_byte(255 - dev->props.brightness) != -ETIMEDOUT)
+ ret = (255 - dev->props.brightness);
+ } else
+ printk(KERN_ERR "jornada720_bl: SetBrightness timeout\n");
+ }
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+/* LCD HANDLING FUNCTIONS
+ == */
+static int jornada_lcd_set_contrast(struct lcd_device *pdev, int contrast)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(SETCONTRAST);
+
+ if (ret == -ETIMEDOUT)
+ printk(KERN_INFO "jornada_lcd: failure to set contrast\n");
+else
+ ret = jornada_ssp_byte(contrast);
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+static int jornada_lcd_set_power(struct lcd_device *pdev, int power)
+{
+ if (power != FB_BLANK_UNBLANK) {
+ /* turn off LCD */
+ PPSR &= ~PPC_LDD2;
+ PPDR |= PPC_LDD2;
+ } else
+ /* turn on LCD */
+ PPSR |= PPC_LDD2;
+
+ return 0;
+}
+
+static int jornada_lcd_get_power(struct lcd_device *pdev)
+{
+ if (PPSR & PPC_LDD2)
+ return FB_BLANK_UNBLANK;
+ else
+ return FB_BLANK_POWERDOWN;
+}
+
+static int jornada_lcd_get_contrast(struct lcd_device *pdev)
+{
+ int ret;
+
+ /* Don't set contrast on off powerd LCD */
+ if (jornada_lcd_get_power(pdev) != FB_BLANK_UNBLANK)
+ return 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(GETCONTRAST);
+ if (ret != -ETIMEDOUT)
+ ret = jornada_ssp_inout(TXDUMMY);
+ else {
+ printk(K
[PATCH/HP6XX] - Add leds support to the HP Jornada 6xx handheld
Greetings,
Richard, I've been told from paul that I should seek another solution for my
hd6446x.h merger (perhaps mfd driver). So this patch
is against linux-2.6.git with the header and defines changed back to old style.
Tested to compile. I tested the "old" patch and that worked and I've only
changed 5-6 names so it really should work as before.
shortlog:
This patch adds leds support for the HP Jornada 6xx handheld(s). Usage can
either be through /sys/platform..
or by adding various triggers in menuconfig. The leds only support on / off
where 0 is off and 1 is on.
signed-off-by:Kristoffer Ericson <[EMAIL PROTECTED]>
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ec568fa..0b0bca1 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -100,6 +100,14 @@ config LEDS_COBALT_RAQ
help
This option enables support for the Cobalt Raq series LEDs.
+config LEDS_HP6XX
+ bool "LED Support for the HP Jornada 6xx"
+ depends on LEDS_CLASS && SH_HP6XX
+ select LEDS_TRIGGERS
+ help
+ This option enables led support for the handheld
+ HP Jornada 620/660/680/690.
+
config LEDS_GPIO
tristate "LED Support for GPIO connected LEDs"
depends on LEDS_CLASS && GENERIC_GPIO
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index a60de1b..a9a8ffb 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+=
leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
diff --git a/drivers/leds/leds-hp6xx.c b/drivers/leds/leds-hp6xx.c
new file mode 100644
index 000..82d4ec3
--- /dev/null
+++ b/drivers/leds/leds-hp6xx.c
@@ -0,0 +1,120 @@
+/*
+ * LED Triggers Core
+ * For the HP Jornada 620/660/680/690 handhelds
+ *
+ * Copyright 2008 Kristoffer Ericson <[EMAIL PROTECTED]>
+ * this driver is based on leds-spitz.c by Richard Purdie.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void hp6xxled_green_set(struct led_classdev *led_cdev, enum
led_brightness value)
+{
+ u8 v8;
+
+ v8 = inb(PKDR);
+ if (value)
+ outb(v8 & (~PKDR_LED_GREEN), PKDR);
+ else
+ outb(v8 | PKDR_LED_GREEN, PKDR);
+}
+
+static void hp6xxled_red_set(struct led_classdev *led_cdev, enum
led_brightness value)
+{
+ u16 v16;
+
+ v16 = inw(HD64461_GPBDR);
+ if (value)
+ outw(v16 & (~HD64461_GPBDR_LED_RED), HD64461_GPBDR);
+ else
+ outw(v16 | HD64461_GPBDR_LED_RED, HD64461_GPBDR);
+}
+
+static struct led_classdev hp6xx_red_led = {
+ .name = "hp6xx:red",
+ .default_trigger= "hp6xx-charge",
+ .brightness_set = hp6xxled_red_set,
+};
+
+static struct led_classdev hp6xx_green_led = {
+ .name = "hp6xx:green",
+ .default_trigger= "ide-disk",
+ .brightness_set = hp6xxled_green_set,
+};
+
+#ifdef CONFIG_PM
+static int hp6xxled_suspend(struct platform_device *dev, pm_message_t state)
+{
+ led_classdev_suspend(_red_led);
+ led_classdev_suspend(_green_led);
+ return 0;
+}
+
+static int hp6xxled_resume(struct platform_device *dev)
+{
+ led_classdev_resume(_red_led);
+ led_classdev_resume(_green_led);
+ return 0;
+}
+#endif
+
+static int hp6xxled_probe(struct platform_device *pdev)
+{
+ int ret;
+
+ ret = led_classdev_register(>dev, _red_led);
+ if (ret < 0)
+ return ret;
+
+ ret = led_classdev_register(>dev, _green_led);
+ if (ret < 0)
+ led_classdev_unregister(_red_led);
+
+ return ret;
+}
+
+static int hp6xxled_remove(struct platform_device *pdev)
+{
+ led_classdev_unregister(_red_led);
+ led_classdev_unregister(_green_led);
+
+ return 0;
+}
+
+static struct platform_driver hp6xxled_driver = {
+ .probe = hp6xxled_probe,
+ .remove = hp6xxled_remove,
+#ifdef CONFIG_PM
+ .suspend= hp6xxled_suspend,
+ .resume = hp6xxled_resume,
+#endif
+ .driver = {
+ .name = "hp6xx-led",
+ },
+};
+
+static int __init hp6xxled_init(void)
+{
+ return platform_driver_register(_driver);
+}
+
+static void __exit hp6xxled_exit(void)
+{
+ platform_driver_unregister
Re: Unable to access PCMCIA with O2 Micro OZ711MP1/MS1
On Tue, 05 Feb 2008 06:46:16 +0100 "Mader, Alexander (N-MSR)" <[EMAIL PROTECTED]> wrote: > Hello, > > after contacting linux-pcmcia and some search I am approaching lkml. > > There seems to be a problem accessing PCMCIA cards with O2 Micro > OZ711MP1/MS1 Controller. > > On a Fujitsu Siemens Celsius H240 a 2.6.22-3-amd64 kernel from Debian > testing is in use. PCMCIA utilities for Linux 2.6 version 014-4 are > installed. I could supply the output of lspci and lshal. Assuming debian has alot of patches applied, it would be interesting to see if this bug exist on vanilla 2.6.24. Would probably get alot more attention from pcmcia guru's. > > When I insert a CardBus adapter, for instance a CNET CNF401 fast > ethernet, everything works fine and the adapter becomes available to the > system -- in this example the NIC with working LAN access. The lspci and > lshal output then reflects the new hardware. > > When I insert a PCMCIA adapter, for instance a 3com 3CCE589EC, a 3com > 3C589C or an compact flash adapter, almost nothing happens: In the case > of the 3com I just get (dmesg): > > pccard: PCMCIA card inserted into slot 0 So your issue is with non-cardbus pcmcia cards? > > In the case of the compact flash adapter at the first insert dmesg gives: > > pccard: PCMCIA card inserted into slot 0 > cs: memory probe 0x0c-0x0f: excluding 0xc-0xf > cs: memory probe 0x6000-0x60ff: excluding 0x6000-0x60ff > cs: memory probe 0x8800-0x8fff: excluding 0x8800-0x8fff > cs: memory probe 0xa000-0xa0ff: excluding 0xa000-0xa0ff > cs: memory probe 0xf030-0xf03f: excluding 0xf030-0xf03f > > Later on dmesg just issues "pccard: PCMCIA card inserted into slot 0" > when the same card is inserted no matter how often. > > In the PCMCIA cases the lshal output doesn't change, but in the lspci > output the original line changes from: > > BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ > PostWrite+ ^^ > Have you looked inside the pcmcia driver file to check what sets the Reset +/-? > to: > > BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ > PostWrite+ ^^ > > In the case of the compact flash adapters neither "modprobe ide_cs" nor > "modprobe pata_pcmcia" yield anything -- not even in dmesg. > > As I do not want to access a SmartCard I did not try the o2scr driver > from gna.org/projects/o2scr. > > If I could supply more data I would like to do so on your request. > > Best regards, Alexander. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Questions regarding mfd drivers
On Mon, 4 Feb 2008 23:01:55 + Ben Dooks <[EMAIL PROTECTED]> wrote: > On Mon, Feb 04, 2008 at 12:37:14PM +0100, Kristoffer Ericson wrote: > > Greetings, > > > > Trying to wrap my head around sm501. From what I can tell an mfd driver is > > a "master" driver that takes control of all > > memory and io areas. It then hands out areas of those to drivers. Anywhere > > near correct? > > Yes, it is the central management for these, but also ensures that any > of the sub-drivers have properly locked access to the clocks, gpio and > other shared resources. Oki > > The mfd driver for the sm501 exports a number of functions for the > sub drivers to use, you should be able to see what is exported easily > by the fact they are exported with EXPORT_SYMBOL_GPL(). The header > files should document basic functionality of this. > Will take a look at that. > > I can see some benefit but still hard for me to motivate. What am I > > missing? What will the mfd be able to do, that I lack now? > > > > The sm501 driver seems way more advanced than I will need for > > hd64461/hd64465 anyhow, but still need to understand sm501 completely before > > attempting to write one on my own. Anyone know any documentation aside from > > example drivers? > > Are you trying to write your own SM501, or something else? It seems > you are writing for something else. > Im trying to move the companion chip hd64461 to a more sensible location. Paul suggested building an mfd driver. The hd64461 chipset supplies for example pcmcia and framebuffer support. Its not as advanced as the SM501. > If the chip you are targetting has shared resources, such as clock > gates, PLLs, or gpio that other drivers need to touch, then the best > way to go is for an mfd driver to provide this functionality and have > all the child drivers use the exported functionality. Oki, sounds good. Thanks for info. > > -- > Ben ([EMAIL PROTECTED], http://www.fluff.org/) > > 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Questions regarding mfd drivers
On Mon, 4 Feb 2008 23:01:55 + Ben Dooks [EMAIL PROTECTED] wrote: On Mon, Feb 04, 2008 at 12:37:14PM +0100, Kristoffer Ericson wrote: Greetings, Trying to wrap my head around sm501. From what I can tell an mfd driver is a master driver that takes control of all memory and io areas. It then hands out areas of those to drivers. Anywhere near correct? Yes, it is the central management for these, but also ensures that any of the sub-drivers have properly locked access to the clocks, gpio and other shared resources. Oki The mfd driver for the sm501 exports a number of functions for the sub drivers to use, you should be able to see what is exported easily by the fact they are exported with EXPORT_SYMBOL_GPL(). The header files should document basic functionality of this. Will take a look at that. I can see some benefit but still hard for me to motivate. What am I missing? What will the mfd be able to do, that I lack now? The sm501 driver seems way more advanced than I will need for hd64461/hd64465 anyhow, but still need to understand sm501 completely before attempting to write one on my own. Anyone know any documentation aside from example drivers? Are you trying to write your own SM501, or something else? It seems you are writing for something else. Im trying to move the companion chip hd64461 to a more sensible location. Paul suggested building an mfd driver. The hd64461 chipset supplies for example pcmcia and framebuffer support. Its not as advanced as the SM501. If the chip you are targetting has shared resources, such as clock gates, PLLs, or gpio that other drivers need to touch, then the best way to go is for an mfd driver to provide this functionality and have all the child drivers use the exported functionality. Oki, sounds good. Thanks for info. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unable to access PCMCIA with O2 Micro OZ711MP1/MS1
On Tue, 05 Feb 2008 06:46:16 +0100 Mader, Alexander (N-MSR) [EMAIL PROTECTED] wrote: Hello, after contacting linux-pcmcia and some search I am approaching lkml. There seems to be a problem accessing PCMCIA cards with O2 Micro OZ711MP1/MS1 Controller. On a Fujitsu Siemens Celsius H240 a 2.6.22-3-amd64 kernel from Debian testing is in use. PCMCIA utilities for Linux 2.6 version 014-4 are installed. I could supply the output of lspci and lshal. Assuming debian has alot of patches applied, it would be interesting to see if this bug exist on vanilla 2.6.24. Would probably get alot more attention from pcmcia guru's. When I insert a CardBus adapter, for instance a CNET CNF401 fast ethernet, everything works fine and the adapter becomes available to the system -- in this example the NIC with working LAN access. The lspci and lshal output then reflects the new hardware. When I insert a PCMCIA adapter, for instance a 3com 3CCE589EC, a 3com 3C589C or an compact flash adapter, almost nothing happens: In the case of the 3com I just get (dmesg): pccard: PCMCIA card inserted into slot 0 So your issue is with non-cardbus pcmcia cards? In the case of the compact flash adapter at the first insert dmesg gives: pccard: PCMCIA card inserted into slot 0 cs: memory probe 0x0c-0x0f: excluding 0xc-0xf cs: memory probe 0x6000-0x60ff: excluding 0x6000-0x60ff cs: memory probe 0x8800-0x8fff: excluding 0x8800-0x8fff cs: memory probe 0xa000-0xa0ff: excluding 0xa000-0xa0ff cs: memory probe 0xf030-0xf03f: excluding 0xf030-0xf03f Later on dmesg just issues pccard: PCMCIA card inserted into slot 0 when the same card is inserted no matter how often. In the PCMCIA cases the lshal output doesn't change, but in the lspci output the original line changes from: BridgeCtl: Parity- SERR- ISA- VGA- MAbort- Reset+ 16bInt+ PostWrite+ ^^ Have you looked inside the pcmcia driver file to check what sets the Reset +/-? to: BridgeCtl: Parity- SERR- ISA- VGA- MAbort- Reset- 16bInt+ PostWrite+ ^^ In the case of the compact flash adapters neither modprobe ide_cs nor modprobe pata_pcmcia yield anything -- not even in dmesg. As I do not want to access a SmartCard I did not try the o2scr driver from gna.org/projects/o2scr. If I could supply more data I would like to do so on your request. Best regards, Alexander. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH/HP6XX] - Add leds support to the HP Jornada 6xx handheld
Greetings,
Richard, I've been told from paul that I should seek another solution for my
hd6446x.h merger (perhaps mfd driver). So this patch
is against linux-2.6.git with the header and defines changed back to old style.
Tested to compile. I tested the old patch and that worked and I've only
changed 5-6 names so it really should work as before.
shortlog:
This patch adds leds support for the HP Jornada 6xx handheld(s). Usage can
either be through /sys/platform..
or by adding various triggers in menuconfig. The leds only support on / off
where 0 is off and 1 is on.
signed-off-by:Kristoffer Ericson [EMAIL PROTECTED]
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ec568fa..0b0bca1 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -100,6 +100,14 @@ config LEDS_COBALT_RAQ
help
This option enables support for the Cobalt Raq series LEDs.
+config LEDS_HP6XX
+ bool LED Support for the HP Jornada 6xx
+ depends on LEDS_CLASS SH_HP6XX
+ select LEDS_TRIGGERS
+ help
+ This option enables led support for the handheld
+ HP Jornada 620/660/680/690.
+
config LEDS_GPIO
tristate LED Support for GPIO connected LEDs
depends on LEDS_CLASS GENERIC_GPIO
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index a60de1b..a9a8ffb 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+=
leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
diff --git a/drivers/leds/leds-hp6xx.c b/drivers/leds/leds-hp6xx.c
new file mode 100644
index 000..82d4ec3
--- /dev/null
+++ b/drivers/leds/leds-hp6xx.c
@@ -0,0 +1,120 @@
+/*
+ * LED Triggers Core
+ * For the HP Jornada 620/660/680/690 handhelds
+ *
+ * Copyright 2008 Kristoffer Ericson [EMAIL PROTECTED]
+ * this driver is based on leds-spitz.c by Richard Purdie.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/leds.h
+#include asm/hd64461.h
+#include asm/hp6xx.h
+
+static void hp6xxled_green_set(struct led_classdev *led_cdev, enum
led_brightness value)
+{
+ u8 v8;
+
+ v8 = inb(PKDR);
+ if (value)
+ outb(v8 (~PKDR_LED_GREEN), PKDR);
+ else
+ outb(v8 | PKDR_LED_GREEN, PKDR);
+}
+
+static void hp6xxled_red_set(struct led_classdev *led_cdev, enum
led_brightness value)
+{
+ u16 v16;
+
+ v16 = inw(HD64461_GPBDR);
+ if (value)
+ outw(v16 (~HD64461_GPBDR_LED_RED), HD64461_GPBDR);
+ else
+ outw(v16 | HD64461_GPBDR_LED_RED, HD64461_GPBDR);
+}
+
+static struct led_classdev hp6xx_red_led = {
+ .name = hp6xx:red,
+ .default_trigger= hp6xx-charge,
+ .brightness_set = hp6xxled_red_set,
+};
+
+static struct led_classdev hp6xx_green_led = {
+ .name = hp6xx:green,
+ .default_trigger= ide-disk,
+ .brightness_set = hp6xxled_green_set,
+};
+
+#ifdef CONFIG_PM
+static int hp6xxled_suspend(struct platform_device *dev, pm_message_t state)
+{
+ led_classdev_suspend(hp6xx_red_led);
+ led_classdev_suspend(hp6xx_green_led);
+ return 0;
+}
+
+static int hp6xxled_resume(struct platform_device *dev)
+{
+ led_classdev_resume(hp6xx_red_led);
+ led_classdev_resume(hp6xx_green_led);
+ return 0;
+}
+#endif
+
+static int hp6xxled_probe(struct platform_device *pdev)
+{
+ int ret;
+
+ ret = led_classdev_register(pdev-dev, hp6xx_red_led);
+ if (ret 0)
+ return ret;
+
+ ret = led_classdev_register(pdev-dev, hp6xx_green_led);
+ if (ret 0)
+ led_classdev_unregister(hp6xx_red_led);
+
+ return ret;
+}
+
+static int hp6xxled_remove(struct platform_device *pdev)
+{
+ led_classdev_unregister(hp6xx_red_led);
+ led_classdev_unregister(hp6xx_green_led);
+
+ return 0;
+}
+
+static struct platform_driver hp6xxled_driver = {
+ .probe = hp6xxled_probe,
+ .remove = hp6xxled_remove,
+#ifdef CONFIG_PM
+ .suspend= hp6xxled_suspend,
+ .resume = hp6xxled_resume,
+#endif
+ .driver = {
+ .name = hp6xx-led,
+ },
+};
+
+static int __init hp6xxled_init(void)
+{
+ return platform_driver_register(hp6xxled_driver);
+}
+
+static void __exit hp6xxled_exit(void)
+{
+ platform_driver_unregister(hp6xxled_driver
[PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds
Greetings,
Richard I've cleaned up the driver by checking with checkpatch.pl as Russell
suggested. I would appreciate it if you could
look through the patch again and give comments since the patch looks somewhat
different.
I can add patch for Kconfig/Makefile later on but suspect there will be some
changes required before that.
Oh and to answer your question regarding MAX/MIN values of the backlight, 0 =
max and 255 = min. So we simply turn it around
by returning 255 - value. Same thing when we need to set value.
Best wishes
Kristoffer Ericson
diff --git a/drivers/video/backlight/jornada720_bllcd.c
b/drivers/video/backlight/jornada720_bllcd.c
new file mode 100644
index 000..4967b86
--- /dev/null
+++ b/drivers/video/backlight/jornada720_bllcd.c
@@ -0,0 +1,284 @@
+/*
+ * drivers/video/backlight/jornada720_bllcd.c
+ *
+ * Backlight and LCD Driver for HP Jornada 720
+ * Copyright (C) 2007 Kristoffer Ericson [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * or any later version as published by the Free Software Foundation.
+ *
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/backlight.h
+#include linux/lcd.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/fb.h
+#include linux/device.h
+#include asm/hardware.h
+#include asm/arch/jornada720.h
+#include video/s1d13xxxfb.h
+
+MODULE_AUTHOR(Kristoffer Ericson [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(HP Jornada 710/720/728 Backlight/LCD Driver);
+MODULE_LICENSE(GPL);
+
+#define JORNADA_LCD_MAX_CONTRAST 0xff
+#define JORNADA_LCD_DEFAULT_CONTRAST 0x80
+#define JORNADA_BL_MAX_BRIGHTNESS 0xff
+#define JORNADA_BL_DEFAULT_BRIGHTNESS 0x19
+
+struct jornada_bllcd_device {
+ struct backlight_device *jorn_backlight_device;
+ struct lcd_device *jorn_lcd_device;
+};
+
+/*
+ * BACKLIGHT HANDLING ROUTINES
+ */
+static int jornada_bl_get_brightness(struct backlight_device *dev)
+{
+ int ret;
+
+ /* check if backlight is on */
+ if (!(PPSR PPC_LDD1))
+ return 255;
+
+ jornada_ssp_start();
+ if (jornada_ssp_inout(GETBRIGHTNESS) == -ETIMEDOUT) {
+ printk(KERN_ERR jornada720_bl: GetBrightness failed\n);
+ ret = 256;
+ } else
+ ret = jornada_ssp_inout(TXDUMMY);
+
+ jornada_ssp_end();
+
+ /* 0 is max brightness */
+ return (255 - ret);
+}
+
+static int jornada_bl_update_status(struct backlight_device *dev)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ if (dev-props.power != FB_BLANK_UNBLANK ||
+ dev-props.fb_blank != FB_BLANK_UNBLANK) {
+ ret = jornada_ssp_inout(BRIGHTNESSOFF);
+ if (ret == -ETIMEDOUT)
+ printk(KERN_ERR jornada720_bl:
+ BrightnessOff timeout\n);
+ else {
+ /* backlight off */
+ PPSR = ~PPC_LDD1;
+ PPDR |= PPC_LDD1;
+ }
+ } else {/* backlight on */
+ PPSR |= PPC_LDD1;
+
+ if ((jornada_ssp_inout(SETBRIGHTNESS)) == TXDUMMY) {
+ /* send brightness value (0 is max, 255 lowest) */
+ if (jornada_ssp_byte(255 - dev-props.brightness) != -ETIMEDOUT)
+ ret = (255 - dev-props.brightness);
+ } else
+ printk(KERN_ERR jornada720_bl: SetBrightness timeout\n);
+ }
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+/* LCD HANDLING FUNCTIONS
+ == */
+static int jornada_lcd_set_contrast(struct lcd_device *pdev, int contrast)
+{
+ int ret = 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(SETCONTRAST);
+
+ if (ret == -ETIMEDOUT)
+ printk(KERN_INFO jornada_lcd: failure to set contrast\n);
+else
+ ret = jornada_ssp_byte(contrast);
+
+ jornada_ssp_end();
+
+ return ret;
+}
+
+static int jornada_lcd_set_power(struct lcd_device *pdev, int power)
+{
+ if (power != FB_BLANK_UNBLANK) {
+ /* turn off LCD */
+ PPSR = ~PPC_LDD2;
+ PPDR |= PPC_LDD2;
+ } else
+ /* turn on LCD */
+ PPSR |= PPC_LDD2;
+
+ return 0;
+}
+
+static int jornada_lcd_get_power(struct lcd_device *pdev)
+{
+ if (PPSR PPC_LDD2)
+ return FB_BLANK_UNBLANK;
+ else
+ return FB_BLANK_POWERDOWN;
+}
+
+static int jornada_lcd_get_contrast(struct lcd_device *pdev)
+{
+ int ret;
+
+ /* Don't set contrast on off powerd LCD */
+ if (jornada_lcd_get_power(pdev) != FB_BLANK_UNBLANK)
+ return 0;
+
+ jornada_ssp_start();
+
+ ret = jornada_ssp_inout(GETCONTRAST);
+ if (ret != -ETIMEDOUT)
+ ret = jornada_ssp_inout(TXDUMMY);
+ else
Where to send new pcmcia driver?
Greetings, Im almost finished with my pcmcia driver for the h64461 chipset, it works fine just need to clean it up. Now looking at the MAINTAINER list it doesn't reference anyone special as the maintainer for pcmcia subsystem. So in short where should I send the patch? Also, I've tried on numerous occasions to seek help on pcmcia list and besides some helpful replies from Peter Stuge, it's been silent. Perhaps linux-pcmcia mailinglist would be better off getting merged into linux-main list? Best wishes Kristoffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Questions regarding mfd drivers
Greetings, Trying to wrap my head around sm501. From what I can tell an mfd driver is a "master" driver that takes control of all memory and io areas. It then hands out areas of those to drivers. Anywhere near correct? I can see some benefit but still hard for me to motivate. What am I missing? What will the mfd be able to do, that I lack now? The sm501 driver seems way more advanced than I will need for hd64461/hd64465 anyhow, but still need to understand sm501 completely before attempting to write one on my own. Anyone know any documentation aside from example drivers? Best wishes Kristoffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Questions regarding mfd drivers
Greetings, Trying to wrap my head around sm501. From what I can tell an mfd driver is a master driver that takes control of all memory and io areas. It then hands out areas of those to drivers. Anywhere near correct? I can see some benefit but still hard for me to motivate. What am I missing? What will the mfd be able to do, that I lack now? The sm501 driver seems way more advanced than I will need for hd64461/hd64465 anyhow, but still need to understand sm501 completely before attempting to write one on my own. Anyone know any documentation aside from example drivers? Best wishes Kristoffer -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Where to send new pcmcia driver?
Greetings, Im almost finished with my pcmcia driver for the h64461 chipset, it works fine just need to clean it up. Now looking at the MAINTAINER list it doesn't reference anyone special as the maintainer for pcmcia subsystem. So in short where should I send the patch? Also, I've tried on numerous occasions to seek help on pcmcia list and besides some helpful replies from Peter Stuge, it's been silent. Perhaps linux-pcmcia mailinglist would be better off getting merged into linux-main list? Best wishes Kristoffer -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH/LEDS] - Add support for leds on the HP Jornada 6xx series
Greetings,
Patch against linux-2.6.git (synced today)
shortlog:
The HP Jornada 6xx series have simple leds thats able to produce green or red
light.
This patch enables the leds to be used by the kernel and/or userland.
signed-off-by: Kristoffer Ericson <[EMAIL PROTECTED]>
Richard please note that this driver makes use of include/asm-sh/hd6446x.h
which is a merged header not yet
available. I've sent patch to paul but gotten no answer yet. If you cannot
commit it for that reason, then please just look through it.
I've confirmed that this patch compiles for me (using local git-tree with
header at place) and that it works as expected on jornada.
Best wishes
Kristoffer Ericson
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ec568fa..0b0bca1 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -100,6 +100,14 @@ config LEDS_COBALT_RAQ
help
This option enables support for the Cobalt Raq series LEDs.
+config LEDS_HP6XX
+ bool "LED Support for the HP Jornada 6xx"
+ depends on LEDS_CLASS && SH_HP6XX
+ select LEDS_TRIGGERS
+ help
+ This option enables led support for the handheld
+ HP Jornada 620/660/680/690.
+
config LEDS_GPIO
tristate "LED Support for GPIO connected LEDs"
depends on LEDS_CLASS && GENERIC_GPIO
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index a60de1b..a9a8ffb 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+=
leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
diff --git a/drivers/leds/leds-hp6xx.c b/drivers/leds/leds-hp6xx.c
new file mode 100644
index 000..f882e8f
--- /dev/null
+++ b/drivers/leds/leds-hp6xx.c
@@ -0,0 +1,120 @@
+/*
+ * LED Triggers Core
+ * For the HP Jornada 620/660/680/690 handhelds
+ *
+ * Copyright 2008 Kristoffer Ericson <[EMAIL PROTECTED]>
+ * this driver is based on leds-spitz.c by Richard Purdie.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void hp6xxled_green_set(struct led_classdev *led_cdev, enum
led_brightness value)
+{
+ u8 v8;
+
+ v8 = inb(PKDR);
+ if (value)
+ outb(v8 & (~PKDR_LED_GREEN), PKDR);
+ else
+ outb(v8 | PKDR_LED_GREEN, PKDR);
+}
+
+static void hp6xxled_red_set(struct led_classdev *led_cdev, enum
led_brightness value)
+{
+ u16 v16;
+
+ v16 = inw(HD6446x_GPBDR);
+ if (value)
+ outw(v16 & (~HD64461_GPBDR_LED_RED), HD6446x_GPBDR);
+ else
+ outw(v16 | HD64461_GPBDR_LED_RED, HD6446x_GPBDR);
+}
+
+static struct led_classdev hp6xx_red_led = {
+ .name = "hp6xx:red",
+ .default_trigger= "hp6xx-charge",
+ .brightness_set = hp6xxled_red_set,
+};
+
+static struct led_classdev hp6xx_green_led = {
+ .name = "hp6xx:green",
+ .default_trigger= "ide-disk",
+ .brightness_set = hp6xxled_green_set,
+};
+
+#ifdef CONFIG_PM
+static int hp6xxled_suspend(struct platform_device *dev, pm_message_t state)
+{
+ led_classdev_suspend(_red_led);
+ led_classdev_suspend(_green_led);
+ return 0;
+}
+
+static int hp6xxled_resume(struct platform_device *dev)
+{
+ led_classdev_resume(_red_led);
+ led_classdev_resume(_green_led);
+ return 0;
+}
+#endif
+
+static int hp6xxled_probe(struct platform_device *pdev)
+{
+ int ret;
+
+ ret = led_classdev_register(>dev, _red_led);
+ if (ret < 0)
+ return ret;
+
+ ret = led_classdev_register(>dev, _green_led);
+ if (ret < 0)
+ led_classdev_unregister(_red_led);
+
+ return ret;
+}
+
+static int hp6xxled_remove(struct platform_device *pdev)
+{
+ led_classdev_unregister(_red_led);
+ led_classdev_unregister(_green_led);
+
+ return 0;
+}
+
+static struct platform_driver hp6xxled_driver = {
+ .probe = hp6xxled_probe,
+ .remove = hp6xxled_remove,
+#ifdef CONFIG_PM
+ .suspend= hp6xxled_suspend,
+ .resume = hp6xxled_resume,
+#endif
+ .driver = {
+ .name = "hp6xx-led",
+ },
+};
+
+static int __init hp6xxled_init(void)
+{
+ return platform_driver_register(_driver);
+}
+
+static void __exit hp6xxled_e
[PATCH/LEDS] - Add support for leds on the HP Jornada 6xx series
Greetings,
Patch against linux-2.6.git (synced today)
shortlog:
The HP Jornada 6xx series have simple leds thats able to produce green or red
light.
This patch enables the leds to be used by the kernel and/or userland.
signed-off-by: Kristoffer Ericson [EMAIL PROTECTED]
Richard please note that this driver makes use of include/asm-sh/hd6446x.h
which is a merged header not yet
available. I've sent patch to paul but gotten no answer yet. If you cannot
commit it for that reason, then please just look through it.
I've confirmed that this patch compiles for me (using local git-tree with
header at place) and that it works as expected on jornada.
Best wishes
Kristoffer Ericson
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ec568fa..0b0bca1 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -100,6 +100,14 @@ config LEDS_COBALT_RAQ
help
This option enables support for the Cobalt Raq series LEDs.
+config LEDS_HP6XX
+ bool LED Support for the HP Jornada 6xx
+ depends on LEDS_CLASS SH_HP6XX
+ select LEDS_TRIGGERS
+ help
+ This option enables led support for the handheld
+ HP Jornada 620/660/680/690.
+
config LEDS_GPIO
tristate LED Support for GPIO connected LEDs
depends on LEDS_CLASS GENERIC_GPIO
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index a60de1b..a9a8ffb 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+=
leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
diff --git a/drivers/leds/leds-hp6xx.c b/drivers/leds/leds-hp6xx.c
new file mode 100644
index 000..f882e8f
--- /dev/null
+++ b/drivers/leds/leds-hp6xx.c
@@ -0,0 +1,120 @@
+/*
+ * LED Triggers Core
+ * For the HP Jornada 620/660/680/690 handhelds
+ *
+ * Copyright 2008 Kristoffer Ericson [EMAIL PROTECTED]
+ * this driver is based on leds-spitz.c by Richard Purdie.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/leds.h
+#include asm/hd6446x.h
+#include asm/hp6xx.h
+
+static void hp6xxled_green_set(struct led_classdev *led_cdev, enum
led_brightness value)
+{
+ u8 v8;
+
+ v8 = inb(PKDR);
+ if (value)
+ outb(v8 (~PKDR_LED_GREEN), PKDR);
+ else
+ outb(v8 | PKDR_LED_GREEN, PKDR);
+}
+
+static void hp6xxled_red_set(struct led_classdev *led_cdev, enum
led_brightness value)
+{
+ u16 v16;
+
+ v16 = inw(HD6446x_GPBDR);
+ if (value)
+ outw(v16 (~HD64461_GPBDR_LED_RED), HD6446x_GPBDR);
+ else
+ outw(v16 | HD64461_GPBDR_LED_RED, HD6446x_GPBDR);
+}
+
+static struct led_classdev hp6xx_red_led = {
+ .name = hp6xx:red,
+ .default_trigger= hp6xx-charge,
+ .brightness_set = hp6xxled_red_set,
+};
+
+static struct led_classdev hp6xx_green_led = {
+ .name = hp6xx:green,
+ .default_trigger= ide-disk,
+ .brightness_set = hp6xxled_green_set,
+};
+
+#ifdef CONFIG_PM
+static int hp6xxled_suspend(struct platform_device *dev, pm_message_t state)
+{
+ led_classdev_suspend(hp6xx_red_led);
+ led_classdev_suspend(hp6xx_green_led);
+ return 0;
+}
+
+static int hp6xxled_resume(struct platform_device *dev)
+{
+ led_classdev_resume(hp6xx_red_led);
+ led_classdev_resume(hp6xx_green_led);
+ return 0;
+}
+#endif
+
+static int hp6xxled_probe(struct platform_device *pdev)
+{
+ int ret;
+
+ ret = led_classdev_register(pdev-dev, hp6xx_red_led);
+ if (ret 0)
+ return ret;
+
+ ret = led_classdev_register(pdev-dev, hp6xx_green_led);
+ if (ret 0)
+ led_classdev_unregister(hp6xx_red_led);
+
+ return ret;
+}
+
+static int hp6xxled_remove(struct platform_device *pdev)
+{
+ led_classdev_unregister(hp6xx_red_led);
+ led_classdev_unregister(hp6xx_green_led);
+
+ return 0;
+}
+
+static struct platform_driver hp6xxled_driver = {
+ .probe = hp6xxled_probe,
+ .remove = hp6xxled_remove,
+#ifdef CONFIG_PM
+ .suspend= hp6xxled_suspend,
+ .resume = hp6xxled_resume,
+#endif
+ .driver = {
+ .name = hp6xx-led,
+ },
+};
+
+static int __init hp6xxled_init(void)
+{
+ return platform_driver_register(hp6xxled_driver);
+}
+
+static void __exit hp6xxled_exit
Re: [PATCH/KCONFIG] - Add SUPERH depends to sound/soc/sh/Kconfig
On Fri, 1 Feb 2008 08:17:15 +0900 Paul Mundt <[EMAIL PROTECTED]> wrote: > On Thu, Jan 31, 2008 at 10:58:11PM +0100, Kristoffer Ericson wrote: > > Currently you will see an empty "SoC Audio support for SuperH" menu > > when building for other archs (example pxa). > > This patch adds "depends on SUPERH" to remove that empty menu. > > > > signed-off-by: Kristoffer Ericson <[EMAIL PROTECTED]> > > > Yeah, I noticed that too. Please send this to the ALSA folks. Done, just got message from takashi that its applied. Thx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/KCONFIG] - Add SUPERH depends to sound/soc/sh/Kconfig
On Fri, 1 Feb 2008 08:17:15 +0900 Paul Mundt [EMAIL PROTECTED] wrote: On Thu, Jan 31, 2008 at 10:58:11PM +0100, Kristoffer Ericson wrote: Currently you will see an empty SoC Audio support for SuperH menu when building for other archs (example pxa). This patch adds depends on SUPERH to remove that empty menu. signed-off-by: Kristoffer Ericson [EMAIL PROTECTED] Yeah, I noticed that too. Please send this to the ALSA folks. Done, just got message from takashi that its applied. Thx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH/KCONFIG] - Add SUPERH depends to sound/soc/sh/Kconfig
Currently you will see an empty "SoC Audio support for SuperH" menu when building for other archs (example pxa). This patch adds "depends on SUPERH" to remove that empty menu. signed-off-by: Kristoffer Ericson <[EMAIL PROTECTED]> diff --git a/sound/soc/sh/Kconfig b/sound/soc/sh/Kconfig index f03220d..4c1e013 100644 --- a/sound/soc/sh/Kconfig +++ b/sound/soc/sh/Kconfig @@ -1,4 +1,5 @@ menu "SoC Audio support for SuperH" + depends on SUPERH config SND_SOC_PCM_SH7760 tristate "SoC Audio support for Renesas SH7760" SoC-SuperH-add-depends.patch Description: Binary data
[PATCH/KCONFIG] - Add SUPERH depends to sound/soc/sh/Kconfig
Currently you will see an empty SoC Audio support for SuperH menu when building for other archs (example pxa). This patch adds depends on SUPERH to remove that empty menu. signed-off-by: Kristoffer Ericson [EMAIL PROTECTED] diff --git a/sound/soc/sh/Kconfig b/sound/soc/sh/Kconfig index f03220d..4c1e013 100644 --- a/sound/soc/sh/Kconfig +++ b/sound/soc/sh/Kconfig @@ -1,4 +1,5 @@ menu SoC Audio support for SuperH + depends on SUPERH config SND_SOC_PCM_SH7760 tristate SoC Audio support for Renesas SH7760 SoC-SuperH-add-depends.patch Description: Binary data
Re: [HD64461_PCMCIA_driver] - Shared IRQ lines / Segfaults
On Wed, 30 Jan 2008 14:05:59 +0100 Manuel Lauss <[EMAIL PROTECTED]> wrote: > On Wed, Jan 30, 2008 at 01:20:36PM +0100, Kristoffer Ericson wrote: > > Greetings, > > > > Driver detects card insertion / ejection and sets power properly. The > > mapping looks resonable also compairing to a working 2.6.17 driver. > > modprobe hostap_cs > > hostap_cs: Registered netdevice wifi0 > > Unable to handle kernel NULL pointer dereference at virtual address 0028 > > pc = 8d0031b8 > > *pde = > > Oops: [#1] > > Modules linked in: hostap_cs hostap orinoco_cs orinoco hermes atmel_cs atmel > > > > Pid : 283, Comm: modprobe > > PC is at generic_inw+0x8/0x20 > > PC : 8d0031b8 SP : 8ecaba74 SR : 40f0 TEA : c0045040Not tainted > > R0 : 0028 R1 : 8d2d9030 R2 : 8d2ac050 R3 : 0007 > > R4 : 0028 R5 : 0002 R6 : 0080 R7 : 8ecf06a0 > > R8 : 8ee62000 R9 : 8a32 R10 : c002a1b0 R11 : 8ee62000 > > R12 : 0080 R13 : 8ee62000 R14 : 8ecf06a0 > > MACH: 458f MACL: 1110 GBR : 296ce450 PR : 8d0031b8 > > > > Call trace: > > [] prism2_interrupt+0x4a/0xc50 [hostap_cs] > > The oops output suggests it crashes in > drivers/net/wireless/hostap/hostap_hw.c::prism2_check_magic(), > specifically when it tries to read the HF384X_SWSUPPORT0_OFF register > (which ist at offset 0x28, just like the oopsing address). > So, looking at the HFA384X_INW macro, it seems dev->base_addr is NULL. > I suspect this is because of set_io_map() callback in the hd64461.c > socket driver. The comment there says IO area is statically mapped, > yet it returns null; I suggest you let it return the base address of > the IO area instead. > I've tried changing the s->io_offset = 0xf000 just to see if I get any reactions. The result is that now orinoco_cs segfaults, which it more or less should. Correct s->io_offset gives : Segfault in hostap_cs Bad s->io_offset gives : Segfault in orinoco_cs Segfault in hostap_cs So basicly, the segfault in hostap_cs is not dependant on my io_offset at all.. :( Orinoco_cs log : sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x pcmcia: request for exclusive IRQ could not be fulfilled. pcmcia: the driver needs updating to supported shared IRQ lines. flags = 200, csc_mask = 80, Vcc = 33 Vpp = 0 io_irq = 0 state->Vpp != sp->state.Vcc hd64461_set_voltage: 33 Vcc, 0 Vpp flags = 220, csc_mask = 80, Vcc = 33 Vpp = 0 io_irq = 78 hd64461_set_socket: SS_IOCARD and state changed hd64461_set_socket: Lets reset and set to IO card sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x Unable to handle kernel paging request at virtual address f032 pc = 8d0034f2 *pde = Oops: 0001 [#1] Modules linked in: orinoco_cs orinoco hermes Pid : 265, Comm: modprobe PC is at generic_writew+0x2/0x10 PC : 8d0034f2 SP : 8ec25960 SR : 4000 TEA : c00205c4Not tainted R0 : c001f0d0 R1 : 0032 R2 : 8d0034f0 R3 : R4 : R5 : f032 R6 : 0004 R7 : 000b R8 : 8ece617c R9 : 8ece6000 R10 : 00c4 R11 : 8ece6424 R12 : 8ece6000 R13 : 8d2ac090 R14 : MACH: 7df8 MACL: 01936912 GBR : 296ce450 PR : c001f0fc Call trace: [] orinoco_init+0x2c/0xbb0 [orinoco] [<8d111fbe>] vsnprintf+0x35e/0x570 [<8d007024>] call_dpf+0x10/0x30 [] orinoco_init+0x0/0xbb0 [orinoco] [<8d1962c6>] register_netdevice+0x56/0x3f0 [<8d19668c>] register_netdev+0x2c/0x60 [] orinoco_cs_probe+0x38a/0x450 [orinoco_cs] [<8d08a340>] sync_buffer+0x0/0x50 [<8d22f354>] out_of_line_wait_on_bit+0x54/0x70 [<8d101046>] get_request+0xa6/0x310 [<8d10111a>] get_request+0x17a/0x310 [<8d106e01>] as_find_next_rq+0xb1/0xc0 [<8d0f0076>] ipcget_public+0x116/0x1a0 [<8d107df0>] as_add_request+0x50/0x150 [<8d02eafc>] update_wall_time+0x2dc/0x7e0 [<8d02eb34>] update_wall_time+0x314/0x7e0 [<8d00ccc8>] task_tick_fair+0x48/0xc0 [<8d00ddc0>] scheduler_tick+0x90/0x100 [<8d02e214>] getnstimeofday+0x64/0x100 [<8d112c90>] __lshrdi3+0x0/0x50 [<8d02b5ea>] ktime_get_ts+0x1a/0x60 [<8d02b630>] ktime_get+0x0/0x20 [<8d02bb90>] __remove_hrtimer+0x0/0xa0 [<8d02e1b0>] getnstimeofday+0x0/0x100 [<8d0310ea>] clockevents_program_event+0x9a/0x140 [<8d02b630>] ktime_get+0x0/0x20 [<8d0310f2>] clockevents_program_event+0xa2/0x140 [<8d031ac4>] tick_program_event+0x34/0xb0 [<8d031050>] clockevents_program_event+0x0/0x140 [<8d0200aa>] sys_rt_sigtimedwait+0x18a/0x280 [<8d01ca02>] free_uid+0x22/0x120 [<8d00f7c2>] __put_task_struct+0x32/0xd0 [<8d00f766>] free_task+0x16/0x40 [<8d025ae6>] __rcu_process_
Re: [HD64461_PCMCIA_driver] - Shared IRQ lines / Segfaults
On Wed, 30 Jan 2008 14:05:59 +0100 Manuel Lauss <[EMAIL PROTECTED]> wrote: > On Wed, Jan 30, 2008 at 01:20:36PM +0100, Kristoffer Ericson wrote: > > Greetings, > > > > Driver detects card insertion / ejection and sets power properly. The > > mapping looks resonable also compairing to a working 2.6.17 driver. > > modprobe hostap_cs > > hostap_cs: Registered netdevice wifi0 > > Unable to handle kernel NULL pointer dereference at virtual address 0028 > > pc = 8d0031b8 > > *pde = > > Oops: [#1] > > Modules linked in: hostap_cs hostap orinoco_cs orinoco hermes atmel_cs atmel > > > > Pid : 283, Comm: modprobe > > PC is at generic_inw+0x8/0x20 > > PC : 8d0031b8 SP : 8ecaba74 SR : 40f0 TEA : c0045040Not tainted > > R0 : 0028 R1 : 8d2d9030 R2 : 8d2ac050 R3 : 0007 > > R4 : 0028 R5 : 0002 R6 : 0080 R7 : 8ecf06a0 > > R8 : 8ee62000 R9 : 8a32 R10 : c002a1b0 R11 : 8ee62000 > > R12 : 0080 R13 : 8ee62000 R14 : 8ecf06a0 > > MACH: 458f MACL: 1110 GBR : 296ce450 PR : 8d0031b8 > > > > Call trace: > > [] prism2_interrupt+0x4a/0xc50 [hostap_cs] > > The oops output suggests it crashes in > drivers/net/wireless/hostap/hostap_hw.c::prism2_check_magic(), > specifically when it tries to read the HF384X_SWSUPPORT0_OFF register > (which ist at offset 0x28, just like the oopsing address). > So, looking at the HFA384X_INW macro, it seems dev->base_addr is NULL. > I suspect this is because of set_io_map() callback in the hd64461.c > socket driver. The comment there says IO area is statically mapped, > yet it returns null; I suggest you let it return the base address of > the IO area instead. I tried returning the base IO area but didn't make any difference. I took a look at some other pcmcia drivers set_io_map and it looks it should only return 0 on success. When setting up the socket I define socket->io_offset = 0xba00 which it should use. A bit lost why it doesn't get used though. Its the only IO area so thats why its static. Perhaps the io_offset is ment to be used with base_addr? > > -- > Manuel Lauss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[HD64461_PCMCIA_driver] - Shared IRQ lines / Segfaults
Greetings, Driver detects card insertion / ejection and sets power properly. The mapping looks resonable also compairing to a working 2.6.17 driver. However when manually modprobing drivers I either get a segmentation fault or problems with IRQ shared lines. Any suggestesions? Best wishes Kristoffer Insert Card Log : hd64461_interrupt: we are pushing changed events! events=64 hd64461_interrupt: Passing SS_DETECT to events hd64461_interrupt: cscr changed due to [HD6446x_PCC0ISR] & HD6446x_PCCISR_MASK = true hd64461_interrupt: we are pushing changed events! events=128 hd64461 : getting status from slot, b7 hd64461: will return status = 0 hd64461_interrupt: Passing SS_DETECT to events hd64461_interrupt: cscr changed due to [HD6446x_PCC0ISR] & HD6446x_PCCISR_MASK = true hd64461_interrupt: we are pushing changed events! events=128 hd64461 : getting status from slot, b3 hd64461: setting status to SS_DETECT hd64461: IC_memory = 1 hd64461: setting status to SS_READY hd64461: setting status to SS_3VCARD hd64461: will return status = 10c0 hd64461 : getting status from slot, b3 hd64461: setting status to SS_DETECT hd64461: IC_memory = 1 hd64461: setting status to SS_READY hd64461: setting status to SS_3VCARD hd64461: will return status = 10c0 hd64461 : getting status from slot, b3 hd64461: setting status to SS_DETECT hd64461: IC_memory = 1 hd64461: setting status to SS_READY hd64461: setting status to SS_3VCARD hd64461: will return status = 10c0 flags = 0, csc_mask = 80, Vcc = 33 Vpp = 33 io_irq = 0 state->Vpp != sp->state.Vcc hd64461_set_voltage: 33 Vcc, 33 Vpp hd64461_set_socket: We've passed the routine successfully hd64461 : getting status from slot, b3 hd64461: setting status to SS_DETECT hd64461: IC_memory = 1 hd64461: setting status to SS_READY hd64461: setting status to SS_3VCARD hd64461: setting status to SS_POWERON hd64461: will return status = 11c0 flags = 240, csc_mask = 80, Vcc = 33 Vpp = 33 io_irq = 0 hd64461_set_socket: SS_RESET and state changed hd64461_set_socket: SS_OUTPUT_ENA and state changed hd64461_set_socket: We've passed the routine successfully flags = 200, csc_mask = 80, Vcc = 33 Vpp = 33 io_irq = 0 hd64461_set_socket: SS_RESET and state changed hd64461_set_socket: We've passed the routine successfully hd64461_interrupt: we are pushing changed events! events=64 hd64461 : getting status from slot, b3 hd64461: setting status to SS_DETECT hd64461: IC_memory = 1 hd64461: setting status to SS_READY hd64461: setting status to SS_3VCARD hd64461: setting status to SS_POWERON hd64461: will return status = 11c0 pccard: PCMCIA card inserted into slot 0 sock=0, map=0 flags=0x21 static_start=0x, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem->static_start = saddr
[HD64461_PCMCIA_driver] - Shared IRQ lines / Segfaults
Greetings, Driver detects card insertion / ejection and sets power properly. The mapping looks resonable also compairing to a working 2.6.17 driver. However when manually modprobing drivers I either get a segmentation fault or problems with IRQ shared lines. Any suggestesions? Best wishes Kristoffer Insert Card Log : hd64461_interrupt: we are pushing changed events! events=64 hd64461_interrupt: Passing SS_DETECT to events hd64461_interrupt: cscr changed due to [HD6446x_PCC0ISR] HD6446x_PCCISR_MASK = true hd64461_interrupt: we are pushing changed events! events=128 hd64461 : getting status from slot, b7 hd64461: will return status = 0 hd64461_interrupt: Passing SS_DETECT to events hd64461_interrupt: cscr changed due to [HD6446x_PCC0ISR] HD6446x_PCCISR_MASK = true hd64461_interrupt: we are pushing changed events! events=128 hd64461 : getting status from slot, b3 hd64461: setting status to SS_DETECT hd64461: IC_memory = 1 hd64461: setting status to SS_READY hd64461: setting status to SS_3VCARD hd64461: will return status = 10c0 hd64461 : getting status from slot, b3 hd64461: setting status to SS_DETECT hd64461: IC_memory = 1 hd64461: setting status to SS_READY hd64461: setting status to SS_3VCARD hd64461: will return status = 10c0 hd64461 : getting status from slot, b3 hd64461: setting status to SS_DETECT hd64461: IC_memory = 1 hd64461: setting status to SS_READY hd64461: setting status to SS_3VCARD hd64461: will return status = 10c0 flags = 0, csc_mask = 80, Vcc = 33 Vpp = 33 io_irq = 0 state-Vpp != sp-state.Vcc hd64461_set_voltage: 33 Vcc, 33 Vpp hd64461_set_socket: We've passed the routine successfully hd64461 : getting status from slot, b3 hd64461: setting status to SS_DETECT hd64461: IC_memory = 1 hd64461: setting status to SS_READY hd64461: setting status to SS_3VCARD hd64461: setting status to SS_POWERON hd64461: will return status = 11c0 flags = 240, csc_mask = 80, Vcc = 33 Vpp = 33 io_irq = 0 hd64461_set_socket: SS_RESET and state changed hd64461_set_socket: SS_OUTPUT_ENA and state changed hd64461_set_socket: We've passed the routine successfully flags = 200, csc_mask = 80, Vcc = 33 Vpp = 33 io_irq = 0 hd64461_set_socket: SS_RESET and state changed hd64461_set_socket: We've passed the routine successfully hd64461_interrupt: we are pushing changed events! events=64 hd64461 : getting status from slot, b3 hd64461: setting status to SS_DETECT hd64461: IC_memory = 1 hd64461: setting status to SS_READY hd64461: setting status to SS_3VCARD hd64461: setting status to SS_POWERON hd64461: will return status = 11c0 pccard: PCMCIA card inserted into slot 0 sock=0, map=0 flags=0x21 static_start=0x, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x hd64461: settings pointers smem to 8d2ee4bc and saddr to b800 hd64461: mem-static_start = saddr (b800) sock=0,
Re: [HD64461_PCMCIA_driver] - Shared IRQ lines / Segfaults
On Wed, 30 Jan 2008 14:05:59 +0100 Manuel Lauss [EMAIL PROTECTED] wrote: On Wed, Jan 30, 2008 at 01:20:36PM +0100, Kristoffer Ericson wrote: Greetings, Driver detects card insertion / ejection and sets power properly. The mapping looks resonable also compairing to a working 2.6.17 driver. modprobe hostap_cs hostap_cs: Registered netdevice wifi0 Unable to handle kernel NULL pointer dereference at virtual address 0028 pc = 8d0031b8 *pde = Oops: [#1] Modules linked in: hostap_cs hostap orinoco_cs orinoco hermes atmel_cs atmel Pid : 283, Comm: modprobe PC is at generic_inw+0x8/0x20 PC : 8d0031b8 SP : 8ecaba74 SR : 40f0 TEA : c0045040Not tainted R0 : 0028 R1 : 8d2d9030 R2 : 8d2ac050 R3 : 0007 R4 : 0028 R5 : 0002 R6 : 0080 R7 : 8ecf06a0 R8 : 8ee62000 R9 : 8a32 R10 : c002a1b0 R11 : 8ee62000 R12 : 0080 R13 : 8ee62000 R14 : 8ecf06a0 MACH: 458f MACL: 1110 GBR : 296ce450 PR : 8d0031b8 Call trace: [c002a1fa] prism2_interrupt+0x4a/0xc50 [hostap_cs] The oops output suggests it crashes in drivers/net/wireless/hostap/hostap_hw.c::prism2_check_magic(), specifically when it tries to read the HF384X_SWSUPPORT0_OFF register (which ist at offset 0x28, just like the oopsing address). So, looking at the HFA384X_INW macro, it seems dev-base_addr is NULL. I suspect this is because of set_io_map() callback in the hd64461.c socket driver. The comment there says IO area is statically mapped, yet it returns null; I suggest you let it return the base address of the IO area instead. I tried returning the base IO area but didn't make any difference. I took a look at some other pcmcia drivers set_io_map and it looks it should only return 0 on success. When setting up the socket I define socket-io_offset = 0xba00 which it should use. A bit lost why it doesn't get used though. Its the only IO area so thats why its static. Perhaps the io_offset is ment to be used with base_addr? -- Manuel Lauss -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [HD64461_PCMCIA_driver] - Shared IRQ lines / Segfaults
On Wed, 30 Jan 2008 14:05:59 +0100 Manuel Lauss [EMAIL PROTECTED] wrote: On Wed, Jan 30, 2008 at 01:20:36PM +0100, Kristoffer Ericson wrote: Greetings, Driver detects card insertion / ejection and sets power properly. The mapping looks resonable also compairing to a working 2.6.17 driver. modprobe hostap_cs hostap_cs: Registered netdevice wifi0 Unable to handle kernel NULL pointer dereference at virtual address 0028 pc = 8d0031b8 *pde = Oops: [#1] Modules linked in: hostap_cs hostap orinoco_cs orinoco hermes atmel_cs atmel Pid : 283, Comm: modprobe PC is at generic_inw+0x8/0x20 PC : 8d0031b8 SP : 8ecaba74 SR : 40f0 TEA : c0045040Not tainted R0 : 0028 R1 : 8d2d9030 R2 : 8d2ac050 R3 : 0007 R4 : 0028 R5 : 0002 R6 : 0080 R7 : 8ecf06a0 R8 : 8ee62000 R9 : 8a32 R10 : c002a1b0 R11 : 8ee62000 R12 : 0080 R13 : 8ee62000 R14 : 8ecf06a0 MACH: 458f MACL: 1110 GBR : 296ce450 PR : 8d0031b8 Call trace: [c002a1fa] prism2_interrupt+0x4a/0xc50 [hostap_cs] The oops output suggests it crashes in drivers/net/wireless/hostap/hostap_hw.c::prism2_check_magic(), specifically when it tries to read the HF384X_SWSUPPORT0_OFF register (which ist at offset 0x28, just like the oopsing address). So, looking at the HFA384X_INW macro, it seems dev-base_addr is NULL. I suspect this is because of set_io_map() callback in the hd64461.c socket driver. The comment there says IO area is statically mapped, yet it returns null; I suggest you let it return the base address of the IO area instead. I've tried changing the s-io_offset = 0xf000 just to see if I get any reactions. The result is that now orinoco_cs segfaults, which it more or less should. Correct s-io_offset gives : Segfault in hostap_cs Bad s-io_offset gives : Segfault in orinoco_cs Segfault in hostap_cs So basicly, the segfault in hostap_cs is not dependant on my io_offset at all.. :( Orinoco_cs log : sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x pcmcia: request for exclusive IRQ could not be fulfilled. pcmcia: the driver needs updating to supported shared IRQ lines. flags = 200, csc_mask = 80, Vcc = 33 Vpp = 0 io_irq = 0 state-Vpp != sp-state.Vcc hd64461_set_voltage: 33 Vcc, 0 Vpp flags = 220, csc_mask = 80, Vcc = 33 Vpp = 0 io_irq = 78 hd64461_set_socket: SS_IOCARD and state changed hd64461_set_socket: Lets reset and set to IO card sock=0, map=0 flags=0x21 static_start=0xb800, card_start=0x Unable to handle kernel paging request at virtual address f032 pc = 8d0034f2 *pde = Oops: 0001 [#1] Modules linked in: orinoco_cs orinoco hermes Pid : 265, Comm: modprobe PC is at generic_writew+0x2/0x10 PC : 8d0034f2 SP : 8ec25960 SR : 4000 TEA : c00205c4Not tainted R0 : c001f0d0 R1 : 0032 R2 : 8d0034f0 R3 : R4 : R5 : f032 R6 : 0004 R7 : 000b R8 : 8ece617c R9 : 8ece6000 R10 : 00c4 R11 : 8ece6424 R12 : 8ece6000 R13 : 8d2ac090 R14 : MACH: 7df8 MACL: 01936912 GBR : 296ce450 PR : c001f0fc Call trace: [c0002f0c] orinoco_init+0x2c/0xbb0 [orinoco] [8d111fbe] vsnprintf+0x35e/0x570 [8d007024] call_dpf+0x10/0x30 [c0002ee0] orinoco_init+0x0/0xbb0 [orinoco] [8d1962c6] register_netdevice+0x56/0x3f0 [8d19668c] register_netdev+0x2c/0x60 [c000c53a] orinoco_cs_probe+0x38a/0x450 [orinoco_cs] [8d08a340] sync_buffer+0x0/0x50 [8d22f354] out_of_line_wait_on_bit+0x54/0x70 [8d101046] get_request+0xa6/0x310 [8d10111a] get_request+0x17a/0x310 [8d106e01] as_find_next_rq+0xb1/0xc0 [8d0f0076] ipcget_public+0x116/0x1a0 [8d107df0] as_add_request+0x50/0x150 [8d02eafc] update_wall_time+0x2dc/0x7e0 [8d02eb34] update_wall_time+0x314/0x7e0 [8d00ccc8] task_tick_fair+0x48/0xc0 [8d00ddc0] scheduler_tick+0x90/0x100 [8d02e214] getnstimeofday+0x64/0x100 [8d112c90] __lshrdi3+0x0/0x50 [8d02b5ea] ktime_get_ts+0x1a/0x60 [8d02b630] ktime_get+0x0/0x20 [8d02bb90] __remove_hrtimer+0x0/0xa0 [8d02e1b0] getnstimeofday+0x0/0x100 [8d0310ea] clockevents_program_event+0x9a/0x140 [8d02b630] ktime_get+0x0/0x20 [8d0310f2] clockevents_program_event+0xa2/0x140 [8d031ac4] tick_program_event+0x34/0xb0 [8d031050] clockevents_program_event+0x0/0x140 [8d0200aa] sys_rt_sigtimedwait+0x18a/0x280 [8d01ca02] free_uid+0x22/0x120 [8d00f7c2] __put_task_struct+0x32/0xd0 [8d00f766] free_task+0x16/0x40 [8d025ae6] __rcu_process_callbacks+0x56/0x280 [8d025d1e] rcu_process_callbacks+0xe/0x30 [8d018a66] tasklet_action+0x86/0xf0 [8d0184e8] __do_softirq+0x58/0xe0 [8d0185d6] do_softirq+0x66/0x80 [8d106e01] as_find_next_rq+0xb1/0xc0 [8d0f0076] ipcget_public+0x116/0x1a0 [8d107df0] as_add_request+0x50/0x150 [8d02eafc] update_wall_time+0x2dc/0x7e0 [8d02eb34] update_wall_time+0x314/0x7e0 [8d00ccc8] task_tick_fair+0x48/0xc0 [8d00ddc0] scheduler_tick+0x90/0x100 [8d02e214] getnstimeofday+0x64/0x100 [8d112c90] __lshrdi3
Re: Kernel crash in 2.6.21
On Tue, 29 Jan 2008 12:38:43 -0500 Jerry Geis <[EMAIL PROTECTED]> wrote: > Below is a kernel crash for 2.6.21 > > The kernel runs for a number of days/weeks and then the crash below. > I am not running X windows. Just a server. Without knowing much about the issue I would suggest you compile a fresh 2.6.24 kernel and see if the issue remains. If it does people will be alot more eager to help out. Best wishes Kristoffer > > Jerry > > --- > > 00:00.0 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a1) > 00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2) > 00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2) > 00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2) > 00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3) > 00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3) > 00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1) > 00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio > (rev a2) > 00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2) > 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) > 00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2) > 00:08.1 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2) > 00:0d.0 VGA compatible controller: nVidia Corporation GeForce 6100 > nForce 430 (rev a2) > 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > HyperTransport Technology Configuration > 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Address Map > 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > DRAM Controller > 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Miscellaneous Control > 01:08.0 Ethernet controller: Digium, Inc. Wildcard TDM800P 8-port analog > card (rev 11) > 01:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 > IEEE-1394a-2000 Controller (PHY/Link) > > Module Size Used by > ipv6 447328 18 > autofs457992 0 > sunrpc213480 1 > iptable_filter 36736 0 > ip_tables 55888 1 iptable_filter > x_tables 54664 1 ip_tables > dm_mirror 55488 0 > dm_mod 95632 1 dm_mirror > video 52880 0 > button 42528 0 > battery44680 0 > asus_acpi 52268 0 > ac 39432 0 > ohci_hcd 55172 0 > ehci_hcd 67980 0 > snd_hda_intel 55840 4 > snd_hda_codec 289096 1 snd_hda_intel > snd_pcm_oss78080 0 > snd_mixer_oss 50560 1 snd_pcm_oss > snd_pcm 118920 5 snd_hda_intel,snd_hda_codec,snd_pcm_oss > snd_timer 57992 3 snd_pcm > snd96680 10 > snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer > soundcore 42272 1 snd > snd_page_alloc 43920 2 snd_hda_intel,snd_pcm > wctdm24xxp144704 2 > zaptel230088 7 wctdm24xxp > crc_ccitt 35712 1 zaptel > forcedeth 81160 0 > ide_cd 74784 0 > cdrom 69800 1 ide_cd > ext3 164752 2 > jbd96880 1 ext3 > raid1 56832 2 > sata_nv54916 6 > libata155168 1 sata_nv > sd_mod 54272 8 > scsi_mod 189496 2 libata,sd_mod > > Running Centos 4.6 x86_64. > > Jan 26 04:05:28 ksdsigns kernel: CR2: 007ac000 CR3: > 3b2cd000 CR4: 06e0 > Jan 26 04:05:28 ksdsigns kernel: Process prelink (pid: 29143, threadinfo > 81004d83, task 810033a61780) > Jan 26 04:05:28 ksdsigns kernel: Stack: 00776ca0 > 1000 81004d831bb8 > Jan 26 04:05:28 ksdsigns kernel: 00775ca0 8100f933 > 81007bfd9380 810035700780 > Jan 26 04:05:28 ksdsigns kernel: 0012 810035700780 > 880b1440 810035700890 > Jan 26 04:05:28 ksdsigns kernel: Call Trace: > Jan 26 04:05:28 ksdsigns kernel: [] > generic_file_buffered_write+0x18b/0x6d4 > Jan 26 04:05:28 ksdsigns kernel: [] > __generic_file_aio_write_nolock+0x403/0x436 > Jan 26 04:05:28 ksdsigns kernel: [] __getblk+0x24/0x213 > Jan 26 04:05:28 ksdsigns kernel: [] > :ext3:__ext3_journal_dirty_metadata+0x1b/0x45 > Jan 26 04:05:28 ksdsigns kernel: [] > generic_file_aio_write+0x61/0xc1 > Jan 26 04:05:28 ksdsigns kernel: [] > :ext3:ext3_file_write+0x16/0x9d > Jan 26 04:05:28 ksdsigns kernel: [] > do_sync_write+0xc8/0x10b > Jan 26 04:05:28 ksdsigns kernel: [] > autoremove_wake_function+0x0/0x2e > Jan 26 04:05:28 ksdsigns kernel: [] > notify_change+0x307/0x319 > Jan 26 04:05:28 ksdsigns kernel: [] vfs_write+0xd4/0x158 > Jan 26 04:05:28 ksdsigns kernel: [] >
Re: Kernel crash in 2.6.21
On Tue, 29 Jan 2008 12:38:43 -0500 Jerry Geis [EMAIL PROTECTED] wrote: Below is a kernel crash for 2.6.21 The kernel runs for a number of days/weeks and then the crash below. I am not running X windows. Just a server. Without knowing much about the issue I would suggest you compile a fresh 2.6.24 kernel and see if the issue remains. If it does people will be alot more eager to help out. Best wishes Kristoffer Jerry --- 00:00.0 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a1) 00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2) 00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2) 00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3) 00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3) 00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1) 00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) 00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2) 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) 00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2) 00:08.1 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2) 00:0d.0 VGA compatible controller: nVidia Corporation GeForce 6100 nForce 430 (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:08.0 Ethernet controller: Digium, Inc. Wildcard TDM800P 8-port analog card (rev 11) 01:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) Module Size Used by ipv6 447328 18 autofs457992 0 sunrpc213480 1 iptable_filter 36736 0 ip_tables 55888 1 iptable_filter x_tables 54664 1 ip_tables dm_mirror 55488 0 dm_mod 95632 1 dm_mirror video 52880 0 button 42528 0 battery44680 0 asus_acpi 52268 0 ac 39432 0 ohci_hcd 55172 0 ehci_hcd 67980 0 snd_hda_intel 55840 4 snd_hda_codec 289096 1 snd_hda_intel snd_pcm_oss78080 0 snd_mixer_oss 50560 1 snd_pcm_oss snd_pcm 118920 5 snd_hda_intel,snd_hda_codec,snd_pcm_oss snd_timer 57992 3 snd_pcm snd96680 10 snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer soundcore 42272 1 snd snd_page_alloc 43920 2 snd_hda_intel,snd_pcm wctdm24xxp144704 2 zaptel230088 7 wctdm24xxp crc_ccitt 35712 1 zaptel forcedeth 81160 0 ide_cd 74784 0 cdrom 69800 1 ide_cd ext3 164752 2 jbd96880 1 ext3 raid1 56832 2 sata_nv54916 6 libata155168 1 sata_nv sd_mod 54272 8 scsi_mod 189496 2 libata,sd_mod Running Centos 4.6 x86_64. Jan 26 04:05:28 ksdsigns kernel: CR2: 007ac000 CR3: 3b2cd000 CR4: 06e0 Jan 26 04:05:28 ksdsigns kernel: Process prelink (pid: 29143, threadinfo 81004d83, task 810033a61780) Jan 26 04:05:28 ksdsigns kernel: Stack: 00776ca0 1000 81004d831bb8 Jan 26 04:05:28 ksdsigns kernel: 00775ca0 8100f933 81007bfd9380 810035700780 Jan 26 04:05:28 ksdsigns kernel: 0012 810035700780 880b1440 810035700890 Jan 26 04:05:28 ksdsigns kernel: Call Trace: Jan 26 04:05:28 ksdsigns kernel: [8100f933] generic_file_buffered_write+0x18b/0x6d4 Jan 26 04:05:28 ksdsigns kernel: [81015a14] __generic_file_aio_write_nolock+0x403/0x436 Jan 26 04:05:28 ksdsigns kernel: [81018bdf] __getblk+0x24/0x213 Jan 26 04:05:28 ksdsigns kernel: [880ae87a] :ext3:__ext3_journal_dirty_metadata+0x1b/0x45 Jan 26 04:05:28 ksdsigns kernel: [81020961] generic_file_aio_write+0x61/0xc1 Jan 26 04:05:28 ksdsigns kernel: [880a11b1] :ext3:ext3_file_write+0x16/0x9d Jan 26 04:05:28 ksdsigns kernel: [8101750d] do_sync_write+0xc8/0x10b Jan 26 04:05:28 ksdsigns kernel: [81098987] autoremove_wake_function+0x0/0x2e Jan 26 04:05:28 ksdsigns kernel: [8102b870] notify_change+0x307/0x319 Jan 26 04:05:28 ksdsigns kernel: [81015de8] vfs_write+0xd4/0x158 Jan
[HD64461] Pcmcia driver and Vcc/Vpp issues
Greetings, FYI: Porting/rewriting a pcmcia driver that was working in 2.6.17 (PIO-based) to work on 2.6.24 (MMIO-based) and haven't been able to make it work yet. I've used the good driver to extract values to compair against the new driver. Bugtracked the issue abit more and found 2 strange factors. 1) Working 2.6.17 driver sets Vcc/Vpp = 30 while 2.6.24 sets it to 50 (using same card) 2) Working 2.6.17 driver uses 2->4 mem_maps while 2.6.24 only uses 1 (bad MAX_WIN?) Other than that the output seems equal. Any ideas? Best wishes Kristoffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[HD64461] Pcmcia driver and Vcc/Vpp issues
Greetings, FYI: Porting/rewriting a pcmcia driver that was working in 2.6.17 (PIO-based) to work on 2.6.24 (MMIO-based) and haven't been able to make it work yet. I've used the good driver to extract values to compair against the new driver. Bugtracked the issue abit more and found 2 strange factors. 1) Working 2.6.17 driver sets Vcc/Vpp = 30 while 2.6.24 sets it to 50 (using same card) 2) Working 2.6.17 driver uses 2-4 mem_maps while 2.6.24 only uses 1 (bad MAX_WIN?) Other than that the output seems equal. Any ideas? Best wishes Kristoffer -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(RESEND) [HP6XX] - Still issues with pcmcia driver (HD64461)
Unable to get any respons from the linux-pcmcia list so putting this in main.
Must be some pcmcia guru out there.
Greetings,
I'm getting nowhere with this.
IRQ 78 using IRQF_SHARED to handle both socket and inserted pcmcia card. I've
set so socket interrupt returns IRQ_NONE when it sees that it belongs to
PCMCIA_CARD_IRQ. This should mean that the interrupt should dropped from socket
interrupt and be taken up by the card interrupt handler.
For whatever reason the pcmcia subsystem hasn't setup any PCMCIA_CARD_IRQ
handler and I get a kernel panic "irq 78: nobody cared (try booting with the
"irqpoll" option)".
In /sys/devices/platform/hd64461-pcmcia/ I see :
driver, modalias, power, pcmcia_socket, subsystem, uevent. And I know that
pcmcia_register_socket is successfull.
If I remove the IRQ_NONE return but still only handle the SOCKET_IRQ requests
it detects insertion / removal properly but obviously non-working.
In short, I need to make sure the PCMCIA_CARD_IRQ is properly setup by the
pcmcia_subsystem (or manually request it in driver).
Best wishes
Kristoffer Ericson
/*
* drivers/pcmcia/hd64461_ss.c
*
* PCMCIA platform driver for Hitachi HD64461 companion chip
* Copyright (C) 2006-2007 Kristoffer Ericson <[EMAIL PROTECTED]>
*
* This driver is based on hd64461_ss.c that was maintained in LinuxSH cvs
before merger with mainline
* by
* COPYRIGHT (C) 2002-2005 Andriy Skulysh <[EMAIL PROTECTED]>
* COPYRIGHT (C) ? Greg Banks <[EMAIL PROTECTED]>
* COPYRIGHT (C) 2000 YAEGASHI Takeshi
*
* Please note that although the hd64461 chipset supports two sockets (0 & 1)
this driver only
* supports the PCMCIA one. The CF slot cannot handle anything other than
memory cards, so its
* better to leave support for that on libata.
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "cs_internal.h"
#include
#include
#include
#define MODNAME "HD64461_ss"
/*
*
* Our socket implementation
**/
typedef struct hd64461_socket_t {
u8 cscier;
unsigned intirq;
unsigned long mem_base;
socket_state_t state;
pccard_mem_map mem_maps[MAX_WIN];
unsigned char IC_memory;
struct pcmcia_socketsocket;
} hd64461_socket_t;
/* socket declaration */
static hd64461_socket_t hd64461_sockets[CONFIG_HD64461_PCMCIA_SOCKETS];
/*
* hd64461_set_voltage(int Vcc, int Vpp)
*
* returns : %1 on success (no error checking!)
*/
static int hd64461_set_voltage(int Vcc, int Vpp)
{
u8 gcr, scr;
u16 stbcr;
u32 gcr_reg = HD64461_PCC0GCR;
u32 scr_reg = HD64461_PCC0SCR;
gcr = inb(gcr_reg);
scr = inb(scr_reg);
/* Handling voltage control pins */
switch (Vcc) {
case 0:
gcr |= HD64461_PCCGCR_VCC0;
scr |= HD64461_PCCSCR_VCC1;
break;
case 33:
gcr |= HD64461_PCCGCR_VCC0;
scr &= ~HD64461_PCCSCR_VCC1;
break;
case 50:
gcr &= ~HD64461_PCCGCR_VCC0;
scr &= ~HD64461_PCCSCR_VCC1;
break;
}
outb(gcr, gcr_reg);
outb(scr, scr_reg);
stbcr = inw(HD64461_STBCR);
if (Vcc > 0) {
stbcr &= ~HD64461_STBCR_SPC0ST;
} else {
stbcr |= HD64461_STBCR_SPC0ST;
}
outw(stbcr, HD64461_STBCR);
return 1;
}
static int hd64461_init(struct pcmcia_socket *s)
{
u16 gpadr;
hd64461_socket_t *sp = container_of(s, struct hd64461_socket_t, socket);
printk(KERN_INFO "hd64461_ss: entering hd64461_init from
pcmcia_register_socket\n");
sp->state.Vcc = 0;
sp->state.Vpp = 0;
hd64461_set_voltage(0, 0);
gpadr = inw(HD64461_GPADR);
gpadr &= ~HD64461_GPADR_PCMCIA0;
outw(gpadr, HD64461_GPADR);
return 0;
}
static int hd64461_suspend(struct pcmcia_socket *s)
{
u16 gpadr;
u8 gcr;
u32 gcr_reg = HD64461_PCC0GCR;
gcr = inb(gcr_reg);
gcr &= ~HD64461_PCCGCR_DRVE;
outb(gcr, gcr_reg);
hd64461_set_voltage(0, 0);
gpadr = inw(HD64461_GPADR);
gpadr |= HD64461_GPADR_PCMCIA0;
outw(gpadr, HD64461_GPADR);
return 0;
}
/*
* hd64461_get_status(struct pcmcia_socket *s, u32 * value)
*
*
*/
static int hd64461_get_status(struct pcmcia_socket *s, u32 *value)
{
u8 isr;
u32 status = 0;
hd64461_socket_t *sp = container_of(s, struct hd64461_socket_t, socket);
/* get status of pcmcia socket */
isr = inb(HD64461_PCC0ISR);
printk
(RESEND) [HP6XX] - Still issues with pcmcia driver (HD64461)
Unable to get any respons from the linux-pcmcia list so putting this in main.
Must be some pcmcia guru out there.
Greetings,
I'm getting nowhere with this.
IRQ 78 using IRQF_SHARED to handle both socket and inserted pcmcia card. I've
set so socket interrupt returns IRQ_NONE when it sees that it belongs to
PCMCIA_CARD_IRQ. This should mean that the interrupt should dropped from socket
interrupt and be taken up by the card interrupt handler.
For whatever reason the pcmcia subsystem hasn't setup any PCMCIA_CARD_IRQ
handler and I get a kernel panic irq 78: nobody cared (try booting with the
irqpoll option).
In /sys/devices/platform/hd64461-pcmcia/ I see :
driver, modalias, power, pcmcia_socket, subsystem, uevent. And I know that
pcmcia_register_socket is successfull.
If I remove the IRQ_NONE return but still only handle the SOCKET_IRQ requests
it detects insertion / removal properly but obviously non-working.
In short, I need to make sure the PCMCIA_CARD_IRQ is properly setup by the
pcmcia_subsystem (or manually request it in driver).
Best wishes
Kristoffer Ericson
/*
* drivers/pcmcia/hd64461_ss.c
*
* PCMCIA platform driver for Hitachi HD64461 companion chip
* Copyright (C) 2006-2007 Kristoffer Ericson [EMAIL PROTECTED]
*
* This driver is based on hd64461_ss.c that was maintained in LinuxSH cvs
before merger with mainline
* by
* COPYRIGHT (C) 2002-2005 Andriy Skulysh [EMAIL PROTECTED]
* COPYRIGHT (C) ? Greg Banks [EMAIL PROTECTED]
* COPYRIGHT (C) 2000 YAEGASHI Takeshi
*
* Please note that although the hd64461 chipset supports two sockets (0 1)
this driver only
* supports the PCMCIA one. The CF slot cannot handle anything other than
memory cards, so its
* better to leave support for that on libata.
*
*/
#include linux/autoconf.h
#include linux/types.h
#include linux/module.h
#include linux/init.h
#include linux/string.h
#include linux/kernel.h
#include linux/ioport.h
#include linux/mm.h
#include linux/vmalloc.h
#include linux/irq.h
#include linux/interrupt.h
#include linux/platform_device.h
#include pcmcia/cs_types.h
#include pcmcia/cs.h
#include pcmcia/ss.h
#include pcmcia/bulkmem.h
#include pcmcia/cistpl.h
#include cs_internal.h
#include asm/io.h
#include asm/hd64461.h
#include asm/hp6xx.h
#define MODNAME HD64461_ss
/*
*
* Our socket implementation
**/
typedef struct hd64461_socket_t {
u8 cscier;
unsigned intirq;
unsigned long mem_base;
socket_state_t state;
pccard_mem_map mem_maps[MAX_WIN];
unsigned char IC_memory;
struct pcmcia_socketsocket;
} hd64461_socket_t;
/* socket declaration */
static hd64461_socket_t hd64461_sockets[CONFIG_HD64461_PCMCIA_SOCKETS];
/*
* hd64461_set_voltage(int Vcc, int Vpp)
*
* returns : %1 on success (no error checking!)
*/
static int hd64461_set_voltage(int Vcc, int Vpp)
{
u8 gcr, scr;
u16 stbcr;
u32 gcr_reg = HD64461_PCC0GCR;
u32 scr_reg = HD64461_PCC0SCR;
gcr = inb(gcr_reg);
scr = inb(scr_reg);
/* Handling voltage control pins */
switch (Vcc) {
case 0:
gcr |= HD64461_PCCGCR_VCC0;
scr |= HD64461_PCCSCR_VCC1;
break;
case 33:
gcr |= HD64461_PCCGCR_VCC0;
scr = ~HD64461_PCCSCR_VCC1;
break;
case 50:
gcr = ~HD64461_PCCGCR_VCC0;
scr = ~HD64461_PCCSCR_VCC1;
break;
}
outb(gcr, gcr_reg);
outb(scr, scr_reg);
stbcr = inw(HD64461_STBCR);
if (Vcc 0) {
stbcr = ~HD64461_STBCR_SPC0ST;
} else {
stbcr |= HD64461_STBCR_SPC0ST;
}
outw(stbcr, HD64461_STBCR);
return 1;
}
static int hd64461_init(struct pcmcia_socket *s)
{
u16 gpadr;
hd64461_socket_t *sp = container_of(s, struct hd64461_socket_t, socket);
printk(KERN_INFO hd64461_ss: entering hd64461_init from
pcmcia_register_socket\n);
sp-state.Vcc = 0;
sp-state.Vpp = 0;
hd64461_set_voltage(0, 0);
gpadr = inw(HD64461_GPADR);
gpadr = ~HD64461_GPADR_PCMCIA0;
outw(gpadr, HD64461_GPADR);
return 0;
}
static int hd64461_suspend(struct pcmcia_socket *s)
{
u16 gpadr;
u8 gcr;
u32 gcr_reg = HD64461_PCC0GCR;
gcr = inb(gcr_reg);
gcr = ~HD64461_PCCGCR_DRVE;
outb(gcr, gcr_reg);
hd64461_set_voltage(0, 0);
gpadr = inw(HD64461_GPADR);
gpadr |= HD64461_GPADR_PCMCIA0;
outw(gpadr, HD64461_GPADR);
return 0;
}
/*
* hd64461_get_status(struct pcmcia_socket *s, u32 * value)
*
*
*/
static int hd64461_get_status(struct pcmcia_socket *s, u32 *value)
{
u8 isr;
u32 status = 0;
hd64461_socket_t *sp
Re: [HP6XX/FIX/PATCH] - Fix bad default keymap in HP Jornada 6xx keyboard driver
On Thu, 13 Dec 2007 03:45:58 +0900 Paul Mundt <[EMAIL PROTECTED]> wrote: > On Wed, Dec 12, 2007 at 07:22:07PM +0100, Kristoffer Ericson wrote: > > shortlog: > > * This patch fixes the HP Jornada 6xx keyboard default keymap which had > > some bad keymap values. This resulted in wrong > > key being returned when pressed (example : key y returned 'r'). > > * Also, while we are at it lets arrange the include files in alphabetical > > order. > > > You do realize that the default keymap was written for the Japanese units > and the Japanese keyboards, right? From the looks of it, you are just > trying to swap one functional set for another. I can assure you that this > keymap worked fine on the Japanese units, so calling it a bug is a bit > misleading. Mostly true yes. However a few errors entered simply due to me copying the keymap poorly in the initial keymap. So it does infact have 'bug' keys that wouldn't work properly on neither japanese / european / US jornadas. And whatever functional set, this patch fixes those bugs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[HP6XX/FIX/PATCH] - Fix bad default keymap in HP Jornada 6xx keyboard driver
Greetings,
Dmitry, any chance of getting this into the RC since its really a bugfix?
Anyhow, compiled cleanly with patch applied.
shortlog:
* This patch fixes the HP Jornada 6xx keyboard default keymap which had some
bad keymap values. This resulted in wrong
key being returned when pressed (example : key y returned 'r').
* Also, while we are at it lets arrange the include files in alphabetical order.
signed-off-by: Kristoffer Ericson <[EMAIL PROTECTED]>
diff --git a/drivers/input/keyboard/jornada680_kbd.c
b/drivers/input/keyboard/jornada680_kbd.c
index bec1cf4..a23633a 100644
--- a/drivers/input/keyboard/jornada680_kbd.c
+++ b/drivers/input/keyboard/jornada680_kbd.c
@@ -16,14 +16,14 @@
* published by the Free Software Foundation.
*/
-#include
-#include
-#include
#include
+#include
#include
+#include
#include
+#include
+#include
#include
-#include
#include
#include
@@ -43,22 +43,22 @@
#define PLDR 0xa4000134
static const unsigned short jornada_scancodes[] = {
-/* PTD1 */ KEY_CAPSLOCK, KEY_MACRO, KEY_LEFTCTRL, 0, KEY_ESC, 0, 0, 0,
/* 1 -> 8 */
- KEY_F1, KEY_F2, KEY_F3, KEY_F8, KEY_F7, KEY_F2, KEY_F4, KEY_F5,
/* 9 -> 16 */
-/* PTD5 */ KEY_SLASH, KEY_APOSTROPHE, KEY_ENTER, 0, KEY_Z, 0, 0, 0,
/* 17 -> 24 */
- KEY_X, KEY_C, KEY_V, KEY_DOT, KEY_COMMA, KEY_M, KEY_B, KEY_N,
/* 25 -> 32 */
-/* PTD7 */ KEY_KP2, KEY_KP6, 0, 0, 0, 0, 0, 0,
/* 33 -> 40 */
- 0, 0, 0, KEY_KP4, 0, 0, KEY_LEFTALT, KEY_HANJA,
/* 41 -> 48 */
-/* PTE0 */ 0, 0, 0, 0, KEY_FINANCE, 0, 0, 0,
/* 49 -> 56 */
- KEY_LEFTCTRL, 0, KEY_SPACE, KEY_KPDOT, KEY_VOLUMEUP, 249, 0, 0,
/* 57 -> 64 */
-/* PTE1 */ KEY_SEMICOLON, KEY_RIGHTBRACE, KEY_BACKSLASH, 0, KEY_A, 0, 0,
0,/* 65 -> 72 */
- KEY_S, KEY_D, KEY_F, KEY_L, KEY_K, KEY_J, KEY_G, KEY_H,
/* 73 -> 80 */
-/* PTE3 */ KEY_KP8, KEY_LEFTMETA, KEY_RIGHTSHIFT, 0, KEY_TAB, 0, 0,0,
/* 81 -> 88 */
- 0, KEY_LEFTSHIFT, 0, 0, 0, 0, 0, 0,
/* 89 -> 96 */
-/* PTE6 */ KEY_P, KEY_LEFTBRACE, KEY_BACKSPACE, 0, KEY_Q, 0, 0, 0,
/* 97 -> 104 */
- KEY_W, KEY_E, KEY_R, KEY_O, KEY_I, KEY_U, KEY_T, KEY_R,
/* 105 -> 112 */
-/* PTE7 */ KEY_0, KEY_MINUS, KEY_EQUAL, 0, KEY_1, 0, 0, 0,
/* 113 -> 120 */
- KEY_2, KEY_3, KEY_4, KEY_9, KEY_8, KEY_7, KEY_5, KEY_6,
/* 121 -> 128 */
+/* PTD1 */ KEY_CAPSLOCK, KEY_MACRO, KEY_LEFTCTRL, 0, KEY_ESC, KEY_KP5, 0,
0, /* 1 -> 8 */
+ KEY_F1, KEY_F2, KEY_F3, KEY_F8, KEY_F7, KEY_F6, KEY_F4, KEY_F5,
/* 9 -> 16 */
+/* PTD5 */ KEY_SLASH, KEY_APOSTROPHE, KEY_ENTER, 0, KEY_Z, 0, 0, 0,
/* 17 -> 24 */
+ KEY_X, KEY_C, KEY_V, KEY_DOT, KEY_COMMA, KEY_M, KEY_B, KEY_N,
/* 25 -> 32 */
+/* PTD7 */ KEY_KP2, KEY_KP6, KEY_KP3, 0, 0, 0, 0, 0,
/* 33 -> 40 */
+ KEY_F10, KEY_RO, KEY_F9, KEY_KP4, KEY_NUMLOCK, KEY_SCROLLLOCK,
KEY_LEFTALT, KEY_HANJA, /* 41 -> 48 */
+/* PTE0 */ KEY_KATAKANA, KEY_KP0, KEY_GRAVE, 0, KEY_FINANCE, 0, 0, 0,
/* 49 -> 56 */
+ KEY_KPMINUS, KEY_HIRAGANA, KEY_SPACE, KEY_KPDOT, KEY_VOLUMEUP,
249, 0, 0, /* 57 -> 64 */
+/* PTE1 */ KEY_SEMICOLON, KEY_RIGHTBRACE, KEY_BACKSLASH, 0, KEY_A, 0, 0,
0,/* 65 -> 72 */
+ KEY_S, KEY_D, KEY_F, KEY_L, KEY_K, KEY_J, KEY_G, KEY_H,
/* 73 -> 80 */
+/* PTE3 */ KEY_KP8, KEY_LEFTMETA, KEY_RIGHTSHIFT, 0, KEY_TAB, 0, 0, 0,
/* 81 -> 88 */
+ 0, KEY_LEFTSHIFT, KEY_KP7, KEY_KP9, KEY_KP1, KEY_F11,
KEY_KPPLUS, KEY_KPASTERISK, /* 89 -> 96 */
+/* PTE6 */ KEY_P, KEY_LEFTBRACE, KEY_BACKSPACE, 0, KEY_Q, 0, 0, 0,
/* 97 -> 104 */
+ KEY_W, KEY_E, KEY_R, KEY_O, KEY_I, KEY_U, KEY_T, KEY_Y,
/* 105 -> 112 */
+/* PTE7 */ KEY_0, KEY_MINUS, KEY_EQUAL, 0, KEY_1, 0, 0, 0,
/* 113 -> 120 */
+ KEY_2, KEY_3, KEY_4, KEY_9, KEY_8, KEY_7, KEY_5, KEY_6,
/* 121 -> 128 */
/* */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0
};
hp6xx-keyboard-keymap-fix.patch
Description: Binary data
[HP6XX/FIX/PATCH] - Fix bad default keymap in HP Jornada 6xx keyboard driver
Greetings,
Dmitry, any chance of getting this into the RC since its really a bugfix?
Anyhow, compiled cleanly with patch applied.
shortlog:
* This patch fixes the HP Jornada 6xx keyboard default keymap which had some
bad keymap values. This resulted in wrong
key being returned when pressed (example : key y returned 'r').
* Also, while we are at it lets arrange the include files in alphabetical order.
signed-off-by: Kristoffer Ericson [EMAIL PROTECTED]
diff --git a/drivers/input/keyboard/jornada680_kbd.c
b/drivers/input/keyboard/jornada680_kbd.c
index bec1cf4..a23633a 100644
--- a/drivers/input/keyboard/jornada680_kbd.c
+++ b/drivers/input/keyboard/jornada680_kbd.c
@@ -16,14 +16,14 @@
* published by the Free Software Foundation.
*/
-#include linux/input.h
-#include linux/kernel.h
-#include linux/module.h
#include linux/init.h
+#include linux/input.h
#include linux/input-polldev.h
+#include linux/interrupt.h
#include linux/jiffies.h
+#include linux/kernel.h
+#include linux/module.h
#include linux/platform_device.h
-#include linux/interrupt.h
#include asm/delay.h
#include asm/io.h
@@ -43,22 +43,22 @@
#define PLDR 0xa4000134
static const unsigned short jornada_scancodes[] = {
-/* PTD1 */ KEY_CAPSLOCK, KEY_MACRO, KEY_LEFTCTRL, 0, KEY_ESC, 0, 0, 0,
/* 1 - 8 */
- KEY_F1, KEY_F2, KEY_F3, KEY_F8, KEY_F7, KEY_F2, KEY_F4, KEY_F5,
/* 9 - 16 */
-/* PTD5 */ KEY_SLASH, KEY_APOSTROPHE, KEY_ENTER, 0, KEY_Z, 0, 0, 0,
/* 17 - 24 */
- KEY_X, KEY_C, KEY_V, KEY_DOT, KEY_COMMA, KEY_M, KEY_B, KEY_N,
/* 25 - 32 */
-/* PTD7 */ KEY_KP2, KEY_KP6, 0, 0, 0, 0, 0, 0,
/* 33 - 40 */
- 0, 0, 0, KEY_KP4, 0, 0, KEY_LEFTALT, KEY_HANJA,
/* 41 - 48 */
-/* PTE0 */ 0, 0, 0, 0, KEY_FINANCE, 0, 0, 0,
/* 49 - 56 */
- KEY_LEFTCTRL, 0, KEY_SPACE, KEY_KPDOT, KEY_VOLUMEUP, 249, 0, 0,
/* 57 - 64 */
-/* PTE1 */ KEY_SEMICOLON, KEY_RIGHTBRACE, KEY_BACKSLASH, 0, KEY_A, 0, 0,
0,/* 65 - 72 */
- KEY_S, KEY_D, KEY_F, KEY_L, KEY_K, KEY_J, KEY_G, KEY_H,
/* 73 - 80 */
-/* PTE3 */ KEY_KP8, KEY_LEFTMETA, KEY_RIGHTSHIFT, 0, KEY_TAB, 0, 0,0,
/* 81 - 88 */
- 0, KEY_LEFTSHIFT, 0, 0, 0, 0, 0, 0,
/* 89 - 96 */
-/* PTE6 */ KEY_P, KEY_LEFTBRACE, KEY_BACKSPACE, 0, KEY_Q, 0, 0, 0,
/* 97 - 104 */
- KEY_W, KEY_E, KEY_R, KEY_O, KEY_I, KEY_U, KEY_T, KEY_R,
/* 105 - 112 */
-/* PTE7 */ KEY_0, KEY_MINUS, KEY_EQUAL, 0, KEY_1, 0, 0, 0,
/* 113 - 120 */
- KEY_2, KEY_3, KEY_4, KEY_9, KEY_8, KEY_7, KEY_5, KEY_6,
/* 121 - 128 */
+/* PTD1 */ KEY_CAPSLOCK, KEY_MACRO, KEY_LEFTCTRL, 0, KEY_ESC, KEY_KP5, 0,
0, /* 1 - 8 */
+ KEY_F1, KEY_F2, KEY_F3, KEY_F8, KEY_F7, KEY_F6, KEY_F4, KEY_F5,
/* 9 - 16 */
+/* PTD5 */ KEY_SLASH, KEY_APOSTROPHE, KEY_ENTER, 0, KEY_Z, 0, 0, 0,
/* 17 - 24 */
+ KEY_X, KEY_C, KEY_V, KEY_DOT, KEY_COMMA, KEY_M, KEY_B, KEY_N,
/* 25 - 32 */
+/* PTD7 */ KEY_KP2, KEY_KP6, KEY_KP3, 0, 0, 0, 0, 0,
/* 33 - 40 */
+ KEY_F10, KEY_RO, KEY_F9, KEY_KP4, KEY_NUMLOCK, KEY_SCROLLLOCK,
KEY_LEFTALT, KEY_HANJA, /* 41 - 48 */
+/* PTE0 */ KEY_KATAKANA, KEY_KP0, KEY_GRAVE, 0, KEY_FINANCE, 0, 0, 0,
/* 49 - 56 */
+ KEY_KPMINUS, KEY_HIRAGANA, KEY_SPACE, KEY_KPDOT, KEY_VOLUMEUP,
249, 0, 0, /* 57 - 64 */
+/* PTE1 */ KEY_SEMICOLON, KEY_RIGHTBRACE, KEY_BACKSLASH, 0, KEY_A, 0, 0,
0,/* 65 - 72 */
+ KEY_S, KEY_D, KEY_F, KEY_L, KEY_K, KEY_J, KEY_G, KEY_H,
/* 73 - 80 */
+/* PTE3 */ KEY_KP8, KEY_LEFTMETA, KEY_RIGHTSHIFT, 0, KEY_TAB, 0, 0, 0,
/* 81 - 88 */
+ 0, KEY_LEFTSHIFT, KEY_KP7, KEY_KP9, KEY_KP1, KEY_F11,
KEY_KPPLUS, KEY_KPASTERISK, /* 89 - 96 */
+/* PTE6 */ KEY_P, KEY_LEFTBRACE, KEY_BACKSPACE, 0, KEY_Q, 0, 0, 0,
/* 97 - 104 */
+ KEY_W, KEY_E, KEY_R, KEY_O, KEY_I, KEY_U, KEY_T, KEY_Y,
/* 105 - 112 */
+/* PTE7 */ KEY_0, KEY_MINUS, KEY_EQUAL, 0, KEY_1, 0, 0, 0,
/* 113 - 120 */
+ KEY_2, KEY_3, KEY_4, KEY_9, KEY_8, KEY_7, KEY_5, KEY_6,
/* 121 - 128 */
/* */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0
};
hp6xx-keyboard-keymap-fix.patch
Description: Binary data
Re: [HP6XX/FIX/PATCH] - Fix bad default keymap in HP Jornada 6xx keyboard driver
On Thu, 13 Dec 2007 03:45:58 +0900 Paul Mundt [EMAIL PROTECTED] wrote: On Wed, Dec 12, 2007 at 07:22:07PM +0100, Kristoffer Ericson wrote: shortlog: * This patch fixes the HP Jornada 6xx keyboard default keymap which had some bad keymap values. This resulted in wrong key being returned when pressed (example : key y returned 'r'). * Also, while we are at it lets arrange the include files in alphabetical order. You do realize that the default keymap was written for the Japanese units and the Japanese keyboards, right? From the looks of it, you are just trying to swap one functional set for another. I can assure you that this keymap worked fine on the Japanese units, so calling it a bug is a bit misleading. Mostly true yes. However a few errors entered simply due to me copying the keymap poorly in the initial keymap. So it does infact have 'bug' keys that wouldn't work properly on neither japanese / european / US jornadas. And whatever functional set, this patch fixes those bugs. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (RESEND) [PATCH/HP6xx/HP7xx] Cleanup drivers/input/keyboard|touchscreen Kconfigs
Dmitry, could I get feedback on this? On Wed, 5 Dec 2007 21:19:26 +0100 Kristoffer Ericson <[EMAIL PROTECTED]> wrote: > Greetings, > > Oki, here is a more standard Kconfig setting for both platforms. Nothing > major really. > Note that touchscreen for hp6xx was called TOUCHSCREEN_HP600 and I've changed > it to HP6XX to get it inline with everything else. > > This should be pushed through dmitry I assume. Its against linux-2.6.git. > > shortlog: > This patch cleans up the drivers/input/keyboard|touchscreen Kconfigs for > platforms hp6xx and hp7xx. It unifies the naming and descriptions. > > signed-off-by: Kristoffer Ericson <[EMAIL PROTECTED]> > > diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig > index dfa6592..7421b91 100644 > --- a/drivers/input/keyboard/Kconfig > +++ b/drivers/input/keyboard/Kconfig > @@ -209,22 +209,22 @@ config KEYBOARD_HIL > to your machine, so normally you should say Y here. > > config KEYBOARD_HP6XX > - tristate "HP Jornada 6XX Keyboard support" > + tristate "HP Jornada 6xx keyboard" > depends on SH_HP6XX > select INPUT_POLLDEV > help > - This adds support for the onboard keyboard found on > - HP Jornada 620/660/680/690. > + Say Y here if you have a HP Jornada 620/660/680/690 and want to > + support the built-in keyboard. > > To compile this driver as a module, choose M here: the > module will be called jornada680_kbd. > > config KEYBOARD_HP7XX > - tristate "HP Jornada 7XX Keyboard Driver" > + tristate "HP Jornada 7xx keyboard" > depends on SA1100_JORNADA720_SSP && SA1100_SSP > help > - Say Y here to add support for the HP Jornada 7xx (710/720/728) > - onboard keyboard. > + Say Y here if you have a HP Jornada 710/720/728 and want to > + support the built-in keyboard. > > To compile this driver as a module, choose M here: the > module will be called jornada720_kbd. > diff --git a/drivers/input/touchscreen/Kconfig > b/drivers/input/touchscreen/Kconfig > index fa8442b..3271dd3 100644 > --- a/drivers/input/touchscreen/Kconfig > +++ b/drivers/input/touchscreen/Kconfig > @@ -114,20 +114,18 @@ config TOUCHSCREEN_MK712 > To compile this driver as a module, choose M here: the > module will be called mk712. > > -config TOUCHSCREEN_HP600 > - tristate "HP Jornada 680/690 touchscreen" > +config TOUCHSCREEN_HP6XX > + tristate "HP Jornada 6xx touchscreen" > depends on SH_HP6XX && SH_ADC > help > - Say Y here if you have a HP Jornada 680 or 690 and want to > + Say Y here if you have a HP Jornada 620/660/680/690 and want to >support the built-in touchscreen. > > - If unsure, say N. > - > To compile this driver as a module, choose M here: the > module will be called hp680_ts_input. > > config TOUCHSCREEN_HP7XX > - tristate "HP Jornada 710/720/728 touchscreen" > + tristate "HP Jornada 7xx touchscreen" > depends on SA1100_JORNADA720_SSP > help > Say Y here if you have a HP Jornada 710/720/728 and want > diff --git a/drivers/input/touchscreen/Makefile > b/drivers/input/touchscreen/Makefile > index 35d4097..75c2fe8 100644 > --- a/drivers/input/touchscreen/Makefile > +++ b/drivers/input/touchscreen/Makefile > @@ -12,7 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o > obj-$(CONFIG_TOUCHSCREEN_FUJITSU)+= fujitsu_ts.o > obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o > obj-$(CONFIG_TOUCHSCREEN_MK712) += mk712.o > -obj-$(CONFIG_TOUCHSCREEN_HP600) += hp680_ts_input.o > +obj-$(CONFIG_TOUCHSCREEN_HP6XX) += hp680_ts_input.o > obj-$(CONFIG_TOUCHSCREEN_HP7XX) += jornada720_ts.o > obj-$(CONFIG_TOUCHSCREEN_USB_COMPOSITE) += usbtouchscreen.o > obj-$(CONFIG_TOUCHSCREEN_PENMOUNT) += penmount.o > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (RESEND) [PATCH/HP6xx/HP7xx] Cleanup drivers/input/keyboard|touchscreen Kconfigs
Dmitry, could I get feedback on this? On Wed, 5 Dec 2007 21:19:26 +0100 Kristoffer Ericson [EMAIL PROTECTED] wrote: Greetings, Oki, here is a more standard Kconfig setting for both platforms. Nothing major really. Note that touchscreen for hp6xx was called TOUCHSCREEN_HP600 and I've changed it to HP6XX to get it inline with everything else. This should be pushed through dmitry I assume. Its against linux-2.6.git. shortlog: This patch cleans up the drivers/input/keyboard|touchscreen Kconfigs for platforms hp6xx and hp7xx. It unifies the naming and descriptions. signed-off-by: Kristoffer Ericson [EMAIL PROTECTED] diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig index dfa6592..7421b91 100644 --- a/drivers/input/keyboard/Kconfig +++ b/drivers/input/keyboard/Kconfig @@ -209,22 +209,22 @@ config KEYBOARD_HIL to your machine, so normally you should say Y here. config KEYBOARD_HP6XX - tristate HP Jornada 6XX Keyboard support + tristate HP Jornada 6xx keyboard depends on SH_HP6XX select INPUT_POLLDEV help - This adds support for the onboard keyboard found on - HP Jornada 620/660/680/690. + Say Y here if you have a HP Jornada 620/660/680/690 and want to + support the built-in keyboard. To compile this driver as a module, choose M here: the module will be called jornada680_kbd. config KEYBOARD_HP7XX - tristate HP Jornada 7XX Keyboard Driver + tristate HP Jornada 7xx keyboard depends on SA1100_JORNADA720_SSP SA1100_SSP help - Say Y here to add support for the HP Jornada 7xx (710/720/728) - onboard keyboard. + Say Y here if you have a HP Jornada 710/720/728 and want to + support the built-in keyboard. To compile this driver as a module, choose M here: the module will be called jornada720_kbd. diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index fa8442b..3271dd3 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -114,20 +114,18 @@ config TOUCHSCREEN_MK712 To compile this driver as a module, choose M here: the module will be called mk712. -config TOUCHSCREEN_HP600 - tristate HP Jornada 680/690 touchscreen +config TOUCHSCREEN_HP6XX + tristate HP Jornada 6xx touchscreen depends on SH_HP6XX SH_ADC help - Say Y here if you have a HP Jornada 680 or 690 and want to + Say Y here if you have a HP Jornada 620/660/680/690 and want to support the built-in touchscreen. - If unsure, say N. - To compile this driver as a module, choose M here: the module will be called hp680_ts_input. config TOUCHSCREEN_HP7XX - tristate HP Jornada 710/720/728 touchscreen + tristate HP Jornada 7xx touchscreen depends on SA1100_JORNADA720_SSP help Say Y here if you have a HP Jornada 710/720/728 and want diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile index 35d4097..75c2fe8 100644 --- a/drivers/input/touchscreen/Makefile +++ b/drivers/input/touchscreen/Makefile @@ -12,7 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o obj-$(CONFIG_TOUCHSCREEN_FUJITSU)+= fujitsu_ts.o obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o obj-$(CONFIG_TOUCHSCREEN_MK712) += mk712.o -obj-$(CONFIG_TOUCHSCREEN_HP600) += hp680_ts_input.o +obj-$(CONFIG_TOUCHSCREEN_HP6XX) += hp680_ts_input.o obj-$(CONFIG_TOUCHSCREEN_HP7XX) += jornada720_ts.o obj-$(CONFIG_TOUCHSCREEN_USB_COMPOSITE) += usbtouchscreen.o obj-$(CONFIG_TOUCHSCREEN_PENMOUNT) += penmount.o -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH/HP6xx/HP7xx] Cleanup drivers/input/keyboard|touchscreen Kconfigs
Greetings, Oki, here is a more standard Kconfig setting for both platforms. Nothing major really. Note that touchscreen for hp6xx was called TOUCHSCREEN_HP600 and I've changed it to HP6XX to get it inline with everything else. This should be pushed through dmitry I assume. Its against linux-2.6.git. shortlog: This patch cleans up the drivers/input/keyboard|touchscreen Kconfigs for platforms hp6xx and hp7xx. It unifies the naming and descriptions. signed-off-by: Kristoffer Ericson <[EMAIL PROTECTED]> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig index dfa6592..7421b91 100644 --- a/drivers/input/keyboard/Kconfig +++ b/drivers/input/keyboard/Kconfig @@ -209,22 +209,22 @@ config KEYBOARD_HIL to your machine, so normally you should say Y here. config KEYBOARD_HP6XX - tristate "HP Jornada 6XX Keyboard support" + tristate "HP Jornada 6xx keyboard" depends on SH_HP6XX select INPUT_POLLDEV help - This adds support for the onboard keyboard found on - HP Jornada 620/660/680/690. + Say Y here if you have a HP Jornada 620/660/680/690 and want to + support the built-in keyboard. To compile this driver as a module, choose M here: the module will be called jornada680_kbd. config KEYBOARD_HP7XX - tristate "HP Jornada 7XX Keyboard Driver" + tristate "HP Jornada 7xx keyboard" depends on SA1100_JORNADA720_SSP && SA1100_SSP help - Say Y here to add support for the HP Jornada 7xx (710/720/728) - onboard keyboard. + Say Y here if you have a HP Jornada 710/720/728 and want to + support the built-in keyboard. To compile this driver as a module, choose M here: the module will be called jornada720_kbd. diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index fa8442b..3271dd3 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -114,20 +114,18 @@ config TOUCHSCREEN_MK712 To compile this driver as a module, choose M here: the module will be called mk712. -config TOUCHSCREEN_HP600 - tristate "HP Jornada 680/690 touchscreen" +config TOUCHSCREEN_HP6XX + tristate "HP Jornada 6xx touchscreen" depends on SH_HP6XX && SH_ADC help - Say Y here if you have a HP Jornada 680 or 690 and want to + Say Y here if you have a HP Jornada 620/660/680/690 and want to support the built-in touchscreen. - If unsure, say N. - To compile this driver as a module, choose M here: the module will be called hp680_ts_input. config TOUCHSCREEN_HP7XX - tristate "HP Jornada 710/720/728 touchscreen" + tristate "HP Jornada 7xx touchscreen" depends on SA1100_JORNADA720_SSP help Say Y here if you have a HP Jornada 710/720/728 and want diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile index 35d4097..75c2fe8 100644 --- a/drivers/input/touchscreen/Makefile +++ b/drivers/input/touchscreen/Makefile @@ -12,7 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o obj-$(CONFIG_TOUCHSCREEN_FUJITSU) += fujitsu_ts.o obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o obj-$(CONFIG_TOUCHSCREEN_MK712)+= mk712.o -obj-$(CONFIG_TOUCHSCREEN_HP600)+= hp680_ts_input.o +obj-$(CONFIG_TOUCHSCREEN_HP6XX)+= hp680_ts_input.o obj-$(CONFIG_TOUCHSCREEN_HP7XX)+= jornada720_ts.o obj-$(CONFIG_TOUCHSCREEN_USB_COMPOSITE)+= usbtouchscreen.o obj-$(CONFIG_TOUCHSCREEN_PENMOUNT) += penmount.o hp6xx-drivers-Kconfig-cleanup.patch Description: Binary data
[PATCH/HP6xx/HP7xx] Cleanup drivers/input/keyboard|touchscreen Kconfigs
Greetings, Oki, here is a more standard Kconfig setting for both platforms. Nothing major really. Note that touchscreen for hp6xx was called TOUCHSCREEN_HP600 and I've changed it to HP6XX to get it inline with everything else. This should be pushed through dmitry I assume. Its against linux-2.6.git. shortlog: This patch cleans up the drivers/input/keyboard|touchscreen Kconfigs for platforms hp6xx and hp7xx. It unifies the naming and descriptions. signed-off-by: Kristoffer Ericson [EMAIL PROTECTED] diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig index dfa6592..7421b91 100644 --- a/drivers/input/keyboard/Kconfig +++ b/drivers/input/keyboard/Kconfig @@ -209,22 +209,22 @@ config KEYBOARD_HIL to your machine, so normally you should say Y here. config KEYBOARD_HP6XX - tristate HP Jornada 6XX Keyboard support + tristate HP Jornada 6xx keyboard depends on SH_HP6XX select INPUT_POLLDEV help - This adds support for the onboard keyboard found on - HP Jornada 620/660/680/690. + Say Y here if you have a HP Jornada 620/660/680/690 and want to + support the built-in keyboard. To compile this driver as a module, choose M here: the module will be called jornada680_kbd. config KEYBOARD_HP7XX - tristate HP Jornada 7XX Keyboard Driver + tristate HP Jornada 7xx keyboard depends on SA1100_JORNADA720_SSP SA1100_SSP help - Say Y here to add support for the HP Jornada 7xx (710/720/728) - onboard keyboard. + Say Y here if you have a HP Jornada 710/720/728 and want to + support the built-in keyboard. To compile this driver as a module, choose M here: the module will be called jornada720_kbd. diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index fa8442b..3271dd3 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -114,20 +114,18 @@ config TOUCHSCREEN_MK712 To compile this driver as a module, choose M here: the module will be called mk712. -config TOUCHSCREEN_HP600 - tristate HP Jornada 680/690 touchscreen +config TOUCHSCREEN_HP6XX + tristate HP Jornada 6xx touchscreen depends on SH_HP6XX SH_ADC help - Say Y here if you have a HP Jornada 680 or 690 and want to + Say Y here if you have a HP Jornada 620/660/680/690 and want to support the built-in touchscreen. - If unsure, say N. - To compile this driver as a module, choose M here: the module will be called hp680_ts_input. config TOUCHSCREEN_HP7XX - tristate HP Jornada 710/720/728 touchscreen + tristate HP Jornada 7xx touchscreen depends on SA1100_JORNADA720_SSP help Say Y here if you have a HP Jornada 710/720/728 and want diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile index 35d4097..75c2fe8 100644 --- a/drivers/input/touchscreen/Makefile +++ b/drivers/input/touchscreen/Makefile @@ -12,7 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o obj-$(CONFIG_TOUCHSCREEN_FUJITSU) += fujitsu_ts.o obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o obj-$(CONFIG_TOUCHSCREEN_MK712)+= mk712.o -obj-$(CONFIG_TOUCHSCREEN_HP600)+= hp680_ts_input.o +obj-$(CONFIG_TOUCHSCREEN_HP6XX)+= hp680_ts_input.o obj-$(CONFIG_TOUCHSCREEN_HP7XX)+= jornada720_ts.o obj-$(CONFIG_TOUCHSCREEN_USB_COMPOSITE)+= usbtouchscreen.o obj-$(CONFIG_TOUCHSCREEN_PENMOUNT) += penmount.o hp6xx-drivers-Kconfig-cleanup.patch Description: Binary data
Re: Best way to detect CF id strings
On Tue, 4 Dec 2007 20:30:38 + Alan Cox <[EMAIL PROTECTED]> wrote: > On Tue, 4 Dec 2007 20:19:33 +0100 > Kristoffer Ericson <[EMAIL PROTECTED]> wrote: > > > Greetings, > > > > Usually I detect them by attaching CF->PCMCIA adapter to my laptop, but > > would much rather be able to use my usb-CF adapter. > > This would also alot easier to explain to users which are having issues > > (unsupported/unknown id's). > > What sort of "id" are we talking about here ? Manufacturer and product id. Since the CF needs to be known to be used as an ide-cs device. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suspend order
Hey rafael, For obvious reasons it would be great to have serial output to be the last to enter suspend, thus giving every last drop of debugging before actually turning the machine "off". I'm not aware of any specific order currently, from what I've seen currently every driver is asked to go into suspend at the same time. This of course providing driver x isn't dependant on driver y. You following? So, without digging to much into this, is there any specific order? Best wishes Kristoffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Best way to detect CF id strings
Greetings, Usually I detect them by attaching CF->PCMCIA adapter to my laptop, but would much rather be able to use my usb-CF adapter. This would also alot easier to explain to users which are having issues (unsupported/unknown id's). Any good suggestions on this? Best wishes Kristoffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Best way to detect CF id strings
Greetings, Usually I detect them by attaching CF-PCMCIA adapter to my laptop, but would much rather be able to use my usb-CF adapter. This would also alot easier to explain to users which are having issues (unsupported/unknown id's). Any good suggestions on this? Best wishes Kristoffer -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suspend order
Hey rafael, For obvious reasons it would be great to have serial output to be the last to enter suspend, thus giving every last drop of debugging before actually turning the machine off. I'm not aware of any specific order currently, from what I've seen currently every driver is asked to go into suspend at the same time. This of course providing driver x isn't dependant on driver y. You following? So, without digging to much into this, is there any specific order? Best wishes Kristoffer -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Best way to detect CF id strings
On Tue, 4 Dec 2007 20:30:38 + Alan Cox [EMAIL PROTECTED] wrote: On Tue, 4 Dec 2007 20:19:33 +0100 Kristoffer Ericson [EMAIL PROTECTED] wrote: Greetings, Usually I detect them by attaching CF-PCMCIA adapter to my laptop, but would much rather be able to use my usb-CF adapter. This would also alot easier to explain to users which are having issues (unsupported/unknown id's). What sort of id are we talking about here ? Manufacturer and product id. Since the CF needs to be known to be used as an ide-cs device. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
I'll give it a go later today, still on 2.6.22.4.
Any logs of interest except for obvious behavior?
On Thu, 29 Nov 2007 15:05:50 +0100
Johann Wilhelm <[EMAIL PROTECTED]> wrote:
> If everything's working please also add code to also support the other
> E220 device... so both PID 0x1003 and 0x1004 should be treaded the
> same way...
>
> to test the device with the 0x1004-PID maybe Jaime Velasco
> <[EMAIL PROTECTED]> could be asked.. he initialy added the lines
> for this device in option.c
>
> 73
>
> Zitat von Oliver Neukum <[EMAIL PROTECTED]>:
>
> > Am Donnerstag 29 November 2007 schrieb Rui Santos:
> >> >> Just to remember that that specific flag was one SET and, was removed,
> >> >> in part, because of what I state. Of course we aim at perfection but, if
> >> >> the benefits are only for a few situations and, will cause all this
> >> >> problems for all other, perhaps the reinsert of that flag would be a
> >> >> positive action.
> >> >>
> >> >
> >> > OK, can you provide "lsusb -v" for the device in the CD mode and in
> >> > the modem mode?
> >> >
> >> Of course. Heri it is.
> >
> > Thanks. Please try this patch.
> >
> > Regards
> > Oliver
> >
> >
> >
> > --- a/drivers/usb/serial/option.c 2007-11-29 12:35:09.0 +0100
> > +++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.0 +0100
> > @@ -158,7 +158,7 @@ static struct usb_device_id option_ids[]
> > { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
> > { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
> > { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
> > - { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
> > + { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
> > HUAWEI_PRODUCT_E220, 0xff, 0xff, 0xff) },
> > { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
> > { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel
> > Merlin XS620/S640 */
> > { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel
> > Merlin S620 */
> >
> >
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
I'll give it a go later today, still on 2.6.22.4.
Any logs of interest except for obvious behavior?
On Thu, 29 Nov 2007 15:05:50 +0100
Johann Wilhelm [EMAIL PROTECTED] wrote:
If everything's working please also add code to also support the other
E220 device... so both PID 0x1003 and 0x1004 should be treaded the
same way...
to test the device with the 0x1004-PID maybe Jaime Velasco
[EMAIL PROTECTED] could be asked.. he initialy added the lines
for this device in option.c
73
Zitat von Oliver Neukum [EMAIL PROTECTED]:
Am Donnerstag 29 November 2007 schrieb Rui Santos:
Just to remember that that specific flag was one SET and, was removed,
in part, because of what I state. Of course we aim at perfection but, if
the benefits are only for a few situations and, will cause all this
problems for all other, perhaps the reinsert of that flag would be a
positive action.
OK, can you provide lsusb -v for the device in the CD mode and in
the modem mode?
Of course. Heri it is.
Thanks. Please try this patch.
Regards
Oliver
--- a/drivers/usb/serial/option.c 2007-11-29 12:35:09.0 +0100
+++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.0 +0100
@@ -158,7 +158,7 @@ static struct usb_device_id option_ids[]
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
- { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
+ { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
HUAWEI_PRODUCT_E220, 0xff, 0xff, 0xff) },
{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel
Merlin XS620/S640 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel
Merlin S620 */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
On Wed, 28 Nov 2007 12:23:48 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote: > Kristoffer Ericson schrieb: > > Google is your friend. > > Sigh. > > In case you didn't guess, I *have* of course searched Google, > and not just that. I thought the wording of my request would > have made that sufficiently clear. Do I really have to add the > phrase "Yes, I have searched Google!" to my sig? > A visit to #git on freenode.net would clear up any problems you might have, thats all Im saying. > -- > Tilman SchmidtE-Mail: [EMAIL PROTECTED] > Bonn, Germany > Yes, I have searched Google! > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
On Wed, 28 Nov 2007 12:23:48 +0100 Tilman Schmidt [EMAIL PROTECTED] wrote: Kristoffer Ericson schrieb: Google is your friend. Sigh. In case you didn't guess, I *have* of course searched Google, and not just that. I thought the wording of my request would have made that sufficiently clear. Do I really have to add the phrase Yes, I have searched Google! to my sig? A visit to #git on freenode.net would clear up any problems you might have, thats all Im saying. -- Tilman SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Yes, I have searched Google! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
On Wed, 28 Nov 2007 00:52:38 +0100 Willy Tarreau <[EMAIL PROTECTED]> wrote: > On Tue, Nov 27, 2007 at 11:55:11PM +0100, Kristoffer Ericson wrote: > > Greetings, > > > > Google is your friend. If you're looking for irc channels you can always > > try #git at irc.freenode.net > > Git howto/tutorial/... doesn't belong in the kernel mailinglist. > > Well, I don't agree with you. His question is about how to use GIT to > develop his driver. >1) linux-kernel is a development ML. >2) he needs help from people how already encountered such beginner's > issues and who might git very good advices. Agreed, my main concern was turning list into a "git-support" list and since I used the tutorials myself to get started, I felt they are quite satisfactory. However as you pointed out, needing help to develope his driver is a kernel matter. Point taken. :) > > It should not turn into an endless thread led by people who want to > redefine GIT's roadmap, but experience sharing helps a lot with GIT. > > Tilman, there was a howto by Jeff Garzik I believe. It helped me > a lot when I didn't understand a damn command, even if it was in > the very old ages (version 0.5 or something like this). The tutorials > on the GIT site are quite good too. You must read them entirely and > proceed with the examples as you read them. Believe me, it helps you > understand a lot of things, specially about the split in 3 parts > (objects, cache, and working dir). > > I really think that if your patches do not apply, it's because you > have lost some changes due to a wrong initial use possibly caused > by a mis-understanding of the tool. It happened to me too, but in > this case you can almost certainly find your old changes in older > commits. > > I really hope that soon someone will come up with a big 400-pages > book called "GIT" with a lot of good advices. It would be awesome. I second that :) > > Anyway, don't get demotivated about the tool or the workflow. If > you find it inconvenient to use, you're doing something wrong and > you don't know it. > > Regards, > Willy > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
Greetings, Google is your friend. If you're looking for irc channels you can always try #git at irc.freenode.net Git howto/tutorial/... doesn't belong in the kernel mailinglist. Best wishes Kristoffer Ericson On Tue, 27 Nov 2007 23:33:21 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote: > So I've watched Linus' Google Tech Talk about git and let him convince > me that I've been stupid to use CVS, that Subversion is even worse, > and the only sensible approach is to use git. Went ahead and tried to > convert my driver development to git. > > It didn't work too well. The first result was one of maximal > embarrassment: I produced a patch that didn't even compile when > applied to the official tree. This shouldn't happen with git, right? > Well, it did. So now I'm back to keeping a virgin kernel source tree > alongside my development area in order to produce diffs. That can't > be right? > > Obviously I'm still being stupid. (Probably an aftereffect of using > CVS for too long.) But where do I turn for guidance? I read all the > docs and READMEs I could find, but I still don't understand why GIT > doesn't produce the results I need, and what to do differently. > > Does somebody have a step by step tutorial for doing the standard > "edit - test - modify - retest - submit - edit - resubmit" sequence > with GIT? Is there a GIT newsgroup or mailinglist? Or should I just > post my silly questions to LKML? > > TIA > > -- > Tilman Schmidt E-Mail: [EMAIL PROTECTED] > Bonn, Germany > Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. > Ungeöffnet mindestens haltbar bis: (siehe Rückseite) > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
Greetings, Google is your friend. If you're looking for irc channels you can always try #git at irc.freenode.net Git howto/tutorial/... doesn't belong in the kernel mailinglist. Best wishes Kristoffer Ericson On Tue, 27 Nov 2007 23:33:21 +0100 Tilman Schmidt [EMAIL PROTECTED] wrote: So I've watched Linus' Google Tech Talk about git and let him convince me that I've been stupid to use CVS, that Subversion is even worse, and the only sensible approach is to use git. Went ahead and tried to convert my driver development to git. It didn't work too well. The first result was one of maximal embarrassment: I produced a patch that didn't even compile when applied to the official tree. This shouldn't happen with git, right? Well, it did. So now I'm back to keeping a virgin kernel source tree alongside my development area in order to produce diffs. That can't be right? Obviously I'm still being stupid. (Probably an aftereffect of using CVS for too long.) But where do I turn for guidance? I read all the docs and READMEs I could find, but I still don't understand why GIT doesn't produce the results I need, and what to do differently. Does somebody have a step by step tutorial for doing the standard edit - test - modify - retest - submit - edit - resubmit sequence with GIT? Is there a GIT newsgroup or mailinglist? Or should I just post my silly questions to LKML? TIA -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
On Wed, 28 Nov 2007 00:52:38 +0100 Willy Tarreau [EMAIL PROTECTED] wrote: On Tue, Nov 27, 2007 at 11:55:11PM +0100, Kristoffer Ericson wrote: Greetings, Google is your friend. If you're looking for irc channels you can always try #git at irc.freenode.net Git howto/tutorial/... doesn't belong in the kernel mailinglist. Well, I don't agree with you. His question is about how to use GIT to develop his driver. 1) linux-kernel is a development ML. 2) he needs help from people how already encountered such beginner's issues and who might git very good advices. Agreed, my main concern was turning list into a git-support list and since I used the tutorials myself to get started, I felt they are quite satisfactory. However as you pointed out, needing help to develope his driver is a kernel matter. Point taken. :) It should not turn into an endless thread led by people who want to redefine GIT's roadmap, but experience sharing helps a lot with GIT. Tilman, there was a howto by Jeff Garzik I believe. It helped me a lot when I didn't understand a damn command, even if it was in the very old ages (version 0.5 or something like this). The tutorials on the GIT site are quite good too. You must read them entirely and proceed with the examples as you read them. Believe me, it helps you understand a lot of things, specially about the split in 3 parts (objects, cache, and working dir). I really think that if your patches do not apply, it's because you have lost some changes due to a wrong initial use possibly caused by a mis-understanding of the tool. It happened to me too, but in this case you can almost certainly find your old changes in older commits. I really hope that soon someone will come up with a big 400-pages book called GIT with a lot of good advices. It would be awesome. I second that :) Anyway, don't get demotivated about the tool or the workflow. If you find it inconvenient to use, you're doing something wrong and you don't know it. Regards, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question regarding naming scheme (HP Jornada 6XX/7XX)
On Mon, 26 Nov 2007 09:40:14 -0500 "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote: > On Nov 25, 2007 11:30 PM, Paul Mundt <[EMAIL PROTECTED]> wrote: > > On Mon, Nov 26, 2007 at 12:03:29AM +0100, Kristoffer Ericson wrote: > > > > > Why I want to use 600-series/700-series instead of 6XX/7XX is simply > > > because 600-series/700-series leaves no doubt. > > > > > Apparently your end users are more technically apt than I am, as I have > > no idea how using 00 over XX makes things any less ambiguous. > > > > We already have a 6xx mach-type that drivers can set their dependency on. > > If it's not 680-only, then that's a perfectly reasonable dependency. Feel > > free to change the Kconfig text to make the description more useful, but > > please don't start idly shuffling around code and symbols because users > > can't work out why a driver is available that they can't support. > > Agreed. Users simply should not care what a particular module is > called. If Kconfig entries and/or its help is unclear on whta devices > are supported by the drivers let's fix that. > Ok, guess the idea was shot down then :). I'll look at Kconfigs to see how I can make it clearer. thx for feedback. > -- > Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question regarding naming scheme (HP Jornada 6XX/7XX)
On Mon, 26 Nov 2007 09:40:14 -0500 Dmitry Torokhov [EMAIL PROTECTED] wrote: On Nov 25, 2007 11:30 PM, Paul Mundt [EMAIL PROTECTED] wrote: On Mon, Nov 26, 2007 at 12:03:29AM +0100, Kristoffer Ericson wrote: Why I want to use 600-series/700-series instead of 6XX/7XX is simply because 600-series/700-series leaves no doubt. Apparently your end users are more technically apt than I am, as I have no idea how using 00 over XX makes things any less ambiguous. We already have a 6xx mach-type that drivers can set their dependency on. If it's not 680-only, then that's a perfectly reasonable dependency. Feel free to change the Kconfig text to make the description more useful, but please don't start idly shuffling around code and symbols because users can't work out why a driver is available that they can't support. Agreed. Users simply should not care what a particular module is called. If Kconfig entries and/or its help is unclear on whta devices are supported by the drivers let's fix that. Ok, guess the idea was shot down then :). I'll look at Kconfigs to see how I can make it clearer. thx for feedback. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question regarding naming scheme (HP Jornada 6XX/7XX)
Greetings, Just want some input before I start dropping patches everywhere. A simple ack will do nicely if you just agree. Currently we use the name of the most typical HP Jornada (680 and 720) to mean all 6XX/7XX (= 620/660/680/690 and 720/720/728). In the past this has led to some confusion when people tried to compile their own kernels. For instance an hp 620 user thought that their system was unsupported because everything was for '680'. Or the other way round 728 users didn't want to use 720 since they thought they would loose their extra ram (only difference between versions). So, I want to instead use the term 600-series or 700-series. This would mean changing Kconfig/Makefile and driver name. For example /drivers/input/keyboard/jornada680_kbd.c would become /drivers/input/keyboard/jornada600_kbd.c The machine name tag would also return (HP Jornada 600-series | HP Jornada 700-series) since I know for instance opie loves to grep the machine line. Currently this is set as "hp6xx" for 600-series and "HP Jornada 720" for 700-series. They are related machines so it would be nice to unify their output a tad. Why I want to use 600-series/700-series instead of 6XX/7XX is simply because 600-series/700-series leaves no doubt. Any objections? Best wishes Kristoffer Ericson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question regarding naming scheme (HP Jornada 6XX/7XX)
Greetings, Just want some input before I start dropping patches everywhere. A simple ack will do nicely if you just agree. Currently we use the name of the most typical HP Jornada (680 and 720) to mean all 6XX/7XX (= 620/660/680/690 and 720/720/728). In the past this has led to some confusion when people tried to compile their own kernels. For instance an hp 620 user thought that their system was unsupported because everything was for '680'. Or the other way round 728 users didn't want to use 720 since they thought they would loose their extra ram (only difference between versions). So, I want to instead use the term 600-series or 700-series. This would mean changing Kconfig/Makefile and driver name. For example /drivers/input/keyboard/jornada680_kbd.c would become /drivers/input/keyboard/jornada600_kbd.c The machine name tag would also return (HP Jornada 600-series | HP Jornada 700-series) since I know for instance opie loves to grep the machine line. Currently this is set as hp6xx for 600-series and HP Jornada 720 for 700-series. They are related machines so it would be nice to unify their output a tad. Why I want to use 600-series/700-series instead of 6XX/7XX is simply because 600-series/700-series leaves no doubt. Any objections? Best wishes Kristoffer Ericson - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suspend/Resume/Hibernation - bisecting or bug-logs?
Greetings, Ive been following your discussion and documentation efforts concerning pm in the kernel. This has in the past been a gray area which was hard to find information about so kudos. I maintain 2 handheld platforms that would benefit greatly from implementing proper pm (mainly suspend) but Im having problems bugtracking it. Currently the system tries to suspend but fails somewhere and then tries to resume (which fails). The end result however is that Im unable to see anything (bugmessages...) since the video driver gets deactivated by pm. My question is this: Is bisecting (turning off device support in kernel until it works) the best approach when bugtracking pm suspend? Or is there any other logging system that I can use? -- Kristoffer Ericson <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suspend/Resume/Hibernation - bisecting or bug-logs?
Greetings, Ive been following your discussion and documentation efforts concerning pm in the kernel. This has in the past been a gray area which was hard to find information about so kudos. I maintain 2 handheld platforms that would benefit greatly from implementing proper pm (mainly suspend) but Im having problems bugtracking it. Currently the system tries to suspend but fails somewhere and then tries to resume (which fails). The end result however is that Im unable to see anything (bugmessages...) since the video driver gets deactivated by pm. My question is this: Is bisecting (turning off device support in kernel until it works) the best approach when bugtracking pm suspend? Or is there any other logging system that I can use? -- Kristoffer Ericson [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/video/s1d13xxxfb.c as module with dbg
On Sun, 11 Nov 2007 07:29:35 +0800
"dave chung" <[EMAIL PROTECTED]> wrote:
> On 11/10/07, Stanislav Brabec <[EMAIL PROTECTED]> wrote:
> > Attached patch fixes two compilation problems of s1d13xxxfb.c:
> > - Fixes outdated dbg() message to fix compilation error with debugging
> > enabled.
> > - Do not read kernel command line options when compiled as module.
> >
> > Signed-off-by: Stanislav Brabec <[EMAIL PROTECTED]>
> >
> > --- linux-2.6.23/drivers/video/s1d13xxxfb.c 2007-10-09
> > 22:31:38.0 +0200
> > +++ linux-2.6.23/drivers/video/s1d13xxxfb.c 2007-11-02
> > 16:48:34.0 +0100
> > @@ -540,7 +540,7 @@
> > int ret = 0;
> > u8 revision;
> >
> > - dbg("probe called: device is %p\n", dev);
> > + dbg("probe called: device is %p\n", pdev);
> >
> > printk(KERN_INFO "Epson S1D13XXX FB Driver\n");
> >
> > @@ -753,8 +753,11 @@
> > static int __init
> > s1d13xxxfb_init(void)
> > {
> > +
> > +#ifndef MODULE
> > if (fb_get_options("s1d13xxxfb", NULL))
> > return -ENODEV;
> > +#endif
> >
> > return platform_driver_register(_driver);
> > }
> >
> >
> >
> > Stanislav Brabec
> > http://www.penguin.cz/~utx
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> we also need to look at splitting out the "chip revision", which is
> currently hard set, as I have had very good results with this driver
> and chip S1D13506, which is functionally similar but without the
> external clocking and without teh internal ram.
> We also have some build dependancies related to "CONFIG_FB_S1D13XXX"
> and ics1523 , this chip is not used on the full range of S1D13XXX and
> causes errors in the build , for chips such as S1D13506.
> potentially we could re-use most of the code, but would need a way to
> pass in S1D_CHIP_REV and one or 2 other chip specific data items.
Im all for that. Got 2 platforms (Mobilepro 900c & HP Jornada 720) with both
uses S1D13... based chipsets. The driver should
make more room for similiar versions.
>
> Steve
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] jonada720: remove duplicate include
Thanks On Tue, 13 Nov 2007 17:17:36 +0100 [EMAIL PROTECTED] wrote: > From: Andre Haupt <[EMAIL PROTECTED]> > Signed-off-by: Andre Haupt <[EMAIL PROTECTED]> > > --- > drivers/input/keyboard/jornada720_kbd.c |1 - > 1 file changed, 1 deletion(-) > > Index: linus/drivers/input/keyboard/jornada720_kbd.c > === > --- linus.orig/drivers/input/keyboard/jornada720_kbd.c2007-11-13 > 16:33:24.0 +0100 > +++ linus/drivers/input/keyboard/jornada720_kbd.c 2007-11-13 > 16:33:41.0 +0100 > @@ -17,7 +17,6 @@ > */ > #include > #include > -#include > #include > #include > #include > > -- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] jonada720: remove duplicate include
Thanks On Tue, 13 Nov 2007 17:17:36 +0100 [EMAIL PROTECTED] wrote: From: Andre Haupt [EMAIL PROTECTED] Signed-off-by: Andre Haupt [EMAIL PROTECTED] --- drivers/input/keyboard/jornada720_kbd.c |1 - 1 file changed, 1 deletion(-) Index: linus/drivers/input/keyboard/jornada720_kbd.c === --- linus.orig/drivers/input/keyboard/jornada720_kbd.c2007-11-13 16:33:24.0 +0100 +++ linus/drivers/input/keyboard/jornada720_kbd.c 2007-11-13 16:33:41.0 +0100 @@ -17,7 +17,6 @@ */ #include linux/device.h #include linux/errno.h -#include linux/init.h #include linux/interrupt.h #include linux/init.h #include linux/input.h -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/video/s1d13xxxfb.c as module with dbg
On Sun, 11 Nov 2007 07:29:35 +0800
dave chung [EMAIL PROTECTED] wrote:
On 11/10/07, Stanislav Brabec [EMAIL PROTECTED] wrote:
Attached patch fixes two compilation problems of s1d13xxxfb.c:
- Fixes outdated dbg() message to fix compilation error with debugging
enabled.
- Do not read kernel command line options when compiled as module.
Signed-off-by: Stanislav Brabec [EMAIL PROTECTED]
--- linux-2.6.23/drivers/video/s1d13xxxfb.c 2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/drivers/video/s1d13xxxfb.c 2007-11-02
16:48:34.0 +0100
@@ -540,7 +540,7 @@
int ret = 0;
u8 revision;
- dbg(probe called: device is %p\n, dev);
+ dbg(probe called: device is %p\n, pdev);
printk(KERN_INFO Epson S1D13XXX FB Driver\n);
@@ -753,8 +753,11 @@
static int __init
s1d13xxxfb_init(void)
{
+
+#ifndef MODULE
if (fb_get_options(s1d13xxxfb, NULL))
return -ENODEV;
+#endif
return platform_driver_register(s1d13xxxfb_driver);
}
Stanislav Brabec
http://www.penguin.cz/~utx
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
we also need to look at splitting out the chip revision, which is
currently hard set, as I have had very good results with this driver
and chip S1D13506, which is functionally similar but without the
external clocking and without teh internal ram.
We also have some build dependancies related to CONFIG_FB_S1D13XXX
and ics1523 , this chip is not used on the full range of S1D13XXX and
causes errors in the build , for chips such as S1D13506.
potentially we could re-use most of the code, but would need a way to
pass in S1D_CHIP_REV and one or 2 other chip specific data items.
Im all for that. Got 2 platforms (Mobilepro 900c HP Jornada 720) with both
uses S1D13... based chipsets. The driver should
make more room for similiar versions.
Steve
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] : kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined reference to `.L343'
On Sat, 3 Nov 2007 00:04:14 + Russell King - ARM Linux <[EMAIL PROTECTED]> wrote: > On Sat, Nov 03, 2007 at 12:04:06AM -0700, Kristoffer Ericson wrote: > > On Fri, 2 Nov 2007 21:10:23 +0100 > > Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > > > > On Fri, Nov 02, 2007 at 07:48:18PM +, Russell King - ARM Linux wrote: > > > > On Fri, Nov 02, 2007 at 08:29:31PM -0700, Kristoffer Ericson wrote: > > > > > Greetings, > > > > > > > > > > Haven't found anyone reporting this. Taken from the very latest > > > > > linux-2.6.git pull. > > > > > > > > > > dnsdomainname: Unknown host > > > > > UPD include/linux/compile.h > > > > > CC init/version.o > > > > > LD init/built-in.o > > > > > LD .tmp_vmlinux1 > > > > > kernel/built-in.o(.text+0x18db0): In function `destroy_workqueue': > > > > > kernel/workqueue.c:823: undefined reference to `.L342' > > > > > kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined > > > > > reference to `.L343' > > > > > make: *** [.tmp_vmlinux1] Error 1 > > > > > > > > I think you'll have to look at the assembly produced for workqueue.c and > > > > work out why GCC is referencing an undefined label. You can get the > > > > assembly for that by doing: > > > > > > > > make ARCH=arm ...etc... kernel/workqueue.s > > > Or make that: > > > > > > make ARCH=arm ...etc... kernel/workqueue.lst > > > > > > to get intermixed C and assenbly > > > > > > Sam > > arm-unknown-linux-gnu- kernel/workqueue.1strrent:)$ make ARCH=arm > > CROSS_COMPILE=a > > make: *** No rule to make target `kernel/workqueue.1st'. Stop. > > Suggest you use a better console font that allows you to identify > the difference between '1' (one) and 'l' (lima). Point taken. > > > arm-unknown-linux-gnu- kernel/workqueue.lstrrent:)$ make ARCH=arm > > CROSS_COMPILE=a > > CHK include/linux/version.h > > make[1]: `include/asm-arm/mach-types.h' is up to date. > > CHK include/linux/utsrelease.h > > CALLscripts/checksyscalls.sh > > :1097:2: warning: #warning syscall fadvise64 not implemented > > :1265:2: warning: #warning syscall migrate_pages not implemented > > :1321:2: warning: #warning syscall pselect6 not implemented > > :1325:2: warning: #warning syscall ppoll not implemented > > :1365:2: warning: #warning syscall epoll_pwait not implemented > > MKLST kernel/workqueue.lst > > No System.map > > You're not looking for a system.map file, but the workqueue.s or > workqueue.lst file to find out where this nonexistent label is > referenced. Sorry, I misunderstod Sam's reply earlier. Tried to compile the .lst file :D I've done some checks in the .config and seems like some setting in 'kernel hacking', caused this. Unfortunantly I changed too much at once to be sure what exactly in there caused it. Anyhow, thanks for helping out :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] : kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined reference to `.L343'
On Fri, 2 Nov 2007 21:10:23 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > On Fri, Nov 02, 2007 at 07:48:18PM +, Russell King - ARM Linux wrote: > > On Fri, Nov 02, 2007 at 08:29:31PM -0700, Kristoffer Ericson wrote: > > > Greetings, > > > > > > Haven't found anyone reporting this. Taken from the very latest > > > linux-2.6.git pull. > > > > > > dnsdomainname: Unknown host > > > UPD include/linux/compile.h > > > CC init/version.o > > > LD init/built-in.o > > > LD .tmp_vmlinux1 > > > kernel/built-in.o(.text+0x18db0): In function `destroy_workqueue': > > > kernel/workqueue.c:823: undefined reference to `.L342' > > > kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined > > > reference to `.L343' > > > make: *** [.tmp_vmlinux1] Error 1 > > > > I think you'll have to look at the assembly produced for workqueue.c and > > work out why GCC is referencing an undefined label. You can get the > > assembly for that by doing: > > > > make ARCH=arm ...etc... kernel/workqueue.s > Or make that: > > make ARCH=arm ...etc... kernel/workqueue.lst > > to get intermixed C and assenbly > > Sam arm-unknown-linux-gnu- kernel/workqueue.1strrent:)$ make ARCH=arm CROSS_COMPILE=a make: *** No rule to make target `kernel/workqueue.1st'. Stop. arm-unknown-linux-gnu- kernel/workqueue.lstrrent:)$ make ARCH=arm CROSS_COMPILE=a CHK include/linux/version.h make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh :1097:2: warning: #warning syscall fadvise64 not implemented :1265:2: warning: #warning syscall migrate_pages not implemented :1321:2: warning: #warning syscall pselect6 not implemented :1325:2: warning: #warning syscall ppoll not implemented :1365:2: warning: #warning syscall epoll_pwait not implemented MKLST kernel/workqueue.lst No System.map - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] : kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined reference to `.L343'
Greetings, Haven't found anyone reporting this. Taken from the very latest linux-2.6.git pull. dnsdomainname: Unknown host UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o(.text+0x18db0): In function `destroy_workqueue': kernel/workqueue.c:823: undefined reference to `.L342' kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined reference to `.L343' make: *** [.tmp_vmlinux1] Error 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] : kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined reference to `.L343'
Greetings, Haven't found anyone reporting this. Taken from the very latest linux-2.6.git pull. dnsdomainname: Unknown host UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o(.text+0x18db0): In function `destroy_workqueue': kernel/workqueue.c:823: undefined reference to `.L342' kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined reference to `.L343' make: *** [.tmp_vmlinux1] Error 1 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] : kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined reference to `.L343'
On Fri, 2 Nov 2007 21:10:23 +0100 Sam Ravnborg [EMAIL PROTECTED] wrote: On Fri, Nov 02, 2007 at 07:48:18PM +, Russell King - ARM Linux wrote: On Fri, Nov 02, 2007 at 08:29:31PM -0700, Kristoffer Ericson wrote: Greetings, Haven't found anyone reporting this. Taken from the very latest linux-2.6.git pull. dnsdomainname: Unknown host UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o(.text+0x18db0): In function `destroy_workqueue': kernel/workqueue.c:823: undefined reference to `.L342' kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined reference to `.L343' make: *** [.tmp_vmlinux1] Error 1 I think you'll have to look at the assembly produced for workqueue.c and work out why GCC is referencing an undefined label. You can get the assembly for that by doing: make ARCH=arm ...etc... kernel/workqueue.s Or make that: make ARCH=arm ...etc... kernel/workqueue.lst to get intermixed C and assenbly Sam arm-unknown-linux-gnu- kernel/workqueue.1strrent:)$ make ARCH=arm CROSS_COMPILE=a make: *** No rule to make target `kernel/workqueue.1st'. Stop. arm-unknown-linux-gnu- kernel/workqueue.lstrrent:)$ make ARCH=arm CROSS_COMPILE=a CHK include/linux/version.h make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh stdin:1097:2: warning: #warning syscall fadvise64 not implemented stdin:1265:2: warning: #warning syscall migrate_pages not implemented stdin:1321:2: warning: #warning syscall pselect6 not implemented stdin:1325:2: warning: #warning syscall ppoll not implemented stdin:1365:2: warning: #warning syscall epoll_pwait not implemented MKLST kernel/workqueue.lst No System.map - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] : kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined reference to `.L343'
On Sat, 3 Nov 2007 00:04:14 + Russell King - ARM Linux [EMAIL PROTECTED] wrote: On Sat, Nov 03, 2007 at 12:04:06AM -0700, Kristoffer Ericson wrote: On Fri, 2 Nov 2007 21:10:23 +0100 Sam Ravnborg [EMAIL PROTECTED] wrote: On Fri, Nov 02, 2007 at 07:48:18PM +, Russell King - ARM Linux wrote: On Fri, Nov 02, 2007 at 08:29:31PM -0700, Kristoffer Ericson wrote: Greetings, Haven't found anyone reporting this. Taken from the very latest linux-2.6.git pull. dnsdomainname: Unknown host UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o(.text+0x18db0): In function `destroy_workqueue': kernel/workqueue.c:823: undefined reference to `.L342' kernel/built-in.o(.text+0x18db4):kernel/workqueue.c:823: undefined reference to `.L343' make: *** [.tmp_vmlinux1] Error 1 I think you'll have to look at the assembly produced for workqueue.c and work out why GCC is referencing an undefined label. You can get the assembly for that by doing: make ARCH=arm ...etc... kernel/workqueue.s Or make that: make ARCH=arm ...etc... kernel/workqueue.lst to get intermixed C and assenbly Sam arm-unknown-linux-gnu- kernel/workqueue.1strrent:)$ make ARCH=arm CROSS_COMPILE=a make: *** No rule to make target `kernel/workqueue.1st'. Stop. Suggest you use a better console font that allows you to identify the difference between '1' (one) and 'l' (lima). Point taken. arm-unknown-linux-gnu- kernel/workqueue.lstrrent:)$ make ARCH=arm CROSS_COMPILE=a CHK include/linux/version.h make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh stdin:1097:2: warning: #warning syscall fadvise64 not implemented stdin:1265:2: warning: #warning syscall migrate_pages not implemented stdin:1321:2: warning: #warning syscall pselect6 not implemented stdin:1325:2: warning: #warning syscall ppoll not implemented stdin:1365:2: warning: #warning syscall epoll_pwait not implemented MKLST kernel/workqueue.lst No System.map You're not looking for a system.map file, but the workqueue.s or workqueue.lst file to find out where this nonexistent label is referenced. Sorry, I misunderstod Sam's reply earlier. Tried to compile the .lst file :D I've done some checks in the .config and seems like some setting in 'kernel hacking', caused this. Unfortunantly I changed too much at once to be sure what exactly in there caused it. Anyhow, thanks for helping out :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SUPERH / PATA / SCSI] Unable to do start userland after kernel boot (BISECTED)
On Wed, 31 Oct 2007 02:56:21 -0700 Kristoffer Ericson <[EMAIL PROTECTED]> wrote: > On Fri, 26 Oct 2007 04:46:18 +0900 > Paul Mundt <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 25, 2007 at 09:22:40PM -0700, Kristoffer Ericson wrote: > > > The bottom line seems to be that it fails to attach scsi sg0. It > > > explains why it doesn't work, but not why it stopped working. And this > > > has nothing to do with the current kernel config, I've been over that > > > the last 4 days. It all started when I synced my jlime-current.git > > > repository with linux-2.6.git. As you can see I had 2.6.23-rc6 and then > > > synced up to 2.6.23-rc8/rc9 and thats when the troubles started. > > > > > At least that suggests it's not fallout from the INTC changes in -rc1, so > > that helps to narrow it down a bit. Since you have a known good and bad, > > it would be nice if you could bisect this to figure out what exactly > > caused the regression. There weren't any SH-specific changes between rc6 > > and rc8/rc9 at least. Just wanted to confirm that when reverting the patch below my kernels start booting again. Bisect is a pain to go through, but is really effective. > > I've spent a couple of hours bisecting it, and this is where it stops > working. I haven't reversed the patch yet, simply because Im dead tired :D > Will do that tommorow, but Im quite confident that this is the correct bug. > > 023ef184fff6ac2e7cba345708f35536a2a419cb is first bad commit > commit 023ef184fff6ac2e7cba345708f35536a2a419cb > Author: Stuart Menefy <[EMAIL PROTECTED]> > Date: Fri Sep 28 12:36:35 2007 +0900 > > sh: __copy_user() optimizations for small copies. > > This implements a fast-path for small (less than 12 bytes) copies, > with the existing path treated as the slow-path and left as the default > behaviour for all other copy sizes. > > Signed-off-by: Stuart Menefy <[EMAIL PROTECTED]> > Signed-off-by: Paul Mundt <[EMAIL PROTECTED]> > > :04 04 43f62cf05d1f71a5564b232dfd9e8492af909a90 > 4ab51dc5b85bc9bc86d58331845e525a67751be8 > > My bisect log: > *START_ BAD - _CURRENT_ > 30 October "No Init found" > BAD - b5869ce7f68b233ceb81465a7655be0d9a5f3dbb"Merge git://..sched" > 15 October "No Init found" > BAD - f248488b397d52717f6683e2e53200aa687ffc89"merge infradead.org" > 14 October "No Init found" > BAD - 3749c66c67fb5c257771815c186bc32290cacf44"merge git/avi/kvm" > 13 October "No Init found" > BAD - dcf397f037f52add9945eced57ca300ab6a4413c"merge sh-2.6" > 13 October "No Init found" > BAD - 5d9df8eeacec943c9599f1cfd1069bc8cced3de6"sh: Fix SH-4 DMAC.." > "8 October" "No Init found" > BAD - e5137682a1ad48bc5306070935c277e262f119ef"sh: Tidy up gUSA .." > "28 September" "No Init found" > BAD - 023ef184fff6ac2e7cba345708f35536a2a419cb"sh: __copy_user().." > "28 September" "No Init found" > GOOD- 24eb17e0813490497f4d5b2fad218bdba402cece"sh: clkfwk: > Support." "28 September" "WORKS!" > GOOD- cb7af21f7d370edb3a6a6d3e15cb17c8fd61591e"sh: Use boot_cpu_d." > "27 September" "WORKS!" > GOOD- c167aeef232c45deaf5c6c9be00a1f71b14962d3"sh: Kill off dupl.." > "27 September" "WORKS!" > GOOD- 1db4e9bb5682fd3fd3f37f7fe9c322e7c5bb7578"sh: don't enable.." > "11 September" "WORKS!" > GOOD- ab9c232286c2b77be78441c2d8396500b045777e"Merge..libata-dev" > 12 October "WORKS!" > GOOD- ce9d3c9a6a9aef61525be07fe6ba27d937236aa2"Merge-br.. for > linux" 11 October "WORKS!" > GOOD- d85f57938ad1d674dff8077a2e6a36a45dbe0e22"Merge branch > 'master'" 26 Sept "WORKS!" > GOOD- 2aee6198652b32e5eaef29a8f8330a9dd15b8efd"fixes-jgarzik" > 25 Sept "WORKS!" > GOOD- f3d5e3a4155b6f42f6f6f0a2cc95ca0adbabe1af"[PPP] L2TP: Fix .. > 19 Sept "WORKS!" > GOOD- 53a3f3087be361dacfc02e7a85b6d6142a41ce8a~2.6.23-rc > 14 Sept "WORKS!" > GOOD- ea3c4b126ad63bd782c7bb5266bb4fd88e203169~2.6.23-rc >4 Sept "WORKS!" > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SUPERH / PATA / SCSI] Unable to do start userland after kernel boot (BISECTED)
On Wed, 31 Oct 2007 02:56:21 -0700 Kristoffer Ericson [EMAIL PROTECTED] wrote: On Fri, 26 Oct 2007 04:46:18 +0900 Paul Mundt [EMAIL PROTECTED] wrote: On Thu, Oct 25, 2007 at 09:22:40PM -0700, Kristoffer Ericson wrote: The bottom line seems to be that it fails to attach scsi sg0. It explains why it doesn't work, but not why it stopped working. And this has nothing to do with the current kernel config, I've been over that the last 4 days. It all started when I synced my jlime-current.git repository with linux-2.6.git. As you can see I had 2.6.23-rc6 and then synced up to 2.6.23-rc8/rc9 and thats when the troubles started. At least that suggests it's not fallout from the INTC changes in -rc1, so that helps to narrow it down a bit. Since you have a known good and bad, it would be nice if you could bisect this to figure out what exactly caused the regression. There weren't any SH-specific changes between rc6 and rc8/rc9 at least. Just wanted to confirm that when reverting the patch below my kernels start booting again. Bisect is a pain to go through, but is really effective. I've spent a couple of hours bisecting it, and this is where it stops working. I haven't reversed the patch yet, simply because Im dead tired :D Will do that tommorow, but Im quite confident that this is the correct bug. 023ef184fff6ac2e7cba345708f35536a2a419cb is first bad commit commit 023ef184fff6ac2e7cba345708f35536a2a419cb Author: Stuart Menefy [EMAIL PROTECTED] Date: Fri Sep 28 12:36:35 2007 +0900 sh: __copy_user() optimizations for small copies. This implements a fast-path for small (less than 12 bytes) copies, with the existing path treated as the slow-path and left as the default behaviour for all other copy sizes. Signed-off-by: Stuart Menefy [EMAIL PROTECTED] Signed-off-by: Paul Mundt [EMAIL PROTECTED] :04 04 43f62cf05d1f71a5564b232dfd9e8492af909a90 4ab51dc5b85bc9bc86d58331845e525a67751be8 My bisect log: *START_ BAD - _CURRENT_ 30 October No Init found BAD - b5869ce7f68b233ceb81465a7655be0d9a5f3dbbMerge git://..sched 15 October No Init found BAD - f248488b397d52717f6683e2e53200aa687ffc89merge infradead.org 14 October No Init found BAD - 3749c66c67fb5c257771815c186bc32290cacf44merge git/avi/kvm 13 October No Init found BAD - dcf397f037f52add9945eced57ca300ab6a4413cmerge sh-2.6 13 October No Init found BAD - 5d9df8eeacec943c9599f1cfd1069bc8cced3de6sh: Fix SH-4 DMAC.. 8 October No Init found BAD - e5137682a1ad48bc5306070935c277e262f119efsh: Tidy up gUSA .. 28 September No Init found BAD - 023ef184fff6ac2e7cba345708f35536a2a419cbsh: __copy_user().. 28 September No Init found GOOD- 24eb17e0813490497f4d5b2fad218bdba402cecesh: clkfwk: Support. 28 September WORKS! GOOD- cb7af21f7d370edb3a6a6d3e15cb17c8fd61591esh: Use boot_cpu_d. 27 September WORKS! GOOD- c167aeef232c45deaf5c6c9be00a1f71b14962d3sh: Kill off dupl.. 27 September WORKS! GOOD- 1db4e9bb5682fd3fd3f37f7fe9c322e7c5bb7578sh: don't enable.. 11 September WORKS! GOOD- ab9c232286c2b77be78441c2d8396500b045777eMerge..libata-dev 12 October WORKS! GOOD- ce9d3c9a6a9aef61525be07fe6ba27d937236aa2Merge-br.. for linux 11 October WORKS! GOOD- d85f57938ad1d674dff8077a2e6a36a45dbe0e22Merge branch 'master' 26 Sept WORKS! GOOD- 2aee6198652b32e5eaef29a8f8330a9dd15b8efdfixes-jgarzik 25 Sept WORKS! GOOD- f3d5e3a4155b6f42f6f6f0a2cc95ca0adbabe1af[PPP] L2TP: Fix .. 19 Sept WORKS! GOOD- 53a3f3087be361dacfc02e7a85b6d6142a41ce8a~2.6.23-rc 14 Sept WORKS! GOOD- ea3c4b126ad63bd782c7bb5266bb4fd88e203169~2.6.23-rc 4 Sept WORKS! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SUPERH / PATA / SCSI] Unable to do start userland after kernel boot (BISECTED)
On Fri, 26 Oct 2007 04:46:18 +0900 Paul Mundt <[EMAIL PROTECTED]> wrote: > On Thu, Oct 25, 2007 at 09:22:40PM -0700, Kristoffer Ericson wrote: > > The bottom line seems to be that it fails to attach scsi sg0. It > > explains why it doesn't work, but not why it stopped working. And this > > has nothing to do with the current kernel config, I've been over that > > the last 4 days. It all started when I synced my jlime-current.git > > repository with linux-2.6.git. As you can see I had 2.6.23-rc6 and then > > synced up to 2.6.23-rc8/rc9 and thats when the troubles started. > > > At least that suggests it's not fallout from the INTC changes in -rc1, so > that helps to narrow it down a bit. Since you have a known good and bad, > it would be nice if you could bisect this to figure out what exactly > caused the regression. There weren't any SH-specific changes between rc6 > and rc8/rc9 at least. I've spent a couple of hours bisecting it, and this is where it stops working. I haven't reversed the patch yet, simply because Im dead tired :D Will do that tommorow, but Im quite confident that this is the correct bug. 023ef184fff6ac2e7cba345708f35536a2a419cb is first bad commit commit 023ef184fff6ac2e7cba345708f35536a2a419cb Author: Stuart Menefy <[EMAIL PROTECTED]> Date: Fri Sep 28 12:36:35 2007 +0900 sh: __copy_user() optimizations for small copies. This implements a fast-path for small (less than 12 bytes) copies, with the existing path treated as the slow-path and left as the default behaviour for all other copy sizes. Signed-off-by: Stuart Menefy <[EMAIL PROTECTED]> Signed-off-by: Paul Mundt <[EMAIL PROTECTED]> :04 04 43f62cf05d1f71a5564b232dfd9e8492af909a90 4ab51dc5b85bc9bc86d58331845e525a67751be8 My bisect log: *START_ BAD - _CURRENT_ 30 October "No Init found" BAD - b5869ce7f68b233ceb81465a7655be0d9a5f3dbb"Merge git://..sched" 15 October "No Init found" BAD - f248488b397d52717f6683e2e53200aa687ffc89"merge infradead.org" 14 October "No Init found" BAD - 3749c66c67fb5c257771815c186bc32290cacf44"merge git/avi/kvm" 13 October "No Init found" BAD - dcf397f037f52add9945eced57ca300ab6a4413c"merge sh-2.6" 13 October "No Init found" BAD - 5d9df8eeacec943c9599f1cfd1069bc8cced3de6"sh: Fix SH-4 DMAC.." "8 October" "No Init found" BAD - e5137682a1ad48bc5306070935c277e262f119ef"sh: Tidy up gUSA .." "28 September" "No Init found" BAD - 023ef184fff6ac2e7cba345708f35536a2a419cb"sh: __copy_user().." "28 September" "No Init found" GOOD- 24eb17e0813490497f4d5b2fad218bdba402cece"sh: clkfwk: Support." "28 September" "WORKS!" GOOD- cb7af21f7d370edb3a6a6d3e15cb17c8fd61591e"sh: Use boot_cpu_d." "27 September" "WORKS!" GOOD- c167aeef232c45deaf5c6c9be00a1f71b14962d3"sh: Kill off dupl.." "27 September" "WORKS!" GOOD- 1db4e9bb5682fd3fd3f37f7fe9c322e7c5bb7578"sh: don't enable.." "11 September" "WORKS!" GOOD- ab9c232286c2b77be78441c2d8396500b045777e"Merge..libata-dev" 12 October "WORKS!" GOOD- ce9d3c9a6a9aef61525be07fe6ba27d937236aa2"Merge-br.. for linux" 11 October "WORKS!" GOOD- d85f57938ad1d674dff8077a2e6a36a45dbe0e22"Merge branch 'master'" 26 Sept "WORKS!" GOOD- 2aee6198652b32e5eaef29a8f8330a9dd15b8efd"fixes-jgarzik" 25 Sept "WORKS!" GOOD- f3d5e3a4155b6f42f6f6f0a2cc95ca0adbabe1af"[PPP] L2TP: Fix .. 19 Sept "WORKS!" GOOD- 53a3f3087be361dacfc02e7a85b6d6142a41ce8a~2.6.23-rc 14 Sept "WORKS!" GOOD- ea3c4b126ad63bd782c7bb5266bb4fd88e203169~2.6.23-rc 4 Sept "WORKS!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
On Tue, 30 Oct 2007 21:47:20 +0100 Norbert Preining <[EMAIL PROTECTED]> wrote: > Hi Kristoffer, > > thanks for the feedback. > > On Di, 30 Okt 2007, Kristoffer Ericson wrote: > > Im using a Huawei E220 USB modem, currently running 2.6.22.5 vanilla > > kernel. It has worked fine for me since 2.6.21. > > Strange. I rebuilt the kernel, compiled the usb serial and options into > the kernel, while leaving usb-storage as module. Still I have to issue > the huaweiAktBbo program to get it working/switching into the *right* > modus. > > > The lights give you a hint what mode its in. Green = usb_storage, Dark-blue > > = MODEM_slow, bright-blue = MODEM_fast (3G). > > BTW, I have seen a slightly different pattern: Green blinking from the > beginning I get green blinking up to udev, then it turns into dark blue. > calling huaweiAktBbo to make the switch > still blinking green > calling the internet provider > when the connection is established (on the hardware level, not on ip > level) the modem starts blinking blue and then solid blue > turning off the ppp connection it goes into blinking blue mode > I have no experience with huewaiAktBbo, I just use wvdial, works nicely. Solid color also symbolises "Established mode" for me. > > If the light is green after reboot, I need to reboot again until it turns > > blue. I know this sucks, but just something I've noticed. > > Probably you could use the huaweiAktBbo program for this, too. > I've noticed that it depends on the USB host somehow. On my laptop I need to restart 3 times before it will go into "blue mode" properly. On my primary PC though, it always works right away. No idea why and haven't had the time to bugtrack it. > Best wishes > > Norbert > > --- > Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of > Technology > Debian Developer <[EMAIL PROTECTED]> Debian TeX Group > gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 > B094 > --- > HASELBURY PLUCKNETT (n.) > A mechanical device for cleaning combs invented during the industrial > revolution at the same time as Arkwright's Spinning Jenny, but which > didn't catch on in the same way. > --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
Greetings, Im using a Huawei E220 USB modem, currently running 2.6.22.5 vanilla kernel. It has worked fine for me since 2.6.21. The lights give you a hint what mode its in. Green = usb_storage, Dark-blue = MODEM_slow, bright-blue = MODEM_fast (3G). If the light is green after reboot, I need to reboot again until it turns blue. I know this sucks, but just something I've noticed. One hint is to put the USB modem as static in kernel and usb_storage as module. Best wishes Kristoffer Ericson On Tue, 30 Oct 2007 20:09:45 +0100 Norbert Preining <[EMAIL PROTECTED]> wrote: > Dear all, > > I recently got an Huawei E220 usb modem. Reading a bit on the net I > found that: > > The Huaweii E220 modem is a composite USB device: in fact it acts like a > mass storage device, and also as three serial communication ports. The > Linux's developers dealt with this ignoring the mass device storage > (which is a read-only mass storage, i.e. a CD-ROM with preload software > only for Windows). For more information see > http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.20-rc2 or > http://lwn.net/Articles/220545/ where you read the changelog for 2.6.20 > linux kernel. The interesting part is reported here below: > > [...] > Johann Wilhelm (2): usb-storage: Ignore the virtual cd-drive of the > Huawei E220 USB Modem usb-gsm-driver: Added VendorId and ProductId for > Huawei E220 USB Modem > [...] > > This modification is present from Linux kernel 2.6.20 and more recent > ones. > > See: http://ske.sourceforge.net/html/projects/huawei/huawei_tre.html > > Now that I plug my modem I definitely get this usb storage device, and I > need to call a special program to switch to the other mode > (huaweiAktBbo, from > http://www.kanoistika.sk/bobovsky/archiv/umts/huaweiAktBbo.c). > > Several pages on the web state that it should work *without* this switch > program. > > Is this a regression from 2.6.20, or is it supposed to work? > > Thanks a lot and all the best > > Norbert > > --- > Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of > Technology > Debian Developer <[EMAIL PROTECTED]> Debian TeX Group > gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 > B094 > --- > DEAL (n.) > The gummy substance found between damp toes. > --- Douglas Adams, The Meaning of Liff > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
Greetings, Im using a Huawei E220 USB modem, currently running 2.6.22.5 vanilla kernel. It has worked fine for me since 2.6.21. The lights give you a hint what mode its in. Green = usb_storage, Dark-blue = MODEM_slow, bright-blue = MODEM_fast (3G). If the light is green after reboot, I need to reboot again until it turns blue. I know this sucks, but just something I've noticed. One hint is to put the USB modem as static in kernel and usb_storage as module. Best wishes Kristoffer Ericson On Tue, 30 Oct 2007 20:09:45 +0100 Norbert Preining [EMAIL PROTECTED] wrote: Dear all, I recently got an Huawei E220 usb modem. Reading a bit on the net I found that: The Huaweii E220 modem is a composite USB device: in fact it acts like a mass storage device, and also as three serial communication ports. The Linux's developers dealt with this ignoring the mass device storage (which is a read-only mass storage, i.e. a CD-ROM with preload software only for Windows). For more information see http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.20-rc2 or http://lwn.net/Articles/220545/ where you read the changelog for 2.6.20 linux kernel. The interesting part is reported here below: [...] Johann Wilhelm (2): usb-storage: Ignore the virtual cd-drive of the Huawei E220 USB Modem usb-gsm-driver: Added VendorId and ProductId for Huawei E220 USB Modem [...] This modification is present from Linux kernel 2.6.20 and more recent ones. See: http://ske.sourceforge.net/html/projects/huawei/huawei_tre.html Now that I plug my modem I definitely get this usb storage device, and I need to call a special program to switch to the other mode (huaweiAktBbo, from http://www.kanoistika.sk/bobovsky/archiv/umts/huaweiAktBbo.c). Several pages on the web state that it should work *without* this switch program. Is this a regression from 2.6.20, or is it supposed to work? Thanks a lot and all the best Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Vienna University of Technology Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- DEAL (n.) The gummy substance found between damp toes. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Huawei E220 and usb storage
On Tue, 30 Oct 2007 21:47:20 +0100 Norbert Preining [EMAIL PROTECTED] wrote: Hi Kristoffer, thanks for the feedback. On Di, 30 Okt 2007, Kristoffer Ericson wrote: Im using a Huawei E220 USB modem, currently running 2.6.22.5 vanilla kernel. It has worked fine for me since 2.6.21. Strange. I rebuilt the kernel, compiled the usb serial and options into the kernel, while leaving usb-storage as module. Still I have to issue the huaweiAktBbo program to get it working/switching into the *right* modus. The lights give you a hint what mode its in. Green = usb_storage, Dark-blue = MODEM_slow, bright-blue = MODEM_fast (3G). BTW, I have seen a slightly different pattern: Green blinking from the beginning I get green blinking up to udev, then it turns into dark blue. calling huaweiAktBbo to make the switch still blinking green calling the internet provider when the connection is established (on the hardware level, not on ip level) the modem starts blinking blue and then solid blue turning off the ppp connection it goes into blinking blue mode I have no experience with huewaiAktBbo, I just use wvdial, works nicely. Solid color also symbolises Established mode for me. If the light is green after reboot, I need to reboot again until it turns blue. I know this sucks, but just something I've noticed. Probably you could use the huaweiAktBbo program for this, too. I've noticed that it depends on the USB host somehow. On my laptop I need to restart 3 times before it will go into blue mode properly. On my primary PC though, it always works right away. No idea why and haven't had the time to bugtrack it. Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Vienna University of Technology Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HASELBURY PLUCKNETT (n.) A mechanical device for cleaning combs invented during the industrial revolution at the same time as Arkwright's Spinning Jenny, but which didn't catch on in the same way. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SUPERH / PATA / SCSI] Unable to do start userland after kernel boot (BISECTED)
On Fri, 26 Oct 2007 04:46:18 +0900 Paul Mundt [EMAIL PROTECTED] wrote: On Thu, Oct 25, 2007 at 09:22:40PM -0700, Kristoffer Ericson wrote: The bottom line seems to be that it fails to attach scsi sg0. It explains why it doesn't work, but not why it stopped working. And this has nothing to do with the current kernel config, I've been over that the last 4 days. It all started when I synced my jlime-current.git repository with linux-2.6.git. As you can see I had 2.6.23-rc6 and then synced up to 2.6.23-rc8/rc9 and thats when the troubles started. At least that suggests it's not fallout from the INTC changes in -rc1, so that helps to narrow it down a bit. Since you have a known good and bad, it would be nice if you could bisect this to figure out what exactly caused the regression. There weren't any SH-specific changes between rc6 and rc8/rc9 at least. I've spent a couple of hours bisecting it, and this is where it stops working. I haven't reversed the patch yet, simply because Im dead tired :D Will do that tommorow, but Im quite confident that this is the correct bug. 023ef184fff6ac2e7cba345708f35536a2a419cb is first bad commit commit 023ef184fff6ac2e7cba345708f35536a2a419cb Author: Stuart Menefy [EMAIL PROTECTED] Date: Fri Sep 28 12:36:35 2007 +0900 sh: __copy_user() optimizations for small copies. This implements a fast-path for small (less than 12 bytes) copies, with the existing path treated as the slow-path and left as the default behaviour for all other copy sizes. Signed-off-by: Stuart Menefy [EMAIL PROTECTED] Signed-off-by: Paul Mundt [EMAIL PROTECTED] :04 04 43f62cf05d1f71a5564b232dfd9e8492af909a90 4ab51dc5b85bc9bc86d58331845e525a67751be8 My bisect log: *START_ BAD - _CURRENT_ 30 October No Init found BAD - b5869ce7f68b233ceb81465a7655be0d9a5f3dbbMerge git://..sched 15 October No Init found BAD - f248488b397d52717f6683e2e53200aa687ffc89merge infradead.org 14 October No Init found BAD - 3749c66c67fb5c257771815c186bc32290cacf44merge git/avi/kvm 13 October No Init found BAD - dcf397f037f52add9945eced57ca300ab6a4413cmerge sh-2.6 13 October No Init found BAD - 5d9df8eeacec943c9599f1cfd1069bc8cced3de6sh: Fix SH-4 DMAC.. 8 October No Init found BAD - e5137682a1ad48bc5306070935c277e262f119efsh: Tidy up gUSA .. 28 September No Init found BAD - 023ef184fff6ac2e7cba345708f35536a2a419cbsh: __copy_user().. 28 September No Init found GOOD- 24eb17e0813490497f4d5b2fad218bdba402cecesh: clkfwk: Support. 28 September WORKS! GOOD- cb7af21f7d370edb3a6a6d3e15cb17c8fd61591esh: Use boot_cpu_d. 27 September WORKS! GOOD- c167aeef232c45deaf5c6c9be00a1f71b14962d3sh: Kill off dupl.. 27 September WORKS! GOOD- 1db4e9bb5682fd3fd3f37f7fe9c322e7c5bb7578sh: don't enable.. 11 September WORKS! GOOD- ab9c232286c2b77be78441c2d8396500b045777eMerge..libata-dev 12 October WORKS! GOOD- ce9d3c9a6a9aef61525be07fe6ba27d937236aa2Merge-br.. for linux 11 October WORKS! GOOD- d85f57938ad1d674dff8077a2e6a36a45dbe0e22Merge branch 'master' 26 Sept WORKS! GOOD- 2aee6198652b32e5eaef29a8f8330a9dd15b8efdfixes-jgarzik 25 Sept WORKS! GOOD- f3d5e3a4155b6f42f6f6f0a2cc95ca0adbabe1af[PPP] L2TP: Fix .. 19 Sept WORKS! GOOD- 53a3f3087be361dacfc02e7a85b6d6142a41ce8a~2.6.23-rc 14 Sept WORKS! GOOD- ea3c4b126ad63bd782c7bb5266bb4fd88e203169~2.6.23-rc 4 Sept WORKS! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[SUPERH / PATA / SCSI] Unable to do start userland after kernel boot
Greetings, I know I'm being annoying about this, but kinda a show stopper for hp6xx currently. I compaired a bootlog (good kernel vs bad kernel), and they are identical apart from this stuff The bottom line seems to be that it fails to attach scsi sg0. It explains why it doesn't work, but not why it stopped working. And this has nothing to do with the current kernel config, I've been over that the last 4 days. It all started when I synced my jlime-current.git repository with linux-2.6.git. As you can see I had 2.6.23-rc6 and then synced up to 2.6.23-rc8/rc9 and thats when the troubles started. Any scsi/libata gurus giving feedback on this would be appreciated. Best wishes Kristoffer Ericson [BAD KERNEL] (Linux version 2.6.23-gbc53c3a1-dirty ([EMAIL PROTECTED]) (gcc version 3.4.5) #2 Tue Oct 23 19:34:27 PDT 2007) scsi0 : pata_platform ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77 <-- "mmio cmd" + "" ata1.00: CFA: Hitachi XX.V.3.5.0.0, Rev 0.00, max PIO4 ata1.00: 2002896 sectors, multi 0: LBA ata1.00: configured for PIO scsi 0:0:0:0: Direct-Access ATA Hitachi XX.V.3.5 Rev PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI removable disk . . EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 128k freed Failed to execute /bin/sh. Attempting defaults... Kernel panic - not syncing: No init found. Try passing init= option to kernel. [GOOD KERNEL] (Linux version 2.6.23-rc6-gab762e2c-dirty ([EMAIL PROTECTED]) (gcc version 3.4.4) #51 Sun Oct 21 15:23:19 ART 2007) scsi0 : pata_platform ata1: PATA max PIO0 cmd 0xb50001f0 ctl 0xb50001fe bmdma 0x irq 77 <--- "cmd" + "bmdma" ata1.00: CFA: Hitachi XX.V.3.5.0.0, Rev 0.00, max PIO4 ata1.00: 2002896 sectors, multi 0: LBA ata1.00: configured for PIO ata1: EH pending after completion, repeating EH (cnt=4) scsi 0:0:0:0: Direct-Access ATA Hitachi XX.V.3.5 Rev PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI removable disk sd 0:0:0:0: Attached scsi generic sg0 type 0 < Only here, missing from bad kernel. ... . EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 140k freed /bin/sh: can't access tty; job control turned off (init=/bin/sh was used as bootparam) / $ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[SUPERH / PATA / SCSI] Unable to do start userland after kernel boot
Greetings, I know I'm being annoying about this, but kinda a show stopper for hp6xx currently. I compaired a bootlog (good kernel vs bad kernel), and they are identical apart from this stuff The bottom line seems to be that it fails to attach scsi sg0. It explains why it doesn't work, but not why it stopped working. And this has nothing to do with the current kernel config, I've been over that the last 4 days. It all started when I synced my jlime-current.git repository with linux-2.6.git. As you can see I had 2.6.23-rc6 and then synced up to 2.6.23-rc8/rc9 and thats when the troubles started. Any scsi/libata gurus giving feedback on this would be appreciated. Best wishes Kristoffer Ericson [BAD KERNEL] (Linux version 2.6.23-gbc53c3a1-dirty ([EMAIL PROTECTED]) (gcc version 3.4.5) #2 Tue Oct 23 19:34:27 PDT 2007) scsi0 : pata_platform ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77 -- mmio cmd + ata1.00: CFA: Hitachi XX.V.3.5.0.0, Rev 0.00, max PIO4 ata1.00: 2002896 sectors, multi 0: LBA ata1.00: configured for PIO scsi 0:0:0:0: Direct-Access ATA Hitachi XX.V.3.5 Rev PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI removable disk . . EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 128k freed Failed to execute /bin/sh. Attempting defaults... Kernel panic - not syncing: No init found. Try passing init= option to kernel. [GOOD KERNEL] (Linux version 2.6.23-rc6-gab762e2c-dirty ([EMAIL PROTECTED]) (gcc version 3.4.4) #51 Sun Oct 21 15:23:19 ART 2007) scsi0 : pata_platform ata1: PATA max PIO0 cmd 0xb50001f0 ctl 0xb50001fe bmdma 0x irq 77 --- cmd + bmdma ata1.00: CFA: Hitachi XX.V.3.5.0.0, Rev 0.00, max PIO4 ata1.00: 2002896 sectors, multi 0: LBA ata1.00: configured for PIO ata1: EH pending after completion, repeating EH (cnt=4) scsi 0:0:0:0: Direct-Access ATA Hitachi XX.V.3.5 Rev PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI removable disk sd 0:0:0:0: Attached scsi generic sg0 type 0 Only here, missing from bad kernel. ... . EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 140k freed /bin/sh: can't access tty; job control turned off (init=/bin/sh was used as bootparam) / $ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
