Re: [PATCH v3 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
On 11/23/2012 04:04 PM, Thierry Reding wrote:
On Tue, Nov 20, 2012 at 10:56:22AM +0100, Peter Ujfalusi wrote:
The driver supports the following LED outputs as generic PWM driver:
TWL4030 LEDA and LEDB (PWMA and PWMB)
TWL6030 Charging indicator LED (PWM LED)
On TWL6030 when the PWM requested LED is configured to be controlled by SW.
In this case the user can enable/disable and set the duty period freely.
When the PWM has been freed, the LED driver is put back to HW control.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-twl-led.c | 303
++
3 files changed, 314 insertions(+)
create mode 100644 drivers/pwm/pwm-twl-led.c
Doesn't this belong in the drivers/leds subsystem? Besides that, the
same comments as for the previous patch apply. One additional note
below.
The PINs itself are called as LED but they are PWMs at the end. If we
represent them as PWMs they can be used for different purposes which is going
to be needed for example in BeagleBoard, where the LEDA (PWMA) is used as a
GPO to enable/disable the USB host power.
Also the removed 'twl6030-pwm' driver was only controlled the LED part of
twl6030.
With this series I enable the use of the PWMs and the PWMs behind of the LED
functions to give us flexibility on how we are using them.
+static struct platform_driver twl_pwmled_driver = {
+.driver = {
+.name = twl-pwmled,
+.of_match_table = of_match_ptr(twl_pwmled_of_match),
+},
+.probe = twl_pwmled_probe,
+.remove = __devexit_p(twl_pwmled_remove),
You didn't annotate twl_pwmled_remove() with __devexit, so __devexit_p
isn't needed here either.
Oh yes, I have also received patches from a series which removes the
_devexit_p() from the kernel.
But should the __devexit need to be added to the remove function?
--
Péter
--
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: OMAP build now completely broken in latest arm-soc
On 2012-11-26 08:00, Olof Johansson wrote: Tony, Tomi, I've taken a stab at resolving these conflicts. They seem to come from the cleanups combined with fixes that went upstream, and it seems like we want to stick to the arm-soc versions for most of the conflicts. I've pushed a merge of 3.7-rc7 into next/cleanup (and for-next) of arm-soc, can you please check and see if this is the correct resolution? As far as I can tell it is, but a double-check would be appreciated. Conflicts were in: arch/arm/mach-omap2/omap_hwmod_44xx_data.c arch/arm/plat-omap/i2c.c drivers/video/omap2/dss/dss.c The hwmod data was trivial (include files). i2c was a little hairier, a revert in mainline -- I presumed we're still good with our arm-soc contents so I stuck close to what we had there. The DSS change seems to be done completely differently in mainline, i.e. the surrounding code is different to what we have in arm-soc today, and it looks like the bugfix (3630-specific stuff) is taken care of in the version we had. So I stuck to that. But, please speak up ASAP if the above doesn't look correct, since we want to fix it up before we merge much on top. The dss.c is resolved correctly. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/1] ARM: OMAP2+: enable support for GPIO connected LEDs
On 11/26/2012 06:45 AM, AnilKumar, Chimata wrote: On Sat, Nov 24, 2012 at 15:04:02, Javier Martinez Canillas wrote: Many OMAP boards use GPIO LEDs to notify status to the user on boot. So, it is good to have by default support for GPIO connected LEDs as well as some commonly used triggers. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/configs/omap2plus_defconfig |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6333e96..7c6cbdf 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,14 @@ CONFIG_MMC_UNSAFE_RESUME=y CONFIG_SDIO_UART=y CONFIG_MMC_OMAP=y CONFIG_MMC_OMAP_HS=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_LEDS_TRIGGER_BACKLIGHT=y +CONFIG_LEDS_TRIGGER_GPIO=y +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y Hi Javier, Similar patch sent few days back http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/133760.html Let me know do you have any comments Thanks AnilKumar Hi AnilKumar, I haven't seen your patch before sorry. I've answered on your original patch thread. Thanks a lot and best regards, Javier -- 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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
Hi, On Fri, Nov 23, 2012 at 11:27:34AM -0500, Alan Stern wrote: On Fri, 23 Nov 2012, Felipe Balbi wrote: And maybe the same sort of scheme could be used for clocks, although I don't know how to do it in a generic way that will work on all platforms. perhaps making use of pm_clk_add() and letting PM layer do the rest for us ? If that doesn't work then it means PM layer's clk handling could be improved, I suppose. Is the clock framework sufficiently generic at this point that it can be used by core code (like the PM layer)? It already is :-) See drivers/base/power/clock_ops.c -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 03/10] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
Hi Vaibhav, On 11/26/2012 06:19 AM, Bedia, Vaibhav wrote: On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote: On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote: As part of PWM subsystem integration, PWM subsystem are sharing resources like clock across submodules (ECAP, EQEP EHRPWM). To handle resource sharing IP integration 1. Rework on parent child relation between PWMSS and ECAP, EQEP EHRPWM child devices to support runtime PM. 2. Add support for opt_clks in EHRPWM HWMOD entry to handle additional clock gating from control module. 3. Add HWMOD entries for EQEP PWM submodule. Is there any review on this patch? This patch depends on ECAP EHRPWM to work in am335x. First of all, I think you should break up this patch as per the 3 points that you mentioned above. The usage of opt_clks for this does not look right to me. Based on your description this clock is necessary and not optional on AM335x and on Davinci platforms this clock does not exist. I think the custom activate/deactivate functions in the OMAP runtime PM implementation was a good fit for keeping this SoC integration detail out of the driver code. However, the current DT flow in omap_device.c seems to assign the default activate/deactivate ops. Is that approach deprecated? The issue is that this approach is not doable anymore with DT, that's why I had to provide a default set of functions. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] pwm: Remove pwm-twl6030 driver
On 11/23/2012 04:05 PM, Thierry Reding wrote: On Tue, Nov 20, 2012 at 10:56:20AM +0100, Peter Ujfalusi wrote: This driver only supported the Charging indicator LED. New set of drivers going to provide support for both PWMs and LEDs for twl4030 and twl6030 series of PMICs. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/pwm/Kconfig | 9 --- drivers/pwm/Makefile | 1 - drivers/pwm/pwm-twl6030.c | 184 -- 3 files changed, 194 deletions(-) delete mode 100644 drivers/pwm/pwm-twl6030.c I think I'd rather see this patch as the last in the series to make sure that no functionality is dropped across the series. Sure, I will move it as a last patch. -- Péter -- 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] i2c: omap: Remove the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE flag
The OMAP_I2C_FLAG_RESET_REGS_POSTIDLE is not used anymore
in the i2c driver. Remove the flag.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Has dependency on the below patch
http://git.pengutronix.de/?p=wsa/linux.git;a=commitdiff;h=554c96744afd169886bd6fc2736fb0d9aaf634e8
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 +--
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +--
drivers/i2c/busses/i2c-omap.c |3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 943222c4..3dd9e69 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -791,8 +791,7 @@ static struct omap_hwmod omap3xxx_dss_venc_hwmod = {
/* I2C1 */
static struct omap_i2c_dev_attr i2c1_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
- OMAP_I2C_FLAG_BUS_SHIFT_2,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_hwmod omap3xxx_i2c1_hwmod = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0b1249e..1afab5f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1527,8 +1527,7 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
};
/* i2c1 */
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 872444a..d3b853b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1034,8 +1034,7 @@ static const struct i2c_algorithm omap_i2c_algo = {
#ifdef CONFIG_OF
static struct omap_i2c_bus_platform_data omap3_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
- .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
-OMAP_I2C_FLAG_BUS_SHIFT_2,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_i2c_bus_platform_data omap4_pdata = {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/7] ARM: OMAP2+: omap2plus_defconfig: Enable leds-gpio driver
On Mon, Nov 26, 2012 at 13:59:24, Javier Martinez Canillas wrote: On Wed, Nov 21, 2012 at 7:59 AM, AnilKumar Ch anilku...@ti.com wrote: AM335X-EVMSK and AM335X-BONE devices have gpio controlled user leds, one has to manually enable this support to use user leds. So this patch enables gpio-leds driver in omap2plus_defconfig. Also enables TRIGGER_TIMER and TRIGGER_HEARTBEAT. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 133f04a..5e1a763 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -202,6 +202,11 @@ CONFIG_MMC_UNSAFE_RESUME=y CONFIG_SDIO_UART=y CONFIG_MMC_OMAP=y CONFIG_MMC_OMAP_HS=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_OMAP=y CONFIG_RTC_DRV_TWL92330=y -- 1.7.9.5 Hi AnilKumar, Your patch looks good to me but I would enable CONFIG_LEDS_TRIGGER_DEFAULT_ON too since this seems to be a very popular trigger used on many boards. But this could be made on a follow up patch too, so is your call. I will submit v2 (with this change) in few days. I am waiting for review comments on other patches in this series. Thanks AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
On Mon, Nov 26, 2012 at 09:30:03AM +0100, Peter Ujfalusi wrote:
On 11/23/2012 04:04 PM, Thierry Reding wrote:
On Tue, Nov 20, 2012 at 10:56:22AM +0100, Peter Ujfalusi wrote:
The driver supports the following LED outputs as generic PWM driver:
TWL4030 LEDA and LEDB (PWMA and PWMB)
TWL6030 Charging indicator LED (PWM LED)
On TWL6030 when the PWM requested LED is configured to be controlled by SW.
In this case the user can enable/disable and set the duty period freely.
When the PWM has been freed, the LED driver is put back to HW control.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-twl-led.c | 303
++
3 files changed, 314 insertions(+)
create mode 100644 drivers/pwm/pwm-twl-led.c
Doesn't this belong in the drivers/leds subsystem? Besides that, the
same comments as for the previous patch apply. One additional note
below.
The PINs itself are called as LED but they are PWMs at the end. If we
represent them as PWMs they can be used for different purposes which is going
to be needed for example in BeagleBoard, where the LEDA (PWMA) is used as a
GPO to enable/disable the USB host power.
Heh, that's an interesting use-case for a PWM. =)
Also the removed 'twl6030-pwm' driver was only controlled the LED part of
twl6030.
With this series I enable the use of the PWMs and the PWMs behind of the LED
functions to give us flexibility on how we are using them.
Alright, we can keep it in the PWM subsystem then.
+static struct platform_driver twl_pwmled_driver = {
+ .driver = {
+ .name = twl-pwmled,
+ .of_match_table = of_match_ptr(twl_pwmled_of_match),
+ },
+ .probe = twl_pwmled_probe,
+ .remove = __devexit_p(twl_pwmled_remove),
You didn't annotate twl_pwmled_remove() with __devexit, so __devexit_p
isn't needed here either.
Oh yes, I have also received patches from a series which removes the
_devexit_p() from the kernel.
But should the __devexit need to be added to the remove function?
__devexit_p without a corresponding __devexit doesn't make sense. But as
all of __devinit, __devexit and __devexit_p will be removed sooner or
later, new code just shouldn't bother adding it. In this case, just drop
__devexit_p.
Thierry
pgpQDvwjBEQsV.pgp
Description: PGP signature
Re: [PATCH] i2c: omap: Remove the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE flag
On Mon, Nov 26, 2012 at 02:43:55PM +0530, Shubhrajyoti D wrote:
The OMAP_I2C_FLAG_RESET_REGS_POSTIDLE is not used anymore
in the i2c driver. Remove the flag.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Has dependency on the below patch
http://git.pengutronix.de/?p=wsa/linux.git;a=commitdiff;h=554c96744afd169886bd6fc2736fb0d9aaf634e8
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 +--
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +--
drivers/i2c/busses/i2c-omap.c |3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 943222c4..3dd9e69 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -791,8 +791,7 @@ static struct omap_hwmod omap3xxx_dss_venc_hwmod = {
/* I2C1 */
static struct omap_i2c_dev_attr i2c1_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
- OMAP_I2C_FLAG_BUS_SHIFT_2,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
if it's not used anymore, how about removing its definition too ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 2/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs
On 11/23/2012 03:58 PM, Thierry Reding wrote:
On Tue, Nov 20, 2012 at 10:56:21AM +0100, Peter Ujfalusi wrote:
The driver supports the following PWM outputs:
TWL4030 PWM0 and PWM1
TWL6030 PWM1 and PWM2
On TWL4030 the PWM signals are muxed. Upon requesting the PWM the driver
will select the correct mux so the PWM can be used. When the PWM has been
freed the original configuration going to be restored.
configuration is going to be
Yes, I'll fix it.
+config PWM_TWL
+tristate TWL4030/6030 PWM support
+select HAVE_PWM
Why do you select HAVE_PWM?
LEDS_PWM driver for example depends on this option. Not sure why we have this
in the first place, why PWM alone is not good enough?
we could also select HAVE_PWM when the CONFIG_PWM is enabled to cut back on
duplicated lines in the Kconfig.
+static int twl_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+int duty_cycle = DIV_ROUND_UP(duty_ns * TWL_PWM_MAX, period_ns);
+u8 pwm_config[2] = {1, 0};
+int base, ret;
+
+/*
+ * To configure the duty period:
+ * On-cycle is set to 1 (the minimum allowed value)
+ * The off time of 0 is not configurable, so the mapping is:
+ * 0 - off cycle = 2,
+ * 1 - off cycle = 2,
+ * 2 - off cycle = 3,
+ * 126 - off cycle 127,
+ * 127 - off cycle 1
+ * When on cycle == off cycle the PWM will be always on
+ */
+duty_cycle += 1;
The canonical form to write this would be duty_cycle++, but maybe it
would even be better to add it to the expression that defines
duty_cycle?
True. This is actually a leftover from a previous version I had for the
calculation. Will change it.
+static int twl4030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+int ret;
+u8 val;
+
+ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+if (ret 0) {
+dev_err(chip-dev, %s: Failed to read GPBR1\n, pwm-label);
+return ret;
+}
+
+val |= TWL4030_PWM_TOGGLE(pwm-hwpwm, TWL4030_PWMXCLK_ENABLE);
+
+ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+if (ret 0)
+dev_err(chip-dev, %s: Failed to enable PWM\n, pwm-label);
+
+val |= TWL4030_PWM_TOGGLE(pwm-hwpwm, TWL4030_PWMX_ENABLE);
+
+ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+if (ret 0)
+dev_err(chip-dev, %s: Failed to enable PWM\n, pwm-label);
+
+return ret;
+}
Does this perhaps need some locking to make sure the read-modify-write
sequence isn't interrupted?
I'll add locking (mutex) to both drivers.
+static void twl4030_pwm_disable(struct pwm_chip *chip, struct pwm_device
*pwm)
+{
+int ret;
+u8 val;
+
+ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+if (ret 0) {
+dev_err(chip-dev, %s: Failed to read GPBR1\n, pwm-label);
+return;
+}
+
+val = ~TWL4030_PWM_TOGGLE(pwm-hwpwm, TWL4030_PWMX_ENABLE);
+
+ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+if (ret 0)
+dev_err(chip-dev, %s: Failed to disable PWM\n, pwm-label);
+
+val = ~TWL4030_PWM_TOGGLE(pwm-hwpwm, TWL4030_PWMXCLK_ENABLE);
+
+ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+if (ret 0)
+dev_err(chip-dev, %s: Failed to disable PWM\n, pwm-label);
+}
Same here.
+static int twl4030_pwm_request(struct pwm_chip *chip, struct pwm_device
*pwm)
+{
+struct twl_pwm_chip *twl = container_of(chip, struct twl_pwm_chip,
+chip);
This could use a macro like to_twl(chip).
Does the macro really makes it more readable?
+int ret;
+u8 val, mask, bits;
+
+ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_PMBR1_REG);
+if (ret 0) {
+dev_err(chip-dev, %s: Failed to read PMBR1\n, pwm-label);
+return ret;
+}
+
+if (pwm-hwpwm) {
+/* PWM 1 */
+mask = TWL4030_GPIO7_VIBRASYNC_PWM1_MASK;
+bits = TWL4030_GPIO7_VIBRASYNC_PWM1_PWM1;
+} else {
+/* PWM 0 */
+mask = TWL4030_GPIO6_PWM0_MUTE_MASK;
+bits = TWL4030_GPIO6_PWM0_MUTE_PWM0;
+}
+
+/* Save the current MUX configuration for the PWM */
+twl-twl4030_pwm_mux = ~mask;
+twl-twl4030_pwm_mux |= (val mask);
+
+/* Select PWM functionality */
+val = ~mask;
+val |= bits;
+
+ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_PMBR1_REG);
+if (ret 0)
+dev_err(chip-dev, %s: Failed to request PWM\n, pwm-label);
+
+return ret;
+}
Again, more read-modify-write without locking.
+
+static void twl4030_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+struct twl_pwm_chip *twl = container_of(chip,
Re: [PATCH v3 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
On 11/26/2012 10:17 AM, Thierry Reding wrote:
Doesn't this belong in the drivers/leds subsystem? Besides that, the
same comments as for the previous patch apply. One additional note
below.
The PINs itself are called as LED but they are PWMs at the end. If we
represent them as PWMs they can be used for different purposes which is going
to be needed for example in BeagleBoard, where the LEDA (PWMA) is used as a
GPO to enable/disable the USB host power.
Heh, that's an interesting use-case for a PWM. =)
You should have seen the expression on my face when I saw this on the
schematics ;)
Also the removed 'twl6030-pwm' driver was only controlled the LED part of
twl6030.
With this series I enable the use of the PWMs and the PWMs behind of the LED
functions to give us flexibility on how we are using them.
Alright, we can keep it in the PWM subsystem then.
Thank you.
+static struct platform_driver twl_pwmled_driver = {
+ .driver = {
+ .name = twl-pwmled,
+ .of_match_table = of_match_ptr(twl_pwmled_of_match),
+ },
+ .probe = twl_pwmled_probe,
+ .remove = __devexit_p(twl_pwmled_remove),
You didn't annotate twl_pwmled_remove() with __devexit, so __devexit_p
isn't needed here either.
Oh yes, I have also received patches from a series which removes the
_devexit_p() from the kernel.
But should the __devexit need to be added to the remove function?
__devexit_p without a corresponding __devexit doesn't make sense. But as
all of __devinit, __devexit and __devexit_p will be removed sooner or
later, new code just shouldn't bother adding it. In this case, just drop
__devexit_p.
I'll get rid of them.
Thank you,
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: Conditionally compile counter_32k
The 32K timer isn't available on all OMAP devices. Signed-off-by: Alessio Igor Bogani alessio.bog...@elettra.trieste.it --- arch/arm/plat-omap/Makefile |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 8d88584..b1b321c 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -3,11 +3,13 @@ # # Common support -obj-y := sram.o dma.o fb.o counter_32k.o +obj-y := sram.o dma.o fb.o obj-m := obj-n := obj- := +obj-$(CONFIG_OMAP_32K_TIMER) += counter_32k.o + # omap_device support (OMAP2+ only at the moment) obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o -- 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
[PATCH] i2c: omap: Remove the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE flag
The OMAP_I2C_FLAG_RESET_REGS_POSTIDLE is not used anymore
in the i2c driver. Remove the flag.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Has dependency on the below patch
http://git.pengutronix.de/?p=wsa/linux.git;a=commitdiff;h=554c96744afd169886bd6fc2736fb0d9aaf634e8
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 +--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |9 +++--
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +--
drivers/i2c/busses/i2c-omap.c |3 +--
include/linux/i2c-omap.h |1 -
5 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 59d5c1c..c9a186b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1103,8 +1103,7 @@ static struct omap_hwmod_class i2c_class = {
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
};
/* i2c1 */
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 943222c4..36270bb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -791,8 +791,7 @@ static struct omap_hwmod omap3xxx_dss_venc_hwmod = {
/* I2C1 */
static struct omap_i2c_dev_attr i2c1_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
- OMAP_I2C_FLAG_BUS_SHIFT_2,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_hwmod omap3xxx_i2c1_hwmod = {
@@ -817,8 +816,7 @@ static struct omap_hwmod omap3xxx_i2c1_hwmod = {
/* I2C2 */
static struct omap_i2c_dev_attr i2c2_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
-OMAP_I2C_FLAG_BUS_SHIFT_2,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_hwmod omap3xxx_i2c2_hwmod = {
@@ -843,8 +841,7 @@ static struct omap_hwmod omap3xxx_i2c2_hwmod = {
/* I2C3 */
static struct omap_i2c_dev_attr i2c3_dev_attr = {
.fifo_depth = 64, /* bytes */
- .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
-OMAP_I2C_FLAG_BUS_SHIFT_2,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_hwmod_irq_info i2c3_mpu_irqs[] = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..eb40dbc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1526,8 +1526,7 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
};
/* i2c1 */
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index fabcbe1..815a401 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1038,8 +1038,7 @@ static const struct i2c_algorithm omap_i2c_algo = {
#ifdef CONFIG_OF
static struct omap_i2c_bus_platform_data omap3_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
- .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
-OMAP_I2C_FLAG_BUS_SHIFT_2,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_i2c_bus_platform_data omap4_pdata = {
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index 1b25c04..babe0cf 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@ -20,7 +20,6 @@
#define OMAP_I2C_FLAG_NO_FIFO BIT(0)
#define OMAP_I2C_FLAG_SIMPLE_CLOCK BIT(1)
#define OMAP_I2C_FLAG_16BIT_DATA_REG BIT(2)
-#define OMAP_I2C_FLAG_RESET_REGS_POSTIDLE BIT(3)
#define OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLKBIT(5)
#define OMAP_I2C_FLAG_FORCE_19200_INT_CLK BIT(6)
/* how the CPU address bus must be translated for I2C unit access */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] i2c: omap: Remove the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE flag
The OMAP_I2C_FLAG_RESET_REGS_POSTIDLE is not used anymore
in the i2c driver. Remove the flag.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Has dependency on the below patch
http://git.pengutronix.de/?p=wsa/linux.git;a=commitdiff;h=554c96744afd169886bd6fc2736fb0d9aaf634e8
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 +--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |9 +++--
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +--
drivers/i2c/busses/i2c-omap.c |3 +--
include/linux/i2c-omap.h |1 -
5 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 59d5c1c..c9a186b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1103,8 +1103,7 @@ static struct omap_hwmod_class i2c_class = {
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
};
/* i2c1 */
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 943222c4..36270bb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -791,8 +791,7 @@ static struct omap_hwmod omap3xxx_dss_venc_hwmod = {
/* I2C1 */
static struct omap_i2c_dev_attr i2c1_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
- OMAP_I2C_FLAG_BUS_SHIFT_2,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_hwmod omap3xxx_i2c1_hwmod = {
@@ -817,8 +816,7 @@ static struct omap_hwmod omap3xxx_i2c1_hwmod = {
/* I2C2 */
static struct omap_i2c_dev_attr i2c2_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
-OMAP_I2C_FLAG_BUS_SHIFT_2,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_hwmod omap3xxx_i2c2_hwmod = {
@@ -843,8 +841,7 @@ static struct omap_hwmod omap3xxx_i2c2_hwmod = {
/* I2C3 */
static struct omap_i2c_dev_attr i2c3_dev_attr = {
.fifo_depth = 64, /* bytes */
- .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
-OMAP_I2C_FLAG_BUS_SHIFT_2,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_hwmod_irq_info i2c3_mpu_irqs[] = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..eb40dbc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1526,8 +1526,7 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
};
/* i2c1 */
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index fabcbe1..815a401 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1038,8 +1038,7 @@ static const struct i2c_algorithm omap_i2c_algo = {
#ifdef CONFIG_OF
static struct omap_i2c_bus_platform_data omap3_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
- .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
-OMAP_I2C_FLAG_BUS_SHIFT_2,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_i2c_bus_platform_data omap4_pdata = {
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index 1b25c04..babe0cf 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@ -20,7 +20,6 @@
#define OMAP_I2C_FLAG_NO_FIFO BIT(0)
#define OMAP_I2C_FLAG_SIMPLE_CLOCK BIT(1)
#define OMAP_I2C_FLAG_16BIT_DATA_REG BIT(2)
-#define OMAP_I2C_FLAG_RESET_REGS_POSTIDLE BIT(3)
#define OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLKBIT(5)
#define OMAP_I2C_FLAG_FORCE_19200_INT_CLK BIT(6)
/* how the CPU address bus must be translated for I2C unit access */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: Remove the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE flag
On Mon, Nov 26, 2012 at 2:44 PM, Felipe Balbi ba...@ti.com wrote: - OMAP_I2C_FLAG_BUS_SHIFT_2, + .flags = OMAP_I2C_FLAG_BUS_SHIFT_2, if it's not used anymore, how about removing its definition too ? Just updated the patch , thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] i2c: omap: Remove the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE flag
Hi, On Mon, Nov 26, 2012 at 03:25:11PM +0530, Shubhrajyoti D wrote: The OMAP_I2C_FLAG_RESET_REGS_POSTIDLE is not used anymore in the i2c driver. Remove the flag. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com looks ok to me: Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH] gpio: New driver for GPO emulation using PWM generators
On 11/23/2012 10:44 AM, Peter Ujfalusi wrote:
Hi Grant,
On 11/23/2012 10:13 AM, Peter Ujfalusi wrote:
Hi Grant,
On 11/23/2012 08:55 AM, Grant Likely wrote:
Ugh. and this is why I wanted the PWM and GPIO subsystems to use the
same namespace and binding. grumble, mutter But that's not your fault.
It's pretty horrible to have a separate translator node to convert a PWM
into a GPIO (with output only of course). The gpio properties should
appear directly in the PWM node itself and the translation code should
be in either the pwm or the gpio core. I don't think it should look like
a separate device.
Let me see if I understand your suggestion correctly. In the DT you suggest
something like this:
twl_pwmled: pwmled {
compatible = ti,twl4030-pwmled;
#pwm-cells = 2;
#gpio-cells = 2;
gpio-controller;
};
After I thought about this.. Is this what we really want?
After all what we have here is a PWM generator used to emulate a GPIO signal.
The PWM itself can be used for driving a LED (standard LED or backlight and we
have DT bindings for these already), vibra motor, or other things.
If we combine the PWM with GPIO we should go and 'bloat' the DT node to also
include all sort of other uses of PWM at once?
IMHO it is better to keep them as separate things.
pwm node to describe the PWM generator,
separate nodes to describe it's uses like led, backlight, motor and gpio.
The difference here is that the LED, backlight, etc are all different
physical devices begin driven by the pwm pin, so it makes sense to have a
device tree node for them, while using the pwm as gpio is just a different
function of the same physical pin. So in a sense the pwm controller also
becomes a gpio controller. I like the idea of the pwm core automatically
instantiating a pwm-gpo device if it sees a gpio-controller property in the
pwm device devicetree node.
- Lars
--
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] Input: omap4-keypad: Remove the OMAP4_KBD_SYSCONFIG and OMAP4_KBD_SYSSTATUS
The macros OMAP4_KBD_SYSSTATUS and OMAP4_KBD_SYSSTATUS are not used so remove them. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/input/keyboard/omap4-keypad.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index c05f98c..d2b72b7 100644 --- a/drivers/input/keyboard/omap4-keypad.c +++ b/drivers/input/keyboard/omap4-keypad.c @@ -36,8 +36,6 @@ /* OMAP4 registers */ #define OMAP4_KBD_REVISION 0x00 -#define OMAP4_KBD_SYSCONFIG0x10 -#define OMAP4_KBD_SYSSTATUS0x14 #define OMAP4_KBD_IRQSTATUS0x18 #define OMAP4_KBD_IRQENABLE0x1C #define OMAP4_KBD_WAKEUPENABLE 0x20 -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 03/10] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
Hi Benoit, On Mon, Nov 26, 2012 at 14:32:59, Cousson, Benoit wrote: Hi Vaibhav, On 11/26/2012 06:19 AM, Bedia, Vaibhav wrote: On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote: On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote: As part of PWM subsystem integration, PWM subsystem are sharing resources like clock across submodules (ECAP, EQEP EHRPWM). To handle resource sharing IP integration 1. Rework on parent child relation between PWMSS and ECAP, EQEP EHRPWM child devices to support runtime PM. 2. Add support for opt_clks in EHRPWM HWMOD entry to handle additional clock gating from control module. 3. Add HWMOD entries for EQEP PWM submodule. Is there any review on this patch? This patch depends on ECAP EHRPWM to work in am335x. First of all, I think you should break up this patch as per the 3 points that you mentioned above. The usage of opt_clks for this does not look right to me. Based on your description this clock is necessary and not optional on AM335x and on Davinci platforms this clock does not exist. I checked the DA830 TRM and looks like TBCLK for eHRPWM is an always on clock there. So, the only difference in AM335x is an additional enable bit. Instead of adding this as opt_clk in hwmod, we could add an always on clock node in Davinci clock data and have the driver always do a clk_enable() on the tbclk as part of the probe sequence. On AM335x, with the right clock node this will enable the clock in hardware and on DA830 it turns into a NOP. This way we can avoid adding the opt_clk entry in hwmod of eHRPWM. I think the custom activate/deactivate functions in the OMAP runtime PM implementation was a good fit for keeping this SoC integration detail out of the driver code. However, the current DT flow in omap_device.c seems to assign the default activate/deactivate ops. Is that approach deprecated? The issue is that this approach is not doable anymore with DT, that's why I had to provide a default set of functions. So once all OMAP drivers get converted to DT, will there be no notion of latency based activate/deactivate functions? Or will it get used in a different manner? Regards, Vaibhav -- 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: Problem with OHCI on OMAP4430
Alan, On Tue, Oct 30, 2012 at 9:34 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 30 Oct 2012, Mohan V wrote: Device not getting detected when connected--- / # [ 135.621002] usbhs_wakeup: Enabling clocks [ 135.625762] usbhs_runtime_resume:++ [ 135.630371] usbhs_runtime_resume:-- [ 135.638183] USB IO PAD Wakeup event triggered## [ 135.644958] usbhs_runtime_suspend:++ [ 135.649749] usbhs_runtime_suspend:- It appears that ohci_irq() didn't run. Did ohci_finish_controller_resume() get called? This function is not used in ohci-omap3.c and is used only in ohci-omap.c. Is it necessary to call this function? It is necessary if the driver supports suspend/resume. As far as I can tell, the ohci-omap3 driver does not have this support (at least, not in the 3.6 kernel) whereas the ohci-omap driver does. What driver produced the usbhs_runtime_suspend and usbhs_runtime_resume messages above? (No such messages are present in ohci-omap3.c.) Apparently that driver _does_ support suspend/resume. This driver is USBHS core driver for OMAP EHCI and OHCI (drivers/mfd/omap-usb-host.c) Okay. I don't understand why the usbhs_runtime_suspend routine ever got called. Since ohci-omap3 never allows the OHCI controller to be suspended, the parent platform device should never get suspended either. Sorry for the delay in confirmation. In the android kernel, it seems that somehow the OHCI interrupts are not propagated to ARM interrupt controller. So, reading one of the OHCI registers in usbhs_runtime_resume() seems to resolve the issue. Thanks, Mohan What do the various files in the /sys/devices/.../ohci-omap3.0/power directory show? What about the corresponding files in the power subdirectory of the parent device? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: New driver for GPO emulation using PWM generators
hi, On 11/26/2012 11:30 AM, Lars-Peter Clausen wrote: The difference here is that the LED, backlight, etc are all different physical devices begin driven by the pwm pin, so it makes sense to have a device tree node for them, while using the pwm as gpio is just a different function of the same physical pin. So in a sense the pwm controller also becomes a gpio controller. I like the idea of the pwm core automatically instantiating a pwm-gpo device if it sees a gpio-controller property in the pwm device devicetree node. OK, fair enough. I will go with the plan I described in the first mail for the GPIO use of PWM. -- Péter -- 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 RFC] i2c: omap: Remove the OMAP_I2C_IP_VERSION_*
The OMAP_I2C_IP_VERSION_1 and OMAP_I2C_IP_VERSION_2 was needed
as on VER2 we were not reading all the 32-bits. Since now that
we read the hi register we do not need the OMAP_I2C_IP_VERSION_*.
Delete the same.
The custom reset is also changed to detect VER2 based on the
scheme.
Also move some of the common defines to i2c-omap.h to avoid duplication.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/i2c.c | 16 +++-
arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 -
arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 -
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |1 -
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 -
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 -
arch/arm/plat-omap/i2c.c |3 ---
drivers/i2c/busses/i2c-omap.c |5 -
include/linux/i2c-omap.h | 16
9 files changed, 11 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c
index fc57e67..6532bc1 100644
--- a/arch/arm/mach-omap2/i2c.c
+++ b/arch/arm/mach-omap2/i2c.c
@@ -63,18 +63,16 @@ void __init omap2_i2c_mux_pins(int bus_id)
int omap_i2c_reset(struct omap_hwmod *oh)
{
u32 v;
- u16 i2c_con;
+ u16 i2c_con, scheme;
int c = 0;
- if (oh-class-rev == OMAP_I2C_IP_VERSION_2) {
- i2c_con = OMAP4_I2C_CON_OFFSET;
- } else if (oh-class-rev == OMAP_I2C_IP_VERSION_1) {
+ i2c_con = OMAP4_I2C_CON_OFFSET;
+ v = omap_hwmod_read(oh, 0x4);
+
+ scheme = OMAP_I2C_SCHEME(v);
+
+ if (scheme == OMAP_I2C_SCHEME_0)
i2c_con = OMAP2_I2C_CON_OFFSET;
- } else {
- WARN(1, Cannot reset I2C block %s: unsupported revision\n,
-oh-name);
- return -EINVAL;
- }
/* Disable I2C */
v = omap_hwmod_read(oh, i2c_con);
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b5db600..51251a9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -91,7 +91,6 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
- .rev= OMAP_I2C_IP_VERSION_1,
.reset = omap_i2c_reset,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index b79ccf6..260b3d1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -70,7 +70,6 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
- .rev= OMAP_I2C_IP_VERSION_1,
.reset = omap_i2c_reset,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index c9a186b..ce1f68e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1098,7 +1098,6 @@ static struct omap_hwmod_class_sysconfig am33xx_i2c_sysc
= {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = am33xx_i2c_sysc,
- .rev= OMAP_I2C_IP_VERSION_2,
.reset = omap_i2c_reset,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 36270bb..5c1c8e2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -612,7 +612,6 @@ static struct omap_hwmod am35xx_uart4_hwmod = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
- .rev= OMAP_I2C_IP_VERSION_1,
.reset = omap_i2c_reset,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index eb40dbc..d6ef477 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1521,7 +1521,6 @@ static struct omap_hwmod_class_sysconfig
omap44xx_i2c_sysc = {
static struct omap_hwmod_class omap44xx_i2c_hwmod_class = {
.name = i2c,
.sysc = omap44xx_i2c_sysc,
- .rev= OMAP_I2C_IP_VERSION_2,
.reset = omap_i2c_reset,
};
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 6013831..d02d4b6 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -108,9 +108,6 @@ static inline int omap1_i2c_add_bus(int bus_id)
res[1].start = OMAP1_INT_I2C;
pdata = i2c_pdata[bus_id - 1];
- /* all OMAP1 have IP version 1 register set */
- pdata-rev = OMAP_I2C_IP_VERSION_1;
-
/* all OMAP1 I2C are implemented like this */
pdata-flags = OMAP_I2C_FLAG_NO_FIFO |
Re: [PATCH RFC] i2c: omap: Remove the OMAP_I2C_IP_VERSION_*
Hi, On Mon, Nov 26, 2012 at 05:09:42PM +0530, Shubhrajyoti D wrote: The OMAP_I2C_IP_VERSION_1 and OMAP_I2C_IP_VERSION_2 was needed as on VER2 we were not reading all the 32-bits. Since now that we read the hi register we do not need the OMAP_I2C_IP_VERSION_*. Delete the same. The custom reset is also changed to detect VER2 based on the scheme. looks like this should become a series IMO. First patch would move the macros to common header, second patch would switch the Reset part to use those macros and third patch gets rid of OMAP_I2C_IP_VERSION_* other than that, looks very good to me. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/7] mmc: omap_hsmmc: Fix Oops in case of data errors
On Mon, Nov 26, 2012 at 2:19 AM, Chris Ball c...@laptop.org wrote: Hi Venkat, On Mon, Nov 19 2012, Venkatraman S wrote: From: Balaji T K balaj...@ti.com commit ae4bf788ee9bf7c2d51b0309117d1fcccbdd50a2 mmc: omap_hsmmc: consolidate error report handling of HSMMC IRQ sets both end_cmd and end_trans to 1. Setting end_cmd to 1 for Data Timeout/CRC leads to NULL pointer dereference of host-cmd as the command complete has previously been handled. Set end_cmd only in case of command Timeout/CRC. Moreover host-cmd-error should not be updated on data error case, only host-data-error needs to be updated. Signed-off-by: Balaji T K balaj...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com Signed-off-by: Venkatraman S svenk...@ti.com Thanks, pushed all 7 patches to mmc-next for 3.8. Great - Thank you ! -- 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] ARM: OMAP: Conditionally compile counter_32k
On 11/26/12 11:28, Alessio Igor Bogani wrote: The 32K timer isn't available on all OMAP devices. Signed-off-by: Alessio Igor Bogani alessio.bog...@elettra.trieste.it --- arch/arm/plat-omap/Makefile |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 8d88584..b1b321c 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -3,11 +3,13 @@ # # Common support -obj-y := sram.o dma.o fb.o counter_32k.o +obj-y := sram.o dma.o fb.o obj-m := obj-n := obj- := +obj-$(CONFIG_OMAP_32K_TIMER) += counter_32k.o We are moving away from this config option in favor of runtime detection, so I don't think this patch is appropriate. Why do you need this? + # omap_device support (OMAP2+ only at the moment) obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o -- 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 RFC] i2c: omap: Remove the OMAP_I2C_IP_VERSION_*
On Mon, Nov 26, 2012 at 5:22 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Nov 26, 2012 at 05:09:42PM +0530, Shubhrajyoti D wrote: The OMAP_I2C_IP_VERSION_1 and OMAP_I2C_IP_VERSION_2 was needed as on VER2 we were not reading all the 32-bits. Since now that we read the hi register we do not need the OMAP_I2C_IP_VERSION_*. Delete the same. The custom reset is also changed to detect VER2 based on the scheme. looks like this should become a series IMO. First patch would move the macros to common header, second patch would switch the Reset part to use those macros and third patch gets rid of OMAP_I2C_IP_VERSION_* other than that, looks very good to me. OK will respin it accordingly. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4430 produces boot warnings
Hi, On Monday 26 November 2012 12:18 PM, Archit Taneja wrote: On Friday 23 November 2012 03:04 PM, Tero Kristo wrote: On Thu, 2012-11-22 at 16:44 +0200, Tomi Valkeinen wrote: On 2012-11-22 16:34, Tero Kristo wrote: I guess you checked that DSS pwrdm is switching between RET and ON in your setup? Yes: # cat /debug/pm_debug/count |grep dss [ 35.356567] pwrdm state mismatch(l3init_pwrdm) 3 != 1 [ 35.361938] pwrdm state mismatch(cam_pwrdm) 3 != 0 [ 35.366973] pwrdm state mismatch(ivahd_pwrdm) 3 != 1 [ 35.372253] pwrdm state mismatch(tesla_pwrdm) 3 != 1 [ 35.377532] pwrdm state mismatch(abe_pwrdm) 3 != 1 dss_pwrdm (RET),OFF:1,RET:11,INA:0,ON:11,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 l3_dss_clkdm-dss_pwrdm (0) then I load and unload the dss modules, and then: # cat /debug/pm_debug/count |grep dss [ 60.813629] pwrdm state mismatch(l3init_pwrdm) 3 != 1 [ 60.819000] pwrdm state mismatch(cam_pwrdm) 3 != 0 [ 60.824127] pwrdm state mismatch(ivahd_pwrdm) 3 != 1 [ 60.829376] pwrdm state mismatch(tesla_pwrdm) 3 != 1 [ 60.834625] pwrdm state mismatch(abe_pwrdm) 3 != 1 dss_pwrdm (ON),OFF:1,RET:21,INA:0,ON:22,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 l3_dss_clkdm-dss_pwrdm (0) Does the pwrdm mistakenly think that in RET state the DSS still keeps the register contents? This might be the case, however the pwrdm code should be generic and handle all domains properly. What is the tree / branch / commit you are using for testing this stuff? I can take a look at this also. arm-soc/for-next I guess this is caused because some of the patches are still not in the for-next branch, it looks like at least this is missing: https://patchwork.kernel.org/patch/1608901/ ...or the latest update done by Paul to that one. The patch I posted appears to have a small merge induced bug, it is registering the context loss soc_ops for am33xx when it should actually register those for omap4. This might explain another bug I've been looking at in a different branch recently... The update Paul posted does not seem to have this problem, but I haven't tested it myself. Applying the patch above, and registering the soc_ops for omap4 instead of am33xx doesn't seem to help. The context lost count now always returns 0. And to verify Tomi's observation, if we don't rely on the context lost count, and restore the registers always, we don't see the problem. So Rajendra and I found the problem. The function _omap4_update_context_lost() reads the register RM_DSS_DSS_CONTEXT for all DSS hwmods, and increments the count if we read a non zero value. The issue is that the DSS's parent platform device (tied to dss_core hwmod) is called first when resuming, it correctly reads the register and observes that DSS lost context, and then clears the register. When the children hwmods are enabled, the see that the registers are cleared, and hence never increment their count. One option is to make the DSS driver use the context lost count of the hwmod corresponding to the parent platform device. It sort of makes a bit of sense as all the DSS platform devices belong to the same power domain, so considering only the parent's context lost count is not so bad. The second option would be to have some usecounting mechanism in omap_hwmod where different hwmods belonging to the same power domain don't have their PM_CONTEXT registers cleared until all the hwmods are enabled. The first option is easier to implement, here is a patch for the DISPC driver: From 619276fa0e62b90875475eb345a310f1223e82f6 Mon Sep 17 00:00:00 2001 From: Archit Taneja arc...@ti.com Date: Mon, 26 Nov 2012 17:22:27 +0530 Subject: [PATCH] OMAPDSS: DISPC: Use DISPC's parent device to get context lost count When enabling a hwmod, omap_hwmod refers to the register mentioned in the hwmod struct's member 'prcm.omap4.context_offs' to see whether context was lost or not. It increments the context lost count for the hwmod and then clears the register. All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as context_offs. When DSS is enabled, the first hwmod to be enabled is the dss_core hwmod since it's the parent platform device. The dss_core hwmod updates it's context lost count correctly and clears the register. When the hwmods corresponding to the children platform devices are enabled. They see that the register is clear, and don't increment their context lost count. Therefore, all the children platfrom devices never report a change in context. The DISPC driver currently gets the context lost count for DSS from it's corresponsing platform device instance. The DISPC platform device is one of the child devices, and doesn't report the context lost count correctly. Make the DISPC driver get the context lost count from it's parent. The parent platform device's hwmod is the only one which correctly updates the context lost count. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/dispc.c |4 ++-- 1 file
[RFC PATCH 0/5] Device Paths introduced and applied to generic hub and panda
NB this is against usb-next at 3.7-rc6 The following series introduces wildcard device paths as discussed recently; in particular the wildcard idea is from Alan Stern. First the API is introduced for generating, comparing and registering the wildcard device paths. I put them in drivers/base for now but if that seems wrong it's easy to move. They are a default n CONFIG_ option. Then I remove the ehci-omap existing regulator support completely. Third I add optional regulator support to the usb generic hub. This uses wildcard device path APIs to look for a regulator that matches the hub. Again the support is optional on a default n CONFIG_ option. If the regulator is found, then it is enabled for the lifetime of the matching logical hub object. Board support for OMAP4 Panda is added which provides regulators with the correct wildcard name to match the ehci-omap.0 root hub object. The wildcard name is registered so it will be used as a literal on any matching generated device path. Lastly there's a config delta on omap2plus_defconfig which enables EHCI, which is otherwise disabled by default. The end result is that the SMSC HUB+ETH chip is off by default at boot, and is powered cleanly for the lifecycle of the ehci-hcd root hub object. Comments welcome, this is my first attempt at turning the discussion of the last few days into an implementation, it is working here well on Panda ES. -Andy --- Andy Green (5): drivers : introduce device_path api usb: omap ehci: remove all regulator control from ehci omap usb: hub: add device_path regulator control to generic hub omap4: panda: add smsc95xx regulator and reset dependent on root hub config omap2plus add ehci bits arch/arm/configs/omap2plus_defconfig | 42 +++ arch/arm/mach-omap2/Kconfig|1 arch/arm/mach-omap2/board-omap4panda.c | 90 +--- drivers/base/Kconfig |6 + drivers/base/Makefile |2 drivers/base/core.c|2 drivers/base/path.c| 181 drivers/usb/core/Kconfig | 10 ++ drivers/usb/core/hub.c | 26 - drivers/usb/host/ehci-omap.c | 33 -- include/linux/device.h | 12 ++ 11 files changed, 327 insertions(+), 78 deletions(-) create mode 100644 drivers/base/path.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/5] drivers : introduce device_path api
This adds a small optional API into drivers/base which deals with generating,
matching and registration of wildcard device paths.
From a struct device * you can generate a string like
/platform/usbhs_omap/ehci-omap.0/usb1/1-1
which enapsulates the path of the device's connection to the board.
These can be used to match up other assets, for example struct regulators,
that have been registed elsewhere with a device instance that is probed
asynchronously from the other board assets.
If your device is on a bus, as it probably is, the device path will feature
redundant bus indexes that do not contain information about the connectivity.
For example if more than one driver can generate devices on the same bus,
then the ordering of device probing will change the path, despite the
connectivity remains the same.
For that reason, to get a deterministic path for matching, wildcards are
allowed. If your target device has the path
/platform/usbhs_omap/ehci-omap.0/usb1/1-1
generated, in the asset you wish to match with it you can instead use
/platform/usbhs_omap/ehci-omap.0/usb*/*-1
in order to only leave the useful, invariant parts of the path to match
against.
To avoid having to adapt every kind of search by string api to also use
the wildcards, the api takes the approach you can register your wildcard,
and if a matching path is generated for a device, the wildcard itself is
handed back as the device path instead.
So if your board code or a (not yet done) DT binding registers this wildcard
/platform/usbhs_omap/ehci-omap.0/usb*
and the usb hub driver asks to generate its device path
device_path_generate(dev, name, sizeof name);
that is actually
/platform/usbhs_omap/ehci-omap.0/usb1
then what will be returned is
/platform/usbhs_omap/ehci-omap.0/usb*
providing the same literal string for ehci-omap.0 hub no matter how many\
usb buses have been registered before.
This wildcard string can then be matched to regulators or other string-
searchable assets intended for the device on that hardware path.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/base/Kconfig |6 ++
drivers/base/Makefile |2 +
drivers/base/core.c|2 +
drivers/base/path.c| 181
include/linux/device.h | 12 +++
5 files changed, 203 insertions(+)
create mode 100644 drivers/base/path.c
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index b34b5cd..3324a55 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -282,4 +282,10 @@ config CMA_AREAS
endif
+config DEVICEPATH
+ bool Device path api
+ default n
+ help
+ Include dynamicly probed path matching API
+
endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 5aa2d70..b8d5723 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -22,5 +22,7 @@ obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o
obj-$(CONFIG_REGMAP) += regmap/
obj-$(CONFIG_SOC_BUS) += soc.o
+obj-$(CONFIG_DEVICEPATH) += path.o
+
ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
diff --git a/drivers/base/core.c b/drivers/base/core.c
index abea76c..cc0ba02 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1368,6 +1368,8 @@ int __init devices_init(void)
if (!sysfs_dev_char_kobj)
goto char_kobj_err;
+ device_path_init();
+
return 0;
char_kobj_err:
diff --git a/drivers/base/path.c b/drivers/base/path.c
new file mode 100644
index 000..384e792
--- /dev/null
+++ b/drivers/base/path.c
@@ -0,0 +1,181 @@
+/*
+ * drivers/base/path.c - device_path apis for matching dynamic / variable
+ * device paths on buses like usb / mmc to wildcard constants from
+ * platform or DT
+ *
+ * Copyright (c) 2012 Linaro, LTD
+ * Author: Andy Green andy.gr...@linaro.org
+ *
+ * This file is released under the GPLv2
+ *
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/string.h
+#include linux/export.h
+#include linux/slab.h
+
+struct device_path {
+ char *path;
+ struct list_head list;
+};
+
+struct device_path list;
+DEFINE_MUTEX(lock);
+
+static int device_path_compare_wildcard(const char *awc, const char *b)
+{
+ while (*awc *b) {
+ if (*awc == '*') {
+ awc++;
+ /* wildcard disallowed from extening past / */
+ while (*b *b != *awc *b != '/')
+ b++;
+ }
+ if (*awc != *b)
+ return -ENOENT;
+ if (!*awc)
+ return 0;
+ awc++;
+ b++;
+ }
+
+ if (!*awc !*b)
+ return 0;
+
+ return -ENOENT;
+}
+
+static const char *device_path_find_wildcard(const char *device_path)
+{
+ struct device_path *dp;
+
+ mutex_lock(lock);
+ list_for_each_entry(dp, list.list, list) {
+
[RFC PATCH 2/5] usb: omap ehci: remove all regulator control from ehci omap
This series migrates it to the hub driver as suggested by
Felipe Balbi.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/usb/host/ehci-omap.c | 33 -
1 file changed, 33 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 44e7d0f..2292544 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -40,7 +40,6 @@
#include linux/slab.h
#include linux/usb/ulpi.h
#include plat/usb.h
-#include linux/regulator/consumer.h
#include linux/pm_runtime.h
#include linux/gpio.h
#include linux/clk.h
@@ -149,19 +148,6 @@ static int omap_ehci_init(struct usb_hcd *hcd)
return rc;
}
-static void disable_put_regulator(
- struct ehci_hcd_omap_platform_data *pdata)
-{
- int i;
-
- for (i = 0 ; i OMAP3_HS_USB_PORTS ; i++) {
- if (pdata-regulator[i]) {
- regulator_disable(pdata-regulator[i]);
- regulator_put(pdata-regulator[i]);
- }
- }
-}
-
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
@@ -223,23 +209,6 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
hcd-rsrc_len = resource_size(res);
hcd-regs = regs;
- /* get ehci regulator and enable */
- for (i = 0 ; i OMAP3_HS_USB_PORTS ; i++) {
- if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY) {
- pdata-regulator[i] = NULL;
- continue;
- }
- snprintf(supply, sizeof(supply), hsusb%d, i);
- pdata-regulator[i] = regulator_get(dev, supply);
- if (IS_ERR(pdata-regulator[i])) {
- pdata-regulator[i] = NULL;
- dev_dbg(dev,
- failed to get ehci port%d regulator\n, i);
- } else {
- regulator_enable(pdata-regulator[i]);
- }
- }
-
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
@@ -265,7 +234,6 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
return 0;
err_pm_runtime:
- disable_put_regulator(pdata);
pm_runtime_put_sync(dev);
usb_put_hcd(hcd);
@@ -290,7 +258,6 @@ static int ehci_hcd_omap_remove(struct platform_device
*pdev)
struct ehci_hcd_omap_platform_data *pdata = dev-platform_data;
usb_remove_hcd(hcd);
- disable_put_regulator(dev-platform_data);
iounmap(hcd-regs);
usb_put_hcd(hcd);
--
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 3/5] usb: hub: add device_path regulator control to generic hub
This adds the config option to associate a regulator with each hub,
when the hub on a specific, interesting device path appears, then
the regular is powered while the logical hub exists.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/usb/core/Kconfig | 10 ++
drivers/usb/core/hub.c | 26 +-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index f70c1a1..4a91eb1 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -95,3 +95,13 @@ config USB_OTG_BLACKLIST_HUB
and software costs by not supporting external hubs. So
are Embedded Hosts that don't offer OTG support.
+config USB_HUB_DEVICE_PATH_REGULATOR
+ bool Support generic regulators at hubs
+ select DEVICEPATH
+ depends on USB
+ default n
+ help
+ Allows you to use the device_path APIs to associate kernel regulators
+ with dynamically probed USB hubs, so the regulators are enabled
+ as the appropriate hub instance gets created and disabled as it
+ is destroyed.
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a815fd2..49ebb5e 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -26,6 +26,7 @@
#include linux/mutex.h
#include linux/freezer.h
#include linux/random.h
+#include linux/regulator/consumer.h
#include asm/uaccess.h
#include asm/byteorder.h
@@ -54,7 +55,9 @@ struct usb_hub {
struct usb_device *hdev;
struct kref kref;
struct urb *urb; /* for interrupt polling pipe */
-
+#ifdef CONFIG_USB_HUB_DEVICE_PATH_REGULATOR
+ struct regulator*regulator; /* optional power control */
+#endif
/* buffer for urb ... with extra space in case of babble */
char(*buffer)[8];
union {
@@ -1594,6 +1597,12 @@ static void hub_disconnect(struct usb_interface *intf)
if (hub-hdev-speed == USB_SPEED_HIGH)
highspeed_hubs--;
+#ifdef CONFIG_USB_HUB_DEVICE_PATH_REGULATOR
+ if (hub-regulator !IS_ERR(hub-regulator)) {
+ regulator_disable(hub-regulator);
+ regulator_put(hub-regulator);
+ }
+#endif
usb_free_urb(hub-urb);
kfree(hub-ports);
kfree(hub-descriptor);
@@ -1609,6 +1618,9 @@ static int hub_probe(struct usb_interface *intf, const
struct usb_device_id *id)
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+#ifdef CONFIG_USB_HUB_DEVICE_PATH_REGULATOR
+ char *dev_path;
+#endif
desc = intf-cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -1692,6 +1704,18 @@ descriptor_error:
return -ENOMEM;
}
+#ifdef CONFIG_USB_HUB_DEVICE_PATH_REGULATOR
+ /* if a regulator is associated on our device_path, use it */
+ dev_path = kmalloc(MAX_DEV_PATH_SIZE, GFP_KERNEL);
+ if (!device_path_generate(hdev-dev, dev_path, MAX_DEV_PATH_SIZE)) {
+ dev_info(hdev-dev, device_path: %s\n, dev_path);
+ hub-regulator = regulator_get(hdev-dev, dev_path);
+ if (!IS_ERR(hub-regulator))
+ regulator_enable(hub-regulator);
+ }
+ kfree(dev_path);
+#endif
+
kref_init(hub-kref);
INIT_LIST_HEAD(hub-event_list);
hub-intfdev = intf-dev;
--
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 4/5] omap4: panda: add smsc95xx regulator and reset dependent on root hub
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
Without power control, the ULPI PHY + SMSC9614 on the Panda eats 700-900mW
all the time, which is around the same as the idle power of the SoC and
rest of the board.
This allows us to start off with it depowered, and only power it if the
ehci-hcd module is inserted. When the module is removed, it's depowered
again.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/Kconfig|1
arch/arm/mach-omap2/board-omap4panda.c | 90 +---
2 files changed, 72 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index d669e22..5105109 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -368,6 +368,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select USB_HUB_DEVICE_PATH_REGULATOR
config OMAP3_EMU
bool OMAP3 debugging peripherals
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..b032b6b 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -154,11 +154,6 @@ static const struct usbhs_omap_board_data usbhs_bdata
__initconst = {
.reset_gpio_port[2] = -EINVAL
};
-static struct gpio panda_ehci_gpios[] __initdata = {
- { GPIO_HUB_POWER, GPIOF_OUT_INIT_LOW, hub_power },
- { GPIO_HUB_NRESET, GPIOF_OUT_INIT_LOW, hub_nreset },
-};
-
static void __init omap4_ehci_init(void)
{
int ret;
@@ -173,23 +168,76 @@ static void __init omap4_ehci_init(void)
clk_set_rate(phy_ref_clk, 1920);
clk_prepare_enable(phy_ref_clk);
- /* disable the power to the usb hub prior to init and reset phy+hub */
- ret = gpio_request_array(panda_ehci_gpios,
-ARRAY_SIZE(panda_ehci_gpios));
- if (ret) {
- pr_err(Unable to initialize EHCI power/reset\n);
- return;
- }
+ usbhs_init(usbhs_bdata);
+}
- gpio_export(GPIO_HUB_POWER, 0);
- gpio_export(GPIO_HUB_NRESET, 0);
- gpio_set_value(GPIO_HUB_NRESET, 1);
+/*
+ * hub_nreset also resets the ULPI PHY and is required after powering SMSC chip
+ * ULPI PHY is always powered... need to do reset once for both once
+ * hub_power enables a 3.3V regulator for (hub + eth) chip
+ * however there's no point having ULPI PHY in use alone
+ * since it's only connected to the (hub + eth) chip
+ */
- usbhs_init(usbhs_bdata);
+static struct regulator_init_data panda_hub = {
+ .constraints = {
+ .name = vhub,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+};
- /* enable power to hub */
- gpio_set_value(GPIO_HUB_POWER, 1);
-}
+static struct fixed_voltage_config panda_vhub = {
+ .supply_name = vhub,
+ .microvolts = 330,
+ .gpio = GPIO_HUB_POWER,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = panda_hub,
+};
+
+static struct platform_device omap_vhub_device = {
+ .name = reg-fixed-voltage,
+ .id = 2,
+ .dev = {
+ .platform_data = panda_vhub,
+ },
+};
+
+static struct regulator_init_data panda_ulpireset = {
+ /*
+* idea is that when operating ulpireset, regulator api will make
+* sure that the hub+eth chip is powered, since it's the parent
+*/
+ .supply_regulator = vhub, /* we are a child of vhub */
+ .constraints = {
+ /*
+* this magic string associates us with ehci-omap.0 root hub
+* when the root hub logical device is up, we will power
+* and reset [ ULPI PHY + [ HUB + ETH ] ]
+*/
+ .name = /platform/usbhs_omap/ehci-omap.0/usb*,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct fixed_voltage_config panda_vulpireset = {
+ .supply_name = /platform/usbhs_omap/ehci-omap.0/usb*,
+ .microvolts = 330,
+ .gpio = GPIO_HUB_NRESET,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = panda_ulpireset,
+};
+
+static struct platform_device omap_vulpireset_device = {
+ .name = reg-fixed-voltage,
+ .id = 3,
+ .dev = {
+ .platform_data = panda_vulpireset,
+ },
+};
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
@@ -503,7 +551,11 @@ static void __init omap4_panda_init(void)
omap4_panda_init_rev();
omap4_panda_i2c_init();
platform_add_devices(panda_devices,
[RFC PATCH 5/5] config omap2plus add ehci bits
omap2plus seems to have rotted a bit, this is the delta that appears if we enable modular build for ehci-hcd and smsc95xx. Signed-off-by: Andy Green andy.gr...@linaro.org --- arch/arm/configs/omap2plus_defconfig | 42 ++ 1 file changed, 17 insertions(+), 25 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6230304..2f858a3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -1,14 +1,14 @@ CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y -# CONFIG_SYSCTL_SYSCALL is not set -CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_SLAB=y CONFIG_PROFILING=y CONFIG_OPROFILE=y @@ -20,16 +20,15 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set +CONFIG_PARTITION_ADVANCED=y CONFIG_ARCH_OMAP=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y +CONFIG_SOC_OMAP5=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_NR_CPUS=2 -CONFIG_LEDS=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 @@ -87,22 +86,21 @@ CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_MD=y CONFIG_NETDEVICES=y -CONFIG_SMSC_PHY=y -CONFIG_NET_ETHERNET=y -CONFIG_SMC91X=y -CONFIG_SMSC911X=y CONFIG_KS8851=y CONFIG_KS8851_MLL=y -CONFIG_LIBERTAS=m -CONFIG_LIBERTAS_USB=m -CONFIG_LIBERTAS_SDIO=m -CONFIG_LIBERTAS_DEBUG=y +CONFIG_SMC91X=y +CONFIG_SMSC911X=y +CONFIG_SMSC_PHY=y CONFIG_USB_USBNET=y -CONFIG_USB_NET_SMSC95XX=y +CONFIG_USB_NET_SMSC95XX=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y +CONFIG_LIBERTAS=m +CONFIG_LIBERTAS_USB=m +CONFIG_LIBERTAS_SDIO=m +CONFIG_LIBERTAS_DEBUG=y CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y @@ -132,14 +130,13 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y -CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y +CONFIG_REGULATOR_TWL4030=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y -CONFIG_FB_OMAP_LCD_VGA=y CONFIG_OMAP2_DSS=m CONFIG_OMAP2_DSS_RFBI=y CONFIG_OMAP2_DSS_SDI=y @@ -154,7 +151,6 @@ CONFIG_PANEL_ACX565AKM=m CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_PLATFORM=y -CONFIG_DISPLAY_SUPPORT=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_FONTS=y @@ -174,13 +170,15 @@ CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=y +CONFIG_USB_EHCI_HCD=m +CONFIG_USB_EHCI_ROOT_HUB_TT=y +CONFIG_USB_EHCI_HCD_PLATFORM=m CONFIG_USB_WDM=y CONFIG_USB_STORAGE=y -CONFIG_USB_LIBUSUAL=y CONFIG_USB_TEST=y +CONFIG_OMAP_USB2=m CONFIG_USB_GADGET=y CONFIG_USB_GADGET_DEBUG=y CONFIG_USB_GADGET_DEBUG_FILES=y @@ -214,23 +212,18 @@ CONFIG_JFFS2_RUBIN=y CONFIG_UBIFS_FS=y CONFIG_CRAMFS=y CONFIG_NFS_FS=y -CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y -CONFIG_PARTITION_ADVANCED=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_PRINTK_TIME=y CONFIG_MAGIC_SYSRQ=y -CONFIG_DEBUG_KERNEL=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_PROVE_LOCKING=y -CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y -# CONFIG_RCU_CPU_STALL_DETECTOR is not set CONFIG_SECURITY=y CONFIG_CRYPTO_MICHAEL_MIC=y # CONFIG_CRYPTO_ANSI_CPRNG is not set @@ -239,4 +232,3 @@ CONFIG_CRC_T10DIF=y CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y -CONFIG_SOC_OMAP5=y -- 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] ARM: OMAP: Conditionally compile counter_32k
Hi Igor, On 26/11/2012 13:02, Igor Grinberg wrote: On 11/26/12 11:28, Alessio Igor Bogani wrote: [...] # Common support -obj-y := sram.o dma.o fb.o counter_32k.o +obj-y := sram.o dma.o fb.o obj-m := obj-n := obj- := +obj-$(CONFIG_OMAP_32K_TIMER) += counter_32k.o We are moving away from this config option in favor of runtime detection, Well, I'll be happy when it'll happen. Why do you need this? Because until now the build system doesn't honour the config file. Indeed it builds that source code file also when I set CONFIG_OMAP_32K_TIMER to n. The runtime detection isn't a good excuse for doesn't make the build system working like users expect. Ciao, Alessio -- 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 065/493] i2c: remove use of __devexit_p
Wolfram Sang writes: --osDK9TLjxFScVI/L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 20, 2012 at 02:46:21PM +0100, Jean Delvare wrote: On Mon, 19 Nov 2012 13:20:14 -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. =20 As mentioned on the lm-sensors list for hwmon patches already, I think it would be much clearer to not split __devexit, __devexit_p, __devinit etc. removal into separate patches. One patch per subsystem would be easier to review and apply. If patches grow too large then you'd rather split in a different direction, for example drivers/i2c/muxes vs. drivers/i2c/busses or even grouped by related bus drivers (see entries I2C OVER PARALLEL PORT and I2C/SMBUS CONTROLLER DRIVERS FOR PC in MAINTAINERS for examples of meaningful groups.) I agree with Jean here. Is there a V2 planned? With a change like this? Yes, my plan is to redo the patches for the i2c subsystem. -- Bill -- 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] ARM: OMAP: Conditionally compile counter_32k
On 11/26/12 15:15, Alessio Igor Bogani wrote: Hi Igor, On 26/11/2012 13:02, Igor Grinberg wrote: On 11/26/12 11:28, Alessio Igor Bogani wrote: [...] # Common support -obj-y := sram.o dma.o fb.o counter_32k.o +obj-y := sram.o dma.o fb.o obj-m := obj-n := obj- := +obj-$(CONFIG_OMAP_32K_TIMER) += counter_32k.o We are moving away from this config option in favor of runtime detection, Well, I'll be happy when it'll happen. Why do you need this? Because until now the build system doesn't honour the config file. Indeed it builds that source code file also when I set CONFIG_OMAP_32K_TIMER to n. The runtime detection isn't a good excuse for doesn't make the build system working like users expect. So, the problem is the users expectations... If you look, at Tony's omap-for-v3.8/timer branch, patch: ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER it should change the expectations (at least I tried to do this in Kconfig file). So, to the question of honoring the config option - yes, but it is a work in progress on removing that one. If you have a real issue that you are trying to fix - it is totally different thing, but if it is just config option honoring... then I don't think we should merge this patch. -- 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 06/16] mfd: omap-usb-host: cleanup clock management code
Felipe,
On 11/21/2012 03:39 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 15, 2012 at 04:34:04PM +0200, Roger Quadros wrote:
All ports have similarly named port clocks so we can
bunch them into a port data structure and use for loop
to enable/disable the clocks.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 208
+--
1 files changed, 101 insertions(+), 107 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 23cec57..7303c41 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -76,6 +76,8 @@
#define OMAP_UHH_DEBUG_CSR (0x44)
+#define MAX_HS_USB_PORTS3 /* Increase this if any chip has more */
+
/* Values of UHH_REVISION - Note: these are not given in the TRM */
#define OMAP_USBHS_REV1 0x0010 /* OMAP3 */
#define OMAP_USBHS_REV2 0x50700100 /* OMAP4 */
@@ -87,14 +89,15 @@
#define is_ehci_tll_mode(x) (x == OMAP_EHCI_PORT_MODE_TLL)
#define is_ehci_hsic_mode(x)(x == OMAP_EHCI_PORT_MODE_HSIC)
+struct usbhs_port {
+struct clk *utmi_clk;
+};
I rather not since this will make it a lot more difficult to use
pm_clk_add() :-s Also, this sort of thing should be dynamically
allocated anyway ;-)
Why do you say so? The whole point of this patch is to group similarly
named clocks so that we can use a for loop and set number of ports (or
clocks) dynamically. I suppose it would be just a matter of replacing
clk_enable/disable() with pm_clk_add() later, right?
If you see patch 11, we are adding 2 HSIC related clocks to this
structure. This means 9 clocks (i.e. 3 clocks for 3 ports) can be
managed using a simple for loop instead of coding each clock name by hand.
--
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/5] omap4: panda: add smsc95xx regulator and reset dependent on root hub
Hi Andy,
On 11/26/2012 02:45 PM, Andy Green wrote:
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
Without power control, the ULPI PHY + SMSC9614 on the Panda eats 700-900mW
all the time, which is around the same as the idle power of the SoC and
rest of the board.
This allows us to start off with it depowered, and only power it if the
ehci-hcd module is inserted. When the module is removed, it's depowered
again.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/Kconfig|1
arch/arm/mach-omap2/board-omap4panda.c | 90
+---
2 files changed, 72 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index d669e22..5105109 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -368,6 +368,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select USB_HUB_DEVICE_PATH_REGULATOR
config OMAP3_EMU
bool OMAP3 debugging peripherals
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..b032b6b 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -154,11 +154,6 @@ static const struct usbhs_omap_board_data usbhs_bdata
__initconst = {
.reset_gpio_port[2] = -EINVAL
};
-static struct gpio panda_ehci_gpios[] __initdata = {
- { GPIO_HUB_POWER, GPIOF_OUT_INIT_LOW, hub_power },
- { GPIO_HUB_NRESET, GPIOF_OUT_INIT_LOW, hub_nreset },
-};
-
static void __init omap4_ehci_init(void)
{
int ret;
@@ -173,23 +168,76 @@ static void __init omap4_ehci_init(void)
clk_set_rate(phy_ref_clk, 1920);
clk_prepare_enable(phy_ref_clk);
- /* disable the power to the usb hub prior to init and reset phy+hub */
- ret = gpio_request_array(panda_ehci_gpios,
- ARRAY_SIZE(panda_ehci_gpios));
- if (ret) {
- pr_err(Unable to initialize EHCI power/reset\n);
- return;
- }
+ usbhs_init(usbhs_bdata);
+}
- gpio_export(GPIO_HUB_POWER, 0);
- gpio_export(GPIO_HUB_NRESET, 0);
- gpio_set_value(GPIO_HUB_NRESET, 1);
+/*
+ * hub_nreset also resets the ULPI PHY and is required after powering SMSC
chip
+ * ULPI PHY is always powered... need to do reset once for both once
+ * hub_power enables a 3.3V regulator for (hub + eth) chip
+ * however there's no point having ULPI PHY in use alone
+ * since it's only connected to the (hub + eth) chip
+ */
- usbhs_init(usbhs_bdata);
+static struct regulator_init_data panda_hub = {
+ .constraints = {
+ .name = vhub,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+};
- /* enable power to hub */
- gpio_set_value(GPIO_HUB_POWER, 1);
-}
+static struct fixed_voltage_config panda_vhub = {
+ .supply_name = vhub,
+ .microvolts = 330,
+ .gpio = GPIO_HUB_POWER,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = panda_hub,
+};
+
+static struct platform_device omap_vhub_device = {
+ .name = reg-fixed-voltage,
+ .id = 2,
+ .dev = {
+ .platform_data = panda_vhub,
+ },
+};
+
+static struct regulator_init_data panda_ulpireset = {
+ /*
+ * idea is that when operating ulpireset, regulator api will make
+ * sure that the hub+eth chip is powered, since it's the parent
+ */
+ .supply_regulator = vhub, /* we are a child of vhub */
+ .constraints = {
+ /*
+ * this magic string associates us with ehci-omap.0 root hub
+ * when the root hub logical device is up, we will power
+ * and reset [ ULPI PHY + [ HUB + ETH ] ]
+ */
+ .name = /platform/usbhs_omap/ehci-omap.0/usb*,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct fixed_voltage_config panda_vulpireset = {
+ .supply_name = /platform/usbhs_omap/ehci-omap.0/usb*,
Does this supply_name really needs to be the magic string?
+ .microvolts = 330,
+ .gpio = GPIO_HUB_NRESET,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = panda_ulpireset,
+};
+
+static struct platform_device omap_vulpireset_device = {
+ .name = reg-fixed-voltage,
+ .id = 3,
+ .dev = {
+ .platform_data = panda_vulpireset,
+ },
+};
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
@@ -503,7 +551,11 @@ static void __init omap4_panda_init(void)
Re: [PATCH] gpio: New driver for GPO emulation using PWM generators
On Fri, 23 Nov 2012 10:44:36 +0100, Peter Ujfalusi peter.ujfal...@ti.com
wrote:
Hi Grant,
On 11/23/2012 10:13 AM, Peter Ujfalusi wrote:
Hi Grant,
On 11/23/2012 08:55 AM, Grant Likely wrote:
Ugh. and this is why I wanted the PWM and GPIO subsystems to use the
same namespace and binding. grumble, mutter But that's not your fault.
It's pretty horrible to have a separate translator node to convert a PWM
into a GPIO (with output only of course). The gpio properties should
appear directly in the PWM node itself and the translation code should
be in either the pwm or the gpio core. I don't think it should look like
a separate device.
Let me see if I understand your suggestion correctly. In the DT you suggest
something like this:
twl_pwmled: pwmled {
compatible = ti,twl4030-pwmled;
#pwm-cells = 2;
#gpio-cells = 2;
gpio-controller;
};
After I thought about this.. Is this what we really want?
After all what we have here is a PWM generator used to emulate a GPIO signal.
The PWM itself can be used for driving a LED (standard LED or backlight and we
have DT bindings for these already), vibra motor, or other things.
If we combine the PWM with GPIO we should go and 'bloat' the DT node to also
include all sort of other uses of PWM at once?
IMHO it is better to keep them as separate things.
pwm node to describe the PWM generator,
separate nodes to describe it's uses like led, backlight, motor and gpio.
You're effectively asking the pwm layer to behave like a gpio (which
is completely reasonable). Having a completely separate translation node
really doesn't make sense because it is entirely a software construct.
In fact, the way your using it is *entirely* to make the Linux driver
model instantiate the translation code. It has *nothing* to do with the
structure of the hardware. It makes complete sense that if a PWM is
going to be used as a GPIO, then the PWM node should conform to the GPIO
binding.
g.
--
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: OMAP build now completely broken in latest arm-soc
* Olof Johansson o...@lixom.net [121125 22:02]:
Hi,
On Sun, Nov 25, 2012 at 6:07 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sun, Nov 25, 2012 at 05:56:58AM -0800, Olof Johansson wrote:
Hi,
On Sun, Nov 25, 2012 at 1:37 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Not much more to say...
arch/arm/plat-omap/i2c.c:35:1: error: expected identifier or '(' before
'' token
Hmm. In for-next, line 35 is a blank line.
Could this be because of a merge conflict in your local version? This
is one of the files that has conflicts with mainline right now; I'll
look to see if we can resolve those in our tree later today.
Hmm, it looks like a merge conflict which didn't get fixed up... and
looking at it, it's beyond what I'd call trivial to fix.
So I'll shut down the build system until that can be resolved properly;
as OMAP is effectively unbuildable there's not much point it running the
builds.
Tony, Tomi,
I've taken a stab at resolving these conflicts. They seem to come from
the cleanups combined with fixes that went upstream, and it seems like
we want to stick to the arm-soc versions for most of the conflicts.
I've pushed a merge of 3.7-rc7 into next/cleanup (and for-next) of
arm-soc, can you please check and see if this is the correct
resolution? As far as I can tell it is, but a double-check would be
appreciated.
Conflicts were in:
arch/arm/mach-omap2/omap_hwmod_44xx_data.c
arch/arm/plat-omap/i2c.c
drivers/video/omap2/dss/dss.c
The hwmod data was trivial (include files). i2c was a little hairier,
a revert in mainline -- I presumed we're still good with our arm-soc
contents so I stuck close to what we had there. The DSS change seems
to be done completely differently in mainline, i.e. the surrounding
code is different to what we have in arm-soc today, and it looks like
the bugfix (3630-specific stuff) is taken care of in the version we
had. So I stuck to that.
Looks like that i2c revert probably needs a fixup patch as we still
don't have the prerequisites merged. Anyways, the fixup should be done
in mach-omap2/i2c.c instead of plat-omap/i2c.c, so your merge fix
is OK.
But, please speak up ASAP if the above doesn't look correct, since we
want to fix it up before we merge much on top.
That's good, thanks.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: omap4-keypad: Remove the OMAP4_KBD_SYSCONFIG and OMAP4_KBD_SYSSTATUS
On Mon, Nov 26, 2012 at 04:21:19PM +0530, Shubhrajyoti D wrote: The macros OMAP4_KBD_SYSSTATUS and OMAP4_KBD_SYSSTATUS are not used so remove them. They document the existing registers and do not add bloat to the generated objects so let's leave them be. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] drivers : introduce device_path api
On Mon, 26 Nov 2012, Andy Green wrote: This adds a small optional API into drivers/base which deals with generating, matching and registration of wildcard device paths. From a struct device * you can generate a string like /platform/usbhs_omap/ehci-omap.0/usb1/1-1 which enapsulates the path of the device's connection to the board. These can be used to match up other assets, for example struct regulators, that have been registed elsewhere with a device instance that is probed asynchronously from the other board assets. If your device is on a bus, as it probably is, the device path will feature redundant bus indexes that do not contain information about the connectivity. For example if more than one driver can generate devices on the same bus, then the ordering of device probing will change the path, despite the connectivity remains the same. For that reason, to get a deterministic path for matching, wildcards are allowed. If your target device has the path /platform/usbhs_omap/ehci-omap.0/usb1/1-1 generated, in the asset you wish to match with it you can instead use /platform/usbhs_omap/ehci-omap.0/usb*/*-1 in order to only leave the useful, invariant parts of the path to match against. Have you considered limiting these wildcards in various useful ways? In this example, the wildcard must match a string of decimal digits. (Furthermore the two wildcard strings will always match each other, although it's probably not necessary to add this sort of constraint.) I don't know what sort of matches people will want in the future. Perhaps one for hex digits, or one for arbitrary text with the exception of a few characters (such as '/' but perhaps others too). To do what you want for now, the match should be restricted to digits. To avoid having to adapt every kind of search by string api to also use the wildcards, the api takes the approach you can register your wildcard, and if a matching path is generated for a device, the wildcard itself is handed back as the device path instead. So if your board code or a (not yet done) DT binding registers this wildcard /platform/usbhs_omap/ehci-omap.0/usb* and the usb hub driver asks to generate its device path device_path_generate(dev, name, sizeof name); that is actually /platform/usbhs_omap/ehci-omap.0/usb1 then what will be returned is /platform/usbhs_omap/ehci-omap.0/usb* providing the same literal string for ehci-omap.0 hub no matter how many\ usb buses have been registered before. This wildcard string can then be matched to regulators or other string- searchable assets intended for the device on that hardware path. That's not how I would do it, at least, not for this application. I would register tuples containing a name, a pointer, and two callback routines. For example, (/platform/usbhs_omap/ehci-omap.0/usb*, omap_vhub_device, turn_on_regulator, turn_off_regulator) The when a device is registered whose path matches the string in such a tuple, the device core would know to invoke the first callback. The arguments would be a pointer to the device being registered and the pointer in the tuple. Similarly, the device core would invoke the second callback when the device is unregistered. There doesn't have to be anything in this scheme that's specific to hubs or even to USB. In particular, no changes to the hub driver would be needed. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] drivers : introduce device_path api
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote: +struct device_path list; +DEFINE_MUTEX(lock); Those are some very descriptive global variables you just created :( -- 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] Don't mark shared helper functions as inline
The helper functions that access the opaque struct clk should
not be marked inline since they are contained in clk.c, but expected
to be used by other compilation units. This causes compile errors
under gcc-4.7
In file included from arch/arm/mach-omap2/clockdomain.c:25:0:
arch/arm/mach-omap2/clockdomain.c: In function ‘clkdm_clk_disable’:
include/linux/clk-provider.h:338:12: error: inlining failed in call to
always_inline ‘__clk_get_enable_count’: function body not available
arch/arm/mach-omap2/clockdomain.c:1001:28: error: called from here
make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Russ Dill russ.d...@ti.com
---
drivers/clk/clk.c| 14 +++---
include/linux/clk-provider.h | 4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 56e4495e..ed01746 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -249,32 +249,32 @@ late_initcall(clk_disable_unused);
/***helper functions ***/
-inline const char *__clk_get_name(struct clk *clk)
+const char *__clk_get_name(struct clk *clk)
{
return !clk ? NULL : clk-name;
}
-inline struct clk_hw *__clk_get_hw(struct clk *clk)
+struct clk_hw *__clk_get_hw(struct clk *clk)
{
return !clk ? NULL : clk-hw;
}
-inline u8 __clk_get_num_parents(struct clk *clk)
+u8 __clk_get_num_parents(struct clk *clk)
{
return !clk ? -EINVAL : clk-num_parents;
}
-inline struct clk *__clk_get_parent(struct clk *clk)
+struct clk *__clk_get_parent(struct clk *clk)
{
return !clk ? NULL : clk-parent;
}
-inline int __clk_get_enable_count(struct clk *clk)
+int __clk_get_enable_count(struct clk *clk)
{
return !clk ? -EINVAL : clk-enable_count;
}
-inline int __clk_get_prepare_count(struct clk *clk)
+int __clk_get_prepare_count(struct clk *clk)
{
return !clk ? -EINVAL : clk-prepare_count;
}
@@ -300,7 +300,7 @@ out:
return ret;
}
-inline unsigned long __clk_get_flags(struct clk *clk)
+unsigned long __clk_get_flags(struct clk *clk)
{
return !clk ? -EINVAL : clk-flags;
}
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index c127315..f9f5e9e 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -335,8 +335,8 @@ const char *__clk_get_name(struct clk *clk);
struct clk_hw *__clk_get_hw(struct clk *clk);
u8 __clk_get_num_parents(struct clk *clk);
struct clk *__clk_get_parent(struct clk *clk);
-inline int __clk_get_enable_count(struct clk *clk);
-inline int __clk_get_prepare_count(struct clk *clk);
+int __clk_get_enable_count(struct clk *clk);
+int __clk_get_prepare_count(struct clk *clk);
unsigned long __clk_get_rate(struct clk *clk);
unsigned long __clk_get_flags(struct clk *clk);
int __clk_is_enabled(struct clk *clk);
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] drivers : introduce device_path api
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote: This adds a small optional API into drivers/base which deals with generating, matching and registration of wildcard device paths. From a struct device * you can generate a string like /platform/usbhs_omap/ehci-omap.0/usb1/1-1 which enapsulates the path of the device's connection to the board. These can be used to match up other assets, for example struct regulators, that have been registed elsewhere with a device instance that is probed asynchronously from the other board assets. If your device is on a bus, as it probably is, the device path will feature redundant bus indexes that do not contain information about the connectivity. Huh? A bus index does show the connectivity, well, one type of connectivity, but perhaps it's not the one _you_ happen to want at the moment. Which is fine, but I don't see why you want to try to figure this out using the device path in the first place, surely you have some other way that the hardware can describe itself to the kernel as to where it needs to be hooked up to? For example if more than one driver can generate devices on the same bus, then the ordering of device probing will change the path, despite the connectivity remains the same. That's an expected thing, I don't see the issue here. For that reason, to get a deterministic path for matching, wildcards are allowed. If your target device has the path Wait, no, why would you want a deterministic path and have that hard-coded into the kernel here? You can't rely on that any more than userspace can, so let's not start making the mistake that lots of userspace programmers originally did when they started using sysfs please. We have learned from our past mistakes. /platform/usbhs_omap/ehci-omap.0/usb1/1-1 generated, in the asset you wish to match with it you can instead use /platform/usbhs_omap/ehci-omap.0/usb*/*-1 in order to only leave the useful, invariant parts of the path to match against. To avoid having to adapt every kind of search by string api to also use the wildcards, the api takes the approach you can register your wildcard, and if a matching path is generated for a device, the wildcard itself is handed back as the device path instead. So if your board code or a (not yet done) DT binding registers this wildcard /platform/usbhs_omap/ehci-omap.0/usb* Device tree lists sysfs paths in it's descriptions? That's news to me. and the usb hub driver asks to generate its device path device_path_generate(dev, name, sizeof name); that is actually /platform/usbhs_omap/ehci-omap.0/usb1 then what will be returned is /platform/usbhs_omap/ehci-omap.0/usb* providing the same literal string for ehci-omap.0 hub no matter how many\ usb buses have been registered before. This wildcard string can then be matched to regulators or other string- searchable assets intended for the device on that hardware path. Ah, here's the root of your problem, right? You need a way for your hardware to tell the kernel that you have a regulator attached to a specific device? Using the device path and hard-coding it into the kernel is not the proper way to solve this, sorry. Use some other unique way to describe the hardware, surely the hardware designers couldn't have been that foolish not to provide this [1]? thanks, greg k-h [1] Yeah, I know I'm being hopeful here, and probably wrong, but then you need to push back. We are not helpless here. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/5] usb: hub: add device_path regulator control to generic hub
On Mon, Nov 26, 2012 at 12:45:45PM +, Andy Green wrote:
This adds the config option to associate a regulator with each hub,
when the hub on a specific, interesting device path appears, then
the regular is powered while the logical hub exists.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/usb/core/Kconfig | 10 ++
drivers/usb/core/hub.c | 26 +-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index f70c1a1..4a91eb1 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -95,3 +95,13 @@ config USB_OTG_BLACKLIST_HUB
and software costs by not supporting external hubs. So
are Embedded Hosts that don't offer OTG support.
+config USB_HUB_DEVICE_PATH_REGULATOR
+ bool Support generic regulators at hubs
+ select DEVICEPATH
+ depends on USB
+ default n
+ help
+ Allows you to use the device_path APIs to associate kernel regulators
+ with dynamically probed USB hubs, so the regulators are enabled
+ as the appropriate hub instance gets created and disabled as it
+ is destroyed.
Even if I did like the device_path code (which I do not), this needs to
be rewritten to actually make sense to a user who would have to pick
this option, not a kernel developer.
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a815fd2..49ebb5e 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -26,6 +26,7 @@
#include linux/mutex.h
#include linux/freezer.h
#include linux/random.h
+#include linux/regulator/consumer.h
#include asm/uaccess.h
#include asm/byteorder.h
@@ -54,7 +55,9 @@ struct usb_hub {
struct usb_device *hdev;
struct kref kref;
struct urb *urb; /* for interrupt polling pipe */
-
+#ifdef CONFIG_USB_HUB_DEVICE_PATH_REGULATOR
No #ifdefs in .c files, if at all possible please.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] drivers : introduce device_path api
On Mon, Nov 26, 2012 at 11:22:06AM -0800, Greg KH wrote: On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote: This adds a small optional API into drivers/base which deals with generating, matching and registration of wildcard device paths. From a struct device * you can generate a string like /platform/usbhs_omap/ehci-omap.0/usb1/1-1 which enapsulates the path of the device's connection to the board. These can be used to match up other assets, for example struct regulators, that have been registed elsewhere with a device instance that is probed asynchronously from the other board assets. If your device is on a bus, as it probably is, the device path will feature redundant bus indexes that do not contain information about the connectivity. Huh? A bus index does show the connectivity, well, one type of connectivity, but perhaps it's not the one _you_ happen to want at the moment. Which is fine, but I don't see why you want to try to figure this out using the device path in the first place, surely you have some other way that the hardware can describe itself to the kernel as to where it needs to be hooked up to? For example if more than one driver can generate devices on the same bus, then the ordering of device probing will change the path, despite the connectivity remains the same. That's an expected thing, I don't see the issue here. For that reason, to get a deterministic path for matching, wildcards are allowed. If your target device has the path Wait, no, why would you want a deterministic path and have that hard-coded into the kernel here? You can't rely on that any more than userspace can, so let's not start making the mistake that lots of userspace programmers originally did when they started using sysfs please. We have learned from our past mistakes. /platform/usbhs_omap/ehci-omap.0/usb1/1-1 Oh, and further proof of this, there are patches floating around to drop the platform name from the sys/drivers/ tree, so your driver just broke if that goes through, showing you really don't want to be hard-coding sysfs paths in any type of logic. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Don't mark shared helper functions as inline
Quoting Russ Dill (2012-11-26 11:20:09)
The helper functions that access the opaque struct clk should
not be marked inline since they are contained in clk.c, but expected
to be used by other compilation units. This causes compile errors
under gcc-4.7
In file included from arch/arm/mach-omap2/clockdomain.c:25:0:
arch/arm/mach-omap2/clockdomain.c: In function ‘clkdm_clk_disable’:
include/linux/clk-provider.h:338:12: error: inlining failed in call to
always_inline ‘__clk_get_enable_count’: function body not available
arch/arm/mach-omap2/clockdomain.c:1001:28: error: called from here
make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Hi Russ,
A fix for this was merged into rc7. See 93532c8a, clk: remove inline
usage from clk-provider.h.
Regardless, I'm still considering this patch. I've heard many times
that we should trust the compiler to optimize for us and some folks look
down on inlining in general. If anyone has an opinion on removing
inlines from the common clk core then please do speak up.
Russ, can you update to the latest rc and verify if that fix is enough
for you?
Regards,
Mike
Signed-off-by: Russ Dill russ.d...@ti.com
---
drivers/clk/clk.c| 14 +++---
include/linux/clk-provider.h | 4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 56e4495e..ed01746 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -249,32 +249,32 @@ late_initcall(clk_disable_unused);
/***helper functions ***/
-inline const char *__clk_get_name(struct clk *clk)
+const char *__clk_get_name(struct clk *clk)
{
return !clk ? NULL : clk-name;
}
-inline struct clk_hw *__clk_get_hw(struct clk *clk)
+struct clk_hw *__clk_get_hw(struct clk *clk)
{
return !clk ? NULL : clk-hw;
}
-inline u8 __clk_get_num_parents(struct clk *clk)
+u8 __clk_get_num_parents(struct clk *clk)
{
return !clk ? -EINVAL : clk-num_parents;
}
-inline struct clk *__clk_get_parent(struct clk *clk)
+struct clk *__clk_get_parent(struct clk *clk)
{
return !clk ? NULL : clk-parent;
}
-inline int __clk_get_enable_count(struct clk *clk)
+int __clk_get_enable_count(struct clk *clk)
{
return !clk ? -EINVAL : clk-enable_count;
}
-inline int __clk_get_prepare_count(struct clk *clk)
+int __clk_get_prepare_count(struct clk *clk)
{
return !clk ? -EINVAL : clk-prepare_count;
}
@@ -300,7 +300,7 @@ out:
return ret;
}
-inline unsigned long __clk_get_flags(struct clk *clk)
+unsigned long __clk_get_flags(struct clk *clk)
{
return !clk ? -EINVAL : clk-flags;
}
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index c127315..f9f5e9e 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -335,8 +335,8 @@ const char *__clk_get_name(struct clk *clk);
struct clk_hw *__clk_get_hw(struct clk *clk);
u8 __clk_get_num_parents(struct clk *clk);
struct clk *__clk_get_parent(struct clk *clk);
-inline int __clk_get_enable_count(struct clk *clk);
-inline int __clk_get_prepare_count(struct clk *clk);
+int __clk_get_enable_count(struct clk *clk);
+int __clk_get_prepare_count(struct clk *clk);
unsigned long __clk_get_rate(struct clk *clk);
unsigned long __clk_get_flags(struct clk *clk);
int __clk_is_enabled(struct clk *clk);
--
1.8.0
--
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 06/16] mfd: omap-usb-host: cleanup clock management code
Hi,
On Mon, Nov 26, 2012 at 05:14:45PM +0200, Roger Quadros wrote:
Felipe,
On 11/21/2012 03:39 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 15, 2012 at 04:34:04PM +0200, Roger Quadros wrote:
All ports have similarly named port clocks so we can
bunch them into a port data structure and use for loop
to enable/disable the clocks.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 208
+--
1 files changed, 101 insertions(+), 107 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 23cec57..7303c41 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -76,6 +76,8 @@
#define OMAP_UHH_DEBUG_CSR (0x44)
+#define MAX_HS_USB_PORTS 3 /* Increase this if any chip has more */
+
/* Values of UHH_REVISION - Note: these are not given in the TRM */
#define OMAP_USBHS_REV1 0x0010 /* OMAP3 */
#define OMAP_USBHS_REV2 0x50700100 /* OMAP4 */
@@ -87,14 +89,15 @@
#define is_ehci_tll_mode(x) (x == OMAP_EHCI_PORT_MODE_TLL)
#define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC)
+struct usbhs_port {
+ struct clk *utmi_clk;
+};
I rather not since this will make it a lot more difficult to use
pm_clk_add() :-s Also, this sort of thing should be dynamically
allocated anyway ;-)
Why do you say so? The whole point of this patch is to group similarly
named clocks so that we can use a for loop and set number of ports (or
clocks) dynamically. I suppose it would be just a matter of replacing
clk_enable/disable() with pm_clk_add() later, right?
If you see patch 11, we are adding 2 HSIC related clocks to this
structure. This means 9 clocks (i.e. 3 clocks for 3 ports) can be
managed using a simple for loop instead of coding each clock name by hand.
that's usually not what you want, actually. You want clock management to
be explicit so you can have micro-power optimizations. I fear that the
time omap-usb-host.c gets *truly* stabilized and we move to more
aggressive PM, we will undo these changes just to have a more granular
control of the clocks, at which point your patch would be rendered
useless.
--
balbi
signature.asc
Description: Digital signature
Re: [GIT PULL] ARM: OMAP2+: hwmod/PRM changes for 3.8
* Paul Walmsley p...@pwsan.com [121121 16:19]: Hi Tony The following changes since commit 558a0780b0a04862a678f7823215424b4e5501f9: Merge tag 'omap-cleanup-c-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8/clock (2012-11-13 13:32:24 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-a-for-3.8 for you to fetch changes up to c567b0584c352e7f97ced003be46bed8581ddd5b: ARM: OMAP2+: omap_device: Correct resource handling for DT boot (2012-11-21 16:15:18 -0700) Some miscellaneous OMAP hwmod changes for 3.8, along with a PRM change needed for one of the hwmod patches to function. Basic test logs for this branch on top of Tony's omap-for-v3.8/clock branch at commit 558a0780b0a04862a678f7823215424b4e5501f9 are here: http://www.pwsan.com/omap/testlogs/hwmod_devel_a_3.8/20121121161522/ However, omap-for-v3.8/clock at 558a0780 does not include some fixes that are needed for a successful test. With several reverts, fixes, and workarounds applied, the following test logs were obtained: http://www.pwsan.com/omap/testlogs/TEST_hwmod_devel_a_3.8/20121121162719/ which indicate that the series tests cleanly. Thanks pulling into omap-for-v3.8/devel-prcm, let's see if we can still get this and the clock changes in. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: hwmod/PRM changes for 3.8
* Tony Lindgren t...@atomide.com [121126 12:39]: Thanks pulling into omap-for-v3.8/devel-prcm, let's see if we can still get this and the clock changes in. Sorry I mean the timer changes from Jon and Igor, not clock changes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Don't mark shared helper functions as inline
On Mon, Nov 26, 2012 at 11:57:42AM -0800, Mike Turquette wrote: Quoting Russ Dill (2012-11-26 11:20:09) The helper functions that access the opaque struct clk should not be marked inline since they are contained in clk.c, but expected to be used by other compilation units. This causes compile errors under gcc-4.7 In file included from arch/arm/mach-omap2/clockdomain.c:25:0: arch/arm/mach-omap2/clockdomain.c: In function ‘clkdm_clk_disable’: include/linux/clk-provider.h:338:12: error: inlining failed in call to always_inline ‘__clk_get_enable_count’: function body not available arch/arm/mach-omap2/clockdomain.c:1001:28: error: called from here make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Hi Mike. Regardless, I'm still considering this patch. I've heard many times that we should trust the compiler to optimize for us and some folks look down on inlining in general. If anyone has an opinion on removing inlines from the common clk core then please do speak up. You should take a look at Chapter 15: The inline disease in Documentation/CodingStyle. 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
Re: [RFC PATCH 1/5] drivers : introduce device_path api
On Mon, 26 Nov 2012, Greg KH wrote: Ah, here's the root of your problem, right? You need a way for your hardware to tell the kernel that you have a regulator attached to a specific device? Using the device path and hard-coding it into the kernel is not the proper way to solve this, sorry. Use some other unique way to describe the hardware, surely the hardware designers couldn't have been that foolish not to provide this [1]? As far as I know, the kernel has no other way to describe devices. What about using partial matches? In this example, instead of doing a wildcard match against /platform/usbhs_omap/ehci-omap.0/usb* (which would fail if the platform part of the path changes), suppose the string ehci-omap.0/usb* could be associated with the usbhs_omap component somehow. Or even better, the string usb* could be associated with the ehci-omap.0 device. Then the path-matching code could restrict its attention to that part of the path and to devices below the specified one. Naming changes wouldn't be an issue, because the changes themselves would be made in the same source file that contains the partial path string. On the other hand, this may be way more general than we really need. For this particular case, all we need to do is take special action the first time any device is registered below the ehci-omap.0 platform device. There ought to be a more direct way to accomplish this, without using string pattern-matching or sysfs pathnames (and without adding overhead every time a device is added or deleted). I don't know if such an approach would be sufficiently general for future requirements, but it would solve the problem at hand. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] drivers : introduce device_path api
On Mon, Nov 26, 2012 at 04:07:38PM -0500, Alan Stern wrote: On Mon, 26 Nov 2012, Greg KH wrote: Ah, here's the root of your problem, right? You need a way for your hardware to tell the kernel that you have a regulator attached to a specific device? Using the device path and hard-coding it into the kernel is not the proper way to solve this, sorry. Use some other unique way to describe the hardware, surely the hardware designers couldn't have been that foolish not to provide this [1]? As far as I know, the kernel has no other way to describe devices. What about using partial matches? In this example, instead of doing a wildcard match against /platform/usbhs_omap/ehci-omap.0/usb* (which would fail if the platform part of the path changes), suppose the string ehci-omap.0/usb* could be associated with the usbhs_omap component somehow. Or even better, the string usb* could be associated with the ehci-omap.0 device. Yes, all you really care about here is the ehci-omap.0 device, so why even search for this, you know where the device is, you just created it :) Then the path-matching code could restrict its attention to that part of the path and to devices below the specified one. Naming changes wouldn't be an issue, because the changes themselves would be made in the same source file that contains the partial path string. On the other hand, this may be way more general than we really need. For this particular case, all we need to do is take special action the first time any device is registered below the ehci-omap.0 platform device. There ought to be a more direct way to accomplish this, without using string pattern-matching or sysfs pathnames (and without adding overhead every time a device is added or deleted). I don't know if such an approach would be sufficiently general for future requirements, but it would solve the problem at hand. And given that this is a very specific problem, and the changes are only needed for one piece of problem hardware, I suggest keeping the existing code that implements it. It's smaller, more specific to the exact platform, and we don't end up getting stuck with device paths to describe hardware that might change in the future in ways we do not anticipate (i.e. the platform change.) thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] drivers : introduce device_path api
On 11/27/2012 03:12 AM, the mail apparently from Alan Stern included: On Mon, 26 Nov 2012, Andy Green wrote: This adds a small optional API into drivers/base which deals with generating, matching and registration of wildcard device paths. From a struct device * you can generate a string like /platform/usbhs_omap/ehci-omap.0/usb1/1-1 which enapsulates the path of the device's connection to the board. These can be used to match up other assets, for example struct regulators, that have been registed elsewhere with a device instance that is probed asynchronously from the other board assets. If your device is on a bus, as it probably is, the device path will feature redundant bus indexes that do not contain information about the connectivity. For example if more than one driver can generate devices on the same bus, then the ordering of device probing will change the path, despite the connectivity remains the same. For that reason, to get a deterministic path for matching, wildcards are allowed. If your target device has the path /platform/usbhs_omap/ehci-omap.0/usb1/1-1 generated, in the asset you wish to match with it you can instead use /platform/usbhs_omap/ehci-omap.0/usb*/*-1 in order to only leave the useful, invariant parts of the path to match against. Have you considered limiting these wildcards in various useful ways? In this example, the wildcard must match a string of decimal digits. (Furthermore the two wildcard strings will always match each other, although it's probably not necessary to add this sort of constraint.) I don't know what sort of matches people will want in the future. Perhaps one for hex digits, or one for arbitrary text with the exception of a few characters (such as '/' but perhaps others too). To do what you want for now, the match should be restricted to digits. I'm not sure what we'd use that for... it doesn't seem the biggest problem we have at the moment ^^ To avoid having to adapt every kind of search by string api to also use the wildcards, the api takes the approach you can register your wildcard, and if a matching path is generated for a device, the wildcard itself is handed back as the device path instead. So if your board code or a (not yet done) DT binding registers this wildcard /platform/usbhs_omap/ehci-omap.0/usb* and the usb hub driver asks to generate its device path device_path_generate(dev, name, sizeof name); that is actually /platform/usbhs_omap/ehci-omap.0/usb1 then what will be returned is /platform/usbhs_omap/ehci-omap.0/usb* providing the same literal string for ehci-omap.0 hub no matter how many\ usb buses have been registered before. This wildcard string can then be matched to regulators or other string- searchable assets intended for the device on that hardware path. That's not how I would do it, at least, not for this application. I would register tuples containing a name, a pointer, and two callback routines. For example, (/platform/usbhs_omap/ehci-omap.0/usb*, omap_vhub_device, turn_on_regulator, turn_off_regulator) The when a device is registered whose path matches the string in such a tuple, the device core would know to invoke the first callback. The arguments would be a pointer to the device being registered and the pointer in the tuple. Similarly, the device core would invoke the second callback when the device is unregistered. There doesn't have to be anything in this scheme that's specific to hubs or even to USB. In particular, no changes to the hub driver would be needed. By just using paths, it's not restricted to regulators or binary operations on them but anything that needs a floating binding to another named kernel object can leverage it. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-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: [RFC PATCH 1/5] drivers : introduce device_path api
On 11/27/2012 03:16 AM, the mail apparently from Greg KH included: On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote: +struct device_path list; +DEFINE_MUTEX(lock); Those are some very descriptive global variables you just created :( I guess I can add the static if that will heal the emotional damage I caused. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-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: [RFC PATCH 1/5] drivers : introduce device_path api
On 11/27/2012 03:22 AM, the mail apparently from Greg KH included: On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote: This adds a small optional API into drivers/base which deals with generating, matching and registration of wildcard device paths. From a struct device * you can generate a string like /platform/usbhs_omap/ehci-omap.0/usb1/1-1 which enapsulates the path of the device's connection to the board. These can be used to match up other assets, for example struct regulators, that have been registed elsewhere with a device instance that is probed asynchronously from the other board assets. If your device is on a bus, as it probably is, the device path will feature redundant bus indexes that do not contain information about the connectivity. Huh? A bus index does show the connectivity, well, one type of connectivity, but perhaps it's not the one _you_ happen to want at the moment. Which is fine, but I don't see why you want to try to figure this out using the device path in the first place, surely you have some other way that the hardware can describe itself to the kernel as to where it needs to be hooked up to? The bus index is like a counter, it shows logical connectivity inside Linux that isn't repeatable and doesn't reflect hardware routing information directly. For example if more than one driver can generate devices on the same bus, then the ordering of device probing will change the path, despite the connectivity remains the same. That's an expected thing, I don't see the issue here. Alan brought up in a thread here the last days, wouldn't it be nice if we could arbitrarily bind regulators to asynchronously probed objects, and after discussion proposed this wildcard matching scheme to mask these generated bus numbers. For that reason, to get a deterministic path for matching, wildcards are allowed. If your target device has the path Wait, no, why would you want a deterministic path and have that hard-coded into the kernel here? You can't rely on that any more than userspace can, so let's not start making the mistake that lots of userspace programmers originally did when they started using sysfs please. We have learned from our past mistakes. I guess that is a fair point. I was going to say that it's no different than using any kernel API in code, which history proves is very mutable; people deal with it by changing the usages as they change the API definition. But it's complicated a bit by DTs meant to be more stable and these paths would turn up in the DT. In platform case though, a heuristic that leaving off the initial / and allowing matches anywhere along the path then to the end would get around it. /platform/usbhs_omap/ehci-omap.0/usb1/1-1 generated, in the asset you wish to match with it you can instead use /platform/usbhs_omap/ehci-omap.0/usb*/*-1 in order to only leave the useful, invariant parts of the path to match against. To avoid having to adapt every kind of search by string api to also use the wildcards, the api takes the approach you can register your wildcard, and if a matching path is generated for a device, the wildcard itself is handed back as the device path instead. So if your board code or a (not yet done) DT binding registers this wildcard /platform/usbhs_omap/ehci-omap.0/usb* Device tree lists sysfs paths in it's descriptions? That's news to me. It does not say that... and the usb hub driver asks to generate its device path device_path_generate(dev, name, sizeof name); that is actually /platform/usbhs_omap/ehci-omap.0/usb1 then what will be returned is /platform/usbhs_omap/ehci-omap.0/usb* providing the same literal string for ehci-omap.0 hub no matter how many\ usb buses have been registered before. This wildcard string can then be matched to regulators or other string- searchable assets intended for the device on that hardware path. Ah, here's the root of your problem, right? You need a way for your hardware to tell the kernel that you have a regulator attached to a specific device? Using the device path and hard-coding it into the kernel is not the proper way to solve this, sorry. Use some other unique way to describe the hardware, surely the hardware designers couldn't have been that foolish not to provide this [1]? thanks, greg k-h [1] Yeah, I know I'm being hopeful here, and probably wrong, but then you need to push back. We are not helpless here. Specific hardware information is something that's kept hidden away and private in the driver for good reasons. We could add elective, additional information at the driver for every physical interface it represented and match that way. But I am not sure the effort involved is repaid by the relatively few instances that need what is basically asynchronously probed platform_data. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro
Re: [RFC PATCH 1/5] drivers : introduce device_path api
On 11/27/2012 05:07 AM, the mail apparently from Alan Stern included: On Mon, 26 Nov 2012, Greg KH wrote: Ah, here's the root of your problem, right? You need a way for your hardware to tell the kernel that you have a regulator attached to a specific device? Using the device path and hard-coding it into the kernel is not the proper way to solve this, sorry. Use some other unique way to describe the hardware, surely the hardware designers couldn't have been that foolish not to provide this [1]? As far as I know, the kernel has no other way to describe devices. What about using partial matches? In this example, instead of doing a wildcard match against /platform/usbhs_omap/ehci-omap.0/usb* (which would fail if the platform part of the path changes), suppose the string ehci-omap.0/usb* could be associated with the usbhs_omap component somehow. Or even better, the string usb* could be associated with the ehci-omap.0 device. Then the path-matching code could restrict its attention to that part of the path and to devices below the specified one. Naming changes wouldn't be an issue, because the changes themselves would be made in the same source file that contains the partial path string. Yes just dropping the starting / on the match and allowing a fragment to match further up the string would solve it. ehci-omap.0 won't appear down any other earlier device paths than the right one. On the other hand, this may be way more general than we really need. For this particular case, all we need to do is take special action the first time any device is registered below the ehci-omap.0 platform device. There ought to be a more direct way to accomplish this, without using string pattern-matching or sysfs pathnames (and without adding overhead every time a device is added or deleted). There are no sysfs pathnames involved here at all. Greg invented that. I don't know if such an approach would be sufficiently general for future requirements, but it would solve the problem at hand. We can get a notification about device creation and do things there. But the cost of that is like the tuple suggestion, they'll only be able to do a fixed thing like operate on regulators. Actually the targeted device may have arbitrary associated assets like generic GPIO to turn on a flash for built-in webcam controlled out-of-band. These also can be reached by known names. And the driver may wish to do things with them that are more complex than enable / disable or follow logical lifecycle of the hub or whatever. However when the guidance from Greg is that we can do nothing except complain at hardware designers for some reason I failed to quite identify, I fear we are moving deckchairs on the titanic. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-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: [RFC PATCH 4/5] omap4: panda: add smsc95xx regulator and reset dependent on root hub
On 11/27/2012 12:20 AM, the mail apparently from Roger Quadros included:
Hi Andy,
On 11/26/2012 02:45 PM, Andy Green wrote:
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
Without power control, the ULPI PHY + SMSC9614 on the Panda eats 700-900mW
all the time, which is around the same as the idle power of the SoC and
rest of the board.
This allows us to start off with it depowered, and only power it if the
ehci-hcd module is inserted. When the module is removed, it's depowered
again.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/Kconfig|1
arch/arm/mach-omap2/board-omap4panda.c | 90 +---
2 files changed, 72 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index d669e22..5105109 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -368,6 +368,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select USB_HUB_DEVICE_PATH_REGULATOR
config OMAP3_EMU
bool OMAP3 debugging peripherals
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..b032b6b 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -154,11 +154,6 @@ static const struct usbhs_omap_board_data usbhs_bdata
__initconst = {
.reset_gpio_port[2] = -EINVAL
};
-static struct gpio panda_ehci_gpios[] __initdata = {
- { GPIO_HUB_POWER, GPIOF_OUT_INIT_LOW, hub_power },
- { GPIO_HUB_NRESET, GPIOF_OUT_INIT_LOW, hub_nreset },
-};
-
static void __init omap4_ehci_init(void)
{
int ret;
@@ -173,23 +168,76 @@ static void __init omap4_ehci_init(void)
clk_set_rate(phy_ref_clk, 1920);
clk_prepare_enable(phy_ref_clk);
- /* disable the power to the usb hub prior to init and reset phy+hub */
- ret = gpio_request_array(panda_ehci_gpios,
-ARRAY_SIZE(panda_ehci_gpios));
- if (ret) {
- pr_err(Unable to initialize EHCI power/reset\n);
- return;
- }
+ usbhs_init(usbhs_bdata);
+}
- gpio_export(GPIO_HUB_POWER, 0);
- gpio_export(GPIO_HUB_NRESET, 0);
- gpio_set_value(GPIO_HUB_NRESET, 1);
+/*
+ * hub_nreset also resets the ULPI PHY and is required after powering SMSC chip
+ * ULPI PHY is always powered... need to do reset once for both once
+ * hub_power enables a 3.3V regulator for (hub + eth) chip
+ * however there's no point having ULPI PHY in use alone
+ * since it's only connected to the (hub + eth) chip
+ */
- usbhs_init(usbhs_bdata);
+static struct regulator_init_data panda_hub = {
+ .constraints = {
+ .name = vhub,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+};
- /* enable power to hub */
- gpio_set_value(GPIO_HUB_POWER, 1);
-}
+static struct fixed_voltage_config panda_vhub = {
+ .supply_name = vhub,
+ .microvolts = 330,
+ .gpio = GPIO_HUB_POWER,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = panda_hub,
+};
+
+static struct platform_device omap_vhub_device = {
+ .name = reg-fixed-voltage,
+ .id = 2,
+ .dev = {
+ .platform_data = panda_vhub,
+ },
+};
+
+static struct regulator_init_data panda_ulpireset = {
+ /*
+* idea is that when operating ulpireset, regulator api will make
+* sure that the hub+eth chip is powered, since it's the parent
+*/
+ .supply_regulator = vhub, /* we are a child of vhub */
+ .constraints = {
+ /*
+* this magic string associates us with ehci-omap.0 root hub
+* when the root hub logical device is up, we will power
+* and reset [ ULPI PHY + [ HUB + ETH ] ]
+*/
+ .name = /platform/usbhs_omap/ehci-omap.0/usb*,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct fixed_voltage_config panda_vulpireset = {
+ .supply_name = /platform/usbhs_omap/ehci-omap.0/usb*,
Does this supply_name really needs to be the magic string?
I believe that's how the two regulators bind together in the
parent-child relationship.
Having the literal twice is bad I agree... it could be moved to a const
char * earlier and referenced as that.
-Andy
+ .microvolts = 330,
+ .gpio = GPIO_HUB_NRESET,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = panda_ulpireset,
+};
+
+static struct platform_device omap_vulpireset_device = {
+ .name = reg-fixed-voltage,
+ .id
[PATCH v2] OMAP2+: mux: Fixed gpio mux mode analysis.
From: Oleg Matcovschi oleg.matcovs...@ti.com
OMAP_MODE_GPIO() macro verified only OMAP_MUX_MODE4.
It is not correct for following platforms:
2430 - gpio mux mode 3
44xx - gpio mux mode 3
54xx - gpio mux mode 6
Patch reserves first 3 bits in partition flags for storing gpio mux
mode in same format as stored in control pad register.
Modified OMAP_MODE_GPIO() macro to handle all possible cases of gpio mux mode.
Modified omap_mux_init() flags of omap34xx to include OMAP_MUX_GPIO_IN_MODE4.
Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com
---
arch/arm/mach-omap2/mux.c | 10 --
arch/arm/mach-omap2/mux.h | 20 +++-
arch/arm/mach-omap2/mux34xx.c |2 +-
3 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 701e17c..1fa39dc 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -134,10 +134,7 @@ static int __init _omap_mux_init_gpio(struct
omap_mux_partition *partition,
old_mode = omap_mux_read(partition, gpio_mux-reg_offset);
mux_mode = val ~(OMAP_MUX_NR_MODES - 1);
- if (partition-flags OMAP_MUX_GPIO_IN_MODE3)
- mux_mode |= OMAP_MUX_MODE3;
- else
- mux_mode |= OMAP_MUX_MODE4;
+ mux_mode |= partition-gpio;
pr_debug(%s: Setting signal %s.gpio%i 0x%04x - 0x%04x\n, __func__,
gpio_mux-muxnames[0], gpio, old_mode, mux_mode);
omap_mux_write(partition, mux_mode, gpio_mux-reg_offset);
@@ -799,7 +796,7 @@ int __init omap_mux_late_init(void)
struct omap_mux *m = e-mux;
u16 mode = omap_mux_read(partition, m-reg_offset);
- if (OMAP_MODE_GPIO(mode))
+ if (OMAP_MODE_GPIO(partition, mode))
continue;
#ifndef CONFIG_DEBUG_FS
@@ -1064,7 +1061,7 @@ static void __init omap_mux_init_list(struct
omap_mux_partition *partition,
}
#else
/* Skip pins that are not muxed as GPIO by bootloader */
- if (!OMAP_MODE_GPIO(omap_mux_read(partition,
+ if (!OMAP_MODE_GPIO(partition, omap_mux_read(partition,
superset-reg_offset))) {
superset++;
continue;
@@ -1131,6 +1128,7 @@ int __init omap_mux_init(const char *name, u32 flags,
partition-name = name;
partition-flags = flags;
+ partition-gpio = flags OMAP_MUX_MODE7;
partition-size = mux_size;
partition-phys = mux_pbase;
partition-base = ioremap(mux_pbase, mux_size);
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 76f9b3c..5504e12 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -58,7 +58,8 @@
#define OMAP_PIN_OFF_INPUT_PULLDOWN(OMAP_OFF_EN | OMAP_OFF_PULL_EN)
#define OMAP_PIN_OFF_WAKEUPENABLE OMAP_WAKEUP_EN
-#define OMAP_MODE_GPIO(x) (((x) OMAP_MUX_MODE7) == OMAP_MUX_MODE4)
+#define OMAP_MODE_GPIO(partition, x) (((x) OMAP_MUX_MODE7) == \
+ partition-gpio)
#define OMAP_MODE_UART(x) (((x) OMAP_MUX_MODE7) == OMAP_MUX_MODE0)
/* Flags for omapX_mux_init */
@@ -79,13 +80,20 @@
/*
* omap_mux_init flags definition:
*
+ * OMAP_GPIO_MUX_MODE, bits 0-2: gpio muxing mode, same like pad control
+ * register which includes values from 0-7.
* OMAP_MUX_REG_8BIT: Ensure that access to padconf is done in 8 bits.
* The default value is 16 bits.
- * OMAP_MUX_GPIO_IN_MODE3: The GPIO is selected in mode3.
- * The default is mode4.
*/
-#define OMAP_MUX_REG_8BIT (1 0)
-#define OMAP_MUX_GPIO_IN_MODE3 (1 1)
+#define OMAP_MUX_GPIO_IN_MODE0 OMAP_MUX_MODE0
+#define OMAP_MUX_GPIO_IN_MODE1 OMAP_MUX_MODE1
+#define OMAP_MUX_GPIO_IN_MODE2 OMAP_MUX_MODE2
+#define OMAP_MUX_GPIO_IN_MODE3 OMAP_MUX_MODE3
+#define OMAP_MUX_GPIO_IN_MODE4 OMAP_MUX_MODE4
+#define OMAP_MUX_GPIO_IN_MODE5 OMAP_MUX_MODE5
+#define OMAP_MUX_GPIO_IN_MODE6 OMAP_MUX_MODE6
+#define OMAP_MUX_GPIO_IN_MODE7 OMAP_MUX_MODE7
+#define OMAP_MUX_REG_8BIT (1 3)
/**
* struct omap_board_data - board specific device data
@@ -105,6 +113,7 @@ struct omap_board_data {
* struct mux_partition - contain partition related information
* @name: name of the current partition
* @flags: flags specific to this partition
+ * @gpio: gpio mux mode
* @phys: physical address
* @size: partition size
* @base: virtual address after ioremap
@@ -114,6 +123,7 @@ struct omap_board_data {
struct omap_mux_partition {
const char *name;
u32 flags;
+ u32 gpio;
u32 phys;
u32 size;
void __iomem*base;
diff --git a/arch/arm/mach-omap2/mux34xx.c
[GIT PULL 1/3] omap late timer clean-up (and a warning fix) for v3.8 merge window
The following changes since commit 9dc57643738f9fbe45c10cc062903d5dfda5bdd9: Merge branch 'fixes-timer' of github.com:jonhunter/linux into omap-for-v3.8/timer (2012-11-13 13:52:38 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8/cleanup-timer-signed for you to fetch changes up to 26f01998b0657a61167a819f1c37cb9f9e9d674b: ARM: OMAP3: cm-t3517: use GPTIMER for system clock (2012-11-21 10:20:43 -0800) Timer clean-up to get us closer to moving timer code to drivers, and to get rid of CONFIG_OMAP_32K_TIMER and rely on the board or devicetree provided timer configuration. Note that these changes are on top of the recent timer fixes. Igor Grinberg (2): ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER ARM: OMAP3: cm-t3517: use GPTIMER for system clock Jon Hunter (8): ARM: OMAP: Clean-up dmtimer reset code ARM: OMAP: Define omap_dm_timer_prepare function as static ARM: OMAP: Don't store timers physical address ARM: OMAP2+: Remove unnecessary local variable in timer code ARM: OMAP: Remove unnecessary omap_dm_timer structure declaration ARM: OMAP: Add platform data header for DMTIMERs ARM: OMAP: Remove unnecessary inclusion of dmtimer.h ARM: OMAP2+: Fix compiler warning for 32k timer Tony Lindgren (1): Merge branch 'cleanup-timer' of git://github.com/jonhunter/linux into omap-for-v3.8/timer arch/arm/mach-omap1/timer.c| 1 + arch/arm/mach-omap1/timer32k.c | 1 - arch/arm/mach-omap2/board-cm-t3517.c | 2 +- arch/arm/mach-omap2/common.h | 1 + arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 - arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 - arch/arm/mach-omap2/pm-debug.c | 1 - arch/arm/mach-omap2/timer.c| 167 + arch/arm/plat-omap/Kconfig | 6 ++ arch/arm/plat-omap/dmtimer.c | 54 ++ arch/arm/plat-omap/include/plat/dmtimer.h | 80 -- drivers/staging/tidspbridge/core/ue_deh.c | 1 - include/linux/platform_data/dmtimer-omap.h | 31 ++ 13 files changed, 168 insertions(+), 179 deletions(-) create mode 100644 include/linux/platform_data/dmtimer-omap.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP build now completely broken in latest arm-soc
* Olof Johansson o...@lixom.net [121125 05:59]: On Sun, Nov 25, 2012 at 1:37 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: But also, the: arch/arm/mach-omap2/timer.c:163:28: warning: 'omap_counter_match' defined but not used warning is still there. There's a fix for this in Tony's tree, but he hasn't sent up the pull request for it yet. Sent a pull request for that as omap late timer clean-up (and a warning fix) for v3.8 merge window. The fix is there there as the topmost third patch, but that probably does not matter in this case as the regression was introduced in the patches queued. Let me know if you want it separately though. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] ARM: OMAP2+: omap2plus_defconfig: enable twl4030 SoC audio
Many TI OMAP SoC based boards that uses twl4030 as codec have been updated to use the unified audio driver (omap-twl4030) since they have similar audio setup. So, is good to have it built to add audio support to these boards. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/configs/omap2plus_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 7c6cbdf..022212c 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -172,6 +172,7 @@ CONFIG_SND_DEBUG=y CONFIG_SND_USB_AUDIO=m CONFIG_SND_SOC=m CONFIG_SND_OMAP_SOC=m +CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m CONFIG_USB=y CONFIG_USB_DEBUG=y -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] drivers : introduce device_path api
On Tue, Nov 27, 2012 at 5:07 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 26 Nov 2012, Greg KH wrote: Ah, here's the root of your problem, right? You need a way for your hardware to tell the kernel that you have a regulator attached to a specific device? Using the device path and hard-coding it into the kernel is not the proper way to solve this, sorry. Use some other unique way to describe the hardware, surely the hardware designers couldn't have been that foolish not to provide this [1]? As far as I know, the kernel has no other way to describe devices. What about using partial matches? In this example, instead of doing a wildcard match against /platform/usbhs_omap/ehci-omap.0/usb* IMO, all matches mean the devices are inside the ehci-omap bus, so the direct/simple way is to enable/disable the regulators in the probe() and remove() of ehci-omap controller driver. On the other side, both the two LAN95xx USB devices(hub + ethernet) are simple self-powered device. Just like other self-powered devices, the power should be provided from external world, instead of hub driver itself. And it is doable to power on the devices before creating the specific ehci-omap usb bus inside ehci-omap driver. Thanks, -- Ming Lei -- 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] Input: omap4-keypad: Remove the OMAP4_KBD_SYSCONFIG and OMAP4_KBD_SYSSTATUS
On Mon, Nov 26, 2012 at 11:31 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Mon, Nov 26, 2012 at 04:21:19PM +0530, Shubhrajyoti D wrote: The macros OMAP4_KBD_SYSSTATUS and OMAP4_KBD_SYSSTATUS are not used so remove them. They document the existing registers and do not add bloat to the generated objects so let's leave them be. The objective of the patch is not to prevent bloat. Actually these registers have power/system impact so it was decided that the drivers will not configure the sysc registers (infact not define). Currently hwmod configures the registers. To be safe I thought of deleting it. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 03/10] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
On Mon, Nov 26, 2012 at 16:37:36, Bedia, Vaibhav wrote: Hi Benoit, On Mon, Nov 26, 2012 at 14:32:59, Cousson, Benoit wrote: Hi Vaibhav, On 11/26/2012 06:19 AM, Bedia, Vaibhav wrote: On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote: On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote: As part of PWM subsystem integration, PWM subsystem are sharing resources like clock across submodules (ECAP, EQEP EHRPWM). To handle resource sharing IP integration 1. Rework on parent child relation between PWMSS and ECAP, EQEP EHRPWM child devices to support runtime PM. 2. Add support for opt_clks in EHRPWM HWMOD entry to handle additional clock gating from control module. 3. Add HWMOD entries for EQEP PWM submodule. Is there any review on this patch? This patch depends on ECAP EHRPWM to work in am335x. First of all, I think you should break up this patch as per the 3 points that you mentioned above. I will split the patches into 2. 1. One for correcting hwmod entries plus adding EQEP HWMOD entry 2. Adding parent child relation in hwmod entry. The usage of opt_clks for this does not look right to me. Based on your description this clock is necessary and not optional on AM335x and on Davinci platforms this clock does not exist. I checked the DA830 TRM and looks like TBCLK for eHRPWM is an always on clock there. So, the only difference in AM335x is an additional enable bit. Instead of adding this as opt_clk in hwmod, we could add an always on clock node in Davinci clock data and have the driver always do a clk_enable() on the tbclk as part of the probe sequence. On AM335x, with the right clock node this will enable the clock in hardware and on DA830 it turns into a NOP. This way we can avoid adding the opt_clk entry in hwmod of eHRPWM. I will remove opt_clk in HWMOD and made tbclk is a mandatory clock in EHRPWM driver. Thanks Avinash -- 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
