Re: [PATCH 00/10] ARM: OMAP1: ams-delta: replace custom I/O with GPIO
On Sun, Dec 11, 2011 at 09:11:58PM +0100, Janusz Krzysztofik wrote: > The Amstrad Delta board has two extra output ports used for driving > input lines of different on-board devices. Those ports are now > controlled with custom functions, provided by the board arch code and > used by several device drivers. > > The idea behind the series is to replace those custom I/O functions > with gpiolib API. This way, existing drivers can be made less platform > dependent, and some of them perhaps even superseded with generic GPIO > based drivers after the board platform device descriptions are > converted. Moreover, should a new driver for the on-board Smart Card > controller ever be created, it could be designed as a generic GPIO > based driver, not a custom one. Nice work; moving ams-delta over to gpiolib has been on my todo list for a while (albeit quite low down). J. -- I just Fedexed my soul to hell. I'm *real* clever. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] video: omap: Staticise non-exported symbols
atic int palmte_panel_resume(struct platform_device
> > *pdev) return 0;
> > }
> >
> > -struct platform_driver palmte_panel_driver = {
> > +static struct platform_driver palmte_panel_driver = {
> > .probe = palmte_panel_probe,
> > .remove = palmte_panel_remove,
> > .suspend= palmte_panel_suspend,
> > diff --git a/drivers/video/omap/lcd_palmtt.c
> > b/drivers/video/omap/lcd_palmtt.c index b51b332..c2e96a7 100644
> > --- a/drivers/video/omap/lcd_palmtt.c
> > +++ b/drivers/video/omap/lcd_palmtt.c
> > @@ -102,7 +102,7 @@ static int palmtt_panel_resume(struct platform_device
> > *pdev) return 0;
> > }
> >
> > -struct platform_driver palmtt_panel_driver = {
> > +static struct platform_driver palmtt_panel_driver = {
> > .probe = palmtt_panel_probe,
> > .remove = palmtt_panel_remove,
> > .suspend = palmtt_panel_suspend,
> > diff --git a/drivers/video/omap/lcd_palmz71.c
> > b/drivers/video/omap/lcd_palmz71.c index 2334e56..1ab4847 100644
> > --- a/drivers/video/omap/lcd_palmz71.c
> > +++ b/drivers/video/omap/lcd_palmz71.c
> > @@ -98,7 +98,7 @@ static int palmz71_panel_resume(struct platform_device
> > *pdev) return 0;
> > }
> >
> > -struct platform_driver palmz71_panel_driver = {
> > +static struct platform_driver palmz71_panel_driver = {
> > .probe = palmz71_panel_probe,
> > .remove = palmz71_panel_remove,
> > .suspend= palmz71_panel_suspend,
>
> I can speak for palmtt and palmz71,
>
> Acked-by: Marek Vasut
Likewise, for ams-delta,
Acked-By: Jonathan McDowell
J.
--
Generally, all generalizations are false..
This .sig brought to you by the letter Z and the number 26
Product of the Republic of HuggieTag
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] video: omap: convert drivers/video/omap/* to use module_platform_driver()
On Fri, Dec 09, 2011 at 09:24:29AM +0100, Marek Vasut wrote:
> > This patch converts the drivers in drivers/video/omap/* to use the
> > module_platform_driver() macro which makes the code smaller and a bit
> > simpler.
> >
> > Cc: Jonathan McDowell
> > Cc: Cory Maccarrone
> > Cc: Laurent Gonzalez
> > Cc: Marek Vasut
> > Signed-off-by: Axel Lin
> > ---
> > drivers/video/omap/lcd_ams_delta.c | 13 +
> > drivers/video/omap/lcd_h3.c| 14 +-
> > drivers/video/omap/lcd_htcherald.c | 14 +-
> > drivers/video/omap/lcd_inn1510.c | 14 +-
> > drivers/video/omap/lcd_inn1610.c | 14 +-
> > drivers/video/omap/lcd_osk.c | 14 +-
> > drivers/video/omap/lcd_palmte.c| 14 +-
> > drivers/video/omap/lcd_palmtt.c| 13 +
> > drivers/video/omap/lcd_palmz71.c | 13 +
> > 9 files changed, 9 insertions(+), 114 deletions(-)
> >
> > diff --git a/drivers/video/omap/lcd_ams_delta.c
> > b/drivers/video/omap/lcd_ams_delta.c index eb50a95..0fdd6f6 100644
> > --- a/drivers/video/omap/lcd_ams_delta.c
> > +++ b/drivers/video/omap/lcd_ams_delta.c
> > @@ -209,15 +209,4 @@ static struct platform_driver ams_delta_panel_driver =
> > { },
> > };
> >
> > -static int __init ams_delta_panel_drv_init(void)
> > -{
> > - return platform_driver_register(&ams_delta_panel_driver);
> > -}
> > -
> > -static void __exit ams_delta_panel_drv_cleanup(void)
> > -{
> > - platform_driver_unregister(&ams_delta_panel_driver);
> > -}
> > -
> > -module_init(ams_delta_panel_drv_init);
> > -module_exit(ams_delta_panel_drv_cleanup);
> > +module_platform_driver(ams_delta_panel_driver);
> > diff --git a/drivers/video/omap/lcd_h3.c b/drivers/video/omap/lcd_h3.c
> > index baec34e..49bdeca 100644
> > --- a/drivers/video/omap/lcd_h3.c
> > +++ b/drivers/video/omap/lcd_h3.c
> > @@ -124,16 +124,4 @@ static struct platform_driver h3_panel_driver = {
> > },
> > };
> >
> > -static int __init h3_panel_drv_init(void)
> > -{
> > - return platform_driver_register(&h3_panel_driver);
> > -}
> > -
> > -static void __exit h3_panel_drv_cleanup(void)
> > -{
> > - platform_driver_unregister(&h3_panel_driver);
> > -}
> > -
> > -module_init(h3_panel_drv_init);
> > -module_exit(h3_panel_drv_cleanup);
> > -
> > +module_platform_driver(h3_panel_driver);
> > diff --git a/drivers/video/omap/lcd_htcherald.c
> > b/drivers/video/omap/lcd_htcherald.c index b1a022f..20f4778 100644
> > --- a/drivers/video/omap/lcd_htcherald.c
> > +++ b/drivers/video/omap/lcd_htcherald.c
> > @@ -115,16 +115,4 @@ static struct platform_driver htcherald_panel_driver =
> > { },
> > };
> >
> > -static int __init htcherald_panel_drv_init(void)
> > -{
> > - return platform_driver_register(&htcherald_panel_driver);
> > -}
> > -
> > -static void __exit htcherald_panel_drv_cleanup(void)
> > -{
> > - platform_driver_unregister(&htcherald_panel_driver);
> > -}
> > -
> > -module_init(htcherald_panel_drv_init);
> > -module_exit(htcherald_panel_drv_cleanup);
> > -
> > +module_platform_driver(htcherald_panel_driver);
> > diff --git a/drivers/video/omap/lcd_inn1510.c
> > b/drivers/video/omap/lcd_inn1510.c index d129946..b38b1dd 100644
> > --- a/drivers/video/omap/lcd_inn1510.c
> > +++ b/drivers/video/omap/lcd_inn1510.c
> > @@ -109,16 +109,4 @@ static struct platform_driver
> > innovator1510_panel_driver = { },
> > };
> >
> > -static int __init innovator1510_panel_drv_init(void)
> > -{
> > - return platform_driver_register(&innovator1510_panel_driver);
> > -}
> > -
> > -static void __exit innovator1510_panel_drv_cleanup(void)
> > -{
> > - platform_driver_unregister(&innovator1510_panel_driver);
> > -}
> > -
> > -module_init(innovator1510_panel_drv_init);
> > -module_exit(innovator1510_panel_drv_cleanup);
> > -
> > +module_platform_driver(innovator1510_panel_driver);
> > diff --git a/drivers/video/omap/lcd_inn1610.c
> > b/drivers/video/omap/lcd_inn1610.c index a95756b..7e8bd8e 100644
> > --- a/drivers/video/omap/lcd_inn1610.c
> > +++ b/drivers/video/omap/lcd_inn1610.c
> > @@ -133,16 +133,4 @@ static struct platform_driver
> > innovator1610_panel_driver = { },
> > };
> >
> > -static int __init innovator1610_panel_drv_init(void)
Re: [PATCHv1 1/3] OMAP UART: Adds omap-serial driver support.
On Thu, Sep 24, 2009 at 03:57:13PM +0530, Govindraj.R wrote: > From: Govindraj R > > This patch adds support for OMAP3430-HIGH SPEED UART Controller. > > Signed-off-by:Govindraj R > Reviewed-by: Alan Cox > Reviewed-by: Tony Lindgren > --- > +config SERIAL_OMAP > + bool "OMAP serial port support" > + depends on ARM && ARCH_OMAP > + select SERIAL_CORE > + help > + If you have a machine based on an Texas Instruments OMAP CPU you > + can enable its onboard serial ports by enabling this option. If it's OMAP3 hardware then should the "depends on" be ARCH_OMAP3 || ARCH_OMAP4, rather than allowing it for OMAP1 + 2 as well? J. -- Revd. Jonathan McDowell, ULC | If they can't take a jokefuck 'em. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: RX51: support sleep indicator LEDs
On Fri, Oct 02, 2009 at 08:35:55AM -0700, Kevin Hilman wrote: > The sleep indicator LEDs can be enabled/disabled by toggling GPIO162. > Request this GPIO in RX51 board init, disable by default and expose > GPIO162 to userspace so LEDs can be toggled from userspace: Wouldn't this be better done using the LED class subsystem? > To enable: > > # echo 1 > /sys/class/gpio/gpio162/value > > To disable: > > # echo 0 > /sys/class/gpio/gpio162/value > > Signed-off-by: Kevin Hilman > --- J. -- 101 things you can't have too much of : 16 - Time. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP1: AMS_DELTA: add modem support
On Mon, Aug 10, 2009 at 11:12:48AM +0200, Janusz Krzysztofik wrote:
> Jonathan, Tony,
>
> Any chance for this patch ready for 2.6.32 inclusion? Or maybe v2,
> that has no external dependencies and can be updated later to v3 when
> Vikram's changes get accepted upstream?
Vikram's patch is in linux-next, so there shouldn't be a problem with
this version of your patch for 2.6.32. I haven't been able to test it
myself (though I hope to next week), but it looks ok from a brief
inspection, so:
Acked-By: Jonathan McDowell
> Monday 06 July 2009 12:24:27 Janusz Krzysztofik wrote:
> > This patch adds support for modem device found on Amstrad E3 (Delta) board.
> >
> > Based on earlier patch by Jonathan McDowell, available at
> > http://the.earth.li/pub/e3/2.6.19/ams-delta-modem.patch.
> > Modified after Ladislav Michl's arch/arm/mach-omap1/board-voiceblue.c.
> >
> > This version, unlike v2, is dependent on 8250 driver changes getting
> > accepted upstream:
> > Refer: http://patchwork.kernel.org/patch/31884/
> >
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > Registering the modem platform device from a separate arch_initcall (and
> > not from init_machine() callback) preserves serial console port at ttyS0.
> >
> > OMAP mux pin set up just for case if Amstrad bootloader is ever replaced.
> >
> > Warning:
> > could cause compilation break if 8250 patch is not integrated first
> >
> > --- linux-2.6.31-rc1/arch/arm/mach-omap1/board-ams-delta.c.orig
> > 2009-07-04
> > 16:39:37.0 +0200 +++
> > linux-2.6.31-rc1/arch/arm/mach-omap1/board-ams-delta.c 2009-07-05
> > 13:41:08.0 +0200 @@ -15,8 +15,11 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > +#include
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -235,6 +238,41 @@ static void __init ams_delta_init(void)
> > platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
> > }
> >
> > +static struct plat_serial8250_port ams_delta_modem_ports[] = {
> > + {
> > + .membase= (void *) AMS_DELTA_MODEM_VIRT,
> > + .mapbase= AMS_DELTA_MODEM_PHYS,
> > + .irq= -EINVAL, /* changed later */
> > + .flags = UPF_BOOT_AUTOCONF,
> > + .irqflags = IRQF_TRIGGER_RISING,
> > + .iotype = UPIO_MEM,
> > + .regshift = 1,
> > + .uartclk= BASE_BAUD * 16,
> > + },
> > + { },
> > +};
> > +
> > +static struct platform_device ams_delta_modem_device = {
> > + .name = "serial8250",
> > + .id = PLAT8250_DEV_PLATFORM1,
> > + .dev= {
> > + .platform_data = ams_delta_modem_ports,
> > + },
> > +};
> > +
> > +static int __init ams_delta_modem_init(void)
> > +{
> > + omap_cfg_reg(M14_1510_GPIO2);
> > + ams_delta_modem_ports[0].irq = gpio_to_irq(2);
> > +
> > + ams_delta_latch2_write(
> > + AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
> > + AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
> > +
> > + return platform_device_register(&ams_delta_modem_device);
> > +}
> > +arch_initcall(ams_delta_modem_init);
> > +
> > static void __init ams_delta_map_io(void)
> > {
> > omap1_map_common_io();
>
>
J.
--
Revd. Jonathan McDowell, ULC | I am a passenger.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[TRIVIAL PATCH] Fix compilation of arch/arm/mach-omap1/mailbox.c
This fixes the positioning of " in MODULE_AUTHOR, which is currently
causing a build failure on latest git with CONFIG_OMAP_MBOX_FWK=m; the
original breakage appears to date from the end of last year in
a5abbbe52b7e89a7633319c5417bd4331f7ac8ed
Signed-Off-By: Jonathan McDowell
-
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 0af4d6c..6810b4a 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -203,5 +203,5 @@ module_exit(omap1_mbox_exit);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("omap mailbox: omap1 architecture specific functions");
-MODULE_AUTHOR("Hiroshi DOYU" );
+MODULE_AUTHOR("Hiroshi DOYU ");
MODULE_ALIAS("platform:omap1-mailbox");
-
J.
--
] http://www.earth.li/~noodles/ [] "Making the impossible very [
] PGP/GPG Key @ the.earth.li [] difficult" -- The OpenGALEN [
] via keyserver, web or email. [] website. [
] RSA: 4096/2DA8B985[] [
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/20] omapfb: Add support for the Amstrad Delta LCD
On Fri, Jun 05, 2009 at 12:38:22PM +0200, Janusz Krzysztofik wrote: > Thursday 04 June 2009 19:52:29 Imre Deak napisał(a): > > From: Jonathan McDowell > > > > This is an updated version of the LCD driver for the Amstrad Delta to > > take into account the recent changes to the omapfb infrastructure. The > > Delta features a 480x320 12 bit DSTN panel. > > I'd really love to see the lcd_ams_delta support included in the mainline > kernel, but I am not sure if it is ready for submission, as I still have > issues with it. It does work perfectly unless power management is turned on. > With CONFIG_PM=y, the omapfb device, after initially starting correctly, > breaks with the following error messages: > > omapfb omapfb: resetting (status 0xff96,reset count 1) > ... > omapfb omapfb: resetting (status 0xff96,reset count 100) > omapfb omapfb: too many reset attempts, giving up. > > Tested with linux-2.6.30-rc5 and linux-omap revision > 90e758af52ba803cba233fabee81176d99589f09. Error messages do not appear when > CONFIG_PM=n or lcd_ams_delta.o is removed from omapfb-objs. > > Please let me know what else I can do to help in resolving this issue. Reporting it was a good start; it's the first I've heard of this issue. Looking at the E3 configs I have lying around it looks like none of them have CONFIG_PM set, so it's possible most people have just been using the defconfig or a minor variation of it. I don't have my E3 convenient at present to investigate however. J. -- 101 things you can't have too much of : 14 - Paperclips. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] Add support for hook switch on ams-delta
On Wed, Jun 03, 2009 at 11:03:20AM +0200, Janusz Krzysztofik wrote: > Wednesday 03 June 2009 00:04:33 Jonathan McDowell napisał(a): > > I'm obviously too late as I've seen the "Applied" mail, > > No problem, I'm glad to hear from you. > > > but some > > comments: > > > > * I don't think SW_HEADPHONE_INSERT is appropriate. input guys, is it > > not reasonable to have SW_PHONE_HOOK or similar? > > I do share you point of view. However, I didn't want to start a discussion if > there is a need for another symbol or not before the patch got any > acceptance. > > > * We assume the bootloader does the appropriate GPIO pin setup for us, > > so I don't think your omap_cfg_reg is required but it doesn't hurt in > > the unlikely event we ever replace the Amstrad PBL. > > OK, let it stay there. Do you see a need for replaceing it with a new > ams_delta_hook_switch_init() function call that just calls omap_cfg_reg()? I don't see a need for this; it's always present and not a lot of code to have in the init function as it stands. > > * The commented out code to include the GPIO status in sysfs shouldn't > > be included. > > Yes, I put it there to get a feedback. > > > Does the input layer not provide a way to obtain the > > state of the switch? > > Yes, it does, with EVIOCGSW ioctl()[1]. I personally don't like this way of > getting the switch status and would rather see it available over sysfs. > However, input guys may have their own preferences and gpio-keys driver > belongs to them. I think that's a discussion to have with the input guys rather than putting a hack in the platform file then. So really the only issue with the patch that remains is if it justifies adding a new SW_PHONE_HOOK switch type? J. -- ] http://www.earth.li/~noodles/ [] Purranoia: The fear that your cat [ ] PGP/GPG Key @ the.earth.li [] is up to something. [ ] via keyserver, web or email. [] [ ] RSA: 4096/2DA8B985[] [ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] Add support for hook switch on ams-delta
On Tue, May 26, 2009 at 08:57:20PM +0200, Janusz Krzysztofik wrote:
> This trivial patch adds gpio-keys compatible platform device definition to
> ams-delta board, that supports hook switch found on this videophone. It is
> derived from similiar definitions found in other boards code. The patch is
> based on linux-2.6.30-rc5. Any comments are welcome.
I'm obviously too late as I've seen the "Applied" mail, but some
comments:
* I don't think SW_HEADPHONE_INSERT is appropriate. input guys, is it
not reasonable to have SW_PHONE_HOOK or similar? I can't find anything
else in tree I know to be a VOIP phone that has the concept of a hook
switch except perhaps the TuxScreen and it doesn't have anything set
up that I could find. I think you're correct that EV_SW is
appropriate; it may remain in the off-hook state for some time and
AFAICT the gpio-key driver would produce a repeating key press if you
used EV_KEY.
* We assume the bootloader does the appropriate GPIO pin setup for us,
so I don't think your omap_cfg_reg is required but it doesn't hurt in
the unlikely event we ever replace the Amstrad PBL.
* The commented out code to include the GPIO status in sysfs shouldn't
be included. Does the input layer not provide a way to obtain the
state of the switch?
> diff -Npru a/arch/arm/mach-omap1/board-ams-delta.c
> b/arch/arm/mach-omap1/board-ams-delta.c
> --- a/arch/arm/mach-omap1/board-ams-delta.c 2009-05-17 17:58:18.0
> +0200
> +++ b/arch/arm/mach-omap1/board-ams-delta.c 2009-05-17 16:22:59.0
> +0200
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -213,10 +214,35 @@ static struct platform_device ams_delta_
> .id = -1
> };
>
> +static struct gpio_keys_button ams_delta_gpio_keys_buttons[] = {
> + [0] = {
> + .desc = "hook_switch",
> + .type = EV_SW,/* or EV_KEY ? */
> + .code = SW_HEADPHONE_INSERT, /* or a new one ? */
> + .active_low = 1,
> + .gpio = AMS_DELTA_GPIO_PIN_HOOK_SWITCH,
> + .debounce_interval = 10,
> + },
> +};
> +
> +static struct gpio_keys_platform_data ams_delta_gpio_keys = {
> + .buttons= ams_delta_gpio_keys_buttons,
> + .nbuttons = ARRAY_SIZE(ams_delta_gpio_keys_buttons),
> +};
> +
> +static struct platform_device ams_delta_gpio_keys_device = {
> + .name = "gpio-keys",
> + .id = -1,
> + .dev= {
> + .platform_data = &ams_delta_gpio_keys,
> + },
> +};
> +
> static struct platform_device *ams_delta_devices[] __initdata = {
> &ams_delta_kp_device,
> &ams_delta_lcd_device,
> &ams_delta_led_device,
> + &ams_delta_gpio_keys_device,
> };
>
> static void __init ams_delta_init(void)
> @@ -233,6 +259,13 @@ static void __init ams_delta_init_irq(vo
>
> omap_usb_init(&ams_delta_usb_config);
> platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
> +
> + omap_cfg_reg(P20_1610_GPIO4); /* is this required? */
> +
> + /* The hook switch state could be exposed over sysfs with gpio_export().
> + * This should be done after the gpio-keys driver calls gpio_request(),
> + * but I don't know how to do this from outside of the driver. */
> + /* gpio_export(AMS_DELTA_GPIO_PIN_HOOK_SWITCH, 0); */
> }
>
> static void __init ams_delta_map_io(void)
J.
--
Revd. Jonathan McDowell, ULC | I don't sleep, I dream.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix section mismatch warnings on some OMAP1 boards
On Tue, Nov 11, 2008 at 04:36:38PM -0800, Tony Lindgren wrote: > * Jonathan McDowell <[EMAIL PROTECTED]> [08 15:43]: > > I got some section mismatch warnings when compiling latest git for > > MACH_AMS_DELTA this evening; this seems to be due to a missing > > __initdata on the omap_board_config_kernel. Adding it fixes the > > warnings. I noticed that although this had been done for other OMAP1 > > boards fsample, innovator and voiceblue were all lacking it too, so I > > fixed them up at the same time. > > These cannot be __initdata as they are used by get_config() in > plat-omap/common.c, and omap_get_config() is called in some drivers > that could be modules. Hmmm. Well that isn't going to work at present anyway, because the 3 members of ams_delta_config are marked __initdata. > Let's rather just get rid of all the omap_board_config_kernel stuff > and use platform_data instead. Ok. I shall attempt to find time to test Felipe's USB tag removal patch. J. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix omap-gpio warnings when compiling for ARCH_OMAP15XX
When compiling for ARCH_OMAP15XX I get the following compiler warning in
gpio.c:
arch/arm/plat-omap/gpio.c: In function ‘_set_gpio_wakeup’:
arch/arm/plat-omap/gpio.c:848: warning: unused variable ‘flags’
Simple patch below fixes this.
Signed-off-by: Jonathan McDowell <[EMAIL PROTECTED]>
-
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 8bb4542..bfbe366 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -845,7 +845,10 @@ static inline void _set_gpio_irqenable(struct gpio_bank
*bank, int gpio, int ena
*/
static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
{
+#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP24XX) || \
+ defined(CONFIG_ARCH_OMAP34XX)
unsigned long flags;
+#endif
switch (bank->method) {
#ifdef CONFIG_ARCH_OMAP16XX
-
J.
--
Web [ Asking whether machines can think is like asking whether ]
site: http:// [ submarines can swim. ] Made by
www.earth.li/~noodles/ [ ] HuggieTag 0.0.23
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix section mismatch warnings on some OMAP1 boards
I got some section mismatch warnings when compiling latest git for
MACH_AMS_DELTA this evening; this seems to be due to a missing
__initdata on the omap_board_config_kernel. Adding it fixes the
warnings. I noticed that although this had been done for other OMAP1
boards fsample, innovator and voiceblue were all lacking it too, so I
fixed them up at the same time.
Signed-off-by: Jonathan McDowell <[EMAIL PROTECTED]>
-
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 2e61839..682cb91 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -172,7 +172,7 @@ static struct omap_usb_config ams_delta_usb_config
__initdata = {
.pins[0]= 2,
};
-static struct omap_board_config_kernel ams_delta_config[] = {
+static struct omap_board_config_kernel ams_delta_config[] __initdata = {
{ OMAP_TAG_LCD, &ams_delta_lcd_config },
{ OMAP_TAG_UART,&ams_delta_uart_config },
{ OMAP_TAG_USB, &ams_delta_usb_config },
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index db78946..38f4f18 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -216,7 +216,7 @@ static struct omap_lcd_config fsample_lcd_config __initdata
= {
.ctrl_name = "internal",
};
-static struct omap_board_config_kernel fsample_config[] = {
+static struct omap_board_config_kernel fsample_config[] __initdata = {
{ OMAP_TAG_UART,&fsample_uart_config },
{ OMAP_TAG_LCD, &fsample_lcd_config },
};
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index 7a97f6b..b86eb95 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -408,7 +408,7 @@ static struct omap_uart_config innovator_uart_config
__initdata = {
.enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
};
-static struct omap_board_config_kernel innovator_config[] = {
+static struct omap_board_config_kernel innovator_config[] __initdata = {
{ OMAP_TAG_USB, NULL },
{ OMAP_TAG_LCD, NULL },
{ OMAP_TAG_UART,&innovator_uart_config },
diff --git a/arch/arm/mach-omap1/board-voiceblue.c
b/arch/arm/mach-omap1/board-voiceblue.c
index 3ab5bbf..93de7e0 100644
--- a/arch/arm/mach-omap1/board-voiceblue.c
+++ b/arch/arm/mach-omap1/board-voiceblue.c
@@ -145,7 +145,7 @@ static struct omap_uart_config voiceblue_uart_config
__initdata = {
.enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
};
-static struct omap_board_config_kernel voiceblue_config[] = {
+static struct omap_board_config_kernel voiceblue_config[] __initdata = {
{ OMAP_TAG_USB, &voiceblue_usb_config },
{ OMAP_TAG_UART, &voiceblue_uart_config },
};
-
J.
--
jid: [EMAIL PROTECTED]
Are you out of my mind?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
