Re: Linux 4.2.0-rc5: am335x: musb warnings
On Mon, Aug 31, 2015 at 03:11:58PM +0200, Yegor Yefremov wrote: > Hi Felipe, > > On Fri, Aug 7, 2015 at 12:57 PM, Yegor Yefremov > wrote: > > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov > > wrote: > >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi wrote: > >>> HI, > >>> > >>> On Thu, Aug 06, 2015 at 09:40:26AM +0200, Yegor Yefremov wrote: > I performed a stress test with several FT4232H chips connected to a > >>> > >>> how many ? > >> > >> # lsusb -t > >> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M > >> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M > >> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M > >> |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 480M > >> |__ Port 1: Dev 3, If 1, Class=, Driver=ftdi_sio, 480M > >> |__ Port 1: Dev 3, If 2, Class=, Driver=ftdi_sio, 480M > >> |__ Port 1: Dev 3, If 3, Class=, Driver=ftdi_sio, 480M > >> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M > >> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M > >> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M > >> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M > >> |__ Port 3: Dev 5, If 0, Class=, Driver=ftdi_sio, 480M > >> |__ Port 3: Dev 5, If 1, Class=, Driver=ftdi_sio, 480M > >> |__ Port 3: Dev 5, If 2, Class=, Driver=ftdi_sio, 480M > >> |__ Port 3: Dev 5, If 3, Class=, Driver=ftdi_sio, 480M > >> > >> 3 chips a 4-ports are attached. > > > > Warnings appear on another device (without internal hub) with only one > > FT4232H too: > > > > # lsusb -t > > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M > > |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M > > |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M > > |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M > > |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M > > > hub, that is attached to one of the musb ports. So far the test was > successful for several hours. But I've seen following warnings: > > musb_host_rx 1973: Rx interrupt with no errors or packet! > musb_ep_program 931: broken !rx_reinit, ep5 csr 0203 > musb_host_rx 1973: Rx interrupt with no errors or packet! > musb_host_rx 1973: Rx interrupt with no errors or packet! > musb_host_rx 1973: Rx interrupt with no errors or packet! > musb_host_rx 1973: Rx interrupt with no errors or packet! > musb_ep_program 931: broken !rx_reinit, ep5 csr 0003 > musb_host_rx 1973: Rx interrupt with no errors or packet! > musb_ep_program 931: broken !rx_reinit, ep7 csr 0003 > > Is this expected behavior? > >>> > >>> no, that shouldn't happen, but it does and, apparently, in more than one > >>> implementation. Wondering if you're running into endpoint limitation due > >>> to MUSB's poor transfer scheduling for non-bulk endpoints. To add more: kernel 4.2.0 on AM3703 musb in DMA mode with Quectel U15 modem plugged: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, Driver=option, 480M |__ Port 4: Dev 3, If 1, Class=Vendor Specific Class, Driver=option, 480M |__ Port 4: Dev 3, If 2, Class=Vendor Specific Class, Driver=option, 480M |__ Port 4: Dev 3, If 3, Class=Vendor Specific Class, Driver=option, 480M |__ Port 4: Dev 3, If 4, Class=Vendor Specific Class, Driver=option, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M musb_ep_program 931: broken !rx_reinit, ep2 csr a203 musb_host_rx 1973: Rx interrupt with no errors or packet! musb_ep_program 931: broken !rx_reinit, ep5 csr a203 musb_host_rx 1973: Rx interrupt with no errors or packet! and in both PIO and DMA mode write to device ends this way: [ cut here ] WARNING: CPU: 0 PID: 146 at drivers/usb/musb/musb_host.c:128 musb_h_tx_flush_fifo+0x84/0xb8() Could not flush host TX2 fifo: csr: 2003 Modules linked in: option usb_wwan usbserial snd_soc_omap_twl4030 cpufreq_dt snd_soc_omap_mcbsp snd_soc_omap snd_soc_twl4030 snd_pcm_dmaengine omap_aes snd_soc_core omap_sham omap_mailbox s CPU: 0 PID: 146 Comm: ModemManager Not tainted 4.2.0 #3 Hardware name: Generic OMAP36xx (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (warn_slowpath_common+0x84/0xac) [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x2c/0x3c) [] (warn_slowpath_fmt) from [] (musb_h_tx_flush_fifo+0x84/0xb8) [] (musb_h_tx_flush_fifo) from [] (musb_cleanup_urb.isra.13+0xa0/0x12c) [] (musb_cleanup_urb.isra.13) from [] (musb_urb_dequeue+0xf4/0x114) [] (musb_urb_dequeue) from [] (usb_hcd_unlink_urb+0x60/0x7c) [] (usb_hcd_unlink_urb) from [] (usb_kill_urb+0x4c/0xc4) [] (usb_kill_urb) from [] (usb_wwan_close+0x94/0xb0
Re: AM37x unable to drive output of some gpio lines (works with 2.6.37)
On Tue, Oct 13, 2015 at 09:26:24PM +0300, Grygorii Strashko wrote:
> I think You might need to check pin muxing in DT-file. if you have smth like
>
> dss_dpi_pins_cm_t35x: pinmux_dss_dpi_pins_cm_t35x {
> pinctrl-single,pins = <
> OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0)
> /* dss_data0.dss_data0 */
> OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0)
> /* dss_data1.dss_data1 */
>
> ^ it will not work as gpio.
>
> OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0)
> /* dss_data2.dss_data2 */
> OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0)
> /* dss_data3.dss_data3 */
> OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0)
> /* dss_data4.dss_data4 */
> OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0)
> /* dss_data5.dss_data5 */
> >;
> };
It is not there as proven in very first mail reading mux register value
CONTROL_PADCONF_DSS_DATA0 0x480020DC: 0x1040104
Turned out to be hardware problem, scheme I have does not match PCB -
device controled by GPIO 71 is actually powered by VSDI_CSI (vpll2),
but on scheme there is line directly from power supply. And as 2.6.37
does not disable regulator it worked there. Shame on me and sorry for the
noise.
Regards,
ladis
--
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: AM37x unable to drive output of some gpio lines (works with 2.6.37)
On Fri, Oct 09, 2015 at 11:45:17AM +0200, Rolf Peukert wrote: > On 09.10.2015 02:54, Ladislav Michl wrote: > > Hi there! > > > > on custom AM37x board running 2.6.37 this was enough to enable gpio 67: > > echo 71 > /sys/class/gpio/export > > echo out > /sys/class/gpio/gpio71/direction > > echo 1 > /sys/class/gpio/gpio71/value > > > > However, with DT configured linux-4.2 compiled using omap2plus_defconfig > > this no longer works. > [...] > > Is some other device driver using these pins? Pins 70 and 71 could be > DSS or UART1. Maybe you need to set them to "disabled" in your DT. Only UART2 is enabled. This should not make difference anyway, as it should be matter of mux config and gpio settings. Working GPIO 82 is on the same bank as GPIO 71 and to make it work from U-Boot only these registers need to be touched: => mw.l 0x480020DC 0x40004 => mw.l 0x480020F4 0x40004 => mw.l 0x49052034 0xFFF41F3F => mw.l 0x4905203C First two writes are mux config, 3rd is direction and the last one is output. Both GPIO 71 and 82 could be driven this way. But as long as kernel steps in, GPIO 71 no longer works even if I use devmem utility to write relevant registers. Just tried 3.19.8 and it does not work either, moving backward to the past... Regards, ladis -- 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
AM37x unable to drive output of some gpio lines (works with 2.6.37)
Hi there! on custom AM37x board running 2.6.37 this was enough to enable gpio 67: echo 71 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio71/direction echo 1 > /sys/class/gpio/gpio71/value However, with DT configured linux-4.2 compiled using omap2plus_defconfig this no longer works. Using devmme2 utility, these are register values read from system running 2.6.37 kernel. CONTROL_SYSCONFIG 0x48002010: 0x1 CONTROL_PADCONF_DSS_DATA0 0x480020DC: 0x1040104 CONTROL_PADCONF_OFF 0x48002270: 0x0 CONTROL_DEVCONF0 0x48002274: 0x500 GPIO_SYSCONFIG0x49052010: 0x15 GPIO_CTRL 0x49052030: 0x0 GPIO_OE 0x49052034: 0xFF17 GPIO_DATAOUT 0x4905203C: 0x80 Relevant bits are the same on 4.2 kernel. Also, zeroing OE and writing to GPIO_DATAOUT it is possible to enable gpio81 and 80, 83, 69 (light LED), but not gpio71 or 70 or 69 (muxing done with DT) For testing purposes function drivers/gpio/gpio-omap.c:omap_gpio_restore_context was set to no-op. Any pointers where to look next? Thank you, ladis -- 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
[PATCH] Remove board support for VoiceBlue board.
Remove board support files for 10 years discontinued VoiceBlue board.
Signed-off-by: Ladislav Michl
---
arch/arm/mach-omap1/Kconfig| 7 -
arch/arm/mach-omap1/Makefile | 1 -
arch/arm/mach-omap1/board-voiceblue.c | 296 -
arch/arm/mach-omap1/include/mach/board-voiceblue.h | 19 --
4 files changed, 323 deletions(-)
delete mode 100644 arch/arm/mach-omap1/board-voiceblue.c
delete mode 100644 arch/arm/mach-omap1/include/mach/board-voiceblue.h
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index cdd05f2..afb80950 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -90,13 +90,6 @@ config MACH_OMAP_FSAMPLE
Support for TI OMAP 850 F-Sample board. Say Y here if you have such
a board.
-config MACH_VOICEBLUE
- bool "Voiceblue"
- depends on ARCH_OMAP1 && ARCH_OMAP15XX
- help
- Support for Voiceblue GSM/VoIP gateway. Say Y here if you have
- such a board.
-
config MACH_OMAP_PALMTE
bool "Palm Tungsten E"
depends on ARCH_OMAP1 && ARCH_OMAP15XX
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 3889b6c..0e8ea95 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -37,7 +37,6 @@ obj-$(CONFIG_MACH_OMAP_FSAMPLE) +=
board-fsample.o board-nand.o
obj-$(CONFIG_MACH_OMAP_OSK)+= board-osk.o
obj-$(CONFIG_MACH_OMAP_H3) += board-h3.o board-h3-mmc.o \
board-nand.o
-obj-$(CONFIG_MACH_VOICEBLUE) += board-voiceblue.o
obj-$(CONFIG_MACH_OMAP_PALMTE) += board-palmte.o
obj-$(CONFIG_MACH_OMAP_PALMZ71)+= board-palmz71.o
obj-$(CONFIG_MACH_OMAP_PALMTT) += board-palmtt.o
diff --git a/arch/arm/mach-omap1/board-voiceblue.c
b/arch/arm/mach-omap1/board-voiceblue.c
deleted file mode 100644
index e960687..000
--- a/arch/arm/mach-omap1/board-voiceblue.c
+++ /dev/null
@@ -1,296 +0,0 @@
-/*
- * linux/arch/arm/mach-omap1/board-voiceblue.c
- *
- * Modified from board-generic.c
- *
- * Copyright (C) 2004 2N Telekomunikace, Ladislav Michl
- *
- * Code for OMAP5910 based VoiceBlue board (VoIP to GSM gateway).
- *
- * 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
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-
-#include
-#include
-
-#include "common.h"
-
-static struct plat_serial8250_port voiceblue_ports[] = {
- {
- .mapbase= (unsigned long)(OMAP_CS1_PHYS + 0x4),
- .flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
- .iotype = UPIO_MEM,
- .regshift = 1,
- .uartclk= 3686400,
- },
- {
- .mapbase= (unsigned long)(OMAP_CS1_PHYS + 0x5),
- .flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
- .iotype = UPIO_MEM,
- .regshift = 1,
- .uartclk= 3686400,
- },
- {
- .mapbase= (unsigned long)(OMAP_CS1_PHYS + 0x6),
- .flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
- .iotype = UPIO_MEM,
- .regshift = 1,
- .uartclk= 3686400,
- },
- {
- .mapbase= (unsigned long)(OMAP_CS1_PHYS + 0x7),
- .flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
- .iotype = UPIO_MEM,
- .regshift = 1,
- .uartclk= 3686400,
- },
- { },
-};
-
-static struct platform_device serial_device = {
- .name = "serial8250",
- .id = PLAT8250_DEV_PLATFORM1,
-};
-
-static int __init ext_uart_init(void)
-{
- if (!machine_is_voiceblue())
- return -ENODEV;
-
- voiceblue_ports[0].irq = gpio_to_irq(12);
- voiceblue_ports[1].irq = gpio_to_irq(13);
- voiceblue_ports[2].irq = gpio_to_irq(14);
- voiceblue_ports[3].irq = gpio_to_irq(15);
- serial_device.dev.platform_data = voiceblue_ports;
- return platform_device_register(&serial_device);
-}
-arch_initcall(ext_uart_init);
-
-static struct physmap_flash_data voiceblue_flash_data = {
- .width = 2,
- .set_vpp= omap1_set_vpp,
-};
-
-static struct resource voiceblue_flash_resource = {
- .start = OMAP_CS0_PHYS,
- .end= OMAP_CS0_PHYS + SZ_32M - 1,
- .f
Re: [PATCH] ARM: OMAP AM35x: clockdomain data: fix resolving dependency problem
On Mon, Jul 02, 2012 at 10:41:38AM -0700, Mark A. Greer wrote:
> On Mon, Jul 02, 2012 at 05:54:57AM +, Kim, Milo wrote:
> > In am35x board , iva2 clock domain doesn't be used.
> > So mpu_am35x_clkdm should be used rather than mpu_3xxx_clkdm.
> > OMAP3430 : mpu_3xxx_clkdm (with iva2 clkdm)
> > AM35x: mpu_am35x_clkdm (without iva2 clkdm)
> >
> > For the compatibility with omap3430, this patch has no conflict because
> > mpu_3xxx_clkdm was already defined in clock domains for omap3430.
> > So this can be removed from common clock domain.
> >
> > Below error can be fixed with this patch.
> >
> > [0.00] AM3517 ES1.1 (l2cache sgx neon )
> > [0.00] [ cut here ]
> > [0.00] WARNING: at arch/arm/mach-omap2/clockdomain.c:237
> > _resolve_clkdm_deps+0x68/0x108()
> > [0.00] clockdomain: mpu_clkdm: could not find clkdm iva2_clkdm
> > while resolving dependencies - should never happen
> > [0.00] Modules linked in:
> > [0.00] [] (unwind_backtrace+0x0/0xf4) from []
> > (warn_slowpath_common+0x4c/0x64)
> > [0.00] [] (warn_slowpath_common+0x4c/0x64) from
> > [] (warn_slowpath_fmt+0x30/0x40)
> > [0.00] [] (warn_slowpath_fmt+0x30/0x40) from []
> > (_resolve_clkdm_deps+0x68/0x108)
> > [0.00] [] (_resolve_clkdm_deps+0x68/0x108) from
> > [] (clkdm_complete_init+0x34/0x90)
> > [0.00] [] (clkdm_complete_init+0x34/0x90) from
> > [] (omap3_init_early+0x20/0x30)
> > [0.00] [] (omap3_init_early+0x20/0x30) from []
> > (setup_arch+0x834/0x94c)
> > [0.00] [] (setup_arch+0x834/0x94c) from []
> > (start_kernel+0x88/0x2fc)
> > [0.00] [] (start_kernel+0x88/0x2fc) from [<80008044>]
> > (0x80008044)
> >
> > Signed-off-by: Milo(Woogyom) Kim
> > ---
> > arch/arm/mach-omap2/clockdomains3xxx_data.c |1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
> > b/arch/arm/mach-omap2/clockdomains3xxx_data.c
> > index d625844..56089c4 100644
> > --- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
> > +++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
> > @@ -454,7 +454,6 @@ static struct clkdm_autodep clkdm_am35x_autodeps[] = {
> >
> > static struct clockdomain *clockdomains_common[] __initdata = {
> > &wkup_common_clkdm,
> > - &mpu_3xxx_clkdm,
> > &neon_clkdm,
> > &core_l3_3xxx_clkdm,
> > &core_l4_3xxx_clkdm,
> > --
> > 1.7.2.5
>
> Hi Milo.
>
> Thanks for the patch but this issue should already be fixed in a patch
> that Tony just made a pull request for
> (http://www.spinics.net/lists/linux-omap/msg73080.html).
>
> >From that email (and branch in the email), look for this patch:
>
> > Mark A. Greer (4):
>
> > ARM: OMAP AM35x: clockdomain data: Fix clockdomain dependencies
>
> Please take a look as another set of eyes never hurts. :)
Hi Mark,
just tested above patch on Technexion's TAM-3517 and it indeed fixes above
warning. Without patch, warning is generated. Tested on Tony's master branch.
ladis
--
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: latest kernel for am35xx
On Mon, Jun 04, 2012 at 09:28:23AM +0200, Ladislav Michl wrote: > does USB work for you? I forward ported support for TechNexion's TAM-3517 on > Twister board to current master, but so far no luck with mass storage > support (patch for reference http://ladislav.michl.sweb.cz/tam3517.patch). patch updated, so now does not contain random clock changes, so output changes: omap_hwmod: am35x_otg_hs: cannot be enabled for reset (3) ... usbhs_omap: alias fck already exists ... Switching to clocksource 32k_counter usbhs_omap usbhs_omap: xclk60mhsp1_ck set parentfailed error:-22 ... musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) musb-hdrc musb-hdrc: musb_init_controller failed with status -19 It would be nice to update master branch :-) ladis -- 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: latest kernel for am35xx
On Thu, May 31, 2012 at 11:02:06AM +0200, Yegor Yefremov wrote: > my best choice was 3.3-rc7 so far. With final 3.3 frame buffer made problems. > wl1271 was working like a charm. I have another PMIC, so I don't know if it > works well with tps65910. > > I just took the master branch of linux-omap.git Yegor, does USB work for you? I forward ported support for TechNexion's TAM-3517 on Twister board to current master, but so far no luck with mass storage support (patch for reference http://ladislav.michl.sweb.cz/tam3517.patch). It does not detect any plugged in devices. USB related errors: GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 [ cut here ] WARNING: at arch/arm/mach-omap2/pm.c:48 _init_omap_device+0x74/0x94() _init_omap_device: could not find omap_hwmod for iva Modules linked in: [] (unwind_backtrace+0x0/0xec) from [] (warn_slowpath_common+0x4c/0x64) [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_fmt+0x30/0x40) [] (warn_slowpath_fmt+0x30/0x40) from [] (_init_omap_device+0x74/0x94) [] (_init_omap_device+0x74/0x94) from [] (omap2_common_pm_init+0x38/0x64) [] (omap2_common_pm_init+0x38/0x64) from [] (do_one_initcall+0x94/0x15c) [] (do_one_initcall+0x94/0x15c) from [] (kernel_init+0xd4/0x1ac) [] (kernel_init+0xd4/0x1ac) from [] (kernel_thread_exit+0x0/0x8) ---[ end trace 1b75b31a2719ed1c ]--- [...] [ cut here ] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:161 omap3_l3_app_irq+0x210/0x2a0() In-band Error seen by USB_OTG at address 0 Modules linked in: [] (unwind_backtrace+0x0/0xec) from [] (warn_slowpath_common+0x4c/0x64) [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_fmt+0x30/0x40) [] (warn_slowpath_fmt+0x30/0x40) from [] (omap3_l3_app_irq+0x210/0x2a0) [] (omap3_l3_app_irq+0x210/0x2a0) from [] (handle_irq_event_percpu+0x34/0x194) [] (handle_irq_event_percpu+0x34/0x194) from [] (handle_irq_event+0x28/0x38) [] (handle_irq_event+0x28/0x38) from [] (handle_level_irq+0xb8/0xe8) [] (handle_level_irq+0xb8/0xe8) from [] (generic_handle_irq+0x2c/0x44) [] (generic_handle_irq+0x2c/0x44) from [] (handle_IRQ+0x64/0x8c) [] (handle_IRQ+0x64/0x8c) from [] (omap3_intc_handle_irq+0x58/0x70) [] (omap3_intc_handle_irq+0x58/0x70) from [] (__irq_svc+0x40/0x60) Exception stack(0xcf02be40 to 0xcf02be88) be40: 000a 0021 c043d044 000a cf04b740 be60: 6013 c043d074 c045fd80 cf006080 cf02be88 c0061834 c005fff8 be80: 6013 [] (__irq_svc+0x40/0x60) from [] (__setup_irq+0x2a4/0x358) [] (__setup_irq+0x2a4/0x358) from [] (request_threaded_irq+0xc0/0x114) [] (request_threaded_irq+0xc0/0x114) from [] (omap3_l3_probe+0x108/0x164) [] (omap3_l3_probe+0x108/0x164) from [] (platform_drv_probe+0x1c/0x24) [] (platform_drv_probe+0x1c/0x24) from [] (driver_probe_device+0xcc/0x21c) [] (driver_probe_device+0xcc/0x21c) from [] (__driver_attach+0x60/0x84) [] (__driver_attach+0x60/0x84) from [] (bus_for_each_dev+0x4c/0x8c) [] (bus_for_each_dev+0x4c/0x8c) from [] (bus_add_driver+0xa0/0x21c) [] (bus_add_driver+0xa0/0x21c) from [] (driver_register+0xa0/0x12c) [] (driver_register+0xa0/0x12c) from [] (platform_driver_probe+0x1c/0x70) [] (platform_driver_probe+0x1c/0x70) from [] (do_one_initcall+0x94/0x15c) [] (do_one_initcall+0x94/0x15c) from [] (kernel_init+0xd4/0x1ac) [] (kernel_init+0xd4/0x1ac) from [] (kernel_thread_exit+0x0/0x8) ---[ end trace 1b75b31a2719ed1d ]--- omap_mux_init: Add partition: #1: core, flags: 0 usbhs_omap: alias fck already exists [...] hci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-omap.0 supply hsusb0 not found, using dummy regulator ehci-omap ehci-omap.0: OMAP-EHCI Host Controller ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: OMAP-EHCI Host Controller usb usb1: Manufacturer: Linux 3.4.0-rc6+ ehci_hcd usb usb1: SerialNumber: ehci-omap.0 hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected usbcore: registered new interface driver cdc_wdm Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. [...] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) musb-am35x musb-am35x: failed to get clock musb-am35x: probe of musb-am35x failed with error -2 Any ideas? Not following OMAP development for a long time was probably a bad idea. Thanks, ladis -- 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/4] [OMAP1] Add MMC board code common to HTC devices
On Fri, May 28, 2010 at 10:28:04PM -0700, Cory Maccarrone wrote:
> This change adds the htc-mmc.c and htc-mmc.h files that
> contain common setup code for many OMAP850-based HTC
> smartphones. This code is a port of the code used by
> the linwizard project to support devices such as the
> HTC Wizard, HTC Herald, HTC Opal, etc.
>
> Signed-off-by: Cory Maccarrone
> ---
> arch/arm/mach-omap1/htc-mmc.c | 104
> +
> arch/arm/mach-omap1/htc-mmc.h | 26 ++
> 2 files changed, 130 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap1/htc-mmc.c
> create mode 100644 arch/arm/mach-omap1/htc-mmc.h
>
> diff --git a/arch/arm/mach-omap1/htc-mmc.c b/arch/arm/mach-omap1/htc-mmc.c
> new file mode 100644
> index 000..4fa8bb4
> --- /dev/null
> +++ b/arch/arm/mach-omap1/htc-mmc.c
> @@ -0,0 +1,104 @@
> +/*
> + * linux/arch/arm/mach-omap1/htc-mmc.c
> + *
> + * Copyright (C) 2007 Instituto Nokia de Tecnologia - INdT
> + * Author: Felipe Balbi
> + *
> + * This code is based on linux/arch/arm/mach-omap2/board-n800-mmc.c, which
> is:
> + * Copyright (C) 2006 Nokia Corporation
> + *
> + * 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
> +
> +#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
> +
> +#define OMAP_MMC_REG_SYSC (0xfffb7800 + 0x32)
> +#define OMAP_MMC_REG_SYSS (0xfffb7800 + 0x34)
Where are these used?
> +static int slot_cover_open;
> +static struct device *mmc_device;
> +
> +static int htc_mmc_set_power(struct device *dev, int slot, int power_on,
> + int vdd)
> +{
> +#ifdef CONFIG_MMC_DEBUG
> + dev_dbg(dev, "Set slot %d power: %s (vdd %d)\n", slot + 1,
> + power_on ? "on" : "off", vdd);
> +#endif
> + if (slot != 0) {
> + dev_err(dev, "No such slot %d\n", slot + 1);
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
No-op?
> +static int htc_mmc_set_bus_mode(struct device *dev, int slot, int bus_mode)
> +{
> +#ifdef CONFIG_MMC_DEBUG
> + dev_dbg(dev, "Set slot %d bus_mode %s\n", slot + 1,
> + bus_mode == MMC_BUSMODE_OPENDRAIN ? "open-drain" : "push-pull");
> +#endif
> + if (slot != 0) {
> + dev_err(dev, "No such slot %d\n", slot + 1);
> + return -ENODEV;
> + }
> +
> + /* Treated on upper level */
> +
> + return bus_mode;
> +}
> +
> +static int htc_mmc_get_cover_state(struct device *dev, int slot)
> +{
> + BUG_ON(slot != 0);
> + return slot_cover_open;
> +}
Just a complicated way to return zero...
> +static int htc_mmc_late_init(struct device *dev)
> +{
> + mmc_device = dev;
> + return 0;
> +}
What is this good for?
> +static void htc_mmc_cleanup(struct device *dev)
> +{
> +}
> +
> +static struct omap_mmc_platform_data htc_mmc1_data = {
> + .nr_slots = 1,
> + .switch_slot= NULL,
> + .init = htc_mmc_late_init,
> + .cleanup= htc_mmc_cleanup,
> + .slots[0] = {
> + .set_power = htc_mmc_set_power,
> + .set_bus_mode = htc_mmc_set_bus_mode,
> + .get_ro = NULL,
> + .get_cover_state= htc_mmc_get_cover_state,
> + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
> + MMC_VDD_32_33 | MMC_VDD_33_34,
> + .name = "mmcblk",
> + .nomux = 1,
> + .wires = 4,
> + .switch_pin = -1,
> + },
> +};
To me above seems completely no-op, so it could be simplified this way:
static struct omap_mmc_platform_data htc_mmc1_data = {
.nr_slots = 1,
.switch_slot= NULL,
.slots[0] = {
.ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
MMC_VDD_32_33 | MMC_VDD_33_34,
.name = "mmcblk",
.nomux = 1,
.wires = 4,
.switch_pin = -1,
},
};
Now, once this file contains only one structure definition, is it worth
to let it exist at all? What about adding it to board-htcherald.c instead?
> +
> +static struct omap_mmc_platform_data *htc_mmc_data[1];
> +
> +void __init htc_mmc_init(void)
> +{
> + /* register it */
> + htc_mmc_data[0] = &htc_mmc1_data;
> + omap1_init_mmc(htc_mmc_data, 1);
> +}
> +#endif
> +
> diff --git a/arch/arm/mach-omap1/htc-mmc.h b/arch/arm/mach-omap1/htc-mmc.h
> new file mode 100644
> index 000..480de14
> --- /dev/null
> +++ b/arch/arm/ma
Re: [PATCH v3 2/3] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
On Mon, Feb 08, 2010 at 06:38:57PM +0530, Vimal Singh wrote:
> In this version: (as per comments recieved for 2nd version)
> - remove 'omap_set_vpp' function
> - set 'set_vpp' to null
Ah, I'm sorry for not being quite exact. "leave set_vpp set to NULL" means
there is no need to asign anything to that structure member, because BSS is
zeroed (set to NULL) anyway. Something like this:
static struct physmap_flash_data sdp_nor_data = {
.width = 2,
};
Yes, this is a nitpick only...
--
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 v2 2/3] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
> diff --git a/arch/arm/mach-omap2/board-sdp-flash.c
> b/arch/arm/mach-omap2/board-sdp-flash.c
> new file mode 100644
> index 000..54ef19f
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-sdp-flash.c
[snip]
> +static void omap_set_vpp(struct map_info *map, int enable)
> +{
> + static int count;
> + u32 l;
> +
> + if (cpu_class_is_omap1()) {
> + if (enable) {
> + if (count++ == 0) {
> + l = omap_readl(EMIFS_CONFIG);
> + l |= OMAP_EMIFS_CONFIG_WP;
> + omap_writel(l, EMIFS_CONFIG);
> + }
> + } else {
> + if (count && (--count == 0)) {
> + l = omap_readl(EMIFS_CONFIG);
> + l &= ~OMAP_EMIFS_CONFIG_WP;
> + omap_writel(l, EMIFS_CONFIG);
> + }
> + }
> + }
> +}
Hmm, as you are adding files into arch/arm/mach-omap2 directory, is there
a chance cpu_class_is_omap1() ever returns non-zero?
> +static struct physmap_flash_data sdp_nor_data = {
> + .width = 2,
> + .set_vpp= omap_set_vpp,
> +};
... and in case there is not, just leave set_vpp set to NULL and delete this
incarnation of omap_set_vpp.
--
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 v5 resubmit] mmc-omap: Add support for 16-bit and 32-bit registers
On Sat, Jan 09, 2010 at 09:52:16AM -0800, Cory Maccarrone wrote:
> From: Marek Belisko
>
> The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring
> a modification of the register addresses in the mmc-omap driver. To resolve
> this, a bit shift is performed on base register addresses, either by 1 or 2
> bits depending on the CPU in use. This yields the correct registers for
> each CPU.
>
> Signed-off-by: Marek Belisko
> Signed-off-by: Cory Maccarrone
> ---
> drivers/mmc/host/omap.c | 63 +-
> 1 files changed, 34 insertions(+), 29 deletions(-)
>
> I am submitting this patch again, as it has been a long time since any
> activity was on it, and I fear it may have been lost in the mailing list
> history. This change is required for mmc card functionality to work on
> omap7xx devices.
This patch differs from v5 you sent earlier:
Subject: [PATCH v5] mmc-omap: Add support for 16-bit and 32-bit registers
Date: Mon, 23 Nov 2009 10:37:28 -0800
Message-Id: <1259001448-9574-1-git-send-email-darkstar6...@gmail.com>
Patch below is not going to work with 32-bit wide registers. Whoever is going
to apply it, please don't. Use original version referred above.
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index c6d7e8e..c7ed01f 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -38,30 +38,30 @@
> #include
>
> #define OMAP_MMC_REG_CMD0x00
> -#define OMAP_MMC_REG_ARGL 0x04
> -#define OMAP_MMC_REG_ARGH 0x08
> -#define OMAP_MMC_REG_CON0x0c
> -#define OMAP_MMC_REG_STAT 0x10
> -#define OMAP_MMC_REG_IE 0x14
> -#define OMAP_MMC_REG_CTO0x18
> -#define OMAP_MMC_REG_DTO0x1c
> -#define OMAP_MMC_REG_DATA 0x20
> -#define OMAP_MMC_REG_BLEN 0x24
> -#define OMAP_MMC_REG_NBLK 0x28
> -#define OMAP_MMC_REG_BUF0x2c
> -#define OMAP_MMC_REG_SDIO0x34
> -#define OMAP_MMC_REG_REV0x3c
> -#define OMAP_MMC_REG_RSP0 0x40
> -#define OMAP_MMC_REG_RSP1 0x44
> -#define OMAP_MMC_REG_RSP2 0x48
> -#define OMAP_MMC_REG_RSP3 0x4c
> -#define OMAP_MMC_REG_RSP4 0x50
> -#define OMAP_MMC_REG_RSP5 0x54
> -#define OMAP_MMC_REG_RSP6 0x58
> -#define OMAP_MMC_REG_RSP7 0x5c
> -#define OMAP_MMC_REG_IOSR 0x60
> -#define OMAP_MMC_REG_SYSC 0x64
> -#define OMAP_MMC_REG_SYSS 0x68
> +#define OMAP_MMC_REG_ARGL 0x01
> +#define OMAP_MMC_REG_ARGH 0x02
> +#define OMAP_MMC_REG_CON0x03
> +#define OMAP_MMC_REG_STAT 0x04
> +#define OMAP_MMC_REG_IE 0x05
> +#define OMAP_MMC_REG_CTO0x06
> +#define OMAP_MMC_REG_DTO0x07
> +#define OMAP_MMC_REG_DATA 0x08
> +#define OMAP_MMC_REG_BLEN 0x09
> +#define OMAP_MMC_REG_NBLK 0x0a
> +#define OMAP_MMC_REG_BUF0x0b
> +#define OMAP_MMC_REG_SDIO 0x0d
> +#define OMAP_MMC_REG_REV0x0f
> +#define OMAP_MMC_REG_RSP0 0x10
> +#define OMAP_MMC_REG_RSP1 0x11
> +#define OMAP_MMC_REG_RSP2 0x12
> +#define OMAP_MMC_REG_RSP3 0x13
> +#define OMAP_MMC_REG_RSP4 0x14
> +#define OMAP_MMC_REG_RSP5 0x15
> +#define OMAP_MMC_REG_RSP6 0x16
> +#define OMAP_MMC_REG_RSP7 0x17
> +#define OMAP_MMC_REG_IOSR 0x18
> +#define OMAP_MMC_REG_SYSC 0x19
> +#define OMAP_MMC_REG_SYSS 0x1a
>
> #define OMAP_MMC_STAT_CARD_ERR (1 << 14)
> #define OMAP_MMC_STAT_CARD_IRQ (1 << 13)
> @@ -77,8 +77,9 @@
> #define OMAP_MMC_STAT_CARD_BUSY (1 << 2)
> #define OMAP_MMC_STAT_END_OF_CMD(1 << 0)
>
> -#define OMAP_MMC_READ(host, reg) __raw_readw((host)->virt_base +
> OMAP_MMC_REG_##reg)
> -#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val),
> (host)->virt_base + OMAP_MMC_REG_##reg)
> +#define OMAP_MMC_REG(host, reg) (OMAP_MMC_REG_##reg <<
> (host)->reg_shift)
> +#define OMAP_MMC_READ(host, reg) __raw_readw((host)->virt_base +
> OMAP_MMC_REG(host, reg))
> +#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val),
> (host)->virt_base + OMAP_MMC_REG(host, reg))
>
> /*
> * Command types
> @@ -167,6 +168,8 @@ struct mmc_omap_host {
> spinlock_t clk_lock; /* for changing enabled state */
> unsigned intfclk_enabled:1;
>
> + unsignedreg_shift:1;
> +
This is not going to work
> struct omap_mmc_platform_data *pdata;
> };
>
> @@ -679,9 +682,9 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
> host->data->bytes_xfered += n;
>
> if (write) {
> - __raw_writesw(host->virt_base + OMAP_MMC_REG_DATA,
> host->buffer,
Re: [rfc/rft/patch-v2.6.32-omap1+ 2/2] arm: omap: add missing __initdata to omap_board_config_kernel
On Wed, Dec 16, 2009 at 11:52:35PM +0200, Felipe Balbi wrote:
> we still need to get rid of the OMAP_TAG_LCD, but while
> it's still there, let's kill the section mismatches.
Hmm, couldn't we just simply remove all empty declarations first? As data
section
is zeroed it should not cause any harm. Anyway, patch bellow is entirely
untested
and posted for your convenience only :-)
Signed-off-by: Ladislav Michl
diff --git a/arch/arm/mach-omap1/board-generic.c
b/arch/arm/mach-omap1/board-generic.c
index e1195a3..bea32cf 100644
--- a/arch/arm/mach-omap1/board-generic.c
+++ b/arch/arm/mach-omap1/board-generic.c
@@ -57,9 +57,6 @@ static struct omap_usb_config generic1610_usb_config
__initdata = {
};
#endif
-static struct omap_board_config_kernel generic_config[] __initdata = {
-};
-
static void __init omap_generic_init(void)
{
#ifdef CONFIG_ARCH_OMAP15XX
@@ -80,9 +77,6 @@ static void __init omap_generic_init(void)
omap_usb_init(&generic1610_usb_config);
}
#endif
-
- omap_board_config = generic_config;
- omap_board_config_size = ARRAY_SIZE(generic_config);
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
}
diff --git a/arch/arm/mach-omap1/board-voiceblue.c
b/arch/arm/mach-omap1/board-voiceblue.c
index 1691835..5a95391 100644
--- a/arch/arm/mach-omap1/board-voiceblue.c
+++ b/arch/arm/mach-omap1/board-voiceblue.c
@@ -150,9 +150,6 @@ static struct omap_usb_config voiceblue_usb_config
__initdata = {
.pins[2]= 6,
};
-static struct omap_board_config_kernel voiceblue_config[] = {
-};
-
static void __init voiceblue_init_irq(void)
{
omap1_init_common_hw();
@@ -194,8 +191,6 @@ static void __init voiceblue_init(void)
set_irq_type(gpio_to_irq(15), IRQ_TYPE_EDGE_RISING);
platform_add_devices(voiceblue_devices, ARRAY_SIZE(voiceblue_devices));
- omap_board_config = voiceblue_config;
- omap_board_config_size = ARRAY_SIZE(voiceblue_config);
omap_serial_init();
omap_usb_init(&voiceblue_usb_config);
omap_register_i2c_bus(1, 100, NULL, 0);
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index c90b0d0..4bfd8e3 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -298,13 +298,8 @@ static struct platform_device *sdp3430_devices[]
__initdata = {
&sdp3430_dss_device,
};
-static struct omap_board_config_kernel sdp3430_config[] __initdata = {
-};
-
static void __init omap_3430sdp_init_irq(void)
{
- omap_board_config = sdp3430_config;
- omap_board_config_size = ARRAY_SIZE(sdp3430_config);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
omap_init_irq();
omap_gpio_init();
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 7390596..f460d4f 100755
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -72,13 +72,8 @@ static void __init omap_sdp_map_io(void)
omap2_map_common_io();
}
-static struct omap_board_config_kernel sdp_config[] __initdata = {
-};
-
static void __init omap_sdp_init_irq(void)
{
- omap_board_config = sdp_config;
- omap_board_config_size = ARRAY_SIZE(sdp_config);
omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
h8mbx00u0mer0em_sdrc_params);
omap_init_irq();
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index b4e6eca..c16cb3f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,17 +35,11 @@
/*
* Board initialization
*/
-static struct omap_board_config_kernel am3517_evm_config[] __initdata = {
-};
-
static struct platform_device *am3517_evm_devices[] __initdata = {
};
static void __init am3517_evm_init_irq(void)
{
- omap_board_config = am3517_evm_config;
- omap_board_config_size = ARRAY_SIZE(am3517_evm_config);
-
omap2_init_common_hw(NULL, NULL);
omap_init_irq();
omap_gpio_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 2626a9f..3ec2687 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -462,14 +462,8 @@ static void __init cm_t35_init_i2c(void)
ARRAY_SIZE(cm_t35_i2c_boardinfo));
}
-static struct omap_board_config_kernel cm_t35_config[] __initdata = {
-};
-
static void __init cm_t35_init_irq(void)
{
- omap_board_config = cm_t35_config;
- omap_board_config_size = ARRAY_SIZE(cm_t35_config);
-
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
omap_init_irq();
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 7e6e6ca..cad8b9c 100644
--- a/arch/arm/mach-omap2/board-generic.
[PATCH v2 1/2] OMAP: convert boards to use physmap-flash
Convert OMAP based boards to use physmap-flash. Refreshed against today's
Linux omap kernel tree
Signed-off-by: Ladislav Michl
--- /dev/null 2009-12-08 14:04:43.543715066 +0100
+++ linux-omap-2.6/arch/arm/plat-omap/include/plat/flash.h 2009-12-08
18:53:34.0 +0100
@@ -0,0 +1,16 @@
+/*
+ * Flash support for OMAP1
+ *
+ * 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.
+ */
+
+#ifndef __OMAP_FLASH_H
+#define __OMAP_FLASH_H
+
+#include
+
+extern void omap1_set_vpp(struct map_info *map, int enable);
+
+#endif
--- /dev/null 2009-12-08 14:04:43.543715066 +0100
+++ linux-omap-2.6/arch/arm/mach-omap1/flash.c 2009-12-08 18:45:16.0
+0100
@@ -0,0 +1,33 @@
+/*
+ * Flash support for OMAP1
+ *
+ * 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
+
+void omap1_set_vpp(struct map_info *map, int enable)
+{
+ static int count;
+ u32 l;
+
+ if (enable) {
+ if (count++ == 0) {
+ l = omap_readl(EMIFS_CONFIG);
+ l |= OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ } else {
+ if (count && (--count == 0)) {
+ l = omap_readl(EMIFS_CONFIG);
+ l &= ~OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ }
+}
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 9ce17f1..3378486 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := io.o id.o sram.o irq.o mux.o serial.o devices.o
+obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o
obj-y += clock.o clock_data.o opp_data.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 7e70c3c..096f2ed 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -18,18 +18,19 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -150,9 +151,9 @@ static struct mtd_partition nor_partitions[] = {
},
};
-static struct flash_platform_data nor_data = {
- .map_name = "cfi_probe",
+static struct physmap_flash_data nor_data = {
.width = 2,
+ .set_vpp= omap1_set_vpp,
.parts = nor_partitions,
.nr_parts = ARRAY_SIZE(nor_partitions),
};
@@ -164,7 +165,7 @@ static struct resource nor_resource = {
};
static struct platform_device nor_device = {
- .name = "omapflash",
+ .name = "physmap-flash",
.id = 0,
.dev= {
.platform_data = &nor_data,
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index fa7cece..d1100e4 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -35,7 +36,6 @@
#include
#include
-#include
#include
#include
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include "board-h2.h"
@@ -121,9 +122,9 @@ static struct mtd_partition h2_nor_partitions[] = {
}
};
-static struct flash_platform_data h2_nor_data = {
- .map_name = "cfi_probe",
+static struct physmap_flash_data h2_nor_data = {
.width = 2,
+ .set_vpp= omap1_set_vpp,
.parts = h2_nor_partitions,
.nr_parts = ARRAY_SIZE(h2_nor_partitions),
};
@@ -134,7 +135,7 @@ static struct resource h2_nor_resource = {
};
static struct platform_device h2_nor_device = {
- .name = "omapflash",
+ .name = "physmap-flash",
.id = 0,
.dev= {
.platform_data = &h2_nor_data,
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 6a7f9c3..a53ab82 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -37,7 +38,6 @@
#include
#include
-#include
#include
#include
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include "board-h3.h"
@@ -126,9 +127,9 @@ static struct mtd_partition nor_partitions[] = {
[PATCH 2/2] MTD: remove no longer used OMAP flash map
All OMAP boards are now using physmap-flash.
Signed-off-by: Ladislav Michl
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index 14be075..c165a27 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -436,15 +436,6 @@ config MTD_H720X
This enables access to the flash chips on the Hynix evaluation boards.
If you have such a board, say 'Y'.
-config MTD_OMAP_NOR
- tristate "TI OMAP board mappings"
- depends on MTD_CFI && ARCH_OMAP
- help
- This enables access to the NOR flash chips on TI OMAP-based
- boards defining flash platform devices and flash platform data.
- These boards include the Innovator, H2, H3, OSK, Perseus2, and
- more. If you have such a board, say 'Y'.
-
# This needs CFI or JEDEC, depending on the cards found.
config MTD_PCI
tristate "PCI MTD driver"
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index ae2f6db..ef11888 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -55,7 +55,6 @@ obj-$(CONFIG_MTD_IXP2000) += ixp2000.o
obj-$(CONFIG_MTD_WRSBC8260)+= wr_sbc82xx_flash.o
obj-$(CONFIG_MTD_DMV182) += dmv182.o
obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o
-obj-$(CONFIG_MTD_OMAP_NOR) += omap_nor.o
obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o
obj-$(CONFIG_MTD_BFIN_ASYNC) += bfin-async-flash.o
obj-$(CONFIG_MTD_RBTX4939) += rbtx4939-flash.o
--- a/drivers/mtd/maps/omap_nor.c 2009-10-20 13:04:52.0 +0200
+++ b/drivers/mtd/maps/omap_nor.c 2009-12-08 14:04:43.543715066 +0100
@@ -1,188 +0,0 @@
-/*
- * Flash memory support for various TI OMAP boards
- *
- * Copyright (C) 2001-2002 MontaVista Software Inc.
- * Copyright (C) 2003-2004 Texas Instruments
- * Copyright (C) 2004 Nokia Corporation
- *
- * Assembled using driver code copyright the companies above
- * and written by David Brownell, Jian Zhang ,
- * Tony Lindgren and others.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
- * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-
-#ifdef CONFIG_MTD_PARTITIONS
-static const char *part_probes[] = { /* "RedBoot", */ "cmdlinepart", NULL };
-#endif
-
-struct omapflash_info {
- struct mtd_partition*parts;
- struct mtd_info *mtd;
- struct map_info map;
-};
-
-static void omap_set_vpp(struct map_info *map, int enable)
-{
- static int count;
- u32 l;
-
- if (cpu_class_is_omap1()) {
- if (enable) {
- if (count++ == 0) {
- l = omap_readl(EMIFS_CONFIG);
- l |= OMAP_EMIFS_CONFIG_WP;
- omap_writel(l, EMIFS_CONFIG);
- }
- } else {
- if (count && (--count == 0)) {
- l = omap_readl(EMIFS_CONFIG);
- l &= ~OMAP_EMIFS_CONFIG_WP;
- omap_writel(l, EMIFS_CONFIG);
- }
- }
- }
-}
-
-static int __init omapflash_probe(struct platform_device *pdev)
-{
- int err;
- struct omapflash_info *info;
- struct flash_platform_data *pdata = pdev->dev.platform_data;
- struct resource *res = pdev->resource;
- unsigned long size = res->end - res->start + 1;
-
- info = kzalloc(sizeof(struct omapflash_info), GFP_KERNEL);
- if (!info)
- return -ENOMEM;
-
- if (!request_mem_region(res->start, size, "flash")) {
- err = -EBUSY;
-
[PATCH 1/2] OMAP: convert boards to use physmap-flash
Convert OMAP based boards to use physmap-flash.
Signed-off-by: Ladislav Michl
--- /dev/null 2009-12-08 14:04:43.543715066 +0100
+++ linux-omap-2.6/arch/arm/plat-omap/include/plat/flash.h 2009-12-08
18:53:34.0 +0100
@@ -0,0 +1,16 @@
+/*
+ * Flash support for OMAP1
+ *
+ * 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.
+ */
+
+#ifndef __OMAP_FLASH_H
+#define __OMAP_FLASH_H
+
+#include
+
+extern void omap1_set_vpp(struct map_info *map, int enable);
+
+#endif
--- /dev/null 2009-12-08 14:04:43.543715066 +0100
+++ linux-omap-2.6/arch/arm/mach-omap1/flash.c 2009-12-08 18:45:16.0
+0100
@@ -0,0 +1,33 @@
+/*
+ * Flash support for OMAP1
+ *
+ * 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
+
+void omap1_set_vpp(struct map_info *map, int enable)
+{
+ static int count;
+ u32 l;
+
+ if (enable) {
+ if (count++ == 0) {
+ l = omap_readl(EMIFS_CONFIG);
+ l |= OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ } else {
+ if (count && (--count == 0)) {
+ l = omap_readl(EMIFS_CONFIG);
+ l &= ~OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ }
+}
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 87e539a..c5c1360 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := io.o id.o sram.o clock.o irq.o mux.o serial.o devices.o
+obj-y := io.o id.o sram.o clock.o irq.o mux.o serial.o flash.o devices.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index f4b72c1..6b681d1 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -18,18 +18,19 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -144,9 +145,9 @@ static struct mtd_partition nor_partitions[] = {
},
};
-static struct flash_platform_data nor_data = {
- .map_name = "cfi_probe",
+static struct physmap_flash_data nor_data = {
.width = 2,
+ .set_vpp= omap1_set_vpp,
.parts = nor_partitions,
.nr_parts = ARRAY_SIZE(nor_partitions),
};
@@ -158,7 +159,7 @@ static struct resource nor_resource = {
};
static struct platform_device nor_device = {
- .name = "omapflash",
+ .name = "physmap-flash",
.id = 0,
.dev= {
.platform_data = &nor_data,
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 89ba8ec..3e7200e 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -34,12 +35,12 @@
#include
#include
-#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -121,9 +122,9 @@ static struct mtd_partition h2_nor_partitions[] = {
}
};
-static struct flash_platform_data h2_nor_data = {
- .map_name = "cfi_probe",
+static struct physmap_flash_data h2_nor_data = {
.width = 2,
+ .set_vpp= omap1_set_vpp,
.parts = h2_nor_partitions,
.nr_parts = ARRAY_SIZE(h2_nor_partitions),
};
@@ -134,7 +135,7 @@ static struct resource h2_nor_resource = {
};
static struct platform_device h2_nor_device = {
- .name = "omapflash",
+ .name = "physmap-flash",
.id = 0,
.dev= {
.platform_data = &h2_nor_data,
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index f5cc0a7..8a99a7c 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -36,12 +37,12 @@
#include
#include
-#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -126,9 +127,9 @@ static struct mtd_partition nor_partitions[] = {
}
};
-static struct flash_platform_data nor_data = {
- .map_name = "cfi_probe",
+static struct physmap_flash_data nor_dat
[PATCH 0/2] OMAP: use physmap-flash
There is nothing special on omapflash driver, so it can be replaced with physmap-flash. First patch in serie does exactly this and second one removes drivers/mtd/maps/omap_nor.c and associated Kconfig option. I'd like to have either ack or merge into mtd git tree by mtd maintainers for that second part. arch/arm/mach-omap1/flash.c | 33 ++ arch/arm/plat-omap/include/plat/flash.h | 16 + arch/arm/mach-omap1/Makefile |2 arch/arm/mach-omap1/board-fsample.c |9 arch/arm/mach-omap1/board-h2.c |9 arch/arm/mach-omap1/board-h3.c |9 arch/arm/mach-omap1/board-innovator.c|9 arch/arm/mach-omap1/board-osk.c |9 arch/arm/mach-omap1/board-palmte.c |9 arch/arm/mach-omap1/board-palmtt.c |9 arch/arm/mach-omap1/board-palmz71.c | 10 arch/arm/mach-omap1/board-perseus2.c |9 arch/arm/mach-omap1/board-sx1.c | 11 arch/arm/mach-omap1/board-voiceblue.c|9 arch/arm/mach-omap2/board-2430sdp.c |7 arch/arm/mach-omap2/board-h4.c |7 drivers/mtd/maps/Kconfig |9 drivers/mtd/maps/Makefile|1 drivers/mtd/maps/omap_nor.c | 188 - 19 files changed, 112 insertions(+), 253 deletions(-) -- 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
[PATCH 2/2] smc91x: remove OMAP specific bits
Now that all OMAP boards are using the board resources, we don't need to keep the arch/board specific crap in the driver header. Signed-off-by: Ladislav Michl diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h index 3911be7..bfc53eb 100644 --- a/drivers/net/smc91x.h +++ b/drivers/net/smc91x.h @@ -206,21 +206,6 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg) } } -#elif defined(CONFIG_ARCH_OMAP) - -/* We can only do 16-bit reads and writes in the static memory space. */ -#define SMC_CAN_USE_8BIT 0 -#define SMC_CAN_USE_16BIT 1 -#define SMC_CAN_USE_32BIT 0 -#define SMC_IO_SHIFT 0 -#define SMC_NOWAIT 1 - -#define SMC_inw(a, r) readw((a) + (r)) -#define SMC_outw(v, a, r) writew(v, (a) + (r)) -#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l) -#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l) -#defineSMC_IRQ_FLAGS (-1)/* from resource */ - #elif defined(CONFIG_SH_SH4202_MICRODEV) #define SMC_CAN_USE_8BIT 0 -- 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
[PATCH 1/2] OMAP: use smc91x_platdata to setup smc91x
Use smc91x_platdata to setup smc91x, so we can get rid of OMAP specific stuff
in smc91x driver
Signed-off-by: Ladislav Michl
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index f4b72c1..91e7b2f 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -100,6 +101,12 @@ static int fsample_keymap[] = {
0
};
+static struct smc91x_platdata smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource smc91x_resources[] = {
[0] = {
.start = H2P2_DBG_FPGA_ETHR_START, /* Physical */
@@ -190,6 +197,9 @@ static struct platform_device nand_device = {
static struct platform_device smc91x_device = {
.name = "smc91x",
.id = 0,
+ .dev= {
+ .platform_data = &smc91x_info,
+ },
.num_resources = ARRAY_SIZE(smc91x_resources),
.resource = smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 89ba8ec..eeafe6e 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -200,6 +201,12 @@ static struct platform_device h2_nand_device = {
.resource = &h2_nand_resource,
};
+static struct smc91x_platdata h2_smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource h2_smc91x_resources[] = {
[0] = {
.start = OMAP1610_ETHR_START, /* Physical */
@@ -216,6 +223,9 @@ static struct resource h2_smc91x_resources[] = {
static struct platform_device h2_smc91x_device = {
.name = "smc91x",
.id = 0,
+ .dev= {
+ .platform_data = &h2_smc91x_info,
+ },
.num_resources = ARRAY_SIZE(h2_smc91x_resources),
.resource = h2_smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index f5cc0a7..e0aee66 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -202,6 +203,12 @@ static struct platform_device nand_device = {
.resource = &nand_resource,
};
+static struct smc91x_platdata smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource smc91x_resources[] = {
[0] = {
.start = OMAP1710_ETHR_START, /* Physical */
@@ -218,6 +225,9 @@ static struct resource smc91x_resources[] = {
static struct platform_device smc91x_device = {
.name = "smc91x",
.id = 0,
+ .dev= {
+ .platform_data = &smc91x_info,
+ },
.num_resources = ARRAY_SIZE(smc91x_resources),
.resource = smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index cf0fdb9..91b3b8e 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -159,6 +160,12 @@ static struct map_desc innovator1510_io_desc[] __initdata
= {
}
};
+static struct smc91x_platdata innovator_smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource innovator1510_smc91x_resources[] = {
[0] = {
.start = OMAP1510_FPGA_ETHR_START, /* Physical */
@@ -175,6 +182,9 @@ static struct resource innovator1510_smc91x_resources[] = {
static struct platform_device innovator1510_smc91x_device = {
.name = "smc91x",
.id = 0,
+ .dev= {
+ .platform_data = &innovator_smc91x_info,
+ },
.num_resources = ARRAY_SIZE(innovator1510_smc91x_resources),
.resource = innovator1510_smc91x_resources,
};
@@ -241,6 +251,9 @@ static struct resource innovator1610_smc91x_resources[] = {
static struct platform_device innovator1610_smc91x_device = {
.name = "smc91x",
.id = 0,
+ .dev= {
+ .platform_data = &innovator_smc91x_info,
+ },
.num_resources = ARRAY_SIZE(innovator1610_smc91x_resources),
.resource = innovator1610_smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-osk.c b/arc
[PATCH 0/2] OMAP: convert boards to use platform data with smc91x
As smc91x driver allows specifying settings in board resources, use that rather than needing CONFIG_ARCH_OMAP in the drivers/net/smc91x.h header. arch/arm/mach-omap1/board-fsample.c | 10 ++ arch/arm/mach-omap1/board-h2.c| 10 ++ arch/arm/mach-omap1/board-h3.c| 10 ++ arch/arm/mach-omap1/board-innovator.c | 13 + arch/arm/mach-omap1/board-osk.c | 10 ++ arch/arm/mach-omap1/board-perseus2.c | 10 ++ arch/arm/mach-omap1/board-voiceblue.c | 10 ++ arch/arm/mach-omap2/board-apollon.c | 10 ++ arch/arm/mach-omap2/gpmc-smc91x.c |8 +--- arch/arm/plat-omap/debug-devices.c| 10 ++ drivers/net/smc91x.h | 15 --- 11 files changed, 98 insertions(+), 18 deletions(-) -- 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
[PATCH] arch/arm/plat-omap/devices.c - sort alphabetically
Comment in omap_init_devices asks to keep init calls and their
implementations in alphabetical order, so let it be that way.
Signed-off-by: Ladislav Michl
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index f866178..30b5db7 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -242,6 +242,39 @@ fail:
/*-*/
+#if defined(CONFIG_HW_RANDOM_OMAP) || defined(CONFIG_HW_RANDOM_OMAP_MODULE)
+
+#ifdef CONFIG_ARCH_OMAP24XX
+#defineOMAP_RNG_BASE 0x480A
+#else
+#defineOMAP_RNG_BASE 0xfffe5000
+#endif
+
+static struct resource rng_resources[] = {
+ {
+ .start = OMAP_RNG_BASE,
+ .end= OMAP_RNG_BASE + 0x4f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap_rng_device = {
+ .name = "omap_rng",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(rng_resources),
+ .resource = rng_resources,
+};
+
+static void omap_init_rng(void)
+{
+ (void) platform_device_register(&omap_rng_device);
+}
+#else
+static inline void omap_init_rng(void) {}
+#endif
+
+/*-*/
+
/* Numbering for the SPI-capable controllers when used for SPI:
* spi = 1
* uwire = 2
@@ -324,39 +357,6 @@ static void omap_init_wdt(void)
static inline void omap_init_wdt(void) {}
#endif
-/*-*/
-
-#if defined(CONFIG_HW_RANDOM_OMAP) || defined(CONFIG_HW_RANDOM_OMAP_MODULE)
-
-#ifdef CONFIG_ARCH_OMAP24XX
-#defineOMAP_RNG_BASE 0x480A
-#else
-#defineOMAP_RNG_BASE 0xfffe5000
-#endif
-
-static struct resource rng_resources[] = {
- {
- .start = OMAP_RNG_BASE,
- .end= OMAP_RNG_BASE + 0x4f,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap_rng_device = {
- .name = "omap_rng",
- .id = -1,
- .num_resources = ARRAY_SIZE(rng_resources),
- .resource = rng_resources,
-};
-
-static void omap_init_rng(void)
-{
- (void) platform_device_register(&omap_rng_device);
-}
-#else
-static inline void omap_init_rng(void) {}
-#endif
-
/*
* This gets called after board-specific INIT_MACHINE, and initializes most
* on-chip peripherals accessible on this board (except for few like USB):
@@ -384,9 +384,9 @@ static int __init omap_init_devices(void)
*/
omap_init_dsp();
omap_init_kp();
+ omap_init_rng();
omap_init_uwire();
omap_init_wdt();
- omap_init_rng();
return 0;
}
arch_initcall(omap_init_devices);
--
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
[RFC] use physmap-flash
Hi!
and sorry for touching ancient stuff again... Also sorry for long Cc list,
which is not even complete, because some projects seem to be dead now.
So, are there any objections to remove drivers/mtd/maps/omap_nor.c entirely
in favour of physmap-flash?
$ rgrep omapflash arch/arm | sed "s/:.*//" | sort | uniq
arch/arm/mach-omap1/board-fsample.c
arch/arm/mach-omap1/board-h2.c
arch/arm/mach-omap1/board-h3.c
arch/arm/mach-omap1/board-innovator.c
arch/arm/mach-omap1/board-osk.c
arch/arm/mach-omap1/board-palmte.c
arch/arm/mach-omap1/board-palmtt.c
arch/arm/mach-omap1/board-palmz71.c
arch/arm/mach-omap1/board-perseus2.c
arch/arm/mach-omap1/board-sx1.c
arch/arm/mach-omap2/board-2430sdp.c
arch/arm/mach-omap2/board-h4.c
Note that list is missing board-voiceblue.c, which is converted by patch bellow.
Function omap_set_vpp should be probably moved somewhere to plat-omap.
Suggestions?
diff --git a/arch/arm/mach-omap1/board-voiceblue.c
b/arch/arm/mach-omap1/board-voiceblue.c
index 35c75c1..30e6d0d 100644
--- a/arch/arm/mach-omap1/board-voiceblue.c
+++ b/arch/arm/mach-omap1/board-voiceblue.c
@@ -22,11 +22,11 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
@@ -85,9 +85,31 @@ static int __init ext_uart_init(void)
}
arch_initcall(ext_uart_init);
-static struct flash_platform_data voiceblue_flash_data = {
- .map_name = "cfi_probe",
+static void omap_set_vpp(struct map_info *map, int enable)
+{
+ static int count;
+ u32 l;
+
+ if (cpu_class_is_omap1()) {
+ if (enable) {
+ if (count++ == 0) {
+ l = omap_readl(EMIFS_CONFIG);
+ l |= OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ } else {
+ if (count && (--count == 0)) {
+ l = omap_readl(EMIFS_CONFIG);
+ l &= ~OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ }
+ }
+}
+
+static struct physmap_flash_data voiceblue_flash_data = {
.width = 2,
+ .set_vpp= omap_set_vpp,
};
static struct resource voiceblue_flash_resource = {
@@ -97,7 +119,7 @@ static struct resource voiceblue_flash_resource = {
};
static struct platform_device voiceblue_flash_device = {
- .name = "omapflash",
+ .name = "physmap-flash",
.id = 0,
.dev= {
.platform_data = &voiceblue_flash_data,
--
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] [OMAP1] use gen_nand
On Mon, Nov 23, 2009 at 09:24:16AM -0800, Tony Lindgren wrote: > * Ladislav Michl [091123 03:45]: > > Since omapnand driver never find its way into mainline, switch to gen_nand > > instead. > > Following patch is compile tested only, but it is based on code I wrote for > > NetStar board and runtime tested it there. > > Nice patch, and totally the way to go! Well, after one week of silence... Anything else I could do to get it merged? Btw, these boards could probably use physmap-flash, so we could get rid of omap_nor as well. Best regards, ladis -- 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 v4] mmc-omap: Add support for 16-bit and 32-bit registers
On Mon, Nov 23, 2009 at 08:23:59AM -0800, Cory Maccarrone wrote:
> The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring
> a modification of the register addresses in the mmc-omap driver. To resolve
> this, a bit shift is performed on base register addresses, either by 1 or 2
> bits depending on the CPU in use. This yields the correct registers for
> each CPU.
[...]
> @@ -167,6 +168,8 @@ struct mmc_omap_host {
> spinlock_t clk_lock; /* for changing enabled state */
> unsigned intfclk_enabled:1;
>
> + unsignedreg_shift:2;
Ah, there is no valid reason to make it bitfield, right? Whole struct is
not well layed wtr alignment, but please do not make it any worse. That is
my last complain, I swear ;-). Thank you for your patience.
Other than that, tested on OMAP5910 and it works now (though it needs
additional patch, see here:
http://thread.gmane.org/gmane.linux.kernel.mmc/649).
Tested-by: Ladislav Michl
Best regards,
ladis
--
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] mmc-omap: Add support for 16-bit and 32-bit registers
On Sun, Nov 22, 2009 at 01:16:25PM -0800, Cory Maccarrone wrote:
> The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring
> a modification of the register addresses in the mmc-omap driver. To resolve
> this, a bit shift is performed on base register addresses, either by 1 or 2
> bits depending on the CPU in use. This yields the correct registers for
> each CPU.
[...]
> @@ -167,6 +168,8 @@ struct mmc_omap_host {
> spinlock_t clk_lock; /* for changing enabled state */
> unsigned intfclk_enabled:1;
>
> + unsignedreg_shift:1;
> +
[...]
Here you made reg_shift one bit wide variable...
> @@ -1490,6 +1493,8 @@ static int __init mmc_omap_probe(struct platform_device
> *pdev)
> }
> }
>
> + host->reg_shift = (cpu_is_omap7xx() ? 1 : 2);
> +
...and here you are possibly trying to set second bit of that variable. It does
not work.
And sorry to ask again. This very driver works reliable and there are no
timeouts like this
mmci-omap mmci-omap.0: command timeout (CMD8)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
while detecting MMC card on OMAP730? (because I can see them on 5910). This
question
is unrelated to your patch.
ladis
--
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
[PATCH] [OMAP1] use gen_nand
Since omapnand driver never find its way into mainline, switch to gen_nand
instead.
Following patch is compile tested only, but it is based on code I wrote for
NetStar board and runtime tested it there.
Signed-off-by: Ladislav Michl
Cc: Imre Deak
Cc: Brian Swetland
Cc: Kevin Hilman
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index f4b72c1..8da8c64 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -30,7 +30,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -167,8 +166,40 @@ static struct platform_device nor_device = {
.resource = &nor_resource,
};
-static struct omap_nand_platform_data nand_data = {
- .options= NAND_SAMSUNG_LP_OPTIONS,
+static void nand_cmd_ctl(struct mtd_info *mtd, int cmd,unsigned int
ctrl)
+{
+ struct nand_chip *this = mtd->priv;
+ unsigned long mask;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ mask = (ctrl & NAND_CLE) ? 0x02 : 0;
+ if (ctrl & NAND_ALE)
+ mask |= 0x04;
+ writeb(cmd, (unsigned long)this->IO_ADDR_W | mask);
+}
+
+#define FSAMPLE_NAND_RB_GPIO_PIN 62
+
+static int nand_dev_ready(struct mtd_info *mtd)
+{
+ return gpio_get_value(FSAMPLE_NAND_RB_GPIO_PIN);
+}
+
+static const char *part_probes[] = { "cmdlinepart", NULL };
+
+static struct platform_nand_data nand_data = {
+ .chip = {
+ .nr_chips = 1,
+ .chip_offset= 0,
+ .options= NAND_SAMSUNG_LP_OPTIONS,
+ .part_probe_types = part_probes,
+ },
+ .ctrl = {
+ .cmd_ctrl = nand_cmd_ctl,
+ .dev_ready = nand_dev_ready,
+ },
};
static struct resource nand_resource = {
@@ -178,7 +209,7 @@ static struct resource nand_resource = {
};
static struct platform_device nand_device = {
- .name = "omapnand",
+ .name = "gen_nand",
.id = 0,
.dev= {
.platform_data = &nand_data,
@@ -233,13 +264,6 @@ static struct platform_device *devices[] __initdata = {
&lcd_device,
};
-#define P2_NAND_RB_GPIO_PIN62
-
-static int nand_dev_ready(struct omap_nand_platform_data *data)
-{
- return gpio_get_value(P2_NAND_RB_GPIO_PIN);
-}
-
static struct omap_lcd_config fsample_lcd_config __initdata = {
.ctrl_name = "internal",
};
@@ -250,9 +274,9 @@ static struct omap_board_config_kernel fsample_config[] = {
static void __init omap_fsample_init(void)
{
- if (gpio_request(P2_NAND_RB_GPIO_PIN, "NAND ready") < 0)
+ if (gpio_request(FSAMPLE_NAND_RB_GPIO_PIN, "NAND ready") < 0)
BUG();
- nand_data.dev_ready = nand_dev_ready;
+ gpio_direction_input(FSAMPLE_NAND_RB_GPIO_PIN);
omap_cfg_reg(L3_1610_FLASH_CS2B_OE);
omap_cfg_reg(M8_1610_FLASH_CS2B_WE);
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 89ba8ec..283a6f2 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -40,7 +40,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -179,11 +178,43 @@ static struct mtd_partition h2_nand_partitions[] = {
},
};
-/* dip switches control NAND chip access: 8 bit, 16 bit, or neither */
-static struct omap_nand_platform_data h2_nand_data = {
- .options= NAND_SAMSUNG_LP_OPTIONS,
- .parts = h2_nand_partitions,
- .nr_parts = ARRAY_SIZE(h2_nand_partitions),
+static void h2_nand_cmd_ctl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+ struct nand_chip *this = mtd->priv;
+ unsigned long mask;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ mask = (ctrl & NAND_CLE) ? 0x02 : 0;
+ if (ctrl & NAND_ALE)
+ mask |= 0x04;
+ writeb(cmd, (unsigned long)this->IO_ADDR_W | mask);
+}
+
+#define H2_NAND_RB_GPIO_PIN62
+
+static int h2_nand_dev_ready(struct mtd_info *mtd)
+{
+ return gpio_get_value(H2_NAND_RB_GPIO_PIN);
+}
+
+static const char *h2_part_probes[] = { "cmdlinepart", NULL };
+
+struct platform_nand_data h2_nand_platdata = {
+ .chip = {
+ .nr_chips = 1,
+ .chip_offset= 0,
+ .nr_partitions = ARRAY_SIZE(h2_nand_partitions),
+ .partitions = h2_nand_partitions,
+ .options= NAND_SAMSUNG_LP_OPTIONS,
+ .part_probe_types = h2_part_probes,
+ },
+ .ctrl = {
+ .cmd_ctrl = h2_nand_cmd_ctl,
+ .dev_ready = h2_nand_dev_ready,
+
+ },
};
static struct
Re: [PATCH] [mmc-omap] Add support for 16-bit and 32-bit registers
On Wed, Nov 18, 2009 at 01:09:22PM -0800, Cory Maccarrone wrote: > On Wed, Nov 18, 2009 at 10:41 AM, Ladislav Michl > wrote: > > Did you test it? It does not work on 5910, see here: > > http://thread.gmane.org/gmane.linux.kernel.mmc/649 > > Not sure why it wouldn't work on the 5910. I tested it on my device, > and it works properly for me, but then I don't have an omap-based > device that uses 32-bit register definitions. I'm confused at the > post you have above though...Is that with my patch, or is that with > something else? It seems to reference the status of current git, > which I don't think this patch shouldn't be in. To put it clear, current git does not work and it is unrelated to your patch. If driver works for you with your patch, then either your MMC card or controller in your SoC survives multiple init sequences or it has something to do with clock settings or... You can find two more people confirming this here: http://www.spinics.net/lists/linux-omap/msg09547.html I'll probably need to find some time to read MMC spec. ladis -- 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] [mmc-omap] Add support for 16-bit and 32-bit registers
On Sat, Nov 14, 2009 at 07:24:55PM -0800, Cory Maccarrone wrote: > The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring > a modification of the register addresses in the mmc-omap driver. To > make this as portable as possible, I made the following changes: Hmm, I would not trade portability anyone currently needs for complexity... > * Moved register address offsets from drivers/mmc/host/omap.c to > drivers/mmc/host/omap.h > * Implemented a lookup table for 16-bit and 32-bit register offsets > * Added a reg_size field in the mmc_omap_host structure > * Added code in mmc_omap_probe() to populate the reg_size > field based on processor in use > * Added inline function to return the register offset based on > the register size and register name > * Modified mmc-omap driver to use the new inline function to call out > register names All this could be probably done by making register definition an index and shifting it left by one or two depending on CPU. No lookup table needed. > This change should allow the omap7xx-series of processors to correctly > utilize the MMC driver. Did you test it? It does not work on 5910, see here: http://thread.gmane.org/gmane.linux.kernel.mmc/649 Best regards, ladis -- 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: mmci-omap regressions
Hmm, it seems noone is going to fix it for me, so let's move on...
On Mon, Jan 12, 2009 at 12:42:43PM +0200, Tony Lindgren wrote:
> Hi,
>
> * Ladislav Michl [090112 11:19]:
> > Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well
> > on
> > my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently
> > used
> > for production) doesn't work at all. Inspecting diff between 2.6.15-omap2
> > and
> > 2.6.22-omap1 showed that
> > --- a/drivers/mmc/host/omap.c 2009-01-12 09:32:23.0 +0100
> > +++ b/drivers/mmc/host/omap.c 2009-01-12 09:46:26.0 +0100
> > @@ -974,7 +974,7 @@
> > * Writing to the CON register twice seems to do the trick. */
> > for (i = 0; i < 2; i++)
> > OMAP_MMC_WRITE(host, CON, dsor);
> > - if (ios->power_mode == MMC_POWER_ON) {
> > + if (ios->power_mode == MMC_POWER_UP) {
> > /* Send clock cycles, poll completion */
> > OMAP_MMC_WRITE(host, IE, 0);
> > OMAP_MMC_WRITE(host, STAT, 0x);
> > did the trick.
> >
> > With above patch applied to 2.6.22-omap1 I got
> > # modprobe omap
> > mmci-omap mmci-omap.1: command timeout, CMD 8
> > mmcblk0: mmc0:0001127104KiB
> > mmcblk0: p1
> > while there is no command timeout with 2.6.15-omap2, but at least it works.
>
> OK, well at least that's a good start on figuring out what has broken
> it. It does not seem like the right fix though as the MMC_POWER_UP
> should just power up the slot, and clocks should not get turned on
> until in MMC_POWER_ON.
>
> > Doing the same modification in current git doesn't help. Moreover removing
> > omap.ko and inserting again behaves differently than inserting for first
> > time:
> > # modprobe omap
> > mmci-omap mmci-omap.0: command timeout (CMD8)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmc0: error -22 whilst initialising MMC card
> > # rmmod omap
> > # modprobe omap
> > mmci-omap: probe of mmci-omap.0 failed with error -16
>
> Looks like the current git head does goto exit after MMC_POWER_UP before
> you even get to that code.
>
> > I'll happily send any requested debug informations and test any patches
>
> Can you maybe try to debug by applying your patch and commenting out
> the goto exit?
Here is somehow working version. It seems sending init stream multiple times
is not good idea. Please note I have no clue how is MMC supposed to work
(except very basic knowledge).
So with the patch (complete patch, see mmc driver fixes I posted earlier today)
below, output looks like:
# modprobe omap
MMC_POWER_OFF
MMC dsor: 0
MMC_POWER_UP
MMC_POWER_ON
MMC dsor: 878
time elapsed: 254us
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
mmci-omap mmci-omap.0: command timeout (CMD8)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 803
mmc0: new MMC card at address 0001
mmcblk0: mmc0:0001 D0601 122 MiB
mmcblk0:
p1
Note, that "command timeout" is still there, but at least it detect card and
also note that "worst case at 400kHz, 80 cycles makes 200 microsecs" took
actually more than 200us.
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 5d773b8..0bcd6b0 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -123,15 +123,16 @@ struct mmc_omap_host {
struct mmc_data * data;
struct mmc_host * mmc;
struct device * dev;
- unsigned char id; /* 16xx chips have 2 MMC blocks */
struct clk *iclk;
struct clk *fclk;
struct resource *mem_res;
void __iomem*virt_base;
unsigned intphys_base;
int irq;
+ unsigned char id; /* 16xx chips have 2 MMC blocks */
unsigned char bus_mode;
[PATCH] mmci-omap: remove bogus check for host->iclk
Remove check for host->iclk being NULL from error path since we already know
it is non-null and use return value from clk_get.
Signed-off-by: Ladislav Michl
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 5d773b8..c6d7e8e 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1459,8 +1459,10 @@ static int __init mmc_omap_probe(struct platform_device
*pdev)
goto err_ioremap;
host->iclk = clk_get(&pdev->dev, "ick");
- if (IS_ERR(host->iclk))
+ if (IS_ERR(host->iclk)) {
+ ret = PTR_ERR(host->iclk);
goto err_free_mmc_host;
+ }
clk_enable(host->iclk);
host->fclk = clk_get(&pdev->dev, "fck");
@@ -1500,10 +1502,8 @@ err_free_irq:
err_free_fclk:
clk_put(host->fclk);
err_free_iclk:
- if (host->iclk != NULL) {
- clk_disable(host->iclk);
- clk_put(host->iclk);
- }
+ clk_disable(host->iclk);
+ clk_put(host->iclk);
err_free_mmc_host:
iounmap(host->virt_base);
err_ioremap:
--
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
[PATCH] mmci-omap: free irq resource
Free IRQ on remove. Signed-off-by: Ladislav Michl diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c index 5d773b8..5f970e2 100644 --- a/drivers/mmc/host/omap.c +++ b/drivers/mmc/host/omap.c @@ -1529,6 +1529,7 @@ static int mmc_omap_remove(struct platform_device *pdev) host->pdata->cleanup(&pdev->dev); mmc_omap_fclk_enable(host, 0); + free_irq(host->irq, host); clk_put(host->fclk); clk_disable(host->iclk); clk_put(host->iclk); -- 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: [APPLIED] [PATCH] [RFC] OMAP: eliminate OMAP_MAX_NR_PORTS
On Tue, Oct 20, 2009 at 05:40:17PM -0700, Tony Lindgren wrote: > > > > Unable to handle kernel NULL pointer dereference at virtual address > > > > 0028 > > > > pgd = c0004000 > > > > [0028] *pgd= > > > > Internal error: Oops: 8005 [#1] > > > > last sysfs file: > > > > Modules linked in: > > > > CPU: 0Not tainted (2.6.32-rc5-06314-g4155da6-dirty #12) > > > > PC is at 0x28 > > > > LR is at serial8250_config_port+0x184/0xc34 > > > > (...etc...) > > > > > > > > Please consider following fix (and while there fix OMAP2 too as patch > > > > broke > > > > it as well (untested)) > > > > > > Thanks, I already refreshed the original patch with the same fix few > > > days ago :) It should be there in for-next branch and master branch. > > > > Correction, sorry looks like I did not really read your patch. It seems > > to be the right solution for mach-omap1, but not needed for mach-omap2 > > because the array is not plat_serial8250_port on mach-omap2. Ach, sorry. Now it was me who didn't read code carefully. > I've refreshed the original serial.c patch in for-next branch by leaving > out the mach-omap2 changes. Also updated in the master branch, can you > please check? Just pulled master branch and succesfully booted on OMAP5910 board. Thank you, ladis -- 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: [APPLIED] [PATCH] [RFC] OMAP: eliminate OMAP_MAX_NR_PORTS
On Fri, Oct 09, 2009 at 06:46:23PM -0400, Tony Lindgren wrote:
> This patch has been applied to the linux-omap
> by youw fwiendly patch wobot.
>
> Branch in linux-omap: omap2-upstream
>
> Initial commit ID (Likely to change): 439d2c69335a28ffdb5a9795ff384b6755ca0f7f
>
> PatchWorks
> http://patchwork.kernel.org/patch/52477/
>
> Git (Likely to change, and takes a while to get mirrored)
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=439d2c69335a28ffdb5a9795ff384b6755ca0f7f
This patch broke all OMAP1 boards. NULL terminator entry for omap1
serial_platform_data cannot be removed just because serial driver uses
is as last entry marker. Without it we end this way:
Unable to handle kernel NULL pointer dereference at virtual address 0028
pgd = c0004000
[0028] *pgd=
Internal error: Oops: 8005 [#1]
last sysfs file:
Modules linked in:
CPU: 0Not tainted (2.6.32-rc5-06314-g4155da6-dirty #12)
PC is at 0x28
LR is at serial8250_config_port+0x184/0xc34
(...etc...)
Please consider following fix (and while there fix OMAP2 too as patch broke
it as well (untested))
Signed-off-by: Ladislav Michl
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index 9c59332..0392ff5 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -86,7 +86,9 @@ static struct plat_serial8250_port serial_platform_data[] = {
.iotype = UPIO_MEM,
.regshift = 2,
.uartclk= OMAP16XX_BASE_BAUD * 16,
- },
+ }, {
+ }
+
};
static struct platform_device serial_device = {
@@ -119,7 +121,7 @@ void __init omap_serial_init(void)
serial_platform_data[2].uartclk = OMAP1510_BASE_BAUD * 16;
}
- for (i = 0; i < ARRAY_SIZE(serial_platform_data); i++) {
+ for (i = 0; i < ARRAY_SIZE(serial_platform_data) - 1; i++) {
unsigned char reg;
/* Static mapping, never released */
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index dabc089..ca69ffa 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -585,7 +585,7 @@ void __init omap_serial_early_init(void)
* if not needed.
*/
- for (i = 0; i < ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i < ARRAY_SIZE(omap_uart) - 1; i++) {
struct omap_uart_state *uart = &omap_uart[i];
struct platform_device *pdev = &uart->pdev;
struct device *dev = &pdev->dev;
@@ -637,7 +637,7 @@ void __init omap_serial_init(void)
{
int i;
- for (i = 0; i < ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i < ARRAY_SIZE(omap_uart) - 1; i++) {
struct omap_uart_state *uart = &omap_uart[i];
struct platform_device *pdev = &uart->pdev;
struct device *dev = &pdev->dev;
--
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/5] omap mmc: Add better MMC low-level init
On Tue, Jan 13, 2009 at 03:43:44PM +0200, Tony Lindgren wrote:
> > diff --git a/arch/arm/plat-omap/include/mach/mmc.h
> > b/arch/arm/plat-omap/include/mach/mmc.h
> > index 031250f..1129e97 100644
> > --- a/arch/arm/plat-omap/include/mach/mmc.h
> > +++ b/arch/arm/plat-omap/include/mach/mmc.h
> > @@ -51,7 +51,6 @@ struct omap_mmc_platform_data {
> > * not supported */
> > int (* init)(struct device *dev);
> > void (* cleanup)(struct device *dev);
> > - void (* shutdown)(struct device *dev);
> >
> > /* To handle board related suspend/resume functionality for MMC */
> > int (*suspend)(struct device *dev, int slot);
> > @@ -77,10 +76,6 @@ struct omap_mmc_platform_data {
> >
> > /* use the internal clock */
> > unsigned internal_clock:1;
> > - s16 power_pin;
> > -
> > - int switch_pin; /* gpio (card detect) */
> > - int gpio_wp;/* gpio (write protect) */
> >
> > int (* set_bus_mode)(struct device *dev, int slot, int
> > bus_mode);
> > int (* set_power)(struct device *dev, int slot, int power_on,
> > int vdd);
>
> Hmm, aren't switch_pin and gpio_wp used at least in the
> mmc-twl4030.c?
Yes, they are. I missed them completely. Sorry.
> I guess they could be internal to mmc-twl4030.c if not used
> in the drivers directly.
They could, but that's a bit more complicated. Will look at it later.
> > diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> > index 67d7b7f..84de289 100644
> > --- a/drivers/mmc/host/omap.c
> > +++ b/drivers/mmc/host/omap.c
> > @@ -157,8 +157,6 @@ struct mmc_omap_host {
> > struct timer_list dma_timer;
> > unsigneddma_len;
> >
> > - short power_pin;
> > -
> > struct mmc_omap_slot*slots[OMAP_MMC_MAX_SLOTS];
> > struct mmc_omap_slot*current_slot;
> > spinlock_t slot_lock;
> >
>
> Looks like power_pin could go though.
Updated patch follows
Signed-off-by: Ladislav Michl
diff --git a/arch/arm/plat-omap/include/mach/mmc.h
b/arch/arm/plat-omap/include/mach/mmc.h
index 4435bd4..81d5b36 100644
--- a/arch/arm/plat-omap/include/mach/mmc.h
+++ b/arch/arm/plat-omap/include/mach/mmc.h
@@ -79,7 +79,6 @@ struct omap_mmc_platform_data {
/* use the internal clock */
unsigned internal_clock:1;
- s16 power_pin;
int switch_pin; /* gpio (card detect) */
int gpio_wp;/* gpio (write protect) */
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 67d7b7f..e8e0e09 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -157,8 +157,6 @@ struct mmc_omap_host {
struct timer_list dma_timer;
unsigneddma_len;
- short power_pin;
-
struct mmc_omap_slot*slots[OMAP_MMC_MAX_SLOTS];
struct mmc_omap_slot*current_slot;
spinlock_t slot_lock;
--
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: mmci-omap regressions
On Mon, Jan 12, 2009 at 12:42:43PM +0200, Tony Lindgren wrote:
> Looks like the current git head does goto exit after MMC_POWER_UP before
> you even get to that code.
...and 2.6.22-omap1 version does return at the same place. So patch can be
also shown as
--- a/drivers/mmc/host/omap.c 2009-01-12 09:32:23.0 +0100
+++ b/drivers/mmc/host/omap.c 2009-01-12 12:31:52.0 +0100
@@ -974,14 +974,6 @@
* Writing to the CON register twice seems to do the trick. */
for (i = 0; i < 2; i++)
OMAP_MMC_WRITE(host, CON, dsor);
- if (ios->power_mode == MMC_POWER_ON) {
- /* Send clock cycles, poll completion */
- OMAP_MMC_WRITE(host, IE, 0);
- OMAP_MMC_WRITE(host, STAT, 0x);
- OMAP_MMC_WRITE(host, CMD, 1 << 7);
- while ((OMAP_MMC_READ(host, STAT) & 1) == 0);
- OMAP_MMC_WRITE(host, STAT, 1);
- }
clk_disable(host->fclk);
}
Sorry for not thinking a bit harder first time. I'll try to figure out how
to make git version working.
ladis
--
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
mmci-omap regressions
Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well on
my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently used
for production) doesn't work at all. Inspecting diff between 2.6.15-omap2 and
2.6.22-omap1 showed that
--- a/drivers/mmc/host/omap.c 2009-01-12 09:32:23.0 +0100
+++ b/drivers/mmc/host/omap.c 2009-01-12 09:46:26.0 +0100
@@ -974,7 +974,7 @@
* Writing to the CON register twice seems to do the trick. */
for (i = 0; i < 2; i++)
OMAP_MMC_WRITE(host, CON, dsor);
- if (ios->power_mode == MMC_POWER_ON) {
+ if (ios->power_mode == MMC_POWER_UP) {
/* Send clock cycles, poll completion */
OMAP_MMC_WRITE(host, IE, 0);
OMAP_MMC_WRITE(host, STAT, 0x);
did the trick.
With above patch applied to 2.6.22-omap1 I got
# modprobe omap
mmci-omap mmci-omap.1: command timeout, CMD 8
mmcblk0: mmc0:0001127104KiB
mmcblk0: p1
while there is no command timeout with 2.6.15-omap2, but at least it works.
Doing the same modification in current git doesn't help. Moreover removing
omap.ko and inserting again behaves differently than inserting for first
time:
# modprobe omap
mmci-omap mmci-omap.0: command timeout (CMD8)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmc0: error -22 whilst initialising MMC card
# rmmod omap
# modprobe omap
mmci-omap: probe of mmci-omap.0 failed with error -16
I'll happily send any requested debug informations and test any patches
Thank you,
ladis
--
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/5] omap mmc: Add better MMC low-level init
On Sun, Dec 07, 2008 at 01:47:47PM -0800, Tony Lindgren wrote:
> This will simplify the MMC low-level init, and make it more
> flexible to add support for a newer MMC controller in the
> following patches.
Simple simplification...
Signed-off-by: Ladislav Michl
diff --git a/arch/arm/mach-omap1/board-h3-mmc.c
b/arch/arm/mach-omap1/board-h3-mmc.c
index fdfe793..d7f40f9 100644
--- a/arch/arm/mach-omap1/board-h3-mmc.c
+++ b/arch/arm/mach-omap1/board-h3-mmc.c
@@ -24,11 +24,7 @@
static int mmc_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
- if (power_on)
- gpio_direction_output(H3_TPS_GPIO_MMC_PWR_EN, 1);
- else
- gpio_direction_output(H3_TPS_GPIO_MMC_PWR_EN, 0);
-
+ gpio_set_value(H3_TPS_GPIO_MMC_PWR_EN, power_on);
return 0;
}
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 7fdb725..4de55c7 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -223,11 +223,7 @@ static struct omap_usb_config nokia770_usb_config
__initdata = {
static int nokia770_mmc_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
- if (power_on)
- gpio_set_value(NOKIA770_GPIO_MMC_POWER, 1);
- else
- gpio_set_value(NOKIA770_GPIO_MMC_POWER, 0);
-
+ gpio_set_value(NOKIA770_GPIO_MMC_POWER, power_on);
return 0;
}
--
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/5] omap mmc: Add better MMC low-level init
On Sat, Jan 10, 2009 at 11:49:42PM +0100, Ladislav Michl wrote:
> On Sun, Dec 07, 2008 at 01:47:47PM -0800, Tony Lindgren wrote:
> > diff --git a/arch/arm/mach-omap1/board-h2-mmc.c
> > b/arch/arm/mach-omap1/board-h2-mmc.c
> > index 504ae88..409fa56 100644
> > --- a/arch/arm/mach-omap1/board-h2-mmc.c
> > +++ b/arch/arm/mach-omap1/board-h2-mmc.c
> [snip]
> > +static void mmc_shutdown(struct device *dev)
> > +{
> > + gpio_free(H2_TPS_GPIO_MMC_PWR_EN);
> > +}
> > +
> > +/*
> > + * H2 could use the following functions tested:
> > + * - mmc_get_cover_state that uses OMAP_MPUIO(1)
> > + * - mmc_get_wp that uses OMAP_MPUIO(3)
> > + */
> > +static struct omap_mmc_platform_data mmc1_data = {
> > + .nr_slots = 1,
> > + .init = mmc_late_init,
> > + .shutdown = mmc_shutdown,
> It seems that shutdown is no-op, so what about patch below?
After all, lets remove some unused fields.
Signed-off-by: Ladislav Michl
diff --git a/arch/arm/plat-omap/include/mach/mmc.h
b/arch/arm/plat-omap/include/mach/mmc.h
index 031250f..1129e97 100644
--- a/arch/arm/plat-omap/include/mach/mmc.h
+++ b/arch/arm/plat-omap/include/mach/mmc.h
@@ -51,7 +51,6 @@ struct omap_mmc_platform_data {
* not supported */
int (* init)(struct device *dev);
void (* cleanup)(struct device *dev);
- void (* shutdown)(struct device *dev);
/* To handle board related suspend/resume functionality for MMC */
int (*suspend)(struct device *dev, int slot);
@@ -77,10 +76,6 @@ struct omap_mmc_platform_data {
/* use the internal clock */
unsigned internal_clock:1;
- s16 power_pin;
-
- int switch_pin; /* gpio (card detect) */
- int gpio_wp;/* gpio (write protect) */
int (* set_bus_mode)(struct device *dev, int slot, int
bus_mode);
int (* set_power)(struct device *dev, int slot, int power_on,
int vdd);
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 67d7b7f..84de289 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -157,8 +157,6 @@ struct mmc_omap_host {
struct timer_list dma_timer;
unsigneddma_len;
- short power_pin;
-
struct mmc_omap_slot*slots[OMAP_MMC_MAX_SLOTS];
struct mmc_omap_slot*current_slot;
spinlock_t slot_lock;
--
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/5] omap mmc: Add better MMC low-level init
On Sun, Dec 07, 2008 at 01:47:47PM -0800, Tony Lindgren wrote:
> diff --git a/arch/arm/mach-omap1/board-h2-mmc.c
> b/arch/arm/mach-omap1/board-h2-mmc.c
> index 504ae88..409fa56 100644
> --- a/arch/arm/mach-omap1/board-h2-mmc.c
> +++ b/arch/arm/mach-omap1/board-h2-mmc.c
[snip]
> +static void mmc_shutdown(struct device *dev)
> +{
> + gpio_free(H2_TPS_GPIO_MMC_PWR_EN);
> +}
> +
> +/*
> + * H2 could use the following functions tested:
> + * - mmc_get_cover_state that uses OMAP_MPUIO(1)
> + * - mmc_get_wp that uses OMAP_MPUIO(3)
> + */
> +static struct omap_mmc_platform_data mmc1_data = {
> + .nr_slots = 1,
> + .init = mmc_late_init,
> + .shutdown = mmc_shutdown,
It seems that shutdown is no-op, so what about patch below?
Signed-off-by: Ladislav Michl
diff --git a/arch/arm/mach-omap1/board-h2-mmc.c
b/arch/arm/mach-omap1/board-h2-mmc.c
index 409fa56..613adfc 100644
--- a/arch/arm/mach-omap1/board-h2-mmc.c
+++ b/arch/arm/mach-omap1/board-h2-mmc.c
@@ -24,19 +24,13 @@
static int mmc_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
- if (power_on)
- gpio_direction_output(H2_TPS_GPIO_MMC_PWR_EN, 1);
- else
- gpio_direction_output(H2_TPS_GPIO_MMC_PWR_EN, 0);
-
+ gpio_set_value(H2_TPS_GPIO_MMC_PWR_EN, power_on);
return 0;
}
static int mmc_late_init(struct device *dev)
{
- int ret;
-
- ret = gpio_request(H2_TPS_GPIO_MMC_PWR_EN, "MMC power");
+ int ret = gpio_request(H2_TPS_GPIO_MMC_PWR_EN, "MMC power");
if (ret < 0)
return ret;
@@ -45,7 +39,7 @@ static int mmc_late_init(struct device *dev)
return ret;
}
-static void mmc_shutdown(struct device *dev)
+static void mmc_cleanup(struct device *dev)
{
gpio_free(H2_TPS_GPIO_MMC_PWR_EN);
}
@@ -58,7 +52,7 @@ static void mmc_shutdown(struct device *dev)
static struct omap_mmc_platform_data mmc1_data = {
.nr_slots = 1,
.init = mmc_late_init,
- .shutdown = mmc_shutdown,
+ .cleanup= mmc_cleanup,
.dma_mask = 0x,
.slots[0] = {
.set_power = mmc_set_power,
--
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] [RFC] dmtimer library is very inefficient today
On Tue, Mar 18, 2008 at 11:33:40AM -0700, Kevin Hilman wrote: > and upstream folks tend dislike the polling loops like this: > >while(condition); > > and prefer the semicolon on its own line to be clear that the loop is > indeed doing nothing. > >while(condition) >; > Once there, polling loops usually looks like this while (condition) cpu_relax(); -- 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
