devkit8000 omap3stalker LCD panel
Hi Thomas, Jason, I noticed that both devkit8000 and omap3stalker boards use the generic dpi driver for LCD. Why is that? If the boards have a normal fixed resolution LCD, the timings for the LCD should be added to the panel-generic-dpi.c. 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
Re: [PATCH v2 03/10] OMAP4: DSS: HDMI: Use specific HDMI timings structure
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com Define new HDMI timings structure to replace the OMAP DSS timing strucutre in hdmi.c to have the HDMI include defintion out of DSS. structure and definition typoed. And the point is not to remove hdmi stuff from dss, but dss stuff from hdmi. The generic hdmi driver cannot use omap dss specific stuff. Signed-off-by: Mythri P K mythr...@ti.com --- drivers/video/omap2/dss/hdmi.c | 22 +++--- drivers/video/omap2/dss/hdmi.h | 15 ++- 2 files changed, 33 insertions(+), 4 deletions(-) diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c index 084a47e..ba1ad06 100644 --- a/drivers/video/omap2/dss/hdmi.c +++ b/drivers/video/omap2/dss/hdmi.c @@ -537,6 +537,20 @@ static int read_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length) return 0; } +static void copy_hdmi_to_dss_timings(struct hdmi_video_timings hdmi_timings, + struct omap_video_timings *timings) Pass hdmi_timings as a const pointer. 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
Re: [PATCH v2 02/10] OMAP4: DSS: HDMI: Move pll and video configuration
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
As the pll and the video configuration info are part of the ip_data those
structures are moved to the ip_data strtucure.Also the functions are modified
accordingly to take care of this movement.
structure typoed, and use a space after period.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 34 +++---
drivers/video/omap2/dss/hdmi.h | 18 ++
2 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 544f93e..084a47e 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -59,7 +59,6 @@ static struct {
u8 edid[HDMI_EDID_MAX_LENGTH];
u8 edid_set;
bool custom_set;
- struct hdmi_config cfg;
struct clk *sys_clk;
} hdmi;
@@ -230,11 +229,11 @@ int hdmi_init_display(struct omap_dss_device *dssdev)
}
static int hdmi_pll_init(struct hdmi_ip_data *ip_data,
- enum hdmi_clk_refsel refsel, int dcofreq,
- struct hdmi_pll_info *fmt, u16 sd)
+ enum hdmi_clk_refsel refsel)
{
u32 r;
void __iomem *pll_base = hdmi_pll_base(ip_data);
+ struct hdmi_pll_info *fmt = ip_data-pll_data;
/* PLL start always use manual mode */
REG_FLD_MOD(pll_base, PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
@@ -251,9 +250,9 @@ static int hdmi_pll_init(struct hdmi_ip_data *ip_data,
r = FLD_MOD(r, 0x1, 13, 13); /* PLL_REFEN */
r = FLD_MOD(r, 0x0, 14, 14); /* PHY_CLKINEN de-assert during locking */
- if (dcofreq) {
+ if (fmt-dcofreq) {
/* divider programming for frequency beyond 1000Mhz */
- REG_FLD_MOD(pll_base, PLLCTRL_CFG3, sd, 17, 10);
+ REG_FLD_MOD(pll_base, PLLCTRL_CFG3, fmt-regsd, 17, 10);
r = FLD_MOD(r, 0x4, 3, 1); /* 1000MHz and 2000MHz */
} else {
r = FLD_MOD(r, 0x2, 3, 1); /* 500MHz and 1000MHz */
@@ -379,8 +378,7 @@ static int hdmi_phy_init(struct hdmi_ip_data *ip_data)
return 0;
}
-static int hdmi_pll_program(struct hdmi_ip_data *ip_data,
- struct hdmi_pll_info *fmt)
+static int hdmi_pll_program(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
enum hdmi_clk_refsel refsel;
@@ -399,7 +397,7 @@ static int hdmi_pll_program(struct hdmi_ip_data *ip_data,
refsel = HDMI_REFSEL_SYSCLK;
- r = hdmi_pll_init(ip_data, refsel, fmt-dcofreq, fmt, fmt-regsd);
+ r = hdmi_pll_init(ip_data, refsel);
I don't think I quite understood why refsel is not part of the pll info.
And if it has to be hardcoded, you could as well do that in
hdmi_pll_init().
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
Re: [PATCH v2 07/10] OMAP4: DSS2: HDMI: Provide a wrapper API to configure
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com Instead of DSS knowing of the interior IP driver function provide a wrapper API to configure. This commit message doesn't make much sense. What you do in this patch is just rename the functions, and add the hdmi_pll_disable function. 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
Re: [PATCH v2 08/10] OMAP4: DSS2: HDMI: Function pointer approach to call
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
To make the current hdmi DSS driver compatible with future OMAP with different
IP blocks , add HDMI as a feature in dss_features and abstract the internal
function in hdmi dss driver.
No space before comma.
The description could use some improvement, HDMI is not a feature in
dss_features, and I don't understand what the rest of the sentence
means.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss_features.c | 24 +++-
drivers/video/omap2/dss/dss_features.h |1 +
drivers/video/omap2/dss/hdmi.c | 22 +++---
include/video/omapdss.h| 19 +++
include/video/omaphdmi.h |1 +
5 files changed, 55 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index b63c5f8..edf2929 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -429,6 +429,26 @@ static const struct omap_dss_features omap4_dss_features
= {
.burst_size_unit = 16,
};
+const struct omap_hdmi_ip_driver *omap_hdmi_functions;
Should be static, but considering you never use this variable, except to
assign it once, it should be removed.
+
+/* HDMI OMAP4 Functions*/
+const struct omap_hdmi_ip_driver omap4_hdmi_functions = {
Should be static.
+
+ .video_configure= hdmi_basic_configure,
+ .phy_enable = hdmi_phy_enable,
+ .phy_disable= hdmi_phy_disable,
+ .read_edid = read_edid,
+ .pll_enable = hdmi_pll_enable,
+ .pll_disable= hdmi_pll_disable,
+ .video_enable = hdmi_wp_video_start,
+};
Check that this compiles if HDMI is disabled.
+
+void dss_hdmi_features_init(struct hdmi_ip_data *ip_data)
Perhaps something like dss_init_hdmi_ip_data() would be better?
+{
+ if (cpu_is_omap44xx())
+ ip_data-hdmi_ops = omap4_hdmi_functions;
+}
+
/* Functions returning values related to a DSS feature */
int dss_feat_get_num_mgrs(void)
{
@@ -512,8 +532,10 @@ void dss_features_init(void)
omap_current_dss_features = omap3430_dss_features;
else if (omap_rev() == OMAP4430_REV_ES1_0)
omap_current_dss_features = omap4430_es1_0_dss_features;
- else if (cpu_is_omap44xx())
+ else if (cpu_is_omap44xx()) {
omap_current_dss_features = omap4_dss_features;
+ omap_hdmi_functions = omap4_hdmi_functions;
No need for this code.
+ }
else
DSSWARN(Unsupported OMAP version);
}
diff --git a/drivers/video/omap2/dss/dss_features.h
b/drivers/video/omap2/dss/dss_features.h
index 4271e96..ca64b21 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -99,4 +99,5 @@ u32 dss_feat_get_burst_size_unit(void); /* in
bytes */
bool dss_has_feature(enum dss_feat_id id);
void dss_feat_get_reg_field(enum dss_feat_reg_field id, u8 *start, u8 *end);
void dss_features_init(void);
+void dss_hdmi_features_init(struct hdmi_ip_data *ip_data);
#endif
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index fb7d66f..c508cf6 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -184,7 +184,7 @@ static void hdmi_runtime_put(void)
int hdmi_init_display(struct omap_dss_device *dssdev)
{
DSSDBG(init_display\n);
-
+ dss_hdmi_features_init(hdmi.hdmi_data);
return 0;
}
@@ -364,8 +364,8 @@ static void hdmi_read_edid(struct omap_video_timings *dp)
memset(hdmi.edid, 0, HDMI_EDID_MAX_LENGTH);
if (!hdmi.edid_set)
- ret = read_edid(hdmi.hdmi_data, hdmi.edid,
- HDMI_EDID_MAX_LENGTH);
+ ret = hdmi.hdmi_data.hdmi_ops-read_edid(hdmi.hdmi_data,
+ hdmi.edid, HDMI_EDID_MAX_LENGTH);
hdmi_ops could be just ops, there's no possibility to confuse it with
some other ops.
if (!ret) {
if (!memcmp(hdmi.edid, edid_header, sizeof(edid_header))) {
/* search for timings of default resolution */
@@ -475,16 +475,16 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
hdmi_compute_pll(dssdev, phy, hdmi.hdmi_data.pll_data);
- hdmi_wp_video_start(hdmi.hdmi_data, 0);
+ hdmi.hdmi_data.hdmi_ops-video_enable(hdmi.hdmi_data, 0);
/* config the PLL and PHY hdmi_set_pll_pwrfirst */
- r = hdmi_pll_enable(hdmi.hdmi_data);
+ r = hdmi.hdmi_data.hdmi_ops-pll_enable(hdmi.hdmi_data);
if (r) {
DSSDBG(Failed to lock PLL\n);
goto err;
}
- r = hdmi_phy_enable(hdmi.hdmi_data);
+
Re: [PATCH v2 04/10] OMAP4: DSS: HDMI: Move the common header file
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com Some of the header file definitions of HDMI IP are needed by audio driver thus moving the common defintion to more generic Include/video. Signed-off-by: Mythri P K mythr...@ti.com --- drivers/video/omap2/dss/dss.h | 10 - drivers/video/omap2/dss/hdmi.c |1 + drivers/video/omap2/dss/hdmi.h | 53 include/video/omaphdmi.h | 86 4 files changed, 87 insertions(+), 63 deletions(-) create mode 100644 include/video/omaphdmi.h As the functions will be renamed to hdmi_ti_4xxx_*, perhaps the header file is a bit misnamed. Also, please first do the changes/renamings/etc, and only then move the finished header file to include/video/ to prevent unnecessary changes in include/video. 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
Re: [PATCH] iommu: omap_iovmm: support non page-aligned buffers in iommu_vmap
On Wed, Aug 31, 2011 at 12:56:26PM -0400, Laurent Pinchart wrote: True, but if we implement address rounding transparently in the IOMMU layer Ohad's concern can be valid, depending on whether the device is trusted. If we decide to push address rounding to the drivers that decision can be made on a per-device basis. However, drivers are usually not aware of what granularity the IOMMU works on, so that wouldn't be straightforward and clean. Drivers usually just use the DMA-API, so they can not assume at all that any protection happens. The problem also can't be really solved without changing/breaking the DMA-API. It is defined to work on byte granularity while the hardware only works with pages. The only way to work around this it to implement the driver in a way so that they only map page-aligned buffers where the size is also a multiple of a page-size. In this case you can assume the page-size you are working on because you already assume in the driver that an iommu is in use. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
Hi Marc, On 31/08/11 17:55, Marc Dietrich wrote: Am Mittwoch 31 August 2011, 18:12:48 schrieb Marc Zyngier: [...] Oddly enough, this patch doesn't do anything on my Tegra setup. In both cases, I get around 17MB/s from a crap SD card plugged in a USB reader. This leads me to suspect that this issue is very much OMAP4 specific. Can anyone verify this theory on other some A9 platforms? That's odd. On my Tegra2 (on ac100) it boosts the transfer rate from 7 to 17 MB/s. I'm using a Harmony board. Could you share your kernel version, .config and dmesg? Thanks, M. -- Jazz is not dead. It just smells funny... -- 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] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
Hi Marc, ^dito, On 31/08/11 17:55, Marc Dietrich wrote: Am Mittwoch 31 August 2011, 18:12:48 schrieb Marc Zyngier: [...] Oddly enough, this patch doesn't do anything on my Tegra setup. In both cases, I get around 17MB/s from a crap SD card plugged in a USB reader. This leads me to suspect that this issue is very much OMAP4 specific. Can anyone verify this theory on other some A9 platforms? That's odd. On my Tegra2 (on ac100) it boosts the transfer rate from 7 to 17 MB/s. I'm using a Harmony board. Could you share your kernel version, .config and dmesg? Thanks, M. I use the chromiumos tree (for chromiumos 2.6.38 kernel: http://git.chromium.org/chromiumos/third_party/kernel-next.git) with some additions to make it run on the AC100. This modified tree is on git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git. The config is paz00_defconfig and a dmesg you can get e.g. from http://pastebin.com/9uVfDWma (it's not very current, but it should be sufficient). I'll add Stephen Warren from NVIDIA to the CC list. He has more HW to test on. Btw, this is the patch I used: http://gitorious.org/~marvin24/ac100/marvin24s- kernel/commit/cce8d9e25d009a45c219a6ad0b9ac4e27d034ab0 Marc -- 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_iovmm: support non page-aligned buffers in iommu_vmap
On Wed, Aug 31, 2011 at 1:52 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures (i.e. whenever the buffer passed from userspace is not
page-aligned).
Remove this limitation by rounding the address of the first page entry
down, and adding the offset back to the device address.
Seems like the unmap paths were skipped (need to adjust the sizes in
the unmap path too).
Laurent, if it looks good to you, I'll just squash it to the original
patch and repost:
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index d28a256..39bdb92 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -447,7 +447,7 @@ err_out:
for_each_sg(sgt-sgl, sg, i, j) {
size_t bytes;
- bytes = sg-length;
+ bytes = sg-length + sg-offset;
order = get_order(bytes);
/* ignore failures.. we're already handling one */
@@ -476,7 +476,7 @@ static void unmap_iovm_area(struct iommu_domain *domain, str
size_t bytes;
int order;
- bytes = sg-length;
+ bytes = sg-length + sg-offset;
order = get_order(bytes);
err = iommu_unmap(domain, start, order);
--
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/7] OMAP: PM: omap_device: add omap_hwmod_name_get_odev
On 9/1/2011 12:20 AM, Hilman, Kevin wrote:
Benoit Coussonb-cous...@ti.com writes:
From: Nishanth Menonn...@ti.com
An API which translates a standard hwmod name to corresponding
omap_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back into the device
structure pointers. These ideally should be used by drivers in
mach directory. Using a generic hwmod name like gpu instead of
the actual device name which could change in the future, allows
us to:
a) Could in effect help replace apis such as omap2_get_mpuss_device,
omap2_get_iva_device, omap2_get_l3_device, omap4_get_dsp_device,
etc..
b) Scale to more devices rather than be restricted to named functions
c) Simplify driver's platform_data from passing additional fields
all doing the same thing with different function pointer names
just for accessing a different device name.
Signed-off-by: Nishanth Menonn...@ti.com
[b-cous...@ti.com: rebased on top of Kevin's changes]
Signed-off-by: Benoit Coussonb-cous...@ti.com
OK, I cerainly like this better than the omap2_get_*_device APIs, but
I don't see the point in returning an omap_device pointer.
That's a good point.
Nishanth,
Do you have any objection to replace that API with omap_hwmod_name_get_pdev?
In my series, I tried to make all the OMAP device APIs return/use a
platform_device pointer instead of an omap_device pointer, so I'd rather
just see this return the platform_device pointer directly.
It make sense to me.
Thanks,
Benoit
Kevin
---
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/omap_device.c | 32 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index d4d9b96..bdc2804 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -101,6 +101,7 @@ struct platform_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
int pm_lats_cnt, int is_early_device);
void __iomem *omap_device_get_rt_va(struct omap_device *od);
+struct omap_device *omap_hwmod_name_get_odev(const char *oh_name);
/* OMAP PM interface */
int omap_device_align_pm_lat(struct platform_device *pdev,
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d8f2299..455594a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -840,6 +840,38 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od)
return omap_hwmod_get_mpu_rt_va(od-hwmods[0]);
}
+/**
+ * omap_hwmod_name_get_odev() - convert a hwmod name to omap_device pointer
+ * @oh_name: name of the hwmod device
+ *
+ * returns back a struct omap_device * pointer associated with a hwmod
+ * device represented by a hwmod_name
+ */
+struct omap_device *omap_hwmod_name_get_odev(const char *oh_name)
+{
+ struct omap_hwmod *oh;
+
+ if (!oh_name) {
+ WARN(1, %s: no hwmod name!\n, __func__);
+ return ERR_PTR(-EINVAL);
+ }
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (IS_ERR_OR_NULL(oh)) {
+ WARN(1, %s: no hwmod for %s\n, __func__,
+ oh_name);
+ return ERR_PTR(oh ? PTR_ERR(oh) : -ENODEV);
+ }
+ if (IS_ERR_OR_NULL(oh-od)) {
+ WARN(1, %s: no omap_device for %s\n, __func__,
+ oh_name);
+ return ERR_PTR(oh-od ? PTR_ERR(oh-od) : -ENODEV);
+ }
+
+ return oh-od;
+}
+EXPORT_SYMBOL(omap_hwmod_name_get_odev);
+
/*
* Public functions intended for use in omap_device_pm_latency
* .activate_func and .deactivate_func function pointers
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] OMAP: PM: omap_device: add few quick access functions
On 9/1/2011 12:23 AM, Hilman, Kevin wrote:
Benoit Coussonb-cous...@ti.com writes:
From: Nishanth Menonn...@ti.com
Provide a quick set of access functions:
a) Convert omap_device to platform_device - This is the flip of
to_omap_device for equivalent usage
b) Convert omap_device to device pointer - This is useful for
most devices that need to go through standard linux functions that
take device pointer.
c) Convert hwmod to device pointer - This wrapper provides ability for
drivers to convert directly from hwmod name back to device pointer
without having to handle this on a driver by driver basis
Signed-off-by: Nishanth Menonn...@ti.com
[b-cous...@ti.com: Adapt it to the new pdev pointer inside od]
Signed-off-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index bdc2804..903f329 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -152,6 +152,21 @@ static inline struct omap_device *to_omap_device(struct
platform_device *pdev)
return pdev ? pdev-archdata.od : NULL;
}
+/* Convert omap_device to platform device pointer */
+#define omap_device_get_pdev(x) ((x)-pdev)
+/* Convert omap_device to device pointer */
+#define omap_device_get_dev(x) (omap_device_get_pdev(x)-dev)
I don't see these used elsewhere, and I don't think they're needed...
Well, there are used once... just below, and that's all.
+/* Convert omap_hwmod name to device pointer */
+static inline struct device *omap_hwmod_name_get_dev(const char *oh_name)
+{
+ struct omap_device *od;
+ od = omap_hwmod_name_get_odev(oh_name);
+ if (IS_ERR_OR_NULL(od))
+ return ERR_PTR(od ? PTR_ERR(od) : -ENODEV);
+ return omap_device_get_dev(od);
+}
+
I will let Nishant comment, but I guess the idea was that an omap_device
API should handle omap_device pointer, and then access to pdev or dev is
done using these helpers.
Assuming that now omap_device API should preferably use pdev, we can
remove one step of indirection and thus get rid of the helpers, since
they are not used anywhere else.
After comments on patch 1 are addressed, the
pdev = omap_hwmod_name_get_pdev(oh_name)
returnpdev-dev;
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] OMAP2+: devices: Remove all omap_device_pm_latency structures
On 9/1/2011 12:31 AM, Hilman, Kevin wrote: Benoit Coussonb-cous...@ti.com writes: Remove all these duplicated structures since a default one is now available. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Kevin Hilmankhil...@ti.com --- arch/arm/mach-omap2/devices.c| 46 +++-- arch/arm/mach-omap2/display.c| 11 + arch/arm/mach-omap2/dma.c| 11 + arch/arm/mach-omap2/gpio.c | 12 +- arch/arm/mach-omap2/hsmmc.c | 18 +-- arch/arm/mach-omap2/hwspinlock.c | 12 +- arch/arm/mach-omap2/mcbsp.c | 11 + arch/arm/mach-omap2/serial.c | 25 +--- arch/arm/mach-omap2/sr_device.c | 11 + arch/arm/mach-omap2/usb-musb.c | 11 + arch/arm/plat-omap/i2c.c | 10 +--- 11 files changed, 14 insertions(+), 164 deletions(-) Nice! queuing this for v3.2 (branch: for_3.2/omap_device) Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] Add L2 cache cleaning to generic CPU suspend
Some systems (such as OMAP) preserve the L2 cache across a suspend/ resume cycle. This means they do not perform L2 cache maintanence in their suspend finisher function. However, the side effect is that the saved CPU state is not readable by the resume code because it is sitting in the L2 cache. This patch series adds L2 cache cleaning to the generic CPU suspend/ resume support code, making it possible to use this on systems with L2 cache enabled without having to clean/invalidate the entire L2 cache. We also add a separate page table, allocated at boot time, for the resume process to use so we don't have to fiddle about with tweaking entries in the current processes page table. Moreover, the current processes page table may be in use by another CPU in the system if these paths are used from cpuidle or hotplug, so changing the page table is technically unsound. Overall, this makes it possible for OMAP4 systems to use this code. The first four patches in this set are already merged into Linus' tree as bug fixes, and are included here for completeness given that the kernel.org infrastructure is currently offline. This has (so far) only been tested on OMAP4. Further testing on OMAP3 and Assabet will follow. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] ARM: pm: CPU specific code should not overwrite r1 (v:p offset)
r1 stores the v:p offset from the CPU invariant resume code, and is
expected to be preserved by the CPU specific code. Overwriting it is
not a good idea.
We've managed to get away with it on sa1100 platforms because most
happen to have PHYS_OFFSET == PAGE_OFFSET, but that may not be the
case depending on kernel configuration. So fix this latent bug.
This fixes xsc3 as well which was saving and restoring this register
independently.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/proc-sa1100.S | 10 +-
arch/arm/mm/proc-xsc3.S |6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mm/proc-sa1100.S b/arch/arm/mm/proc-sa1100.S
index 07219c2..69e7f2e 100644
--- a/arch/arm/mm/proc-sa1100.S
+++ b/arch/arm/mm/proc-sa1100.S
@@ -182,11 +182,11 @@ ENDPROC(cpu_sa1100_do_suspend)
ENTRY(cpu_sa1100_do_resume)
ldmia r0, {r4 - r7} @ load cp regs
- mov r1, #0
- mcr p15, 0, r1, c8, c7, 0 @ flush I+D TLBs
- mcr p15, 0, r1, c7, c7, 0 @ flush ID cache
- mcr p15, 0, r1, c9, c0, 0 @ invalidate RB
- mcr p15, 0, r1, c9, c0, 5 @ allow user space to use RB
+ mov ip, #0
+ mcr p15, 0, ip, c8, c7, 0 @ flush I+D TLBs
+ mcr p15, 0, ip, c7, c7, 0 @ flush ID cache
+ mcr p15, 0, ip, c9, c0, 0 @ invalidate RB
+ mcr p15, 0, ip, c9, c0, 5 @ allow user space to use RB
mcr p15, 0, r4, c3, c0, 0 @ domain ID
mcr p15, 0, r5, c2, c0, 0 @ translation table base addr
diff --git a/arch/arm/mm/proc-xsc3.S b/arch/arm/mm/proc-xsc3.S
index 28c72a2..755e1bf 100644
--- a/arch/arm/mm/proc-xsc3.S
+++ b/arch/arm/mm/proc-xsc3.S
@@ -406,7 +406,7 @@ ENTRY(cpu_xsc3_set_pte_ext)
.align
.globl cpu_xsc3_suspend_size
-.equ cpu_xsc3_suspend_size, 4 * 8
+.equ cpu_xsc3_suspend_size, 4 * 7
#ifdef CONFIG_PM_SLEEP
ENTRY(cpu_xsc3_do_suspend)
stmfd sp!, {r4 - r10, lr}
@@ -418,12 +418,12 @@ ENTRY(cpu_xsc3_do_suspend)
mrc p15, 0, r9, c1, c0, 1 @ auxiliary control reg
mrc p15, 0, r10, c1, c0, 0 @ control reg
bic r4, r4, #2 @ clear frequency change bit
- stmia r0, {r1, r4 - r10} @ store v:p offset + cp regs
+ stmia r0, {r4 - r10} @ store cp regs
ldmia sp!, {r4 - r10, pc}
ENDPROC(cpu_xsc3_do_suspend)
ENTRY(cpu_xsc3_do_resume)
- ldmia r0, {r1, r4 - r10} @ load v:p offset + cp regs
+ ldmia r0, {r4 - r10} @ load cp regs
mov ip, #0
mcr p15, 0, ip, c7, c7, 0 @ invalidate I D caches, BTB
mcr p15, 0, ip, c7, c10, 4 @ drain write (fill) buffer
--
1.7.4.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: devkit8000 omap3stalker LCD panel
Am 01.09.2011 08:42, schrieb Tomi Valkeinen: Hi Thomas, Jason, I noticed that both devkit8000 and omap3stalker boards use the generic dpi driver for LCD. Why is that? If the boards have a normal fixed resolution LCD, the timings for the LCD should be added to the panel-generic-dpi.c. Tomi Hello Tomi, I will send a patch that adds support for the devkit8000 panel. Thomas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP: DSS2: Support for Innolux AT070TN83
Add support for Innolux AT070TN83, a 7 inch LCD
with RGB-Interface and touch panel to panel-generic-dpi.
Tested with Devkit8000.
Signed-off-by: Thomas Weber we...@corscience.de
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 ++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 9c90f75..b401304 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -232,6 +232,31 @@ static struct panel_config generic_dpi_panels[] = {
.power_off_delay= 0,
.name = powertip_ph480272t,
},
+
+ /* Innolux AT070TN83 */
+ {
+ {
+ .x_res = 800,
+ .y_res = 480,
+
+ .pixel_clock= 4,
+
+ .hsw= 48,
+ .hfp= 1,
+ .hbp= 1,
+
+ .vsw= 3,
+ .vfp= 12,
+ .vbp= 25,
+ },
+ .acbi = 0x0,
+ .acb= 0x28,
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS,
+ .power_on_delay = 0,
+ .power_off_delay= 0,
+ .name = innolux_at070tn83,
+ },
};
struct panel_drv_data {
--
1.7.6.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/3] OMAP: Devkit8000: Change lcd driver to AT070TN83
Change lcd driver from generic to AT070TN83.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 4b1f6c6..a3b8e81 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -139,7 +139,7 @@ static struct regulator_consumer_supply
devkit8000_vio_supply[] = {
};
static struct panel_generic_dpi_data lcd_panel = {
- .name = generic,
+ .name = innolux_at070tn83,
.platform_enable= devkit8000_panel_enable_lcd,
.platform_disable = devkit8000_panel_disable_lcd,
};
--
1.7.6.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 10/10] OMAP: DSS2: DSI Video mode support
On Tue, 2011-08-30 at 16:21 +0530, Archit Taneja wrote:
Add initial support for DSI video mode panels:
- Add a new structure omap_dss_dsi_videomode_data in the member panel in
omap_dss_device struct. This allows panel driver to configure dsi video_mode
specific parameters.
- Configure basic DSI video mode timing parameters: HBP, HFP, HSA, VBP, VFP,
VSA,
TL and VACT.
- Configure DSI protocol engine registers for video_mode support.
- Introduce functions dsi_video_mode_enable() and dsi_video_mode_disable()
which
enable/disable video mode for a given virtual channel and a given pixel
format
type.
Things left for later
- Add functions to check for errors in video mode timings provided by panel.
- Configure timing registers required for command mode interleaving.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 256
-
include/video/omapdss.h | 32 +
2 files changed, 259 insertions(+), 29 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 582ae7b..e3d5c38 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -132,7 +132,7 @@ struct dsi_reg { u16 idx; };
#define DSI_IRQ_TA_TIMEOUT (1 20)
#define DSI_IRQ_ERROR_MASK \
(DSI_IRQ_HS_TX_TIMEOUT | DSI_IRQ_LP_RX_TIMEOUT | DSI_IRQ_SYNC_LOST | \
- DSI_IRQ_TA_TIMEOUT)
+ DSI_IRQ_TA_TIMEOUT | DSI_IRQ_SYNC_LOST)
#define DSI_IRQ_CHANNEL_MASK 0xf
/* Virtual channel interrupts */
@@ -2472,6 +2472,12 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
dsi_cio_timings(dsidev);
+ if (dssdev-panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ /* DDR_CLK_ALWAYS_ON */
+ REG_FLD_MOD(dsidev, DSI_CLK_CTRL,
+ dssdev-panel.dsi_vm_data.ddr_clk_always_on, 13, 13);
+ }
+
For the DDR clock to start, you need to send a null packet, don't you?
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
RE: [PATCH] omap_vout: fix section mismatch in probe function
-Original Message-
From: Maupin, Chase
Sent: Friday, August 26, 2011 11:10 AM
To: linux-omap@vger.kernel.org
Cc: Maupin, Chase
Subject: [PATCH] omap_vout: fix section mismatch in probe function
Building the OMAP vout driver resulted in the following message:
WARNING: vmlinux.o(.data+0x38084): Section mismatch in reference
from the variable omap_vout_driver to the function
.init.text:omap_vout_probe()
The variable omap_vout_driver references
the function __init omap_vout_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name
the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one,
*_console
Signed-off-by: Chase Maupin chase.mau...@ti.com
Just wanted to ping on this patch. Are there any issues?
---
drivers/media/video/omap/omap_vout.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index b3a5ecd..9b5dad5 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2133,7 +2133,7 @@ static int omap_vout_remove(struct
platform_device *pdev)
return 0;
}
-static int __init omap_vout_probe(struct platform_device *pdev)
+static int omap_vout_probe(struct platform_device *pdev)
{
int ret = 0, i;
struct omap_overlay *ovl;
--
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] iommu: omap_iovmm: support non page-aligned buffers in iommu_vmap
Hi Ohad,
On Thursday 01 September 2011 13:47:26 Ohad Ben-Cohen wrote:
On Wed, Aug 31, 2011 at 1:52 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures (i.e. whenever the buffer passed from userspace is not
page-aligned).
Remove this limitation by rounding the address of the first page entry
down, and adding the offset back to the device address.
Seems like the unmap paths were skipped (need to adjust the sizes in
the unmap path too).
Laurent, if it looks good to you, I'll just squash it to the original
patch and repost:
Do you have a tree where the current code base can be found ?
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index d28a256..39bdb92 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -447,7 +447,7 @@ err_out:
for_each_sg(sgt-sgl, sg, i, j) {
size_t bytes;
- bytes = sg-length;
+ bytes = sg-length + sg-offset;
order = get_order(bytes);
/* ignore failures.. we're already handling one */
@@ -476,7 +476,7 @@ static void unmap_iovm_area(struct iommu_domain
*domain, str size_t bytes;
int order;
- bytes = sg-length;
+ bytes = sg-length + sg-offset;
order = get_order(bytes);
err = iommu_unmap(domain, start, order);
--
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: [PATCH] iommu: omap_iovmm: support non page-aligned buffers in iommu_vmap
On Thu, Sep 01, 2011 at 09:31:13AM -0400, Laurent Pinchart wrote: Hi Ohad, On Thursday 01 September 2011 13:47:26 Ohad Ben-Cohen wrote: On Wed, Aug 31, 2011 at 1:52 PM, Ohad Ben-Cohen o...@wizery.com wrote: From: Laurent Pinchart laurent.pinch...@ideasonboard.com omap_iovmm requires page-aligned buffers, and that sometimes causes omap3isp failures (i.e. whenever the buffer passed from userspace is not page-aligned). Remove this limitation by rounding the address of the first page entry down, and adding the offset back to the device address. Seems like the unmap paths were skipped (need to adjust the sizes in the unmap path too). Laurent, if it looks good to you, I'll just squash it to the original patch and repost: Do you have a tree where the current code base can be found ? Please base your upstream-patches against git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git arm/omap Thanks, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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_iovmm: support non page-aligned buffers in iommu_vmap
Hi Ohad,
On Thursday 01 September 2011 13:47:26 Ohad Ben-Cohen wrote:
On Wed, Aug 31, 2011 at 1:52 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures (i.e. whenever the buffer passed from userspace is not
page-aligned).
Remove this limitation by rounding the address of the first page entry
down, and adding the offset back to the device address.
Seems like the unmap paths were skipped (need to adjust the sizes in
the unmap path too).
Laurent, if it looks good to you, I'll just squash it to the original
patch and repost:
It looks good to me. I haven't tested it though.
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index d28a256..39bdb92 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -447,7 +447,7 @@ err_out:
for_each_sg(sgt-sgl, sg, i, j) {
size_t bytes;
- bytes = sg-length;
+ bytes = sg-length + sg-offset;
order = get_order(bytes);
/* ignore failures.. we're already handling one */
@@ -476,7 +476,7 @@ static void unmap_iovm_area(struct iommu_domain
*domain, str size_t bytes;
int order;
- bytes = sg-length;
+ bytes = sg-length + sg-offset;
order = get_order(bytes);
err = iommu_unmap(domain, start, order);
--
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: [PATCHv6 01/11] omap: prcm: switch to a chained IRQ handler mechanism
Hey Paul, I've been looking at this now and got one question below. Otherwise your comments look okay to me and I can work with those. On Fri, 2011-08-26 at 11:12 +0200, Paul Walmsley wrote: Hello Tero, a few comments on this patch: On Mon, 25 Jul 2011, Tero Kristo wrote: 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. arch/arm/mach-omap2/prcm.c implements the chained interrupt mechanism itself, with SoC specific support / init structure defined in arch/arm/mach-omap2/prm2xxx_3xxx.c and arch/arm/mach-omap2/prm4xxx.c respectively. At initialization time, the set of PRCM events is filtered against the SoC on which we are running, keeping only the ones that are actually useful. All the logic is written to be generic with regard to OMAP3/OMAP4, even though OMAP3 has single PRCM event registers and OMAP4 has two PRCM event registers. Looking over this patch, it seems that this functionality should be part of a PRM device driver. That would allow the separation of the SoC-specific data from the code, so there wouldn't be a need to embed the OMAP_PRCM_IRQ data in the driver code. Rather, that data could go into the dev_attr data for the PRM hwmod. That avoids putting SoC-specific data in driver code, allows the removal of omap[34]_prcm_irq_setup(), and should also remove the dependency on omap_chip. Similarly, OMAP_PRCM_MAX_NR_PENDING_REG and OMAP_PRCM_NR_IRQS should be defined somewhere SoC-specific. I'd suggest defining those in the hwmod dev_attr data. That way that file won't need to be patched if those constants need change in the future. Unfortunately, doing this in a clean way will probably mean that the variables that are allocated via these constants will need to be allocated and freed dynamically. What I'd suggest is to create a short series that: 1. adds PRM hwmod data for OMAP2430+ platforms How should this be done? It believe all the data in the hwmods should be autogenerated somehow... should I just make a temporary hack patch for one platform that could be then autogenerated by someone for all omap platforms? 2. adds a basic PRM device driver skeleton in a directory such as drivers/power -- (I'm not convinced that this is the right place, in the end; but seems like a good place to start) 3. creates the chained interrupt handler in the PRM device driver, and removes the old PRCM interrupt handler from pm34xx.c ... A few other relatively minor comments: - Probably omap_prcm_irq_cleanup() shouldn't be called from pm34xx.c, since other code outside of pm34xx.c might wish to use the PRCM interrupt, even in the (admittedly unlikely) circumstance that some of the code in pm34xx.c fails? - It would be good to document struct omap_prcm_irq via KernelDoc, rather than inline comments (Documentation/kernel-doc-nano-HOWTO.txt). It would be ideal if the patch's function documentation followed the same standard. - Paul 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
[PATCH 11/11] ARM: pm: add L2 cache cleaning for suspend
We need to ensure that state is pushed out from the L2 cache when suspending so that the resume paths can access their data before the MMU and caches have been re-initialized. Add the necessary calls to __cpu_suspend_save(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/kernel/suspend.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c index c78a88f..4c95410 100644 --- a/arch/arm/kernel/suspend.c +++ b/arch/arm/kernel/suspend.c @@ -28,6 +28,9 @@ void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr) cpu_do_suspend(ptr); flush_cache_all(); + outer_clean_range(*save_ptr, *save_ptr + ptrsz); + outer_clean_range(virt_to_phys(save_ptr), + virt_to_phys(save_ptr) + sizeof(*save_ptr)); } /* -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] ARM: pm: convert some assembly to C
Convert some of the sleep.S guts to C code, which makes it easier to
use our macros and to add L2 cache handling. We provide a helper
function, __cpu_suspend_save(), which deals with saving the common
state, setting up for resume, and flushing caches.
The remainder left as assembly code is the saving of the CPU general
purpose registers, and allocating space on the stack to save the CPU
specific registers and resume state.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/include/asm/proc-fns.h |8 ++
arch/arm/kernel/sleep.S | 53 --
arch/arm/kernel/suspend.c | 24 +++--
3 files changed, 46 insertions(+), 39 deletions(-)
diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
index 633d1cb..9e92cb2 100644
--- a/arch/arm/include/asm/proc-fns.h
+++ b/arch/arm/include/asm/proc-fns.h
@@ -81,6 +81,10 @@ extern void cpu_dcache_clean_area(void *, int);
extern void cpu_do_switch_mm(unsigned long pgd_phys, struct mm_struct *mm);
extern void cpu_set_pte_ext(pte_t *ptep, pte_t pte, unsigned int ext);
extern void cpu_reset(unsigned long addr) __attribute__((noreturn));
+
+/* These three are private to arch/arm/kernel/suspend.c */
+extern void cpu_do_suspend(void *);
+extern void cpu_do_resume(void *);
#else
#define cpu_proc_init processor._proc_init
#define cpu_proc_fin processor._proc_fin
@@ -89,6 +93,10 @@ extern void cpu_reset(unsigned long addr)
__attribute__((noreturn));
#define cpu_dcache_clean_area processor.dcache_clean_area
#define cpu_set_pte_extprocessor.set_pte_ext
#define cpu_do_switch_mm processor.switch_mm
+
+/* These three are private to arch/arm/kernel/suspend.c */
+#define cpu_do_suspend processor.do_suspend
+#define cpu_do_resume processor.do_resume
#endif
extern void cpu_resume(void);
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index c9a43ca..020e99c 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -8,54 +8,35 @@
.text
/*
- * Save CPU state for a suspend
- * r0 = phys addr of temporary page tables
- * r1 = v:p offset
- * r2 = suspend function arg0
- * r3 = suspend function
+ * Save CPU state for a suspend. This saves the CPU general purpose
+ * registers, and allocates space on the kernel stack to save the CPU
+ * specific registers and some other data for resume.
+ * r0 = suspend function arg0
+ * r1 = suspend function
*/
ENTRY(__cpu_suspend)
stmfd sp!, {r4 - r11, lr}
- mov r4, r0
#ifdef MULTI_CPU
ldr r10, =processor
- ldr r5, [r10, #CPU_SLEEP_SIZE] @ size of CPU sleep state
- ldr ip, [r10, #CPU_DO_RESUME] @ virtual resume function
+ ldr r4, [r10, #CPU_SLEEP_SIZE] @ size of CPU sleep state
#else
- ldr r5, =cpu_suspend_size
- ldr ip, =cpu_do_resume
+ ldr r4, =cpu_suspend_size
#endif
- mov r6, sp @ current virtual SP
- sub sp, sp, r5 @ allocate CPU state on stack
- mov r0, sp @ save pointer to CPU save block
- add ip, ip, r1 @ convert resume fn to phys
- stmfd sp!, {r4, r6, ip} @ save phys pgd, virt SP, phys resume fn
- ldr r5, =sleep_save_sp
- add r6, sp, r1 @ convert SP to phys
- stmfd sp!, {r2, r3} @ save suspend func arg and pointer
+ mov r5, sp @ current virtual SP
+ add r4, r4, #12 @ Space for pgd, virt sp, phys resume fn
+ sub sp, sp, r4 @ allocate CPU state on stack
+ stmfd sp!, {r0, r1} @ save suspend func arg and pointer
+ add r0, sp, #8 @ save pointer to save block
+ mov r1, r4 @ size of save block
+ mov r2, r5 @ virtual SP
+ ldr r3, =sleep_save_sp
#ifdef CONFIG_SMP
ALT_SMP(mrc p15, 0, lr, c0, c0, 5)
ALT_UP(mov lr, #0)
and lr, lr, #15
- str r6, [r5, lr, lsl #2]@ save phys SP
-#else
- str r6, [r5]@ save phys SP
-#endif
-#ifdef MULTI_CPU
- mov lr, pc
- ldr pc, [r10, #CPU_DO_SUSPEND] @ save CPU state
-#else
- bl cpu_do_suspend
-#endif
-
- @ flush data cache
-#ifdef MULTI_CACHE
- ldr r10, =cpu_cache
- mov lr, pc
- ldr pc, [r10, #CACHE_FLUSH_KERN_ALL]
-#else
- bl __cpuc_flush_kern_all
+ add r3, r3, lr, lsl #2
#endif
+ bl __cpu_suspend_save
adr lr, BSYM(cpu_suspend_abort)
ldmfd sp!, {r0, pc} @ call suspend fn
ENDPROC(__cpu_suspend)
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 115736a..c78a88f 100644
--- a/arch/arm/kernel/suspend.c
+++
[PATCH 06/11] ARM: pm: preallocate a page table for suspend/resume
Preallocate a page table and setup an identity mapping for the MMU
enable code. This means we don't have to borrow a page table to
do this, avoiding complexities with L2 cache coherency.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/include/asm/suspend.h | 17 +-
arch/arm/kernel/Makefile |2 +-
arch/arm/kernel/sleep.S| 33 ++-
arch/arm/kernel/suspend.c | 47
arch/arm/mm/proc-arm920.S |4 ---
arch/arm/mm/proc-arm926.S |4 ---
arch/arm/mm/proc-sa1100.S |4 ---
arch/arm/mm/proc-v6.S |6 -
arch/arm/mm/proc-v7.S |6 -
arch/arm/mm/proc-xsc3.S|6 -
arch/arm/mm/proc-xscale.S |4 ---
11 files changed, 61 insertions(+), 72 deletions(-)
create mode 100644 arch/arm/kernel/suspend.c
diff --git a/arch/arm/include/asm/suspend.h b/arch/arm/include/asm/suspend.h
index b0e4e1a..1c0a551 100644
--- a/arch/arm/include/asm/suspend.h
+++ b/arch/arm/include/asm/suspend.h
@@ -1,22 +1,7 @@
#ifndef __ASM_ARM_SUSPEND_H
#define __ASM_ARM_SUSPEND_H
-#include asm/memory.h
-#include asm/tlbflush.h
-
extern void cpu_resume(void);
-
-/*
- * Hide the first two arguments to __cpu_suspend - these are an implementation
- * detail which platform code shouldn't have to know about.
- */
-static inline int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
-{
- extern int __cpu_suspend(int, long, unsigned long,
-int (*)(unsigned long));
- int ret = __cpu_suspend(0, PHYS_OFFSET - PAGE_OFFSET, arg, fn);
- flush_tlb_all();
- return ret;
-}
+extern int cpu_suspend(unsigned long, int (*)(unsigned long));
#endif
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index f7887dc..787b888 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -29,7 +29,7 @@ obj-$(CONFIG_MODULES) += armksyms.o module.o
obj-$(CONFIG_ARTHUR) += arthur.o
obj-$(CONFIG_ISA_DMA) += dma-isa.o
obj-$(CONFIG_PCI) += bios32.o isa.o
-obj-$(CONFIG_PM_SLEEP) += sleep.o
+obj-$(CONFIG_PM_SLEEP) += sleep.o suspend.o
obj-$(CONFIG_HAVE_SCHED_CLOCK) += sched_clock.o
obj-$(CONFIG_SMP) += smp.o smp_tlb.o
obj-$(CONFIG_HAVE_ARM_SCU) += smp_scu.o
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 46a9f46..8cf13de 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -27,7 +27,7 @@ ENTRY(__cpu_suspend)
sub sp, sp, r5 @ allocate CPU state on stack
mov r0, sp @ save pointer to CPU save block
add ip, ip, r1 @ convert resume fn to phys
- stmfd sp!, {r1, r6, ip} @ save v:p, virt SP, phys resume fn
+ stmfd sp!, {r6, ip} @ save virt SP, phys resume fn
ldr r5, =sleep_save_sp
add r6, sp, r1 @ convert SP to phys
stmfd sp!, {r2, r3} @ save suspend func arg and pointer
@@ -60,7 +60,7 @@ ENDPROC(__cpu_suspend)
.ltorg
cpu_suspend_abort:
- ldmia sp!, {r1 - r3} @ pop v:p, virt SP, phys resume fn
+ ldmia sp!, {r2 - r3} @ pop virt SP, phys resume fn
teq r0, #0
moveq r0, #1 @ force non-zero value
mov sp, r2
@@ -74,28 +74,19 @@ ENDPROC(cpu_suspend_abort)
* r3 = L1 section flags
*/
ENTRY(cpu_resume_mmu)
- adr r4, cpu_resume_turn_mmu_on
- mov r4, r4, lsr #20
- orr r3, r3, r4, lsl #20
- ldr r5, [r2, r4, lsl #2]@ save old mapping
- str r3, [r2, r4, lsl #2]@ setup 1:1 mapping for mmu code
- sub r2, r2, r1
ldr r3, =cpu_resume_after_mmu
- bic r1, r0, #CR_C @ ensure D-cache is disabled
b cpu_resume_turn_mmu_on
ENDPROC(cpu_resume_mmu)
.ltorg
.align 5
-cpu_resume_turn_mmu_on:
- mcr p15, 0, r1, c1, c0, 0 @ turn on MMU, I-cache, etc
- mrc p15, 0, r1, c0, c0, 0 @ read id reg
- mov r1, r1
- mov r1, r1
+ENTRY(cpu_resume_turn_mmu_on)
+ mcr p15, 0, r0, c1, c0, 0 @ turn on MMU, I-cache, etc
+ mrc p15, 0, r0, c0, c0, 0 @ read id reg
+ mov r0, r0
+ mov r0, r0
mov pc, r3 @ jump to virtual address
ENDPROC(cpu_resume_turn_mmu_on)
cpu_resume_after_mmu:
- str r5, [r2, r4, lsl #2]@ restore old mapping
- mcr p15, 0, r0, c1, c0, 0 @ turn on D-cache
bl cpu_init@ restore the und/abt/irq banked regs
mov r0, #0 @ return zero on success
ldmfd sp!, {r4 - r11, pc}
@@ -121,11 +112,11 @@ ENTRY(cpu_resume)
ldr r0, sleep_save_sp @ stack phys addr
#endif
setmode PSR_I_BIT | PSR_F_BIT | SVC_MODE, r1 @
[PATCH 09/11] ARM: pm: get rid of cpu_resume_turn_mmu_on
We don't require cpu_resume_turn_mmu_on as we can combine the ldr
instruction with the following code provided we ensure that
cpu_resume_mmu is aligned for older CPUs. Note that we also align
to a 32-byte boundary to ensure that the code can't cross a section
boundary.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/kernel/sleep.S |8 ++--
arch/arm/kernel/suspend.c |4 ++--
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 25d42df..c9a43ca 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -72,19 +72,15 @@ ENDPROC(cpu_suspend_abort)
/*
* r0 = control register value
*/
+ .align 5
ENTRY(cpu_resume_mmu)
ldr r3, =cpu_resume_after_mmu
- b cpu_resume_turn_mmu_on
-ENDPROC(cpu_resume_mmu)
- .ltorg
- .align 5
-ENTRY(cpu_resume_turn_mmu_on)
mcr p15, 0, r0, c1, c0, 0 @ turn on MMU, I-cache, etc
mrc p15, 0, r0, c0, c0, 0 @ read id reg
mov r0, r0
mov r0, r0
mov pc, r3 @ jump to virtual address
-ENDPROC(cpu_resume_turn_mmu_on)
+ENDPROC(cpu_resume_mmu)
cpu_resume_after_mmu:
bl cpu_init@ restore the und/abt/irq banked regs
mov r0, #0 @ return zero on success
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 7606122..115736a 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -9,7 +9,7 @@
static pgd_t *suspend_pgd;
extern int __cpu_suspend(int, long, unsigned long, int (*)(unsigned long));
-extern void cpu_resume_turn_mmu_on(void);
+extern void cpu_resume_mmu(void);
/*
* Hide the first two arguments to __cpu_suspend - these are an implementation
@@ -41,7 +41,7 @@ static int __init cpu_suspend_init(void)
{
suspend_pgd = pgd_alloc(init_mm);
if (suspend_pgd) {
- unsigned long addr = virt_to_phys(cpu_resume_turn_mmu_on);
+ unsigned long addr = virt_to_phys(cpu_resume_mmu);
identity_mapping_add(suspend_pgd, addr, addr + SECTION_SIZE);
}
return suspend_pgd ? 0 : -ENOMEM;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/11] ARM: pm: no need to save/restore context ID register
There is no need to save and restore the context ID register on ARMv6
and ARMv7 with a temporary page table as we write the context ID
register when we switch back to the real page tables for the thread.
Moreover, the temporary page tables do not contain any non-global
mappings, so the context ID value should not be used. To be safe,
initialize the register to a reserved context ID value.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/proc-v6.S | 33 -
arch/arm/mm/proc-v7.S | 13 ++---
2 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 2e27b46..a92c3c3 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -128,19 +128,18 @@ ENTRY(cpu_v6_set_pte_ext)
/* Suspend/resume support: taken from arch/arm/mach-s3c64xx/sleep.S */
.globl cpu_v6_suspend_size
-.equ cpu_v6_suspend_size, 4 * 7
+.equ cpu_v6_suspend_size, 4 * 6
#ifdef CONFIG_PM_SLEEP
ENTRY(cpu_v6_do_suspend)
- stmfd sp!, {r4 - r10, lr}
+ stmfd sp!, {r4 - r9, lr}
mrc p15, 0, r4, c13, c0, 0 @ FCSE/PID
- mrc p15, 0, r5, c13, c0, 1 @ Context ID
- mrc p15, 0, r6, c3, c0, 0 @ Domain ID
- mrc p15, 0, r7, c2, c0, 1 @ Translation table base 1
- mrc p15, 0, r8, c1, c0, 1 @ auxiliary control register
- mrc p15, 0, r9, c1, c0, 2 @ co-processor access control
- mrc p15, 0, r10, c1, c0, 0 @ control register
- stmia r0, {r4 - r10}
- ldmfd sp!, {r4- r10, pc}
+ mrc p15, 0, r5, c3, c0, 0 @ Domain ID
+ mrc p15, 0, r6, c2, c0, 1 @ Translation table base 1
+ mrc p15, 0, r7, c1, c0, 1 @ auxiliary control register
+ mrc p15, 0, r8, c1, c0, 2 @ co-processor access control
+ mrc p15, 0, r9, c1, c0, 0 @ control register
+ stmia r0, {r4 - r9}
+ ldmfd sp!, {r4- r9, pc}
ENDPROC(cpu_v6_do_suspend)
ENTRY(cpu_v6_do_resume)
@@ -149,19 +148,19 @@ ENTRY(cpu_v6_do_resume)
mcr p15, 0, ip, c7, c5, 0 @ invalidate I cache
mcr p15, 0, ip, c7, c15, 0 @ clean+invalidate cache
mcr p15, 0, ip, c7, c10, 4 @ drain write buffer
- ldmia r0, {r4 - r10}
+ mcr p15, 0, ip, c13, 0, 1 @ set reserved context ID
+ ldmia r0, {r4 - r9}
mcr p15, 0, r4, c13, c0, 0 @ FCSE/PID
- mcr p15, 0, r5, c13, c0, 1 @ Context ID
- mcr p15, 0, r6, c3, c0, 0 @ Domain ID
+ mcr p15, 0, r5, c3, c0, 0 @ Domain ID
ALT_SMP(orr r1, r1, #TTB_FLAGS_SMP)
ALT_UP(orr r1, r1, #TTB_FLAGS_UP)
mcr p15, 0, r1, c2, c0, 0 @ Translation table base 0
- mcr p15, 0, r7, c2, c0, 1 @ Translation table base 1
- mcr p15, 0, r8, c1, c0, 1 @ auxiliary control register
- mcr p15, 0, r9, c1, c0, 2 @ co-processor access control
+ mcr p15, 0, r6, c2, c0, 1 @ Translation table base 1
+ mcr p15, 0, r7, c1, c0, 1 @ auxiliary control register
+ mcr p15, 0, r8, c1, c0, 2 @ co-processor access control
mcr p15, 0, ip, c2, c0, 2 @ TTB control register
mcr p15, 0, ip, c7, c5, 4 @ ISB
- mov r0, r10 @ control register
+ mov r0, r9 @ control register
b cpu_resume_mmu
ENDPROC(cpu_v6_do_resume)
#endif
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index b56004f..6af366c 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -217,14 +217,13 @@ ENDPROC(cpu_v7_set_pte_ext)
/* Suspend/resume support: derived from arch/arm/mach-s5pv210/sleep.S */
.globl cpu_v7_suspend_size
-.equ cpu_v7_suspend_size, 4 * 8
+.equ cpu_v7_suspend_size, 4 * 7
#ifdef CONFIG_PM_SLEEP
ENTRY(cpu_v7_do_suspend)
stmfd sp!, {r4 - r10, lr}
mrc p15, 0, r4, c13, c0, 0 @ FCSE/PID
- mrc p15, 0, r5, c13, c0, 1 @ Context ID
- mrc p15, 0, r6, c13, c0, 3 @ User r/o thread ID
- stmia r0!, {r4 - r6}
+ mrc p15, 0, r5, c13, c0, 3 @ User r/o thread ID
+ stmia r0!, {r4 - r5}
mrc p15, 0, r6, c3, c0, 0 @ Domain ID
mrc p15, 0, r7, c2, c0, 1 @ TTB 1
mrc p15, 0, r8, c1, c0, 0 @ Control register
@@ -238,10 +237,10 @@ ENTRY(cpu_v7_do_resume)
mov ip, #0
mcr p15, 0, ip, c8, c7, 0 @ invalidate TLBs
mcr p15, 0, ip, c7, c5, 0 @ invalidate I cache
- ldmia r0!, {r4 - r6}
+ mcr p15, 0, ip, c13, c0, 1 @ set reserved context ID
+ ldmia r0!, {r4 - r5}
mcr p15, 0, r4, c13, c0, 0 @ FCSE/PID
- mcr p15, 0, r5, c13, c0, 1 @ Context ID
- mcr p15, 0, r6, c13, c0, 3 @ User r/o thread ID
+ mcr p15, 0, r5, c13, c0, 3 @ User r/o thread ID
ldmia r0, {r6 - r10}
mcr p15, 0, r6, c3, c0, 0 @ Domain ID
[PATCH 07/11] ARM: pm: only use preallocated page table during resume
Only use the preallocated page table during the resume, not while
suspending. This avoids the overhead of having to switch unnecessarily
to the resume page table in the suspend path.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/kernel/sleep.S | 19 +--
arch/arm/kernel/suspend.c | 14 --
arch/arm/mm/proc-arm920.S | 17 -
arch/arm/mm/proc-arm926.S | 17 -
arch/arm/mm/proc-sa1100.S | 21 ++---
arch/arm/mm/proc-v6.S | 31 ---
arch/arm/mm/proc-v7.S | 33 +
arch/arm/mm/proc-xsc3.S | 22 +++---
arch/arm/mm/proc-xscale.S | 21 ++---
9 files changed, 97 insertions(+), 98 deletions(-)
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 8cf13de..25d42df 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -9,12 +9,14 @@
/*
* Save CPU state for a suspend
+ * r0 = phys addr of temporary page tables
* r1 = v:p offset
* r2 = suspend function arg0
* r3 = suspend function
*/
ENTRY(__cpu_suspend)
stmfd sp!, {r4 - r11, lr}
+ mov r4, r0
#ifdef MULTI_CPU
ldr r10, =processor
ldr r5, [r10, #CPU_SLEEP_SIZE] @ size of CPU sleep state
@@ -27,7 +29,7 @@ ENTRY(__cpu_suspend)
sub sp, sp, r5 @ allocate CPU state on stack
mov r0, sp @ save pointer to CPU save block
add ip, ip, r1 @ convert resume fn to phys
- stmfd sp!, {r6, ip} @ save virt SP, phys resume fn
+ stmfd sp!, {r4, r6, ip} @ save phys pgd, virt SP, phys resume fn
ldr r5, =sleep_save_sp
add r6, sp, r1 @ convert SP to phys
stmfd sp!, {r2, r3} @ save suspend func arg and pointer
@@ -60,7 +62,7 @@ ENDPROC(__cpu_suspend)
.ltorg
cpu_suspend_abort:
- ldmia sp!, {r2 - r3} @ pop virt SP, phys resume fn
+ ldmia sp!, {r1 - r3} @ pop phys pgd, virt SP, phys resume fn
teq r0, #0
moveq r0, #1 @ force non-zero value
mov sp, r2
@@ -69,9 +71,6 @@ ENDPROC(cpu_suspend_abort)
/*
* r0 = control register value
- * r1 = v:p offset (preserved by cpu_do_resume)
- * r2 = phys page table base
- * r3 = L1 section flags
*/
ENTRY(cpu_resume_mmu)
ldr r3, =cpu_resume_after_mmu
@@ -112,11 +111,11 @@ ENTRY(cpu_resume)
ldr r0, sleep_save_sp @ stack phys addr
#endif
setmode PSR_I_BIT | PSR_F_BIT | SVC_MODE, r1 @ set SVC, irqs off
- @ load stack, resume fn
- ARM( ldmia r0!, {sp, pc} )
-THUMB( ldmia r0!, {r2, r3} )
-THUMB( mov sp, r2 )
-THUMB( bx r3 )
+ @ load phys pgd, stack, resume fn
+ ARM( ldmia r0!, {r1, sp, pc} )
+THUMB( ldmia r0!, {r1, r2, r3} )
+THUMB( mov sp, r2 )
+THUMB( bx r3 )
ENDPROC(cpu_resume)
sleep_save_sp:
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 4d9ac3d..7606122 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -24,13 +24,15 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
return -EINVAL;
/*
-* Temporarily switch the page tables to our suspend page
-* tables, which contain the temporary identity mapping
-* required for resuming.
+* Provide a temporary page table with an identity mapping for
+* the MMU-enable code, required for resuming. On successful
+* resume (indicated by a zero return code), we need to switch
+* back to the correct page tables.
*/
- cpu_switch_mm(suspend_pgd, mm);
- ret = __cpu_suspend(0, PHYS_OFFSET - PAGE_OFFSET, arg, fn);
- cpu_switch_mm(mm-pgd, mm);
+ ret = __cpu_suspend(virt_to_phys(suspend_pgd),
+ PHYS_OFFSET - PAGE_OFFSET, arg, fn);
+ if (ret == 0)
+ cpu_switch_mm(mm-pgd, mm);
return ret;
}
diff --git a/arch/arm/mm/proc-arm920.S b/arch/arm/mm/proc-arm920.S
index 035d57b..88fb3d9 100644
--- a/arch/arm/mm/proc-arm920.S
+++ b/arch/arm/mm/proc-arm920.S
@@ -379,27 +379,26 @@ ENTRY(cpu_arm920_set_pte_ext)
/* Suspend/resume support: taken from arch/arm/plat-s3c24xx/sleep.S */
.globl cpu_arm920_suspend_size
-.equ cpu_arm920_suspend_size, 4 * 4
+.equ cpu_arm920_suspend_size, 4 * 3
#ifdef CONFIG_PM_SLEEP
ENTRY(cpu_arm920_do_suspend)
- stmfd sp!, {r4 - r7, lr}
+ stmfd sp!, {r4 - r6, lr}
mrc p15, 0, r4, c13, c0, 0 @ PID
mrc p15, 0, r5, c3, c0, 0 @ Domain ID
- mrc p15, 0, r6, c2, c0, 0 @ TTB address
- mrc p15, 0, r7, c1, c0, 0 @ Control register
- stmia r0, {r4 - r7}
- ldmfd sp!, {r4 - r7, pc}
+ mrc
[PATCH 05/11] ARM: pm: force non-zero return value from __cpu_suspend when aborting
Ensure that the return value from __cpu_suspend is non-zero when
aborting. Zero indicates a successful suspend occurred.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/kernel/sleep.S |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index dc902f2..46a9f46 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -61,6 +61,8 @@ ENDPROC(__cpu_suspend)
cpu_suspend_abort:
ldmia sp!, {r1 - r3} @ pop v:p, virt SP, phys resume fn
+ teq r0, #0
+ moveq r0, #1 @ force non-zero value
mov sp, r2
ldmfd sp!, {r4 - r11, pc}
ENDPROC(cpu_suspend_abort)
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] ARM: pm: arm920/926: fix number of registers saved
ARM920 and ARM926 save four registers, not three. Fix the size of
the suspend region required.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/proc-arm920.S |2 +-
arch/arm/mm/proc-arm926.S |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/proc-arm920.S b/arch/arm/mm/proc-arm920.S
index 92bd102..2e6849b 100644
--- a/arch/arm/mm/proc-arm920.S
+++ b/arch/arm/mm/proc-arm920.S
@@ -379,7 +379,7 @@ ENTRY(cpu_arm920_set_pte_ext)
/* Suspend/resume support: taken from arch/arm/plat-s3c24xx/sleep.S */
.globl cpu_arm920_suspend_size
-.equ cpu_arm920_suspend_size, 4 * 3
+.equ cpu_arm920_suspend_size, 4 * 4
#ifdef CONFIG_PM_SLEEP
ENTRY(cpu_arm920_do_suspend)
stmfd sp!, {r4 - r7, lr}
diff --git a/arch/arm/mm/proc-arm926.S b/arch/arm/mm/proc-arm926.S
index 2bbcf05..cd8f79c 100644
--- a/arch/arm/mm/proc-arm926.S
+++ b/arch/arm/mm/proc-arm926.S
@@ -394,7 +394,7 @@ ENTRY(cpu_arm926_set_pte_ext)
/* Suspend/resume support: taken from arch/arm/plat-s3c24xx/sleep.S */
.globl cpu_arm926_suspend_size
-.equ cpu_arm926_suspend_size, 4 * 3
+.equ cpu_arm926_suspend_size, 4 * 4
#ifdef CONFIG_PM_SLEEP
ENTRY(cpu_arm926_do_suspend)
stmfd sp!, {r4 - r7, lr}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] ARM: pm: avoid writing the auxillary control register for ARMv7
For ARMv7 kernels running in the non-secure world, writing to the auxillary control register causes an abort, so we must avoid directly writing the auxillary control register. If the ACR has already been reinitialized by SoC code, don't try to restore it. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mm/proc-v7.S |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index a773f4e..9049c07 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -248,7 +248,9 @@ ENTRY(cpu_v7_do_resume) mcr p15, 0, r7, c2, c0, 0 @ TTB 0 mcr p15, 0, r8, c2, c0, 1 @ TTB 1 mcr p15, 0, ip, c2, c0, 2 @ TTB control register - mcr p15, 0, r10, c1, c0, 1 @ Auxiliary control register + mrc p15, 0, r4, c1, c0, 1 @ Read Auxiliary control register + teq r4, r10 @ Is it already set? + mcrne p15, 0, r10, c1, c0, 1 @ No, so write it mcr p15, 0, r11, c1, c0, 2 @ Co-processor access control ldr r4, =PRRR @ PRRR ldr r5, =NMRR @ NMRR -- 1.7.4.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] iommu: omap_iovmm: support non page-aligned buffers in iommu_vmap
On Thursday 01 September 2011 16:02:35 Ohad Ben-Cohen wrote: On Thu, Sep 1, 2011 at 4:59 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: It looks good to me. Thanks. I haven't tested it though. I did, but I always get aligned buffers so my testing is a bit moot. I can't see how unmap could work without this patch, though, so I'll squash this and re-post. You can allocate a page-aligned buffer with posix_memalign() and add an offset (64 should do the job, smaller values can get rejected by the OMAP3 ISP driver). -- 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: [PATCH 2/7] OMAP: PM: omap_device: add few quick access functions
Cousson, Benoit b-cous...@ti.com writes:
On 9/1/2011 12:23 AM, Hilman, Kevin wrote:
Benoit Coussonb-cous...@ti.com writes:
From: Nishanth Menonn...@ti.com
Provide a quick set of access functions:
a) Convert omap_device to platform_device - This is the flip of
to_omap_device for equivalent usage
b) Convert omap_device to device pointer - This is useful for
most devices that need to go through standard linux functions that
take device pointer.
c) Convert hwmod to device pointer - This wrapper provides ability for
drivers to convert directly from hwmod name back to device pointer
without having to handle this on a driver by driver basis
Signed-off-by: Nishanth Menonn...@ti.com
[b-cous...@ti.com: Adapt it to the new pdev pointer inside od]
Signed-off-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index bdc2804..903f329 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -152,6 +152,21 @@ static inline struct omap_device
*to_omap_device(struct platform_device *pdev)
return pdev ? pdev-archdata.od : NULL;
}
+/* Convert omap_device to platform device pointer */
+#define omap_device_get_pdev(x) ((x)-pdev)
+/* Convert omap_device to device pointer */
+#define omap_device_get_dev(x) (omap_device_get_pdev(x)-dev)
I don't see these used elsewhere, and I don't think they're needed...
Well, there are used once... just below, and that's all.
+/* Convert omap_hwmod name to device pointer */
+static inline struct device *omap_hwmod_name_get_dev(const char *oh_name)
+{
+ struct omap_device *od;
+ od = omap_hwmod_name_get_odev(oh_name);
+ if (IS_ERR_OR_NULL(od))
+ return ERR_PTR(od ? PTR_ERR(od) : -ENODEV);
+ return omap_device_get_dev(od);
+}
+
I will let Nishant comment, but I guess the idea was that an
omap_device API should handle omap_device pointer, and then access to
pdev or dev is done using these helpers.
Assuming that now omap_device API should preferably use pdev, we can
remove one step of indirection and thus get rid of the helpers, since
they are not used anywhere else.
Yes please.
I've made most of the omap_device API now use pdev pointers already in
my series.
Thanks,
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: cpuidle status in mainline for Beagleboard xM
javier Martin javier.mar...@vista-silicon.com writes: I am trying to enable cpuidle and cpufreq support in latest stable kernel (3.0.4) in the Beagleboard xM. OMAP CPUfreq driver is still not in mailine. I plan to rectify that (finally) for v3.2. In the mean time, feel free to try the pm-wip/cpufreq branch from my linux-omap-pm tree[1] (currently based on v3.0-rc3) The default governor I've selected in the kernel menu is powersave. However, when I execute powertop 1.12 (downloaded from Angstrom 2010.x repository through opkg) I get the following: Cn Avg residency P-states (frequencies) C0 (cpu running) ( 0.4%) C0 16.7ms (99.6%) C1 0.0ms ( 0.0%) C2 0.0ms ( 0.0%) C3 0.0ms ( 0.0%) C4 0.0ms ( 0.0%) C5 0.0ms ( 0.0%) C6 0.0ms ( 0.0%) So, the CPU always stays in C0 status and P-states are not shown. P-states are not shown because there is no CPUfreq driver, so no P-states available, and of course the choice of CPUfreq governor doesn't matter. CPU is staying in C0 probably because UARTs are not being idled, so SoC cannot hit deeper idle states. Try the following at the command line to to enable UART idle timeouts, so the SoC can attempt idle after the timeout period # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4) echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.3/sleep_timeout After 5 seconds of inactivity on the UARTs, you should see the SoC hitting deeper C-states. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git -- 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 00/11] Add L2 cache cleaning to generic CPU suspend
Hi Russell, On Thu, Sep 01, 2011 at 01:47:52PM +0100, Russell King - ARM Linux wrote: Some systems (such as OMAP) preserve the L2 cache across a suspend/ resume cycle. This means they do not perform L2 cache maintanence in their suspend finisher function. However, the side effect is that the saved CPU state is not readable by the resume code because it is sitting in the L2 cache. This patch series adds L2 cache cleaning to the generic CPU suspend/ resume support code, making it possible to use this on systems with L2 cache enabled without having to clean/invalidate the entire L2 cache. This is also the case on i.MX6Q, which L2 cache is retained during a suspend/resume cycle. Currently, I have to call into the following before calling generic cpu_suspend() to clean/invalidate the entire L2 cache. outer_flush_all(); outer_disable(); But there is a wired thing on using generic cpu_resume(). I have to invalidate L1 before calling into cpu_resume() like below. ENTRY(imx6q_cpu_resume) bl v7_invalidate_l1 b cpu_resume ENDPROC(imx6q_cpu_resume) ENTRY(imx6q_secondary_startup) bl v7_invalidate_l1 b secondary_startup ENDPROC(imx6q_secondary_startup) The v7_invalidate_l1() is the function copied from mach-tegra/headsmp.S, which has to be called before calling secondary_startup to boot secondary cores (same situation between Tegra and i.MX6Q). /* * Tegra specific entry point for secondary CPUs. * The secondary kernel init calls v7_flush_dcache_all before it enables * the L1; however, the L1 comes out of reset in an undefined state, so * the clean + invalidate performed by v7_flush_dcache_all causes a bunch * of cache lines with uninitialized data and uninitialized tags to get * written out to memory, which does really unpleasant things to the main * processor. We fix this by performing an invalidate, rather than a * clean + invalidate, before jumping into the kernel. */ ENTRY(v7_invalidate_l1) mov r0, #0 mcr p15, 2, r0, c0, c0, 0 mrc p15, 1, r0, c0, c0, 0 ldr r1, =0x7fff and r2, r1, r0, lsr #13 ldr r1, =0x3ff and r3, r1, r0, lsr #3 @ NumWays - 1 add r2, r2, #1 @ NumSets and r0, r0, #0x7 add r0, r0, #4 @ SetShift clz r1, r3 @ WayShift add r4, r3, #1 @ NumWays 1: sub r2, r2, #1 @ NumSets-- mov r3, r4 @ Temp = NumWays 2: subsr3, r3, #1 @ Temp-- mov r5, r3, lsl r1 mov r6, r2, lsl r0 orr r5, r5, r6 @ Reg = (TempWayShift)|(NumSetsSetShift) mcr p15, 0, r5, c7, c6, 2 bgt 2b cmp r2, #0 bgt 1b dsb isb mov pc, lr ENDPROC(v7_invalidate_l1) Before applying this patch series, I have something like below actually working. outer_flush_all(); outer_disable(); imx_set_cpu_jump(0, imx6q_cpu_resume); /* Zzz ... */ cpu_suspend(0, imx6q_suspend_finish); I expect with you patches applied, I can still have it work with simply removing those two lines outer cache codes. But unfortunately, I'm running into Oops when resuming back. And I also have Oops with imx_set_cpu_jump(0, cpu_resume) which means skipping the v7_invalidate_l1() and calling generic cpu_resume() only. I know the key point of the whole thing is that we need to invalidate L1 before either booting secondary cores or resuming the primary core on i.MX6Q. But I really need some help to understand why, and the best solution to that. -- Regards, Shawn -- 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: cpuidle status in mainline for Beagleboard xM
Hi Kevin, thanks for your help. CPU is staying in C0 probably because UARTs are not being idled, so SoC cannot hit deeper idle states. Try the following at the command line to to enable UART idle timeouts, so the SoC can attempt idle after the timeout period # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4) echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.3/sleep_timeout After 5 seconds of inactivity on the UARTs, you should see the SoC hitting deeper C-states. I've tried that but it still doesn't hit any C-state deeper than 0. I'll try the same test using your pm branch you pointed me out and post the results. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] Add L2 cache cleaning to generic CPU suspend
On Thu, Sep 01, 2011 at 11:33:43PM +0800, Shawn Guo wrote: This is also the case on i.MX6Q, which L2 cache is retained during a suspend/resume cycle. Currently, I have to call into the following before calling generic cpu_suspend() to clean/invalidate the entire L2 cache. outer_flush_all(); outer_disable(); But there is a wired thing on using generic cpu_resume(). I have to invalidate L1 before calling into cpu_resume() like below. ENTRY(imx6q_cpu_resume) bl v7_invalidate_l1 b cpu_resume ENDPROC(imx6q_cpu_resume) ENTRY(imx6q_secondary_startup) bl v7_invalidate_l1 b secondary_startup ENDPROC(imx6q_secondary_startup) The v7_invalidate_l1() is the function copied from mach-tegra/headsmp.S, which has to be called before calling secondary_startup to boot secondary cores (same situation between Tegra and i.MX6Q). Presumably that's because your L1 cache contains randomized data with random validity (and presumably random dirtyness) at boot time - something which unfortunately the ARM ARM permits. I don't think we can go to the extent of dealing with this in the generic code as it would unnecessarily perturb those implementations which either the boot loader has already sorted out that issue, or which don't have the issue at all. Before applying this patch series, I have something like below actually working. outer_flush_all(); outer_disable(); imx_set_cpu_jump(0, imx6q_cpu_resume); /* Zzz ... */ cpu_suspend(0, imx6q_suspend_finish); I expect with you patches applied, I can still have it work with simply removing those two lines outer cache codes. That should be the case. But unfortunately, I'm running into Oops when resuming back. And I also have Oops with imx_set_cpu_jump(0, cpu_resume) which means skipping the v7_invalidate_l1() and calling generic cpu_resume() only. Do you have a copy of the oops? -- 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 00/11] Add L2 cache cleaning to generic CPU suspend
On Thu, Sep 01, 2011 at 04:34:51PM +0100, Russell King - ARM Linux wrote: On Thu, Sep 01, 2011 at 11:33:43PM +0800, Shawn Guo wrote: This is also the case on i.MX6Q, which L2 cache is retained during a suspend/resume cycle. Currently, I have to call into the following before calling generic cpu_suspend() to clean/invalidate the entire L2 cache. outer_flush_all(); outer_disable(); But there is a wired thing on using generic cpu_resume(). I have to invalidate L1 before calling into cpu_resume() like below. ENTRY(imx6q_cpu_resume) bl v7_invalidate_l1 b cpu_resume ENDPROC(imx6q_cpu_resume) ENTRY(imx6q_secondary_startup) bl v7_invalidate_l1 b secondary_startup ENDPROC(imx6q_secondary_startup) The v7_invalidate_l1() is the function copied from mach-tegra/headsmp.S, which has to be called before calling secondary_startup to boot secondary cores (same situation between Tegra and i.MX6Q). Presumably that's because your L1 cache contains randomized data with random validity (and presumably random dirtyness) at boot time - something which unfortunately the ARM ARM permits. I don't think we can go to the extent of dealing with this in the generic code as it would unnecessarily perturb those implementations which either the boot loader has already sorted out that issue, or which don't have the issue at all. Yes, agreed. It seems that Tegra and i.MX6Q are the only two CA9MP cases here. But is it possible to maintain this v7_invalidate_l1() function in cache-v7.S, so that we do not need to duplicate it in platform codes? Before applying this patch series, I have something like below actually working. outer_flush_all(); outer_disable(); imx_set_cpu_jump(0, imx6q_cpu_resume); /* Zzz ... */ cpu_suspend(0, imx6q_suspend_finish); I expect with you patches applied, I can still have it work with simply removing those two lines outer cache codes. That should be the case. But unfortunately, I'm running into Oops when resuming back. And I also have Oops with imx_set_cpu_jump(0, cpu_resume) which means skipping the v7_invalidate_l1() and calling generic cpu_resume() only. Do you have a copy of the oops? root@freescale ~$ echo mem /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.01 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. PM: Entering mem sleep PM: suspend of devices complete after 0.402 msecs PM: suspend devices took 0.000 seconds PM: late suspend of devices complete after 0.276 msecs Disabling non-boot CPUs ... CPU1: shutdown CPU2: shutdown CPU3: shutdown Unable to handle kernel NULL pointer dereference at virtual address pgd = eb308000 [] *pgd=7b11d831, *pte=, *ppte= Internal error: Oops: 8005 [#1] SMP Modules linked in: CPU: 0Not tainted (3.1.0-rc4+ #319) PC is at 0x0 LR is at cpu_init+0x28/0x74 pc : []lr : [80010544]psr: 81f3 sp : eb3dbe70 ip : eb3dbe4c fp : eb2b2560 r10: 8001d8dc r9 : 8001ef68 r8 : 0004 r7 : 0003 r6 : r5 : eb0b8b60 r4 : 804865d0 r3 : 80012758 r2 : eb3dbe34 r1 : 7b8f806a r0 : Flags: Nzcv IRQs off FIQs off Mode SVC_32 ISA Thumb Segment user Control: 10c53c7d Table: 7b8f804a DAC: 0015 Process login (pid: 445, stack limit = 0xeb3da2f0) Stack: (0xeb3dbe70 to 0xeb3dc000) be60: eb3dbeac eb3dbe88 be80: 8008adc8 8008a5f8 eb3dbeb4 eb3dbe98 801dbec0 eb0a01e0 eb406600 bea0: 0003 eb3dbed4 eb3dbeb8 80063ffc 80063c78 006d eb321000 bec0: 8000e34c 8004d730 eb3dbee4 0b04 800bc9e4 eb868140 bee0: eb3dbf70 eb8286c0 0004 eb806bc0 eb3dbf0c eb3dbf00 801d7344 800633a8 bf00: eb3dbf2c 0003 2aad7000 eb3da000 eb0b91e0 0007 1000 bf20: eb3dbf64 eb3dbf30 801dbff4 80311644 8013 eb0b8b9c eb3da000 2aaeb000 bf40: 800a71ec 80025538 800aae40 eb181000 eb3dbfb0 eb3dbfb0 eb0df000 bf60: 0002 0024 0100 02012080 0008 02012080 0005 bf80: 8000e504 eb3dbfa4 eb3dbf98 8009fb74 8009f9d8 eb3dbfa8 bfa0: 8000e380 8002f8a8 7e837d90 00a69008 bfc0: 0004 2ab06000 2acb95f8 0004 0004 0201029c 0001 bfe0: 0004 7ebc0478 2ac0798c 2ac53e6c 6010 0001 Backtrace: frame pointer underflow [eb2b02d4] (0xeb2b02d4) from [2571140e] (0x2571140e) Backtrace aborted due to bad frame pointer 2551140e Code: bad PC value ---[ end trace b4510fc09c2ffbd1 ]--- Fixing recursive fault but reboot is needed! Unable to handle kernel NULL pointer dereference at virtual address 0010 pgd = eb308000 [0010] *pgd=7b11d831, *pte=, *ppte= Internal error: Oops: 5 [#2] SMP Modules
Re: [PATCH 1/1] OMAP: omap_device: only override _noirq methods, not normal suspend/resume
On Thursday 25 August 2011, Kevin Hilman wrote:
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -622,7 +622,8 @@ static struct dev_pm_domain omap_device_pm_domain = {
SET_RUNTIME_PM_OPS(_od_runtime_suspend, _od_runtime_resume,
_od_runtime_idle)
USE_PLATFORM_PM_SLEEP_OPS
- SET_SYSTEM_SLEEP_PM_OPS(_od_suspend_noirq, _od_resume_noirq)
+ .suspend_noirq = _od_suspend_noirq,
+ .resume_noirq = _od_resume_noirq,
}
};
This breaks if CONFIG_SUSPEND is not set and the
_od_suspend_noirq/_od_resume_noirq
functions are not defined.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] OMAP: omap_device cleanup before device-tree integration
Benoit Cousson b-cous...@ti.com writes: Hi Kevin, Here are a couple of cleanups on top of your for_3.2/omap_device series rebased on top of 3.1-rc2 to get your pm-fixes. OK, my for_3.2/omap_device is now based on v3.1-rc4 which has my pm-fixes merged. The goal is to help building core devices using device-tree by removing direct reference to the device inside PM. Great. For that, I took and rebased the two patches done by Nishanth to use hwmod to identify the device from the generic IP name. OK, I had some minor comments on those. The currently unused omap_device_pm_latency is moved inside the omap_device core code to avoid the duplication. And these two I've pulled into my for_3.2/omap_device branch. (not yet pushed because main kernel.org server is down.) Kevin patches are available here: git://gitorious.org/omap-pm/linux.git for_3.2/omap_device_cleanup It is tested on OMAP4 SDP and Panda only. I don't even have the Beagle to test the beagle patch :-( Regards, Benoit Benoit Cousson (5): OMAP3: beagle-board: Use the omap_hwmod_name_get_dev API OMAP2+: pm: Use hwmod name instead of dev pointer OMAP2+: pm: Remove static devices variable for mpu, dsp, iva and l3 PM OMAP: omap_device: Create a default omap_device_pm_latency OMAP2+: devices: Remove all omap_device_pm_latency structures Nishanth Menon (2): OMAP: PM: omap_device: add omap_hwmod_name_get_odev OMAP: PM: omap_device: add few quick access functions arch/arm/mach-omap2/board-omap3beagle.c |4 +- arch/arm/mach-omap2/devices.c | 46 ++--- arch/arm/mach-omap2/display.c | 11 + arch/arm/mach-omap2/dma.c | 11 + arch/arm/mach-omap2/gpio.c| 12 + arch/arm/mach-omap2/hsmmc.c | 18 +-- arch/arm/mach-omap2/hwspinlock.c | 12 + arch/arm/mach-omap2/mcbsp.c | 11 + arch/arm/mach-omap2/pm.c | 69 - arch/arm/mach-omap2/serial.c | 25 +- arch/arm/mach-omap2/sr_device.c | 11 + arch/arm/mach-omap2/usb-musb.c| 11 + arch/arm/plat-omap/i2c.c | 10 +--- arch/arm/plat-omap/include/plat/omap_device.h | 16 ++ arch/arm/plat-omap/omap_device.c | 49 +- 15 files changed, 101 insertions(+), 215 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 00/13] OMAP4: Add DT support for i2c and twl6030
Hi Grant, Tony, This is a rework of the original series done by Manju: http://www.spinics.net/lists/linux-omap/msg55827.html It fixes the main issue of the previous series that was not booting at all due to the lack of twl support. That fix is mandatory to allow further work on the regulators DT bindings. In order to have a minimal i2c support, both i2c and twl must be added at the same time. Please note than some patches can be reshuffle with the previous OMAP4 series to avoid the intermediate step with static i2c initialization. That series is as well using the hwmods binding introduced in my previous series. The OMAP3/beagle support will be added in an other series. A couple of basic i2c devices are added for panda and sdp board. Patches are based on for_3.2/4_omap4_dt_early_devices + devicetree/test and are available here: git://gitorious.org/omap-pm/linux.git for_3.2/5_omap_dt_i2c_twl Tested on PandaBoard and sdp4430. Comments are welcome. Regards, Benoit Benoit Cousson (10): irq: Add stub for none DT build in irqdomain.h mfd: twl-core: Add initial DT support for twl4030/twl6030 documentation/dt: Add TWL4030 and TWL6030 bindings arm/dts: OMAP4: Add i2c controller nodes arm/dts: omap4-sdp: Set clock freq for i2c controllers arm/dts: omap4-sdp: Add twl6030 node arm/dts: omap4-panda: Add twl6030 node OMAP4: board-dt: Remove static i2c init arm/dts: omap4-sdp: Add i2c3 i2c4 devices arm/dts: omap4-panda: Add EEPROM entry in i2c3 G, Manjunath Kondaiah (3): i2c: OMAP: Add DT support for i2c controller documentation/dt: Add OMAP i2c bindings documentation arm/dts: omap4-panda: Set clock freq for i2c controllers Documentation/devicetree/bindings/i2c/omap-i2c.txt | 30 ++ .../devicetree/bindings/mfd/twl-familly.txt| 47 + arch/arm/boot/dts/omap4-panda.dts | 48 ++ arch/arm/boot/dts/omap4-sdp.dts| 66 + arch/arm/boot/dts/omap4.dtsi | 32 +++ arch/arm/mach-omap2/board-omap4-dt.c | 15 --- drivers/i2c/busses/i2c-omap.c | 23 - drivers/mfd/twl-core.c | 99 +++- include/linux/irqdomain.h |2 + 9 files changed, 340 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/13] mfd: twl-core: Add initial DT support for twl4030/twl6030
Add initial device-tree support for twl familly chips.
The current version is missing the regulator entries due
to the lack of DT regulator bindings for the moment.
Only the simple sub-modules that do not depend on
platform_data information can be initialized properly.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji T K balaj...@ti.com
Cc: Graeme Gregory g...@slimlogic.co.uk
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/twl-core.c | 99 ++--
1 files changed, 95 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 01ecfee..a12af12 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -33,6 +33,9 @@
#include linux/platform_device.h
#include linux/clk.h
#include linux/err.h
+#include linux/slab.h
+#include linux/of_irq.h
+#include linux/irqdomain.h
#include linux/regulator/machine.h
@@ -633,6 +636,55 @@ add_regulator(int num, struct regulator_init_data *pdata,
return add_regulator_linked(num, pdata, NULL, 0, features);
}
+#ifdef CONFIG_OF
+#define MODALIAS_SIZE 32
+
+static int add_of_children(struct i2c_client *client, unsigned long features)
+{
+ u32 reg;
+ struct device *child, *dev = client-dev;
+ struct device_node *node, *parent = client-dev.of_node;
+ int irq;
+ char alias[MODALIAS_SIZE];
+
+ for_each_child_of_node(parent, node) {
+ if (of_property_read_u32(node, reg, reg)) {
+ dev_err(dev, %s(): invalid reg on %s\n, __func__,
+ node-full_name);
+ continue;
+ }
+
+ irq = irq_of_parse_and_map(node, 0);
+
+ if (of_modalias_node(node, alias, MODALIAS_SIZE)) {
+ dev_err(dev, %s(): modalias failure on %s\n, __func__,
+ node-full_name);
+ continue;
+ }
+
+ if (of_device_is_compatible(node, ti,twl_reg)) {
+ dev_dbg(dev, %s(): add_regulator\n, __func__);
+ child = NULL;
+ } else {
+ dev_dbg(dev, %s(): add_child\n, __func__);
+ child = add_child(reg, alias, NULL, 0, true, irq, 0);
+ }
+
+ if (IS_ERR(child)) {
+ dev_err(dev, %s(): add_child failed: %ld\n, __func__,
+ PTR_ERR(child));
+ continue;
+ }
+ }
+ return 0;
+}
+#else
+static int add_of_children(struct device_node *parent, unsigned long features)
+{
+ return 0;
+}
+#endif
+
/*
* NOTE: We know the first 8 IRQs after pdata-base_irq are
* for the PIH, and the next are for the PWR_INT SIH, since
@@ -1182,22 +1234,53 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
int status;
unsignedi;
struct twl4030_platform_data*pdata = client-dev.platform_data;
+ struct device_node *node = client-dev.of_node;
u8 temp;
int ret = 0;
+ if (node !pdata) {
+ /*
+* XXX: Temporary fake pdata until the information
+* is correctly retrieved by every TWL modules from DT.
+*/
+ pdata = kzalloc(sizeof(struct twl4030_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ status = -ENOMEM;
+ goto exit;
+ }
+
+ /*
+* XXX: For the moment the IRQs for TWL seems to be encoded in
+* the global OMAP space. That should be cleaned to allow
+* dynamically adding a new IRQ controller.
+*/
+ if ((id-driver_data) TWL6030_CLASS) {
+ pdata-irq_base = TWL6030_IRQ_BASE;
+ pdata-irq_end = pdata-irq_base + TWL6030_BASE_NR_IRQS;
+ } else {
+ pdata-irq_base = TWL4030_IRQ_BASE;
+ pdata-irq_end = pdata-irq_base + TWL4030_BASE_NR_IRQS;
+ }
+ irq_domain_add_simple(node, pdata-irq_base);
+ }
+
if (!pdata) {
dev_dbg(client-dev, no platform data?\n);
- return -EINVAL;
+ status = -EINVAL;
+ goto fail_free;
}
if (i2c_check_functionality(client-adapter, I2C_FUNC_I2C) == 0) {
dev_dbg(client-dev, can't talk I2C?\n);
- return -EIO;
+ status = -EIO;
+ goto fail_free;
}
if (inuse) {
dev_dbg(client-dev, driver is already in use\n);
- return -EBUSY;
+ status = -EBUSY;
+ goto fail_free;
}
for (i = 0; i
[PATCH 0/7] OMAP3: Add basic DT support + i2c + twl
Hi Grant, Tony, This is second part of the rework of the original series done by Manju: http://www.spinics.net/lists/linux-omap/msg55827.html It introduces the OMAP3 DT support incrementaly like it was done for OMAP4. Patches are based on for_3.2/5_omap_dt_i2c_twl + devicetree/test and are available here: git://gitorious.org/omap-pm/linux.git for_3.2/6_omap3_dt_base Tested on Beagle XM. Comments are welcome. Regards, Benoit Benoit Cousson (7): arm/dts: Add initial device-tree support for OMAP3 SoC arm/dts: OMAP3: Add mpu and iva nodes arm/dts: OMAP3: Add i2c controllers nodes arm/dts: omap3-beagle: Include the generic omap3.dtsi arm/dts: omap3-beagle: Add twl4030 and EEPROM i2c devices OMAP3: board-dt: Add generic board file for DT support OMAP3: beagleboard: Remove DT support from regular board arch/arm/boot/dts/omap3-beagle.dts | 68 +- arch/arm/boot/dts/omap3.dtsi| 95 +++ arch/arm/mach-omap2/Kconfig | 10 +++ arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-omap3-dt.c| 74 arch/arm/mach-omap2/board-omap3beagle.c | 13 arch/arm/mach-omap2/pm.c|6 +- 7 files changed, 250 insertions(+), 17 deletions(-) create mode 100644 arch/arm/boot/dts/omap3.dtsi create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] arm/dts: omap3-beagle: Add twl4030 and EEPROM i2c devices
Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Add required clock frequencies for the i2c client devices existing
on beagle board.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 42
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index da13ec7..5d0a558 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -27,3 +27,45 @@
reg = 0x8000 0x2000; /* 512 MB */
};
};
+
+i2c1 {
+ clock-frequency = 260;
+
+ /*
+* Integrated Power Management Chip
+*/
+ twl@48 {
+ compatible = ti,twl4030;
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-controller;
+ #interrupt-cells = 1;
+ interrupt-parent = intc;
+ #address-cells = 1;
+ #size-cells = 0;
+ ranges = 0 0x48;
+
+ twl_rtc {
+ compatible = ti,twl_rtc;
+ interrupts = 11;
+ reg = 0;
+ };
+ };
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 10;
+
+ /*
+* Display monitor features are burnt in the EEPROM
+* as EDID data.
+*/
+ eeprom@50 {
+ compatible = ti,eeprom;
+ reg = 0x50;
+ };
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
Create an OMAP3 generic board to start the DT migration.
This file is doing the minimal initialization needed to boot
properly on a RAMDISK filesystem.
As soon as the OMAP3 specifics will be removed, that board will
be converted to an even more generic board-dt.c that will support
every OMAP2+ platforms.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55832.html
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/mach-omap2/Kconfig | 10 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3-dt.c | 74 ++
3 files changed, 85 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5d501d2..82f0df2 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -305,6 +305,16 @@ config MACH_OMAP_3630SDP
default y
select OMAP_PACKAGE_CBP
+config MACH_OMAP3_DT
+ bool Generic OMAP3 board (FDT support)
+ depends on ARCH_OMAP3
+ select OMAP_PACKAGE_CBB
+ select USE_OF
+ help
+ Support for generic TI OMAP3 boards using Flattened Device Tree.
+ Say Y here to enable OMAP3 device tree support
+ More information at Documentation/devicetree
+
config MACH_TI8168EVM
bool TI8168 Evaluation Module
depends on SOC_OMAPTI816X
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6ab9116..5144c17 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -197,6 +197,7 @@ obj-$(CONFIG_MACH_OVERO)+= board-overo.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
+obj-$(CONFIG_MACH_OMAP3_DT)+= board-omap3-dt.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
sdram-nokia.o
diff --git a/arch/arm/mach-omap2/board-omap3-dt.c
b/arch/arm/mach-omap2/board-omap3-dt.c
new file mode 100644
index 000..6eb56c6
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3-dt.c
@@ -0,0 +1,74 @@
+/*
+ * OMAP3 Device tree boards support
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/irqdomain.h
+#include linux/of_platform.h
+#include linux/i2c/twl.h
+
+#include asm/mach/arch.h
+#include plat/common.h
+
+#include mux.h
+#include common-board-devices.h
+#include sdram-micron-mt46h32m32lf-6.h
+
+
+static void __init omap3_init_early(void)
+{
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
+ mt46h32m32lf6_sdrc_params);
+}
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#endif
+
+static struct of_device_id omap_dt_match_table[] __initdata = {
+ { .compatible = simple-bus, },
+ { .compatible = ti,omap-infra, },
+ {}
+};
+
+static struct of_device_id omap_dt_intc_match[] __initdata = {
+ { .compatible = ti,omap3-intc, },
+ {}
+};
+
+static void __init omap3_init(void)
+{
+ struct device_node *node;
+
+ node = of_find_matching_node(NULL, omap_dt_intc_match);
+ if (node)
+ irq_domain_add_simple(node, 0);
+
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_serial_init();
+
+ of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+}
+
+static const char *omap3_dt_match[] __initdata = {
+ ti,omap3,
+ NULL
+};
+
+DT_MACHINE_START(OMAP3_DT, TI OMAP3 (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3_init_early,
+ .init_irq = omap3_init_irq,
+ .init_machine = omap3_init,
+ .timer = omap3_timer,
+ .dt_compat = omap3_dt_match,
+MACHINE_END
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
In order to avoid conflict with the new board-omap3-dt.c file,
remove the .dt_compat entry from the beagle regular board
file.
Any DT work for OMAP3 will have to be done on the generic DT
board file to avoid breaking the legacy board support until
DT migration is done.
Based on orginal patch fropm Manju:
http://www.spinics.net/lists/linux-omap/msg55832.html
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index a7923ca..2c358a2 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -19,7 +19,6 @@
#include linux/err.h
#include linux/clk.h
#include linux/io.h
-#include linux/of_platform.h
#include linux/leds.h
#include linux/gpio.h
#include linux/input.h
@@ -388,9 +387,7 @@ static int __init omap3_beagle_i2c_init(void)
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
ARRAY_SIZE(beagle_i2c_eeprom));
-#ifdef CONFIG_OF
omap_register_i2c_bus(2, 100, NULL, 0);
-#endif /* CONFIG_OF */
return 0;
}
@@ -528,10 +525,6 @@ static void __init beagle_opp_init(void)
static void __init omap3_beagle_init(void)
{
-#ifdef CONFIG_OF
- of_platform_prepare(NULL, NULL);
-#endif /* CONFIG_OF */
-
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
@@ -563,11 +556,6 @@ static void __init omap3_beagle_init(void)
beagle_opp_init();
}
-static const char *omap3_beagle_dt_match[] __initdata = {
- ti,omap3-beagle,
- NULL
-};
-
MACHINE_START(OMAP3_BEAGLE, OMAP3 Beagle Board)
/* Maintainer: Syed Mohammed Khasim - http://beagleboard.org */
.boot_params= 0x8100,
@@ -577,5 +565,4 @@ MACHINE_START(OMAP3_BEAGLE, OMAP3 Beagle Board)
.init_irq = omap3_beagle_init_irq,
.init_machine = omap3_beagle_init,
.timer = omap3_secure_timer,
- .dt_compat = omap3_beagle_dt_match,
MACHINE_END
--
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: [RFC/PATCH v2 08/13] dt: omap: i2c: add dt support for i2c1 controller
Hi Manju, On 8/23/2011 5:46 PM, G, Manjunath Kondaiah wrote: Hi Grant, [...] This function calls of_i2c_register_devices which attaches all the required parameters reg, irq, archdata etc into i2c adapter. But it will not attach platform_data which results empty pdata pointer in i2c child devices. Is this done purposefully? I think so, but anyway, we'd rather spend some time on doing a proper DT implementation than hacking more the AUXDATA temporary solution. I've just sent a reworked version of that series with a pure dt-no-auxdata-hack approach. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpuidle status in mainline for Beagleboard xM
javier Martin javier.mar...@vista-silicon.com writes: Hi Kevin, thanks for your help. CPU is staying in C0 probably because UARTs are not being idled, so SoC cannot hit deeper idle states. Try the following at the command line to to enable UART idle timeouts, so the SoC can attempt idle after the timeout period # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4) echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.3/sleep_timeout After 5 seconds of inactivity on the UARTs, you should see the SoC hitting deeper C-states. I've tried that but it still doesn't hit any C-state deeper than 0. I'll try the same test using your pm branch you pointed me out and post the results. The CPUidle stuff works in mainline (after allowing UARTs to idle). You only need my pm-wip/cpufreq branch for testing CPUfreq. 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 1/1] OMAP: omap_device: only override _noirq methods, not normal suspend/resume
Arnd Bergmann a...@arndb.de writes:
On Thursday 25 August 2011, Kevin Hilman wrote:
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -622,7 +622,8 @@ static struct dev_pm_domain omap_device_pm_domain = {
SET_RUNTIME_PM_OPS(_od_runtime_suspend, _od_runtime_resume,
_od_runtime_idle)
USE_PLATFORM_PM_SLEEP_OPS
- SET_SYSTEM_SLEEP_PM_OPS(_od_suspend_noirq, _od_resume_noirq)
+ .suspend_noirq = _od_suspend_noirq,
+ .resume_noirq = _od_resume_noirq,
}
};
This breaks if CONFIG_SUSPEND is not set and the
_od_suspend_noirq/_od_resume_noirq
functions are not defined.
Indeed.
Will post a fix shortly.
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] OMAP: omap_device: fix !CONFIG_SUSPEND case in _noirq handlers
The suspend/resume _noirq handlers were #ifdef'd out in the
!CONFIG_SUSPEND case, but were still assigned to the dev_pm_ops
struct. Fix by defining them to NULL in the !CONFIG_SUSPEND case.
Reported-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies to v3.1-rc4.
arch/arm/plat-omap/omap_device.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 9a6a538..02609ee 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -615,6 +615,9 @@ static int _od_resume_noirq(struct device *dev)
return pm_generic_resume_noirq(dev);
}
+#else
+#define _od_suspend_noirq NULL
+#define _od_resume_noirq NULL
#endif
static struct dev_pm_domain omap_device_pm_domain = {
--
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 2/7] arm/dts: OMAP3: Add mpu and iva nodes
On Thursday 01 September 2011 19:25:07 Benoit Cousson wrote:
/*
+* XXX: The cpus node is mandatory, but since the CPUs are as well
part
+* of the mpu subsystem below, it is not clear where the information
+* should be. Maybe here with a phandle inside the mpu?
+*/
+ cpus {
+ };
+
+ /*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
*/
soc {
compatible = ti,omap-infra;
+ mpu {
+ compatible = ti,omap3-mpu;
+ hwmods = mpu;
+ cpu@0 {
+ compatible = arm,cortex-a8;
+ };
+ };
+
I would always put the cpu nodes in the top-level, even if that's
a slight misrepresentation of the truth. The point is basically
that CPU nodes are special (you cannot have device drivers for them)
and that the device tree is basically laid out from the perspective
of the CPU, which may be different from the perspective that a
hardware designer has.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: omap_device: fix !CONFIG_SUSPEND case in _noirq handlers
On Thursday 01 September 2011 11:12:02 Kevin Hilman wrote: The suspend/resume _noirq handlers were #ifdef'd out in the !CONFIG_SUSPEND case, but were still assigned to the dev_pm_ops struct. Fix by defining them to NULL in the !CONFIG_SUSPEND case. Reported-by: Arnd Bergmann a...@arndb.de Signed-off-by: Kevin Hilman khil...@ti.com Acked-by: Arnd Bergmann a...@arndb.de Thansk for the fast response! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/13] mfd: twl-core: Add initial DT support for twl4030/twl6030
On Thursday 01 September 2011 19:21:20 Benoit Cousson wrote:
+#ifdef CONFIG_OF
+#define MODALIAS_SIZE 32
+
+static int add_of_children(struct i2c_client *client, unsigned long features)
+{
+ u32 reg;
+ struct device *child, *dev = client-dev;
+ struct device_node *node, *parent = client-dev.of_node;
+ int irq;
+ char alias[MODALIAS_SIZE];
+
+ for_each_child_of_node(parent, node) {
+ if (of_property_read_u32(node, reg, reg)) {
+ dev_err(dev, %s(): invalid reg on %s\n, __func__,
+ node-full_name);
+ continue;
+ }
+
Have you tried just calling calling of_platform_bus_probe on the
parent? If all child devices are in the device tree, I think that
should work, too. It probably requires some tweaking in the
child drivers though.
Arnd
--
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/3] OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration
Benoit Cousson b-cous...@ti.com writes:
Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already alocated 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.
Very nice, I started down this path in the original series, but didn't
finish.
Some minor comments below...
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/omap_device.c | 168
++
1 files changed, 114 insertions(+), 54 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index f2149be..752d72a 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,105 @@ static int omap_device_fill_resources(struct
omap_device *od,
}
/**
+ * omap_device_alloc - allocate an omap_device
+ * @pdev: platform_device that will be represent 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 = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt,
+ GFP_KERNEL);
+ if (!hwmods)
+ goto oda_exit2;
+
+ memcpy(hwmods, ohs, sizeof(struct omap_hwmod *) * oh_cnt);
+ od-hwmods = hwmods;
+ od-pdev = pdev;
+
+ if (pdev-num_resources pdev-resource)
+ dev_warn(pdev-dev, %s(): ressources already allocated %d\n,
typo: ressources (occurs again below)
also, this check/warn should probably go after the 'HACK' comment below.
+ __func__, pdev-num_resources);
+ /*
+ * HACK: Idealy the resources from DT should match, and hwmod
s/Idealy/Ideally/
+ * should just add the missing ones. Since the name is not
+ * properly populated by DT, stick to hwmod resources only.
I think this limitation is fine until we come to resolution in the named
resources debate.
+ */
+ res_count = omap_device_count_resources(od);
+ if (res_count 0) {
+ dev_dbg(pdev-dev, %s(): ressources 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) {
+ 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);
+ }
+
+ 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);
+}
+
+void omap_device_delete(struct omap_device *od)
+{
+ kfree(od-hwmods);
+ kfree(od);
maybe set pdev-archdata.od = NULL too.
+}
Re: [RFC PATCH 2/3] OMAP: omap_device: Add a DT parser for multiple strings
Benoit Cousson b-cous...@ti.com writes:
Add two helpers function to parse a property that contains multiple
strings.
These functions might be exported and moved to a common place if they
can to be useful elsewhere.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
These should just be folded into 3/3 where they are used (with a comment
changelog of course.)
Kevin
---
arch/arm/plat-omap/omap_device.c | 39
++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 752d72a..70361f8 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -315,6 +315,45 @@ 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;
+}
+
/* Public functions for use by core code */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omap: hsmmc: Normalize dma cleanup operations
Reuse omap_hsmmc_dma_cleanup even for normal dma teardown in
omap_hsmmc_dma_cb. Consolidate multiple points of dma unmap into a
single location in post_req function, to prevent double unmapping.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 20 +---
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..5b7776c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -999,7 +999,8 @@ static void omap_hsmmc_dma_cleanup(struct omap_hsmmc_host
*host, int errno)
{
int dma_ch;
- host-data-error = errno;
+ if (host-data)
+ host-data-error = errno;
spin_lock(host-irq_lock);
dma_ch = host-dma_ch;
@@ -1007,12 +1008,8 @@ static void omap_hsmmc_dma_cleanup(struct
omap_hsmmc_host *host, int errno)
spin_unlock(host-irq_lock);
if (host-use_dma dma_ch != -1) {
- dma_unmap_sg(mmc_dev(host-mmc), host-data-sg,
- host-data-sg_len,
- omap_hsmmc_get_dma_dir(host, host-data));
omap_free_dma(dma_ch);
}
- host-data = NULL;
}
/*
@@ -1370,7 +1367,7 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status,
void *cb_data)
{
struct omap_hsmmc_host *host = cb_data;
struct mmc_data *data;
- int dma_ch, req_in_progress;
+ int req_in_progress;
if (!(ch_status OMAP_DMA_BLOCK_IRQ)) {
dev_warn(mmc_dev(host-mmc), unexpected dma status %x\n,
@@ -1394,16 +1391,9 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status,
void *cb_data)
return;
}
- if (!data-host_cookie)
- dma_unmap_sg(mmc_dev(host-mmc), data-sg, data-sg_len,
-omap_hsmmc_get_dma_dir(host, data));
-
req_in_progress = host-req_in_progress;
- dma_ch = host-dma_ch;
- host-dma_ch = -1;
spin_unlock(host-irq_lock);
-
- omap_free_dma(dma_ch);
+ omap_hsmmc_dma_cleanup(host, 0);
/* If DMA has finished after TC, complete the request */
if (!req_in_progress) {
@@ -1575,7 +1565,7 @@ static void omap_hsmmc_post_req(struct mmc_host *mmc,
struct mmc_request *mrq,
struct omap_hsmmc_host *host = mmc_priv(mmc);
struct mmc_data *data = mrq-data;
- if (host-use_dma) {
+ if (data-host_cookie) {
dma_unmap_sg(mmc_dev(host-mmc), data-sg, data-sg_len,
omap_hsmmc_get_dma_dir(host, data));
data-host_cookie = 0;
--
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 0/2] omap: hsmmc: Cleanup omap hsmmc dma routines
The first patch substitutes the dma_cleanup function in place of the body of the code which does the same thing. The dma unmap operation is now restricted just to the post_req function. The second patch minimizes holding spin lock during dma configuration, where it is not necessary. Venkatraman S (2): omap: hsmmc: normalize dma cleanup operations omap: hsmmc: don't hold spinlock during dma configuration drivers/mmc/host/omap_hsmmc.c | 22 ++ 1 files changed, 6 insertions(+), 16 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap: hsmmc: Don't hold spinlock during dma configuration
No need to hold the spinlock during a rather long dma configuration
sequence inside dma callback, which doesn't need it.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5b7776c..c5fd413 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1384,10 +1384,10 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status,
void *cb_data)
data = host-mrq-data;
host-dma_sg_idx++;
if (host-dma_sg_idx host-dma_len) {
+ spin_unlock(host-irq_lock);
/* Fire up the next transfer. */
omap_hsmmc_config_dma_params(host, data,
data-sg + host-dma_sg_idx);
- spin_unlock(host-irq_lock);
return;
}
--
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] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
Marc Dietich wrote at Thursday, September 01, 2011 5:14 AM: I'll add Stephen Warren from NVIDIA to the CC list. He has more HW to test on. Here are the results I found: Harmony: Tegra USB3 - SMSC9514 hub: NOT affected (Unplugging LAN cable, or disabling SMSC9514 LAN driver doesn't change this) Seaboard (springbank; clamshell): Tegra USB1 - no hub: Affected Seaboard (seaboard non-clamshell): Tegra USB1 - no hub: Affected Tegra USB3 - no hub: Affected TrimSlice: Tegra USB3 - unknown hub: Affected This implies there's something different about Harmony. Is the USB hub a clue? Seaboard doesn't have one, and although I don't know what model TrimSlice uses, I assume it's different since I know TrimSlice's Ethernet is not the same as Harmony's. I don't see anything in board-harmony.c vs. board-seaboard.c that'd affect anything USB-related. Perhaps there's some kind of bootloader or BCT difference. However, my Harmony and both Seaboards both use (a very old) U-Boot and BCT from ChromeOS, so I don't imagine there's actually much difference there. -- nvpublic -- 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 00/13] OMAP4: Add DT support for i2c and twl6030
On Thursday 01 September 2011 19:21:16 Benoit Cousson wrote: This is a rework of the original series done by Manju: http://www.spinics.net/lists/linux-omap/msg55827.html It fixes the main issue of the previous series that was not booting at all due to the lack of twl support. That fix is mandatory to allow further work on the regulators DT bindings. In order to have a minimal i2c support, both i2c and twl must be added at the same time. Please note than some patches can be reshuffle with the previous OMAP4 series to avoid the intermediate step with static i2c initialization. That series is as well using the hwmods binding introduced in my previous series. The OMAP3/beagle support will be added in an other series. A couple of basic i2c devices are added for panda and sdp board. Patches are based on for_3.2/4_omap4_dt_early_devices + devicetree/test and are available here: git://gitorious.org/omap-pm/linux.git for_3.2/5_omap_dt_i2c_twl Tested on PandaBoard and sdp4430. I think this is great stuff. I missed the original series, but it's definitely good to see progress on this! Arnd -- 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/7] OMAP: PM: omap_device: add omap_hwmod_name_get_odev
On Thu, Sep 1, 2011 at 06:48, Cousson, Benoit b-cous...@ti.com wrote: Nishanth, Do you have any objection to replace that API with omap_hwmod_name_get_pdev? None. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: omap_device: fix !CONFIG_SUSPEND case in _noirq handlers
On Thursday, September 01, 2011, Arnd Bergmann wrote: On Thursday 01 September 2011 11:12:02 Kevin Hilman wrote: The suspend/resume _noirq handlers were #ifdef'd out in the !CONFIG_SUSPEND case, but were still assigned to the dev_pm_ops struct. Fix by defining them to NULL in the !CONFIG_SUSPEND case. Reported-by: Arnd Bergmann a...@arndb.de Signed-off-by: Kevin Hilman khil...@ti.com Acked-by: Arnd Bergmann a...@arndb.de Thansk for the fast response! I'll apply the patch when kernel.org is back in order. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
Mark Salter msalter at redhat.com writes:
On Wed, 2011-08-31 at 00:03 +0800, ming.lei at canonical.com wrote:
...
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
...
Consider moving the #ifdef inside the function. :)
I'm wondering if this doesn't really belong in the DMA API for any
future architectures that can't avoid prolonged write buffering to DMA
coherent memory.
I suspect the semantics needed exist in mmiowb(). Honestly, I'm not an expert
of either ehci USB and ARM platforms but it looks that way to me after reading
the thread.
BTW, ChromiumOS has had a performance bug open for quite a while:
http://code.google.com/p/chromium-os/issues/detail?id=11503
Vince Palatin said he would try it.
mmiowb() was originally implemented for SGI SN2 (IA64/Altix) machines but
applies to any case where MMIO (any uncached writes really) and regular (ie
cached) memory writes need to be ordered.
The wmb() vs mmiowb() thread explains this pretty well:
http://www.mail-archive.com/linux-ia64@vger.kernel.org/msg03379.html
IIUC, ARM mitigates this for most drivers by including
an implicit write buffer flush in the mmio write routines.
The write flush is part of the MMIO writel() semantics AFAIK because MMIO writes
have to be strongly ordered (PCI requirement).
This takes
care of the drivers which write to a mmio device register after writing
something to shared DMA memory. IIUC, this doesn't help ehci because the
host controller is polling to see what the cpu writes to the shared
memory.
Write flush in writel() does help for the not RUNNING - RUNNING state
transition (I'm looking at qh_link_async()). It doesn't help for already
RUNNING case.
Other hardware which polls shared memory like that will likely
have the same problem and could use buffer drain helpers as well.
Yup - agreed.
cheers,
grant
--
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 3/3] OMAP: omap_device: Add a method to build an omap_device from a DT node
Benoit Cousson b-cous...@ti.com writes:
Add a notifier called during device_add phase. If a of_node is present,
retrieve the hwmod entry in order to populate propely 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.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Nice, minor comment below...
---
arch/arm/plat-omap/omap_device.c | 102
++
1 files changed, 102 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 70361f8..0ae9e7f 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_platform.h
+#include linux/notifier.h
#include plat/omap_device.h
#include plat/omap_hwmod.h
@@ -94,6 +96,8 @@
#define USE_WAKEUP_LAT 0
#define IGNORE_WAKEUP_LAT1
+#define MAX_HWMOD_NAME_SIZE 32
+
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,
@@ -354,6 +358,100 @@ static int _dt_get_property(const char *prop, int len,
int index, char *output,
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, Cannot allocate omap_device for :%s\n,
+ oh_name);
+ ret = PTR_ERR(od);
+ goto odbfd_exit1;
+ }
+
+ if (of_get_property(pdev-dev.of_node, no_idle_on_suspend, NULL))
+ omap_device_disable_idle_on_suspend(pdev);
+
+ pdev-dev.pm_domain = omap_device_pm_domain;
+
+odbfd_exit1:
+ kfree(hwmods);
+odbfd_exit:
+ return ret;
+}
+
+static int _omap_device_notifier_call(struct notifier_block *nb,
+ unsigned long event, void *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ switch (event) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ if (pdev-dev.of_node) {
+ dev_dbg(pdev-dev, add_device with DT bindings\n);
+ omap_device_build_from_dt(pdev);
+ }
+ break;
+
+ case BUS_NOTIFY_DEL_DEVICE:
+ dev_dbg(pdev-dev, del_device\n);
Need a delete/cleanup here.
Looks like all all it needs to do is call omap_device_delete()?
Kevin
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
/* Public functions for use by core code */
@@ -1064,8 +1162,12 @@ struct device omap_device_parent = {
.parent = platform_bus,
};
+static struct notifier_block platform_nb;
Re: [GIT PULL v2] OMAP: clock/powerdomain/clockdomain/hwmod: fixes for 3.1-rc
On Tue, 30 Aug 2011, Paul Walmsley wrote: On Tue, 23 Aug 2011, Paul Walmsley wrote: 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://git.pwsan.com/linux-2.6 prcm-fixes-a-3.1rc Just checking up on this. Any issues with this branch? By the way, this branch has now been updated to base on v3.1-rc4. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] OMAP2: clockdomain/powerdomain: remove OMAP_CHIP bitmasks
Remove the OMAP_CHIP bitmasks from the powerdomain and clockdomain code. In their place, use lists of powerdomains and clockdomains to register for particular chips and chip families. The intention of this change is to reduce the number of lines that need to be patched to add support for new SoCs that are similar to previous SoCs. This series has been boot-tested on a 2430SDP, BeagleBoard 35xx and 37xx, and PandaBoard 44xxES2, but I don't have boards for all of the different variants needed for a complete test. A git branch is available at git://git.pwsan.com/linux-2.6 based on v3.1-rc4 with prcm-fixes-a-3.1rc. - Paul --- pwrdm_clkdm_remove_omap_chip_cleanup_3.2 textdata bss dec hex filename 6330180 656956 5591124 12578260 bfedd4 vmlinux.omap2plus_defconfig.orig 6330432 656052 5591124 12577608 bfeb48 vmlinux.omap2plus_defconfig Paul Walmsley (4): 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 arch/arm/mach-omap2/Makefile |5 arch/arm/mach-omap2/clockdomain.c| 149 +++- 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 | 155 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/io.c |8 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 - 18 files changed, 1104 insertions(+), 1299 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains2420_data.c create mode 100644 arch/arm/mach-omap2/clockdomains2430_data.c create mode 100644 arch/arm/mach-omap2/clockdomains3xxx_data.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] OMAP: clockdomain: split clkdm_init()
In preparation for OMAP_CHIP() removal, split clkdm_init() into four
functions. This allows some of them to be called multiple times: for
example, clkdm_register_clkdms() can be called once to register
clockdomains that are common to a group of SoCs, and once to register
clockdomains that are specific to a single SoC.
The appropriate order to call these functions - which is enforced
by the code - is:
1. clkdm_register_platform_funcs()
2. clkdm_register_clkdms() (can be called multiple times)
3. clkdm_register_autodeps() (optional; deprecated)
4. clkdm_complete_init()
Convert the OMAP2, 3, and 4 clockdomain init code to use these new
functions.
While here, improve documentation, and increase CodingStyle
conformance by shortening some local variable names.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomain.c| 130 +-
arch/arm/mach-omap2/clockdomain.h|7 +
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 13 ++
arch/arm/mach-omap2/clockdomains44xx_data.c |5 +
4 files changed, 121 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 8f08906..b73a1dc 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -257,43 +257,113 @@ static void _resolve_clkdm_deps(struct clockdomain
*clkdm,
/* Public functions */
/**
- * clkdm_init - set up the clockdomain layer
- * @clkdms: optional pointer to an array of clockdomains to register
- * @init_autodeps: optional pointer to an array of autodeps to register
- * @custom_funcs: func pointers for arch specific implementations
- *
- * Set up internal state. If a pointer to an array of clockdomains
- * @clkdms was supplied, loop through the list of clockdomains,
- * register all that are available on the current platform. Similarly,
- * if a pointer to an array of clockdomain autodependencies
- * @init_autodeps was provided, register those. No return value.
+ * clkdm_register_platform_funcs - register clockdomain implementation fns
+ * @co: func pointers for arch specific implementations
+ *
+ * Register the list of function pointers used to implement the
+ * clockdomain functions on different OMAP SoCs. Should be called
+ * before any other clkdm_register*() function. Returns -EINVAL if
+ * @co is null, -EEXIST if platform functions have already been
+ * registered, or 0 upon success.
+ */
+int clkdm_register_platform_funcs(struct clkdm_ops *co)
+{
+ if (!co)
+ return -EINVAL;
+
+ if (arch_clkdm)
+ return -EEXIST;
+
+ arch_clkdm = co;
+
+ return 0;
+};
+
+/**
+ * clkdm_register_clkdms - register SoC clockdomains
+ * @cs: pointer to an array of struct clockdomain to register
+ *
+ * Register the clockdomains available on a particular OMAP SoC. Must
+ * be called after clkdm_register_platform_funcs(). May be called
+ * multiple times. Returns -EACCES if called before
+ * clkdm_register_platform_funcs(); -EINVAL if the argument @cs is
+ * null; or 0 upon success.
*/
-void clkdm_init(struct clockdomain **clkdms,
- struct clkdm_autodep *init_autodeps,
- struct clkdm_ops *custom_funcs)
+int clkdm_register_clkdms(struct clockdomain **cs)
{
struct clockdomain **c = NULL;
- struct clockdomain *clkdm;
- struct clkdm_autodep *autodep = NULL;
- if (!custom_funcs)
- WARN(1, No custom clkdm functions registered\n);
- else
- arch_clkdm = custom_funcs;
+ if (!arch_clkdm)
+ return -EACCES;
+
+ if (!cs)
+ return -EINVAL;
+
+ for (c = cs; *c; c++)
+ _clkdm_register(*c);
- if (clkdms)
- for (c = clkdms; *c; c++)
- _clkdm_register(*c);
+ return 0;
+}
+
+/**
+ * clkdm_register_autodeps - register autodeps (if required)
+ * @ia: pointer to a static array of struct clkdm_autodep to register
+ *
+ * Register clockdomain automatic dependencies. These are
+ * clockdomain wakeup and sleep dependencies that are automatically
+ * added whenever the first clock inside a clockdomain is enabled, and
+ * removed whenever the last clock inside a clockdomain is disabled.
+ * These are currently only used on OMAP3 devices, and are deprecated,
+ * since they waste energy. However, until the OMAP2/3 IP block
+ * enable/disable sequence can be converted to match the OMAP4
+ * sequence, they are needed.
+ *
+ * Must be called only after all of the SoC clockdomains are
+ * registered, since the function will resolve autodep clockdomain
+ * names into clockdomain pointers.
+ *
+ * The struct clkdm_autodep @ia array must be static, as this function
+ * does not copy the array elements.
+ *
+ * Returns -EACCES if called before any clockdomains have been
+ * registered, -EINVAL if called with a null @ia argument, -EEXIST if
+ * autodeps have already
[PATCH 3/4] OMAP: powerdomain: split pwrdm_init() into two functions
In preparation for OMAP_CHIP() removal, split pwrdm_init() into three
functions. This allows some of them to be called multiple times: for
example, pwrdm_register_pwrdms() can be called once to register
powerdomains that are common to a group of SoCs, and once to register
powerdomains that are specific to a single SoC.
The appropriate order to call these functions - which is enforced
by the code - is:
1. pwrdm_register_platform_funcs()
2. pwrdm_register_pwrdms() (can be called multiple times)
3. pwrdm_complete_init()
Convert the OMAP2, 3, and 4 powerdomain init code to use these new
functions.
While here, improve documentation, and increase CodingStyle
conformance by shortening some local variable names.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomain.c | 84 ---
arch/arm/mach-omap2/powerdomain.h |4 +
arch/arm/mach-omap2/powerdomains2xxx_data.c |4 +
arch/arm/mach-omap2/powerdomains3xxx_data.c |4 +
arch/arm/mach-omap2/powerdomains44xx_data.c |4 +
5 files changed, 74 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index ef71fdd..3483537 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1,7 +1,7 @@
/*
* OMAP powerdomain control
*
- * Copyright (C) 2007-2008 Texas Instruments, Inc.
+ * Copyright (C) 2007-2008, 2011 Texas Instruments, Inc.
* Copyright (C) 2007-2011 Nokia Corporation
*
* Written by Paul Walmsley
@@ -194,36 +194,76 @@ static int _pwrdm_post_transition_cb(struct powerdomain
*pwrdm, void *unused)
/* Public functions */
/**
- * pwrdm_init - set up the powerdomain layer
- * @pwrdms: array of struct powerdomain pointers to register
- * @custom_funcs: func pointers for arch specific implementations
+ * pwrdm_register_platform_funcs - register powerdomain implementation fns
+ * @po: func pointers for arch specific implementations
*
- * Loop through the array of powerdomains @pwrdms, registering all
- * that are available on the current CPU. Also, program all
- * powerdomain target state as ON; this is to prevent domains from
- * hitting low power states (if bootloader has target states set to
- * something other than ON) and potentially even losing context while
- * PM is not fully initialized. The PM late init code can then program
- * the desired target state for all the power domains. No return
- * value.
+ * Register the list of function pointers used to implement the
+ * powerdomain functions on different OMAP SoCs. Should be called
+ * before any other pwrdm_register*() function. Returns -EINVAL if
+ * @po is null, -EEXIST if platform functions have already been
+ * registered, or 0 upon success.
*/
-void pwrdm_init(struct powerdomain **pwrdms, struct pwrdm_ops *custom_funcs)
+int pwrdm_register_platform_funcs(struct pwrdm_ops *po)
+{
+ if (!po)
+ return -EINVAL;
+
+ if (arch_pwrdm)
+ return -EEXIST;
+
+ arch_pwrdm = po;
+
+ return 0;
+}
+
+/**
+ * pwrdm_register_pwrdms - register SoC powerdomains
+ * @ps: pointer to an array of struct powerdomain to register
+ *
+ * Register the powerdomains available on a particular OMAP SoC. Must
+ * be called after pwrdm_register_platform_funcs(). May be called
+ * multiple times. Returns -EACCES if called before
+ * pwrdm_register_platform_funcs(); -EINVAL if the argument @ps is
+ * null; or 0 upon success.
+ */
+int pwrdm_register_pwrdms(struct powerdomain **ps)
{
struct powerdomain **p = NULL;
- struct powerdomain *temp_p;
- if (!custom_funcs)
- WARN(1, powerdomain: No custom pwrdm functions registered\n);
- else
- arch_pwrdm = custom_funcs;
+ if (!arch_pwrdm)
+ return -EEXIST;
- if (pwrdms) {
- for (p = pwrdms; *p; p++)
- _pwrdm_register(*p);
- }
+ if (!ps)
+ return -EINVAL;
+
+ for (p = ps; *p; p++)
+ _pwrdm_register(*p);
+
+ return 0;
+}
+
+/**
+ * pwrdm_complete_init - set up the powerdomain layer
+ *
+ * Do whatever is necessary to initialize registered powerdomains and
+ * powerdomain code. Currently, this programs the next power state
+ * for each powerdomain to ON. This prevents powerdomains from
+ * unexpectedly losing context or entering high wakeup latency modes
+ * with non-power-management-enabled kernels. Must be called after
+ * pwrdm_register_pwrdms(). Returns -EACCES if called before
+ * pwrdm_register_pwrdms(), or 0 upon success.
+ */
+int pwrdm_complete_init(void)
+{
+ struct powerdomain *temp_p;
+
+ if (list_empty(pwrdm_list))
+ return -EACCES;
list_for_each_entry(temp_p, pwrdm_list, node)
pwrdm_set_next_pwrst(temp_p, PWRDM_POWER_ON);
+
+ return 0;
}
/**
diff --git a/arch/arm/mach-omap2/powerdomain.h
[PATCH 4/4] OMAP: powerdomain: remove omap_chip bitmasks
At Tony's request, remove the omap_chip bitmasks from the powerdomain
definitions. Instead, initialize powerdomains based on one or more
lists that are applicable to a particular SoC family, variant, and
silicon revision.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/io.c |4 +
arch/arm/mach-omap2/powerdomain-common.c |7 +-
arch/arm/mach-omap2/powerdomain.c|3 -
arch/arm/mach-omap2/powerdomain.h|5 +
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c | 19 -
arch/arm/mach-omap2/powerdomains2xxx_data.c | 42 +++-
arch/arm/mach-omap2/powerdomains3xxx_data.c | 79 +-
arch/arm/mach-omap2/powerdomains44xx_data.c | 16
8 files changed, 79 insertions(+), 96 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index d098c87..40b6d47 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -341,11 +341,11 @@ void __init omap2_init_common_infrastructure(void)
u8 postsetup_state;
if (cpu_is_omap242x()) {
- omap2xxx_powerdomains_init();
+ omap242x_powerdomains_init();
omap242x_clockdomains_init();
omap2420_hwmod_init();
} else if (cpu_is_omap243x()) {
- omap2xxx_powerdomains_init();
+ omap243x_powerdomains_init();
omap243x_clockdomains_init();
omap2430_hwmod_init();
} else if (cpu_is_omap34xx()) {
diff --git a/arch/arm/mach-omap2/powerdomain-common.c
b/arch/arm/mach-omap2/powerdomain-common.c
index 171fccd..f97afff 100644
--- a/arch/arm/mach-omap2/powerdomain-common.c
+++ b/arch/arm/mach-omap2/powerdomain-common.c
@@ -1,9 +1,8 @@
/*
- * linux/arch/arm/mach-omap2/powerdomain-common.c
- * Contains common powerdomain framework functions
+ * Common powerdomain framework functions
*
- * Copyright (C) 2010 Texas Instruments, Inc.
- * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2010-2011 Texas Instruments, Inc.
+ * Copyright (C) 2010 Nokia Corporation
*
* Derived from mach-omap2/powerdomain.c written by Paul Walmsley
*
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 3483537..896cb4c 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -81,9 +81,6 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
if (!pwrdm || !pwrdm-name)
return -EINVAL;
- if (!omap_chip_is(pwrdm-omap_chip))
- return -EINVAL;
-
if (cpu_is_omap44xx()
pwrdm-prcm_partition == OMAP4430_INVALID_PRCM_PARTITION) {
pr_err(powerdomain: %s: missing OMAP4 PRCM partition ID\n,
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 489e1c5..8febd84 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -78,7 +78,6 @@ struct powerdomain;
/**
* struct powerdomain - OMAP powerdomain
* @name: Powerdomain name
- * @omap_chip: represents the OMAP chip types containing this pwrdm
* @prcm_offs: the address offset from CM_BASE/PRM_BASE
* @prcm_partition: (OMAP4 only) the PRCM partition ID containing @prcm_offs
* @pwrsts: Possible powerdomain power states
@@ -98,7 +97,6 @@ struct powerdomain;
*/
struct powerdomain {
const char *name;
- const struct omap_chip_id omap_chip;
const s16 prcm_offs;
const u8 pwrsts;
const u8 pwrsts_logic_ret;
@@ -212,7 +210,8 @@ int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
-extern void omap2xxx_powerdomains_init(void);
+extern void omap242x_powerdomains_init(void);
+extern void omap243x_powerdomains_init(void);
extern void omap3xxx_powerdomains_init(void);
extern void omap44xx_powerdomains_init(void);
diff --git a/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
b/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
index 4210c33..bf30483 100644
--- a/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
@@ -1,7 +1,7 @@
/*
* OMAP2/3 common powerdomain definitions
*
- * Copyright (C) 2007-2008 Texas Instruments, Inc.
+ * Copyright (C) 2007-2008, 2011 Texas Instruments, Inc.
* Copyright (C) 2007-2011 Nokia Corporation
*
* Paul Walmsley, Jouni Högander
@@ -12,20 +12,6 @@
*/
/*
- * To Do List
- * - Move the Sleep/Wakeup dependencies from Power Domain framework to
- *Clock Domain Framework
- */
-
-/*
- * This file contains all of the powerdomains that have some element
- * of software control for the OMAP24xx and OMAP34xx chips.
- *
- * This is not an exhaustive listing of powerdomains on the chips; only
- * powerdomains that can be controlled in software.
- */
-
-/*
* The names for the
Re: [RFC/PATCH v2 08/13] dt: omap: i2c: add dt support for i2c1 controller
Hi Benoit, On Thu, Sep 01, 2011 at 07:34:11PM +0200, Cousson, Benoit wrote: Hi Manju, On 8/23/2011 5:46 PM, G, Manjunath Kondaiah wrote: Hi Grant, [...] This function calls of_i2c_register_devices which attaches all the required parameters reg, irq, archdata etc into i2c adapter. But it will not attach platform_data which results empty pdata pointer in i2c child devices. Is this done purposefully? I think so, but anyway, we'd rather spend some time on doing a proper DT implementation than hacking more the AUXDATA temporary solution. I've just sent a reworked version of that series with a pure dt-no-auxdata-hack approach. Thanks for initiating aux data cleanup series. Let us syncup on further changes and follow up so that we can have this feature with v3.2 merge window. Grant, Can you have a look and provide feedback on all the patches which are done for omap dt work. -M -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/10] OMAP4: DSS: HDMI: Use specific HDMI timings structure
Hi, On Thu, Sep 1, 2011 at 1:44 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com Define new HDMI timings structure to replace the OMAP DSS timing strucutre in hdmi.c to have the HDMI include defintion out of DSS. structure and definition typoed. And the point is not to remove hdmi stuff from dss, but dss stuff from hdmi. The generic hdmi driver cannot use omap dss specific stuff. Signed-off-by: Mythri P K mythr...@ti.com --- drivers/video/omap2/dss/hdmi.c | 22 +++--- drivers/video/omap2/dss/hdmi.h | 15 ++- 2 files changed, 33 insertions(+), 4 deletions(-) diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c index 084a47e..ba1ad06 100644 --- a/drivers/video/omap2/dss/hdmi.c +++ b/drivers/video/omap2/dss/hdmi.c @@ -537,6 +537,20 @@ static int read_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length) return 0; } +static void copy_hdmi_to_dss_timings(struct hdmi_video_timings hdmi_timings, + struct omap_video_timings *timings) Pass hdmi_timings as a const pointer. Ok. 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 v2 02/10] OMAP4: DSS: HDMI: Move pll and video configuration
Hi,
On Thu, Sep 1, 2011 at 1:57 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
As the pll and the video configuration info are part of the ip_data those
structures are moved to the ip_data strtucure.Also the functions are modified
accordingly to take care of this movement.
structure typoed, and use a space after period.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 34 +++---
drivers/video/omap2/dss/hdmi.h | 18 ++
2 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 544f93e..084a47e 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -59,7 +59,6 @@ static struct {
u8 edid[HDMI_EDID_MAX_LENGTH];
u8 edid_set;
bool custom_set;
- struct hdmi_config cfg;
struct clk *sys_clk;
} hdmi;
@@ -230,11 +229,11 @@ int hdmi_init_display(struct omap_dss_device *dssdev)
}
static int hdmi_pll_init(struct hdmi_ip_data *ip_data,
- enum hdmi_clk_refsel refsel, int dcofreq,
- struct hdmi_pll_info *fmt, u16 sd)
+ enum hdmi_clk_refsel refsel)
{
u32 r;
void __iomem *pll_base = hdmi_pll_base(ip_data);
+ struct hdmi_pll_info *fmt = ip_data-pll_data;
/* PLL start always use manual mode */
REG_FLD_MOD(pll_base, PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
@@ -251,9 +250,9 @@ static int hdmi_pll_init(struct hdmi_ip_data *ip_data,
r = FLD_MOD(r, 0x1, 13, 13); /* PLL_REFEN */
r = FLD_MOD(r, 0x0, 14, 14); /* PHY_CLKINEN de-assert during locking */
- if (dcofreq) {
+ if (fmt-dcofreq) {
/* divider programming for frequency beyond 1000Mhz */
- REG_FLD_MOD(pll_base, PLLCTRL_CFG3, sd, 17, 10);
+ REG_FLD_MOD(pll_base, PLLCTRL_CFG3, fmt-regsd, 17, 10);
r = FLD_MOD(r, 0x4, 3, 1); /* 1000MHz and 2000MHz */
} else {
r = FLD_MOD(r, 0x2, 3, 1); /* 500MHz and 1000MHz */
@@ -379,8 +378,7 @@ static int hdmi_phy_init(struct hdmi_ip_data *ip_data)
return 0;
}
-static int hdmi_pll_program(struct hdmi_ip_data *ip_data,
- struct hdmi_pll_info *fmt)
+static int hdmi_pll_program(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
enum hdmi_clk_refsel refsel;
@@ -399,7 +397,7 @@ static int hdmi_pll_program(struct hdmi_ip_data *ip_data,
refsel = HDMI_REFSEL_SYSCLK;
- r = hdmi_pll_init(ip_data, refsel, fmt-dcofreq, fmt, fmt-regsd);
+ r = hdmi_pll_init(ip_data, refsel);
I don't think I quite understood why refsel is not part of the pll info.
And if it has to be hardcoded, you could as well do that in
hdmi_pll_init().
Ok , yes that is better.
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
Re: [PATCH v2 02/10] OMAP4: DSS: HDMI: Move pll and video configuration
On Fri, 2011-09-02 at 10:41 +0530, K, Mythri P wrote:
Hi,
On Thu, Sep 1, 2011 at 1:57 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
As the pll and the video configuration info are part of the ip_data those
structures are moved to the ip_data strtucure.Also the functions are
modified
accordingly to take care of this movement.
structure typoed, and use a space after period.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 34 +++---
drivers/video/omap2/dss/hdmi.h | 18 ++
2 files changed, 25 insertions(+), 27 deletions(-)
-static int hdmi_pll_program(struct hdmi_ip_data *ip_data,
- struct hdmi_pll_info *fmt)
+static int hdmi_pll_program(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
enum hdmi_clk_refsel refsel;
@@ -399,7 +397,7 @@ static int hdmi_pll_program(struct hdmi_ip_data
*ip_data,
refsel = HDMI_REFSEL_SYSCLK;
- r = hdmi_pll_init(ip_data, refsel, fmt-dcofreq, fmt, fmt-regsd);
+ r = hdmi_pll_init(ip_data, refsel);
I don't think I quite understood why refsel is not part of the pll info.
And if it has to be hardcoded, you could as well do that in
hdmi_pll_init().
Ok , yes that is better.
So, why refsel is not part of the pll info? The HW doesn't support
changing it? If so, is it only for OMAPs or for all SoCs?
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
Re: [PATCH v2 04/10] OMAP4: DSS: HDMI: Move the common header file
Hi, On Thu, Sep 1, 2011 at 2:30 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com Some of the header file definitions of HDMI IP are needed by audio driver thus moving the common defintion to more generic Include/video. Signed-off-by: Mythri P K mythr...@ti.com --- drivers/video/omap2/dss/dss.h | 10 - drivers/video/omap2/dss/hdmi.c | 1 + drivers/video/omap2/dss/hdmi.h | 53 include/video/omaphdmi.h | 86 4 files changed, 87 insertions(+), 63 deletions(-) create mode 100644 include/video/omaphdmi.h As the functions will be renamed to hdmi_ti_4xxx_*, perhaps the header file is a bit misnamed. Also, please first do the changes/renamings/etc, and only then move the finished header file to include/video/ to prevent unnecessary changes in include/video. The Include/video hdmi header file is a generic file that can be used across 4 ,5 and Netra. Actually even the hdmi_ti_5xxx_ definitions would come in this header so what do you think it can be named as ? , If you have any better name for hdmi_ti_4xxx_ip as well please suggest would be happy to take it , as it doesn't sound that intuitive to me as well. 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
Re: [PATCH 10/10] OMAP: DSS2: DSI Video mode support
Hi,
On Thursday 01 September 2011 06:44 PM, Valkeinen, Tomi wrote:
On Tue, 2011-08-30 at 16:21 +0530, Archit Taneja wrote:
Add initial support for DSI video mode panels:
- Add a new structure omap_dss_dsi_videomode_data in the member panel in
omap_dss_device struct. This allows panel driver to configure dsi video_mode
specific parameters.
- Configure basic DSI video mode timing parameters: HBP, HFP, HSA, VBP, VFP,
VSA,
TL and VACT.
- Configure DSI protocol engine registers for video_mode support.
- Introduce functions dsi_video_mode_enable() and dsi_video_mode_disable() which
enable/disable video mode for a given virtual channel and a given pixel
format
type.
Things left for later
- Add functions to check for errors in video mode timings provided by panel.
- Configure timing registers required for command mode interleaving.
Signed-off-by: Archit Tanejaarc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 256 -
include/video/omapdss.h | 32 +
2 files changed, 259 insertions(+), 29 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 582ae7b..e3d5c38 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -132,7 +132,7 @@ struct dsi_reg { u16 idx; };
#define DSI_IRQ_TA_TIMEOUT(1 20)
#define DSI_IRQ_ERROR_MASK \
(DSI_IRQ_HS_TX_TIMEOUT | DSI_IRQ_LP_RX_TIMEOUT | DSI_IRQ_SYNC_LOST | \
- DSI_IRQ_TA_TIMEOUT)
+ DSI_IRQ_TA_TIMEOUT | DSI_IRQ_SYNC_LOST)
#define DSI_IRQ_CHANNEL_MASK 0xf
/* Virtual channel interrupts */
@@ -2472,6 +2472,12 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
dsi_cio_timings(dsidev);
+ if (dssdev-panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ /* DDR_CLK_ALWAYS_ON */
+ REG_FLD_MOD(dsidev, DSI_CLK_CTRL,
+ dssdev-panel.dsi_vm_data.ddr_clk_always_on, 13, 13);
+ }
+
For the DDR clock to start, you need to send a null packet, don't you?
Yes, we have to send a null packet, but that is for the case when DDR
clock is required by the panel to function properly. Hence we need to
start the DDR clock right at the beginning(before we start sending
DCS/generic commands to configure the panel).
The panel driver may set DDR_CLK_ALWAYS_ON even if it has its own
internal clock to function. In that case, we don't need it to be enabled
right at the beginning, i.e, when we send DCS commands to configure the
panel. In this case, the signal TxRequestHS will be asserted later on
when we enable video mode for a VC, and that will start the DDR clock.
I had left out the sending null packet part as I think its a more
specific case. Setting DDR_CLK_ALWAYS_ON affects timing calculations,
that is why I added it as a configurable parameter for the panel driver.
Archit
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
Re: [PATCH v2 02/10] OMAP4: DSS: HDMI: Move pll and video configuration
Hi,
On Fri, Sep 2, 2011 at 10:43 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-09-02 at 10:41 +0530, K, Mythri P wrote:
Hi,
On Thu, Sep 1, 2011 at 1:57 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
As the pll and the video configuration info are part of the ip_data those
structures are moved to the ip_data strtucure.Also the functions are
modified
accordingly to take care of this movement.
structure typoed, and use a space after period.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 34 +++---
drivers/video/omap2/dss/hdmi.h | 18 ++
2 files changed, 25 insertions(+), 27 deletions(-)
-static int hdmi_pll_program(struct hdmi_ip_data *ip_data,
- struct hdmi_pll_info *fmt)
+static int hdmi_pll_program(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
enum hdmi_clk_refsel refsel;
@@ -399,7 +397,7 @@ static int hdmi_pll_program(struct hdmi_ip_data
*ip_data,
refsel = HDMI_REFSEL_SYSCLK;
- r = hdmi_pll_init(ip_data, refsel, fmt-dcofreq, fmt, fmt-regsd);
+ r = hdmi_pll_init(ip_data, refsel);
I don't think I quite understood why refsel is not part of the pll info.
And if it has to be hardcoded, you could as well do that in
hdmi_pll_init().
Ok , yes that is better.
So, why refsel is not part of the pll info? The HW doesn't support
changing it? If so, is it only for OMAPs or for all SoCs?
It is a variable parameter ,H/w supports changing it but it is never tried,
I was considering hard-coding it in the hdmi.c and passing it,
so that there would be no hard-coding in IP functions.
Thanks and regards,
Mythri.
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
Re: [PATCH v2 04/10] OMAP4: DSS: HDMI: Move the common header file
On Fri, 2011-09-02 at 10:45 +0530, K, Mythri P wrote: Hi, On Thu, Sep 1, 2011 at 2:30 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com Some of the header file definitions of HDMI IP are needed by audio driver thus moving the common defintion to more generic Include/video. Signed-off-by: Mythri P K mythr...@ti.com --- drivers/video/omap2/dss/dss.h | 10 - drivers/video/omap2/dss/hdmi.c |1 + drivers/video/omap2/dss/hdmi.h | 53 include/video/omaphdmi.h | 86 4 files changed, 87 insertions(+), 63 deletions(-) create mode 100644 include/video/omaphdmi.h As the functions will be renamed to hdmi_ti_4xxx_*, perhaps the header file is a bit misnamed. Also, please first do the changes/renamings/etc, and only then move the finished header file to include/video/ to prevent unnecessary changes in include/video. The Include/video hdmi header file is a generic file that can be used across 4 ,5 and Netra. Actually even the hdmi_ti_5xxx_ definitions would come in this header so what do you think it can be named as ? , If you have any better name for hdmi_ti_4xxx_ip as well please suggest would be happy to take it , as it doesn't sound that intuitive to me as well. Well, I think whatever the header name is, it should somehow match the functions and the .c file. So if the functions and the .c file in this case are hdmi_ti_4xxx, then it'd be logical for the .h file to be named similarly. So, if it will contain functions for other IPs also, perhaps just leave the 4xxx out of it and name it hdmi_ti.h. Then the functions could be named hdmi_ti_4xxx_yyy(), and accordingly the .c file can be hdmi_ti_4xxx.c. Or, perhaps ti_hdmi.h (and funcs .c files accordingly) would be more standard, as it's quite usual to name drivers etc. starting with the company name. 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
Re: [PATCH v2 04/10] OMAP4: DSS: HDMI: Move the common header file
Hi, On Fri, Sep 2, 2011 at 10:54 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2011-09-02 at 10:45 +0530, K, Mythri P wrote: Hi, On Thu, Sep 1, 2011 at 2:30 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com Some of the header file definitions of HDMI IP are needed by audio driver thus moving the common defintion to more generic Include/video. Signed-off-by: Mythri P K mythr...@ti.com --- drivers/video/omap2/dss/dss.h | 10 - drivers/video/omap2/dss/hdmi.c | 1 + drivers/video/omap2/dss/hdmi.h | 53 include/video/omaphdmi.h | 86 4 files changed, 87 insertions(+), 63 deletions(-) create mode 100644 include/video/omaphdmi.h As the functions will be renamed to hdmi_ti_4xxx_*, perhaps the header file is a bit misnamed. Also, please first do the changes/renamings/etc, and only then move the finished header file to include/video/ to prevent unnecessary changes in include/video. The Include/video hdmi header file is a generic file that can be used across 4 ,5 and Netra. Actually even the hdmi_ti_5xxx_ definitions would come in this header so what do you think it can be named as ? , If you have any better name for hdmi_ti_4xxx_ip as well please suggest would be happy to take it , as it doesn't sound that intuitive to me as well. Well, I think whatever the header name is, it should somehow match the functions and the .c file. So if the functions and the .c file in this case are hdmi_ti_4xxx, then it'd be logical for the .h file to be named similarly. So, if it will contain functions for other IPs also, perhaps just leave the 4xxx out of it and name it hdmi_ti.h. Then the functions could be named hdmi_ti_4xxx_yyy(), and accordingly the .c file can be hdmi_ti_4xxx.c. Or, perhaps ti_hdmi.h (and funcs .c files accordingly) would be more standard, as it's quite usual to name drivers etc. starting with the company name. Thanks i shall change it to ti_hdmi.h and rename functions accordingly. Thanks and regards, Mythri. 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
Re: [PATCH 10/10] OMAP: DSS2: DSI Video mode support
On Fri, 2011-09-02 at 10:45 +0530, Archit Taneja wrote:
Hi,
On Thursday 01 September 2011 06:44 PM, Valkeinen, Tomi wrote:
On Tue, 2011-08-30 at 16:21 +0530, Archit Taneja wrote:
Add initial support for DSI video mode panels:
- Add a new structure omap_dss_dsi_videomode_data in the member panel in
omap_dss_device struct. This allows panel driver to configure dsi
video_mode
specific parameters.
- Configure basic DSI video mode timing parameters: HBP, HFP, HSA, VBP,
VFP, VSA,
TL and VACT.
- Configure DSI protocol engine registers for video_mode support.
- Introduce functions dsi_video_mode_enable() and dsi_video_mode_disable()
which
enable/disable video mode for a given virtual channel and a given pixel
format
type.
Things left for later
- Add functions to check for errors in video mode timings provided by
panel.
- Configure timing registers required for command mode interleaving.
Signed-off-by: Archit Tanejaarc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 256
-
include/video/omapdss.h | 32 +
2 files changed, 259 insertions(+), 29 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 582ae7b..e3d5c38 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -132,7 +132,7 @@ struct dsi_reg { u16 idx; };
#define DSI_IRQ_TA_TIMEOUT (1 20)
#define DSI_IRQ_ERROR_MASK \
(DSI_IRQ_HS_TX_TIMEOUT | DSI_IRQ_LP_RX_TIMEOUT | DSI_IRQ_SYNC_LOST | \
- DSI_IRQ_TA_TIMEOUT)
+ DSI_IRQ_TA_TIMEOUT | DSI_IRQ_SYNC_LOST)
#define DSI_IRQ_CHANNEL_MASK 0xf
/* Virtual channel interrupts */
@@ -2472,6 +2472,12 @@ static int dsi_cio_init(struct omap_dss_device
*dssdev)
dsi_cio_timings(dsidev);
+ if (dssdev-panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ /* DDR_CLK_ALWAYS_ON */
+ REG_FLD_MOD(dsidev, DSI_CLK_CTRL,
+ dssdev-panel.dsi_vm_data.ddr_clk_always_on, 13, 13);
+ }
+
For the DDR clock to start, you need to send a null packet, don't you?
Yes, we have to send a null packet, but that is for the case when DDR
clock is required by the panel to function properly. Hence we need to
start the DDR clock right at the beginning(before we start sending
DCS/generic commands to configure the panel).
The panel driver may set DDR_CLK_ALWAYS_ON even if it has its own
internal clock to function. In that case, we don't need it to be enabled
right at the beginning, i.e, when we send DCS commands to configure the
panel. In this case, the signal TxRequestHS will be asserted later on
when we enable video mode for a VC, and that will start the DDR clock.
Why would the panel need DDR_CLK_ALWAYS_ON if it has an another fclk?
I'm not that familiar with video mode, but somehow it would sound
logical that if the panel wants DDR clock to be always on, it should be
started right from the beginning. And if the panel doesn't need DDR
clock to be always on, there's no need to even set DDR_CLK_ALWAYS_ON.
I had left out the sending null packet part as I think its a more
specific case. Setting DDR_CLK_ALWAYS_ON affects timing calculations,
that is why I added it as a configurable parameter for the panel driver.
Ok. But your patches handle the calculations, don't they?
Sending a null packet to start the DDR clk is rather OMAP specific
internal thing, so I don't want to require the panel driver to need to
know that it must send a null packet to start the clock. So if the ddr
clk is not started automatically, I think we should have a function to
do that (dsi_start_ddr_clk or whatever), which will then send the null
packet (and perhaps return an error if DDR_CLK_ALWAYS_ON is not set,
dunno...).
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
