Re: [PATCH 09/16] ARM: OMAP: Split plat/mmc.h into local headers and platform_data
On Fri, Oct 5, 2012 at 3:34 AM, Tony Lindgren t...@atomide.com wrote: We need to remove this from plat for ARM common zImage support. Cc: Chris Ball c...@laptop.org Cc: Venkatraman S svenk...@ti.com Cc: linux-...@vger.kernel.org Signed-off-by: Tony Lindgren t...@atomide.com Thanks Tony. I suppose this should go into your tree.. Acked-by: Venkatraman S svenk...@ti.com --- arch/arm/mach-omap1/board-h2-mmc.c |5 +-- arch/arm/mach-omap1/board-h3-mmc.c |3 +- arch/arm/mach-omap1/board-htcherald.c |2 + arch/arm/mach-omap1/board-innovator.c |2 + arch/arm/mach-omap1/board-nokia770.c |2 + arch/arm/mach-omap1/board-sx1-mmc.c|3 +- arch/arm/mach-omap1/devices.c |2 + arch/arm/mach-omap1/mmc.h | 18 +++ arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-n8x0.c |2 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-rm680.c |2 + arch/arm/mach-omap2/hsmmc.c|2 + arch/arm/mach-omap2/mmc.h | 23 ++ arch/arm/mach-omap2/msdi.c |2 + arch/arm/mach-omap2/omap4-common.c |2 + arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 + arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c |2 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 + drivers/mmc/host/omap.c|3 +- drivers/mmc/host/omap_hsmmc.c |2 + include/linux/platform_data/mmc-omap.h | 45 +--- 24 files changed, 67 insertions(+), 67 deletions(-) create mode 100644 arch/arm/mach-omap1/mmc.h create mode 100644 arch/arm/mach-omap2/mmc.h -- 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: MUSB regression in linux next at least for pandboard
Hi, On Friday 05 October 2012 07:09 AM, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [121004 11:04]: Hi, On Thu, Oct 04, 2012 at 10:31:08AM -0700, Tony Lindgren wrote: Hi Felipe Kishon, Looks like musb is broken at least on pandaboard es in current linux next while it works with v3.6: [1.933074] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) [1.939422] unable to find transceiver of type USB2 PHYrouping on. Total pages: 251648 [1.945190] HS USB OTG: no transceiver configured [1.950134] musb-hdrc musb-hdrc.0: musb_init_controller failed with status -19 [1.958160] couldn't find an available UDC I do have CONFIG_OMAP_USB2 set. Note that we won't be able to flip omap4 over to be device tree only probably until v3.9 because of the bindings we're still missing from usability point of view. So this regression should be fixed. I see. Kishon, can you cook a patch adding platform_data until we actually move to DT-only for OMAP4 ? Sure. Thanks Kishon -- 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 0/7] uio_pruss cleanup and platform support
Matt, On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote: On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote: Changes since v1: - Replaced uio_pruss private SRAM API use with genalloc - Added DA850 platform device and clock support - Added DA850 L3 RAM gen_pool support - Split out DT binding This series enables uio_pruss on both DA850 and AM33xx. The driver previously was not enabled by any platform and the private SRAM API was accessing an invalid SRAM bank for use on DA850. For AM33xx, DT, pinctrl, and runtime PM support are added since AM33xx only boots via DT. I'm dropping AM33xx/OMAP support from v3 for this series Just for my clarification, I believe you will be taking up AM33xx/OMAP SRAM support later once you have completed supporting DaVinci. Right? since the focus has turned to fixing Davinci SRAM to provide genalloc support and the associated use of that in the driver. I'll have a separate series with AM33xx support since dealing cleanly with external resets on OMAP is a bigger issue. -Matt ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Regards, Gururaja -- 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
[PATCHv4] Input: keypad: Add smsc ece1099 keypad driver
From: G, Manjunath Kondaiah manj...@ti.com
SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
supports a keypad scan matrix of 23*8.This driver uses this
device as a keypad driver.
Tested on omap5430 evm with 3.6-rc6 custom kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
This patch was posted as a series initially
http://www.spinics.net/lists/linux-omap/msg78772.html
But the parent mfd driver has beeen already picked by mfd maintainer.
So this patch can now posted as an standalone patch.
v3-v4:
Fix Dmitry's comments:
- Error patch(input_free_device/input_unregister_device).
- Few cleanups.
- Included INPUT_MATRIXKMAP
drivers/input/keyboard/Kconfig | 12 +
drivers/input/keyboard/Makefile |1 +
drivers/input/keyboard/smsc-ece1099-keypad.c | 303 ++
3 files changed, 316 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index c50fa75..e370b03 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -593,6 +593,18 @@ config KEYBOARD_TWL4030
To compile this driver as a module, choose M here: the
module will be called twl4030_keypad.
+config KEYBOARD_SMSC
+ tristate SMSC ECE1099 keypad support
+ depends on I2C
+ select INPUT_MATRIXKMAP
+ help
+ Say Y here if your board use the smsc keypad controller
+ for omap5 defconfig. It's safe to say enable this
+ even on boards that don't use the keypad controller.
+
+ To compile this driver as a module, choose M here: the
+ module will be called smsc-ece1099-keypad.
+
config KEYBOARD_XTKBD
tristate XT keyboard
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 44e7600..0f2aa26 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X)+=
tc3589x-keypad.o
obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
+obj-$(CONFIG_KEYBOARD_SMSC)+= smsc-ece1099-keypad.o
obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
diff --git a/drivers/input/keyboard/smsc-ece1099-keypad.c
b/drivers/input/keyboard/smsc-ece1099-keypad.c
new file mode 100644
index 000..a4a0dfe
--- /dev/null
+++ b/drivers/input/keyboard/smsc-ece1099-keypad.c
@@ -0,0 +1,303 @@
+/*
+ * SMSC_ECE1099 Keypad driver
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/i2c.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/input.h
+#include linux/gpio.h
+#include linux/slab.h
+#include linux/jiffies.h
+#include linux/input/matrix_keypad.h
+#include linux/delay.h
+#include linux/mfd/core.h
+#include linux/mfd/smsc.h
+#include linux/of_gpio.h
+#include linux/of.h
+
+#define KEYPRESS_TIME 200
+
+struct smsc_keypad {
+ struct smsc *smsc;
+ struct matrix_keymap_data *keymap_data;
+ unsigned int last_key_state[16];
+ unsigned int last_col;
+ unsigned int last_key_ms[16];
+ unsigned short *keymap;
+ struct i2c_client *client;
+ struct input_dev *input;
+ int rows, cols;
+ int row_shift;
+ bool no_autorepeat;
+ unsignedirq;
+ struct device *dev;
+};
+
+static void smsc_kp_scan(struct smsc_keypad *kp)
+{
+ struct input_dev *input = kp-input;
+ int i, j;
+ int row, col;
+ int temp, code;
+ unsigned int new_state[16];
+ unsigned int bits_changed;
+ int this_ms;
+
+ smsc_write(kp-dev, SMSC_KP_INT_MASK, 0x00);
+ smsc_write(kp-dev, SMSC_KP_INT_STAT, 0xFF);
+
+ /* Scan for row and column */
+ for (i = 0; i kp-cols; i++) {
+ smsc_write(kp-dev, SMSC_KP_OUT, SMSC_KSO_EVAL + i);
+ /* Read Row Status */
+ smsc_read(kp-dev, SMSC_KP_IN, temp);
+ if (temp == 0xFF)
+ continue;
+
+ col = i;
+ for (j = 0; j kp-rows; j++) {
+ if ((temp 0x01) != 0x00) {
+ temp = temp 1;
+ continue;
+ }
+
+
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
On Fri, Oct 5, 2012 at 1:08 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Thu, 4 Oct 2012 22:30:58 +0200, Enric Balletbò i Serra wrote: I recently tested kernel 3.6-rc5 and worked for me. Let me check tomorrow kernel 3.6. Which u-boot version are you using? 2011.12 + a few patches to make the NAND of the IGEPv2 rev6 work. Let me try to build a recent U-Boot (which now includes the SPL for the IGEP) and see if it improves the situation. However, I believe that the rule is that the kernel shouldn't depend too much on initialization done by the bootloader, so it still seems like an issue to me. Correct, if the kernel is relying on any bootloader assumptions, it should be considered a kernel bug. We'd really like to remove any bootloader assumptions from the kernel. This will allow the kernel to be bootloader independent, and make it easier to support reboot via kexec. Kevin Hi Thomas, As Enric said, u-boot has SPL and NAND support for IGEP since v2012.10-rc1. I just tried kernel a 3.6 with u-boot v2012.10-rc2 and it works for me. But I agree that the kernel shouldn't do any assumptions about the bootloader setting correctly the omap mux. Could you please share your bootloader that makes the kernel to fail (or your IGEP NAND patches on top of u-boot U-boot 2011.12) so I can reproduce the issue and try to fix it? Thanks a lot and best regards, Javier -- 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 14/24] USB: ohci: merge ohci_finish_controller_resume with ohci_resume
On 10/04/2012 05:17 PM, Florian Fainelli :
Merge ohci_finish_controller_resume with ohci_resume as suggested by Alan
Stern. Since ohci_finish_controller_resume no longer exists, update the
various OHCI drivers to call ohci_resume() instead. Some drivers used to set
themselves the bit HCD_FLAG_HW_ACCESSIBLE, which is now handled by
ohci_resume().
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
drivers/usb/host/ohci-at91.c |2 +-
Seems ok for AT91, so
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Thanks Florian, bye,
drivers/usb/host/ohci-ep93xx.c |2 +-
drivers/usb/host/ohci-exynos.c |5 +
drivers/usb/host/ohci-hcd.c | 41 +++--
drivers/usb/host/ohci-hub.c | 42
--
drivers/usb/host/ohci-omap.c |2 +-
drivers/usb/host/ohci-platform.c |2 +-
drivers/usb/host/ohci-pxa27x.c |2 +-
drivers/usb/host/ohci-s3c2410.c |3 +--
drivers/usb/host/ohci-spear.c|2 +-
drivers/usb/host/ohci-tmio.c |2 +-
11 files changed, 48 insertions(+), 57 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 0bf72f9..908d84a 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -705,7 +705,7 @@ static int ohci_hcd_at91_drv_resume(struct
platform_device *pdev)
if (!clocked)
at91_start_clock();
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
#else
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index dbfbd1d..a982f04 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -194,7 +194,7 @@ static int ohci_hcd_ep93xx_drv_resume(struct
platform_device *pdev)
ep93xx_start_hc(pdev-dev);
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
#endif
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index fc3091b..53c5a989 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -252,10 +252,7 @@ static int exynos_ohci_resume(struct device *dev)
if (pdata pdata-phy_init)
pdata-phy_init(pdev, S5P_USB_PHY_HOST);
- /* Mark hardware accessible again as we are out of D3 state by now */
- set_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
-
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 5d30992..568bdb3 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1003,13 +1003,50 @@ static int __maybe_unused ohci_suspend(struct usb_hcd
*hcd, bool do_wakeup)
static int __maybe_unused ohci_resume(struct usb_hcd *hcd, bool hibernated)
{
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ int port;
+ boolneed_reinit = false;
+
set_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
/* Make sure resume from hibernation re-enumerates everything */
if (hibernated)
- ohci_usb_reset(hcd_to_ohci(hcd));
+ ohci_usb_reset(ohci);
+
+ /* See if the controller is already running or has been reset */
+ ohci-hc_control = ohci_readl(ohci, ohci-regs-control);
+ if (ohci-hc_control (OHCI_CTRL_IR | OHCI_SCHED_ENABLES)) {
+ need_reinit = true;
+ } else {
+ switch (ohci-hc_control OHCI_CTRL_HCFS) {
+ case OHCI_USB_OPER:
+ case OHCI_USB_RESET:
+ need_reinit = true;
+ }
+ }
+
+ /* If needed, reinitialize and suspend the root hub */
+ if (need_reinit) {
+ spin_lock_irq(ohci-lock);
+ ohci_rh_resume(ohci);
+ ohci_rh_suspend(ohci, 0);
+ spin_unlock_irq(ohci-lock);
+ }
+
+ /* Normally just turn on port power and enable interrupts */
+ else {
+ ohci_dbg(ohci, powerup ports\n);
+ for (port = 0; port ohci-num_ports; port++)
+ ohci_writel(ohci, RH_PS_PPS,
+ ohci-regs-roothub.portstatus[port]);
+
+ ohci_writel(ohci, OHCI_INTR_MIE, ohci-regs-intrenable);
+ ohci_readl(ohci, ohci-regs-intrenable);
+ msleep(20);
+ }
+
+ usb_hcd_resume_root_hub(hcd);
- ohci_finish_controller_resume(hcd);
return 0;
}
diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
index 2f3619e..db09dae 100644
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -316,48 +316,6 @@ static int ohci_bus_resume (struct usb_hcd *hcd)
return rc;
}
-/* Carry out the final steps of resuming the controller device */
-static void __maybe_unused
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Kevin, On Thu, 04 Oct 2012 16:06:27 -0700, Kevin Hilman wrote: It seems they are exactly the same, unless my eyes missed something, of course. The example I gave was only for the UART3 RX, you should dump the UART3 TX pins as. Using the omap_mux debugfs, you can see all of the potential pins where uart3_tx can be routed: Well, UART3 TX seems to be working fine. Do RX and TX have mutual influence in terms of pin muxing? Yes, that tells me where UART3 is expected to be mux'd on the board. So you can ignore the dss_data* and husb_data* files above and focus on uart3* So to summarize, in /sys/kernel/debug/omap_mux, just do a 'cat uart3*' on a working and non-working board and see if there are any differences. 3.2 (working) name: uart3_cts_rctx.uart3_cts_rctx (0x4800219a/0x16a = 0x0108), b h18, t NA mode: OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0 signals: uart3_cts_rctx | NA | NA | NA | gpio_163 | NA | NA | safe_mode name: uart3_rts_sd.uart3_rts_sd (0x4800219c/0x16c = 0x), b h19, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_rts_sd | NA | NA | NA | gpio_164 | NA | NA | safe_mode name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode name: uart3_tx_irtx.uart3_tx_irtx (0x480021a0/0x170 = 0x), b h21, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_tx_irtx | NA | NA | NA | gpio_166 | NA | NA | safe_mode 3.6 (not working) name: uart3_cts_rctx.uart3_cts_rctx (0x4800219a/0x16a = 0x0108), b h18, t NA mode: OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0 signals: uart3_cts_rctx | NA | NA | NA | gpio_163 | NA | NA | safe_mode name: uart3_rts_sd.uart3_rts_sd (0x4800219c/0x16c = 0x), b h19, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_rts_sd | NA | NA | NA | gpio_164 | NA | NA | safe_mode name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode name: uart3_tx_irtx.uart3_tx_irtx (0x480021a0/0x170 = 0x), b h21, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_tx_irtx | NA | NA | NA | gpio_166 | NA | NA | safe_mode Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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 0/2] ARM: OMAP: SmartReflex: pass device dependent data via platform data
On Fri, Oct 5, 2012 at 1:40 AM, Kevin Hilman khil...@deeprootsystems.com wrote: jean.pi...@newoldbits.com writes: From: Jean Pihet j-pi...@ti.com Remove the device dependent code (ex. cpu_is_xxx()) and settings from the driver code and instead pass them via the platform data. This allows a clean separation of the driver code and the platform code, as required by the move of the platform header files to include/linux/platform_data. Note about the smartreflex functional clocks: the smartreflex fclks are derived from sys_clk and have the same name as the main_clk from the hwmod entry, in order for the SmartReflex driver to request the fclk (using clk_get(dev, fck)). Based on mainline 3.6.0. Boot tested on OMAP34 platforms. Thanks, queuing this version for v3.8 (branch: for_3.8/pm/sr) Thanks! Jean Kevin P.S. in the future, It helps reviewers and maintainers if there's some versioning in the patches (e.g. PATCH v3 0/2]), especially when updated versions come in quick succession. Thanks. -- 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: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
On Fri, 5 Oct 2012 09:32:07 +0200, Javier Martinez Canillas wrote: As Enric said, u-boot has SPL and NAND support for IGEP since v2012.10-rc1. I just tried kernel a 3.6 with u-boot v2012.10-rc2 and it works for me. Ok, I'll try this out. But I agree that the kernel shouldn't do any assumptions about the bootloader setting correctly the omap mux. Could you please share your bootloader that makes the kernel to fail (or your IGEP NAND patches on top of u-boot U-boot 2011.12) so I can reproduce the issue and try to fix it? Ok, I'm using the X-Loader from git://git.igep.es/pub/scm/x-loader.git, tag v1.4.4-3, on top of which I apply http://git.free-electrons.com/training-materials/plain/lab-data/sysdev/u-boot/x-loader-1.4.4-3-igep-nand-support.patch to add support for the NAND-based IGEPv2 rev6. In terms of U-Boot, I use U-Boot 2011.12, on top of which I apply http://git.free-electrons.com/training-materials/plain/lab-data/sysdev/u-boot/u-boot-2011.12-igep-nand-support.patch to add support for the NAND-based IGEPv2 rev6. To make things easier if you don't need to rebuild those, I've put online pre-built binaries of X-Loader and U-Boot I'm using: http://free-electrons.com/~thomas/pub/igep-serial-problem/. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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 4/4] mtd: nand: omap2: Add data correction support
On Thu, Oct 04, 2012 at 15:51:03, Philip, Avinash wrote:
On Thu, Oct 04, 2012 at 00:50:45, Ivan Djelic wrote:
On Wed, Oct 03, 2012 at 03:29:49PM +0100, Philip, Avinash wrote:
ELM module can be used for error correction of BCH 4 8 bit. Also
support read write page in one shot by adding custom read_page
write_page methods. This helps in optimizing code.
New structure member is_elm_used is added to know the status of
whether the ELM module is used for error correction or not.
Note:
ECC layout of BCH8 uses 14 bytes for 512 byte of data to make compatible
with RBL ECC layout, even though the requirement was only 13 byte. This
results a common ecc layout across RBL, U-boot Linux.
See a few comments below,
(...)
+static int omap_elm_correct_data(struct mtd_info *mtd, u_char *dat,
+ u_char *read_ecc, u_char *calc_ecc)
+{
+ struct omap_nand_info *info = container_of(mtd, struct
omap_nand_info,
+ mtd);
+ int eccsteps = info-nand.ecc.steps;
+ int i , j, stat = 0;
+ int eccsize, eccflag, size;
+ struct elm_errorvec err_vec[ERROR_VECTOR_MAX];
+ u_char *ecc_vec = calc_ecc;
+ enum bch_ecc type;
+ bool is_error_reported = false;
+
+ /* initialize elm error vector to zero */
+ memset(err_vec, 0, sizeof(err_vec));
+ if (info-nand.ecc.strength == BCH8_MAX_ERROR) {
+ size = BCH8_SIZE;
+ eccsize = BCH8_ECC_OOB_BYTES;
+ type = BCH8_ECC;
+ } else {
+ size = BCH4_SIZE;
+ eccsize = BCH4_SIZE;
+ type = BCH4_ECC;
+ }
+
+ for (i = 0; i eccsteps ; i++) {
+ eccflag = 0;/* initialize eccflag */
+
+ for (j = 0; (j eccsize); j++) {
+ if (read_ecc[j] != 0xFF) {
+ eccflag = 1;/* data area is flashed */
Just a reminder: this way of checking if a page has been programmed is not
robust to bitflips,
so you may get into trouble with UBIFS on a fairly recent device.
Sorry I missed this point.
Here we were checking data in spare area (only in ecc layout 14*4 for BCH8) is
0xFF. If all data
in spare area is 0xFF, conclude that the page is erased no need of error
correction. In case
of bit flip present in spare area, page will be reported as uncorrectable.
But I am not understand understand trouble with UBIFS on a fairly recent
device.
Can you little elaborativ
Thanks
Avinash
--
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 02/16] ARM: OMAP: Split plat-omap/i2c.c into mach-omap1 and mach-omap2
On Friday 05 October 2012 03:34 AM, Tony Lindgren wrote:
There's no need to keep the device related things in the
common i2c.c as omap2+ is using hwmod. Split the code to
mach-omap1 and mach-omap2 parts and only leave common
code to plat-omap/i2c.c.
Note that as omap1 only has one i2c controller, we can
now remove the old device related macros.
Reviewed-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/common.h |3 +
arch/arm/mach-omap1/i2c.c | 59 +++
arch/arm/mach-omap2/board-rm680.c |1
arch/arm/mach-omap2/common.h |4 +
arch/arm/mach-omap2/i2c.c | 72 +
arch/arm/mach-omap2/i2c.h | 25 +
arch/arm/mach-omap2/omap_hwmod_2420_data.c |4 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c |4 +
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |4 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 -
arch/arm/mach-omap2/twl-common.c |1
arch/arm/plat-omap/i2c.c | 152
+---
arch/arm/plat-omap/i2c.h | 46
arch/arm/plat-omap/include/plat/common.h |1
15 files changed, 202 insertions(+), 181 deletions(-)
rename arch/arm/{plat-omap/include/plat/i2c.h = mach-omap2/i2c.h} (66%)
create mode 100644 arch/arm/plat-omap/i2c.h
diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
index c2552b2..306b7ac 100644
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -28,6 +28,9 @@
#include plat/common.h
#include linux/mtd/mtd.h
+#include linux/i2c-omap.h
+
+#include ../plat-omap/i2c.h
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
void omap7xx_map_io(void);
diff --git a/arch/arm/mach-omap1/i2c.c b/arch/arm/mach-omap1/i2c.c
index a0551a6..a6f465a 100644
--- a/arch/arm/mach-omap1/i2c.c
+++ b/arch/arm/mach-omap1/i2c.c
@@ -19,11 +19,25 @@
*
*/
-#include plat/i2c.h
+#include linux/i2c-omap.h
#include mach/mux.h
#include plat/cpu.h
-void __init omap1_i2c_mux_pins(int bus_id)
+#include ../plat-omap/i2c.h
+
+#define OMAP_I2C_SIZE0x3f
+#define OMAP1_I2C_BASE 0xfffb3800
+#define OMAP1_INT_I2C(32 + 4)
+
+static const char name[] = omap_i2c;
+
+static struct resource i2c_resources[2] = {
+};
+
+static struct platform_device omap_i2c_devices[1] = {
+};
+
+static void __init omap1_i2c_mux_pins(int bus_id)
{
if (cpu_is_omap7xx()) {
omap_cfg_reg(I2C_7XX_SDA);
@@ -33,3 +47,44 @@ void __init omap1_i2c_mux_pins(int bus_id)
omap_cfg_reg(I2C_SCL);
}
}
+
+int __init omap_i2c_add_bus(struct omap_i2c_bus_platform_data *pdata,
+ int bus_id)
+{
+ struct platform_device *pdev;
+ struct resource *res;
+
+ omap1_i2c_mux_pins(bus_id);
+
+ pdev = omap_i2c_devices[bus_id - 1];
+ pdev-id = bus_id;
+ pdev-name = name;
+ pdev-num_resources = ARRAY_SIZE(i2c_resources);
+ res = i2c_resources;
+ res[0].start = OMAP1_I2C_BASE;
+ res[0].end = res[0].start + OMAP_I2C_SIZE;
+ res[0].flags = IORESOURCE_MEM;
+ res[1].start = OMAP1_INT_I2C;
+ res[1].flags = IORESOURCE_IRQ;
+ pdev-resource = res;
+
+ /* all OMAP1 have IP version 1 register set */
+ pdata-rev = OMAP_I2C_IP_VERSION_1;
+
+ /* all OMAP1 I2C are implemented like this */
+ pdata-flags = OMAP_I2C_FLAG_NO_FIFO |
+OMAP_I2C_FLAG_SIMPLE_CLOCK |
+OMAP_I2C_FLAG_16BIT_DATA_REG |
+OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK;
+
+ /* how the cpu bus is wired up differs for 7xx only */
+
+ if (cpu_is_omap7xx())
+ pdata-flags |= OMAP_I2C_FLAG_BUS_SHIFT_1;
+ else
+ pdata-flags |= OMAP_I2C_FLAG_BUS_SHIFT_2;
+
+ pdev-dev.platform_data = pdata;
+
+ return platform_device_register(pdev);
+}
diff --git a/arch/arm/mach-omap2/board-rm680.c
b/arch/arm/mach-omap2/board-rm680.c
index 45997bf..a57ed21 100644
--- a/arch/arm/mach-omap2/board-rm680.c
+++ b/arch/arm/mach-omap2/board-rm680.c
@@ -22,7 +22,6 @@
#include asm/mach/arch.h
#include asm/mach-types.h
-#include plat/i2c.h
#include plat/mmc.h
#include plat/usb.h
#include plat/gpmc.h
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 7045e4d..a68b421 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -28,7 +28,9 @@
#include linux/irq.h
#include linux/delay.h
+#include linux/i2c.h
#include linux/i2c/twl.h
+#include linux/i2c-omap.h
#include asm/proc-fns.h
@@ -36,6 +38,8 @@
#include plat/serial.h
#include plat/common.h
+#include i2c.h
+
#define OMAP_INTC_START
[PATCH] i2c: i2c-omap: fix interrupt flood during resume
The resume_noirq enables interrupts one-by-one starting from
first one. Now if the wake up event for suspend came from i2c
device, the i2c bus irq gets enabled before the threaded
i2c device irq, causing a flood of i2c bus interrupts as the
threaded irq that should clear the event is not enabled yet.
Fixed the issue by adding suspend_late and resume_early
functions that keep i2c bus interrupts disabled until
resume_noirq has run completely.
Issue was detected doing a wake up from autosleep with
twl4030 power key on N9. Patch tested on N9.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com
---
drivers/i2c/busses/i2c-omap.c | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..b77b0c2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1158,6 +1158,35 @@ omap_i2c_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_SUSPEND
+static int omap_i2c_suspend_late(struct device *dev)
+{
+
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+
+ /*
+* The noirq_resume enables the interrupts one by one,
+* this causes a interrupt flood if the SW irq actually reading
+* event from i2c device is enabled only after i2c bus irq, as the
+* irq that should clear the event is still disabled. We have to
+* disable the bus irq until all other irqs have been enabled.
+*/
+ disable_irq(_dev-irq);
+ return 0;
+}
+
+static int omap_i2c_resume_early(struct device *dev)
+{
+
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+
+ enable_irq(_dev-irq);
+
+ return 0;
+}
+#endif
#ifdef CONFIG_PM_RUNTIME
static int omap_i2c_runtime_suspend(struct device *dev)
{
@@ -1178,10 +1207,18 @@ static int omap_i2c_runtime_resume(struct device *dev)
return 0;
}
+#endif
+#if defined(CONFIG_SUSPEND) || defined(CONFIG_PM_RUNTIME)
static struct dev_pm_ops omap_i2c_pm_ops = {
+#ifdef CONFIG_SUSPEND
+ .suspend_late = omap_i2c_suspend_late,
+ .resume_early = omap_i2c_resume_early,
+#endif
+#ifdef CONFIG_PM_RUNTIME
.runtime_suspend = omap_i2c_runtime_suspend,
.runtime_resume = omap_i2c_runtime_resume,
+#endif
};
#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
#else
--
1.7.4.1
--
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] gpio/gpio-omap: Use existing pointer to struct device
A pointer to pdev-dev is already stored in dev, so use it in
devm_kzalloc.
Signed-off-by: Tobias Klauser tklau...@distanz.ch
---
drivers/gpio/gpio-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..eb73dee 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1070,7 +1070,7 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
if (!pdata)
return -EINVAL;
- bank = devm_kzalloc(pdev-dev, sizeof(struct gpio_bank), GFP_KERNEL);
+ bank = devm_kzalloc(dev, sizeof(struct gpio_bank), GFP_KERNEL);
if (!bank) {
dev_err(dev, Memory alloc failed\n);
return -ENOMEM;
--
1.7.5.4
--
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: OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
Hi,
On Friday 31 August 2012 01:58 PM, Archit Taneja wrote:
On Friday 31 August 2012 01:57 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote:
On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
The only little problem was that during bootup, when hwmods are setup,
only the 'parent' hwmod was able to get reset properly, all the other
'child' hwmods don't have modulemode bits tied to them, and hence
weren't able to reset. So we got some error prints.
Once DSS driver kicks in, the driver ensures the parent is enabled for
any child to be enabled, so we don't face the issue again.
So, if DSS driver is not built in, and if the bootloader left DSS in a
bad state, the DSS clocks might remain messed up all the time since
hwmod fwk wasn't able to reset them.
I think this is why we didn't proceed with remove dss_fck as a slave
clock. If this issue is minor, we could go ahead and remove it.
I wonder if we could handle this with a custom reset function. We
already have a reset func for dss core. If I remember right, the main
point for that is the fact that omap4 doesn't have a softreset for dss
core, so we manually write the default values to registers.
For omap2/3 this would be simple: skip the resets for all other dss
submodules, and dss core's reset would enable all the clocks and set
the
softreset bit. This would reset all the submodules also.
Omap4 is more tricky. I guess we'd need to enable all the clocks, clear
manually dss core's registers, and then set softreset bits in all the
submodules. So in this case dss core would need to have information
about the other submodules.
The is a good idea. I don't clearly understand your approach though. Are
you saying we have a custom reset function for only dss core? And reset
the submodules in it manually?
Yes.
An alternative approach would be to implement custom reset functions for
each submodule(or each hwmod), and in the beginning of every reset
function, add a hack to enable MODULEMODE bits(since we don't want hwmod
fwk to touch MODULEMODE for the DSS submodules), and then set the soft
reset bits.
I thought about that also. We'd need reset functions for all of them,
and for omap2/3 we'd just reset the submodules again as they have
already been reset with the dss core reset.
The dss submodule resets are a bit linked. For omap2/3 the connection is
obvious as dss core reset resets also the submodules, and for omap4 we
have this requirement for the modulemode. That's why I though it'd be
perhaps cleaner to handle the reset of the DSS block as a whole, in one
place.
Your approach would ensure that we get a clean reset of DSS, but it
would still give the annoying prints when each of the submodule tries to
reset itself.
The other submodules would not be reset by the hwmod framework at all,
so there wouldn't be prints. I think there's a flag for that.
Sorry for bringing up an old thread. I was working on cleaning up the
OMAP4 DSS related clock/pm issues, hence brought it up.
We were discussing here on how to setting up and reset the OMAP4 DSS
submodules correctly without tying the MODULEMODE bits to the
corresponding hwmods.
Tomi, your suggestion was to do soft resets for the submodules manually
in the dss_core hwmod's custom reset function itself, and use the flag
HWMOD_INIT_NO_RESET to prevent _reset() being called.
However, this won't still resolve the issue of the errors we see a
bootup. The function _setup_reset() looks like this:
static int _setup_reset(struct omap_hwmod *oh)
{
...
r = _enable(oh);
if (r) {
pr_warning(omap_hwmod: %s: cannot be enabled for
reset (%d)\n, oh-name, oh-_state);
return -EINVAL;
}
...
if (!(oh-flags HWMOD_INIT_NO_RESET))
r = _reset(oh);
...
}
So, even if we have ask hwmod not to reset the DSS submodules, it will
still try to enable them, and we can't enable them since MODULEMODE
isn't tied to them. I don't see how we can get a clean reset done for
the DSS submodules without making some changes in hwmod framework.
Archit
--
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: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
On Fri, Oct 5, 2012 at 10:10 AM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: On Fri, 5 Oct 2012 09:32:07 +0200, Javier Martinez Canillas wrote: As Enric said, u-boot has SPL and NAND support for IGEP since v2012.10-rc1. I just tried kernel a 3.6 with u-boot v2012.10-rc2 and it works for me. Ok, I'll try this out. But I agree that the kernel shouldn't do any assumptions about the bootloader setting correctly the omap mux. Could you please share your bootloader that makes the kernel to fail (or your IGEP NAND patches on top of u-boot U-boot 2011.12) so I can reproduce the issue and try to fix it? Ok, I'm using the X-Loader from git://git.igep.es/pub/scm/x-loader.git, tag v1.4.4-3, on top of which I apply http://git.free-electrons.com/training-materials/plain/lab-data/sysdev/u-boot/x-loader-1.4.4-3-igep-nand-support.patch to add support for the NAND-based IGEPv2 rev6. In terms of U-Boot, I use U-Boot 2011.12, on top of which I apply http://git.free-electrons.com/training-materials/plain/lab-data/sysdev/u-boot/u-boot-2011.12-igep-nand-support.patch to add support for the NAND-based IGEPv2 rev6. To make things easier if you don't need to rebuild those, I've put online pre-built binaries of X-Loader and U-Boot I'm using: http://free-electrons.com/~thomas/pub/igep-serial-problem/. Thanks, Thomas Perfect, I'll try it and let you know if I find a fix for the issue. Thanks a lot! Javier -- 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/3] ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
is assigned a device attribute to represent the attached devices.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..cf579b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -21,6 +21,7 @@
#include linux/io.h
#include linux/platform_data/gpio-omap.h
#include linux/power/smartreflex.h
+#include linux/platform_data/omap_ocp2scp.h
#include plat/omap_hwmod.h
#include plat/i2c.h
@@ -2681,6 +2682,32 @@ static struct omap_hwmod_class
omap44xx_ocp2scp_hwmod_class = {
.sysc = omap44xx_ocp2scp_sysc,
};
+/* ocp2scp dev_attr */
+static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
+ {
+ .name = usb_phy,
+ .start = 0x4a0ad080,
+ .end= 0x4a0ae000,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ /* XXX: Remove this once control module driver is in place */
+ .name = ctrl_dev,
+ .start = 0x4a002300,
+ .end= 0x4a002303,
+ .flags = IORESOURCE_MEM,
+ },
+ { }
+};
+
+static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
+ {
+ .drv_name = omap-usb2,
+ .res= omap44xx_usb_phy_and_pll_addrs,
+ },
+ { }
+};
+
/* ocp2scp_usb_phy */
static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
.name = ocp2scp_usb_phy,
@@ -2694,6 +2721,7 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod =
{
.modulemode = MODULEMODE_HWCTRL,
},
},
+ .dev_attr = ocp2scp_dev_attr,
};
/*
--
1.7.9.5
--
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 0/3] ocp2scp: add non-dt support
This patch series allows ocp2scp driver to create its child devices from the platform data. In omap platforms, usb phy is connected to ocp2scp and usb phy is needed for MUSB to be functional. When ocp2scp driver was added, it had only dt support which means it wont create usb phy devices for non-dt boot. This patch series adds non-dt support to ocp2scp and this series is needed for getting MUSB functioanl in non-dt boot. This patch series is rebased on linux-next. Let me know if it had to be based on some other tree. Did a quick testing for g_zero enumeration in panda board. Kishon Vijay Abraham I (3): drivers: bus: ocp2scp: add pdata support ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy ARM: OMAP: ocp2scp: create omap device for ocp2scp arch/arm/mach-omap2/devices.c | 72 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28 +++ drivers/bus/omap-ocp2scp.c | 67 -- include/linux/platform_data/omap_ocp2scp.h | 31 4 files changed, 195 insertions(+), 3 deletions(-) create mode 100644 include/linux/platform_data/omap_ocp2scp.h -- 1.7.9.5 -- 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/3] drivers: bus: ocp2scp: add pdata support
ocp2scp was not having pdata support which makes *musb* fail for non-dt
boot in OMAP platform. The pdata will have information about the devices
that is connected to ocp2scp. ocp2scp driver will now make use of this
information to create the devices that is attached to ocp2scp.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/bus/omap-ocp2scp.c | 67 ++--
include/linux/platform_data/omap_ocp2scp.h | 31 +
2 files changed, 95 insertions(+), 3 deletions(-)
create mode 100644 include/linux/platform_data/omap_ocp2scp.h
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
index ff63560..5db8297 100644
--- a/drivers/bus/omap-ocp2scp.c
+++ b/drivers/bus/omap-ocp2scp.c
@@ -22,6 +22,26 @@
#include linux/pm_runtime.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/platform_data/omap_ocp2scp.h
+
+/**
+ * _count_resources - count for the number of resources
+ * @res: struct resource *
+ *
+ * Count and return the number of resources populated for the device that is
+ * connected to ocp2scp.
+ */
+static unsigned _count_resources(struct resource *res)
+{
+ int cnt = 0;
+
+ while (res-start != res-end) {
+ cnt++;
+ res++;
+ }
+
+ return cnt;
+}
static int ocp2scp_remove_devices(struct device *dev, void *c)
{
@@ -34,20 +54,61 @@ static int ocp2scp_remove_devices(struct device *dev, void
*c)
static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
{
- int ret;
- struct device_node *np = pdev-dev.of_node;
+ int ret;
+ unsigned res_cnt, i;
+ struct device_node *np = pdev-dev.of_node;
+ struct platform_device *pdev_child;
+ struct omap_ocp2scp_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_ocp2scp_dev *dev;
if (np) {
ret = of_platform_populate(np, NULL, NULL, pdev-dev);
if (ret) {
- dev_err(pdev-dev, failed to add resources for
ocp2scp child\n);
+ dev_err(pdev-dev,
+ failed to add resources for ocp2scp child\n);
goto err0;
}
+ } else if (pdata) {
+ for (i = 0, dev = *pdata-devices; i pdata-dev_cnt; i++,
+ dev++) {
+ res_cnt = _count_resources(dev-res);
+
+ pdev_child = platform_device_alloc(dev-drv_name, -1);
+ if (!pdev_child) {
+ dev_err(pdev-dev,
+ failed to allocate mem for ocp2scp child\n);
+ goto err0;
+ }
+
+ ret = platform_device_add_resources(pdev_child,
+ dev-res, res_cnt);
+ if (ret) {
+ dev_err(pdev-dev,
+failed to add resources for ocp2scp child\n);
+ goto err1;
+ }
+
+ pdev_child-dev.parent = pdev-dev;
+
+ ret = platform_device_add(pdev_child);
+ if (ret) {
+ dev_err(pdev-dev,
+ failed to register ocp2scp child device\n);
+ goto err1;
+ }
+ }
+ } else {
+ dev_err(pdev-dev, OCP2SCP initialized without plat data\n);
+ return -EINVAL;
}
+
pm_runtime_enable(pdev-dev);
return 0;
+err1:
+ platform_device_put(pdev_child);
+
err0:
device_for_each_child(pdev-dev, NULL, ocp2scp_remove_devices);
diff --git a/include/linux/platform_data/omap_ocp2scp.h
b/include/linux/platform_data/omap_ocp2scp.h
new file mode 100644
index 000..5c6c393
--- /dev/null
+++ b/include/linux/platform_data/omap_ocp2scp.h
@@ -0,0 +1,31 @@
+/*
+ * omap_ocp2scp.h -- ocp2scp header file
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * 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.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __DRIVERS_OMAP_OCP2SCP_H
+#define __DRIVERS_OMAP_OCP2SCP_H
+
+struct omap_ocp2scp_dev {
+ const char *drv_name;
+ struct resource *res;
+};
+
+struct omap_ocp2scp_platform_data {
+
[PATCH 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp
Platfrom device for ocp2scp is created using omap_device_build in
devices file. This is used for both omap4(musb) and omap5(dwc3).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/devices.c | 72 +
1 file changed, 72 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..e2ba505 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -19,6 +19,7 @@
#include linux/of.h
#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
+#include linux/platform_data/omap_ocp2scp.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -613,6 +614,76 @@ static void omap_init_vout(void)
static inline void omap_init_vout(void) {}
#endif
+#if defined(CONFIG_OMAP_OCP2SCP) || defined(CONFIG_OMAP_OCP2SCP_MODULE)
+static int count_ocp2scp_devices(struct omap_ocp2scp_dev *ocp2scp_dev)
+{
+ int cnt = 0;
+
+ while (ocp2scp_dev-drv_name != NULL) {
+ cnt++;
+ ocp2scp_dev++;
+ }
+
+ return cnt;
+}
+
+static void omap_init_ocp2scp(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ int bus_id = -1, dev_cnt = 0, i;
+ struct omap_ocp2scp_dev *ocp2scp_dev;
+ const char *oh_name, *name;
+ struct omap_ocp2scp_platform_data *pdata;
+
+ oh_name = ocp2scp_usb_phy;
+ name= omap-ocp2scp;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(%s: could not find omap_hwmod for %s\n, __func__,
+ oh_name);
+ return;
+ }
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ pr_err(%s: No memory for ocp2scp pdata\n, __func__);
+ return;
+ }
+
+ ocp2scp_dev = oh-dev_attr;
+ dev_cnt = count_ocp2scp_devices(ocp2scp_dev);
+
+ if (!dev_cnt) {
+ pr_err(%s: No devices connected to ocp2scp\n, __func__);
+ return;
+ }
+
+ pdata-devices = kzalloc(sizeof(struct omap_ocp2scp_dev *)
+ * dev_cnt, GFP_KERNEL);
+ if (!pdata-devices) {
+ pr_err(%s: No memory for ocp2scp pdata devices\n, __func__);
+ return;
+ }
+
+ for (i = 0; i dev_cnt; i++, ocp2scp_dev++)
+ pdata-devices[i] = ocp2scp_dev;
+
+ pdata-dev_cnt = dev_cnt;
+
+ pdev = omap_device_build(name, bus_id, oh, pdata, sizeof(*pdata), NULL,
+ 0, false);
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build omap_device for %s %s\n,
+ name, oh_name);
+ return;
+ }
+}
+#else
+static inline void omap_init_ocp2scp(void) { }
+#endif
+
/*-*/
static int __init omap2_init_devices(void)
@@ -640,6 +711,7 @@ static int __init omap2_init_devices(void)
omap_init_sham();
omap_init_aes();
omap_init_vout();
+ omap_init_ocp2scp();
return 0;
}
--
1.7.9.5
--
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: omap DSS cmdline resolution not working for HDMI?
On Thu, 2012-10-04 at 10:56 -0700, Tony Lindgren wrote: Hi, FYI, looks like for some reason DSS command line is not working for HDMI while it works for DSS. On my panda es I'm trying to set my motorola lapdock resolution from cmdline with: omapdss.def_disp=hdmi omapfb.mode=hdmi:1366x768@60 But it does not seem to do anything and resolution is VGA. If I change the cable to DVI port this works: omapdss.def_disp=dvi omapfb.mode=dvi:1366x768@60 Any ideas? This is with current linux next. That's because our HDMI only supports certain timings. To be honest, I don't really understand this restriction, as I believe the hardware should be able to use more or less any timings just like DVI. The 1366x768@60 mode is parsed with fbdev functions, which returns a video timings. These timings are then given to the HDMI driver, which tries to find matching timings from its timing table. And when it doesn't find a match, it fails. This is a known problem, and the hdmi driver would really need some love in other aspects also. I'm not sure what would be the best way to improve this without doing major rewrites. Perhaps the check in the hdmi driver could be more relaxed, but that needs some careful thought. I can change the HDMI resolution OK from userspace with: echo 1 /sys/devices/platform/omapdss/display1/enabled echo 0 /sys/devices/platform/omapdss/overlay0/enabled echo tv /sys/devices/platform/omapdss/overlay0/manager echo 1 /sys/devices/platform/omapdss/overlay0/enabled echo 85500,1366/70/213/143,768/3/24/3 /sys/devices/platform/omapdss/display1/timings That's because the above line has timings that are in the hdmi driver's table. They are somewhat different than what fbdev gives for 1366x768@60. The reason to use HDMI instead of DVI here is that HDMI also has the speakers on the lapdock ;) Then I'm able to switch between HDMI panel and DVI panel just fine using overlay0. I don't know if getting both HDMI and DVI to work the same time using overlay1 is supposed to work, but trying use overlay1 produces the following: HDMI and DVI cannot be used reliably at the same time, due to a HW issue we've had unresolved for a long time. Luckily, it was solved this week and we'll have a patch for next merge window to get this working. echo 1 /sys/devices/platform/omapdss/display0/enabled echo 0 /sys/devices/platform/omapdss/overlay1/enabled echo lcd2 /sys/devices/platform/omapdss/overlay1/manager echo 1 /sys/devices/platform/omapdss/overlay1/enabled echo 170666,1920/336/128/208,1200/38/1/3 /sys/devices/platform/omapdss/display0/timings [ 816.446044] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz [ 881.639221] omapdss APPLY: timeout in wait_pending_extra_info_updates [ 958.946594] [ cut here ] [ 958.953277] WARNING: at drivers/bus/omap_l3_noc.c:97 l3_interrupt_handler+0xc0/0x184() [ 958.965576] L3 standard error: TARGET:DMM2 at address 0x0 ... Having said the above, I don't quite know where this error comes from... Tiler (DMM) is not even used by omapfb. Tomi signature.asc Description: This is a digitally signed message part
Re: OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
Hi Archit,
On 10/05/2012 11:46 AM, Archit Taneja wrote:
Hi,
On Friday 31 August 2012 01:58 PM, Archit Taneja wrote:
On Friday 31 August 2012 01:57 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote:
On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
The only little problem was that during bootup, when hwmods are
setup,
only the 'parent' hwmod was able to get reset properly, all the other
'child' hwmods don't have modulemode bits tied to them, and hence
weren't able to reset. So we got some error prints.
Once DSS driver kicks in, the driver ensures the parent is enabled
for
any child to be enabled, so we don't face the issue again.
So, if DSS driver is not built in, and if the bootloader left DSS
in a
bad state, the DSS clocks might remain messed up all the time since
hwmod fwk wasn't able to reset them.
I think this is why we didn't proceed with remove dss_fck as a
slave
clock. If this issue is minor, we could go ahead and remove it.
I wonder if we could handle this with a custom reset function. We
already have a reset func for dss core. If I remember right, the main
point for that is the fact that omap 4 doesn't have a softreset for dss
core, so we manually write the default values to registers.
For omap2/3 this would be simple: skip the resets for all other dss
submodules, and dss core's reset would enable all the clocks and set
the
softreset bit. This would reset all the submodules also.
Omap4 is more tricky. I guess we'd need to enable all the clocks,
clear
manually dss core's registers, and then set softreset bits in all the
submodules. So in this case dss core would need to have information
about the other submodules.
The is a good idea. I don't clearly understand your approach though.
Are
you saying we have a custom reset function for only dss core? And reset
the submodules in it manually?
Yes.
An alternative approach would be to implement custom reset functions
for
each submodule(or each hwmod), and in the beginning of every reset
function, add a hack to enable MODULEMODE bits(since we don't want
hwmod
fwk to touch MODULEMODE for the DSS submodules), and then set the soft
reset bits.
I thought about that also. We'd need reset functions for all of them,
and for omap2/3 we'd just reset the submodules again as they have
already been reset with the dss core reset.
The dss submodule resets are a bit linked. For omap2/3 the connection is
obvious as dss core reset resets also the submodules, and for omap4 we
have this requirement for the modulemode. That's why I though it'd be
perhaps cleaner to handle the reset of the DSS block as a whole, in one
place.
Your approach would ensure that we get a clean reset of DSS, but it
would still give the annoying prints when each of the submodule
tries to
reset itself.
The other submodules would not be reset by the hwmod framework at all,
so there wouldn't be prints. I think there's a flag for that.
Sorry for bringing up an old thread. I was working on cleaning up the
OMAP4 DSS related clock/pm issues, hence brought it up.
We were discussing here on how to setting up and reset the OMAP4 DSS
submodules correctly without tying the MODULEMODE bits to the
corresponding hwmods.
Tomi, your suggestion was to do soft resets for the submodules manually
in the dss_core hwmod's custom reset function itself, and use the flag
HWMOD_INIT_NO_RESET to prevent _reset() being called.
Yep, that's the right approach.
However, this won't still resolve the issue of the errors we see a
bootup. The function _setup_reset() looks like this:
static int _setup_reset(struct omap_hwmod *oh)
{
...
r = _enable(oh);
if (r) {
pr_warning(omap_hwmod: %s: cannot be enabled for
reset (%d)\n, oh-name, oh-_state);
return -EINVAL;
}
...
if (!(oh-flags HWMOD_INIT_NO_RESET))
r = _reset(oh);
...
}
So, even if we have ask hwmod not to reset the DSS submodules, it will
still try to enable them, and we can't enable them since MODULEMODE
isn't tied to them. I don't see how we can get a clean reset done for
the DSS submodules without making some changes in hwmod framework.
Yeah, I do agree. Some module cannot but enabled automatically in the fmwk due
to PM dependency.
This is the case as well for MCPDM, IPU, DSP, ISS, FDIF...
In that case the early setup should just be skipped and the DSS driver should
take care of that during probe / pm_runtime_enable.
I already have a WIP series that delay the setup until the driver probe the
device. It will allow the setup to work properly in the case of the DSS
assuming the DISPC and other sub IPs are setup in the context of DSS probe. At
that time the DSS will be enabled already and thus every sub IPs will be able
to get enabled.
It is done in the context of
Re: OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
On Friday 05 October 2012 05:50 PM, Benoit Cousson wrote:
Hi Archit,
On 10/05/2012 11:46 AM, Archit Taneja wrote:
Hi,
On Friday 31 August 2012 01:58 PM, Archit Taneja wrote:
On Friday 31 August 2012 01:57 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote:
On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
The only little problem was that during bootup, when hwmods are
setup,
only the 'parent' hwmod was able to get reset properly, all the other
'child' hwmods don't have modulemode bits tied to them, and hence
weren't able to reset. So we got some error prints.
Once DSS driver kicks in, the driver ensures the parent is enabled
for
any child to be enabled, so we don't face the issue again.
So, if DSS driver is not built in, and if the bootloader left DSS
in a
bad state, the DSS clocks might remain messed up all the time since
hwmod fwk wasn't able to reset them.
I think this is why we didn't proceed with remove dss_fck as a
slave
clock. If this issue is minor, we could go ahead and remove it.
I wonder if we could handle this with a custom reset function. We
already have a reset func for dss core. If I remember right, the main
point for that is the fact that omap 4 doesn't have a softreset for dss
core, so we manually write the default values to registers.
For omap2/3 this would be simple: skip the resets for all other dss
submodules, and dss core's reset would enable all the clocks and set
the
softreset bit. This would reset all the submodules also.
Omap4 is more tricky. I guess we'd need to enable all the clocks,
clear
manually dss core's registers, and then set softreset bits in all the
submodules. So in this case dss core would need to have information
about the other submodules.
The is a good idea. I don't clearly understand your approach though.
Are
you saying we have a custom reset function for only dss core? And reset
the submodules in it manually?
Yes.
An alternative approach would be to implement custom reset functions
for
each submodule(or each hwmod), and in the beginning of every reset
function, add a hack to enable MODULEMODE bits(since we don't want
hwmod
fwk to touch MODULEMODE for the DSS submodules), and then set the soft
reset bits.
I thought about that also. We'd need reset functions for all of them,
and for omap2/3 we'd just reset the submodules again as they have
already been reset with the dss core reset.
The dss submodule resets are a bit linked. For omap2/3 the connection is
obvious as dss core reset resets also the submodules, and for omap4 we
have this requirement for the modulemode. That's why I though it'd be
perhaps cleaner to handle the reset of the DSS block as a whole, in one
place.
Your approach would ensure that we get a clean reset of DSS, but it
would still give the annoying prints when each of the submodule
tries to
reset itself.
The other submodules would not be reset by the hwmod framework at all,
so there wouldn't be prints. I think there's a flag for that.
Sorry for bringing up an old thread. I was working on cleaning up the
OMAP4 DSS related clock/pm issues, hence brought it up.
We were discussing here on how to setting up and reset the OMAP4 DSS
submodules correctly without tying the MODULEMODE bits to the
corresponding hwmods.
Tomi, your suggestion was to do soft resets for the submodules manually
in the dss_core hwmod's custom reset function itself, and use the flag
HWMOD_INIT_NO_RESET to prevent _reset() being called.
Yep, that's the right approach.
However, this won't still resolve the issue of the errors we see a
bootup. The function _setup_reset() looks like this:
static int _setup_reset(struct omap_hwmod *oh)
{
...
r = _enable(oh);
if (r) {
pr_warning(omap_hwmod: %s: cannot be enabled for
reset (%d)\n, oh-name, oh-_state);
return -EINVAL;
}
...
if (!(oh-flags HWMOD_INIT_NO_RESET))
r = _reset(oh);
...
}
So, even if we have ask hwmod not to reset the DSS submodules, it will
still try to enable them, and we can't enable them since MODULEMODE
isn't tied to them. I don't see how we can get a clean reset done for
the DSS submodules without making some changes in hwmod framework.
Yeah, I do agree. Some module cannot but enabled automatically in the fmwk due
to PM dependency.
This is the case as well for MCPDM, IPU, DSP, ISS, FDIF...
In that case the early setup should just be skipped and the DSS driver should
take care of that during probe / pm_runtime_enable.
I already have a WIP series that delay the setup until the driver probe the
device. It will allow the setup to work properly in the case of the DSS
assuming the DISPC and other sub IPs are setup in the context of DSS probe. At
that time the DSS will be enabled already and thus every sub IPs will be able
to get enabled.
It is done in the context of DT
Re: [PATCH V4 4/5] OMAPDSS: Replace multi part debug prints with pr_debug
On Sat, 2012-09-29 at 16:19 +0530, Chandrabhanu Mahapatra wrote: The omap_dispc_unregister_isr() and _dsi_print_reset_status() consist of a number of debug prints which need to be enabled all at once or none at all. So, these debug prints in corresponding functions are replaced with one dynamic debug enabled pr_debug() each. Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com --- drivers/video/omap2/dss/dispc.c | 32 +--- drivers/video/omap2/dss/dsi.c | 30 ++ 2 files changed, 27 insertions(+), 35 deletions(-) diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index a173a94..67d9f3b 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -3675,26 +3675,20 @@ static void print_irq_status(u32 status) if ((status dispc.irq_error_mask) == 0) return; - printk(KERN_DEBUG DISPC IRQ: 0x%x: , status); - -#define PIS(x) \ - if (status DISPC_IRQ_##x) \ - printk(#x ); - PIS(GFX_FIFO_UNDERFLOW); - PIS(OCP_ERR); - PIS(VID1_FIFO_UNDERFLOW); - PIS(VID2_FIFO_UNDERFLOW); - if (dss_feat_get_num_ovls() 3) - PIS(VID3_FIFO_UNDERFLOW); - PIS(SYNC_LOST); - PIS(SYNC_LOST_DIGIT); - if (dss_has_feature(FEAT_MGR_LCD2)) - PIS(SYNC_LOST2); - if (dss_has_feature(FEAT_MGR_LCD3)) - PIS(SYNC_LOST3); +#define PIS(x) (status DISPC_IRQ_##x) ? (#x ) : + + pr_debug(DISPC IRQ: 0x%x: %s%s%s%s%s%s%s%s%s\n, + status, + PIS(OCP_ERR), + PIS(GFX_FIFO_UNDERFLOW), + PIS(VID1_FIFO_UNDERFLOW), + PIS(VID2_FIFO_UNDERFLOW), + dss_feat_get_num_ovls() 3 ? PIS(VID3_FIFO_UNDERFLOW) : , + PIS(SYNC_LOST), + PIS(SYNC_LOST_DIGIT), + dss_has_feature(FEAT_MGR_LCD2) ? PIS(SYNC_LOST2) : , + dss_has_feature(FEAT_MGR_LCD3) ? PIS(SYNC_LOST3) : ); #undef PIS - - printk(\n); } #endif There's similar irq printing code in dsi.c that should also be converted to the above style. Tomi signature.asc Description: This is a digitally signed message part
Re: OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
On Friday 05 October 2012 05:59 PM, Archit Taneja wrote: The other not so good option to make DSS PM work would be to add OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which have the hack dss_fck as slave clock). I gave this approach a try, that too isn't working so well. When I disable DSS, I get CM_DSS_DSS_CLKCTRL.IDLEST as 0x1, and CM_DSS_CLKSTCTRL.CLKACTIVITY_DSS_L3_ICLK is set. I wonder why that's happening. I have seen DSS get stuck in transition, with just a clkdm state toggle (from say HWSUP to SWWKUP) while its optional clocks are not running. Thats probably whats happening now. Did you try keeping the modulemode enabled and see if it really gates DSS/system sleep. I remember testing with Teros CORE ret/off patches and I was always seeing DSS modulemode enabled but it wasn't gating sleep. -- 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 0/5] OMAPDSS: Enable dynamic debug printing
On Sat, 2012-09-29 at 16:19 +0530, Chandrabhanu Mahapatra wrote: Hi everyone, this patch series aims at cleaning up of DSS of printk()'s enabled with dss_debug and replace them with generic dynamic debug printing. Except for the missing debug print conversions in dsi.c this looks good. Do you want me to apply the current series and you can send the dsi.c patch later, or do you want to fix the dsi.c also before I apply? Tomi signature.asc Description: This is a digitally signed message part
Re: OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
On Friday 05 October 2012 06:07 PM, Rajendra Nayak wrote: On Friday 05 October 2012 05:59 PM, Archit Taneja wrote: The other not so good option to make DSS PM work would be to add OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which have the hack dss_fck as slave clock). I gave this approach a try, that too isn't working so well. When I disable DSS, I get CM_DSS_DSS_CLKCTRL.IDLEST as 0x1, and CM_DSS_CLKSTCTRL.CLKACTIVITY_DSS_L3_ICLK is set. I wonder why that's happening. I have seen DSS get stuck in transition, with just a clkdm state toggle (from say HWSUP to SWWKUP) while its optional clocks are not running. Thats probably whats happening now. Oh ok, I can notice that too. So in the _idle() path, the clocks are disabled first, and then we try to change the clkdm state. I guess that could be the reason why DSS doesn't sleep. But then, I don't understand why this problem isn't seen if I try the alternative option of removing the fake dss_fck slave clock, and tie modulemode to only the parent hwmod. There DSS IDLEST is 0x3 when I disable DSS. I think with this approach, the problem is with _disable_clocks(), in disable_clocks, main_clk is disabled first, and then the slave clocks. That translates to DSS_FCK opt clock getting disabled first, and then MODULEMODE bits. I think DSS doesn't transition to sleep with this disable sequence. Did you try keeping the modulemode enabled and see if it really gates DSS/system sleep. I remember testing with Teros CORE ret/off patches and I was always seeing DSS modulemode enabled but it wasn't gating sleep. If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all set). Is this helpful? Can we just leave modulemode on all the time? That'll be the best :) Anyway, I guess it would be the best to have a custom _setup function(or skip them all together) for DSS as Benoit suggested. Archit -- 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: OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all set). Is this helpful? Can we just leave modulemode on all the time? That'll be the best :) Is everything around DSS enabled by default in omap2plus? If so, I haven't seen Tero (who has been working on getting OMAP4 to sleep) complain about DSS causing him any trouble. So you should be good with whats already there atleast from 'not-gating-sleep' point of view. -- 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: OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
On Friday 05 October 2012 07:01 PM, Rajendra Nayak wrote: If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all set). Is this helpful? Can we just leave modulemode on all the time? That'll be the best :) Is everything around DSS enabled by default in omap2plus? If so, I haven't seen Tero (who has been working on getting OMAP4 to sleep) complain about DSS causing him any trouble. So you should be good with whats already there atleast from 'not-gating-sleep' point of view. DSS is selected only as a module in omap2plus_defconfig, so the DSS driver would never kick in with the defconfig. The DSS hwmods would be initialised though. If I boot up linux-next with omap2plus_defconfig, I get: CM_DSS_CLKSTCTRL 0x3 CM_DSS_DSS_CLKCTRL 0x00060002 So the module is in standby, but IDLEST is 0x2, which says DSS is idle only with respect to the interconnect. In the bootloader, IDLEST was 0x3. So I don't know if that's a good thing or not. Archit -- 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: OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
On 10/05/2012 03:20 PM, Archit Taneja wrote: On Friday 05 October 2012 06:07 PM, Rajendra Nayak wrote: On Friday 05 October 2012 05:59 PM, Archit Taneja wrote: The other not so good option to make DSS PM work would be to add OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which have the hack dss_fck as slave clock). I gave this approach a try, that too isn't working so well. When I disable DSS, I get CM_DSS_DSS_CLKCTRL.IDLEST as 0x1, and CM_DSS_CLKSTCTRL.CLKACTIVITY_DSS_L3_ICLK is set. I wonder why that's happening. I have seen DSS get stuck in transition, with just a clkdm state toggle (from say HWSUP to SWWKUP) while its optional clocks are not running. Thats probably whats happening now. Oh ok, I can notice that too. So in the _idle() path, the clocks are disabled first, and then we try to change the clkdm state. I guess that could be the reason why DSS doesn't sleep. But then, I don't understand why this problem isn't seen if I try the alternative option of removing the fake dss_fck slave clock, and tie modulemode to only the parent hwmod. There DSS IDLEST is 0x3 when I disable DSS. I think with this approach, the problem is with _disable_clocks(), in disable_clocks, main_clk is disabled first, and then the slave clocks. That translates to DSS_FCK opt clock getting disabled first, and then MODULEMODE bits. I think DSS doesn't transition to sleep with this disable sequence. Did you try keeping the modulemode enabled and see if it really gates DSS/system sleep. I remember testing with Teros CORE ret/off patches and I was always seeing DSS modulemode enabled but it wasn't gating sleep. If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all set). Is this helpful? Can we just leave modulemode on all the time? That'll be the best :) Well, it is true that in the case of the DSS the modulemode is only managing the interface clock. And since the interface clock is doing autogating, it will not prevent clockdomain transition. But I will not recommend using that, it should not be useful assuming the clocks are properly managed by the DSS. I think we still have issue dur to the presence of that fake modulemode clock node. Regards, Benoit -- 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 07/16] ARM: OMAP: Make plat/sram.h local to plat-omap
Hi Tony, On 10/04/2012 05:04 PM, Tony Lindgren wrote: We can move this from plat to be local to plat-omap for common ARM zImage support. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap1/clock.c |3 - arch/arm/mach-omap1/clock_data.c |3 - arch/arm/mach-omap1/devices.c|2 arch/arm/mach-omap1/pm.c |3 - arch/arm/mach-omap2/clkt2xxx_dpllcore.c |3 - arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |3 - arch/arm/mach-omap2/clkt34xx_dpll3m2.c |3 - arch/arm/mach-omap2/io.c |3 - arch/arm/mach-omap2/omap4-common.c |4 - arch/arm/mach-omap2/pm24xx.c |3 - arch/arm/mach-omap2/pm34xx.c |3 - arch/arm/mach-omap2/sdrc.c |2 arch/arm/mach-omap2/sdrc2xxx.c |2 arch/arm/mach-omap2/sleep34xx.S |2 arch/arm/plat-omap/common.h |2 arch/arm/plat-omap/include/plat/sram.h | 105 - arch/arm/plat-omap/sram.c|1 arch/arm/plat-omap/sram.h| 109 +- 18 files changed, 130 insertions(+), 126 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/sram.h diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c index 638f407..b15d4ee 100644 --- a/arch/arm/mach-omap1/clock.c +++ b/arch/arm/mach-omap1/clock.c @@ -24,11 +24,12 @@ #include plat/cpu.h #include plat/usb.h #include plat/clock.h -#include plat/sram.h #include plat/clkdev_omap.h #include mach/hardware.h +#include ../plat-omap/sram.h Any reason why you did not put this in arch/arm/plat-omap/include/plat-omap/ like we were discussing for dma and dmtimers headers? Then it can be just #include plat-omap/sram.h. Just curious ... Cheers Jon -- 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 4/4] mtd: nand: omap2: Add data correction support
On Fri, Oct 05, 2012 at 09:51:50AM +0100, Philip, Avinash wrote:
On Thu, Oct 04, 2012 at 15:51:03, Philip, Avinash wrote:
On Thu, Oct 04, 2012 at 00:50:45, Ivan Djelic wrote:
On Wed, Oct 03, 2012 at 03:29:49PM +0100, Philip, Avinash wrote:
ELM module can be used for error correction of BCH 4 8 bit. Also
support read write page in one shot by adding custom read_page
write_page methods. This helps in optimizing code.
New structure member is_elm_used is added to know the status of
whether the ELM module is used for error correction or not.
Note:
ECC layout of BCH8 uses 14 bytes for 512 byte of data to make compatible
with RBL ECC layout, even though the requirement was only 13 byte. This
results a common ecc layout across RBL, U-boot Linux.
See a few comments below,
(...)
+static int omap_elm_correct_data(struct mtd_info *mtd, u_char *dat,
+ u_char *read_ecc, u_char *calc_ecc)
+{
+ struct omap_nand_info *info = container_of(mtd, struct
omap_nand_info,
+ mtd);
+ int eccsteps = info-nand.ecc.steps;
+ int i , j, stat = 0;
+ int eccsize, eccflag, size;
+ struct elm_errorvec err_vec[ERROR_VECTOR_MAX];
+ u_char *ecc_vec = calc_ecc;
+ enum bch_ecc type;
+ bool is_error_reported = false;
+
+ /* initialize elm error vector to zero */
+ memset(err_vec, 0, sizeof(err_vec));
+ if (info-nand.ecc.strength == BCH8_MAX_ERROR) {
+ size = BCH8_SIZE;
+ eccsize = BCH8_ECC_OOB_BYTES;
+ type = BCH8_ECC;
+ } else {
+ size = BCH4_SIZE;
+ eccsize = BCH4_SIZE;
+ type = BCH4_ECC;
+ }
+
+ for (i = 0; i eccsteps ; i++) {
+ eccflag = 0;/* initialize eccflag */
+
+ for (j = 0; (j eccsize); j++) {
+ if (read_ecc[j] != 0xFF) {
+ eccflag = 1;/* data area is flashed
*/
Just a reminder: this way of checking if a page has been programmed is
not robust to bitflips,
so you may get into trouble with UBIFS on a fairly recent device.
Sorry I missed this point.
Here we were checking data in spare area (only in ecc layout 14*4 for BCH8)
is 0xFF. If all data
in spare area is 0xFF, conclude that the page is erased no need of error
correction. In case
of bit flip present in spare area, page will be reported as uncorrectable.
But I am not understand understand trouble with UBIFS on a fairly recent
device.
Can you little elaborativ
There are at least 2 potential problems when reading an erased page with
bitflips:
1. bitflip in data area and no bitflip in spare area (all 0xff)
Your code will not perform any ECC correction.
UBIFS does not like finding bitflips in empty pages, see for instance
http://lists.infradead.org/pipermail/linux-mtd/2012-March/040328.html.
2. bitflip in ECC bytes in spare area
Your code will report an uncorrectable error upon reading; if this happens
while reading a partially programmed UBI block,
I guess you will lose data.
BR,
--
Ivan
--
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 v8 0/6] OMAP-GPMC cleanup for generic timing
Hi, This series prepares gpmc for generic timing. v7 of this series was named OMAP-GPMC: generic time calc, prepare for driver. generic timing routine has been removed from this series. generic timing will be posted as a new separate series shortly. This rearrangement has been done so that generic timing series will happen on top of another cleanup series required for common arm zImage. Both will follow shortly. Intention is to make easy path for common arm zImage cleanup. This series contains minor cleanups that were low hanging fruits came across upon implementing generic timing routine. This series is same as v7, except that last 4 patches in v7 has been removed from this series (those 4 patches were for generic timing) This series is available @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-prep-v8 and is based on linux-next (next-20121005) Regards Afzal v8: Remove generic timing conversion patches v7: 1. Use picoseconds throughout generic timing routine to prevent rounding error. 2. Documentation on gpmc timings 3. Remove redundant rounding of nand timings (a new patch) v6: 1. Generic timing calculation, move existing users of custom calculation to use the new generic one 2. Set OneNAND part to async mode before gpmc configuration 3. Move extra delay time user handling to proper patch (3/10 - 2/10) 4. Modify nand init for OMAP3EVM too as support got added v5: Use flags for sync_read/write, hv, vhf v4: Reorganize OneNAND set_sync/async functions in a better way v3: 1. Refactor OneNAND set_sync/async functions to separate out timing and configurations 2. Handle bool type timings too 3. Swap patches 2 3 due to dependency of OneNAND change on newly added bool type timings v2: 1. Make use of timing api for setting clock activation time, and remove direct writing to register for clock activation. 2. Move ensuring that async mode in OneNAND has been setup from set_sync to setup function, improve commit message Afzal Mohammed (5): ARM: OMAP2+: nand: unify init functions ARM: OMAP2+: nand: remove redundant rounding ARM: OMAP2+: gpmc: handle additional timings ARM: OMAP2+: onenand: refactor for clarity ARM: OMAP2+: gpmc: remove cs# in sync clk div calc Jon Hunter (1): ARM: OMAP2+: GPMC: Remove unused OneNAND get_freq() platform function arch/arm/mach-omap2/board-devkit8000.c | 8 +- arch/arm/mach-omap2/board-flash.c | 45 ++--- arch/arm/mach-omap2/board-flash.h | 6 +- arch/arm/mach-omap2/board-igep0020.c| 2 +- arch/arm/mach-omap2/board-ldp.c | 4 +- arch/arm/mach-omap2/board-omap3beagle.c | 8 +- arch/arm/mach-omap2/board-omap3evm.c| 8 +- arch/arm/mach-omap2/board-omap3touchbook.c | 8 +- arch/arm/mach-omap2/board-overo.c | 7 +- arch/arm/mach-omap2/board-zoom.c| 5 +- arch/arm/mach-omap2/common-board-devices.c | 45 - arch/arm/mach-omap2/common-board-devices.h | 1 - arch/arm/mach-omap2/gpmc-nand.c | 30 ++- arch/arm/mach-omap2/gpmc-onenand.c | 232 arch/arm/mach-omap2/gpmc.c | 52 +- arch/arm/mach-omap2/usb-tusb6010.c | 3 +- arch/arm/plat-omap/include/plat/gpmc.h | 21 ++- include/linux/platform_data/mtd-onenand-omap2.h | 8 - 18 files changed, 262 insertions(+), 231 deletions(-) -- 1.7.12 -- 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 v8 1/6] ARM: OMAP2+: nand: unify init functions
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things similar to
board_nand_init except that NAND CS# were being acquired
based on bootloader setting. As CS# is hardwired for a given
board, acquiring gpmc CS# has been removed, and updated with
the value on board.
NAND CS# used in beagle board omap3evm was found to be CS0.
Thomas Weber thomas.weber.li...@googlemail.com reported
that value of devkit8000 to be CS0. Overo board was found
to be using CS0 based on u-boot, while google grep says
omap3touchbook too has CS0.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-devkit8000.c | 8 --
arch/arm/mach-omap2/board-flash.c | 45 +++---
arch/arm/mach-omap2/board-flash.h | 6 ++--
arch/arm/mach-omap2/board-igep0020.c | 2 +-
arch/arm/mach-omap2/board-ldp.c| 4 +--
arch/arm/mach-omap2/board-omap3beagle.c| 8 --
arch/arm/mach-omap2/board-omap3evm.c | 8 --
arch/arm/mach-omap2/board-omap3touchbook.c | 8 --
arch/arm/mach-omap2/board-overo.c | 7 +++--
arch/arm/mach-omap2/board-zoom.c | 5 ++--
arch/arm/mach-omap2/common-board-devices.c | 45 --
arch/arm/mach-omap2/common-board-devices.h | 1 -
12 files changed, 62 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..9933966 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -55,8 +55,11 @@
#include sdram-micron-mt46h32m32lf-6.h
#include mux.h
#include hsmmc.h
+#include board-flash.h
#include common-board-devices.h
+#defineNAND_CS 0
+
#define OMAP_DM9000_GPIO_IRQ 25
#define OMAP3_DEVKIT_TS_GPIO 27
@@ -621,8 +624,9 @@ static void __init devkit8000_init(void)
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
- omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
-ARRAY_SIZE(devkit8000_nand_partitions));
+ board_nand_init(devkit8000_nand_partitions,
+ ARRAY_SIZE(devkit8000_nand_partitions), NAND_CS,
+ NAND_BUSWIDTH_16, NULL);
omap_twl4030_audio_init(omap3beagle);
/* Ensure SDRC pins are mux'd for self-refresh */
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0cabe61..f8b30cb 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -104,41 +104,41 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
defined(CONFIG_MTD_NAND_OMAP2_MODULE)
/* Note that all values in this struct are in nanoseconds */
-static struct gpmc_timings nand_timings = {
+struct gpmc_timings nand_default_timings[1] = {
+ {
+ .sync_clk = 0,
- .sync_clk = 0,
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
- .cs_on = 0,
- .cs_rd_off = 36,
- .cs_wr_off = 36,
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
- .adv_on = 6,
- .adv_rd_off = 24,
- .adv_wr_off = 36,
+ .we_off = 30,
+ .oe_off = 48,
- .we_off = 30,
- .oe_off = 48,
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
- .access = 54,
- .rd_cycle = 72,
- .wr_cycle = 72,
-
- .wr_access = 30,
- .wr_data_mux_bus = 0,
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+ },
};
-static struct omap_nand_platform_data board_nand_data = {
- .gpmc_t = nand_timings,
-};
+static struct omap_nand_platform_data board_nand_data;
void
-__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs,
+ int nand_type, struct gpmc_timings *gpmc_t)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+ board_nand_data.gpmc_t = gpmc_t;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
gpmc_nand_init(board_nand_data);
@@ -238,5 +238,6 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
pr_err(NAND: Unable to find configuration in GPMC\n);
else
board_nand_init(partition_info[2].parts,
-
[PATCH v8 2/6] ARM: OMAP2+: nand: remove redundant rounding
gpmc_cs_set_timings() calculate ticks to be programmed by
rounding time in ns to next tick value. Hence remove
redundant rounding of nanosecond timing.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 4acf497..4eceaca 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -50,31 +50,27 @@ static int omap2_nand_gpmc_retime(struct
omap_nand_platform_data *gpmc_nand_data
memset(t, 0, sizeof(t));
t.sync_clk = gpmc_nand_data-gpmc_t-sync_clk;
- t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_on);
- t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-adv_on);
+ t.cs_on = gpmc_nand_data-gpmc_t-cs_on;
+ t.adv_on = gpmc_nand_data-gpmc_t-adv_on;
/* Read */
- t.adv_rd_off = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-adv_rd_off);
+ t.adv_rd_off = gpmc_nand_data-gpmc_t-adv_rd_off;
t.oe_on = t.adv_on;
- t.access = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-access);
- t.oe_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-oe_off);
- t.cs_rd_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_rd_off);
- t.rd_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-rd_cycle);
+ t.access = gpmc_nand_data-gpmc_t-access;
+ t.oe_off = gpmc_nand_data-gpmc_t-oe_off;
+ t.cs_rd_off = gpmc_nand_data-gpmc_t-cs_rd_off;
+ t.rd_cycle = gpmc_nand_data-gpmc_t-rd_cycle;
/* Write */
- t.adv_wr_off = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-adv_wr_off);
+ t.adv_wr_off = gpmc_nand_data-gpmc_t-adv_wr_off;
t.we_on = t.oe_on;
if (cpu_is_omap34xx()) {
- t.wr_data_mux_bus = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-wr_data_mux_bus);
- t.wr_access = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-wr_access);
+ t.wr_data_mux_bus = gpmc_nand_data-gpmc_t-wr_data_mux_bus;
+ t.wr_access = gpmc_nand_data-gpmc_t-wr_access;
}
- t.we_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-we_off);
- t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_wr_off);
- t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
+ t.we_off = gpmc_nand_data-gpmc_t-we_off;
+ t.cs_wr_off = gpmc_nand_data-gpmc_t-cs_wr_off;
+ t.wr_cycle = gpmc_nand_data-gpmc_t-wr_cycle;
/* Configure GPMC */
if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
--
1.7.12
--
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 v8 3/6] ARM: OMAP2+: gpmc: handle additional timings
Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
clkactivationtime in gpmc_cs_set_timings(). This is done so
that boards can configure these parameters of gpmc in Kernel
instead of relying on bootloader. Also configure bool type
timings like extradelay.
This needed change to the existing users that were configuring
clk activation time and extra delay by directly writing to
registers. Thanks to Tony for making me aware of users of clk
activation and being kind enough to test the modified one.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 28 +---
arch/arm/mach-omap2/gpmc.c | 48 ++
arch/arm/mach-omap2/usb-tusb6010.c | 3 ++-
arch/arm/plat-omap/include/plat/gpmc.h | 19 ++
4 files changed, 75 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 916716e..3b61544 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -284,27 +284,10 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
sync_read, sync_write, hf, vhf);
if (div == 1) {
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG2);
- reg |= (1 7);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG2, reg);
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG3);
- reg |= (1 7);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG3, reg);
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG4);
- reg |= (1 7);
- reg |= (1 23);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG4, reg);
- } else {
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG2);
- reg = ~(1 7);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG2, reg);
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG3);
- reg = ~(1 7);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG3, reg);
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG4);
- reg = ~(1 7);
- reg = ~(1 23);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG4, reg);
+ t.bool_timings.cs_extra_delay = true;
+ t.bool_timings.adv_extra_delay = true;
+ t.bool_timings.oe_extra_delay = true;
+ t.bool_timings.we_extra_delay = true;
}
/* Set synchronous read timings */
@@ -329,6 +312,8 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
t.rd_cycle = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div +
ticks_cez);
+ t.clk_activation = fclk_offset_ns;
+
/* Write */
if (sync_write) {
t.adv_wr_off = t.adv_rd_off;
@@ -362,7 +347,6 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
(sync_read ? GPMC_CONFIG1_READTYPE_SYNC : 0) |
(sync_write ? GPMC_CONFIG1_WRITEMULTIPLE_SUPP : 0) |
(sync_write ? GPMC_CONFIG1_WRITETYPE_SYNC : 0) |
- GPMC_CONFIG1_CLKACTIVATIONTIME(fclk_offset) |
GPMC_CONFIG1_PAGE_LEN(2) |
(cpu_is_omap34xx() ? 0 :
(GPMC_CONFIG1_WAIT_READ_MON |
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8ab1e1b..c2d90f6 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -73,6 +73,13 @@
#define GPMC_ECC_CTRL_ECCREG8 0x008
#define GPMC_ECC_CTRL_ECCREG9 0x009
+#defineGPMC_CONFIG2_CSEXTRADELAY BIT(7)
+#defineGPMC_CONFIG3_ADVEXTRADELAY BIT(7)
+#defineGPMC_CONFIG4_OEEXTRADELAY BIT(7)
+#defineGPMC_CONFIG4_WEEXTRADELAY BIT(23)
+#defineGPMC_CONFIG6_CYCLE2CYCLEDIFFCSENBIT(6)
+#defineGPMC_CONFIG6_CYCLE2CYCLESAMECSENBIT(7)
+
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
@@ -238,6 +245,39 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
return ticks * gpmc_get_fclk_period() / 1000;
}
+static inline void gpmc_cs_modify_reg(int cs, int reg, u32 mask, bool value)
+{
+ u32 l;
+
+ l = gpmc_cs_read_reg(cs, reg);
+ if (value)
+ l |= mask;
+ else
+ l = ~mask;
+ gpmc_cs_write_reg(cs, reg, l);
+}
+
+static void gpmc_cs_bool_timings(int cs, const struct gpmc_bool_timings *p)
+{
+ gpmc_cs_modify_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_TIME_PARA_GRAN,
+ p-time_para_granularity);
+ gpmc_cs_modify_reg(cs, GPMC_CS_CONFIG2,
+ GPMC_CONFIG2_CSEXTRADELAY, p-cs_extra_delay);
+ gpmc_cs_modify_reg(cs,
[PATCH v8 4/6] ARM: OMAP2+: onenand: refactor for clarity
Refactor set_async_mode set_sync_mode functions to
separate out timing calculation actual configuration
(GPMC OneNAND side).
Thanks to Jon for his suggestions.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 174 +++--
1 file changed, 109 insertions(+), 65 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 3b61544..e1328f5 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -16,6 +16,7 @@
#include linux/mtd/onenand_regs.h
#include linux/io.h
#include linux/platform_data/mtd-onenand-omap2.h
+#include linux/err.h
#include asm/mach/flash.h
@@ -25,6 +26,14 @@
#defineONENAND_IO_SIZE SZ_128K
+#defineONENAND_FLAG_SYNCREAD (1 0)
+#defineONENAND_FLAG_SYNCWRITE (1 1)
+#defineONENAND_FLAG_HF (1 2)
+#defineONENAND_FLAG_VHF(1 3)
+
+static unsigned onenand_flags;
+static unsigned latency;
+
static struct omap_onenand_platform_data *gpmc_onenand_data;
static struct resource gpmc_onenand_resource = {
@@ -38,11 +47,9 @@ static struct platform_device gpmc_onenand_device = {
.resource = gpmc_onenand_resource,
};
-static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
+static struct gpmc_timings omap2_onenand_calc_async_timings(void)
{
struct gpmc_timings t;
- u32 reg;
- int err;
const int t_cer = 15;
const int t_avdp = 12;
@@ -55,11 +62,6 @@ static int omap2_onenand_set_async_mode(int cs, void __iomem
*onenand_base)
const int t_wpl = 40;
const int t_wph = 30;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
-
memset(t, 0, sizeof(t));
t.sync_clk = 0;
t.cs_on = 0;
@@ -86,25 +88,30 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
t.wr_cycle = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
+ return t;
+}
+
+static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
+{
/* Configure GPMC for asynchronous read */
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
GPMC_CONFIG1_DEVICESIZE_16 |
GPMC_CONFIG1_MUXADDDATA);
- err = gpmc_cs_set_timings(cs, t);
- if (err)
- return err;
+ return gpmc_cs_set_timings(cs, t);
+}
+
+static void omap2_onenand_set_async_mode(void __iomem *onenand_base)
+{
+ u32 reg;
/* Ensure sync read and sync write are disabled */
reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
-
- return 0;
}
-static void set_onenand_cfg(void __iomem *onenand_base, int latency,
- int sync_read, int sync_write, int hf, int vhf)
+static void set_onenand_cfg(void __iomem *onenand_base)
{
u32 reg;
@@ -112,19 +119,19 @@ static void set_onenand_cfg(void __iomem *onenand_base,
int latency,
reg = ~((0x7 ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 9));
reg |= (latency ONENAND_SYS_CFG1_BRL_SHIFT) |
ONENAND_SYS_CFG1_BL_16;
- if (sync_read)
+ if (onenand_flags ONENAND_FLAG_SYNCREAD)
reg |= ONENAND_SYS_CFG1_SYNC_READ;
else
reg = ~ONENAND_SYS_CFG1_SYNC_READ;
- if (sync_write)
+ if (onenand_flags ONENAND_FLAG_SYNCWRITE)
reg |= ONENAND_SYS_CFG1_SYNC_WRITE;
else
reg = ~ONENAND_SYS_CFG1_SYNC_WRITE;
- if (hf)
+ if (onenand_flags ONENAND_FLAG_HF)
reg |= ONENAND_SYS_CFG1_HF;
else
reg = ~ONENAND_SYS_CFG1_HF;
- if (vhf)
+ if (onenand_flags ONENAND_FLAG_VHF)
reg |= ONENAND_SYS_CFG1_VHF;
else
reg = ~ONENAND_SYS_CFG1_VHF;
@@ -172,9 +179,9 @@ static int omap2_onenand_get_freq(struct
omap_onenand_platform_data *cfg,
return freq;
}
-static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
- void __iomem *onenand_base,
- int *freq_ptr)
+static struct gpmc_timings
+omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
+ int freq, bool clk_dep)
{
struct gpmc_timings t;
const int t_cer = 15;
@@ -184,29 +191,14 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
const int t_wpl = 40;
const int t_wph =
[PATCH v8 5/6] ARM: OMAP2+: GPMC: Remove unused OneNAND get_freq() platform function
From: Jon Hunter jon-hun...@ti.com
A platform function pointer for getting the frequency of a OneNAND device
was added so that a platform could specify a custom function for returning
the frequency and not just rely on the OneNAND version to determine the
frequency. However, this platform function pointer is not currently being
used and I am not sure if it ever has.
OneNAND devices are not so common these days and as far as I know not being
used with new devices. Therefore, it is most likely that this get_freq()
function pointer will not be used and so remove it.
Given that the get_freq() function pointer is not used, neither is the
clk_dep variable and so all references to it can also be removed.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 39 -
include/linux/platform_data/mtd-onenand-omap2.h | 8 -
2 files changed, 5 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index e1328f5..ac06e90 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -139,21 +139,10 @@ static void set_onenand_cfg(void __iomem *onenand_base)
}
static int omap2_onenand_get_freq(struct omap_onenand_platform_data *cfg,
- void __iomem *onenand_base, bool *clk_dep)
+ void __iomem *onenand_base)
{
u16 ver = readw(onenand_base + ONENAND_REG_VERSION_ID);
- int freq = 0;
-
- if (cfg-get_freq) {
- struct onenand_freq_info fi;
-
- fi.maf_id = readw(onenand_base + ONENAND_REG_MANUFACTURER_ID);
- fi.dev_id = readw(onenand_base + ONENAND_REG_DEVICE_ID);
- fi.ver_id = ver;
- freq = cfg-get_freq(fi, clk_dep);
- if (freq)
- return freq;
- }
+ int freq;
switch ((ver 4) 0xf) {
case 0:
@@ -181,7 +170,7 @@ static int omap2_onenand_get_freq(struct
omap_onenand_platform_data *cfg,
static struct gpmc_timings
omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
- int freq, bool clk_dep)
+ int freq)
{
struct gpmc_timings t;
const int t_cer = 15;
@@ -259,22 +248,6 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
else
latency = 4;
- if (clk_dep) {
- if (gpmc_clk_ns 12) { /* 83Mhz */
- t_ces = 3;
- t_avds = 4;
- } else if (gpmc_clk_ns 15) { /* 66Mhz */
- t_ces = 5;
- t_avds = 4;
- } else if (gpmc_clk_ns 25) { /* 40Mhz */
- t_ces = 6;
- t_avds = 5;
- } else {
- t_ces = 7;
- t_avds = 7;
- }
- }
-
/* Set synchronous read timings */
memset(t, 0, sizeof(t));
@@ -381,16 +354,14 @@ static int omap2_onenand_setup_sync(void __iomem
*onenand_base, int *freq_ptr)
{
int ret, freq = *freq_ptr;
struct gpmc_timings t;
- bool clk_dep = false;
if (!freq) {
/* Very first call freq is not known */
- freq = omap2_onenand_get_freq(gpmc_onenand_data,
- onenand_base, clk_dep);
+ freq = omap2_onenand_get_freq(gpmc_onenand_data, onenand_base);
set_onenand_cfg(onenand_base);
}
- t = omap2_onenand_calc_sync_timings(gpmc_onenand_data, freq, clk_dep);
+ t = omap2_onenand_calc_sync_timings(gpmc_onenand_data, freq);
ret = gpmc_set_sync_mode(gpmc_onenand_data-cs, t);
if (IS_ERR_VALUE(ret))
diff --git a/include/linux/platform_data/mtd-onenand-omap2.h
b/include/linux/platform_data/mtd-onenand-omap2.h
index 2858667..21bb0ff 100644
--- a/include/linux/platform_data/mtd-onenand-omap2.h
+++ b/include/linux/platform_data/mtd-onenand-omap2.h
@@ -15,20 +15,12 @@
#define ONENAND_SYNC_READ (1 0)
#define ONENAND_SYNC_READWRITE (1 1)
-struct onenand_freq_info {
- u16 maf_id;
- u16 dev_id;
- u16 ver_id;
-};
-
struct omap_onenand_platform_data {
int cs;
int gpio_irq;
struct mtd_partition*parts;
int nr_parts;
int (*onenand_setup)(void __iomem *, int *freq_ptr);
- int (*get_freq)(const struct onenand_freq_info *freq_info,
- bool *clk_dep);
int dma_channel;
u8 flags;
u8 regulator_can_sleep;
[PATCH v8 6/6] ARM: OMAP2+: gpmc: remove cs# in sync clk div calc
Divider value for a certain sync clk is determined solely
based on gpmc fclk. CS# does not have any role here, thus
remove presence of CS# in clock divider calculation API.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 3 +--
arch/arm/mach-omap2/gpmc.c | 4 ++--
arch/arm/plat-omap/include/plat/gpmc.h | 2 +-
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index ac06e90..544d501 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -182,7 +182,6 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
int div, fclk_offset_ns, fclk_offset, gpmc_clk_ns;
int ticks_cez;
- int cs = cfg-cs;
if (cfg-flags ONENAND_SYNC_READ)
onenand_flags = ONENAND_FLAG_SYNCREAD;
@@ -229,7 +228,7 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
break;
}
- div = gpmc_cs_calc_divider(cs, min_gpmc_clk_period);
+ div = gpmc_calc_divider(min_gpmc_clk_period);
gpmc_clk_ns = gpmc_ticks_to_ns(div);
if (gpmc_clk_ns 15) /* 66Mhz */
onenand_flags |= ONENAND_FLAG_HF;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index c2d90f6..2cbdcb9 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -328,7 +328,7 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit,
int end_bit,
return -1
#endif
-int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
+int gpmc_calc_divider(unsigned int sync_clk)
{
int div;
u32 l;
@@ -348,7 +348,7 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
int div;
u32 l;
- div = gpmc_cs_calc_divider(cs, t-sync_clk);
+ div = gpmc_calc_divider(t-sync_clk);
if (div 0)
return div;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index b7c9ea6..1cafbfd 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -179,7 +179,7 @@ extern unsigned long gpmc_get_fclk_period(void);
extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
extern u32 gpmc_cs_read_reg(int cs, int idx);
-extern int gpmc_cs_calc_divider(int cs, unsigned int sync_clk);
+extern int gpmc_calc_divider(unsigned int sync_clk);
extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
extern void gpmc_cs_free(int cs);
--
1.7.12
--
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 v8 0/6] OMAP-GPMC cleanup for generic timing
+ Jon and Paul On Fri, Oct 05, 2012 at 21:04:57, Mohammed, Afzal wrote: Hi, This series prepares gpmc for generic timing. v7 of this series was named OMAP-GPMC: generic time calc, prepare for driver. generic timing routine has been removed from this series. generic timing will be posted as a new separate series shortly. This rearrangement has been done so that generic timing series will happen on top of another cleanup series required for common arm zImage. Both will follow shortly. Intention is to make easy path for common arm zImage cleanup. This series contains minor cleanups that were low hanging fruits came across upon implementing generic timing routine. This series is same as v7, except that last 4 patches in v7 has been removed from this series (those 4 patches were for generic timing) This series is available @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-prep-v8 and is based on linux-next (next-20121005) Regards Afzal v8: Remove generic timing conversion patches v7: 1. Use picoseconds throughout generic timing routine to prevent rounding error. 2. Documentation on gpmc timings 3. Remove redundant rounding of nand timings (a new patch) v6: 1. Generic timing calculation, move existing users of custom calculation to use the new generic one 2. Set OneNAND part to async mode before gpmc configuration 3. Move extra delay time user handling to proper patch (3/10 - 2/10) 4. Modify nand init for OMAP3EVM too as support got added v5: Use flags for sync_read/write, hv, vhf v4: Reorganize OneNAND set_sync/async functions in a better way v3: 1. Refactor OneNAND set_sync/async functions to separate out timing and configurations 2. Handle bool type timings too 3. Swap patches 2 3 due to dependency of OneNAND change on newly added bool type timings v2: 1. Make use of timing api for setting clock activation time, and remove direct writing to register for clock activation. 2. Move ensuring that async mode in OneNAND has been setup from set_sync to setup function, improve commit message Afzal Mohammed (5): ARM: OMAP2+: nand: unify init functions ARM: OMAP2+: nand: remove redundant rounding ARM: OMAP2+: gpmc: handle additional timings ARM: OMAP2+: onenand: refactor for clarity ARM: OMAP2+: gpmc: remove cs# in sync clk div calc Jon Hunter (1): ARM: OMAP2+: GPMC: Remove unused OneNAND get_freq() platform function arch/arm/mach-omap2/board-devkit8000.c | 8 +- arch/arm/mach-omap2/board-flash.c | 45 ++--- arch/arm/mach-omap2/board-flash.h | 6 +- arch/arm/mach-omap2/board-igep0020.c| 2 +- arch/arm/mach-omap2/board-ldp.c | 4 +- arch/arm/mach-omap2/board-omap3beagle.c | 8 +- arch/arm/mach-omap2/board-omap3evm.c| 8 +- arch/arm/mach-omap2/board-omap3touchbook.c | 8 +- arch/arm/mach-omap2/board-overo.c | 7 +- arch/arm/mach-omap2/board-zoom.c| 5 +- arch/arm/mach-omap2/common-board-devices.c | 45 - arch/arm/mach-omap2/common-board-devices.h | 1 - arch/arm/mach-omap2/gpmc-nand.c | 30 ++- arch/arm/mach-omap2/gpmc-onenand.c | 232 arch/arm/mach-omap2/gpmc.c | 52 +- arch/arm/mach-omap2/usb-tusb6010.c | 3 +- arch/arm/plat-omap/include/plat/gpmc.h | 21 ++- include/linux/platform_data/mtd-onenand-omap2.h | 8 - 18 files changed, 262 insertions(+), 231 deletions(-) -- 1.7.12
RE: [PATCH v8 1/6] ARM: OMAP2+: nand: unify init functions
+ Jon and Paul
On Fri, Oct 05, 2012 at 21:05:54, Mohammed, Afzal wrote:
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things similar to
board_nand_init except that NAND CS# were being acquired
based on bootloader setting. As CS# is hardwired for a given
board, acquiring gpmc CS# has been removed, and updated with
the value on board.
NAND CS# used in beagle board omap3evm was found to be CS0.
Thomas Weber thomas.weber.li...@googlemail.com reported
that value of devkit8000 to be CS0. Overo board was found
to be using CS0 based on u-boot, while google grep says
omap3touchbook too has CS0.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-devkit8000.c | 8 --
arch/arm/mach-omap2/board-flash.c | 45
+++---
arch/arm/mach-omap2/board-flash.h | 6 ++--
arch/arm/mach-omap2/board-igep0020.c | 2 +-
arch/arm/mach-omap2/board-ldp.c| 4 +--
arch/arm/mach-omap2/board-omap3beagle.c| 8 --
arch/arm/mach-omap2/board-omap3evm.c | 8 --
arch/arm/mach-omap2/board-omap3touchbook.c | 8 --
arch/arm/mach-omap2/board-overo.c | 7 +++--
arch/arm/mach-omap2/board-zoom.c | 5 ++--
arch/arm/mach-omap2/common-board-devices.c | 45
--
arch/arm/mach-omap2/common-board-devices.h | 1 -
12 files changed, 62 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..9933966 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -55,8 +55,11 @@
#include sdram-micron-mt46h32m32lf-6.h
#include mux.h
#include hsmmc.h
+#include board-flash.h
#include common-board-devices.h
+#define NAND_CS 0
+
#define OMAP_DM9000_GPIO_IRQ 25
#define OMAP3_DEVKIT_TS_GPIO 27
@@ -621,8 +624,9 @@ static void __init devkit8000_init(void)
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
- omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
- ARRAY_SIZE(devkit8000_nand_partitions));
+ board_nand_init(devkit8000_nand_partitions,
+ ARRAY_SIZE(devkit8000_nand_partitions), NAND_CS,
+ NAND_BUSWIDTH_16, NULL);
omap_twl4030_audio_init(omap3beagle);
/* Ensure SDRC pins are mux'd for self-refresh */
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0cabe61..f8b30cb 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -104,41 +104,41 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
defined(CONFIG_MTD_NAND_OMAP2_MODULE)
/* Note that all values in this struct are in nanoseconds */
-static struct gpmc_timings nand_timings = {
+struct gpmc_timings nand_default_timings[1] = {
+ {
+ .sync_clk = 0,
- .sync_clk = 0,
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
- .cs_on = 0,
- .cs_rd_off = 36,
- .cs_wr_off = 36,
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
- .adv_on = 6,
- .adv_rd_off = 24,
- .adv_wr_off = 36,
+ .we_off = 30,
+ .oe_off = 48,
- .we_off = 30,
- .oe_off = 48,
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
- .access = 54,
- .rd_cycle = 72,
- .wr_cycle = 72,
-
- .wr_access = 30,
- .wr_data_mux_bus = 0,
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+ },
};
-static struct omap_nand_platform_data board_nand_data = {
- .gpmc_t = nand_timings,
-};
+static struct omap_nand_platform_data board_nand_data;
void
-__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs,
+ int nand_type, struct gpmc_timings *gpmc_t)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+ board_nand_data.gpmc_t = gpmc_t;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
gpmc_nand_init(board_nand_data);
@@ -238,5 +238,6 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
pr_err(NAND: Unable to find configuration in GPMC\n);
[PATCH 00/15] OMAP-GPMC related cleanup for common zImage
Hi,
This series cleans up omap-gpmc related code so that omap can
be a part of common zImage.
This series moves gpmc.h from plat-omap/include/plat to mach-omap2
so that header file is local.
Patches 1-4 qualifies as -rc material (assuming pull request
containing basic gpmc driver is accepted by Linus).
Patch 1 is an already posted one, has been pulled into this series.
Patches 5-6 removes necessity of cpu.h from onenand driver based
on Tony's suggestion.
Patches 7 8 cleans up the already moved platform data header files
to contain only platform data. Also gpmc-nand information is moved
to nand platform data header.
Patches 9-14 makes nand driver independent of gpmc header file
And the final patch localizes gpmc header.
This has been tested on omap3evm.
This series is available
@ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-czimage-v1
and is based on
linux-next (next-20121005)
and is dependent on
http://marc.info/?l=linux-omapm=134945131602622w=2
Regards
Afzal
Afzal Mohammed (15):
ARM: OMAP2+: gpmc: annotate exit sections properly
mtd: onenand: omap: cleanup gpmc dependency
mtd: nand: omap: free region as per resource size
mtd: nand: omap: read nand using register address
ARM: OMAP2+: onenand: connected soc info in pdata
mtd: onenand: omap: use pdata info instead of cpu_is
ARM: OMAP2+: onenand: header cleanup
ARM: OMAP2+: nand: header cleanup
mtd: nand: omap: bring in gpmc nand macros
ARM: OMAP2+: nand: bch capability check
ARM: OMAP2+: gpmc: nand register helper bch update
mtd: nand: omap: handle gpmc bch[48]
ARM: OMAP2+: gpmc: remove exported nand functions
mtd: nand: omap: gpmc header removal
ARM: OMAP2+: gpmc: localize gpmc header
arch/arm/mach-omap2/board-2430sdp.c| 2 +-
arch/arm/mach-omap2/board-3430sdp.c| 2 +-
arch/arm/mach-omap2/board-apollon.c| 2 +-
arch/arm/mach-omap2/board-cm-t35.c | 5 +-
arch/arm/mach-omap2/board-cm-t3517.c | 5 +-
arch/arm/mach-omap2/board-devkit8000.c | 2 +-
arch/arm/mach-omap2/board-flash.c | 7 +-
arch/arm/mach-omap2/board-flash.h | 2 +-
arch/arm/mach-omap2/board-h4.c | 2 +-
arch/arm/mach-omap2/board-igep0020.c | 3 +-
arch/arm/mach-omap2/board-ldp.c| 2 +-
arch/arm/mach-omap2/board-n8x0.c | 1 +
arch/arm/mach-omap2/board-omap3beagle.c| 2 +-
arch/arm/mach-omap2/board-omap3logic.c | 2 +-
arch/arm/mach-omap2/board-omap3pandora.c | 3 +-
arch/arm/mach-omap2/board-omap3stalker.c | 2 +-
arch/arm/mach-omap2/board-omap3touchbook.c | 2 +-
arch/arm/mach-omap2/board-overo.c | 2 +-
arch/arm/mach-omap2/board-rm680.c | 3 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 3 +-
arch/arm/mach-omap2/board-rx51.c | 2 +-
arch/arm/mach-omap2/board-zoom-debugboard.c| 2 +-
arch/arm/mach-omap2/common-board-devices.c | 1 -
arch/arm/mach-omap2/gpmc-nand.c| 81 ++--
arch/arm/mach-omap2/gpmc-nand.h| 27 ++
arch/arm/mach-omap2/gpmc-onenand.c | 9 +-
arch/arm/mach-omap2/gpmc-onenand.h | 24 ++
arch/arm/mach-omap2/gpmc-smc91x.c | 2 +-
arch/arm/mach-omap2/gpmc-smsc911x.c| 2 +-
arch/arm/mach-omap2/gpmc.c | 459 +
.../{plat-omap/include/plat = mach-omap2}/gpmc.h | 59 +--
arch/arm/mach-omap2/pm34xx.c | 2 +-
arch/arm/mach-omap2/usb-tusb6010.c | 2 +-
drivers/mtd/nand/omap2.c | 121 +-
drivers/mtd/onenand/omap2.c| 9 +-
include/linux/platform_data/mtd-nand-omap2.h | 46 ++-
include/linux/platform_data/mtd-onenand-omap2.h| 20 +-
37 files changed, 317 insertions(+), 605 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.h
create mode 100644 arch/arm/mach-omap2/gpmc-onenand.h
rename arch/arm/{plat-omap/include/plat = mach-omap2}/gpmc.h (70%)
--
1.7.12
--
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 01/15] ARM: OMAP2+: gpmc: annotate exit sections properly
compiler complained,
`gpmc_remove' referenced in section `.data' of arch/arm/mach-omap2/built-in.o:
defined in discarded section `.exit.text' of arch/arm/mach-omap2/built-in.o
Annotate gpmc_remove function and dependents with __devexit.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2cbdcb9..163458d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -886,7 +886,7 @@ static int gpmc_setup_irq(void)
return request_irq(gpmc_irq, gpmc_handle_irq, 0, gpmc, NULL);
}
-static __exit int gpmc_free_irq(void)
+static __devexit int gpmc_free_irq(void)
{
int i;
@@ -992,7 +992,7 @@ static __devinit int gpmc_probe(struct platform_device
*pdev)
return 0;
}
-static __exit int gpmc_remove(struct platform_device *pdev)
+static __devexit int gpmc_remove(struct platform_device *pdev)
{
gpmc_free_irq();
gpmc_mem_exit();
--
1.7.12
--
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 02/15] mtd: onenand: omap: cleanup gpmc dependency
requesting, freeing gpmc cs is now handled fully by gpmc, remove left out gpmc dependency as well as unnecessary include of gpmc.h Signed-off-by: Afzal Mohammed af...@ti.com --- drivers/mtd/onenand/omap2.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c index 1961be9..d7ef2c9 100644 --- a/drivers/mtd/onenand/omap2.c +++ b/drivers/mtd/onenand/omap2.c @@ -38,7 +38,6 @@ #include linux/regulator/consumer.h #include asm/mach/flash.h -#include plat/gpmc.h #include linux/platform_data/mtd-onenand-omap2.h #include asm/gpio.h @@ -803,7 +802,6 @@ static int __devexit omap2_onenand_remove(struct platform_device *pdev) } iounmap(c-onenand.base); release_mem_region(c-phys_base, c-mem_size); - gpmc_cs_free(c-gpmc_cs); kfree(c); return 0; -- 1.7.12 -- 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 03/15] mtd: nand: omap: free region as per resource size
memory as is now obtained via resource, upon freeing use resource size. This also helps get rid of one macro. Signed-off-by: Afzal Mohammed af...@ti.com --- drivers/mtd/nand/omap2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 5b31386..4c33135 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1513,7 +1513,7 @@ static int omap_nand_remove(struct platform_device *pdev) /* Release NAND device, its internal structures and partitions */ nand_release(info-mtd); iounmap(info-nand.IO_ADDR_R); - release_mem_region(info-phys_base, NAND_IO_SIZE); + release_mem_region(info-phys_base, info-mem_size); kfree(info); return 0; } -- 1.7.12 -- 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 04/15] mtd: nand: omap: read nand using register address
Now that gpmc-nand registers are available in driver, use it to read nand data. 65b97cf mtd: nand: omap2: handle nand on gpmc modified all other instances. After initial versions of that patch, a new change added reading nand data using gpmc exposed function. In the final version this change was not taken care. Signed-off-by: Afzal Mohammed af...@ti.com --- drivers/mtd/nand/omap2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 4c33135..abfc602 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -996,7 +996,7 @@ static int omap_wait(struct mtd_info *mtd, struct nand_chip *chip) cond_resched(); } - status = gpmc_nand_read(info-gpmc_cs, GPMC_NAND_DATA); + status = readb(info-reg.gpmc_nand_data); return status; } -- 1.7.12 -- 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 05/15] ARM: OMAP2+: onenand: connected soc info in pdata
onenand driver needs to know whether soc is falling under
34xx family to properly handle onenand. But driver is not
supposed to do cpu_is_* check, hence educate platform data
with this information. Driver can make use of it to avoid
cpu_is_* check.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 5 +
include/linux/platform_data/mtd-onenand-omap2.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 544d501..f0b677a 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -409,6 +409,11 @@ void __init gpmc_onenand_init(struct
omap_onenand_platform_data *_onenand_data)
gpmc_onenand_data-flags |= ONENAND_SYNC_READ;
}
+ if (cpu_is_omap34xx())
+ gpmc_onenand_data-flags |= ONENAND_IN_OMAP34XX;
+ else
+ gpmc_onenand_data-flags = ~ONENAND_IN_OMAP34XX;
+
err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
(unsigned long *)gpmc_onenand_resource.start);
if (err 0) {
diff --git a/include/linux/platform_data/mtd-onenand-omap2.h
b/include/linux/platform_data/mtd-onenand-omap2.h
index 21bb0ff..ef9c60d 100644
--- a/include/linux/platform_data/mtd-onenand-omap2.h
+++ b/include/linux/platform_data/mtd-onenand-omap2.h
@@ -14,6 +14,7 @@
#define ONENAND_SYNC_READ (1 0)
#define ONENAND_SYNC_READWRITE (1 1)
+#defineONENAND_IN_OMAP34XX (1 2)
struct omap_onenand_platform_data {
int cs;
--
1.7.12
--
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 06/15] mtd: onenand: omap: use pdata info instead of cpu_is
platform data now contains a field to indicate whether
soc belongs to omap34xx family, use it instead of
cpu_is_* check.
This helps in removing dependency of platform specific
header file - cpu.h
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/onenand/omap2.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index d7ef2c9..959f465 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -42,7 +42,6 @@
#include asm/gpio.h
#include plat/dma.h
-#include plat/cpu.h
#define DRIVER_NAME omap2-onenand
@@ -62,6 +61,7 @@ struct omap2_onenand {
int freq;
int (*setup)(void __iomem *base, int *freq_ptr);
struct regulator *regulator;
+ u8 flags;
};
static void omap2_onenand_dma_cb(int lch, u16 ch_status, void *data)
@@ -154,7 +154,7 @@ static int omap2_onenand_wait(struct mtd_info *mtd, int
state)
if (!(syscfg ONENAND_SYS_CFG1_IOBE)) {
syscfg |= ONENAND_SYS_CFG1_IOBE;
write_reg(c, syscfg, ONENAND_REG_SYS_CFG1);
- if (cpu_is_omap34xx())
+ if (c-flags ONENAND_IN_OMAP34XX)
/* Add a delay to let GPIO settle */
syscfg = read_reg(c, ONENAND_REG_SYS_CFG1);
}
@@ -638,6 +638,7 @@ static int __devinit omap2_onenand_probe(struct
platform_device *pdev)
init_completion(c-irq_done);
init_completion(c-dma_done);
+ c-flags = pdata-flags;
c-gpmc_cs = pdata-cs;
c-gpio_irq = pdata-gpio_irq;
c-dma_channel = pdata-dma_channel;
@@ -728,7 +729,7 @@ static int __devinit omap2_onenand_probe(struct
platform_device *pdev)
this = c-onenand;
if (c-dma_channel = 0) {
this-wait = omap2_onenand_wait;
- if (cpu_is_omap34xx()) {
+ if (c-flags ONENAND_IN_OMAP34XX) {
this-read_bufferram = omap3_onenand_read_bufferram;
this-write_bufferram = omap3_onenand_write_bufferram;
} else {
--
1.7.12
--
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 07/15] ARM: OMAP2+: onenand: header cleanup
For common arm zImage existing onenand header file
in platform specific location was moved to generic
platform data location, but it contained more than
platform data, remove it. New local header has been
created for exposing functions.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-flash.c | 1 +
arch/arm/mach-omap2/board-igep0020.c| 1 +
arch/arm/mach-omap2/board-n8x0.c| 1 +
arch/arm/mach-omap2/board-rm680.c | 1 +
arch/arm/mach-omap2/board-rx51-peripherals.c| 1 +
arch/arm/mach-omap2/gpmc-onenand.c | 1 +
arch/arm/mach-omap2/gpmc-onenand.h | 24
include/linux/platform_data/mtd-onenand-omap2.h | 19 +++
8 files changed, 33 insertions(+), 16 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-onenand.h
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index f8b30cb..de68fdf 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -25,6 +25,7 @@
#include common.h
#include board-flash.h
+#include gpmc-onenand.h
#define REG_FPGA_REV 0x10
#define REG_FPGA_DIP_SWITCH_INPUT2 0x60
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index f6b3ed0..83c6efa 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -43,6 +43,7 @@
#include common-board-devices.h
#include board-flash.h
#include control.h
+#include gpmc-onenand.h
#define IGEP2_SMSC911X_CS 5
#define IGEP2_SMSC911X_GPIO 176
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index d95f727..92b1916 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -32,6 +32,7 @@
#include plat/mmc.h
#include mux.h
+#include gpmc-onenand.h
#define TUSB6010_ASYNC_CS 1
#define TUSB6010_SYNC_CS 4
diff --git a/arch/arm/mach-omap2/board-rm680.c
b/arch/arm/mach-omap2/board-rm680.c
index 45997bf..154cf33 100644
--- a/arch/arm/mach-omap2/board-rm680.c
+++ b/arch/arm/mach-omap2/board-rm680.c
@@ -33,6 +33,7 @@
#include hsmmc.h
#include sdram-nokia.h
#include common-board-devices.h
+#include gpmc-onenand.h
static struct regulator_consumer_supply rm680_vemmc_consumers[] = {
REGULATOR_SUPPLY(vmmc, omap_hsmmc.1),
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ed85fb8..aa6a2a4 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -54,6 +54,7 @@
#include mux.h
#include hsmmc.h
#include common-board-devices.h
+#include gpmc-onenand.h
#define SYSTEM_REV_B_USES_VAUX30x1699
#define SYSTEM_REV_S_USES_VAUX3 0x8
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index f0b677a..29671cc 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -23,6 +23,7 @@
#include plat/gpmc.h
#include soc.h
+#include gpmc-onenand.h
#defineONENAND_IO_SIZE SZ_128K
diff --git a/arch/arm/mach-omap2/gpmc-onenand.h
b/arch/arm/mach-omap2/gpmc-onenand.h
new file mode 100644
index 000..216f23a
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-onenand.h
@@ -0,0 +1,24 @@
+/*
+ * arch/arm/mach-omap2/gpmc-onenand.h
+ *
+ * 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.
+ */
+
+#ifndef__OMAP2_GPMC_ONENAND_H
+#define__OMAP2_GPMC_ONENAND_H
+
+#include linux/platform_data/mtd-onenand-omap2.h
+
+#if IS_ENABLED(CONFIG_MTD_ONENAND_OMAP2)
+extern void gpmc_onenand_init(struct omap_onenand_platform_data *d);
+#else
+#define board_onenand_data NULL
+static inline void gpmc_onenand_init(struct omap_onenand_platform_data *d)
+{
+}
+#endif
+
+#endif
diff --git a/include/linux/platform_data/mtd-onenand-omap2.h
b/include/linux/platform_data/mtd-onenand-omap2.h
index ef9c60d..685af7e 100644
--- a/include/linux/platform_data/mtd-onenand-omap2.h
+++ b/include/linux/platform_data/mtd-onenand-omap2.h
@@ -9,6 +9,9 @@
* published by the Free Software Foundation.
*/
+#ifndef__MTD_ONENAND_OMAP2_H
+#define__MTD_ONENAND_OMAP2_H
+
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
@@ -27,20 +30,4 @@ struct omap_onenand_platform_data {
u8 regulator_can_sleep;
u8 skip_initial_unlocking;
};
-
-#define ONENAND_MAX_PARTITIONS 8
-
-#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
- defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
-
-extern void gpmc_onenand_init(struct omap_onenand_platform_data *d);
-
-#else
-
-#define board_onenand_data NULL
-
-static inline void
[PATCH 08/15] ARM: OMAP2+: nand: header cleanup
For common arm zImage existing onenand header file
in platform specific location was moved to generic
platform data location, but it contained more than
platform data, remove it. New local header has been
created for exposing functions.
Also move gpmc-nand platform data to platform header
meant for nand from gpmc header file
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 3 +-
arch/arm/mach-omap2/board-cm-t3517.c | 3 +-
arch/arm/mach-omap2/board-flash.c| 4 +--
arch/arm/mach-omap2/board-omap3pandora.c | 3 +-
arch/arm/mach-omap2/common-board-devices.c | 1 -
arch/arm/mach-omap2/gpmc-nand.c | 54 +++-
arch/arm/mach-omap2/gpmc-nand.h | 27 ++
arch/arm/mach-omap2/gpmc.c | 2 ++
arch/arm/plat-omap/include/plat/gpmc.h | 28 ++-
include/linux/platform_data/mtd-nand-omap2.h | 41 ++---
10 files changed, 98 insertions(+), 68 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.h
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 376d26e..fef68de 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -53,6 +53,7 @@
#include sdram-micron-mt46h32m32lf-6.h
#include hsmmc.h
#include common-board-devices.h
+#include gpmc-nand.h
#define CM_T35_GPIO_PENDOWN57
#define SB_T35_USB_HUB_RESET_GPIO 167
@@ -181,7 +182,7 @@ static struct omap_nand_platform_data cm_t35_nand_data = {
static void __init cm_t35_init_nand(void)
{
- if (gpmc_nand_init(cm_t35_nand_data) 0)
+ if (gpmc_nand_init(cm_t35_nand_data, NULL) 0)
pr_err(CM-T35: Unable to register NAND device\n);
}
#else
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 59c0a45..3a19e80 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -49,6 +49,7 @@
#include control.h
#include common-board-devices.h
#include am35xx-emac.h
+#include gpmc-nand.h
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
static struct gpio_led cm_t3517_leds[] = {
@@ -240,7 +241,7 @@ static struct omap_nand_platform_data cm_t3517_nand_data = {
static void __init cm_t3517_init_nand(void)
{
- if (gpmc_nand_init(cm_t3517_nand_data) 0)
+ if (gpmc_nand_init(cm_t3517_nand_data, NULL) 0)
pr_err(CM-T3517: NAND initialization failed\n);
}
#else
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index de68fdf..776e57a 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -26,6 +26,7 @@
#include common.h
#include board-flash.h
#include gpmc-onenand.h
+#include gpmc-nand.h
#define REG_FPGA_REV 0x10
#define REG_FPGA_DIP_SWITCH_INPUT2 0x60
@@ -139,10 +140,9 @@ __init board_nand_init(struct mtd_partition *nand_parts,
u8 nr_parts, u8 cs,
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
- board_nand_data.gpmc_t = gpmc_t;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
- gpmc_nand_init(board_nand_data);
+ gpmc_nand_init(board_nand_data, gpmc_t);
}
#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 00a1f4a..f286b4b 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -50,6 +50,7 @@
#include sdram-micron-mt46h32m32lf-6.h
#include hsmmc.h
#include common-board-devices.h
+#include gpmc-nand.h
#define PANDORA_WIFI_IRQ_GPIO 21
#define PANDORA_WIFI_NRESET_GPIO 23
@@ -602,7 +603,7 @@ static void __init omap3pandora_init(void)
omap_ads7846_init(1, OMAP3_PANDORA_TS_GPIO, 0, NULL);
usbhs_init(usbhs_bdata);
usb_musb_init(NULL);
- gpmc_nand_init(pandora_nand_data);
+ gpmc_nand_init(pandora_nand_data, NULL);
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/common-board-devices.c
b/arch/arm/mach-omap2/common-board-devices.c
index 90e0597..ad85609 100644
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -25,7 +25,6 @@
#include linux/spi/ads7846.h
#include linux/platform_data/spi-omap2-mcspi.h
-#include linux/platform_data/mtd-nand-omap2.h
#include common.h
#include common-board-devices.h
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 4eceaca..c1b9b1d 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -20,6 +20,10 @@
#include plat/gpmc.h
[PATCH 09/15] mtd: nand: omap: bring in gpmc nand macros
Bring onto driver the macros defined in gpmc.h that are
not necessary outside driver, helps in removing inclusion
of gpmc.h too. Also remove GPMC prefix on those macros to
make clear it's independence with gpmc header.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/nand/omap2.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index abfc602..f0a1b1d 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -110,6 +110,11 @@
#defineECC1RESULTSIZE 0x1
#defineECCCLEAR0x100
#defineECC10x1
+#definePREFETCH_FIFOTHRESHOLD_MAX 0x40
+#definePREFETCH_FIFOTHRESHOLD(val) ((val) 8)
+#definePREFETCH_STATUS_COUNT(val) (val 0x3fff)
+#definePREFETCH_STATUS_FIFO_CNT(val) ((val 24) 0x7F)
+#defineSTATUS_BUFF_EMPTY 0x0001
/* oob info generated runtime depending on ecc algorithm and layout selected */
static struct nand_ecclayout omap_oobinfo;
@@ -269,7 +274,7 @@ static void omap_write_buf8(struct mtd_info *mtd, const
u_char *buf, int len)
/* wait until buffer is available for write */
do {
status = readl(info-reg.gpmc_status)
- GPMC_STATUS_BUFF_EMPTY;
+ STATUS_BUFF_EMPTY;
} while (!status);
}
}
@@ -307,7 +312,7 @@ static void omap_write_buf16(struct mtd_info *mtd, const
u_char * buf, int len)
/* wait until buffer is available for write */
do {
status = readl(info-reg.gpmc_status)
- GPMC_STATUS_BUFF_EMPTY;
+ STATUS_BUFF_EMPTY;
} while (!status);
}
}
@@ -348,7 +353,7 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
} else {
do {
r_count = readl(info-reg.gpmc_prefetch_status);
- r_count = GPMC_PREFETCH_STATUS_FIFO_CNT(r_count);
+ r_count = PREFETCH_STATUS_FIFO_CNT(r_count);
r_count = r_count 2;
ioread32_rep(info-nand.IO_ADDR_R, p, r_count);
p += r_count;
@@ -395,7 +400,7 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
} else {
while (len) {
w_count = readl(info-reg.gpmc_prefetch_status);
- w_count = GPMC_PREFETCH_STATUS_FIFO_CNT(w_count);
+ w_count = PREFETCH_STATUS_FIFO_CNT(w_count);
w_count = w_count 1;
for (i = 0; (i w_count) len; i++, len -= 2)
iowrite16(*p++, info-nand.IO_ADDR_W);
@@ -407,7 +412,7 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
do {
cpu_relax();
val = readl(info-reg.gpmc_prefetch_status);
- val = GPMC_PREFETCH_STATUS_COUNT(val);
+ val = PREFETCH_STATUS_COUNT(val);
} while (val (tim++ limit));
/* disable and stop the PFPW engine */
@@ -493,7 +498,7 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
do {
cpu_relax();
val = readl(info-reg.gpmc_prefetch_status);
- val = GPMC_PREFETCH_STATUS_COUNT(val);
+ val = PREFETCH_STATUS_COUNT(val);
} while (val (tim++ limit));
/* disable and stop the PFPW engine */
@@ -556,7 +561,7 @@ static irqreturn_t omap_nand_irq(int this_irq, void *dev)
u32 bytes;
bytes = readl(info-reg.gpmc_prefetch_status);
- bytes = GPMC_PREFETCH_STATUS_FIFO_CNT(bytes);
+ bytes = PREFETCH_STATUS_FIFO_CNT(bytes);
bytes = bytes 0xFFFC; /* io in multiple of 4 bytes */
if (info-iomode == OMAP_NAND_IO_WRITE) { /* checks for write io */
if (this_irq == info-gpmc_irq_count)
@@ -682,7 +687,7 @@ static void omap_write_buf_irq_pref(struct mtd_info *mtd,
limit = (loops_per_jiffy * msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));
do {
val = readl(info-reg.gpmc_prefetch_status);
- val = GPMC_PREFETCH_STATUS_COUNT(val);
+ val = PREFETCH_STATUS_COUNT(val);
cpu_relax();
} while (val (tim++ limit));
--
1.7.12
--
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 10/15] ARM: OMAP2+: nand: bch capability check
Capability of bch schemes could be discovered using soc
revision checks. If soc revision indicates that selected
ecc scheme is not supported bail out.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index c1b9b1d..7983d54 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -90,6 +90,27 @@ static int omap2_nand_gpmc_retime(
return 0;
}
+static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
+{
+ /* support only OMAP3 class */
+ if (!cpu_is_omap34xx()) {
+ pr_err(BCH ecc is not supported on this CPU\n);
+ return 0;
+ }
+
+ /*
+* For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1.
+* Other chips may be added if confirmed to work.
+*/
+ if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW)
+ (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0))) {
+ pr_err(BCH 4-bit mode is not supported on this CPU\n);
+ return 0;
+ }
+
+ return 1;
+}
+
int __init gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
struct gpmc_timings *gpmc_t)
{
@@ -128,6 +149,9 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
gpmc_update_nand_reg(gpmc_nand_data-reg, gpmc_nand_data-cs);
+ if (!gpmc_hwecc_bch_capable(gpmc_nand_data-ecc_opt))
+ return -EINVAL;
+
err = platform_device_register(gpmc_nand_device);
if (err 0) {
dev_err(dev, Unable to register NAND device\n);
--
1.7.12
--
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 11/15] ARM: OMAP2+: gpmc: nand register helper bch update
Update helper function that provides gpmc-nand register
details for nand driver with bch register information.
Using this nand driver can be made self sufficient to
handle remaining gpmc-nand operations by itself instead
of relying on gpmc exported nand functions.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 18 +-
include/linux/platform_data/mtd-nand-omap2.h | 7 ++-
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 3a73196..eb577c5 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -61,6 +61,9 @@
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
#define GPMC_ECC_BCH_RESULT_0 0x240 /* not available on OMAP2 */
+#defineGPMC_ECC_BCH_RESULT_1 0x244 /* not available on OMAP2 */
+#defineGPMC_ECC_BCH_RESULT_2 0x248 /* not available on OMAP2 */
+#defineGPMC_ECC_BCH_RESULT_3 0x24c /* not available on OMAP2 */
/* GPMC ECC control settings */
#define GPMC_ECC_CTRL_ECCCLEAR 0x100
@@ -84,6 +87,7 @@
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
+#defineGPMC_BCH_SIZE 0x10
#define GPMC_MEM_START 0x
#define GPMC_MEM_END 0x3FFF
@@ -779,6 +783,8 @@ EXPORT_SYMBOL(gpmc_prefetch_reset);
void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
{
+ int i;
+
reg-gpmc_status = gpmc_base + GPMC_STATUS;
reg-gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
@@ -794,7 +800,17 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int
cs)
reg-gpmc_ecc_control = gpmc_base + GPMC_ECC_CONTROL;
reg-gpmc_ecc_size_config = gpmc_base + GPMC_ECC_SIZE_CONFIG;
reg-gpmc_ecc1_result = gpmc_base + GPMC_ECC1_RESULT;
- reg-gpmc_bch_result0 = gpmc_base + GPMC_ECC_BCH_RESULT_0;
+
+ for (i = 0; i GPMC_BCH_NUM_REMAINDER; i++) {
+ reg-gpmc_bch_result0[i] = gpmc_base + GPMC_ECC_BCH_RESULT_0 +
+ GPMC_BCH_SIZE * i;
+ reg-gpmc_bch_result1[i] = gpmc_base + GPMC_ECC_BCH_RESULT_1 +
+ GPMC_BCH_SIZE * i;
+ reg-gpmc_bch_result2[i] = gpmc_base + GPMC_ECC_BCH_RESULT_2 +
+ GPMC_BCH_SIZE * i;
+ reg-gpmc_bch_result3[i] = gpmc_base + GPMC_ECC_BCH_RESULT_3 +
+ GPMC_BCH_SIZE * i;
+ }
}
int gpmc_get_client_irq(unsigned irq_config)
diff --git a/include/linux/platform_data/mtd-nand-omap2.h
b/include/linux/platform_data/mtd-nand-omap2.h
index e1965fe..24d32ca 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -13,6 +13,8 @@
#include linux/mtd/partitions.h
+#defineGPMC_BCH_NUM_REMAINDER 8
+
enum nand_io {
NAND_OMAP_PREFETCH_POLLED = 0, /* prefetch polled mode, default */
NAND_OMAP_POLLED, /* polled mode, without prefetch */
@@ -43,7 +45,10 @@ struct gpmc_nand_regs {
void __iomem*gpmc_ecc_control;
void __iomem*gpmc_ecc_size_config;
void __iomem*gpmc_ecc1_result;
- void __iomem*gpmc_bch_result0;
+ void __iomem*gpmc_bch_result0[GPMC_BCH_NUM_REMAINDER];
+ void __iomem*gpmc_bch_result1[GPMC_BCH_NUM_REMAINDER];
+ void __iomem*gpmc_bch_result2[GPMC_BCH_NUM_REMAINDER];
+ void __iomem*gpmc_bch_result3[GPMC_BCH_NUM_REMAINDER];
};
struct omap_nand_platform_data {
--
1.7.12
--
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 12/15] mtd: nand: omap: handle gpmc bch[48]
gpmc-nand bch registers are now available in driver,
make use of it to handle bch[48] instead of relying
on gpmc exported functions.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/nand/omap2.c | 95 +++-
1 file changed, 86 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index f0a1b1d..e3fc8d7 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -106,6 +106,7 @@
#defineCS_MASK 0x7
#defineENABLE_PREFETCH (0x1 7)
#defineDMA_MPU_MODE_SHIFT 2
+#defineECCSIZE0_SHIFT 12
#defineECCSIZE1_SHIFT 22
#defineECC1RESULTSIZE 0x1
#defineECCCLEAR0x100
@@ -1034,19 +1035,45 @@ static int omap_dev_ready(struct mtd_info *mtd)
static void omap3_enable_hwecc_bch(struct mtd_info *mtd, int mode)
{
int nerrors;
- unsigned int dev_width;
+ unsigned int dev_width, nsectors;
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
struct nand_chip *chip = mtd-priv;
+ u32 val;
nerrors = (info-nand.ecc.bytes == 13) ? 8 : 4;
dev_width = (chip-options NAND_BUSWIDTH_16) ? 1 : 0;
+ nsectors = 1;
/*
* Program GPMC to perform correction on one 512-byte sector at a time.
* Using 4 sectors at a time (i.e. ecc.size = 2048) is also possible and
* gives a slight (5%) performance gain (but requires additional code).
*/
- (void)gpmc_enable_hwecc_bch(info-gpmc_cs, mode, dev_width, 1, nerrors);
+
+ writel(ECC1, info-reg.gpmc_ecc_control);
+
+ /*
+* When using BCH, sector size is hardcoded to 512 bytes.
+* Here we are using wrapping mode 6 both for reading and writing, with:
+* size0 = 0 (no additional protected byte in spare area)
+* size1 = 32 (skip 32 nibbles = 16 bytes per sector in spare area)
+*/
+ val = (32 ECCSIZE1_SHIFT) | (0 ECCSIZE0_SHIFT);
+ writel(val, info-reg.gpmc_ecc_size_config);
+
+ /* BCH configuration */
+ val = ((1 16) | /* enable BCH */
+ (((nerrors == 8) ? 1 : 0) 12) | /* 8 or 4 bits */
+ (0x06 8) | /* wrap mode = 6 */
+ (dev_width 7) | /* bus width */
+ (((nsectors-1) 0x7) 4) | /* number of sectors */
+ (info-gpmc_cs 1) | /* ECC CS */
+ (0x1));/* enable ECC */
+
+ writel(val, info-reg.gpmc_ecc_config);
+
+ /* clear ecc and enable bits */
+ writel(ECCCLEAR | ECC1, info-reg.gpmc_ecc_control);
}
/**
@@ -1060,7 +1087,31 @@ static int omap3_calculate_ecc_bch4(struct mtd_info
*mtd, const u_char *dat,
{
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
- return gpmc_calculate_ecc_bch4(info-gpmc_cs, dat, ecc_code);
+ unsigned long nsectors, val1, val2;
+
+ nsectors = ((readl(info-reg.gpmc_ecc_config) 4) 0x7) + 1;
+
+ for (i = 0; i nsectors; i++) {
+
+ /* Read hw-computed remainder */
+ val1 = readl(info-reg.gpmc_bch_result0[i]);
+ val2 = readl(info-reg.gpmc_bch_result1[i]);
+
+ /*
+* Add constant polynomial to remainder, in order to get an ecc
+* sequence of 0xFFs for a buffer filled with 0xFFs; and
+* left-justify the resulting polynomial.
+*/
+ *ecc++ = 0x28 ^ ((val2 12) 0xFF);
+ *ecc++ = 0x13 ^ ((val2 4) 0xFF);
+ *ecc++ = 0xcc ^ (((val2 0xF) 4)|((val1 28) 0xF));
+ *ecc++ = 0x39 ^ ((val1 20) 0xFF);
+ *ecc++ = 0x96 ^ ((val1 12) 0xFF);
+ *ecc++ = 0xac ^ ((val1 4) 0xFF);
+ *ecc++ = 0x7f ^ ((val1 0xF) 4);
+ }
+
+ return 0;
}
/**
@@ -1074,7 +1125,38 @@ static int omap3_calculate_ecc_bch8(struct mtd_info
*mtd, const u_char *dat,
{
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
- return gpmc_calculate_ecc_bch8(info-gpmc_cs, dat, ecc_code);
+ unsigned long nsectors, reg, val1, val2, val3, val4;
+
+ nsectors = ((readl(info-reg.gpmc_ecc_config) 4) 0x7) + 1;
+
+ for (i = 0; i nsectors; i++) {
+
+ /* Read hw-computed remainder */
+ val1 = readl(info-reg.gpmc_bch_result0[i]);
+ val2 = readl(info-reg.gpmc_bch_result1[i]);
+ val3 = readl(info-reg.gpmc_bch_result2[i]);
+ val4 = readl(info-reg.gpmc_bch_result3[i]);
+
+
[PATCH 13/15] ARM: OMAP2+: gpmc: remove exported nand functions
nand driver handles gpmc-nand block fully, hence no more
users for these exported nand functions, remove it.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 432 -
arch/arm/plat-omap/include/plat/gpmc.h | 31 ---
2 files changed, 463 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index eb577c5..1121248 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -150,7 +150,6 @@ static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_map; /* flag for cs which are initialized */
-static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
static struct device *gpmc_dev;
static int gpmc_irq;
static resource_size_t phys_base, mem_size;
@@ -171,22 +170,6 @@ static u32 gpmc_read_reg(int idx)
return __raw_readl(gpmc_base + idx);
}
-static void gpmc_cs_write_byte(int cs, int idx, u8 val)
-{
- void __iomem *reg_addr;
-
- reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
- __raw_writeb(val, reg_addr);
-}
-
-static u8 gpmc_cs_read_byte(int cs, int idx)
-{
- void __iomem *reg_addr;
-
- reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
- return __raw_readb(reg_addr);
-}
-
void gpmc_cs_write_reg(int cs, int idx, u32 val)
{
void __iomem *reg_addr;
@@ -563,44 +546,6 @@ void gpmc_cs_free(int cs)
EXPORT_SYMBOL(gpmc_cs_free);
/**
- * gpmc_read_status - read access request to get the different gpmc status
- * @cmd: command type
- * @return status
- */
-int gpmc_read_status(int cmd)
-{
- int status = -EINVAL;
- u32 regval = 0;
-
- switch (cmd) {
- case GPMC_GET_IRQ_STATUS:
- status = gpmc_read_reg(GPMC_IRQSTATUS);
- break;
-
- case GPMC_PREFETCH_FIFO_CNT:
- regval = gpmc_read_reg(GPMC_PREFETCH_STATUS);
- status = GPMC_PREFETCH_STATUS_FIFO_CNT(regval);
- break;
-
- case GPMC_PREFETCH_COUNT:
- regval = gpmc_read_reg(GPMC_PREFETCH_STATUS);
- status = GPMC_PREFETCH_STATUS_COUNT(regval);
- break;
-
- case GPMC_STATUS_BUFFER:
- regval = gpmc_read_reg(GPMC_STATUS);
- /* 1 : buffer is available to write */
- status = regval GPMC_STATUS_BUFF_EMPTY;
- break;
-
- default:
- printk(KERN_ERR gpmc_read_status: Not supported\n);
- }
- return status;
-}
-EXPORT_SYMBOL(gpmc_read_status);
-
-/**
* gpmc_cs_configure - write request to configure gpmc
* @cs: chip select number
* @cmd: command type
@@ -668,119 +613,6 @@ int gpmc_cs_configure(int cs, int cmd, int wval)
}
EXPORT_SYMBOL(gpmc_cs_configure);
-/**
- * gpmc_nand_read - nand specific read access request
- * @cs: chip select number
- * @cmd: command type
- */
-int gpmc_nand_read(int cs, int cmd)
-{
- int rval = -EINVAL;
-
- switch (cmd) {
- case GPMC_NAND_DATA:
- rval = gpmc_cs_read_byte(cs, GPMC_CS_NAND_DATA);
- break;
-
- default:
- printk(KERN_ERR gpmc_read_nand_ctrl: Not supported\n);
- }
- return rval;
-}
-EXPORT_SYMBOL(gpmc_nand_read);
-
-/**
- * gpmc_nand_write - nand specific write request
- * @cs: chip select number
- * @cmd: command type
- * @wval: value to write
- */
-int gpmc_nand_write(int cs, int cmd, int wval)
-{
- int err = 0;
-
- switch (cmd) {
- case GPMC_NAND_COMMAND:
- gpmc_cs_write_byte(cs, GPMC_CS_NAND_COMMAND, wval);
- break;
-
- case GPMC_NAND_ADDRESS:
- gpmc_cs_write_byte(cs, GPMC_CS_NAND_ADDRESS, wval);
- break;
-
- case GPMC_NAND_DATA:
- gpmc_cs_write_byte(cs, GPMC_CS_NAND_DATA, wval);
-
- default:
- printk(KERN_ERR gpmc_write_nand_ctrl: Not supported\n);
- err = -EINVAL;
- }
- return err;
-}
-EXPORT_SYMBOL(gpmc_nand_write);
-
-
-
-/**
- * gpmc_prefetch_enable - configures and starts prefetch transfer
- * @cs: cs (chip select) number
- * @fifo_th: fifo threshold to be used for read/ write
- * @dma_mode: dma mode enable (1) or disable (0)
- * @u32_count: number of bytes to be transferred
- * @is_write: prefetch read(0) or write post(1) mode
- */
-int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
- unsigned int u32_count, int is_write)
-{
-
- if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX) {
- pr_err(gpmc: fifo threshold is not supported\n);
- return -1;
- } else if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
- /* Set the amount of bytes to be prefetched */
- gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
-
- /* Set dma/mpu mode, the
[PATCH 14/15] mtd: nand: omap: gpmc header removal
nand driver no longer needs gpmc header, remove it. Signed-off-by: Afzal Mohammed af...@ti.com --- drivers/mtd/nand/omap2.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index e3fc8d7..d6664d7 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -28,7 +28,6 @@ #endif #include plat/dma.h -#include plat/gpmc.h #include linux/platform_data/mtd-nand-omap2.h #defineDRIVER_NAME omap2-nand -- 1.7.12 -- 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 15/15] ARM: OMAP2+: gpmc: localize gpmc header
Requirement of gpmc header outside of mach-omap2 has been
cutoff, move gpmc header file in plat-omap folder to local
mach-omap2 folder
Objective - common zImage participation of omap
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c| 2 +-
arch/arm/mach-omap2/board-3430sdp.c| 2 +-
arch/arm/mach-omap2/board-apollon.c| 2 +-
arch/arm/mach-omap2/board-cm-t35.c | 2 +-
arch/arm/mach-omap2/board-cm-t3517.c | 2 +-
arch/arm/mach-omap2/board-devkit8000.c | 2 +-
arch/arm/mach-omap2/board-flash.c | 2 +-
arch/arm/mach-omap2/board-flash.h | 2 +-
arch/arm/mach-omap2/board-h4.c | 2 +-
arch/arm/mach-omap2/board-igep0020.c | 2 +-
arch/arm/mach-omap2/board-ldp.c| 2 +-
arch/arm/mach-omap2/board-omap3beagle.c| 2 +-
arch/arm/mach-omap2/board-omap3logic.c | 2 +-
arch/arm/mach-omap2/board-omap3stalker.c | 2 +-
arch/arm/mach-omap2/board-omap3touchbook.c | 2 +-
arch/arm/mach-omap2/board-overo.c | 2 +-
arch/arm/mach-omap2/board-rm680.c | 2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
arch/arm/mach-omap2/board-rx51.c | 2 +-
arch/arm/mach-omap2/board-zoom-debugboard.c| 2 +-
arch/arm/mach-omap2/gpmc-nand.c| 3 +--
arch/arm/mach-omap2/gpmc-nand.h| 2 +-
arch/arm/mach-omap2/gpmc-onenand.c | 3 +--
arch/arm/mach-omap2/gpmc-smc91x.c | 2 +-
arch/arm/mach-omap2/gpmc-smsc911x.c| 2 +-
arch/arm/mach-omap2/gpmc.c | 3 +--
arch/arm/{plat-omap/include/plat = mach-omap2}/gpmc.h | 0
arch/arm/mach-omap2/pm34xx.c | 2 +-
arch/arm/mach-omap2/usb-tusb6010.c | 2 +-
29 files changed, 28 insertions(+), 31 deletions(-)
rename arch/arm/{plat-omap/include/plat = mach-omap2}/gpmc.h (100%)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 95b384d..49e49d0 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -34,7 +34,7 @@
#include asm/mach/map.h
#include common.h
-#include plat/gpmc.h
+#include gpmc.h
#include plat/usb.h
#include gpmc-smc91x.h
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 96cd369..5ad0901 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -33,7 +33,7 @@
#include plat/usb.h
#include common.h
#include plat/dma.h
-#include plat/gpmc.h
+#include gpmc.h
#include video/omapdss.h
#include video/omap-panel-tfp410.h
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index cea3aba..8cdd186 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -35,7 +35,7 @@
#include plat/led.h
#include common.h
-#include plat/gpmc.h
+#include gpmc.h
#include video/omapdss.h
#include video/omap-panel-generic-dpi.h
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index fef68de..73e2ba9 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -40,7 +40,7 @@
#include common.h
#include linux/platform_data/mtd-nand-omap2.h
-#include plat/gpmc.h
+#include gpmc.h
#include plat/usb.h
#include video/omapdss.h
#include video/omap-panel-generic-dpi.h
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 3a19e80..b5495e4 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -41,7 +41,7 @@
#include common.h
#include plat/usb.h
#include linux/platform_data/mtd-nand-omap2.h
-#include plat/gpmc.h
+#include gpmc.h
#include am35xx.h
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 9933966..3eedb8f 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -39,7 +39,7 @@
#include asm/mach/flash.h
#include common.h
-#include plat/gpmc.h
+#include gpmc.h
#include linux/platform_data/mtd-nand-omap2.h
#include plat/usb.h
#include video/omapdss.h
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 776e57a..c56986f 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -18,7 +18,7 @@
#include linux/io.h
#include plat/cpu.h
-#include plat/gpmc.h
+#include gpmc.h
#include linux/platform_data/mtd-nand-omap2.h
#include linux/platform_data/mtd-onenand-omap2.h
#include plat/tc.h
diff --git a/arch/arm/mach-omap2/board-flash.h
b/arch/arm/mach-omap2/board-flash.h
index
[PATCH 0/4] OMAP-GPMC generic timing migration
Hi, This series provides a generic gpmc timing calculation routine. There were three peripherals (OneNAND, tusb6010, smc91x) using custom timing calculations, they are migrated to use the generic timing calculation. Such a generic routine would help create a driver out of gpmc platform code, which would be peripheral agnostic and thus lead to DT finally. Input to generic timing calculation routine would be gpmc peripheral timings, output - translated timings that gpmc can understand. Later, to DT'ify, gpmc peripheral timings could be passed through DT. Input timings that has been used here are selected such that it represents those that are present in peripheral timing datasheets. This series has been created by pulling out last 4 patches in v7 of the series, OMAP-GPMC: generic time calc, prepare for driver This was done to have easy path for common zImage gpmc cleanup patches. Proposed generic routine has been tested on OneNAND (async) on OMAP3EVM rev C (as mainline does not have the OneNAND support for this, local patch were used to test). For other cases of custom timing calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing calculation routine was verified by simulating on OMAP3EVM. This series is available @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing-v1 and is based on linux-next (next-20121005) and is dependent on http://marc.info/?l=linux-omapm=134945131602622w=2 http://marc.info/?l=linux-omapm=134945239306131w=2 This series as such is only the first version, but these patches has already undergone one change before being made as this series. The change was in using ps instead of ns to prevent rounding errors. Also along with this series documentation has been improved. Regards Afzal Afzal Mohammed (4): ARM: OMAP2+: gpmc: generic timing calculation ARM: OMAP2+: onenand: generic timing calculation ARM: OMAP2+: smc91x: generic timing calculation ARM: OMAP2+: tusb6010: generic timing calculation Documentation/bus-devices/ti-gpmc.txt | 122 + arch/arm/mach-omap2/gpmc-onenand.c| 124 + arch/arm/mach-omap2/gpmc-smc91x.c | 43 ++--- arch/arm/mach-omap2/gpmc.c| 325 ++ arch/arm/mach-omap2/gpmc.h| 102 --- arch/arm/mach-omap2/usb-tusb6010.c| 182 +-- 6 files changed, 633 insertions(+), 265 deletions(-) create mode 100644 Documentation/bus-devices/ti-gpmc.txt -- 1.7.12 -- 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/4] ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing by runtime calculation. Those peripherals can work with frequency scaling that affects gpmc clock. But timing calculation for them are in different ways. Here a generic runtime calculation method is proposed. Input to this function were selected so that they represent timing variables that are present in peripheral datasheets. Motive behind this was to achieve DT bindings for the inputs as is. Even though a few of the tusb6010 timings could not be made directly related to timings normally found on peripherals, expressions used were translated to those that could be justified. There are possibilities of improving the calculations, like calculating timing for read write operations in a more similar way. Expressions derived here were tested for async onenand on omap3evm (as vanilla Kernel does not have omap3evm onenand support, local patch was used). Other peripherals, tusb6010, smc91x calculations were validated by simulating on omap3evm. Regarding we_on for onenand async, it was found that even for muxed address/data, it need not be greater than adv_wr_off, but rather could be derived from write setup time for peripheral from start of access time, hence would more be in line with peripheral timings. With this method it was working fine. If it is required in some cases to have we_on same as wr_data_mux_bus (i.e. greater than adv_wr_off), another variable could be added to indicate it. But such a requirement is not expected though. It has been observed that adv_rd_off adv_wr_off are currently calculated by adding an offset over oe_on and we_on respectively in the case of smc91x. But peripheral datasheet does not specify so and so adv_rd(wr)_off has been derived (to be specific, made ignorant of oe_on and we_on) observing datasheet rather than adding an offset. Hence this generic routine is expected to work for smc91x (91C96 RX51 board). This was verified on smsc911x (9220 on OMAP3EVM) - a similar ethernet controller. Timings are calculated in ps to prevent rounding errors and converted to ns at final stage so that these values can be directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings() would be modified to take ps once all custom timing routines are replaced by the generic routine, at the same time generic timing routine would be modified to provide timings in ps. struct gpmc_timings field types are upgraded from u16 = u32 so that it can hold ps values. Whole of this exercise is being done to achieve driver and DT conversion. If timings could not be calculated in a peripheral agnostic way, either gpmc driver would have to be peripheral gnostic or a wrapper arrangement over gpmc driver would be required. Signed-off-by: Afzal Mohammed af...@ti.com --- Documentation/bus-devices/ti-gpmc.txt | 122 + arch/arm/mach-omap2/gpmc.c| 325 ++ arch/arm/mach-omap2/gpmc.h| 102 --- 3 files changed, 529 insertions(+), 20 deletions(-) create mode 100644 Documentation/bus-devices/ti-gpmc.txt diff --git a/Documentation/bus-devices/ti-gpmc.txt b/Documentation/bus-devices/ti-gpmc.txt new file mode 100644 index 000..cc9ce57 --- /dev/null +++ b/Documentation/bus-devices/ti-gpmc.txt @@ -0,0 +1,122 @@ +GPMC (General Purpose Memory Controller): += + +GPMC is an unified memory controller dedicated to interfacing external +memory devices like + * Asynchronous SRAM like memories and application specific integrated + circuit devices. + * Asynchronous, synchronous, and page mode burst NOR flash devices + NAND flash + * Pseudo-SRAM devices + +GPMC is found on Texas Instruments SoC's (OMAP based) +IP details: http://www.ti.com/lit/pdf/spruh73 section 7.1 + + +GPMC generic timing calculation: + + +GPMC has certain timings that has to be programmed for proper +functioning of the peripheral, while peripheral has another set of +timings. To have peripheral work with gpmc, peripheral timings has to +be translated to the form gpmc can understand. The way it has to be +translated depends on the connected peripheral. Also there is a +dependency for certain gpmc timings on gpmc clock frequency. Hence a +generic timing routine was developed to achieve above requirements. + +Generic routine provides a generic method to calculate gpmc timings +from gpmc peripheral timings. struct gpmc_device_timings fields has to +be updated with timings from the datasheet of the peripheral that is +connected to gpmc. A few of the peripheral timings can be fed either +in time or in cycles, provision to handle this scenario has been +provided (refer struct gpmc_device_timings definition). It may so +happen that timing as specified by peripheral datasheet is not present +in timing structure, in this scenario, try to correlate peripheral +timing to the one available. If that doesn't work, try to add a new +field as required by peripheral,
[PATCH 2/4] ARM: OMAP2+: onenand: generic timing calculation
Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 124 +
1 file changed, 43 insertions(+), 81 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 54e2255..94a349e 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -49,6 +49,7 @@ static struct platform_device gpmc_onenand_device = {
static struct gpmc_timings omap2_onenand_calc_async_timings(void)
{
+ struct gpmc_device_timings dev_t;
struct gpmc_timings t;
const int t_cer = 15;
@@ -58,35 +59,24 @@ static struct gpmc_timings
omap2_onenand_calc_async_timings(void)
const int t_aa = 76;
const int t_oe = 20;
const int t_cez = 20; /* max of t_cez, t_oez */
- const int t_ds = 30;
const int t_wpl = 40;
const int t_wph = 30;
- memset(t, 0, sizeof(t));
- t.sync_clk = 0;
- t.cs_on = 0;
- t.adv_on = 0;
-
- /* Read */
- t.adv_rd_off = gpmc_round_ns_to_ticks(max_t(int, t_avdp, t_cer));
- t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(t_aavdh);
- t.access = t.adv_on + gpmc_round_ns_to_ticks(t_aa);
- t.access = max_t(int, t.access, t.cs_on + gpmc_round_ns_to_ticks(t_ce));
- t.access = max_t(int, t.access, t.oe_on + gpmc_round_ns_to_ticks(t_oe));
- t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
- t.cs_rd_off = t.oe_off;
- t.rd_cycle = t.cs_rd_off + gpmc_round_ns_to_ticks(t_cez);
-
- /* Write */
- t.adv_wr_off = t.adv_rd_off;
- t.we_on = t.oe_on;
- if (cpu_is_omap34xx()) {
- t.wr_data_mux_bus = t.we_on;
- t.wr_access = t.we_on + gpmc_round_ns_to_ticks(t_ds);
- }
- t.we_off = t.we_on + gpmc_round_ns_to_ticks(t_wpl);
- t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
- t.wr_cycle = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
+ memset(dev_t, 0, sizeof(dev_t));
+
+ dev_t.mux = true;
+ dev_t.t_avdp_r = max_t(int, t_avdp, t_cer) * 1000;
+ dev_t.t_avdp_w = dev_t.t_avdp_r;
+ dev_t.t_aavdh = t_aavdh * 1000;
+ dev_t.t_aa = t_aa * 1000;
+ dev_t.t_ce = t_ce * 1000;
+ dev_t.t_oe = t_oe * 1000;
+ dev_t.t_cez_r = t_cez * 1000;
+ dev_t.t_cez_w = dev_t.t_cez_r;
+ dev_t.t_wpl = t_wpl * 1000;
+ dev_t.t_wph = t_wph * 1000;
+
+ gpmc_calc_timings(t, dev_t);
return t;
}
@@ -172,16 +162,15 @@ static struct gpmc_timings
omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
int freq)
{
+ struct gpmc_device_timings dev_t;
struct gpmc_timings t;
const int t_cer = 15;
const int t_avdp = 12;
const int t_cez = 20; /* max of t_cez, t_oez */
- const int t_ds = 30;
const int t_wpl = 40;
const int t_wph = 30;
int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
- int div, fclk_offset_ns, fclk_offset, gpmc_clk_ns;
- int ticks_cez;
+ int div, gpmc_clk_ns;
if (cfg-flags ONENAND_SYNC_READ)
onenand_flags = ONENAND_FLAG_SYNCREAD;
@@ -248,62 +237,35 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
latency = 4;
/* Set synchronous read timings */
- memset(t, 0, sizeof(t));
-
- if (div == 1) {
- t.bool_timings.cs_extra_delay = true;
- t.bool_timings.adv_extra_delay = true;
- t.bool_timings.oe_extra_delay = true;
- t.bool_timings.we_extra_delay = true;
- }
+ memset(dev_t, 0, sizeof(dev_t));
- t.sync_clk = min_gpmc_clk_period;
- t.cs_on = 0;
- t.adv_on = 0;
- fclk_offset_ns = gpmc_round_ns_to_ticks(max_t(int, t_ces, t_avds));
- fclk_offset = gpmc_ns_to_ticks(fclk_offset_ns);
- t.page_burst_access = gpmc_clk_ns;
-
- /* Read */
- t.adv_rd_off = gpmc_ticks_to_ns(fclk_offset + gpmc_ns_to_ticks(t_avdh));
- t.oe_on = gpmc_ticks_to_ns(fclk_offset + gpmc_ns_to_ticks(t_ach));
- /* Force at least 1 clk between AVD High to OE Low */
- if (t.oe_on = t.adv_rd_off)
- t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(1);
- t.access = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div);
- t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
- t.cs_rd_off = t.oe_off;
- ticks_cez = ((gpmc_ns_to_ticks(t_cez) + div - 1) / div) * div;
- t.rd_cycle = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div +
-ticks_cez);
-
- t.clk_activation = fclk_offset_ns;
-
- /* Write */
+ dev_t.mux = true;
+ dev_t.sync_read = true;
if (onenand_flags ONENAND_FLAG_SYNCWRITE) {
-
[PATCH 3/4] ARM: OMAP2+: smc91x: generic timing calculation
Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-smc91x.c | 43 ---
1 file changed, 17 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c
b/arch/arm/mach-omap2/gpmc-smc91x.c
index 6eed907..11d0b75 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -58,6 +58,7 @@ static struct platform_device gpmc_smc91x_device = {
static int smc91c96_gpmc_retime(void)
{
struct gpmc_timings t;
+ struct gpmc_device_timings dev_t;
const int t3 = 10; /* Figure 12.2 read and 12.4 write */
const int t4_r = 20;/* Figure 12.2 read */
const int t4_w = 5; /* Figure 12.4 write */
@@ -68,32 +69,6 @@ static int smc91c96_gpmc_retime(void)
const int t20 = 185;/* Figure 12.2 read and 12.4 write */
u32 l;
- memset(t, 0, sizeof(t));
-
- /* Read timings */
- t.cs_on = 0;
- t.adv_on = t.cs_on;
- t.oe_on = t.adv_on + t3;
- t.access = t.oe_on + t5;
- t.oe_off = t.access;
- t.adv_rd_off = t.oe_off + max(t4_r, t6);
- t.cs_rd_off = t.oe_off;
- t.rd_cycle = t20 - t.oe_on;
-
- /* Write timings */
- t.we_on = t.adv_on + t3;
-
- if (cpu_is_omap34xx() (gpmc_cfg-flags GPMC_MUX_ADD_DATA)) {
- t.wr_data_mux_bus = t.we_on;
- t.we_off = t.wr_data_mux_bus + t7;
- } else
- t.we_off = t.we_on + t7;
- if (cpu_is_omap34xx())
- t.wr_access = t.we_off;
- t.adv_wr_off = t.we_off + max(t4_w, t8);
- t.cs_wr_off = t.we_off + t4_w;
- t.wr_cycle = t20 - t.we_on;
-
l = GPMC_CONFIG1_DEVICESIZE_16;
if (gpmc_cfg-flags GPMC_MUX_ADD_DATA)
l |= GPMC_CONFIG1_MUXADDDATA;
@@ -115,6 +90,22 @@ static int smc91c96_gpmc_retime(void)
if (gpmc_cfg-flags GPMC_MUX_ADD_DATA)
return 0;
+ memset(dev_t, 0, sizeof(dev_t));
+
+ dev_t.t_oeasu = t3 * 1000;
+ dev_t.t_oe = t5 * 1000;
+ dev_t.t_cez_r = t4_r * 1000;
+ dev_t.t_oez = t6 * 1000;
+ dev_t.t_rd_cycle = (t20 - t3) * 1000;
+
+ dev_t.t_weasu = t3 * 1000;
+ dev_t.t_wpl = t7 * 1000;
+ dev_t.t_wph = t8 * 1000;
+ dev_t.t_cez_w = t4_w * 1000;
+ dev_t.t_wr_cycle = (t20 - t3) * 1000;
+
+ gpmc_calc_timings(t, dev_t);
+
return gpmc_cs_set_timings(gpmc_cfg-cs, t);
}
--
1.7.12
--
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 4/4] ARM: OMAP2+: tusb6010: generic timing calculation
Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/usb-tusb6010.c | 182 +
1 file changed, 44 insertions(+), 138 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c
b/arch/arm/mach-omap2/usb-tusb6010.c
index 8ee73fc..4c7d7b5 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -26,182 +26,88 @@ static u8 async_cs, sync_cs;
static unsignedrefclk_psec;
-/* t2_ps, when quantized to fclk units, must happen no earlier than
- * the clock after after t1_NS.
- *
- * Return a possibly updated value of t2_ps, converted to nsec.
- */
-static unsigned
-next_clk(unsigned t1_NS, unsigned t2_ps, unsigned fclk_ps)
-{
- unsignedt1_ps = t1_NS * 1000;
- unsignedt1_f, t2_f;
-
- if ((t1_ps + fclk_ps) t2_ps)
- return t2_ps / 1000;
-
- t1_f = (t1_ps + fclk_ps - 1) / fclk_ps;
- t2_f = (t2_ps + fclk_ps - 1) / fclk_ps;
-
- if (t1_f = t2_f)
- t2_f = t1_f + 1;
-
- return (t2_f * fclk_ps) / 1000;
-}
-
/* NOTE: timings are from tusb 6010 datasheet Rev 1.8, 12-Sept 2006 */
-static int tusb_set_async_mode(unsigned sysclk_ps, unsigned fclk_ps)
+static int tusb_set_async_mode(unsigned sysclk_ps)
{
+ struct gpmc_device_timings dev_t;
struct gpmc_timings t;
unsignedt_acsnh_advnh = sysclk_ps + 3000;
- unsignedtmp;
-
- memset(t, 0, sizeof(t));
-
- /* CS_ON = t_acsnh_acsnl */
- t.cs_on = 8;
- /* ADV_ON = t_acsnh_advnh - t_advn */
- t.adv_on = next_clk(t.cs_on, t_acsnh_advnh - 7000, fclk_ps);
-
- /*
-* READ ... from omap2420 TRM fig 12-13
-*/
-
- /* ADV_RD_OFF = t_acsnh_advnh */
- t.adv_rd_off = next_clk(t.adv_on, t_acsnh_advnh, fclk_ps);
-
- /* OE_ON = t_acsnh_advnh + t_advn_oen (then wait for nRDY) */
- t.oe_on = next_clk(t.adv_on, t_acsnh_advnh + 1000, fclk_ps);
-
- /* ACCESS = counters continue only after nRDY */
- tmp = t.oe_on * 1000 + 300;
- t.access = next_clk(t.oe_on, tmp, fclk_ps);
-
- /* OE_OFF = after data gets sampled */
- tmp = t.access * 1000;
- t.oe_off = next_clk(t.access, tmp, fclk_ps);
-
- t.cs_rd_off = t.oe_off;
-
- tmp = t.cs_rd_off * 1000 + 7000 /* t_acsn_rdy_z */;
- t.rd_cycle = next_clk(t.cs_rd_off, tmp, fclk_ps);
-
- /*
-* WRITE ... from omap2420 TRM fig 12-15
-*/
- /* ADV_WR_OFF = t_acsnh_advnh */
- t.adv_wr_off = t.adv_rd_off;
+ memset(dev_t, 0, sizeof(dev_t));
- /* WE_ON = t_acsnh_advnh + t_advn_wen (then wait for nRDY) */
- t.we_on = next_clk(t.adv_wr_off, t_acsnh_advnh + 1000, fclk_ps);
+ dev_t.mux = true;
- /* WE_OFF = after data gets sampled */
- tmp = t.we_on * 1000 + 300;
- t.we_off = next_clk(t.we_on, tmp, fclk_ps);
+ dev_t.t_ceasu = 8 * 1000;
+ dev_t.t_avdasu = t_acsnh_advnh - 7000;
+ dev_t.t_ce_avd = 1000;
+ dev_t.t_avdp_r = t_acsnh_advnh;
+ dev_t.t_oeasu = t_acsnh_advnh + 1000;
+ dev_t.t_oe = 300;
+ dev_t.t_cez_r = 7000;
+ dev_t.t_cez_w = dev_t.t_cez_r;
+ dev_t.t_avdp_w = t_acsnh_advnh;
+ dev_t.t_weasu = t_acsnh_advnh + 1000;
+ dev_t.t_wpl = 300;
+ dev_t.cyc_aavdh_we = 1;
- t.cs_wr_off = t.we_off;
-
- tmp = t.cs_wr_off * 1000 + 7000 /* t_acsn_rdy_z */;
- t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
+ gpmc_calc_timings(t, dev_t);
return gpmc_cs_set_timings(async_cs, t);
}
-static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned fclk_ps)
+static int tusb_set_sync_mode(unsigned sysclk_ps)
{
+ struct gpmc_device_timings dev_t;
struct gpmc_timings t;
unsignedt_scsnh_advnh = sysclk_ps + 3000;
- unsignedtmp;
-
- memset(t, 0, sizeof(t));
- t.cs_on = 8;
-
- /* ADV_ON = t_acsnh_advnh - t_advn */
- t.adv_on = next_clk(t.cs_on, t_scsnh_advnh - 7000, fclk_ps);
-
- /* GPMC_CLK rate = fclk rate / div */
- t.sync_clk = 11100 /* 11.1 nsec */;
- tmp = (t.sync_clk + fclk_ps - 1) / fclk_ps;
- if (tmp 4)
- return -ERANGE;
- if (tmp == 0)
- tmp = 1;
- t.page_burst_access = (fclk_ps * tmp) / 1000;
-
- /*
-* READ ... based on omap2420 TRM fig 12-19, 12-20
-*/
-
- /* ADV_RD_OFF = t_scsnh_advnh */
- t.adv_rd_off = next_clk(t.adv_on, t_scsnh_advnh, fclk_ps);
-
- /* OE_ON = t_scsnh_advnh + t_advn_oen * fclk_ps (then wait for nRDY) */
- tmp = (t.adv_rd_off * 1000) + (3 * fclk_ps);
- t.oe_on = next_clk(t.adv_on, tmp, fclk_ps);
-
- /* ACCESS = number of clock cycles after t_adv_eon */
- tmp = (t.oe_on * 1000) + (5
[PATCH 15/32 v2] USB: ohci: merge ohci_finish_controller_resume with ohci_resume
Merge ohci_finish_controller_resume with ohci_resume as suggested by Alan
Stern. Since ohci_finish_controller_resume no longer exists, update the
various OHCI drivers to call ohci_resume() instead. Some drivers used to set
themselves the bit HCD_FLAG_HW_ACCESSIBLE, which is now handled by
ohci_resume().
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
Changes since v1:
- added Nicolas and Jingoo's Acked-by
drivers/usb/host/ohci-at91.c |2 +-
drivers/usb/host/ohci-ep93xx.c |2 +-
drivers/usb/host/ohci-exynos.c |5 +
drivers/usb/host/ohci-hcd.c | 41 +++--
drivers/usb/host/ohci-hub.c | 42 --
drivers/usb/host/ohci-omap.c |2 +-
drivers/usb/host/ohci-platform.c |2 +-
drivers/usb/host/ohci-pxa27x.c |2 +-
drivers/usb/host/ohci-s3c2410.c |3 +--
drivers/usb/host/ohci-spear.c|2 +-
drivers/usb/host/ohci-tmio.c |2 +-
11 files changed, 48 insertions(+), 57 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 0bf72f9..908d84a 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -705,7 +705,7 @@ static int ohci_hcd_at91_drv_resume(struct platform_device
*pdev)
if (!clocked)
at91_start_clock();
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
#else
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index dbfbd1d..a982f04 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -194,7 +194,7 @@ static int ohci_hcd_ep93xx_drv_resume(struct
platform_device *pdev)
ep93xx_start_hc(pdev-dev);
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
#endif
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index fc3091b..53c5a989 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -252,10 +252,7 @@ static int exynos_ohci_resume(struct device *dev)
if (pdata pdata-phy_init)
pdata-phy_init(pdev, S5P_USB_PHY_HOST);
- /* Mark hardware accessible again as we are out of D3 state by now */
- set_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
-
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index acf8c83..d97dc48 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1005,13 +1005,50 @@ static int __maybe_unused ohci_suspend(struct usb_hcd
*hcd, bool do_wakeup)
static int __maybe_unused ohci_resume(struct usb_hcd *hcd, bool hibernated)
{
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ int port;
+ boolneed_reinit = false;
+
set_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
/* Make sure resume from hibernation re-enumerates everything */
if (hibernated)
- ohci_usb_reset(hcd_to_ohci(hcd));
+ ohci_usb_reset(ohci);
+
+ /* See if the controller is already running or has been reset */
+ ohci-hc_control = ohci_readl(ohci, ohci-regs-control);
+ if (ohci-hc_control (OHCI_CTRL_IR | OHCI_SCHED_ENABLES)) {
+ need_reinit = true;
+ } else {
+ switch (ohci-hc_control OHCI_CTRL_HCFS) {
+ case OHCI_USB_OPER:
+ case OHCI_USB_RESET:
+ need_reinit = true;
+ }
+ }
+
+ /* If needed, reinitialize and suspend the root hub */
+ if (need_reinit) {
+ spin_lock_irq(ohci-lock);
+ ohci_rh_resume(ohci);
+ ohci_rh_suspend(ohci, 0);
+ spin_unlock_irq(ohci-lock);
+ }
+
+ /* Normally just turn on port power and enable interrupts */
+ else {
+ ohci_dbg(ohci, powerup ports\n);
+ for (port = 0; port ohci-num_ports; port++)
+ ohci_writel(ohci, RH_PS_PPS,
+ ohci-regs-roothub.portstatus[port]);
+
+ ohci_writel(ohci, OHCI_INTR_MIE, ohci-regs-intrenable);
+ ohci_readl(ohci, ohci-regs-intrenable);
+ msleep(20);
+ }
+
+ usb_hcd_resume_root_hub(hcd);
- ohci_finish_controller_resume(hcd);
return 0;
}
diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
index 2f3619e..db09dae 100644
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -316,48 +316,6 @@ static int ohci_bus_resume (struct usb_hcd *hcd)
return rc;
}
-/* Carry out the final steps of resuming the controller device */
-static void __maybe_unused
Re: MUSB regression in linux next at least for pandboard
* Tony Lindgren t...@atomide.com [121004 18:41]: Also on the EHCI port, I've seen issues where unplugging the cable hangs kernel with an infinite loop. But that happens only occasionally, sorry does not seem to happen right now so no output to paste here. Or maybe this issue has already been fixed? Looks like the system eventually recovers from the EHCI issue after about fivew minutes or so of spamming the logs. It seems the ehci-omap errors are: [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31 [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule More data below. Regards, Tony ... [62927.200012] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 19 [62927.215606] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 25 [62927.220092] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 22 [62927.225738] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes [62927.232238] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 17 [62927.236633] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 18 [62927.241119] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 3 [62927.251098] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 18 [62927.258605] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 12 [62927.264343] usb 1-1.3.7.5: link qh8-0e01/ea5632c0 start 6 [1/2 us] [62927.274353] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 17 [62927.276092] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 24 [62927.280700] usb 1-1.3.7: clear tt 4 (0120) error -71 [62927.289245] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62927.292633] usb 1-1.3.7: clear tt buffer port 4, a18 ep0 t00080248 [62927.296356] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 26 [62927.302368] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 6 [62927.307098] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 24 [62927.308258] hid-generic 0003:047D:1020.000C: can't reset device, ehci-omap.0-1.3.7.4/input0, status -1 [62927.317230] usb 1-1.3.7: clear tt buffer port 5, a26 ep0 t00080248 [62927.322357] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 18 [62927.324981] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 5 [62927.330718] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 9 [62927.336364] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 20 [62927.348114] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31 [62927.349090] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 5 [62927.356475] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 26 [62927.368469] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62927.372253] usb 1-1.3.7: clear tt buffer port 4, a18 ep0 t00080248 [62926.616607] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 29 [62926.622863] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 10 [62926.627746] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 29 [62926.628112] ehci-omap ehci-omap.0: devpath 1.3.7.4 ep0out 3strikes [62926.639404] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 14 [62926.643737] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 29 [62926.651123] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 15 [62926.655609] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 18 [62926.660125] usb 1-1.3.7: clear tt buffer port 4, a18 ep0 t00080248 [62926.667480] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 15 [62926.669982] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 1 [62926.680603] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 3 [62926.686126] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 14 [62926.693237] usb 1-1.3.7: clear tt buffer port 5, a26 ep0 t00080248 [62926.694091] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 4 [62926.706359] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62926.709350] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 7 [62926.712554] usb 1-1.3.7: clear tt 4 (0120) error -71 [62926.714599] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 16 [62926.720855] ehci-omap ehci-omap.0: devpath 1.3.7.5 ep0out 3strikes [62926.729248] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62926.732238] usb 1-1.3.7: clear tt buffer port 4, a18 ep0 t00080248 [62926.736358] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes [62926.742736] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 9 [62926.755615] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 27 [62926.756744] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62926.763610] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 19 [62926.769226] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 29 [62926.780609] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62926.782745] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 19 [62926.789978] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 3
Re: omap DSS cmdline resolution not working for HDMI?
* Tomi Valkeinen tomi.valkei...@ti.com [121005 04:06]: On Thu, 2012-10-04 at 10:56 -0700, Tony Lindgren wrote: Hi, FYI, looks like for some reason DSS command line is not working for HDMI while it works for DSS. On my panda es I'm trying to set my motorola lapdock resolution from cmdline with: omapdss.def_disp=hdmi omapfb.mode=hdmi:1366x768@60 But it does not seem to do anything and resolution is VGA. If I change the cable to DVI port this works: omapdss.def_disp=dvi omapfb.mode=dvi:1366x768@60 Any ideas? This is with current linux next. That's because our HDMI only supports certain timings. To be honest, I don't really understand this restriction, as I believe the hardware should be able to use more or less any timings just like DVI. The 1366x768@60 mode is parsed with fbdev functions, which returns a video timings. These timings are then given to the HDMI driver, which tries to find matching timings from its timing table. And when it doesn't find a match, it fails. This is a known problem, and the hdmi driver would really need some love in other aspects also. I'm not sure what would be the best way to improve this without doing major rewrites. Perhaps the check in the hdmi driver could be more relaxed, but that needs some careful thought. OK, I'll take a look when I have a chance. I can change the HDMI resolution OK from userspace with: echo 1 /sys/devices/platform/omapdss/display1/enabled echo 0 /sys/devices/platform/omapdss/overlay0/enabled echo tv /sys/devices/platform/omapdss/overlay0/manager echo 1 /sys/devices/platform/omapdss/overlay0/enabled echo 85500,1366/70/213/143,768/3/24/3 /sys/devices/platform/omapdss/display1/timings That's because the above line has timings that are in the hdmi driver's table. They are somewhat different than what fbdev gives for 1366x768@60. OK The reason to use HDMI instead of DVI here is that HDMI also has the speakers on the lapdock ;) Then I'm able to switch between HDMI panel and DVI panel just fine using overlay0. I don't know if getting both HDMI and DVI to work the same time using overlay1 is supposed to work, but trying use overlay1 produces the following: HDMI and DVI cannot be used reliably at the same time, due to a HW issue we've had unresolved for a long time. Luckily, it was solved this week and we'll have a patch for next merge window to get this working. That's nice, I'll give that a try at some point. echo 1 /sys/devices/platform/omapdss/display0/enabled echo 0 /sys/devices/platform/omapdss/overlay1/enabled echo lcd2 /sys/devices/platform/omapdss/overlay1/manager echo 1 /sys/devices/platform/omapdss/overlay1/enabled echo 170666,1920/336/128/208,1200/38/1/3 /sys/devices/platform/omapdss/display0/timings [ 816.446044] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz [ 881.639221] omapdss APPLY: timeout in wait_pending_extra_info_updates [ 958.946594] [ cut here ] [ 958.953277] WARNING: at drivers/bus/omap_l3_noc.c:97 l3_interrupt_handler+0xc0/0x184() [ 958.965576] L3 standard error: TARGET:DMM2 at address 0x0 ... Having said the above, I don't quite know where this error comes from... Tiler (DMM) is not even used by omapfb. Looks like somehow also output_size won't change when changing display output from DVI to HDMI. If I boot with DVI panel at 1600x1200, then try to switch to the HDMI monitor with the following script: #!/bin/sh export dvi=display0 export hdmi=display1 export overlay=overlay0 echo 0 /sys/devices/platform/omapdss/$dvi/enabled echo 1 /sys/devices/platform/omapdss/$hdmi/enabled echo 85500,1366/70/213/143,768/3/24/3 /sys/devices/platform/omapdss/$hdmi/timings echo 0 /sys/devices/platform/omapdss/$overlay/enabled echo tv /sys/devices/platform/omapdss/$overlay/manager #echo 1366,768 /sys/devices/platform/omapdss/$overlay/output_size echo 1 /sys/devices/platform/omapdss/$overlay/enabled cat /sys/devices/platform/omapdss/$hdmi/timings cat /sys/devices/platform/omapdss/$overlay/output_size I get the following which may provide more clues: [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 = 13) [64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed [64370.849670] omapdss HDMI error: failed to power on device [64370.855407] omapdss error: failed to power on [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 = 13) [64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed [64370.880798] omapdss HDMI error: failed to power on device [64370.886505] omapdss error: failed to power on 85500,1366/70/213/143,768/3/24/3 1600,1200 FYI, I'm also seeing the DVI
[PATCH 09.5/16] mmc: omap: Remove cpu_is_omap usage from the driver
This is needed for the ARM common zImage support.
We can use the existing slot features to pass omap1
specific options to the driver. For omap2 we don't
want to pass anything new as that will be eventually
moved to use device tree based init.
Note that this patch depends on earlier patch that
moves plat/mmc.h into include/linux/platform_data.
Cc: Chris Ball c...@laptop.org
Cc: Venkatraman S svenk...@ti.com
Cc: linux-...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
Chris, I can set up a minimal immutable branch with omap
header changes that you can also pull into MMC tree if these
two MMC patches look ackable to you.
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -177,6 +177,13 @@ static int __init omap_mmc_add(const char *name, int id,
unsigned long base,
res[3].name = tx;
res[3].flags = IORESOURCE_DMA;
+ if (cpu_is_omap7xx())
+ data-slots[0].features = MMC_OMAP7XX;
+ if (cpu_is_omap15xx())
+ data-slots[0].features = MMC_OMAP15XX;
+ if (cpu_is_omap16xx())
+ data-slots[0].features = MMC_OMAP16XX;
+
ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
if (ret == 0)
ret = platform_device_add_data(pdev, data, sizeof(*data));
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -30,7 +30,6 @@
#include linux/slab.h
#include linux/platform_data/mmc-omap.h
-#include plat/cpu.h
#include plat/dma.h
#defineOMAP_MMC_REG_CMD0x00
@@ -73,6 +72,13 @@
#defineOMAP_MMC_STAT_CARD_BUSY (1 2)
#defineOMAP_MMC_STAT_END_OF_CMD(1 0)
+#define mmc_omap7xx() (host-features MMC_OMAP7XX)
+#define mmc_omap15xx() (host-features MMC_OMAP15XX)
+#define mmc_omap16xx() (host-features MMC_OMAP16XX)
+#define MMC_OMAP1_MASK (MMC_OMAP7XXX | MMC_OMAP15XX | MMC_OMAP16XX)
+#define mmc_omap1()(host-features MMC_OMAP1_MASK)
+#define mmc_omap2()(!mmc_omap1)
+
#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))
@@ -148,6 +154,7 @@ struct mmc_omap_host {
u32 buffer_bytes_left;
u32 total_bytes_left;
+ unsignedfeatures;
unsigneduse_dma:1;
unsignedbrs_received:1, dma_done:1;
unsigneddma_in_use:1;
@@ -989,7 +996,7 @@ mmc_omap_prepare_data(struct mmc_omap_host *host, struct
mmc_request *req)
* blocksize is at least that large. Blocksize is
* usually 512 bytes; but not for some SD reads.
*/
- burst = cpu_is_omap15xx() ? 32 : 64;
+ burst = mmc_omap15xx() ? 32 : 64;
if (burst data-blksz)
burst = data-blksz;
@@ -1105,8 +1112,7 @@ static void mmc_omap_set_power(struct mmc_omap_slot
*slot, int power_on,
if (slot-pdata-set_power != NULL)
slot-pdata-set_power(mmc_dev(slot-mmc), slot-id, power_on,
vdd);
-
- if (cpu_is_omap24xx()) {
+ if (mmc_omap2()) {
u16 w;
if (power_on) {
@@ -1240,7 +1246,7 @@ static int __devinit mmc_omap_new_slot(struct
mmc_omap_host *host, int id)
mmc-ops = mmc_omap_ops;
mmc-f_min = 40;
- if (cpu_class_is_omap2())
+ if (mmc_omap2())
mmc-f_max = 4800;
else
mmc-f_max = 2400;
@@ -1360,6 +1366,7 @@ static int __devinit mmc_omap_probe(struct
platform_device *pdev)
init_waitqueue_head(host-slot_wq);
host-pdata = pdata;
+ host-features = host-pdata-slots[0].features;
host-dev = pdev-dev;
platform_set_drvdata(pdev, host);
@@ -1392,7 +1399,7 @@ static int __devinit mmc_omap_probe(struct
platform_device *pdev)
host-dma_tx_burst = -1;
host-dma_rx_burst = -1;
- if (cpu_is_omap24xx())
+ if (mmc_omap2())
sig = host-id == 0 ? OMAP24XX_DMA_MMC1_TX :
OMAP24XX_DMA_MMC2_TX;
else
sig = host-id == 0 ? OMAP_DMA_MMC_TX : OMAP_DMA_MMC2_TX;
@@ -1408,7 +1415,7 @@ static int __devinit mmc_omap_probe(struct
platform_device *pdev)
dev_warn(host-dev, unable to obtain TX DMA engine channel
%u\n,
sig);
#endif
- if (cpu_is_omap24xx())
+ if (mmc_omap2())
sig = host-id == 0 ? OMAP24XX_DMA_MMC1_RX :
OMAP24XX_DMA_MMC2_RX;
else
sig = host-id == 0 ? OMAP_DMA_MMC_RX : OMAP_DMA_MMC2_RX;
@@ -1436,7 +1443,7 @@ static int __devinit mmc_omap_probe(struct
platform_device *pdev)
}
host-nr_slots = pdata-nr_slots;
Re: [PATCH 09/16] ARM: OMAP: Split plat/mmc.h into local headers and platform_data
* Venkatraman S svenk...@ti.com [121004 23:40]: On Fri, Oct 5, 2012 at 3:34 AM, Tony Lindgren t...@atomide.com wrote: We need to remove this from plat for ARM common zImage support. Cc: Chris Ball c...@laptop.org Cc: Venkatraman S svenk...@ti.com Cc: linux-...@vger.kernel.org Signed-off-by: Tony Lindgren t...@atomide.com Thanks Tony. I suppose this should go into your tree.. Acked-by: Venkatraman S svenk...@ti.com Thanks yeah it's probably best that I set up some minimal immutable branch that Chris can also pull in assuming these two MMC patches look OK. Regards, Tony -- 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 09.5/16] mmc: omap: Remove cpu_is_omap usage from the driver
Hi Tony, On Fri, Oct 05 2012, Tony Lindgren wrote: This is needed for the ARM common zImage support. We can use the existing slot features to pass omap1 specific options to the driver. For omap2 we don't want to pass anything new as that will be eventually moved to use device tree based init. Note that this patch depends on earlier patch that moves plat/mmc.h into include/linux/platform_data. Cc: Chris Ball c...@laptop.org Cc: Venkatraman S svenk...@ti.com Cc: linux-...@vger.kernel.org Signed-off-by: Tony Lindgren t...@atomide.com --- Chris, I can set up a minimal immutable branch with omap header changes that you can also pull into MMC tree if these two MMC patches look ackable to you. Thanks, sounds good. Acked-by: Chris Ball c...@laptop.org - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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] gpio/gpio-omap: Use existing pointer to struct device
Tobias Klauser tklau...@distanz.ch writes: A pointer to pdev-dev is already stored in dev, so use it in devm_kzalloc. Signed-off-by: Tobias Klauser tklau...@distanz.ch Acked-by: Kevin Hilman khil...@ti.com -- 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 09.5/16] mmc: omap: Remove cpu_is_omap usage from the driver
* Chris Ball c...@laptop.org [121005 11:24]:
Hi Tony,
On Fri, Oct 05 2012, Tony Lindgren wrote:
This is needed for the ARM common zImage support.
We can use the existing slot features to pass omap1
specific options to the driver. For omap2 we don't
want to pass anything new as that will be eventually
moved to use device tree based init.
Note that this patch depends on earlier patch that
moves plat/mmc.h into include/linux/platform_data.
Cc: Chris Ball c...@laptop.org
Cc: Venkatraman S svenk...@ti.com
Cc: linux-...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
Chris, I can set up a minimal immutable branch with omap
header changes that you can also pull into MMC tree if these
two MMC patches look ackable to you.
Thanks, sounds good.
Acked-by: Chris Ball c...@laptop.org
Thanks will do when -rc1 is available.
Looks like I posted a version before running stg refresh
that was missing two compile fixes: MMC_OMAP7XXX should be
MMC_OMAP7XX and !mmc_omap1 should be !mmc_omap1().
Updated patch below.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Thu, 4 Oct 2012 19:01:53 -0700
Subject: [PATCH] mmc: omap: Remove cpu_is_omap usage from the driver
This is needed for the ARM common zImage support.
We can use the existing slot features to pass omap1
specific options to the driver. For omap2 we don't
want to pass anything new as that will be eventually
moved to use device tree based init.
Note that this patch depends on earlier patch that
moves plat/mmc.h into include/linux/platform_data.
Cc: linux-...@vger.kernel.org
Cc: Venkatraman S svenk...@ti.com
Acked-by: Chris Ball c...@laptop.org
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 1cc4e18..f9c4fb9 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -177,6 +177,13 @@ static int __init omap_mmc_add(const char *name, int id,
unsigned long base,
res[3].name = tx;
res[3].flags = IORESOURCE_DMA;
+ if (cpu_is_omap7xx())
+ data-slots[0].features = MMC_OMAP7XX;
+ if (cpu_is_omap15xx())
+ data-slots[0].features = MMC_OMAP15XX;
+ if (cpu_is_omap16xx())
+ data-slots[0].features = MMC_OMAP16XX;
+
ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
if (ret == 0)
ret = platform_device_add_data(pdev, data, sizeof(*data));
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index e7c61b9..9f0e26f 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -30,7 +30,6 @@
#include linux/slab.h
#include linux/platform_data/mmc-omap.h
-#include plat/cpu.h
#include plat/dma.h
#defineOMAP_MMC_REG_CMD0x00
@@ -73,6 +72,13 @@
#defineOMAP_MMC_STAT_CARD_BUSY (1 2)
#defineOMAP_MMC_STAT_END_OF_CMD(1 0)
+#define mmc_omap7xx() (host-features MMC_OMAP7XX)
+#define mmc_omap15xx() (host-features MMC_OMAP15XX)
+#define mmc_omap16xx() (host-features MMC_OMAP16XX)
+#define MMC_OMAP1_MASK (MMC_OMAP7XX | MMC_OMAP15XX | MMC_OMAP16XX)
+#define mmc_omap1()(host-features MMC_OMAP1_MASK)
+#define mmc_omap2()(!mmc_omap1())
+
#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))
@@ -148,6 +154,7 @@ struct mmc_omap_host {
u32 buffer_bytes_left;
u32 total_bytes_left;
+ unsignedfeatures;
unsigneduse_dma:1;
unsignedbrs_received:1, dma_done:1;
unsigneddma_in_use:1;
@@ -989,7 +996,7 @@ mmc_omap_prepare_data(struct mmc_omap_host *host, struct
mmc_request *req)
* blocksize is at least that large. Blocksize is
* usually 512 bytes; but not for some SD reads.
*/
- burst = cpu_is_omap15xx() ? 32 : 64;
+ burst = mmc_omap15xx() ? 32 : 64;
if (burst data-blksz)
burst = data-blksz;
@@ -1105,8 +1112,7 @@ static void mmc_omap_set_power(struct mmc_omap_slot
*slot, int power_on,
if (slot-pdata-set_power != NULL)
slot-pdata-set_power(mmc_dev(slot-mmc), slot-id, power_on,
vdd);
-
- if (cpu_is_omap24xx()) {
+ if (mmc_omap2()) {
u16 w;
if (power_on) {
@@ -1240,7 +1246,7 @@ static int __devinit mmc_omap_new_slot(struct
mmc_omap_host *host, int id)
mmc-ops = mmc_omap_ops;
mmc-f_min = 40;
- if (cpu_class_is_omap2())
+ if (mmc_omap2())
mmc-f_max = 4800;
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
Hi, * Marc Zyngier marc.zyng...@arm.com [120907 10:04]: From: Dave Martin dave.mar...@linaro.org This patch does two things: * Ensure that asynchronous aborts are masked at kernel entry. The bootloader should be masking these anyway, but this reduces the damage window just in case it doesn't. * Enter svc mode via exception return to ensure that CPU state is properly serialised. This does not matter when switching from an ordinary privileged mode (PL1 modes in ARMv7-AR rev C parlance), but it potentially does matter when switching from a another privileged mode such as hyp mode. This should allow the kernel to boot safely either from svc mode or hyp mode, even if no support for use of the ARM Virtualization Extensions is built into the kernel. Signed-off-by: Dave Martin dave.mar...@linaro.org Signed-off-by: Marc Zyngier marc.zyng...@arm.com Just bisected this down in linux-next for breaking booting of my omap2420 ARMv6 based n8x0.. --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,8 +83,12 @@ ENTRY(stext) THUMB( .thumb ) @ switch to Thumb now. THUMB(1:) - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode - @ and irqs disabled +#ifdef CONFIG_ARM_VIRT_EXT + bl __hyp_stub_install +#endif + @ ensure svc mode and all interrupts masked + safe_svcmode_maskall r9 + mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid movsr10, r5 @ invalid processor (r5=0)? ..and looks like undoing this part fixes it. Any ideas? I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's ARMv6 but that does not help. Regards, Tony -- 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 0/7] uio_pruss cleanup and platform support
On Fri, Oct 05, 2012 at 04:43:56AM +, Hebbar, Gururaja wrote: Matt, On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote: On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote: Changes since v1: - Replaced uio_pruss private SRAM API use with genalloc - Added DA850 platform device and clock support - Added DA850 L3 RAM gen_pool support - Split out DT binding This series enables uio_pruss on both DA850 and AM33xx. The driver previously was not enabled by any platform and the private SRAM API was accessing an invalid SRAM bank for use on DA850. For AM33xx, DT, pinctrl, and runtime PM support are added since AM33xx only boots via DT. I'm dropping AM33xx/OMAP support from v3 for this series Just for my clarification, I believe you will be taking up AM33xx/OMAP SRAM support later once you have completed supporting DaVinci. Right? There's no SRAM support for uio_pruss to be handled for AM33xx, but I will be posting a separate series with the DT portion and some alternate hard reset handling implementation. I find the private OMAP reset api to be very ugly but we might have to go with that for now. I didn't want the OMAP hard reset portion to hold up the more important part of this cleanup. -Matt since the focus has turned to fixing Davinci SRAM to provide genalloc support and the associated use of that in the driver. I'll have a separate series with AM33xx support since dealing cleanly with external resets on OMAP is a bigger issue. -Matt ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Regards, Gururaja ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- 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] i2c: i2c-omap: fix interrupt flood during resume
+Grygorii (who's been working on various I2C related suspend/resume
issues also)
Hi Kalle,
Kalle Jokiniemi kalle.jokini...@jollamobile.com writes:
The resume_noirq enables interrupts one-by-one starting from
first one. Now if the wake up event for suspend came from i2c
device, the i2c bus irq gets enabled before the threaded
i2c device irq, causing a flood of i2c bus interrupts as the
threaded irq that should clear the event is not enabled yet.
Ugh, another reason we need some sort of driver dependency tracking in the
driver model.
Fixed the issue by adding suspend_late and resume_early
functions that keep i2c bus interrupts disabled until
resume_noirq has run completely.
Hmm, any reason we couldn't put the disable in the .suspend_noirq
callback? The reason being is that other drivers might use I2C in their
suspend or late_suspend callbacks. I'm not aware of any using I2C in
their late_suspend callbacks in mainline, but in theory I2C should work
all the way through the late callbacks.
I know it might look strange to have a disable_irq() in the noirq
callback, since IRQs are already disabled at that point, but a comment
stating that it's just there to balance the (re)enable in the
early_resume callback should be clear.
Some other minor comments below...
Issue was detected doing a wake up from autosleep with
twl4030 power key on N9. Patch tested on N9.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com
---
drivers/i2c/busses/i2c-omap.c | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..b77b0c2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1158,6 +1158,35 @@ omap_i2c_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_SUSPEND
This should be CONFIG_PM_SLEEP in order to cover hibernation also.
+static int omap_i2c_suspend_late(struct device *dev)
+{
+
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+
+ /*
+ * The noirq_resume enables the interrupts one by one,
+ * this causes a interrupt flood if the SW irq actually reading
+ * event from i2c device is enabled only after i2c bus irq, as the
+ * irq that should clear the event is still disabled. We have to
+ * disable the bus irq until all other irqs have been enabled.
+ */
This comment probably belongs in the resume handler.
+ disable_irq(_dev-irq);
+ return 0;
+}
+
+static int omap_i2c_resume_early(struct device *dev)
+{
+
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+
+ enable_irq(_dev-irq);
+
+ return 0;
+}
+#endif
#ifdef CONFIG_PM_RUNTIME
static int omap_i2c_runtime_suspend(struct device *dev)
{
@@ -1178,10 +1207,18 @@ static int omap_i2c_runtime_resume(struct device *dev)
return 0;
}
+#endif
+#if defined(CONFIG_SUSPEND) || defined(CONFIG_PM_RUNTIME)
#ifdef CONFIG_PM will cover this
static struct dev_pm_ops omap_i2c_pm_ops = {
+#ifdef CONFIG_SUSPEND
again, CONFIG_PM_SLEEP here
+ .suspend_late = omap_i2c_suspend_late,
+ .resume_early = omap_i2c_resume_early,
+#endif
+#ifdef CONFIG_PM_RUNTIME
.runtime_suspend = omap_i2c_runtime_suspend,
.runtime_resume = omap_i2c_runtime_resume,
+#endif
};
#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
#else
Kevin
--
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 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp
Hello.
On 05-10-2012 12:07, Kishon Vijay Abraham I wrote:
Platfrom device for ocp2scp is created using omap_device_build in
devices file. This is used for both omap4(musb) and omap5(dwc3).
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
arch/arm/mach-omap2/devices.c | 72 +
1 file changed, 72 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..e2ba505 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
[...]
@@ -613,6 +614,76 @@ static void omap_init_vout(void)
[...]
+static void omap_init_ocp2scp(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ int bus_id = -1, dev_cnt = 0, i;
+ struct omap_ocp2scp_dev *ocp2scp_dev;
+ const char *oh_name, *name;
+ struct omap_ocp2scp_platform_data *pdata;
+
+ oh_name = ocp2scp_usb_phy;
+ name= omap-ocp2scp;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(%s: could not find omap_hwmod for %s\n, __func__,
+ oh_name);
+ return;
+ }
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ pr_err(%s: No memory for ocp2scp pdata\n, __func__);
+ return;
+ }
+
+ ocp2scp_dev = oh-dev_attr;
+ dev_cnt = count_ocp2scp_devices(ocp2scp_dev);
+
+ if (!dev_cnt) {
+ pr_err(%s: No devices connected to ocp2scp\n, __func__);
+ return;
Don't you leak 'pdata' here?
+ }
+
+ pdata-devices = kzalloc(sizeof(struct omap_ocp2scp_dev *)
+ * dev_cnt, GFP_KERNEL);
+ if (!pdata-devices) {
+ pr_err(%s: No memory for ocp2scp pdata devices\n, __func__);
+ return;
+ }
+
+ for (i = 0; i dev_cnt; i++, ocp2scp_dev++)
+ pdata-devices[i] = ocp2scp_dev;
+
+ pdata-dev_cnt = dev_cnt;
+
+ pdev = omap_device_build(name, bus_id, oh, pdata, sizeof(*pdata), NULL,
+ 0, false);
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build omap_device for %s %s\n,
+ name, oh_name);
+ return;
Don't you leak 'pdata' and 'pdata-devices' here?
+ }
+}
WBR, Sergei
--
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 0/9] ARM: dts/OMAP: Pinmux audio configuration for OMAP4+
* Peter Ujfalusi peter.ujfal...@ti.com [121004 04:57]: Hello, u-boot recently stopped configuring 'non essential' pin mux. This change leaves the audio essential pins in non configured state which prevents the use of audio. The following series makes sure that the needed pins are configured correctly by the kernel on OMAP4 and OMAP5. Tony: can this series queued for 3.7? Let's see if that's possible to avoid mysterious bug reports of things not working. If we can't merge it, then it might be worth adding a warning that bails out early after some pin is checked or similar. Regards, Tony Regards, Peter --- Peter Ujfalusi (9): ARM: OMAP: board-4430-sdp: Pin mux configuration for audio needs ARM: OMAP: board-omap4panda: Pin mux configuration for audio needs ARM/dts: omap4-panda: Disable unused audio IPs ARM/dts: omap4-sdp: Disable unused McBSP3 ARM/dts: omap5-evm: Disable unused McBSP3 ARM/dts: omap4-sdp: pinmux configuration for audio ARM/dts: omap4-panda: pinmux configuration for audio ARM/dts: Add pinctrl driver entries for omap5 ARM/dts: omap5-evm: pinmux configuration for audio arch/arm/boot/dts/omap4-panda.dts | 47 +++ arch/arm/boot/dts/omap4-sdp.dts| 57 + arch/arm/boot/dts/omap5-evm.dts| 58 ++ arch/arm/boot/dts/omap5.dtsi | 17 ++ arch/arm/mach-omap2/board-4430sdp.c| 26 +++ arch/arm/mach-omap2/board-omap4panda.c | 15 + 6 files changed, 220 insertions(+) -- 1.7.12 -- 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/7] ARM: virt: allow the kernel to be entered in HYP mode
On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote: Just bisected this down in linux-next for breaking booting of my omap2420 ARMv6 based n8x0.. --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,8 +83,12 @@ ENTRY(stext) THUMB(.thumb ) @ switch to Thumb now. THUMB(1: ) - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode - @ and irqs disabled +#ifdef CONFIG_ARM_VIRT_EXT + bl __hyp_stub_install +#endif + @ ensure svc mode and all interrupts masked + safe_svcmode_maskall r9 + mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid movsr10, r5 @ invalid processor (r5=0)? ..and looks like undoing this part fixes it. Any ideas? I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's ARMv6 but that does not help. You really should Cc me when you hit something like this. I was thinking about sending my tree (which contains these changes) this evening but if they're breaking stuff, I'd prefer to delay that stuff at least for a while. -- 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/7] ARM: virt: allow the kernel to be entered in HYP mode
* Russell King - ARM Linux li...@arm.linux.org.uk [121005 16:10]: On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote: Just bisected this down in linux-next for breaking booting of my omap2420 ARMv6 based n8x0.. --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,8 +83,12 @@ ENTRY(stext) THUMB( .thumb ) @ switch to Thumb now. THUMB(1:) - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode - @ and irqs disabled +#ifdef CONFIG_ARM_VIRT_EXT + bl __hyp_stub_install +#endif + @ ensure svc mode and all interrupts masked + safe_svcmode_maskall r9 + mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid movsr10, r5 @ invalid processor (r5=0)? ..and looks like undoing this part fixes it. Any ideas? I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's ARMv6 but that does not help. You really should Cc me when you hit something like this. I was thinking about sending my tree (which contains these changes) this evening but if they're breaking stuff, I'd prefer to delay that stuff at least for a while. Sorry was planning to cc you for sure but forgot. Got any ideas what to try to fix this? Tony -- 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/7] ARM: virt: allow the kernel to be entered in HYP mode
* Tony Lindgren t...@atomide.com [121005 16:27]: * Russell King - ARM Linux li...@arm.linux.org.uk [121005 16:10]: On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote: Just bisected this down in linux-next for breaking booting of my omap2420 ARMv6 based n8x0.. --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,8 +83,12 @@ ENTRY(stext) THUMB(.thumb ) @ switch to Thumb now. THUMB(1: ) - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode - @ and irqs disabled +#ifdef CONFIG_ARM_VIRT_EXT + bl __hyp_stub_install +#endif + @ ensure svc mode and all interrupts masked + safe_svcmode_maskall r9 + mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid movsr10, r5 @ invalid processor (r5=0)? ..and looks like undoing this part fixes it. Any ideas? I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's ARMv6 but that does not help. The same kernel boots on 2430sdp, which is the same ARMv6 core as 2430 if I remember correctly. So this hints that it has something to do with the bits set differently by the bootloader? Regards, Tony -- 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/7] ARM: virt: allow the kernel to be entered in HYP mode
On Fri, 5 Oct 2012, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [121005 16:27]: * Russell King - ARM Linux li...@arm.linux.org.uk [121005 16:10]: On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote: Just bisected this down in linux-next for breaking booting of my omap2420 ARMv6 based n8x0.. --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,8 +83,12 @@ ENTRY(stext) THUMB( .thumb ) @ switch to Thumb now. THUMB(1:) - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode - @ and irqs disabled +#ifdef CONFIG_ARM_VIRT_EXT + bl __hyp_stub_install +#endif + @ ensure svc mode and all interrupts masked + safe_svcmode_maskall r9 + mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid movsr10, r5 @ invalid processor (r5=0)? ..and looks like undoing this part fixes it. Any ideas? I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's ARMv6 but that does not help. The same kernel boots on 2430sdp, which is the same ARMv6 core as 2430 if I remember correctly. So this hints that it has something to do with the bits set differently by the bootloader? Possibly. What if you apply this on top: diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 683a1e6b60..b276c26e19 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -254,8 +254,7 @@ mov lr , \reg and lr , lr , #MODE_MASK cmp lr , #HYP_MODE - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT - bic \reg , \reg , #MODE_MASK + mov \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT orr \reg , \reg , #SVC_MODE THUMB( orr \reg , \reg , #PSR_T_BIT) msr spsr_cxsf, \reg Nicolas -- 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/7] ARM: virt: allow the kernel to be entered in HYP mode
* Nicolas Pitre nicolas.pi...@linaro.org [121005 18:33]: On Fri, 5 Oct 2012, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [121005 16:27]: * Russell King - ARM Linux li...@arm.linux.org.uk [121005 16:10]: On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote: Just bisected this down in linux-next for breaking booting of my omap2420 ARMv6 based n8x0.. --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,8 +83,12 @@ ENTRY(stext) THUMB(.thumb ) @ switch to Thumb now. THUMB(1: ) - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode - @ and irqs disabled +#ifdef CONFIG_ARM_VIRT_EXT + bl __hyp_stub_install +#endif + @ ensure svc mode and all interrupts masked + safe_svcmode_maskall r9 + mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid movsr10, r5 @ invalid processor (r5=0)? ..and looks like undoing this part fixes it. Any ideas? I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's ARMv6 but that does not help. The same kernel boots on 2430sdp, which is the same ARMv6 core as 2430 if I remember correctly. So this hints that it has something to do with the bits set differently by the bootloader? Possibly. What if you apply this on top: diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 683a1e6b60..b276c26e19 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -254,8 +254,7 @@ mov lr , \reg and lr , lr , #MODE_MASK cmp lr , #HYP_MODE - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT - bic \reg , \reg , #MODE_MASK + mov \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT orr \reg , \reg , #SVC_MODE THUMB( orr \reg , \reg , #PSR_T_BIT) msr spsr_cxsf, \reg Thanks but that does not seem to help. Regards, Tony -- 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
