[PATCH] OMAPDSS: HDMI: Register definition cleanup and improvements
From: Mythri P K mythr...@ti.com
1.Add some H/w indexable registers missed in definition.
2.Remove usage of struct hdmi_reg and use u16 instead.
3.Move the avi_infoframe parameters comments above the field.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 10 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 296 ++---
2 files changed, 151 insertions(+), 155 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index da7fe50..5f22d2e 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -32,15 +32,15 @@
#include dss.h
static inline void hdmi_write_reg(void __iomem *base_addr,
- const struct hdmi_reg idx, u32 val)
+ const u16 idx, u32 val)
{
- __raw_writel(val, base_addr + idx.idx);
+ __raw_writel(val, base_addr + idx);
}
static inline u32 hdmi_read_reg(void __iomem *base_addr,
- const struct hdmi_reg idx)
+ const u16 idx)
{
- return __raw_readl(base_addr + idx.idx);
+ return __raw_readl(base_addr + idx);
}
static inline void __iomem *hdmi_wp_base(struct hdmi_ip_data *ip_data)
@@ -69,7 +69,7 @@ static inline void __iomem *hdmi_core_sys_base(struct
hdmi_ip_data *ip_data)
}
static inline int hdmi_wait_for_bit_change(void __iomem *base_addr,
- const struct hdmi_reg idx,
+ const u16 idx,
int b2, int b1, u32 val)
{
u32 t = 0;
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 929de88..2040956 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -30,142 +30,138 @@
#include sound/pcm_params.h
#endif
-struct hdmi_reg { u16 idx; };
-
-#define HDMI_REG(idx) ((const struct hdmi_reg) { idx })
-
/* HDMI Wrapper */
-#define HDMI_WP_REVISION HDMI_REG(0x0)
-#define HDMI_WP_SYSCONFIG HDMI_REG(0x10)
-#define HDMI_WP_IRQSTATUS_RAW HDMI_REG(0x24)
-#define HDMI_WP_IRQSTATUS HDMI_REG(0x28)
-#define HDMI_WP_PWR_CTRL HDMI_REG(0x40)
-#define HDMI_WP_IRQENABLE_SET HDMI_REG(0x2C)
-#define HDMI_WP_VIDEO_CFG HDMI_REG(0x50)
-#define HDMI_WP_VIDEO_SIZE HDMI_REG(0x60)
-#define HDMI_WP_VIDEO_TIMING_H HDMI_REG(0x68)
-#define HDMI_WP_VIDEO_TIMING_V HDMI_REG(0x6C)
-#define HDMI_WP_WP_CLK HDMI_REG(0x70)
-#define HDMI_WP_AUDIO_CFG HDMI_REG(0x80)
-#define HDMI_WP_AUDIO_CFG2 HDMI_REG(0x84)
-#define HDMI_WP_AUDIO_CTRL HDMI_REG(0x88)
-#define HDMI_WP_AUDIO_DATA HDMI_REG(0x8C)
+#define HDMI_WP_REVISION 0x0
+#define HDMI_WP_SYSCONFIG 0x10
+#define HDMI_WP_IRQSTATUS_RAW 0x24
+#define HDMI_WP_IRQSTATUS 0x28
+#define HDMI_WP_PWR_CTRL 0x40
+#define HDMI_WP_IRQENABLE_SET 0x2C
+#define HDMI_WP_VIDEO_CFG 0x50
+#define HDMI_WP_VIDEO_SIZE 0x60
+#define HDMI_WP_VIDEO_TIMING_H 0x68
+#define HDMI_WP_VIDEO_TIMING_V 0x6C
+#define HDMI_WP_WP_CLK 0x70
+#define HDMI_WP_AUDIO_CFG 0x80
+#define HDMI_WP_AUDIO_CFG2 0x84
+#define HDMI_WP_AUDIO_CTRL 0x88
+#define HDMI_WP_AUDIO_DATA 0x8C
/* HDMI IP Core System */
-#define HDMI_CORE_SYS_VND_IDL HDMI_REG(0x0)
-#define HDMI_CORE_SYS_DEV_IDL HDMI_REG(0x8)
-#define HDMI_CORE_SYS_DEV_IDH HDMI_REG(0xC)
-#define HDMI_CORE_SYS_DEV_REV HDMI_REG(0x10)
-#define HDMI_CORE_SYS_SRST HDMI_REG(0x14)
-#define HDMI_CORE_CTRL1HDMI_REG(0x20)
-#define HDMI_CORE_SYS_SYS_STAT HDMI_REG(0x24)
-#define HDMI_CORE_SYS_VID_ACEN HDMI_REG(0x124)
-#define HDMI_CORE_SYS_VID_MODE HDMI_REG(0x128)
-#define HDMI_CORE_SYS_INTR_STATE HDMI_REG(0x1C0)
-#define HDMI_CORE_SYS_INTR1HDMI_REG(0x1C4)
-#define HDMI_CORE_SYS_INTR2HDMI_REG(0x1C8)
-#define HDMI_CORE_SYS_INTR3HDMI_REG(0x1CC)
-#define HDMI_CORE_SYS_INTR4HDMI_REG(0x1D0)
-#define HDMI_CORE_SYS_UMASK1 HDMI_REG(0x1D4)
-#define HDMI_CORE_SYS_TMDS_CTRLHDMI_REG(0x208)
-#define HDMI_CORE_SYS_DE_DLY HDMI_REG(0xC8)
-#define HDMI_CORE_SYS_DE_CTRL
Re: [PATCH] OMAPDSS: HDMI: Register definition cleanup and improvements
Hi, On Fri, 2011-09-16 at 11:32 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com 1.Add some H/w indexable registers missed in definition. 2.Remove usage of struct hdmi_reg and use u16 instead. 3.Move the avi_infoframe parameters comments above the field. Please split this patch as those are separate things. And include this patch in the HDMI patch series that we discussed about (reg dumps, clk dumps etc). Tomi -- 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/3] OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting
On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed
to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
OMAP4, alpha blending is always enabled by default, if the above bits are set,
we switch to an OMAP3 compatibility mode where the zorder values in the pipleine
attribute registers are ignored and a fixed priority is configured.
Rename the manager_info member alpha_enabled to partial_alpha_enabled for
more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and
FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and OMAP4
alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2 user is
expected to check for the ZORDER cap, if an overlay doesn't have this cap, the
user is expected to set the parameter partial_alpha_enabled. If the overlay has
ZORDER cap, the DSS2 user can assume that alpha blending is already enabled.
Don't support OMAP3 compatibility mode for now. Trying to read/write to
alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does not
set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits.
Change alpha_enabled to partial_alpha_enabled int the omap_vout driver. Use
overlay cap OMAP_DSS_OVL_CAP_GLOBAL_ALPHA to check if overlay supports alpha
blending or not. Replace this with checks for VIDEO1 pipeline.
Initial patch was made by: Lajos Molnar mol...@ti.com
Cc: linux-me...@vger.kernel.org
Cc: Lajos Molnar mol...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 16 +++-
drivers/video/omap2/dss/dispc.c| 24
drivers/video/omap2/dss/dss.h |4 ++--
drivers/video/omap2/dss/dss_features.c | 22 +++---
drivers/video/omap2/dss/dss_features.h |3 ++-
drivers/video/omap2/dss/manager.c | 28 +++-
include/video/omapdss.h|3 ++-
7 files changed, 59 insertions(+), 41 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index b3a5ecd..95daf98 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1165,12 +1165,17 @@ static int vidioc_try_fmt_vid_overlay(struct file
*file, void *fh,
{
int ret = 0;
struct omap_vout_device *vout = fh;
+ struct omap_overlay *ovl;
+ struct omapvideo_info *ovid;
struct v4l2_window *win = f-fmt.win;
+ ovid = vout-vid_info;
+ ovl = ovid-overlays[0];
+
ret = omap_vout_try_window(vout-fbuf, win);
if (!ret) {
- if (vout-vid == OMAP_VIDEO1)
+ if ((ovl-caps OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
win-global_alpha = 255;
else
win-global_alpha = f-fmt.win.global_alpha;
@@ -1194,8 +1199,7 @@ static int vidioc_s_fmt_vid_overlay(struct file *file,
void *fh,
ret = omap_vout_new_window(vout-crop, vout-win, vout-fbuf, win);
if (!ret) {
- /* Video1 plane does not support global alpha */
- if (ovl-id == OMAP_DSS_VIDEO1)
+ if ((ovl-caps OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
vout-win.global_alpha = 255;
else
vout-win.global_alpha = f-fmt.win.global_alpha;
@@ -1788,7 +1792,9 @@ static int vidioc_s_fbuf(struct file *file, void *fh,
if (ovl-manager ovl-manager-get_manager_info
ovl-manager-set_manager_info) {
ovl-manager-get_manager_info(ovl-manager, info);
- info.alpha_enabled = enable;
+ /* enable this only if there is no zorder cap */
+ if ((ovl-caps OMAP_DSS_OVL_CAP_ZORDER) == 0)
+ info.partial_alpha_enabled = enable;
if (ovl-manager-set_manager_info(ovl-manager, info))
return -EINVAL;
}
@@ -1820,7 +1826,7 @@ static int vidioc_g_fbuf(struct file *file, void *fh,
}
if (ovl-manager ovl-manager-get_manager_info) {
ovl-manager-get_manager_info(ovl-manager, info);
- if (info.alpha_enabled)
+ if (info.partial_alpha_enabled)
a-flags |= V4L2_FBUF_FLAG_LOCAL_ALPHA;
}
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5e6849e..e0639d3 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -179,7 +179,8 @@ static void dispc_save_context(void)
SR(CONTROL);
SR(CONFIG);
SR(LINE_NUMBER);
- if (dss_has_feature(FEAT_GLOBAL_ALPHA))
+ if (dss_has_feature(FEAT_ALPHA_FIXED_ZORDER) ||
+ dss_has_feature(FEAT_ALPHA_FREE_ZORDER))
SR(GLOBAL_ALPHA);
if (dss_has_feature(FEAT_MGR_LCD2)) {
SR(CONTROL2);
@@ -293,7 +294,8 @@ static void
[PATCH v2 2/3] OMAPDSS: DISPC: VIDEO3 pipeline support
Add support for VIDEO3 pipeline on OMAP4:
- Add VIDEO3 pipeline information in dss_features and omapdss.h
- Add VIDEO3 pipeline register coefficients in dispc.h
- Create a new overlay structure corresponding to VIDEO3.
- Make changes in dispc.c for VIDEO3
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c| 17 --
drivers/video/omap2/dss/dispc.h| 57
drivers/video/omap2/dss/dss_features.c | 18 +-
drivers/video/omap2/dss/dss_features.h |2 +-
drivers/video/omap2/dss/overlay.c |5 +++
include/video/omapdss.h|5 ++-
6 files changed, 97 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e0639d3..fa7aadf 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -751,7 +751,7 @@ static void dispc_ovl_set_pre_mult_alpha(enum omap_plane
plane, bool enable)
static void dispc_ovl_setup_global_alpha(enum omap_plane plane, u8
global_alpha)
{
- static const unsigned shifts[] = { 0, 8, 16, };
+ static const unsigned shifts[] = { 0, 8, 16, 24, };
int shift;
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
@@ -866,6 +866,7 @@ static void dispc_ovl_set_channel_out(enum omap_plane plane,
break;
case OMAP_DSS_VIDEO1:
case OMAP_DSS_VIDEO2:
+ case OMAP_DSS_VIDEO3:
shift = 16;
break;
default:
@@ -903,7 +904,7 @@ static void dispc_ovl_set_channel_out(enum omap_plane plane,
static void dispc_ovl_set_burst_size(enum omap_plane plane,
enum omap_burst_size burst_size)
{
- static const unsigned shifts[] = { 6, 14, 14, };
+ static const unsigned shifts[] = { 6, 14, 14, 14, };
int shift;
shift = shifts[plane];
@@ -988,7 +989,7 @@ static void dispc_ovl_set_vid_color_conv(enum omap_plane
plane, bool enable)
static void dispc_ovl_enable_replication(enum omap_plane plane, bool enable)
{
- static const unsigned shifts[] = { 5, 10, 10 };
+ static const unsigned shifts[] = { 5, 10, 10, 10 };
int shift;
shift = shifts[plane];
@@ -2558,6 +2559,10 @@ void dispc_dump_irqs(struct seq_file *s)
PIS(VID1_END_WIN);
PIS(VID2_FIFO_UNDERFLOW);
PIS(VID2_END_WIN);
+ if (dss_feat_get_num_ovls() 3) {
+ PIS(VID3_FIFO_UNDERFLOW);
+ PIS(VID3_END_WIN);
+ }
PIS(SYNC_LOST);
PIS(SYNC_LOST_DIGIT);
PIS(WAKEUP);
@@ -2583,6 +2588,7 @@ void dispc_dump_regs(struct seq_file *s)
[OMAP_DSS_GFX] = GFX,
[OMAP_DSS_VIDEO1] = VID1,
[OMAP_DSS_VIDEO2] = VID2,
+ [OMAP_DSS_VIDEO3] = VID3,
};
const char **p_names;
@@ -2985,6 +2991,8 @@ static void print_irq_status(u32 status)
PIS(OCP_ERR);
PIS(VID1_FIFO_UNDERFLOW);
PIS(VID2_FIFO_UNDERFLOW);
+ if (dss_feat_get_num_ovls() 3)
+ PIS(VID3_FIFO_UNDERFLOW);
PIS(SYNC_LOST);
PIS(SYNC_LOST_DIGIT);
if (dss_has_feature(FEAT_MGR_LCD2))
@@ -3082,6 +3090,7 @@ static void dispc_error_worker(struct work_struct *work)
DISPC_IRQ_GFX_FIFO_UNDERFLOW,
DISPC_IRQ_VID1_FIFO_UNDERFLOW,
DISPC_IRQ_VID2_FIFO_UNDERFLOW,
+ DISPC_IRQ_VID3_FIFO_UNDERFLOW,
};
static const unsigned sync_lost_bits[] = {
@@ -3257,6 +3266,8 @@ static void _omap_dispc_initialize_irq(void)
dispc.irq_error_mask = DISPC_IRQ_MASK_ERROR;
if (dss_has_feature(FEAT_MGR_LCD2))
dispc.irq_error_mask |= DISPC_IRQ_SYNC_LOST2;
+ if (dss_feat_get_num_ovls() 3)
+ dispc.irq_error_mask |= DISPC_IRQ_VID3_FIFO_UNDERFLOW;
/* there's SYNC_LOST_DIGIT waiting after enabling the DSS,
* so clear it */
diff --git a/drivers/video/omap2/dss/dispc.h b/drivers/video/omap2/dss/dispc.h
index 6c9ee0a..c06efc3 100644
--- a/drivers/video/omap2/dss/dispc.h
+++ b/drivers/video/omap2/dss/dispc.h
@@ -291,6 +291,8 @@ static inline u16 DISPC_OVL_BASE(enum omap_plane plane)
return 0x00BC;
case OMAP_DSS_VIDEO2:
return 0x014C;
+ case OMAP_DSS_VIDEO3:
+ return 0x0300;
default:
BUG();
}
@@ -304,6 +306,8 @@ static inline u16 DISPC_BA0_OFFSET(enum omap_plane plane)
case OMAP_DSS_VIDEO1:
case OMAP_DSS_VIDEO2:
return 0x;
+ case OMAP_DSS_VIDEO3:
+ return 0x0008;
default:
BUG();
}
@@ -316,6 +320,8 @@ static inline u16 DISPC_BA1_OFFSET(enum omap_plane plane)
case OMAP_DSS_VIDEO1:
case OMAP_DSS_VIDEO2:
return 0x0004;
+ case OMAP_DSS_VIDEO3:
+ return 0x000C;
default:
[PATCH v2 3/3] OMAPDSS: DISPC: zorder support for DSS overlays
Add zorder support on OMAP4, this feature allows deciding the visibility order
of the overlays based on the zorder value provided as an overlay info parameter
or a sysfs attribute of the overlay object.
Use the overlay cap OMAP_DSS_OVL_CAP_ZORDER to determine whether zorder is
supported for the overlay or not. Use dss feature FEAT_ALPHA_FREE_ZORDER
if the caps are not available.
Ensure that all overlays that are enabled and connected to the same manager
have different zorders. Swapping zorders of 2 enabled overlays currently
requires disabling one of the overlays.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 24
drivers/video/omap2/dss/overlay.c | 72 +
include/video/omapdss.h |1 +
3 files changed, 97 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index fa7aadf..6892cfd 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -739,6 +739,27 @@ static void dispc_ovl_set_vid_size(enum omap_plane plane,
int width, int height)
dispc_write_reg(DISPC_OVL_SIZE(plane), val);
}
+static void dispc_ovl_set_zorder(enum omap_plane plane, u8 zorder)
+{
+ struct omap_overlay *ovl = omap_dss_get_overlay(plane);
+
+ if ((ovl-caps OMAP_DSS_OVL_CAP_ZORDER) == 0)
+ return;
+
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), zorder, 27, 26);
+}
+
+static void dispc_ovl_enable_zorder_planes(void)
+{
+ int i;
+
+ if (!dss_has_feature(FEAT_ALPHA_FREE_ZORDER))
+ return;
+
+ for (i = 0; i dss_feat_get_num_ovls(); i++)
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(i), 1, 25, 25);
+}
+
static void dispc_ovl_set_pre_mult_alpha(enum omap_plane plane, bool enable)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
@@ -1866,6 +1887,7 @@ int dispc_ovl_setup(enum omap_plane plane, struct
omap_overlay_info *oi,
dispc_ovl_set_rotation_attrs(plane, oi-rotation, oi-mirror,
oi-color_mode);
+ dispc_ovl_set_zorder(plane, oi-zorder);
dispc_ovl_set_pre_mult_alpha(plane, oi-pre_mult_alpha);
dispc_ovl_setup_global_alpha(plane, oi-global_alpha);
@@ -3317,6 +3339,8 @@ static void _omap_dispc_initial_config(void)
dispc_read_plane_fifo_sizes();
dispc_configure_burst_sizes();
+
+ dispc_ovl_enable_zorder_planes();
}
/* DISPC HW IP initialisation */
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index 11d21e3..ab8e40e 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -311,6 +311,42 @@ static ssize_t overlay_pre_mult_alpha_store(struct
omap_overlay *ovl,
return size;
}
+static ssize_t overlay_zorder_show(struct omap_overlay *ovl, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, %d\n, ovl-info.zorder);
+}
+
+static ssize_t overlay_zorder_store(struct omap_overlay *ovl,
+ const char *buf, size_t size)
+{
+ int r;
+ u8 zorder;
+ struct omap_overlay_info info;
+
+ if ((ovl-caps OMAP_DSS_OVL_CAP_ZORDER) == 0)
+ return -ENODEV;
+
+ r = kstrtou8(buf, 0, zorder);
+ if (r)
+ return r;
+
+ ovl-get_overlay_info(ovl, info);
+
+ info.zorder = zorder;
+
+ r = ovl-set_overlay_info(ovl, info);
+ if (r)
+ return r;
+
+ if (ovl-manager) {
+ r = ovl-manager-apply(ovl-manager);
+ if (r)
+ return r;
+ }
+
+ return size;
+}
+
struct overlay_attribute {
struct attribute attr;
ssize_t (*show)(struct omap_overlay *, char *);
@@ -337,6 +373,8 @@ static OVERLAY_ATTR(global_alpha, S_IRUGO|S_IWUSR,
static OVERLAY_ATTR(pre_mult_alpha, S_IRUGO|S_IWUSR,
overlay_pre_mult_alpha_show,
overlay_pre_mult_alpha_store);
+static OVERLAY_ATTR(zorder, S_IRUGO|S_IWUSR,
+ overlay_zorder_show, overlay_zorder_store);
static struct attribute *overlay_sysfs_attrs[] = {
overlay_attr_name.attr,
@@ -348,6 +386,7 @@ static struct attribute *overlay_sysfs_attrs[] = {
overlay_attr_enabled.attr,
overlay_attr_global_alpha.attr,
overlay_attr_pre_mult_alpha.attr,
+ overlay_attr_zorder.attr,
NULL
};
@@ -397,6 +436,7 @@ int dss_check_overlay(struct omap_overlay *ovl, struct
omap_dss_device *dssdev)
struct omap_overlay_info *info;
u16 outw, outh;
u16 dw, dh;
+ int i;
if (!dssdev)
return 0;
@@ -452,6 +492,31 @@ int dss_check_overlay(struct omap_overlay *ovl, struct
omap_dss_device *dssdev)
return -EINVAL;
}
+ if (ovl-caps OMAP_DSS_OVL_CAP_ZORDER) {
+ if (info-zorder 0 || info-zorder 3) {
+ DSSERR(zorder out of range: %d\n,
+
[PATCH v2 0/3] OMAPDSS: DISPC: VIDEO3 and ZORDER support
This contains support for VIDEO3 pipeline and zorder support for OMAP4 Display controller. This set originally had some more miscellaneous patches. Those patches have been separated out and this set is created since it makes some trivial changes in the omap_vout driver. The patch set is based on Tomi's master branch. It can be tried on: https://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone/commits/dispc_misc Tested on 4430sdp, 3430sdp. Archit Taneja (3): OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting OMAPDSS: DISPC: VIDEO3 pipeline support OMAPDSS: DISPC: zorder support for DSS overlays drivers/media/video/omap/omap_vout.c | 16 +-- drivers/video/omap2/dss/dispc.c| 65 -- drivers/video/omap2/dss/dispc.h| 57 +++ drivers/video/omap2/dss/dss.h |4 +- drivers/video/omap2/dss/dss_features.c | 40 +++- drivers/video/omap2/dss/dss_features.h |5 +- drivers/video/omap2/dss/manager.c | 28 drivers/video/omap2/dss/overlay.c | 77 include/video/omapdss.h|9 +++- 9 files changed, 253 insertions(+), 48 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
Re: [RFC PATCH 01/11] OMAP: TWL: Clean up mode and ops mask passed from board files
On Thursday 15 September 2011 07:02 PM, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:51:57PM +0530, Rajendra Nayak wrote: The TWL driver seems to set the default .valid_modes_mask to (REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY) and .valid_ops_mask to (REGULATOR_CHANGE_VOLTAGE | REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS) for all the registered regulators. There is no need for all the board files to pass this information additionally, when the driver already sets them by default. the driver? This sounds very buggy... Yeah, the driver currently sets some default based on what the chip itself supports and completely ignores the board inputs. How about the driver using the defaults and letting the boards override it (if it ever wants to)? Currently none of the boards (using any of the twl regulators) seem to override the defaults and that way a lot of this duplication in board files could be avoided. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 02/11] regulator: Fix error check in set_consumer_device_supply
On Thursday 15 September 2011 07:03 PM, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:51:58PM +0530, Rajendra Nayak wrote: The parameters to set_consumer_device_supply() can be considered invalid (and hence it could return -EINVAL) if nether consumer_dev nor consumer_dev_name are passed, not when *both* are passed. Signed-off-by: Rajendra Nayakrna...@ti.com No, passing both is a clear bug on the part of the caller - the two ways of specifying the device are not supposed to be used together. Got it, I'll just drop this one. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
On Thursday 15 September 2011 07:14 PM, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote: .../devicetree/bindings/regulator/regulator.txt| 37 + drivers/of/Kconfig |6 ++ drivers/of/Makefile|1 + drivers/of/of_regulator.c | 85 include/linux/of_regulator.h | 23 + Don't go hiding the bindings for things away from the code they're binding. Bindings for the regualtor API are a regulator API thing and should be part of the regulator API code. Sure, Grant seems to think so too, so I'll just move these into drivers/regulator/ +Required properties: +- compatible: Must be regulator; Is this idiomatic or should we just have a helper that parses a big list of properties from the device node? I will just be dropping this and use compatible to specify the specific device type like regulator-twl or regulator-fixed. +- mode-fast: boolean, Can handle fast changes in its load +- mode-normal: boolean, Normal regulator power supply mode +- mode-idle: boolean, Can be more efficient during light loads +- mode-standby: boolean, Can be most efficient during light loads I guess these are actually permissions to set the given modes? The documentation should be clearer. Ok +- apply-uV: apply uV constraint if min == max This seems a bit Linux/runtime policy specific (especially the last bit). So these bindings should be defined differently? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
On Thursday 15 September 2011 07:16 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
+Required properties:
+- compatible: Must be regulator,ti,twl-reg;
I'd expect listings for the specific chips too.
I just did'nt do that because we have just one driver for
all twl chips (twl4030/twl6030/twl6025) and there seems to be
no real need to identify specific chips while we could
do knowing just the chip family.
+ xyz-regulator: regulator@0 {
+ compatible = regulator,ti,twl-reg;
+ ti,reg-id =37; /* TWL6030_REG_VAUX1_6030 */
These magic numbers are *very* Linux specific, we should have a better
way of specifying regulators - I'd off the top of my head expect that
the compatible property would identify the regulator.
The driver seems to use a per-regulator table, and it uses the above
id to indexed into it. I could probably do it with the compatible
property, but that would mean I have a compatible for *each* regulator
instance, like ti,twl-reg-vaux1, ti,twl-reg-vmmc etc.
Does that sound reasonable?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 06/11] DT: regulator: Helper routine to extract fixed_voltage_config
On Thursday 15 September 2011 07:20 PM, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote: .../devicetree/bindings/regulator/regulator.txt| 19 drivers/of/of_regulator.c | 31 include/linux/of_regulator.h |7 3 files changed, 57 insertions(+), 0 deletions(-) Again, this should be part of the regulator API code not hidden away where it will only get reviewed by device tree people. Ok, will do. Required properties: - compatible: Must be regulator; +or +- compatible: Must be regulator-fixed; /* For Fixed volatge regulator */ This seems at best confusing - the fixed voltage regulator is a particular regulator driver, and the general concept of a fixed voltage regulator is still a subset of regulators. Yeah, I will be defining the compatible based on the different regulator types, fixed being one of them. so they would be something like - compatible: Must be regulator-twl for twl regulators - compatible: Must be regulator-fixed for fixed regulators +# For fixed voltage regulators +- supply-name: Name of the regulator supply +- microvolts: Output voltage of regulator +- gpio: gpio to use for enable control +- startup-delay: startup time in microseconds +- enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low +- enabled-at-boot: 1 = yes, 0 = no Much of this is specific to the Linux fixed voltage regulator driver rather than a generic regulator with a fixed voltage. So how should these non-generic things be handled through device tree? Should they never be part of dt or should the bindings just be defined such that its clear they are linux specific? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 09/11] DT: regulator: Helper to extract regulator node based on supply name
On Friday 16 September 2011 04:33 AM, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:50:35PM -0600, Grant Likely wrote: We've got two competing approaches here. For reg and interrupts, the proposal on the table that we talked about at LPC is to do reg-names and interrupts-names so as to preserve the existing semantics of the reg and interrupts properties. For gpios we're using the binding name-gpios for named gpio references. There isn't the same pressure to preserve existing bindings in that case. I'm okay with either approach, providing that -regulator is encoded into the name. I think I prefer the latter but I'm probably not too fussed. I'd rather use something like -supply for these just on the basis that you don't always connect things to regulators (for example, speaker supplies are generally attached direct to the battery). Ok, I'll go with name-supply then. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 10/11] regulator: Implement consumer regulator mapping from device tree
On Thursday 15 September 2011 07:29 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:06PM +0530, Rajendra Nayak wrote:
+#ifdef CONFIG_OF
+ struct device_node *node;
+ node = of_get_regulator(dev, id);
+ if (!node)
+ goto out;
+ list_for_each_entry(rdev, regulator_list, list)
+ if (node == rdev-node)
+ goto found;
+#else
list_for_each_entry(map,regulator_map_list, list) {
/* If the mapping has a device set up it must match */
if (map-dev_name
@@ -1178,6 +1189,7 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
goto found;
}
}
+#endif
This forces all machines to use device tree when CONFIG_OF is enabled.
I'd expect to see both mechanisms supported simultaneously, for example
by falling back to the current code if the device tree lookup fails.
agree, will change this to fall back if the dt lookup fails.
@@ -1216,6 +1228,15 @@ found:
if (!try_module_get(rdev-owner))
goto out;
+#ifdef CONFIG_OF
+ ret = set_consumer_device_supply(rdev, dev, devname, id);
+ if (ret 0) {
+ dev_err(dev, Failed to set supply %d\n, ret);
+ unset_regulator_supplies(rdev);
+ goto out;
+ }
+#endif
+
This seems wrong, why are we adding things to the regulator_map which is
really only there for lookups when we already did the lookup using the
device tree?
I did this only so the mappings show up in sysfs.
@@ -2619,6 +2640,8 @@ struct regulator_dev *regulator_register(struct
regulator_desc *regulator_desc,
rdev-reg_data = driver_data;
rdev-owner = regulator_desc-owner;
rdev-desc = regulator_desc;
+ if (dev dev-of_node)
+ rdev-node = dev-of_node;
dev is mandatory.
ok
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 11/11] DT: regulator: register regulators as platform devices
On Thursday 15 September 2011 07:51 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:07PM +0530, Rajendra Nayak wrote:
of_regulator_register_devices() registers all regulators
as platform devices. Use this to register all twl regulators
from the twl driver probe.
Regulators can be devices of any type, not just platform devices.
Right, I am just going to drop this patch, since we would have all
twl child nodes being added as platform devices.
drivers/mfd/twl-core.c |3 +++
drivers/of/of_regulator.c| 30 ++
include/linux/of_regulator.h |5 +
Again, in the regulator code not hidden away please.
+/**
+ * of_regulator_register_devices - Register regulator devices to platform bus
+ * @np:Parent device node with regulator child nodes
+ *
+ * Registers all the regulator and regulator-fixed nodes as platform devices
+ *
+ */
+void of_regulator_register_devices(struct device_node *np)
+{
+ struct device_node *child;
+ struct platform_device *dev;
+
+ for_each_child_of_node(np, child) {
+ if (of_device_is_compatible(child, regulator)
+ || of_device_is_compatible(child, regulator-fixed)) {
+ dev = of_device_alloc(child, NULL, NULL);
+ if (!dev)
+ return;
+ dev-dev.bus =platform_bus_type;
+ if (of_device_add(dev) != 0) {
+ platform_device_put(dev);
+ return;
+ }
I'm not entirely sure what this is for? Surely we should be
instantiating the subdevices of the MFD in the same way we always have
done?
+ }
+ }
+ return;
+}
+
diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
index 5fc7329..38cf7e3 100644
--- a/include/linux/of_regulator.h
+++ b/include/linux/of_regulator.h
@@ -15,6 +15,7 @@ extern struct fixed_voltage_config
*of_get_fixed_voltage_config(struct device_node *np);
extern struct device_node *of_get_regulator(struct device *dev,
const char *id);
+extern void of_regulator_register_devices(struct device_node *np);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
@@ -31,6 +32,10 @@ static inline struct device_node *of_get_regulator(struct
device *dev,
{
return NULL;
}
+static inline void of_regulator_register_devices(struct device_node *np)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
On Friday 16 September 2011 03:42 AM, Grant Likely wrote:
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.
Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.
Signed-off-by: Rajendra Nayakrna...@ti.com
---
.../devicetree/bindings/regulator/regulator.txt| 37 +
drivers/of/Kconfig |6 ++
drivers/of/Makefile|1 +
drivers/of/of_regulator.c | 85
I originally put the DT stuff under drivers/of for i2c and spi because
there was resistance from driver subsystem maintainers to having code
for something that was powerpc only. Now that it is no longer the
case, I recommend putting this code under drivers/regulator.
sure, will move these in drivers/regulator.
include/linux/of_regulator.h | 23 +
5 files changed, 152 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 drivers/of/of_regulator.c
create mode 100644 include/linux/of_regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 000..001e5ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,37 @@
+Voltage/Current Regulators
+
+Required properties:
+- compatible: Must be regulator;
A regulator compatible doesn't actually help much. Compatible is
for specifying the specific device, not for trying to describe what
kind of device it is. Instead, specific regulator bindings can adopt
extend this binding.
yeah, will have a compatible for each specific device.
+
+Optional properties:
+- supply-regulator: Name of the parent regulator
If this is a reference to another regulator node then don't use names.
Use phandles instead. In which case it should probably be named
something like regulator-parent (similar to interrupt parent).
However, I can imagine it possible for a regulator to have multiple
parents. It may just be better to go with something like the gpio
scheme ofphandle gpio-specifier list of entries. Or maybe just a
list of phandles would be sufficient.
Ok, I can use phandles instead of the name, and have a list to specify
multiple parents.
The linux regulator framework though limits to just one parent I guess.
+- min-uV: smallest voltage consumers may set
+- max-uV: largest voltage consumers may set
+- uV-offset: Offset applied to voltages from consumer to compensate for
voltage drops
+- min-uA: smallest current consumers may set
+- max-uA: largest current consumers may set
+- mode-fast: boolean, Can handle fast changes in its load
+- mode-normal: boolean, Normal regulator power supply mode
+- mode-idle: boolean, Can be more efficient during light loads
+- mode-standby: boolean, Can be most efficient during light loads
+- change-voltage: boolean, Output voltage can be changed by software
+- change-current: boolean, Output current can be chnaged by software
+- change-mode: boolean, Operating mode can be changed by software
+- change-status: boolean, Enable/Disable control for regulator exists
+- change-drms: boolean, Dynamic regulator mode switching is enabled
+- input-uV: Input voltage for regulator when supplied by another regulator
+- initial-mode: Mode to set at startup
+- always-on: boolean, regulator should never be disabled
+- boot-on: bootloader/firmware enabled regulator
+- apply-uV: apply uV constraint if min == max
To avoid collisions, I'd prefix all of these with a common prefix.
Something like regulator-*.
Ok.
These map 1:1 to how Linux currently implements regulators; which
isn't exactly bad, but it means that even if Linux changes, we're
still have to support this binding. Does this represent the best
layout for high level description of regulators?
I guess, except for some like apply-uV, which like Mark pointed
out are very linux/runtime policy specific.
Mark, what do you think?
+
+Example:
+
+ xyz-regulator: regulator@0 {
+ compatible = regulator;
+ min-uV =100;
+ max-uV =250;
+ mode-fast;
+ change-voltage;
+ always-on;
+ };
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index b3bfea5..296b96d 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -87,4 +87,10 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_REGULATOR
+ def_bool y
+ depends
Re: [RFC PATCH 05/11] TWL: regulator: Make twl-regulator driver extract data from DT
On Friday 16 September 2011 03:48 AM, Grant Likely wrote:
On Thu, Sep 15, 2011 at 04:52:01PM +0530, Rajendra Nayak wrote:
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayakrna...@ti.com
---
drivers/regulator/twl-regulator.c | 28 +---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index ee8747f..df1b95a 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -17,6 +17,8 @@
#includelinux/regulator/driver.h
#includelinux/regulator/machine.h
#includelinux/i2c/twl.h
+#includelinux/of.h
+#includelinux/of_regulator.h
/*
@@ -1011,6 +1013,9 @@ static int __devinit twlreg_probe(struct platform_device
*pdev)
struct regulation_constraints *c;
struct regulator_dev*rdev;
+ if (pdev-dev.of_node)
+ of_property_read_u32(pdev-dev.of_node, ti,reg-id,pdev-id);
+
Don't do this. As much as possible, don't reply on plaform_device-id
when using DT. Plus it is illegal to modify pdev-id after the device
is registered.
yeah, I did this hackery to just get around the drivers per-regulator
lookup table for which it uses the pdev-id as the index.
I will need to do this lookup based on compatible instead I guess.
for (i = 0, info = NULL; i ARRAY_SIZE(twl_regs); i++) {
if (twl_regs[i].desc.id != pdev-id)
continue;
@@ -1020,7 +1025,11 @@ static int __devinit twlreg_probe(struct platform_device
*pdev)
if (!info)
return -ENODEV;
- initdata = pdev-dev.platform_data;
+ if (pdev-dev.of_node)
+ initdata = of_get_regulator_init_data(pdev-dev.of_node);
+ else
+ initdata = pdev-dev.platform_data;
+
if (!initdata)
return -EINVAL;
@@ -1101,14 +1110,27 @@ static int __devexit twlreg_remove(struct
platform_device *pdev)
MODULE_ALIAS(platform:twl_reg);
+#if defined(CONFIG_OF)
+static const struct of_device_id twl_of_match[] __devinitconst = {
+ { .compatible = ti,twl-reg, },
This looks rather generic. Is this a specific chip? It should be.
We have multiple chips in the twl family like twl6030/twl6040/twl6025
but just one driver which handles all variants.
g.
+ {},
+};
+MODULE_DEVICE_TABLE(of, twl_of_match);
+#else
+#define twl_of_match NULL
+#endif
+
static struct platform_driver twlreg_driver = {
.probe = twlreg_probe,
.remove = __devexit_p(twlreg_remove),
/* NOTE: short name, to work around driver model truncation of
* twl_regulator.12 (and friends) to twl_regulator.1.
*/
- .driver.name= twl_reg,
- .driver.owner = THIS_MODULE,
+ .driver = {
+ .name = twl_reg,
+ .owner = THIS_MODULE,
+ .of_match_table = twl_of_match,
+ },
};
static int __init twlreg_init(void)
--
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: [PATCH 5/5 v9] mfd: omap: usb: Runtime PM support
On Fri, Sep 16, 2011 at 11:17 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Fri, Sep 16, 2011 at 6:10 AM, Frank Rowand frank.row...@am.sony.com wrote: On 09/15/11 06:22, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com The usbhs core driver does not enable/disable the interface and functional clocks; These clocks are handled by hwmod and runtime pm, hence instead of the clock enable/disable, the runtime pm APIS are used. however,the port clocks are handled by the usbhs core. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/include/plat/usb.h | 3 - drivers/mfd/omap-usb-host.c | 731 + drivers/usb/host/ehci-omap.c | 17 +- drivers/usb/host/ohci-omap3.c | 18 +- 4 files changed, 295 insertions(+), 474 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h index 17d3c93..2b66dc2 100644 Patch 5/5 is white space mangled. The tabs have been changed into spaces. -Frank Hi Frank I tried the checkpatch with --strict option; its not showing anything here. may be some problem with your editor/browser. regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 01/11] OMAP: TWL: Clean up mode and ops mask passed from board files
On Fri, Sep 16, 2011 at 12:41:53PM +0530, Rajendra Nayak wrote: On Thursday 15 September 2011 07:02 PM, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:51:57PM +0530, Rajendra Nayak wrote: There is no need for all the board files to pass this information additionally, when the driver already sets them by default. the driver? This sounds very buggy... Yeah, the driver currently sets some default based on what the chip itself supports and completely ignores the board inputs. How about the driver using the defaults and letting the boards override it (if it ever wants to)? Currently none of the boards (using any of the twl regulators) seem to override the defaults and that way a lot of this duplication in board files could be avoided. No, this is just plain buggy. It's fine for OMAP to have some common stuff that the board reference but if the drivers are doing this that's bad. The drivers and framework shouldn't touch the hardware unless the board says it's OK. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
On Fri, Sep 16, 2011 at 12:45:55PM +0530, Rajendra Nayak wrote: On Thursday 15 September 2011 07:14 PM, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote: +- apply-uV: apply uV constraint if min == max This seems a bit Linux/runtime policy specific (especially the last bit). So these bindings should be defined differently? If at all. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
On Fri, Sep 16, 2011 at 12:47:05PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:16 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
+Required properties:
+- compatible: Must be regulator,ti,twl-reg;
I'd expect listings for the specific chips too.
I just did'nt do that because we have just one driver for
all twl chips (twl4030/twl6030/twl6025) and there seems to be
no real need to identify specific chips while we could
do knowing just the chip family.
The driver can bind to as many names as it likes.
+ xyz-regulator: regulator@0 {
+ compatible = regulator,ti,twl-reg;
+ ti,reg-id =37; /* TWL6030_REG_VAUX1_6030 */
These magic numbers are *very* Linux specific, we should have a better
way of specifying regulators - I'd off the top of my head expect that
the compatible property would identify the regulator.
The driver seems to use a per-regulator table, and it uses the above
id to indexed into it. I could probably do it with the compatible
I know what the driver is doing, the problem is that it's very much
specific to Linux (and Linux may change the numbers at some point).
property, but that would mean I have a compatible for *each* regulator
instance, like ti,twl-reg-vaux1, ti,twl-reg-vmmc etc.
Does that sound reasonable?
Yes.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 06/11] DT: regulator: Helper routine to extract fixed_voltage_config
On Fri, Sep 16, 2011 at 12:49:17PM +0530, Rajendra Nayak wrote: On Thursday 15 September 2011 07:20 PM, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote: +# For fixed voltage regulators +- supply-name: Name of the regulator supply +- microvolts: Output voltage of regulator +- gpio: gpio to use for enable control +- startup-delay: startup time in microseconds +- enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low +- enabled-at-boot: 1 = yes, 0 = no Much of this is specific to the Linux fixed voltage regulator driver rather than a generic regulator with a fixed voltage. So how should these non-generic things be handled through device tree? Should they never be part of dt or should the bindings just be defined such that its clear they are linux specific? Having them be part of the fixed voltage regulator bindings would be fine, the problem is that you're adding this in framework code not in a driver. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 10/11] regulator: Implement consumer regulator mapping from device tree
On Fri, Sep 16, 2011 at 12:51:06PM +0530, Rajendra Nayak wrote: On Thursday 15 September 2011 07:29 PM, Mark Brown wrote: This seems wrong, why are we adding things to the regulator_map which is really only there for lookups when we already did the lookup using the device tree? I did this only so the mappings show up in sysfs. Reworking to bind sysfs at regulator_get() time seems a better approach to this. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 01/11] OMAP: TWL: Clean up mode and ops mask passed from board files
On Friday 16 September 2011 02:27 PM, Mark Brown wrote: On Fri, Sep 16, 2011 at 12:41:53PM +0530, Rajendra Nayak wrote: On Thursday 15 September 2011 07:02 PM, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:51:57PM +0530, Rajendra Nayak wrote: There is no need for all the board files to pass this information additionally, when the driver already sets them by default. the driver? This sounds very buggy... Yeah, the driver currently sets some default based on what the chip itself supports and completely ignores the board inputs. How about the driver using the defaults and letting the boards override it (if it ever wants to)? Currently none of the boards (using any of the twl regulators) seem to override the defaults and that way a lot of this duplication in board files could be avoided. No, this is just plain buggy. It's fine for OMAP to have some common stuff that the board reference but if the drivers are doing this that's bad. The drivers and framework shouldn't touch the hardware unless the board says it's OK. fair enough, I'll fix up the driver then. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
On Friday 16 September 2011 02:30 PM, Mark Brown wrote:
On Fri, Sep 16, 2011 at 12:47:05PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:16 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
+Required properties:
+- compatible: Must be regulator,ti,twl-reg;
I'd expect listings for the specific chips too.
I just did'nt do that because we have just one driver for
all twl chips (twl4030/twl6030/twl6025) and there seems to be
no real need to identify specific chips while we could
do knowing just the chip family.
The driver can bind to as many names as it likes.
makes sense, I'll add one per chip variant.
+ xyz-regulator: regulator@0 {
+ compatible = regulator,ti,twl-reg;
+ ti,reg-id =37; /* TWL6030_REG_VAUX1_6030 */
These magic numbers are *very* Linux specific, we should have a better
way of specifying regulators - I'd off the top of my head expect that
the compatible property would identify the regulator.
The driver seems to use a per-regulator table, and it uses the above
id to indexed into it. I could probably do it with the compatible
I know what the driver is doing, the problem is that it's very much
specific to Linux (and Linux may change the numbers at some point).
property, but that would mean I have a compatible for *each* regulator
instance, like ti,twl-reg-vaux1, ti,twl-reg-vmmc etc.
Does that sound reasonable?
Yes.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 06/11] DT: regulator: Helper routine to extract fixed_voltage_config
On Friday 16 September 2011 02:31 PM, Mark Brown wrote: On Fri, Sep 16, 2011 at 12:49:17PM +0530, Rajendra Nayak wrote: On Thursday 15 September 2011 07:20 PM, Mark Brown wrote: On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote: +# For fixed voltage regulators +- supply-name: Name of the regulator supply +- microvolts: Output voltage of regulator +- gpio: gpio to use for enable control +- startup-delay: startup time in microseconds +- enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low +- enabled-at-boot: 1 = yes, 0 = no Much of this is specific to the Linux fixed voltage regulator driver rather than a generic regulator with a fixed voltage. So how should these non-generic things be handled through device tree? Should they never be part of dt or should the bindings just be defined such that its clear they are linux specific? Having them be part of the fixed voltage regulator bindings would be fine, the problem is that you're adding this in framework code not in a driver. agree, will make the bindings fixed voltage regulator specific. -- 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 v15 06/12] OMAP: dmtimer: switch-over to platform device driver
[...]
1. Modify the inline access functions to take the PEND and others
if needed registers as a parameter
2. Modify mach-omap2/timer.c to initialize the PEND and others
in the SoC specific timer_init function
Just to make my understanding complete, need some clarifications:
As we would end up modifying almost all inline functions, what naming
convention should we follow for the parameters? For instance, PEND
is related to TWPS register. So are you suggesting using parameter
names related to respective registers in each inline functions?
If that is the case we would end up declaring lot of local variables along
with PEND. Instead, we could very well have just two variables to
represent functional and interrupt offsets.
Also, in plat-omap/dmtimer.c, timer_regs{} stores the register values and
not the register offsets. Therefore, we would not be able to pass as
parameters, timer-context.x ... etc.
Please let me know if I am off-track in my understanding.
Thanks.
--
Tarun
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/6] usb: musb: omap: Configure OTG_INTERFSEL for proper charger detection
Hello.
On 15-09-2011 18:19, Kishon Vijay Abraham I wrote:
Setting OTG_INTERFSEL to UTMI interferes with charger detection resulting
in incorrect detection of charger type. Hence OTG_INTERFSEL is configured to
ULPI initially and changed to UTMI only after receiving USB_EVENT_ID or
USB_EVENT_VBUS notification.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Balaji T Kbalaj...@ti.com
AFAIK, full name is needed here.
[sandesh.go...@ti.com: The interface selection has to be done before the PHY
is activated and is not allowed to change when the PHY clock is already
running]
No signoff from him?
---
drivers/usb/musb/omap2430.c | 50 +++---
1 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index fc9377c..724450b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -228,6 +228,7 @@ static inline void omap2430_low_level_init(struct musb
*musb)
static int musb_otg_notifications(struct notifier_block *nb,
unsigned long event, void *unused)
{
+ u32 val;
struct musb *musb = container_of(nb, struct musb, nb);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -240,11 +241,32 @@ static int musb_otg_notifications(struct notifier_block
*nb,
if (is_otg_enabled(musb)) {
if (musb-gadget_driver) {
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ if (data-interface_type ==
+ MUSB_INTERFACE_UTMI) {
+ val= ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
usb_phy_init(musb-xceiv);
omap2430_musb_set_vbus(musb, 1);
}
} else {
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ if (data-interface_type == MUSB_INTERFACE_UTMI) {
+ val= ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
usb_phy_init(musb-xceiv);
omap2430_musb_set_vbus(musb, 1);
}
@@ -255,6 +277,16 @@ static int musb_otg_notifications(struct notifier_block
*nb,
if (musb-gadget_driver)
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ if (data-interface_type == MUSB_INTERFACE_UTMI) {
+ val= ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
usb_phy_init(musb-xceiv);
break;
Why repeat the same sequence 3 times. Couldn't you factor it out into a
subroutine?
@@ -272,6 +304,11 @@ static int musb_otg_notifications(struct notifier_block
*nb,
otg_set_vbus(musb-xceiv-otg, 0);
}
usb_phy_shutdown(musb-xceiv);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ val |= ULPI_12PIN;
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
break;
default:
dev_dbg(musb-controller, ID float\n);
@@ -304,16 +341,11 @@ static int omap2430_musb_init(struct musb *musb)
goto err1;
}
+ /* Set OTG_INTERFSEL to ULPI for correct charger detection.
+* This should be later set to UTMI.
+*/
l = musb_readl(musb-mregs, OTG_INTERFSEL);
-
- if (data-interface_type == MUSB_INTERFACE_UTMI) {
- /* OMAP4 uses Internal PHY GS70 which uses UTMI interface */
- l= ~ULPI_12PIN; /* Disable ULPI */
- l |= UTMI_8BIT; /* Enable UTMI */
- } else {
- l |= ULPI_12PIN;
- }
-
+ l |= ULPI_12PIN;
musb_writel(musb-mregs, OTG_INTERFSEL, l);
This also seems to be the same code repeated twice...
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
Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
On Fri, Sep 16, 2011 at 12:54:18PM +0530, Rajendra Nayak wrote: On Friday 16 September 2011 03:42 AM, Grant Likely wrote: However, I can imagine it possible for a regulator to have multiple parents. It may just be better to go with something like the gpio scheme ofphandle gpio-specifier list of entries. Or maybe just a list of phandles would be sufficient. Ok, I can use phandles instead of the name, and have a list to specify multiple parents. The linux regulator framework though limits to just one parent I guess. I think if we've got multiple parents they should be listed as named supplies rather than as parents since it's probably important which is which. In fact we probably want to list all parents as supplies since that's what they are, they just have special handling in the code due to the recursion. These map 1:1 to how Linux currently implements regulators; which isn't exactly bad, but it means that even if Linux changes, we're still have to support this binding. Does this represent the best layout for high level description of regulators? I guess, except for some like apply-uV, which like Mark pointed out are very linux/runtime policy specific. Mark, what do you think? Yes, overall this feels far too direct. -- 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] iommu/omap: Fix build error with !IOMMU_SUPPORT
On Thu, Sep 15, 2011 at 1:45 PM, Roedel, Joerg joerg.roe...@amd.com wrote: This doesn't work on platforms that may have more than one possible iommu driver, like x86 for example. Ok. Acked-by: Ohad Ben-Cohen o...@wizery.com (cc'ing Laurent for the VIDEO_OMAP3 part) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] [media]: OMAP_VOUT: Misc fixes and cleanup patches for 3.2
This set includes patches which do the following: - Fix crash if a we call dssdev-driver-update for a disabled panel. - Fix the issue of not being able to request for a buffer which is larger than what we did the last time. - Fix a small bug in omap_vout_isr() - Remove some redundant code in omap_vout_isr() - Add basic support for DSI panels Note: The patch OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation had been posted in the past, but wasn't commented on. So copied it here again. These patches are based on Tomi's master branch(which is based on 3.1-rc6), and a patches which affects omap_vout and has been posted recently on linux-media (see OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting). This tree can be used as reference: g...@gitorious.org:~boddob/linux-omap-dss2/archit-dss2-clone.git 'for_omap_vout' Archit Taneja (5): OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr OMAP_VOUT: Add support for DSI panels OMAP_VOUT: Don't trigger updates in omap_vout_probe drivers/media/video/omap/omap_vout.c | 199 +- 1 files changed, 99 insertions(+), 100 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 1/5] [media]: OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation
The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf and mmap
prevent
requesting a larger size buffer than what is allocated at kernel boot during
omap_vout_probe.
The requested size is compared with vout-buffer_size, this isn't correct as
vout-buffer_size is later set to the size requested in reqbuf. When the video
device is opened the next time, this check will prevent us to allocate a buffer
which is larger than what we requested the last time.
Don't use vout-buffer_size, always check with the parameters video1_bufsize
or video2_bufsize.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 95daf98..e14c82b 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct videobuf_queue
*q, unsigned int *count,
u32 phy_addr = 0, virt_addr = 0;
struct omap_vout_device *vout = q-priv_data;
struct omapvideo_info *ovid = vout-vid_info;
+ int vid_max_buf_size;
if (!vout)
return -EINVAL;
+ vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize :
+ video2_bufsize;
+
if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
return -EINVAL;
@@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q,
unsigned int *count,
video1_numbuffers : video2_numbuffers;
/* Check the size of the buffer */
- if (*size vout-buffer_size) {
+ if (*size vid_max_buf_size) {
v4l2_err(vout-vid_dev-v4l2_dev,
buffer allocation mismatch [%u] [%u]\n,
*size, vout-buffer_size);
@@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct
vm_area_struct *vma)
unsigned long size = (vma-vm_end - vma-vm_start);
struct omap_vout_device *vout = file-private_data;
struct videobuf_queue *q = vout-vbq;
+ int vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize :
+ video2_bufsize;
v4l2_dbg(1, debug, vout-vid_dev-v4l2_dev,
%s pgoff=0x%lx, start=0x%lx, end=0x%lx\n, __func__,
@@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct
vm_area_struct *vma)
return -EINVAL;
}
/* Check the size of the buffer */
- if (size vout-buffer_size) {
+ if (size vid_max_buf_size) {
v4l2_err(vout-vid_dev-v4l2_dev,
insufficient memory [%lu] [%u]\n,
size, vout-buffer_size);
--
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 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
Currently, there is a lot of redundant code is between DPI and VENC panels, this
can be made common by moving out field/interlace specific code to a separate
function called omapvid_handle_interlace_display(). There is no functional
change made.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 172 --
1 files changed, 82 insertions(+), 90 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index e14c82b..c5f2ea0 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -524,10 +524,50 @@ static int omapvid_apply_changes(struct omap_vout_device
*vout)
return 0;
}
+static int omapvid_handle_interlace_display(struct omap_vout_device *vout,
+ unsigned int irqstatus, struct timeval timevalue)
+{
+ u32 fid;
+
+ if (vout-first_int) {
+ vout-first_int = 0;
+ goto err;
+ }
+
+ if (irqstatus DISPC_IRQ_EVSYNC_ODD)
+ fid = 1;
+ else if (irqstatus DISPC_IRQ_EVSYNC_EVEN)
+ fid = 0;
+ else
+ goto err;
+
+ vout-field_id ^= 1;
+ if (fid != vout-field_id) {
+ /* reset field ID */
+ vout-field_id = 0;
+ } else if (0 == fid) {
+ if (vout-cur_frm == vout-next_frm)
+ goto err;
+
+ vout-cur_frm-ts = timevalue;
+ vout-cur_frm-state = VIDEOBUF_DONE;
+ wake_up_interruptible(vout-cur_frm-done);
+ vout-cur_frm = vout-next_frm;
+ } else {
+ if (list_empty(vout-dma_queue) ||
+ (vout-cur_frm != vout-next_frm))
+ goto err;
+ }
+
+ return vout-field_id;
+err:
+ return 0;
+}
+
static void omap_vout_isr(void *arg, unsigned int irqstatus)
{
- int ret;
- u32 addr, fid;
+ int ret, fid;
+ u32 addr;
struct omap_overlay *ovl;
struct timeval timevalue;
struct omapvideo_info *ovid;
@@ -548,107 +588,59 @@ static void omap_vout_isr(void *arg, unsigned int
irqstatus)
spin_lock(vout-vbq_lock);
do_gettimeofday(timevalue);
- if (cur_display-type != OMAP_DISPLAY_TYPE_VENC) {
- switch (cur_display-type) {
- case OMAP_DISPLAY_TYPE_DPI:
- if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
- goto vout_isr_err;
- break;
- case OMAP_DISPLAY_TYPE_HDMI:
- if (!(irqstatus DISPC_IRQ_EVSYNC_EVEN))
- goto vout_isr_err;
- break;
- default:
+ switch (cur_display-type) {
+ case OMAP_DISPLAY_TYPE_DPI:
+ if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
goto vout_isr_err;
- }
- if (!vout-first_int (vout-cur_frm != vout-next_frm)) {
- vout-cur_frm-ts = timevalue;
- vout-cur_frm-state = VIDEOBUF_DONE;
- wake_up_interruptible(vout-cur_frm-done);
- vout-cur_frm = vout-next_frm;
- }
- vout-first_int = 0;
- if (list_empty(vout-dma_queue))
+ break;
+ case OMAP_DISPLAY_TYPE_VENC:
+ fid = omapvid_handle_interlace_display(vout, irqstatus,
+ timevalue);
+ if (!fid)
goto vout_isr_err;
+ break;
+ case OMAP_DISPLAY_TYPE_HDMI:
+ if (!(irqstatus DISPC_IRQ_EVSYNC_EVEN))
+ goto vout_isr_err;
+ break;
+ default:
+ goto vout_isr_err;
+ }
- vout-next_frm = list_entry(vout-dma_queue.next,
- struct videobuf_buffer, queue);
- list_del(vout-next_frm-queue);
-
- vout-next_frm-state = VIDEOBUF_ACTIVE;
-
- addr = (unsigned long) vout-queued_buf_addr[vout-next_frm-i]
- + vout-cropped_offset;
+ if (!vout-first_int (vout-cur_frm != vout-next_frm)) {
+ vout-cur_frm-ts = timevalue;
+ vout-cur_frm-state = VIDEOBUF_DONE;
+ wake_up_interruptible(vout-cur_frm-done);
+ vout-cur_frm = vout-next_frm;
+ }
- /* First save the configuration in ovelray structure */
- ret = omapvid_init(vout, addr);
- if (ret)
- printk(KERN_ERR VOUT_NAME
- failed to set overlay info\n);
- /* Enable the pipeline and set the Go bit */
- ret = omapvid_apply_changes(vout);
- if (ret)
- printk(KERN_ERR
[PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
Currently, in omap_vout_isr(), if the panel type is DPI, and if we
get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the
current buffers state to VIDEOBUF_DONE and prepare to display the
next frame in the queue.
On OMAP4, because we have 2 LCD managers, the panel type itself is not
sufficient to tell if we have received the correct irq, i.e, we shouldn't
proceed ahead if we get a VSYNC interrupt for LCD2 manager, or a VSYNC2
interrupt for LCD manager.
Fix this by correlating LCD manager to VSYNC interrupt and LCD2 manager
to VSYNC2 interrupt.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index c5f2ea0..20638c3 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -566,8 +566,8 @@ err:
static void omap_vout_isr(void *arg, unsigned int irqstatus)
{
- int ret, fid;
- u32 addr;
+ int ret, fid, mgr_id;
+ u32 addr, irq;
struct omap_overlay *ovl;
struct timeval timevalue;
struct omapvideo_info *ovid;
@@ -583,6 +583,7 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus)
if (!ovl-manager || !ovl-manager-device)
return;
+ mgr_id = ovl-manager-id;
cur_display = ovl-manager-device;
spin_lock(vout-vbq_lock);
@@ -590,7 +591,14 @@ static void omap_vout_isr(void *arg, unsigned int
irqstatus)
switch (cur_display-type) {
case OMAP_DISPLAY_TYPE_DPI:
- if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
+ if (mgr_id == OMAP_DSS_CHANNEL_LCD)
+ irq = DISPC_IRQ_VSYNC;
+ else if (mgr_id == OMAP_DSS_CHANNEL_LCD2)
+ irq = DISPC_IRQ_VSYNC2;
+ else
+ goto vout_isr_err;
+
+ if (!(irqstatus irq))
goto vout_isr_err;
break;
case OMAP_DISPLAY_TYPE_VENC:
--
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 4/5] [media] OMAP_VOUT: Add support for DSI panels
Add support for DSI panels. DSI video mode panels will work directly. For
command mode panels, we will need to trigger updates regularly. This isn't done
by the omap_vout driver currently. It can still be supported if we connect a
framebuffer device to the panel and configure it in auto update mode.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 20638c3..51cf6c2 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -590,6 +590,7 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus)
do_gettimeofday(timevalue);
switch (cur_display-type) {
+ case OMAP_DISPLAY_TYPE_DSI:
case OMAP_DISPLAY_TYPE_DPI:
if (mgr_id == OMAP_DSS_CHANNEL_LCD)
irq = DISPC_IRQ_VSYNC;
--
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 5/5] [media]: OMAP_VOUT: Don't trigger updates in omap_vout_probe
Remove the code in omap_vout_probe() which calls display-driver-update() for
all the displays. This isn't correct because:
- An update in probe doesn't make sense, because we don't have any valid content
to show at this time.
- Calling update for a panel which isn't enabled is not supported by DSS2. This
leads to a crash at probe.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 51cf6c2..a9fcb1a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2220,14 +2220,6 @@ static int __init omap_vout_probe(struct platform_device
*pdev)
if (ret)
goto probe_err2;
- for (i = 0; i vid_dev-num_displays; i++) {
- struct omap_dss_device *display = vid_dev-displays[i];
-
- if (display-driver-update)
- display-driver-update(display, 0, 0,
- display-panel.timings.x_res,
- display-panel.timings.y_res);
- }
return 0;
probe_err2:
--
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: [PATCH v2 5/6] OMAP: omap_device: Create a default omap_device_pm_latency
Hi Kevin,
On 9/2/2011 4:25 PM, Cousson, Benoit wrote:
Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will be used if
the device does not have an explicit one.
[...]
- od-pm_lats = pm_lats;
- od-pm_lats_cnt = pm_lats_cnt;
+ if (pm_lats) {
+ od-pm_lats = pm_lats;
+ od-pm_lats_cnt = pm_lats_cnt;
+ } else {
+ od-pm_lats = omap_default_latency;
+ od-pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
+ }
Here is the fix for that part. I did the easy version :-). Splitting the
structure in two parts will indeed require more work.
I updated the for_3.2/1_omap_device_cleanup branch.
Regards,
Benoit
---
From ad163000568dd61dee441473d0a576d84152da9e Mon Sep 17 00:00:00 2001
From: Benoit Cousson b-cous...@ti.com
Date: Tue, 9 Aug 2011 16:54:19 +0200
Subject: [PATCH v3 5/6] OMAP: omap_device: Create a default
omap_device_pm_latency
Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will be used if
the device does not have an explicit one.
Next patches will clean the duplicated structures.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/omap_device.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7b2cf62..54bbe7b 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -97,6 +97,14 @@
static int omap_device_register(struct platform_device *pdev);
static int omap_early_device_register(struct platform_device *pdev);
+static struct omap_device_pm_latency omap_default_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ }
+};
+
/* Private functions */
/**
@@ -510,8 +518,17 @@ struct platform_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
if (ret)
goto odbs_exit3;
- od-pm_lats = pm_lats;
+ if (!pm_lats) {
+ pm_lats = omap_default_latency;
+ pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
+ }
+
od-pm_lats_cnt = pm_lats_cnt;
+ od-pm_lats = kmemdup(pm_lats,
+ sizeof(struct omap_device_pm_latency) * pm_lats_cnt,
+ GFP_KERNEL);
+ if (!od-pm_lats)
+ goto odbs_exit3;
for (i = 0; i oh_cnt; i++) {
hwmods[i]-od = od;
--
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: [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
On Fri, Sep 16, 2011 at 1:30 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Fri, Sep 16, 2011 at 1:13 AM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [110915 10:49]: On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren t...@atomide.com wrote: Please also include the errata in the description and set it up with a Kconfig entry with something like ARM_ERRATA_XX or TI_ERRATA_XX. Sure. It's a TI ERRATA. OK Also it would be best to apply this fix at the end of the PM series so it is easier to verify the bug and potentially remove the hack if a better fix is ever available. As such order doesn't matter much because it can be removed either way even if it is in the beginning of the series with KCONFIG entry. But I can change the order if you prefer that way. Well it seems that it's the omap4_finish_suspend in this series that can be used to trigger the bug, although the bug has been around for few years. So then instead of mentioning random hangups you can have a better description with something like Patch xyz added PM idle support for omap4, however bug 123 causes so and so. Fix the issue with blah blah. Sounds good . Also, if you have some easy way to reproduce the bug maybe mention that too? That would make it easy to verify if issue has been fixed. Just for record, Below are the errata details. ERRATA: i688: Async Bridge Corruption If a data is stalled inside asynchronous bridge because of backpressure, it may be accepted multiple times, creating pointer misalignment that will corrupt next transfers on that data path until next reset of the system (No recovery procedure once the issue is hit, the path remains consistently broken). Async bridge can be found on path between MPU to EMIF, MPU to L3 interconnect and Cortex M3 to Emif . This situation can happen only when the idle is initiated by a Master Request Disconnection (which is trigged by software whenexecuting WFI) WORKAROUND All the initiators connected through Async Bridge must ensure that data path is properly drained before issuing WFI. This condition will be met if one Strongly ordered access is performed to the target right before executing the WFI. There are some multimedia usecases where the bug was discovered but on mainline obviously we don't have that support. I will check with IP folks if any other simple test-case is possible to reproduce the issue and If I find one, will mention that. We have a GFX usecase which demonstrate this issue but can't be tested on mainline sicne no GFX support. But the same patch is already in the product line which has fixed the GFX usecase issue. Regards Santosh -- 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: [PATCHv2 09/15] OMAP: DSS2: HDMI: implement detect()
Hi, On Thu, Sep 15, 2011 at 12:02 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2011-09-15 at 11:54 +0530, K, Mythri P wrote: Hi, On Thu, Sep 15, 2011 at 11:27 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2011-09-15 at 11:11 +0530, K, Mythri P wrote: Hi, On Wed, Sep 14, 2011 at 7:41 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Yes, you are right, detect() does not know if the monitor has changed between polls, so both notification and polling are needed. I implemented only polling as there's no HPD event mechanism yet in omapdss, and also because this was simple and gives DRM basic ability to detect a monitor. If it is needed for DRM then it is fine, but with detect renamed to poll. By next week i should have a patch ready for HPD event mechanism. What is wrong with detect? It detects if there's a display connected. It can be used in polling manner, trying it every n seconds, but it should also be used even if you use HPD event. I think the normal sequence would be something like: 1) register HPD event 2) use detect() to see if a monitor is already connected I guess polling ever few seconds to detect would be waste of CPU cycles when there is already a mechanism in the H/w to detect the connection. Obviously. Polling is only used if hot-plug-detect is not available. But detect function can be used even when HPD is available. Current sequence : Enable display ( Irrespective of whether the cable is connected on not) Sequence with HPD: 1.Register for HPD connect. 2.Enable display 3.Notify DRM/Audio/Kernel component that wants to listen to this event. Why would you enable the display even if there's no monitor connected? And when the DRM starts, how does DRM know if the display was already connected? Would you send a HPD event when DRM registers to the event even if there's no actual plug-in event done (i.e. user actually connecting the cable)? HPD event would be triggered only when the cable is connected , and the EDID is ready to be read by the monitor. So the question enabling display doesnt exist. When HDMI is enabled in the HPD mode it will be in minimal power mode. Yes then the driver will notify DRM/any module that cable(monitor) is now connected. And just to clarify, my sequence example was from DRM's point of view. The HDMI driver shouldn't do anything before DRM/omapfb asks it to do something. Tomi Thanks and regards, Mythri. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
Hi,
Sorry for the delayed response.
From: Laurent Pinchart [laurent.pinch...@ideasonboard.com]
Sent: Thursday, September 08, 2011 10:51 PM
To: Ravi, Deepthy
Cc: linux-me...@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk;
linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-ker...@vger.kernel.org; mche...@infradead.org; g.liakhovet...@gmx.de;
Hiremath, Vaibhav
Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
Hi,
Thanks for the patch.
On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
In order to support TVP5146 (for that matter any video decoder),
it is important to support G/S/ENUM_STD ioctl on /dev/videoX
device node.
Why so ? Shouldn't it be queried on the subdev output pad directly ?
[Deepthy Ravi] Because standard v4l2 application for analog devices will call
these std ioctls on the streaming device node. So it's done on /dev/video to
make the existing apllication work.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
drivers/media/video/omap3isp/ispvideo.c | 98
++- drivers/media/video/omap3isp/ispvideo.h |
1 +
2 files changed, 98 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index d5b8236..ff0ffed 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -37,6 +37,7 @@
#include plat/iovmm.h
#include plat/omap-pm.h
+#include media/tvp514x.h
#include ispvideo.h
#include isp.h
@@ -1136,7 +1137,97 @@ isp_video_g_input(struct file *file, void *fh,
unsigned int *input) static int
isp_video_s_input(struct file *file, void *fh, unsigned int input)
{
- return input == 0 ? 0 : -EINVAL;
+ struct isp_video *video = video_drvdata(file);
+ struct media_entity *entity = video-video.entity;
+ struct media_entity_graph graph;
+ struct v4l2_subdev *subdev;
+ struct v4l2_routing route;
+ int ret = 0;
+
+ media_entity_graph_walk_start(graph, entity);
+ while ((entity = media_entity_graph_walk_next(graph))) {
+ if (media_entity_type(entity) ==
+ MEDIA_ENT_T_V4L2_SUBDEV) {
+ subdev = media_entity_to_v4l2_subdev(entity);
+ if (subdev != NULL) {
+ if (input == 0)
+ route.input = INPUT_CVBS_VI4A;
+ else
+ route.input = INPUT_SVIDEO_VI2C_VI1C;
+ route.output = 0;
+ ret = v4l2_subdev_call(subdev, video,
s_routing,
+ route.input, route.output, 0);
+ if (ret 0 ret != -ENOIOCTLCMD)
+ return ret;
+ }
+ }
+ }
+
+ return 0;
+}
+
+static int isp_video_querystd(struct file *file, void *fh, v4l2_std_id *a)
+{
+ struct isp_video_fh *vfh = to_isp_video_fh(fh);
+ struct isp_video *video = video_drvdata(file);
+ struct media_entity *entity = video-video.entity;
+ struct media_entity_graph graph;
+ struct v4l2_subdev *subdev;
+ int ret = 0;
+
+ media_entity_graph_walk_start(graph, entity);
+ while ((entity = media_entity_graph_walk_next(graph))) {
+ if (media_entity_type(entity) ==
+ MEDIA_ENT_T_V4L2_SUBDEV) {
+ subdev = media_entity_to_v4l2_subdev(entity);
+ if (subdev != NULL) {
+ ret = v4l2_subdev_call(subdev, video, querystd,
+ a);
+ if (ret 0 ret != -ENOIOCTLCMD)
+ return ret;
+ }
+ }
+ }
+
+ vfh-standard.id = *a;
+ return 0;
+}
+
+static int isp_video_g_std(struct file *file, void *fh, v4l2_std_id *norm)
+{
+ struct isp_video_fh *vfh = to_isp_video_fh(fh);
+ struct isp_video *video = video_drvdata(file);
+
+ mutex_lock(video-mutex);
+ *norm = vfh-standard.id;
+ mutex_unlock(video-mutex);
+
+ return 0;
+}
+
+static int isp_video_s_std(struct file *file, void *fh, v4l2_std_id *norm)
+{
+ struct isp_video *video = video_drvdata(file);
+ struct media_entity *entity = video-video.entity;
+ struct media_entity_graph graph;
+ struct v4l2_subdev *subdev;
+ int ret = 0;
+
+ media_entity_graph_walk_start(graph, entity);
+ while ((entity = media_entity_graph_walk_next(graph))) {
+ if (media_entity_type(entity) ==
+ MEDIA_ENT_T_V4L2_SUBDEV) {
+
Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
Hi Deepthy, On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote: On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote: On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote: From: Vaibhav Hiremath hvaib...@ti.com In order to support TVP5146 (for that matter any video decoder), it is important to support G/S/ENUM_STD ioctl on /dev/videoX device node. Why so ? Shouldn't it be queried on the subdev output pad directly ? Because standard v4l2 application for analog devices will call these std ioctls on the streaming device node. So it's done on /dev/video to make the existing apllication work. Existing applications can't work with the OMAP3 ISP (and similar complex embedded devices) without userspace support anyway, either in the form of a GStreamer element or a libv4l plugin. I still believe that analog video standard operations should be added to the subdev pad operations and exposed through subdev device nodes, exactly as done with formats. -- Regards, Laurent Pinchart -- 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: Problems with 3.1.0-rc6 on at3517evm
I am owning a ZOOM am3517evm evaluation board, where I want to run the latest linux kernel (mainline). I am not able to boot this board. Are there any patches to fix this issues? The deliverd kernel (2.6.32-psp09.00.01.06.sdk) boots fine. You're not alone. This platform is not completely supported in the mainline kernel. Some important patches are still awaiting approval to be committed. Search this list for AM3517: Booting up: [PATCH v3 1/2] AM35x: Using OMAP3 generic hwmods [PATCH v3 2/2] omap_twl: Prevent SR to enable for am3517/am3505 devices Yegor -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/6] usb: musb: omap: Configure OTG_INTERFSEL for proper charger detection
Sergei,
Thanks for your comments.
On Fri, Sep 16, 2011 at 3:18 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 15-09-2011 18:19, Kishon Vijay Abraham I wrote:
Setting OTG_INTERFSEL to UTMI interferes with charger detection resulting
in incorrect detection of charger type. Hence OTG_INTERFSEL is configured
to
ULPI initially and changed to UTMI only after receiving USB_EVENT_ID or
USB_EVENT_VBUS notification.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Balaji T Kbalaj...@ti.com
AFAIK, full name is needed here.
is it not the prerogative of the person giving his signed-off by??
[sandesh.go...@ti.com: The interface selection has to be done before the
PHY
is activated and is not allowed to change when the PHY clock is already
running]
No signoff from him?
ok. will add his signoff.
---
drivers/usb/musb/omap2430.c | 50
+++---
1 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index fc9377c..724450b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -228,6 +228,7 @@ static inline void omap2430_low_level_init(struct musb
*musb)
static int musb_otg_notifications(struct notifier_block *nb,
unsigned long event, void *unused)
{
+ u32 val;
struct musb *musb = container_of(nb, struct musb, nb);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -240,11 +241,32 @@ static int musb_otg_notifications(struct
notifier_block *nb,
if (is_otg_enabled(musb)) {
if (musb-gadget_driver) {
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs,
OTG_INTERFSEL);
+ if (data-interface_type ==
+
MUSB_INTERFACE_UTMI) {
+ val= ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL,
val);
+
usb_phy_init(musb-xceiv);
omap2430_musb_set_vbus(musb, 1);
}
} else {
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ if (data-interface_type == MUSB_INTERFACE_UTMI) {
+ val= ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
usb_phy_init(musb-xceiv);
omap2430_musb_set_vbus(musb, 1);
}
@@ -255,6 +277,16 @@ static int musb_otg_notifications(struct
notifier_block *nb,
if (musb-gadget_driver)
pm_runtime_get_sync(musb-controller);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ if (data-interface_type == MUSB_INTERFACE_UTMI) {
+ val= ~ULPI_12PIN;
+ val |= UTMI_8BIT;
+ } else {
+ val |= ULPI_12PIN;
+ }
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
usb_phy_init(musb-xceiv);
break;
Why repeat the same sequence 3 times. Couldn't you factor it out into a
subroutine?
I thought it will be unnecessary to to add a subroutine just for a
single register modification.
Since you have pointed that out, I'll add a subroutine for it.
@@ -272,6 +304,11 @@ static int musb_otg_notifications(struct
notifier_block *nb,
otg_set_vbus(musb-xceiv-otg, 0);
}
usb_phy_shutdown(musb-xceiv);
+
+ val = musb_readl(musb-mregs, OTG_INTERFSEL);
+ val |= ULPI_12PIN;
+ musb_writel(musb-mregs, OTG_INTERFSEL, val);
+
break;
default:
dev_dbg(musb-controller, ID float\n);
@@ -304,16 +341,11 @@ static int omap2430_musb_init(struct musb *musb)
goto err1;
}
+ /* Set OTG_INTERFSEL to ULPI for correct charger detection.
+ * This should be later set to UTMI.
+ */
l = musb_readl(musb-mregs, OTG_INTERFSEL);
-
- if (data-interface_type == MUSB_INTERFACE_UTMI) {
- /* OMAP4 uses Internal PHY GS70 which uses UTMI interface
*/
- l= ~ULPI_12PIN; /* Disable ULPI */
- l |= UTMI_8BIT; /*
Re: [RFC PATCH 1/6] usb: musb: omap: Configure OTG_INTERFSEL for proper charger detection
On Fri, Sep 16, 2011 at 07:21:41PM +0530, ABRAHAM, KISHON VIJAY wrote: Sergei, Thanks for your comments. On Fri, Sep 16, 2011 at 3:18 PM, Sergei Shtylyov sshtyl...@mvista.com wrote: Hello. On 15-09-2011 18:19, Kishon Vijay Abraham I wrote: Setting OTG_INTERFSEL to UTMI interferes with charger detection resulting in incorrect detection of charger type. Hence OTG_INTERFSEL is configured to ULPI initially and changed to UTMI only after receiving USB_EVENT_ID or USB_EVENT_VBUS notification. Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com Signed-off-by: Balaji T Kbalaj...@ti.com AFAIK, full name is needed here. is it not the prerogative of the person giving his signed-off by?? Not really. [sandesh.go...@ti.com: The interface selection has to be done before the PHY is activated and is not allowed to change when the PHY clock is already running] No signoff from him? ok. will add his signoff. You can NOT add someone else's sign-off to a patch, please go re-read Documentation/SubmittingPatches as to what this really means. 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
[PATCH v2 0/2] OMAP: omap_device: Add a method to build an omap_device from a DT node
Hi Kevin, This is the updated version of the initial series that introduced a notifier in order to create an omap_device from a platform_device bound to DT node as suggested by Grant. For the moment, the informations are all extracted from the hwmod data. The idea is to focus first on the devices / board static init removal. The other issue is that some bindings, like dma, are still not present in the DT core code. The reg and irq bindings are there, but cannot be used by some drivers due to the lack of named resources in DT for the moment. We agreed with Grant about the strategy to introduce the name without breaking the compatibility and the default assumption about the order. I'll update that in another series after 3.2 and then these informations will be moved from hwmod to DT. Patches are based on my for_3.2/1_omap_device_cleanup branch and are available here: git://gitorious.org/omap-pm/linux.git for_3.2/2_omap_device_dt It is tested on OMAP4 SDP, Panda and Beagle-xM with and without CONFIG_OF. Regards, Benoit Changes since v1: http://www.spinics.net/lists/linux-omap/msg55814.html - delete omap_device structure during BUS_NOTIFY_DEL_DEVICE callback as suggested by Kevin - merge previous patches 23 as suggested by Kevin - delete pm_lats in omap_device_delete since this is now kmalloc-ed - use kmemdup instead of kzalloc + memcopy for hmwods creation - Fix the wrong usage of of_*.h includes to build properly without CONFIG_OF. Benoit Cousson (2): OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration OMAP: omap_device: Add a method to build an omap_device from a DT node arch/arm/plat-omap/omap_device.c | 321 +++--- 1 files changed, 263 insertions(+), 58 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 v2 1/2] OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration
Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already allocated by
device-tree.
The functionality of the omap_device_build_ss is still the same, but
the omap_device_alloc will be usable with devices already built by
device-tree.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/omap_device.c | 177 +
1 files changed, 119 insertions(+), 58 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 54bbe7b..cac7b9a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -96,6 +96,11 @@
static int omap_device_register(struct platform_device *pdev);
static int omap_early_device_register(struct platform_device *pdev);
+static struct omap_device *omap_device_alloc(struct platform_device *pdev,
+ struct omap_hwmod **ohs, int oh_cnt,
+ struct omap_device_pm_latency *pm_lats,
+ int pm_lats_cnt);
+
static struct omap_device_pm_latency omap_default_latency[] = {
{
@@ -397,6 +402,110 @@ static int omap_device_fill_resources(struct omap_device
*od,
}
/**
+ * omap_device_alloc - allocate an omap_device
+ * @pdev: platform_device that will be included in this omap_device
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ *
+ * Convenience function for allocating an omap_device structure and filling
+ * hwmods, resources and pm_latency attributes.
+ *
+ * Returns an struct omap_device pointer or ERR_PTR() on error;
+ */
+static struct omap_device *omap_device_alloc(struct platform_device *pdev,
+ struct omap_hwmod **ohs, int oh_cnt,
+ struct omap_device_pm_latency *pm_lats,
+ int pm_lats_cnt)
+{
+ int ret = -ENOMEM;
+ struct omap_device *od;
+ struct resource *res = NULL;
+ int i, res_count;
+ struct omap_hwmod **hwmods;
+
+ od = kzalloc(sizeof(struct omap_device), GFP_KERNEL);
+ if (!od) {
+ ret = -ENOMEM;
+ goto oda_exit1;
+ }
+ od-hwmods_cnt = oh_cnt;
+
+ hwmods = kmemdup(ohs, sizeof(struct omap_hwmod *) * oh_cnt, GFP_KERNEL);
+ if (!hwmods)
+ goto oda_exit2;
+
+ od-hwmods = hwmods;
+ od-pdev = pdev;
+
+ /*
+* HACK: Ideally the resources from DT should match, and hwmod
+* should just add the missing ones. Since the name is not
+* properly populated by DT, stick to hwmod resources only.
+*/
+ if (pdev-num_resources pdev-resource)
+ dev_warn(pdev-dev, %s(): resources already allocated %d\n,
+ __func__, pdev-num_resources);
+
+ res_count = omap_device_count_resources(od);
+ if (res_count 0) {
+ dev_dbg(pdev-dev, %s(): resources allocated from hwmod %d\n,
+ __func__, res_count);
+ res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
+ if (!res)
+ goto oda_exit3;
+
+ omap_device_fill_resources(od, res);
+
+ ret = platform_device_add_resources(pdev, res, res_count);
+ kfree(res);
+
+ if (ret)
+ goto oda_exit3;
+ }
+
+ if (!pm_lats) {
+ pm_lats = omap_default_latency;
+ pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
+ }
+
+ od-pm_lats_cnt = pm_lats_cnt;
+ od-pm_lats = kmemdup(pm_lats,
+ sizeof(struct omap_device_pm_latency) * pm_lats_cnt,
+ GFP_KERNEL);
+ if (!od-pm_lats)
+ goto oda_exit3;
+
+ pdev-archdata.od = od;
+
+ for (i = 0; i oh_cnt; i++) {
+ hwmods[i]-od = od;
+ _add_hwmod_clocks_clkdev(od, hwmods[i]);
+ }
+
+ return od;
+
+oda_exit3:
+ kfree(hwmods);
+oda_exit2:
+ kfree(od);
+oda_exit1:
+ dev_err(pdev-dev, omap_device: build failed (%d)\n, ret);
+
+ return ERR_PTR(ret);
+}
+
+static void omap_device_delete(struct omap_device *od)
+{
+ od-pdev-archdata.od = NULL;
+ kfree(od-pm_lats);
+ kfree(od-hwmods);
+ kfree(od);
+}
+
+/**
* omap_device_build - build and register an omap_device with one omap_hwmod
* @pdev_name: name of the platform_device driver to use
* @pdev_id: this platform_device's connection ID
@@ -455,9 +564,6 @@ struct platform_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
[PATCH v2 2/2] OMAP: omap_device: Add a method to build an omap_device from a DT node
Add a notifier called during device_add phase. If an of_node is present,
retrieve the hwmod entry in order to populate properly the omap_device
structure.
For the moment the resource from the device-tree are overloaded.
DT does not support named resource yet, and thus, most driver
will not work without that information.
Add two helpers function to parse a property that contains multiple
strings.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/omap_device.c | 144 ++
1 files changed, 144 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index cac7b9a..da13630 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -85,6 +85,8 @@
#include linux/clk.h
#include linux/clkdev.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/notifier.h
#include plat/omap_device.h
#include plat/omap_hwmod.h
@@ -94,12 +96,15 @@
#define USE_WAKEUP_LAT 0
#define IGNORE_WAKEUP_LAT 1
+#define MAX_HWMOD_NAME_SIZE32
+
static int omap_device_register(struct platform_device *pdev);
static int omap_early_device_register(struct platform_device *pdev);
static struct omap_device *omap_device_alloc(struct platform_device *pdev,
struct omap_hwmod **ohs, int oh_cnt,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt);
+static void omap_device_delete(struct omap_device *od);
static struct omap_device_pm_latency omap_default_latency[] = {
@@ -315,6 +320,138 @@ static void _add_hwmod_clocks_clkdev(struct omap_device
*od,
_add_clkdev(od, oh-opt_clks[i].role, oh-opt_clks[i].clk);
}
+/*
+ * XXX: DT helper functions that should probably move elsewhere if
+ * they become usefull for other needs.
+ */
+static int _dt_count_property_string(const char *prop, int len)
+{
+ int i = 0;
+ size_t l = 0, total = 0;
+
+ if (!prop || !len)
+ return -EINVAL;
+
+ for (i = 0; len = total; total += l, prop += l) {
+ l = strlen(prop) + 1;
+ if (*prop != 0)
+ i++;
+ }
+ return i;
+}
+
+static int _dt_get_property(const char *prop, int len, int index, char *output,
+ int size)
+{
+ int i = 0;
+ size_t l = 0, total = 0;
+
+ if (!prop || !len)
+ return -EINVAL;
+
+ for (i = 0; len = total; total += l, prop += l) {
+ l = strlcpy(output, prop, size) + 1;
+ if (*prop != 0) {
+ if (i++ == index)
+ return 0;
+ }
+ }
+ return -ENODEV;
+}
+
+static struct dev_pm_domain omap_device_pm_domain;
+
+/**
+ * omap_device_build_from_dt - build an omap_device with multiple hwmods
+ * @pdev_name: name of the platform_device driver to use
+ * @pdev_id: this platform_device's connection ID
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Function for building an omap_device already registered from device-tree
+ *
+ * Returns 0 or PTR_ERR() on error.
+ */
+static int omap_device_build_from_dt(struct platform_device *pdev)
+{
+ struct omap_hwmod **hwmods;
+ struct omap_device *od;
+ struct omap_hwmod *oh;
+ char oh_name[MAX_HWMOD_NAME_SIZE];
+ const char *prop;
+ int oh_cnt, i, prop_len;
+ int ret = 0;
+
+ prop = of_get_property(pdev-dev.of_node, hwmods, prop_len);
+ oh_cnt = _dt_count_property_string(prop, prop_len);
+ if (!oh_cnt || IS_ERR_VALUE(oh_cnt)) {
+ dev_warn(pdev-dev, No 'hwmods' to build omap_device\n);
+ return -ENODEV;
+ }
+
+ hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt, GFP_KERNEL);
+ if (!hwmods) {
+ ret = -ENOMEM;
+ goto odbfd_exit;
+ }
+
+ for (i = 0; i oh_cnt; i++) {
+ _dt_get_property(prop, prop_len, i, oh_name,
+MAX_HWMOD_NAME_SIZE);
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ dev_err(pdev-dev, Cannot lookup hwmod '%s'\n,
+ oh_name);
+ ret = -EINVAL;
+ goto odbfd_exit1;
+ }
+ hwmods[i] = oh;
+ }
+
+ od = omap_device_alloc(pdev, hwmods, oh_cnt, NULL, 0);
+ if (!od) {
+ dev_err(pdev-dev,
Re: [PATCH 1/8] OMAP: convert I2C driver to PM QoS for latency constraints
Kevin, On Fri, Sep 16, 2011 at 12:46 AM, Kevin Hilman khil...@ti.com wrote: Hi Jean, Jean Pihet jean.pi...@newoldbits.com writes: Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat API to the new PM QoS API. Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY class of PM QoS. The resulting MPU constraints are used by cpuidle to decide the next power state of the MPU subsystem. Currently only OMAP3 is placing constraints on the MPU. Signed-off-by: Jean Pihet j-pi...@ti.com [...] @@ -648,8 +648,16 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) if (r 0) goto out; - if (dev-set_mpu_wkup_lat != NULL) - dev-set_mpu_wkup_lat(dev-dev, dev-latency); + /* + * When waiting for completion of a i2c transfer, we need to + * set a wake up latency constraint for the MPU. This is to + * ensure quick enough wakeup from idle, when transfer + * completes. + * Used on OMAP3 Only + */ + if (cpu_is_omap34xx()) We don't want any cpu_is_* checking in drivers. If this is only done on certain SoCs, then a flag should be passed from device init code via pdata. That being said, I don't see why this shouldn't be set for all SoCs since it's using the FIFO size to determine the latency. I am OK to have the constraints active for all OMAPs. Side question: what if different SOCs need different values for the constraint? Kevin Regards, Jean -- 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 1/8] OMAP: hwmod: Fix the addr spaces, irq, dma count APIs.
Hi Sricharan,
On 9/9/2011 6:02 PM, R, Sricharan wrote:
The address spaces, irqs and dma reqs count API returns the
number of corresponding entries in a hwmod including a additional
null value or a -1 terminator in the structure introduced
recently. More information here:
212738a4 (omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs
arrays)
78183f3f (omap_hwmod: use a null structure record to terminate
omap_hwmod_addr_space arrays)
bc614958 (omap_hwmod: use a terminator record with omap_hwmod_dma_info
arrays)
The devices which have multiple hwmods and use device_build_ss are
broken with this, as their resources are populated with a
extra null value, subsequently the probe fails. So fix the API not to
include the array terminator in the count.
Signed-off-by: sricharanr.sricha...@ti.com
Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@ti.com
It would have been nice to give me the credit for the bug report on the
other functions, but otherwise:
Acked-by: Benoit Cousson b-cous...@ti.com
And I still prefer the return i - 1 :-)
---
[v1]
Initial version.
[v2]
1) Added the correction for irq and dma counts along with
addr spaces.
2) Changed the commit log.
arch/arm/mach-omap2/omap_hwmod.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..c69fbc2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -745,9 +745,9 @@ static int _count_mpu_irqs(struct omap_hwmod *oh)
if (!oh || !oh-mpu_irqs)
return 0;
- do {
- ohii =oh-mpu_irqs[i++];
- } while (ohii-irq != -1);
+ ohii =oh-mpu_irqs[i];
+ while (ohii-irq != -1)
+ ohii =oh-mpu_irqs[++i];
return i;
}
@@ -768,9 +768,9 @@ static int _count_sdma_reqs(struct omap_hwmod *oh)
if (!oh || !oh-sdma_reqs)
return 0;
- do {
- ohdi =oh-sdma_reqs[i++];
- } while (ohdi-dma_req != -1);
+ ohdi =oh-sdma_reqs[i];
+ while (ohdi-dma_req != -1)
+ ohdi =oh-sdma_reqs[++i];
return i;
}
@@ -791,9 +791,9 @@ static int _count_ocp_if_addr_spaces(struct
omap_hwmod_ocp_if *os)
if (!os || !os-addr)
return 0;
- do {
- mem =os-addr[i++];
- } while (mem-pa_start != mem-pa_end);
+ mem =os-addr[i];
+ while (mem-pa_start != mem-pa_end)
+ mem =os-addr[++i];
return i;
}
--
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 6/8] OMAP: PM CONSTRAINTS: implement the devices wake-up latency constraints
Kevin, On Fri, Sep 16, 2011 at 1:47 AM, Kevin Hilman khil...@ti.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: Implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer by calling the corresponding function at hwmod level. Note: the bus throughput function is implemented but currently is a no-op. A new PM QoS class for the bus throughput needs to be added. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com This patch does 2 things. 1) removes the MPU lat stuff from the OMAP PM layer (since it's now available in a generic form 2) implements device wake-up latency constraints This should be broken up into two parts. Also, this patch seems to remove a bunch of stuff that was just added in patch 2/8. Probably best to create the new OMAP PM layer after remving the unused stuff. It think the code using the new per-device PM QoS API should also live outside the OMAP PM layer, since it's not related, and we want to get rid of the OMAP PM layer eventually. Speaking of which..., the more I think about it, the more I think we should take this opportunity to clean and/or remove the OMAP PM layer completely. I agree completely, the OMAP PM 'plugin' layer is useless and anyway an empty implementation for now. With your work, other than the no-op bus throughput API, it's basically unused. I think that rather than creating a new OMAP PM layer just to have a a no-op bus throughput function here, I think it's time to remove OMAP PM completely. Ok. The only useful code is to register a PM QoS notifier in order to apply the constraints to the power domains. Are you suggesting to move this code to e.g. pmxxx.c? This might also give some incentive for a PM QoS bus throughput constraint as well. Sure the tput constraints should be implemented as well. Of course, Paul can make the final decision there whether to remove it now, but I think it's time. Just to prove it's usefulness (or lack thereof), Here's a hack that combined with your patch 1/8 shows that it is pretty easy to remove. Kevin Thanks! Jean -- 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 6/8] OMAP: PM CONSTRAINTS: implement the devices wake-up latency constraints
Jean Pihet jean.pi...@newoldbits.com writes: Kevin, On Fri, Sep 16, 2011 at 1:47 AM, Kevin Hilman khil...@ti.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: Implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer by calling the corresponding function at hwmod level. Note: the bus throughput function is implemented but currently is a no-op. A new PM QoS class for the bus throughput needs to be added. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com This patch does 2 things. 1) removes the MPU lat stuff from the OMAP PM layer (since it's now available in a generic form 2) implements device wake-up latency constraints This should be broken up into two parts. Also, this patch seems to remove a bunch of stuff that was just added in patch 2/8. Probably best to create the new OMAP PM layer after remving the unused stuff. It think the code using the new per-device PM QoS API should also live outside the OMAP PM layer, since it's not related, and we want to get rid of the OMAP PM layer eventually. Speaking of which..., the more I think about it, the more I think we should take this opportunity to clean and/or remove the OMAP PM layer completely. I agree completely, the OMAP PM 'plugin' layer is useless and anyway an empty implementation for now. Great, let's wait for Paul's view on this since he's the maintainer of the OMAP PM layer. With your work, other than the no-op bus throughput API, it's basically unused. I think that rather than creating a new OMAP PM layer just to have a a no-op bus throughput function here, I think it's time to remove OMAP PM completely. Ok. The only useful code is to register a PM QoS notifier in order to apply the constraints to the power domains. Are you suggesting to move this code to e.g. pmxxx.c? Yes, or simply pm-constraints.c since I guess it should be SoC-independent. 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
[PATCHv8 07/16] OMAP2+: mux: add support for PAD wakeup interrupts
OMAP mux now provides a service routine to parse pending wakeup events
and to call registered ISR whenever active wakeups are detected. This
routine is called directly from PRCM interrupt handler.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 50ee806..9127273 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -32,6 +32,9 @@
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/uaccess.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/power/omap_prm.h
#include asm/system.h
@@ -381,6 +384,33 @@ bool omap_hwmod_mux_get_wake_status(struct
omap_hwmod_mux_info *hmux)
return ret;
}
+/**
+ * omap_hwmod_mux_handle_irq - Process wakeup events for a single hwmod
+ *
+ * Checks a single hwmod for every wakeup capable pad to see if there is an
+ * active wakeup event. If this is the case, call the corresponding ISR.
+ */
+static int _omap_hwmod_mux_handle_irq(struct omap_hwmod *oh, void *data)
+{
+ if (!oh-mux || !oh-mux-enabled)
+ return 0;
+ if (omap_hwmod_mux_get_wake_status(oh-mux))
+ generic_handle_irq(oh-mpu_irqs[0].irq);
+ return 0;
+}
+
+/**
+ * omap_hwmod_mux_handle_irq - Process pad wakeup irqs.
+ *
+ * Calls a function for each registered omap_hwmod to check
+ * pad wakeup statuses.
+ */
+static irqreturn_t omap_hwmod_mux_handle_irq(int irq, void *unused)
+{
+ omap_hwmod_for_each(_omap_hwmod_mux_handle_irq, NULL);
+ return IRQ_HANDLED;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
@@ -745,6 +775,7 @@ static void __init omap_mux_free_names(struct omap_mux *m)
static int __init omap_mux_late_init(void)
{
struct omap_mux_partition *partition;
+ int ret;
list_for_each_entry(partition, mux_partitions, node) {
struct omap_mux_entry *e, *tmp;
@@ -765,6 +796,13 @@ static int __init omap_mux_late_init(void)
}
}
+ ret = request_irq(omap_prcm_event_to_irq(io),
+ omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
+ hwmod_io, omap_mux_late_init);
+
+ if (ret)
+ printk(KERN_WARNING Failed to setup hwmod io irq %d\n, ret);
+
omap_mux_dbg_init();
return 0;
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8 08/16] omap3: pm: use prcm chain handler
PM interrupt handling is now done through the PRCM chain handler. The
interrupt handling logic is also split in two parts, to server IO and
WKUP events separately. This allows us to handle IO chain events in a
clean way.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 104 +++---
1 files changed, 37 insertions(+), 67 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..2789e0a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -29,6 +29,7 @@
#include linux/delay.h
#include linux/slab.h
#include linux/console.h
+#include linux/power/omap_prm.h
#include trace/events/power.h
#include asm/suspend.h
@@ -198,7 +199,7 @@ static void omap3_save_secure_ram_context(void)
* that any peripheral wake-up events occurring while attempting to
* clear the PM_WKST_x are detected and cleared.
*/
-static int prcm_clear_mod_irqs(s16 module, u8 regs)
+static int prcm_clear_mod_irqs(s16 module, u8 regs, u32 ignore_bits)
{
u32 wkst, fclk, iclk, clken;
u16 wkst_off = (regs == 3) ? OMAP3430ES2_PM_WKST3 : PM_WKST1;
@@ -210,6 +211,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = omap2_prm_read_mod_reg(module, grpsel_off);
+ wkst = ~ignore_bits;
if (wkst) {
iclk = omap2_cm_read_mod_reg(module, iclk_off);
fclk = omap2_cm_read_mod_reg(module, fclk_off);
@@ -225,6 +227,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
omap2_cm_set_mod_reg_bits(clken, module, fclk_off);
omap2_prm_write_mod_reg(wkst, module, wkst_off);
wkst = omap2_prm_read_mod_reg(module, wkst_off);
+ wkst = ~ignore_bits;
c++;
}
omap2_cm_write_mod_reg(iclk, module, iclk_off);
@@ -234,76 +237,35 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
return c;
}
-static int _prcm_int_handle_wakeup(void)
+static irqreturn_t _prcm_int_handle_io(int irq, void *unused)
{
int c;
- c = prcm_clear_mod_irqs(WKUP_MOD, 1);
- c += prcm_clear_mod_irqs(CORE_MOD, 1);
- c += prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
- if (omap_rev() OMAP3430_REV_ES1_0) {
- c += prcm_clear_mod_irqs(CORE_MOD, 3);
- c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
- }
+ c = prcm_clear_mod_irqs(WKUP_MOD, 1,
+ ~(OMAP3430_ST_IO_MASK | OMAP3430_ST_IO_CHAIN_MASK));
- return c;
+ return c ? IRQ_HANDLED : IRQ_NONE;
}
-/*
- * PRCM Interrupt Handler
- *
- * The PRM_IRQSTATUS_MPU register indicates if there are any pending
- * interrupts from the PRCM for the MPU. These bits must be cleared in
- * order to clear the PRCM interrupt. The PRCM interrupt handler is
- * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear
- * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU
- * register indicates that a wake-up event is pending for the MPU and
- * this bit can only be cleared if the all the wake-up events latched
- * in the various PM_WKST_x registers have been cleared. The interrupt
- * handler is implemented using a do-while loop so that if a wake-up
- * event occurred during the processing of the prcm interrupt handler
- * (setting a bit in the corresponding PM_WKST_x register and thus
- * preventing us from clearing bit 0 of the PRM_IRQSTATUS_MPU register)
- * this would be handled.
- */
-static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
+static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
{
- u32 irqenable_mpu, irqstatus_mpu;
- int c = 0;
-
- irqenable_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQENABLE_MPU_OFFSET);
- irqstatus_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
- irqstatus_mpu = irqenable_mpu;
-
- do {
- if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK |
-OMAP3430_IO_ST_MASK)) {
- c = _prcm_int_handle_wakeup();
-
- /*
-* Is the MPU PRCM interrupt handler racing with the
-* IVA2 PRCM interrupt handler ?
-*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
-but no wakeup sources are marked\n);
- } else {
- /* XXX we need to expand our PRCM interrupt handler */
- WARN(1, prcm: WARNING: PRCM interrupt received, but
-no code to handle it (%08x)\n, irqstatus_mpu);
- }
-
-
[PATCHv8 09/16] TEMP: serial: added mux support
Just for PRCM chain handler testing purposes. This should be replaced with
a proper implementation.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/serial.c | 71 -
1 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3d1c1d3..e08feb1 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -862,17 +862,84 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
* can call this function when they want to have default behaviour
* for serial ports (e.g initialize them all as serial ports).
*/
+
+struct serial_mux_conf {
+ char *name;
+ int omap3_mux;
+ int omap4_mux;
+};
+
+#define OMAP3_SERIAL_MUX_IN_PU (OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_IN_PD (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_IN (OMAP_PIN_INPUT | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_OUT (OMAP_PIN_OUTPUT | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_IN_PU (OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_OUT (OMAP_PIN_OUTPUT | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_IN (OMAP_PIN_INPUT | OMAP_MUX_MODE0)
+#define SERIAL_DISABLED OMAP_MUX_MODE7
+
+#define OMAP_SERIAL_NUM_PADS_PER_PORT 4
+
+static const struct serial_mux_conf serial_mux_data[] = {
+ { uart1_cts.uart1_cts, OMAP3_SERIAL_MUX_IN, SERIAL_DISABLED, },
+ { uart1_rts.uart1_rts, OMAP3_SERIAL_MUX_OUT, SERIAL_DISABLED, },
+ { uart1_rx.uart1_rx, OMAP3_SERIAL_MUX_IN, SERIAL_DISABLED, },
+ { uart1_tx.uart1_tx, OMAP3_SERIAL_MUX_OUT, SERIAL_DISABLED, },
+ { uart2_cts.uart2_cts, OMAP3_SERIAL_MUX_IN,
+ OMAP4_SERIAL_MUX_IN_PU, },
+ { uart2_rts.uart2_rts, OMAP3_SERIAL_MUX_OUT, OMAP4_SERIAL_MUX_OUT, },
+ { uart2_rx.uart2_rx, OMAP3_SERIAL_MUX_IN, OMAP4_SERIAL_MUX_IN_PU, },
+ { uart2_tx.uart2_tx, OMAP3_SERIAL_MUX_OUT, OMAP4_SERIAL_MUX_OUT },
+ { uart3_cts_rctx.uart3_cts_rctx, OMAP3_SERIAL_MUX_IN_PD,
+ OMAP4_SERIAL_MUX_IN_PU, },
+ { uart3_rts_sd.uart3_rts_sd, OMAP3_SERIAL_MUX_OUT,
+ OMAP4_SERIAL_MUX_OUT, },
+ { uart3_rx_irrx.uart3_rx_irrx, OMAP3_SERIAL_MUX_IN,
+ OMAP4_SERIAL_MUX_IN, },
+ { uart3_tx_irtx.uart3_tx_irtx, OMAP3_SERIAL_MUX_OUT,
+ OMAP4_SERIAL_MUX_OUT, },
+ { uart4_rx.uart4_rx, SERIAL_DISABLED, OMAP4_SERIAL_MUX_IN, },
+ { uart4_tx.uart4_tx, SERIAL_DISABLED, OMAP4_SERIAL_MUX_OUT, },
+ { NULL, SERIAL_DISABLED, SERIAL_DISABLED, },
+ { NULL, SERIAL_DISABLED, SERIAL_DISABLED, },
+};
+
void __init omap_serial_init(void)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
+ struct omap_device_pad *pads;
+ int idx;
+ int i;
+ pads = kmalloc(sizeof(struct omap_device_pad) * 4, GFP_KERNEL);
list_for_each_entry(uart, uart_list, node) {
bdata.id = uart-num;
bdata.flags = 0;
- bdata.pads = NULL;
bdata.pads_cnt = 0;
+ bdata.pads = pads;
+
+ for (i = 0; i OMAP_SERIAL_NUM_PADS_PER_PORT; i++) {
+ idx = bdata.id * OMAP_SERIAL_NUM_PADS_PER_PORT + i;
+ pads[i].name = serial_mux_data[idx].name;
+ pads[i].enable = 0;
+ pads[i].idle = 0;
+ pads[i].flags = 0;
+ if (cpu_is_omap34xx())
+ pads[i].enable = serial_mux_data[idx].omap3_mux;
+ if (cpu_is_omap44xx())
+ pads[i].enable = serial_mux_data[idx].omap4_mux;
+ if (pads[i].enable != SERIAL_DISABLED)
+ bdata.pads_cnt++;
+ if (pads[i].enable OMAP_PIN_INPUT) {
+ pads[i].flags = OMAP_DEVICE_PAD_REMUX |
+ OMAP_DEVICE_PAD_WAKEUP;
+ }
+ pads[i].idle = pads[i].enable;
+ }
+ if (bdata.pads_cnt == 0)
+ bdata.pads = NULL;
omap_serial_init_port(bdata);
-
}
+ kfree(pads);
}
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8 12/16] TEMP: OMAP3: pm: remove serial resume / idle calls from idle path
This is no longer needed as it will be handled within serial driver itself.
This part should be properly handled with serial runtime support.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 19 ---
1 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2789e0a..4571993 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -341,18 +341,9 @@ void omap_sram_idle(void)
omap3_enable_io_chain();
}
- /* Block console output in case it is on one of the OMAP UARTs */
- if (!is_suspending())
- if (per_next_state PWRDM_POWER_ON ||
- core_next_state PWRDM_POWER_ON)
- if (!console_trylock())
- goto console_still_active;
-
/* PER */
if (per_next_state PWRDM_POWER_ON) {
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
- omap_uart_prepare_idle(2);
- omap_uart_prepare_idle(3);
omap2_gpio_prepare_for_idle(per_going_off);
if (per_next_state == PWRDM_POWER_OFF)
omap3_per_save_context();
@@ -360,8 +351,6 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
- omap_uart_prepare_idle(0);
- omap_uart_prepare_idle(1);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
@@ -408,8 +397,6 @@ void omap_sram_idle(void)
omap3_sram_restore_context();
omap2_sms_restore_context();
}
- omap_uart_resume_idle(0);
- omap_uart_resume_idle(1);
if (core_next_state == PWRDM_POWER_OFF)
omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK,
OMAP3430_GR_MOD,
@@ -423,14 +410,8 @@ void omap_sram_idle(void)
omap2_gpio_resume_after_idle();
if (per_prev_state == PWRDM_POWER_OFF)
omap3_per_restore_context();
- omap_uart_resume_idle(2);
- omap_uart_resume_idle(3);
}
- if (!is_suspending())
- console_unlock();
-
-console_still_active:
/* Disable IO-PAD and IO-CHAIN wakeup */
if (omap3_has_io_wakeup()
(per_next_state PWRDM_POWER_ON ||
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8] 00/16] OMAP PRCM chain handler driver
Hello, This patch set is the version 8 for the OMAP PRCM chain interrupt handler. The driver is providing a chain handler for PRCM interrupt events, which can be then individually used by different drivers. Currently PRCM interrupt is owned by the PM core code and it is impossible for other users to listen to any of the PRCM events. Quite a few of the patches in this set are tagged as TEMP, they are not meant for integration at this point, but are provided as FYI for educated users and as a means to test the driver out. Changes compared to the previous set: - PRCM chain handler is now a driver of its own - The driver gets PRCM IP info from omap hwmod and configures itself based on this - Added temporary implementations for OMAP3 and OMAP4 PRM hwmods Applies on top of Kevin's PM branch. Testing done: - platforms used: omap3 beagleboard and omap4430 blaze - suspend / resume test with retention : ok on both - cpuidle with retention test : ok on both - off-mode testing : ok on omap3 (omap4 does not support off-mode yet) OMAP4 testing was done on top of a custom kernel tree, this patch set does not work directly for omap4 on mainline. -Tero Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- 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
[PATCHv8 13/16] TEMP: OMAP3: serial: made serial to work properly with PRCM chain handler
This patch is just a temporary hack to allow serial to work properly with
the PRCM chain handler. Should be replaced with a proper implementation
by serial runtime PM support.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 29 +
drivers/tty/serial/omap-serial.c |8
2 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index e08feb1..0cc5434 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -39,6 +39,7 @@
#include plat/dma.h
#include plat/omap_hwmod.h
#include plat/omap_device.h
+#include plat/prcm.h
#include prm2xxx_3xxx.h
#include pm.h
@@ -380,6 +381,7 @@ static void omap_uart_allow_sleep(struct omap_uart_state
*uart)
omap_uart_smart_idle_enable(uart, 1);
uart-can_sleep = 1;
del_timer(uart-timer);
+ omap_uart_disable_clocks(uart);
}
static void omap_uart_idle_timer(unsigned long data)
@@ -391,36 +393,23 @@ static void omap_uart_idle_timer(unsigned long data)
void omap_uart_prepare_idle(int num)
{
- struct omap_uart_state *uart;
-
- list_for_each_entry(uart, uart_list, node) {
- if (num == uart-num uart-can_sleep) {
- omap_uart_disable_clocks(uart);
- return;
- }
- }
}
void omap_uart_resume_idle(int num)
{
struct omap_uart_state *uart;
+ u32 wkst;
list_for_each_entry(uart, uart_list, node) {
if (num == uart-num uart-can_sleep) {
- omap_uart_enable_clocks(uart);
+ omap_uart_block_sleep(uart);
- /* Check for IO pad wakeup */
- if (cpu_is_omap34xx() uart-padconf) {
- u16 p = omap_ctrl_readw(uart-padconf);
-
- if (p OMAP3_PADCONF_WAKEUPEVENT0)
- omap_uart_block_sleep(uart);
+ /* Check for normal UART wakeup (and clear it) */
+ if (uart-wk_st uart-wk_mask) {
+ wkst = __raw_readl(uart-wk_st) uart-wk_mask;
+ if (wkst)
+ __raw_writel(wkst, uart-wk_st);
}
-
- /* Check for normal UART wakeup */
- if (__raw_readl(uart-wk_st) uart-wk_mask)
- omap_uart_block_sleep(uart);
- return;
}
}
}
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c37df8d..cfff8ac 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -261,6 +261,8 @@ static void serial_omap_start_tx(struct uart_port *port)
unsigned int start;
int ret = 0;
+ omap_uart_resume_idle(up-pdev-id);
+
if (!up-use_dma) {
serial_omap_enable_ier_thri(up);
return;
@@ -354,6 +356,8 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
unsigned int iir, lsr;
unsigned long flags;
+ omap_uart_resume_idle(up-pdev-id);
+
iir = serial_in(up, UART_IIR);
if (iir UART_IIR_NO_INT)
return IRQ_NONE;
@@ -641,6 +645,8 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
unsigned long flags = 0;
unsigned int baud, quot;
+ omap_uart_resume_idle(up-pdev-id);
+
switch (termios-c_cflag CSIZE) {
case CS5:
cval = UART_LCR_WLEN5;
@@ -947,6 +953,8 @@ serial_omap_console_write(struct console *co, const char *s,
unsigned int ier;
int locked = 1;
+ omap_uart_resume_idle(up-pdev-id);
+
local_irq_save(flags);
if (up-port.sysrq)
locked = 0;
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8 02/16] OMAP2+: hwmod: Add API to enable IO ring wakeup.
From: R, Govindraj govindraj.r...@ti.com
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
during hwmod idle transition based on whether wakeup_flag is
set or cleared.
Map the enable/disable pad wakeup API's to hwmod_wakeup_enable/disable.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 59 ++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..e751dd9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2062,6 +2062,34 @@ static int __init omap_hwmod_setup_all(void)
core_initcall(omap_hwmod_setup_all);
/**
+ * omap_hwmod_set_ioring_wakeup - enable io pad wakeup flag.
+ * @oh: struct omap_hwmod *
+ * @set: bool value indicating to set or clear wakeup status.
+ *
+ * Set or Clear wakeup flag for the io_pad.
+ */
+static int omap_hwmod_set_ioring_wakeup(struct omap_hwmod *oh, bool set_wake)
+{
+ struct omap_device_pad *pad;
+ int ret = -EINVAL, j;
+
+ if (oh-mux oh-mux-enabled) {
+ for (j = 0; j oh-mux-nr_pads_dynamic; j++) {
+ pad = oh-mux-pads_dynamic[j];
+ if (pad-flags OMAP_DEVICE_PAD_WAKEUP) {
+ if (set_wake)
+ pad-idle |= OMAP_WAKEUP_EN;
+ else
+ pad-idle = ~OMAP_WAKEUP_EN;
+ ret = 0;
+ }
+ }
+ }
+
+ return ret;
+}
+
+/**
* omap_hwmod_enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -2393,6 +2421,35 @@ int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
{
return _del_initiator_dep(oh, init_oh);
}
+/**
+ * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * set wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh)
+{
+ /* Enable pad wake-up capability */
+ return omap_hwmod_set_ioring_wakeup(oh, true);
+}
+
+/**
+ * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * clear wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh)
+{
+ /* Disable pad wakeup capability */
+ return omap_hwmod_set_ioring_wakeup(oh, false);
+}
/**
* omap_hwmod_enable_wakeup - allow device to wake up the system
@@ -2419,6 +2476,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_enable_wakeup(oh, v);
_write_sysconfig(v, oh);
+ omap_hwmod_enable_ioring_wakeup(oh);
spin_unlock_irqrestore(oh-_lock, flags);
return 0;
@@ -2449,6 +2507,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_disable_wakeup(oh, v);
_write_sysconfig(v, oh);
+ omap_hwmod_disable_ioring_wakeup(oh);
spin_unlock_irqrestore(oh-_lock, flags);
return 0;
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8 14/16] TEMP: OMAP: serial: remove padconf hacks
These are no longer needed as omap_hwmod takes care of multiplexing of pads.
Should be handled properly with serial runtime PM support patches.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 25 +
1 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cc5434..cdcdd83 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -73,7 +73,6 @@ struct omap_uart_state {
void __iomem *wk_st;
void __iomem *wk_en;
u32 wk_mask;
- u32 padconf;
u32 dma_enabled;
struct clk *ick;
@@ -309,13 +308,6 @@ static void omap_uart_enable_wakeup(struct omap_uart_state
*uart)
v |= uart-wk_mask;
__raw_writel(v, uart-wk_en);
}
-
- /* Ensure IOPAD wake-enables are set */
- if (cpu_is_omap34xx() uart-padconf) {
- u16 v = omap_ctrl_readw(uart-padconf);
- v |= OMAP3_PADCONF_WAKEUPENABLE0;
- omap_ctrl_writew(v, uart-padconf);
- }
}
static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
@@ -326,13 +318,6 @@ static void omap_uart_disable_wakeup(struct
omap_uart_state *uart)
v = ~uart-wk_mask;
__raw_writel(v, uart-wk_en);
}
-
- /* Ensure IOPAD wake-enables are cleared */
- if (cpu_is_omap34xx() uart-padconf) {
- u16 v = omap_ctrl_readw(uart-padconf);
- v = ~OMAP3_PADCONF_WAKEUPENABLE0;
- omap_ctrl_writew(v, uart-padconf);
- }
}
static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
@@ -478,7 +463,6 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
if (cpu_is_omap34xx() !cpu_is_ti816x()) {
u32 mod = (uart-num 1) ? OMAP3430_PER_MOD : CORE_MOD;
u32 wk_mask = 0;
- u32 padconf = 0;
/* XXX These PRM accesses do not belong here */
uart-wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1);
@@ -486,23 +470,18 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
switch (uart-num) {
case 0:
wk_mask = OMAP3430_ST_UART1_MASK;
- padconf = 0x182;
break;
case 1:
wk_mask = OMAP3430_ST_UART2_MASK;
- padconf = 0x17a;
break;
case 2:
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;
} else if (cpu_is_omap24xx()) {
u32 wk_mask = 0;
u32 wk_en = PM_WKEN1, wk_st = PM_WKST1;
@@ -532,7 +511,6 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
uart-wk_en = NULL;
uart-wk_st = NULL;
uart-wk_mask = 0;
- uart-padconf = 0;
}
uart-irqflags |= IRQF_SHARED;
@@ -833,8 +811,7 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
console_unlock();
- if ((cpu_is_omap34xx() uart-padconf) ||
- (uart-wk_en uart-wk_mask)) {
+ if (uart-oh-mux || (uart-wk_en uart-wk_mask)) {
device_init_wakeup(pdev-dev, true);
DEV_CREATE_FILE(pdev-dev, dev_attr_sleep_timeout);
}
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8 01/16] power: add omap prm driver skeleton
This driver will eventually support OMAP soc PRM module features, e.g. PRCM
chain interrupts.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
drivers/power/Kconfig|7
drivers/power/Makefile |1 +
drivers/power/omap_prm.c | 83 ++
3 files changed, 91 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/omap_prm.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 57de051..e735a95 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -249,4 +249,11 @@ config CHARGER_MAX8998
Say Y to enable support for the battery charger control sysfs and
platform data of MAX8998/LP3974 PMICs.
+config OMAP_PRM
+ bool OMAP Power and Reset Management driver
+ depends on (ARCH_OMAP) PM
+ help
+ Say Y to enable support for the OMAP Power and Reset Management
+ driver.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b4af13d..8df93c2 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_WM831X_BACKUP) += wm831x_backup.o
obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
obj-$(CONFIG_WM8350_POWER) += wm8350_power.o
obj-$(CONFIG_TEST_POWER) += test_power.o
+obj-$(CONFIG_OMAP_PRM) += omap_prm.o
obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o
diff --git a/drivers/power/omap_prm.c b/drivers/power/omap_prm.c
new file mode 100644
index 000..dfc0920
--- /dev/null
+++ b/drivers/power/omap_prm.c
@@ -0,0 +1,83 @@
+/*
+ * OMAP Power and Reset Management (PRM) driver
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * Author: Tero Kristo t-kri...@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.
+ */
+
+#include linux/kernel.h
+#include linux/ctype.h
+#include linux/module.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+
+#define DRIVER_NAME omap-prm
+
+struct omap_prm_device {
+ struct platform_device pdev;
+};
+
+static struct omap_prm_device prm_dev = {
+ .pdev = {
+ .name = DRIVER_NAME,
+ .id = -1,
+ },
+};
+
+static int __init omap_prm_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int __devexit omap_prm_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver prm_driver = {
+ .remove = __exit_p(omap_prm_remove),
+ .driver = {
+ .name = DRIVER_NAME,
+ },
+};
+
+static int __init omap_prm_init(void)
+{
+ int ret;
+
+ ret = platform_device_register(prm_dev.pdev);
+
+ if (ret) {
+ printk(KERN_ERR Unable to register PRM device: %d\n, ret);
+ return ret;
+ }
+
+ ret = platform_driver_probe(prm_driver, omap_prm_probe);
+
+ if (ret)
+ printk(KERN_ERR PRM driver probe failed: %d\n, ret);
+
+ return ret;
+}
+subsys_initcall(omap_prm_init);
+
+static void __exit omap_prm_exit(void)
+{
+ platform_device_unregister(prm_dev.pdev);
+ platform_driver_unregister(prm_driver);
+}
+module_exit(omap_prm_exit);
+
+MODULE_ALIAS(platform:DRIVER_NAME);
+MODULE_AUTHOR(Tero Kristo t-kri...@ti.com);
+MODULE_DESCRIPTION(OMAP PRM driver);
+MODULE_LICENSE(GPL);
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8 05/16] TEMP: OMAP4xxx: hwmod data: add PRM hwmod
This patch is temporary until Benoit can provide final version.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 65
1 files changed, 65 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 6201422..600c7b9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3990,6 +3990,68 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+ /*
+ * 'prm' class
+ * power and reset manager (part of the prcm infrastructure)
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_prm_sysc = {
+ .rev_offs = 0x,
+ .sysc_flags = 0,
+};
+
+static struct omap_hwmod_class omap44xx_prm_hwmod_class = {
+ .name = prm,
+ .sysc = omap44xx_prm_sysc,
+};
+
+/* prm */
+static struct omap_hwmod omap44xx_prm_hwmod;
+static struct omap_hwmod_irq_info omap44xx_prm_irqs[] = {
+ { .irq = 11 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_prm_resets[] = {
+ { .name = rst_global_warm_sw, .rst_shift = 0 },
+ { .name = rst_global_cold_sw, .rst_shift = 1 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_prm_addrs[] = {
+ {
+ .pa_start = 0x4a306000,
+ .pa_end = 0x4a307fff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_wkup - prm */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__prm = {
+ .master = omap44xx_l4_wkup_hwmod,
+ .slave = omap44xx_prm_hwmod,
+ .clk= l4_wkup_clk_mux_ck,
+ .addr = omap44xx_prm_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* prm slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_prm_slaves[] = {
+ omap44xx_l4_wkup__prm,
+};
+
+static struct omap_hwmod omap44xx_prm_hwmod = {
+ .name = prm,
+ .class = omap44xx_prm_hwmod_class,
+ .mpu_irqs = omap44xx_prm_irqs,
+ .clkdm_name = l4_wkup_clkdm,
+ .rst_lines = omap44xx_prm_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_prm_resets),
+ .slaves = omap44xx_prm_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_prm_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
/*
* 'smartreflex' class
* smartreflex module (monitor silicon performance and outputs a measure of
@@ -5448,6 +5510,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* mpu class */
omap44xx_mpu_hwmod,
+ /* prm class */
+ omap44xx_prm_hwmod,
+
/* smartreflex class */
omap44xx_smartreflex_core_hwmod,
omap44xx_smartreflex_iva_hwmod,
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8 03/16] OMAP2+: hwmod: Add API to check IO PAD wakeup status
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h| 13 +++
arch/arm/mach-omap2/omap_hwmod.c |7 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
4 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index c7fb22a..50ee806 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -351,6 +351,36 @@ err1:
return NULL;
}
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Gets the wakeup status of given pad from omap-hwmod.
+ * Returns true if wakeup event is set for pad else false
+ * if wakeup is not occured or pads are not avialable.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ int i;
+ unsigned int val;
+ u8 ret = false;
+
+ for (i = 0; i hmux-nr_pads; i++) {
+ struct omap_device_pad *pad = hmux-pads[i];
+
+ if (pad-flags OMAP_DEVICE_PAD_WAKEUP) {
+ val = omap_mux_read(pad-partition,
+ pad-mux-reg_offset);
+ if (val OMAP_WAKEUP_EVENT) {
+ ret = true;
+ break;
+ }
+ }
+ }
+
+ return ret;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 2132308..8b2150a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,21 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int
nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Called only from omap_hwmod.c, do not use.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux);
#else
+static inline bool
+omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e751dd9..a8b24d7 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2724,3 +2724,10 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
return 0;
}
+
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh)
+{
+ if (oh oh-mux)
+ return omap_hwmod_mux_get_wake_status(oh-mux);
+ return -EINVAL;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 38ac4af..9c70cc8 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -606,6 +606,7 @@ u32 omap_hwmod_get_context_loss_count(struct omap_hwmod
*oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh);
/*
* Chip variant-specific hwmod init routines - XXX should be converted
* to use initcalls once the initial boot ordering is straightened out
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8 06/16] power: omap-prm: added chain interrupt handler
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC being used.
Driver detects the version of the PRM module in use via PRM hwmod
revision. This hwmod also defines the interrupt number for the chain
handler. Driver itself contains SoC specific data for register offsets
within the PRM module, and contains a list of supported PRCM interrupt
events.
PRCM interrupts have two priority levels, high or normal. High priority
is needed for IO event handling, so that we can be sure that IO events
are processed before other events. This reduces latency for IO event
customers and also prevents incorrect ack sequence on OMAP3.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Avinash.H.M avinas...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Govindraj.R govindraj.r...@ti.com
---
drivers/power/omap_prm.c | 351 +++-
include/linux/power/omap_prm.h | 19 +++
2 files changed, 368 insertions(+), 2 deletions(-)
create mode 100644 include/linux/power/omap_prm.h
diff --git a/drivers/power/omap_prm.c b/drivers/power/omap_prm.c
index dfc0920..880748a 100644
--- a/drivers/power/omap_prm.c
+++ b/drivers/power/omap_prm.c
@@ -15,15 +15,59 @@
#include linux/ctype.h
#include linux/module.h
#include linux/io.h
+#include linux/irq.h
+#include linux/interrupt.h
#include linux/slab.h
#include linux/init.h
#include linux/err.h
#include linux/platform_device.h
+#include plat/irqs.h
+#include plat/omap_hwmod.h
+
#define DRIVER_NAME omap-prm
+#define OMAP_PRCM_MAX_NR_PENDING_REG 2
+
+struct omap_prcm_irq_setup {
+ u32 ack;
+ u32 mask;
+ int nr_regs;
+};
struct omap_prm_device {
- struct platform_device pdev;
+ struct platform_device pdev;
+ const struct omap_prcm_irq_setup*irq_setup;
+ struct irq_chip_generic **irq_chips;
+ int suspended;
+ u32 *saved_ena;
+ u32 *priority_mask;
+ int base_irq;
+ int irq;
+ void __iomem*base;
+ int revision;
+};
+
+#define OMAP3_PRM_REVISION 0x10
+#define OMAP4_PRM_REVISION 0x4100
+
+#define PRM_OMAP3 0x1
+#define PRM_OMAP4 0x2
+
+#define OMAP3_PRM_IRQSTATUS_OFFSET 0x818
+#define OMAP3_PRM_IRQENABLE_OFFSET 0x81c
+#define OMAP4_PRM_IRQSTATUS_OFFSET 0x10
+#define OMAP4_PRM_IRQENABLE_OFFSET 0x18
+
+static const struct omap_prcm_irq_setup omap3_prcm_irq_setup = {
+ .ack= OMAP3_PRM_IRQSTATUS_OFFSET,
+ .mask = OMAP3_PRM_IRQENABLE_OFFSET,
+ .nr_regs= 1,
+};
+
+static const struct omap_prcm_irq_setup omap4_prcm_irq_setup = {
+ .ack= OMAP4_PRM_IRQSTATUS_OFFSET,
+ .mask = OMAP4_PRM_IRQENABLE_OFFSET,
+ .nr_regs= 2,
};
static struct omap_prm_device prm_dev = {
@@ -33,20 +77,321 @@ static struct omap_prm_device prm_dev = {
},
};
-static int __init omap_prm_probe(struct platform_device *pdev)
+struct omap_prcm_irq {
+ const char *name;
+ unsigned int offset;
+ bool priority;
+ u32 supported_rev;
+};
+
+#define OMAP_PRCM_IRQ(_name, _offset, _high_priority, _rev) { \
+ .name = _name, \
+ .offset = _offset, \
+ .priority = _high_priority, \
+ .supported_rev = _rev \
+ }
+
+static struct omap_prcm_irq omap_prcm_irqs[] = {
+ OMAP_PRCM_IRQ(wkup, 0, 0, PRM_OMAP3),
+ OMAP_PRCM_IRQ(io, 9, 1, PRM_OMAP3 | PRM_OMAP4),
+};
+
+static inline u32 prm_read_reg(int offset)
+{
+ return __raw_readl(prm_dev.base + offset);
+}
+
+static inline void prm_write_reg(u32 value, int offset)
+{
+ __raw_writel(value, prm_dev.base + offset);
+}
+
+static void prm_pending_events(unsigned long *events)
+{
+ u32 ena, st;
+ int i;
+
+ memset(events, 0, prm_dev.irq_setup-nr_regs * 4);
+
+ for (i = 0; i prm_dev.irq_setup-nr_regs; i++) {
+ ena = prm_read_reg(prm_dev.irq_setup-mask + i * 4);
+ st = prm_read_reg(prm_dev.irq_setup-ack + i * 4);
+ events[i] = ena st;
+ }
+}
+
+static void prm_events_filter_priority(unsigned long *events,
+ unsigned long *priority_events)
+{
+ int i;
+
+ for (i = 0; i
[PATCHv8 10/16] TEMP: 4430sdp: use common serial init with mux support
Temporary testing related patch, not meant for integration.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index c7cef44..f1151e8 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -737,17 +737,7 @@ static struct omap_board_data serial4_data __initdata = {
static inline void board_serial_init(void)
{
- struct omap_board_data bdata;
- bdata.flags = 0;
- bdata.pads = NULL;
- bdata.pads_cnt = 0;
- bdata.id= 0;
- /* pass dummy data for UART1 */
- omap_serial_init_port(bdata);
-
- omap_serial_init_port(serial2_data);
- omap_serial_init_port(serial3_data);
- omap_serial_init_port(serial4_data);
+ omap_serial_init();
}
#else
#define board_mux NULL
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8 11/16] TEMP: mux: added trace for io wkup event
Temporary patch for testing purposes, not meant for integration.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/mux.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 9127273..5b38f1e 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -376,6 +376,8 @@ bool omap_hwmod_mux_get_wake_status(struct
omap_hwmod_mux_info *hmux)
pad-mux-reg_offset);
if (val OMAP_WAKEUP_EVENT) {
ret = true;
+ pr_info(wkup detected: %04x\n,
+ pad-mux-reg_offset);
break;
}
}
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8 04/16] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
This patch is temporary until Paul can provide a final version.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 56
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..77f44de 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -161,6 +161,7 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod = {
};
static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
+static struct omap_hwmod omap3xxx_prm_hwmod;
static struct omap_hwmod omap3xxx_uart1_hwmod;
static struct omap_hwmod omap3xxx_uart2_hwmod;
static struct omap_hwmod omap3xxx_uart3_hwmod;
@@ -478,6 +479,24 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+static struct omap_hwmod_addr_space omap3xxx_prm_addrs[] = {
+ {
+ .pa_start = 0x48306000,
+ .pa_end = 0x48306000 + SZ_8K + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+/* L4_WKUP - PRM interface */
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__prm = {
+ .master = omap3xxx_l4_wkup_hwmod,
+ .slave = omap3xxx_prm_hwmod,
+ .clk= wkup_l4_ick,
+ .addr = omap3xxx_prm_addrs,
+ .user = OCP_USER_MPU,
+};
+
/* Slave interfaces on the L4_WKUP interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
omap3xxx_l4_core__l4_wkup,
@@ -493,6 +512,40 @@ static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+/* Slave interfaces on the L4_WKUP interconnect */
+static struct omap_hwmod_ocp_if *omap3xxx_prm_slaves[] = {
+ omap3xxx_l4_wkup__prm,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_prm_sysc = {
+ .rev_offs = 0x0804,
+ .sysc_offs = 0x0814,
+ .sysc_flags = SYSC_HAS_AUTOIDLE,
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_prm_hwmod_class = {
+ .name = prm,
+ .sysc = omap3xxx_prm_sysc,
+};
+
+static struct omap_hwmod_irq_info omap3xxx_prm_irqs[] = {
+ { .irq = 11 },
+ { .irq = -1 }
+};
+
+/* PRM */
+static struct omap_hwmod omap3xxx_prm_hwmod = {
+ .name = prm,
+ .mpu_irqs = omap3xxx_prm_irqs,
+ .class = omap3xxx_prm_hwmod_class,
+ .main_clk = wkup_32k_fck,
+ .slaves = omap3xxx_prm_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_prm_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
/* Master interfaces on the MPU device */
static struct omap_hwmod_ocp_if *omap3xxx_mpu_masters[] = {
omap3xxx_mpu__l3_main,
@@ -3201,6 +3254,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l4_core_hwmod,
omap3xxx_l4_per_hwmod,
omap3xxx_l4_wkup_hwmod,
+
+ omap3xxx_prm_hwmod,
+
omap3xxx_mmc1_hwmod,
omap3xxx_mmc2_hwmod,
omap3xxx_mmc3_hwmod,
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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
[PATCHv8 15/16] OMAP3: pm: do not enable PRCM MPU interrupts manually
This is handled automatically by the PRCM chain interrupt mechanism now. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/pm34xx.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 4571993..5765949 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -642,10 +642,6 @@ static void __init prcm_setup_regs(void) OMAP3430_GRPSEL_GPT1_MASK | OMAP3430_GRPSEL_GPT12_MASK, WKUP_MOD, OMAP3430_PM_MPUGRPSEL); - /* For some reason IO doesn't generate wakeup event even if -* it is selected to mpu wakeup goup */ - omap2_prm_write_mod_reg(OMAP3430_IO_EN_MASK | OMAP3430_WKUP_EN_MASK, - OCP_MOD, OMAP3_PRM_IRQENABLE_MPU_OFFSET); /* Enable PM_WKEN to support DSS LPR */ omap2_prm_write_mod_reg(OMAP3430_PM_WKEN_DSS_EN_DSS_MASK, -- 1.7.4.1 Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- 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
[PATCHv8 16/16] TEMP: OMAP device: change pr_warnings to pr_debugs
Prevents a hang when omap_device would want to print something for serial console device while enabling / disabling its clocks. Should be handled properly by serial runtime PM support. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Govindraj.R govindraj.r...@ti.com --- arch/arm/plat-omap/omap_device.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index d8f2299..ecec0cc 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -154,7 +154,7 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat) %d: %llu\n, od-pm_lat_level, act_lat); } else - dev_warn(od-pdev-dev, + dev_dbg(od-pdev-dev, activate latency %d higher than exptected. (%llu %d)\n, od-pm_lat_level, act_lat, @@ -221,7 +221,7 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat) %d: %llu\n, od-pm_lat_level, deact_lat); } else - dev_warn(od-pdev-dev, + dev_dbg(od-pdev-dev, deactivate latency %d higher than exptected. (%llu %d)\n, od-pm_lat_level, deact_lat, -- 1.7.4.1 Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] OMAP: convert I2C driver to PM QoS for latency constraints
Jean Pihet jean.pi...@newoldbits.com writes: Kevin, On Fri, Sep 16, 2011 at 12:46 AM, Kevin Hilman khil...@ti.com wrote: Hi Jean, Jean Pihet jean.pi...@newoldbits.com writes: Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat API to the new PM QoS API. Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY class of PM QoS. The resulting MPU constraints are used by cpuidle to decide the next power state of the MPU subsystem. Currently only OMAP3 is placing constraints on the MPU. Signed-off-by: Jean Pihet j-pi...@ti.com [...] @@ -648,8 +648,16 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) if (r 0) goto out; - if (dev-set_mpu_wkup_lat != NULL) - dev-set_mpu_wkup_lat(dev-dev, dev-latency); + /* + * When waiting for completion of a i2c transfer, we need to + * set a wake up latency constraint for the MPU. This is to + * ensure quick enough wakeup from idle, when transfer + * completes. + * Used on OMAP3 Only + */ + if (cpu_is_omap34xx()) We don't want any cpu_is_* checking in drivers. If this is only done on certain SoCs, then a flag should be passed from device init code via pdata. That being said, I don't see why this shouldn't be set for all SoCs since it's using the FIFO size to determine the latency. I am OK to have the constraints active for all OMAPs. Side question: what if different SOCs need different values for the constraint? This latency calculation is based on FIFO size and drain rate, so it should be completely SoC independent. However, if for some reason there are SoC dependencies, the SoC specific parts need to be passed in to the driver. 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
[PATCH] OMAP3: PM: fix UART handling when using no_console_suspend
During the idle/suspend path, we expect the console lock to be held so
that no console output is done during/after the UARTs are idled.
However, when using the no_console_suspend argument on the
command-line, the console driver does not take the console lock. This
allows the possibility of console activity after UARTs have been
disabled.
To fix, update the current is_suspending() to also check the
console_suspend_enabled flag.
Reported-by: Abhilash Koyamangalath abhilash...@ti.com
Tested-by: Abhilash Koyamangalath abhilash...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
This patch will be included in my PM cleanup series for v3.2
(branch: for_3.2/pm-cleanup)
arch/arm/mach-omap2/pm34xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..c8cbd00 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -55,7 +55,7 @@
static suspend_state_t suspend_state = PM_SUSPEND_ON;
static inline bool is_suspending(void)
{
- return (suspend_state != PM_SUSPEND_ON);
+ return (suspend_state != PM_SUSPEND_ON) console_suspend_enabled;
}
#else
static inline bool is_suspending(void)
--
1.7.6
--
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 5/6] OMAP: omap_device: Create a default omap_device_pm_latency
Cousson, Benoit b-cous...@ti.com writes:
Hi Kevin,
On 9/2/2011 4:25 PM, Cousson, Benoit wrote:
Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will be used if
the device does not have an explicit one.
[...]
-od-pm_lats = pm_lats;
-od-pm_lats_cnt = pm_lats_cnt;
+if (pm_lats) {
+od-pm_lats = pm_lats;
+od-pm_lats_cnt = pm_lats_cnt;
+} else {
+od-pm_lats = omap_default_latency;
+od-pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
+}
Here is the fix for that part. I did the easy version :-). Splitting
the structure in two parts will indeed require more work.
The kmemdup() method is fine with me.
I updated the for_3.2/1_omap_device_cleanup branch.
Thanks, I'll pick these into my branch (which is now renamed to
for_3.2/omap_device-cleanup)
Kevin
Regards,
Benoit
---
From ad163000568dd61dee441473d0a576d84152da9e Mon Sep 17 00:00:00 2001
From: Benoit Cousson b-cous...@ti.com
Date: Tue, 9 Aug 2011 16:54:19 +0200
Subject: [PATCH v3 5/6] OMAP: omap_device: Create a default
omap_device_pm_latency
Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will be used if
the device does not have an explicit one.
Next patches will clean the duplicated structures.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/omap_device.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 7b2cf62..54bbe7b 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -97,6 +97,14 @@
static int omap_device_register(struct platform_device *pdev);
static int omap_early_device_register(struct platform_device *pdev);
+static struct omap_device_pm_latency omap_default_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ }
+};
+
/* Private functions */
/**
@@ -510,8 +518,17 @@ struct platform_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
if (ret)
goto odbs_exit3;
- od-pm_lats = pm_lats;
+ if (!pm_lats) {
+ pm_lats = omap_default_latency;
+ pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
+ }
+
od-pm_lats_cnt = pm_lats_cnt;
+ od-pm_lats = kmemdup(pm_lats,
+ sizeof(struct omap_device_pm_latency) * pm_lats_cnt,
+ GFP_KERNEL);
+ if (!od-pm_lats)
+ goto odbs_exit3;
for (i = 0; i oh_cnt; i++) {
hwmods[i]-od = od;
--
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] OMAP PM cleanup for v3.2
Tony, Please pull the following PM cleanups for v3.2 Kevin The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c: Linux 3.1-rc3 (2011-08-22 11:42:53 -0700) are available in the git repository at: git://gitorious.org/khilman/linux-omap-pm.git for_3.2/pm-cleanup Johan Hovold (2): OMAP2+: PM: fix typos in misc. comment and error messages OMAP2+: PM: clean up error messages: replace printk with pr_err. Kevin Hilman (1): OMAP3: PM: fix UART handling when using no_console_suspend Michael Jones (1): OMAP2: PM debug: remove leftover debug code arch/arm/mach-omap2/pm.c | 22 ++ arch/arm/mach-omap2/pm24xx.c | 27 --- arch/arm/mach-omap2/pm34xx.c |2 +- 3 files changed, 11 insertions(+), 40 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
Re: [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support
Santosh Shilimkar santosh.shilim...@ti.com writes:
When MPUSS hits off-mode e, L2 cache is lost. This patch adds L2X0
^^^
extra 'e' ?
necessary maintenance operations and context restoration in the
low power code.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
[...]
@@ -135,6 +138,33 @@ static void scu_pwrst_prepare(unsigned int cpu_id,
unsigned int cpu_state)
__raw_writel(scu_pwr_st, pm_info-scu_sar_addr);
}
+/*
+ * Store the CPU cluster state for L2X0 low power operations.
+ */
+static void l2x0_pwrst_prepare(unsigned int cpu_id, unsigned int save_state)
+{
+ struct omap4_cpu_pm_info *pm_info = per_cpu(omap4_pm_info, cpu_id);
+
+ __raw_writel(save_state, pm_info-l2x0_sar_addr);
+}
+
+/*
+ * Save the L2X0 AUXCTRL and POR value to SAR memory. Its used to
+ * in every restore MPUSS OFF path.
+ */
+static void save_l2x0_context(void)
+{
+#ifdef CONFIG_CACHE_L2X0
+ u32 val;
+ void __iomem *l2x0_base = omap4_get_l2cache_base();
+
+ val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
+ __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
+ val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
+ __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+#endif
nit: (c.f. '#ifdefs are ugly' in Documentatin/SubmittingPatches)
This should probably be more like
#ifdef CONFIG_CACHE_L2X0
static void save_l2x0_context(void)
{
/* real function */
}
#else
static void save_l2x0_context(void) {}
#endif
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 23/25] OMAP4: PM: Add CPUidle support
Hi Santosh,
Santosh Shilimkar santosh.shilim...@ti.com writes:
Add OMAP4 CPUIDLE support. CPU1 is left with defualt idle and
the low power state for it is managed via cpu-hotplug.
This patch adds MPUSS low power states in cpuidle.
C1 - CPU0 ON + CPU1 ON + MPU ON
C2 - CPU0 OFF + CPU1 OFF + MPU CSWR
C3 - CPU0 OFF + CPU1 OFF + MPU OSWR
OMAP4460 onwards, MPUSS power domain doesn't support OFF state any more
anymore just like CORE power domain. The deepest state supported is OSWr.
Ofcourse when MPUSS and CORE PD transitions to OSWR along with device
off mode, even the memory contemts are lost which is as good as
the PD off state.
On OMAP4 because of hardware constraints, no low power states are
targeted when both CPUs are online and in SMP mode. The low power
states are attempted only when secondary CPU gets offline to OFF
through hotplug infrastructure.
Thanks to Nicole Chalhoub n-chalh...@ti.com for doing exhaustive
C-state latency profiling.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
A handful of minor comments below...
[...]
+/**
+ * omap4_enter_idle - Programs OMAP4 to enter the specified state
+ * @dev: cpuidle device
+ * @state: The target state to be programmed
+ *
+ * Called from the CPUidle framework to program the device to the
+ * specified low power state selected by the governor.
+ * Returns the amount of time spent in the low power state.
+ */
+static int omap4_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ struct omap4_idle_statedata *cx = cpuidle_get_statedata(state);
+ struct timespec ts_preidle, ts_postidle, ts_idle;
+ u32 cpu1_state;
+
+ /* Used to keep track of the total time in idle */
+ getnstimeofday(ts_preidle);
+
+ local_irq_disable();
+ local_fiq_disable();
+
+ /*
+ * Keep demoting CPU0 C-state till CPU1 hits OFF state.
IMO, the working here isn't as clear as it could be. IOW, I don't like
keep demoting, which makes it sound iterative through a set of states,
where what's happening here is a one-time decision.
Rather, what I think you mean is CPU0 has to stay on (e.g in C1) until
CPU1 is off.
+ * This is necessary to honour hardware recommondation
+ * of triggeing all the possible low power modes once CPU1 is
+ * out of coherency and in OFF mode.
+ * Update dev-last_state so that governor stats reflects right
+ * data.
+ */
+ cpu1_state = pwrdm_read_pwrst(cpu1_pd);
+ if (cpu1_state != PWRDM_POWER_OFF) {
+ dev-last_state = dev-safe_state;
+ cx = cpuidle_get_statedata(dev-safe_state);
+ }
+
+ /* Call idle CPU PM enter notifier chain */
This comment doesn't add any value over the code. If anything, a
comment explaining why it's only there for off-mode transitions would be
helpful.
+ if (cx-cpu_state == PWRDM_POWER_OFF)
+ cpu_pm_enter();
I think the CPU PM notifier usage should probably be a separate patch.
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+
+ /* Call idle CPU cluster PM enter notifier chain */
+ if ((cx-mpu_state == PWRDM_POWER_RET)
+ (cx-mpu_logic_state == PWRDM_POWER_OFF))
+ cpu_cluster_pm_enter();
+
+ omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+ /* Call idle CPU PM exit notifier chain */
As above, this comment doesn't add any value over the code.
While I understand why it's only done for CPU0 here (CPU1 is managed by
hotplug), we should anticipating the moment where we will have forgotten
why it's only done for CPU0, and add a comment here.
+ if (pwrdm_read_prev_pwrst(cpu0_pd) == PWRDM_POWER_OFF)
+ cpu_pm_exit();
+
+ /* Call idle CPU cluster PM exit notifier chain */
again, comment not helpful
+ if (omap4_mpuss_read_prev_context_state())
+ cpu_cluster_pm_exit();
+
+ getnstimeofday(ts_postidle);
+ ts_idle = timespec_sub(ts_postidle, ts_preidle);
+
+ local_irq_enable();
+ local_fiq_enable();
+
+ return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
+}
+
+DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
+
+struct cpuidle_driver omap4_idle_driver = {
+ .name = omap4_idle,
+ .owner =THIS_MODULE,
+};
+
+/* Fill in the state data from the mach tables and register the driver_data
*/
if documented, it should have a kerneldoc header instead
+static inline struct omap4_idle_statedata *_fill_cstate(
+ struct cpuidle_device *dev,
+ int idx, const char *descr)
+{
+ struct omap4_idle_statedata *cx = omap4_idle_data[idx];
+ struct cpuidle_state *state = dev-states[idx];
+
+
[PATCH v2 0/6] OMAP3+ Clock Fixes
From: Jon Hunter jon-hun...@ti.com Various clock fixes for OMAP3 and OMAP4 devices. Jon Hunter (4): OMAP4: Add missing clock divider for OCP_ABE_ICLK OMAP3+: use DPLLs recalc function instead of omap2_get_dpll_rate OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices OMAP4: Clock: Correct the name of SLIMBUS interface clocks Mike Turquette (2): OMAP4: Clock: round_rate and recalc functions for DPLL_ABE OMAP3+: use DPLL's round_rate when setting rate arch/arm/mach-omap2/clkt_dpll.c | 51 +++-- arch/arm/mach-omap2/clock.h |2 + arch/arm/mach-omap2/clock44xx.h |2 + arch/arm/mach-omap2/clock44xx_data.c | 32 +++-- arch/arm/mach-omap2/dpll3xxx.c |6 ++-- arch/arm/mach-omap2/dpll44xx.c | 45 ++ 6 files changed, 110 insertions(+), 28 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5 v9] mfd: omap: usb: Runtime PM support
On 09/16/11 00:31, Munegowda, Keshava wrote: On Fri, Sep 16, 2011 at 11:17 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Fri, Sep 16, 2011 at 6:10 AM, Frank Rowand frank.row...@am.sony.com wrote: On 09/15/11 06:22, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com The usbhs core driver does not enable/disable the interface and functional clocks; These clocks are handled by hwmod and runtime pm, hence instead of the clock enable/disable, the runtime pm APIS are used. however,the port clocks are handled by the usbhs core. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/include/plat/usb.h |3 - drivers/mfd/omap-usb-host.c | 731 + drivers/usb/host/ehci-omap.c | 17 +- drivers/usb/host/ohci-omap3.c | 18 +- 4 files changed, 295 insertions(+), 474 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h index 17d3c93..2b66dc2 100644 Patch 5/5 is white space mangled. The tabs have been changed into spaces. -Frank Hi Frank I tried the checkpatch with --strict option; its not showing anything here. may be some problem with your editor/browser. It must be my email server, because when I pull the patch from an archive it has tabs. Weird that only the fifth patch is being munged for me... Thanks for checking! -Frank -- 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/6] OMAP4: Add missing clock divider for OCP_ABE_ICLK
From: Jon Hunter jon-hun...@ti.com
The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
parent clock of the AESS_FCLK is the ABE_FCLK...
ABE_FCLK -- AESS_FCLK -- OCP_ABE_ICLK
The AESS_FCLK and OCP_ABE_ICLK clocks both have dividers which
determine their operational frequency. However, the dividers for
the AESS_FCLK and OCP_ABE_ICLK are controlled via a single bit,
which is the CM1_ABE_AESS_CLKCTRL[24] bit. When this bit is set to
0, the AESS_FCLK divider is 1 and the OCP_ABE_ICLK divider is 2.
Similarly, when this bit is set to 1, the AESS_FCLK divider is 2
and the OCP_ABE_ICLK is 1.
The above relationship between the AESS_FCLK and OCP_ABE_ICLK
dividers ensure that the OCP_ABE_ICLK clock is always half the
frequency of the ABE_CLK...
OCP_ABE_ICLK = ABE_FCLK/2
The divider for the OCP_ABE_ICLK is currently missing so add a
divider that will ensure the OCP_ABE_ICLK frequency is always half
the ABE_FCLK frequency.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index c0b6fbd..3e34dcd 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1195,11 +1195,25 @@ static struct clk l4_wkup_clk_mux_ck = {
.recalc = omap2_clksel_recalc,
};
+static const struct clksel_rate div2_2to1_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 2, .val = 0, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel ocp_abe_iclk_div[] = {
+ { .parent = aess_fclk, .rates = div2_2to1_rates },
+ { .parent = NULL },
+};
+
static struct clk ocp_abe_iclk = {
.name = ocp_abe_iclk,
.parent = aess_fclk,
+ .clksel = ocp_abe_iclk_div,
+ .clksel_reg = OMAP4430_CM1_ABE_AESS_CLKCTRL,
+ .clksel_mask= OMAP4430_CLKSEL_AESS_FCLK_MASK,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .recalc = omap2_clksel_recalc,
};
static struct clk per_abe_24m_fclk = {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/6] OMAP4: Clock: round_rate and recalc functions for DPLL_ABE
From: Mike Turquette mturque...@ti.com
OMAP4 DPLL_ABE can enable a 4X multipler on top of the normal MN multipler
and divider. This is achieved by setting CM_CLKMODE_DPLL_ABE.DPLL_REGM4XEN
bit in CKGEN module of CM1. From the OMAP4 TRM:
Fdpll = Fref x 2 x (4 x M/(N+1)) in case REGM4XEN bit field is set (only
applicable to DPLL_ABE).
Add new round_rate() and recalc() functions for OMAP4, that check the
setting of REGM4XEN bit and handle this appropriately. The new functions
are a simple wrapper on top of the existing omap2_dpll_round_rate() and
omap2_dpll_get_rate() functions to handle the REGM4XEN bit.
The REGM4XEN bit is only implemented for the ABE DPLL on OMAP4 and so
only dpll_abe_ck uses omap4_dpll_regm4xen_round_rate() and
omap4_dpll_regm4xen_recalc() functions.
Signed-off-by: Mike Turquette mturque...@ti.com
Tested-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock.h |2 +
arch/arm/mach-omap2/clock44xx.h |2 +
arch/arm/mach-omap2/clock44xx_data.c |4 +-
arch/arm/mach-omap2/dpll44xx.c | 45 ++
4 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 48ac568..2311bc2 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -66,6 +66,8 @@ void omap3_noncore_dpll_disable(struct clk *clk);
int omap4_dpllmx_gatectrl_read(struct clk *clk);
void omap4_dpllmx_allow_gatectrl(struct clk *clk);
void omap4_dpllmx_deny_gatectrl(struct clk *clk);
+long omap4_dpll_regm4xen_round_rate(struct clk *clk, unsigned long
target_rate);
+unsigned long omap4_dpll_regm4xen_recalc(struct clk *clk);
#ifdef CONFIG_OMAP_RESET_CLOCKS
void omap2_clk_disable_unused(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock44xx.h b/arch/arm/mach-omap2/clock44xx.h
index 7ceb870..e9cce7d 100644
--- a/arch/arm/mach-omap2/clock44xx.h
+++ b/arch/arm/mach-omap2/clock44xx.h
@@ -8,6 +8,8 @@
#ifndef __ARCH_ARM_MACH_OMAP2_CLOCK44XX_H
#define __ARCH_ARM_MACH_OMAP2_CLOCK44XX_H
+#define OMAP4430_REGM4XEN_MULT 4
+
int omap4xxx_clk_init(void);
#endif
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 3e34dcd..eb2a345 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -270,8 +270,8 @@ static struct clk dpll_abe_ck = {
.dpll_data = dpll_abe_dd,
.init = omap2_init_dpll_parent,
.ops= clkops_omap3_noncore_dpll_ops,
- .recalc = omap3_dpll_recalc,
- .round_rate = omap2_dpll_round_rate,
+ .recalc = omap4_dpll_regm4xen_recalc,
+ .round_rate = omap4_dpll_regm4xen_round_rate,
.set_rate = omap3_noncore_dpll_set_rate,
};
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 4e4da61..4f31530 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -19,6 +19,7 @@
#include plat/clock.h
#include clock.h
+#include clock44xx.h
#include cm-regbits-44xx.h
/* Supported only on OMAP4 */
@@ -82,3 +83,47 @@ const struct clkops clkops_omap4_dpllmx_ops = {
.deny_idle = omap4_dpllmx_deny_gatectrl,
};
+unsigned long omap4_dpll_regm4xen_recalc(struct clk *clk)
+{
+ u32 v;
+ unsigned long rate;
+ struct dpll_data *dd;
+
+ if (!clk || !clk-dpll_data)
+ return -EINVAL;
+
+ dd = clk-dpll_data;
+
+ rate = omap2_get_dpll_rate(clk);
+
+ /* regm4xen adds a multiplier of 4 to DPLL calculations */
+ v = __raw_readl(dd-control_reg);
+ if (v OMAP4430_DPLL_REGM4XEN_MASK)
+ rate *= OMAP4430_REGM4XEN_MULT;
+
+ return rate;
+}
+
+long omap4_dpll_regm4xen_round_rate(struct clk *clk, unsigned long target_rate)
+{
+ u32 v;
+ struct dpll_data *dd;
+
+ if (!clk || !clk-dpll_data)
+ return -EINVAL;
+
+ dd = clk-dpll_data;
+
+ /* regm4xen adds a multiplier of 4 to DPLL calculations */
+ v = __raw_readl(dd-control_reg) OMAP4430_DPLL_REGM4XEN_MASK;
+
+ if (v)
+ target_rate = target_rate / OMAP4430_REGM4XEN_MULT;
+
+ omap2_dpll_round_rate(clk, target_rate);
+
+ if (v)
+ clk-dpll_data-last_rounded_rate *= OMAP4430_REGM4XEN_MULT;
+
+ return clk-dpll_data-last_rounded_rate;
+}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/6] OMAP3+: use DPLL's round_rate when setting rate
From: Mike Turquette mturque...@ti.com
omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly. Instead
use the struct clk pointer's round_rate function to allow for DPLL's with
special needs.
Also the rounded rate can differ from target rate, so to better reflect
reality set clk-rate equal to the rounded rate when setting DPLL frequency.
This avoids issues where the DPLL frequency is slightly different than what
debugfs clock tree reports using the old target rate.
An example of both of these needs is DPLL_ABE on OMAP4 which can have a 4x
multiplier on top of the usual MN dividers depending on register settings.
This requires a special round_rate function that might yield a rate
different from the initial target.
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/dpll3xxx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index f77022b..73a1595 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -455,7 +455,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
new_parent = dd-clk_bypass;
} else {
if (dd-last_rounded_rate != rate)
- omap2_dpll_round_rate(clk, rate);
+ rate = clk-round_rate(clk, rate);
if (dd-last_rounded_rate == 0)
return -EINVAL;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/6] OMAP3+: use DPLLs recalc function instead of omap2_get_dpll_rate
From: Jon Hunter jon-hun...@ti.com This is a continuation of Mike Turquette's patch OMAP3+: use DPLL's round_rate when setting rate. omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call omap2_get_dpll_rate() explicitly. It may be necessary for some DPLLs to use a different function and so use the DPLLs recalc() function pointer instead. An example is the DPLL_ABE on OMAP4 which can have a 4X multiplier in addition to the usual MN multipler and dividers and therefore uses a different round_rate and recalc function. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/dpll3xxx.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 73a1595..7916f66 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -390,7 +390,7 @@ int omap3_noncore_dpll_enable(struct clk *clk) * propagating? */ if (!r) - clk-rate = omap2_get_dpll_rate(clk); + clk-rate = clk-recalc(clk); return r; } @@ -435,7 +435,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate) if (!dd) return -EINVAL; - if (rate == omap2_get_dpll_rate(clk)) + if (rate == clk-recalc(clk)) return 0; /* -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/6] OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices
From: Jon Hunter jon-hun...@ti.com
The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
clock frequency (fint) operating range than OMAP3430. Update the
dpll_test_fint() function to check for the correct frequency ranges
for OMAP36xx and OMAP4xxx.
For OMAP36xx and OMAP4xxx devices, DPLLs fint range is 0.5MHz to
2.5MHz for j-type DPLLs and otherwise it is 32KHz to 52MHz for all
other DPLLs.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c | 51 ++
1 files changed, 35 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index bcffee0..e069a9b 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -46,10 +46,19 @@
(DPLL_SCALE_FACTOR / DPLL_SCALE_BASE))
/* DPLL valid Fint frequency band limits - from 34xx TRM Section 4.7.6.2 */
-#define DPLL_FINT_BAND1_MIN75
-#define DPLL_FINT_BAND1_MAX210
-#define DPLL_FINT_BAND2_MIN750
-#define DPLL_FINT_BAND2_MAX2100
+#define OMAP3430_DPLL_FINT_BAND1_MIN 75
+#define OMAP3430_DPLL_FINT_BAND1_MAX 210
+#define OMAP3430_DPLL_FINT_BAND2_MIN 750
+#define OMAP3430_DPLL_FINT_BAND2_MAX 2100
+
+/*
+ * DPLL valid Fint frequency range for OMAP36xx and OMAP4xxx.
+ * From device data manual section 4.3 DPLL and DLL Specifications.
+ */
+#define OMAP3PLUS_DPLL_FINT_JTYPE_MIN 50
+#define OMAP3PLUS_DPLL_FINT_JTYPE_MAX 250
+#define OMAP3PLUS_DPLL_FINT_MIN32000
+#define OMAP3PLUS_DPLL_FINT_MAX5200
/* _dpll_test_fint() return codes */
#define DPLL_FINT_UNDERFLOW-1
@@ -71,33 +80,43 @@
static int _dpll_test_fint(struct clk *clk, u8 n)
{
struct dpll_data *dd;
- long fint;
+ long fint, fint_min, fint_max;
int ret = 0;
dd = clk-dpll_data;
/* DPLL divider must result in a valid jitter correction val */
fint = clk-parent-rate / n;
- if (fint DPLL_FINT_BAND1_MIN) {
+ if (cpu_is_omap24xx()) {
+ /* Should not be called for OMAP2, so warn if it is called */
+ WARN(1, No fint limits available for OMAP2!\n);
+ return DPLL_FINT_INVALID;
+ } else if (cpu_is_omap3430()) {
+ fint_min = OMAP3430_DPLL_FINT_BAND1_MIN;
+ fint_max = OMAP3430_DPLL_FINT_BAND2_MAX;
+ } else if (dd-flags DPLL_J_TYPE) {
+ fint_min = OMAP3PLUS_DPLL_FINT_JTYPE_MIN;
+ fint_max = OMAP3PLUS_DPLL_FINT_JTYPE_MAX;
+ } else {
+ fint_min = OMAP3PLUS_DPLL_FINT_MIN;
+ fint_max = OMAP3PLUS_DPLL_FINT_MAX;
+ }
+
+ if (fint fint_min) {
pr_debug(rejecting n=%d due to Fint failure,
lowering max_divider\n, n);
dd-max_divider = n;
ret = DPLL_FINT_UNDERFLOW;
-
- } else if (fint DPLL_FINT_BAND1_MAX
- fint DPLL_FINT_BAND2_MIN) {
-
- pr_debug(rejecting n=%d due to Fint failure\n, n);
- ret = DPLL_FINT_INVALID;
-
- } else if (fint DPLL_FINT_BAND2_MAX) {
-
+ } else if (fint fint_max) {
pr_debug(rejecting n=%d due to Fint failure,
boosting min_divider\n, n);
dd-min_divider = n;
ret = DPLL_FINT_INVALID;
-
+ } else if (cpu_is_omap3430() fint OMAP3430_DPLL_FINT_BAND1_MAX
+ fint OMAP3430_DPLL_FINT_BAND2_MIN) {
+ pr_debug(rejecting n=%d due to Fint failure\n, n);
+ ret = DPLL_FINT_INVALID;
}
return ret;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/6] OMAP4: Clock: Correct the name of SLIMBUS interface clocks
From: Jon Hunter jon-hun...@ti.com
Currently the interface clocks for the two SLIMBUS peripherals are
named slimbus1_fck and slimbus2_fck. Rename these clocks to be
slimbus1_ick and slimbus2_ick so it is clear that these are
interface clocks and not functional clocks.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index eb2a345..d75ebdd 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2210,8 +2210,8 @@ static struct clk slimbus1_slimbus_clk = {
.recalc = followparent_recalc,
};
-static struct clk slimbus1_fck = {
- .name = slimbus1_fck,
+static struct clk slimbus1_ick = {
+ .name = slimbus1_ick,
.ops= clkops_omap2_dflt,
.enable_reg = OMAP4430_CM1_ABE_SLIMBUS_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_SWCTRL,
@@ -2250,8 +2250,8 @@ static struct clk slimbus2_slimbus_clk = {
.recalc = followparent_recalc,
};
-static struct clk slimbus2_fck = {
- .name = slimbus2_fck,
+static struct clk slimbus2_ick = {
+ .name = slimbus2_ick,
.ops= clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_L4PER_SLIMBUS2_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_SWCTRL,
@@ -3272,11 +3272,11 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, slimbus1_fclk_0, slimbus1_fclk_0,
CK_443X),
CLK(NULL, slimbus1_fclk_2, slimbus1_fclk_2,
CK_443X),
CLK(NULL, slimbus1_slimbus_clk, slimbus1_slimbus_clk,
CK_443X),
- CLK(NULL, slimbus1_fck, slimbus1_fck,
CK_443X),
+ CLK(NULL, slimbus1_ick, slimbus1_ick,
CK_443X),
CLK(NULL, slimbus2_fclk_1, slimbus2_fclk_1,
CK_443X),
CLK(NULL, slimbus2_fclk_0, slimbus2_fclk_0,
CK_443X),
CLK(NULL, slimbus2_slimbus_clk, slimbus2_slimbus_clk,
CK_443X),
- CLK(NULL, slimbus2_fck, slimbus2_fck,
CK_443X),
+ CLK(NULL, slimbus2_ick, slimbus2_ick,
CK_443X),
CLK(NULL, smartreflex_core_fck, smartreflex_core_fck,
CK_443X),
CLK(NULL, smartreflex_iva_fck, smartreflex_iva_fck,
CK_443X),
CLK(NULL, smartreflex_mpu_fck, smartreflex_mpu_fck,
CK_443X),
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/6] iommu: split mapping to page sizes as supported by the hardware
v2-v3: - s/KB/KiB/ (David W) v1-v2: - split to patches (by keeping the old code around until all drivers are converted) (Joerg) Ohad Ben-Cohen (6): iommu/core: split mapping to page sizes as supported by the hardware iommu/omap: announce supported page sizes iommu/msm: announce supported page sizes iommu/amd: announce supported page sizes iommu/intel: announce supported page sizes iommu/core: remove the temporary register_iommu_pgsize API drivers/iommu/amd_iommu.c | 20 ++- drivers/iommu/intel-iommu.c | 20 ++- drivers/iommu/iommu.c | 130 +++ drivers/iommu/msm_iommu.c |8 ++- drivers/iommu/omap-iommu.c |6 ++- drivers/iommu/omap-iovmm.c | 12 +--- include/linux/iommu.h |7 +- virt/kvm/iommu.c|4 +- 8 files changed, 177 insertions(+), 30 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP (and seemingly MSM too) but
it would probably not fly with intel's hardware, where the page size
capabilities seem to have the potential to be different between
several DMA remapping devices. This limitation can be dealt with
later, if desired. For now, the existing IOMMU API behavior is retained
(see: iommu/intel: announce supported page sizes).
As requested, register_iommu() isn't changed yet, so we can convert
the IOMMU drivers in subsequent patches, and after all the drivers
are converted, register_iommu will be changed (and the temporary
register_iommu_pgsize() will be removed).
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to send the mapping size in bytes instead of in page order.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: David Brown dav...@codeaurora.org
Cc: David Woodhouse dw...@infradead.org
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Stepan Moskovchenko step...@codeaurora.org
Cc: Hiroshi DOYU hiroshi.d...@nokia.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: k...@vger.kernel.org
---
drivers/iommu/iommu.c | 158 +---
drivers/iommu/omap-iovmm.c | 12 +---
include/linux/iommu.h |6 +-
virt/kvm/iommu.c |4 +-
4 files changed, 157 insertions(+), 23 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index c68ff29..7c01c8c 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -16,6 +16,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#define pr_fmt(fmt)%s: fmt, __func__
+
#include linux/kernel.h
#include linux/bug.h
#include linux/types.h
@@ -23,15 +25,73 @@
#include linux/slab.h
#include linux/errno.h
#include linux/iommu.h
+#include linux/bitmap.h
static struct iommu_ops *iommu_ops;
+/* bitmap of supported page sizes */
+static unsigned long *iommu_pgsize_bitmap;
+
+/* number of bits used to represent the supported pages */
+static unsigned int iommu_nr_page_bits;
+
+/* size of the smallest supported page (in bytes) */
+static unsigned int iommu_min_pagesz;
+
+/* bit number of the smallest supported page */
+static unsigned int iommu_min_page_idx;
+
+/**
+ * register_iommu() - register an IOMMU hardware
+ * @ops: iommu handlers
+ * @pgsize_bitmap: bitmap of page sizes supported by the hardware
+ * @nr_page_bits: size of @pgsize_bitmap (in bits)
+ *
+ * Note: this is a temporary function, which will be removed once
+ * all IOMMU drivers are converted. The only reason it exists is to
+ * allow splitting the pgsizes changes to several patches in order to ease
+ * the review.
+ */
+void register_iommu_pgsize(struct iommu_ops *ops, unsigned long *pgsize_bitmap,
+ unsigned int nr_page_bits)
+{
+ if (iommu_ops || iommu_pgsize_bitmap || !nr_page_bits)
+ BUG();
+
+ iommu_ops = ops;
+ iommu_pgsize_bitmap = pgsize_bitmap;
+ iommu_nr_page_bits = nr_page_bits;
+
+ /* find the minimum page size and its index only once */
+ iommu_min_page_idx = find_first_bit(pgsize_bitmap, nr_page_bits);
+ iommu_min_pagesz = 1 iommu_min_page_idx;
+}
+
+/*
+ * default pagesize bitmap, will be removed once all IOMMU drivers
+ * are converted
+ */
+static unsigned long default_iommu_pgsizes = ~0xFFFUL;
+
void register_iommu(struct iommu_ops *ops)
{
if (iommu_ops)
BUG();
iommu_ops = ops;
+
+ /*
+* set default pgsize values, which retain the existing
+* IOMMU API behavior: drivers will be called to map
+* regions that are sized/aligned to order of 4KiB pages
+*/
+ iommu_pgsize_bitmap = default_iommu_pgsizes;
+ iommu_nr_page_bits = BITS_PER_LONG;
+
+ /* find the minimum page size and its index only once */
+ iommu_min_page_idx = find_first_bit(iommu_pgsize_bitmap,
+ iommu_nr_page_bits);
+ iommu_min_pagesz = 1 iommu_min_page_idx;
}
bool iommu_found(void)
@@ -109,26 +169,104 @@ int iommu_domain_has_cap(struct iommu_domain *domain,
EXPORT_SYMBOL_GPL(iommu_domain_has_cap);
int iommu_map(struct iommu_domain *domain, unsigned
[PATCH v3 3/6] iommu/msm: announce supported page sizes
Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes.
This way the IOMMU core can split any arbitrary-sized physically
contiguous regions (that it needs to map) as needed.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: David Brown dav...@codeaurora.org
Cc: Stepan Moskovchenko step...@codeaurora.org
---
drivers/iommu/msm_iommu.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index d1733f6..a4ed116 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -676,6 +676,9 @@ fail:
return 0;
}
+/* bitmap of the page sizes currently supported */
+static unsigned long msm_iommu_pgsizes = SZ_4K | SZ_64K | SZ_1M | SZ_16M;
+
static struct iommu_ops msm_iommu_ops = {
.domain_init = msm_iommu_domain_init,
.domain_destroy = msm_iommu_domain_destroy,
@@ -728,7 +731,10 @@ static void __init setup_iommu_tex_classes(void)
static int __init msm_iommu_init(void)
{
setup_iommu_tex_classes();
- register_iommu(msm_iommu_ops);
+
+ /* we're only using the first 25 bits of the pgsizes bitmap */
+ register_iommu_pgsize(msm_iommu_ops, msm_iommu_pgsizes, 25);
+
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/6] iommu/amd: announce supported page sizes
Let the IOMMU core know we support arbitrary page sizes (as long as
they're an order of 4KiB).
This way the IOMMU core will retain the existing behavior we're used to;
it will let us map regions that:
- their size is an order of 4KiB
- they are naturally aligned
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Joerg Roedel joerg.roe...@amd.com
---
drivers/iommu/amd_iommu.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index a14f8dc..80191d2 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2488,12 +2488,31 @@ static unsigned device_dma_ops_init(void)
}
/*
+ * This bitmap is used to advertise the page sizes our hardware support
+ * to the IOMMU core, which will then use this information to split
+ * physically contiguous memory regions it is mapping into page sizes
+ * that we support.
+ *
+ * Traditionally the IOMMU core just handed us the mappings directly,
+ * after making sure the size is an order of a 4KiB page and that the
+ * mapping has natural alignment.
+ *
+ * To retain this behavior, we currently advertise that we support
+ * all page sizes that are an order of 4KiB.
+ *
+ * If at some point we'd like to utilize the IOMMU core's new behavior,
+ * we could change this to advertise the real page sizes we support.
+ */
+static unsigned long amd_iommu_pgsizes = ~0xFFFUL;
+
+/*
* The function which clues the AMD IOMMU driver into dma_ops.
*/
void __init amd_iommu_init_api(void)
{
- register_iommu(amd_iommu_ops);
+ register_iommu_pgsize(amd_iommu_ops, amd_iommu_pgsizes,
+ BITS_PER_LONG);
}
int __init amd_iommu_init_dma_ops(void)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/6] iommu/intel: announce supported page sizes
Let the IOMMU core know we support arbitrary page sizes (as long as
they're an order of 4KiB).
This way the IOMMU core will retain the existing behavior we're used to;
it will let us map regions that:
- their size is an order of 4KiB
- they are naturally aligned
Note: Intel IOMMU hardware doesn't support arbitrary page sizes,
but the driver does (it splits arbitrary-sized mappings into
the pages supported by the hardware).
To make everything simpler for now, though, this patch effectively tells
the IOMMU core to keep giving this driver the same memory regions it did
before, so nothing is changed as far as it's concerned.
At this point, the page sizes announced remain static within the IOMMU
core. To correctly utilize the pgsize-splitting of the IOMMU core by
this driver, it seems that some core changes should still be done,
because Intel's IOMMU page size capabilities seem to have the potential
to be different between different DMA remapping devices.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: David Woodhouse dw...@infradead.org
---
drivers/iommu/intel-iommu.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c621c98..46c21a2 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3426,6 +3426,24 @@ static struct notifier_block device_nb = {
.notifier_call = device_notifier,
};
+/*
+ * This bitmap is used to advertise the page sizes our hardware support
+ * to the IOMMU core, which will then use this information to split
+ * physically contiguous memory regions it is mapping into page sizes
+ * that we support.
+ *
+ * Traditionally the IOMMU core just handed us the mappings directly,
+ * after making sure the size is an order of a 4KiB page and that the
+ * mapping has natural alignment.
+ *
+ * To retain this behavior, we currently advertise that we support
+ * all page sizes that are an order of 4KiB.
+ *
+ * If at some point we'd like to utilize the IOMMU core's new behavior,
+ * we could change this to advertise the real page sizes we support.
+ */
+static unsigned long intel_iommu_pgsizes = ~0xFFFUL;
+
int __init intel_iommu_init(void)
{
int ret = 0;
@@ -3486,7 +3504,8 @@ int __init intel_iommu_init(void)
init_iommu_pm_ops();
- register_iommu(intel_iommu_ops);
+ register_iommu_pgsize(intel_iommu_ops, intel_iommu_pgsizes,
+ BITS_PER_LONG);
bus_register_notifier(pci_bus_type, device_nb);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/6] iommu/omap: announce supported page sizes
Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes.
This way the IOMMU core can split any arbitrary-sized physically
contiguous regions (that it needs to map) as needed.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Hiroshi DOYU hiroshi.d...@nokia.com
---
drivers/iommu/omap-iommu.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 7e0188f..403dd6a 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1202,6 +1202,9 @@ static int omap_iommu_domain_has_cap(struct iommu_domain
*domain,
return 0;
}
+/* bitmap of the page sizes supported by the OMAP IOMMU hardware */
+static unsigned long omap_iommu_pgsizes = SZ_4K | SZ_64K | SZ_1M | SZ_16M;
+
static struct iommu_ops omap_iommu_ops = {
.domain_init= omap_iommu_domain_init,
.domain_destroy = omap_iommu_domain_destroy,
@@ -1225,7 +1228,8 @@ static int __init omap_iommu_init(void)
return -ENOMEM;
iopte_cachep = p;
- register_iommu(omap_iommu_ops);
+ /* we're only using the first 25 bits of the pgsizes bitmap */
+ register_iommu_pgsize(omap_iommu_ops, omap_iommu_pgsizes, 25);
return platform_driver_register(omap_iommu_driver);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/6] iommu/core: remove the temporary register_iommu_pgsize API
Now that all IOMMU drivers are converted to the new
register_iommu_pgsize() API, the old code can be removed, and
we can s/register_iommu_pgsize/register_iommu/.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: David Woodhouse dw...@infradead.org
Cc: David Brown dav...@codeaurora.org
Cc: Stepan Moskovchenko step...@codeaurora.org
---
drivers/iommu/amd_iommu.c |3 +--
drivers/iommu/intel-iommu.c |3 +--
drivers/iommu/iommu.c | 34 +-
drivers/iommu/msm_iommu.c |2 +-
drivers/iommu/omap-iommu.c |2 +-
include/linux/iommu.h |5 ++---
6 files changed, 7 insertions(+), 42 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 80191d2..cf29645 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2511,8 +2511,7 @@ static unsigned long amd_iommu_pgsizes = ~0xFFFUL;
void __init amd_iommu_init_api(void)
{
- register_iommu_pgsize(amd_iommu_ops, amd_iommu_pgsizes,
- BITS_PER_LONG);
+ register_iommu(amd_iommu_ops, amd_iommu_pgsizes, BITS_PER_LONG);
}
int __init amd_iommu_init_dma_ops(void)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 46c21a2..c013b85 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3504,8 +3504,7 @@ int __init intel_iommu_init(void)
init_iommu_pm_ops();
- register_iommu_pgsize(intel_iommu_ops, intel_iommu_pgsizes,
- BITS_PER_LONG);
+ register_iommu(intel_iommu_ops, intel_iommu_pgsizes, BITS_PER_LONG);
bus_register_notifier(pci_bus_type, device_nb);
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 7c01c8c..8bbd1aa 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -46,13 +46,8 @@ static unsigned int iommu_min_page_idx;
* @ops: iommu handlers
* @pgsize_bitmap: bitmap of page sizes supported by the hardware
* @nr_page_bits: size of @pgsize_bitmap (in bits)
- *
- * Note: this is a temporary function, which will be removed once
- * all IOMMU drivers are converted. The only reason it exists is to
- * allow splitting the pgsizes changes to several patches in order to ease
- * the review.
*/
-void register_iommu_pgsize(struct iommu_ops *ops, unsigned long *pgsize_bitmap,
+void register_iommu(struct iommu_ops *ops, unsigned long *pgsize_bitmap,
unsigned int nr_page_bits)
{
if (iommu_ops || iommu_pgsize_bitmap || !nr_page_bits)
@@ -67,33 +62,6 @@ void register_iommu_pgsize(struct iommu_ops *ops, unsigned
long *pgsize_bitmap,
iommu_min_pagesz = 1 iommu_min_page_idx;
}
-/*
- * default pagesize bitmap, will be removed once all IOMMU drivers
- * are converted
- */
-static unsigned long default_iommu_pgsizes = ~0xFFFUL;
-
-void register_iommu(struct iommu_ops *ops)
-{
- if (iommu_ops)
- BUG();
-
- iommu_ops = ops;
-
- /*
-* set default pgsize values, which retain the existing
-* IOMMU API behavior: drivers will be called to map
-* regions that are sized/aligned to order of 4KiB pages
-*/
- iommu_pgsize_bitmap = default_iommu_pgsizes;
- iommu_nr_page_bits = BITS_PER_LONG;
-
- /* find the minimum page size and its index only once */
- iommu_min_page_idx = find_first_bit(iommu_pgsize_bitmap,
- iommu_nr_page_bits);
- iommu_min_pagesz = 1 iommu_min_page_idx;
-}
-
bool iommu_found(void)
{
return iommu_ops != NULL;
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index a4ed116..e59ced9 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -733,7 +733,7 @@ static int __init msm_iommu_init(void)
setup_iommu_tex_classes();
/* we're only using the first 25 bits of the pgsizes bitmap */
- register_iommu_pgsize(msm_iommu_ops, msm_iommu_pgsizes, 25);
+ register_iommu(msm_iommu_ops, msm_iommu_pgsizes, 25);
return 0;
}
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 403dd6a..3d8ad87 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1229,7 +1229,7 @@ static int __init omap_iommu_init(void)
iopte_cachep = p;
/* we're only using the first 25 bits of the pgsizes bitmap */
- register_iommu_pgsize(omap_iommu_ops, omap_iommu_pgsizes, 25);
+ register_iommu(omap_iommu_ops, omap_iommu_pgsizes, 25);
return platform_driver_register(omap_iommu_driver);
}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 1806956..297893f 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -60,9 +60,8 @@ struct iommu_ops {
#ifdef CONFIG_IOMMU_API
-extern void register_iommu(struct iommu_ops *ops);
-extern void
Re: [PATCH 8/8] OMAP4: Fix the emif and dmm virtual mapping
Santosh Shilimkar santosh.shilim...@ti.com writes: Fix the address overlap with Emulation domain (EMU). The previous mapping was entering into EMU mapping and was not as per comments. Fix the mapping accordingly. [giris...@ti.com: Helped fixing comments.] Signed-off-by: Girish S G giris...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/plat-omap/include/plat/io.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h index d72ec85..a2f7d31 100644 --- a/arch/arm/plat-omap/include/plat/io.h +++ b/arch/arm/plat-omap/include/plat/io.h @@ -228,12 +228,12 @@ #define OMAP44XX_EMIF2_PHYS OMAP44XX_EMIF2_BASE /* 0x4d00 -- 0xfd20 */ -#define OMAP44XX_EMIF2_VIRT (OMAP44XX_EMIF2_PHYS + OMAP4_L3_PER_IO_OFFSET) +#define OMAP44XX_EMIF2_VIRT (OMAP44XX_EMIF1_VIRT + SZ_1M) IMO, this would be much clearer (and future proof) if you used '+ OMAP44XX_EMIF1_SIZE' instead of SZ_1M. #define OMAP44XX_EMIF2_SIZE SZ_1M #define OMAP44XX_DMM_PHYSOMAP44XX_DMM_BASE /* 0x4e00 -- 0xfd30 */ -#define OMAP44XX_DMM_VIRT(OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET) +#define OMAP44XX_DMM_VIRT(OMAP44XX_EMIF2_VIRT + SZ_1M) and '+ OMAP44XX_EMIF2_SIZE' here. #define OMAP44XX_DMM_SIZESZ_1M /* * Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] OMAP2+: powerdomain: control power domains next state
Jean Pihet jean.pi...@newoldbits.com writes:
When a PM QoS device latency constraint is requested or removed the
PM QoS layer notifies the underlying layer with the updated aggregated
constraint value. The constraint is stored in the powerdomain constraints
list and then applied to the corresponding power domain.
The power domains get the next power state programmed directly in the
registers via pwrdm_wakeuplat_update_pwrst.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using
wake-up latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
[...]
@@ -191,6 +198,77 @@ static int _pwrdm_post_transition_cb(struct powerdomain
*pwrdm, void *unused)
return 0;
}
+/**
+ * pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed
+ * @pwrdm: struct powerdomain * to which requesting device belongs to.
+ * @min_latency: the allowed wake-up latency for the given power domain. A
+ * value of PM_QOS_DEV_LAT_DEFAULT_VALUE means 'no constraint' on the pwrdm.
+ *
+ * Finds the power domain next power state that fulfills the constraint.
+ * Programs a new target state if it is different from current power state.
+ * The power domains get the next power state programmed directly in the
+ * registers.
+ *
+ * Returns 0 upon success.
+ */
+static int pwrdm_wakeuplat_update_pwrst(struct powerdomain *pwrdm,
+ long min_latency)
+{
+ int ret = 0, new_state = 0;
+
+ if (!pwrdm) {
+ WARN(1, powerdomain: %s: invalid parameter(s), __func__);
+ return -EINVAL;
+ }
+
+ /*
+ * Apply constraints to power domains by programming
+ * the pwrdm next power state.
+ */
+
+ /* Find power state with wakeup latency minimum constraint */
+ for (new_state = 0x0; new_state PWRDM_MAX_PWRSTS; new_state++) {
+ if (min_latency == PM_QOS_DEV_LAT_DEFAULT_VALUE ||
+ pwrdm-wakeup_lat[new_state] = min_latency)
Since min_latency is signed, this is a signed compare. In later patches
you've defined the UNSUP_STATE to be -1, which will always be =
min_latency whn using a signed compare.
So, won't this always end up picking the first state marked as
UNSUP_STATE?
+ break;
+ }
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
omap kernel mirror?
On Fri, Sep 16, 2011 at 6:33 PM, Peter Lyon lordva...@gmail.com wrote: With kernel.org down for maintenance, what is the recommended git mirror to use instead of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git? Mainline is temporarily available at https://github.com/torvalds/linux. linux-omap is temporarily available at https://github.com/tmlind/linux. Thanks, Peter -- 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] ARM: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
* DebBarma, Tarun Kanti tarun.ka...@ti.com [110916 01:56]:
[...]
1. Modify the inline access functions to take the PEND and others
if needed registers as a parameter
2. Modify mach-omap2/timer.c to initialize the PEND and others
in the SoC specific timer_init function
Just to make my understanding complete, need some clarifications:
As we would end up modifying almost all inline functions, what naming
convention should we follow for the parameters?
Well here's what I came up with to deal with the different timer
registers. We can't use the context registers as those are for
the value naturally..
But we can map the interrupt registers separately and then have
the rest start from func_base that is different based on the timer
version. Rebasing the rest of the dmtimer hwmod patches on this
should be fairly easy, mostly just need to pass timer instead of
timer-io_base and use __raw_read/write for the interrupt registers.
Also, I ended up checking the timer revision with if (!(tidr 16))
as it seems that those bits are zero for v1 timers? If that works,
then we don't need patch 02/12 for the revision number.
Afzal, care to check if that works for AM335X/TI816X/TI814X?
It tried it briefly with omap4 gptimer3 as the clockevent and
CONFIG_LOCAL_TIMER disabled.
The patch is against the current cleanup branch in linux-omap
tree.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Fri, 16 Sep 2011 15:44:20 -0700
Subject: [PATCH] ARM: OMAP: Add support for dmtimer v2 ip
The registers are slightly different between v1 and v2 ip that
is available in omap4 and later for some timers.
Add support for v2 ip by mapping the interrupt related registers
separately and adding func_base for the functional registers.
Also disable dmtimer driver features on omap4 for now as
those need the hwmod conversion series to deal with enabling
the timers properly in omap_dm_timer_init.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index cf1de7d..21d34fb 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -78,7 +78,7 @@ static irqreturn_t omap2_gp_timer_interrupt(int irq, void
*dev_id)
{
struct clock_event_device *evt = clockevent_gpt;
- __omap_dm_timer_write_status(clkev.io_base, OMAP_TIMER_INT_OVERFLOW);
+ __omap_dm_timer_write_status(clkev, OMAP_TIMER_INT_OVERFLOW);
evt-event_handler(evt);
return IRQ_HANDLED;
@@ -93,7 +93,7 @@ static struct irqaction omap2_gp_timer_irq = {
static int omap2_gp_timer_set_next_event(unsigned long cycles,
struct clock_event_device *evt)
{
- __omap_dm_timer_load_start(clkev.io_base, OMAP_TIMER_CTRL_ST,
+ __omap_dm_timer_load_start(clkev, OMAP_TIMER_CTRL_ST,
0x - cycles, 1);
return 0;
@@ -104,16 +104,16 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
{
u32 period;
- __omap_dm_timer_stop(clkev.io_base, 1, clkev.rate);
+ __omap_dm_timer_stop(clkev, 1, clkev.rate);
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
period = clkev.rate / HZ;
period -= 1;
/* Looks like we need to first set the load value separately */
- __omap_dm_timer_write(clkev.io_base, OMAP_TIMER_LOAD_REG,
+ __omap_dm_timer_write(clkev, OMAP_TIMER_LOAD_REG,
0x - period, 1);
- __omap_dm_timer_load_start(clkev.io_base,
+ __omap_dm_timer_load_start(clkev,
OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
0x - period, 1);
break;
@@ -172,6 +172,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
}
omap_hwmod_enable(oh);
+ __omap_dm_timer_init_regs(timer);
sys_timer_reserved |= (1 (gptimer_id - 1));
@@ -189,7 +190,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
clk_put(src);
}
}
- __omap_dm_timer_reset(timer-io_base, 1, 1);
+ __omap_dm_timer_reset(timer, 1, 1);
timer-posted = 1;
timer-rate = clk_get_rate(timer-fclk);
@@ -210,7 +211,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
omap2_gp_timer_irq.dev_id = (void *)clkev;
setup_irq(clkev.irq, omap2_gp_timer_irq);
- __omap_dm_timer_int_enable(clkev.io_base, OMAP_TIMER_INT_OVERFLOW);
+ __omap_dm_timer_int_enable(clkev, OMAP_TIMER_INT_OVERFLOW);
clockevent_gpt.mult = div_sc(clkev.rate, NSEC_PER_SEC,
clockevent_gpt.shift);
@@ -251,7 +252,7 @@ static struct omap_dm_timer clksrc;
static DEFINE_CLOCK_DATA(cd);
static cycle_t
[GIT PULL] omap cleanup part1 for v3.2 merge window
Hi Arnd, Please pull the first part of omap cleanup from: git://github.com/tmlind/linux.git cleanup This series cleans up early_init functions and removes CHIP_IS macro usage. This makes it easier to have SoC specific init functions so adding support for new omap variants does not require patching all over the place. Regards, Tony The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb: Linus Torvalds (1): Linux 3.1-rc6 are available in the git repository at: git://github.com/tmlind/linux.git cleanup Paul Walmsley (12): OMAP3: id: remove identification codes that only correspond to marketing names OMAP3: id: remove useless strcpy()s OMAP3: id: use explicit omap_revision codes for 3505/3517 ES levels OMAP3: id: add fallthrough warning; fix some CodingStyle issues OMAP3: id: remove duplicate code for testing SoC ES level OMAP2+: id: remove OMAP_REVBITS_* macros OMAP: clockdomain: split clkdm_init() OMAP: clockdomain code/data: remove omap_chip bitmask from struct clockdomain OMAP: powerdomain: split pwrdm_init() into two functions OMAP: powerdomain: remove omap_chip bitmasks OMAP2+: hwmod: remove OMAP_CHIP* OMAP: id: remove OMAP_CHIP declarations, code Tony Lindgren (4): omap2+: Use Kconfig symbol in Makefile instead of obj-y ARM: OMAP: Move omap2_init_common_devices out of init_early ARM: OMAP: Introduce SoC specific early_init Merge branch 'omap_chip_remove_cleanup_3.2' of git://git.pwsan.com/linux-2.6 into cleanup arch/arm/mach-omap2/Makefile | 81 +-- arch/arm/mach-omap2/board-2430sdp.c |9 +- arch/arm/mach-omap2/board-3430sdp.c |9 +- arch/arm/mach-omap2/board-3630sdp.c | 11 +- arch/arm/mach-omap2/board-4430sdp.c |9 +- arch/arm/mach-omap2/board-am3517crane.c |9 +- arch/arm/mach-omap2/board-am3517evm.c|8 +- arch/arm/mach-omap2/board-apollon.c |9 +- arch/arm/mach-omap2/board-cm-t35.c | 13 +- arch/arm/mach-omap2/board-cm-t3517.c |9 +- arch/arm/mach-omap2/board-devkit8000.c | 12 +- arch/arm/mach-omap2/board-generic.c |2 +- arch/arm/mach-omap2/board-h4.c |9 +- arch/arm/mach-omap2/board-igep0020.c | 13 +- arch/arm/mach-omap2/board-ldp.c |9 +- arch/arm/mach-omap2/board-n8x0.c | 13 +- arch/arm/mach-omap2/board-omap3beagle.c |4 +- arch/arm/mach-omap2/board-omap3evm.c |9 +- arch/arm/mach-omap2/board-omap3logic.c | 11 +- arch/arm/mach-omap2/board-omap3pandora.c | 11 +- arch/arm/mach-omap2/board-omap3stalker.c |9 +- arch/arm/mach-omap2/board-omap3touchbook.c | 11 +- arch/arm/mach-omap2/board-omap4panda.c |9 +- arch/arm/mach-omap2/board-overo.c| 11 +- arch/arm/mach-omap2/board-rm680.c| 17 +- arch/arm/mach-omap2/board-rx51.c | 17 +- arch/arm/mach-omap2/board-ti8168evm.c|9 +- arch/arm/mach-omap2/board-zoom.c | 23 +- arch/arm/mach-omap2/clock3xxx_data.c | 11 +- arch/arm/mach-omap2/clockdomain.c| 147 +++-- arch/arm/mach-omap2/clockdomain.h| 22 +- arch/arm/mach-omap2/clockdomain2xxx_3xxx.c |4 - arch/arm/mach-omap2/clockdomain44xx.c|2 - arch/arm/mach-omap2/clockdomains2420_data.c | 154 + arch/arm/mach-omap2/clockdomains2430_data.c | 181 + arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 803 +- arch/arm/mach-omap2/clockdomains3xxx_data.c | 398 +++ arch/arm/mach-omap2/clockdomains44xx_data.c | 409 +++- arch/arm/mach-omap2/id.c | 191 ++ arch/arm/mach-omap2/io.c | 52 ++- arch/arm/mach-omap2/omap_hwmod.c |3 - arch/arm/mach-omap2/omap_hwmod_2420_data.c | 37 - arch/arm/mach-omap2/omap_hwmod_2430_data.c | 45 -- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 169 +++--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 82 --- arch/arm/mach-omap2/powerdomain-common.c |7 +- arch/arm/mach-omap2/powerdomain.c| 87 ++- arch/arm/mach-omap2/powerdomain.h|9 +- arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c | 19 +- arch/arm/mach-omap2/powerdomains2xxx_data.c | 44 +- arch/arm/mach-omap2/powerdomains3xxx_data.c | 81 ++- arch/arm/mach-omap2/powerdomains44xx_data.c | 20 +- arch/arm/plat-omap/include/plat/clock.h |2 - arch/arm/plat-omap/include/plat/common.h |9 + arch/arm/plat-omap/include/plat/cpu.h| 108 +--- arch/arm/plat-omap/include/plat/io.h |2 +-
[GIT PULL] omap voltage cleanup for v3.2 merge window
Hi Arnd, Please pull omap voltage cleanup series: git://github.com/tmlind/linux.git voltage This has a dependency to the cleanup part 1 series. As this contains some voltage fixes too, it's a separate series. You can either pull it into cleanup or keep it separate. Regards, Tony The following changes since commit ceb1c532ba6220900e61ec7073a9234661efa450: Tony Lindgren (1): Merge branch 'omap_chip_remove_cleanup_3.2' of git://git.pwsan.com/linux-2.6 into cleanup are available in the git repository at: git://github.com/tmlind/linux.git voltage Benoit Cousson (1): OMAP4: powerdomain data: add voltage domains Kevin Hilman (48): OMAP2+: hwmod: remove unused voltagedomain pointer OMAP2+: voltage: move PRCM mod offets into VC/VP structures OMAP2+: voltage: move prm_irqst_reg from VP into voltage domain OMAP2+: voltage: start towards a new voltagedomain layer OMAP3: voltage: rename mpu voltagedomain to mpu_iva OMAP3: voltagedomain data: add wakeup domain OMAP3+: voltage: add scalable flag to voltagedomain OMAP2+: powerdomain: add voltagedomain to struct powerdomain OMAP2: add voltage domains and connect to powerdomains OMAP3: powerdomain data: add voltage domains OMAP2+: powerdomain: add voltage domain lookup during register OMAP2+: voltage: keep track of powerdomains in each voltagedomain OMAP2+: voltage: split voltage controller (VC) code into dedicated layer OMAP2+: voltage: move VC into struct voltagedomain, misc. renames OMAP2+: voltage: enable VC bypass scale method when VC is initialized OMAP2+: voltage: split out voltage processor (VP) code into new layer OMAP2+: VC: support PMICs with separate voltage and command registers OMAP2+: add PRM VP functions for checking/clearing VP TX done status OMAP3+ VP: replace transaction done check/clear with VP ops OMAP2+: PRM: add register access functions for VC/VP OMAP3+: voltage: convert to PRM register access functions OMAP3+: VC: cleanup i2c slave address configuration OMAP3+: VC: cleanup PMIC register address configuration OMAP3+: VC bypass: use fields from VC struct instead of PMIC info OMAP3+: VC: cleanup voltage setup time configuration OMAP3+: VC: move on/onlp/ret/off command configuration into common init OMAP3+: VC: abstract out channel configuration OMAP3+: voltage domain: move PMIC struct from vdd_info into struct voltagedomain OMAP3+: VC: make I2C config programmable with PMIC-specific settings OMAP3+: PM: VC: handle mutant channel config for OMAP4 MPU channel OMAP3+: VC: use last nominal voltage setting to get current_vsel OMAP3+: VP: cleanup: move VP instance into voltdm, misc. renames OMAP3+: voltage: remove unneeded debugfs interface OMAP3+: VP: struct omap_vp_common: replace shift with __ffs(mask) OMAP3+: VP: move SoC-specific sys clock rate retreival late init OMAP3+: VP: move timing calculation/config into VP init OMAP3+: VP: create VP helper function for updating error gain OMAP3+: VP: remove omap_vp_runtime_data OMAP3+: VP: move voltage scale function pointer into struct voltagedomain OMAP3+: VP: update_errorgain(): return error if VP OMAP3+: VP: remove unused omap_vp_get_curr_volt() OMAP3+: VP: combine setting init voltage into common function OMAP3+: voltage: rename scale and reset functions using voltdm_ prefix OMAP3+: voltage: move/rename curr_volt from vdd_info into struct voltagedomain OMAP3+: voltdm: final removal of omap_vdd_info OMAP3+: voltage: rename omap_voltage_get_nom_volt - voltdm_get_voltage OMAP3+: voltage: update nominal voltage in voltdm_scale() not VC post-scale OMAP2+: VC: more registers are per-channel starting with OMAP5 Nishanth Menon (3): OMAP4: PM: TWL6030: fix uv to voltage for 0x39 OMAP4: PM: TWL6030: address 0V conversions OMAP4: PM: TWL6030: add cmd register Patrick Titiano (2): OMAP4: PM: TWL6030: fix voltage conversion formula OMAP4: PM: TWL6030: fix ON/RET/OFF voltages Tero Kristo (1): omap: voltage: add a stub header file for external/regulator use Todd Poynor (1): OMAP: VP: Explicitly mask VPVOLTAGE field Tony Lindgren (1): Merge branch 'for_3.2/voltage-cleanup' of git://gitorious.org/khilman/linux-omap-pm into voltage arch/arm/mach-omap2/Makefile |5 +- arch/arm/mach-omap2/io.c |5 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4 +- arch/arm/mach-omap2/omap_twl.c | 107 ++- arch/arm/mach-omap2/pm.c |6 +- arch/arm/mach-omap2/powerdomain.c| 23 + arch/arm/mach-omap2/powerdomain.h| 10 + arch/arm/mach-omap2/powerdomain2xxx_3xxx.c |2 +- arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |
