[PATCH] spi: omap2_mcspi: Make the runtime functions depend on CONFIG_PM_RUNTIME
Makes the function omap_mcspi_runtime_resume depend on CONFIG_PM_RUNTIME.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 41 +++--
1 files changed, 23 insertions(+), 18 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index cb2c0e3..f9d694d 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -248,23 +248,6 @@ static void omap2_mcspi_set_master_mode(struct spi_master
*master)
omap2_mcspi_ctx[master-bus_num - 1].modulctrl = l;
}
-static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
-{
- struct spi_master *spi_cntrl;
- struct omap2_mcspi_cs *cs;
- spi_cntrl = mcspi-master;
-
- /* McSPI: context restore */
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
- omap2_mcspi_ctx[spi_cntrl-bus_num - 1].modulctrl);
-
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
- omap2_mcspi_ctx[spi_cntrl-bus_num - 1].wakeupenable);
-
- list_for_each_entry(cs, omap2_mcspi_ctx[spi_cntrl-bus_num - 1].cs,
- node)
- __raw_writel(cs-chconf0, cs-base + OMAP2_MCSPI_CHCONF0);
-}
static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
{
pm_runtime_put_sync(mcspi-dev);
@@ -1066,6 +1049,26 @@ static int __init omap2_mcspi_master_setup(struct
omap2_mcspi *mcspi)
return 0;
}
+#ifdef CONFIG_PM_RUNTIME
+static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
+{
+ struct spi_master *spi_cntrl;
+ struct omap2_mcspi_cs *cs;
+
+ spi_cntrl = mcspi-master;
+
+ /* McSPI: context restore */
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].modulctrl);
+
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].wakeupenable);
+
+ list_for_each_entry(cs, omap2_mcspi_ctx[spi_cntrl-bus_num - 1].cs,
+ node)
+ __raw_writel(cs-chconf0, cs-base + OMAP2_MCSPI_CHCONF0);
+}
+
static int omap_mcspi_runtime_resume(struct device *dev)
{
struct omap2_mcspi *mcspi;
@@ -1077,7 +1080,9 @@ static int omap_mcspi_runtime_resume(struct device *dev)
return 0;
}
-
+#else
+#defineomap_mcspi_runtime_resume NULL
+#endif
static int __devinit omap2_mcspi_probe(struct platform_device *pdev)
{
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Add TWL4030 PWM driver
Am 20.03.12 23:02, schrieb Arnd Bergmann: On Tuesday 20 March 2012, Bernhard Walle wrote: This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030 PWM has been used as mode, but the PWM registers are different. The driver can be used and has been tested in conjunction with pwm-backlight to control a backlight LED of a LCD touch screen. Signed-off-by: Bernhard Walle wa...@corscience.de Since it's too late for v3.4 now and we will get a new pwm subsystem in v3.5, I suggest you change the driver to work register with that subsystem instead of just using the old header file. Note that drivers/mfd is not really the right place anyway, because this is not a multifunction driver but just one device driver that happens to be a slave of an mfd. Does that new subsystem already exist in some tree? Regards, Bernhard -- 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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Tue, Mar 20, 2012 at 9:25 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Mar 20, 2012 at 04:53:53PM +0100, Samuel Ortiz wrote: Hi Keshava, On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Felipe, are you ok with that patch ? I'll most likely queue it after this merge window is closed though. my bad, here's my Ack: Acked-by: Felipe Balbi ba...@ti.com -- balbi thanks , Felipe regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] MFD: OMAP: USB: Make the runtime functions depend on CONFIG_PM_RUNTIME
Currently the runtime functions are compiled regardless
of CONFIG_PM_RUNTIME flag. This patch intends to fix the same by
using SET_RUNTIME_PM_OPS.
Reviewed-by: Kevin Hilman khil...@ti.com
Cc : Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/mfd/omap-usb-host.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 68ac2c5..f8fdd5f 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -422,6 +422,7 @@ static void usbhs_omap_tll_init(struct device *dev, u8
tll_channel_count)
}
}
+#ifdef CONFIG_PM_RUNTIME
static int usbhs_runtime_resume(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
@@ -489,6 +490,7 @@ static int usbhs_runtime_suspend(struct device *dev)
return 0;
}
+#endif
static void omap_usbhs_init(struct device *dev)
{
@@ -881,8 +883,8 @@ static int __devexit usbhs_omap_remove(struct
platform_device *pdev)
}
static const struct dev_pm_ops usbhsomap_dev_pm_ops = {
- .runtime_suspend= usbhs_runtime_suspend,
- .runtime_resume = usbhs_runtime_resume,
+ SET_RUNTIME_PM_OPS(usbhs_runtime_suspend,
+ usbhs_runtime_resume, NULL)
};
static struct platform_driver usbhs_omap_driver = {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/3] Documentation: common clk API
Hello Nico, On Tue, 20 Mar 2012, Nicolas Pitre wrote: This common clk API has been under development for over *two* years already, with several attempts to merge it. And each previous merge attempt aborted because someone came along at the last minute to do exactly what you are doing i.e. underline all the flaws and call for a redesign. This is becoming a bad joke. There is a misunderstanding. I am not calling for a redesign. I am simply stating that the current maturity level of the API and code should be documented in the Kconfig dependencies or description text before the code goes upstream. The objectives are to make future changes easier, set expectations, and clearly disclose the extent to which the API and code will need to change. The code will be easier to change once it is in mainline, simply due to the fact that you can also change all its users at once. And it is well possible that most users won't have to deal with the same magnitude of complexity as yours, again reducing the scope for resistance to changes. I hope you are right. To me, these conclusions seem unlikely. It seems equally likely that these rationales will make it much more difficult to change the code once it's upstream and platforms are depending on it. Particularly given the ongoing sensitivity to reducing churn of mainline code, so publicly discussed. So it seems like a good idea to attempt to address these potential roadblocks and criticisms to major clock framework changes early. And APIs in the Linux kernel do change all the time. There is no stable API in the kernel. Extensions will come about eventually, and existing users (simple ones by definition if the current API already meets their needs) should be converted over easily. Yes, simple extensions should be straightforward. Of greater concern are changes to the existing interface that will probably be required. These could involve significant changes to driver or platform code. It seems likely that there will be strong inertia to making these changes after platforms and drivers are converted. However, if we clearly state that these API changes are likely until the API is well-defined, we will hopefully reduce some angst by disclosing what some of us know. ... One last comment to address which is orthogonal to the technical content of this discussion. Otherwise one might ask where were you during those development years if you claim that the behavior and/or API of the common clock code still need to change significantly? One might ask this. If one were to ask this, another might briefly outline the participation in public and private clock discussions at Linaro Connect in Budapest and Redwood Shores, at LPC in Santa Rosa, at ELCE/KS in Prague, at ELC in Redwood Shores, in conference calls, IRC sessions, and private E-mails with many of the people included in the header of this message, not to mention the list posts. None of the concerns that have been described are new. There has been an endeavour to discuss them with anyone who seemed even remotely interested. Of course it is a personal source of regret that the participation could not have been greater, but this regret is hardly limited to the common clock project. regards, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
IVA and SGX not getting detected on 3630 ES1.2
Hi, I have a freshly built beagleboard xM on my desk which is giving me some trouble: xM revision A: [0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) new xM revision C: [0.00] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk ) So the IVA and SGX aren't getting detected, while they *are* present. Any hints where I should look to debug this? regards, Koen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/3] Documentation: common clk API
Hello Saravana, On Tue, 20 Mar 2012, Saravana Kannan wrote: To add a few more thoughts, while I agree with Paul that there is room for improvement in the APIs, I think the difference in opinion comes when we ask the question: When we eventually refine the APIs in the future to be more expressive, do we think that the current APIs can or cannot be made as wrappers around the new more expressive APIs? Absolutes are almost never right, so I can't give an absolute answer. But I'm strongly leaning towards we can as the answer to the question. That combined with the reasons Nicholas mentioned is why I think the APIs should not be marked as experimental in anyway. The resistance to documenting that the clock interface is not well-defined, and that therefore it is likely to change, and that users should not expect it to be stable, is perplexing to me. Certainly a Kconfig help text change seems trivial enough. But even the resistance to CONFIG_EXPERIMENTAL has been quite surprising to me, given that every single defconfig in arch/arm/defconfig sets it: $ find arch/arm/configs -type f | wc -l 122 $ fgrep -r CONFIG_EXPERIMENTAL=y arch/arm/configs | wc -l 122 $ (that includes iMX, by the way...) Certainly, neither Kconfig change is going to prevent us on OMAP from figuring out what else is needed to convert our platform to the common clock code. And given the level of enthusiasm on the lists, I don't think it's going to prevent many of the other ARM platforms from experimenting with the conversion, either. So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3+: fix oops triggered in omap_prcm_register_chain_handler
On Wed, 2012-03-21 at 12:49 +0800, Ming Lei wrote:
This patch fixes the oos below:
[1.790242] Unable to handle kernel NULL pointer dereference at virtual
address 0004
[1.798632] pgd = c0004000
[1.801638] [0004] *pgd=
[1.805400] Internal error: Oops: 805 [#1] PREEMPT SMP THUMB2
[1.811381] Modules linked in:
[1.814601] CPU: 1Not tainted (3.3.0-next-20120320+ #733)
[1.820683] PC is at irq_setup_generic_chip+0x6a/0x84
[1.825951] LR is at irq_get_irq_data+0x7/0x8
[1.830508] pc : [c006465e]lr : [c0063a03]psr: 2133
[1.830512] sp : ee04ff58 ip : fp :
[1.842461] r10: r9 : r8 : 0800
[1.847905] r7 : c064e260 r6 : 01dc r5 : 0001 r4 : ee0accc0
[1.854687] r3 : 0002 r2 : 0800 r1 : 01dc r0 :
[1.861472] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment
kernel
[1.869234] Control: 50c5387d Table: 8000404a DAC: 0015
[1.875215] Process swapper/0 (pid: 1, stack limit = 0xee04e2f8)
[1.881463] Stack: (0xee04ff58 to 0xee05)
[1.886017] ff40: c061b668 0008
[1.894497] ff60: c0682090 ee0accc0 0003 c001c637
0201
[1.902976] ff80: 0004 c0473820 c0473800 c0459e8d c0680ac0 c000866d
0004 0004
[1.911455] ffa0: ee04ffa8 0004 c047381c 0004 c0473820 c0473800
c0680ac0 0082
[1.919934] ffc0: c0489694 c045265f 0004 0004 c0452135 c000d105
0033
[1.928413] ffe0: c04525b5 c000d111 0033 c000d111
[1.936912] [c006465e] (irq_setup_generic_chip+0x6a/0x84) from
[c001c637] (omap_prcm_register_chain_handler+0x147/0x1a0)
[1.948516] [c001c637] (omap_prcm_register_chain_handler+0x147/0x1a0)
from [c000866d] (do_one_initcall+0x65/0xf4)
[1.959500] [c000866d] (do_one_initcall+0x65/0xf4) from [c045265f]
(kernel_init+0xab/0x138)
[1.968529] [c045265f] (kernel_init+0xab/0x138) from [c000d111]
(kernel_thread_exit+0x1/0x6)
[1.977632] Code: f7ff f9d1 6b23 1af3 (6043) 086d
[1.982684] ---[ end trace 1b75b31a2719ed1c ]---
[1.987526] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Ming Lei tom.leim...@gmail.com
---
arch/arm/mach-omap2/prm_common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prm_common.c
b/arch/arm/mach-omap2/prm_common.c
index 873b51d..d28f848 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -290,7 +290,7 @@ int omap_prcm_register_chain_handler(struct
omap_prcm_irq_setup *irq_setup)
goto err;
}
- for (i = 0; i = irq_setup-nr_regs; i++) {
+ for (i = 0; i irq_setup-nr_regs; i++) {
gc = irq_alloc_generic_chip(PRCM, 1,
irq_setup-base_irq + i * 32, prm_base,
handle_level_irq);
Wow, I feel ashamed now. Best thing is it is correctly elsewhere in
code. :) You could probably write a better changelog for this but other
than that, acked.
-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
Food shaped and fruit shaped USB drives
Hello, we are factory in China. we offer USB flash drives USB2.0 and USB3.0 LOGO printed for free. Hope can help you Thanks John -- 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] mfd: Add TWL4030 PWM driver
On Wednesday 21 March 2012, Bernhard Walle wrote: Am 20.03.12 23:02, schrieb Arnd Bergmann: On Tuesday 20 March 2012, Bernhard Walle wrote: This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030 PWM has been used as mode, but the PWM registers are different. The driver can be used and has been tested in conjunction with pwm-backlight to control a backlight LED of a LCD touch screen. Signed-off-by: Bernhard Walle wa...@corscience.de Since it's too late for v3.4 now and we will get a new pwm subsystem in v3.5, I suggest you change the driver to work register with that subsystem instead of just using the old header file. Note that drivers/mfd is not really the right place anyway, because this is not a multifunction driver but just one device driver that happens to be a slave of an mfd. Does that new subsystem already exist in some tree? Thierry Reding has been busily posting patches, so he probably has one that you can use, but I couldn't find it now. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Add TWL4030 PWM driver
* Arnd Bergmann wrote: On Wednesday 21 March 2012, Bernhard Walle wrote: Am 20.03.12 23:02, schrieb Arnd Bergmann: On Tuesday 20 March 2012, Bernhard Walle wrote: This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030 PWM has been used as mode, but the PWM registers are different. The driver can be used and has been tested in conjunction with pwm-backlight to control a backlight LED of a LCD touch screen. Signed-off-by: Bernhard Walle wa...@corscience.de Since it's too late for v3.4 now and we will get a new pwm subsystem in v3.5, I suggest you change the driver to work register with that subsystem instead of just using the old header file. Note that drivers/mfd is not really the right place anyway, because this is not a multifunction driver but just one device driver that happens to be a slave of an mfd. Does that new subsystem already exist in some tree? Thierry Reding has been busily posting patches, so he probably has one that you can use, but I couldn't find it now. I don't have a public tree anywhere. Does anyone have a recommendation where I could set one up? github or gitorious are the first to come to my mind. Thierry pgpPaZGkm9Iu7.pgp Description: PGP signature
Re: [PATCH v7 1/3] Documentation: common clk API
On Wed, Mar 21, 2012 at 01:44:01AM -0600, Paul Walmsley wrote: Hello Saravana, Certainly a Kconfig help text change seems trivial enough. But even the resistance to CONFIG_EXPERIMENTAL has been quite surprising to me, given that every single defconfig in arch/arm/defconfig sets it: $ find arch/arm/configs -type f | wc -l 122 $ fgrep -r CONFIG_EXPERIMENTAL=y arch/arm/configs | wc -l 122 $ (that includes iMX, by the way...) Certainly, neither Kconfig change is going to prevent us on OMAP from figuring out what else is needed to convert our platform to the common clock code. And given the level of enthusiasm on the lists, I don't think it's going to prevent many of the other ARM platforms from experimenting with the conversion, either. So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful. Mainly because COMMON_CLK is an invisible option which has to be selected by architectures. So with the Kconfig change we either have to: config ARCH_MXC depends on EXPERIMENTAL or: config ARCH_MXC select EXPERIMENTAL select COMMON_CLK Neither of both seems very appealing to me. You can add a warning to the Kconfig help text if you like, I have no problem with that. As you said it will prevent noone from using it anyway. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 0/7] OMAP4 cpuidle cleanup
This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. A couple a things call my intention. Why the cpuidle device is set for cpu0 only and why the WFI is not used ? Daniel Lezcano (7): ARM: OMAP4: cpuidle - Remove unused valid field ARM: OMAP4: cpuidle - Declare the states with the driver declaration ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time arch/arm/mach-omap2/cpuidle44xx.c | 126 - 1 files changed, 54 insertions(+), 72 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 1/7] ARM: OMAP4: cpuidle - Remove unused valid field
The 'valid' field is never used in the code, let's remove it.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index cfdbb86..1210229 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -29,16 +29,15 @@ struct omap4_idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
- u8 valid;
};
static struct cpuidle_params cpuidle_params_table[] = {
/* C1 - CPU0 ON + CPU1 ON + MPU ON */
- {.exit_latency = 2 + 2 , .target_residency = 5, .valid = 1},
+ {.exit_latency = 2 + 2 , .target_residency = 5 },
/* C2- CPU0 OFF + CPU1 OFF + MPU CSWR */
- {.exit_latency = 328 + 440 , .target_residency = 960, .valid = 1},
+ {.exit_latency = 328 + 440 , .target_residency = 960 },
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
- {.exit_latency = 460 + 518 , .target_residency = 1100, .valid = 1},
+ {.exit_latency = 460 + 518 , .target_residency = 1100 },
};
#define OMAP4_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
@@ -171,7 +170,6 @@ static inline struct omap4_idle_statedata
*_fill_cstate_usage(
struct omap4_idle_statedata *cx = omap4_idle_data[idx];
struct cpuidle_state_usage *state_usage = dev-states_usage[idx];
- cx-valid = cpuidle_params_table[idx].valid;
cpuidle_set_statedata(state_usage, cx);
return cx;
@@ -207,7 +205,6 @@ int __init omap4_idle_init(void)
_fill_cstate(drv, 0, MPUSS ON);
drv-safe_state_index = 0;
cx = _fill_cstate_usage(dev, 0);
- cx-valid = 1; /* C1 is always valid */
cx-cpu_state = PWRDM_POWER_ON;
cx-mpu_state = PWRDM_POWER_ON;
cx-mpu_logic_state = PWRDM_POWER_RET;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 2/7] ARM: OMAP4: cpuidle - Declare the states with the driver declaration
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c | 56 +
1 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 1210229..cd6bee7 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -148,21 +148,38 @@ DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
struct cpuidle_driver omap4_idle_driver = {
.name = omap4_idle,
.owner =THIS_MODULE,
+ .states = {
+ {
+ /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = C1,
+ .desc = MPUSS ON
+ },
+ {
+/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
+ .exit_latency = 328 + 440,
+ .target_residency = 960,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = C2,
+ .desc = MPUSS CSWR,
+ },
+ {
+ /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
+ .exit_latency = 460 + 518,
+ .target_residency = 1100,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = C3,
+ .desc = MPUSS OSWR,
+ },
+ },
+ .state_count = OMAP4_NUM_STATES,
};
-static inline void _fill_cstate(struct cpuidle_driver *drv,
- int idx, const char *descr)
-{
- struct cpuidle_state *state = drv-states[idx];
-
- state-exit_latency = cpuidle_params_table[idx].exit_latency;
- state-target_residency = cpuidle_params_table[idx].target_residency;
- state-flags= CPUIDLE_FLAG_TIME_VALID;
- state-enter= omap4_enter_idle;
- sprintf(state-name, C%d, idx + 1);
- strncpy(state-desc, descr, CPUIDLE_DESC_LEN);
-}
-
static inline struct omap4_idle_statedata *_fill_cstate_usage(
struct cpuidle_device *dev,
int idx)
@@ -196,37 +213,28 @@ int __init omap4_idle_init(void)
if ((!mpu_pd) || (!cpu0_pd) || (!cpu1_pd))
return -ENODEV;
-
- drv-safe_state_index = -1;
dev = per_cpu(omap4_idle_dev, cpu_id);
dev-cpu = cpu_id;
- /* C1 - CPU0 ON + CPU1 ON + MPU ON */
- _fill_cstate(drv, 0, MPUSS ON);
- drv-safe_state_index = 0;
cx = _fill_cstate_usage(dev, 0);
cx-cpu_state = PWRDM_POWER_ON;
cx-mpu_state = PWRDM_POWER_ON;
cx-mpu_logic_state = PWRDM_POWER_RET;
- /* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
- _fill_cstate(drv, 1, MPUSS CSWR);
cx = _fill_cstate_usage(dev, 1);
cx-cpu_state = PWRDM_POWER_OFF;
cx-mpu_state = PWRDM_POWER_RET;
cx-mpu_logic_state = PWRDM_POWER_RET;
- /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
- _fill_cstate(drv, 2, MPUSS OSWR);
cx = _fill_cstate_usage(dev, 2);
cx-cpu_state = PWRDM_POWER_OFF;
cx-mpu_state = PWRDM_POWER_RET;
cx-mpu_logic_state = PWRDM_POWER_OFF;
- drv-state_count = OMAP4_NUM_STATES;
cpuidle_register_driver(omap4_idle_driver);
- dev-state_count = OMAP4_NUM_STATES;
+ dev-state_count = drv-state_count;
+
if (cpuidle_register_device(dev)) {
pr_err(%s: CPUidle register device failed\n, __func__);
return -EIO;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 3/7] ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table
We do not longer need this table as we defined the values
in the driver states.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index cd6bee7..0455858 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -31,16 +31,7 @@ struct omap4_idle_statedata {
u32 mpu_state;
};
-static struct cpuidle_params cpuidle_params_table[] = {
- /* C1 - CPU0 ON + CPU1 ON + MPU ON */
- {.exit_latency = 2 + 2 , .target_residency = 5 },
- /* C2- CPU0 OFF + CPU1 OFF + MPU CSWR */
- {.exit_latency = 328 + 440 , .target_residency = 960 },
- /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
- {.exit_latency = 460 + 518 , .target_residency = 1100 },
-};
-
-#define OMAP4_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
+#define OMAP4_NUM_STATES 3
struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 4/7] ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 0455858..254f97b 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -33,7 +33,7 @@ struct omap4_idle_statedata {
#define OMAP4_NUM_STATES 3
-struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
+static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
/**
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 5/7] ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 254f97b..e14cd56 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -33,7 +33,24 @@ struct omap4_idle_statedata {
#define OMAP4_NUM_STATES 3
-static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
+static struct omap4_idle_statedata omap4_idle_data[] = {
+ {
+ .cpu_state = PWRDM_POWER_ON,
+ .mpu_state = PWRDM_POWER_ON,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+ {
+ .cpu_state = PWRDM_POWER_OFF,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+ {
+ .cpu_state = PWRDM_POWER_OFF,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_OFF,
+ },
+};
+
static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
/**
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 6/7] ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
We are storing the 'omap4_idle_data' in the private data field
if the cpuidle device. As we are using this variable only in this file,
that does not really make sense. Let's use the global variable directly
instead dereferencing pointers in an idle critical loop.
Also, that simplfies the code.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c | 17 +
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index e14cd56..cb91d1f 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -24,7 +24,7 @@
#ifdef CONFIG_CPU_IDLE
-/* Machine specific information to be recorded in the C-state driver_data */
+/* Machine specific information */
struct omap4_idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
@@ -67,8 +67,7 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct omap4_idle_statedata *cx =
- cpuidle_get_statedata(dev-states_usage[index]);
+ struct omap4_idle_statedata *cx = omap4_idle_data[index];
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 cpu1_state;
int idle_time;
@@ -92,7 +91,7 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
cpu1_state = pwrdm_read_pwrst(cpu1_pd);
if (cpu1_state != PWRDM_POWER_OFF) {
new_state_idx = drv-safe_state_index;
- cx = cpuidle_get_statedata(dev-states_usage[new_state_idx]);
+ cx = omap4_idle_data[new_state_idx]
}
if (index 0)
@@ -193,15 +192,9 @@ static inline struct omap4_idle_statedata
*_fill_cstate_usage(
int idx)
{
struct omap4_idle_statedata *cx = omap4_idle_data[idx];
- struct cpuidle_state_usage *state_usage = dev-states_usage[idx];
-
- cpuidle_set_statedata(state_usage, cx);
-
return cx;
}
-
-
/**
* omap4_idle_init - Init routine for OMAP4 idle
*
@@ -210,9 +203,9 @@ static inline struct omap4_idle_statedata
*_fill_cstate_usage(
*/
int __init omap4_idle_init(void)
{
- struct omap4_idle_statedata *cx;
- struct cpuidle_device *dev;
+ struct omap4_idle_statedata *cx = omap4_idle_data[index];
struct cpuidle_driver *drv = omap4_idle_driver;
+ struct cpuidle_device *dev;
unsigned int cpu_id = 0;
mpu_pd = pwrdm_lookup(mpu_pwrdm);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 7/7] ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time
We initialized it at compile time, no need to do that at boot
time.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c | 26 +-
1 files changed, 1 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index cb91d1f..fd220f9 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -33,7 +33,7 @@ struct omap4_idle_statedata {
#define OMAP4_NUM_STATES 3
-static struct omap4_idle_statedata omap4_idle_data[] = {
+static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES] = {
{
.cpu_state = PWRDM_POWER_ON,
.mpu_state = PWRDM_POWER_ON,
@@ -187,14 +187,6 @@ struct cpuidle_driver omap4_idle_driver = {
.state_count = OMAP4_NUM_STATES,
};
-static inline struct omap4_idle_statedata *_fill_cstate_usage(
- struct cpuidle_device *dev,
- int idx)
-{
- struct omap4_idle_statedata *cx = omap4_idle_data[idx];
- return cx;
-}
-
/**
* omap4_idle_init - Init routine for OMAP4 idle
*
@@ -203,7 +195,6 @@ static inline struct omap4_idle_statedata
*_fill_cstate_usage(
*/
int __init omap4_idle_init(void)
{
- struct omap4_idle_statedata *cx = omap4_idle_data[index];
struct cpuidle_driver *drv = omap4_idle_driver;
struct cpuidle_device *dev;
unsigned int cpu_id = 0;
@@ -217,21 +208,6 @@ int __init omap4_idle_init(void)
dev = per_cpu(omap4_idle_dev, cpu_id);
dev-cpu = cpu_id;
- cx = _fill_cstate_usage(dev, 0);
- cx-cpu_state = PWRDM_POWER_ON;
- cx-mpu_state = PWRDM_POWER_ON;
- cx-mpu_logic_state = PWRDM_POWER_RET;
-
- cx = _fill_cstate_usage(dev, 1);
- cx-cpu_state = PWRDM_POWER_OFF;
- cx-mpu_state = PWRDM_POWER_RET;
- cx-mpu_logic_state = PWRDM_POWER_RET;
-
- cx = _fill_cstate_usage(dev, 2);
- cx-cpu_state = PWRDM_POWER_OFF;
- cx-mpu_state = PWRDM_POWER_RET;
- cx-mpu_logic_state = PWRDM_POWER_OFF;
-
cpuidle_register_driver(omap4_idle_driver);
dev-state_count = drv-state_count;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. Thanks. Will have a look at your series. A couple a things call my intention. Why the cpuidle device is set for cpu0 only Because the mainline code CPUIDLE is supported along with CPUhotplug. This is going to change though with Couple CPUIDLE and corresponding OMAP updates. and why the WFI is not used ? I didn't get this question. Do you mean the generic WFI? If yes, then, it's mainly because OMAP need additional custom barriers. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/7] ARM: OMAP4: cpuidle - Remove unused valid field
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: The 'valid' field is never used in the code, let's remove it. Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org --- It is used during the registration. This field has been very useful for debug when need to disable a C-state etc. So unless and until there is a strong reason, i would like to retain it. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/7] ARM: OMAP4: cpuidle - Remove unused valid field
On 03/21/2012 10:41 AM, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: The 'valid' field is never used in the code, let's remove it. Signed-off-by: Daniel Lezcanodaniel.lezc...@linaro.org --- It is used during the registration. This field has been very useful for debug when need to disable a C-state etc. So unless and until there is a strong reason, i would like to retain it. IMO if it used for debug purpose, it should be moved to the debug code and if the debug code is not upstream, then that 'valid' should not be here but in the out-of-tree code. By the way, this may be a debate for nothing because a patchset is on the way to disable C-states from sysfs. -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/7] ARM: OMAP4: cpuidle - Declare the states with the driver declaration
+ Jean, On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote: The cpuidle API allows to declare statically the states in the driver structure. Let's use it. We do no longer need the fill_cstate function called at runtime and by the way adding more instructions at boot time. Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org --- Jean added the fill_cstate() kind of helpers o.w in the old cpuidle code9OMAP30, static tables were used. Ofcourse those tables were not uinsg the cpuidle driver structure. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/3] OMAPDSS: DISPC: Enable predecimation for DMA and VRFB
Hi everyone, the following patch set directs to enable predecimation for DMA and VRFB which consists of two pacthes. The first patch is based on code written by Lajos Molnar la...@ti.com in Android Kernel, which updates the code with predecimation logic thereby increasing the downscaling ability of the DISPC module. In version 2 patch description has been modified include reason for maximum predecimation limit of 16. The second patch is based on code written by Ville Syrjälä ville.syrj...@nokia.com which aims to avoid synclost errors occurring in OMAP3 due to some undocumented horizontal position and timing related limitations which I faced during testing of the previous patch. In version 2 the pcd factor has been replaced lclk / pclk to support HDMI and tv output as pointed out by Ville Syrjälä. The third patch corrects the usage of dispc fclk in scaling checks by replacing it with dispc_core_clk as per suggestions of Ville Syrjälä. I have tested these patches successfully on OMAP2, OMAP3 AND OMAP4 on the mainline kernel v3.3. Horizontal and vertical predecimation worked fine but skewed images were seen on OMAP2 and OMAP3 on HDMI tv during horizontal predecimation which will be addressed in the future patches. All your comments and suggestions are welcome. Regards, Chandrabhanu Chandrabhanu Mahapatra (3): OMAPDSS: DISPC: Enable predecimation OMAPDSS: DISPC: Handle synclost errors in OMAP3 OMAPDSS: DISPC: Correct DISPC functional clock usage drivers/video/omap2/dss/dispc.c | 360 +++ 1 files changed, 254 insertions(+), 106 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
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. Thanks. Will have a look at your series. Cool, thanks. A couple a things call my intention. Why the cpuidle device is set for cpu0 only Because the mainline code CPUIDLE is supported along with CPUhotplug. This is going to change though with Couple CPUIDLE and corresponding OMAP updates. Ok, thanks for the information. I will look deeper. What happens to cpu1 when it is online and has nothing to do ? and why the WFI is not used ? I didn't get this question. Do you mean the generic WFI? yes. If yes, then, it's mainly because OMAP need additional custom barriers. Ah, ok. I am not sure if it is possible but that may be cool if we can call cpu_do_idle instead with additional barrier. -- 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 -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ 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 V2 1/3] OMAPDSS: DISPC: Enable predecimation
In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times, and
up to 2 times in OMAP2. However, with predecimation, the image can be reduced
to 16 times by fetching only the necessary pixels in memory. Then this
predecimated image can be downscaled further by the DISPC scaler.
The pipeline is configured to use a burst of size 8 * 128 bits which consists
of 8 mini bursts of 16 bytes each. So, horizontal predecimation more than 16
can lead to complete discarding of such mini bursts. L3 interconnect may
handover the bus to some other initiator and inturn delay the fetching of
pixels leading to underflows. So, maximum predecimation limit is fixed at 16.
Based on the downscaling required, a prior calculation of predecimation values
for width and height of an image is done. Since, Predecimation reduces quality
of an image higher priorty is given to DISPC Scaler for downscaling.
This code was successfully tested on OMAP2, OMAP3 and OMAP4. Horizontal and
vertical predecimation worked fine except for some synclost errors due to
undocumented errata in OMAP3 which are fixed later and skewed images were seen
on OMAP2 and OMAP3 during horizontal predecimation which will be addressed in
the future patches.
This code is based on code written by Lajos Molnar la...@ti.com who had added
predecimation support for NV12/YUV/rotated/SDMA buffers.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 262 +++
1 files changed, 181 insertions(+), 81 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e1626a1..5a1963e 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1389,7 +1389,7 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool
mirror,
enum omap_color_mode color_mode, bool fieldmode,
unsigned int field_offset,
unsigned *offset0, unsigned *offset1,
- s32 *row_inc, s32 *pix_inc)
+ s32 *row_inc, s32 *pix_inc, int x_predecim, int y_predecim)
{
u8 ps;
@@ -1435,10 +1435,10 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool
mirror,
else
*offset0 = 0;
- *row_inc = pixinc(1 + (screen_width - width) +
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 +
+ (y_predecim * screen_width - x_predecim * width) +
+ (fieldmode ? screen_width : 0), ps);
+ *pix_inc = pixinc(x_predecim, ps);
break;
case OMAP_DSS_ROT_0 + 4:
@@ -1456,10 +1456,10 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool
mirror,
*offset0 = field_offset * screen_width * ps;
else
*offset0 = 0;
- *row_inc = pixinc(1 - (screen_width + width) -
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 -
+ (y_predecim * screen_width + x_predecim * width) -
+ (fieldmode ? screen_width : 0), ps);
+ *pix_inc = pixinc(x_predecim, ps);
break;
default:
@@ -1473,7 +1473,7 @@ static void calc_dma_rotation_offset(u8 rotation, bool
mirror,
enum omap_color_mode color_mode, bool fieldmode,
unsigned int field_offset,
unsigned *offset0, unsigned *offset1,
- s32 *row_inc, s32 *pix_inc)
+ s32 *row_inc, s32 *pix_inc, int x_predecim, int y_predecim)
{
u8 ps;
u16 fbw, fbh;
@@ -1515,10 +1515,14 @@ static void calc_dma_rotation_offset(u8 rotation, bool
mirror,
*offset0 = *offset1 + field_offset * screen_width * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(1 + (screen_width - fbw) +
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 +
+ (y_predecim * screen_width - fbw * x_predecim) +
+ (fieldmode ? screen_width : 0), ps);
+ if (color_mode == OMAP_DSS_COLOR_YUV2 ||
+ color_mode == OMAP_DSS_COLOR_UYVY)
+ *pix_inc = pixinc(x_predecim, 2 * ps);
+ else
+ *pix_inc = pixinc(x_predecim, ps);
break;
case OMAP_DSS_ROT_90:
*offset1 = screen_width * (fbh - 1) * ps;
@@ -1526,9 +1530,9 @@ static void calc_dma_rotation_offset(u8 rotation, bool
mirror,
*offset0 = *offset1 + field_offset
Re: [RFC][PATCH 4/7] ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 0455858..254f97b 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -33,7 +33,7 @@ struct omap4_idle_statedata {
#define OMAP4_NUM_STATES 3
-struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
+static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
OK
Regards
santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 3/3] OMAPDSS: DISPC: Correct DISPC functional clock usage
DISPC_FCLK is incorrectly used as functional clock of DISPC in scaling
calculations. So, DISPC_CORE_CLK replaces as functional clock of DISPC.
DISPC_CORE_CLK is derived from DISPC_FCLK divided by an independent DISPC
divisor LCD.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index d8a1672..1fdac73 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1761,6 +1761,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
const int max_decim_limit = 16;
unsigned long fclk = 0;
+ unsigned long dispc_core_clk = dispc_mgr_lclk_rate(channel);
int decim_x, decim_y, error, min_factor;
u16 in_width, in_height, in_width_max = 0;
@@ -1803,7 +1804,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
fclk = calc_fclk(channel, in_width, in_height,
out_width, out_height);
error = (in_width maxsinglelinewidth || !fclk ||
- fclk dispc_fclk_rate());
+ fclk dispc_core_clk);
if (error) {
if (decim_x == decim_y) {
decim_x = min_factor;
@@ -1841,7 +1842,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
out_width, out_height);
error = (error || in_width maxsinglelinewidth * 2 ||
(in_width maxsinglelinewidth *five_taps) ||
- !fclk || fclk dispc_fclk_rate());
+ !fclk || fclk dispc_core_clk);
if (error) {
if (decim_x == decim_y) {
decim_x = min_factor;
@@ -1873,7 +1874,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
}
} else {
in_height = DIV_ROUND_UP(height, decim_y);
- in_width_max = dispc_fclk_rate() /
+ in_width_max = dispc_core_clk /
DIV_ROUND_UP(dispc_mgr_pclk_rate(channel),
out_width);
decim_x = DIV_ROUND_UP(width, in_width_max);
@@ -1894,13 +1895,13 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
}
DSSDBG(required fclk rate = %lu Hz\n, fclk);
- DSSDBG(current fclk rate = %lu Hz\n, dispc_fclk_rate());
+ DSSDBG(current fclk rate = %lu Hz\n, dispc_core_clk);
- if (!fclk || fclk dispc_fclk_rate()) {
+ if (!fclk || fclk dispc_core_clk) {
DSSERR(failed to set up scaling,
required fclk rate = %lu Hz,
current fclk rate = %lu Hz\n,
- fclk, dispc_fclk_rate());
+ fclk, dispc_core_clk);
return -EINVAL;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/3] OMAPDSS: DISPC: Handle synclost errors in OMAP3
In OMAP3 DISPC video overlays suffer from some undocumented horizontal position
and timing related limitations leading to SYNCLOST errors. Whenever the image
window is moved towards the right of the screen SYNCLOST errors become
frequent. Checks have been implemented to see that DISPC driver rejects
configuration exceeding above limitations.
This code was successfully tested on OMAP3. This code is written based on code
written by Ville Syrjälä ville.syrj...@nokia.com in Linux OMAP kernel. Ville
Syrjälä ville.syrj...@nokia.com had added checks for video overlay horizontal
timing and DISPC horizontal blanking length limitations.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 97 +--
1 files changed, 72 insertions(+), 25 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5a1963e..d8a1672 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1622,6 +1622,57 @@ static void calc_dma_rotation_offset(u8 rotation, bool
mirror,
}
}
+static int check_horiz_timing(enum omap_channel channel, u16 pos_x,
+ u16 width, u16 height, u16 out_width, u16 out_height)
+{
+ int DS = DIV_ROUND_UP(height, out_height);
+ struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
+ struct omap_video_timings t = dssdev-panel.timings;
+ unsigned long nonactive, lclk, pclk;
+ static const u8 limits[3] = { 8, 10, 20 };
+ u64 val, blank;
+ int i;
+
+ nonactive = t.x_res + t.hfp + t.hsw + t.hbp - out_width;
+ pclk = dispc_mgr_pclk_rate(channel);
+ lclk = dispc_mgr_lclk_rate(channel);
+
+ i = 0;
+ if (out_height height)
+ i++;
+ if (out_width width)
+ i++;
+ blank = div_u64((u64)(t.hbp + t.hsw + t.hfp) * lclk, pclk);
+ DSSDBG(blanking period + ppl = %llu (limit = %u)\n, blank, limits[i]);
+ if (blank = limits[i])
+ return -EINVAL;
+
+ /*
+* Pixel data should be prepared before visible display point starts.
+* So, atleast DS-2 lines must have already been fetched by DISPC
+* during nonactive - pos_x period.
+*/
+ val = div_u64((u64)(nonactive - pos_x) * lclk, pclk);
+ DSSDBG((nonactive - pos_x) * pcd = %llu,
+max(0, DS - 2) * width = %d\n,
+ val, max(0, DS - 2) * width);
+ if (val max(0, DS - 2) * width)
+ return -EINVAL;
+
+ /*
+* All lines need to be refilled during the nonactive period of which
+* only one line can be loaded during the active period. So, atleast
+* DS - 1 lines should be loaded during nonactive period.
+*/
+ val = div_u64((u64)nonactive * lclk, pclk);
+ DSSDBG(nonactive * pcd = %llu, max(0, DS - 1) * width = %d\n,
+ val, max(0, DS - 1) * width);
+ if (val max(0, DS - 1) * width)
+ return -EINVAL;
+
+ return 0;
+}
+
static unsigned long calc_fclk_five_taps(enum omap_channel channel, u16 width,
u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode)
@@ -1702,7 +1753,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
enum omap_channel channel, u16 width, u16 height,
u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
- int *x_predecim, int *y_predecim)
+ int *x_predecim, int *y_predecim, u16 pos_x)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
@@ -1778,6 +1829,9 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
fclk = calc_fclk_five_taps(channel, in_width, in_height,
out_width, out_height, color_mode);
+ error = check_horiz_timing(channel, pos_x, in_width,
+ in_height, out_width, out_height);
+
if (in_width maxsinglelinewidth)
if (in_height out_height
in_height out_height * 2)
@@ -1785,7 +1839,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
if (!*five_taps)
fclk = calc_fclk(channel, in_width, in_height,
out_width, out_height);
- error = (in_width maxsinglelinewidth * 2 ||
+ error = (error || in_width maxsinglelinewidth * 2 ||
(in_width maxsinglelinewidth *five_taps) ||
!fclk || fclk dispc_fclk_rate());
if (error) {
@@ -1801,6 +1855,12 @@ static int dispc_ovl_calc_scaling(enum
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote: On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. Thanks. Will have a look at your series. Cool, thanks. A couple a things call my intention. Why the cpuidle device is set for cpu0 only Because the mainline code CPUIDLE is supported along with CPUhotplug. This is going to change though with Couple CPUIDLE and corresponding OMAP updates. Ok, thanks for the information. I will look deeper. What happens to cpu1 when it is online and has nothing to do ? and why the WFI is not used ? I didn't get this question. Do you mean the generic WFI? I execute default idle loop. yes. If yes, then, it's mainly because OMAP need additional custom barriers. Ah, ok. I am not sure if it is possible but that may be cool if we can call cpu_do_idle instead with additional barrier. There is no need. Since code around WFI is customised, it make no sense to call cpu_do_idle(0 ofr only that instruction sake. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/7] ARM: OMAP4: cpuidle - Remove unused valid field
On Wednesday 21 March 2012 03:16 PM, Daniel Lezcano wrote: On 03/21/2012 10:41 AM, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: The 'valid' field is never used in the code, let's remove it. Signed-off-by: Daniel Lezcanodaniel.lezc...@linaro.org --- It is used during the registration. This field has been very useful for debug when need to disable a C-state etc. So unless and until there is a strong reason, i would like to retain it. IMO if it used for debug purpose, it should be moved to the debug code and if the debug code is not upstream, then that 'valid' should not be here but in the out-of-tree code. When I said debug, I mean CPUIDLE debug and not any special debug code. By the way, this may be a debate for nothing because a patchset is on the way to disable C-states from sysfs. I see but sysfs won't solve that because you want to disable certain C-state so that CPUIDLE driver don't use that state. Let say if the C4 which is OSWR is broken. In such cases, just setting valid flag let you disable it. Again I don't have strong objection to this change. Regards santosh -- 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] mfd: Add TWL4030 PWM driver
On Wednesday 21 March 2012, Thierry Reding wrote: * Arnd Bergmann wrote: On Wednesday 21 March 2012, Bernhard Walle wrote: Am 20.03.12 23:02, schrieb Arnd Bergmann: On Tuesday 20 March 2012, Bernhard Walle wrote: This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030 PWM has been used as mode, but the PWM registers are different. The driver can be used and has been tested in conjunction with pwm-backlight to control a backlight LED of a LCD touch screen. Signed-off-by: Bernhard Walle wa...@corscience.de Since it's too late for v3.4 now and we will get a new pwm subsystem in v3.5, I suggest you change the driver to work register with that subsystem instead of just using the old header file. Note that drivers/mfd is not really the right place anyway, because this is not a multifunction driver but just one device driver that happens to be a slave of an mfd. Does that new subsystem already exist in some tree? Thierry Reding has been busily posting patches, so he probably has one that you can use, but I couldn't find it now. I don't have a public tree anywhere. Does anyone have a recommendation where I could set one up? github or gitorious are the first to come to my mind. They both work fine and are easy to set up, at least as a temporary location. If you want to have something more official in the long run, you could either set up your own git server on your employer's domain or if that is impractical, get an account on kernel.org or linaro.org. Both of those try to limit the amount of accounts they hand out to external people, but since you are going to be a subsystem maintainer, I don't see it as a problem. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/3] Documentation: common clk API
On Tuesday 20 March 2012, Paul Walmsley wrote: Hello Arnd, On Sat, 17 Mar 2012, Arnd Bergmann wrote: I think it's rather pointless, because the option is not going to be user selectable but will get selected by the platform unless I'm mistaken. The platform maintainers that care already know the state of the framework. This is where we have differing views, I think. Clearly, Sascha, Saravana, Rob, and I have at least slightly different opinions on the durability of the existing API and code. So it seems reasonable to assume that others who have not followed the development of the common clock code might mistake the implementation or API as being stable and well-defined. It sounds like the primary objection is to the use of CONFIG_EXPERIMENTAL. So here is a patch to simply note the status of this code in its Kconfig text. Yes, looks good to me. If there are no objections, I'll apply this one. Thanks, Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads
From: Govindraj.R govindraj.r...@ti.com
The following commit:
(7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
added default pads for all uarts. But not all boards tend to
use all uarts and most of unused uart pins are muxed for
other purpose. This commit breaks the modules which where trying
to use unused uart pins on their boards.
So remove all default pads except uart1/3 as most boards
tend to use either uart1/3 as console port and use only tx/rx
lines, declare only those pads for uart1/3.
If any boards tend to use any other uart other uart1/3
the mux data should to passed from board file and init individual
uart port using omap_serial_init_port api.
These pads are needed not only for muxing but are also used to specify
pad wakeup capability for console uart, prior to commit specified we used
to do raw_write to mux pin to enable wakeup capability to uart1/2/3 now
with runtime changes we are using the hwmod/mux framework.
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
Based on Linux 3.3
Tested on Beagle XM and Zoom3 board.
arch/arm/mach-omap2/serial.c | 78 --
1 files changed, 0 insertions(+), 78 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 83ab5a2..4dccf14 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -124,14 +124,6 @@ static void omap_uart_set_smartidle(struct platform_device
*pdev) {}
#ifdef CONFIG_OMAP_MUX
static struct omap_device_pad default_uart1_pads[] __initdata = {
{
- .name = uart1_cts.uart1_cts,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_rts.uart1_rts,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
.name = uart1_tx.uart1_tx,
.enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
},
@@ -143,37 +135,8 @@ static struct omap_device_pad default_uart1_pads[]
__initdata = {
},
};
-static struct omap_device_pad default_uart2_pads[] __initdata = {
- {
- .name = uart2_cts.uart2_cts,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_rts.uart2_rts,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_tx.uart2_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_rx.uart2_rx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- .idle = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
-};
-
static struct omap_device_pad default_uart3_pads[] __initdata = {
{
- .name = uart3_cts_rctx.uart3_cts_rctx,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart3_rts_sd.uart3_rts_sd,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
.name = uart3_tx_irtx.uart3_tx_irtx,
.enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
},
@@ -185,32 +148,6 @@ static struct omap_device_pad default_uart3_pads[]
__initdata = {
},
};
-static struct omap_device_pad default_omap36xx_uart4_pads[] __initdata = {
- {
- .name = gpmc_wait2.uart4_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = gpmc_wait3.uart4_rx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE2,
- .idle = OMAP_PIN_INPUT | OMAP_MUX_MODE2,
- },
-};
-
-static struct omap_device_pad default_omap4_uart4_pads[] __initdata = {
- {
- .name = uart4_tx.uart4_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart4_rx.uart4_rx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
- .idle = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
- },
-};
-
static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
{
switch (bdata-id) {
@@ -218,25 +155,10 @@ static void omap_serial_fill_default_pads(struct
omap_board_data *bdata)
bdata-pads = default_uart1_pads;
bdata-pads_cnt = ARRAY_SIZE(default_uart1_pads);
break;
- case 1:
- bdata-pads = default_uart2_pads;
- bdata-pads_cnt = ARRAY_SIZE(default_uart2_pads);
- break;
case 2:
bdata-pads = default_uart3_pads;
bdata-pads_cnt =
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
Daniel, On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. A couple a things call my intention. Why the cpuidle device is set for cpu0 only and why the WFI is not used ? Daniel Lezcano (7): ARM: OMAP4: cpuidle - Remove unused valid field ARM: OMAP4: cpuidle - Declare the states with the driver declaration ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time The series looks fine to me in general. This clean-up is applicable for OMAP3 cpuidle code as well. I want Jean to look at this series because some of his earlier clean up has introduced those custom functions which are getting removed in this series. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: musb: fix some runtime_pm issues
On Sat, Feb 04, 2012 at 07:43:51PM +0200, Grazvydas Ignotas wrote: When runtime_pm was originally added, it was done in rather confusing way: omap2430_musb_init() (called from musb_init_controller) would do runtime_pm_get_sync() and musb_init_controller() itself would do runtime_pm_put to balance it out. This is not only confusing but also wrong if non-omap2430 glue layer is used. This confusion resulted in commit 772aed45b604 usb: musb: fix pm_runtime mismatch, that removed runtime_pm_put() from musb_init_controller as that looked unbalanced, and also happened to fix unrelated isp1704_charger crash. However this broke runtime PM functionality (musb is now always powered, even without gadget active). Avoid these confusing runtime pm dependences by making musb_init_controller() and omap2430_musb_init() do their own runtime get/put pairs; also cover error paths. Remove unneeded runtime_pm_put in omap2430_remove too. isp1704_charger crash that motivated 772aed45b604 will be fixed by following patch. Cc: Felipe Contreras felipe.contre...@gmail.com Signed-off-by: Grazvydas Ignotas nota...@gmail.com applied, thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/2] usb: musb: wake the device before ulpi transfers
On Sat, Feb 04, 2012 at 07:43:52PM +0200, Grazvydas Ignotas wrote: musb can be suspended at the time some other driver wants to do ulpi transfers using otg_io_* functions, and that can cause data abort, as it happened with isp1704_charger: http://article.gmane.org/gmane.linux.kernel/1226122 Add pm_runtime to ulpi functions to rectify this. This also adds io_dev to otg_transceiver so that pm_runtime can be used. Cc: Felipe Contreras felipe.contre...@gmail.com Signed-off-by: Grazvydas Ignotas nota...@gmail.com doesn't apply, please refresh. -- balbi signature.asc Description: Digital signature
[PATCH 0/3] OMAP2+: UART: Enable tx wakeup + remove cpu checks
From: Govindraj.R govindraj.r...@ti.com Based on Linux-OMAP tree uart branch. (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git remotes/origin/uart) * Removes the cpu checks wherever possible and use version reg for populating features and errata's * enable tx wakeup available in wer reg for applicable module revision's Govindraj.R (3): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx arch/arm/mach-omap2/serial.c | 13 + arch/arm/plat-omap/include/plat/omap-serial.h |8 +++- drivers/tty/serial/omap-serial.c | 71 - 3 files changed, 78 insertions(+), 14 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP2+: UART: Remove cpu checks for populating errata flags
From: Govindraj.R govindraj.r...@ti.com
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
can be managed within the driver itself.
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |8 ---
arch/arm/plat-omap/include/plat/omap-serial.h |1 -
drivers/tty/serial/omap-serial.c | 62 -
3 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..330ee04 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -357,14 +357,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
omap_up.dma_rx_poll_rate = info-dma_rx_poll_rate;
omap_up.autosuspend_timeout = info-autosuspend_timeout;
- /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
- if (!cpu_is_omap2420() !cpu_is_ti816x())
- omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
-
- /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
- if (cpu_is_omap34xx() || cpu_is_omap3630())
- omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
-
pdata = omap_up;
pdata_size = sizeof(struct omap_uart_port_info);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..1a52725 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -65,7 +65,6 @@ struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
unsigned intuartclk;/* UART clock rate */
upf_t flags; /* UPF_* flags */
- u32 errata;
unsigned intdma_rx_buf_size;
unsigned intdma_rx_timeout;
unsigned intautosuspend_timeout;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f809041..c7666d6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -44,6 +44,13 @@
#include plat/dmtimer.h
#include plat/omap-serial.h
+#define UART_BUILD_REVISION(x, y) (((x) 8) | (y))
+
+#define OMAP_UART_REV_42 0x0402
+#define OMAP_UART_REV_46 0x0406
+#define OMAP_UART_REV_52 0x0502
+#define OMAP_UART_REV_63 0x0603
+
#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
/* SCR register bitmasks */
@@ -1346,6 +1353,58 @@ static void uart_tx_dma_callback(int lch, u16 ch_status,
void *data)
return;
}
+static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
+{
+ u32 mvr, scheme;
+ u16 revision, major, minor;
+
+ mvr = serial_in(up, UART_OMAP_MVER);
+
+ /* Check revision register scheme */
+ scheme = mvr (0x03 30);
+ scheme = 30;
+
+ switch (scheme) {
+ case 0: /* Legacy Scheme: OMAP2/3 */
+ /* MINOR_REV[0:4], MAJOR_REV[4:7] */
+ major = (mvr 0xf0) 4;
+ minor = (mvr 0x0f);
+ break;
+ case 1:
+ /* New Scheme: OMAP4+ */
+ /* MINOR_REV[0:5], MAJOR_REV[8:10] */
+ major = (mvr 0x7 8) 8;
+ minor = (mvr 0x3f);
+ break;
+ default:
+ dev_warn(up-pdev-dev,
+ Unknown %s revision, defaulting to highest\n,
+ up-name);
+ /* highest possible revision */
+ major = 0xff;
+ minor = 0xff;
+ }
+
+ /* normalize revision for the driver */
+ revision = UART_BUILD_REVISION(major, minor);
+
+ switch (revision) {
+ case OMAP_UART_REV_46:
+ up-errata |= (UART_ERRATA_i202_MDR1_ACCESS |
+ UART_ERRATA_i291_DMA_FORCEIDLE);
+ break;
+ case OMAP_UART_REV_52:
+ up-errata |= (UART_ERRATA_i202_MDR1_ACCESS |
+ UART_ERRATA_i291_DMA_FORCEIDLE);
+ break;
+ case OMAP_UART_REV_63:
+ up-errata |= UART_ERRATA_i202_MDR1_ACCESS;
+ break;
+ default:
+ break;
+ }
+}
+
static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
{
struct omap_uart_port_info *omap_up_info;
@@ -1443,7 +1502,6 @@ static int serial_omap_probe(struct platform_device *pdev)
%d\n, DEFAULT_CLK_SPEED);
}
up-uart_dma.uart_base = mem-start;
- up-errata = omap_up_info-errata;
if
[PATCH 3/3] OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx
From: Govindraj.R govindraj.r...@ti.com Minor cleanup, replace all omap34xx/omap44xx cpu checks with cpu is not omap24xx check. Cc: Paul Walmsley p...@pwsan.com Cc: Felipe Balbi ba...@ti.com Cc: Kevin Hilman khil...@ti.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/serial.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c index 330ee04..83ab5a2 100644 --- a/arch/arm/mach-omap2/serial.c +++ b/arch/arm/mach-omap2/serial.c @@ -377,8 +377,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata, oh-dev_attr = uart; - if (((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads) -!uart_debug) + if ((!cpu_is_omap24xx() bdata-pads) !uart_debug) device_init_wakeup(pdev-dev, true); } @@ -401,7 +400,7 @@ void __init omap_serial_board_init(struct omap_uart_port_info *info) bdata.pads = NULL; bdata.pads_cnt = 0; - if (cpu_is_omap44xx() || cpu_is_omap34xx()) + if (!cpu_is_omap24xx()) omap_serial_fill_default_pads(bdata); if (!info) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] OMAP2+: UART: enable tx wakeup bit for wer reg
From: Govindraj.R govindraj.r...@ti.com
From omap36xx onwards the module wakeup enable reg
wer has TX wakeup bit available enable the same
by populating the necessary tx wakeup flag for the
applicable module ip blocks and use the same
while configuaring wer reg.
Also wer is not context restored, restore wer when
context is lost.
Cc: Paul Walmsley p...@pwsan.com
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h |7 +++
drivers/tty/serial/omap-serial.c |9 -
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 1a52725..8a4ca5c 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -61,6 +61,11 @@
#define UART_ERRATA_i202_MDR1_ACCESS BIT(0)
#define UART_ERRATA_i291_DMA_FORCEIDLE BIT(1)
+#define OMAP_UART_TX_WAKEUP_EN BIT(7)
+
+/* Feature flags */
+#define OMAP_UART_WER_HAS_TX_WAKEUPBIT(0)
+
struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
unsigned intuartclk;/* UART clock rate */
@@ -116,6 +121,7 @@ struct uart_omap_port {
unsigned char dlh;
unsigned char mdr1;
unsigned char scr;
+ unsigned char wer;
int use_dma;
/*
@@ -129,6 +135,7 @@ struct uart_omap_port {
unsigned long port_activity;
u32 context_loss_cnt;
u32 errata;
+ u32 features;
u8 wakeups_enabled;
struct pm_qos_request pm_qos_request;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c7666d6..20d568d 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -585,7 +585,11 @@ static int serial_omap_startup(struct uart_port *port)
serial_out(up, UART_IER, up-ier);
/* Enable module level wake up */
- serial_out(up, UART_OMAP_WER, OMAP_UART_WER_MOD_WKUP);
+ up-wer = OMAP_UART_WER_MOD_WKUP;
+ if (up-features OMAP_UART_WER_HAS_TX_WAKEUP)
+ up-wer |= OMAP_UART_TX_WAKEUP_EN;
+
+ serial_out(up, UART_OMAP_WER, up-wer);
pm_runtime_mark_last_busy(up-pdev-dev);
pm_runtime_put_autosuspend(up-pdev-dev);
@@ -1396,9 +1400,11 @@ static void omap_serial_fill_features_erratas(struct
uart_omap_port *up)
case OMAP_UART_REV_52:
up-errata |= (UART_ERRATA_i202_MDR1_ACCESS |
UART_ERRATA_i291_DMA_FORCEIDLE);
+ up-features |= OMAP_UART_WER_HAS_TX_WAKEUP;
break;
case OMAP_UART_REV_63:
up-errata |= UART_ERRATA_i202_MDR1_ACCESS;
+ up-features |= OMAP_UART_WER_HAS_TX_WAKEUP;
break;
default:
break;
@@ -1629,6 +1635,7 @@ static void serial_omap_restore_context(struct
uart_omap_port *up)
serial_omap_mdr1_errataset(up, up-mdr1);
else
serial_out(up, UART_OMAP_MDR1, up-mdr1);
+ serial_out(up, UART_OMAP_WER, up-wer);
}
static int serial_omap_runtime_suspend(struct device *dev)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Add TWL4030 PWM driver
* Arnd Bergmann wrote: On Wednesday 21 March 2012, Thierry Reding wrote: I don't have a public tree anywhere. Does anyone have a recommendation where I could set one up? github or gitorious are the first to come to my mind. They both work fine and are easy to set up, at least as a temporary location. Okay, I'll check both and will also investigate whether one can be setup on our domain. If you want to have something more official in the long run, you could either set up your own git server on your employer's domain or if that is impractical, get an account on kernel.org or linaro.org. Both of those try to limit the amount of accounts they hand out to external people, but since you are going to be a subsystem maintainer, I don't see it as a problem. Maybe Sascha should have a say in this (adding to Cc). He wrote the original code and got the ball rolling, so I don't want to jump the queue. If he's okay with it, though, I'd be happy to take over. Thierry pgptsfuoboMUB.pgp Description: PGP signature
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On 03/21/2012 10:56 AM, Santosh Shilimkar wrote: On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote: On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. Thanks. Will have a look at your series. Cool, thanks. A couple a things call my intention. Why the cpuidle device is set for cpu0 only Because the mainline code CPUIDLE is supported along with CPUhotplug. This is going to change though with Couple CPUIDLE and corresponding OMAP updates. Ok, thanks for the information. I will look deeper. What happens to cpu1 when it is online and has nothing to do ? and why the WFI is not used ? I didn't get this question. Do you mean the generic WFI? I execute default idle loop. So is it not possible to add a cpuidle device for cpu1 and define only one state for the 'wfi-for-omap' ? yes. If yes, then, it's mainly because OMAP need additional custom barriers. Ah, ok. I am not sure if it is possible but that may be cool if we can call cpu_do_idle instead with additional barrier. There is no need. Since code around WFI is customised, it make no sense to call cpu_do_idle(0 ofr only that instruction sake. For my personal information, why the WFI is customised for omap4 ? Thanks -- Daniel -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On 03/21/2012 11:07 AM, Santosh Shilimkar wrote: Daniel, On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. A couple a things call my intention. Why the cpuidle device is set for cpu0 only and why the WFI is not used ? Daniel Lezcano (7): ARM: OMAP4: cpuidle - Remove unused valid field ARM: OMAP4: cpuidle - Declare the states with the driver declaration ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time The series looks fine to me in general. This clean-up is applicable for OMAP3 cpuidle code as well. Yes, I am planning to do the same for omap3. Thanks for reviewing. -- Daniel I want Jean to look at this series because some of his earlier clean up has introduced those custom functions which are getting removed in this series. Regards santosh -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On Wed, Mar 21, 2012 at 4:13 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 03/21/2012 10:56 AM, Santosh Shilimkar wrote: On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote: On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. Thanks. Will have a look at your series. Cool, thanks. A couple a things call my intention. Why the cpuidle device is set for cpu0 only Because the mainline code CPUIDLE is supported along with CPUhotplug. This is going to change though with Couple CPUIDLE and corresponding OMAP updates. Ok, thanks for the information. I will look deeper. What happens to cpu1 when it is online and has nothing to do ? and why the WFI is not used ? I didn't get this question. Do you mean the generic WFI? I execute default idle loop. So is it not possible to add a cpuidle device for cpu1 and define only one state for the 'wfi-for-omap' ? That's how my post was handling it. But after the review Kevin suggested me to drop the CPU1 shallow state since it was same as default idle. yes. If yes, then, it's mainly because OMAP need additional custom barriers. Ah, ok. I am not sure if it is possible but that may be cool if we can call cpu_do_idle instead with additional barrier. There is no need. Since code around WFI is customised, it make no sense to call cpu_do_idle(0 ofr only that instruction sake. For my personal information, why the WFI is customised for omap4 ? OMAP4 silicon has couple of hardware issues around interconnect and needs to drain the axi buffers with strongly order writes to ensure that data reaches to peripherals and not get stuck. That lead to have custom function. Note that, the wfi instruction itself is same. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On 03/21/2012 11:49 AM, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 4:13 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 03/21/2012 10:56 AM, Santosh Shilimkar wrote: On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote: On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. Thanks. Will have a look at your series. Cool, thanks. A couple a things call my intention. Why the cpuidle device is set for cpu0 only Because the mainline code CPUIDLE is supported along with CPUhotplug. This is going to change though with Couple CPUIDLE and corresponding OMAP updates. Ok, thanks for the information. I will look deeper. What happens to cpu1 when it is online and has nothing to do ? and why the WFI is not used ? I didn't get this question. Do you mean the generic WFI? I execute default idle loop. So is it not possible to add a cpuidle device for cpu1 and define only one state for the 'wfi-for-omap' ? That's how my post was handling it. But after the review Kevin suggested me to drop the CPU1 shallow state since it was same as default idle. Ok, thanks. I am asking that because the more I am looking at the different SoCs cpuidle drivers, the more I am convinced we can factor out more code across SoCs. yes. If yes, then, it's mainly because OMAP need additional custom barriers. Ah, ok. I am not sure if it is possible but that may be cool if we can call cpu_do_idle instead with additional barrier. There is no need. Since code around WFI is customised, it make no sense to call cpu_do_idle(0 ofr only that instruction sake. For my personal information, why the WFI is customised for omap4 ? OMAP4 silicon has couple of hardware issues around interconnect and needs to drain the axi buffers with strongly order writes to ensure that data reaches to peripherals and not get stuck. That lead to have custom function. Note that, the wfi instruction itself is same. Thanks for the explanation. -- Daniel -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ 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] ARM: OMAP2+: control: Add AM33XX control reg sec clkctrl offset
Define AM33XX control register, in order to allow access to control register address space, also add CONTROL_SEC_CLK_CTRL register offset; both are required in clock tree data, for wdt0 and timer0 clock source select configuration. CONTROL.SEC_CLK_CTRL register is provided to select/configure clock input for WDT0 and TIMER0. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Paul Walmsley p...@pwsan.com CC: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/control.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index a406fd0..2858b80 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -28,6 +28,8 @@ OMAP2_L4_IO_ADDRESS(OMAP243X_CTRL_BASE + (reg)) #define OMAP343X_CTRL_REGADDR(reg) \ OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE + (reg)) +#define AM33XX_CTRL_REGADDR(reg) \ + AM33XX_L4_WK_IO_ADDRESS(AM33XX_SCM_BASE + (reg)) #else #define OMAP242X_CTRL_REGADDR(reg) \ OMAP2_L4_IO_ADDRESS(OMAP242X_CTRL_BASE + (reg)) @@ -35,6 +37,8 @@ OMAP2_L4_IO_ADDRESS(OMAP243X_CTRL_BASE + (reg)) #define OMAP343X_CTRL_REGADDR(reg) \ OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE + (reg)) +#define AM33XX_CTRL_REGADDR(reg) \ + AM33XX_L4_WK_IO_ADDRESS(AM33XX_SCM_BASE + (reg)) #endif /* __ASSEMBLY__ */ /* @@ -341,6 +345,7 @@ * CONTROL AM33XX STATUS register */ #define AM33XX_CONTROL_STATUS 0x040 +#define AM33XX_CONTROL_SEC_CLK_CTRL0x1bc /* * CONTROL OMAP STATUS register to identify OMAP3 features -- 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 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Mon, Mar 19, 2012 at 17:14:30, Ming Lei wrote: On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: I think you made very good point here. With the above patch, we are almost missing the capability of registering dmtimer as a clocksource for OMAP. It will always use 32k-counter, and never fall back to dmtimer. Then the only options we have here is, 1) Register both the timers, 32k-counter and dmtimer for clocksource; let Kernel pick up best rating clocksource out of these two. In case of OMAP1/2/3/4, kernel will use dmtimer, since it has better Rating. User can choose the 32k-counter clocksource via bootargs. Impact: without bootargs for clocksource selection, kernel will choose dmtimer, impacting loss of time during suspend/resume. 2) Let the current code be as is, means, the clocksource registration will Happened based on #ifdef CONFIG_OMAP_32K_TIMER and this option selection will be Controlled by Kconfig rules. How about the 3rd option? 3), take the way in your patch 1) at default, but will switch to register dmtimer directly and bypass 32k-counter if user need it via kernel parameter. As far as I can think of, the situations required for dmtimer are high-frequency perf sample and high precision trace points, so looks it is OK to take 32k-counter at default. But if you register both the timers (dmtimer 32ksync), then initially kernel will only pick up dmtimer, as this has better rating. And late in the boot sequence clocksource switch will happen, base on kernel parameter (clocksource=). So logically dmtimer will be always used as a default here. Thanks, Vaibhav Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Add TWL4030 PWM driver
On Wed, Mar 21, 2012 at 11:28:47AM +0100, Thierry Reding wrote: * Arnd Bergmann wrote: On Wednesday 21 March 2012, Thierry Reding wrote: I don't have a public tree anywhere. Does anyone have a recommendation where I could set one up? github or gitorious are the first to come to my mind. They both work fine and are easy to set up, at least as a temporary location. Okay, I'll check both and will also investigate whether one can be setup on our domain. If you want to have something more official in the long run, you could either set up your own git server on your employer's domain or if that is impractical, get an account on kernel.org or linaro.org. Both of those try to limit the amount of accounts they hand out to external people, but since you are going to be a subsystem maintainer, I don't see it as a problem. Maybe Sascha should have a say in this (adding to Cc). He wrote the original code and got the ball rolling, so I don't want to jump the queue. If he's okay with it, though, I'd be happy to take over. I'm okay with this. I only wanted to write code for pwm, not maintain it ;) Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
I think you made very good point here. With the above patch, we are almost
missing the capability of registering dmtimer as a clocksource for OMAP.
It will always use 32k-counter, and never fall back to dmtimer.
Then the only options we have here is,
1) Register both the timers, 32k-counter and dmtimer for clocksource; let
Kernel pick up best rating clocksource out of these two.
In case of OMAP1/2/3/4, kernel will use dmtimer, since it has better
Rating. User can choose the 32k-counter clocksource via bootargs.
Impact: without bootargs for clocksource selection, kernel will choose
dmtimer, impacting loss of time during suspend/resume.
This is the right option. The problem is gptimer clocksource
doesn't work across power transitions and hence it is broken.
Even for the perf, with PM enabled, dmtimer can't be used or it needs
to be used with 32KHz clock which makes it no better than sync timer.
So here keeping 32K sync timer is default clocksource makes sense since
it is the only working and viable option.
So what can be done is register both 32K and gptimer together but make
gptimer clocksource registration depends on PM enabled.
This should solve all the needs I guess.
I am not sure this will work on all platforms, for example, AM33XX, where
We do not have 32ksync timer available, but we need PM support. Also, I
personally think, we should not again use compile time option here.
So the only option I have here is, register both the clocksources, let dmtimer
be a default clocksource for the kernel (since it has better rating),
And based on kernel parameter user can change the clocksource, specially
for PM use-cases.
Implementation point of view, I just need to do something like,
static void __init omap2_gp_clocksource_init(int gptimer_id,
const char *fck_source)
{
int res;
res = omap_init_clocksource_32k();
if (!res)
pr_err(failed to register 32ksync counter as a clocksource\n);
/*
* Continue with dmtimer registration as well, irrespective of
* whether 32ksync timer registration succeeded or not.
*/
}
2) Let the current code be as is, means, the clocksource registration will
Happened based on #ifdef CONFIG_OMAP_32K_TIMER and this option
selection will be Controlled by Kconfig rules.
We should get rid off CONFIG_OMAP_32K_TIMER.
Agreed, I will take this activity once I close on this.
Thanks,
Vaibhav
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] omap-serial: Fix the error handling in the omap_serial probe
The patch does the following
- The pm_runtime_disable is called in the remove not in the error
case of probe.The patch calls the pm_runtime_disable in the error
case.
- Calls pm_runtime_put in the error case.
- The up is not freed in the error path. Fix the memory leak by using
devm_* so that the memory need not be freed in the driver.
- Also the iounmap is not called fix the same by calling using devm_ioremap.
- Make the name of the error tags more meaningful.
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Govindraj.R govindraj.r...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Changes from the v1:
Use devm_* functions instead of freeing in the driver.
drivers/tty/serial/omap-serial.c | 43 +
1 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 1e193fc..5386239 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1381,29 +1381,24 @@ static int serial_omap_probe(struct platform_device
*pdev)
return -ENODEV;
}
- if (!request_mem_region(mem-start, resource_size(mem),
+ if (!devm_request_mem_region(pdev-dev, mem-start, resource_size(mem),
pdev-dev.driver-name)) {
dev_err(pdev-dev, memory region already claimed\n);
return -EBUSY;
}
dma_rx = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
- if (!dma_rx) {
- ret = -EINVAL;
- goto err;
- }
+ if (!dma_rx)
+ return -ENXIO;
dma_tx = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
- if (!dma_tx) {
- ret = -EINVAL;
- goto err;
- }
+ if (!dma_tx)
+ return -ENXIO;
+
+ up = devm_kzalloc(pdev-dev, sizeof(*up), GFP_KERNEL);
+ if (!up)
+ return -ENOMEM;
- up = kzalloc(sizeof(*up), GFP_KERNEL);
- if (up == NULL) {
- ret = -ENOMEM;
- goto do_release_region;
- }
up-pdev = pdev;
up-port.dev = pdev-dev;
up-port.type = PORT_OMAP;
@@ -1423,16 +1418,17 @@ static int serial_omap_probe(struct platform_device
*pdev)
dev_err(pdev-dev, failed to get alias/pdev id, errno %d\n,
up-port.line);
ret = -ENODEV;
- goto err;
+ goto err_port_line;
}
sprintf(up-name, OMAP UART%d, up-port.line);
up-port.mapbase = mem-start;
- up-port.membase = ioremap(mem-start, resource_size(mem));
+ up-port.membase = devm_ioremap(pdev-dev, mem-start,
+ resource_size(mem));
if (!up-port.membase) {
dev_err(pdev-dev, can't ioremap UART\n);
ret = -ENOMEM;
- goto err;
+ goto err_ioremap;
}
up-port.flags = omap_up_info-flags;
@@ -1478,16 +1474,19 @@ static int serial_omap_probe(struct platform_device
*pdev)
ret = uart_add_one_port(serial_omap_reg, up-port);
if (ret != 0)
- goto do_release_region;
+ goto err_add_port;
pm_runtime_put(pdev-dev);
platform_set_drvdata(pdev, up);
return 0;
-err:
+
+err_add_port:
+ pm_runtime_put(pdev-dev);
+ pm_runtime_disable(pdev-dev);
+err_ioremap:
+err_port_line:
dev_err(pdev-dev, [UART%d]: failure [%s]: %d\n,
pdev-id, __func__, ret);
-do_release_region:
- release_mem_region(mem-start, resource_size(mem));
return ret;
}
@@ -1499,8 +1498,6 @@ static int serial_omap_remove(struct platform_device *dev)
pm_runtime_disable(up-pdev-dev);
uart_remove_one_port(serial_omap_reg, up-port);
pm_qos_remove_request(up-pm_qos_request);
-
- kfree(up);
}
platform_set_drvdata(dev, NULL);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IVA and SGX not getting detected on 3630 ES1.2
Op 21 mrt. 2012, om 08:36 heeft Koen Kooi het volgende geschreven: Hi, I have a freshly built beagleboard xM on my desk which is giving me some trouble: xM revision A: [0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) new xM revision C: [0.00] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk ) So the IVA and SGX aren't getting detected, while they *are* present. Any hints where I should look to debug this? This is on 3.0.25 if that makes a difference.-- 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: IVA and SGX not getting detected on 3630 ES1.2
xM revision A: [0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) new xM revision C: [0.00] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk ) on a rev. C -xm with kernel 3.2.8: [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) maybe u-boot makes some difference? regards p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IVA and SGX not getting detected on 3630 ES1.2
Op 21 mrt. 2012, om 13:29 heeft Peter Meerwald het volgende geschreven: xM revision A: [0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) new xM revision C: [0.00] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk ) on a rev. C -xm with kernel 3.2.8: [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) maybe u-boot makes some difference? From what I can tell the kernel reads the register directly, so u-boot shouldn't make a difference. regards, Koen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP DSS for v3.4
Hi Florian,
On Mon, 2012-03-19 at 13:01 +0200, Tomi Valkeinen wrote:
Hi Florian, Arnd,
Here are the changes for OMAP DSS driver for v3.4.
There's an issue with the dss driver that appears on arm-soc/for-next
branch, which I'm still solving
(http://marc.info/?l=linux-omapm=133214966902577w=2). I hope to get
fix for that ready and merged for -rc1, but I'm not sure if I can make
it in time, so I wanted to sent this pull request already.
Below is a patch that fixes the issue I mentioned above. So briefly, the
problem is that omapdss's driver registration is broken, and it has been
working so far by luck. arm-soc tree contains a patch which changes how
arch/arm/plat-omap/omap_device.c creates the devices, and this causes
the (broken) omapdss driver registration to break, causing a deadlock.
The patch below makes the omapdss driver registration saner. The patch
works with and without the omap_device.c patch from arm-soc.
Florian, if you didn't send the pull request yet, this would be a good
patch to add to it. We can, of course, get it in for -rc2, but avoiding
a kernel deadlock on -rc1 would be nice.
Tomi
From 849c07b1fd3d9f23e8ed94436b6221f8652462c0 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Mon, 19 Mar 2012 15:05:02 +0200
Subject: [PATCH] OMAPDSS: register dss drivers in module init
We do the dss driver registration in a rather strange way: we have the
higher level omapdss driver, and we use that driver's probe function to
register the drivers for the rest of the dss devices.
There doesn't seem to be any reason for that, and additionally the
soon-to-be-merged patch ARM: OMAP: omap_device: remove
omap_device_parent will break omapdss initialization with the current
registration model.
This patch changes the registration for all drivers to happen at the
same place, in the init of the module.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 135 +++-
1 files changed, 77 insertions(+), 58 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8613f86..e8a1207 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -183,42 +183,6 @@ static int omap_dss_probe(struct platform_device *pdev)
dss_init_overlay_managers(pdev);
dss_init_overlays(pdev);
- r = dss_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize DSS platform driver\n);
- goto err_dss;
- }
-
- r = dispc_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize dispc platform driver\n);
- goto err_dispc;
- }
-
- r = rfbi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize rfbi platform driver\n);
- goto err_rfbi;
- }
-
- r = venc_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize venc platform driver\n);
- goto err_venc;
- }
-
- r = dsi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize DSI platform driver\n);
- goto err_dsi;
- }
-
- r = hdmi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize hdmi\n);
- goto err_hdmi;
- }
-
r = dss_initialize_debugfs();
if (r)
goto err_debugfs;
@@ -246,18 +210,6 @@ static int omap_dss_probe(struct platform_device *pdev)
err_register:
dss_uninitialize_debugfs();
err_debugfs:
- hdmi_uninit_platform_driver();
-err_hdmi:
- dsi_uninit_platform_driver();
-err_dsi:
- venc_uninit_platform_driver();
-err_venc:
- dispc_uninit_platform_driver();
-err_dispc:
- rfbi_uninit_platform_driver();
-err_rfbi:
- dss_uninit_platform_driver();
-err_dss:
return r;
}
@@ -269,13 +221,6 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
- hdmi_uninit_platform_driver();
- dsi_uninit_platform_driver();
- venc_uninit_platform_driver();
- rfbi_uninit_platform_driver();
- dispc_uninit_platform_driver();
- dss_uninit_platform_driver();
-
dss_uninit_overlays(pdev);
dss_uninit_overlay_managers(pdev);
@@ -525,6 +470,80 @@ static int omap_dss_bus_register(void)
/* INIT */
+static int __init omap_dss_register_drivers(void)
+{
+ int r;
+
+ r = platform_driver_register(omap_dss_driver);
+ if (r)
+ return r;
+
+ r = dss_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize DSS platform driver\n);
+ goto err_dss;
+ }
+
+ r = dispc_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize dispc platform driver\n);
+ goto err_dispc;
+ }
+
+ r =
Re: [PATCH] OMAP: DSS2: Remove suspicous and unused TAAL regulator API usage
On Mon, 2012-03-19 at 14:50 +, Mark Brown wrote: The TAAL driver contains some regulator support which is currently unused (the code is there but the one panel supported by the driver doesn't have any regulators provided). This code mostly looks like an open coded version of the regulator core bulk API. The only additional feature is that a voltage range can be set once when the device is opened, though this is never varied at runtime. The general expectation is that if the device is not actively managing the voltage of the device (eg, doing DVFS) then any configuration will be done using the constraints rather than by drivers, saving them code and ensuring that they work well with systems where the voltage is not configurable. If systems are added needing regulator support this can be added back in, though it should be based on core features rather than open coding things. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com Looks fine to me, I'll apply to omapdss tree. We had multiple panels in Nokia, almost the same but with slightly different regulator needs, so we wrote the code removed in this patch. But as it seems there are no more linux devices coming from Nokia, let's just remove the regulator code. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] OMAPDSS: VENC: Check for errors from regulator_enable()
On Mon, 2012-03-19 at 14:56 +, Mark Brown wrote: It is possible for regulator_enable() to fail and if it does fail that's generally a bad sign for anything we try to do with the hardware afterwards so check for and immediately return an error if regulator_enable() fails. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com --- drivers/video/omap2/dss/venc.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c index 9c3daf7..abfbd4a 100644 --- a/drivers/video/omap2/dss/venc.c +++ b/drivers/video/omap2/dss/venc.c @@ -443,7 +443,9 @@ static int venc_power_on(struct omap_dss_device *dssdev) dispc_set_digit_size(dssdev-panel.timings.x_res, dssdev-panel.timings.y_res/2); - regulator_enable(venc.vdda_dac_reg); + r = regulator_enable(venc.vdda_dac_reg); + if (r) + goto err; if (dssdev-platform_enable) dssdev-platform_enable(dssdev); Thanks, I'll apply to omapdss tree. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] OMAPDSS: TPO-TD03MTEA1: Check for errors from regulator_enable()
On Mon, 2012-03-19 at 15:02 +, Mark Brown wrote:
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
.../video/omap2/displays/panel-tpo-td043mtea1.c|5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index 32f3fcd..74c6b87 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -272,11 +272,14 @@ static const struct omap_video_timings
tpo_td043_timings = {
static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
{
int nreset_gpio = tpo_td043-nreset_gpio;
+ int r;
if (tpo_td043-powered_on)
return 0;
- regulator_enable(tpo_td043-vcc_reg);
+ r = regulator_enable(tpo_td043-vcc_reg);
+ if (r != 0)
+ return r;
/* wait for regulator to stabilize */
msleep(160);
Thanks, I'll apply this series to omapdss tree.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] OMAPDSS: OMAPFB: check for matching memory size early
Hi, On Fri, 2012-03-09 at 02:42 +0200, Grazvydas Ignotas wrote: If the size of memory region that is being set up is the same as before, we don't have to do memory and layer busy checks. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- I'm not sure if this is semantically correct, but this helps to get some old programs working, that rely on old DSS version which didn't check for mmap lock, but incidentally they are using same size too.. Well, I wouldn't allow code like that if it was a new ioctl, but if, as you say, the old omapfb worked that way, then I think it's better to do things the same way. I can see no harm in it, so I'll apply. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] OMAPDSS: provide default get_timings function for panels
On Thu, 2012-03-15 at 20:00 +0200, Grazvydas Ignotas wrote: With this we can eliminate some duplicate code in panel drivers. Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and tpo-td043mtea1 gain support of reading timings over sysfs. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- drivers/video/omap2/displays/panel-acx565akm.c |7 --- drivers/video/omap2/displays/panel-generic-dpi.c |7 --- drivers/video/omap2/displays/panel-n8x0.c|8 drivers/video/omap2/displays/panel-taal.c|8 drivers/video/omap2/dss/core.c |2 ++ drivers/video/omap2/dss/display.c|7 +++ drivers/video/omap2/dss/venc.c |7 --- include/video/omapdss.h |2 ++ 8 files changed, 11 insertions(+), 37 deletions(-) These two patches look fine to me, I'll apply to omapdss tree. Thanks! Tomi signature.asc Description: This is a digitally signed message part
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
Hi Santosh, Daniel, On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Daniel, On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. A couple a things call my intention. Why the cpuidle device is set for cpu0 only and why the WFI is not used ? Daniel Lezcano (7): ARM: OMAP4: cpuidle - Remove unused valid field ARM: OMAP4: cpuidle - Declare the states with the driver declaration ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time The series looks fine to me in general. This clean-up is applicable for OMAP3 cpuidle code as well. I want Jean to look at this series because some of his earlier clean up has introduced those custom functions which are getting removed in this series. I am OK with the patch set, I only have minor remarks to the individual patches. Reviewed-by: Jean Pihet j-pi...@ti.com Regards santosh Thanks! Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2: DSS: Add Mitsubishi AA084SB01 display support
On Fri, 2012-02-17 at 13:41 +0100, Thomas Weber wrote: This patch adds support for the Mitsubishi display AA084SB01. This is a 7 inch LVDS display. It is tested with an OMAP3 board. Signed-off-by: Thomas Weber we...@corscience.de Thanks, I'll add these two panels to omapdss tree. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v7 1/3] Documentation: common clk API
On Wed, 21 Mar 2012, Paul Walmsley wrote: Hello Nico, On Tue, 20 Mar 2012, Nicolas Pitre wrote: This common clk API has been under development for over *two* years already, with several attempts to merge it. And each previous merge attempt aborted because someone came along at the last minute to do exactly what you are doing i.e. underline all the flaws and call for a redesign. This is becoming a bad joke. There is a misunderstanding. I am not calling for a redesign. I am simply stating that the current maturity level of the API and code should be documented in the Kconfig dependencies or description text before the code goes upstream. The objectives are to make future changes easier, set expectations, and clearly disclose the extent to which the API and code will need to change. Maybe there is no actual consensus on that extent. The code will be easier to change once it is in mainline, simply due to the fact that you can also change all its users at once. And it is well possible that most users won't have to deal with the same magnitude of complexity as yours, again reducing the scope for resistance to changes. I hope you are right. To me, these conclusions seem unlikely. It seems equally likely that these rationales will make it much more difficult to change the code once it's upstream and platforms are depending on it. No code should go upstream if no one depends on it. Therefore we change code that many platforms depend on all the time. What is killing us is the need to synchronize with multiple external code bases scattered around. Particularly given the ongoing sensitivity to reducing churn of mainline code, so publicly discussed. Please stop buying into that crap. We congratulate ourselves every merge cycles with the current process being able to deal with around half a million of lines changed every 3 months or so. It's pointless churn that is frowned upon, not useful and incremental API changes. I don't think that pointless would apply here. So it seems like a good idea to attempt to address these potential roadblocks and criticisms to major clock framework changes early. I understand your concern, however I don't think it is as serious as you are making it. One last comment to address which is orthogonal to the technical content of this discussion. Otherwise one might ask where were you during those development years if you claim that the behavior and/or API of the common clock code still need to change significantly? One might ask this. If one were to ask this, another might briefly outline the participation in public and private clock discussions at Linaro Connect in Budapest and Redwood Shores, at LPC in Santa Rosa, at ELCE/KS in Prague, at ELC in Redwood Shores, in conference calls, IRC sessions, and private E-mails with many of the people included in the header of this message, not to mention the list posts. Sure. I was there too and came across you many times. I just don't understand why some apparent consensus was built around the current submission, that people involved appeared to be highly satisfied at last, given the emphasis you are giving to your present concern which doesn't seem to be widely shared. This is a bit surprising. None of the concerns that have been described are new. There has been an endeavour to discuss them with anyone who seemed even remotely interested. Let's change tactics then. We've been discussing this code for over two years and no one could really benefit from it during that time. Maybe future discussion could become more productive and concrete when some code is merged _and_ used at last. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/7] ARM: OMAP4: cpuidle - Remove unused valid field
On Wed, Mar 21, 2012 at 11:03 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On Wednesday 21 March 2012 03:16 PM, Daniel Lezcano wrote: On 03/21/2012 10:41 AM, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: The 'valid' field is never used in the code, let's remove it. Signed-off-by: Daniel Lezcanodaniel.lezc...@linaro.org --- It is used during the registration. This field has been very useful for debug when need to disable a C-state etc. So unless and until there is a strong reason, i would like to retain it. IMO if it used for debug purpose, it should be moved to the debug code and if the debug code is not upstream, then that 'valid' should not be here but in the out-of-tree code. When I said debug, I mean CPUIDLE debug and not any special debug code. By the way, this may be a debate for nothing because a patchset is on the way to disable C-states from sysfs. I see but sysfs won't solve that because you want to disable certain C-state so that CPUIDLE driver don't use that state. This will solve the problem, the only difference is that you need the user space to switch the disable knob from sysfs. From the kernel space, for debug, you can set the .disable value to 1 in the cpuidle_driver-states struct. Let say if the C4 which is OSWR is broken. In such cases, just setting valid flag let you disable it. Again I don't have strong objection to this change. Regards santosh Regards, Jean ___ linaro-dev mailing list linaro-...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/7] ARM: OMAP4: cpuidle - Declare the states with the driver declaration
On Wed, Mar 21, 2012 at 10:27 AM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c | 56
+
1 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 1210229..cd6bee7 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -148,21 +148,38 @@ DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
struct cpuidle_driver omap4_idle_driver = {
.name = omap4_idle,
.owner = THIS_MODULE,
+ .states = {
+ {
+ /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = C1,
+ .desc = MPUSS ON
+ },
...
+ },
+ .state_count = OMAP4_NUM_STATES,
};
-static inline void _fill_cstate(struct cpuidle_driver *drv,
- int idx, const char *descr)
-{
- struct cpuidle_state *state = drv-states[idx];
-
- state-exit_latency = cpuidle_params_table[idx].exit_latency;
- state-target_residency = cpuidle_params_table[idx].target_residency;
- state-flags = CPUIDLE_FLAG_TIME_VALID;
- state-enter = omap4_enter_idle;
- sprintf(state-name, C%d, idx + 1);
- strncpy(state-desc, descr, CPUIDLE_DESC_LEN);
-}
I am OK with this change, which makes the code more readable (and so
maintainable).
-
static inline struct omap4_idle_statedata *_fill_cstate_usage(
struct cpuidle_device *dev,
int idx)
@@ -196,37 +213,28 @@ int __init omap4_idle_init(void)
if ((!mpu_pd) || (!cpu0_pd) || (!cpu1_pd))
return -ENODEV;
-
- drv-safe_state_index = -1;
dev = per_cpu(omap4_idle_dev, cpu_id);
dev-cpu = cpu_id;
- /* C1 - CPU0 ON + CPU1 ON + MPU ON */
- _fill_cstate(drv, 0, MPUSS ON);
- drv-safe_state_index = 0;
I would keep this or add a clear comment that C1 is the safe state.
...
Thanks,
Jean
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Daniel, On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. A couple a things call my intention. Why the cpuidle device is set for cpu0 only and why the WFI is not used ? Daniel Lezcano (7): ARM: OMAP4: cpuidle - Remove unused valid field ARM: OMAP4: cpuidle - Declare the states with the driver declaration ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time The series looks fine to me in general. This clean-up is applicable for OMAP3 cpuidle code as well. Great! However OMAP3 has a few specific things that cannot be removed as easily: - the 'valid' flag is used because only certain combinations of power domains states are possible, - the latency settings can be overriden by the board code, so the cpuidle_params struct is needed. I want Jean to look at this series because some of his earlier clean up has introduced those custom functions which are getting removed in this series. Regards santosh Thanks, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote: On Monday 19 March 2012 05:14 PM, Ming Lei wrote: On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: I think you made very good point here. With the above patch, we are almost missing the capability of registering dmtimer as a clocksource for OMAP. It will always use 32k-counter, and never fall back to dmtimer. Then the only options we have here is, 1) Register both the timers, 32k-counter and dmtimer for clocksource; let Kernel pick up best rating clocksource out of these two. In case of OMAP1/2/3/4, kernel will use dmtimer, since it has better Rating. User can choose the 32k-counter clocksource via bootargs. Impact: without bootargs for clocksource selection, kernel will choose dmtimer, impacting loss of time during suspend/resume. This is the right option. The problem is gptimer clocksource doesn't work across power transitions and hence it is broken. Even for the perf, with PM enabled, dmtimer can't be used or it needs to be used with 32KHz clock which makes it no better than sync timer. So here keeping 32K sync timer is default clocksource makes sense since it is the only working and viable option. So what can be done is register both 32K and gptimer together but make gptimer clocksource registration depends on PM enabled. This should solve all the needs I guess. I am not sure this will work on all platforms, for example, AM33XX, where We do not have 32ksync timer available, but we need PM support. Also, I personally think, we should not again use compile time option here. Why not ? If 32ksync timer is not available, don't register it. Then in AM case you just have one clock-source. I am against the idea of making gptimer as the default and asking user to choose sync32k from command-line. Btw, if you need PM, how are you going to use GPTIMER as a clocksource. Note sys-clock is generally stopped in low power states. So that leaves you option with using gptimer with 32K clock and in that case, GPTIMER is not a better clock-source compare to 32K sync timer and so shouldn't be the rating. Regards Santosh -- 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 RESEND 6/7] gpio/omap: fix incorrect update to context.irqenable1
DebBarma, Tarun Kanti tarun.ka...@ti.com writes: On Wed, Mar 21, 2012 at 8:10 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Tue, Mar 20, 2012 at 11:31 PM, Kevin Hilman khil...@ti.com wrote: Tarun Kanti DebBarma tarun.ka...@ti.com writes: In _enable_gpio_irqbank() when bank-regs-set_irqenable is valid, gpio_mask can be directly set by writing to set_irqenable register without overwriting current value. In order to ensure the same is stored in context.irqenable1, we must read from regs-irqenable instead of overwriting it with gpio_mask. The overwriting makes sense only in the second case where irqenable is explicitly read and updated with new gpio_mask before writing it back. However, for consistency reading regs-irqenable into the bank-context.irqenable1 takes care of both the scenarios. ...except that the code doesn't do this anymore. Yes. I like the newer version (I hope so, since I suggested it :), but please update the changlog to describe what the code is actually doing. Sure. I have updated the change log here: git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev for_3.4/gpio_more_fixes Please also post and updated version of the patch for review. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/7] ARM: OMAP4: cpuidle - Declare the states with the driver declaration
On 03/21/2012 02:31 PM, Jean Pihet wrote:
On Wed, Mar 21, 2012 at 10:27 AM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
Signed-off-by: Daniel Lezcanodaniel.lezc...@linaro.org
---
arch/arm/mach-omap2/cpuidle44xx.c | 56 +
1 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 1210229..cd6bee7 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -148,21 +148,38 @@ DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
struct cpuidle_driver omap4_idle_driver = {
.name = omap4_idle,
.owner =THIS_MODULE,
+ .states = {
+ {
+ /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = C1,
+ .desc = MPUSS ON
+ },
...
+ },
+ .state_count = OMAP4_NUM_STATES,
};
-static inline void _fill_cstate(struct cpuidle_driver *drv,
- int idx, const char *descr)
-{
- struct cpuidle_state *state =drv-states[idx];
-
- state-exit_latency = cpuidle_params_table[idx].exit_latency;
- state-target_residency = cpuidle_params_table[idx].target_residency;
- state-flags= CPUIDLE_FLAG_TIME_VALID;
- state-enter= omap4_enter_idle;
- sprintf(state-name, C%d, idx + 1);
- strncpy(state-desc, descr, CPUIDLE_DESC_LEN);
-}
I am OK with this change, which makes the code more readable (and so
maintainable).
-
static inline struct omap4_idle_statedata *_fill_cstate_usage(
struct cpuidle_device *dev,
int idx)
@@ -196,37 +213,28 @@ int __init omap4_idle_init(void)
if ((!mpu_pd) || (!cpu0_pd) || (!cpu1_pd))
return -ENODEV;
-
- drv-safe_state_index = -1;
dev =per_cpu(omap4_idle_dev, cpu_id);
dev-cpu = cpu_id;
- /* C1 - CPU0 ON + CPU1 ON + MPU ON */
- _fill_cstate(drv, 0, MPUSS ON);
- drv-safe_state_index = 0;
I would keep this or add a clear comment that C1 is the safe state.
Actually with the driver's states declaration, the safe_state_index is
initialized to zero, which means the default safe_state is always 0 with
the new API. But I can add the initialization anyway in the structure
declaration if you want.
...
Thanks,
Jean
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On 03/21/2012 02:19 PM, Jean Pihet wrote: Hi Santosh, Daniel, On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Daniel, On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. A couple a things call my intention. Why the cpuidle device is set for cpu0 only and why the WFI is not used ? Daniel Lezcano (7): ARM: OMAP4: cpuidle - Remove unused valid field ARM: OMAP4: cpuidle - Declare the states with the driver declaration ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time The series looks fine to me in general. This clean-up is applicable for OMAP3 cpuidle code as well. I want Jean to look at this series because some of his earlier clean up has introduced those custom functions which are getting removed in this series. I am OK with the patch set, I only have minor remarks to the individual patches. Reviewed-by: Jean Pihetj-pi...@ti.com Thanks for the review Jean. Thanks! Jean -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3+: fix oops triggered in omap_prcm_register_chain_handler
Ming Lei tom.leim...@gmail.com writes:
This patch fixes the oos below:
As Tero mentioned, please add a bit more description to the changelog
about why the iterator is wrong and repost.
Thanks for the patch. After the above changes, I'll queue this up for v3.4-rc.
Kevin
[1.790242] Unable to handle kernel NULL pointer dereference at virtual
address 0004
[1.798632] pgd = c0004000
[1.801638] [0004] *pgd=
[1.805400] Internal error: Oops: 805 [#1] PREEMPT SMP THUMB2
[1.811381] Modules linked in:
[1.814601] CPU: 1Not tainted (3.3.0-next-20120320+ #733)
[1.820683] PC is at irq_setup_generic_chip+0x6a/0x84
[1.825951] LR is at irq_get_irq_data+0x7/0x8
[1.830508] pc : [c006465e]lr : [c0063a03]psr: 2133
[1.830512] sp : ee04ff58 ip : fp :
[1.842461] r10: r9 : r8 : 0800
[1.847905] r7 : c064e260 r6 : 01dc r5 : 0001 r4 : ee0accc0
[1.854687] r3 : 0002 r2 : 0800 r1 : 01dc r0 :
[1.861472] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment
kernel
[1.869234] Control: 50c5387d Table: 8000404a DAC: 0015
[1.875215] Process swapper/0 (pid: 1, stack limit = 0xee04e2f8)
[1.881463] Stack: (0xee04ff58 to 0xee05)
[1.886017] ff40: c061b668 0008
[1.894497] ff60: c0682090 ee0accc0 0003 c001c637
0201
[1.902976] ff80: 0004 c0473820 c0473800 c0459e8d c0680ac0 c000866d
0004 0004
[1.911455] ffa0: ee04ffa8 0004 c047381c 0004 c0473820 c0473800
c0680ac0 0082
[1.919934] ffc0: c0489694 c045265f 0004 0004 c0452135 c000d105
0033
[1.928413] ffe0: c04525b5 c000d111 0033 c000d111
[1.936912] [c006465e] (irq_setup_generic_chip+0x6a/0x84) from
[c001c637] (omap_prcm_register_chain_handler+0x147/0x1a0)
[1.948516] [c001c637] (omap_prcm_register_chain_handler+0x147/0x1a0)
from [c000866d] (do_one_initcall+0x65/0xf4)
[1.959500] [c000866d] (do_one_initcall+0x65/0xf4) from [c045265f]
(kernel_init+0xab/0x138)
[1.968529] [c045265f] (kernel_init+0xab/0x138) from [c000d111]
(kernel_thread_exit+0x1/0x6)
[1.977632] Code: f7ff f9d1 6b23 1af3 (6043) 086d
[1.982684] ---[ end trace 1b75b31a2719ed1c ]---
[1.987526] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Ming Lei tom.leim...@gmail.com
---
arch/arm/mach-omap2/prm_common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prm_common.c
b/arch/arm/mach-omap2/prm_common.c
index 873b51d..d28f848 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -290,7 +290,7 @@ int omap_prcm_register_chain_handler(struct
omap_prcm_irq_setup *irq_setup)
goto err;
}
- for (i = 0; i = irq_setup-nr_regs; i++) {
+ for (i = 0; i irq_setup-nr_regs; i++) {
gc = irq_alloc_generic_chip(PRCM, 1,
irq_setup-base_irq + i * 32, prm_base,
handle_level_irq);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On 03/21/2012 02:43 PM, Jean Pihet wrote: On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Daniel, On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. A couple a things call my intention. Why the cpuidle device is set for cpu0 only and why the WFI is not used ? Daniel Lezcano (7): ARM: OMAP4: cpuidle - Remove unused valid field ARM: OMAP4: cpuidle - Declare the states with the driver declaration ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time The series looks fine to me in general. This clean-up is applicable for OMAP3 cpuidle code as well. Great! However OMAP3 has a few specific things that cannot be removed as easily: - the 'valid' flag is used because only certain combinations of power domains states are possible, - the latency settings can be overriden by the board code, so the cpuidle_params struct is needed. Right, I noticed that. I am looking for a way to have a similar cleanup for omap3 but without breaking the rx51 board. Thanks -- Daniel I want Jean to look at this series because some of his earlier clean up has introduced those custom functions which are getting removed in this series. Regards santosh Thanks, Jean -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On Wed, Mar 21, 2012 at 6:49 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Santosh, Daniel, On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Daniel, On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote: This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself. A couple a things call my intention. Why the cpuidle device is set for cpu0 only and why the WFI is not used ? Daniel Lezcano (7): ARM: OMAP4: cpuidle - Remove unused valid field ARM: OMAP4: cpuidle - Declare the states with the driver declaration ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time The series looks fine to me in general. This clean-up is applicable for OMAP3 cpuidle code as well. I want Jean to look at this series because some of his earlier clean up has introduced those custom functions which are getting removed in this series. I am OK with the patch set, I only have minor remarks to the individual patches. Reviewed-by: Jean Pihet j-pi...@ti.com Thanks Jean for looking at it. Daniel, Feel free to add. Reviewed-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
Re: [PATCH v8 4/8] ARM: davinci: Consolidate time keeping and irq enable
Sekhar tested this patch on Davinci last night and found a problem. I
looked at the code again and found a mindless omission on my part (see
below). Fix is trivial. I've check all other platforms and confirmed
this problem does not exist for those. Will resend a v9 of the
patchset shortly.
On Tue, Mar 20, 2012 at 3:22 PM, Robert Lee rob@linaro.org wrote:
Enable core cpuidle timekeeping and irq enabling and remove that
handling from this code.
Signed-off-by: Robert Lee rob@linaro.org
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-davinci/cpuidle.c | 82
---
1 file changed, 33 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index a30c7c5..93ae096 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -18,6 +18,7 @@
#include linux/io.h
#include linux/export.h
#include asm/proc-fns.h
+#include asm/cpuidle.h
#include mach/cpuidle.h
#include mach/ddr2.h
@@ -30,12 +31,42 @@ struct davinci_ops {
u32 flags;
};
+/* Actual code that puts the SoC in different idle states */
+static int davinci_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct cpuidle_state_usage *state_usage = dev-states_usage[index];
+ struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
+
+ if (ops ops-enter)
+ ops-enter(ops-flags);
+
+ index = cpuidle_wrap_enter(dev, drv, index,
+ arm_cpuidle_simple_enter);
+
+ if (ops ops-exit)
+ ops-exit(ops-flags);
+
+ return index;
+}
+
/* fields in davinci_ops.flags */
#define DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN BIT(0)
static struct cpuidle_driver davinci_idle_driver = {
- .name = cpuidle-davinci,
- .owner = THIS_MODULE,
+ .name = cpuidle-davinci,
+ .owner = THIS_MODULE,
Argh! I am missing the .en_core_tk_irqen = 1 here.
+ .states[0] = ARM_CPUIDLE_WFI_STATE,
+ .states[1] = {
+ .enter = davinci_enter_idle,
+ .exit_latency = 10,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = DDR SR,
+ .desc = WFI and DDR Self Refresh,
+ },
+ .state_count = DAVINCI_CPUIDLE_MAX_STATES,
};
static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
@@ -77,41 +108,10 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
},
};
-/* Actual code that puts the SoC in different idle states */
-static int davinci_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- struct cpuidle_state_usage *state_usage = dev-states_usage[index];
- struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
- struct timeval before, after;
- int idle_time;
-
- local_irq_disable();
- do_gettimeofday(before);
-
- if (ops ops-enter)
- ops-enter(ops-flags);
- /* Wait for interrupt state */
- cpu_do_idle();
- if (ops ops-exit)
- ops-exit(ops-flags);
-
- do_gettimeofday(after);
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
-
- dev-last_residency = idle_time;
-
- return index;
-}
-
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
{
int ret;
struct cpuidle_device *device;
- struct cpuidle_driver *driver = davinci_idle_driver;
struct davinci_cpuidle_config *pdata = pdev-dev.platform_data;
device = per_cpu(davinci_cpuidle_device, smp_processor_id());
@@ -123,27 +123,11 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
ddr2_reg_base = pdata-ddr2_ctlr_base;
- /* Wait for interrupt state */
- driver-states[0].enter = davinci_enter_idle;
- driver-states[0].exit_latency = 1;
- driver-states[0].target_residency = 1;
- driver-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(driver-states[0].name, WFI);
- strcpy(driver-states[0].desc, Wait for interrupt);
-
- /* Wait for interrupt and DDR self refresh state */
- driver-states[1].enter = davinci_enter_idle;
- driver-states[1].exit_latency = 10;
- driver-states[1].target_residency = 1;
-
Re: [PATCH 0/3] OMAP2+: UART: Enable tx wakeup + remove cpu checks
Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com Based on Linux-OMAP tree uart branch. (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git remotes/origin/uart) * Removes the cpu checks wherever possible and use version reg for populating features and errata's * enable tx wakeup available in wer reg for applicable module revision's As this affects multiple SoCs, please report what SoCs it was tested on as well. Thanks, Kevin Govindraj.R (3): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx arch/arm/mach-omap2/serial.c | 13 + arch/arm/plat-omap/include/plat/omap-serial.h |8 +++- drivers/tty/serial/omap-serial.c | 71 - 3 files changed, 78 insertions(+), 14 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 v2] usb: musb: wake the device before ulpi transfers
musb can be suspended at the time some other driver wants to do ulpi
transfers using usb_phy_io_* functions, and that can cause data abort,
as it happened with isp1704_charger:
http://article.gmane.org/gmane.linux.kernel/1226122
Add pm_runtime to ulpi functions to rectify this. This also adds io_dev
to usb_phy so that pm_runtime_* functions can be used.
Cc: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
v2: refreshed for current tree
drivers/usb/musb/musb_core.c | 31 +--
include/linux/usb/otg.h |1 +
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2392146..66aaccf 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -137,6 +137,9 @@ static int musb_ulpi_read(struct usb_phy *phy, u32 offset)
int i = 0;
u8 r;
u8 power;
+ int ret;
+
+ pm_runtime_get_sync(phy-io_dev);
/* Make sure the transceiver is not in low power mode */
power = musb_readb(addr, MUSB_POWER);
@@ -154,15 +157,22 @@ static int musb_ulpi_read(struct usb_phy *phy, u32 offset)
while (!(musb_readb(addr, MUSB_ULPI_REG_CONTROL)
MUSB_ULPI_REG_CMPLT)) {
i++;
- if (i == 1)
- return -ETIMEDOUT;
+ if (i == 1) {
+ ret = -ETIMEDOUT;
+ goto out;
+ }
}
r = musb_readb(addr, MUSB_ULPI_REG_CONTROL);
r = ~MUSB_ULPI_REG_CMPLT;
musb_writeb(addr, MUSB_ULPI_REG_CONTROL, r);
- return musb_readb(addr, MUSB_ULPI_REG_DATA);
+ ret = musb_readb(addr, MUSB_ULPI_REG_DATA);
+
+out:
+ pm_runtime_put(phy-io_dev);
+
+ return ret;
}
static int musb_ulpi_write(struct usb_phy *phy, u32 offset, u32 data)
@@ -171,6 +181,9 @@ static int musb_ulpi_write(struct usb_phy *phy, u32 offset,
u32 data)
int i = 0;
u8 r = 0;
u8 power;
+ int ret = 0;
+
+ pm_runtime_get_sync(phy-io_dev);
/* Make sure the transceiver is not in low power mode */
power = musb_readb(addr, MUSB_POWER);
@@ -184,15 +197,20 @@ static int musb_ulpi_write(struct usb_phy *phy, u32
offset, u32 data)
while (!(musb_readb(addr, MUSB_ULPI_REG_CONTROL)
MUSB_ULPI_REG_CMPLT)) {
i++;
- if (i == 1)
- return -ETIMEDOUT;
+ if (i == 1) {
+ ret = -ETIMEDOUT;
+ goto out;
+ }
}
r = musb_readb(addr, MUSB_ULPI_REG_CONTROL);
r = ~MUSB_ULPI_REG_CMPLT;
musb_writeb(addr, MUSB_ULPI_REG_CONTROL, r);
- return 0;
+out:
+ pm_runtime_put(phy-io_dev);
+
+ return ret;
}
#else
#define musb_ulpi_read NULL
@@ -1908,6 +1926,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
}
if (!musb-xceiv-io_ops) {
+ musb-xceiv-io_dev = musb-controller;
musb-xceiv-io_priv = musb-mregs;
musb-xceiv-io_ops = musb_ulpi_access;
}
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index f67810f..38ab3f4 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -94,6 +94,7 @@ struct usb_phy {
struct usb_otg *otg;
+ struct device *io_dev;
struct usb_phy_io_ops *io_ops;
void __iomem*io_priv;
--
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 v8 4/8] ARM: davinci: Consolidate time keeping and irq enable
On Wed, Mar 21, 2012 at 9:28 AM, Rob Lee rob@linaro.org wrote:
Sekhar tested this patch on Davinci last night and found a problem. I
looked at the code again and found a mindless omission on my part (see
below). Fix is trivial. I've check all other platforms and confirmed
this problem does not exist for those. Will resend a v9 of the
patchset shortly.
Kevin just informed me that Len already has v8 patchset queued so I'll
just send this fix out as a separate patch.
On Tue, Mar 20, 2012 at 3:22 PM, Robert Lee rob@linaro.org wrote:
Enable core cpuidle timekeeping and irq enabling and remove that
handling from this code.
Signed-off-by: Robert Lee rob@linaro.org
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-davinci/cpuidle.c | 82
---
1 file changed, 33 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c
b/arch/arm/mach-davinci/cpuidle.c
index a30c7c5..93ae096 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -18,6 +18,7 @@
#include linux/io.h
#include linux/export.h
#include asm/proc-fns.h
+#include asm/cpuidle.h
#include mach/cpuidle.h
#include mach/ddr2.h
@@ -30,12 +31,42 @@ struct davinci_ops {
u32 flags;
};
+/* Actual code that puts the SoC in different idle states */
+static int davinci_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct cpuidle_state_usage *state_usage = dev-states_usage[index];
+ struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
+
+ if (ops ops-enter)
+ ops-enter(ops-flags);
+
+ index = cpuidle_wrap_enter(dev, drv, index,
+ arm_cpuidle_simple_enter);
+
+ if (ops ops-exit)
+ ops-exit(ops-flags);
+
+ return index;
+}
+
/* fields in davinci_ops.flags */
#define DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN BIT(0)
static struct cpuidle_driver davinci_idle_driver = {
- .name = cpuidle-davinci,
- .owner = THIS_MODULE,
+ .name = cpuidle-davinci,
+ .owner = THIS_MODULE,
Argh! I am missing the .en_core_tk_irqen = 1 here.
+ .states[0] = ARM_CPUIDLE_WFI_STATE,
+ .states[1] = {
+ .enter = davinci_enter_idle,
+ .exit_latency = 10,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = DDR SR,
+ .desc = WFI and DDR Self Refresh,
+ },
+ .state_count = DAVINCI_CPUIDLE_MAX_STATES,
};
static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
@@ -77,41 +108,10 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
},
};
-/* Actual code that puts the SoC in different idle states */
-static int davinci_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- struct cpuidle_state_usage *state_usage = dev-states_usage[index];
- struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
- struct timeval before, after;
- int idle_time;
-
- local_irq_disable();
- do_gettimeofday(before);
-
- if (ops ops-enter)
- ops-enter(ops-flags);
- /* Wait for interrupt state */
- cpu_do_idle();
- if (ops ops-exit)
- ops-exit(ops-flags);
-
- do_gettimeofday(after);
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
-
- dev-last_residency = idle_time;
-
- return index;
-}
-
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
{
int ret;
struct cpuidle_device *device;
- struct cpuidle_driver *driver = davinci_idle_driver;
struct davinci_cpuidle_config *pdata = pdev-dev.platform_data;
device = per_cpu(davinci_cpuidle_device, smp_processor_id());
@@ -123,27 +123,11 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
ddr2_reg_base = pdata-ddr2_ctlr_base;
- /* Wait for interrupt state */
- driver-states[0].enter = davinci_enter_idle;
- driver-states[0].exit_latency = 1;
- driver-states[0].target_residency = 1;
- driver-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(driver-states[0].name, WFI);
- strcpy(driver-states[0].desc, Wait for interrupt);
-
- /* Wait for interrupt and DDR self
Re: [PATCH v8 4/8] ARM: davinci: Consolidate time keeping and irq enable
Rob, you should start a new '3.4-fixes' branch containing such
bugfixes that can be pushed to Len after -rc1.
On Wed, Mar 21, 2012 at 4:28 PM, Rob Lee rob@linaro.org wrote:
Sekhar tested this patch on Davinci last night and found a problem. I
looked at the code again and found a mindless omission on my part (see
below). Fix is trivial. I've check all other platforms and confirmed
this problem does not exist for those. Will resend a v9 of the
patchset shortly.
On Tue, Mar 20, 2012 at 3:22 PM, Robert Lee rob@linaro.org wrote:
Enable core cpuidle timekeeping and irq enabling and remove that
handling from this code.
Signed-off-by: Robert Lee rob@linaro.org
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-davinci/cpuidle.c | 82
---
1 file changed, 33 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c
b/arch/arm/mach-davinci/cpuidle.c
index a30c7c5..93ae096 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -18,6 +18,7 @@
#include linux/io.h
#include linux/export.h
#include asm/proc-fns.h
+#include asm/cpuidle.h
#include mach/cpuidle.h
#include mach/ddr2.h
@@ -30,12 +31,42 @@ struct davinci_ops {
u32 flags;
};
+/* Actual code that puts the SoC in different idle states */
+static int davinci_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct cpuidle_state_usage *state_usage = dev-states_usage[index];
+ struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
+
+ if (ops ops-enter)
+ ops-enter(ops-flags);
+
+ index = cpuidle_wrap_enter(dev, drv, index,
+ arm_cpuidle_simple_enter);
+
+ if (ops ops-exit)
+ ops-exit(ops-flags);
+
+ return index;
+}
+
/* fields in davinci_ops.flags */
#define DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN BIT(0)
static struct cpuidle_driver davinci_idle_driver = {
- .name = cpuidle-davinci,
- .owner = THIS_MODULE,
+ .name = cpuidle-davinci,
+ .owner = THIS_MODULE,
Argh! I am missing the .en_core_tk_irqen = 1 here.
+ .states[0] = ARM_CPUIDLE_WFI_STATE,
+ .states[1] = {
+ .enter = davinci_enter_idle,
+ .exit_latency = 10,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = DDR SR,
+ .desc = WFI and DDR Self Refresh,
+ },
+ .state_count = DAVINCI_CPUIDLE_MAX_STATES,
};
static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
@@ -77,41 +108,10 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
},
};
-/* Actual code that puts the SoC in different idle states */
-static int davinci_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- struct cpuidle_state_usage *state_usage = dev-states_usage[index];
- struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
- struct timeval before, after;
- int idle_time;
-
- local_irq_disable();
- do_gettimeofday(before);
-
- if (ops ops-enter)
- ops-enter(ops-flags);
- /* Wait for interrupt state */
- cpu_do_idle();
- if (ops ops-exit)
- ops-exit(ops-flags);
-
- do_gettimeofday(after);
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
-
- dev-last_residency = idle_time;
-
- return index;
-}
-
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
{
int ret;
struct cpuidle_device *device;
- struct cpuidle_driver *driver = davinci_idle_driver;
struct davinci_cpuidle_config *pdata = pdev-dev.platform_data;
device = per_cpu(davinci_cpuidle_device, smp_processor_id());
@@ -123,27 +123,11 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
ddr2_reg_base = pdata-ddr2_ctlr_base;
- /* Wait for interrupt state */
- driver-states[0].enter = davinci_enter_idle;
- driver-states[0].exit_latency = 1;
- driver-states[0].target_residency = 1;
- driver-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(driver-states[0].name, WFI);
- strcpy(driver-states[0].desc, Wait for interrupt);
-
- /* Wait for interrupt and DDR self refresh
Re: [PATCH 2/2] usb: musb: wake the device before ulpi transfers
On Wed, Mar 21, 2012 at 12:10 PM, Felipe Balbi ba...@ti.com wrote: On Sat, Feb 04, 2012 at 07:43:52PM +0200, Grazvydas Ignotas wrote: musb can be suspended at the time some other driver wants to do ulpi transfers using otg_io_* functions, and that can cause data abort, as it happened with isp1704_charger: http://article.gmane.org/gmane.linux.kernel/1226122 Add pm_runtime to ulpi functions to rectify this. This also adds io_dev to otg_transceiver so that pm_runtime can be used. Cc: Felipe Contreras felipe.contre...@gmail.com Signed-off-by: Grazvydas Ignotas nota...@gmail.com doesn't apply, please refresh. done. -- Gražvydas -- 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] usb: musb: wake the device before ulpi transfers
On Wed, Mar 21, 2012 at 04:35:52PM +0200, Grazvydas Ignotas wrote: musb can be suspended at the time some other driver wants to do ulpi transfers using usb_phy_io_* functions, and that can cause data abort, as it happened with isp1704_charger: http://article.gmane.org/gmane.linux.kernel/1226122 Add pm_runtime to ulpi functions to rectify this. This also adds io_dev to usb_phy so that pm_runtime_* functions can be used. Cc: Felipe Contreras felipe.contre...@gmail.com Signed-off-by: Grazvydas Ignotas nota...@gmail.com applied, thanks -- balbi signature.asc Description: Digital signature
Re: smsc911x on Gumstix Overo/Tobi doesn't work
Am 20.03.2012 20:47, schrieb Javier Martinez Canillas: On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute thomas2.kl...@uni-dortmund.de wrote: Am 19.03.2012 23:51, schrieb Tony Lindgren: * Thomas Klute thomas2.kl...@uni-dortmund.de [120319 09:26]: Am 16.03.2012 20:33, schrieb Tony Lindgren: Hi, * Thomas Klute thomas2.kl...@uni-dortmund.de [120316 05:08]: Hi, I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows: du14:~# modprobe smsc911x [ 254.843811] smsc911x: Driver version 2008-10-21 [ 254.854553] smsc911x: Driver version 2008-10-21 [ 254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using dummy regulator [ 254.868377] _regulator_get: smsc911x.1 supply vddvario not found, using dummy regulator ip link show does not show any available Ethernet port. The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3. The Tobi board has only one Ethernet port. I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case. The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed. Care to test the following patch by passing a fixed regulator from board-overo.c? After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you! Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted? You're right, during further tests I found that the problem lies elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after # modprobe -r smsc911x [attach cable] # modprobe smsc911x it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem. Hi Thomas, I had the same behavior with the smsc911x chip but on an IGEPv2 board. The problem was when CONFIG_SMSC_PHY=y since the driver for the chip internal PHY enables an energy detect power-down mode. The smsc911x driver probe function tries to software reset the chip but if the cable is unplugged the energy detect puts the chip in a low power mode. Since the chip is not in an operational state the reset fails and hence the driver probe function. If the cable is plugged then then energy is detected, the chip is in an operational state and the reset is successful. I sent a patch a few months ago to fix this issue. The patch disables the energy detect power-down mode before reseting the chip and then it enables again after reset. The commit is: commit 6386994e03ebbe60338ded3d586308a41e81c0dc Author: Javier Martinez Canillas jav...@dowhile0.org Date: Tue Jan 3 13:36:19 2012 + net/smsc911x: Check if PHY is in operational mode before software reset When I fix the issue I only guarded against generation 4 chips (i.e: pdata-generation == 4), but maybe this problem also exists in other SMSC chips (I didn't know since I only had access to specific data-sheets). Also you can try enabling debug in the driver by setting USE_DEBUG to 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put the chip in auto power mode. Hi Javier, thanks for the hint. Deactivating CONFIG_SMSC_PHY didn't help, but I'll look into activating USE_DEBUG later. Regards, Thomas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/7] OMAP4 cpuidle cleanup
On 03/21/2012 02:43 PM, Jean Pihet wrote:
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not change the behavior of the
driver itself.
A couple a things call my intention. Why the cpuidle device is set for cpu0 only
and why the WFI is not used ?
Daniel Lezcano (7):
ARM: OMAP4: cpuidle - Remove unused valid field
ARM: OMAP4: cpuidle - Declare the states with the driver declaration
ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table
ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time
ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot
time
The series looks fine to me in general. This clean-up is applicable
for OMAP3 cpuidle code as well.
Great!
However OMAP3 has a few specific things that cannot be removed as easily:
- the 'valid' flag is used because only certain combinations of power
domains states are possible,
When I look the board-rx51 code I see:
static struct cpuidle_params rx51_cpuidle_params[] = {
/* C1 */
{110 + 162, 5 , 1},
/* C2 */
{106 + 180, 309, 1},
/* C3 */
{107 + 410, 46057, 0},
/* C4 */
{121 + 3374, 46057, 0},
/* C5 */
{855 + 1146, 46057, 1},
/* C6 */
{7580 + 4134, 484329, 0},
/* C7 */
{7505 + 15274, 484329, 1},
};
If C3, C4, C6 are not valid, so AFAICS never used in the cpuidle code
why the values are 'exit_latency' and 'target_residency' specified ? I
mean why don't we have { 0, 0, 0 } ? Is it just for information ?
I understand the purpose of this code but it looks a bit tricky and hard
to factor out. Is it acceptable to create a new cpuidle driver for rx51
then we factor out the code between omap3, omap4 and rx51 when all the
code consistent ?
- the latency settings can be overriden by the board code, so the
cpuidle_params struct is needed.
I want Jean to look at this series because some of his earlier
clean up has introduced those custom functions which
are getting removed in this series.
Regards
santosh
Thanks,
Jean
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Add TWL4030 PWM driver
On Tue, Mar 20, 2012 at 6:48 PM, Bernhard Walle wa...@corscience.de wrote: This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030 PWM has been used as mode, but the PWM registers are different. The driver can be used and has been tested in conjunction with pwm-backlight to control a backlight LED of a LCD touch screen. Nice, could we also have LEDA and LEDB pwm control as pwm_id 2 and 3 in next version? No worries if you don't want it, I could try to take a stab at that later. -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.
Commit c7e963f616 (net/smsc911x: Add regulator support) breaks
registration of gpmc connected smcs911x devices on machines with
regulator support, but without dummy regulator support.
Commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add
required smsc911x regulators) fixed the issue for boards with single
smsc911x devices, but attempted to register the fixed voltage regulator
twice for boards with 2 devices which fails.
A proper fix needs to supply a proper regulator/consumer mapping for
each smsc911x device. The below patch does that. However, it also
points out how unmanageable things will become if regulators are required
for each and every device for the sake of the one board where they need
to be enabled.
In the case of the smsc911x driver, the ST-Ericsson Snowball has regulators
that need to be powered up for the smsc911x to function. Robert Marklund
added functionality to the smsc911x driver to power up its regulators at
probe time and power them off at remove time. One can see how quickly
unwieldy this would become if it were done for every device. Either the
functionality needs to be moved to Snowball board init code, or a generic
framework needs to be made for attaching regulators to arbitrary devices.
Incidentally, while the patch for the smsc911x regulators is in, it does not
appear that the patch for the snowball to supply these is in.
This patch has been compile tested, but not run tested.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 34 +-
arch/arm/mach-omap2/board-igep0020.c| 15 +++--
arch/arm/mach-omap2/board-ldp.c | 14 ++--
arch/arm/mach-omap2/board-omap3evm.c| 21 --
arch/arm/mach-omap2/board-omap3logic.c | 18 +++--
arch/arm/mach-omap2/board-omap3stalker.c| 15 +++--
arch/arm/mach-omap2/board-overo.c | 32 +-
arch/arm/mach-omap2/board-zoom-debugboard.c | 14 ++--
arch/arm/mach-omap2/gpmc-smsc911x.c | 79 +--
arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |6 +-
10 files changed, 154 insertions(+), 94 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index d73316e..4090ca1 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -65,26 +65,28 @@
#include linux/smsc911x.h
#include plat/gpmc-smsc911x.h
-static struct omap_smsc911x_platform_data cm_t35_smsc911x_cfg = {
- .id = 0,
- .cs = CM_T35_SMSC911X_CS,
- .gpio_irq = CM_T35_SMSC911X_GPIO,
- .gpio_reset = -EINVAL,
- .flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
-};
-
-static struct omap_smsc911x_platform_data sb_t35_smsc911x_cfg = {
- .id = 1,
- .cs = SB_T35_SMSC911X_CS,
- .gpio_irq = SB_T35_SMSC911X_GPIO,
- .gpio_reset = -EINVAL,
- .flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
+static struct omap_smsc911x_platform_data cm_smsc911x_cfg[] = {
+ {
+ .id = 0,
+ .cs = CM_T35_SMSC911X_CS,
+ .gpio_irq = CM_T35_SMSC911X_GPIO,
+ .gpio_reset = -EINVAL,
+ .flags = SMSC911X_USE_32BIT
+ | SMSC911X_SAVE_MAC_ADDRESS,
+ },
+ {
+ .id = 1,
+ .cs = SB_T35_SMSC911X_CS,
+ .gpio_irq = SB_T35_SMSC911X_GPIO,
+ .gpio_reset = -EINVAL,
+ .flags = SMSC911X_USE_32BIT
+ | SMSC911X_SAVE_MAC_ADDRESS,
+ }
};
static void __init cm_t35_init_ethernet(void)
{
- gpmc_smsc911x_init(cm_t35_smsc911x_cfg);
- gpmc_smsc911x_init(sb_t35_smsc911x_cfg);
+ gpmc_smsc911x_init(cm_smsc911x_cfg, ARRAY_SIZE(cm_smsc911x_cfg));
}
#else
static inline void __init cm_t35_init_ethernet(void) { return; }
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index a59ace0..b5523b5 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -206,16 +206,19 @@ static void __init igep_flash_init(void) {}
#include linux/smsc911x.h
#include plat/gpmc-smsc911x.h
-static struct omap_smsc911x_platform_data smsc911x_cfg = {
- .cs = IGEP2_SMSC911X_CS,
- .gpio_irq = IGEP2_SMSC911X_GPIO,
- .gpio_reset = -EINVAL,
- .flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
+static struct omap_smsc911x_platform_data smsc911x_cfg[] = {
+ {
+ .cs = IGEP2_SMSC911X_CS,
+ .gpio_irq = IGEP2_SMSC911X_GPIO,
+ .gpio_reset = -EINVAL,
+ .flags = SMSC911X_USE_32BIT
+ |
[GIT PULL] omap fixes for merge window
Hi Arnd Olof, Here's a set of fixes that would be nice to get merged during the merge window before the GPIO changes get merged to avoid boot issues on many omap boards. The changes queued in the GPIO tree require getting rid of OMAP_GPIO_IRQ and use gpio_to_irq() instead. This is needed for dynamically allocated GPIO interrupt ranges. Ideally these changes would have been done way earlier of course. Unfortunately this issue was not discovered until last week while testing linux-next. Also included is one fix for the wrong __init changes for display.c. This branch is based on the previously merged fixes-non-critical-part3 as that's pretty much the earliest point where these apply. Note that these might add on a bit to the existing trivial merge conflicts with drivers/video related board file clean-up queued by Tomi. Regards, Tony The following changes since commit 4647ca5761f5534470e98d06494403a2fd0d7b32: Tony Lindgren (1): ARM: OMAP2+: Fix build for omap4 only builds with missing include of linux/bug.h are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap cleanup-fixes Tarun Kanti DebBarma (3): ARM: OMAP: boards: Fix OMAP_GPIO_IRQ usage with gpio_to_irq() drivers: input: Fix OMAP_GPIO_IRQ with gpio_to_irq() in ams_delta_serio_exit() ARM: OMAP: Remove OMAP_GPIO_IRQ macro definition Tomi Valkeinen (1): ARM: OMAP2+: Remove __init from DSI mux functions arch/arm/mach-omap1/board-h2.c |8 arch/arm/mach-omap1/board-h3.c |9 - arch/arm/mach-omap1/board-htcherald.c|6 +++--- arch/arm/mach-omap1/board-innovator.c|4 ++-- arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap1/board-osk.c | 12 ++-- arch/arm/mach-omap1/board-palmte.c |2 +- arch/arm/mach-omap1/board-palmtt.c |2 +- arch/arm/mach-omap1/board-palmz71.c |2 +- arch/arm/mach-omap1/board-voiceblue.c| 16 +++- arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-4430sdp.c |2 +- arch/arm/mach-omap2/board-apollon.c |6 -- arch/arm/mach-omap2/board-devkit8000.c |3 ++- arch/arm/mach-omap2/board-h4.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap4panda.c |2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |3 ++- arch/arm/mach-omap2/board-zoom-debugboard.c |3 ++- arch/arm/mach-omap2/board-zoom-peripherals.c |6 -- arch/arm/mach-omap2/common-board-devices.c |2 +- arch/arm/mach-omap2/display.c|8 arch/arm/plat-omap/include/plat/gpio.h |4 drivers/input/serio/ams_delta_serio.c|2 +- 24 files changed, 55 insertions(+), 55 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
Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.
On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote:
unwieldy this would become if it were done for every device. Either the
functionality needs to be moved to Snowball board init code, or a generic
framework needs to be made for attaching regulators to arbitrary devices.
Hrm? Adding regulator supply mappings anywhere other than the
initialisation for a specific board would be extremely unusual and
rather suspicious.
+ supplies = kcalloc(ARRAY_SIZE(smsc911x_refs) * num,
+ sizeof(struct regulator_consumer_supply), GFP_KERNEL);
+ if (!supplies) {
+ pr_err(Failed to allocate memory\n);
+ return;
+ }
+
+ for (i = 0; i ARRAY_SIZE(smsc911x_refs) * num; i++) {
+ int id;
+ char *name;
+
+ id = board_data[i / num].id;
+ if (id != -1)
+ name = kasprintf(GFP_KERNEL, smsc911x.%d, id);
+ else
+ name = kstrdup(smsc911x, GFP_KERNEL);
This seems pretty much insane, it's costing a lot more to faff around
like this than it's worth. Just do the setup in the individual boards,
if you really have no idea what's supplying the device (which seems a
bit unusual, more boards like this have things coming off the PMIC than
don't) there's now regulator_register_fixed() which cuts down on the
boilerplate a little.
I'd have complained about the original code if I'd noticed it wasn't a
patch for a particular board as the breakage you've found is obvious.
The regulation constraints it adds are bogus too, it's setting
REGULATOR_CHANGE_MODE on a regulator that doesn't support modes and
REGULATOR_CHANGE_STATUS without supplying the enable GPIO.
signature.asc
Description: Digital signature
Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.
On Mar 21, 2012, at 2:13 PM, Mark Brown wrote:
On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote:
+for (i = 0; i ARRAY_SIZE(smsc911x_refs) * num; i++) {
+int id;
+char *name;
+
+id = board_data[i / num].id;
+if (id != -1)
+name = kasprintf(GFP_KERNEL, smsc911x.%d, id);
+else
+name = kstrdup(smsc911x, GFP_KERNEL);
This seems pretty much insane, it's costing a lot more to faff around
like this than it's worth. Just do the setup in the individual boards,
if you really have no idea what's supplying the device (which seems a
bit unusual, more boards like this have things coming off the PMIC than
don't) there's now regulator_register_fixed() which cuts down on the
boilerplate a little.
I'd have complained about the original code if I'd noticed it wasn't a
patch for a particular board as the breakage you've found is obvious.
The regulation constraints it adds are bogus too, it's setting
REGULATOR_CHANGE_MODE on a regulator that doesn't support modes and
REGULATOR_CHANGE_STATUS without supplying the enable GPIO.
The original patch for the problem was specific to the fixed regulator
on the OMAP3EVM/AMDM37xxEVM board...it was rejected. I was asked to
put something generic in gpmc-smsc911x.c like this.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.
On Mar 21, 2012, at 2:13 PM, Mark Brown wrote: On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote: unwieldy this would become if it were done for every device. Either the functionality needs to be moved to Snowball board init code, or a generic framework needs to be made for attaching regulators to arbitrary devices. Hrm? Adding regulator supply mappings anywhere other than the initialisation for a specific board would be extremely unusual and rather suspicious. Just to be clear, here is the thread on the board-specific approach: https://lkml.org/lkml/2012/2/8/415 -Matt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/3] Documentation: common clk API
On 03/21/2012 12:44 AM, Paul Walmsley wrote: Hello Saravana, On Tue, 20 Mar 2012, Saravana Kannan wrote: To add a few more thoughts, while I agree with Paul that there is room for improvement in the APIs, I think the difference in opinion comes when we ask the question: When we eventually refine the APIs in the future to be more expressive, do we think that the current APIs can or cannot be made as wrappers around the new more expressive APIs? Absolutes are almost never right, so I can't give an absolute answer. But I'm strongly leaning towards we can as the answer to the question. That combined with the reasons Nicholas mentioned is why I think the APIs should not be marked as experimental in anyway. The resistance to documenting that the clock interface is not well-defined, and that therefore it is likely to change, and that users should not expect it to be stable, is perplexing to me. Certainly a Kconfig help text change seems trivial enough. But even the resistance to CONFIG_EXPERIMENTAL has been quite surprising to me, given that every single defconfig in arch/arm/defconfig sets it: $ find arch/arm/configs -type f | wc -l 122 $ fgrep -r CONFIG_EXPERIMENTAL=y arch/arm/configs | wc -l 122 $ (that includes iMX, by the way...) Certainly, neither Kconfig change is going to prevent us on OMAP from figuring out what else is needed to convert our platform to the common clock code. And given the level of enthusiasm on the lists, I think the enthusiasm we are seeing are from the clock driver developers. And for good reasons. Everyone is tired of having to write or rewrite their own implementation. I don't think it's going to prevent many of the other ARM platforms from experimenting with the conversion, either. So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful. But the enthusiasm of the clock driver developers doesn't necessarily translate to users of the clock APIs (other driver devs). My worry with marking it as experimental in Kconfig and to a certain extent in the documentation is that it will discourage the driver devs from switching to the new APIs. If no one is using the new APIs, then platforms can't switch to the common clock framework either. If a lot of platform don't convert to the common clock framework, the effort to get it merged in now is not also very meaningful. Also, at the rate at which we come to an agreement on new APIs, I think these new APIs should be considered quite stable :-) It's certainly better than what we have today. We should encourage driver devs to move to these new APIs and get the benefits while we go on another 2 yr cycle to agree on the next set of APIs improvements. And as I said before, I think it's much less likely that we will break backward source compatibility when we do the next improvement. We could have mostly avoid this large scale change by calling the APIs prepare/unprepare/gate/ungate (or whatever) and make clk_enable/disable similar to clk_prepare_enable/clk_disable_unprepare(). That would have avoid a lot of drivers from having to mess with their clock calls. But we didn't think about that in the excitement for improved APIs. I think this will still be seared in our minds enough to make sure we don't repeat that in the future. That covers all I have to say on this topic. -Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.
* Porter, Matt mpor...@ti.com [120321 11:27]: On Mar 21, 2012, at 2:13 PM, Mark Brown wrote: On Wed, Mar 21, 2012 at 10:55:54AM -0700, Russ Dill wrote: unwieldy this would become if it were done for every device. Either the functionality needs to be moved to Snowball board init code, or a generic framework needs to be made for attaching regulators to arbitrary devices. Hrm? Adding regulator supply mappings anywhere other than the initialisation for a specific board would be extremely unusual and rather suspicious. The issue here is that we don't want to copy paste the dummy fixed regulator all over the board-*.c files, and we don't know how the real regulator is wired up. Just to be clear, here is the thread on the board-specific approach: https://lkml.org/lkml/2012/2/8/415 We should use the real regulator if passed from board file. And if no real regulator is passed, just use the dummy fixed regulator in gpmc-smsc911x.c. This patch I posted should fix the situation and allow adding the real regulators to board-*.c files when they become known: http://www.spinics.net/lists/linux-omap/msg66714.html Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP DSS for v3.4
On 03/19/2012 11:01 AM, Tomi Valkeinen wrote: Hi Florian, Arnd, Here are the changes for OMAP DSS driver for v3.4. There's an issue with the dss driver that appears on arm-soc/for-next branch, which I'm still solving (http://marc.info/?l=linux-omapm=133214966902577w=2). I hope to get fix for that ready and merged for -rc1, but I'm not sure if I can make it in time, so I wanted to sent this pull request already. Arnd, as discussed before, you can also merge this branch to solve the conflicts between arm-soc and omapdss trees. Note that this is the first pull request I've sent with a branch that I have not been rebasing, so please check that the branch looks sane. Tomi The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7: Linux 3.3 (2012-03-18 16:15:34 -0700) Interesting, I never tried to start at a commit that is not part of the branch. Good to know that it does work. are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-3.4 Merged. Thanks, Florian Tobias Schandinat Archit Taneja (2): OMAPDSS: Features: Maintain dss_feats as a list OMAPDSS: DISPC: Fix scaling constraints for OMAP4 Danny Kukawka (1): OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4 Grazvydas Ignotas (2): OMAPDSS: TPO-TD03MTEA1: fix suspend hang OMAPDSS: TPO-TD03MTEA1: update default gamma Julia Lawall (1): OMAPDSS: use devm_ functions Lajos Molnar (3): OMAPDSS: DISPC: Fix OMAP4 supported color formats OMAPDSS: DISPC: Fix FIR coefficients OMAPDSS: MANAGER/APPLY: Add runtime_pm protection around wait_for_go/vsync functions Mythri P K (6): OMAPDSS: HDMI: remove duplicate video interface code OMAPDSS: HDMI: update static timing table OMAPDSS: HDMI: change the timing match logic OMAPDSS: HDMI: remove duplicate code and mode parameter OMAPDSS: HDMI: Move Avi-infoframe struct to hdmi_ip_data OMAPDSS: HDMI: Add M2 divider while calculating clkout Ricardo Neri (4): OMAPDSS: HDMI: Correct source of the pixel clock in ACR calculation OMAPDSS: Add DSS feature for HDMI MCLK for audio OMAPDSS: HDMI: Implement initialization of MCLK OMAPDSS: HDMI: Modify logic to configure MCLK Tomi Valkeinen (29): OMAPDSS: FEAT: Add FIFO_MERGE feature OMAPDSS: APPLY: add fifo merge support funcs OMAPDSS: APPLY: add fifo-merge support OMAPDSS: DISPC: print fifo threshold values in bytes OMAPDSS: DISPC: move fifo threhold calc to dispc.c OMAPDSS: DISPC: Add naive threshold calc for fifomerge Merge branch 'work/fifomerge' Merge commit 'v3.3-rc4' OMAPDSS: cleanup probe functions OMAPFB: remove old blizzard driver OMAPFB: Remove OMAP2/3 support from old omapfb driver OMAPDSS: Remove video SRAM support OMAPFB: Remove video SRAM support (old omapfb) OMAP2+: remove unneeded #include omapfb.h OMAP: N770: remove HWA742 platform data OAMPFB: remove unused omapfb_set_ctrl_platform_data() OMAPFB: remove early mem alloc from old omapfb OMAPFB: remove mem info from platform_data OMAPFB: remove unused fb_format_to_dss_mode() OMAPFB: Move old omapfb private structs to a private include file OMAPFB: remove omapfb_set_platform_data() OMAP1: pass LCD config with omapfb_set_lcd_config() OMAP: Remove OMAP_TAG_LCD and OMAP_TAG_FBMEM OMAP1: Remove unused LCD devices from board files OMAPFB: remove remaining OMAP arch checks Merge branch 'work/old-omapfb-removal' Merge commit 'v3.3-rc6' OMAPDSS: APPLY: print warning if wait_pending_extra_info_updates fails OMAPDSS: APPLY: fix clearing shadow dirty flag with manual update Tony Lindgren (1): ARM: OMAP2+: Fix compile error when FB_OMAP2 is not set Yegor Yefremov (1): OMAPDSS: add Innolux AT080TN52 display support arch/arm/mach-omap1/board-ams-delta.c |9 +- arch/arm/mach-omap1/board-fsample.c| 15 +- arch/arm/mach-omap1/board-h2.c | 15 +- arch/arm/mach-omap1/board-h3.c |9 +- arch/arm/mach-omap1/board-htcherald.c |9 +- arch/arm/mach-omap1/board-innovator.c | 11 +- arch/arm/mach-omap1/board-nokia770.c | 19 +- arch/arm/mach-omap1/board-osk.c| 14 +- arch/arm/mach-omap1/board-palmte.c | 10 +- arch/arm/mach-omap1/board-palmtt.c | 10 +- arch/arm/mach-omap1/board-palmz71.c| 10 +- arch/arm/mach-omap1/board-perseus2.c | 15 +- arch/arm/mach-omap1/board-sx1.c| 16 +- arch/arm/mach-omap2/io.c |1 - arch/arm/plat-omap/common.c|2
Re: [GIT PULL] OMAP DSS for v3.4
On 03/21/2012 12:39 PM, Tomi Valkeinen wrote:
From 849c07b1fd3d9f23e8ed94436b6221f8652462c0 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Mon, 19 Mar 2012 15:05:02 +0200
Subject: [PATCH] OMAPDSS: register dss drivers in module init
We do the dss driver registration in a rather strange way: we have the
higher level omapdss driver, and we use that driver's probe function to
register the drivers for the rest of the dss devices.
There doesn't seem to be any reason for that, and additionally the
soon-to-be-merged patch ARM: OMAP: omap_device: remove
omap_device_parent will break omapdss initialization with the current
registration model.
This patch changes the registration for all drivers to happen at the
same place, in the init of the module.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Applied.
Thanks,
Florian Tobias Schandinat
---
drivers/video/omap2/dss/core.c | 135
+++-
1 files changed, 77 insertions(+), 58 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8613f86..e8a1207 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -183,42 +183,6 @@ static int omap_dss_probe(struct platform_device *pdev)
dss_init_overlay_managers(pdev);
dss_init_overlays(pdev);
- r = dss_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize DSS platform driver\n);
- goto err_dss;
- }
-
- r = dispc_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize dispc platform driver\n);
- goto err_dispc;
- }
-
- r = rfbi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize rfbi platform driver\n);
- goto err_rfbi;
- }
-
- r = venc_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize venc platform driver\n);
- goto err_venc;
- }
-
- r = dsi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize DSI platform driver\n);
- goto err_dsi;
- }
-
- r = hdmi_init_platform_driver();
- if (r) {
- DSSERR(Failed to initialize hdmi\n);
- goto err_hdmi;
- }
-
r = dss_initialize_debugfs();
if (r)
goto err_debugfs;
@@ -246,18 +210,6 @@ static int omap_dss_probe(struct platform_device *pdev)
err_register:
dss_uninitialize_debugfs();
err_debugfs:
- hdmi_uninit_platform_driver();
-err_hdmi:
- dsi_uninit_platform_driver();
-err_dsi:
- venc_uninit_platform_driver();
-err_venc:
- dispc_uninit_platform_driver();
-err_dispc:
- rfbi_uninit_platform_driver();
-err_rfbi:
- dss_uninit_platform_driver();
-err_dss:
return r;
}
@@ -269,13 +221,6 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
- hdmi_uninit_platform_driver();
- dsi_uninit_platform_driver();
- venc_uninit_platform_driver();
- rfbi_uninit_platform_driver();
- dispc_uninit_platform_driver();
- dss_uninit_platform_driver();
-
dss_uninit_overlays(pdev);
dss_uninit_overlay_managers(pdev);
@@ -525,6 +470,80 @@ static int omap_dss_bus_register(void)
/* INIT */
+static int __init omap_dss_register_drivers(void)
+{
+ int r;
+
+ r = platform_driver_register(omap_dss_driver);
+ if (r)
+ return r;
+
+ r = dss_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize DSS platform driver\n);
+ goto err_dss;
+ }
+
+ r = dispc_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize dispc platform driver\n);
+ goto err_dispc;
+ }
+
+ r = rfbi_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize rfbi platform driver\n);
+ goto err_rfbi;
+ }
+
+ r = venc_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize venc platform driver\n);
+ goto err_venc;
+ }
+
+ r = dsi_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize DSI platform driver\n);
+ goto err_dsi;
+ }
+
+ r = hdmi_init_platform_driver();
+ if (r) {
+ DSSERR(Failed to initialize hdmi\n);
+ goto err_hdmi;
+ }
+
+ return 0;
+
+err_hdmi:
+ dsi_uninit_platform_driver();
+err_dsi:
+ venc_uninit_platform_driver();
+err_venc:
+ rfbi_uninit_platform_driver();
+err_rfbi:
+ dispc_uninit_platform_driver();
+err_dispc:
+ dss_uninit_platform_driver();
+err_dss:
+ platform_driver_unregister(omap_dss_driver);
+
+ return r;
+}
+
+static void __exit omap_dss_unregister_drivers(void)
+{
+
Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.
On Wed, Mar 21, 2012 at 11:39:57AM -0700, Tony Lindgren wrote: * Porter, Matt mpor...@ti.com [120321 11:27]: Hrm? Adding regulator supply mappings anywhere other than the initialisation for a specific board would be extremely unusual and rather suspicious. The issue here is that we don't want to copy paste the dummy fixed regulator all over the board-*.c files, and we don't know how the real regulator is wired up. Well, I don't think it's too unreasonable especially now we've got the fixed helper stuff which slims it right down - it makes it clear there's a missing thing that might need to get filled in and makes it easier to use the same regulator for other devices. Just to be clear, here is the thread on the board-specific approach: https://lkml.org/lkml/2012/2/8/415 We should use the real regulator if passed from board file. And if no real regulator is passed, just use the dummy fixed regulator in gpmc-smsc911x.c. Yes, it should definitely be conditional. This patch I posted should fix the situation and allow adding the real regulators to board-*.c files when they become known: http://www.spinics.net/lists/linux-omap/msg66714.html That should be changed to pass in a boolean flag rather than a pointer to platform device - the board may not have direct access to the relevant regulator (eg, if it's part of a MFD) or the regulator may be on another bus like I2C (for simpler regulator only devices). signature.asc Description: Digital signature
Re: [PATCH v7 1/3] Documentation: common clk API
On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote: So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful. But the enthusiasm of the clock driver developers doesn't necessarily translate to users of the clock APIs (other driver devs). My worry with marking it as experimental in Kconfig and to a certain extent in the documentation is that it will discourage the driver devs from switching to the new APIs. If no one is using the new APIs, then platforms can't switch to the common clock framework These aren't new APIs, the clock API has been around since forever. For driver authors working on anything that isn't platform specific the issue has been that it's not implemented at all on the overwhelming majority of architectures and those that do all have their own random implementations with their own random quirks and with no ability for anything except the platform to even try to do incredibly basic stuff like register a new clock. Simply having something, anything, in place even if it's going to churn is a massive step forward here for people working with clocks. signature.asc Description: Digital signature
Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.
* Mark Brown broo...@opensource.wolfsonmicro.com [120321 12:03]: On Wed, Mar 21, 2012 at 11:39:57AM -0700, Tony Lindgren wrote: * Porter, Matt mpor...@ti.com [120321 11:27]: Hrm? Adding regulator supply mappings anywhere other than the initialisation for a specific board would be extremely unusual and rather suspicious. The issue here is that we don't want to copy paste the dummy fixed regulator all over the board-*.c files, and we don't know how the real regulator is wired up. Well, I don't think it's too unreasonable especially now we've got the fixed helper stuff which slims it right down - it makes it clear there's a missing thing that might need to get filled in and makes it easier to use the same regulator for other devices. Right I guess that's a one liner macro now. Just to be clear, here is the thread on the board-specific approach: https://lkml.org/lkml/2012/2/8/415 We should use the real regulator if passed from board file. And if no real regulator is passed, just use the dummy fixed regulator in gpmc-smsc911x.c. Yes, it should definitely be conditional. This patch I posted should fix the situation and allow adding the real regulators to board-*.c files when they become known: http://www.spinics.net/lists/linux-omap/msg66714.html That should be changed to pass in a boolean flag rather than a pointer to platform device - the board may not have direct access to the relevant regulator (eg, if it's part of a MFD) or the regulator may be on another bus like I2C (for simpler regulator only devices). Hmm I see. This means that we need to patch some board files anyways for the boolean flag to use the fixed regulator. This is because for some cases vddvario and vdd33a regulators can come from the mfd/tps/twl chip and it's unsafe to assume that gpmc-smsc911x.c can set up these regulators automatically. Passing a boolean flag to not set up the default regulator would work too, but we'd rather eventually see the real board specific regulators being patched in. So if that's the case, we might as well patch the board files to add the fixed regulators for each one and drop all the regulator code from gpmc-smsc911x.c. 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 v7 1/3] Documentation: common clk API
* Mark Brown broo...@opensource.wolfsonmicro.com [120321 12:11]: On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote: So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful. But the enthusiasm of the clock driver developers doesn't necessarily translate to users of the clock APIs (other driver devs). My worry with marking it as experimental in Kconfig and to a certain extent in the documentation is that it will discourage the driver devs from switching to the new APIs. If no one is using the new APIs, then platforms can't switch to the common clock framework These aren't new APIs, the clock API has been around since forever. For driver authors working on anything that isn't platform specific the issue has been that it's not implemented at all on the overwhelming majority of architectures and those that do all have their own random implementations with their own random quirks and with no ability for anything except the platform to even try to do incredibly basic stuff like register a new clock. Simply having something, anything, in place even if it's going to churn is a massive step forward here for people working with clocks. Right, and now at least the people reading this thread are pretty aware of the yet unsolved issues with clock fwk api :) 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] [RFC] Correct registration of multiple gpmc smsc911x devices.
On Wed, Mar 21, 2012 at 12:30:47PM -0700, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [120321 12:03]: That should be changed to pass in a boolean flag rather than a pointer to platform device - the board may not have direct access to the relevant regulator (eg, if it's part of a MFD) or the regulator may be on another bus like I2C (for simpler regulator only devices). Hmm I see. This means that we need to patch some board files anyways for the boolean flag to use the fixed regulator. This is because for some cases vddvario and vdd33a regulators can come from the mfd/tps/twl chip and it's unsafe to assume that gpmc-smsc911x.c can set up these regulators automatically. Passing a boolean flag to not set up the default regulator would work too, but we'd rather eventually see the real board specific regulators being patched in. Yes, ideally the boards would do everything and gpmc-smsc911x.c should be able to completely ignore regulators. So if that's the case, we might as well patch the board files to add the fixed regulators for each one and drop all the regulator code from gpmc-smsc911x.c. That's my preferred option, hopefully with the helpers we have for regulator registration we shouldn't need to add device specific helpers. signature.asc Description: Digital signature
Re: [PATCH] [RFC] Correct registration of multiple gpmc smsc911x devices.
* Mark Brown broo...@opensource.wolfsonmicro.com [120321 12:41]: On Wed, Mar 21, 2012 at 12:30:47PM -0700, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [120321 12:03]: That should be changed to pass in a boolean flag rather than a pointer to platform device - the board may not have direct access to the relevant regulator (eg, if it's part of a MFD) or the regulator may be on another bus like I2C (for simpler regulator only devices). Hmm I see. This means that we need to patch some board files anyways for the boolean flag to use the fixed regulator. This is because for some cases vddvario and vdd33a regulators can come from the mfd/tps/twl chip and it's unsafe to assume that gpmc-smsc911x.c can set up these regulators automatically. Passing a boolean flag to not set up the default regulator would work too, but we'd rather eventually see the real board specific regulators being patched in. Yes, ideally the boards would do everything and gpmc-smsc911x.c should be able to completely ignore regulators. OK, great, let's do that then. So if that's the case, we might as well patch the board files to add the fixed regulators for each one and drop all the regulator code from gpmc-smsc911x.c. That's my preferred option, hopefully with the helpers we have for regulator registration we shouldn't need to add device specific helpers. Russ, care to update your patch accordingly? Those helpers are queued in linux-next. 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 v7 1/3] Documentation: common clk API
On 03/21/2012 12:33 PM, Tony Lindgren wrote: * Mark Brownbroo...@opensource.wolfsonmicro.com [120321 12:11]: On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote: So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful. But the enthusiasm of the clock driver developers doesn't necessarily translate to users of the clock APIs (other driver devs). My worry with marking it as experimental in Kconfig and to a certain extent in the documentation is that it will discourage the driver devs from switching to the new APIs. If no one is using the new APIs, then platforms can't switch to the common clock framework These aren't new APIs, the clock API has been around since forever. I disagree. When I say clock API, I mean the actual functions and their semantics. Not the existence of a header file. The meaning of clk_enable/disable has been changed and they won't work without calling clk_prepare/unprepare. So, these are definitely new APIs. If it weren't new APIs, then none of the general drivers would need to change. For driver authors working on anything that isn't platform specific the issue has been that it's not implemented at all on the overwhelming majority of architectures and those that do all have their own random implementations with their own random quirks and with no ability for anything except the platform to even try to do incredibly basic stuff like register a new clock. Simply having something, anything, in place even if it's going to churn is a massive step forward here for people working with clocks. Right, and now at least the people reading this thread are pretty aware of the yet unsolved issues with clock fwk api :) :-) Shhh... not so loud! -Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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
