* [PATCH] arm: dts: omap4-sdp: pinmux configuration for keypad
From: Benoit Cousson @ 2012-10-22 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350890955-29553-1-git-send-email-sourav.poddar@ti.com>
Hi Sourav,
On 10/22/2012 09:29 AM, Sourav Poddar wrote:
> Currently, omap4 keypad mux settings are done in the board file.
> Populate the mux settings in the dts file for the keypad to
> work via dt.
Have you changed the driver to handle properly the dependency with the
pinctrl and thus return EPROBE_DEFER if this is not ready?
Seb Guiriec has just sent a patch to do that for the omap-i2c driver
([PATCH] i2c: omap: adopt pinctrl support).
> Cc: Felipe Balbi <balbi@ti.com>
> Tested on omap4430 sdp with 3.7-rc1.
>
> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
> ---
> arch/arm/boot/dts/omap4-sdp.dts | 26 ++++++++++++++++++++++++++
> 1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index 5b7e04f..5efb059 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -194,6 +194,27 @@
> 0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT | MODE0 */
> >;
> };
> +
> + keypad_pins: pinmux_keypad_pins {
> + pinctrl-single,pins = <
> + 0x24 0x4119 /* gpmc_a18.kpd_row6 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x26 0x4119 /* gpmc_a19.kpd_row6 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x2c 0x4001 /* gpmc_a22.kpd_col6 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
> + 0x2e 0x4001 /* gpmc_a23.kpd_col7 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
> + 0x13c 0x4001 /* kpd_col0.kpd_col0 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
> + 0x13e 0x4001 /* kpd_col1.kpd_col1 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
> + 0x140 0x4001 /* kpd_col2.kpd_col2 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
> + 0x142 0x10F /* kpd_col3.kpd_col3 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
Alway use lower case for hexa value.
> + 0x144 0x4001 /* kpd_col4.kpd_col4 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
> + 0x146 0x4001 /* kpd_col5.kpd_col5 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
> + 0x148 0xc119 /* kpd_row0.kpd_row0 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x14a 0x4119 /* kpd_row1.kpd_row1 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x14c 0x4119 /* kpd_row2.kpd_row2 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x14e 0x4119 /* kpd_row3.kpd_row3 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x150 0x4119 /* kpd_row4.kpd_row4 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x152 0x4119 /* kpd_row5.kpd_row5 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + >;
> + };
> };
>
> &i2c1 {
> @@ -406,3 +427,8 @@
> &mcbsp3 {
> status = "disabled";
> };
> +
> +&keypad {
> + pinctrl-names = "default";
> + pinctrl-0 = <&keypad_pins>;
> +};
Otherwise that looks good.
Thanks,
Benoit
^ permalink raw reply
* [PATCH] MMCI: fetch pinctrl handle and set default state
From: Linus Walleij @ 2012-10-22 7:52 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
This fetches the pinctrl resource for the MMCI driver, and if
a "default" state is found, it is activated.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/mmc/host/mmci.c | 18 ++++++++++++++++++
drivers/mmc/host/mmci.h | 4 ++++
2 files changed, 22 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index edc3e9b..269566d 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -33,6 +33,7 @@
#include <linux/amba/mmci.h>
#include <linux/pm_runtime.h>
#include <linux/types.h>
+#include <linux/pinctrl/consumer.h>
#include <asm/div64.h>
#include <asm/io.h>
@@ -1360,6 +1361,23 @@ static int __devinit mmci_probe(struct amba_device *dev,
mmc->f_max = min(host->mclk, fmax);
dev_dbg(mmc_dev(mmc), "clocking block at %u Hz\n", mmc->f_max);
+ host->pinctrl = devm_pinctrl_get(&dev->dev);
+ if (IS_ERR(host->pinctrl)) {
+ ret = PTR_ERR(host->pinctrl);
+ goto clk_disable;
+ }
+
+ host->pins_default = pinctrl_lookup_state(host->pinctrl,
+ PINCTRL_STATE_DEFAULT);
+
+ /* enable pins to be muxed in and configured */
+ if (!IS_ERR(host->pins_default)) {
+ ret = pinctrl_select_state(host->pinctrl, host->pins_default);
+ if (ret)
+ dev_err(&dev->dev, "could not set default pins\n");
+ } else
+ dev_err(&dev->dev, "could not get default pinstate\n");
+
#ifdef CONFIG_REGULATOR
/* If we're using the regulator framework, try to fetch a regulator */
host->vcc = regulator_get(&dev->dev, "vmmc");
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index d437ccf..d34d8c0 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -195,6 +195,10 @@ struct mmci_host {
unsigned int size;
struct regulator *vcc;
+ /* pinctrl handles */
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pins_default;
+
#ifdef CONFIG_DMA_ENGINE
/* DMA stuff */
struct dma_chan *dma_current;
--
1.7.11.3
^ permalink raw reply related
* [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
From: Thierry Reding @ 2012-10-22 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350891382.3592.22.camel@gitbox>
On Mon, Oct 22, 2012 at 08:36:22PM +1300, Tony Prisk wrote:
> On Mon, 2012-10-22 at 09:24 +0200, Thierry Reding wrote:
> > On Mon, Oct 22, 2012 at 08:09:07PM +1300, Tony Prisk wrote:
> > > On Mon, 2012-10-22 at 19:51 +1300, Tony Prisk wrote:
> > > > >
> > > > > > chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
> > > > > > if (chip == NULL) {
> > > > > > dev_err(&pdev->dev, "failed to allocate memory\n");
> > > > > > @@ -123,26 +144,32 @@ static int __devinit pwm_probe(struct platform_device *pdev)
> > > > > > chip->chip.ops = &vt8500_pwm_ops;
> > > > > > chip->chip.base = -1;
> > > > > > chip->chip.npwm = VT8500_NR_PWMS;
> > > > > > + chip->clk = of_clk_get(np, 0);
> > > > >
> > > > > I thought this was supposed to work transparently across OF and !OF
> > > > > configurations by using just clk_get() or devm_clk_get()? I guess that
> > > > > if the driver depends on OF, then this would be moot, but we should
> > > > > probably stick to the standard usage anyway.
> > > > >
> > > > > Furthermore, of_clk_get() doesn't seem to be managed, so you'd need to
> > > > > add explicit clk_put() in the error cleanup paths. One more argument in
> > > > > favour of using devm_clk_get() instead.
> > > >
> > > > Hmm good point. I stuck with of_ functions because its an OF only driver
> > > > and it seemed 'backward' to mix old code with new. It does pose the
> > > > question of 'why have of_clk_get() if existing functions work better'.
> > >
> > > Was about to fix this but noticed why it wasn't like this to start
> > > with :)
> > >
> > > struct clk *devm_clk_get(struct device *dev, const char *id);
> > > struct clk *of_clk_get(struct device_node *np, int index);
> > >
> > > devm_clk_get requires me to 'get' the clock by name. arch-vt8500 (and I
> > > believe a lot of other arch's) don't enforce names for clocks defined in
> > > devicetree, therefore there is no way for me to know what name the clk
> > > has unless I include in the binding that the clock must be named 'xxx'.
> >
> > I thought clk_get() was supposed to return the first clock specified in
> > DT if you pass NULL as the consumer name. I haven't tested this though.
> > And I haven't looked at the code.
> >
> > > of_clk_get retrieves it by the dt-node + index, so it doesn't care as
> > > long as its the 1st clock listed.
> >
> > So the usual way to do this, I believe, is:
> >
> > clocks = <&clk_foo>;
> > clock-names = "foo";
> >
> > Then use:
> >
> > clk = devm_clk_get(&pdev->dev, "foo");
> >
> > And as I said above, I was under the impression that the default would
> > be to use the first clock if NULL was specified instead of "foo".
> >
> > Thierry
>
> clock-names is an optional property (as defined in
> bindings/clock/clock-bindings.txt) so relying on it is .. well,
> unreliable.
>
> What you say makes sense, but it means the binding document has to make
> an optional property into a required property simply to use an 'old'
> function when a new function would 'work' (granted not as well, as you
> pointed out) without requiring the optional property.
Okay, I've just checked the core clock code, and indeed if you run
clk_get() with con_id set to NULL, you'll eventually call of_clk_get()
with index == 0. That's exactly what you want, right? The only setup
where this won't work out is if you need to handle multiple clocks, in
which case I think it would make sense to make the clock-names property
mandatory. But for this driver that won't be necessary, since it will
never use a second clock, right?
> Your subsystem - your rules. Let me know if I've managed to sway you or
> not :)
I'd rather persuade you than force the issue. =)
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/8b102301/attachment.sig>
^ permalink raw reply
* [PATCH v2] pwm: vt8500: Update vt8500 PWM driver support
From: Tony Prisk @ 2012-10-22 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022080414.GB4931@avionic-0098.mockup.avionic-design.de>
This patch updates pwm-vt8500.c to support devicetree probing and
make use of the common clock subsystem.
A binding document describing the PWM controller found on
arch-vt8500 is also included.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
v2 changes:
Merged binding doc patch with main code patch
Fixes as requested by Thierry Reding.
.../devicetree/bindings/pwm/vt8500-pwm.txt | 17 ++++
drivers/pwm/pwm-vt8500.c | 87 +++++++++++++++-----
2 files changed, 82 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
new file mode 100644
index 0000000..bcc6367
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -0,0 +1,17 @@
+VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
+
+Required properties:
+- compatible: should be "via,vt8500-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: should be 2. The first cell specifies the per-chip index
+ of the PWM to use and the second cell is the period in nanoseconds.
+- clocks: phandle to the PWM source clock
+
+Example:
+
+pwm1: pwm at d8220000 {
+ #pwm-cells = <2>;
+ compatible = "via,vt8500-pwm";
+ reg = <0xd8220000 0x1000>;
+ clocks = <&clkpwm>;
+};
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index ad14389..36fef69 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -1,7 +1,8 @@
/*
* drivers/pwm/pwm-vt8500.c
*
- * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
+ * Copyright (C) 2012 Tony Prisk <linux@prisktech.co.nz>
+ * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -21,14 +22,25 @@
#include <linux/io.h>
#include <linux/pwm.h>
#include <linux/delay.h>
+#include <linux/clk.h>
#include <asm/div64.h>
-#define VT8500_NR_PWMS 4
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+
+/*
+ * SoC architecture allocates register space for 4 PWMs but only
+ * 2 are currently implemented.
+ */
+#define VT8500_NR_PWMS 2
struct vt8500_chip {
struct pwm_chip chip;
void __iomem *base;
+ struct clk *clk;
+ int enable_cnt;
};
#define to_vt8500_chip(chip) container_of(chip, struct vt8500_chip, chip)
@@ -52,7 +64,7 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
unsigned long long c;
unsigned long period_cycles, prescale, pv, dc;
- c = 25000000/2; /* wild guess --- need to implement clocks */
+ c = clk_get_rate(vt8500->clk);
c = c * period_ns;
do_div(c, 1000000000);
period_cycles = c;
@@ -87,6 +99,11 @@ static int vt8500_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
+ if (vt8500->enable_cnt == 0)
+ clk_enable(vt8500->clk);
+
+ vt8500->enable_cnt++;
+
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(5, vt8500->base + (pwm->hwpwm << 4));
return 0;
@@ -98,6 +115,11 @@ static void vt8500_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(0, vt8500->base + (pwm->hwpwm << 4));
+
+ vt8500->enable_cnt--;
+
+ if (vt8500->enable_cnt == 0)
+ clk_disable(vt8500->clk);
}
static struct pwm_ops vt8500_pwm_ops = {
@@ -107,12 +129,25 @@ static struct pwm_ops vt8500_pwm_ops = {
.owner = THIS_MODULE,
};
-static int __devinit pwm_probe(struct platform_device *pdev)
+static const struct of_device_id vt8500_pwm_dt_ids[] = {
+ { .compatible = "via,vt8500-pwm", },
+ { /* Sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, vt8500_pwm_dt_ids);
+
+static int vt8500_pwm_probe(struct platform_device *pdev)
{
struct vt8500_chip *chip;
struct resource *r;
+ struct device_node *np = pdev->dev.of_node;
int ret;
+ if (!np) {
+ dev_err(&pdev->dev, "invalid devicetree node\n");
+ return -EINVAL;
+ }
+
chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
if (chip == NULL) {
dev_err(&pdev->dev, "failed to allocate memory\n");
@@ -123,6 +158,13 @@ static int __devinit pwm_probe(struct platform_device *pdev)
chip->chip.ops = &vt8500_pwm_ops;
chip->chip.base = -1;
chip->chip.npwm = VT8500_NR_PWMS;
+ chip->clk = devm_clk_get(&pdev->dev, NULL);
+ chip->enable_cnt = 0;
+
+ if (!chip->clk) {
+ dev_err(&pdev->dev, "clock source not specified\n");
+ return -EINVAL;
+ }
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
@@ -131,18 +173,24 @@ static int __devinit pwm_probe(struct platform_device *pdev)
}
chip->base = devm_request_and_ioremap(&pdev->dev, r);
- if (chip->base == NULL)
+ if (!chip->base) {
+ dev_err(&pdev->dev, "memory resource not available\n");
return -EADDRNOTAVAIL;
+ }
+
+ clk_prepare(chip->clk);
ret = pwmchip_add(&chip->chip);
- if (ret < 0)
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to add pwmchip\n");
return ret;
+ }
platform_set_drvdata(pdev, chip);
return ret;
}
-static int __devexit pwm_remove(struct platform_device *pdev)
+static int vt8500_pwm_remove(struct platform_device *pdev)
{
struct vt8500_chip *chip;
@@ -150,28 +198,23 @@ static int __devexit pwm_remove(struct platform_device *pdev)
if (chip == NULL)
return -ENODEV;
+ clk_unprepare(chip->clk);
+
return pwmchip_remove(&chip->chip);
}
-static struct platform_driver pwm_driver = {
+static struct platform_driver vt8500_pwm_driver = {
+ .probe = vt8500_pwm_probe,
+ .remove = vt8500_pwm_remove,
.driver = {
.name = "vt8500-pwm",
.owner = THIS_MODULE,
+ .of_match_table = vt8500_pwm_dt_ids,
},
- .probe = pwm_probe,
- .remove = __devexit_p(pwm_remove),
};
-static int __init pwm_init(void)
-{
- return platform_driver_register(&pwm_driver);
-}
-arch_initcall(pwm_init);
-
-static void __exit pwm_exit(void)
-{
- platform_driver_unregister(&pwm_driver);
-}
-module_exit(pwm_exit);
+module_platform_driver(vt8500_pwm_driver);
-MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("VT8500 PWM Driver");
+MODULE_AUTHOR("Tony Prisk <linux@prisktech.co.nz>");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ permalink raw reply related
* [PATCH] pinctrl/nomadik: use irq_create_mapping()
From: Linus Walleij @ 2012-10-22 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50817E43.8000804@wwwdotorg.org>
On Fri, Oct 19, 2012 at 6:22 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/19/2012 09:09 AM, Linus Walleij wrote:
>> From: Linus Walleij <linus.walleij@linaro.org>
>
>> @@ -931,7 +931,7 @@ static void __nmk_gpio_irq_handler(unsigned int irq, struct irq_desc *desc,
>> while (status) {
>> int bit = __ffs(status);
>>
>> - generic_handle_irq(irq_find_mapping(nmk_chip->domain, bit));
>> + generic_handle_irq(irq_create_mapping(nmk_chip->domain, bit));
>
> Surely this one can remain as irq_find_mapping() since isn't
> nmk_gpio_to_irq() guaranteed to have been called first for this GPIO/IRQ?
It's an IRQ handler so it should be robust to spurious IRQs due to
transient hardware states etc I believe.
So if there is a transient IRQ before gpio_to_irq() is called -> boom.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: reserve pins when states are activated
From: Linus Walleij @ 2012-10-22 8:15 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
This switches the way that pins are reserved for multiplexing:
We used to do this when the map was parsed, at the creation of
the settings inside the pinctrl handle, in pinmux_map_to_setting().
However this does not work for us, because we want to use the
same set of pins with different devices at different times: the
current code assumes that the pin groups in a pinmux state will
only be used with one single device, albeit different groups can
be active at different times. For example if a single I2C driver
block is used to drive two different busses located on two
pin groups A and B, then the pins for all possible states of a
function are reserved when fetching the pinctrl handle: the
I2C bus can choose either set A or set B by a mux state at
runtime, but all pins in both group A and B (the superset) are
effectively reserved for that I2C function and mapped to the
device. Another device can never get in and use the pins in
group A, even if the device/function is using group B at the
moment.
Instead: let use reserve the pins when the state is activated
and drop them when the state is disabled, i.e. when we move to
another state. This way different devices/functions can use the
same pins at different times.
We know that this is an odd way of doing things, but we really
need to switch e.g. an SD-card slot to become a tracing output
sink at runtime: we plug in a special "tracing card" then mux
the pins that used to be an SD slot around to the tracing
unit and push out tracing data there instead of SD-card
traffic.
As a side effect pinmux_free_setting() is unused but the stubs
are kept for future additions of code.
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Loic Pallardy <loic.pallardy@st.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Jean Nicolas Graux <jean-nicolas.graux@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Keep pinmux_free_setting() stubs
---
Documentation/pinctrl.txt | 4 ++-
drivers/pinctrl/core.c | 2 ++
drivers/pinctrl/core.h | 2 ++
drivers/pinctrl/pinmux.c | 67 ++++++++++++++++-------------------------------
4 files changed, 29 insertions(+), 46 deletions(-)
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index 3b4ee53..a1cd2f9 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -1193,4 +1193,6 @@ foo_switch()
...
}
-The above has to be done from process context.
+The above has to be done from process context. The reservation of the pins
+will be done when the state is activated, so in effect one specific pin
+can be used by different functions at different times on a running system.
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 0f1ec9e..5c6dff2 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -563,6 +563,8 @@ static int add_setting(struct pinctrl *p, struct pinctrl_map const *map)
return -EPROBE_DEFER;
}
+ setting->dev_name = map->dev_name;
+
switch (map->type) {
case PIN_MAP_TYPE_MUX_GROUP:
ret = pinmux_map_to_setting(map, setting);
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index 1f40ff6..12f5694 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -105,12 +105,14 @@ struct pinctrl_setting_configs {
* @type: the type of setting
* @pctldev: pin control device handling to be programmed. Not used for
* PIN_MAP_TYPE_DUMMY_STATE.
+ * @dev_name: the name of the device using this state
* @data: Data specific to the setting type
*/
struct pinctrl_setting {
struct list_head node;
enum pinctrl_map_type type;
struct pinctrl_dev *pctldev;
+ const char *dev_name;
union {
struct pinctrl_setting_mux mux;
struct pinctrl_setting_configs configs;
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 9301a7a..0ef01ee 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -314,14 +314,11 @@ int pinmux_map_to_setting(struct pinctrl_map const *map,
{
struct pinctrl_dev *pctldev = setting->pctldev;
const struct pinmux_ops *pmxops = pctldev->desc->pmxops;
- const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
char const * const *groups;
unsigned num_groups;
int ret;
const char *group;
int i;
- const unsigned *pins;
- unsigned num_pins;
if (!pmxops) {
dev_err(pctldev->dev, "does not support mux function\n");
@@ -376,53 +373,12 @@ int pinmux_map_to_setting(struct pinctrl_map const *map,
}
setting->data.mux.group = ret;
- ret = pctlops->get_group_pins(pctldev, setting->data.mux.group, &pins,
- &num_pins);
- if (ret) {
- dev_err(pctldev->dev,
- "could not get pins for device %s group selector %d\n",
- pinctrl_dev_get_name(pctldev), setting->data.mux.group);
- return -ENODEV;
- }
-
- /* Try to allocate all pins in this group, one by one */
- for (i = 0; i < num_pins; i++) {
- ret = pin_request(pctldev, pins[i], map->dev_name, NULL);
- if (ret) {
- dev_err(pctldev->dev,
- "could not request pin %d on device %s\n",
- pins[i], pinctrl_dev_get_name(pctldev));
- /* On error release all taken pins */
- i--; /* this pin just failed */
- for (; i >= 0; i--)
- pin_free(pctldev, pins[i], NULL);
- return -ENODEV;
- }
- }
-
return 0;
}
void pinmux_free_setting(struct pinctrl_setting const *setting)
{
- struct pinctrl_dev *pctldev = setting->pctldev;
- const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
- const unsigned *pins;
- unsigned num_pins;
- int ret;
- int i;
-
- ret = pctlops->get_group_pins(pctldev, setting->data.mux.group,
- &pins, &num_pins);
- if (ret) {
- dev_err(pctldev->dev,
- "could not get pins for device %s group selector %d\n",
- pinctrl_dev_get_name(pctldev), setting->data.mux.group);
- return;
- }
-
- for (i = 0; i < num_pins; i++)
- pin_free(pctldev, pins[i], NULL);
+ /* This function is currently unused */
}
int pinmux_enable_setting(struct pinctrl_setting const *setting)
@@ -446,6 +402,22 @@ int pinmux_enable_setting(struct pinctrl_setting const *setting)
num_pins = 0;
}
+ /* Try to allocate all pins in this group, one by one */
+ for (i = 0; i < num_pins; i++) {
+ ret = pin_request(pctldev, pins[i], setting->dev_name, NULL);
+ if (ret) {
+ dev_err(pctldev->dev,
+ "could not request pin %d on device %s\n",
+ pins[i], pinctrl_dev_get_name(pctldev));
+ /* On error release all taken pins */
+ i--; /* this pin just failed */
+ for (; i >= 0; i--)
+ pin_free(pctldev, pins[i], NULL);
+ return -ENODEV;
+ }
+ }
+
+ /* Now that we have acquired the pins, encode the mux setting */
for (i = 0; i < num_pins; i++) {
desc = pin_desc_get(pctldev, pins[i]);
if (desc == NULL) {
@@ -482,6 +454,7 @@ void pinmux_disable_setting(struct pinctrl_setting const *setting)
num_pins = 0;
}
+ /* Flag the descs that no setting is active */
for (i = 0; i < num_pins; i++) {
desc = pin_desc_get(pctldev, pins[i]);
if (desc == NULL) {
@@ -493,6 +466,10 @@ void pinmux_disable_setting(struct pinctrl_setting const *setting)
desc->mux_setting = NULL;
}
+ /* And release the pins */
+ for (i = 0; i < num_pins; i++)
+ pin_free(pctldev, pins[i], NULL);
+
if (ops->disable)
ops->disable(pctldev, setting->data.mux.func, setting->data.mux.group);
}
--
1.7.11.3
^ permalink raw reply related
* [PATCH V3 3/5] ARM: tegra: decouple uncompress.h and debug-macro.S
From: Peter De Schrijver @ 2012-10-22 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350686507-3022-3-git-send-email-swarren@wwwdotorg.org>
> +
> +#define checkuart(rp, rv, lhu, bit, uart) \
> + /* Load address of CLK_RST register */ \
> + movw rp, #TEGRA_CLK_RST_DEVICES_##lhu & 0xffff ; \
> + movt rp, #TEGRA_CLK_RST_DEVICES_##lhu >> 16 ; \
> + /* Load value from CLK_RST register */ \
> + ldr rp, [rp, #0] ; \
> + /* Test UART's reset bit */ \
> + tst rp, #(1 << bit) ; \
> + /* If set, can't use UART; jump to save no UART */ \
> + bne 90f ; \
> + /* Load address of CLK_OUT_ENB register */ \
> + movw rp, #TEGRA_CLK_OUT_ENB_##lhu & 0xffff ; \
> + movt rp, #TEGRA_CLK_OUT_ENB_##lhu >> 16 ; \
> + /* Load value from CLK_OUT_ENB register */ \
> + ldr rp, [rp, #0] ; \
> + /* Test UART's clock enable bit */ \
> + tst rp, #(1 << bit) ; \
> + /* If clear, can't use UART; jump to save no UART */ \
> + beq 90f ; \
> + /* Passed all tests, load address of UART registers */ \
> + movw rp, #TEGRA_UART##uart##_BASE & 0xffff ; \
> + movt rp, #TEGRA_UART##uart##_BASE >> 16 ; \
> + /* Jump to save UART address */ \
> + b 91f
>
Maybe make this a subroutine?
Cheers,
Peter.
^ permalink raw reply
* [PATCH v2] pinctrl: reserve pins when states are activated
From: Linus Walleij @ 2012-10-22 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019181019.GP4730@atomide.com>
On Fri, Oct 19, 2012 at 8:10 PM, Tony Lindgren <tony@atomide.com> wrote:
> [Me]
>> Instead: let use reserve the pins when the state is activated
>> and drop them when the state is disabled, i.e. when we move to
>> another state. This way different devices/functions can use the
>> same pins at different times.
>
> Hmm doesn't this mean that we are now doing lots of extra
> reserving and dropping of pins? Performance is important from
> latency point of view for cases where we need to remux pins
> constantly runtime PM.
It is only done in case the pinmux state is switched in runtime
suspend/resume, so it's e.g. possible to just alter the pin config.
But in general what you say is true.
We used to to the same thing by having drivers call
pinctrl_get()/pinctrl_put() in this case instead, but that went
away with the introduction of states, so we cannot encode
different pin sets with say
pinctrl_get(dev, "foo")/pinctrl_get(dev, "bar")
anymore since there is only one pinctrl handle per device,
but multiple states.
If this turns out to be a severe performance bottleneck, I
suggest to add some additional constraint API, like
pinctrl_set_pinmux_homegeneous_pinsets(true) that will
at runtime select whether the pin allocation is done when
getting the pinctrl handle instead.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm: dts: omap4-sdp: pinmux configuration for keypad
From: Sourav @ 2012-10-22 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5084F99B.1030709@ti.com>
Hi Benoit,
On Monday 22 October 2012 01:15 PM, Benoit Cousson wrote:
> Hi Sourav,
>
> On 10/22/2012 09:29 AM, Sourav Poddar wrote:
>> Currently, omap4 keypad mux settings are done in the board file.
>> Populate the mux settings in the dts file for the keypad to
>> work via dt.
> Have you changed the driver to handle properly the dependency with the
> pinctrl and thus return EPROBE_DEFER if this is not ready?
I have send a patch[1] to the mailing list on the driver changes.
http://www.spinics.net/lists/linux-omap/msg79985.html.
Though, I see I have missed the following EPROBE_DEFER check..
+ if (PTR_ERR(dev->pins) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
Will add for the above patch.
> Seb Guiriec has just sent a patch to do that for the omap-i2c driver
> ([PATCH] i2c: omap: adopt pinctrl support).
>
>> Cc: Felipe Balbi <balbi@ti.com>
>> Tested on omap4430 sdp with 3.7-rc1.
>>
>> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
>> ---
>> arch/arm/boot/dts/omap4-sdp.dts | 26 ++++++++++++++++++++++++++
>> 1 files changed, 26 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
>> index 5b7e04f..5efb059 100644
>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>> @@ -194,6 +194,27 @@
>> 0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT | MODE0 */
>> >;
>> };
>> +
>> + keypad_pins: pinmux_keypad_pins {
>> + pinctrl-single,pins = <
>> + 0x24 0x4119 /* gpmc_a18.kpd_row6 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x26 0x4119 /* gpmc_a19.kpd_row6 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x2c 0x4001 /* gpmc_a22.kpd_col6 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x2e 0x4001 /* gpmc_a23.kpd_col7 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x13c 0x4001 /* kpd_col0.kpd_col0 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x13e 0x4001 /* kpd_col1.kpd_col1 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x140 0x4001 /* kpd_col2.kpd_col2 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x142 0x10F /* kpd_col3.kpd_col3 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
> Alway use lower case for hexa value.
Ok. Will fix and send a new version.
>> + 0x144 0x4001 /* kpd_col4.kpd_col4 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x146 0x4001 /* kpd_col5.kpd_col5 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x148 0xc119 /* kpd_row0.kpd_row0 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x14a 0x4119 /* kpd_row1.kpd_row1 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x14c 0x4119 /* kpd_row2.kpd_row2 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x14e 0x4119 /* kpd_row3.kpd_row3 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x150 0x4119 /* kpd_row4.kpd_row4 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x152 0x4119 /* kpd_row5.kpd_row5 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + >;
>> + };
>> };
>>
>> &i2c1 {
>> @@ -406,3 +427,8 @@
>> &mcbsp3 {
>> status = "disabled";
>> };
>> +
>> +&keypad {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&keypad_pins>;
>> +};
> Otherwise that looks good.
>
> Thanks,
> Benoit
Thanks,
Sourav
^ permalink raw reply
* [PATCH] arm: dts: omap4-sdp: pinmux configuration for keypad
From: Benoit Cousson @ 2012-10-22 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50850299.7070405@ti.com>
On 10/22/2012 10:23 AM, Sourav wrote:
> Hi Benoit,
> On Monday 22 October 2012 01:15 PM, Benoit Cousson wrote:
>> Hi Sourav,
>>
>> On 10/22/2012 09:29 AM, Sourav Poddar wrote:
>>> Currently, omap4 keypad mux settings are done in the board file.
>>> Populate the mux settings in the dts file for the keypad to
>>> work via dt.
>> Have you changed the driver to handle properly the dependency with the
>> pinctrl and thus return EPROBE_DEFER if this is not ready?
> I have send a patch[1] to the mailing list on the driver changes.
> http://www.spinics.net/lists/linux-omap/msg79985.html.
Yeah, sorry, I've just seen it :-(.
> Though, I see I have missed the following EPROBE_DEFER check..
Yes, indeed.
> + if (PTR_ERR(dev->pins) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> Will add for the above patch.
Thanks,
Benoit
>> Seb Guiriec has just sent a patch to do that for the omap-i2c driver
>> ([PATCH] i2c: omap: adopt pinctrl support).
>>
>>> Cc: Felipe Balbi <balbi@ti.com>
>>> Tested on omap4430 sdp with 3.7-rc1.
>>>
>>> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
>>> ---
>>> arch/arm/boot/dts/omap4-sdp.dts | 26 ++++++++++++++++++++++++++
>>> 1 files changed, 26 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-sdp.dts
>>> b/arch/arm/boot/dts/omap4-sdp.dts
>>> index 5b7e04f..5efb059 100644
>>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>>> @@ -194,6 +194,27 @@
>>> 0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT |
>>> MODE0 */
>>> >;
>>> };
>>> +
>>> + keypad_pins: pinmux_keypad_pins {
>>> + pinctrl-single,pins = <
>>> + 0x24 0x4119 /* gpmc_a18.kpd_row6 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> + 0x26 0x4119 /* gpmc_a19.kpd_row6 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> + 0x2c 0x4001 /* gpmc_a22.kpd_col6 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> + 0x2e 0x4001 /* gpmc_a23.kpd_col7 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> + 0x13c 0x4001 /* kpd_col0.kpd_col0 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> + 0x13e 0x4001 /* kpd_col1.kpd_col1 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> + 0x140 0x4001 /* kpd_col2.kpd_col2 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> + 0x142 0x10F /* kpd_col3.kpd_col3 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>> Alway use lower case for hexa value.
> Ok. Will fix and send a new version.
>>> + 0x144 0x4001 /* kpd_col4.kpd_col4 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> + 0x146 0x4001 /* kpd_col5.kpd_col5 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> + 0x148 0xc119 /* kpd_row0.kpd_row0 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> + 0x14a 0x4119 /* kpd_row1.kpd_row1 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> + 0x14c 0x4119 /* kpd_row2.kpd_row2 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> + 0x14e 0x4119 /* kpd_row3.kpd_row3 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> + 0x150 0x4119 /* kpd_row4.kpd_row4 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> + 0x152 0x4119 /* kpd_row5.kpd_row5 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> + >;
>>> + };
>>> };
>>> &i2c1 {
>>> @@ -406,3 +427,8 @@
>>> &mcbsp3 {
>>> status = "disabled";
>>> };
>>> +
>>> +&keypad {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&keypad_pins>;
>>> +};
>> Otherwise that looks good.
>>
>> Thanks,
>> Benoit
> Thanks,
> Sourav
^ permalink raw reply
* [PATCH 1/2] ASoC: Ux500: Fixup complile errors due to merge
From: Lee Jones @ 2012-10-22 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350653427-28611-1-git-send-email-ulf.hansson@stericsson.com>
On Fri, 19 Oct 2012, Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> Likely during merge of the below commits ended up breaking compilation:
> ASoC: Ux500: Enable ux500 MSP driver for Device Tree
> ASoC: ux500_msp_i2s: better use devm functions and fix error return code
This is already fixed:
https://patchwork.kernel.org/patch/1593881/
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/2] ASoC: Ux500: Fixup compile error
From: Lee Jones @ 2012-10-22 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350653427-28611-2-git-send-email-ulf.hansson@stericsson.com>
On Fri, 19 Oct 2012, Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> The below commit introduced a compile error for a missing include file.
> ASoC: ux500_msp_i2s: better use devm functions and fix error return code
Already fixed:
https://patchwork.kernel.org/patch/1593881/
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [RFC PATCH v2] prevent top pte being overwritten before flushing
From: Andrew Yan-Pai Chen @ 2012-10-22 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017095757.GB5973@mudshark.cambridge.arm.com>
On Wed, Oct 17, 2012 at 5:57 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Oct 17, 2012 at 10:54:53AM +0100, Jason Lin wrote:
>> 2012/10/17 Will Deacon <will.deacon@arm.com>:
>> > On Wed, Oct 17, 2012 at 09:42:19AM +0100, Andrew Yan-Pai Chen wrote:
>> >> On Mon, Oct 15, 2012 at 1:42 AM, Andrew Yan-Pai Chen
>> >>
>> >> Any ideas?
>> >
>> > I wonder if we could use different ptes for each CPU (by hacking
>> > pte_offset_kernel) and then get away with just disabling preemption in both
>> > cases?
>> >
>> > Will
>>
>> Single core processor will also cause this issue in flush_pfn_alias().
>> So it should use different ptes for each task.
>> Will it be so complicated?
>
> You can just disable preemption in that case -- it's the spin_lock that I'd
> like to avoid.
>
> Will
If we have larger address space for VIPT aliasing flushing, 4 pages
per CPU (for 4 colours)
then we can avoid spinlocks by using per-cpu pte:
#define percpu_colour_offset (0x4000 * smp_processor_id())
static inline void set_top_pte(unsigned long va, pte_t pte)
{
pte_t *ptep = pte_offset_kernel(top_pmd, va + percpu_colour_offset);
set_pte_ext(ptep, pte, 0);
local_flush_tlb_kernel_page(va + percpu_colour_offset);
}
Is this what you mean, Will?
But considering set_top_pte() will also be called in other paths
(functions in highmem.c),
maybe we should keep set_top_pte() untouched but change the caller:
static void flush_icache_alias(unsigned long pfn, unsigned long vaddr,
unsigned long len)
{
unsigned long va = FLUSH_ALIAS_START + (CACHE_COLOUR(vaddr) <<
PAGE_SHIFT);
unsigned long offset = vaddr & (PAGE_SIZE - 1);
unsigned long to;
preempt_disable();
va += percpu_colour_offset;
set_top_pte(va, pfn_pte(pfn, PAGE_KERNEL));
to = va + offset;
flush_icache_range(to, to + len);
preempt_enable();
}
BTW, shouldn't the spinlock in v6_*_user_highpage_aliasing be removed
as well? (disabling preemption instead)
There seems to be no multi-core processors using VIPT aliasing D-cache?
Any comment would be appreciated.
--
Regards,
Andrew
^ permalink raw reply
* [PATCH v2] pwm: vt8500: Update vt8500 PWM driver support
From: Thierry Reding @ 2012-10-22 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350893615-14723-1-git-send-email-linux@prisktech.co.nz>
On Mon, Oct 22, 2012 at 09:13:35PM +1300, Tony Prisk wrote:
> This patch updates pwm-vt8500.c to support devicetree probing and
> make use of the common clock subsystem.
>
> A binding document describing the PWM controller found on
> arch-vt8500 is also included.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
> v2 changes:
> Merged binding doc patch with main code patch
> Fixes as requested by Thierry Reding.
>
> .../devicetree/bindings/pwm/vt8500-pwm.txt | 17 ++++
> drivers/pwm/pwm-vt8500.c | 87 +++++++++++++++-----
> 2 files changed, 82 insertions(+), 22 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
Looking better... just a few minor comments.
> diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
> new file mode 100644
> index 0000000..bcc6367
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
> @@ -0,0 +1,17 @@
> +VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
> +
> +Required properties:
> +- compatible: should be "via,vt8500-pwm"
> +- reg: physical base address and length of the controller's registers
> +- #pwm-cells: should be 2. The first cell specifies the per-chip index
> + of the PWM to use and the second cell is the period in nanoseconds.
> +- clocks: phandle to the PWM source clock
> +
> +Example:
> +
> +pwm1: pwm at d8220000 {
> + #pwm-cells = <2>;
> + compatible = "via,vt8500-pwm";
> + reg = <0xd8220000 0x1000>;
> + clocks = <&clkpwm>;
> +};
> diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
> index ad14389..36fef69 100644
> --- a/drivers/pwm/pwm-vt8500.c
> +++ b/drivers/pwm/pwm-vt8500.c
> @@ -1,7 +1,8 @@
> /*
> * drivers/pwm/pwm-vt8500.c
> *
> - * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
> + * Copyright (C) 2012 Tony Prisk <linux@prisktech.co.nz>
> + * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
> *
> * This software is licensed under the terms of the GNU General Public
> * License version 2, as published by the Free Software Foundation, and
> @@ -21,14 +22,25 @@
> #include <linux/io.h>
> #include <linux/pwm.h>
> #include <linux/delay.h>
> +#include <linux/clk.h>
>
> #include <asm/div64.h>
>
> -#define VT8500_NR_PWMS 4
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_address.h>
> +
> +/*
> + * SoC architecture allocates register space for 4 PWMs but only
> + * 2 are currently implemented.
> + */
> +#define VT8500_NR_PWMS 2
>
> struct vt8500_chip {
> struct pwm_chip chip;
> void __iomem *base;
> + struct clk *clk;
> + int enable_cnt;
You don't need to keep a reference count yourself. The clock framework
does that for you.
> @@ -87,6 +99,11 @@ static int vt8500_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
> {
> struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
>
> + if (vt8500->enable_cnt == 0)
> + clk_enable(vt8500->clk);
> +
> + vt8500->enable_cnt++;
> +
Again, reference counting isn't needed. But you should be checking for
the return value of clk_enable().
> pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
> writel(5, vt8500->base + (pwm->hwpwm << 4));
> return 0;
> @@ -98,6 +115,11 @@ static void vt8500_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
>
> pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
> writel(0, vt8500->base + (pwm->hwpwm << 4));
> +
> + vt8500->enable_cnt--;
> +
> + if (vt8500->enable_cnt == 0)
> + clk_disable(vt8500->clk);
Just clk_disable() will be enough.
> @@ -107,12 +129,25 @@ static struct pwm_ops vt8500_pwm_ops = {
> .owner = THIS_MODULE,
> };
>
> -static int __devinit pwm_probe(struct platform_device *pdev)
> +static const struct of_device_id vt8500_pwm_dt_ids[] = {
> + { .compatible = "via,vt8500-pwm", },
> + { /* Sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, vt8500_pwm_dt_ids);
I've more often seen this without a blank line between. But if you
prefer this for readability or whatever reasons feel free to keep it as
is.
> +
> +static int vt8500_pwm_probe(struct platform_device *pdev)
> {
> struct vt8500_chip *chip;
> struct resource *r;
> + struct device_node *np = pdev->dev.of_node;
> int ret;
>
> + if (!np) {
> + dev_err(&pdev->dev, "invalid devicetree node\n");
> + return -EINVAL;
> + }
> +
> chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
> if (chip == NULL) {
> dev_err(&pdev->dev, "failed to allocate memory\n");
> @@ -123,6 +158,13 @@ static int __devinit pwm_probe(struct platform_device *pdev)
> chip->chip.ops = &vt8500_pwm_ops;
> chip->chip.base = -1;
> chip->chip.npwm = VT8500_NR_PWMS;
> + chip->clk = devm_clk_get(&pdev->dev, NULL);
> + chip->enable_cnt = 0;
> +
> + if (!chip->clk) {
The proper way to check this is with IS_ERR_OR_NULL(clk) and return
PTR_ERR(clk) in case of failure.
> + dev_err(&pdev->dev, "clock source not specified\n");
> + return -EINVAL;
> + }
>
> r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (r == NULL) {
> @@ -131,18 +173,24 @@ static int __devinit pwm_probe(struct platform_device *pdev)
> }
>
> chip->base = devm_request_and_ioremap(&pdev->dev, r);
> - if (chip->base == NULL)
> + if (!chip->base) {
> + dev_err(&pdev->dev, "memory resource not available\n");
devm_request_and_ioremap() already outputs an error message in case of
failure, so no need to repeat it here.
> return -EADDRNOTAVAIL;
> + }
> +
> + clk_prepare(chip->clk);
clk_prepare() can fail, so you should check for errors.
>
> ret = pwmchip_add(&chip->chip);
> - if (ret < 0)
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to add pwmchip\n");
> return ret;
> + }
>
> platform_set_drvdata(pdev, chip);
> return ret;
> }
>
> -static int __devexit pwm_remove(struct platform_device *pdev)
> +static int vt8500_pwm_remove(struct platform_device *pdev)
> {
> struct vt8500_chip *chip;
>
> @@ -150,28 +198,23 @@ static int __devexit pwm_remove(struct platform_device *pdev)
> if (chip == NULL)
> return -ENODEV;
>
> + clk_unprepare(chip->clk);
> +
> return pwmchip_remove(&chip->chip);
> }
>
> -static struct platform_driver pwm_driver = {
> +static struct platform_driver vt8500_pwm_driver = {
> + .probe = vt8500_pwm_probe,
> + .remove = vt8500_pwm_remove,
> .driver = {
> .name = "vt8500-pwm",
> .owner = THIS_MODULE,
> + .of_match_table = vt8500_pwm_dt_ids,
> },
> - .probe = pwm_probe,
> - .remove = __devexit_p(pwm_remove),
> };
>
> -static int __init pwm_init(void)
> -{
> - return platform_driver_register(&pwm_driver);
> -}
> -arch_initcall(pwm_init);
> -
> -static void __exit pwm_exit(void)
> -{
> - platform_driver_unregister(&pwm_driver);
> -}
> -module_exit(pwm_exit);
> +module_platform_driver(vt8500_pwm_driver);
Similar to my comment regarding the MODULE_DEVICE_TABLE() macro, I've
seen this usually without a blank line. But again that's mostly bike-
shedding and I'm find taking the patch with the blank line left in.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/d71dea6f/attachment.sig>
^ permalink raw reply
* [PATCH 03/10] tty: pxa: configure pin
From: Linus Walleij @ 2012-10-22 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508080CB.5010904@wwwdotorg.org>
On Fri, Oct 19, 2012 at 12:20 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/18/2012 03:06 AM, Haojian Zhuang wrote:
>> Configure pins by pinctrl driver.
>
> In general, it seems better to use pinctrl "hogs" if the driver is only
> going to statically set up one pinctrl state and never change it. The
> alternative is make every single driver execute these pinctrl calls,
> which could be tedious.
True. And each platform has to choose how to go ahead with this.
I always imagined that any system of the "power socket in wall"
type would just use hogs to configure its pins and be done with
it, and there appear to be some platforms like that. (e.g. MIPS and
various power-inaware references come to mind).
For the Ux500 drivers we have found that all of those that have pin
resources actually have to be handled by the driver. The reason is
that all of them have idle and/or sleep states that need to be
handled at runtime.
As an additional complication our drivers are used also by
the Versatile and SPEAr family of platforms, so the control
need to be tolerant (accept missing pinctrl handles and states)
as well. (I can see that other drivers take shortcuts by being less
elaborate since there is a 1:1 driver<->platform mapping.)
An alternative to embedding the pin handling code into
the drivers is to use bus notifiers as is done with the
shmobile clocking by drivers/base/power/clock_ops.c
I could easily imagine pinctrl_ops.c like that for some
platforms. This mandates still binding the pin table entries
to a device but avoids adding any code to the drivers.
However this latter approach does not work for us (Ux500) -
the three resources we have: clocks, pins and power domains
are dependent on state switch ordering (sometimes you need
to switch off the clock then set pin state, sometimes the
other way around) and it is not even
the same for all drivers - the notifier approach mandates
that all drivers do the clock, power domain and pin handling
uniformly.
> However, that does raise one question: If all the pinctrl setup is done
> by hogs, then how do we ensure that the pinctrl driver is probed first,
> and hence sets up the pins before any driver relies on them being set
> up? If a driver explicitly enables a pinctrl state (as in this patch),
> then deferred probe ensures that, but without any explicit pinctrl
> action, it'll only work by luck.
Yes, since there are no explicit dependencies with hogs
it is implicitly decoupled and you only know that the hogging will
happen whenever the pin controller driver is probed.
We have many such pieces of code in the kernel for sure,
but I agree it's not always very elegant :-/
If using the bus nofifier approach I described above the
listener can just listen to BUS_NOTIFY_BIND_DRIVER
and BUS_NOTIFY_UNBOUND_DRIVER and hog/unhog
the drivers' pins at this point, but as described this approach
has other drawbacks.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] cpufreq: governors: remove redundant code
From: Viresh Kumar @ 2012-10-22 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <98478a02ae69afc01b3c7860e42a4d763b2045e8.1350677395.git.viresh.kumar@linaro.org>
On 20 October 2012 01:42, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> Initially ondemand governor was written and then using its code conservative
> governor is written. It used a lot of code from ondemand governor, but copy of
> code was created instead of using the same routines from both governors. Which
> increased code redundancy, which is difficult to manage.
>
> This patch is an attempt to move common part of both the governors to
> cpufreq_governor.c file to come over above mentioned issues.
>
> This shouldn't change anything from functionality point of view.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>
> Hi Rafael,
>
> This patch is *NOT TESTED*... (only compiled)
> Out of office now, so can't test it on board.
>
> Floated it, so that i can get some early comments if possible.
Didn't crashed :)
Tested both ondemand and conservative governors and they are working
fine.
> drivers/cpufreq/Makefile | 4 +-
> drivers/cpufreq/cpufreq_conservative.c | 558 +++++++------------------
> drivers/cpufreq/cpufreq_governor.c | 314 ++++++++++++++
> drivers/cpufreq/cpufreq_governor.h | 177 ++++++++
> drivers/cpufreq/cpufreq_ondemand.c | 728 ++++++++++-----------------------
> include/linux/cpufreq.h | 2 +-
> 6 files changed, 864 insertions(+), 919 deletions(-)
diffstat might not look awesome, but considering two new files with
file headers, #includes, etc added.. this looks reasonable :)
--
viresh
^ permalink raw reply
* [PATCH 07/10] pinctrl: remove mutex lock in groups show
From: Linus Walleij @ 2012-10-22 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50808200.3080207@wwwdotorg.org>
On Fri, Oct 19, 2012 at 12:26 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/18/2012 03:07 AM, Haojian Zhuang wrote:
>> Mutex is locked duplicatly by pinconf_groups_show() and
>> pin_config_group_get(). It results dead lock. So avoid to lock mutex
>> in pinconf_groups_show().
>
> With this outer lock removed, how do we ensure that the pinctrl driver
> that is being called into remains loaded? Does the existence of the
> debugfs file ensure this, such that if it's open, the pinctrl driver
> can't be removed?
No, don't think so, dangling debugfs files is a common problem.
> Related, I wonder if much of the variable setup at the start of the
> function shouldn't happen inside the lock instead of outside:
>
> static int pinconf_groups_show(struct seq_file *s, void *what)
> {
> struct pinctrl_dev *pctldev = s->private;
> const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
> const struct pinconf_ops *ops = pctldev->desc->confops;
> unsigned ngroups = pctlops->get_groups_count(pctldev);
>
> since what if s->private is unregistered/destroyed while this function
> is running?
The debugfs code is fragile by nature I think, that's why we are
usually a bit relaxed here and it's also why it should be disabled
on production systems.
But any hardening patches are welcome, however we need to
get around the deadlock Haojian was seeing, maybe we should
introduce a separate debugfs mutex?
/me is slightly confused though...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used
From: kishon @ 2012-10-22 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350571199.2143.53.camel@sokoban>
Hi,
On Thursday 18 October 2012 08:09 PM, Tero Kristo wrote:
> On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
>> hi,
>>
>> On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
>>>>> +static int __init omap4430_phy_power_down(void)
>>>>> +{
>>>>> + void __iomem *ctrl_base;
>>>>> +
>>>>> + if (!cpu_is_omap44xx())
>>>>> + return 0;
>>>>> +
>>>>> + ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
>>>>> + if (!ctrl_base) {
>>>>> + pr_err("control module ioremap failed\n");
>>>>> + return -ENOMEM;
>>>>> + }
>>>>> +
>>>>> + /* Power down the phy */
>>>>> + __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
>>>>> +
>>>>> + iounmap(ctrl_base);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +early_initcall(omap4430_phy_power_down);
>>>>> +#endif
>>>>
>>>> I think you could do it even if the driver is enabled.
>>>
>>> Actually not at least now, it looks like the driver is not controlling
>>> this bit at all, so the driver would fail if we do this.
>>
>> then we can consider that a bug in the driver. Kishon, I thought you had
>> added SCM address space to PHY driver for this particular reason until
>> we get SCM driver, wasn't it ??
>
> Yes, I would say its a bug in the driver.
No. It's done in the driver (omap_usb_phy_power() in
drivers/usb/phy/omap-usb2.c). We explicitly power off the phy during
probe in the driver.
However we need this disable
> mechanism for the case where we don't have the driver also (which is the
> default config for omap.)
Agree.
Thanks
Kishon
^ permalink raw reply
* [PATCH RFC 02/15 v5] gpio: Add sysfs support to block GPIO API
From: Linus Walleij @ 2012-10-22 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019180232.GD3375@kroah.com>
On Fri, Oct 19, 2012 at 8:02 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> We used to have problems with attributes removing/adding devices or
> attributes from their callbacks, but that has been fixed up now, and the
> fact that the other gpio code works this way is good enough precedence
> to keep me from objecting to it.
OK thanks I get this now too...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 02/15 v5] gpio: Add sysfs support to block GPIO API
From: Linus Walleij @ 2012-10-22 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50813EB0.9040102@antcom.de>
On Fri, Oct 19, 2012 at 1:51 PM, Roland Stigge <stigge@antcom.de> wrote:
> [Me]
>> The block GPIO stuff is just following that design pattern.
>
> So what do you think about my just proposed idea of always having the
> "value" argument present, but only useable when "exported" is "1"? Now
> only talking about the block gpios, but later maybe also for gpios?
We should atleast be consistent and do it the same way for
blocks as individual gpios.
> But I would only do this if you and Greg consider it reasonable.
I'm still afraid of this whole thing and would seek Grant's consent.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 02/15 v5] gpio: Add sysfs support to block GPIO API
From: Roland Stigge @ 2012-10-22 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdagQhUjdbda55JaY-J33MTNsEMMFJ=1je8V428ZkEMb9A@mail.gmail.com>
On 10/22/2012 10:55 AM, Linus Walleij wrote:
> On Fri, Oct 19, 2012 at 1:51 PM, Roland Stigge <stigge@antcom.de> wrote:
>> So what do you think about my just proposed idea of always having the
>> "value" argument present, but only useable when "exported" is "1"? Now
>> only talking about the block gpios, but later maybe also for gpios?
>
> We should atleast be consistent and do it the same way for
> blocks as individual gpios.
OK, I'll leave it as creating-attribute-on-export.
>> But I would only do this if you and Greg consider it reasonable.
>
> I'm still afraid of this whole thing and would seek Grant's consent.
Yes, he acked. :-)
Thanks,
Roland
^ permalink raw reply
* [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used
From: Felipe Balbi @ 2012-10-22 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508509C6.10708@ti.com>
On Mon, Oct 22, 2012 at 02:24:30PM +0530, kishon wrote:
> Hi,
>
> On Thursday 18 October 2012 08:09 PM, Tero Kristo wrote:
> >On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
> >>hi,
> >>
> >>On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> >>>>>+static int __init omap4430_phy_power_down(void)
> >>>>>+{
> >>>>>+ void __iomem *ctrl_base;
> >>>>>+
> >>>>>+ if (!cpu_is_omap44xx())
> >>>>>+ return 0;
> >>>>>+
> >>>>>+ ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
> >>>>>+ if (!ctrl_base) {
> >>>>>+ pr_err("control module ioremap failed\n");
> >>>>>+ return -ENOMEM;
> >>>>>+ }
> >>>>>+
> >>>>>+ /* Power down the phy */
> >>>>>+ __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
> >>>>>+
> >>>>>+ iounmap(ctrl_base);
> >>>>>+
> >>>>>+ return 0;
> >>>>>+}
> >>>>>+early_initcall(omap4430_phy_power_down);
> >>>>>+#endif
> >>>>
> >>>>I think you could do it even if the driver is enabled.
> >>>
> >>>Actually not at least now, it looks like the driver is not controlling
> >>>this bit at all, so the driver would fail if we do this.
> >>
> >>then we can consider that a bug in the driver. Kishon, I thought you had
> >>added SCM address space to PHY driver for this particular reason until
> >>we get SCM driver, wasn't it ??
> >
> >Yes, I would say its a bug in the driver.
>
> No. It's done in the driver (omap_usb_phy_power() in
> drivers/usb/phy/omap-usb2.c). We explicitly power off the phy during
> probe in the driver.
so you also handle enabling the IP later when you need ? That's great,
it means we can do the above unconditionally, driver enabled or not.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/927ddcc6/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/2] regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT
From: Lee Jones @ 2012-10-22 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017074102.GJ14199@opensource.wolfsonmicro.com>
On Wed, 17 Oct 2012, Mark Brown wrote:
> On Tue, Oct 16, 2012 at 09:01:09AM +0100, Lee Jones wrote:
>
> > I'm assuming it's just the documentation patch you're missing.
>
> > Let me resend it as a single patch.
>
> This should really be part of the patch adding the bindings...
Would you like me to send the patch-set again?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used
From: kishon @ 2012-10-22 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022090723.GE14033@arwen.pp.htv.fi>
Hi,
On Monday 22 October 2012 02:37 PM, Felipe Balbi wrote:
> On Mon, Oct 22, 2012 at 02:24:30PM +0530, kishon wrote:
>> Hi,
>>
>> On Thursday 18 October 2012 08:09 PM, Tero Kristo wrote:
>>> On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
>>>> hi,
>>>>
>>>> On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
>>>>>>> +static int __init omap4430_phy_power_down(void)
>>>>>>> +{
>>>>>>> + void __iomem *ctrl_base;
>>>>>>> +
>>>>>>> + if (!cpu_is_omap44xx())
>>>>>>> + return 0;
>>>>>>> +
>>>>>>> + ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
>>>>>>> + if (!ctrl_base) {
>>>>>>> + pr_err("control module ioremap failed\n");
>>>>>>> + return -ENOMEM;
>>>>>>> + }
>>>>>>> +
>>>>>>> + /* Power down the phy */
>>>>>>> + __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
>>>>>>> +
>>>>>>> + iounmap(ctrl_base);
>>>>>>> +
>>>>>>> + return 0;
>>>>>>> +}
>>>>>>> +early_initcall(omap4430_phy_power_down);
>>>>>>> +#endif
>>>>>>
>>>>>> I think you could do it even if the driver is enabled.
>>>>>
>>>>> Actually not at least now, it looks like the driver is not controlling
>>>>> this bit at all, so the driver would fail if we do this.
>>>>
>>>> then we can consider that a bug in the driver. Kishon, I thought you had
>>>> added SCM address space to PHY driver for this particular reason until
>>>> we get SCM driver, wasn't it ??
>>>
>>> Yes, I would say its a bug in the driver.
>>
>> No. It's done in the driver (omap_usb_phy_power() in
>> drivers/usb/phy/omap-usb2.c). We explicitly power off the phy during
>> probe in the driver.
>
> so you also handle enabling the IP later when you need ? That's great,
> it means we can do the above unconditionally, driver enabled or not.
yes.
Thanks
Kishon
^ permalink raw reply
* [PATCH 1/2] regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT
From: Mark Brown @ 2012-10-22 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022091355.GE3785@gmail.com>
On Mon, Oct 22, 2012 at 10:13:55AM +0100, Lee Jones wrote:
> On Wed, 17 Oct 2012, Mark Brown wrote:
> > This should really be part of the patch adding the bindings...
> Would you like me to send the patch-set again?
When I said I'd applied the patch that was what I meant.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/f75a7fe2/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox