Re: [PATCH 8/9 v3] usb : musb: Using runtime pm apis for musb.
On Fri, Sep 24, 2010 at 09:49:34AM -0500, Sergei Shtylyov wrote: Hello. Felipe Balbi wrote: I guess that's Felipe's call, but I don't like that option. I think it's cleaner to have the -set_clock hook be a noop on OMAP and the runtime hooks be noops on the other platforms. Agreed. We should focus on removing -set_clock for .38 actually. Is DaVinci already using clkdev, Kevin ? Sure. But DaVinci doesn't use -set_clock(). Ok, so seems like no-one is actually using that. We can already start patching to remove that thing, later on, we need to remove the clock name via platform_data. -- balbi -- 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] OMAP: PM: CPUFREQ: Fix conditional compilation
On Fri, Sep 24, 2010 at 8:36 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Silesh C V sil...@ti.com writes: Fix conditional compilation. What excatly was the compile error? and with which compiler? There is no compiler error.But what we need after an #elif is a conditional expression. The correct usage is #elif defined(CONFIG_XXX) rather than #elif CONFIG_XXX. Further, if the kernel is configured for a non-omap3 arch (eg.OMAP4), you get a compiler warning: arch/arm/plat-omap/cpu-omap.c:47:7: warning: CONFIG_ARCH_OMAP3 is not defined which goes away with this patch. The current pm branch seems to compile fine for me. Kevin Thanks, Silesh. -- 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 v2 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB
This lets omap_vout driver build and run without VRFB. It works along the lines of the following patch series: OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB https://patchwork.kernel.org/patch/105371/ Since VRFB is tightly coupled with the omap_vout driver, a handful of vrfb specific functions have been defined and placed in omap_vout_vrfb.c A variable rotation_type is introduced in omapvideo_info like the way in omapfb_info, this allows to call vrfb specific functions only if the rotation type is vrfb. When the rotation_type is set to SDMA, the S_CTRL ioctl prevents the user setting a non zero rotation value. Archit Taneja (2): V4L/DVB: OMAP_VOUT: Create a seperate vrfb functions library V4L/DVB: OMAP_VOUT: Use rotation_type to choose between vrfb and sdram buffers drivers/media/video/omap/Kconfig |1 - drivers/media/video/omap/Makefile |1 + drivers/media/video/omap/omap_vout.c | 480 ++--- drivers/media/video/omap/omap_vout_vrfb.c | 417 + drivers/media/video/omap/omap_vout_vrfb.h | 40 +++ drivers/media/video/omap/omap_voutdef.h | 26 ++ 6 files changed, 571 insertions(+), 394 deletions(-) create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h -- Version 2: - Don't try to enable SDRAM rotation , return an error if non zero rotation is attempted when rotation_type is set to SDMA rotation. Version 1: http://www.mail-archive.com/linux-me...@vger.kernel.org/msg21937.html -- 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 v2 1/2] V4L/DVB: OMAP_VOUT: Create a seperate vrfb functions library
Create omap_vout_vrfb.c and omap_vout_vrfb.h, these contain functions which
omap_vout will call if the rotation type is set to VRFB rotation. It is
essentialy the code in omap_vout which is used for vrfb specific tasks.
Apart from this, some functions and preprocessor defines needed by the new
vrfb function's have been moved around.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 32 +--
drivers/media/video/omap/omap_vout_vrfb.c | 417 +
drivers/media/video/omap/omap_vout_vrfb.h | 40 +++
drivers/media/video/omap/omap_voutdef.h | 25 ++
4 files changed, 490 insertions(+), 24 deletions(-)
create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c
create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 4ed51b1..46bc642
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -56,7 +56,6 @@ MODULE_AUTHOR(Texas Instruments);
MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
MODULE_LICENSE(GPL);
-
/* Driver Configuration macros */
#define VOUT_NAME omap_vout
@@ -65,28 +64,13 @@ enum omap_vout_channels {
OMAP_VIDEO2,
};
-enum dma_channel_state {
- DMA_CHAN_NOT_ALLOTED,
- DMA_CHAN_ALLOTED,
-};
-
#define QQVGA_WIDTH160
#define QQVGA_HEIGHT 120
-/* Max Resolution supported by the driver */
-#define VID_MAX_WIDTH 1280/* Largest width */
-#define VID_MAX_HEIGHT 720 /* Largest height */
-
/* Mimimum requirement is 2x2 for DSS */
#define VID_MIN_WIDTH 2
#define VID_MIN_HEIGHT 2
-/* 2048 x 2048 is max res supported by OMAP display controller */
-#define MAX_PIXELS_PER_LINE 2048
-
-#define VRFB_TX_TIMEOUT 1000
-#define VRFB_NUM_BUFS 4
-
/* Max buffer size tobe allocated during init */
#define OMAP_VOUT_MAX_BUF_SIZE (VID_MAX_WIDTH*VID_MAX_HEIGHT*4)
@@ -96,8 +80,8 @@ static u32 video1_numbuffers = 3;
static u32 video2_numbuffers = 3;
static u32 video1_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
static u32 video2_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
-static u32 vid1_static_vrfb_alloc;
-static u32 vid2_static_vrfb_alloc;
+u32 vid1_static_vrfb_alloc;
+u32 vid2_static_vrfb_alloc;
static int debug;
/* Module parameters */
@@ -174,7 +158,7 @@ const static struct v4l2_fmtdesc omap_formats[] = {
/*
* Allocate buffers
*/
-static unsigned long omap_vout_alloc_buffer(u32 buf_size, u32 *phys_addr)
+unsigned long omap_vout_alloc_buffer(u32 buf_size, u32 *phys_addr)
{
u32 order, size;
unsigned long virt_addr, addr;
@@ -198,7 +182,7 @@ static unsigned long omap_vout_alloc_buffer(u32 buf_size,
u32 *phys_addr)
/*
* Free buffers
*/
-static void omap_vout_free_buffer(unsigned long virtaddr, u32 buf_size)
+void omap_vout_free_buffer(unsigned long virtaddr, u32 buf_size)
{
u32 order, size;
unsigned long addr = virtaddr;
@@ -371,7 +355,7 @@ static void omap_vout_release_vrfb(struct omap_vout_device
*vout)
/*
* Return true if rotation is 90 or 270
*/
-static inline int rotate_90_or_270(const struct omap_vout_device *vout)
+int rotate_90_or_270(const struct omap_vout_device *vout)
{
return (vout-rotation == dss_rotation_90_degree ||
vout-rotation == dss_rotation_270_degree);
@@ -380,7 +364,7 @@ static inline int rotate_90_or_270(const struct
omap_vout_device *vout)
/*
* Return true if rotation is enabled
*/
-static inline int rotation_enabled(const struct omap_vout_device *vout)
+int rotation_enabled(const struct omap_vout_device *vout)
{
return vout-rotation || vout-mirror;
}
@@ -388,7 +372,7 @@ static inline int rotation_enabled(const struct
omap_vout_device *vout)
/*
* Reverse the rotation degree if mirroring is enabled
*/
-static inline int calc_rotation(const struct omap_vout_device *vout)
+int calc_rotation(const struct omap_vout_device *vout)
{
if (!vout-mirror)
return vout-rotation;
@@ -408,7 +392,7 @@ static inline int calc_rotation(const struct
omap_vout_device *vout)
/*
* Free the V4L2 buffers
*/
-static void omap_vout_free_buffers(struct omap_vout_device *vout)
+void omap_vout_free_buffers(struct omap_vout_device *vout)
{
int i, numbuffers;
diff --git a/drivers/media/video/omap/omap_vout_vrfb.c
b/drivers/media/video/omap/omap_vout_vrfb.c
new file mode 100644
index 000..1e6d8a7
--- /dev/null
+++ b/drivers/media/video/omap/omap_vout_vrfb.c
@@ -0,0 +1,417 @@
+/*
+ * omap_vout_vrfb.c
+ *
+ * Copyright (C) 2010 Texas Instruments.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/sched.h
+#include
[PATCH v2 2/2] V4L/DVB: OMAP_VOUT: Use rotation_type to choose between vrfb and sdram buffers
Add rotation_type member to omapvideo_info, this is initialized based on
the value def_vrfb bootarg parameter, vrfb rotation is chosen by default.
The rotation_type var is now used to choose between vrfb and non-vrfb calls.
vrfb specific code in omap_vout has been removed and is present in
omap_vout_vrfb.c
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/Kconfig|1 -
drivers/media/video/omap/Makefile |1 +
drivers/media/video/omap/omap_vout.c| 448 ++-
drivers/media/video/omap/omap_voutdef.h |1 +
4 files changed, 81 insertions(+), 370 deletions(-)
diff --git a/drivers/media/video/omap/Kconfig b/drivers/media/video/omap/Kconfig
index e63233f..d554bfd
--- a/drivers/media/video/omap/Kconfig
+++ b/drivers/media/video/omap/Kconfig
@@ -5,7 +5,6 @@ config VIDEO_OMAP2_VOUT
select VIDEOBUF_DMA_CONTIG
select OMAP2_DSS
select OMAP2_VRAM
- select OMAP2_VRFB
default n
---help---
V4L2 Display driver support for OMAP2/3 based boards.
diff --git a/drivers/media/video/omap/Makefile
b/drivers/media/video/omap/Makefile
index b287880..bc47569
--- a/drivers/media/video/omap/Makefile
+++ b/drivers/media/video/omap/Makefile
@@ -5,3 +5,4 @@
# OMAP2/3 Display driver
omap-vout-y := omap_vout.o omap_voutlib.o
obj-$(CONFIG_VIDEO_OMAP2_VOUT) += omap-vout.o
+obj-$(CONFIG_OMAP2_VRFB) += omap_vout_vrfb.o
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 46bc642..4d61ee0
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -51,6 +51,7 @@
#include omap_voutlib.h
#include omap_voutdef.h
+#include omap_vout_vrfb.h
MODULE_AUTHOR(Texas Instruments);
MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
@@ -82,6 +83,7 @@ static u32 video1_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
static u32 video2_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
u32 vid1_static_vrfb_alloc;
u32 vid2_static_vrfb_alloc;
+static int def_vrfb = 1;
static int debug;
/* Module parameters */
@@ -109,6 +111,10 @@ module_param(vid2_static_vrfb_alloc, bool, S_IRUGO);
MODULE_PARM_DESC(vid2_static_vrfb_alloc,
Static allocation of the VRFB buffer for video2 device);
+module_param(def_vrfb, bool, S_IRUGO);
+MODULE_PARM_DESC(def_vrfb,
+ decide if vrfb is used for rotation);
+
module_param(debug, bool, S_IRUGO);
MODULE_PARM_DESC(debug, Debug level (0-1));
@@ -199,41 +205,6 @@ void omap_vout_free_buffer(unsigned long virtaddr, u32
buf_size)
}
/*
- * Function for allocating video buffers
- */
-static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
- unsigned int *count, int startindex)
-{
- int i, j;
-
- for (i = 0; i *count; i++) {
- if (!vout-smsshado_virt_addr[i]) {
- vout-smsshado_virt_addr[i] =
- omap_vout_alloc_buffer(vout-smsshado_size,
- vout-smsshado_phy_addr[i]);
- }
- if (!vout-smsshado_virt_addr[i] startindex != -1) {
- if (V4L2_MEMORY_MMAP == vout-memory i = startindex)
- break;
- }
- if (!vout-smsshado_virt_addr[i]) {
- for (j = 0; j i; j++) {
- omap_vout_free_buffer(
- vout-smsshado_virt_addr[j],
- vout-smsshado_size);
- vout-smsshado_virt_addr[j] = 0;
- vout-smsshado_phy_addr[j] = 0;
- }
- *count = 0;
- return -ENOMEM;
- }
- memset((void *) vout-smsshado_virt_addr[i], 0,
- vout-smsshado_size);
- }
- return 0;
-}
-
-/*
* Try format
*/
static int omap_vout_try_format(struct v4l2_pix_format *pix)
@@ -326,33 +297,6 @@ static u32 omap_vout_uservirt_to_phys(u32 virtp)
}
/*
- * Wakes up the application once the DMA transfer to VRFB space is completed.
- */
-static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void *data)
-{
- struct vid_vrfb_dma *t = (struct vid_vrfb_dma *) data;
-
- t-tx_status = 1;
- wake_up_interruptible(t-wait);
-}
-
-/*
- * Release the VRFB context once the module exits
- */
-static void omap_vout_release_vrfb(struct omap_vout_device *vout)
-{
- int i;
-
- for (i = 0; i VRFB_NUM_BUFS; i++)
- omap_vrfb_release_ctx(vout-vrfb_context[i]);
-
- if (vout-vrfb_dma_tx.req_status == DMA_CHAN_ALLOTED) {
- vout-vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
- omap_free_dma(vout-vrfb_dma_tx.dma_ch);
- }
-}
-
-/*
* Return true if rotation is 90 or 270
*/
int rotate_90_or_270(const struct
Re: [RFC 4/5] OMAP4: mux: Select CBL package for SDP4430 with ES1
On 9/25/2010 1:14 AM, Anand Gadiyar wrote:
Benoit Cousson wrote:
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Tony Lindgrent...@atomide.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
---
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/board-4430sdp.c | 12
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 6aede64..4a8f897 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -240,6 +240,7 @@ config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
default y
depends on ARCH_OMAP4
+ select OMAP_PACKAGE_CBL
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..d087712 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -35,6 +35,8 @@
#includeplat/timer-gp.h
#includeplat/usb.h
#includeplat/mmc.h
+
+#include mux.h
#include hsmmc.h
#define ETH_KS8851_IRQ34
@@ -426,10 +428,20 @@ static int __init omap4_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init omap_4430sdp_init(void)
{
int status;
+ omap4_mux_init(board_mux, OMAP_PACKAGE_CBL);
omap4_i2c_init();
platform_add_devices(sdp4430_devices,
ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
Panda uses the same package I believe - I'll double check and update
that board file. I'll test this series tomorrow on both boards.
Probably, please note that there is a new CBS package for ES2.0.
I've just generated the data, I'll send you that ASAP, since I do not
have ES2 board to check that anyway :-(
Thanks,
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] OMAP: PM: CPUFREQ: Fix conditional compilation
On Mon, Sep 27, 2010 at 11:49 AM, Silesh C V sil...@ti.com wrote: On Fri, Sep 24, 2010 at 8:36 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Silesh C V sil...@ti.com writes: Fix conditional compilation. What excatly was the compile error? and with which compiler? There is no compiler error.But what we need after an #elif is a conditional expression. The correct usage is #elif defined(CONFIG_XXX) rather than #elif CONFIG_XXX. Further, if the kernel is configured for a non-omap3 arch (eg.OMAP4), you get a compiler warning: arch/arm/plat-omap/cpu-omap.c:47:7: warning: CONFIG_ARCH_OMAP3 is not defined which goes away with this patch. Silesh, which defconfig are you using with multi omap-build defconfig(omap3_defconfig) CONFIG_ARCH_OMAP3 will be enabled. So this compilation error will not occur. --- Regards, Govindraj.R The current pm branch seems to compile fine for me. Kevin Thanks, Silesh. -- 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 -- 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 1/4] omap4 hsmmc: Adding card detect support for MMC1
Hi Tony, On Sat, Sep 25, 2010 at 6:08 AM, Tony Lindgren t...@atomide.com wrote: * kishore kadiyala kishore.kadiy...@ti.com [100924 10:05]: Adding card detect callback function and card detect configuration function for MMC1 Controller on OMAP4. Card detect configuration function does initial configuration of the MMC Control PullUp-PullDown registers of Phoenix. For MMC1 Controller, card detect interrupt source is twl6030 which is non-gpio. The card detect call back function provides card present/absent status by reading MMC Control register present on twl6030. Since OMAP4 doesn't use any GPIO line as used in OMAP3 for card detect, the suspend/resume initialization which was done in omap_hsmmc_gpio_init previously is moved to the probe thus making it generic for both OMAP3 OMAP4. --- a/drivers/mfd/twl6030-irq.c +++ b/drivers/mfd/twl6030-irq.c Looks like this patch should be sent to Samuel Ortiz as it's mostly mfd related. Thanks , I will send this patch to Samuel. snip Regards, Kishore -- 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 1/4] omap4 hsmmc: Adding card detect support for MMC1
Cc: Samuel Ortiz sa...@linux.intel.com
On Fri, Sep 24, 2010 at 10:43 PM, kishore kadiyala
kishore.kadiy...@ti.com wrote:
Adding card detect callback function and card detect configuration
function for MMC1 Controller on OMAP4.
Card detect configuration function does initial configuration of the
MMC Control PullUp-PullDown registers of Phoenix.
For MMC1 Controller, card detect interrupt source is
twl6030 which is non-gpio. The card detect call back function provides
card present/absent status by reading MMC Control register present
on twl6030.
Since OMAP4 doesn't use any GPIO line as used in OMAP3 for card detect,
the suspend/resume initialization which was done in omap_hsmmc_gpio_init
previously is moved to the probe thus making it generic for both OMAP3
OMAP4.
Cc: Tony Lindgren t...@atomide.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 7 +++-
drivers/mfd/twl6030-irq.c | 73
+++
drivers/mmc/host/omap_hsmmc.c | 4 +-
include/linux/i2c/twl.h | 31 +++
4 files changed, 112 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..a49f285 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device
*dev)
struct omap_mmc_platform_data *pdata = dev-platform_data;
/* Setting MMC1 Card detect Irq */
- if (pdev-id == 0)
+ if (pdev-id == 0) {
+ ret = twl6030_mmc_card_detect_config();
+ if (ret)
+ pr_err(Failed configuring MMC1 card detect\n);
pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
+ pdata-slots[0].card_detect = twl6030_mmc_card_detect;
+ }
return ret;
}
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 10bf228..2d3bb82 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -36,6 +36,7 @@
#include linux/irq.h
#include linux/kthread.h
#include linux/i2c/twl.h
+#include linux/platform_device.h
/*
* TWL6030 (unlike its predecessors, which had two level interrupt handling)
@@ -223,6 +224,78 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect_config(void)
+{
+ int ret;
+ u8 reg_val = 0;
+
+ /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix */
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_LINE_B);
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_STS_B);
+ /*
+ * Intially Configuring MMC_CTRL for receving interrupts
+ * Card status on TWL6030 for MMC1
+ */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ pr_err(twl6030: Failed to read MMCCTRL, error %d\n, ret);
+ return ret;
+ }
+ reg_val = ~VMMC_AUTO_OFF;
+ reg_val |= SW_FC;
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ pr_err(twl6030: Failed to write MMCCTRL, error %d\n, ret);
+ return ret;
+ }
+
+ /* Configuring PullUp-PullDown register */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n,
+ ret);
+ return ret;
+ }
+ reg_val = ~(MMC_PU | MMC_PD);
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ pr_err(twl6030: Failed to write CFG_INPUT_PUPD3, error %d\n,
+ ret);
+ return ret;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(twl6030_mmc_card_detect_config);
+
+int twl6030_mmc_card_detect(struct device *dev, int slot)
+{
+ int ret = -EIO;
+ u8 read_reg = 0;
+ struct platform_device *pdev = to_platform_device(dev);
+
+ if (pdev-id) {
+ /* TWL6030 provide's Card detect support for
+ * only MMC1 controller.
+ */
+ pr_err(Unkown MMC controller
Re: [PATCH v3] power_supply: Add driver for TWL4030/TPS65950 BCI charger
Hi, please re-send this email without the HTML formatting. Please follow the netiquette [1]. [1] http://elinux.org/Netiquette -- balbi -- 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] OMAP: PM: CPUFREQ: Fix conditional compilation
On Mon, Sep 27, 2010 at 1:00 PM, Govindraj govindraj...@gmail.com wrote: On Mon, Sep 27, 2010 at 11:49 AM, Silesh C V sil...@ti.com wrote: On Fri, Sep 24, 2010 at 8:36 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Silesh C V sil...@ti.com writes: Fix conditional compilation. What excatly was the compile error? and with which compiler? There is no compiler error.But what we need after an #elif is a conditional expression. The correct usage is #elif defined(CONFIG_XXX) rather than #elif CONFIG_XXX. Further, if the kernel is configured for a non-omap3 arch (eg.OMAP4), you get a compiler warning: arch/arm/plat-omap/cpu-omap.c:47:7: warning: CONFIG_ARCH_OMAP3 is not defined which goes away with this patch. Silesh, which defconfig are you using with multi omap-build defconfig(omap3_defconfig) CONFIG_ARCH_OMAP3 will be enabled. So this compilation error will not occur. --- Regards, Govindraj.R As I said before there is no compilation error. But what we have to check for is whether CONFIG_ARCH_OMAP3 is defined or not. Not for the value of CONFIG_ARCH_OMAP3. We have to check for value of defined (CONFIG_ARCH_OMAP3). Otherwise compiler searches for the value of the macro and hence the warning(comes with a omap4 config).See how #elif + CONFIG_XXX is used elsewhere in kernel. Thanks, Silesh. -- 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 03/11] OMAP4: Add the new voltage to vsel calculation formula
-Original Message-
From: Manuel, Lesly Arackal
Sent: Monday, September 27, 2010 9:44 AM
To: Gopinath, Thara; linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: RE: [PATCH v2 03/11] OMAP4: Add the new voltage to vsel calculation
formula
Hi Thara,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Thara Gopinath
Sent: Saturday, September 25, 2010 6:21 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; b-cous...@ti.com;
vishwanath...@ti.com; saw...@ti.com; Thara Gopinath
Subject: [PATCH v2 03/11] OMAP4: Add the new voltage to vsel calculation
formula
TWL6030 the power IC used along with OMAP4 in OMAP4 SDPs,
blaze boards and panda boards has a different formula
from that of TWL4030 for voltage to vsel and
vsel to voltage calculation. This patch implements the new
formula depending on the PMIC type.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/opp_twl_tps.c | 71
++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/opp_twl_tps.c b/arch/arm/plat-
omap/opp_twl_tps.c
index 4448fc5..358b67b 100644
--- a/arch/arm/plat-omap/opp_twl_tps.c
+++ b/arch/arm/plat-omap/opp_twl_tps.c
@@ -15,9 +15,16 @@
#include linux/module.h
+#include linux/i2c/twl.h
+
#include plat/opp_twl_tps.h
#include plat/voltage.h
+static bool is_offset_valid;
+static u8 smps_offset;
+
+#define REG_SMPS_OFFSET 0xE0
+
/**
* omap_twl_vsel_to_vdc - convert TWL/TPS VSEL value to microvolts DC
* @vsel: TWL/TPS VSEL value to convert
@@ -27,6 +34,38 @@
*/
unsigned long omap_twl_vsel_to_uv(const u8 vsel)
{
+ if (twl_class_is_6030()) {
+ /*
+* In TWL6030 depending on the value of SMPS_OFFSET
+* efuse register the voltage range supported in
+* standard mode can be either between 0.6V - 1.3V or
+* 0.7V - 1.4V. In TWL6030 ES1.0 SMPS_OFFSET efuse
+* is programmed to all 0's where as starting from
+* TWL6030 ES1.1 the efuse is programmed to 1
+*/
+ if (!is_offset_valid) {
+ twl_i2c_read_u8(TWL6030_MODULE_ID0, smps_offset,
0xE0);
+ is_offset_valid = true;
+ }
Is it necessary to do the i2c read each time to check the smps_offset?
OR it can be done one time initially.
Hello Lesly,
It is not done every time. It is only done the first time omap_twl_vsel_to_uv
or omap_twl_uv_to_vsel is called. If is_offset_valid, we do not read the
register
via i2c interface.
Regards
Thara
--
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: [lm-sensors] [PATCH 1/2] hwmon: twl4030: Driver for twl4030 madc module
Hello Sameo, twl4030-madc driver patch can be found here: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34947.html Based on the received inputs. Can the twl4030-madc driver or part of the driver reside under mfd? Regards, Keerthy On Monday 20 September 2010 08:08 PM, Guenter Roeck wrote: On Mon, Sep 20, 2010 at 10:09:05AM -0400, Guenter Roeck wrote: Hi, On Mon, Sep 20, 2010 at 06:34:24AM -0400, J, KEERTHY wrote: -Original Message- From: Guenter Roeck [mailto:guenter.ro...@ericsson.com] Sent: Thursday, September 16, 2010 8:48 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; lm-sens...@lm-sensors.org; Krishnamoorthy, Balaji T Subject: Re: [lm-sensors] [PATCH 1/2] hwmon: twl4030: Driver for twl4030 madc module [...] +EXPORT_SYMBOL(twl4030_madc_conversion); + If this function is going to be called from external code, it should not really be defined here. I would suggest to move it to a global location such as mfd instead, including all related functions. The existence of this function export indicates that another non-hwmon driver depends on this one, which should not really be the case. Another reason to have a separate common driver instead, and mfd might just be the place for it. Few kernel modules need to perform ADC conversion to measure battery voltage, battery temperature, VBUS voltage via twl4030_madc_conversion. the_madc is needed as those drivers will not have this device pointer. The point I was trying to make is that this function (as well as the ioctl) should not be in this driver in the first place. hwmon is about providing hwmon information, not about providing adc readings to another driver. Or, in other words, hwmon should be a consumer of information from other drivers, not a producer of information to other drivers. There should be a higher level driver (presumably a mfd driver) to provide adc readings to all consumers, ie to all callers of twl4030_madc_conversion(). This driver can provide all data and information needed by more than one driver, and would also be the logical place for the ioctl providing raw adc readings to the user. I just noticed that there already is a mfd core driver for tw4030. You might want to consider moving the functionality to read adc values into that driver. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/5] OMAP4: mux: Add data for OMAP4430 ES1
On 9/25/2010 1:18 AM, Gadiyar, Anand wrote: diff --git a/arch/arm/mach-omap2/mux44xx.c b/arch/arm/mach-omap2/mux44xx.c new file mode 100644 index 000..839a905 --- /dev/null +++ b/arch/arm/mach-omap2/mux44xx.c @@ -0,0 +1,944 @@ +\ Stray change? Yes, indeed. Thanks, 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: mixing device idle and CPUidle or non-atomic idle notifiers
Hi Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Saturday, September 25, 2010 5:15 AM To: linux...@lists.linux-foundation.org; linux-ker...@vger.kernel.org Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RFC: mixing device idle and CPUidle or non-atomic idle notifiers Now that we have runtime PM for devices, I'm exploring ways of how to couple the runtime PM of certain devices with CPUidle transitions. Ideally, CPUidle should only manage CPU idle states, and device idle states would be managed separately using runtime PM. However, there are cases where the device idle transistions need to be coordinated with CPU idle transistions. This is already a proposed topic for the PM mini-conf at Plumbers'[1], so this RFC is to get the discussion started. In the wild west (before runtime PM), we managed these special cases on OMAP by having some special hacks^Whooks for certain drivers that were called during idle. When these devices are converted to using runtime PM, ideally we'd like initiate device runtime PM transitions for these devices somehow coordinated with CPU idle transitions. So, I started to explore how to coordinate device runtime PM transitions with CPU idle transitions. One of the fundamental problems is that by the time CPUidle is entered, interrupts are already disabled, and runtime PM cannot be used from interrupts disabled context (c.f. thread on linux-pm[1].) So that led me down the path of exploring whether we really need to have interrupts disabled during the early part of CPUidle. It seems to me that during the time when the governor is selecting a state, and when the platform-specific code is checking for device/bus activity, interrupts do not really need to be disabled yet. At least, I didn't come up with a good reason why they need to be disabled so early, hence the RFC. One thing that could go wrong is the governor's state selection. If you do end up servicing interrupts post the governor's state selection, and spend considerable amount of time in them, eventually when you do sleep (When CPUidle is scheduled again) the time available to sleep might be much lesser than what the governor thought it had, resulting in a wrong sleep state. regards, Rajendra Here's a simplified version how it works today: /* arch/arm/kernel/process.c, arch/x86/kernel/process_*.c */ cpu_idle() local_irq_disable() pm_idle() -- cpuidle_idle_call() cpuidle_idle_call() dev-prepare() target_state = governor-select() /* selects next state */ target_state-enter() /* the -enter hook must enable IRQs before returning */ As a quick hack, I just (re)enabled interrupts in our CPUidle -prepare() hook (they're later disabled again before the core idle is run.) This allowed the calling of device-specific idle functions which then use runtime PM and thus allows device-specific idle to be coordinated with the CPU idle. So back to the main question... do we really need interrupts disabled so early in the idle path? I'm sure I'm missing something obvious about why this can't work, but it's Friday and my brain prefers to think about beer rather than CPUidle. Or, as another potential option... I just discovered that x86_64 has an atomic idle_notifier called just before idle (c.f. arch/x86/kernel/process_64.c.) However this is also done with interrupts disabled, so using this has the same problems with interrupts disabled. But, what about adding an additional notifier chain that happens with interrupts still enabled hmm, will ponder that over that beer... Kevin [1] http://www.linuxplumbersconf.org/2010/ocw/proposals/717 [1] https://lists.linux-foundation.org/pipermail/linux-pm/2010-August/028124.html -- 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 -- 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 8/9 v3] usb : musb: Using runtime pm apis for musb.
Hello. On 27-09-2010 10:07, Felipe Balbi wrote: I guess that's Felipe's call, but I don't like that option. I think it's cleaner to have the -set_clock hook be a noop on OMAP and the runtime hooks be noops on the other platforms. Agreed. We should focus on removing -set_clock for .38 actually. Is DaVinci already using clkdev, Kevin ? Sure. But DaVinci doesn't use -set_clock(). Ok, so seems like no-one is actually using that. I thought OMAP does... but I'm seeing now that it doesn't. We can already start patching to remove that thing, later on, we need to remove the clock name via platform_data. As I've said already, there are cases where two clocks is needed by MUSB (like AM3517) or where USB 2.0 clock is also needed by the OHCI driver (DA8xx), hence the name seems needed still... 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 v3] power_supply: Add driver for TWL4030/TPS65950 BCI charger
hello,
On Mon, Sep 27, 2010 at 9:18 AM, Felipe Balbi ba...@ti.com wrote:
On Sun, Sep 26, 2010 at 02:35:40PM -0500, Grazvydas Ignotas wrote:
TWL4030/TPS65950 is a multi-function device with integrated charger,
which allows charging from AC or USB. This driver enables the
charger and provides several monitoring functions.
Tested on OMAP3 Pandora board.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
This is v3 of BCI charger driver I first sent nearly a year ago [1].
I've updated it to use the new OTG notifiers for VBUS notifications,
however it still is not able to determine charge current to use.
For that reason there is now a temporary module param to enable USB
charging, until I can figure out how to get that info from the gadget
stack (hopefully Felipe can help me here).
You need to send USB_EVENT_ENUMERATED from usb_gadget_vbus_draw(), but
wait until the UDC class is finished, then we will have a common
location to do those stuff.
ok, I hope I can get CCed or notified in some way as I might miss that.
snip
+
+ ret = request_threaded_irq(bci-irq_bci, NULL,
+ twl4030_bci_interrupt, 0, pdev-name, bci);
+ if (ret 0) {
+ dev_err(pdev-dev, could not request irq %d, status
%d\n,
+ bci-irq_bci, ret);
+ goto fail_bci_irq;
+ }
you should register the power_supply before enabling the IRQ lines,
otherwise you might call power_supply_changed() to a non-existent
power_supply.
good catch, will do.
snip
+
+#ifdef CONFIG_USB_OTG_UTILS
+ bci-transceiver = otg_get_transceiver();
+#endif
this driver should actually depend on that. It won't work without access
to the transceiver anyway.
Well it can still do AC charging fine without OTG stuff.
Or you add something like:
#ifdef CONFIG_USB_OTG_UTILS
extern struct otg_transceiver *otg_get_transceiver(void);
extern void otg_put_transceiver(struct otg_transceiver *);
#else
static inline struct otg_transceiver *otg_get_transceiver(void)
{ return NULL; }
static inline void otg_put_transceiver(struct otg_transceiver *x)
{ }
#endif
I much prefer that, will send a patch.
to the otg.h and avoid having to use that ifdef here and on any other
driver. (should be a separate patch though).
+static struct platform_driver twl4030_bci_driver = {
+ .probe = twl4030_bci_probe,
drivers should not reference __init sections anymore. If you make this
statically linked to the kernel, you'll get section mismatches. It's
better to make probe __init remove it from here and call
platform_driver_probe() from module_init();
Tried that and did not get any section mismatches, but will switch
anyway to better match trends.
+ .remove = __devexit_p(twl4030_bci_remove),
+ .driver = {
+ .name = twl4030_bci,
+ .owner = THIS_MODULE,
+ },
+};
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Mon, Sep 27, 2010 at 10:21 AM, Arun Murthy arunrmurthy...@gmail.com wrote:
On Mon, Sep 27, 2010 at 1:05 AM, Grazvydas Ignotas nota...@gmail.com
wrote:
---
This is v3 of BCI charger driver I first sent nearly a year ago [1].
I've updated it to use the new OTG notifiers for VBUS notifications,
however it still is not able to determine charge current to use.
For that reason there is now a temporary module param to enable USB
charging, until I can figure out how to get that info from the gadget
stack (hopefully Felipe can help me here).
On detecting USB plug, the driver is suppose to detect the type of usb
device. Then if the device is a PC(standard host) the charging current is to
be obtained from the usb stack. Hence the driver will have to wait until the
usb stack or driver notifies the current that can be drawn. The usb stack or
driver gets to know the amount of current to be drawn through the
negotiations that happen between the host and device.
I'm aware of that, the question was how to get that from Linux USB
stack (which Felipe already responded).
snip
Only AC and USB monitoring is achieved by registering with power supply
class.
How is battery monitored?
An instance of battery is to be registered with power supply class in order
to monitor battery.
The problem is that BCI is only active while charging, when it is not
charging most (all?) monitoring registers freeze and no monitoring
happens (BCI registers read frozen values from last charge). So I
don't register battery as it has no useful data to report. I heard it
is possible to use MADC to perform monitoring while not charging, so
battery can be added when MADC driver is merged and corresponding code
is written for this driver.
+
+static struct platform_driver twl4030_bci_driver = {
+ .probe = twl4030_bci_probe,
+ .remove = __devexit_p(twl4030_bci_remove),
+ .driver = {
+ .name = twl4030_bci,
+ .owner = THIS_MODULE,
+ },
+};
dev_pm_ops can be use
nothing to do there right now, the driver relies on FSM change
interrupts from BCI to update state.
--
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 05/11] omap3: Remove non-existent config option
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Saturday, September 25, 2010 9:13 PM To: Premi, Sanjeev Cc: Tony Lindgren; linux-arm-ker...@lists.infradead.org; linux- o...@vger.kernel.org; Marathe, Yogesh Subject: Re: [PATCH 05/11] omap3: Remove non-existent config option On Fri, Sep 24, 2010 at 6:17 PM, Premi, Sanjeev pr...@ti.com wrote: On Fri, Sep 24, 2010 at 4:50 AM, Tony Lindgren t...@atomide.com wrote: From: Yogesh Marathe yogesh_mara...@ti.com The definition of iva2 device in iommu_device is wrapped inside CONFIG_MPU_BRIDGE_IOMMU, but this option is not defined in KConfig. This patch removes the wrapper and makes iva2 available as another iommu_device. NAK. This would break tidspbridge's MMU. This was discussed before: http://thread.gmane.org/gmane.linux.ports.arm.kernel/58302/focus=58305 When tidspbridge has migrated to iommu, then it should define CONFIG_MPU_BRIDGE_IOMMU. Can you go through earlier discussion on this patch http://marc.info/?l=linux-omapm=127979007623260w=2 I believe these concerns were discussed. I am unable to open the gmane thread (getting 504) - so can't be sure if Hiroshi had referred to same discussion. When you merge iommu support, then either you enable CONFIG_MPU_BRIDGE_IOMMU unconditionally, or you apply this patch, but this patch alone will only break things. -- Felipe Contreras Felipe, Any other driver which does not depend on bridge and interested in using iommu should get the handle when iommu_get(iva2) is called. It is not happening in original case. I think there should not be restrictions on other drivers to define un-related compile time define if they just want to use iommu driver. I feel the implementation that is breaking due to removal of this define should be fixed. Regards, Yogesh. -- 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 07/10] TWL CORE: Fix sparse warning
Hi Manjunath,
On Tue, Sep 21, 2010 at 03:31:17PM +0530, G, Manjunath Kondaiah wrote:
Fixes below sparse warning.
drivers/mfd/twl-core.c:258:20: warning: symbol 'twl_map' was not declared.
Should it be static?
Patch applied, thanks.
Cheers,
Samuel.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Tony Lindgren t...@atomide.com
Cc: Nishanth Menon n...@ti.com
---
drivers/mfd/twl-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 720e099..53c371a 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -255,7 +255,7 @@ struct twl_mapping {
unsigned char sid; /* Slave ID */
unsigned char base; /* base address */
};
-struct twl_mapping *twl_map;
+static struct twl_mapping *twl_map;
static struct twl_mapping twl4030_map[TWL4030_MODULE_LAST + 1] = {
/*
--
1.7.0.4
--
Intel Open Source Technology Centre
http://oss.intel.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 v2 08/10] TWL IRQ: Fix fucntion declaration warnings
Hi Manjunath, On Tue, Sep 21, 2010 at 03:31:18PM +0530, G, Manjunath Kondaiah wrote: Fixes following sparse warnings for twl4030 and twl6030 irq files. drivers/mfd/twl4030-irq.c:783:5: warning: symbol 'twl4030_init_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:863:5: warning: symbol 'twl4030_exit_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:873:5: warning: symbol 'twl4030_init_chip_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:226:5: warning: symbol 'twl6030_init_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:290:5: warning: symbol 'twl6030_exit_irq' was not declared. Should it be static? Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Ortiz sa...@linux.intel.com Cc: Tony Lindgren t...@atomide.com Cc: Nishanth Menon n...@ti.com --- include/linux/i2c/twl.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h index 6de90bf..c61e90a 100644 --- a/include/linux/i2c/twl.h +++ b/include/linux/i2c/twl.h @@ -172,6 +172,11 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes); int twl6030_interrupt_unmask(u8 bit_mask, u8 offset); int twl6030_interrupt_mask(u8 bit_mask, u8 offset); +int twl6030_init_irq(int irq_num, unsigned irq_base, unsigned irq_end); +int twl6030_exit_irq(void); +int twl4030_init_irq(int irq_num, unsigned irq_base, unsigned irq_end); +int twl4030_exit_irq(void); +int twl4030_init_chip_irq(const char *chip); No, we don't want to export those. Try defining them as extern from twl*-irq.c. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 v3] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Mon, Sep 27, 2010 at 1:05 AM, Grazvydas Ignotas nota...@gmail.com wrote:
TWL4030/TPS65950 is a multi-function device with integrated charger,
which allows charging from AC or USB. This driver enables the
charger and provides several monitoring functions.
Tested on OMAP3 Pandora board.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
This is v3 of BCI charger driver I first sent nearly a year ago [1].
I've updated it to use the new OTG notifiers for VBUS notifications,
however it still is not able to determine charge current to use.
For that reason there is now a temporary module param to enable USB
charging, until I can figure out how to get that info from the gadget
stack (hopefully Felipe can help me here).
On detecting USB plug, the driver is suppose to detect the type of usb
device. Then if the device is a PC(standard host) the charging current
is to be obtained from the usb stack. Hence the driver will have to
wait until the usb stack or driver notifies the current that can be
drawn. The usb stack or driver gets to know the amount of current to
be drawn through the negotiations that happen between the host and
device.
+
+ platform_set_drvdata(pdev, bci);
+
+ bci-ac.name = twl4030_ac;
+ bci-ac.type = POWER_SUPPLY_TYPE_MAINS;
+ bci-ac.properties = twl4030_charger_props;
+ bci-ac.num_properties = ARRAY_SIZE(twl4030_charger_props);
+ bci-ac.get_property = twl4030_bci_get_property;
+
+ ret = power_supply_register(pdev-dev, bci-ac);
+ if (ret) {
+ dev_err(pdev-dev, failed to register ac: %d\n, ret);
+ goto fail_register_ac;
+ }
+
+ bci-usb.name = twl4030_usb;
+ bci-usb.type = POWER_SUPPLY_TYPE_USB;
+ bci-usb.properties = twl4030_charger_props;
+ bci-usb.num_properties = ARRAY_SIZE(twl4030_charger_props);
+ bci-usb.get_property = twl4030_bci_get_property;
+
+ ret = power_supply_register(pdev-dev, bci-usb);
+ if (ret) {
+ dev_err(pdev-dev, failed to register usb: %d\n, ret);
+ goto fail_register_usb;
+ }
Only AC and USB monitoring is achieved by registering with power supply class.
How is battery monitored?
An instance of battery is to be registered with power supply class in
order to monitor battery.
Thanks and Regards,
Arun R Murthy
-
--
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
Issue : jffs2 and ecc layout
Hi,
I was using the following ecc layout which is not working to mount the jffs2
File-system. I was using this in 2.6.32 kernel and was working; but same layout
is not working with latest 2.6 kernel.
Observation is that - no read request issued to the driver (say omap2.c).
# mount -t jffs2 /dev/mtdblock4 /mnt/nand
[ 32.505218] cannot read OOB for EB at , requested 8 bytes, read 0
bytes, error -22
mount: Mounting /dev/mtdblock4 on /mnt/nand failed: Input/output error
# dmesg
3[ 32.505218] cannot read OOB for EB at , requested 8 bytes, read 0
bytes, error -22
Code:
178 static struct nand_ecclayout hw_x16_romcode_oob_64 = {
179 .eccbytes = 12,
180 .eccpos = {
181 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
182 },
183 .oobfree = {
184 {.offset = 14,
185 .length = 50}
186}
187 };
1188 info-nand.ecc.layout = hw_x16_romcode_oob_64;
Regards,
Ghorai
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Mon, Sep 27, 2010 at 4:24 PM, Grazvydas Ignotas nota...@gmail.com wrote: On Mon, Sep 27, 2010 at 10:21 AM, Arun Murthy arunrmurthy...@gmail.com wrote: On Mon, Sep 27, 2010 at 1:05 AM, Grazvydas Ignotas nota...@gmail.com wrote: --- Only AC and USB monitoring is achieved by registering with power supply class. How is battery monitored? An instance of battery is to be registered with power supply class in order to monitor battery. The problem is that BCI is only active while charging, when it is not charging most (all?) monitoring registers freeze and no monitoring happens (BCI registers read frozen values from last charge). So I don't register battery as it has no useful data to report. I heard it is possible to use MADC to perform monitoring while not charging, so battery can be added when MADC driver is merged and corresponding code is written for this driver. How do I check the battery voltage? I need to check the battery voltage/current/temp and, if I am not wrong these are obtained from MADC. MADC driver has to be added first and then the battery. With being able to read the basic parameter battery voltage, this driver becomes incomplete. How do I get notified if battery voltage is low and needs charging from user space? Thanks and Regards, Arun R Murthy - -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Mon, Sep 27, 2010 at 3:35 PM, Arun Murthy arunrmurthy...@gmail.com wrote: On Mon, Sep 27, 2010 at 4:24 PM, Grazvydas Ignotas nota...@gmail.com wrote: On Mon, Sep 27, 2010 at 10:21 AM, Arun Murthy arunrmurthy...@gmail.com wrote: The problem is that BCI is only active while charging, when it is not charging most (all?) monitoring registers freeze and no monitoring happens (BCI registers read frozen values from last charge). So I don't register battery as it has no useful data to report. I heard it is possible to use MADC to perform monitoring while not charging, so battery can be added when MADC driver is merged and corresponding code is written for this driver. How do I check the battery voltage? I need to check the battery voltage/current/temp and, if I am not wrong these are obtained from MADC. MADC driver has to be added first and then the battery. With being able to read the basic parameter battery voltage, this driver becomes incomplete. Incomplete driver is better than no driver, don't you think? There are some boards like pandora or oswald that have additional battery monitoring chips (as twl monitoring is pretty crude anyway), those boards would have fully functional charging now. Currently mainline kernel is not very useful with them simply because the battery runs flat. How do I get notified if battery voltage is low and needs charging from user space? Either additional monitoring chip notifies you (if you are lucky and have one), or wait for update of this driver :) There are efforts to merge MADC driver [1], but it may take some time. [1] http://marc.info/?t=12846153572r=1w=2 -- 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 08/10] TWL IRQ: Fix fucntion declaration warnings
Hi Samuel, -Original Message- From: Samuel Ortiz [mailto:sa...@linux.intel.com] Sent: Monday, September 27, 2010 4:46 PM To: G, Manjunath Kondaiah Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Tony Lindgren; Menon, Nishanth Subject: Re: [PATCH v2 08/10] TWL IRQ: Fix fucntion declaration warnings Hi Manjunath, On Tue, Sep 21, 2010 at 03:31:18PM +0530, G, Manjunath Kondaiah wrote: Fixes following sparse warnings for twl4030 and twl6030 irq files. drivers/mfd/twl4030-irq.c:783:5: warning: symbol 'twl4030_init_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:863:5: warning: symbol 'twl4030_exit_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:873:5: warning: symbol 'twl4030_init_chip_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:226:5: warning: symbol 'twl6030_init_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:290:5: warning: symbol 'twl6030_exit_irq' was not declared. Should it be static? Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Ortiz sa...@linux.intel.com Cc: Tony Lindgren t...@atomide.com Cc: Nishanth Menon n...@ti.com --- include/linux/i2c/twl.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h index 6de90bf..c61e90a 100644 --- a/include/linux/i2c/twl.h +++ b/include/linux/i2c/twl.h @@ -172,6 +172,11 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes); int twl6030_interrupt_unmask(u8 bit_mask, u8 offset); int twl6030_interrupt_mask(u8 bit_mask, u8 offset); +int twl6030_init_irq(int irq_num, unsigned irq_base, unsigned +irq_end); int twl6030_exit_irq(void); int twl4030_init_irq(int +irq_num, unsigned irq_base, unsigned irq_end); int +twl4030_exit_irq(void); int twl4030_init_chip_irq(const char *chip); No, we don't want to export those. Try defining them as extern from twl*-irq.c. Having extern in .c file will generate checkpatch warning as: WARNING: externs should be avoided in .c files -Manjunath-- 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 v5 0/5] nand prefetch-irq support and ecc layout chanage
The following set of patches applies on linux-2.6. The main motivations behind this patch series are - 1. support NAND I/O in irq mode. 2. support of different ECC schema. 3. also to make ecc layout as like in romcode ecc layout v5: This address the input as to support the irq_chained in GPMC v4: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34882.html and resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32689.html v3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32071.html Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg2.html Sukumar Ghorai (5): omap gpmc: enable irq mode in gpmc omap3: nand: prefetch in irq mode support omap3: nand: configurable fifo threshold to gain the throughput omap: nand: ecc layout select from board file omap: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-2430sdp.c|1 + arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-am3517evm.c |2 + arch/arm/mach-omap2/board-apollon.c|1 + arch/arm/mach-omap2/board-cm-t35.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-flash.c |5 +- arch/arm/mach-omap2/board-generic.c|2 + arch/arm/mach-omap2/board-h4.c |1 + arch/arm/mach-omap2/board-igep0020.c |1 + arch/arm/mach-omap2/board-ldp.c|1 + arch/arm/mach-omap2/board-n8x0.c |2 + arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |1 + arch/arm/mach-omap2/board-omap3touchbook.c |1 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-zoom2.c |2 + arch/arm/mach-omap2/board-zoom3.c |2 + arch/arm/mach-omap2/gpmc.c | 48 +- arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h | 16 ++- arch/arm/plat-omap/include/plat/irqs.h |9 +- arch/arm/plat-omap/include/plat/nand.h |3 + drivers/mtd/nand/Kconfig | 14 ++- drivers/mtd/nand/omap2.c | 277 +--- 31 files changed, 367 insertions(+), 39 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/5] omap gpmc: enable irq mode in gpmc
add support the irq mode in GPMC. gpmc_init() function move after omap_init_irq() as it has dependecy on irq. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c|1 + arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-am3517evm.c |2 + arch/arm/mach-omap2/board-apollon.c|1 + arch/arm/mach-omap2/board-cm-t35.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-generic.c|2 + arch/arm/mach-omap2/board-h4.c |1 + arch/arm/mach-omap2/board-igep0020.c |1 + arch/arm/mach-omap2/board-ldp.c|1 + arch/arm/mach-omap2/board-n8x0.c |2 + arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |1 + arch/arm/mach-omap2/board-omap3touchbook.c |1 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-zoom2.c |2 + arch/arm/mach-omap2/board-zoom3.c |2 + arch/arm/mach-omap2/gpmc.c | 37 ++- arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h |4 +++ arch/arm/plat-omap/include/plat/irqs.h |9 ++- 27 files changed, 79 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 8538e41..a047a35 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -144,6 +144,7 @@ static void __init omap_2430sdp_init_irq(void) omap_board_config_size = ARRAY_SIZE(sdp2430_config); omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index 67b95b5..549cd62 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void) omap3_pm_init_cpuidle(omap3_cpuidle_params_table); omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-omap2/board-3630sdp.c index b359c3f..19cb423 100644 --- a/arch/arm/mach-omap2/board-3630sdp.c +++ b/arch/arm/mach-omap2/board-3630sdp.c @@ -76,6 +76,7 @@ static void __init omap_sdp_init_irq(void) omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params, h8mbx00u0mer0em_sdrc_params); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 9447644..5fc66eb 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -35,6 +35,7 @@ #include plat/timer-gp.h #include plat/usb.h #include plat/mmc.h +#include plat/gpmc.h #include hsmmc.h #define ETH_KS8851_IRQ 34 @@ -181,6 +182,7 @@ static void __init omap_4430sdp_init_irq(void) omap2_gp_clockevent_set_gptimer(1); #endif gic_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c index 4d0f585..3a12571 100644 --- a/arch/arm/mach-omap2/board-am3517evm.c +++ b/arch/arm/mach-omap2/board-am3517evm.c @@ -35,6 +35,7 @@ #include plat/control.h #include plat/usb.h #include plat/display.h +#include plat/gpmc.h #include mux.h @@ -372,6 +373,7 @@ static void __init am3517_evm_init_irq(void) omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c index c6421a7..10fe693 100644 --- a/arch/arm/mach-omap2/board-apollon.c +++ b/arch/arm/mach-omap2/board-apollon.c @@ -280,6 +280,7 @@ static void __init omap_apollon_init_irq(void) omap_board_config_size = ARRAY_SIZE(apollon_config); omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); apollon_init_smc91x(); } diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index e10bc10..8c32e34 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -687,6 +687,7 @@ static void __init cm_t35_init_irq(void) omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
[PATCH v5 3/5] omap3: nand: configurable fifo threshold to gain the throughput
Configure the FIFO THREASHOLD value different for read and write to keep busy
both filling and to drain out of FIFO at reading and writing.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 11 +++
arch/arm/plat-omap/include/plat/gpmc.h |5 -
drivers/mtd/nand/omap2.c | 24 +++-
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 9ecb2a7..10ce5d5 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -59,7 +59,6 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
-#define PREFETCH_FIFOTHRESHOLD (0x40 8)
#define CS_NUM_SHIFT 24
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
@@ -595,15 +594,19 @@ 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 dma_mode,
+int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write)
{
- if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX) {
+ printk(KERN_ERR PREFETCH 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);
@@ -611,7 +614,7 @@ int gpmc_prefetch_enable(int cs, int dma_mode,
* enable the engine. Set which cs is has requested for.
*/
gpmc_write_reg(GPMC_PREFETCH_CONFIG1, ((cs CS_NUM_SHIFT) |
- PREFETCH_FIFOTHRESHOLD |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) |
ENABLE_PREFETCH |
(dma_mode DMA_MPU_MODE) |
(0x1 is_write)));
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 054e704..fb82335 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -83,6 +83,9 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)(val 8)
+
/*
* Note that all values in this struct are in nanoseconds, while
* the register values are in gpmc_fck cycles.
@@ -133,7 +136,7 @@ extern int gpmc_cs_request(int cs, unsigned long size,
unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
extern int gpmc_cs_reserved(int cs);
-extern int gpmc_prefetch_enable(int cs, int dma_mode,
+extern int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write);
extern int gpmc_prefetch_reset(int cs);
extern void omap3_gpmc_save_context(void);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 72994e8..5ac7f7c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -275,7 +275,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x0);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -319,7 +320,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x1);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x1);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -373,10 +375,11 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
dma_addr_t dma_addr;
int ret;
- /* The fifo depth is 64 bytes. We have a sync at each frame and frame
-* length is 64 bytes.
+ /* The fifo depth is 64 bytes max.
+* But configure the FIFO-threahold to 32 to get a sync at each frame
+
[PATCH v5 5/5] omap: nand: making ecc layout as compatible with romcode ecc
This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-loader, u-boot and kernel.
This patch also enables to use romcode ecc for spd and zoom, by default.
This enables to flash x-loader, u-boot, kernel, FS images from kernel itself
and compatiable with other tools.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
drivers/mtd/nand/omap2.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 3fd9ee0..9ccfd88 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -128,6 +128,20 @@ const int use_dma;
const int use_interrupt;
#endif
+/* oob info generated runtime depending on ecc algorithm and layout selected */
+static struct nand_ecclayout omap_oobinfo;
+/* Define some generic bad / good block scan pattern which are used
+ * while scanning a device for factory marked good / bad blocks
+ */
+static uint8_t scan_ff_pattern[] = { 0xff };
+static struct nand_bbt_descr bb_descrip_flashbased = {
+ .options = NAND_BBT_SCANEMPTY | NAND_BBT_SCANALLPAGES,
+ .offs = 0,
+ .len = 1,
+ .pattern = scan_ff_pattern,
+};
+
+
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -946,6 +960,7 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
struct omap_nand_info *info;
struct omap_nand_platform_data *pdata;
int err;
+ int i, offset;
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1079,6 +1094,25 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
}
+ /* rom code layout */
+ if (pdata-ecc_opt != OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT) {
+ offset = (info-nand.options NAND_BUSWIDTH_16) ? 2 : 1;
+ if (info-mtd.oobsize == 16) {
+ info-nand.badblock_pattern = bb_descrip_flashbased;
+ omap_oobinfo.eccbytes = 3;
+ } else
+ omap_oobinfo.eccbytes = 3 * 4;
+
+ for (i = 0; i omap_oobinfo.eccbytes; i++)
+ omap_oobinfo.eccpos[i] = i+offset;
+
+ omap_oobinfo.oobfree-offset = offset + omap_oobinfo.eccbytes;
+ omap_oobinfo.oobfree-length = info-mtd.oobsize -
+ (offset + omap_oobinfo.eccbytes);
+
+ info-nand.ecc.layout = omap_oobinfo;
+ }
+
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
if (err 0)
--
1.7.0.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
[PATCH v5 2/5] omap3: nand: prefetch in irq mode support
This patch enable prefetch-irq mode for NAND.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |4 +-
arch/arm/plat-omap/include/plat/nand.h |1 +
drivers/mtd/nand/Kconfig | 14 ++-
drivers/mtd/nand/omap2.c | 196 +++-
4 files changed, 208 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index ac834aa..2355e4a 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -17,6 +17,7 @@
#include linux/mtd/physmap.h
#include linux/io.h
+#include plat/irqs.h
#include plat/gpmc.h
#include plat/nand.h
#include plat/onenand.h
@@ -142,8 +143,9 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
- board_nand_data.nr_parts= nr_parts;
+ board_nand_data.nr_parts= nr_parts;
+ board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
}
#else
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 6562cd0..5e69463 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -20,6 +20,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ int gpmc_irq;
unsigned long phys_base;
int devsize;
};
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8b4b67c..88cea0c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -112,6 +112,9 @@ config MTD_NAND_OMAP_PREFETCH
help
The NAND device can be accessed for Read/Write using GPMC PREFETCH
engine
to improve the performance.
+GPMC PREFETCH can be configured eigther in MPU interrupt mode or in DMA
+interrupt mode. If not selected any of them prefetch will be used in
+polling mode.
config MTD_NAND_OMAP_PREFETCH_DMA
depends on MTD_NAND_OMAP_PREFETCH
@@ -120,7 +123,16 @@ config MTD_NAND_OMAP_PREFETCH_DMA
help
The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
or in DMA interrupt mode.
-Say y for DMA mode or MPU mode will be used
+Say y for DMA mode
+
+config MTD_NAND_OMAP_PREFETCH_IRQ
+ depends on MTD_NAND_OMAP_PREFETCH !MTD_NAND_OMAP_PREFETCH_DMA
+ bool IRQ mode
+ default n
+ help
+The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
+or in DMA interrupt mode.
+Say y for IRQ mode
config MTD_NAND_IDS
tristate
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 133d515..72994e8 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -12,6 +12,7 @@
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/delay.h
+#include linux/interrupt.h
#include linux/jiffies.h
#include linux/sched.h
#include linux/mtd/mtd.h
@@ -105,17 +106,27 @@ module_param(use_prefetch, bool, 0);
MODULE_PARM_DESC(use_prefetch, enable/disable use of PREFETCH);
#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
+const int use_interrupt;
static int use_dma = 1;
/* modprobe ... use_dma=0 etc */
module_param(use_dma, bool, 0);
-MODULE_PARM_DESC(use_dma, enable/disable use of DMA);
+MODULE_PARM_DESC(use_dma, enable/disable use of DMA mode);
+#elif defined(CONFIG_MTD_NAND_OMAP_PREFETCH_IRQ)
+const int use_dma;
+static int use_interrupt = 1;
+
+/* modprobe ... use_dma=0 etc */
+module_param(use_interrupt, bool, 0);
+MODULE_PARM_DESC(use_interrupt, enable/disable use of IRQ mode);
#else
const int use_dma;
+const int use_interrupt;
#endif
#else
const int use_prefetch;
const int use_dma;
+const int use_interrupt;
#endif
struct omap_nand_info {
@@ -130,6 +141,13 @@ struct omap_nand_info {
unsigned long phys_base;
struct completion comp;
int dma_ch;
+ int gpmc_irq;
+ enum {
+ OMAP_NAND_IO_READ = 0, /* read */
+ OMAP_NAND_IO_WRITE, /* write */
+ } iomode;
+ u_char *buf;
+ int buf_len;
};
/**
@@ -467,6 +485,153 @@ static void omap_write_buf_dma_pref(struct mtd_info *mtd,
omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1);
}
+/*
+ * omap_nand_irq - GMPC irq handler
+ * @this_irq: gpmc irq number
+ * @dev: omap_nand_info structure pointer is passed here
+ */
+static irqreturn_t
[PATCH v5 4/5] omap: nand: ecc layout select from board file
This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver. And hw ecc layout selected for
sdp and zoom boards, by default.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |1 +
arch/arm/plat-omap/include/plat/gpmc.h |7 +++
arch/arm/plat-omap/include/plat/nand.h |2 ++
drivers/mtd/nand/omap2.c | 29 +
4 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 2355e4a..ecd41ae 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -144,6 +144,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
+ board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT;
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index fb82335..54902d8 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -86,6 +86,13 @@
#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
#define PREFETCH_FIFOTHRESHOLD(val)(val 8)
+enum omap_ecc{
+ OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT = 0,
+ /* 1-bit s/w ecc and layout different from romcode */
+ OMAP_ECC_HAMMING_CODE_HW,/* 1-bit ecc, romcode layout */
+ OMAP_ECC_HAMMING_CODE_SW,/* 1-bit ecc, romcode layout */
+};
+
/*
* Note that all values in this struct are in nanoseconds, while
* the register values are in gpmc_fck cycles.
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 5e69463..d5b6fc6 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
+#include plat/gpmc.h
#include linux/mtd/partitions.h
struct omap_nand_platform_data {
@@ -23,6 +24,7 @@ struct omap_nand_platform_data {
int gpmc_irq;
unsigned long phys_base;
int devsize;
+ enum omap_ecc ecc_opt;
};
/* minimum size for IO mapping */
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5ac7f7c..3fd9ee0 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -7,7 +7,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#define CONFIG_MTD_NAND_OMAP_HWECC
#include linux/platform_device.h
#include linux/dma-mapping.h
@@ -659,8 +658,6 @@ static int omap_verify_buf(struct mtd_info *mtd, const
u_char * buf, int len)
return 0;
}
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-
/**
* gen_true_ecc - This function will generate true ECC value
* @ecc_buf: buffer to store ecc code
@@ -880,8 +877,6 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int
mode)
gpmc_enable_hwecc(info-gpmc_cs, mode, dev_width, info-nand.ecc.size);
}
-#endif
-
/**
* omap_wait - wait until the command is done
* @mtd: MTD device structure
@@ -1059,17 +1054,19 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
info-nand.verify_buf = omap_verify_buf;
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
- info-nand.ecc.bytes= 3;
- info-nand.ecc.size = 512;
- info-nand.ecc.calculate= omap_calculate_ecc;
- info-nand.ecc.hwctl= omap_enable_hwecc;
- info-nand.ecc.correct = omap_correct_data;
- info-nand.ecc.mode = NAND_ECC_HW;
-
-#else
- info-nand.ecc.mode = NAND_ECC_SOFT;
-#endif
+ /* selsect the ecc type */
+ if ((pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT) ||
+ (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW)) {
+ info-nand.ecc.bytes= 3;
+ info-nand.ecc.size = 512;
+ info-nand.ecc.calculate= omap_calculate_ecc;
+ info-nand.ecc.hwctl= omap_enable_hwecc;
+ info-nand.ecc.correct = omap_correct_data;
+ info-nand.ecc.mode = NAND_ECC_HW;
+
+ } else if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_SW) {
+ info-nand.ecc.mode = NAND_ECC_SOFT;
+ }
/* DIP switches on some boards change between 8 and 16 bit
* bus widths for flash. Try the other width if the first try fails.
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
RE: [GIT PULL] omap2 sparse fixes
Hi Tony, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Saturday, September 25, 2010 5:49 AM To: G, Manjunath Kondaiah Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [GIT PULL] omap2 sparse fixes * G, Manjunath Kondaiah manj...@ti.com [100924 12:33]: Tony, Here is new pull request which is rebased to 2.6.36-rc5. -Manjunath The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c: Linus Torvalds (1): Linux 2.6.36-rc5 are available in the git repository at: git://dev.omapzoom.org/pub/scm/manju/kernel-omap3-dev.git sparse_fixes G, Manjunath Kondaiah (10): OMAP: mach-omap2: Fix incorrect assignment warnings OMAP: mach-omap2: Fix static declaration warnings OMAP: mach-omap2: Fix static function warnings OMAP: mach-omap2: Fix miscellaneous sparse warnings OMAP: plat-omap: Fix static function warnings OMAP: NAND: Fix static declaration warning TWL CORE: Fix sparse warning TWL IRQ: Fix fucntion declaration warnings OMAP2/3: Convert write/read functions to raw read/write OMAP3: Keypad: Fix incorrect type initializer Hmm tried pulling these, but ran into an issue where at least 2430 takes about a minute to boot with these patches with no output on the console intially. Here is test report for all the boards: 1. omap3_defconfig with 2.6.36-rc5 code as is does not seems to be boot. Enabled early printk and found it was due to musb driver. Boot log is here: 2430sdp_omap3_defconfig_bootlog_nochanges2code.txt http://pastebin.com/wd92PMmE 2. Disabled musb in omap3_defconfig and boot seems be fine. 2430sdp_omap3_defconfig_bootlog_usbdisable http://pastebin.com/eExED5q4 3. With sparse fix series, booting is as expected with omap3_defconfig 2430sdp_omap3_defconfig_bootlog_usbdisable_sparse_fixes.txt http://pastebin.com/GMX4y2fS 4. Here zoom3 boot log: Zoom3_omap3_defconfig_bootlog_usbdisable_sparse_fixes. http://pastebin.com/C2A6YXAL 5. omap4 sdp boot log(with es2.0 patches pulled from for-next branch) omap4sdp_es2.0_omap3_defconfig_bootlog_sparse_fixes. http://pastebin.com/ebiP1X2h Can you please check that? Will not merge for now until we figure out what changes with these patches. Then, I also noticed the following exports getting added: +EXPORT_SYMBOL(omap2_gp_clockevent_set_gptimer); +EXPORT_SYMBOL(omapfb_reserve_sram); +EXPORT_SYMBOL(omap_sram_init); These should not be exported, they are only intended to be called from the low-level platform init code. So exporting them is not the right fix for these. I have declared these API's as extern functions in respective header files. If it is ok, I can push the changes to git branch for pull request. -Manjunath -- 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 08/10] TWL IRQ: Fix fucntion declaration warnings
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G, Manjunath Kondaiah Sent: Monday, September 27, 2010 6:40 PM To: Samuel Ortiz Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Tony Lindgren; Menon, Nishanth Subject: RE: [PATCH v2 08/10] TWL IRQ: Fix fucntion declaration warnings Hi Samuel, -Original Message- From: Samuel Ortiz [mailto:sa...@linux.intel.com] Sent: Monday, September 27, 2010 4:46 PM To: G, Manjunath Kondaiah Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Tony Lindgren; Menon, Nishanth Subject: Re: [PATCH v2 08/10] TWL IRQ: Fix fucntion declaration warnings Hi Manjunath, On Tue, Sep 21, 2010 at 03:31:18PM +0530, G, Manjunath Kondaiah wrote: Fixes following sparse warnings for twl4030 and twl6030 irq files. drivers/mfd/twl4030-irq.c:783:5: warning: symbol 'twl4030_init_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:863:5: warning: symbol 'twl4030_exit_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:873:5: warning: symbol 'twl4030_init_chip_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:226:5: warning: symbol 'twl6030_init_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:290:5: warning: symbol 'twl6030_exit_irq' was not declared. Should it be static? Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: Samuel Ortiz sa...@linux.intel.com Cc: Tony Lindgren t...@atomide.com Cc: Nishanth Menon n...@ti.com --- include/linux/i2c/twl.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h index 6de90bf..c61e90a 100644 --- a/include/linux/i2c/twl.h +++ b/include/linux/i2c/twl.h @@ -172,6 +172,11 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes); int twl6030_interrupt_unmask(u8 bit_mask, u8 offset); int twl6030_interrupt_mask(u8 bit_mask, u8 offset); +int twl6030_init_irq(int irq_num, unsigned irq_base, unsigned +irq_end); int twl6030_exit_irq(void); int twl4030_init_irq(int +irq_num, unsigned irq_base, unsigned irq_end); int +twl4030_exit_irq(void); int twl4030_init_chip_irq(const char *chip); No, we don't want to export those. Try defining them as extern from twl*-irq.c. Having extern in .c file will generate checkpatch warning as: WARNING: externs should be avoided in .c files As an alternate, how about having twl-core.h in drivers/mfd and defining them as extern so that these API's will be available only to files under drivers/mfd? -Manjunath-- 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: [linux-pm] runtime_pm_get_sync() from ISR with IRQs disabled?
On Fri, 24 Sep 2010, Rafael J. Wysocki wrote: On Friday, September 24, 2010, Kevin Hilman wrote: Alan Stern st...@rowland.harvard.edu writes: On Thu, 23 Sep 2010, Kevin Hilman wrote: ... You're trying to fight the runtime-PM design instead of using it as it was intended. We already have an API for starting a resume from interrupt context, and that's what you should use. It may seem like I'm trying to fight the design, but I'm actually trying to find ways to use it. I want to use the API (and we're using it successfully in most of our drivers now.) The problem is only in a few of these corner cases where using it introduces significant changes from previous behavior like introducing long, unbounded windows for missed interrupts. This really sounds to me like you need _noirq() runtime PM callbacks and some framework around them. I'm not fundamentally against that, but it will require some time to introduce, if we decide that it's really necessary. I need to think a bit more about that, thanks for the example. How about adding another flag to the dev_pm_info structure, to indicate that the runtime callbacks may be called in interrupt context? Maybe that will lead to problems I haven't thought of. But if it seems okay to you, I can code it up easily enough. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 5/5] omap: nand: making ecc layout as compatible with romcode ecc
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sukumar Ghorai Sent: Monday, September 27, 2010 7:07 PM To: linux-omap@vger.kernel.org Cc: linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; Ghorai, Sukumar; Vimal Singh Subject: [PATCH v5 5/5] omap: nand: making ecc layout as compatible with romcode ecc This patch overrides nand ecc layout and bad block descriptor (for 8-bit device) to support hw ecc in romcode layout. So as to have in sync with ecc layout throughout; i.e. x-loader, u-boot and kernel. This patch also enables to use romcode ecc for spd and zoom, by default. This enables to flash x-loader, u-boot, kernel, FS images from kernel itself and compatiable with other tools. The description seems to start with different whitespace indents in this patch series. ~sanjeev [snip]...[snip]-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 5/5] omap: nand: making ecc layout as compatible with romcode ecc
-Original Message- From: Premi, Sanjeev Sent: Monday, September 27, 2010 7:29 PM To: Ghorai, Sukumar; linux-omap@vger.kernel.org Cc: linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; Ghorai, Sukumar; Vimal Singh Subject: RE: [PATCH v5 5/5] omap: nand: making ecc layout as compatible with romcode ecc -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sukumar Ghorai Sent: Monday, September 27, 2010 7:07 PM To: linux-omap@vger.kernel.org Cc: linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; Ghorai, Sukumar; Vimal Singh Subject: [PATCH v5 5/5] omap: nand: making ecc layout as compatible with romcode ecc This patch overrides nand ecc layout and bad block descriptor (for 8-bit device) to support hw ecc in romcode layout. So as to have in sync with ecc layout throughout; i.e. x-loader, u-boot and kernel. This patch also enables to use romcode ecc for spd and zoom, by default. This enables to flash x-loader, u-boot, kernel, FS images from kernel itself and compatiable with other tools. The description seems to start with different whitespace indents in this patch series. [Ghorai] Thanks. I will RESEND. ~sanjeev [snip]...[snip] -- 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: [GIT PULL] omap2 sparse fixes
On Mon, Sep 27, 2010 at 07:11:37PM +0530, G, Manjunath Kondaiah wrote: Can you please check that? Will not merge for now until we figure out what changes with these patches. Then, I also noticed the following exports getting added: +EXPORT_SYMBOL(omap2_gp_clockevent_set_gptimer); +EXPORT_SYMBOL(omapfb_reserve_sram); +EXPORT_SYMBOL(omap_sram_init); These should not be exported, they are only intended to be called from the low-level platform init code. So exporting them is not the right fix for these. I have declared these API's as extern functions in respective header files. It's hard to tell whether you're justifying having the EXPORT_SYMBOLs there or not from your reply. Just because you add them as declarations to a header file does not mean you have to add EXPORT_SYMBOLs for them. The only thing that this macro does is make them available to modules. In any case, if functions are marked as __init (or similar, which some are) then they must not be exported - they won't exist when modules are available to be loaded. Instead, their symbols will point to some random data which has replaced the code. -- 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 RESEND v5 0/5] nand prefetch-irq support and ecc layout chanage
The following set of patches applies on linux-2.6. The main motivations behind this patch series are - 1. support NAND I/O in irq mode. 2. support of different ECC schema. 3. also to make ecc layout as like in romcode ecc layout v5: This address the input as to support the irq_chained in GPMC. And resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35848.html v4: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34882.html and resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32689.html v3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32071.html Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg2.html Sukumar Ghorai (5): omap gpmc: enable irq mode in gpmc omap3: nand: prefetch in irq mode support omap3: nand: configurable fifo threshold to gain the throughput omap: nand: ecc layout select from board file omap: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-2430sdp.c|1 + arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-am3517evm.c |2 + arch/arm/mach-omap2/board-apollon.c|1 + arch/arm/mach-omap2/board-cm-t35.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-flash.c |5 +- arch/arm/mach-omap2/board-generic.c|2 + arch/arm/mach-omap2/board-h4.c |1 + arch/arm/mach-omap2/board-igep0020.c |1 + arch/arm/mach-omap2/board-ldp.c|1 + arch/arm/mach-omap2/board-n8x0.c |2 + arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |1 + arch/arm/mach-omap2/board-omap3touchbook.c |1 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-zoom2.c |2 + arch/arm/mach-omap2/board-zoom3.c |2 + arch/arm/mach-omap2/gpmc.c | 48 +- arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h | 16 ++- arch/arm/plat-omap/include/plat/irqs.h |9 +- arch/arm/plat-omap/include/plat/nand.h |3 + drivers/mtd/nand/Kconfig | 14 ++- drivers/mtd/nand/omap2.c | 277 +--- 31 files changed, 367 insertions(+), 39 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v5 3/5] omap3: nand: configurable fifo threshold to gain the throughput
Configure the FIFO THREASHOLD value different for read and write to keep busy
both filling and to drain out of FIFO at reading and writing.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 11 +++
arch/arm/plat-omap/include/plat/gpmc.h |5 -
drivers/mtd/nand/omap2.c | 24 +++-
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 9ecb2a7..10ce5d5 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -59,7 +59,6 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
-#define PREFETCH_FIFOTHRESHOLD (0x40 8)
#define CS_NUM_SHIFT 24
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
@@ -595,15 +594,19 @@ 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 dma_mode,
+int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write)
{
- if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX) {
+ printk(KERN_ERR PREFETCH 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);
@@ -611,7 +614,7 @@ int gpmc_prefetch_enable(int cs, int dma_mode,
* enable the engine. Set which cs is has requested for.
*/
gpmc_write_reg(GPMC_PREFETCH_CONFIG1, ((cs CS_NUM_SHIFT) |
- PREFETCH_FIFOTHRESHOLD |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) |
ENABLE_PREFETCH |
(dma_mode DMA_MPU_MODE) |
(0x1 is_write)));
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 054e704..fb82335 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -83,6 +83,9 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)(val 8)
+
/*
* Note that all values in this struct are in nanoseconds, while
* the register values are in gpmc_fck cycles.
@@ -133,7 +136,7 @@ extern int gpmc_cs_request(int cs, unsigned long size,
unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
extern int gpmc_cs_reserved(int cs);
-extern int gpmc_prefetch_enable(int cs, int dma_mode,
+extern int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write);
extern int gpmc_prefetch_reset(int cs);
extern void omap3_gpmc_save_context(void);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 72994e8..5ac7f7c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -275,7 +275,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x0);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -319,7 +320,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x1);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x1);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -373,10 +375,11 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
dma_addr_t dma_addr;
int ret;
- /* The fifo depth is 64 bytes. We have a sync at each frame and frame
-* length is 64 bytes.
+ /* The fifo depth is 64 bytes max.
+* But configure the FIFO-threahold to 32 to get a sync at each frame
+*
[PATCH RESEND v5 4/5] omap: nand: ecc layout select from board file
This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver. And hw ecc layout selected for
sdp and zoom boards, by default.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |1 +
arch/arm/plat-omap/include/plat/gpmc.h |7 +++
arch/arm/plat-omap/include/plat/nand.h |2 ++
drivers/mtd/nand/omap2.c | 29 +
4 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 2355e4a..ecd41ae 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -144,6 +144,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
+ board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT;
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index fb82335..54902d8 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -86,6 +86,13 @@
#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
#define PREFETCH_FIFOTHRESHOLD(val)(val 8)
+enum omap_ecc{
+ OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT = 0,
+ /* 1-bit s/w ecc and layout different from romcode */
+ OMAP_ECC_HAMMING_CODE_HW,/* 1-bit ecc, romcode layout */
+ OMAP_ECC_HAMMING_CODE_SW,/* 1-bit ecc, romcode layout */
+};
+
/*
* Note that all values in this struct are in nanoseconds, while
* the register values are in gpmc_fck cycles.
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 5e69463..d5b6fc6 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
+#include plat/gpmc.h
#include linux/mtd/partitions.h
struct omap_nand_platform_data {
@@ -23,6 +24,7 @@ struct omap_nand_platform_data {
int gpmc_irq;
unsigned long phys_base;
int devsize;
+ enum omap_ecc ecc_opt;
};
/* minimum size for IO mapping */
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5ac7f7c..3fd9ee0 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -7,7 +7,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#define CONFIG_MTD_NAND_OMAP_HWECC
#include linux/platform_device.h
#include linux/dma-mapping.h
@@ -659,8 +658,6 @@ static int omap_verify_buf(struct mtd_info *mtd, const
u_char * buf, int len)
return 0;
}
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-
/**
* gen_true_ecc - This function will generate true ECC value
* @ecc_buf: buffer to store ecc code
@@ -880,8 +877,6 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int
mode)
gpmc_enable_hwecc(info-gpmc_cs, mode, dev_width, info-nand.ecc.size);
}
-#endif
-
/**
* omap_wait - wait until the command is done
* @mtd: MTD device structure
@@ -1059,17 +1054,19 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
info-nand.verify_buf = omap_verify_buf;
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
- info-nand.ecc.bytes= 3;
- info-nand.ecc.size = 512;
- info-nand.ecc.calculate= omap_calculate_ecc;
- info-nand.ecc.hwctl= omap_enable_hwecc;
- info-nand.ecc.correct = omap_correct_data;
- info-nand.ecc.mode = NAND_ECC_HW;
-
-#else
- info-nand.ecc.mode = NAND_ECC_SOFT;
-#endif
+ /* selsect the ecc type */
+ if ((pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT) ||
+ (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW)) {
+ info-nand.ecc.bytes= 3;
+ info-nand.ecc.size = 512;
+ info-nand.ecc.calculate= omap_calculate_ecc;
+ info-nand.ecc.hwctl= omap_enable_hwecc;
+ info-nand.ecc.correct = omap_correct_data;
+ info-nand.ecc.mode = NAND_ECC_HW;
+
+ } else if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_SW) {
+ info-nand.ecc.mode = NAND_ECC_SOFT;
+ }
/* DIP switches on some boards change between 8 and 16 bit
* bus widths for flash. Try the other width if the first try fails.
--
1.7.0.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
[PATCH RESEND v5 2/5] omap3: nand: prefetch in irq mode support
This patch enable prefetch-irq mode for NAND.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |4 +-
arch/arm/plat-omap/include/plat/nand.h |1 +
drivers/mtd/nand/Kconfig | 14 ++-
drivers/mtd/nand/omap2.c | 196 +++-
4 files changed, 208 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index ac834aa..2355e4a 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -17,6 +17,7 @@
#include linux/mtd/physmap.h
#include linux/io.h
+#include plat/irqs.h
#include plat/gpmc.h
#include plat/nand.h
#include plat/onenand.h
@@ -142,8 +143,9 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
- board_nand_data.nr_parts= nr_parts;
+ board_nand_data.nr_parts= nr_parts;
+ board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
}
#else
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 6562cd0..5e69463 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -20,6 +20,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ int gpmc_irq;
unsigned long phys_base;
int devsize;
};
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8b4b67c..88cea0c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -112,6 +112,9 @@ config MTD_NAND_OMAP_PREFETCH
help
The NAND device can be accessed for Read/Write using GPMC PREFETCH
engine
to improve the performance.
+GPMC PREFETCH can be configured eigther in MPU interrupt mode or in DMA
+interrupt mode. If not selected any of them prefetch will be used in
+polling mode.
config MTD_NAND_OMAP_PREFETCH_DMA
depends on MTD_NAND_OMAP_PREFETCH
@@ -120,7 +123,16 @@ config MTD_NAND_OMAP_PREFETCH_DMA
help
The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
or in DMA interrupt mode.
-Say y for DMA mode or MPU mode will be used
+Say y for DMA mode
+
+config MTD_NAND_OMAP_PREFETCH_IRQ
+ depends on MTD_NAND_OMAP_PREFETCH !MTD_NAND_OMAP_PREFETCH_DMA
+ bool IRQ mode
+ default n
+ help
+The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
+or in DMA interrupt mode.
+Say y for IRQ mode
config MTD_NAND_IDS
tristate
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 133d515..72994e8 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -12,6 +12,7 @@
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/delay.h
+#include linux/interrupt.h
#include linux/jiffies.h
#include linux/sched.h
#include linux/mtd/mtd.h
@@ -105,17 +106,27 @@ module_param(use_prefetch, bool, 0);
MODULE_PARM_DESC(use_prefetch, enable/disable use of PREFETCH);
#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
+const int use_interrupt;
static int use_dma = 1;
/* modprobe ... use_dma=0 etc */
module_param(use_dma, bool, 0);
-MODULE_PARM_DESC(use_dma, enable/disable use of DMA);
+MODULE_PARM_DESC(use_dma, enable/disable use of DMA mode);
+#elif defined(CONFIG_MTD_NAND_OMAP_PREFETCH_IRQ)
+const int use_dma;
+static int use_interrupt = 1;
+
+/* modprobe ... use_dma=0 etc */
+module_param(use_interrupt, bool, 0);
+MODULE_PARM_DESC(use_interrupt, enable/disable use of IRQ mode);
#else
const int use_dma;
+const int use_interrupt;
#endif
#else
const int use_prefetch;
const int use_dma;
+const int use_interrupt;
#endif
struct omap_nand_info {
@@ -130,6 +141,13 @@ struct omap_nand_info {
unsigned long phys_base;
struct completion comp;
int dma_ch;
+ int gpmc_irq;
+ enum {
+ OMAP_NAND_IO_READ = 0, /* read */
+ OMAP_NAND_IO_WRITE, /* write */
+ } iomode;
+ u_char *buf;
+ int buf_len;
};
/**
@@ -467,6 +485,153 @@ static void omap_write_buf_dma_pref(struct mtd_info *mtd,
omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1);
}
+/*
+ * omap_nand_irq - GMPC irq handler
+ * @this_irq: gpmc irq number
+ * @dev: omap_nand_info structure pointer is passed here
+ */
+static irqreturn_t
[PATCH RESEND v5 5/5] omap: nand: making ecc layout as compatible with romcode ecc
This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-loader, u-boot and kernel.
This patch also enables to use romcode ecc for spd and zoom, by default.
This enables to flash x-loader, u-boot, kernel, FS images from kernel itself
and compatiable with other tools.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
drivers/mtd/nand/omap2.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 3fd9ee0..9ccfd88 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -128,6 +128,20 @@ const int use_dma;
const int use_interrupt;
#endif
+/* oob info generated runtime depending on ecc algorithm and layout selected */
+static struct nand_ecclayout omap_oobinfo;
+/* Define some generic bad / good block scan pattern which are used
+ * while scanning a device for factory marked good / bad blocks
+ */
+static uint8_t scan_ff_pattern[] = { 0xff };
+static struct nand_bbt_descr bb_descrip_flashbased = {
+ .options = NAND_BBT_SCANEMPTY | NAND_BBT_SCANALLPAGES,
+ .offs = 0,
+ .len = 1,
+ .pattern = scan_ff_pattern,
+};
+
+
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -946,6 +960,7 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
struct omap_nand_info *info;
struct omap_nand_platform_data *pdata;
int err;
+ int i, offset;
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1079,6 +1094,25 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
}
+ /* rom code layout */
+ if (pdata-ecc_opt != OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT) {
+ offset = (info-nand.options NAND_BUSWIDTH_16) ? 2 : 1;
+ if (info-mtd.oobsize == 16) {
+ info-nand.badblock_pattern = bb_descrip_flashbased;
+ omap_oobinfo.eccbytes = 3;
+ } else
+ omap_oobinfo.eccbytes = 3 * 4;
+
+ for (i = 0; i omap_oobinfo.eccbytes; i++)
+ omap_oobinfo.eccpos[i] = i+offset;
+
+ omap_oobinfo.oobfree-offset = offset + omap_oobinfo.eccbytes;
+ omap_oobinfo.oobfree-length = info-mtd.oobsize -
+ (offset + omap_oobinfo.eccbytes);
+
+ info-nand.ecc.layout = omap_oobinfo;
+ }
+
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
if (err 0)
--
1.7.0.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
[PATCH RESEND v5 1/5] omap gpmc: enable irq mode in gpmc
add support the irq mode in GPMC. gpmc_init() function move after omap_init_irq() as it has dependecy on irq. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c|1 + arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-am3517evm.c |2 + arch/arm/mach-omap2/board-apollon.c|1 + arch/arm/mach-omap2/board-cm-t35.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-generic.c|2 + arch/arm/mach-omap2/board-h4.c |1 + arch/arm/mach-omap2/board-igep0020.c |1 + arch/arm/mach-omap2/board-ldp.c|1 + arch/arm/mach-omap2/board-n8x0.c |2 + arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |1 + arch/arm/mach-omap2/board-omap3touchbook.c |1 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-zoom2.c |2 + arch/arm/mach-omap2/board-zoom3.c |2 + arch/arm/mach-omap2/gpmc.c | 37 ++- arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h |4 +++ arch/arm/plat-omap/include/plat/irqs.h |9 ++- 27 files changed, 79 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 8538e41..a047a35 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -144,6 +144,7 @@ static void __init omap_2430sdp_init_irq(void) omap_board_config_size = ARRAY_SIZE(sdp2430_config); omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index 67b95b5..549cd62 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void) omap3_pm_init_cpuidle(omap3_cpuidle_params_table); omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-omap2/board-3630sdp.c index b359c3f..19cb423 100644 --- a/arch/arm/mach-omap2/board-3630sdp.c +++ b/arch/arm/mach-omap2/board-3630sdp.c @@ -76,6 +76,7 @@ static void __init omap_sdp_init_irq(void) omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params, h8mbx00u0mer0em_sdrc_params); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 9447644..5fc66eb 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -35,6 +35,7 @@ #include plat/timer-gp.h #include plat/usb.h #include plat/mmc.h +#include plat/gpmc.h #include hsmmc.h #define ETH_KS8851_IRQ 34 @@ -181,6 +182,7 @@ static void __init omap_4430sdp_init_irq(void) omap2_gp_clockevent_set_gptimer(1); #endif gic_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c index 4d0f585..3a12571 100644 --- a/arch/arm/mach-omap2/board-am3517evm.c +++ b/arch/arm/mach-omap2/board-am3517evm.c @@ -35,6 +35,7 @@ #include plat/control.h #include plat/usb.h #include plat/display.h +#include plat/gpmc.h #include mux.h @@ -372,6 +373,7 @@ static void __init am3517_evm_init_irq(void) omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c index c6421a7..10fe693 100644 --- a/arch/arm/mach-omap2/board-apollon.c +++ b/arch/arm/mach-omap2/board-apollon.c @@ -280,6 +280,7 @@ static void __init omap_apollon_init_irq(void) omap_board_config_size = ARRAY_SIZE(apollon_config); omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); apollon_init_smc91x(); } diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index e10bc10..8c32e34 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -687,6 +687,7 @@ static void __init cm_t35_init_irq(void) omap2_init_common_hw(mt46h32m32lf6_sdrc_params, mt46h32m32lf6_sdrc_params);
Re: [PATCH v4] power: introduce library for device-specific OPPs
Paul E. McKenney had written, on 09/25/2010 07:56 PM, the following:
On Sat, Sep 25, 2010 at 10:55:20PM +0200, Rafael J. Wysocki wrote:
On Friday, September 24, 2010, Paul E. McKenney wrote:
On Fri, Sep 24, 2010 at 07:50:40AM -0500, Nishanth Menon wrote:
...
Looks like a good start!!! Some questions and suggestions about RCU
usage interspersed below.
...
+ * Locking: RCU reader.
+ */
+int opp_get_opp_count(struct device *dev)
+{
+ struct device_opp *dev_opp;
+ struct opp *temp_opp;
+ int count = 0;
+
+ dev_opp = find_device_opp(dev);
+ if (IS_ERR(dev_opp))
+ return PTR_ERR(dev_opp);
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(temp_opp, dev_opp-opp_list, node) {
+ if (temp_opp-available)
+ count++;
+ }
+ rcu_read_unlock();
This one is OK as well. You are returning a count, so if all of the
counted structures are freed at this point, no problem. The count was
valid when it was accumulated, and the fact that it might now be obsolete
is (usually) not a problem.
However, it looks like it should run rcu_read_lock() before calling
find_device_opp(dev), shouldn't it?
Indeed it does appear that you are right -- good catch!!!
Thanx, Paul
dev_opp as discussed before is safe as it is never freed
(find_device_opp uses it's own rcu_read_lock, the rcu_read_lock in this
context is for the opp list. what am I missing?
ack on Paul's comments w.r.t risk on opp structures itself.. will look
to fix that in v5.
--
Regards,
Nishanth Menon
--
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] power: introduce library for device-specific OPPs
Paul E. McKenney had written, on 09/24/2010 04:40 PM, the following:
[...]
+/**
+ * opp_find_freq_ceil() - Search for an rounded ceil freq
+ * @dev: device for which we do this operation
+ * @freq:Start frequency
+ *
+ * Search for the matching ceil *available* OPP from a starting freq
+ * for a device.
+ *
+ * Returns matching *opp and refreshes *freq accordingly, else returns
+ * ERR_PTR in case of error and should be handled using IS_ERR.
+ *
+ * Locking: RCU reader.
+ */
+struct opp *opp_find_freq_ceil(struct device *dev, unsigned long *freq)
+{
+ struct device_opp *dev_opp;
+ struct opp *temp_opp, *opp = ERR_PTR(-ENODEV);
+
+ if (!dev || !freq) {
+ pr_err(%s: invalid param dev=%p freq=%p\n, __func__,
+ dev, freq);
+ return ERR_PTR(-EINVAL);
+ }
+
+ dev_opp = find_device_opp(dev);
+ if (IS_ERR(dev_opp))
+ return opp;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(temp_opp, dev_opp-opp_list, node) {
+ if (temp_opp-available temp_opp-rate = *freq) {
+ opp = temp_opp;
+ *freq = opp-rate;
+ break;
+ }
+ }
+ rcu_read_unlock();
And this one also has the same problem that find_device_opp() does.
guessing opp ptr here.. am I right? if it is about device_opp, it is
not going to be freed as I mentioned above - at least we dont give
an function to update(hence free) it.
It really does look to me that you are passing a pointer to the thing
being freed out of an RCU read-side critical section. If you are really
doing this, you do need to do something to fix it. I outlined some of
the options earlier.
ack. will try to fix in v5.
+ return opp;
+}
+
+/**
+ * opp_find_freq_floor() - Search for a rounded floor freq
+ * @dev: device for which we do this operation
+ * @freq:Start frequency
+ *
+ * Search for the matching floor *available* OPP from a starting freq
+ * for a device.
+ *
+ * Returns matching *opp and refreshes *freq accordingly, else returns
+ * ERR_PTR in case of error and should be handled using IS_ERR.
+ *
+ * Locking: RCU reader.
+ */
+struct opp *opp_find_freq_floor(struct device *dev, unsigned long *freq)
+{
+ struct device_opp *dev_opp;
+ struct opp *temp_opp, *opp = ERR_PTR(-ENODEV);
+
+ if (!dev || !freq) {
+ pr_err(%s: invalid param dev=%p freq=%p\n, __func__,
+ dev, freq);
+ return ERR_PTR(-EINVAL);
+ }
+
+ dev_opp = find_device_opp(dev);
+ if (IS_ERR(dev_opp))
+ return opp;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(temp_opp, dev_opp-opp_list, node) {
+ if (temp_opp-available) {
+ /* go to the next node, before choosing prev */
+ if (temp_opp-rate *freq)
+ break;
+ else
+ opp = temp_opp;
+ }
+ }
+ if (!IS_ERR(opp))
+ *freq = opp-rate;
+ rcu_read_unlock();
As does this one.
guessing opp ptr here.. am I right?
Again, here it looks to me like you are passing a pointer out of an RCU
read-side critical section that could be freed out from under you. If
so, again, this must be fixed.
[...]
+static int opp_set_availability(struct opp *opp, bool availability_req)
+{
+ struct opp *new_opp, *tmp_opp;
+ bool is_available;
+
+ if (unlikely(!opp || IS_ERR(opp))) {
+ pr_err(%s: Invalid parameters being passed\n, __func__);
+ return -EINVAL;
+ }
+
+ new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
+ if (!new_opp) {
+ pr_warning(%s: unable to allocate opp\n, __func__);
+ return -ENOMEM;
+ }
+
+ mutex_lock(opp-dev_opp-lock);
+
+ rcu_read_lock();
+ tmp_opp = rcu_dereference(opp);
+ is_available = tmp_opp-available;
+ rcu_read_unlock();
+
+ /* Is update really needed? */
+ if (is_available == availability_req) {
+ mutex_unlock(opp-dev_opp-lock);
+ kfree(tmp_opp);
+ return 0;
+ }
+
+ *new_opp = *opp;
+ new_opp-available = availability_req;
+ list_replace_rcu(opp-node, new_opp-node);
+
+ mutex_unlock(opp-dev_opp-lock);
+ synchronize_rcu();
If you decide to rely on reference counts to fix the problem in
find_device_opp(), you will need to check the reference counts here.
Again, please see Documentation/RCU/rcuref.txt.
Does the original point about not needing to free dev_opp resolve this?
For the dev_opp case, yes. However, I believe that my point is still
valid for the opp case.
Ack. I missed that :(.. let me relook at the logic yet again. hopefully
fix in v5.
+ kfree(opp);
+
+ return 0;
+}
+
+/**
+ * opp_enable() - Enable a specific OPP
+ * @opp: Pointer to opp
+ *
+ * Enables a provided opp. If the operation is valid, this returns 0, else the
Re: [PATCH] mfd: speedup twl4030 irq response time and decrease irq disable time
2010/9/22 tom.leim...@gmail.com:
From: Ming Lei tom.leim...@gmail.com
This patch sets scheduler policy of twl4030 irq thread
(twl4030_irq_thread) as SCHED_FIFO to speedup irq response
time, just like taken by kernel threaded irq in irq_thread
(kernel/irq/manage.c). Also higher priority than that of
threaded irq is taken to avoid preemption from twl4030
subchips's threaded irq handler, so pih irq disable time may
be decreased.
The pih irq is disabled in handle_twl4030_pih which may
wakeup twl4030 irq thread, and the pih irq will be enabled
again until complete of all sih irqs' handling in twl4030
irq thread.
Also for each one interrupt line of twl4030 subchip, only
two irq events can be buffered by twl4030(4.4.2.3 of TPS65950 TRM).
Ping...
Signed-off-by: Ming Lei tom.leim...@gmail.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Balaji T K balaj...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: linux-ker...@vger.kernel.org
---
drivers/mfd/twl4030-irq.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 097f24d..d1e0d80 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -286,8 +286,16 @@ static int twl4030_irq_thread(void *data)
long irq = (long)data;
static unsigned i2c_errors;
static const unsigned max_i2c_errors = 100;
-
-
+ struct sched_param param = {
+ .sched_priority = MAX_USER_RT_PRIO/2 + 10,
+ };
+
+ /* Take higher priority than threaded irq to make us immune of
+ * preemption from twl4030 subchips's threaded irq handler, then
+ * we can complete all SIH irqs' handling and enable PIH irq
+ * again asap.
+ * */
+ sched_setscheduler(current, SCHED_FIFO, param);
current-flags |= PF_NOFREEZE;
while (!kthread_should_stop()) {
--
1.6.2.5
thanks,
--
Lei Ming
--
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 08/10] TWL IRQ: Fix fucntion declaration warnings
Hi Manjunath, On Mon, Sep 27, 2010 at 07:19:33PM +0530, G, Manjunath Kondaiah wrote: No, we don't want to export those. Try defining them as extern from twl*-irq.c. Having extern in .c file will generate checkpatch warning as: WARNING: externs should be avoided in .c files As an alternate, how about having twl-core.h in drivers/mfd and defining them as extern so that these API's will be available only to files under drivers/mfd? That would be better, yes. Even though exporting those definititions through linux/i2c/twl.h is harmless. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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
[PATCH 00/13 v3] OMAP: Serial: Add omap-serial driver with platform support
This patch series adds a serial driver to handle uarts on omap platforms. Currenlty omap-uarts are handled with 8250 driver, since updating this driver with omap specific features will over load the 8250 driver with all omap-specific data thus a new driver is added to configure and support features like dma, h/w, s/w flowcontrol for omap-uarts. Also the patch series updates various low level platform specific serial data to support omap-uarts with hwmod framework and adds support for uart4 on OMAP3630. Patch series applies cleanly on pm-core branch on kevins PM tree. http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git; a=shortlog;h=refs/heads/pm-core Patch series Testing Status Update: --- OMAP4:(SDP): Boot tested with ttyO* and ttyS* interfaces using this patch series. OMAP2(2430SDP): Boot tested with ttyO* and ttyS* interfaces using this patch series. (Couldn't test pm functionality here due to board shortage). OMAP3:(3430/3630SDP, ZOOM2/3): Boot tested for console with ttyS* and ttyO* interfaces. PM functionality checked omap3: 1) ret count: debugfs mounted sleep_while_idle enabled, checked for ret count values to increment this was done by setting sysfs timeout for all uarts. Also checked by unsetting uart sysfs timeout to check ret count stopped incrementing. 2) core off count: debugfs mounted sleep_while_idle and enable_off_mode enabled checked for core_off count to increment for core/per_pwrdm. 3) Susupend: Done using echo mem /sys/power/state. Ensured no difference in behaviour with and without this patch series. v2 to v3 changes: - 1) Minor changes with omap-serial https://patchwork.kernel.org/patch/199652/ 2) Undo the timeout macro modification done by mistake. https://patchwork.kernel.org/patch/199642/ 3) update description log for patch: OMAP3: SERIAL: Initialize all omap-uarts for zoom boards https://patchwork.kernel.org/patch/199672/ v1 to v2 changes: - 1) Incorporate timeout check http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35106.html 2) Add wk_st, padconf etc for uart4 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35105.html Benoit Cousson (1): OMAP4: UART: Add uart1-4 hwmods data for omap4 Govindraj.R (8): OMAP2: UART: remove set_uart_globals. OMAP clock: Add uart4_ick/fck definitions for 3630 OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs OMAP3: PM: Add prepare idle and resume idle call for uart4 OMAP3: serial: Fix uart4 handling for 3630 serial: Add OMAP high-speed UART driver OMAP: SERIAL: Enable omap-serial driver in Kconfig. OMAP3: SERIAL: Initialize all omap-uarts for zoom boards Kevin Hilman (4): OMAP2/3: UART: add omap_hwmod data for UARTs 1-4 OMAP: UART: omap_device converions, remove implicit 8520 assumptions OMAP: UART: don't do automatic bus-level suspend/resume OMAP: UART: use non-locking versions of hwmod enable/idle functions arch/arm/mach-omap2/Kconfig | 11 +- arch/arm/mach-omap2/board-3630sdp.c |1 - arch/arm/mach-omap2/board-zoom-peripherals.c |1 + arch/arm/mach-omap2/clock3xxx_data.c | 22 + arch/arm/mach-omap2/cm-regbits-34xx.h |2 + arch/arm/mach-omap2/omap_hwmod_2420_data.c| 193 arch/arm/mach-omap2/omap_hwmod_2430_data.c| 193 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c| 253 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c| 235 + arch/arm/mach-omap2/pm34xx.c | 17 +- arch/arm/mach-omap2/prcm-common.h |5 + arch/arm/mach-omap2/prm-regbits-34xx.h|1 + arch/arm/mach-omap2/serial.c | 555 ++- arch/arm/plat-omap/common.c | 16 - arch/arm/plat-omap/include/plat/common.h |1 - arch/arm/plat-omap/include/plat/dma.h |2 + arch/arm/plat-omap/include/plat/irqs.h|2 + arch/arm/plat-omap/include/plat/omap-serial.h | 129 +++ drivers/serial/Kconfig| 27 + drivers/serial/Makefile |1 + drivers/serial/omap-serial.c | 1333 + include/linux/serial_core.h |3 + 22 files changed, 2707 insertions(+), 296 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h create mode 100644 drivers/serial/omap-serial.c -- 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/13 v3] OMAP4: UART: Add uart1-4 hwmods data for omap4
From: Benoit Cousson b-cous...@ti.com
Add uart1-4 hwmod data into omap4_hwmod data file.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 235
1 files changed, 235 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e20b0ee..afcbd48 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -452,6 +452,235 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'uart' class
+ * universal asynchronous receiver/transmitter (uart)
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_uart_sysc = {
+ .rev_offs = 0x0050,
+ .sysc_offs = 0x0054,
+ .syss_offs = 0x0058,
+ .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_uart_hwmod_class = {
+ .name = uart,
+ .sysc = omap44xx_uart_sysc,
+};
+
+/* uart1 */
+static struct omap_hwmod omap44xx_uart1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_uart1_irqs[] = {
+ { .irq = 72 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_uart1_sdma_reqs[] = {
+ { .name = tx, .dma_req = 48 + OMAP44XX_DMA_REQ_START },
+ { .name = rx, .dma_req = 49 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_uart1_addrs[] = {
+ {
+ .pa_start = 0x4806a000,
+ .pa_end = 0x4806a0ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - uart1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__uart1 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_uart1_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_uart1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_uart1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* uart1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_uart1_slaves[] = {
+ omap44xx_l4_per__uart1,
+};
+
+static struct omap_hwmod omap44xx_uart1_hwmod = {
+ .name = uart1,
+ .class = omap44xx_uart_hwmod_class,
+ .mpu_irqs = omap44xx_uart1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_uart1_irqs),
+ .sdma_reqs = omap44xx_uart1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_uart1_sdma_reqs),
+ .main_clk = uart1_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4PER_UART1_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_uart1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_uart1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* uart2 */
+static struct omap_hwmod omap44xx_uart2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_uart2_irqs[] = {
+ { .irq = 73 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_uart2_sdma_reqs[] = {
+ { .name = tx, .dma_req = 50 + OMAP44XX_DMA_REQ_START },
+ { .name = rx, .dma_req = 51 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_uart2_addrs[] = {
+ {
+ .pa_start = 0x4806c000,
+ .pa_end = 0x4806c0ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - uart2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__uart2 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_uart2_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_uart2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_uart2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* uart2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_uart2_slaves[] = {
+ omap44xx_l4_per__uart2,
+};
+
+static struct omap_hwmod omap44xx_uart2_hwmod = {
+ .name = uart2,
+ .class = omap44xx_uart_hwmod_class,
+ .mpu_irqs = omap44xx_uart2_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_uart2_irqs),
+ .sdma_reqs = omap44xx_uart2_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_uart2_sdma_reqs),
+ .main_clk = uart2_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4PER_UART2_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_uart2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_uart2_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
[PATCH 02/13 v3] OMAP2/3: UART: add omap_hwmod data for UARTs 1-4
From: Kevin Hilman khil...@deeprootsystems.com
This patch adds omap_hwmod data for UARTs on OMAP2 and OMAP3
platforms.
UART4 support for 3630 and OMAP2 hwmod data added by Govindraj R.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 193 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 193 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 253 +++-
arch/arm/mach-omap2/prcm-common.h |3 +
arch/arm/plat-omap/include/plat/dma.h |2 +
arch/arm/plat-omap/include/plat/irqs.h |2 +
6 files changed, 644 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 3cc768e..ba145f7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -15,6 +15,7 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/serial.h
#include omap_hwmod_common_data.h
@@ -71,6 +72,9 @@ static struct omap_hwmod omap2420_l3_main_hwmod = {
};
static struct omap_hwmod omap2420_l4_wkup_hwmod;
+static struct omap_hwmod omap2420_uart1_hwmod;
+static struct omap_hwmod omap2420_uart2_hwmod;
+static struct omap_hwmod omap2420_uart3_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
@@ -79,6 +83,60 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* L4 CORE - UART1 interface */
+static struct omap_hwmod_addr_space omap2420_uart1_addr_space[] = {
+ {
+ .pa_start = OMAP2_UART1_BASE,
+ .pa_end = OMAP2_UART1_BASE + SZ_8K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2_l4_core__uart1 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_uart1_hwmod,
+ .clk= uart1_ick,
+ .addr = omap2420_uart1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_uart1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - UART2 interface */
+static struct omap_hwmod_addr_space omap2420_uart2_addr_space[] = {
+ {
+ .pa_start = OMAP2_UART2_BASE,
+ .pa_end = OMAP2_UART2_BASE + SZ_1K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2_l4_core__uart2 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_uart2_hwmod,
+ .clk= uart2_ick,
+ .addr = omap2420_uart2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_uart2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - UART3 interface */
+static struct omap_hwmod_addr_space omap2420_uart3_addr_space[] = {
+ {
+ .pa_start = OMAP2_UART3_BASE,
+ .pa_end = OMAP2_UART3_BASE + SZ_1K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2_l4_core__uart3 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_uart3_hwmod,
+ .clk= uart3_ick,
+ .addr = omap2420_uart3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_uart3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Slave interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2420_l4_core_slaves[] = {
omap2420_l3_main__l4_core,
@@ -87,6 +145,9 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_slaves[] =
{
/* Master interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[] = {
omap2420_l4_core__l4_wkup,
+ omap2_l4_core__uart1,
+ omap2_l4_core__uart2,
+ omap2_l4_core__uart3,
};
/* L4 CORE */
@@ -165,12 +226,144 @@ static struct omap_hwmod omap2420_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
+/* UART */
+
+static struct omap_hwmod_class_sysconfig uart_sysc = {
+ .rev_offs = 0x50,
+ .sysc_offs = 0x54,
+ .syss_offs = 0x58,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class uart_class = {
+ .name = uart,
+ .sysc = uart_sysc,
+};
+
+/* UART1 */
+
+static struct omap_hwmod_irq_info uart1_mpu_irqs[] = {
+ { .irq = INT_24XX_UART1_IRQ, },
+};
+
+static struct
[PATCH 03/13 v3] OMAP: UART: omap_device converions, remove implicit 8520 assumptions
From: Kevin Hilman khil...@deeprootsystems.com
Major rework of OMAP UART init for omap_device conversion as well as
use with either 8250 driver or new omap-serial driver.
In preparation for a new omap-serial driver, remove 8250 assumptions
and dependencies from the serial core.
Convert UART core and PM support to use omap_device layer. Also add
support for both console on 8250 or omap-serial driver.
omap_device conversion:
- Convert clock API calls to omap_device calls
- Remove all static platform_data setup and configuration. This is
all done by the omap_device build phase.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/serial.c | 529 +-
1 files changed, 260 insertions(+), 269 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 566e991..e6c4027 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -19,19 +19,29 @@
*/
#include linux/kernel.h
#include linux/init.h
-#include linux/serial_8250.h
#include linux/serial_reg.h
#include linux/clk.h
#include linux/io.h
#include linux/delay.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/serial_8250.h
+
+#ifdef CONFIG_SERIAL_OMAP
+#include plat/omap-serial.h
+#endif
#include plat/common.h
#include plat/board.h
#include plat/clock.h
#include plat/control.h
+#include plat/dma.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include prm.h
#include pm.h
+#include cm.h
#include prm-regbits-34xx.h
#define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV0x52
@@ -48,6 +58,8 @@
*/
#define DEFAULT_TIMEOUT 0
+#define MAX_UART_HWMOD_NAME_LEN16
+
struct omap_uart_state {
int num;
int can_sleep;
@@ -58,14 +70,21 @@ struct omap_uart_state {
void __iomem *wk_en;
u32 wk_mask;
u32 padconf;
+ u32 dma_enabled;
struct clk *ick;
struct clk *fck;
int clocked;
- struct plat_serial8250_port *p;
+ int irq;
+ int regshift;
+ int irqflags;
+ void __iomem *membase;
+ resource_size_t mapbase;
+
struct list_head node;
- struct platform_device pdev;
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
u32 errata;
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
@@ -83,75 +102,33 @@ struct omap_uart_state {
};
static LIST_HEAD(uart_list);
+static u8 num_uarts;
-static struct plat_serial8250_port serial_platform_data0[] = {
- {
- .irq= 72,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .flags = 0
- }
-};
-
-static struct plat_serial8250_port serial_platform_data1[] = {
- {
- .irq= 73,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .flags = 0
- }
-};
-
-static struct plat_serial8250_port serial_platform_data2[] = {
- {
- .irq= 74,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .flags = 0
- }
-};
-
-static struct plat_serial8250_port serial_platform_data3[] = {
- {
- .irq= 70,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .flags = 0
- }
-};
void __init omap2_set_globals_uart(struct omap_globals *omap2_globals)
{
- serial_platform_data0[0].mapbase = omap2_globals-uart1_phys;
- serial_platform_data1[0].mapbase = omap2_globals-uart2_phys;
- serial_platform_data2[0].mapbase = omap2_globals-uart3_phys;
- serial_platform_data3[0].mapbase = omap2_globals-uart4_phys;
}
+static struct omap_device_pm_latency omap_uart_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
static inline unsigned int __serial_read_reg(struct uart_port *up,
- int offset)
+int offset)
{
offset = up-regshift;
return (unsigned int)__raw_readb(up-membase + offset);
}
-static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
+static
[PATCH 04/13 v3] OMAP2: UART: remove set_uart_globals
Remove set_uart_globals function as this will not be needed as
physical address for uarts will be taken from hwmod data file.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |5 -
arch/arm/plat-omap/common.c | 16
arch/arm/plat-omap/include/plat/common.h |1 -
3 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index e6c4027..6ffbc92 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -104,11 +104,6 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
-
-void __init omap2_set_globals_uart(struct omap_globals *omap2_globals)
-{
-}
-
static struct omap_device_pm_latency omap_uart_latency[] = {
{
.deactivate_func = omap_device_idle_hwmods,
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 3008e71..ab04dad 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -257,7 +257,6 @@ static void __init __omap2_set_globals(struct omap_globals
*omap2_globals)
omap2_set_globals_sdrc(omap2_globals);
omap2_set_globals_control(omap2_globals);
omap2_set_globals_prcm(omap2_globals);
- omap2_set_globals_uart(omap2_globals);
}
#endif
@@ -272,9 +271,6 @@ static struct omap_globals omap242x_globals = {
.ctrl = OMAP2420_CTRL_BASE,
.prm= OMAP2420_PRM_BASE,
.cm = OMAP2420_CM_BASE,
- .uart1_phys = OMAP2_UART1_BASE,
- .uart2_phys = OMAP2_UART2_BASE,
- .uart3_phys = OMAP2_UART3_BASE,
};
void __init omap2_set_globals_242x(void)
@@ -293,9 +289,6 @@ static struct omap_globals omap243x_globals = {
.ctrl = OMAP243X_CTRL_BASE,
.prm= OMAP2430_PRM_BASE,
.cm = OMAP2430_CM_BASE,
- .uart1_phys = OMAP2_UART1_BASE,
- .uart2_phys = OMAP2_UART2_BASE,
- .uart3_phys = OMAP2_UART3_BASE,
};
void __init omap2_set_globals_243x(void)
@@ -314,10 +307,6 @@ static struct omap_globals omap3_globals = {
.ctrl = OMAP343X_CTRL_BASE,
.prm= OMAP3430_PRM_BASE,
.cm = OMAP3430_CM_BASE,
- .uart1_phys = OMAP3_UART1_BASE,
- .uart2_phys = OMAP3_UART2_BASE,
- .uart3_phys = OMAP3_UART3_BASE,
- .uart4_phys = OMAP3_UART4_BASE, /* Only on 3630 */
};
void __init omap2_set_globals_3xxx(void)
@@ -340,10 +329,6 @@ static struct omap_globals omap4_globals = {
.prm= OMAP4430_PRM_BASE,
.cm = OMAP4430_CM_BASE,
.cm2= OMAP4430_CM2_BASE,
- .uart1_phys = OMAP4_UART1_BASE,
- .uart2_phys = OMAP4_UART2_BASE,
- .uart3_phys = OMAP4_UART3_BASE,
- .uart4_phys = OMAP4_UART4_BASE,
};
void __init omap2_set_globals_443x(void)
@@ -351,7 +336,6 @@ void __init omap2_set_globals_443x(void)
omap2_set_globals_tap(omap4_globals);
omap2_set_globals_control(omap4_globals);
omap2_set_globals_prcm(omap4_globals);
- omap2_set_globals_uart(omap4_globals);
}
#endif
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index c45dbb9..159e45c 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -66,7 +66,6 @@ void omap2_set_globals_tap(struct omap_globals *);
void omap2_set_globals_sdrc(struct omap_globals *);
void omap2_set_globals_control(struct omap_globals *);
void omap2_set_globals_prcm(struct omap_globals *);
-void omap2_set_globals_uart(struct omap_globals *);
void omap3_map_io(void);
--
1.6.3.3
--
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/13 v3] OMAP: UART: don't do automatic bus-level suspend/resume
From: Kevin Hilman khil...@deeprootsystems.com
Since the omap_device for UART is currently managed inside the idle
path itself, don't let the bus-level code suspend/resume the UART.
To prevent this, pm_runtime_get() is used when preparing for suspend
and pm_runtime_put() is used when finished with suspend.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 6ffbc92..ff83e91 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -26,6 +26,7 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/serial_8250.h
+#include linux/pm_runtime.h
#ifdef CONFIG_SERIAL_OMAP
#include plat/omap-serial.h
@@ -530,14 +531,17 @@ void omap_uart_enable_irqs(int enable)
struct omap_uart_state *uart;
list_for_each_entry(uart, uart_list, node) {
- if (enable)
+ if (enable) {
+ pm_runtime_put_sync(uart-pdev-dev);
ret = request_threaded_irq(uart-irq, NULL,
omap_uart_interrupt,
IRQF_SHARED,
serial idle,
(void *)uart);
- else
+ } else {
+ pm_runtime_get_noresume(uart-pdev-dev);
free_irq(uart-irq, (void *)uart);
+ }
}
}
--
1.6.3.3
--
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/13 v3] OMAP: UART: use non-locking versions of hwmod enable/idle functions
From: Kevin Hilman khil...@deeprootsystems.com
Since the UART enable/idle is done during the idle path (with
interrupts disabled), use the non-locking versions of the hwmod
enable/idle functions.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 23 +--
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ff83e91..72b5c98 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -105,10 +105,29 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
+/*
+ * Since these idle/enable hooks are used in the idle path itself
+ * which has interrupts disabled, use the non-locking versions of
+ * the hwmod enable/disable functions.
+ */
+static int uart_idle_hwmod(struct omap_device *od)
+{
+ _omap_hwmod_idle(od-hwmods[0]);
+
+ return 0;
+}
+
+static int uart_enable_hwmod(struct omap_device *od)
+{
+ _omap_hwmod_enable(od-hwmods[0]);
+
+ return 0;
+}
+
static struct omap_device_pm_latency omap_uart_latency[] = {
{
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
+ .deactivate_func = uart_idle_hwmod,
+ .activate_func = uart_enable_hwmod,
.flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
},
};
--
1.6.3.3
--
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/13 v3] OMAP clock: Add uart4_ick/fck definitions for 3630
This is only valid for omap 36xx family of chips.
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index dfdce2d..90a4198 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -2465,6 +2465,16 @@ static struct clk uart3_fck = {
.recalc = followparent_recalc,
};
+static struct clk uart4_fck = {
+ .name = uart4_fck,
+ .ops= clkops_omap2_dflt_wait,
+ .parent = per_48m_fck,
+ .enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
+ .enable_bit = OMAP3630_EN_UART4_SHIFT,
+ .clkdm_name = per_clkdm,
+ .recalc = followparent_recalc,
+};
+
static struct clk gpt2_fck = {
.name = gpt2_fck,
.ops= clkops_omap2_dflt_wait,
@@ -2715,6 +2725,16 @@ static struct clk uart3_ick = {
.recalc = followparent_recalc,
};
+static struct clk uart4_ick = {
+ .name = uart4_ick,
+ .ops= clkops_omap2_dflt_wait,
+ .parent = per_l4_ick,
+ .enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_ICLKEN),
+ .enable_bit = OMAP3630_EN_UART4_SHIFT,
+ .clkdm_name = per_clkdm,
+ .recalc = followparent_recalc,
+};
+
static struct clk gpt9_ick = {
.name = gpt9_ick,
.ops= clkops_omap2_dflt_wait,
@@ -3349,6 +3369,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, per_96m_fck, per_96m_fck, CK_3XXX),
CLK(NULL, per_48m_fck, per_48m_fck, CK_3XXX),
CLK(NULL, uart3_fck,uart3_fck, CK_3XXX),
+ CLK(NULL, uart4_fck,uart4_fck, CK_36XX),
CLK(NULL, gpt2_fck, gpt2_fck, CK_3XXX),
CLK(NULL, gpt3_fck, gpt3_fck, CK_3XXX),
CLK(NULL, gpt4_fck, gpt4_fck, CK_3XXX),
@@ -3372,6 +3393,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, gpio2_ick,gpio2_ick, CK_3XXX),
CLK(NULL, wdt3_ick, wdt3_ick, CK_3XXX),
CLK(NULL, uart3_ick,uart3_ick, CK_3XXX),
+ CLK(NULL, uart4_ick,uart4_ick, CK_36XX),
CLK(NULL, gpt9_ick, gpt9_ick, CK_3XXX),
CLK(NULL, gpt8_ick, gpt8_ick, CK_3XXX),
CLK(NULL, gpt7_ick, gpt7_ick, CK_3XXX),
--
1.6.3.3
--
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 08/13 v3] OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs
To standarize among other uarts (1 to 3), we shall now:
- Enable uart4 autodile bit.
- Enable uart4 wakeup in PER.
- Allow uart4 to wakeup the MPU.
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
arch/arm/mach-omap2/pm34xx.c | 15 +--
arch/arm/mach-omap2/prcm-common.h |2 ++
arch/arm/mach-omap2/prm-regbits-34xx.h |1 +
4 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index fe82b79..4f959a7 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -649,6 +649,8 @@
#define OMAP3430_ST_MCBSP2_MASK(1 0)
/* CM_AUTOIDLE_PER */
+#define OMAP3630_AUTO_UART4_MASK (1 18)
+#define OMAP3630_AUTO_UART4_SHIFT 18
#define OMAP3430_AUTO_GPIO6_MASK (1 17)
#define OMAP3430_AUTO_GPIO6_SHIFT 17
#define OMAP3430_AUTO_GPIO5_MASK (1 16)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index d2b940c..043faaa 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -676,6 +676,14 @@ static void __init omap3_d2d_idle(void)
static void __init prcm_setup_regs(void)
{
+ u32 omap3630_auto_uart4_mask = cpu_is_omap3630() ?
+ OMAP3630_AUTO_UART4_MASK : 0;
+ u32 omap3630_en_uart4_mask = cpu_is_omap3630() ?
+ OMAP3630_EN_UART4_MASK : 0;
+ u32 omap3630_grpsel_uart4_mask = cpu_is_omap3630() ?
+ OMAP3630_GRPSEL_UART4_MASK : 0;
+
+
/* XXX Reset all wkdeps. This should be done when initializing
* powerdomains */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, PM_WKDEP);
@@ -762,6 +770,7 @@ static void __init prcm_setup_regs(void)
CM_AUTOIDLE);
cm_write_mod_reg(
+ omap3630_auto_uart4_mask |
OMAP3430_AUTO_GPIO6_MASK |
OMAP3430_AUTO_GPIO5_MASK |
OMAP3430_AUTO_GPIO4_MASK |
@@ -838,14 +847,16 @@ static void __init prcm_setup_regs(void)
OMAP3430_DSS_MOD, PM_WKEN);
/* Enable wakeups in PER */
- prm_write_mod_reg(OMAP3430_EN_GPIO2_MASK | OMAP3430_EN_GPIO3_MASK |
+ prm_write_mod_reg(omap3630_en_uart4_mask |
+ OMAP3430_EN_GPIO2_MASK | OMAP3430_EN_GPIO3_MASK |
OMAP3430_EN_GPIO4_MASK | OMAP3430_EN_GPIO5_MASK |
OMAP3430_EN_GPIO6_MASK | OMAP3430_EN_UART3_MASK |
OMAP3430_EN_MCBSP2_MASK | OMAP3430_EN_MCBSP3_MASK |
OMAP3430_EN_MCBSP4_MASK,
OMAP3430_PER_MOD, PM_WKEN);
/* and allow them to wake up MPU */
- prm_write_mod_reg(OMAP3430_GRPSEL_GPIO2_MASK |
+ prm_write_mod_reg(omap3630_grpsel_uart4_mask |
+ OMAP3430_GRPSEL_GPIO2_MASK |
OMAP3430_GRPSEL_GPIO3_MASK |
OMAP3430_GRPSEL_GPIO4_MASK |
OMAP3430_GRPSEL_GPIO5_MASK |
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 86edcf9..298a22a 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -425,6 +425,8 @@
#define OMAP3430_EN_MCBSP2_SHIFT 0
/* CM_IDLEST_PER, PM_WKST_PER shared bits */
+#define OMAP3630_ST_UART4_SHIFT18
+#define OMAP3630_ST_UART4_MASK (1 18)
#define OMAP3430_ST_GPIO6_SHIFT17
#define OMAP3430_ST_GPIO6_MASK (1 17)
#define OMAP3430_ST_GPIO5_SHIFT16
diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h
b/arch/arm/mach-omap2/prm-regbits-34xx.h
index 7fd6023..9e63cb7 100644
--- a/arch/arm/mach-omap2/prm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
@@ -122,6 +122,7 @@
#define OMAP3430_MEMRETSTATE_MASK (1 8)
/* PM_MPUGRPSEL_PER, PM_IVA2GRPSEL_PER shared bits */
+#define OMAP3630_GRPSEL_UART4_MASK (1 18)
#define OMAP3430_GRPSEL_GPIO6_MASK (1 17)
#define OMAP3430_GRPSEL_GPIO5_MASK (1 16)
#define OMAP3430_GRPSEL_GPIO4_MASK (1 15)
--
1.6.3.3
--
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 09/13 v3] OMAP3: PM: Add prepare idle and resume idle call for uart4
Add prepare idle and resume idle call for uart4 used by 3630.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 043faaa..60baffa 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -388,6 +388,7 @@ void omap_sram_idle(void)
/* PER */
if (per_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(2);
+ omap_uart_prepare_idle(3);
omap2_gpio_prepare_for_idle(per_next_state);
if (per_next_state == PWRDM_POWER_OFF)
omap3_per_save_context();
@@ -459,6 +460,7 @@ void omap_sram_idle(void)
if (per_prev_state == PWRDM_POWER_OFF)
omap3_per_restore_context();
omap_uart_resume_idle(2);
+ omap_uart_resume_idle(3);
}
/* Disable IO-PAD and IO-CHAIN wakeup */
--
1.6.3.3
--
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/13 v3] OMAP3: serial: Fix uart4 handling for 3630
This patch makes the following:
- Adds missing wakeup padding register handling.
- Fixes a hardcode to use PER module ONLY on UART3.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 72b5c98..0bcc9df 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -487,7 +487,7 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
omap_uart_smart_idle_enable(uart, 0);
if (cpu_is_omap34xx()) {
- u32 mod = (uart-num == 2) ? OMAP3430_PER_MOD : CORE_MOD;
+ u32 mod = (uart-num 1) ? OMAP3430_PER_MOD : CORE_MOD;
u32 wk_mask = 0;
u32 padconf = 0;
@@ -506,6 +506,10 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
wk_mask = OMAP3430_ST_UART3_MASK;
padconf = 0x19e;
break;
+ case 3:
+ wk_mask = OMAP3630_ST_UART4_MASK;
+ padconf = 0x0d2;
+ break;
}
uart-wk_mask = wk_mask;
uart-padconf = padconf;
--
1.6.3.3
--
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/13 v3] OMAP: SERIAL: Enable omap-serial driver in Kconfig
Enable omap-serial driver in /mach-omap2/Kconfig and move 8250 driver selection for zoom boards. With omap-serial driver addition all omap-uarts can be handled with omap-serial driver. With addition of omap-serial driver console parameter needs be changed in bootargs from ttyS* should be replaced with ttyO* [O -- OMAP not ZERO] For example: ttyS0[UART1 on 3430SDP] changes to ttyO0. But with some boards that do not use omap-uart as console uart. we need to handle them with 8250 driver. Ex: ZOOM2/3. For zoom2/3 board we need to use 8250 serial driver and console parameter will remain ttyS0 which basically uses a Quad uart placed on the debug board connected through a gpio line. Cc: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/Kconfig | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b48bacf..19b6c5f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -11,9 +11,8 @@ config ARCH_OMAP2PLUS_TYPICAL select PM_RUNTIME select VFP select NEON if ARCH_OMAP3 || ARCH_OMAP4 - select SERIAL_8250 - select SERIAL_CORE_CONSOLE - select SERIAL_8250_CONSOLE + select SERIAL_OMAP + select SERIAL_OMAP_CONSOLE select I2C select I2C_OMAP select MFD @@ -200,12 +199,18 @@ config MACH_OMAP_ZOOM2 depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB + select SERIAL_8250 + select SERIAL_CORE_CONSOLE + select SERIAL_8250_CONSOLE config MACH_OMAP_ZOOM3 bool OMAP3630 Zoom3 board depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBP + select SERIAL_8250 + select SERIAL_CORE_CONSOLE + select SERIAL_8250_CONSOLE config MACH_CM_T35 bool CompuLab CM-T35 module -- 1.6.3.3 -- 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/13 v3] serial: Add OMAP high-speed UART driver
This patch adds driver support for OMAP2/3/4 high speed UART.
The driver is made separate from 8250 driver as we cannot
over load 8250 driver with omap platform specific configuration for
features like DMA, it makes easier to implement features like DMA and
hardware flow control and software flow control configuration with
this driver as required for the omap-platform.
This patch involves only the core driver and its dependent.
Cc: Tony Lindgren t...@atomide.com
Tested-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h | 129 +++
drivers/serial/Kconfig| 27 +
drivers/serial/Makefile |1 +
drivers/serial/omap-serial.c | 1333 +
include/linux/serial_core.h |3 +
5 files changed, 1493 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h
create mode 100644 drivers/serial/omap-serial.c
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
new file mode 100644
index 000..0d6f076
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -0,0 +1,129 @@
+/*
+ * Driver for OMAP-UART controller.
+ * Based on drivers/serial/8250.c
+ *
+ * Copyright (C) 2010 Texas Instruments.
+ *
+ * Authors:
+ * Govindraj R govindraj.r...@ti.com
+ * Thara Gopinath th...@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.
+ */
+
+#ifndef __OMAP_SERIAL_H__
+#define __OMAP_SERIAL_H__
+
+#include linux/serial_core.h
+#include linux/platform_device.h
+
+#include plat/control.h
+#include plat/mux.h
+
+#define DRIVER_NAMEomap-hsuart
+
+/*
+ * Use tty device name as ttyO, [O - OMAP]
+ * in bootargs we specify as console=ttyO0 if uart1
+ * is used as console uart.
+ */
+#define OMAP_SERIAL_NAME ttyO
+
+#define OMAP_MDR1_DISABLE 0x07
+#define OMAP_MDR1_MODE13X 0x03
+#define OMAP_MDR1_MODE16X 0x00
+#define OMAP_MODE13X_SPEED 230400
+
+/*
+ * LCR = 0XBF: Switch to Configuration Mode B.
+ * In configuration mode b allow access
+ * to EFR,DLL,DLH.
+ * Reference OMAP TRM Chapter 17
+ * Section: 1.4.3 Mode Selection
+ */
+#define OMAP_UART_LCR_CONF_MDB 0XBF
+
+/* WER = 0x7F
+ * Enable module level wakeup in WER reg
+ */
+#define OMAP_UART_WER_MOD_WKUP 0X7F
+
+/* Enable XON/XOFF flow control on output */
+#define OMAP_UART_SW_TX0x04
+
+/* Enable XON/XOFF flow control on input */
+#define OMAP_UART_SW_RX0x04
+
+#define OMAP_UART_SYSC_RESET 0X07
+#define OMAP_UART_TCR_TRIG 0X0F
+#define OMAP_UART_SW_CLR 0XF0
+#define OMAP_UART_FIFO_CLR 0X06
+
+#define OMAP_UART_DMA_CH_FREE -1
+
+#define RX_TIMEOUT (3 * HZ)
+#define OMAP_MAX_HSUART_PORTS 4
+
+#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
+
+struct omap_uart_port_info {
+ booldma_enabled;/* To specify DMA Mode */
+ unsigned intuartclk;/* UART clock rate */
+ void __iomem*membase; /* ioremap cookie or NULL */
+ resource_size_t mapbase;/* resource base */
+ unsigned long irqflags; /* request_irq flags */
+ upf_t flags; /* UPF_* flags */
+};
+
+struct uart_omap_dma {
+ u8 uart_dma_tx;
+ u8 uart_dma_rx;
+ int rx_dma_channel;
+ int tx_dma_channel;
+ dma_addr_t rx_buf_dma_phys;
+ dma_addr_t tx_buf_dma_phys;
+ unsigned intuart_base;
+ /*
+* Buffer for rx dma.It is not required for tx because the buffer
+* comes from port structure.
+*/
+ unsigned char *rx_buf;
+ unsigned intprev_rx_dma_pos;
+ int tx_buf_size;
+ int tx_dma_used;
+ int rx_dma_used;
+ spinlock_t tx_lock;
+ spinlock_t rx_lock;
+ /* timer to poll activity on rx dma */
+ struct timer_list rx_timer;
+ int rx_buf_size;
+ int rx_timeout;
+};
+
+struct uart_omap_port {
+ struct uart_portport;
+ struct uart_omap_dmauart_dma;
+ struct platform_device *pdev;
+
+ unsigned char ier;
+ unsigned char lcr;
+ unsigned char mcr;
+ unsigned char fcr;
+ unsigned char efr;
+
+ int use_dma;
+ /*
+* Some bits in registers are
[PATCH 13/13 v3] OMAP3: SERIAL: Initialize all omap-uarts for zoom boards
Iniatize all omap-uarts for zoom boards.
Now zoom_peripheral_init will initialise
all uarts for 3630. 3630sdp_board_init call
zoom_peripheral_init so we can now remove
serial_init from 3630sdp board init as
zoom_peripheral_init now will do that the
same.
Signed-off-by: Kevin Hilman khil...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/board-3630sdp.c |1 -
arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index b359c3f..d510451 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -208,7 +208,6 @@ static struct flash_partitions sdp_flash_partitions[] = {
static void __init omap_sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
- omap_serial_init();
zoom_peripherals_init();
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_sdp);
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..641765a 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -282,4 +282,5 @@ void __init zoom_peripherals_init(void)
omap_i2c_init();
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
+ omap_serial_init();
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
Basak, Partha p-bas...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, September 24, 2010 5:23 AM To: Basak, Partha Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Tero Kristo; Cousson, Benoit Subject: Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path Kevin Hilman khil...@deeprootsystems.com writes: [...] We cannot do a get_sync() from ISR context, right? Right, but we *should* be able to. ;) I'm still trying to craft a good description of this problem so I can argue better for it on linux-pm. Until then... A bit of a hack, but you could do a _get_noresume() (which is safe from interrupt context) and directly call the drivers -runtime_resume() method, which would be the equivalent of a _get_sync(). Followed of course by a _put() (async version, also interrupt safe) at the end of the ISR to keep the usecount correct. You probably figured this out already, but I just realized that this won't currently work either as omap_hwmod is using mutexes, and is safe in ISR context either. :( What about for now just directly enabling (and re-disabling) the hwmod clocks in the ISR using omap_hwmod_[enable|disable]_clocks() Since this is a core driver in arch/arm/*omap*, you can directly call the omap_hwmod API. omap_hwmod_[enable/disable]_clocks() use mutex inside therefore cannot be used in the ISR context We cannot readily use the _enable_clocks/_disble_clocks directly as they are static APIs. But we can use the non-mutex versions, of omap_hwmod_enable/idle. (_omap_hwmod_enable/_omap_hwmod_disable) Do you agree? Yes, I meant to use the non-mutex versions. Sorry, 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
uninstall
-- 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
uninstall
-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC:] FIX: OMAP3EVM: Ethernet controller smsc911x reset
Varadarajan, Charulatha ch...@ti.com writes:
Sanjeev,
With GPIO hwmod series, OMAP3EVM board is not up with DHCP + nfs root.
This issue was reported by Kevin.
The root cause of this issue is that during OMAP3EVM board init, the
Ethernet controller (smsc911x) is not reset and it relies on the uboot
configurations for it's operations. The reset GPIO pin used for this
purpose is not even reserved.
After gpio hmwod series are merged, this patch is required to make the
EVM board working. Also omap3evm_init_smsc911x() needs to be fixed
including CS settings and other required settings for Ethernet controller.
Links to related discussions:
http://www.spinics.net/lists/linux-omap/msg37234.html
http://www.spinics.net/lists/linux-omap/msg36698.html
http://www.spinics.net/lists/linux-omap/msg36799.html
The below patch is tested on OMAP3 EVM board (ES3.1).
Also note that the patch below didn't work on my EVM (ES2.1), making me
assume that it uses a different GPIO for older boards.
Kevin
-Original Message-
From: Varadarajan, Charulatha
Sent: Saturday, September 25, 2010 5:07 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; t...@atomide.com; Premi, Sanjeev;
Varadarajan, Charulatha
Subject: [PATCH RFC:] FIX: OMAP3EVM: Ethernet controller smsc911x reset
Do reset of Ethernet controller smsc911x using OMAP gpio7
while initializing the Ethernet controller.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index f76d9c0..54a7e20 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -55,6 +55,7 @@
#define OMAP3EVM_ETHR_SIZE 1024
#define OMAP3EVM_ETHR_ID_REV0x50
#define OMAP3EVM_ETHR_GPIO_IRQ 176
+#define OMAP3EVM_ETHR_GPIO_RST 7
#define OMAP3EVM_SMSC911X_CS5
static u8 omap3_evm_version;
@@ -134,6 +135,20 @@ static inline void __init
omap3evm_init_smsc911x(void)
else
rate = clk_get_rate(l3ck);
+/* Configure ethernet controller reset gpio */
+if (gpio_request(OMAP3EVM_ETHR_GPIO_RST, SMSC911x gpio) 0) {
+pr_err(KERN_ERR Failed to request GPIO8 for smsc911x
gpio\n);
+return;
+}
+
+gpio_direction_output(OMAP3EVM_ETHR_GPIO_RST, 1);
+
+/* reset pulse to ethernet controller*/
+gpio_set_value(OMAP3EVM_ETHR_GPIO_RST, 0);
+usleep_range(150, 220);
+gpio_set_value(OMAP3EVM_ETHR_GPIO_RST, 1);
+usleep_range(1, 2);
+
if (gpio_request(OMAP3EVM_ETHR_GPIO_IRQ, SMSC911x irq) 0) {
printk(KERN_ERR Failed to request GPIO%d for smsc911x IRQ\n,
OMAP3EVM_ETHR_GPIO_IRQ);
--
1.7.0.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: [GIT PULL] omap2 sparse fixes
Hi Russell, -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Monday, September 27, 2010 7:38 PM To: G, Manjunath Kondaiah Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [GIT PULL] omap2 sparse fixes On Mon, Sep 27, 2010 at 07:11:37PM +0530, G, Manjunath Kondaiah wrote: Can you please check that? Will not merge for now until we figure out what changes with these patches. Then, I also noticed the following exports getting added: +EXPORT_SYMBOL(omap2_gp_clockevent_set_gptimer); +EXPORT_SYMBOL(omapfb_reserve_sram); +EXPORT_SYMBOL(omap_sram_init); These should not be exported, they are only intended to be called from the low-level platform init code. So exporting them is not the right fix for these. I have declared these API's as extern functions in respective header files. It's hard to tell whether you're justifying having the EXPORT_SYMBOLs there or not from your reply. I tried following approches in order to fix these warnings: 1. Having these defines in .c files as extern functions. It will generate checkpatch error if it is declared as extern in .c file. 2. Moving/creating header file to source code location. This will resolve only omap2_gp_clockevent_set_gptimer function since other functions are used in source files in different directories. Only option came to my mind is, having it in header file either in plat or mach headers. As you said, even though it is not explicitely declared as EXPORT, the functions are available for all other files. -Manjunath -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RFC:] FIX: OMAP3EVM: Ethernet controller smsc911x reset
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, September 27, 2010 8:26 PM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; Premi, Sanjeev; t...@atomide.com
Subject: Re: [PATCH RFC:] FIX: OMAP3EVM: Ethernet controller
smsc911x reset
Varadarajan, Charulatha ch...@ti.com writes:
Sanjeev,
With GPIO hwmod series, OMAP3EVM board is not up with DHCP
+ nfs root.
This issue was reported by Kevin.
The root cause of this issue is that during OMAP3EVM board init, the
Ethernet controller (smsc911x) is not reset and it relies
on the uboot
configurations for it's operations. The reset GPIO pin used for this
purpose is not even reserved.
After gpio hmwod series are merged, this patch is required
to make the
EVM board working. Also omap3evm_init_smsc911x() needs to be fixed
including CS settings and other required settings for
Ethernet controller.
Links to related discussions:
http://www.spinics.net/lists/linux-omap/msg37234.html
http://www.spinics.net/lists/linux-omap/msg36698.html
http://www.spinics.net/lists/linux-omap/msg36799.html
The below patch is tested on OMAP3 EVM board (ES3.1).
Also note that the patch below didn't work on my EVM (ES2.1),
making me
assume that it uses a different GPIO for older boards.
I am waiting for right person to review the patches; he was
on travel this weekend. Hope to get his time tomorrow...
Kevin
-Original Message-
From: Varadarajan, Charulatha
Sent: Saturday, September 25, 2010 5:07 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; t...@atomide.com; Premi, Sanjeev;
Varadarajan, Charulatha
Subject: [PATCH RFC:] FIX: OMAP3EVM: Ethernet controller
smsc911x reset
Do reset of Ethernet controller smsc911x using OMAP gpio7
while initializing the Ethernet controller.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index f76d9c0..54a7e20 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -55,6 +55,7 @@
#define OMAP3EVM_ETHR_SIZE1024
#define OMAP3EVM_ETHR_ID_REV 0x50
#define OMAP3EVM_ETHR_GPIO_IRQ176
+#define OMAP3EVM_ETHR_GPIO_RST 7
#define OMAP3EVM_SMSC911X_CS 5
static u8 omap3_evm_version;
@@ -134,6 +135,20 @@ static inline void __init
omap3evm_init_smsc911x(void)
else
rate = clk_get_rate(l3ck);
+ /* Configure ethernet controller reset gpio */
+ if (gpio_request(OMAP3EVM_ETHR_GPIO_RST, SMSC911x gpio) 0) {
+ pr_err(KERN_ERR Failed to request GPIO8 for smsc911x
gpio\n);
+ return;
+ }
+
+ gpio_direction_output(OMAP3EVM_ETHR_GPIO_RST, 1);
+
+ /* reset pulse to ethernet controller*/
+ gpio_set_value(OMAP3EVM_ETHR_GPIO_RST, 0);
+ usleep_range(150, 220);
+ gpio_set_value(OMAP3EVM_ETHR_GPIO_RST, 1);
+ usleep_range(1, 2);
+
if (gpio_request(OMAP3EVM_ETHR_GPIO_IRQ, SMSC911x irq) 0) {
printk(KERN_ERR Failed to request GPIO%d for
smsc911x IRQ\n,
OMAP3EVM_ETHR_GPIO_IRQ);
--
1.7.0.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: [QUESTION] How to enable runtime PM
Ming Lei tom.leim...@gmail.com writes: Hi Kevin, I am interested in runtime pm implementation on OMAP3, and want to test this function on omap3-based beagle board, but seems no devices on omap3 Soc can support runtime pm(no __pm_runtime_* message found from 'dmesg' and rpm debug option is surely enabled) now after trying the two omap trees below: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git#pm-core git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git#pm So, could you give me some guideline about how to bring up runtime pm on beagle? such as, which git tree and branch should be used? which option should be enabled? or other things. Hello, Thanks for the interest in willing to experiment with runtime PM on OMAP. You're observations are correct. The runtime PM core is ready, but none of the devices have yet been adapted to the runtime PM API. We will be converting devices over to runtime PM over the next few merge windows, with possibly some coming as soon as 2.6.37 (watchdog, UART, GPIO, i2c) 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: [RFC 1/5] OMAP: mux: Add support for control module split in several partitions
* Tony Lindgren t...@atomide.com [100924 17:14]:
* Benoit Cousson b-cous...@ti.com [100924 02:07]:
If we wanted to use only the offset in the data, we could initialize
the various sections separately. But then omapX_mux_init() would have
to know the partition number somehow..
After thinking about this a bit more, to me it seems like this is
the best way to go. Then there's no need to repeat the partition data
for each entry. How about this:
Earlier defines stay the same:
#define OMAP3_MUX(mode0, mux_value) \
{ \
.reg_offset = (OMAP3_CONTROL_PADCONF_##mode0##_OFFSET), \
.value = (mux_value), \
}
Then for omap4, we need to add a separate board mux table for each
partition:
#define OMAP4_MUX_PARTXXX(mode0, mux_value) \
{ \
.reg_offset = (OMAP4_PART_XXX_PADCONF_##mode0##_OFFSET),\
.value = (mux_value), \
}
#define OMAP4_MUX_PARTYYY(mode0, mux_value) \
{ \
.reg_offset = (OMAP4_PARTYYY_PADCONF_##mode0##_OFFSET), \
.value = (mux_value), \
}
...
For omap2 and 3, we just call omap_mux_init once with the mux_pbase
as we currently already do. Then for omap4, we call omap_mux_init for
each partition.
We also need to change omap_mux_read/write to allow specifying the
partition base address:
u16 omap_mux_read(void __iomem *base, u16 offset)
{
if (cpu_is_omap24xx())
return __raw_readb(base + offset);
else
return __raw_readw(base + offset);
}
All the other mux interface functions can stay the same, we just need
to modify the mux.c code to look for signal names or GPIO number in
each registered partition.
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] mfd: speedup twl4030 irq response time and decrease irq disable time
Hi Tom,
On Wed, Sep 22, 2010 at 09:49:31AM +0800, tom.leim...@gmail.com wrote:
From: Ming Lei tom.leim...@gmail.com
This patch sets scheduler policy of twl4030 irq thread
(twl4030_irq_thread) as SCHED_FIFO to speedup irq response
time, just like taken by kernel threaded irq in irq_thread
(kernel/irq/manage.c). Also higher priority than that of
threaded irq is taken to avoid preemption from twl4030
subchips's threaded irq handler, so pih irq disable time may
be decreased.
Wouldn't converting your twl4030_irq_thread() to the threaded IRQ framework
fix that problem ?
The pih irq is disabled in handle_twl4030_pih which may
wakeup twl4030 irq thread, and the pih irq will be enabled
again until complete of all sih irqs' handling in twl4030
irq thread.
Also for each one interrupt line of twl4030 subchip, only
two irq events can be buffered by twl4030(4.4.2.3 of TPS65950 TRM).
Could you explain how is that related to the patch below ?
Cheers,
Samuel.
Signed-off-by: Ming Lei tom.leim...@gmail.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Balaji T K balaj...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: linux-ker...@vger.kernel.org
---
drivers/mfd/twl4030-irq.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 097f24d..d1e0d80 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -286,8 +286,16 @@ static int twl4030_irq_thread(void *data)
long irq = (long)data;
static unsigned i2c_errors;
static const unsigned max_i2c_errors = 100;
-
-
+ struct sched_param param = {
+ .sched_priority = MAX_USER_RT_PRIO/2 + 10,
+ };
+
+ /* Take higher priority than threaded irq to make us immune of
+ * preemption from twl4030 subchips's threaded irq handler, then
+ * we can complete all SIH irqs' handling and enable PIH irq
+ * again asap.
+ * */
+ sched_setscheduler(current, SCHED_FIFO, param);
current-flags |= PF_NOFREEZE;
while (!kthread_should_stop()) {
--
1.6.2.5
--
Intel Open Source Technology Centre
http://oss.intel.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 05/11] omap3: Remove non-existent config option
On Mon, Sep 27, 2010 at 2:02 PM, Marathe, Yogesh yogesh_mara...@ti.com wrote: When you merge iommu support, then either you enable CONFIG_MPU_BRIDGE_IOMMU unconditionally, or you apply this patch, but this patch alone will only break things. Any other driver which does not depend on bridge and interested in using iommu should get the handle when iommu_get(iva2) is called. That's a hypothetical driver, right? The only driver that would ever be interested in the iva2 iommu is tidspbridge, and this patch would brake it. It is not happening in original case. I think there should not be restrictions on other drivers to define un-related compile time define if they just want to use iommu driver. I feel the implementation that is breaking due to removal of this define should be fixed. I couldn't parse that correctly. However, what's wrong with the proposal? Let's think about CONFIG_MPU_BRIDGE_IOMMU when the iommu patches come. -- Felipe Contreras -- 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 v4 0/4] LogicPD minimal board support for LV_SOM and Torpedo
This was tested (and based) against 2.6.36-rc5 Difference from patch v3 1/4: - Merged DEBUG_LL support patch (patch v3 5/5) into first patch - Added select OMAP_PACKAGE_CBB into Kconfig for both boards Tim Nordell (4): Adding LogicPD OMAP3 board support ARM: OMAP3LOGIC: Adding SDMMC support ARM: OMAP3: Add generic smsc911x support when connected to GPMC ARM: OMAP3LOGIC: Added SMSC Ethernet board support arch/arm/mach-omap2/Kconfig | 20 ++ arch/arm/mach-omap2/Makefile|7 + arch/arm/mach-omap2/board-omap3logic.c | 244 +++ arch/arm/mach-omap2/gpmc-smsc911x.c | 113 +++ arch/arm/plat-omap/include/plat/gpmc-smsc911x.h | 35 arch/arm/plat-omap/include/plat/uncompress.h|2 + 6 files changed, 421 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3logic.c create mode 100644 arch/arm/mach-omap2/gpmc-smsc911x.c create mode 100644 arch/arm/plat-omap/include/plat/gpmc-smsc911x.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
[PATCH v4 2/4] ARM: OMAP3LOGIC: Adding SDMMC support
Add low-level initialization for hsmmc controller for
LogicPD's OMAP 3530 LV SOM and OMAP 35x Torpedo board.
Signed-off-by: Tim Nordell tim.nord...@logicpd.com
---
arch/arm/mach-omap2/board-omap3logic.c | 38 +++-
1 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index ac3b0f7..e1f8fbe 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -33,6 +33,7 @@
#include asm/mach/map.h
#include mux.h
+#include hsmmc.h
#include plat/mux.h
#include plat/board.h
@@ -87,6 +88,7 @@ static struct twl4030_platform_data omap3logic_twldata = {
/* platform_data for children goes here */
.gpio = omap3logic_gpio_data,
+ .vmmc1 = omap3logic_vmmc1,
};
static struct i2c_board_info __initdata omap3logic_i2c_boardinfo[] = {
@@ -105,6 +107,40 @@ static int __init omap3logic_i2c_init(void)
return 0;
}
+static struct omap2_hsmmc_info __initdata board_mmc_info[] = {
+ {
+ .name = external,
+ .mmc= 1,
+ .wires = 4,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ },
+ {} /* Terminator */
+};
+
+static void __init board_mmc_init(void)
+{
+ if (machine_is_omap3530_lv_som()) {
+ /* OMAP3530 LV SOM board */
+ board_mmc_info[0].gpio_cd = OMAP3530_LV_SOM_MMC_GPIO_CD;
+ board_mmc_info[0].gpio_wp = OMAP3530_LV_SOM_MMC_GPIO_WP;
+ omap_mux_init_signal(gpio_110, OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(gpio_126, OMAP_PIN_OUTPUT);
+ } else if (machine_is_omap3_torpedo()) {
+ /* OMAP3 Torpedo board */
+ board_mmc_info[0].gpio_cd = OMAP3_TORPEDO_MMC_GPIO_CD;
+ omap_mux_init_signal(gpio_127, OMAP_PIN_OUTPUT);
+ } else {
+ /* unsupported board */
+ printk(KERN_ERR %s(): unknown machine type\n, __func__);
+ return;
+ }
+
+ omap2_hsmmc_init(board_mmc_info);
+ /* link regulators to MMC adapters */
+ omap3logic_vmmc1_supply.dev = board_mmc_info[0].dev;
+}
+
static void __init omap3logic_init_irq(void)
{
omap2_init_common_hw(NULL, NULL);
@@ -116,7 +152,7 @@ static void __init omap3logic_init(void)
{
omap3logic_i2c_init();
omap_serial_init();
-
+ board_mmc_init();
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT);
--
1.7.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 v4 4/4] ARM: OMAP3LOGIC: Added SMSC Ethernet board support
Enable SMSC911x Ethernet driver for LogicPD's OMAP
3530 LV SOM and OMAP 35x Torpedo board.
Signed-off-by: Tim Nordell tim.nord...@logicpd.com
---
arch/arm/mach-omap2/board-omap3logic.c | 65
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index e1f8fbe..687213a 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -38,6 +38,7 @@
#include plat/mux.h
#include plat/board.h
#include plat/common.h
+#include plat/gpmc-smsc911x.h
#include plat/gpmc.h
#include plat/timer-gp.h
#include plat/sdrc.h
@@ -141,6 +142,58 @@ static void __init board_mmc_init(void)
omap3logic_vmmc1_supply.dev = board_mmc_info[0].dev;
}
+static struct omap_smsc911x_platform_data __initdata board_smsc911x_data = {
+ .cs = OMAP3LOGIC_SMSC911X_CS,
+ .gpio_irq = -EINVAL,
+ .gpio_reset = -EINVAL,
+ .flags = IORESOURCE_IRQ_LOWLEVEL,
+};
+
+/* TODO/FIXME (comment by Peter Barada, LogicPD):
+ * Fix the PBIAS voltage for Torpedo MMC1 pins that
+ * are used for other needs (IRQs, etc).*/
+static void omap3torpedo_fix_pbias_voltage(void)
+{
+ u16 control_pbias_offset = OMAP343X_CONTROL_PBIAS_LITE;
+ u32 reg;
+
+ if (machine_is_omap3_torpedo())
+ {
+ /* Set the bias for the pin */
+ reg = omap_ctrl_readl(control_pbias_offset);
+
+ reg = ~OMAP343X_PBIASLITEPWRDNZ1;
+ omap_ctrl_writel(reg, control_pbias_offset);
+
+ /* 100ms delay required for PBIAS configuration */
+ msleep(100);
+
+ reg |= OMAP343X_PBIASLITEVMODE1;
+ reg |= OMAP343X_PBIASLITEPWRDNZ1;
+ omap_ctrl_writel(reg | 0x300, control_pbias_offset);
+ }
+}
+
+static inline void __init board_smsc911x_init(void)
+{
+ if (machine_is_omap3530_lv_som()) {
+ /* OMAP3530 LV SOM board */
+ board_smsc911x_data.gpio_irq =
+ OMAP3530_LV_SOM_SMSC911X_GPIO_IRQ;
+ omap_mux_init_signal(gpio_152, OMAP_PIN_INPUT);
+ } else if (machine_is_omap3_torpedo()) {
+ /* OMAP3 Torpedo board */
+ board_smsc911x_data.gpio_irq = OMAP3_TORPEDO_SMSC911X_GPIO_IRQ;
+ omap_mux_init_signal(gpio_129, OMAP_PIN_INPUT);
+ } else {
+ /* unsupported board */
+ printk(KERN_ERR %s(): unknown machine type\n, __func__);
+ return;
+ }
+
+ gpmc_smsc911x_init(board_smsc911x_data);
+}
+
static void __init omap3logic_init_irq(void)
{
omap2_init_common_hw(NULL, NULL);
@@ -148,11 +201,23 @@ static void __init omap3logic_init_irq(void)
omap_gpio_init();
}
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init omap3logic_init(void)
{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap3torpedo_fix_pbias_voltage();
omap3logic_i2c_init();
omap_serial_init();
board_mmc_init();
+ board_smsc911x_init();
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT);
--
1.7.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 v4 3/4] ARM: OMAP3: Add generic smsc911x support when connected to GPMC
Introduce of a generic way to setup smsc911x based Ethernet
controller connected to GPMC similar to gpmc-smc91x but without
timing setup.
Signed-off-by: Tim Nordell tim.nord...@logicpd.com
---
arch/arm/mach-omap2/Makefile|3 +
arch/arm/mach-omap2/gpmc-smsc911x.c | 113 +++
arch/arm/plat-omap/include/plat/gpmc-smsc911x.h | 35 +++
3 files changed, 151 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-smsc911x.c
create mode 100644 arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9feadd8..f7ec388 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -178,3 +178,6 @@ obj-y += $(nand-m)
$(nand-y)
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
+
+smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
+obj-y += $(smsc911x-m) $(smsc911x-y)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
new file mode 100644
index 000..703f150
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -0,0 +1,113 @@
+/*
+ * linux/arch/arm/mach-omap2/gpmc-smsc911x.c
+ *
+ * Copyright (C) 2009 Li-Pro.Net
+ * Stephan Linz l...@li-pro.net
+ *
+ * Modified from linux/arch/arm/mach-omap2/gpmc-smc91x.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/smsc911x.h
+
+#include plat/board.h
+#include plat/gpmc.h
+#include plat/gpmc-smsc911x.h
+
+static struct omap_smsc911x_platform_data *gpmc_cfg;
+
+static struct resource gpmc_smsc911x_resources[] = {
+ [0] = {
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct smsc911x_platform_config gpmc_smsc911x_config = {
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+ .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+ .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
+ .flags = SMSC911X_USE_16BIT,
+};
+
+static struct platform_device gpmc_smsc911x_device = {
+ .name = smsc911x,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(gpmc_smsc911x_resources),
+ .resource = gpmc_smsc911x_resources,
+ .dev= {
+ .platform_data = gpmc_smsc911x_config,
+ },
+};
+
+/*
+ * Initialize smsc911x device connected to the GPMC. Note that we
+ * assume that pin multiplexing is done in the board-*.c file,
+ * or in the bootloader.
+ */
+void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *board_data)
+{
+ unsigned long cs_mem_base;
+ int ret;
+
+ gpmc_cfg = board_data;
+
+ if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
+ printk(KERN_ERR Failed to request GPMC mem for smsc911x\n);
+ return;
+ }
+
+ gpmc_smsc911x_resources[0].start = cs_mem_base + 0x0;
+ gpmc_smsc911x_resources[0].end = cs_mem_base + 0xff;
+
+ if (gpio_request(gpmc_cfg-gpio_irq, smsc911x irq) 0) {
+ printk(KERN_ERR Failed to request GPIO%d for smsc911x IRQ\n,
+ gpmc_cfg-gpio_irq);
+ goto free1;
+ }
+
+ gpio_direction_input(gpmc_cfg-gpio_irq);
+ gpmc_smsc911x_resources[1].start = gpio_to_irq(gpmc_cfg-gpio_irq);
+ gpmc_smsc911x_resources[1].flags |=
+ (gpmc_cfg-flags IRQF_TRIGGER_MASK);
+
+ if (gpio_is_valid(gpmc_cfg-gpio_reset)) {
+ ret = gpio_request(gpmc_cfg-gpio_reset, smsc911x reset);
+ if (ret) {
+ printk(KERN_ERR Failed to request GPIO%d for smsc911x
reset\n,
+ gpmc_cfg-gpio_reset);
+ goto free2;
+ }
+
+ gpio_direction_output(gpmc_cfg-gpio_reset, 1);
+ gpio_set_value(gpmc_cfg-gpio_reset, 0);
+ msleep(100);
+ gpio_set_value(gpmc_cfg-gpio_reset, 1);
+ }
+
+ if (platform_device_register(gpmc_smsc911x_device) 0) {
+ printk(KERN_ERR Unable to register smsc911x device\n);
+ gpio_free(gpmc_cfg-gpio_reset);
+ goto free2;
+ }
+
+ return;
+
+free2:
+ gpio_free(gpmc_cfg-gpio_irq);
+free1:
+ gpmc_cs_free(gpmc_cfg-cs);
+
+ printk(KERN_ERR Could not initialize smsc911x\n);
+}
diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
[PATCH v4 1/4] Adding LogicPD OMAP3 board support
Adding support for LogicPD's OMAP 3530 LV SOM and
OMAP 35x Torpedo board.
Signed-off-by: Tim Nordell tim.nord...@logicpd.com
---
arch/arm/mach-omap2/Kconfig | 20
arch/arm/mach-omap2/Makefile |4 +
arch/arm/mach-omap2/board-omap3logic.c | 143 ++
arch/arm/plat-omap/include/plat/uncompress.h |2 +
4 files changed, 169 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3logic.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b48bacf..5403443 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -135,6 +135,26 @@ config MACH_OMAP_LDP
default y
select OMAP_PACKAGE_CBB
+config MACH_OMAP3530_LV_SOM
+ bool OMAP3 Logic 3530 LV SOM board
+ depends on ARCH_OMAP3
+ select OMAP_PACKAGE_CBB
+ default y
+ help
+Support for the LogicPD OMAP3530 SOM Development kit
+for full description please see the products webpage at
+
http://www.logicpd.com/products/development-kits/texas-instruments-zoom%E2%84%A2-omap35x-development-kit
+
+config MACH_OMAP3_TORPEDO
+ bool OMAP3 Logic 35x Torpedo board
+ depends on ARCH_OMAP3
+ select OMAP_PACKAGE_CBB
+ default y
+ help
+Support for the LogicPD OMAP35x Torpedo Development kit
+for full description please see the products webpage at
+
http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit
+
config MACH_OVERO
bool Gumstix Overo board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..9feadd8 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -115,6 +115,10 @@ obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
board-flash.o \
hsmmc.o
+obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o \
+ hsmmc.o
+obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \
+ hsmmc.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
new file mode 100644
index 000..ac3b0f7
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -0,0 +1,143 @@
+/*
+ * linux/arch/arm/mach-omap2/board-omap3logic.c
+ *
+ * Copyright (C) 2010 Li-Pro.Net
+ * Stephan Linz l...@li-pro.net
+ *
+ * Copyright (C) 2010 Logic Product Development, Inc.
+ * Peter Barada peter.bar...@logicpd.com
+ *
+ * Modified from Beagle, EVM, and RX51
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/gpio.h
+
+#include linux/regulator/machine.h
+
+#include linux/i2c/twl.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include mux.h
+
+#include plat/mux.h
+#include plat/board.h
+#include plat/common.h
+#include plat/gpmc.h
+#include plat/timer-gp.h
+#include plat/sdrc.h
+#include plat/control.h
+
+#define OMAP3LOGIC_SMSC911X_CS 1
+
+#define OMAP3530_LV_SOM_MMC_GPIO_CD110
+#define OMAP3530_LV_SOM_MMC_GPIO_WP126
+#define OMAP3530_LV_SOM_SMSC911X_GPIO_IRQ 152
+
+#define OMAP3_TORPEDO_MMC_GPIO_CD 127
+#define OMAP3_TORPEDO_SMSC911X_GPIO_IRQ129
+
+static struct regulator_consumer_supply omap3logic_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
+static struct regulator_init_data omap3logic_vmmc1 = {
+ .constraints = {
+ .name = VMMC1,
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = omap3logic_vmmc1_supply,
+};
+
+static struct twl4030_gpio_platform_data omap3logic_gpio_data = {
+ .gpio_base =
Re: [PATCH v3] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Mon, Sep 27, 2010 at 6:38 PM, Grazvydas Ignotas nota...@gmail.com wrote: On Mon, Sep 27, 2010 at 3:35 PM, Arun Murthy arunrmurthy...@gmail.com wrote: On Mon, Sep 27, 2010 at 4:24 PM, Grazvydas Ignotas nota...@gmail.com wrote: On Mon, Sep 27, 2010 at 10:21 AM, Arun Murthy arunrmurthy...@gmail.com wrote: The problem is that BCI is only active while charging, when it is not charging most (all?) monitoring registers freeze and no monitoring happens (BCI registers read frozen values from last charge). So I don't register battery as it has no useful data to report. I heard it is possible to use MADC to perform monitoring while not charging, so battery can be added when MADC driver is merged and corresponding code is written for this driver. How do I check the battery voltage? I need to check the battery voltage/current/temp and, if I am not wrong these are obtained from MADC. MADC driver has to be added first and then the battery. With being able to read the basic parameter battery voltage, this driver becomes incomplete. Incomplete driver is better than no driver, don't you think? There are some boards like pandora or oswald that have additional battery monitoring chips (as twl monitoring is pretty crude anyway), those boards would have fully functional charging now. Currently mainline kernel is not very useful with them simply because the battery runs flat. I agree, but I feel it would be better to make driver compatible with all boards(Zoom2, OMAP3430SDP, Chameleon, BeagleBoard etc). Even support for back-up battery is not supported. This is just a suggestion to have a full fledged driver for twl4030 Battery Charger Interface as a module. You may discard this if you have some strong reasons. How do I get notified if battery voltage is low and needs charging from user space? Either additional monitoring chip notifies you (if you are lucky and have one), or wait for update of this driver :) There are efforts to merge MADC driver [1], but it may take some time. But using MADC, I can get the battery voltage and by means of monitoring battery voltage we can get to know low battery notification. [1] http://marc.info/?t=12846153572r=1w=2 Thanks and Regards, Arun R Murthy -- 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 05/11] omap3: Remove non-existent config option
* Felipe Contreras felipe.contre...@gmail.com [100927 08:47]: On Mon, Sep 27, 2010 at 2:02 PM, Marathe, Yogesh yogesh_mara...@ti.com wrote: When you merge iommu support, then either you enable CONFIG_MPU_BRIDGE_IOMMU unconditionally, or you apply this patch, but this patch alone will only break things. Any other driver which does not depend on bridge and interested in using iommu should get the handle when iommu_get(iva2) is called. That's a hypothetical driver, right? The only driver that would ever be interested in the iva2 iommu is tidspbridge, and this patch would brake it. It is not happening in original case. I think there should not be restrictions on other drivers to define un-related compile time define if they just want to use iommu driver. I feel the implementation that is breaking due to removal of this define should be fixed. I couldn't parse that correctly. However, what's wrong with the proposal? Let's think about CONFIG_MPU_BRIDGE_IOMMU when the iommu patches come. Let's not break the existing code. Dropping this patch for now. 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 05/11] omap3: Remove non-existent config option
Felipe, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Felipe Contreras Sent: Monday, September 27, 2010 10:56 AM To: Marathe, Yogesh Cc: Premi, Sanjeev; Tony Lindgren; linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 05/11] omap3: Remove non-existent config option On Mon, Sep 27, 2010 at 2:02 PM, Marathe, Yogesh yogesh_mara...@ti.com wrote: When you merge iommu support, then either you enable CONFIG_MPU_BRIDGE_IOMMU unconditionally, or you apply this patch, but this patch alone will only break things. Any other driver which does not depend on bridge and interested in using iommu should get the handle when iommu_get(iva2) is called. That's a hypothetical driver, right? The only driver that would ever be interested in the iva2 iommu is tidspbridge, and this patch would brake it. It is not happening in original case. I think there should not be restrictions on other drivers to define un-related compile time define if they just want to use iommu driver. I feel the implementation that is breaking due to removal of this define should be fixed. I couldn't parse that correctly. However, what's wrong with the proposal? Let's think about CONFIG_MPU_BRIDGE_IOMMU when the iommu patches come. Yogesh is coming from dsplink requirement to use iommu. I see his comment as why Bridge requirement should be imposed on other IPCs that need iommu. Thank you, Best regards, Hari -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/5] OMAP: mux: Add support for control module split in several partitions
Hi Tony,
On 9/27/2010 5:46 PM, Tony Lindgren wrote:
* Tony Lindgrent...@atomide.com [100924 17:14]:
* Benoit Coussonb-cous...@ti.com [100924 02:07]:
If we wanted to use only the offset in the data, we could initialize
the various sections separately. But then omapX_mux_init() would have
to know the partition number somehow..
After thinking about this a bit more, to me it seems like this is
the best way to go. Then there's no need to repeat the partition data
for each entry. How about this:
Earlier defines stay the same:
#define OMAP3_MUX(mode0, mux_value) \
{ \
.reg_offset = (OMAP3_CONTROL_PADCONF_##mode0##_OFFSET), \
.value = (mux_value), \
}
Then for omap4, we need to add a separate board mux table for each
partition:
#define OMAP4_MUX_PARTXXX(mode0, mux_value) \
{ \
.reg_offset = (OMAP4_PART_XXX_PADCONF_##mode0##_OFFSET),\
.value = (mux_value), \
}
#define OMAP4_MUX_PARTYYY(mode0, mux_value) \
{ \
.reg_offset = (OMAP4_PARTYYY_PADCONF_##mode0##_OFFSET), \
.value = (mux_value), \
}
OK for that one, that will save the extra id to store the partition in
each static data, but then you will still have to store it during the init?
...
For omap2 and 3, we just call omap_mux_init once with the mux_pbase
as we currently already do. Then for omap4, we call omap_mux_init for
each partition.
We also need to change omap_mux_read/write to allow specifying the
partition base address:
Then you need somehow a partition information from somewhere.
I don't see how we can avoid the id at that point? We can store the base
address instead, but then every mux entries will have it.
The caller of the omap_mux_read still have to figure out what base
address it has to use.
That move the issue to the upper layer, but we still need that.
u16 omap_mux_read(void __iomem *base, u16 offset)
{
if (cpu_is_omap24xx())
return __raw_readb(base + offset);
else
return __raw_readw(base + offset);
}
All the other mux interface functions can stay the same, we just need
to modify the mux.c code to look for signal names or GPIO number in
each registered partition.
OK, now I think I understand your point... Please ignore the previous
comments :-)
You will guess the partition by trying each array at a time, and the
first one will win.
That seems pretty good in fact.
I just have to do it now...
Thanks,
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: [RFC 1/5] OMAP: mux: Add support for control module split in several partitions
* Cousson, Benoit b-cous...@ti.com [100927 10:15]:
OK for that one, that will save the extra id to store the partition
in each static data, but then you will still have to store it during
the init?
For mux.c internal data, we can have an array of struct omap_mux_partition
that contains the mux array for that partition:
struct omap_mux_partition {
void __iomem*base; /* Partition virt base */
struct omap_mux *mux; /* Partition specific mux array */
};
...
For omap2 and 3, we just call omap_mux_init once with the mux_pbase
as we currently already do. Then for omap4, we call omap_mux_init for
each partition.
We also need to change omap_mux_read/write to allow specifying the
partition base address:
Then you need somehow a partition information from somewhere.
I don't see how we can avoid the id at that point? We can store the
base address instead, but then every mux entries will have it.
That should only need to be stored once for each partition in the
struct omap_mux_partition?
The caller of the omap_mux_read still have to figure out what base
address it has to use.
That move the issue to the upper layer, but we still need that.
For the mux.c internal code, we can search through the array
of struct omap_mux_partition and the mux entries in each partition
for signal name or GPIO number.
All the other mux interface functions can stay the same, we just need
to modify the mux.c code to look for signal names or GPIO number in
each registered partition.
OK, now I think I understand your point... Please ignore the
previous comments :-)
You will guess the partition by trying each array at a time, and the
first one will win.
That seems pretty good in fact.
I just have to do it now...
OK cool, let me know if I can help with something.
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 9/9 v3] usb : musb: Offmode fix for idle path
Kalliguddi, Hema hem...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Saturday, September 25, 2010 1:12 AM To: Kalliguddi, Hema Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Mankad, Maulik Ojas; Balbi, Felipe; Tony Lindgren; Cousson, Benoit; Paul Walmsley Subject: Re: [PATCH 9/9 v3] usb : musb: Offmode fix for idle path Hema HK hem...@ti.com writes: With OMAP core-off support musb was not functional as context was getting lost after wakeup from core-off. This should be a separate patch. Let me give the description of the musb offmode support in the idle path. The detail you provided below is very good, and this is the level of detail that needs to go into the changelogs. With the current mainline code, offmode in the idle path is not supported with usb. When the core hits off and wakes up the musb will not be functional. This patch is to support the musb functionality with offmode enabled in the idle path. OK, what about the PM branch. I was under the impression that offmode was working fine in the PM branch. And, looking at the PM branch, the only thing done in the idle path is the disable of autoidle upon wakeup. Everything else (context save/restore etc.) is done in the driver. Below are the requirements to support retention and offmode of OMAP in idle path with usb enabled During idle and when there is no activity on the bus: 1.Since there is no hardware context save/restore supported in OMAP for musb, software has to save the context. 2.Configure the musb in force idle/standby mode during idle mode This needs more detailed description (TRM reference, etc.) 3.May or may not disable the interface clock(as interface clock is autogated) and the functional clock is from ULPI phy on triton chip. When OMAP awakes: 1.enable the clock if it is disabled.and 2.Configure it back to no idle/standby or smart idle/standby after wakeup. In the PM branch, this part is done in idle. 3.Restore the context back. But this is done by the driver. Idling of device can be done when there is no activity on the bus by using the pm_runtime_put_sync n apis in when device disconnects or suspends, but resuming has to done as soon as the omap is wokenup from retention or core off, as we have to put back the musb in known state ie restore the conext atleast enabling D+/D- lines,enabling interrupts and configuring the no idle/standby or smart idle/standby to even capture the irqs. Otherwise we will not be able to capture the musb connect/reset or resume/remote wakeup events as D+/D- lines will disabled when the context is lost duribg offmode. If I use the pm_runtime_put_sync in disconnect/suspend handler when device suspends/disconnects and use pm_runtime_get_sync when OMAP wakesup, then there will be mismatch in the usecount. We could have achieved the same by using the triton connect/disconnect events to idle/resume musb, but some of the phys do not support the connect/disconnect events. So cameup with the design of idling musb device in idle loop and resume once the OMAP wakes up. All this done onl when the musb is not active. Rather than seeing more work done in the idle path, I would rather be moving code out of the idle path. Did you consider using a (deferrable) timer during no-activity times which periodically checks to be sure the IP is in force idle/standby? Since the IDLE REQ/ACK protocol is broken, the recommendation from ip team is to configure the musb in force idle/standby during omap retention and offmode. Yes, this is in the PM branch and there is an errata number for it there. Please reference that errata when implementing this feature (both in the changelog and in the code.) Kevin Since we have to touch the sysconfig registers and context save/restore everytime, I am using the runtime pm apis. And also musb was blocking the core-off after loading the gadget driver even with no cable connected sometimes. this too Added the idle and wakeup APIs in the platform layer which will be called in the idle and wakeup path. And this errata fix should be a separate patch, with reference to the errata etc. This is not an errata, this is requirement from the ip. it is mentioned in the functional spec that when device is not use put it in force idle/standby mode. Used the pm_runtime_put_sysc API to configure the musb to force idle/standby modes, saving the context and disable the clk in while idling if there is no activity on the usb bus. Why? This should not be part of the idle path. If there is no activity on the bus, why hasn't the musb driver already runtime suspended itself? If the driver want's to runtime_suspend itself based on inactivity, it should use an inactivity timer, not hook into the idle loop. The runtime PM API has a function for a deferred suspend int pm_schedule_suspend(struct device *dev, unsigned int delay) The
Re: [PATCH v3] OMAP1: Add support for SoC camera interface
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [100926 17:55]: This patch adds a definition of the OMAP1 camera interface platform device, and a function that allows for providing a board specific platform data. The device will be used with the upcoming OMAP1 SoC camera interface driver. Created and tested against linux-2.6.36-rc5 on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- Tony, I hope this now satisfies your requirements. I resubmit only this updated patch, not the other two, Amstrad Delta specific, which you have alredy applied. Those are still valid (work for me), only the not yet merged include/media/omap1_camera.h header file is required for successfull compilation of board-ams-delta.c. I hope this is not a problem. Yes thanks. Queuing these three for the upcoming merge window. 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 v3] power_supply: Add driver for TWL4030/TPS65950 BCI charger
How do I get notified if battery voltage is low and needs charging from user space? Either additional monitoring chip notifies you (if you are lucky and have one), or wait for update of this driver :) There are efforts to merge MADC driver [1], but it may take some time. But using MADC, I can get the battery voltage and by means of monitoring battery voltage we can get to know low battery notification. True, but let's wait for MADC driver to be merged for that first. [1] http://marc.info/?t=12846153572r=1w=2 Thanks and Regards, Arun R Murthy -- 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] OMAP: PM: Fix build when CONFIG_PM_DEBUG isn't set
Hi Loïc, Loïc Minier loic.min...@linaro.org writes: Since 6cdee91257bee23a46dc869ca62469b67cba2c7e the references to enable_off_mode and sleep_while_idle can't be resolved when CONFIG_PM_DEBUG isn't set: arch/arm/mach-omap2/built-in.o: In function `omap_uart_restore_context': arch/arm/mach-omap2/serial.c:253: undefined reference to `enable_off_mode' arch/arm/mach-omap2/built-in.o: In function `omap3_can_sleep': arch/arm/mach-omap2/pm34xx.c:479: undefined reference to `sleep_while_idle' Simply #define these in pm.h just like omap2_pm_debug. Could you move these down into the exisint #ifdef CONFIG_PM_DEBUG a little bit later in the file (after where omap2_pm_debug.) Also, could you sign-off on the patch please? Thanks, Kevin --- arch/arm/mach-omap2/pm.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index 0a1..68db3a7 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -13,8 +13,13 @@ #include plat/powerdomain.h +#ifdef CONFIG_PM_DEBUG extern u32 enable_off_mode; extern u32 sleep_while_idle; +#else +#define enable_off_mode 0 +#define sleep_while_idle 0 +#endif extern void *omap3_secure_ram_storage; extern void omap3_pm_off_mode_enable(int); -- 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] power: introduce library for device-specific OPPs
On Monday, September 27, 2010, Nishanth Menon wrote:
Paul E. McKenney had written, on 09/25/2010 07:56 PM, the following:
On Sat, Sep 25, 2010 at 10:55:20PM +0200, Rafael J. Wysocki wrote:
On Friday, September 24, 2010, Paul E. McKenney wrote:
On Fri, Sep 24, 2010 at 07:50:40AM -0500, Nishanth Menon wrote:
...
Looks like a good start!!! Some questions and suggestions about RCU
usage interspersed below.
...
+ * Locking: RCU reader.
+ */
+int opp_get_opp_count(struct device *dev)
+{
+struct device_opp *dev_opp;
+struct opp *temp_opp;
+int count = 0;
+
+dev_opp = find_device_opp(dev);
+if (IS_ERR(dev_opp))
+return PTR_ERR(dev_opp);
+
+rcu_read_lock();
+list_for_each_entry_rcu(temp_opp, dev_opp-opp_list, node) {
+if (temp_opp-available)
+count++;
+}
+rcu_read_unlock();
This one is OK as well. You are returning a count, so if all of the
counted structures are freed at this point, no problem. The count was
valid when it was accumulated, and the fact that it might now be obsolete
is (usually) not a problem.
However, it looks like it should run rcu_read_lock() before calling
find_device_opp(dev), shouldn't it?
Indeed it does appear that you are right -- good catch!!!
Thanx, Paul
dev_opp as discussed before is safe as it is never freed
(find_device_opp uses it's own rcu_read_lock, the rcu_read_lock in this
context is for the opp list. what am I missing?
It's simply safer to put the rcu_read_lock() before find_device_opp(), in case
someone will make it possible to remove things from the opp list in the future.
Besides, your entire data structure consists of the opp list and the per-power
domain lists, so you should really tell the writers when you have finished to
traverse it entirely, not in the middle of the operation.
Thanks,
Rafael
--
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: [linux-pm] runtime_pm_get_sync() from ISR with IRQs disabled?
On Monday, September 27, 2010, Alan Stern wrote: On Fri, 24 Sep 2010, Rafael J. Wysocki wrote: On Friday, September 24, 2010, Kevin Hilman wrote: Alan Stern st...@rowland.harvard.edu writes: On Thu, 23 Sep 2010, Kevin Hilman wrote: ... You're trying to fight the runtime-PM design instead of using it as it was intended. We already have an API for starting a resume from interrupt context, and that's what you should use. It may seem like I'm trying to fight the design, but I'm actually trying to find ways to use it. I want to use the API (and we're using it successfully in most of our drivers now.) The problem is only in a few of these corner cases where using it introduces significant changes from previous behavior like introducing long, unbounded windows for missed interrupts. This really sounds to me like you need _noirq() runtime PM callbacks and some framework around them. I'm not fundamentally against that, but it will require some time to introduce, if we decide that it's really necessary. I need to think a bit more about that, thanks for the example. How about adding another flag to the dev_pm_info structure, to indicate that the runtime callbacks may be called in interrupt context? Maybe that will lead to problems I haven't thought of. But if it seems okay to you, I can code it up easily enough. Hmm. I was thinking about adding a new RPM_ flag for that, like RPM_FASTPATH, telling the PM core to assume the callbacks will not sleep and that the call might be from interrupt handler. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/5] OMAP: mux: Add support for control module split in several partitions
On 9/27/2010 7:36 PM, Tony Lindgren wrote:
* Cousson, Benoitb-cous...@ti.com [100927 10:15]:
OK for that one, that will save the extra id to store the partition
in each static data, but then you will still have to store it during
the init?
For mux.c internal data, we can have an array of struct omap_mux_partition
that contains the mux array for that partition:
struct omap_mux_partition {
void __iomem*base; /* Partition virt base */
struct omap_mux *mux; /* Partition specific mux array */
};
...
For omap2 and 3, we just call omap_mux_init once with the mux_pbase
as we currently already do. Then for omap4, we call omap_mux_init for
each partition.
We also need to change omap_mux_read/write to allow specifying the
partition base address:
Then you need somehow a partition information from somewhere.
I don't see how we can avoid the id at that point? We can store the
base address instead, but then every mux entries will have it.
That should only need to be stored once for each partition in the
struct omap_mux_partition?
The caller of the omap_mux_read still have to figure out what base
address it has to use.
That move the issue to the upper layer, but we still need that.
For the mux.c internal code, we can search through the array
of struct omap_mux_partition and the mux entries in each partition
for signal name or GPIO number.
All the other mux interface functions can stay the same, we just need
to modify the mux.c code to look for signal names or GPIO number in
each registered partition.
OK, now I think I understand your point... Please ignore the
previous comments :-)
You will guess the partition by trying each array at a time, and the
first one will win.
That seems pretty good in fact.
I just have to do it now...
OK cool, let me know if I can help with something.
Thanks, but that should be fine for moment. I think I should have the
updated version before the end of the week.
Just one clarification, I don't think we have to use two different
macros in that case. The names are already unique across partition
today, so we can use only macro like for previous OMAP.
I'm just glad I don't have to re-write these 231 entries per ES manually :-)
I'll give it a try, and keep you inform if I have any un-expected issue
with that approach.
Thanks,
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: [RFC 1/5] OMAP: mux: Add support for control module split in several partitions
* Cousson, Benoit b-cous...@ti.com [100927 12:54]: OK cool, let me know if I can help with something. Thanks, but that should be fine for moment. I think I should have the updated version before the end of the week. OK Just one clarification, I don't think we have to use two different macros in that case. The names are already unique across partition today, so we can use only macro like for previous OMAP. OK I'm just glad I don't have to re-write these 231 entries per ES manually :-) :) I'll give it a try, and keep you inform if I have any un-expected issue with that approach. OK 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
[GIT PULL v2] OMAP: clock/CM/PRM/SCM updates for OMAP4 ES2, OMAP3 CORE DVFS fix: for 2.6.37
Hi Tony, Thanks for catching my mistake in the previous pull request for these patches - it inadvertently also contained the patches from the pull request OMAP: hwmod fixes and improvements for 2.6.37. This updated pull request contains just the new patches that were posted from this series: The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c: Linux 2.6.36-rc5 (2010-09-20 16:56:53 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 omap4_and_sdrc_2.6.27 Benoit Cousson (3): OMAP4: clock: Fix clock names and align with hwmod names OMAP4: clock: Add optional clock nodes OMAP4: clocks: Fix ES2 clock issues Jon Hunter (1): omap3: Prevent SDRC deadlock when L3 is changing frequency Rajendra Nayak (4): OMAP4: clocks: Update clock tree for ES2 OMAP4: CM PRM: Update PRCM register bitshifts and masks for ES2 OMAP4: PM: Define additional registers for ES2 OMAP4: powerdomain: Update DSS logic state for ES2 Santosh Shilimkar (4): omap4: control: Add ctrl_pad_base to omap_globals omap4: control: Add accessor api's for pad control module omap4: control: Add the register definition headers omap4: control: Fix the control module register accesses arch/arm/mach-omap2/clock44xx_data.c | 1310 +++--- arch/arm/mach-omap2/cm-regbits-44xx.h | 1287 ++- arch/arm/mach-omap2/cm44xx.h | 90 ++- arch/arm/mach-omap2/control.c | 25 + arch/arm/mach-omap2/hsmmc.c| 67 +- arch/arm/mach-omap2/id.c |2 +- .../include/mach/ctrl_module_core_44xx.h | 391 ++ .../include/mach/ctrl_module_pad_core_44xx.h | 1409 .../include/mach/ctrl_module_pad_wkup_44xx.h | 236 .../include/mach/ctrl_module_wkup_44xx.h | 92 ++ arch/arm/mach-omap2/powerdomains44xx.h |2 +- arch/arm/mach-omap2/prm-regbits-44xx.h | 1314 ++- arch/arm/mach-omap2/prm44xx.h | 14 +- arch/arm/mach-omap2/sram34xx.S |6 +- arch/arm/plat-omap/common.c|3 +- arch/arm/plat-omap/include/plat/common.h |1 + arch/arm/plat-omap/include/plat/control.h | 31 +- arch/arm/plat-omap/include/plat/powerdomain.h |1 + 18 files changed, 4499 insertions(+), 1782 deletions(-) create mode 100644 arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h create mode 100644 arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h create mode 100644 arch/arm/mach-omap2/include/mach/ctrl_module_pad_wkup_44xx.h create mode 100644 arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h - Paul -- 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 v4] power_supply: Add driver for TWL4030/TPS65950 BCI charger
TWL4030/TPS65950 is a multi-function device with integrated charger,
which allows charging from AC or USB. This driver enables the
charger and provides several monitoring functions.
Tested on OMAP3 Pandora board.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
changes since v3 [1]:
- register power supply before enabling interrupts
- use platform_driver_probe
- get rid of ifdefs
[1] http://marc.info/?l=linux-kernelm=128552976908093w=2
drivers/power/Kconfig |6 +
drivers/power/Makefile |1 +
drivers/power/twl4030_charger.c | 565 +++
3 files changed, 572 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/twl4030_charger.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 4d9a637..11eec62 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -180,4 +180,10 @@ config CHARGER_ISP1704
Say Y to enable support for USB Charger Detection with
ISP1707/ISP1704 USB transceivers.
+config CHARGER_TWL4030
+ tristate OMAP TWL4030 BCI charger driver
+ depends on TWL4030_CORE
+ help
+ Say Y here to enable support for TWL4030 Battery Charge Interface.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 2799a84..695e54f 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_CHARGER_PCF50633)+= pcf50633-charger.o
obj-$(CONFIG_BATTERY_JZ4740) += jz4740-battery.o
obj-$(CONFIG_BATTERY_INTEL_MID)+= intel_mid_battery.o
obj-$(CONFIG_CHARGER_ISP1704) += isp1704_charger.o
+obj-$(CONFIG_CHARGER_TWL4030) += twl4030_charger.o
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
new file mode 100644
index 000..ff1f423
--- /dev/null
+++ b/drivers/power/twl4030_charger.c
@@ -0,0 +1,565 @@
+/*
+ * TWL4030/TPS65950 BCI (Battery Charger Interface) driver
+ *
+ * Copyright (C) 2010 Gražvydas Ignotas nota...@gmail.com
+ *
+ * based on twl4030_bci_battery.c by TI
+ * Copyright (C) 2008 Texas Instruments, Inc.
+ *
+ * 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.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/i2c/twl.h
+#include linux/power_supply.h
+#include linux/notifier.h
+#include linux/usb/otg.h
+
+#define TWL4030_BCIMSTATEC 0x02
+#define TWL4030_BCIICHG0x08
+#define TWL4030_BCIVAC 0x0a
+#define TWL4030_BCIVBUS0x0c
+#define TWL4030_BCIMFSTS4 0x10
+#define TWL4030_BCICTL10x23
+
+#define TWL4030_BCIAUTOWEN BIT(5)
+#define TWL4030_CONFIG_DONEBIT(4)
+#define TWL4030_BCIAUTOUSB BIT(1)
+#define TWL4030_BCIAUTOAC BIT(0)
+#define TWL4030_CGAIN BIT(5)
+#define TWL4030_USBFASTMCHGBIT(2)
+#define TWL4030_STS_VBUS BIT(7)
+#define TWL4030_STS_USB_ID BIT(2)
+
+/* BCI interrupts */
+#define TWL4030_WOVF BIT(0) /* Watchdog overflow */
+#define TWL4030_TMOVF BIT(1) /* Timer overflow */
+#define TWL4030_ICHGHIGH BIT(2) /* Battery charge current high */
+#define TWL4030_ICHGLOWBIT(3) /* Battery cc. low / FSM state
change */
+#define TWL4030_ICHGEOCBIT(4) /* Battery current end-of-charge
*/
+#define TWL4030_TBATOR2BIT(5) /* Battery temperature out of
range 2 */
+#define TWL4030_TBATOR1BIT(6) /* Battery temperature out of
range 1 */
+#define TWL4030_BATSTS BIT(7) /* Battery status */
+
+#define TWL4030_VBATLVLBIT(0) /* VBAT level */
+#define TWL4030_VBATOV BIT(1) /* VBAT overvoltage */
+#define TWL4030_VBUSOV BIT(2) /* VBUS overvoltage */
+#define TWL4030_ACCHGOVBIT(3) /* Ac charger overvoltage */
+
+#define TWL4030_MSTATEC_USBBIT(4)
+#define TWL4030_MSTATEC_AC BIT(5)
+#define TWL4030_MSTATEC_MASK 0x0f
+#define TWL4030_MSTATEC_QUICK1 0x02
+#define TWL4030_MSTATEC_QUICK7 0x07
+#define TWL4030_MSTATEC_COMPLETE1 0x0b
+#define TWL4030_MSTATEC_COMPLETE4 0x0e
+
+static bool allow_usb;
+module_param(allow_usb, bool, 1);
+MODULE_PARM_DESC(allow_usb, Allow USB charge drawing default current);
+
+struct twl4030_bci {
+ struct device *dev;
+ struct power_supply ac;
+ struct power_supply usb;
+ struct otg_transceiver *transceiver;
+ struct notifier_block otg_nb;
+ int irq_chg;
+ int irq_bci;
+};
+
+/*
+ * clear and set bits on an given register on a given module
+ */
+static int twl4030_clear_set(u8 mod_no, u8 clear, u8 set, u8 reg)
+{
+ u8 val = 0;
+
Re: [GIT PULL v2] OMAP: clock/CM/PRM/SCM updates for OMAP4 ES2, OMAP3 CORE DVFS fix: for 2.6.37
* Paul Walmsley p...@pwsan.com [100927 13:00]: Hi Tony, Thanks for catching my mistake in the previous pull request for these patches - it inadvertently also contained the patches from the pull request OMAP: hwmod fixes and improvements for 2.6.37. This updated pull request contains just the new patches that were posted from this series: The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c: Linux 2.6.36-rc5 (2010-09-20 16:56:53 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 omap4_and_sdrc_2.6.27 Thanks, pulling this and misc_2.6.37 into omap-for-linus. 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: [linux-pm] runtime_pm_get_sync() from ISR with IRQs disabled?
On Mon, 27 Sep 2010, Rafael J. Wysocki wrote: How about adding another flag to the dev_pm_info structure, to indicate that the runtime callbacks may be called in interrupt context? Maybe that will lead to problems I haven't thought of. But if it seems okay to you, I can code it up easily enough. Hmm. I was thinking about adding a new RPM_ flag for that, like RPM_FASTPATH, telling the PM core to assume the callbacks will not sleep and that the call might be from interrupt handler. That might appear more flexible, but is there any advantage to it? That is, would there be a situation where the driver knows that the next callback won't sleep but in general the callback might sleep sometimes? It doesn't seem very likely. Kevin, do you have any feelings about this? Alan Stern -- 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] OMAP: PM: Fix build when CONFIG_PM_DEBUG isn't set
Since 6cdee91257bee23a46dc869ca62469b67cba2c7e the references to enable_off_mode and sleep_while_idle can't be resolved when CONFIG_PM_DEBUG isn't set: arch/arm/mach-omap2/built-in.o: In function `omap_uart_restore_context': arch/arm/mach-omap2/serial.c:253: undefined reference to `enable_off_mode' arch/arm/mach-omap2/built-in.o: In function `omap3_can_sleep': arch/arm/mach-omap2/pm34xx.c:479: undefined reference to `sleep_while_idle' Simply #define these in pm.h just like omap2_pm_debug. Signed-off-by: Loïc Minier loic.min...@linaro.org --- arch/arm/mach-omap2/pm.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index 0a1..68db3a7 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -13,8 +13,13 @@ #include plat/powerdomain.h +#ifdef CONFIG_PM_DEBUG extern u32 enable_off_mode; extern u32 sleep_while_idle; +#else +#define enable_off_mode 0 +#define sleep_while_idle 0 +#endif extern void *omap3_secure_ram_storage; extern void omap3_pm_off_mode_enable(int); -- 1.7.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
Re: [linux-pm] runtime_pm_get_sync() from ISR with IRQs disabled?
Alan Stern st...@rowland.harvard.edu writes: On Mon, 27 Sep 2010, Rafael J. Wysocki wrote: How about adding another flag to the dev_pm_info structure, to indicate that the runtime callbacks may be called in interrupt context? Maybe that will lead to problems I haven't thought of. But if it seems okay to you, I can code it up easily enough. Hmm. I was thinking about adding a new RPM_ flag for that, like RPM_FASTPATH, telling the PM core to assume the callbacks will not sleep and that the call might be from interrupt handler. That might appear more flexible, but is there any advantage to it? That is, would there be a situation where the driver knows that the next callback won't sleep but in general the callback might sleep sometimes? It doesn't seem very likely. Kevin, do you have any feelings about this? For flexibility, I like the RPM_FASTPATH approach. At least in the drivers I'm currently tinkering with, most of the callers can sleep. It's only the occasional callback triggered from the ISR that can't sleep. During this normal (non-ISR) usage, there might very well be concurrent or pending requests, some of which might have to sleep. So, I think it's best to have the fastpath settable on a per-caller basis. 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 11/13 v3] serial: Add OMAP high-speed UART driver
On Mon, Sep 27, 2010 at 01:55:46PM -0700, Kevin Hilman wrote: [resent with correct address for Greg, sorry for duplicates.] Greg, Govindraj.R govindraj.r...@ti.com writes: This patch adds driver support for OMAP2/3/4 high speed UART. According to MAINTAINERS, you seem to be the one looking after the serial core. Are you the one to ack/merge new drivers? Yup, but Alan Cox is also a good person to get review from as well. With your ack, we can merge this through the OMAP tree along with the rest of the series that has OMAP-specific platform reorg and updates. If you're not the right person, please let us know who would be the right person to ack/sign-off on this. Cc both of us so we can review it please. thanks, greg k-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: [PATCH] OMAP: PM: Fix build when CONFIG_PM_DEBUG isn't set
On Mon, Sep 27, 2010, Kevin Hilman wrote: Could you move these down into the exisint #ifdef CONFIG_PM_DEBUG a little bit later in the file (after where omap2_pm_debug.) I hesitated doing that since there were a couple of other ifdefs using CONFIG_PM_DEBUG later in the file; I will send an updated patch moving to the ifdef CONFIG_PM_DEBUG. Also, could you sign-off on the patch please? Ah sorry about that -- Loïc Minier -- 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 11/13 v3] serial: Add OMAP high-speed UART driver
Govindraj.R govindraj.r...@ti.com writes:
This patch adds driver support for OMAP2/3/4 high speed UART.
Cc'ing Greg KH and Alan Cox for review of the the new serial driver in
this series.
Greg/Alan, this has been on linux-serial several times now with review
mostly from OMAP folks. If this looks OK from your side, with your
ack(s) we can merge via the OMAP tree with the rest of the series which
is a major reorg/cleanup of the OMAP platform init for serial drivers.
Thanks,
Kevin
The driver is made separate from 8250 driver as we cannot
over load 8250 driver with omap platform specific configuration for
features like DMA, it makes easier to implement features like DMA and
hardware flow control and software flow control configuration with
this driver as required for the omap-platform.
This patch involves only the core driver and its dependent.
Cc: Tony Lindgren t...@atomide.com
Tested-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h | 129 +++
drivers/serial/Kconfig| 27 +
drivers/serial/Makefile |1 +
drivers/serial/omap-serial.c | 1333
+
include/linux/serial_core.h |3 +
5 files changed, 1493 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h
create mode 100644 drivers/serial/omap-serial.c
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
new file mode 100644
index 000..0d6f076
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -0,0 +1,129 @@
+/*
+ * Driver for OMAP-UART controller.
+ * Based on drivers/serial/8250.c
+ *
+ * Copyright (C) 2010 Texas Instruments.
+ *
+ * Authors:
+ * Govindraj R govindraj.r...@ti.com
+ * Thara Gopinath th...@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.
+ */
+
+#ifndef __OMAP_SERIAL_H__
+#define __OMAP_SERIAL_H__
+
+#include linux/serial_core.h
+#include linux/platform_device.h
+
+#include plat/control.h
+#include plat/mux.h
+
+#define DRIVER_NAME omap-hsuart
+
+/*
+ * Use tty device name as ttyO, [O - OMAP]
+ * in bootargs we specify as console=ttyO0 if uart1
+ * is used as console uart.
+ */
+#define OMAP_SERIAL_NAME ttyO
+
+#define OMAP_MDR1_DISABLE0x07
+#define OMAP_MDR1_MODE13X0x03
+#define OMAP_MDR1_MODE16X0x00
+#define OMAP_MODE13X_SPEED 230400
+
+/*
+ * LCR = 0XBF: Switch to Configuration Mode B.
+ * In configuration mode b allow access
+ * to EFR,DLL,DLH.
+ * Reference OMAP TRM Chapter 17
+ * Section: 1.4.3 Mode Selection
+ */
+#define OMAP_UART_LCR_CONF_MDB 0XBF
+
+/* WER = 0x7F
+ * Enable module level wakeup in WER reg
+ */
+#define OMAP_UART_WER_MOD_WKUP 0X7F
+
+/* Enable XON/XOFF flow control on output */
+#define OMAP_UART_SW_TX 0x04
+
+/* Enable XON/XOFF flow control on input */
+#define OMAP_UART_SW_RX 0x04
+
+#define OMAP_UART_SYSC_RESET 0X07
+#define OMAP_UART_TCR_TRIG 0X0F
+#define OMAP_UART_SW_CLR 0XF0
+#define OMAP_UART_FIFO_CLR 0X06
+
+#define OMAP_UART_DMA_CH_FREE-1
+
+#define RX_TIMEOUT (3 * HZ)
+#define OMAP_MAX_HSUART_PORTS4
+
+#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
+
+struct omap_uart_port_info {
+ booldma_enabled;/* To specify DMA Mode */
+ unsigned intuartclk;/* UART clock rate */
+ void __iomem*membase; /* ioremap cookie or NULL */
+ resource_size_t mapbase;/* resource base */
+ unsigned long irqflags; /* request_irq flags */
+ upf_t flags; /* UPF_* flags */
+};
+
+struct uart_omap_dma {
+ u8 uart_dma_tx;
+ u8 uart_dma_rx;
+ int rx_dma_channel;
+ int tx_dma_channel;
+ dma_addr_t rx_buf_dma_phys;
+ dma_addr_t tx_buf_dma_phys;
+ unsigned intuart_base;
+ /*
+ * Buffer for rx dma.It is not required for tx because the buffer
+ * comes from port structure.
+ */
+ unsigned char *rx_buf;
+ unsigned intprev_rx_dma_pos;
+ int tx_buf_size;
+ int tx_dma_used;
+ int rx_dma_used;
+ spinlock_t tx_lock;
+ spinlock_t rx_lock;
+ /* timer to poll activity on rx dma */
+ struct timer_list rx_timer;
+ int
Re: [PATCH 3/5] omap3: cm-t3517: add support for usb host.
* Igor Grinberg grinb...@compulab.co.il [100922 01:16]: It should be okay to execute this code independent of whether the driver is built or not. The device registration can be unconditional and if there is no driver present, we won't probe anyway. The current patch looks OK to me, adding all of them into omap-for-linus. 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
