Re: [PATCH] gpio: New driver for GPO emulation using PWM generators
On Thu, 22 Nov 2012 14:42:03 +0100, Peter Ujfalusi peter.ujfal...@ti.com wrote: There seams to be board designs using PWM generators as enable/disable signals. For these boards we used to have custom code as hacks to deal with such a situations. With the gpio-pwm driver we can emulate the GPIO functionality using PWM generators via standard interfaces. The PWM will be configured to be off when the GPIO is off and to full duty cycle when the GPIO is requested to be on. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi Linus, So this is the driver I came up regarding to the issue that some boards (BeagleBoard for example) are using the PWM generators as enable/disable signal. On BeagleBoard the situation is like this: TWL4030 PWMA - TWL4030 LEDA - nUSBHOST_PWR_EN - external power switch - USB host hub power. So I have tested this driver on BeagleBoard: - Custom code to toggle the GPIO just to see if it switches correctly - Real life usecase: fixed voltage regulator with GPIO control (the gpio is the gpio-pwm provided). ehci-omap has been modified to allow deferred probe. the regulator is used by ehci-omap. All works fine. 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. g. -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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: dts: am335x-evmsk: Add cpsw phy_id
Add phy id for CPSW
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
The patch is verified with CPSW patches present in the following git repo
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
arch/arm/boot/dts/am335x-evmsk.dts |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 6f53879..c629086 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -164,3 +164,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = davinci_mdio, 0;
+};
+
+cpsw_emac1 {
+ phy_id = davinci_mdio, 1;
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap DSS fails with tft410 driver panel?
On 2012-11-23 08:14, Steve Sakoman wrote:
On Thu, Nov 22, 2012 at 12:47 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
I'll add the printk's to omapfb_setup_plane() that were requested by
Tomi and report back.
Today was a holiday, so family obligations didn't allow much time to
look at this.
I did however do a quick build with some printk's in
omapfb_setup_plane() so I could narrow down where to start looking.
I discovered that the error (omapdss OVERLAY error: check_overlay:
paddr cannot be 0) is happening as a result of the
ovl-set_overlay_info() call in the else clause of the code below:
if (pi-enabled) {
r = omapfb_setup_overlay(fbi, ovl, pi-pos_x, pi-pos_y,
pi-out_width, pi-out_height);
if (r) {
printk(omapfb_setup_plane: pi-enabled
omapfb_setup_overlay()\n);
goto undo;
}
} else {
struct omap_overlay_info info;
ovl-get_overlay_info(ovl, info);
info.pos_x = pi-pos_x;
info.pos_y = pi-pos_y;
info.out_width = pi-out_width;
info.out_height = pi-out_height;
r = ovl-set_overlay_info(ovl, info);
if (r) {
printk(omapfb_setup_plane: !pi-enabled
ovl-set_overlay_info failed\n);
goto undo;
}
}
Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you
put a printk at dss/apply.c:dss_olv_set_info, and print ovl-id and
info-paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at
the point where it sets info.paddr, as I think that's the only place
where omapfb sets paddr.
I don't know what's going on there, why the paddr is suddenly zero.
Looking at the log from Enric, SETUP_PLANE works fine just fine, and
then, for no reason, next SETUP_PLANE fails, and the log doesn't show
anything much happening between.
However, I think omapdss may have been more permissive in the past,
allowing paddr 0 if the overlay is disabled. I could add that back, but
I'd rather first understand what's happening here.
I'll look at this more over as I get time over the coming days.
How can I reproduce this? Is there a downloadable rootfs somewhere that
I could try?
The only downloadable rootfs I have is 3.5 based. I'll try to get a
3.6 image posted in the next couple of days.
Could you also copy full kernel boot log to pastebin or such?
OK, will do that with my next build. I'll assume you want dss
debugging enabled for that.
That's probably not needed. I mostly wanted to know if there's some dss
error/warning seen on the boot. But probably not if the problem happens
in the code above.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] gpio: New driver for GPO emulation using PWM generators
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;
};
led_user {
compatible = pwm-leds;
pwms = twl_pwmled 1 7812500; /* PWMB/LEDB from twl4030 */
pwm-names = PMU_STAT LED;
label = beagleboard::pmu_stat;
max-brightness = 127;
};
vdd_usbhost: fixedregulator-vdd-usbhost {
compatible = regulator-fixed;
regulator-name = USBHOST_POWER;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
gpio = twl_pwmled 0 7812500; /* PWMA/LEDA from twl4030 */
enable-active-high;
regulator-boot-on;
};
With this I think this is what should happen in code level:
- the pwm-gpo driver does not have of_match_table at all.
- the driver for the ti,twl4030-pwmled is loaded.
- it prepares and calls pwmchip_add() to add the PWM chip.
- the of_pwmchip_add() will look for gpio-controller property of the node
- if it is found it prepares the pdata (based on the PWM chip information)
for the pwm-gpo driver and registers the platform_device for it.
- the pwm-gpo driver will use:
priv-gpio_chip.of_node = pdev-dev.parent-of_node;
In DT boot we are fine with this I think.
When it comes to legacy boot (boot without DT) I think we should still have
the two layers to avoid big changes which would affect all existing pwm
drivers. Something like this in the board files:
static struct pwm_lookup pwm_lookup[] = {
/* LEDA - nUSBHOST_PWR_EN */
PWM_LOOKUP(twl-pwmled, 0, pwm-gpo, nUSBHOST_PWR_EN),
/* LEDB - PMU_STAT */
PWM_LOOKUP(twl-pwmled, 1, leds_pwm, beagleboard::pmu_stat),
};
/* for the LED user of PWM */
static struct led_pwm pwm_leds[] = {
{
.name = beagleboard::pmu_stat,
.max_brightness = 127,
.pwm_period_ns = 7812500,
},
};
static struct led_pwm_platform_data pwm_data = {
.num_leds = ARRAY_SIZE(pwm_leds),
.leds = pwm_leds,
};
static struct platform_device leds_pwm = {
.name = leds_pwm,
.id = -1,
.dev= {
.platform_data = pwm_data,
},
};
/* for the GPIO user of PWM */
static struct gpio_pwm pwm_gpios[] = {
{
.name = nUSBHOST_PWR_EN,
.pwm_period_ns = 7812500,
},
};
static struct gpio_pwm_pdata pwm_gpio_data = {
.num_gpos = ARRAY_SIZE(pwm_gpios),
.gpos = pwm_gpios,
.setup = beagle_pwm_gpio_setup, /*to get the gpio base */
};
static struct platform_device gpos_pwm = {
.name = pwm-gpo,
.id = -1,
.dev= {
.platform_data = pwm_gpio_data,
},
};
static int beagle_pwm_gpio_setup(struct device *dev, unsigned gpio,
unsigned ngpio)
{
beagle_usbhub_pdata.gpio = gpio; /* fixed_voltage_config struct */
platform_device_register(beagle_usbhub);
return 0;
}
What do you think?
--
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: OMAP4430 produces boot warnings
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. -Tero -- 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 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.
--
Péter
led_user {
compatible = pwm-leds;
pwms = twl_pwmled 1 7812500; /* PWMB/LEDB from twl4030 */
pwm-names = PMU_STAT LED;
label = beagleboard::pmu_stat;
max-brightness = 127;
};
vdd_usbhost: fixedregulator-vdd-usbhost {
compatible = regulator-fixed;
regulator-name = USBHOST_POWER;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
gpio = twl_pwmled 0 7812500; /* PWMA/LEDA from twl4030 */
enable-active-high;
regulator-boot-on;
};
With this I think this is what should happen in code level:
- the pwm-gpo driver does not have of_match_table at all.
- the driver for the ti,twl4030-pwmled is loaded.
- it prepares and calls pwmchip_add() to add the PWM chip.
- the of_pwmchip_add() will look for gpio-controller property of the node
- if it is found it prepares the pdata (based on the PWM chip information)
for the pwm-gpo driver and registers the platform_device for it.
- the pwm-gpo driver will use:
priv-gpio_chip.of_node = pdev-dev.parent-of_node;
In DT boot we are fine with this I think.
When it comes to legacy boot (boot without DT) I think we should still have
the two layers to avoid big changes which would affect all existing pwm
drivers. Something like this in the board files:
static struct pwm_lookup pwm_lookup[] = {
/* LEDA - nUSBHOST_PWR_EN */
PWM_LOOKUP(twl-pwmled, 0, pwm-gpo, nUSBHOST_PWR_EN),
/* LEDB - PMU_STAT */
PWM_LOOKUP(twl-pwmled, 1, leds_pwm, beagleboard::pmu_stat),
};
/* for the LED user of PWM */
static struct led_pwm pwm_leds[] = {
{
.name = beagleboard::pmu_stat,
.max_brightness = 127,
.pwm_period_ns = 7812500,
},
};
static struct led_pwm_platform_data pwm_data = {
.num_leds = ARRAY_SIZE(pwm_leds),
.leds = pwm_leds,
};
static struct platform_device leds_pwm = {
.name = leds_pwm,
.id = -1,
.dev= {
.platform_data = pwm_data,
},
};
/* for the GPIO user of PWM */
static struct gpio_pwm pwm_gpios[] = {
{
.name = nUSBHOST_PWR_EN,
.pwm_period_ns = 7812500,
},
};
static struct gpio_pwm_pdata pwm_gpio_data = {
.num_gpos = ARRAY_SIZE(pwm_gpios),
.gpos = pwm_gpios,
.setup = beagle_pwm_gpio_setup, /*to get the gpio base */
};
static struct platform_device gpos_pwm = {
.name = pwm-gpo,
.id = -1,
.dev= {
.platform_data = pwm_gpio_data,
},
};
static int beagle_pwm_gpio_setup(struct device *dev, unsigned gpio,
unsigned ngpio)
{
beagle_usbhub_pdata.gpio = gpio; /* fixed_voltage_config struct */
platform_device_register(beagle_usbhub);
return 0;
}
What do you think?
--
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
Hi Thierry, On 11/20/2012 12:58 PM, Thierry Reding wrote: Oh, I missed to save the updated comment before I commited the change. Can I just send and update patch instead of the whole series again? Sure. Sorry for taking so long to review this. I'm rather busy with other things but I'll try to find some time to review properly tonight or tomorrow. I have sent the update patch for the series: https://lkml.org/lkml/2012/11/20/268 I know you are busy, but would you be able to take a look at the series? 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
Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
On 11/22/2012 06:12 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 22, 2012 at 05:00:45PM +0200, Roger Quadros wrote:
On 11/22/2012 03:56 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 22, 2012 at 09:49:05PM +0800, Andy Green wrote:
Again it sounds like something that should be done at the hub driver
level. I mean using the GPIO (for reset) and Power Regulator.
not implementing the regulator part itself, but using it.
If you mean change the regulator managing code from living in
omap-hsusb to ehci-hcd, it sounds like a good idea.
I mean that drivers/usb/core/hub.c should manage it, since that's what
actually manages the HUB entity.
Yes. I agree that powering up the on-board hubs should be done
generically and not in ehci-omap.c. I'm not sure how it can be done in
hub.c.
I'm assuming that such problem is limited to root hub ports where system
an external LAN95xx HUB is not the roothub. LAN95xx is connected to the
roothub.
I didn't say LAN95xx is the root hub. It is connected to the root hub.
So it is in theory, the root hub port's responsibility to power the LAN95xx.
designers have the flexibility to provide power to the peripherals
outside the USB Hub specification.
I can think of two solutions
1) Associate the regulators with the root hub _ports_ and enable them as
part of port's power-up routine.
doesn't make sense. We need to figure out a way to attach the regulator
to the ports which actually have them. In this case it's the external
LAN95xx, right ?
I think you are confused here. The LAN95xx's ports are compatible with
USB hub specification and they work using the in-band set_port_feature
mechanism already. We have a problem powering the LAN95xx itself which
ideally should have been powered with set_port_feature on the root hub.
(or ehci_port_power() in this case).
2) Have a global list of regulators that are registered by platform code
and enabled them all at once on hcd init.
also wrong as it might cause increased power consumption even when only
a single USB port is currently in use.
Yes that is true. I'm not for (2) certainly.
The patch below is *CLEARLY WRONG* it's just to illustrate how this
could be started:
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 1af04bd..662d4cf 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
@@ -44,6 +45,7 @@ struct usb_port {
struct device dev;
struct dev_state *port_owner;
enum usb_port_connect_type connect_type;
+ struct regulator *port_regulator;
};
struct usb_hub {
@@ -847,8 +849,41 @@ static unsigned hub_power_on(struct usb_hub *hub, bool
do_delay)
else
dev_dbg(hub-intfdev, trying to enable port power on
non-switchable hub\n);
- for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++)
+ for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++) {
+ regulator_enable(hub-ports[port1]-port_regulator);
set_port_feature(hub-hdev, port1, USB_PORT_FEAT_POWER);
+ }
+
+ /* Wait at least 100 msec for power to become stable */
+ delay = max(pgood_delay, (unsigned) 100);
+ if (do_delay)
+ msleep(delay);
+ return delay;
+}
+
+static unsigned hub_power_off(struct usb_hub *hub, bool do_delay)
+{
+ int port1;
+ unsigned pgood_delay = hub-descriptor-bPwrOn2PwrGood * 2;
+ unsigned delay;
+ u16 wHubCharacteristics =
+ le16_to_cpu(hub-descriptor-wHubCharacteristics);
+
+ /* Disable power on each port. Some hubs have reserved values
+ * of LPSM ( 2) in their descriptors, even though they are
+ * USB 2.0 hubs. Some hubs do not implement port-power switching
+ * but only emulate it. In all cases, the ports won't work
+ * unless we send these messages to the hub.
+ */
+ if ((wHubCharacteristics HUB_CHAR_LPSM) 2)
+ dev_dbg(hub-intfdev, disabling power on all ports\n);
+ else
+ dev_dbg(hub-intfdev, trying to disable port power on
+ non-switchable hub\n);
+ for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++) {
+ regulator_disable(hub-ports[port1]-port_regulator);
+ clear_port_feature(hub-hdev, port1, USB_PORT_FEAT_POWER);
+ }
/* Wait at least 100 msec for power to become stable */
delay = max(pgood_delay, (unsigned) 100);
@@ -1336,6 +1371,9 @@ static int hub_configure(struct usb_hub *hub,
goto fail;
}
+ if (hub-has_external_port_regulator) /* maybe implement with a quirk
flag ??? */
+ regulator_get(hub_dev, hub_port_supply\n);
+
wHubCharacteristics =
RE: [PATCH v4 01/11] PWMSS: Add PWM Subsystem driver for parent-child relationship
On Fri, Nov 23, 2012 at 02:17:04, Thierry Reding wrote:
On Wed, Nov 21, 2012 at 06:40:58PM +0530, Philip, Avinash wrote:
[...]
+static const struct of_device_id pwmss_of_match[] = {
+ {
+ .compatible = ti,am33xx-pwmss,
+ },
For consistency with other drivers this should be all on one line.
Ok I will correct it.
+static const struct dev_pm_ops pwmss_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pwmss_suspend, pwmss_resume)
+};
This could be even shorter:
static SIMPLE_DEV_PM_OPS(pwmss_pm_ops, pwmss_suspend, pwmss_resume);
Ok I will correct it.
Thanks
Avinash
Thierry
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 04/11] pwm: pwm-tiecap: Add device-tree binding support for APWM driver
On Fri, Nov 23, 2012 at 02:27:33, Thierry Reding wrote:
On Wed, Nov 21, 2012 at 06:41:01PM +0530, Philip, Avinash wrote:
[...]
+static const struct of_device_id ecap_of_match[] = {
+ {
+ .compatible = ti,am33xx-ecap,
+ },
Same here, can be shorter by putting it on one line instead of three.
I will correct it
Thanks
Avinash
Thierry
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 05/11] pwm: pwm-tiecap: pinctrl support
On Fri, Nov 23, 2012 at 02:29:44, Thierry Reding wrote: On Wed, Nov 21, 2012 at 06:41:02PM +0530, Philip, Avinash wrote: [...] + pinctrl = devm_pinctrl_get_select_default(pdev-dev); + if (IS_ERR(pinctrl)) + dev_warn(pdev-dev, failed to configure pins from driver\n); I think we already discussed this, but shouldn't this be a fatal error? I had checked relevant discussion and found this can be warning message. This is because most boards don't have pinctrl implemented at this point, or may never have. https://lkml.org/lkml/2012/9/11/369 Any way I will change to dev_warn(pdev-dev, unable to select pin group\n); as in other drivers. Thanks Avinash Thierry -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 11/11] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk
On Fri, Nov 23, 2012 at 02:42:45, Thierry Reding wrote: On Wed, Nov 21, 2012 at 06:41:08PM +0530, Philip, Avinash wrote: PWM output from ecap2 uses as backlight source. Also adds low threshold value to have a uniform divisions in brightness-levels scales with inverse polarity. Signed-off-by: Philip, Avinash avinashphi...@ti.com --- :100644 100644 f5a6162... 6f3de83... M arch/arm/boot/dts/am335x-evmsk.dts arch/arm/boot/dts/am335x-evmsk.dts | 23 +++ 1 files changed, 23 insertions(+), 0 deletions(-) Same comments as for the previous patch, but otherwise: I will correct it Thanks Avinash Reviewed-by: Thierry Reding thierry.red...@avionic-design.de -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 10/11] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm
On Fri, Nov 23, 2012 at 02:41:47, Thierry Reding wrote:
On Wed, Nov 21, 2012 at 06:41:07PM +0530, Philip, Avinash wrote:
[...]
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 9f65f17..4178ba4 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -44,6 +44,12 @@
0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7 */
;
};
+
+ ecap0_pins: backlight_pins {
+ pinctrl-single,pins =
+ 0x164 0x0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
+ ;
This looks kind of funky, but I see the rest of the file uses similar
formatting, so I guess it's okay.
@@ -158,6 +174,13 @@
gpio-key,wakeup;
};
};
+
+ backlight {
+ compatible = pwm-backlight;
Maybe you don't want a tab between compatible and =, but a space
instead.
I will correct it.
Thanks
Avinash
Other than that, looks good:
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Hi Peter, On 19.11.2012 21:52, Peter Korsgaard wrote: D == Daniel Mack zon...@gmail.com writes: Hi, D This patch adds basic DT bindings for OMAP GPMC. D The actual peripherals are instanciated from child nodes within the GPMC s/instanciated/instantiated/ Thanks, fixed. D node, and the only type of device that is currently supported is NAND. D Code was added to parse the generic GPMC timing parameters and some D documentation with examples on how to use them. D Successfully tested on an AM33xx board. D Signed-off-by: Daniel Mack zon...@gmail.com D --- D .../devicetree/bindings/mtd/gpmc-nand.txt | 84 ++ D arch/arm/mach-omap2/gpmc.c | 170 + D 2 files changed, 254 insertions(+) D create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt D diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt D new file mode 100644 D index 000..20aa5b9 D --- /dev/null D +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt D @@ -0,0 +1,84 @@ D +Device tree bindings for GPMC connected NANDs D + D +GPMC connected NAND (found on OMAP boards) are represented as child nodes of D +the GPMC controller with a name of nand. D + D +All timing relevant properties as well as generic gpmc child properties are D +explained in a separate documents - please refer to D +Documentation/devicetree/bindings/bus/ti-gpmc.txt Which this patch seems to be missing? True - sorry for that. Will be back at v5. D + D +For NAND specific properties such as ECC modes or bus width, please refer to D +Documentation/devicetree/bindings/mtd/nand.txt D + D + D +Required properties: D + D + - reg: The CS line the peripheral is connected to D + D +Optional properties: D + D + - nand-bus-width: Set this numeric value to 16 if the hardware D + is wired that way. If not specified, a bus D + width of 8 is assumed. D + - ti,nand-ecc-opt: A string setting the ECC layout to use. One of: D + D + Layouts for 1-bit ecc: stored at end of spare area: D + D + software Software method (default) D + hwHardware method (let gpmc do the error detection) Nit: why are you spelling out 'software' when everything else is shortened? Right. Fixed. D + D + Layouts for 1-bit ecc: stored at beginning of spare area as romcode: D + D + hw-romcodegpmc method romcode layout D + bch4 4-bit BCH ecc code D + bch8 8-bit BCH ecc code D + These are not 1-bit - Well, romcode might be depending on SoC. Looking at omap2.c it seems to be an alias for hw, so that isn't really helpful on E.G. am33xx where you should select bch8 to have something compatible with the romcode. Not sure whether I follow you here. drivers/mtd/nand/omap2.c handles cases for pdata-ecc_opt == OMAP_ECC_BCH8_CODE_HW, so the DT bindings need to offer a way to set it. Or are you purely referring to the comments only? D + - ti,nand-ecc-use-elm: Property without value to specify that the D + hardware error correction mode should be used. It's called the error location module. Like you pointed out yourself, this property isn't really nice. I haven't looked at the elm bindings in detail, but couldn't the nand driver automatically use the elm if the device tree provides a node for it? Perhaps the elm should be a subnode of the nand one? That is to be discussed for the elm driver then. I'm not sure though whether the elm should always be used when its DT node is present. For now, I would leave it the way it is and have an optional ti,nand-ecc-use-elm. I just added some more lines of documenation to describe the fact that the elm driver is needed in order to make it work. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 06/11] pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver
On Fri, Nov 23, 2012 at 02:33:47, Thierry Reding wrote:
On Wed, Nov 21, 2012 at 06:41:03PM +0530, Philip, Avinash wrote:
[...]
+static const struct of_device_id ehrpwm_of_match[] = {
+ {
+ .compatible = ti,am33xx-ehrpwm,
+ },
Same comment as for patch 4.
Ok I will correct it.
@@ -437,16 +451,41 @@ static int __devinit ehrpwm_pwm_probe(struct
platform_device *pdev)
dev_err(pdev-dev, pwmchip_add() failed: %d\n, ret);
return ret;
}
-
I think this blank line actually improves readability so it can stay in.
I will add.
Thanks
Avinash
Thierry
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 09/11] ARM: dts: AM33XX: Add PWMSS device tree nodes
On Fri, Nov 23, 2012 at 02:38:57, Thierry Reding wrote: On Wed, Nov 21, 2012 at 06:41:06PM +0530, Philip, Avinash wrote: Add PWMSS device tree nodes in relation with ECAP EHRPWM DT nodes to AM33XX SoC family. Also populates device tree nodes for ECAP EHRPWM by adding necessary properties like pwm-cells, base reg set disabled as status. Signed-off-by: Philip, Avinash avinashphi...@ti.com --- Changes since v2: - ranges property populated to handle child devices address range :100644 100644 20a3f29... 4393161... M arch/arm/boot/dts/am33xx.dtsi arch/arm/boot/dts/am33xx.dtsi | 84 + 1 files changed, 84 insertions(+), 0 deletions(-) Looks good to me, Thanks Avinash Reviewed-by: Thierry Reding thierry.red...@avionic-design.de -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 00/11] Support for AM33xx PWM Subsystem
On Fri, Nov 23, 2012 at 02:46:16, Thierry Reding wrote: On Wed, Nov 21, 2012 at 06:40:57PM +0530, Philip, Avinash wrote: In AM33xx PWM sub modules like ECAP, EHRPWM EQEP are integrated to PWM subsystem. All these submodules shares the resources (clock) has a clock gating register in PWM Subsystem. This patch series creates a parent PWM Subsystem driver to handle access synchronization of shared resources clock gating from PWM Subsystem configuration space. Also Device tree nodes populated to support parent child relation between PWMSS, ECAP EHRPWM submodules. In addition EHRPWM module requires explicit clock gating from control module is handled by patch #2 8. As suggested by Thierry for handling clock gating for PWM submodules should handle with a global function. This requires config space handling done independent from driver and is done at parent driver. So the parent-child relation adopted to handle 1. pm runtime synchronization 2. PWM subsystem common config space clock gating for PWM submodules. Patches supports - Driver support for parent child relation handled patch #1 - Optional EHRPWM tb clock in patch #2 - Parent child in HWMOD handled at patch #3 - Device tree binding support handled in patch #4, 6 8 - pinctrl support in patch #5 7. - DT node populated in patch #9 ,10 11. This patch series based on omap_dt/for_3.8/dts_part2 and tested on am335x-evm am335x-evmsk. It depends on [1] 1. https://lkml.org/lkml/2012/11/21/70 pwm: Device tree support for PWM polarity Changes since v3: - Rebased on top of omap_dt/for_3.8/dts_part2 - Add pwm backlight for am335xevm_sk - Moved tipwmss.h to pwm-tipwmss.h Philip, Avinash (11): PWMSS: Add PWM Subsystem driver for parent-child relationship ARM: am33xx: clk: Add optional clock for EHRPWM ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem pwm: pwm-tiecap: Add device-tree binding support for APWM driver pwm: pwm-tiecap: pinctrl support pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver pwm: pwm-tiehrpwm: pinctrl support pwm: pwm-tiehrpwm: Adding TBCLK gating support. ARM: dts: AM33XX: Add PWMSS device tree nodes ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk Hi, So how do you want to get this merged? Should I take patches 1, 4, 5, 6, 7 and 8 while the rest go through some ARM tree? Can we still merge this for 3.8? These patches can go on, as DT node is not populated. Also without patch #3 PWM Subsystem driver won't come and hence the platform devices for ECAP EHRPWM. So there is no issue in getting this merged in PWM subsystem. The patches don't seem to have build dependencies on each other but how about runtime dependencies? Patch #3 required for PWM subsystem driver to populate PWM subsystem HWMOD Entries and DT entries. Patch #2 required for EHRPWM to have TBCLK handling. This patch required for EHRPWM driver functionality. But currently DT node is disabled for EHRPWM. So the dependency on the entire series is patch #3, for backlight through PWM ecap. I will follow up with OMAP subsystem community for getting reviews/ack Thanks Avinash Thierry -- 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 Thu, Nov 22, 2012 at 09:35:06PM -0500, Alan Stern wrote: On Thu, 22 Nov 2012, Felipe Balbi wrote: The latter, more or less. For example, maybe we can tell usbcore somehow that regulator X is in control of a device attached to host controller Y (not sure how we would express X and Y though). Then when usb_add_hcd() sees that the host controller being added is Y, it will know to turn on regulator X. Similarly for usb_remove_hcd(). that'd look very nice indeed. Perhaps we could even take care of such details for the roothub, even. Maybe some systems might show up where roothub need external regulators provided by e.g. PMIC ?!? As far as I can see, that ought to work provided the controller's platform driver is careful not to access the controller hardware before calling usb_add_hcd(). 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. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 3/3] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Daniel == Daniel Mack zon...@gmail.com writes: Hi, D + Layouts for 1-bit ecc: stored at beginning of spare area as romcode: D + D + hw-romcodegpmc method romcode layout D + bch4 4-bit BCH ecc code D + bch8 8-bit BCH ecc code D + These are not 1-bit - Well, romcode might be depending on SoC. Looking at omap2.c it seems to be an alias for hw, so that isn't really helpful on E.G. am33xx where you should select bch8 to have something compatible with the romcode. Daniel Not sure whether I follow you here. drivers/mtd/nand/omap2.c handles Daniel cases for pdata-ecc_opt == OMAP_ECC_BCH8_CODE_HW, so the DT bindings Daniel need to offer a way to set it. Daniel Or are you purely referring to the comments only? Yes, but the document states (the first line I'm quotinge) 'Layouts for 1-bit ecc'. The other comment was about hw-romcode not being a very good name, as it apparently means the 1bit hamming code and ECC layout used on the older omap3, and not E.G. the bch8/elm layout used by E.G. am335x. D + - ti,nand-ecc-use-elm:Property without value to specify that the D + hardware error correction mode should be used. It's called the error location module. Like you pointed out yourself, this property isn't really nice. I haven't looked at the elm bindings in detail, but couldn't the nand driver automatically use the elm if the device tree provides a node for it? Perhaps the elm should be a subnode of the nand one? Daniel That is to be discussed for the elm driver then. I'm not sure though Daniel whether the elm should always be used when its DT node is present. Daniel For now, I would leave it the way it is and have an optional Daniel ti,nand-ecc-use-elm. I just added some more lines of documenation to Daniel describe the fact that the elm driver is needed in order to make it work. As discussed elsewhere, the elm also changes the ECC layout, so why not just have bchN (software bchN layout) / bchN-elm selections instead of the seperate ti,nand-ecc-use-elm? -- Bye, Peter Korsgaard -- 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 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Wed, Nov 21, 2012 at 15:45:23, Daniel Mack wrote: On 20.11.2012 16:59, Peter Korsgaard wrote: Daniel == Daniel Mack zon...@gmail.com writes: Hi, In omap2 driver NAND_ECC_HW ecc mode supports 3 ecc layout OMAP_ECC_HAMMING_CODE_HW_ROMCODE OMAP_ECC_BCH4_CODE_HW OMAP_ECC_BCH8_CODE_HW So selection of ecc layout data should come from DT not ecc mode. Ok, I see. I would still like to set them by string rather than magic numbers that map to enum entries. Valid values would be none, hw, hw-romcode, bch4 and bch8. Are you ok with that? Ok, that's nice. Better use ecc_opt instead of ecc_mode. Daniel I did some more extensive tests that include reading the same Daniel nand pages from both U-Boot and the kernel with BCH8 ECC, and Daniel it turns out that - is_elm_used needs to be set in the pdata Daniel in order to make this work. So what you're saying is that the choice of ELM or not is not just an optimization, it really changes the ECC layout? Perhaps it should be treated as a seperate layout (E.G. bch8-elm) then? Peter, In patch [1], mtd: nand: omap2: Support for hardware BCH ecc_layout made compatible with Rom Boot Loader ECC layout for am335x. This action is based on is_elm_used flag. Requirement of this flag is to identify the whether the platform ELM module based on this configure ELM module if present. But ideally BCH8 ecc lay out didn't have a dependency on ELM, it can work with software BCH ecc. RBL compatibility is missing in software BCH because of addition of constant polynomial to ecc vector. If we remove the dependency on erased page handling by ecc vector with constant polynomial, software BCH can do the job of RBL compatibility. Ivan, Do you have any suggestions? Discussion for RBL compatibility found at [2]. It is good that software BCH also support RBL compatibility by suppressing constant polynomial modification. Then ecc layout can be selected from DT entry and error correction can be chosen between software/hardware depending on the availability of ELM hardware. Currently RBL BCH8 compatibility depends on the availability of ELM hardware. Later once software BCH start supporting RBL compatibility, we can remove the check. That is what I experienced, yes. The kernel was unable to parse NAND pages that were written from U-Boot with bch8 hardware mode when the elm module was not active. Maybe someone from TI can explain that? Giving it a dedicated name would also solve the problem with the extra DT property. Daniel, Currently BCH8 is supported with software ecc error correction in mainline. The layout for BCH8 ECC layout is 0-1 - BAD block markers 2-11- oob free area 12-63- BCH8 ECC. RBL ECC layout is 0-1 - BAD block markers 2-57- BCH8 ecc layout 58-63- OOB free area As u-boot also maintain RBL ecc layout, write from U-boot and read from Linux requires compatibility with RBL ecc layout. The same is achieved in the patch [1], with by setting is_elm_used to true. 1. https://lkml.org/lkml/2012/10/31/87 2. https://lkml.org/lkml/2012/10/11/20 Thanks Avinash I'll wait until this is decided before I resend a new set that also fixes the issue with the errornousely forgotten Documentation file. Thanks, Daniel -- 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
On Fri, Nov 23, 2012 at 12:23:52PM +0200, Roger Quadros wrote:
On 11/22/2012 06:12 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 22, 2012 at 05:00:45PM +0200, Roger Quadros wrote:
On 11/22/2012 03:56 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 22, 2012 at 09:49:05PM +0800, Andy Green wrote:
Again it sounds like something that should be done at the hub driver
level. I mean using the GPIO (for reset) and Power Regulator.
not implementing the regulator part itself, but using it.
If you mean change the regulator managing code from living in
omap-hsusb to ehci-hcd, it sounds like a good idea.
I mean that drivers/usb/core/hub.c should manage it, since that's what
actually manages the HUB entity.
Yes. I agree that powering up the on-board hubs should be done
generically and not in ehci-omap.c. I'm not sure how it can be done in
hub.c.
I'm assuming that such problem is limited to root hub ports where system
an external LAN95xx HUB is not the roothub. LAN95xx is connected to the
roothub.
I didn't say LAN95xx is the root hub. It is connected to the root hub.
So it is in theory, the root hub port's responsibility to power the LAN95xx.
no, it's LAN95xx's responsibility to power itself up. What if you had
multiple tiers of LAN95xx ?
designers have the flexibility to provide power to the peripherals
outside the USB Hub specification.
I can think of two solutions
1) Associate the regulators with the root hub _ports_ and enable them as
part of port's power-up routine.
doesn't make sense. We need to figure out a way to attach the regulator
to the ports which actually have them. In this case it's the external
LAN95xx, right ?
I think you are confused here. The LAN95xx's ports are compatible with
USB hub specification and they work using the in-band set_port_feature
mechanism already. We have a problem powering the LAN95xx itself which
ideally should have been powered with set_port_feature on the root hub.
(or ehci_port_power() in this case).
I don't set_port_feature() has anything to do with the problem here.
It's not working because the controller's supply isn't turned on. How
can any port be turned on if the supply isn't turned on ?
I still think, however, the hub needs to know how to power itself up.
The patch below is *CLEARLY WRONG* it's just to illustrate how this
could be started:
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 1af04bd..662d4cf 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
@@ -44,6 +45,7 @@ struct usb_port {
struct device dev;
struct dev_state *port_owner;
enum usb_port_connect_type connect_type;
+ struct regulator *port_regulator;
};
struct usb_hub {
@@ -847,8 +849,41 @@ static unsigned hub_power_on(struct usb_hub *hub, bool
do_delay)
else
dev_dbg(hub-intfdev, trying to enable port power on
non-switchable hub\n);
- for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++)
+ for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++) {
+ regulator_enable(hub-ports[port1]-port_regulator);
set_port_feature(hub-hdev, port1, USB_PORT_FEAT_POWER);
+ }
+
+ /* Wait at least 100 msec for power to become stable */
+ delay = max(pgood_delay, (unsigned) 100);
+ if (do_delay)
+ msleep(delay);
+ return delay;
+}
+
+static unsigned hub_power_off(struct usb_hub *hub, bool do_delay)
+{
+ int port1;
+ unsigned pgood_delay = hub-descriptor-bPwrOn2PwrGood * 2;
+ unsigned delay;
+ u16 wHubCharacteristics =
+ le16_to_cpu(hub-descriptor-wHubCharacteristics);
+
+ /* Disable power on each port. Some hubs have reserved values
+* of LPSM ( 2) in their descriptors, even though they are
+* USB 2.0 hubs. Some hubs do not implement port-power switching
+* but only emulate it. In all cases, the ports won't work
+* unless we send these messages to the hub.
+*/
+ if ((wHubCharacteristics HUB_CHAR_LPSM) 2)
+ dev_dbg(hub-intfdev, disabling power on all ports\n);
+ else
+ dev_dbg(hub-intfdev, trying to disable port power on
+ non-switchable hub\n);
+ for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++) {
+ regulator_disable(hub-ports[port1]-port_regulator);
+ clear_port_feature(hub-hdev, port1, USB_PORT_FEAT_POWER);
+ }
/* Wait at least 100 msec for power to become stable */
delay = max(pgood_delay, (unsigned) 100);
@@ -1336,6 +1371,9 @@ static int hub_configure(struct usb_hub *hub,
goto fail;
}
+ if
Re: [PATCH v4 05/11] pwm: pwm-tiecap: pinctrl support
On Fri, Nov 23, 2012 at 10:34:02AM +, Philip, Avinash wrote: On Fri, Nov 23, 2012 at 02:29:44, Thierry Reding wrote: On Wed, Nov 21, 2012 at 06:41:02PM +0530, Philip, Avinash wrote: [...] + pinctrl = devm_pinctrl_get_select_default(pdev-dev); + if (IS_ERR(pinctrl)) + dev_warn(pdev-dev, failed to configure pins from driver\n); I think we already discussed this, but shouldn't this be a fatal error? I had checked relevant discussion and found this can be warning message. This is because most boards don't have pinctrl implemented at this point, or may never have. https://lkml.org/lkml/2012/9/11/369 Any way I will change to dev_warn(pdev-dev, unable to select pin group\n); as in other drivers. But in case pinctrl isn't implemented, shouldn't the implementation of devm_pinctrl_get_select_default() just be a no-op? Thierry pgpF87YzRz2dC.pgp Description: PGP signature
Re: [PATCH v4 3/3] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On 23.11.2012 11:47, Peter Korsgaard wrote: Daniel == Daniel Mack zon...@gmail.com writes: Hi, D + Layouts for 1-bit ecc: stored at beginning of spare area as romcode: D + D + hw-romcodegpmc method romcode layout D + bch4 4-bit BCH ecc code D + bch8 8-bit BCH ecc code D + These are not 1-bit - Well, romcode might be depending on SoC. Looking at omap2.c it seems to be an alias for hw, so that isn't really helpful on E.G. am33xx where you should select bch8 to have something compatible with the romcode. Daniel Not sure whether I follow you here. drivers/mtd/nand/omap2.c handles Daniel cases for pdata-ecc_opt == OMAP_ECC_BCH8_CODE_HW, so the DT bindings Daniel need to offer a way to set it. Daniel Or are you purely referring to the comments only? Yes, but the document states (the first line I'm quotinge) 'Layouts for 1-bit ecc'. Ok, I guess I'll just remove these comments then. The other comment was about hw-romcode not being a very good name, as it apparently means the 1bit hamming code and ECC layout used on the older omap3, and not E.G. the bch8/elm layout used by E.G. am335x. So which name would you pick? bch1? As discussed elsewhere, the elm also changes the ECC layout, so why not just have bchN (software bchN layout) / bchN-elm selections instead of the seperate ti,nand-ecc-use-elm? Avinash - what do you think? Thanks for the feedback - I'd also like to get these bindings right in the first place. Daniel -- 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 02/10] ARM: am33xx: clk: Add optional clock for EHRPWM
On Tue, Nov 20, 2012 at 10:33:43, Philip, Avinash wrote:
EHRPWM module requires explicit clock gating from control module.
Hence add clock node in clock tree for EHRPWM modules.
Is there any review on this patch?
This patch depends on EHRPWM to work in am335x.
Thanks
Avinash
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 17e3de5... 833260f... M
arch/arm/mach-omap2/clock33xx_data.c
:100644 100644 a89e825... c0e34e6... March/arm/mach-omap2/control.h
arch/arm/mach-omap2/clock33xx_data.c | 37
++
arch/arm/mach-omap2/control.h|8 +++
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..833260f 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -995,6 +995,40 @@ static struct clk wdt1_fck = {
};
/*
+ * PWMSS Time based module clock node. This node is
+ * requred to enable clock gating for EHRPWM TBCLK.
+ */
+static struct clk ehrpwm0_tbclk = {
+ .name = ehrpwm0_tbclk,
+ .clkdm_name = l4ls_clkdm,
+ .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+ .enable_bit = AM33XX_PWMSS0_TBCLKEN_SHIFT,
+ .ops= clkops_omap2_dflt,
+ .parent = l4ls_gclk,
+ .recalc = followparent_recalc,
+};
+
+static struct clk ehrpwm1_tbclk = {
+ .name = ehrpwm1_tbclk,
+ .clkdm_name = l4ls_clkdm,
+ .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+ .enable_bit = AM33XX_PWMSS1_TBCLKEN_SHIFT,
+ .ops= clkops_omap2_dflt,
+ .parent = l4ls_gclk,
+ .recalc = followparent_recalc,
+};
+
+static struct clk ehrpwm2_tbclk = {
+ .name = ehrpwm2_tbclk,
+ .clkdm_name = l4ls_clkdm,
+ .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+ .enable_bit = AM33XX_PWMSS2_TBCLKEN_SHIFT,
+ .ops= clkops_omap2_dflt,
+ .parent = l4ls_gclk,
+ .recalc = followparent_recalc,
+};
+
+/*
* clkdev
*/
static struct omap_clk am33xx_clks[] = {
@@ -1074,6 +1108,9 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, clkout2_ck, clkout2_ck,CK_AM33XX),
CLK(NULL, timer_32k_ck, clkdiv32k_ick, CK_AM33XX),
CLK(NULL, timer_sys_ck, sys_clkin_ck, CK_AM33XX),
+ CLK(NULL, ehrpwm0_tbclk,ehrpwm0_tbclk, CK_AM33XX),
+ CLK(NULL, ehrpwm1_tbclk,ehrpwm1_tbclk, CK_AM33XX),
+ CLK(NULL, ehrpwm2_tbclk,ehrpwm2_tbclk, CK_AM33XX),
};
int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a89e825..c0e34e6 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -357,6 +357,14 @@
#define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH 0x2
#define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK (0x3 22)
+/* AM33XX PWMSS Control register */
+#define AM33XX_PWMSS_TBCLK_CLKCTRL 0x664
+
+/* AM33XX PWMSS Control bitfields */
+#define AM33XX_PWMSS0_TBCLKEN_SHIFT 0
+#define AM33XX_PWMSS1_TBCLKEN_SHIFT 1
+#define AM33XX_PWMSS2_TBCLKEN_SHIFT 2
+
/* CONTROL OMAP STATUS register to identify OMAP3 features */
#define OMAP3_CONTROL_OMAP_STATUS0x044c
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 03/10] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
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.
Thanks
Avinash
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
Changes since v1:
- Remove ADDR_TYPE_RT for PWM sub module register entries.
:100644 100644 ad8d43b... de2301c... M
arch/arm/mach-omap2/omap_hwmod_33xx_data.c
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 419
++--
1 files changed, 276 insertions(+), 143 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..de2301c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -768,9 +768,7 @@ static struct omap_hwmod am33xx_elm_hwmod = {
},
};
-/*
- * 'epwmss' class: ecap0,1,2, ehrpwm0,1,2
- */
+/* pwmss */
static struct omap_hwmod_class_sysconfig am33xx_epwmss_sysc = {
.rev_offs = 0x0,
.sysc_offs = 0x4,
@@ -786,18 +784,23 @@ static struct omap_hwmod_class
am33xx_epwmss_hwmod_class = {
.sysc = am33xx_epwmss_sysc,
};
-/* ehrpwm0 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
- { .name = int, .irq = 86 + OMAP_INTC_START, },
- { .name = tzint, .irq = 58 + OMAP_INTC_START, },
- { .irq = -1 },
+
+static struct omap_hwmod_class am33xx_ecap_hwmod_class = {
+ .name = ecap,
};
-static struct omap_hwmod am33xx_ehrpwm0_hwmod = {
- .name = ehrpwm0,
+static struct omap_hwmod_class am33xx_eqep_hwmod_class = {
+ .name = eqep,
+};
+
+static struct omap_hwmod_class am33xx_ehrpwm_hwmod_class = {
+ .name = ehrpwm,
+};
+/* epwmss0 */
+static struct omap_hwmod am33xx_epwmss0_hwmod = {
+ .name = epwmss0,
.class = am33xx_epwmss_hwmod_class,
.clkdm_name = l4ls_clkdm,
- .mpu_irqs = am33xx_ehrpwm0_irqs,
.main_clk = l4ls_gclk,
.prcm = {
.omap4 = {
@@ -807,63 +810,68 @@ static struct omap_hwmod am33xx_ehrpwm0_hwmod = {
},
};
-/* ehrpwm1 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm1_irqs[] = {
- { .name = int, .irq = 87 + OMAP_INTC_START, },
- { .name = tzint, .irq = 59 + OMAP_INTC_START, },
+/* ecap0 */
+static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
+ { .irq = 31 + OMAP_INTC_START, },
{ .irq = -1 },
};
-static struct omap_hwmod am33xx_ehrpwm1_hwmod = {
- .name = ehrpwm1,
- .class = am33xx_epwmss_hwmod_class,
+static struct omap_hwmod am33xx_ecap0_hwmod = {
+ .name = ecap0,
+ .class = am33xx_ecap_hwmod_class,
.clkdm_name = l4ls_clkdm,
- .mpu_irqs = am33xx_ehrpwm1_irqs,
+ .mpu_irqs = am33xx_ecap0_irqs,
.main_clk = l4ls_gclk,
- .prcm = {
- .omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
};
-/* ehrpwm2 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm2_irqs[] = {
- { .name = int, .irq = 39 + OMAP_INTC_START, },
- { .name = tzint, .irq = 60 + OMAP_INTC_START, },
+/* eqep0 */
+static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
+ { .irq = 79 + OMAP_INTC_START, },
{ .irq = -1 },
};
-static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
- .name = ehrpwm2,
- .class = am33xx_epwmss_hwmod_class,
+static struct omap_hwmod am33xx_eqep0_hwmod = {
+ .name = eqep0,
+ .class = am33xx_eqep_hwmod_class,
.clkdm_name = l4ls_clkdm,
- .mpu_irqs = am33xx_ehrpwm2_irqs,
+ .mpu_irqs = am33xx_eqep0_irqs,
.main_clk = l4ls_gclk,
- .prcm = {
- .omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
};
-/* ecap0 */
-static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
- { .irq = 31 + OMAP_INTC_START, },
+/* ehrpwm0 */
+static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
+ { .name = int, .irq = 86 + OMAP_INTC_START, },
+ { .name = tzint, .irq = 58 + OMAP_INTC_START, },
{ .irq = -1 },
};
-static struct
Re: [PATCH v4 3/3] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Daniel == Daniel Mack zon...@gmail.com writes: Hi, The other comment was about hw-romcode not being a very good name, as it apparently means the 1bit hamming code and ECC layout used on the older omap3, and not E.G. the bch8/elm layout used by E.G. am335x. Daniel So which name would you pick? bch1? No, it's hamming code, isn't it? To me it seems similar to the elm discussion, E.G. we have a mix of ECC algorithm + ECC layout + use of hw acceleration or not. The choice of hardware acceleration or not should preferably be transparent to this binding (E.G. it is purely an optimization, ECC strength/format shouldn't change), so the driver should be free to use it if it is available. Daniel Thanks for the feedback - I'd also like to get these bindings Daniel right in the first place. Me too! -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 05/11] pwm: pwm-tiecap: pinctrl support
On Fri, Nov 23, 2012 at 11:12:15AM +, Philip, Avinash wrote: On Fri, Nov 23, 2012 at 16:21:10, Thierry Reding wrote: On Fri, Nov 23, 2012 at 10:34:02AM +, Philip, Avinash wrote: On Fri, Nov 23, 2012 at 02:29:44, Thierry Reding wrote: On Wed, Nov 21, 2012 at 06:41:02PM +0530, Philip, Avinash wrote: [...] + pinctrl = devm_pinctrl_get_select_default(pdev-dev); + if (IS_ERR(pinctrl)) + dev_warn(pdev-dev, failed to configure pins from driver\n); I think we already discussed this, but shouldn't this be a fatal error? I had checked relevant discussion and found this can be warning message. This is because most boards don't have pinctrl implemented at this point, or may never have. https://lkml.org/lkml/2012/9/11/369 Any way I will change to dev_warn(pdev-dev, unable to select pin group\n); as in other drivers. But in case pinctrl isn't implemented, shouldn't the implementation of devm_pinctrl_get_select_default() just be a no-op? So driver can still exist but pin mux functionality missing. Then warning message will give hints. I am also ok with error message failure of driver with EPROBE_DEFER, if you want? Everybody seems to be doing it with a warning, so I guess that's fine for now. I just find it strange that if you request the default pin group to be selected when in fact the hardware doesn't support pinctrl at all you shouldn't be getting an error either. I'm adding LinusW on Cc, perhaps he can shed some light on it. Thierry pgpFMGc5JhlDt.pgp Description: PGP signature
[GIT PULL] OMAPDSS fixes for 3.7-rc
Hi Linus, Here are a few OMAPDSS fixes for the next -rc. I'm sending these directly to you, and quite late, as the fbdev tree maintainer (Florian) has been busy with his work and hasn't had time to manage the fb patches. Tomi The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.7-rc for you to fetch changes up to 8ad9375f8b7c709b89f7de4de413bb2644ba3c24: OMAPDSS: do not fail if dpll4_m4_ck is missing (2012-11-22 17:23:12 +0200) omapdss fixes for 3.7-rc Aaro Koskinen (1): OMAPDSS: do not fail if dpll4_m4_ck is missing Laurent Pinchart (1): omapdss: dss: Fix clocks on OMAP363x Tomi Valkeinen (1): OMAPDSS: DSI: fix dsi_get_dsidev_from_id() Tushar Behera (1): OMAPFB: Fix possible null pointer dereferencing Wei Yongjun (1): OMAPDSS: HDMI: fix missing unlock on error in hdmi_dump_regs() drivers/video/omap2/dss/dsi.c | 13 +++-- drivers/video/omap2/dss/dss.c | 18 +++--- drivers/video/omap2/dss/hdmi.c|4 +++- drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +- 4 files changed, 26 insertions(+), 11 deletions(-) signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 05/11] pwm: pwm-tiecap: pinctrl support
Thierry == Thierry Reding thierry.red...@avionic-design.de writes: Hi, Thierry Everybody seems to be doing it with a warning, so I guess Thierry that's fine for now. I just find it strange that if you Thierry request the default pin group to be selected when in fact the Thierry hardware doesn't support pinctrl at all you shouldn't be Thierry getting an error either. There's several different situations: - Platform without pinctrl support - Platform with pinctrl support but no pinmux specified in dt for device (E.G. pinmux setup in bootloader) - Pinmux specified in dt - Some kind of misconfiguration in dt You could argue that devm_pinctrl_get_select_default() shouldn't return an error for the first situation, but how should it be able to know the difference between 2 and 4? -- Bye, Peter Korsgaard -- 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 2/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs
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
+config PWM_TWL
+ tristate TWL4030/6030 PWM support
+ select HAVE_PWM
Why do you select HAVE_PWM?
+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?
+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?
+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).
+ 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, struct twl_pwm_chip,
+ chip);
+ int ret;
+ u8 val, mask;
+
+ 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;
+ }
+
+ if (pwm-hwpwm)
+ /* PWM 1 */
+ mask = TWL4030_GPIO7_VIBRASYNC_PWM1_MASK;
+ else
+
Re: [PATCH v3 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
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.
+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.
Thierry
pgpOYHLTcsefh.pgp
Description: PGP signature
Re: [PATCH v3 1/3] pwm: Remove pwm-twl6030 driver
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. Thierry pgphwo2JBrmxI.pgp Description: PGP signature
Re: omap DSS fails with tft410 driver panel?
On Fri, Nov 23, 2012 at 12:46 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you put a printk at dss/apply.c:dss_olv_set_info, and print ovl-id and info-paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at the point where it sets info.paddr, as I think that's the only place where omapfb sets paddr. OK, did that and here is what I get when starting up gdm, prior to that all is normal root@omap3-multi:~# systemctl start gdm.service Starting Gnome Display Manager... Started Gnome Display Manager [ OK ] root@omap3-multi:~# [ 83.475128] omapfb_setup_plane entry [ 83.479492] setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 [ 83.485809] omapfb_setup_overlay: setting info.paddr = 9f40 [ 83.492431] dss_ovl_set_info entry [ 83.496307] ovl-id = 0 [ 83.499267] info-paddr = 9f40 [ 83.503601] omapfb_setup_plane: return success [ 83.508697] omapfb_setup_plane entry [ 83.513153] dss_ovl_set_info entry [ 83.516723] ovl-id = 2 [ 83.520111] info-paddr = 0 [ 83.523406] omapdss OVERLAY error: check_overlay: paddr cannot be 0 [ 83.530426] omapfb_setup_plane: !pi-enabled ovl-set_overlay_info [ 83.537414] dss_ovl_set_info entry [ 83.540985] ovl-id = 2 [ 83.544250] info-paddr = 0 [ 83.547546] omapdss OVERLAY error: check_overlay: paddr cannot be 0 repeats as X dies and restarts I don't know what's going on there, why the paddr is suddenly zero. Looking at the log from Enric, SETUP_PLANE works fine just fine, and then, for no reason, next SETUP_PLANE fails, and the log doesn't show anything much happening between. However, I think omapdss may have been more permissive in the past, allowing paddr 0 if the overlay is disabled. I could add that back, but I'd rather first understand what's happening here. From the above it seems that the first SETUP_PLANE is for ovl-id = 0 and then those that fail are for ovl-id =2. No idea what is going on in user space, but maybe this will mean something to you :-) Steve -- 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
On Fri, 23 Nov 2012, Felipe Balbi wrote: Thanks for the example. The only problem is, how do we associate a regulator to a specific port in the system. heh, that's the 1 million dollar question, isn't it ? :-) that's what we need to figure out now. Luckily we have Alan Stern helping us out ;-) Some people might think having me around to interfere was not so lucky after all... :-) First question: Should we worry about individual ports? Ordinarily I'd say No, because hubs always power up all of their ports. But with Lan Tianyu's recent work, that won't be true any more. In this case, it's conceivable that the user might want to power-off the LAN95xx in order to save energy, even though ehci-hcd is still loaded and managing other USB devices. Either way, the regulator has to be associated with _something_: either a root-hub port or the host controller itself. And this will most likely have to be done before the port's or the controller's struct device exists. Something like Andy's scheme might work. It would require the kernel to parse name strings in various formats, which could get complicated. It would be great if the difficult parts could be stuck in the PM core somewhere. 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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
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)? 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 0/5] remaining omap multiplatform patches for v3.8 merge window
* Russell King - ARM Linux li...@arm.linux.org.uk [121122 12:26]: On Wed, Nov 21, 2012 at 09:42:19AM -0800, Tony Lindgren wrote: There are few drivers still breaking because of their use of plat/cpu.h and cpu_is_omap macros. The following already have patches queued in linux next: - drivers/staging/omapdrm/omap_drv.c - drivers/staging/omapdrm/omap_dmm_tiler.h Note that there's a bunch of OMAP drivers in staging which are trivially broken anyway; I've not been bothering to report their breakages which my build system is finding - I figure that if they're trivially broken with compile time errors which aren't config related, and no one's bothering to fixing them, then no one is even trying to build them - which means they're not being used. Do you have a list of the broken drivers somewhere? And if they're not being used, it's pointless them being in mainline. Yes makes sense to me. 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 v3 5/5] ARM: OMAP2+: omap2plus_defconfig: Enable RTC support
AnilKumar Ch wrote: AM33XX family of devices uses RTC module, one has to manually enable this support to use RTC features. So this patch enable RTC driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilkumar-l0cymroi...@public.gmane.org --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index a4b330e..8839ac9 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -194,6 +194,7 @@ CONFIG_SDIO_UART=y CONFIG_MMC_OMAP=y CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_OMAP=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y CONFIG_DMADEVICES=y Hello, But this is not enough, we need to change drivers/rtc/Kconfig too. This change was offered in this thread http://marc.info/?l=linux-arm-kernelm=135057569913027w=2 But, may be all this previous rtc-related changes accounted already in some development branch. I just doesn't see it in the current master. In this case, when could we get RTC support in the current kernel? 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 0/5] remaining omap multiplatform patches for v3.8 merge window
On Fri, Nov 23, 2012 at 08:54:15AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [121122 12:26]: On Wed, Nov 21, 2012 at 09:42:19AM -0800, Tony Lindgren wrote: There are few drivers still breaking because of their use of plat/cpu.h and cpu_is_omap macros. The following already have patches queued in linux next: - drivers/staging/omapdrm/omap_drv.c - drivers/staging/omapdrm/omap_dmm_tiler.h Note that there's a bunch of OMAP drivers in staging which are trivially broken anyway; I've not been bothering to report their breakages which my build system is finding - I figure that if they're trivially broken with compile time errors which aren't config related, and no one's bothering to fixing them, then no one is even trying to build them - which means they're not being used. Do you have a list of the broken drivers somewhere? No, I've been ignoring the error messages from anything in staging, so it'll be a matter of digging through the last seven days build logs. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
On 11/22/2012 08:12 PM, Mark Brown wrote: On Thu, Nov 22, 2012 at 08:03:53PM -0600, Ricardo Neri wrote: On 11/21/2012 07:03 PM, Mark Brown wrote: instantiation infrastructure in there which is rather Linux specific. But the board files are only for Linux, right? The ASoC drivers will always be initialized anyways. They will reach probe only if the devices are present. Could you be more specific please? Sorry, I meant that the drivers will try to register anyways. The will only probe if there is a matching device for them. -- 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
On 11/24/12 00:25, the mail apparently from Alan Stern included: On Fri, 23 Nov 2012, Felipe Balbi wrote: Thanks for the example. The only problem is, how do we associate a regulator to a specific port in the system. heh, that's the 1 million dollar question, isn't it ? :-) that's what we need to figure out now. Luckily we have Alan Stern helping us out ;-) Some people might think having me around to interfere was not so lucky after all... :-) First question: Should we worry about individual ports? Ordinarily I'd say No, because hubs always power up all of their ports. But with Lan Tianyu's recent work, that won't be true any more. In this case, it's conceivable that the user might want to power-off the LAN95xx in order to save energy, even though ehci-hcd is still loaded and managing other USB devices. Either way, the regulator has to be associated with _something_: either a root-hub port or the host controller itself. And this will most likely have to be done before the port's or the controller's struct device exists. Something like Andy's scheme might work. It would require the kernel to parse name strings in various formats, which could get complicated. It would be great if the difficult parts could be stuck in the PM core somewhere. If we're just looking at fixing the current magic regulator name scheme of hsusb0 so that it can work with abstract devices like any hub / port, we could invert what my original device path scheme did. So instead of having a parser (which boiled down quite small, but is complicated by usb%d being the same for different usb drivers), we could just add a helper function that walks the device parents to generate a string representing the device instance. Like int device_path_generate(struct device *device, char *name, int len); if you called it from the hub driver's probe function (or anything else's probe function) with the new hub device pointer, it might fill name with ehci1/usbhub1-1/1-1.1 or somesuch. That is then used in the hub probe function as the magic regulator name, if a regulator exists of that name it gets managed according to logical hub device lifecycle, same as the omap bit does at the moment. That way it'll work with DT alright (you just arrange the regulator name to be ehci1/usbhub1-1/1-1.1 or whatever) and you're just trying to sell device_path_generate() to someone else, which should be pretty small. -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
[PATCH 0/6] ARM: OMAP2+: some PM fixes and cleanup for 3.9
Several OMAP2+ power management fixes, optimizations, and cleanup, intended for 3.9. This series is a prerequisite for the functional powerdomain conversion series. - Paul --- vmlinux object size (delta in bytes from TEST_cleanup-prcm_c9d501e5_v3.7-rc (c9d501e5cb0238910337213e12a09127221c35d8)): text data bsstotal kernel 0000 am33xx_only +5600 +56 n800_multi_omap2xxx +5600 +56 n800_only_a 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0000 omap1_defconfig_5912osk_only +16000 +160 omap2plus_defconfig +8800 +88 omap2plus_defconfig_2430sdp_only +10800 +108 omap2plus_defconfig_cpupm +16000 +160 omap2plus_defconfig_no_pm +3200 +32 omap2plus_defconfig_omap2_4_only -8400 -84 omap2plus_defconfig_omap3_4_only +3040 -48 +256 rmk_omap3430_ldp_allnoconfig 0000 rmk_omap3430_ldp_oldconfig +3040 -48 +256 rmk_omap4430_sdp_allnoconfig -4800 -48 rmk_omap4430_sdp_oldconfig Jean Pihet (1): ARM: OMAP2+: powerdomain: fix powerdomain trace integration Paul Walmsley (5): ARM: OMAP2xxx: powerdomain: core powerdomain missing logic retention states ARM: OMAP2/3: PRM: fix bogus OMAP2xxx powerstate return values ARM: OMAP3xxx: CPUIdle: simplify the PER next-state code ARM: OMAP3xxx: CPUIdle: optimize __omap3_enter_idle() ARM: OMAP4: MPUSS PM: remove unnecessary shim functions for powerdomain control arch/arm/mach-omap2/cpuidle34xx.c | 79 ++-- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 43 ++--- arch/arm/mach-omap2/powerdomain.c |7 +- arch/arm/mach-omap2/powerdomains2xxx_data.c |1 arch/arm/mach-omap2/prm2xxx.c | 88 ++- arch/arm/mach-omap2/prm2xxx_3xxx.c | 22 --- arch/arm/mach-omap2/prm3xxx.c | 28 - 7 files changed, 166 insertions(+), 102 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM: OMAP2xxx: powerdomain: core powerdomain missing logic retention states
Add the possible logic retention states for the 24xx CORE powerdomain.
Subsequent patches use this data to avoid returning incorrect data, by
skipping reads from register bitfields that don't actually exist.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomains2xxx_data.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/powerdomains2xxx_data.c
b/arch/arm/mach-omap2/powerdomains2xxx_data.c
index ba520d4..01abc1e 100644
--- a/arch/arm/mach-omap2/powerdomains2xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains2xxx_data.c
@@ -60,6 +60,7 @@ static struct powerdomain core_24xx_pwrdm = {
.name = core_pwrdm,
.prcm_offs= CORE_MOD,
.pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_RET,
.banks= 3,
.pwrsts_mem_ret = {
[0] = PWRSTS_OFF_RET,/* MEM1RETSTATE */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] ARM: OMAP2/3: PRM: fix bogus OMAP2xxx powerstate return values
On OMAP2xxx chips, the register bitfields for the
PM_PWSTCTRL_*.POWERSTATE and PM_PWSTST_*.LASTSTATEENTERED are
different than those used on OMAP3/4. The order is reversed. So, for
example, on OMAP2xxx, 0x0 indicates 'ON'; but on OMAP3/4, 0x0
indicates 'OFF'. Similarly, on OMAP2xxx, 0x3 indicates 'OFF', but on
OMAP3/4, 0x3 indicates 'ON'.
To fix this, we treat the OMAP3/4 values as the powerdomain API
values, and create new low-level powerdomain functions for the
OMAP2xxx chips which translate between the OMAP2xxx values and the
OMAP3/4 values.
Without this patch, the conversion of the OMAP2xxx PM code to the
functional powerstate code results in a non-booting kernel.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/prm2xxx.c | 88 +++-
arch/arm/mach-omap2/prm2xxx_3xxx.c | 22 -
arch/arm/mach-omap2/prm3xxx.c | 28 ++-
3 files changed, 110 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx.c b/arch/arm/mach-omap2/prm2xxx.c
index bf24fc4..e4cdb69 100644
--- a/arch/arm/mach-omap2/prm2xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx.c
@@ -29,6 +29,14 @@
#include prm-regbits-24xx.h
/*
+ * OMAP24xx PM_PWSTCTRL_*.POWERSTATE and PM_PWSTST_*.LASTSTATEENTERED bits -
+ * these are reversed from the bits used on OMAP3+
+ */
+#define OMAP24XX_PWRDM_POWER_ON0x0
+#define OMAP24XX_PWRDM_POWER_RET 0x1
+#define OMAP24XX_PWRDM_POWER_OFF 0x3
+
+/*
* omap2xxx_prm_reset_src_map - map from bits in the PRM_RSTST_WKUP
* hardware register (which are specific to the OMAP2xxx SoCs) to
* reset source ID bit shifts (which is an OMAP SoC-independent
@@ -69,6 +77,34 @@ static u32 omap2xxx_prm_read_reset_sources(void)
}
/**
+ * omap2xxx_pwrst_to_common_pwrst - convert OMAP2xxx pwrst to common pwrst
+ * @omap2xxx_pwrst: OMAP2xxx hardware power state to convert
+ *
+ * Return the common power state bits corresponding to the OMAP2xxx
+ * hardware power state bits @omap2xxx_pwrst, or -EINVAL upon error.
+ */
+static int omap2xxx_pwrst_to_common_pwrst(u8 omap2xxx_pwrst)
+{
+ u8 pwrst;
+
+ switch (omap2xxx_pwrst) {
+ case OMAP24XX_PWRDM_POWER_OFF:
+ pwrst = PWRDM_POWER_OFF;
+ break;
+ case OMAP24XX_PWRDM_POWER_RET:
+ pwrst = PWRDM_POWER_RET;
+ break;
+ case OMAP24XX_PWRDM_POWER_ON:
+ pwrst = PWRDM_POWER_ON;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return pwrst;
+}
+
+/**
* omap2xxx_prm_dpll_reset - use DPLL reset to reboot the OMAP SoC
*
* Set the DPLL reset bit, which should reboot the SoC. This is the
@@ -98,10 +134,56 @@ int omap2xxx_clkdm_wakeup(struct clockdomain *clkdm)
return 0;
}
+static int omap2xxx_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
+{
+ u8 omap24xx_pwrst;
+
+ switch (pwrst) {
+ case PWRDM_POWER_OFF:
+ omap24xx_pwrst = OMAP24XX_PWRDM_POWER_OFF;
+ break;
+ case PWRDM_POWER_RET:
+ omap24xx_pwrst = OMAP24XX_PWRDM_POWER_RET;
+ break;
+ case PWRDM_POWER_ON:
+ omap24xx_pwrst = OMAP24XX_PWRDM_POWER_ON;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ omap2_prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
+ (omap24xx_pwrst OMAP_POWERSTATE_SHIFT),
+ pwrdm-prcm_offs, OMAP2_PM_PWSTCTRL);
+ return 0;
+}
+
+static int omap2xxx_pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
+{
+ u8 omap2xxx_pwrst;
+
+ omap2xxx_pwrst = omap2_prm_read_mod_bits_shift(pwrdm-prcm_offs,
+ OMAP2_PM_PWSTCTRL,
+ OMAP_POWERSTATE_MASK);
+
+ return omap2xxx_pwrst_to_common_pwrst(omap2xxx_pwrst);
+}
+
+static int omap2xxx_pwrdm_read_pwrst(struct powerdomain *pwrdm)
+{
+ u8 omap2xxx_pwrst;
+
+ omap2xxx_pwrst = omap2_prm_read_mod_bits_shift(pwrdm-prcm_offs,
+ OMAP2_PM_PWSTST,
+ OMAP_POWERSTATEST_MASK);
+
+ return omap2xxx_pwrst_to_common_pwrst(omap2xxx_pwrst);
+}
+
struct pwrdm_ops omap2_pwrdm_operations = {
- .pwrdm_set_next_pwrst = omap2_pwrdm_set_next_pwrst,
- .pwrdm_read_next_pwrst = omap2_pwrdm_read_next_pwrst,
- .pwrdm_read_pwrst = omap2_pwrdm_read_pwrst,
+ .pwrdm_set_next_pwrst = omap2xxx_pwrdm_set_next_pwrst,
+ .pwrdm_read_next_pwrst = omap2xxx_pwrdm_read_next_pwrst,
+ .pwrdm_read_pwrst = omap2xxx_pwrdm_read_pwrst,
.pwrdm_set_logic_retst = omap2_pwrdm_set_logic_retst,
.pwrdm_set_mem_onst = omap2_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap2_pwrdm_set_mem_retst,
diff --git
[PATCH 4/6] ARM: OMAP3xxx: CPUIdle: optimize __omap3_enter_idle()
Avoid programming the MPU and CORE powerdomain next-power-state
registers if those powerdomains will never enter low-power states
(e.g., the state that people refer to as C1).
To avoid making assumptions about CPUIdle states based on their order
in the list, use a flag to mark CPUIdle states that don't enter
powerdomain low-power states.
Avoid a previous-power-state register read on the MPU powerdomain
unless we know that the MPU was supposed to go OFF during the last
state transition. Previous-power-state register reads can be very
expensive, so it's worth avoiding these when possible.
Since the CORE_L3 clockdomain can't go inactive unless the MPU is active,
there's little point blocking autoidle on the CORE_L3 clockdomain in C1
state, since we've programmed the MPU clockdomain to stay active.
Remove the unnecessary code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 35 ++-
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 0067467..ad70220 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -39,9 +39,21 @@ struct omap3_idle_statedata {
u8 mpu_state;
u8 core_state;
u8 per_min_state;
+ u8 flags;
};
/*
+ * Possible flag bits for struct omap3_idle_statedata.flags:
+ *
+ * OMAP_CPUIDLE_CX_NO_CLKDM_IDLE: don't allow the MPU clockdomain to go
+ *inactive. This in turn prevents the MPU DPLL from entering autoidle
+ *mode, so wakeup latency is greatly reduced, at the cost of additional
+ *energy consumption. This also prevents the CORE clockdomain from
+ *entering idle.
+ */
+#define OMAP_CPUIDLE_CX_NO_CLKDM_IDLE BIT(0)
+
+/*
* Prevent PER OFF if CORE is not in RETention or OFF as this would
* disable PER wakeups completely.
*/
@@ -51,6 +63,7 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
.core_state = PWRDM_POWER_ON,
/* In C1 do not allow PER state lower than CORE state */
.per_min_state = PWRDM_POWER_ON,
+ .flags = OMAP_CPUIDLE_CX_NO_CLKDM_IDLE,
},
{
.mpu_state = PWRDM_POWER_ON,
@@ -91,27 +104,25 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
int index)
{
struct omap3_idle_statedata *cx = omap3_idle_data[index];
- u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
local_fiq_disable();
- pwrdm_set_next_pwrst(mpu_pd, mpu_state);
- pwrdm_set_next_pwrst(core_pd, core_state);
-
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
/* Deny idle for C1 */
- if (index == 0) {
+ if (cx-flags OMAP_CPUIDLE_CX_NO_CLKDM_IDLE) {
clkdm_deny_idle(mpu_pd-pwrdm_clkdms[0]);
- clkdm_deny_idle(core_pd-pwrdm_clkdms[0]);
+ } else {
+ pwrdm_set_next_pwrst(mpu_pd, cx-mpu_state);
+ pwrdm_set_next_pwrst(core_pd, cx-core_state);
}
/*
* Call idle CPU PM enter notifier chain so that
* VFP context is saved.
*/
- if (mpu_state == PWRDM_POWER_OFF)
+ if (cx-mpu_state == PWRDM_POWER_OFF)
cpu_pm_enter();
/* Execute ARM wfi */
@@ -121,17 +132,15 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
* Call idle CPU PM enter notifier chain to restore
* VFP context.
*/
- if (pwrdm_read_prev_pwrst(mpu_pd) == PWRDM_POWER_OFF)
+ if (cx-mpu_state == PWRDM_POWER_OFF
+ pwrdm_read_prev_pwrst(mpu_pd) == PWRDM_POWER_OFF)
cpu_pm_exit();
/* Re-allow idle for C1 */
- if (index == 0) {
+ if (cx-flags OMAP_CPUIDLE_CX_NO_CLKDM_IDLE)
clkdm_allow_idle(mpu_pd-pwrdm_clkdms[0]);
- clkdm_allow_idle(core_pd-pwrdm_clkdms[0]);
- }
return_sleep_time:
-
local_fiq_enable();
return index;
@@ -196,7 +205,7 @@ static int next_valid_state(struct cpuidle_device *dev,
* Start search from the next (lower) state.
*/
for (idx = index - 1; idx = 0; idx--) {
- cx = omap3_idle_data[idx];
+ cx = omap3_idle_data[idx];
if ((cx-mpu_state = mpu_deepest_state)
(cx-core_state = core_deepest_state)) {
next_index = idx;
--
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 3/6] ARM: OMAP3xxx: CPUIdle: simplify the PER next-state code
The OMAP3xxx CPUIdle driver contains some code to place a lower bound
on the PER powerdomain's power state. Convert this code to a data-driven
implementation to remove branches and to improve readability.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 44 +++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index bca7a88..0067467 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -36,38 +36,51 @@
/* Mach specific information to be recorded in the C-state driver_data */
struct omap3_idle_statedata {
- u32 mpu_state;
- u32 core_state;
+ u8 mpu_state;
+ u8 core_state;
+ u8 per_min_state;
};
+/*
+ * Prevent PER OFF if CORE is not in RETention or OFF as this would
+ * disable PER wakeups completely.
+ */
static struct omap3_idle_statedata omap3_idle_data[] = {
{
.mpu_state = PWRDM_POWER_ON,
.core_state = PWRDM_POWER_ON,
+ /* In C1 do not allow PER state lower than CORE state */
+ .per_min_state = PWRDM_POWER_ON,
},
{
.mpu_state = PWRDM_POWER_ON,
.core_state = PWRDM_POWER_ON,
+ .per_min_state = PWRDM_POWER_RET,
},
{
.mpu_state = PWRDM_POWER_RET,
.core_state = PWRDM_POWER_ON,
+ .per_min_state = PWRDM_POWER_RET,
},
{
.mpu_state = PWRDM_POWER_OFF,
.core_state = PWRDM_POWER_ON,
+ .per_min_state = PWRDM_POWER_RET,
},
{
.mpu_state = PWRDM_POWER_RET,
.core_state = PWRDM_POWER_RET,
+ .per_min_state = PWRDM_POWER_OFF,
},
{
.mpu_state = PWRDM_POWER_OFF,
.core_state = PWRDM_POWER_RET,
+ .per_min_state = PWRDM_POWER_OFF,
},
{
.mpu_state = PWRDM_POWER_OFF,
.core_state = PWRDM_POWER_OFF,
+ .per_min_state = PWRDM_POWER_OFF,
},
};
@@ -207,10 +220,9 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- int new_state_idx;
- u32 core_next_state, per_next_state = 0, per_saved_state = 0;
+ int new_state_idx, ret;
+ u8 per_next_state, per_saved_state;
struct omap3_idle_statedata *cx;
- int ret;
/*
* Use only C1 if CAM is active.
@@ -231,25 +243,13 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
/* Program PER state */
cx = omap3_idle_data[new_state_idx];
- core_next_state = cx-core_state;
- per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
- if (new_state_idx == 0) {
- /* In C1 do not allow PER state lower than CORE state */
- if (per_next_state core_next_state)
- per_next_state = core_next_state;
- } else {
- /*
-* Prevent PER OFF if CORE is not in RETention or OFF as this
-* would disable PER wakeups completely.
-*/
- if ((per_next_state == PWRDM_POWER_OFF)
- (core_next_state PWRDM_POWER_RET))
- per_next_state = PWRDM_POWER_RET;
- }
- /* Are we changing PER target state? */
- if (per_next_state != per_saved_state)
+ per_next_state = pwrdm_read_next_pwrst(per_pd);
+ per_saved_state = per_next_state;
+ if (per_next_state cx-per_min_state) {
+ per_next_state = cx-per_min_state;
pwrdm_set_next_pwrst(per_pd, per_next_state);
+ }
ret = omap3_enter_idle(dev, drv, new_state_idx);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] ARM: OMAP4: MPUSS PM: remove unnecessary shim functions for powerdomain control
The OMAP4 MPU subsystem power management code contains several unnecessary
shim functions for powerdomain control; remove them.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 43 +
1 file changed, 7 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 3f5fd7e..80d4742 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -86,37 +86,6 @@ static inline void set_cpu_wakeup_addr(unsigned int cpu_id,
u32 addr)
}
/*
- * Set the CPUx powerdomain's previous power state
- */
-static inline void set_cpu_next_pwrst(unsigned int cpu_id,
- unsigned int power_state)
-{
- struct omap4_cpu_pm_info *pm_info = per_cpu(omap4_pm_info, cpu_id);
-
- pwrdm_set_next_pwrst(pm_info-pwrdm, power_state);
-}
-
-/*
- * Read CPU's previous power state
- */
-static inline unsigned int read_cpu_prev_pwrst(unsigned int cpu_id)
-{
- struct omap4_cpu_pm_info *pm_info = per_cpu(omap4_pm_info, cpu_id);
-
- return pwrdm_read_prev_pwrst(pm_info-pwrdm);
-}
-
-/*
- * Clear the CPUx powerdomain's previous power state
- */
-static inline void clear_cpu_prev_pwrst(unsigned int cpu_id)
-{
- struct omap4_cpu_pm_info *pm_info = per_cpu(omap4_pm_info, cpu_id);
-
- pwrdm_clear_all_prev_pwrst(pm_info-pwrdm);
-}
-
-/*
* Store the SCU power status value to scratchpad memory
*/
static void scu_pwrst_prepare(unsigned int cpu_id, unsigned int cpu_state)
@@ -229,6 +198,7 @@ static void save_l2x0_context(void)
*/
int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
{
+ struct omap4_cpu_pm_info *pm_info = per_cpu(omap4_pm_info, cpu);
unsigned int save_state = 0;
unsigned int wakeup_cpu;
@@ -267,7 +237,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
save_state = 2;
cpu_clear_prev_logic_pwrst(cpu);
- set_cpu_next_pwrst(cpu, power_state);
+ pwrdm_set_next_pwrst(pm_info-pwrdm, power_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
scu_pwrst_prepare(cpu, power_state);
l2x0_pwrst_prepare(cpu, save_state);
@@ -285,7 +255,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
* domain transition
*/
wakeup_cpu = smp_processor_id();
- set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON);
+ pwrdm_set_next_pwrst(pm_info-pwrdm, PWRDM_POWER_ON);
pwrdm_post_transition(NULL);
@@ -299,6 +269,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
*/
int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
{
+ struct omap4_cpu_pm_info *pm_info = per_cpu(omap4_pm_info, cpu);
unsigned int cpu_state = 0;
if (omap_rev() == OMAP4430_REV_ES1_0)
@@ -307,8 +278,8 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned
int power_state)
if (power_state == PWRDM_POWER_OFF)
cpu_state = 1;
- clear_cpu_prev_pwrst(cpu);
- set_cpu_next_pwrst(cpu, power_state);
+ pwrdm_clear_all_prev_pwrst(pm_info-pwrdm);
+ pwrdm_set_next_pwrst(pm_info-pwrdm, power_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(omap_secondary_startup));
scu_pwrst_prepare(cpu, power_state);
@@ -319,7 +290,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned
int power_state)
*/
omap4_finish_suspend(cpu_state);
- set_cpu_next_pwrst(cpu, PWRDM_POWER_ON);
+ pwrdm_set_next_pwrst(pm_info-pwrdm, PWRDM_POWER_ON);
return 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
[PATCH 6/6] ARM: OMAP2+: powerdomain: fix powerdomain trace integration
From: Jean Pihet jean.pi...@newoldbits.com
Fix the trace in the case a power domain did not hit the desired
state, as reported by Paul Walmsley.
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Jean Pihet j-pi...@ti.com
[p...@pwsan.com: split this fix off from the patch
ARM: OMAP2+: PM debug: trace the functional power domains states]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomain.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index dea62a9..92388c0 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -143,7 +143,7 @@ static void _update_logic_membank_counters(struct
powerdomain *pwrdm)
static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
{
- int prev, state, trace_state = 0;
+ int prev, next, state, trace_state = 0;
if (pwrdm == NULL)
return -EINVAL;
@@ -164,9 +164,10 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
int flag)
* If the power domain did not hit the desired state,
* generate a trace event with both the desired and hit states
*/
- if (state != prev) {
+ next = pwrdm_read_next_pwrst(pwrdm);
+ if (next != prev) {
trace_state = (PWRDM_TRACE_STATES_FLAG |
- ((state OMAP_POWERSTATE_MASK) 8) |
+ ((next OMAP_POWERSTATE_MASK) 8) |
((prev OMAP_POWERSTATE_MASK) 0));
trace_power_domain_target(pwrdm-name, trace_state,
smp_processor_id());
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: OMAP4: MPUSS PM: remove unnecessary shim functions for powerdomain control
On Saturday 24 November 2012 09:12 AM, Paul Walmsley wrote: The OMAP4 MPU subsystem power management code contains several unnecessary shim functions for powerdomain control; remove them. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com --- Most of them are inline functions so final object code will mostly same after and before the patch. But cleaning these helpers is better I guess. So.. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
