Re: OMAP3 ISP capabilities, resizer
Hello,
* I have a test program, http://pmeerw.net/scaler.c, which exercises the
OMAP3 ISP resizer standalone with the pipeline given below; it crashes the
system quite reliably on 3.7 and recent kernels :(
the reason for the crash is that the ISP resizer can still be busy and
doesn't like to be turned off then; a little sleep before
omap3isp_sbl_disable() helps (or waiting for the ISP resize to become
idle, see the patch below)
I'm not sure what omap3isp_module_sync_idle() is supposed to do, it
immediately returns since we are in SINGLESHOT mode and
isp_pipeline_ready() is false
The function is supposed to wait until the module becomes idle. I'm not sure
why we don't call it for memory-to-memory pipelines, I need to investigate
that. Sakari, do you remember what we've done there ?
with below patch I am happily resizing...
// snip, RFC
From: Peter Meerwald p.meerw...@bct-electronic.com
Date: Wed, 12 Feb 2014 15:59:20 +0100
Subject: [PATCH] omap3isp: Wait for resizer to become idle before
disabling
---
drivers/media/platform/omap3isp/ispresizer.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/platform/omap3isp/ispresizer.c
b/drivers/media/platform/omap3isp/ispresizer.c
index d11fb26..fea98f7 100644
--- a/drivers/media/platform/omap3isp/ispresizer.c
+++ b/drivers/media/platform/omap3isp/ispresizer.c
@@ -1145,6 +1145,7 @@ static int resizer_set_stream(struct v4l2_subdev *sd,
int enable) struct isp_video *video_out = res-video_out;
struct isp_device *isp = to_isp_device(res);
struct device *dev = to_device(res);
+ unsigned long timeout = 0;
if (res-state == ISP_PIPELINE_STREAM_STOPPED) {
if (enable == ISP_PIPELINE_STREAM_STOPPED)
@@ -1176,6 +1177,15 @@ static int resizer_set_stream(struct v4l2_subdev *sd,
int enable) if (omap3isp_module_sync_idle(sd-entity, res-wait,
res-stopping))
dev_dbg(dev, %s: module stop timeout.\n,
sd-name);
+
+ while (omap3isp_resizer_busy(res)) {
+ if (timeout++ 1000) {
+ dev_alert(isp-dev, ISP resizer does not
become idle\n);
+ return -ETIMEDOUT;
+ }
+ udelay(100);
+ }
+
Let's try to avoid busy loops if possible. Does it help if you comment out
the
condition at the top of omap3isp_module_sync_idle() ?
omap3isp_sbl_disable(isp, OMAP3_ISP_SBL_RESIZER_READ |
OMAP3_ISP_SBL_RESIZER_WRITE);
omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_RESIZER);
tried without the check at the top of omap3isp_module_sync_idle()
I am not sure yet when and how many interrupts occur in memory-to-memory
(singleshot) mode... and the code might be racy:
if the resizer is done, we don't want to wait for another interrupt which
might never happen;
if the resizer is not done (how do we know?), we need to test that and
set the stopping flag so that omap3isp_module_sync_is_stopping() wakes us
when done
omap3isp_module_sync_idle():
if (pipe-stream_state == ISP_PIPELINE_STREAM_STOPPED ||
(0 pipe-stream_state == ISP_PIPELINE_STREAM_SINGLESHOT
!isp_pipeline_ready(pipe)))
return 0;
isp_pipeline_ready() seems to be the wrong check for resizer done;
the final interrupt could occur here, before setting 'stopping'
/*
* atomic_set() doesn't include memory barrier on ARM platform for SMP
* scenario. We'll call it here to avoid race conditions.
*/
atomic_set(stopping, 1);
regards, p.
--
Peter Meerwald
+43-664-218 (mobile)
--
To unsubscribe from this list: send the line unsubscribe 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 3/4] Regulators: TPS65218: Add Regulator driver for TPS65218 PMIC
On Saturday 15 February 2014 01:51 AM, Mark Brown wrote: On Thu, Feb 06, 2014 at 11:20:13AM +0530, Keerthy wrote: This patch adds support for TPS65218 PMIC regulators. The regulators set consists of 6 DCDCs and 1 LDO. The output voltages are configurable and are meant to supply power to the main processor and other components. Applied, thanks. Please use subject lines consistent with the subsystem. Sure. Thanks a lot Mark. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM/dts: hdmi-codec: panda/es dt entries
HDMI codec dummy entries for Panda/ES.
Signed-off-by: Paolo Pisati paolo.pis...@canonical.com
---
Depends on 0f7f3d1 ASoC: hdmi-codec: Add devicetree binding with
documentation, eligible for a 3.14-rcX fix.
arch/arm/boot/dts/omap4-panda-common.dtsi |9 -
arch/arm/boot/dts/omap4-panda-es.dts |3 ++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..f4aeaa1 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -36,9 +36,15 @@
};
};
+ hdmi_audio: hdmi_audio@0 {
+ compatible = linux,hdmi-audio;
+ status = okay;
+ };
+
sound: sound {
compatible = ti,abe-twl6040;
ti,model = PandaBoard;
+ ti,audio-codec = hdmi_audio;
ti,mclk-freq = 3840;
@@ -57,7 +63,8 @@
HSMIC, Headset Mic,
Headset Mic, Headset Mic Bias,
AFML, Line In,
- AFMR, Line In;
+ AFMR, Line In,
+ HDMI Out, TX;
};
/* HS USB Port 1 Power */
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..70152d6 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -23,7 +23,8 @@
Line Out, AUXL,
Line Out, AUXR,
AFML, Line In,
- AFMR, Line In;
+ AFMR, Line In,
+ HDMI Out, TX;
};
/* PandaboardES has external pullups on SCL SDA */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAPDSS: use DISPC register to detect context loss
On Friday 14 February 2014 01:59 PM, Tomi Valkeinen wrote:
Instead of relying on the OMAP specific
omap_pm_get_dev_context_loss_count() to detect register context loss, we
can achieve the same in a much simpler way by just observing the DISPC
registers.
We always set DISPC's load mode to LOAD_FRAME_ONLY, which is not the
reset value. Thus we can just observe the load mode to see if we have
lost register context.
Nice trick :p
Reviewed-by: Archit Taneja arc...@ti.com
Archit
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index bbeb8dd7f108..1659aa912d2b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -100,8 +100,6 @@ static struct {
struct platform_device *pdev;
void __iomem*base;
- int ctx_loss_cnt;
-
int irq;
unsigned long core_clk_rate;
@@ -357,29 +355,20 @@ static void dispc_save_context(void)
if (dss_has_feature(FEAT_CORE_CLK_DIV))
SR(DIVISOR);
- dispc.ctx_loss_cnt = dss_get_ctx_loss_count();
dispc.ctx_valid = true;
- DSSDBG(context saved, ctx_loss_count %d\n, dispc.ctx_loss_cnt);
+ DSSDBG(context saved\n);
}
static void dispc_restore_context(void)
{
- int i, j, ctx;
+ int i, j;
DSSDBG(dispc_restore_context\n);
if (!dispc.ctx_valid)
return;
- ctx = dss_get_ctx_loss_count();
-
- if (ctx = 0 ctx == dispc.ctx_loss_cnt)
- return;
-
- DSSDBG(ctx_loss_count: saved %d, current %d\n,
- dispc.ctx_loss_cnt, ctx);
-
/*RR(IRQENABLE);*/
/*RR(CONTROL);*/
RR(CONFIG);
@@ -3768,6 +3757,15 @@ static int dispc_runtime_suspend(struct device *dev)
static int dispc_runtime_resume(struct device *dev)
{
+ /*
+* The reset value for load mode is 0 (OMAP_DSS_LOAD_CLUT_AND_FRAME)
+* but we always initialize it to 2 (OMAP_DSS_LOAD_FRAME_ONLY) in
+* _omap_dispc_initial_config(). We can thus use it to detect if
+* we have lost register context.
+*/
+ if (REG_GET(DISPC_CONFIG, 2, 1) == OMAP_DSS_LOAD_FRAME_ONLY)
+ return 0;
+
_omap_dispc_initial_config();
dispc_restore_context();
--
To unsubscribe from this list: send the line unsubscribe 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/5] ARM: omap2: cm-t35: Add regulators and clock for camera sensor
Mauro, Tony,
On Monday 10 February 2014 22:54:40 Laurent Pinchart wrote:
The camera sensor will soon require regulators and clocks. Register
fixed regulators for its VAA and VDD power supplies and a fixed rate
clock for its master clock.
This patch is a prerequisite for a set of 4 patches that need to go through
the linux-media tree. It would simpler if it could go through the same tree as
well. Given that arch/arm/mach-omap2/board-cm-t35.c has seen very little
activity recently I believe the risk of conflict is pretty low. Tony, would
that be fine with you ?
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/board-cm-t35.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c index 8dd0ec8..018353d 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -16,6 +16,8 @@
*
*/
+#include linux/clk-provider.h
+#include linux/clkdev.h
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
@@ -542,8 +544,22 @@ static struct isp_platform_data cm_t35_isp_pdata = {
.subdevs = cm_t35_isp_subdevs,
};
+static struct regulator_consumer_supply cm_t35_camera_supplies[] = {
+ REGULATOR_SUPPLY(vaa, 3-005d),
+ REGULATOR_SUPPLY(vdd, 3-005d),
+};
+
static void __init cm_t35_init_camera(void)
{
+ struct clk *clk;
+
+ clk = clk_register_fixed_rate(NULL, mt9t001-clkin, NULL, CLK_IS_ROOT,
+ 4800);
+ clk_register_clkdev(clk, NULL, 3-005d);
+
+ regulator_register_fixed(2, cm_t35_camera_supplies,
+ ARRAY_SIZE(cm_t35_camera_supplies));
+
if (omap3_init_camera(cm_t35_isp_pdata) 0)
pr_warn(CM-T3x: Failed registering camera device!\n);
}
--
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 1/5] ARM: omap2: cm-t35: Add regulators and clock for camera sensor
Hi Laurent,
On 02/18/14 14:47, Laurent Pinchart wrote:
Mauro, Tony,
On Monday 10 February 2014 22:54:40 Laurent Pinchart wrote:
The camera sensor will soon require regulators and clocks. Register
fixed regulators for its VAA and VDD power supplies and a fixed rate
clock for its master clock.
This patch is a prerequisite for a set of 4 patches that need to go through
the linux-media tree. It would simpler if it could go through the same tree
as
well. Given that arch/arm/mach-omap2/board-cm-t35.c has seen very little
activity recently I believe the risk of conflict is pretty low.
Indeed, as we work on DT stuff of cm-t35/3730 and pretty much stopped
updating the board-cm-t35.c file.
Tony, would
that be fine with you ?
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c index 8dd0ec8..018353d 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -16,6 +16,8 @@
*
*/
+#include linux/clk-provider.h
+#include linux/clkdev.h
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
@@ -542,8 +544,22 @@ static struct isp_platform_data cm_t35_isp_pdata = {
.subdevs = cm_t35_isp_subdevs,
};
+static struct regulator_consumer_supply cm_t35_camera_supplies[] = {
+REGULATOR_SUPPLY(vaa, 3-005d),
+REGULATOR_SUPPLY(vdd, 3-005d),
+};
+
static void __init cm_t35_init_camera(void)
{
+struct clk *clk;
+
+clk = clk_register_fixed_rate(NULL, mt9t001-clkin, NULL, CLK_IS_ROOT,
+ 4800);
+clk_register_clkdev(clk, NULL, 3-005d);
+
+regulator_register_fixed(2, cm_t35_camera_supplies,
+ ARRAY_SIZE(cm_t35_camera_supplies));
+
if (omap3_init_camera(cm_t35_isp_pdata) 0)
pr_warn(CM-T3x: Failed registering camera device!\n);
}
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: support more DT properties
On Monday 17 February 2014 05:06 PM, Daniel Mack wrote: This should probably be done implicitly through mmc_of_parse(), but that doesn't play well along with the multi-slot model the hsmmc driver features. Hence, for now, do it manually. The properties are already documented in Documentation/devicetree/bindings/mmc/mmc.txt. Signed-off-by: Daniel Mack zon...@gmail.com looks good to me Acked-by: Balaji T K balaj...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 2815de6..a5a38cc 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1765,6 +1765,12 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev) if (of_find_property(np, ti,needs-special-hs-handling, NULL)) pdata-slots[0].features |= HSMMC_HAS_HSPE_SUPPORT; + if (of_find_property(np, keep-power-in-suspend, NULL)) + pdata-slots[0].pm_caps |= MMC_PM_KEEP_POWER; + + if (of_find_property(np, enable-sdio-wakeup, NULL)) + pdata-slots[0].pm_caps |= MMC_PM_WAKE_SDIO_IRQ; + return pdata; } #else -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] mmc: omap_hsmmc: Add support for quirky omap3 hsmmc controller
On Friday 14 February 2014 11:15 AM, Nishanth Menon wrote:
When device is booted using devicetree, platforms impacted by Erratum
2.1.1.128 is not detected easily in the mmc driver. This erratum
indicates that the module cannot do multi-block transfers. Platforms
such as LDP which use OMAP3 ES revision prior to ES3.0 are impacted by
this.
Provide a new compatible property ti,omap3-pre-es3-hsmmc to allow
driver to determine if driver needs to implement quirks associated
with the specific module version (primarily because the IP revision
information is not sufficient for the same).
Signed-off-by: Nishanth Menon n...@ti.com
looks good to me
Acked-by: Balaji T K balaj...@ti.com
---
Changes since v1:
- new compatible flag as suggested by Tony which contains
the relevant controller flag to work around the erratum
V1: https://patchwork.kernel.org/patch/3514851/
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
drivers/mmc/host/omap_hsmmc.c | 26 +---
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 8c8908a..ce80561 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -10,6 +10,7 @@ Required properties:
- compatible:
Should be ti,omap2-hsmmc, for OMAP2 controllers
Should be ti,omap3-hsmmc, for OMAP3 controllers
+ Should be ti,omap3-pre-es3-hsmmc for OMAP3 controllers pre ES3.0
Should be ti,omap4-hsmmc, for OMAP4 controllers
- ti,hwmods: Must be mmcn, n is controller instance starting 1
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 575f9cc..390f421 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -192,6 +192,11 @@ struct omap_hsmmc_host {
struct omap_mmc_platform_data *pdata;
};
+struct omap_mmc_of_data {
+ u32 reg_offset;
+ u8 controller_flags;
+};
+
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -1678,18 +1683,29 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
#endif
#ifdef CONFIG_OF
-static u16 omap4_reg_offset = 0x100;
+static const struct omap_mmc_of_data omap3_pre_es3_mmc_of_data = {
+ /* See 35xx errata 2.1.1.128 in SPRZ278F */
+ .controller_flags = OMAP_HSMMC_BROKEN_MULTIBLOCK_READ,
+};
+
+static const struct omap_mmc_of_data omap4_mmc_of_data = {
+ .reg_offset = 0x100,
+};
static const struct of_device_id omap_mmc_of_match[] = {
{
.compatible = ti,omap2-hsmmc,
},
{
+ .compatible = ti,omap3-pre-es3-hsmmc,
+ .data = omap3_pre_es3_mmc_of_data,
+ },
+ {
.compatible = ti,omap3-hsmmc,
},
{
.compatible = ti,omap4-hsmmc,
- .data = omap4_reg_offset,
+ .data = omap4_mmc_of_data,
},
{},
};
@@ -1759,6 +1775,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
struct pinctrl *pinctrl;
+ const struct omap_mmc_of_data *data;
match = of_match_device(of_match_ptr(omap_mmc_of_match), pdev-dev);
if (match) {
@@ -1768,8 +1785,9 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
return PTR_ERR(pdata);
if (match-data) {
- const u16 *offsetp = match-data;
- pdata-reg_offset = *offsetp;
+ data = match-data;
+ pdata-reg_offset = data-reg_offset;
+ pdata-controller_flags |= data-controller_flags;
}
}
--
To unsubscribe from this list: send the line unsubscribe 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/5] ARM: omap2: cm-t35: Add regulators and clock for camera sensor
Hi Igor,
On Tuesday 18 February 2014 16:03:44 Igor Grinberg wrote:
On 02/18/14 14:47, Laurent Pinchart wrote:
On Monday 10 February 2014 22:54:40 Laurent Pinchart wrote:
The camera sensor will soon require regulators and clocks. Register
fixed regulators for its VAA and VDD power supplies and a fixed rate
clock for its master clock.
This patch is a prerequisite for a set of 4 patches that need to go
through the linux-media tree. It would simpler if it could go through the
same tree as well. Given that arch/arm/mach-omap2/board-cm-t35.c has seen
very little activity recently I believe the risk of conflict is pretty
low.
Indeed, as we work on DT stuff of cm-t35/3730 and pretty much stopped
updating the board-cm-t35.c file.
DT support for the OMAP3 ISP is coming. Too slowly, but it's coming :-)
Tony, would
that be fine with you ?
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
Thank you. Tony, could I get your ack as well to push this through Mauro's
tree ?
---
arch/arm/mach-omap2/board-cm-t35.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c index 8dd0ec8..018353d 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -16,6 +16,8 @@
*
*/
+#include linux/clk-provider.h
+#include linux/clkdev.h
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
@@ -542,8 +544,22 @@ static struct isp_platform_data cm_t35_isp_pdata = {
.subdevs = cm_t35_isp_subdevs,
};
+static struct regulator_consumer_supply cm_t35_camera_supplies[] = {
+ REGULATOR_SUPPLY(vaa, 3-005d),
+ REGULATOR_SUPPLY(vdd, 3-005d),
+};
+
static void __init cm_t35_init_camera(void)
{
+ struct clk *clk;
+
+ clk = clk_register_fixed_rate(NULL, mt9t001-clkin, NULL,
CLK_IS_ROOT,
+4800);
+ clk_register_clkdev(clk, NULL, 3-005d);
+
+ regulator_register_fixed(2, cm_t35_camera_supplies,
+ ARRAY_SIZE(cm_t35_camera_supplies));
+
if (omap3_init_camera(cm_t35_isp_pdata) 0)
pr_warn(CM-T3x: Failed registering camera device!\n);
}
--
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 v7 03/12] mfd: omap-usb-host: Use clock names as per function for reference clocks
On 02/14/2014 03:33 PM, Lee Jones wrote:
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 60a3bed..ce620a8 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device
*pdev)
goto err_mem;
}
- omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
+ omap-xclk60mhsp1_ck = devm_clk_get(dev, refclk_60m_ext_p1);
You can't do that. These changes will have to be in the same patch as
the core change i.e. where they are initialised.
I'm not touching them anywhere in this series. When core changes are you
referring to?
The ones in:
arch/arm/mach-omap2/cclock3xxx_data.c
OK, right. They are now no longer needed so I'll get rid of them.
In fact that change should either be in a separate patch or combined with PATCH
2
in this series. What do you suggest?
cheers,
-roger
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
goto err_mem;
}
- omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
+ omap-xclk60mhsp2_ck = devm_clk_get(dev, refclk_60m_ext_p2);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
goto err_mem;
}
- omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
+ omap-init_60m_fclk = devm_clk_get(dev, refclk_60m_int);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
dev_err(dev, init_60m_fclk failed error:%d\n, ret);
--
To unsubscribe from this list: send the line unsubscribe 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 v7 03/12] mfd: omap-usb-host: Use clock names as per function for reference clocks
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 60a3bed..ce620a8 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device
*pdev)
goto err_mem;
}
-omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
+omap-xclk60mhsp1_ck = devm_clk_get(dev, refclk_60m_ext_p1);
You can't do that. These changes will have to be in the same patch as
the core change i.e. where they are initialised.
I'm not touching them anywhere in this series. When core changes are you
referring to?
The ones in:
arch/arm/mach-omap2/cclock3xxx_data.c
OK, right. They are now no longer needed so I'll get rid of them.
In fact that change should either be in a separate patch or combined with
PATCH 2
in this series. What do you suggest?
A separate patch will do fine.
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
goto err_mem;
}
-omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
+omap-xclk60mhsp2_ck = devm_clk_get(dev, refclk_60m_ext_p2);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
goto err_mem;
}
-omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
+omap-init_60m_fclk = devm_clk_get(dev, refclk_60m_int);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
dev_err(dev, init_60m_fclk failed error:%d\n, ret);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote:
debugfs files to show the contents of important dsps registers.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/musb/musb_dsps.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 593d3c9..d0a97d6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -46,6 +46,8 @@
#include linux/of_irq.h
#include linux/usb/of.h
+#include linux/debugfs.h
+
#include musb_core.h
static const struct of_device_id musb_dsps_of_match[];
@@ -137,6 +139,26 @@ struct dsps_glue {
unsigned long last_timer;/* last timer data for each instance */
struct dsps_context context;
+ struct debugfs_regset32 regset;
+ struct dentry *dbgfs_root;
+};
+
+static const struct debugfs_reg32 dsps_musb_regs[] = {
+ { revision, 0x00 },
+ { control,0x14 },
+ { status, 0x18 },
+ { eoi,0x24 },
+ { intr0_stat, 0x30 },
+ { intr1_stat, 0x34 },
+ { intr0_set, 0x38 },
+ { intr1_set, 0x3c },
+ { txmode, 0x70 },
+ { rxmode, 0x74 },
+ { autoreq,0xd0 },
+ { srpfixtime, 0xd4 },
+ { tdown, 0xd8 },
+ { phy_utmi, 0xe0 },
+ { mode, 0xe8 },
};
static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -369,6 +391,30 @@ out:
return ret;
}
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
+ root = debugfs_create_dir(buf, NULL);
+ if (!root)
wrong, you should be using IS_ERR()
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Tue, Feb 18, 2014 at 10:20:54AM -0600, Felipe Balbi wrote:
On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote:
debugfs files to show the contents of important dsps registers.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/musb/musb_dsps.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 593d3c9..d0a97d6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -46,6 +46,8 @@
#include linux/of_irq.h
#include linux/usb/of.h
+#include linux/debugfs.h
+
#include musb_core.h
static const struct of_device_id musb_dsps_of_match[];
@@ -137,6 +139,26 @@ struct dsps_glue {
unsigned long last_timer;/* last timer data for each instance */
struct dsps_context context;
+ struct debugfs_regset32 regset;
+ struct dentry *dbgfs_root;
+};
+
+static const struct debugfs_reg32 dsps_musb_regs[] = {
+ { revision, 0x00 },
+ { control,0x14 },
+ { status, 0x18 },
+ { eoi,0x24 },
+ { intr0_stat, 0x30 },
+ { intr1_stat, 0x34 },
+ { intr0_set, 0x38 },
+ { intr1_set, 0x3c },
+ { txmode, 0x70 },
+ { rxmode, 0x74 },
+ { autoreq,0xd0 },
+ { srpfixtime, 0xd4 },
+ { tdown, 0xd8 },
+ { phy_utmi, 0xe0 },
+ { mode, 0xe8 },
};
static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -369,6 +391,30 @@ out:
return ret;
}
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
+ root = debugfs_create_dir(buf, NULL);
+ if (!root)
wrong, you should be using IS_ERR()
!root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Tue, Feb 18, 2014 at 08:59:11AM -0800, Greg KH wrote:
On Tue, Feb 18, 2014 at 10:20:54AM -0600, Felipe Balbi wrote:
On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote:
debugfs files to show the contents of important dsps registers.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/musb/musb_dsps.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 593d3c9..d0a97d6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -46,6 +46,8 @@
#include linux/of_irq.h
#include linux/usb/of.h
+#include linux/debugfs.h
+
#include musb_core.h
static const struct of_device_id musb_dsps_of_match[];
@@ -137,6 +139,26 @@ struct dsps_glue {
unsigned long last_timer;/* last timer data for each instance */
struct dsps_context context;
+ struct debugfs_regset32 regset;
+ struct dentry *dbgfs_root;
+};
+
+static const struct debugfs_reg32 dsps_musb_regs[] = {
+ { revision, 0x00 },
+ { control,0x14 },
+ { status, 0x18 },
+ { eoi,0x24 },
+ { intr0_stat, 0x30 },
+ { intr1_stat, 0x34 },
+ { intr0_set, 0x38 },
+ { intr1_set, 0x3c },
+ { txmode, 0x70 },
+ { rxmode, 0x74 },
+ { autoreq,0xd0 },
+ { srpfixtime, 0xd4 },
+ { tdown, 0xd8 },
+ { phy_utmi, 0xe0 },
+ { mode, 0xe8 },
};
static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -369,6 +391,30 @@ out:
return ret;
}
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
+ root = debugfs_create_dir(buf, NULL);
+ if (!root)
wrong, you should be using IS_ERR()
!root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled.
in that case, files will be created on parent directory right ? If we
pass a ERR_PTR(-ENODEV), otoh, we will try to dereference it in
__create_file().
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Tue, Feb 18, 2014 at 11:03:35AM -0600, Felipe Balbi wrote:
On Tue, Feb 18, 2014 at 08:59:11AM -0800, Greg KH wrote:
On Tue, Feb 18, 2014 at 10:20:54AM -0600, Felipe Balbi wrote:
On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote:
debugfs files to show the contents of important dsps registers.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/musb/musb_dsps.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 593d3c9..d0a97d6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -46,6 +46,8 @@
#include linux/of_irq.h
#include linux/usb/of.h
+#include linux/debugfs.h
+
#include musb_core.h
static const struct of_device_id musb_dsps_of_match[];
@@ -137,6 +139,26 @@ struct dsps_glue {
unsigned long last_timer;/* last timer data for each
instance */
struct dsps_context context;
+ struct debugfs_regset32 regset;
+ struct dentry *dbgfs_root;
+};
+
+static const struct debugfs_reg32 dsps_musb_regs[] = {
+ { revision, 0x00 },
+ { control,0x14 },
+ { status, 0x18 },
+ { eoi,0x24 },
+ { intr0_stat, 0x30 },
+ { intr1_stat, 0x34 },
+ { intr0_set, 0x38 },
+ { intr1_set, 0x3c },
+ { txmode, 0x70 },
+ { rxmode, 0x74 },
+ { autoreq,0xd0 },
+ { srpfixtime, 0xd4 },
+ { tdown, 0xd8 },
+ { phy_utmi, 0xe0 },
+ { mode, 0xe8 },
};
static void dsps_musb_try_idle(struct musb *musb, unsigned long
timeout)
@@ -369,6 +391,30 @@ out:
return ret;
}
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue
*glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
+ root = debugfs_create_dir(buf, NULL);
+ if (!root)
wrong, you should be using IS_ERR()
!root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled.
in that case, files will be created on parent directory right ?
If, for some reason, creating a directory fails and then creating a file
would succeed, yes, that will happen.
If we pass a ERR_PTR(-ENODEV), otoh, we will try to dereference it in
__create_file().
No, because -ENODEV will only happen if debugfs is not enabled, so no
dereference will ever happen.
Don't worry about checking return values from debugfs, it shouldn't be
needed.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.14-rc3
Here are some basic OMAP test results for Linux v3.14-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.14-rc3/20140217214814/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass ( 9/ 9): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig/omap4-var-som Build: zImage: Pass (13/13): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig Boot to userspace: FAIL ( 1/12): 2430sdp skip ( 2/12): 5912osk, cmt3517 Pass ( 9/12): 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, 4460varsomom PM: chip retention via suspend: FAIL ( 4/ 7): 2430sdp, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 3/ 7): 3530es3beagle, 3730beaglexm, 37xxevm PM: chip retention via dynamic idle: FAIL ( 7/ 7): 2430sdp, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom PM: chip off except CORE via suspend: FAIL ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: FAIL ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom PM: chip off via dynamic idle: FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom vmlinux object size (delta in bytes from test_v3.14-rc2 (b28a960c42fcd9cfc987441fa6d1c1a471f0f9ed)): text data bsstotal kernel +9089 +2560+9345 omap1_defconfig +5085 +2880+5373 omap1_defconfig_1510innovator_only +4993 +2640+5257 omap1_defconfig_5912osk_only +8797439 +826332 +291072 +9914843 multi_v7_defconfig +5340 +3040+5644 omap2plus_defconfig +9164 +2880+9452 omap2plus_defconfig_2430sdp_only +4996 +2720+5268 omap2plus_defconfig_am33xx_only +5068 +3040+5372 omap2plus_defconfig_am43xx_only +9372 +2640+9636 omap2plus_defconfig_cpupm +5148 +2640+5412 omap2plus_defconfig_dra7xx_only +58100 +581 omap2plus_defconfig_n800_multi_omap2xxx +54900 +549 omap2plus_defconfig_n800_only_a +9372 +2560+9628 omap2plus_defconfig_no_pm +5276 +2560+5532 omap2plus_defconfig_omap2_4_only +5276 +2720+5548 omap2plus_defconfig_omap3_4_only +11048 +8960 +11944 omap2plus_defconfig_omap5_only +3880 -88 +300 rmk_omap3430_ldp_allnoconfig +44900 +449 rmk_omap3430_ldp_oldconfig +3880 -88 +300 rmk_omap4430_sdp_allnoconfig +3170 -64 +253 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.14-rc2 (b28a960c42fcd9cfc987441fa6d1c1a471f0f9ed)) avail rsrvd high freed board kconfig -8k 8k . . 2430sdpomap2plus_defconfig -8k 8k . . 3517evmomap2plus_defconfig -8k 8k . . 3530es3beagle omap2plus_defconfig -8k 8k . . 3730beaglexm omap2plus_defconfig -8k 8k . . 37xxevmomap2plus_defconfig -8k 8k . . 4430es2panda omap2plus_defconfig -8k 8k . . 4460pandaesomap2plus_defconfig -8k 8k . . 4460varsomom omap2plus_defconfig -8k 8k . . am335xbone omap2plus_defconfig_am33xx_only Have added a build config for multi_v7_defconfig. Not booting it yet on any boards. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
Hi,
On Tue, Feb 18, 2014 at 09:30:21AM -0800, Greg KH wrote:
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue
*glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
+ root = debugfs_create_dir(buf, NULL);
+ if (!root)
wrong, you should be using IS_ERR()
!root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled.
in that case, files will be created on parent directory right ?
If, for some reason, creating a directory fails and then creating a file
would succeed, yes, that will happen.
If we pass a ERR_PTR(-ENODEV), otoh, we will try to dereference it in
__create_file().
No, because -ENODEV will only happen if debugfs is not enabled, so no
dereference will ever happen.
Don't worry about checking return values from debugfs, it shouldn't be
needed.
aha, now I see. I missed the:
348 if (error) {
349 dentry = NULL;
350 simple_release_fs(debugfs_mount, debugfs_mount_count);
351 }
in fs/debugfs/inode.c::__create_file(). I'll apply this patch in a few
hours (randconfig running).
cheers
--
balbi
signature.asc
Description: Digital signature
[RFC PATCH 5/6] PM / Voltagedomain: introduce basic voltage domain support for OMAP
OMAP platforms have multiple voltage domains, but each with consistent
behavior of controlling the VDD (supply) and VBB(ABB/Bias voltage).
These need to be sequenced in a specific order for functionality.
Further optimization such as AVS(Adaptive Voltage Scaling), optimized
voltages from efuse(Class0) can also be introduced based on this basic
framework.
This now allows reuse by voltage domain devices which may share the same
voltage domain by allowing the regulator framework to maintain per
consumer usage information.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/power/voltdm/Kconfig |7 +
drivers/power/voltdm/Makefile |1 +
drivers/power/voltdm/voltdm_omap.c | 287
3 files changed, 295 insertions(+)
create mode 100644 drivers/power/voltdm/voltdm_omap.c
diff --git a/drivers/power/voltdm/Kconfig b/drivers/power/voltdm/Kconfig
index 270fdab..41bfbc3 100644
--- a/drivers/power/voltdm/Kconfig
+++ b/drivers/power/voltdm/Kconfig
@@ -9,4 +9,11 @@ config VOLTAGE_DOMAIN
menu Voltage Domain Framework Drivers
depends on VOLTAGE_DOMAIN
+config VOLTAGE_DOMAIN_OMAP
+ tristate TI OMAP Voltage domain driver
+ ---help---
+ Voltage domain support for OMAP platforms which need
+ vdd regulator and Adaptive Body Bias(ABB) regulator
+ support
+
endmenu
diff --git a/drivers/power/voltdm/Makefile b/drivers/power/voltdm/Makefile
index fd32040..e1cb50d 100644
--- a/drivers/power/voltdm/Makefile
+++ b/drivers/power/voltdm/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_VOLTAGE_DOMAIN)+= core.o
# Hardware specific voltage domain
# please keep this section sorted lexicographically by file/directory path name
+obj-$(CONFIG_VOLTAGE_DOMAIN_OMAP) += voltdm_omap.o
diff --git a/drivers/power/voltdm/voltdm_omap.c
b/drivers/power/voltdm/voltdm_omap.c
new file mode 100644
index 000..aacbdde
--- /dev/null
+++ b/drivers/power/voltdm/voltdm_omap.c
@@ -0,0 +1,287 @@
+/*
+ * Copyright (C) 2014 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.
+ *
+ * Helper functions for registering clock rate-change notifier handlers
+ * that scale voltage when a clock changes its output frequency.
+ */
+#include linux/clk.h
+#include linux/cpufreq.h
+#include linux/device.h
+#include linux/module.h
+#include linux/notifier.h
+#include linux/of_device.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pm_opp.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include voltage_domain_private.h
+
+/**
+ * struct omap_voltdm_data - OMAP specific voltage domain data
+ * @vdd_reg: VDD regulator
+ * @vbb_reg: Body Bias regulator
+ */
+struct omap_voltdm_data {
+ struct regulator *vdd_reg;
+ struct regulator *vbb_reg;
+};
+
+/**
+ * omap_voltdm_do_transition() - do the voltage domain transition
+ * @dev: voltage domain device for which we are doing the transition
+ * @voltdm_data: data specific to the device
+ * @clk_notifier_flags:clk notifier flags for direction of transition
+ * @uv:what voltage to transition to
+ * @tol_uv:voltage tolerance to use
+ */
+static int omap_voltdm_do_transition(struct device *dev,
+void *voltdm_data,
+unsigned long clk_notifier_flags, int uv,
+int tol_uv)
+{
+ struct omap_voltdm_data *data = (struct omap_voltdm_data *)voltdm_data;
+ int ret;
+ bool do_abb_first;
+
+ /* We dont expect voltdm layer to make mistakes.. but still */
+ BUG_ON(!data);
+
+ do_abb_first = clk_notifier_flags == ABORT_RATE_CHANGE ||
+ clk_notifier_flags == POST_RATE_CHANGE;
+
+ if (do_abb_first) {
+ dev_dbg(dev, vbb pre %duV[tol %duV]\n, uv, tol_uv);
+ ret = regulator_set_voltage_tol(data-vbb_reg, uv, tol_uv);
+ if (ret) {
+ dev_err(dev,
+ vbb failed for voltage %duV[tol %duV]:%d\n,
+ uv, tol_uv, ret);
+ return ret;
+ }
+ }
+
+ dev_dbg(dev, vdd for voltage %duV[tol %duV]\n, uv, tol_uv);
+ ret = regulator_set_voltage_tol(data-vdd_reg, uv, tol_uv);
+ if (ret) {
+ dev_err(dev,
+ vdd failed for voltage %duV[tol %duV]:%d\n,
+ uv, tol_uv, ret);
+ return ret;
+ }
+
+ if (!do_abb_first) {
+ dev_dbg(dev, vbb post %duV[tol %duV]\n, uv, tol_uv);
+ ret = regulator_set_voltage_tol(data-vbb_reg, uv, tol_uv);
+ if (ret) {
+ dev_err(dev,
+ vbb failed for voltage
[RFC PATCH 2/6] cpufreq: cpufreq-cpu0: use clk rate-change notifiers
From: Mike Turquette mturque...@linaro.org
Removes directly handling of OPP tables and voltage regulators by
calling of_clk_cpufreq_notifier_handler, introduced by commit clk:
cpufreq helper for voltage scaling.
In the future this can help consolidate code found across similar
CPUfreq drivers.
[n...@ti.com: updates to keep the OPP logic still in cpufreq-cpu0 -
optimization to generalize that for cpufreq is to be done in a later
series]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Mike Turquette mturque...@linaro.org
---
drivers/cpufreq/Kconfig|1 +
drivers/cpufreq/cpufreq-cpu0.c | 140
2 files changed, 42 insertions(+), 99 deletions(-)
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 4b029c0..70b07ab 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -187,6 +187,7 @@ config GENERIC_CPUFREQ_CPU0
tristate Generic CPU0 cpufreq driver
depends on HAVE_CLK REGULATOR OF THERMAL CPU_THERMAL
select PM_OPP
+ select VOLTAGE_DOMAIN
help
This adds a generic cpufreq driver for CPU0 frequency management.
It supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 0c12ffc..32719d3 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -21,23 +21,20 @@
#include linux/of.h
#include linux/pm_opp.h
#include linux/platform_device.h
-#include linux/regulator/consumer.h
+#include linux/pm_voltage_domain.h
#include linux/slab.h
#include linux/thermal.h
static unsigned int transition_latency;
-static unsigned int voltage_tolerance; /* in percentage */
static struct device *cpu_dev;
static struct clk *cpu_clk;
-static struct regulator *cpu_reg;
static struct cpufreq_frequency_table *freq_table;
static struct thermal_cooling_device *cdev;
+static struct notifier_block *clk_nb;
static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
{
- struct dev_pm_opp *opp;
- unsigned long volt = 0, volt_old = 0, tol = 0;
unsigned int old_freq, new_freq;
long freq_Hz, freq_exact;
int ret;
@@ -50,50 +47,14 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
unsigned int index)
new_freq = freq_Hz / 1000;
old_freq = clk_get_rate(cpu_clk) / 1000;
- if (!IS_ERR(cpu_reg)) {
- rcu_read_lock();
- opp = dev_pm_opp_find_freq_ceil(cpu_dev, freq_Hz);
- if (IS_ERR(opp)) {
- rcu_read_unlock();
- pr_err(failed to find OPP for %ld\n, freq_Hz);
- return PTR_ERR(opp);
- }
- volt = dev_pm_opp_get_voltage(opp);
- rcu_read_unlock();
- tol = volt * voltage_tolerance / 100;
- volt_old = regulator_get_voltage(cpu_reg);
- }
-
- pr_debug(%u MHz, %ld mV -- %u MHz, %ld mV\n,
-old_freq / 1000, volt_old ? volt_old / 1000 : -1,
-new_freq / 1000, volt ? volt / 1000 : -1);
-
- /* scaling up? scale voltage before frequency */
- if (!IS_ERR(cpu_reg) new_freq old_freq) {
- ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
- if (ret) {
- pr_err(failed to scale voltage up: %d\n, ret);
- return ret;
- }
- }
+ pr_debug(%u MHz -- %u MHz\n, old_freq / 1000, new_freq / 1000);
ret = clk_set_rate(cpu_clk, freq_exact);
if (ret) {
pr_err(failed to set clock rate: %d\n, ret);
- if (!IS_ERR(cpu_reg))
- regulator_set_voltage_tol(cpu_reg, volt_old, tol);
return ret;
}
- /* scaling down? scale voltage after frequency */
- if (!IS_ERR(cpu_reg) new_freq old_freq) {
- ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
- if (ret) {
- pr_err(failed to scale voltage down: %d\n, ret);
- clk_set_rate(cpu_clk, old_freq * 1000);
- }
- }
-
return ret;
}
@@ -117,33 +78,24 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
static int cpu0_cpufreq_probe(struct platform_device *pdev)
{
struct device_node *np;
+ unsigned int voltage_latency;
int ret;
- cpu_dev = get_cpu_device(0);
if (!cpu_dev) {
- pr_err(failed to get cpu0 device\n);
- return -ENODEV;
- }
-
- np = of_node_get(cpu_dev-of_node);
- if (!np) {
- pr_err(failed to find cpu0 node\n);
- return -ENOENT;
- }
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev) {
+ pr_err(failed to get cpu0 device\n);
+ return -ENODEV;
+
[RFC PATCH 3/6] PM / Voltagedomain: introduce voltage domain driver support
Many SoCs have basic concepts of voltage rails supplying a specific
SoC device. These voltage rails may be as simple as a single regulator
or complex to be three or more regulators that are transitioned in
tandem with respect to clock changes. In some cases, they may tend
to use custom frameworks to do the actual voltage transition OR use
hardware modules that takes hints about the required configuration and
does optimized voltage transitions.
The current regulator model provides the basic building blocks for the
transitions, however SoC drivers specific to each of these devices, be
it cpufreq/devfreq have to replicate the logic for functionality.
To simply the logic, we can hence introduce a layer that takes care
of the mundane transition logic, registration mechanisms to provide
the user drivers such as cpufreq/devfreq a generic interface, whose
details are abstracted by the device tree description for the SoC on
which the driver operates on.
This allows us opportunity to make generic cpufreq / devfreq drivers
which may deal with a single clock, however the actual voltage change
mechanism can be customized specific to SoC without impact to the
generic driver.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/power/voltdm/Kconfig |5 +
drivers/power/voltdm/Makefile |3 +
drivers/power/voltdm/core.c | 347 +++--
drivers/power/voltdm/voltage_domain_private.h | 86 ++
4 files changed, 424 insertions(+), 17 deletions(-)
create mode 100644 drivers/power/voltdm/voltage_domain_private.h
diff --git a/drivers/power/voltdm/Kconfig b/drivers/power/voltdm/Kconfig
index c5353bd..270fdab 100644
--- a/drivers/power/voltdm/Kconfig
+++ b/drivers/power/voltdm/Kconfig
@@ -5,3 +5,8 @@ config VOLTAGE_DOMAIN
---help---
Core voltage domain framework using common clock framework's
notifier mechanism.
+
+menu Voltage Domain Framework Drivers
+ depends on VOLTAGE_DOMAIN
+
+endmenu
diff --git a/drivers/power/voltdm/Makefile b/drivers/power/voltdm/Makefile
index 3fa4408..fd32040 100644
--- a/drivers/power/voltdm/Makefile
+++ b/drivers/power/voltdm/Makefile
@@ -1,2 +1,5 @@
# Generic voltage domain
obj-$(CONFIG_VOLTAGE_DOMAIN) += core.o
+
+# Hardware specific voltage domain
+# please keep this section sorted lexicographically by file/directory path name
diff --git a/drivers/power/voltdm/core.c b/drivers/power/voltdm/core.c
index d0ed27e..69f6e81 100644
--- a/drivers/power/voltdm/core.c
+++ b/drivers/power/voltdm/core.c
@@ -10,12 +10,32 @@
* that scale voltage when a clock changes its output frequency.
*/
#include linux/device.h
+#include linux/module.h
#include linux/of.h
#include linux/pm_opp.h
#include linux/pm_voltage_domain.h
#include linux/regulator/consumer.h
#include linux/slab.h
+#include voltage_domain_private.h
+
+/**
+ * struct pm_voltdm_dev - internal representation of voltage domain devices
+ * @desc: voltage domain description
+ * @dev: voltage domain device
+ * @list: list to remaining voltage domain devices
+ * @lock: mutex to control data structure modifications and serialize ops
+ * @notifier_list: list of notifiers registered for this device
+ */
+struct pm_voltdm_dev {
+ const struct pm_voltdm_desc *desc;
+ struct device *dev;
+ struct list_head list;
+ /* list lock */
+ struct mutex lock;
+ struct list_head notifier_list;
+};
+
/**
* struct volt_scale_data - Internal structure to maintain notifier information
* @dev: device on behalf of which we register the notifier
@@ -23,6 +43,9 @@
* @reg: regulator if any which is used for scaling voltage
* @tol: voltage tolerance in %
* @nb:notifier block pointer
+ * @list: list head for the notifier
+ * @vdev: pointer to voltage domain device for this notifier
+ * @voltdm_data: voltdm driver specific data
*/
struct volt_scale_data {
struct device *dev;
@@ -30,23 +53,208 @@ struct volt_scale_data {
struct regulator *reg;
int tol;
struct notifier_block nb;
+ struct list_head list;
+
+ struct pm_voltdm_dev *vdev;
+ void *voltdm_data;
};
#define to_volt_scale_data(_nb) container_of(_nb, \
struct volt_scale_data, nb)
+static DEFINE_MUTEX(pm_voltdm_list_lock);
+static LIST_HEAD(pm_voltdm_list);
+
+static inline bool voltmd_skip_check(struct pm_voltdm_dev *vdev)
+{
+ bool ret = false;
+
+ if (vdev) {
+ const struct pm_voltdm_desc *desc;
+
+ if (IS_ERR(vdev))
+ return false;
+
+ mutex_lock(vdev-lock);
+ desc = vdev-desc;
+
+ if (desc-flags VOLTAGE_DOMAIN_FLAG_NOTIFY_ALL)
+ ret = true;
+ mutex_unlock(vdev-lock);
+ }
+
+ return ret;
+}
+
+static inline int voltmd_scale_voltage(struct volt_scale_data
[RFC PATCH 4/6] devicetree: bindings: add documentation for voltagedomain
Add documentation for voltage domain binding format. Specific
voltage domains will have bindings corresponding to them.
Signed-off-by: Nishanth Menon n...@ti.com
---
.../bindings/power/voltdm/voltage_domain.txt | 65
1 file changed, 65 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt
diff --git a/Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt
b/Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt
new file mode 100644
index 000..da48a19
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt
@@ -0,0 +1,65 @@
+Specifying Voltage Domain information for devices
+=
+
+1. Specifying a voltage domain.
+
+SoCs may have multiple voltage domains under which various clocks operate.
+
+Mandatory Properties:
+- #voltdm-cells - indicates if there are specifiers needed to reference the
+ voltage domain
+
+Optional Properties:
+- voltage-tolerance: Specify the voltage tolerance in percentage
+
+2. Voltage domain consumer
+consumer nodes can be reference using the below binding:
+- name-voltdm: phandle to the voltage domain node.
+
+Examples:
+
+A. Voltage Domain controlling multiple regulator
+voltage_domain_mpu: voltdm@1 {
+ compatible = xyz;
+ #voltdm-cells = 0;
+ vdd-supply = vcc;
+ vbb-supply = abb_mpu;
+ ...
+};
+
+voltage_domain_gpu: voltdm@2 {
+ compatible = xyz;
+ #voltdm-cells = 0;
+ vdd-supply = dcdc2;
+ vbb-supply = abb_gpu;
+ ...
+};
+...
+cpu0 {
+ cpu0-voltdm = voltage_domain_mpu;
+ voltage-tolerance = 1;
+};
+
+gpu {
+ gpu-voltdm = voltage_domain_gpu;
+};
+
+B. Indexed voltage domain device
+
+#define SOC_XYZ_VOLTAGE_DOMAIN_MPU 0
+#define SOC_XYZ_VOLTAGE_DOMAIN_GFX 1
+
+voltage_domain_socx: voltdm@1 {
+ compatible = abc;
+ #voltdm-cells = 1;
+ ...
+};
+...
+cpu0 {
+ cpu0-voltdm = voltage_domain_socx SOC_XYZ_VOLTAGE_DOMAIN_MPU;
+ voltage-tolerance = 1;
+};
+
+gpu {
+ gpu-voltdm = voltage_domain_socx SOC_XYZ_VOLTAGE_DOMAIN_GFX;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling
From: Mike Turquette mturque...@linaro.org
This patch provides helper functions for drivers that wish to scale
voltage through the clock rate-change notifiers. The approach taken
is that the user-driver(cpufreq/devfreq) do not care about the
details of the OPP table, nor does it care about handling the voltage
regulator directly.
By using the clk notifier flags, we are able to sequence the operations
in the right order. The current logic is heavily influenced by
implementation done in cpufreq-cpu0.
[n...@ti.com: Fixes in logic, and broken out from clk to allow building
a generic voltagedomain solution independent of cpufreq]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Mike Turquette mturque...@linaro.org
---
drivers/power/Kconfig |1 +
drivers/power/Makefile|1 +
drivers/power/voltdm/Kconfig |7 ++
drivers/power/voltdm/Makefile |2 +
drivers/power/voltdm/core.c | 195 +
include/linux/pm_voltage_domain.h | 47 +
6 files changed, 253 insertions(+)
create mode 100644 drivers/power/voltdm/Kconfig
create mode 100644 drivers/power/voltdm/Makefile
create mode 100644 drivers/power/voltdm/core.c
create mode 100644 include/linux/pm_voltage_domain.h
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index ba69751..5c4fe16 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -394,3 +394,4 @@ source drivers/power/reset/Kconfig
endif # POWER_SUPPLY
source drivers/power/avs/Kconfig
+source drivers/power/voltdm/Kconfig
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index ee54a3e..3d47072 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -58,3 +58,4 @@ obj-$(CONFIG_POWER_AVS) += avs/
obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o
obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
obj-$(CONFIG_POWER_RESET) += reset/
+obj-$(CONFIG_VOLTAGE_DOMAIN) += voltdm/
diff --git a/drivers/power/voltdm/Kconfig b/drivers/power/voltdm/Kconfig
new file mode 100644
index 000..c5353bd
--- /dev/null
+++ b/drivers/power/voltdm/Kconfig
@@ -0,0 +1,7 @@
+config VOLTAGE_DOMAIN
+ bool
+ depends on COMMON_CLK OF PM_OPP
+ default y if COMMON_CLK
+ ---help---
+ Core voltage domain framework using common clock framework's
+ notifier mechanism.
diff --git a/drivers/power/voltdm/Makefile b/drivers/power/voltdm/Makefile
new file mode 100644
index 000..3fa4408
--- /dev/null
+++ b/drivers/power/voltdm/Makefile
@@ -0,0 +1,2 @@
+# Generic voltage domain
+obj-$(CONFIG_VOLTAGE_DOMAIN) += core.o
diff --git a/drivers/power/voltdm/core.c b/drivers/power/voltdm/core.c
new file mode 100644
index 000..d0ed27e
--- /dev/null
+++ b/drivers/power/voltdm/core.c
@@ -0,0 +1,195 @@
+/*
+ * Copyright (C) 2013 Linaro Ltd mturque...@linaro.org
+ * Copyright (C) 2014 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.
+ *
+ * Helper functions for registering clock rate-change notifier handlers
+ * that scale voltage when a clock changes its output frequency.
+ */
+#include linux/device.h
+#include linux/of.h
+#include linux/pm_opp.h
+#include linux/pm_voltage_domain.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+
+/**
+ * struct volt_scale_data - Internal structure to maintain notifier information
+ * @dev: device on behalf of which we register the notifier
+ * @clk: clk on which we registered the notifier
+ * @reg: regulator if any which is used for scaling voltage
+ * @tol: voltage tolerance in %
+ * @nb:notifier block pointer
+ */
+struct volt_scale_data {
+ struct device *dev;
+ struct clk *clk;
+ struct regulator *reg;
+ int tol;
+ struct notifier_block nb;
+};
+
+#define to_volt_scale_data(_nb) container_of(_nb, \
+ struct volt_scale_data, nb)
+
+static int clk_volt_notifier_handler(struct notifier_block *nb,
+unsigned long flags, void *data)
+{
+ struct clk_notifier_data *cnd = data;
+ struct volt_scale_data *vsd = to_volt_scale_data(nb);
+ int ret, volt, tol;
+ struct dev_pm_opp *opp;
+ unsigned long old_rate = cnd-old_rate;
+ unsigned long new_rate = cnd-new_rate;
+
+ if ((new_rate old_rate flags == PRE_RATE_CHANGE) ||
+ (new_rate old_rate flags == POST_RATE_CHANGE))
+ return NOTIFY_OK;
+
+ rcu_read_lock();
+ if (flags != ABORT_RATE_CHANGE)
+ opp = dev_pm_opp_find_freq_ceil(vsd-dev, new_rate);
+ else
+ opp = dev_pm_opp_find_freq_ceil(vsd-dev, old_rate);
+ if (IS_ERR(opp)) {
+ rcu_read_unlock();
+ dev_err(vsd-dev, %s: Failed to find OPP
[RFC PATCH 0/6] PM: introduce voltage domain abstraction
Hi,
On many SoCs such as OMAP, hardware blocks are isolated into voltage
domains allowing for individual tweaks for optimal power-performance
tradeoffs. Frameworks such as cpufreq, devfreq provide a top level
control of these hardware blocks. Most SoCs have different knobs to
fine tune the voltages. They may supply multiple supplies to various
voltage planes on the same voltage domains.
Regulator framework provides us a with an appropriate representation
of consumer model, however, we lack the abstraction necessary to
isolate the necessary sequencing for a specific voltage domain.
There has been few attempts previously taken such as [3] [4],
this series is a further development of of Mike's series[1] where
cpufreq-cpu0 driver was first targetted with clk notifiers. While I do
understand the concerns Mike has in [2], this could be a base on which
further work may be done.
In a nutshell, this (for cpufreq-cpu0 as an example):
maintains the legacy definitions used by cpufreq/devfreq such as:
cpu0 {
cpu0-supply = regulator_x;
};
on other SoCs where this might turn out to be a more detailed
implementation,
cpu0 {
cpu0-voltdm = voltdm_x;
};
To enure this is split off from clk framework, I chose
drivers/power/voltdm as the location for the new files, I'd love to
hear opinions and suggestions on the approach.
The series is based on 3.14-rc3 and is available here:
https://github.com/nmenon/linux-2.6-playground/commits/push/voltdm-notifier-rfc
A testing branch for Beagle-XM (OMAP3630 as testbed):
https://github.com/nmenon/linux-2.6-playground/commits/testing/beagle-xm-voltdm-notifier-rfc
Log: http://slexy.org/view/s20TgkN7kf
NOTE: TI platforms potentially need further development, however, this
forms the basis of the development.
Mike Turquette (2):
PM / Voltagedomain: Add generic clk notifier handler for regulator
based dynamic voltage scaling
cpufreq: cpufreq-cpu0: use clk rate-change notifiers
Nishanth Menon (4):
PM / Voltagedomain: introduce voltage domain driver support
devicetree: bindings: add documentation for voltagedomain
PM / Voltagedomain: introduce basic voltage domain support for OMAP
devicetree: bindings: voltagedomain: add bindings for OMAP compatible
SoCs
.../bindings/power/voltdm/voltage_domain.txt | 65 +++
.../bindings/power/voltdm/voltdm_omap.txt | 24 +
drivers/cpufreq/Kconfig|1 +
drivers/cpufreq/cpufreq-cpu0.c | 140 ++
drivers/power/Kconfig |1 +
drivers/power/Makefile |1 +
drivers/power/voltdm/Kconfig | 19 +
drivers/power/voltdm/Makefile |6 +
drivers/power/voltdm/core.c| 508
drivers/power/voltdm/voltage_domain_private.h | 86
drivers/power/voltdm/voltdm_omap.c | 287 +++
include/linux/pm_voltage_domain.h | 47 ++
12 files changed, 1086 insertions(+), 99 deletions(-)
create mode 100644
Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt
create mode 100644
Documentation/devicetree/bindings/power/voltdm/voltdm_omap.txt
create mode 100644 drivers/power/voltdm/Kconfig
create mode 100644 drivers/power/voltdm/Makefile
create mode 100644 drivers/power/voltdm/core.c
create mode 100644 drivers/power/voltdm/voltage_domain_private.h
create mode 100644 drivers/power/voltdm/voltdm_omap.c
create mode 100644 include/linux/pm_voltage_domain.h
[1] https://lkml.org/lkml/2013/7/7/110 (original RFC)
[2] http://marc.info/?l=linux-arm-kernelm=137947787621572w=2 (runtime pm
should enable regulator)
[3] http://marc.info/?t=13660311176r=1w=2
[4]
http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/dvfs.c;hb=p-linux-omap-3.4
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 6/6] devicetree: bindings: voltagedomain: add bindings for OMAP compatible SoCs
Add documentation for device tree description for basic voltage domain
for Texas Instruments OMAP compatible SoC family of processors which
controls both bias and supply voltage planes.
Signed-off-by: Nishanth Menon n...@ti.com
---
.../bindings/power/voltdm/voltdm_omap.txt | 24
1 file changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/voltdm/voltdm_omap.txt
diff --git a/Documentation/devicetree/bindings/power/voltdm/voltdm_omap.txt
b/Documentation/devicetree/bindings/power/voltdm/voltdm_omap.txt
new file mode 100644
index 000..30cd3d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/voltdm/voltdm_omap.txt
@@ -0,0 +1,24 @@
+Texas Instruments OMAP compatible voltage domain description
+
+This binding uses [1] and describes the voltage domain devices
+typically used on Texas Instruments OMAP compatible SoC family of
+processors.
+
+[1] Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt
+
+Required Properties:
+- compatible: Should be one of:
+ ti,omap-voltdm - basic voltage domain controlling VDD and VBB
+- vdd-supply: phandle to regulator controlling VDD supply
+- vbb-supply: phandle to regulator controlling Body Bias supply
+ (Usually Adaptive Body Bias regulator)
+- #voltdm-cells: shall be 0
+
+Example:
+voltage_domain_mpu: voltdm@1 {
+ compatible = ti,omap-voltdm;
+ #voltdm-cells = 0;
+
+ vdd-supply = vcc;
+ vbb-supply = abb_mpu;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes against v3.14-rc1
Hi, On Fri, Feb 14, 2014 at 08:44:31AM -0800, Tony Lindgren wrote: The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72: Linus 3.14-rc1 (2014-02-02 16:42:13 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/fixes-against-rc1 Pulled. Looks like the following two snuck in that should maybe have been cleanups instead, but it's not worth respinning over: Paul Bolle (2): ARM: OMAP2+: Remove MACH_NOKIA_N800 ARM: OMAP2+: Remove legacy macros for zoom platforms -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
