Re: [PATCH] ARM: OMAP3: hwmod_data: Correct clock domains for USB modules
On 04/09/2014 06:19 PM, Nishanth Menon wrote:
On 04/09/2014 10:16 AM, Roger Quadros wrote:
OMAP3 doesn't contain l3_init_clkdm clock domain. Use the
proper clock domains for USB Host and USB TLL modules.
Gets rid of the following warnings during boot
omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
Reported-by: Nishant Menon n...@ti.com
I guess I have a h at the end of my first name :P
Sorry Nishanth. I'll send a revised patch.
cheers,
-roger
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9c7e23a..3aa49ed 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1968,7 +1968,7 @@ static struct omap_hwmod_irq_info
omap3xxx_usb_host_hs_irqs[] = {
static struct omap_hwmod omap3xxx_usb_host_hs_hwmod = {
.name = usb_host_hs,
.class = omap3xxx_usb_host_hs_hwmod_class,
-.clkdm_name = l3_init_clkdm,
+.clkdm_name = usbhost_clkdm,
.mpu_irqs = omap3xxx_usb_host_hs_irqs,
.main_clk = usbhost_48m_fck,
.prcm = {
@@ -2053,7 +2053,7 @@ static struct omap_hwmod_irq_info
omap3xxx_usb_tll_hs_irqs[] = {
static struct omap_hwmod omap3xxx_usb_tll_hs_hwmod = {
.name = usb_tll_hs,
.class = omap3xxx_usb_tll_hs_hwmod_class,
-.clkdm_name = l3_init_clkdm,
+.clkdm_name = core_l4_clkdm,
.mpu_irqs = omap3xxx_usb_tll_hs_irqs,
.main_clk = usbtll_fck,
.prcm = {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP3: hwmod_data: Correct clock domains for USB modules
OMAP3 doesn't contain l3_init_clkdm clock domain. Use the
proper clock domains for USB Host and USB TLL modules.
Gets rid of the following warnings during boot
omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
Reported-by: Nishanth Menon n...@ti.com
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Roger Quadros rog...@ti.com
---
v2: Corrected Nishanth's name
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9c7e23a..3aa49ed 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1968,7 +1968,7 @@ static struct omap_hwmod_irq_info
omap3xxx_usb_host_hs_irqs[] = {
static struct omap_hwmod omap3xxx_usb_host_hs_hwmod = {
.name = usb_host_hs,
.class = omap3xxx_usb_host_hs_hwmod_class,
- .clkdm_name = l3_init_clkdm,
+ .clkdm_name = usbhost_clkdm,
.mpu_irqs = omap3xxx_usb_host_hs_irqs,
.main_clk = usbhost_48m_fck,
.prcm = {
@@ -2053,7 +2053,7 @@ static struct omap_hwmod_irq_info
omap3xxx_usb_tll_hs_irqs[] = {
static struct omap_hwmod omap3xxx_usb_tll_hs_hwmod = {
.name = usb_tll_hs,
.class = omap3xxx_usb_tll_hs_hwmod_class,
- .clkdm_name = l3_init_clkdm,
+ .clkdm_name = core_l4_clkdm,
.mpu_irqs = omap3xxx_usb_tll_hs_irqs,
.main_clk = usbtll_fck,
.prcm = {
--
1.8.3.2
--
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/5] add gpio_chip_ops to hold GPIO operations
On Wed, Apr 9, 2014 at 3:20 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: In the kernel there are basically two patterns to implement object oriented code in C. You can either embedded a set of function pointers s/embedded/embed in a struct along with other members or have a separate virtual function table (vtable) structure that hold all the functions and only store a pointer to that vtable on our particular object. The struct gpio_chip uses the former approach, but I don't know if that is a design decision or is just that this code predates the fact that the separate structure pattern is now so popular. Since the having a the operations on a different structure has a number of benefits: Since having the operations maybe? - A clean separation between state (fields) and operations (functions). - Size reduction of struct gpio_chip since will only hold one pointer. - These functions are not supposed to change at runtime so the const qualifier can be used to prevent pointers modification during execution. - Similar drivers for a chip family can reuse their function vtable. There is a drawback though which is that now two memory accesses are needed to execute a GPIO operation since an additional level of indirection is introduced but that should be minimized due temporal and spatial memory locality. I think I really do like this. Having ops in a separate structure is a very common pattern in the kernel and makes things a lot cleaner. On top of the advantages you listed, it also only requires a single assignment in the driver's init function vs. a lot more today. If no one complains about the additional memory access, I'd like to go forward with this. I did much worse performance-hurting changes when introducing gpiod, so I suppose it will be fine. So this is an RFC patch-set to add a virtual table to be used by GPIO chip controllers and consist of the following patches: Javier Martinez Canillas (5): gpio: add a vtable to abstract GPIO controller operations gpiolib: set gpio_chip operations on add using a gpio_chip_ops gpio: omap: convert driver to use gpio_chip_ops gpio: twl4030: convert driver to use gpio_chip_ops gpio: switch to use struct struct gpio_chip_ops drivers/gpio/gpio-omap.c| 19 - drivers/gpio/gpio-twl4030.c | 10 +-- drivers/gpio/gpiolib.c | 64 - include/linux/gpio/driver.h | 69 +++-- 4 files changed, 93 insertions(+), 69 deletions(-) The patch-set is not a complete one though since only the GPIO OMAP and GPIO TWL4030 drivers have been converted so I could test it on my platform (DM3730 OMAP IGEPv2 board). But I preferred to send an early RFC than changing every single driver before discussing if doing the split is worth it or not. To not break git bisect-ability, I added some patches that are transitional changes. If you have a better suggestion on how to handle that please let me know. We will probably need that transition phase. We will also need to switch every single driver to your new scheme, so please wait until we hear from Linus before proceeding. :) Thanks, Alex. -- 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 2/2] pwm: use PWM_LOOKUP to set the period and polarity
On 10/04/2014 at 08:15:49 +0900, Simon Horman wrote : On Wed, Apr 09, 2014 at 08:04:09PM +0200, Alexandre Belloni wrote: Now that the PWM core is able to set the period and polarity based on the lookup table, add those to PWM_LOOKUP to ease their usage. I would prefer if this change was made in a non-atomic manner. 1. Add new infrastructure 2. Update users individually 3. Remove old infrastructure I agree this would be better but I'm not sure how you can modify a macro without renaming it or changing it everywhere at once. Like said, I'm open to creating a new macro. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
From: Sergei Shtylyov It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? That also doesn't sound like you are changing the PHY. I'd have thought that would happen if you had a single controller that select between multiply PHY. David -- 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/5] add gpio_chip_ops to hold GPIO operations
Hello Alexandre, Thanks a lot for your feedback. On 04/10/2014 09:36 AM, Alexandre Courbot wrote: On Wed, Apr 9, 2014 at 3:20 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: In the kernel there are basically two patterns to implement object oriented code in C. You can either embedded a set of function pointers s/embedded/embed in a struct along with other members or have a separate virtual function table (vtable) structure that hold all the functions and only store a pointer to that vtable on our particular object. The struct gpio_chip uses the former approach, but I don't know if that is a design decision or is just that this code predates the fact that the separate structure pattern is now so popular. Since the having a the operations on a different structure has a number of benefits: Since having the operations maybe? Yes, since I'm not a native english speaker I sometimes miss some obvious grammatical errors. I'll fix those when posting the final version with all the drivers converted. - A clean separation between state (fields) and operations (functions). - Size reduction of struct gpio_chip since will only hold one pointer. - These functions are not supposed to change at runtime so the const qualifier can be used to prevent pointers modification during execution. - Similar drivers for a chip family can reuse their function vtable. There is a drawback though which is that now two memory accesses are needed to execute a GPIO operation since an additional level of indirection is introduced but that should be minimized due temporal and spatial memory locality. I think I really do like this. Having ops in a separate structure is a very common pattern in the kernel and makes things a lot cleaner. On top of the advantages you listed, it also only requires a single assignment in the driver's init function vs. a lot more today. If no one complains about the additional memory access, I'd like to go forward with this. I did much worse performance-hurting changes when introducing gpiod, so I suppose it will be fine. So this is an RFC patch-set to add a virtual table to be used by GPIO chip controllers and consist of the following patches: Javier Martinez Canillas (5): gpio: add a vtable to abstract GPIO controller operations gpiolib: set gpio_chip operations on add using a gpio_chip_ops gpio: omap: convert driver to use gpio_chip_ops gpio: twl4030: convert driver to use gpio_chip_ops gpio: switch to use struct struct gpio_chip_ops drivers/gpio/gpio-omap.c| 19 - drivers/gpio/gpio-twl4030.c | 10 +-- drivers/gpio/gpiolib.c | 64 - include/linux/gpio/driver.h | 69 +++-- 4 files changed, 93 insertions(+), 69 deletions(-) The patch-set is not a complete one though since only the GPIO OMAP and GPIO TWL4030 drivers have been converted so I could test it on my platform (DM3730 OMAP IGEPv2 board). But I preferred to send an early RFC than changing every single driver before discussing if doing the split is worth it or not. To not break git bisect-ability, I added some patches that are transitional changes. If you have a better suggestion on how to handle that please let me know. We will probably need that transition phase. We will also need to switch every single driver to your new scheme, so please wait until we hear from Linus before proceeding. :) I'm glad you agree with the idea, let's see what Linus thinks about it. Thanks, Alex. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 10-04-2014 13:20, David Laight wrote: It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2? That also doesn't sound like you are changing the PHY. I am changing one of the PHY registers that controls USB port (Renesas calls it channel) multiplexing. I'd have thought that would happen if you had a single controller that select between multiply PHY. No, it's not the case. David WBR, Sergei -- 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: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 10/04/14 11:49, Sergei Shtylyov wrote: On 10-04-2014 13:20, David Laight wrote: It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2? That also doesn't sound like you are changing the PHY. I am changing one of the PHY registers that controls USB port (Renesas calls it channel) multiplexing. I'd have thought that would happen if you had a single controller that select between multiply PHY. No, it's not the case. There is an interesting case, the USB3 shares a PHY with a SATA and the PCIE and SATA also share a PHY on the R8A7790. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- 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/5] add gpio_chip_ops to hold GPIO operations
On Thu, 2014-04-10 at 11:34 +0200, Javier Martinez Canillas wrote: On 04/10/2014 09:36 AM, Alexandre Courbot wrote: Since having the operations maybe? Yes, since I'm not a native english speaker I sometimes miss some obvious grammatical errors. I'll fix those when posting the final version with all the drivers converted. JFYI: there is nice project called codespell [1]. [1] git://github.com/lucasdemarchi/codespell.git -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- 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: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
From: Ben Dooks On 10/04/14 11:49, Sergei Shtylyov wrote: On 10-04-2014 13:20, David Laight wrote: It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2? Yes. Why do you care which USB controller is driving the pins? That also doesn't sound like you are changing the PHY. I am changing one of the PHY registers that controls USB port (Renesas calls it channel) multiplexing. I'd have thought that would happen if you had a single controller that select between multiply PHY. No, it's not the case. I realised that wasn't what you were doing, but at first it did seem to be what you were doing. There is an interesting case, the USB3 shares a PHY with a SATA and the PCIE and SATA also share a PHY on the R8A7790. Some of those look like pcb design decisions - so there is no dynamic changing, just config time plumbing. OTOH we are carrying PCIe using two SATA cables (the second carries the clock) so I suspect some SoC system pcbs may be able to support SATA or PCIe on the same connector). David -- 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: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 10/04/14 12:14, David Laight wrote: From: Ben Dooks On 10/04/14 11:49, Sergei Shtylyov wrote: On 10-04-2014 13:20, David Laight wrote: It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2? Yes. Why do you care which USB controller is driving the pins? That also doesn't sound like you are changing the PHY. I am changing one of the PHY registers that controls USB port (Renesas calls it channel) multiplexing. I'd have thought that would happen if you had a single controller that select between multiply PHY. No, it's not the case. I realised that wasn't what you were doing, but at first it did seem to be what you were doing. There is an interesting case, the USB3 shares a PHY with a SATA and the PCIE and SATA also share a PHY on the R8A7790. Some of those look like pcb design decisions - so there is no dynamic changing, just config time plumbing. OTOH we are carrying PCIe using two SATA cables (the second carries the clock) so I suspect some SoC system pcbs may be able to support SATA or PCIe on the same connector). Yes, which means we will probably want to support the case where the USB3 is routed out of the PCIe lanes. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- 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/5] add gpio_chip_ops to hold GPIO operations
Hello Andy, On Thu, Apr 10, 2014 at 1:00 PM, Andy Shevchenko andriy.shevche...@linux.intel.com wrote: On Thu, 2014-04-10 at 11:34 +0200, Javier Martinez Canillas wrote: On 04/10/2014 09:36 AM, Alexandre Courbot wrote: Since having the operations maybe? Yes, since I'm not a native english speaker I sometimes miss some obvious grammatical errors. I'll fix those when posting the final version with all the drivers converted. JFYI: there is nice project called codespell [1]. [1] git://github.com/lucasdemarchi/codespell.git Interesting project, thanks a lot for the pointer. Best regards, Javier -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-gpio in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Wednesday 09 April 2014 09:53 PM, Russell King - ARM Linux wrote:
On Tue, Apr 08, 2014 at 08:23:39PM +0530, Sekhar Nori wrote:
On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index f8b8dac..6b2a056 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
return omap_l2_cache_init(aux_ctrl, 0xc19f);
}
+
+int __init am43xx_l2_cache_init(void)
+{
+ u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
+ L310_AUX_CTRL_INSTR_PREFETCH;
It would be good to documenting the difference between this and OMAP4,
and why you have chosen different values.
There are two main differences:
1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
not needed even in OMAP4 with latest kernel, but I am not sure if I can
do this safely without breaking any usecase currently working with OMAP4.
2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
searched through the commit history of L2 cache support on OMAP4 but
there is no mention of why this was needed on OMAP4. I am checking
internally on the history behind this.
That is required because as part of the enable sequence, we write to the
lockdown registers to clear out anything that may be there before we
enable the L2 cache. If we didn't set the NS lockdown bit, then we
would need the secure monitor to do it for us.
And I realized yesterday that the only reason L2C is working on AM437x
is because AM437x ROM is setting these bits up for us.
The NS interrupt access bit is also a good idea to be set, since this
allows us to eventually support EDAC with PL310. As we don't support
EDAC at the moment, or touch the interrupt registers, we can probably
ignore this difference and just preserve whatever value is there for
the time being.
Both of these bits should be managed within the L2C code rather than by
platforms.
The current L2C code is not managing the NS_LOCKDOWN bit. I can take a
shot at adding this support unless you are already looking at it.
3) OMAP4 sets cache replacement policy to RR which is not a big deal
since thats the default anyway. We can probably drop this setting even
from OMAP4.
Yes, since that would just be a case of preserving that bit.
Okay will drop this explicit setting.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Thu, Apr 10, 2014 at 05:26:15PM +0530, Sekhar Nori wrote:
On Wednesday 09 April 2014 09:53 PM, Russell King - ARM Linux wrote:
That is required because as part of the enable sequence, we write to the
lockdown registers to clear out anything that may be there before we
enable the L2 cache. If we didn't set the NS lockdown bit, then we
would need the secure monitor to do it for us.
And I realized yesterday that the only reason L2C is working on AM437x
is because AM437x ROM is setting these bits up for us.
Both of these bits should be managed within the L2C code rather than by
platforms.
The current L2C code is not managing the NS_LOCKDOWN bit. I can take a
shot at adding this support unless you are already looking at it.
True, and I'm aware that it's missing. So... how about this on top
of my series so far. We can deal with L310_AUX_CTRL_NS_INT_CTRL when
the need to access those registers arises (if/when the edac driver
is submitted.)
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index c0f9a81a2d32..4a494cde8367 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -213,8 +213,6 @@ static int __init omap_l2_cache_init(void)
/* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */
aux_ctrl = L310_AUX_CTRL_CACHE_REPLACE_RR |
- L310_AUX_CTRL_NS_LOCKDOWN |
- L310_AUX_CTRL_NS_INT_CTRL |
L2C_AUX_CTRL_SHARED_OVERRIDE |
L310_AUX_CTRL_DATA_PREFETCH |
L310_AUX_CTRL_INSTR_PREFETCH;
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 98796b789eb9..837f384c1d51 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -776,6 +776,13 @@ static void __init l2c310_enable(void __iomem *base, u32
aux, unsigned num_lock)
power_ctrl L310_STNDBY_MODE_EN ? en : dis);
}
+ /*
+* Always enable non-secure access to the lockdown registers -
+* we write to them as part of the L2C enable sequence so they
+* need to be accessible.
+*/
+ aux |= L310_AUX_CTRL_NS_LOCKDOWN;
+
l2c_enable(base, aux, num_lock);
if (aux L310_AUX_CTRL_FULL_LINE_ZERO) {
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Wednesday 09 April 2014 10:22 PM, Santosh Shilimkar wrote:
On Wednesday 09 April 2014 12:33 PM, Russell King - ARM Linux wrote:
On Tue, Apr 08, 2014 at 11:17:17AM -0400, Santosh Shilimkar wrote:
On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index f8b8dac..6b2a056 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
return omap_l2_cache_init(aux_ctrl, 0xc19f);
}
+
+int __init am43xx_l2_cache_init(void)
+{
+u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
+ L310_AUX_CTRL_INSTR_PREFETCH;
It would be good to documenting the difference between this and OMAP4,
and why you have chosen different values.
There are two main differences:
1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
not needed even in OMAP4 with latest kernel, but I am not sure if I can
do this safely without breaking any usecase currently working with OMAP4.
Wrong. Shared bit is mandatory for the OMAP4. Its a SMP system
which needs that.
Errr. This bit affects the L2 cache behaviour for Normal memory, outer
non-cacheable accesses - in other words, those performed to memory mapped
via dma_alloc_coherent() or dma_alloc_writecombine(). It does not affect
other types of mappings (other access types ignore the sharable attribute).
When this bit is clear, accesses to such memory are:
- read: cacheable, no allocate
- write: write through, no write allocate
what this means is that if there are no cache lines in the L2 cache
corresponding with the physical address, then none will be allocated.
However, if there are cache lines present, then they will be hit,
read or updated as appropriate.
This may matter before CMA where we had the memory returned by
dma_alloc_coherent() and friends mapped as normal, cacheable mappings
which could be speculatively prefetched, and therefore cache lines
dragged into the L2 cache for these physical addresses.
However, now that we're using CMA, this does not apply as we no longer
have this aliasing mapping.
So, with CMA enabled, it should be safe not to set this bit.
Agree. That should be safe now.
Since we cannot guarantee that CONFIG_DMA_CMA will always be enabled in
kernel config, shall we take the safer route and keep the Shared
attribute override bit enabled in L2C configuration?
Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Thursday 10 April 2014 05:33 PM, Russell King - ARM Linux wrote: On Thu, Apr 10, 2014 at 05:26:15PM +0530, Sekhar Nori wrote: On Wednesday 09 April 2014 09:53 PM, Russell King - ARM Linux wrote: That is required because as part of the enable sequence, we write to the lockdown registers to clear out anything that may be there before we enable the L2 cache. If we didn't set the NS lockdown bit, then we would need the secure monitor to do it for us. And I realized yesterday that the only reason L2C is working on AM437x is because AM437x ROM is setting these bits up for us. Both of these bits should be managed within the L2C code rather than by platforms. The current L2C code is not managing the NS_LOCKDOWN bit. I can take a shot at adding this support unless you are already looking at it. True, and I'm aware that it's missing. So... how about this on top of my series so far. We can deal with L310_AUX_CTRL_NS_INT_CTRL when the need to access those registers arises (if/when the edac driver is submitted.) diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index c0f9a81a2d32..4a494cde8367 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -213,8 +213,6 @@ static int __init omap_l2_cache_init(void) /* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */ aux_ctrl = L310_AUX_CTRL_CACHE_REPLACE_RR | -L310_AUX_CTRL_NS_LOCKDOWN | -L310_AUX_CTRL_NS_INT_CTRL | L2C_AUX_CTRL_SHARED_OVERRIDE | L310_AUX_CTRL_DATA_PREFETCH | L310_AUX_CTRL_INSTR_PREFETCH; diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c index 98796b789eb9..837f384c1d51 100644 --- a/arch/arm/mm/cache-l2x0.c +++ b/arch/arm/mm/cache-l2x0.c @@ -776,6 +776,13 @@ static void __init l2c310_enable(void __iomem *base, u32 aux, unsigned num_lock) power_ctrl L310_STNDBY_MODE_EN ? en : dis); } + /* + * Always enable non-secure access to the lockdown registers - + * we write to them as part of the L2C enable sequence so they + * need to be accessible. + */ + aux |= L310_AUX_CTRL_NS_LOCKDOWN; + This will work. NS_LOCKDOWN is required for L2C-220 as well and so I was thinking about adding a new l2c220_enable() which will set the NS_LOCKDOWN and then call l2c_enable() Thanks, Sekhar -- 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: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 10-04-2014 15:14, David Laight wrote: It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2? Yes. Why do you care which USB controller is driving the pins? Because the controllers the driver switches between are not companions. The multiplexing is between PCI EHCI/OHCI and Renesas USBHS (high speed device controller in this case) controllers on port 0 and between PCI EHCI/OHCI and non-PCI xHCI controller on port 2. That also doesn't sound like you are changing the PHY. I am changing one of the PHY registers that controls USB port (Renesas calls it channel) multiplexing. I'd have thought that would happen if you had a single controller that select between multiply PHY. No, it's not the case. I realised that wasn't what you were doing, but at first it did seem to be what you were doing. The PHY really does belong to the USBHS controller but that multiplexing register inside it controls routing of the ports 0 and 2; USBHS itself is on port 0. There is an interesting case, the USB3 shares a PHY with a SATA and the PCIE and SATA also share a PHY on the R8A7790. Some of those look like pcb design decisions - so there is no dynamic changing, just config time plumbing. No, there are also host/device mode DIP switches on the boards which control port 0 signals (and the port 0 connector is micro-AB, so both a host and device can be connected). The second board also has OTG chip on port 0 thru which USB ID pin can be read from the micro-AB connector. David WBR, Sergei -- 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 03/13] extcon: extcon-class: remove extcon_set_cable_state() function
This patch removes extcon_set_cable_state() and replace all calls of
this function witch extcon_set_cable_state_(), which is faster version.
This is first step of changing extcon API to faster and safer.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-class.c| 17
drivers/extcon/extcon-max14577.c | 24 ++--
drivers/extcon/extcon-max77693.c | 79 +++---
drivers/extcon/extcon-max8997.c | 32 +--
drivers/extcon/extcon-palmas.c | 27 +
include/linux/extcon.h |8
6 files changed, 99 insertions(+), 88 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index a45c5e9..1b98c4e 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -358,23 +358,6 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
/**
- * extcon_set_cable_state() - Set the status of a specific cable.
- * @edev: the extcon device that has the cable.
- * @cable_name:cable name.
- * @cable_state: the new cable status. The default semantics is
- * true: attached / false: detached.
- *
- * Note that this is slower than extcon_set_cable_state_.
- */
-int extcon_set_cable_state(struct extcon_dev *edev,
- const char *cable_name, bool cable_state)
-{
- return extcon_set_cable_state_(edev, extcon_find_cable_index
- (edev, cable_name), cable_state);
-}
-EXPORT_SYMBOL_GPL(extcon_set_cable_state);
-
-/**
* extcon_get_extcon_dev() - Get the extcon device instance from the name
* @extcon_name: The extcon name provided with extcon_dev_register()
*/
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 3846941..7a947d3 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -333,7 +333,7 @@ static int max14577_muic_get_cable_type(struct
max14577_muic_info *info,
static int max14577_muic_jig_handler(struct max14577_muic_info *info,
int cable_type, bool attached)
{
- char cable_name[32];
+ int cable;
int ret = 0;
u8 path = CTRL1_SW_OPEN;
@@ -344,17 +344,17 @@ static int max14577_muic_jig_handler(struct
max14577_muic_info *info,
switch (cable_type) {
case MAX14577_MUIC_ADC_FACTORY_MODE_USB_OFF:/* ADC_JIG_USB_OFF */
/* PATH:AP_USB */
- strcpy(cable_name, JIG-USB-OFF);
+ cable = EXTCON_CABLE_JIG_USB_OFF;
path = CTRL1_SW_USB;
break;
case MAX14577_MUIC_ADC_FACTORY_MODE_USB_ON: /* ADC_JIG_USB_ON */
/* PATH:AP_USB */
- strcpy(cable_name, JIG-USB-ON);
+ cable = EXTCON_CABLE_JIG_USB_ON;
path = CTRL1_SW_USB;
break;
case MAX14577_MUIC_ADC_FACTORY_MODE_UART_OFF: /* ADC_JIG_UART_OFF */
/* PATH:AP_UART */
- strcpy(cable_name, JIG-UART-OFF);
+ cable = EXTCON_CABLE_JIG_UART_OFF;
path = CTRL1_SW_UART;
break;
default:
@@ -367,7 +367,7 @@ static int max14577_muic_jig_handler(struct
max14577_muic_info *info,
if (ret 0)
return ret;
- extcon_set_cable_state(info-edev, cable_name, attached);
+ extcon_set_cable_state_(info-edev, cable, attached);
return 0;
}
@@ -464,20 +464,22 @@ static int max14577_muic_chg_handler(struct
max14577_muic_info *info)
if (ret 0)
return ret;
- extcon_set_cable_state(info-edev, USB, attached);
+ extcon_set_cable_state_(info-edev, EXTCON_CABLE_USB, attached);
break;
case MAX14577_CHARGER_TYPE_DEDICATED_CHG:
- extcon_set_cable_state(info-edev, TA, attached);
+ extcon_set_cable_state_(info-edev, EXTCON_CABLE_TA, attached);
break;
case MAX14577_CHARGER_TYPE_DOWNSTREAM_PORT:
- extcon_set_cable_state(info-edev,
- Charge-downstream, attached);
+ extcon_set_cable_state_(info-edev,
+ EXTCON_CABLE_CHARGE_DOWNSTREAM, attached);
break;
case MAX14577_CHARGER_TYPE_SPECIAL_500MA:
- extcon_set_cable_state(info-edev, Slow-charger, attached);
+ extcon_set_cable_state_(info-edev,
+ EXTCON_CABLE_SLOW_CHARGER, attached);
break;
case MAX14577_CHARGER_TYPE_SPECIAL_1A:
- extcon_set_cable_state(info-edev, Fast-charger, attached);
+ extcon_set_cable_state_(info-edev,
+ EXTCON_CABLE_FAST_CHARGER, attached);
break;
case
[PATCH 04/13] extcon: extcon-class: match extcon device by devicetree node
This patch modifies extcon_get_edev_by_phandle() function, to match
extcon device by devicetree node. This modification needed to add
field 'node' in extcon_dev structure, and fill it in probe function
of each extcon provider driver.
This patch replaces also extcon_get_extcon_dev() function with
of_extcon_get_extcon_dev(), returning extcon device which contains
given devicetree node.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-adc-jack.c |1 +
drivers/extcon/extcon-arizona.c |1 +
drivers/extcon/extcon-class.c| 19 +--
drivers/extcon/extcon-gpio.c |1 +
drivers/extcon/extcon-max14577.c |2 ++
drivers/extcon/extcon-max77693.c |1 +
drivers/extcon/extcon-max8997.c |1 +
drivers/extcon/extcon-palmas.c |1 +
include/linux/extcon.h |8 ++--
9 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index e23f1c2..d65915e 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -111,6 +111,7 @@ static int adc_jack_probe(struct platform_device *pdev)
}
data-edev.dev.parent = pdev-dev;
+ data-edev.node = pdev-dev.of_node;
data-edev.supported_cable = pdata-cable_names;
/* Check the length of array and set num_cables */
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 98a14f6..fc69cca 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1153,6 +1153,7 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
info-edev.name = Headset Jack;
info-edev.dev.parent = arizona-dev;
+ info-edev.node = pdev-dev.of_node;
info-edev.supported_cable = arizona_cable;
ret = extcon_dev_register(info-edev);
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 1b98c4e..1075ce8 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -358,24 +358,23 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
/**
- * extcon_get_extcon_dev() - Get the extcon device instance from the name
- * @extcon_name: The extcon name provided with extcon_dev_register()
+ * of_extcon_get_extcon_dev() - Get the extcon device instance from the name
+ * @np: The node of extcon device
*/
-struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name)
+struct extcon_dev *of_extcon_get_extcon_dev(const struct device_node *np)
{
- struct extcon_dev *sd;
+ struct extcon_dev *edev;
mutex_lock(extcon_dev_list_lock);
- list_for_each_entry(sd, extcon_dev_list, entry) {
- if (!strcmp(sd-name, extcon_name))
+ list_for_each_entry(edev, extcon_dev_list, entry) {
+ if (edev-node == np)
goto out;
}
- sd = NULL;
+ edev = NULL;
out:
mutex_unlock(extcon_dev_list_lock);
- return sd;
+ return edev;
}
-EXPORT_SYMBOL_GPL(extcon_get_extcon_dev);
static int _call_per_cable(struct notifier_block *nb, unsigned long val,
void *ptr)
@@ -827,7 +826,7 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct device
*dev, int index)
return ERR_PTR(-ENODEV);
}
- edev = extcon_get_extcon_dev(node-name);
+ edev = of_extcon_get_extcon_dev(node);
if (!edev) {
dev_err(dev, unable to get extcon device : %s\n, node-name);
return ERR_PTR(-ENODEV);
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 13d5222..fc90b7a 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -100,6 +100,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
extcon_data-edev.name = pdata-name;
extcon_data-edev.dev.parent = pdev-dev;
+ extcon_data-edev.node = pdev-dev.of_node;
extcon_data-gpio = pdata-gpio;
extcon_data-gpio_active_low = pdata-gpio_active_low;
extcon_data-state_on = pdata-state_on;
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 7a947d3..b017a0d 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -676,6 +676,8 @@ static int max14577_muic_probe(struct platform_device *pdev)
return -ENOMEM;
}
info-edev-name = DEV_NAME;
+ info-edev-dev.parent = pdev-dev;
+ info-edev-node = pdev-dev.of_node;
info-edev-supported_cable = max14577_extcon_cable;
ret = extcon_dev_register(info-edev);
if (ret) {
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 7a014cd..2cd8892 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1200,6 +1200,7 @@ static int max77693_muic_probe(struct
[PATCH 05/13] extcon: extcon-class: improve extcon client API
This patch improves extcon client API to get rid of ugly functions operating
on name strings. It gives independency from naming convention in extcon
provider drivers. Names given at provider registration are now used only
for sysfs, debugs, and to support platforms using legacy devicetree bindings.
From now individual cables are specified in devicetree, so client API has
changed from extcon_dev oriented to extcon_cable oriented. Added also some
minor modifications to simplify interest registration.
The extcon_specific_cable_nb structure has been changed to extcon_cable_nb.
Now this is the only struct which has to be supplied by client. Pointer to
user_nb has been changed to extcon_notifier_fn_t to simplify interest
registation process.
Each single cable is represented by struct extcon_cable. Pointer to
extcon_cable is returned from functions:
of_extcon_get_cable() - returning cable of given index
of_extcon_get_cable_by_name() - returing cable by name defined in devicetree
extcon_get_cable_by_name() - similar to of_extcon_get_cable_by_name(),
but it takes struct device instead of struct device_node
Function extcon_register_interest() has been changed. Registration is now
not based on cable name string, but on pointer to struct extcon_cable.
Also extcon_get_cable_state() function has been changed. Now it takes
pointer to struct extcon_cable.
This patch modifies all client drivers to make it using new extcon API.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-class.c | 201 +--
drivers/power/charger-manager.c | 36 +++---
drivers/usb/dwc3/dwc3-omap.c| 68 ++-
drivers/usb/phy/phy-omap-otg.c | 72 ++-
include/linux/extcon.h | 92 --
include/linux/platform_data/usb-omap1.h |2 -
include/linux/power/charger-manager.h |6 +-
7 files changed, 288 insertions(+), 189 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 1075ce8..708b352 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -324,15 +324,14 @@ EXPORT_SYMBOL_GPL(extcon_get_cable_state_);
/**
* extcon_get_cable_state() - Get the status of a specific cable.
- * @edev: the extcon device that has the cable.
- * @cable_name:cable name.
- *
- * Note that this is slower than extcon_get_cable_state_.
+ * @cable: the cable.
*/
-int extcon_get_cable_state(struct extcon_dev *edev, const char *cable_name)
+int extcon_get_cable_state(struct extcon_cable *cable)
{
- return extcon_get_cable_state_(edev, extcon_find_cable_index
- (edev, cable_name));
+ if (!cable)
+ return -ENODEV;
+
+ return !!(cable-edev-state (1 cable-cable_index));
}
EXPORT_SYMBOL_GPL(extcon_get_cable_state);
@@ -376,24 +375,130 @@ out:
return edev;
}
+/**
+ * of_extcon_get_cable() - Get specified extcon cable instance from devicetree
+ * @np:The node of extcon device
+ */
+struct extcon_cable *of_extcon_get_cable(struct device_node *np, int index)
+{
+ struct of_phandle_args extcon_spec;
+ struct extcon_dev *edev;
+ struct extcon_cable *cable;
+ int ret;
+
+ if (index 0)
+ return ERR_PTR(-EINVAL);
+
+ ret = of_parse_phandle_with_args(np, extcon-cables, #extcon-cells,
+ index, extcon_spec);
+ if (ret)
+ return ERR_PTR(ret);
+
+ edev = of_extcon_get_extcon_dev(extcon_spec.np);
+ if (!edev) {
+ pr_devel(unable to get extcon device);
+ return ERR_PTR(-ENODEV);
+ }
+
+ cable = edev-cables[extcon_spec.args[0]];
+
+ of_node_put(extcon_spec.np);
+ return cable;
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_cable);
+
+struct extcon_cable *of_extcon_get_cable_legacy(struct device_node *np,
+ const char *name)
+{
+ struct device_node *node;
+ struct extcon_dev *edev;
+ int i;
+
+ node = of_parse_phandle(np, extcon, 0);
+ if (!node)
+ return ERR_PTR(-EINVAL);
+ edev = of_extcon_get_extcon_dev(node);
+ if (!edev)
+ return ERR_PTR(-ENODEV);
+
+ if (!edev-supported_cable)
+ return ERR_PTR(-EINVAL);
+
+ for (i = 0; edev-supported_cable[i]; ++i) {
+ if (!strncmp(edev-supported_cable[i], name, CABLE_NAME_MAX))
+ return edev-cables[i];
+ }
+ return ERR_PTR(-ENODEV);
+}
+
+/*
+ * of_extcon_get_cable_by_name() - Get extcon cable from devicetree by name
+ * @np - devicetree node of client device
+ * @name - name of the cable specified in devicetree
+ *
+ * return the instance of extcon cable
+ */
+struct extcon_cable *of_extcon_get_cable_by_name(struct device_node *np,
+
[PATCH 13/13] extcon: extcon-max77693: check if pdata exists
This patch adds check if pdata is NULL, to avoid NULL pointer dereference
when platform data is not available. After this changes, in described
situation driver will be configured with default values.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-max77693.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 2cd8892..fa8534e 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1210,7 +1210,7 @@ static int max77693_muic_probe(struct platform_device
*pdev)
/* Initialize MUIC register by using platform data or default data */
- if (pdata-muic_data) {
+ if (pdata pdata-muic_data) {
init_data = pdata-muic_data-init_data;
num_init_data = pdata-muic_data-num_init_data;
} else {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/13] extcon: extcon-adc-jack: add devicetree support
This patch modifies extcon-adc-jack driver to use initialization data from
devicetree, when platform data is not available. It allows to define cable list
with ADC value ranges for each of them in devicetree bindings.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-adc-jack.c | 74 ++
1 file changed, 74 insertions(+)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index d65915e..293871b1 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -21,6 +21,7 @@
#include linux/err.h
#include linux/interrupt.h
#include linux/workqueue.h
+#include linux/of.h
#include linux/iio/consumer.h
#include linux/extcon/extcon-adc-jack.h
#include linux/extcon.h
@@ -92,12 +93,78 @@ static irqreturn_t adc_jack_irq_thread(int irq, void *_data)
return IRQ_HANDLED;
}
+static struct adc_jack_pdata *get_pdata_from_dt(struct device *dev)
+{
+ int ret, cnt, i;
+ struct device_node *cables_np, *child;
+ struct adc_jack_pdata *pdata =
+ devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+
+ ret = of_property_read_string_index(dev-of_node,
+ adc-name, 0, pdata-name);
+ if (ret)
+ return NULL;
+
+ ret = of_property_read_string_index(dev-of_node,
+ adc-consumer-channel, 0, pdata-consumer_channel);
+ if (ret)
+ return NULL;
+
+ cables_np = of_find_node_by_name(dev-of_node, cables);
+ if (!cables_np)
+ return NULL;
+
+ cnt = of_get_child_count(cables_np);
+ if (cnt = 0)
+ return NULL;
+
+ pdata-cable_names = devm_kcalloc(dev, cnt+1,
+ sizeof(*pdata-cable_names), GFP_KERNEL);
+ if (!pdata-cable_names)
+ return NULL;
+
+ pdata-adc_conditions = devm_kcalloc(dev, cnt+1,
+ sizeof(*pdata-adc_conditions), GFP_KERNEL);
+ if (!pdata-adc_conditions)
+ return NULL;
+
+ i = 0;
+ for_each_child_of_node(cables_np, child) {
+ ret = of_property_read_string_index(child,
+ cable-name, 0, pdata-cable_names[i]);
+ if (ret)
+ return NULL;
+
+ pdata-adc_conditions[i].state = (1i);
+
+ ret = of_property_read_u32_array(child, adc-min,
+ pdata-adc_conditions[i].min_adc, 0);
+ if (ret)
+ return NULL;
+
+ ret = of_property_read_u32_array(child, adc-max,
+ pdata-adc_conditions[i].max_adc, 0);
+ if (ret)
+ return NULL;
+
+ i++;
+ }
+
+ return pdata;
+}
+
static int adc_jack_probe(struct platform_device *pdev)
{
struct adc_jack_data *data;
struct adc_jack_pdata *pdata = dev_get_platdata(pdev-dev);
int i, err = 0;
+ if (!pdata) {
+ pdata = get_pdata_from_dt(pdev-dev);
+ if (!pdata)
+ return -EINVAL;
+ }
+
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
@@ -188,11 +255,18 @@ static int adc_jack_remove(struct platform_device *pdev)
return 0;
}
+static struct of_device_id of_adc_jack_match_tbl[] = {
+ { .compatible = extcon-adc-jack, },
+ { /* end */ },
+};
+
+
static struct platform_driver adc_jack_driver = {
.probe = adc_jack_probe,
.remove = adc_jack_remove,
.driver = {
.name = adc-jack,
+ .of_match_table = of_adc_jack_match_tbl,
.owner = THIS_MODULE,
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/13] extcon: extcon-gpio: add devicetree support
This patch modifies extcon-gpio driver to use initialization data from
devicetree if platform data is not available. It allows to set controller
and cable names, and another parameters from devicetree bindings.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-gpio.c | 63 ++--
include/linux/extcon/extcon-gpio.h |2 +-
2 files changed, 55 insertions(+), 10 deletions(-)
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index fc90b7a..2a3cfd7 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -28,6 +28,8 @@
#include linux/slab.h
#include linux/workqueue.h
#include linux/gpio.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/extcon.h
#include linux/extcon/extcon-gpio.h
@@ -53,7 +55,7 @@ static void gpio_extcon_work(struct work_struct *work)
state = gpio_get_value(data-gpio);
if (data-gpio_active_low)
state = !state;
- extcon_set_state(data-edev, state);
+ extcon_set_cable_state_(data-edev, 0, state);
}
static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
@@ -70,7 +72,7 @@ static ssize_t extcon_gpio_print_state(struct extcon_dev
*edev, char *buf)
struct gpio_extcon_data *extcon_data =
container_of(edev, struct gpio_extcon_data, edev);
const char *state;
- if (extcon_get_state(edev))
+ if (extcon_get_cable_state_(edev, 0))
state = extcon_data-state_on;
else
state = extcon_data-state_off;
@@ -80,17 +82,50 @@ static ssize_t extcon_gpio_print_state(struct extcon_dev
*edev, char *buf)
return -EINVAL;
}
+static struct gpio_extcon_platform_data *get_pdata_from_dt(struct device *dev)
+{
+ int ret;
+ struct gpio_extcon_platform_data *pdata =
+ devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+
+ ret = of_property_read_string_index(dev-of_node,
+ gpio-controller-name, 0, pdata-name);
+ if (ret)
+ return NULL;
+
+ ret = of_property_read_string_index(dev-of_node,
+ gpio-cable-name, 0, pdata-cable_name);
+ if (ret)
+ return NULL;
+
+ ret = of_property_read_u32_array(dev-of_node,
+ gpio-debounce, pdata-debounce, 0);
+ if (ret)
+ pdata-debounce = 0;
+
+ pdata-gpio = of_get_gpio(dev-of_node, 0);
+ if (pdata-gpio 0)
+ return NULL;
+
+ pdata-gpio_active_low = of_property_read_bool(dev-of_node,
+ gpio-active-low);
+
+ pdata-check_on_resume = of_property_read_bool(dev-of_node,
+ check-on-resume);
+ return pdata;
+}
+
static int gpio_extcon_probe(struct platform_device *pdev)
{
struct gpio_extcon_platform_data *pdata = dev_get_platdata(pdev-dev);
struct gpio_extcon_data *extcon_data;
+ const char *gpio_extcon_cable[2];
int ret;
- if (!pdata)
- return -EBUSY;
- if (!pdata-irq_flags) {
- dev_err(pdev-dev, IRQ flag is not specified.\n);
- return -EINVAL;
+ if (!pdata) {
+ pdata = get_pdata_from_dt(pdev-dev);
+ if (!pdata)
+ return -EINVAL;
}
extcon_data = devm_kzalloc(pdev-dev, sizeof(struct gpio_extcon_data),
@@ -98,10 +133,14 @@ static int gpio_extcon_probe(struct platform_device *pdev)
if (!extcon_data)
return -ENOMEM;
+ gpio_extcon_cable[0] = pdata-cable_name;
+ gpio_extcon_cable[1] = NULL;
+
extcon_data-edev.name = pdata-name;
extcon_data-edev.dev.parent = pdev-dev;
extcon_data-edev.node = pdev-dev.of_node;
extcon_data-gpio = pdata-gpio;
+ extcon_data-edev.supported_cable = gpio_extcon_cable;
extcon_data-gpio_active_low = pdata-gpio_active_low;
extcon_data-state_on = pdata-state_on;
extcon_data-state_off = pdata-state_off;
@@ -135,8 +174,8 @@ static int gpio_extcon_probe(struct platform_device *pdev)
}
ret = request_any_context_irq(extcon_data-irq, gpio_irq_handler,
- pdata-irq_flags, pdev-name,
- extcon_data);
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
+ pdev-name, extcon_data);
if (ret 0)
goto err;
@@ -177,6 +216,11 @@ static int gpio_extcon_resume(struct device *dev)
}
#endif
+static struct of_device_id of_gpio_match_tbl[] = {
+ { .compatible = extcon-gpio, },
+ { /* end */ },
+};
+
static SIMPLE_DEV_PM_OPS(gpio_extcon_pm_ops, NULL, gpio_extcon_resume);
static struct platform_driver gpio_extcon_driver = {
@@ -184,6 +228,7 @@ static struct platform_driver
[PATCH 08/13] extcon: extcon-class: simplify extcon_updata_state() function
This patch simplifies extcon_updata_state() function. There is greatly
simplified kobject_uevent preparation. Also meaning of variable passed
to raw_notifier_call_chain() (and in effect to _call_per_cable()) has
changed. Now positions on ones in variable 'val' in _call_per_cable()
indicates numbers of cables which changed their status. It allowed
to simplify also _call_per_cable() function.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-class.c | 81 -
include/linux/extcon.h|1 -
2 files changed, 31 insertions(+), 51 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 2659805..ce76c08 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -206,59 +206,48 @@ int extcon_update_state(struct extcon_dev *edev, u32
mask, u32 state)
{
char name_buf[120];
char state_buf[120];
- char *prop_buf;
+ char *tmp;
char *envp[3];
int env_offset = 0;
int length;
unsigned long flags;
+ u32 change;
spin_lock_irqsave(edev-lock, flags);
- if (edev-state != ((edev-state ~mask) | (state mask))) {
- u32 old_state = edev-state;
-
- if (check_mutually_exclusive(edev, (edev-state ~mask) |
- (state mask))) {
+ change = (edev-state mask) ^ (state mask);
+ if (change) {
+ if (check_mutually_exclusive(edev, edev-state ^ change)) {
spin_unlock_irqrestore(edev-lock, flags);
return -EPERM;
}
- edev-state = ~mask;
- edev-state |= state mask;
-
- raw_notifier_call_chain(edev-nh, old_state, edev);
- /* This could be in interrupt handler */
- prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
- if (prop_buf) {
- length = name_show(edev-dev, NULL, prop_buf);
- if (length 0) {
- if (prop_buf[length - 1] == '\n')
- prop_buf[length - 1] = 0;
- snprintf(name_buf, sizeof(name_buf),
- NAME=%s, prop_buf);
- envp[env_offset++] = name_buf;
- }
- length = state_show(edev-dev, NULL, prop_buf);
- if (length 0) {
- if (prop_buf[length - 1] == '\n')
- prop_buf[length - 1] = 0;
- snprintf(state_buf, sizeof(state_buf),
- STATE=%s, prop_buf);
- envp[env_offset++] = state_buf;
- }
- envp[env_offset] = NULL;
- /* Unlock early before uevent */
- spin_unlock_irqrestore(edev-lock, flags);
+ edev-state ^= change;
- kobject_uevent_env(edev-dev.kobj, KOBJ_CHANGE, envp);
- free_page((unsigned long)prop_buf);
- } else {
- /* Unlock early before uevent */
- spin_unlock_irqrestore(edev-lock, flags);
+ raw_notifier_call_chain(edev-nh, change, edev);
+
+ tmp = name_buf + sprintf(name_buf, NAME=);
+ length = name_show(edev-dev, NULL, tmp);
+ if (length 0) {
+ if (tmp[length - 1] == '\n')
+ tmp[length - 1] = 0;
+ envp[env_offset++] = name_buf;
+ }
- dev_err(edev-dev, out of memory in
extcon_set_state\n);
- kobject_uevent(edev-dev.kobj, KOBJ_CHANGE);
+ tmp = state_buf + sprintf(state_buf, STATE=);
+ length = state_show(edev-dev, NULL, tmp);
+ if (length 0) {
+ if (tmp[length - 1] == '\n')
+ tmp[length - 1] = 0;
+ envp[env_offset++] = state_buf;
}
+
+ envp[env_offset] = NULL;
+
+ /* Unlock early before uevent */
+ spin_unlock_irqrestore(edev-lock, flags);
+
+ kobject_uevent_env(edev-dev.kobj, KOBJ_CHANGE, envp);
} else {
/* No changes */
spin_unlock_irqrestore(edev-lock, flags);
@@ -464,18 +453,10 @@ static int _call_per_cable(struct notifier_block *nb,
unsigned long val,
{
struct extcon_cable_nb *obj = container_of(nb,
struct extcon_cable_nb, internal_nb);
- struct extcon_dev *edev = ptr;
-
- if ((val (1 obj-cable-cable_index)) !=
- (edev-state (1
[PATCH 09/13] extcon: extcon-class: move example to Documentation
This patch removes cable array example form extcon code, to avoid
littering driver namespace. Now it's located in extcon documentation.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
Documentation/extcon/extcon.txt | 108 +++
drivers/extcon/extcon-class.c | 32
include/linux/extcon.h | 42 ---
3 files changed, 108 insertions(+), 74 deletions(-)
create mode 100644 Documentation/extcon/extcon.txt
diff --git a/Documentation/extcon/extcon.txt b/Documentation/extcon/extcon.txt
new file mode 100644
index 000..6713f5f
--- /dev/null
+++ b/Documentation/extcon/extcon.txt
@@ -0,0 +1,108 @@
+Extcon - external connector
+===
+
+Extcon is generic framework used for notifying client drivers
+about specific cable connections and disconnections.
+
+Provider API
+
+
+Providers API consists of very few functions:
+
+extcon_dev_register() - register new extcon provider
+extcon_dev_unregister() - unregister extcon provider
+
+extcon_get_cable_state_() - get specific cable state
+extcon_set_cable_state_() - set specific cable state
+
+extcon_update_state() - update entire extcon state
+extcon_set_state() - set entire extcon state
+
+There are few fields in struct extcon_dev to be filled before passing it
+to extcon_dev_register() functions:
+
+name - name of extcon controller
+node - devicetree node of parent device
+supported_cable - array of strings with cable names ended with NULL pointer
+
+Example of cable array definition example can be found below:
+
+ enum extcon_cable_name {
+ EXTCON_USB = 0,
+ EXTCON_USB_HOST,
+ EXTCON_TA,
+ EXTCON_FAST_CHARGER,
+ EXTCON_SLOW_CHARGER,
+ EXTCON_CHARGE_DOWNSTREAM,
+ EXTCON_HDMI,
+ EXTCON_MHL,
+ EXTCON_DVI,
+ EXTCON_VGA,
+ EXTCON_DOCK,
+ EXTCON_LINE_IN,
+ EXTCON_LINE_OUT,
+ EXTCON_MIC_IN,
+ EXTCON_HEADPHONE_OUT,
+ EXTCON_SPDIF_IN,
+ EXTCON_SPDIF_OUT,
+ EXTCON_VIDEO_IN,
+ EXTCON_VIDEO_OUT,
+ EXTCON_MECHANICAL,
+ };
+
+ const char *extcon_cable_name[] = {
+ [EXTCON_USB]= USB,
+ [EXTCON_USB_HOST] = USB-Host,
+ [EXTCON_TA] = TA,
+ [EXTCON_FAST_CHARGER] = Fast-charger,
+ [EXTCON_SLOW_CHARGER] = Slow-charger,
+ [EXTCON_CHARGE_DOWNSTREAM] = Charge-downstream,
+ [EXTCON_HDMI] = HDMI,
+ [EXTCON_MHL]= MHL,
+ [EXTCON_DVI]= DVI,
+ [EXTCON_VGA]= VGA,
+ [EXTCON_DOCK] = Dock,
+ [EXTCON_LINE_IN]= Line-in,
+ [EXTCON_LINE_OUT] = Line-out,
+ [EXTCON_MIC_IN] = Microphone,
+ [EXTCON_HEADPHONE_OUT] = Headphone,
+ [EXTCON_SPDIF_IN] = SPDIF-in,
+ [EXTCON_SPDIF_OUT] = SPDIF-out,
+ [EXTCON_VIDEO_IN] = Video-in,
+ [EXTCON_VIDEO_OUT] = Video-out,
+ [EXTCON_MECHANICAL] = Mechanical,
+ };
+
+Cable name strings are used for debug messages and sysfs.
+
+After extcon device registration you can use functions modifying extcon state.
+If any extcon clients will register their interests in some cables, they will
+recieve notifications about cable state changes.
+
+Client API
+==
+
+Extcon client API is also pretty simple. It consists of funtions:
+
+of_extcon_get_cable() - returns extcon_cable at selected index
+of_extcon_get_cable_by_name() - returns extcon_cable associated with
+ selected name
+extcon_get_cable_by_name() - the same as above, but takes struct device
+instead of struct device_node
+
+extcon_register_interest() - register interest in selected cable
+extcon_unregister_interest() - unregister cable interest
+
+extcon_get_cable_state() - get state of given cable
+
+The extcon_register_interest() function takes three parameters,
+struct extcon_cable, struct extcon_cable_nb and extcon_notifier_fn_t
+which is pointer to callback function called when cable state changes.
+
+There are also two functions:
+
+extcon_register_notifier() - register notifier for entire extcon state
+extcon_unregister_notifier() - unregister such notifier
+
+But they should be used only for debug, and use of them in client drivers
+is not recommended.
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index ce76c08..2ea9a84 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -33,38 +33,6 @@
#include linux/sysfs.h
#include linux/of.h
-/*
- * extcon_cable_name suggests the
[PATCH 07/13] extcon: extcon-class: improve get_cable_state_()/set_cable_state_() functions
Added check if pointer to edev is not NULL, and updated documentation of index
parameter. Function extcon_find_cable_index() has been deleted and cannot be
used to retrieve cable number.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-class.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 2be0ac9..2659805 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -285,10 +285,12 @@ EXPORT_SYMBOL_GPL(extcon_set_state);
/**
* extcon_get_cable_state_() - Get the status of a specific cable.
* @edev: the extcon device that has the cable.
- * @index: cable index that can be retrieved by extcon_find_cable_index().
+ * @index: cable index in extcon device.
*/
int extcon_get_cable_state_(struct extcon_dev *edev, int index)
{
+ if (!edev)
+ return -ENODEV;
if (index 0 || (edev-max_supported edev-max_supported = index))
return -EINVAL;
@@ -312,8 +314,7 @@ EXPORT_SYMBOL_GPL(extcon_get_cable_state);
/**
* extcon_set_cable_state_() - Set the status of a specific cable.
* @edev: the extcon device that has the cable.
- * @index: cable index that can be retrieved by
- * extcon_find_cable_index().
+ * @index: cable index in extcon device.
* @cable_state: the new cable status. The default semantics is
* true: attached / false: detached.
*/
@@ -322,6 +323,8 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
{
u32 state;
+ if (!edev)
+ return -ENODEV;
if (index 0 || (edev-max_supported edev-max_supported = index))
return -EINVAL;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/13] extcon: extcon-class: remove unused functions
This patch removes two functions, extcon_find_cable_index() and
extcon_get_edev_by_phandle(). They are not longer needed, since
extcon client API has changed to be oriented on extcon_cable instead
of extcon_dev.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-class.c | 67 -
include/linux/extcon.h| 18 ---
2 files changed, 85 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 708b352..2be0ac9 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -283,32 +283,6 @@ int extcon_set_state(struct extcon_dev *edev, u32 state)
EXPORT_SYMBOL_GPL(extcon_set_state);
/**
- * extcon_find_cable_index() - Get the cable index based on the cable name.
- * @edev: the extcon device that has the cable.
- * @cable_name:cable name to be searched.
- *
- * Note that accessing a cable state based on cable_index is faster than
- * cable_name because using cable_name induces a loop with strncmp().
- * Thus, when get/set_cable_state is repeatedly used, using cable_index
- * is recommended.
- */
-int extcon_find_cable_index(struct extcon_dev *edev, const char *cable_name)
-{
- int i;
-
- if (edev-supported_cable) {
- for (i = 0; edev-supported_cable[i]; i++) {
- if (!strncmp(edev-supported_cable[i],
- cable_name, CABLE_NAME_MAX))
- return i;
- }
- }
-
- return -EINVAL;
-}
-EXPORT_SYMBOL_GPL(extcon_find_cable_index);
-
-/**
* extcon_get_cable_state_() - Get the status of a specific cable.
* @edev: the extcon device that has the cable.
* @index: cable index that can be retrieved by extcon_find_cable_index().
@@ -876,47 +850,6 @@ void extcon_dev_unregister(struct extcon_dev *edev)
}
EXPORT_SYMBOL_GPL(extcon_dev_unregister);
-#ifdef CONFIG_OF
-/*
- * extcon_get_edev_by_phandle - Get the extcon device from devicetree
- * @dev - instance to the given device
- * @index - index into list of extcon_dev
- *
- * return the instance of extcon device
- */
-struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
-{
- struct device_node *node;
- struct extcon_dev *edev;
-
- if (!dev-of_node) {
- dev_err(dev, device does not have a device node entry\n);
- return ERR_PTR(-EINVAL);
- }
-
- node = of_parse_phandle(dev-of_node, extcon, index);
- if (!node) {
- dev_err(dev, failed to get phandle in %s node\n,
- dev-of_node-full_name);
- return ERR_PTR(-ENODEV);
- }
-
- edev = of_extcon_get_extcon_dev(node);
- if (!edev) {
- dev_err(dev, unable to get extcon device : %s\n, node-name);
- return ERR_PTR(-ENODEV);
- }
-
- return edev;
-}
-#else
-struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
-{
- return ERR_PTR(-ENOSYS);
-}
-#endif /* CONFIG_OF */
-EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
-
static int __init extcon_class_init(void)
{
return create_extcon_class();
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index a571cad..939a7b0 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -210,8 +210,6 @@ extern int extcon_update_state(struct extcon_dev *edev, u32
mask, u32 state);
* They are used to access the status of each cable based on the cable_name
tt or cable_index, which is retrieved by extcon_find_cable_index
*/
-extern int extcon_find_cable_index(struct extcon_dev *sdev,
- const char *cable_name);
extern int extcon_get_cable_state_(struct extcon_dev *edev, int cable_index);
extern int extcon_set_cable_state_(struct extcon_dev *edev,
int cable_index, bool cable_state);
@@ -252,11 +250,6 @@ extern int extcon_register_notifier(struct extcon_dev
*edev,
extern int extcon_unregister_notifier(struct extcon_dev *edev,
struct notifier_block *nb);
-/*
- * Following API get the extcon device from devicetree.
- * This function use phandle of devicetree to get extcon device directly.
- */
-extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int
index);
#else /* CONFIG_EXTCON */
static inline int extcon_dev_register(struct extcon_dev *edev)
{
@@ -281,12 +274,6 @@ static inline int extcon_update_state(struct extcon_dev
*edev, u32 mask,
return 0;
}
-static inline int extcon_find_cable_index(struct extcon_dev *edev,
- const char *cable_name)
-{
- return 0;
-}
-
static inline int extcon_get_cable_state_(struct extcon_dev *edev,
int cable_index)
{
@@ -341,10 +328,5 @@ static inline int extcon_unregister_interest(struct
extcon_cable_nb
[PATCH 02/13] Documentation: update charger-manager devicetree bindings
This patch changes charger-manager bindings to be compatible with
new extcon bindings.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
.../bindings/power_supply/charger-manager.txt | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/power_supply/charger-manager.txt
b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
index 2b33750..f987bb5 100644
--- a/Documentation/devicetree/bindings/power_supply/charger-manager.txt
+++ b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
@@ -10,8 +10,7 @@ Required properties :
- subnode regulator :
- cm-regulator-name : name of charger regulator
- subnode cable :
- - cm-cable-name : name of charger cable
- - cm-cable-extcon : name of extcon dev
+ - extcon-cable : specified extcon cable
(optional) - cm-cable-min : minimum current of cable
(optional) - cm-cable-max : maximum current of cable
@@ -65,14 +64,14 @@ Example :
regulator@0 {
cm-regulator-name = chg-reg;
cable@0 {
- cm-cable-name = USB;
- cm-cable-extcon = extcon-dev.0;
+ /* USB cable */
+ extcon-cable = extcon 0;
cm-cable-min = 475000;
cm-cable-max = 50;
};
cable@1 {
- cm-cable-name = TA;
- cm-cable-extcon = extcon-dev.0;
+ /* TA cable */
+ extcon-cable = extcon 1;
cm-cable-min = 65;
cm-cable-max = 675000;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] Documentation: add extcon devicetree bindings
This patch adds extcon devicetree bindings. Documentation describes in general
client and provider bindings, and contains detailed desctiprion of bindings
for each extcon provider.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
.../devicetree/bindings/extcon/extcon-adc-jack.txt | 60 +++
.../devicetree/bindings/extcon/extcon-arizona.txt | 47 +++
.../devicetree/bindings/extcon/extcon-bindings.txt | 36 +++
.../devicetree/bindings/extcon/extcon-gpio.txt | 63
.../devicetree/bindings/extcon/extcon-max14577.txt | 49 +++
.../devicetree/bindings/extcon/extcon-max77693.txt | 56 +
.../devicetree/bindings/extcon/extcon-max8997.txt | 49 +++
.../devicetree/bindings/extcon/extcon-palmas.txt | 37 ++--
8 files changed, 393 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-arizona.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-bindings.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max14577.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max77693.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max8997.txt
diff --git a/Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
b/Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
new file mode 100644
index 000..6e43891
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
@@ -0,0 +1,60 @@
+* ADC JACK Extcon Controller
+
+ADC JACK extcon controller is responsible for cable detection.
+
+Required Properties:
+
+- compatible: should be extcon-adc-jack.
+
+- #extcon-cells: should be 1.
+
+- subnode cables: node describing list of cables.
+ - subnode cable:
+ - cable-name: name of specific cable
+ - adc-min: minimum specific cable ADC values range
+ - adc-max: maximum specific cable ADC values range
+
+Subnodes of node 'cables' describes specific cables with ADC value ranges
+associated with this cables. When measured ADC value will be between min and
+max value for specific cable, clients will be notified about connection of
+this cable. Value ranges for individual cables cannot be overlaping.
+
+Example 1: An example of a extcon controller node is listed below.
+
+ extcon: adc-jack {
+ compatible = extcon-adc-jack;
+ #extcon-cells = 1;
+
+ cables {
+ cable@0 {
+ cable-name = CABLE-0;
+ adc-min = 120;
+ adc-max = 240;
+ }
+ cable@1 {
+ cable-name = CABLE-1;
+ adc-min = 250;
+ adc-max = 400;
+ }
+ cable@2 {
+ cable-name = CABLE-2;
+ adc-min = 500;
+ adc-max = 700;
+ };
+ };
+ };
+
+Example 2: USB controller node that uses cable from the extcon
+ controller. Refer to the standard extcon bindings for
+ information about 'extcon-cables' and 'extcon-names'
+ property.
+
+ usb@1248 {
+ vusb_d-supply = vusb_reg;
+ vusb_a-supply = vusbdac_reg;
+
+ extcon-cables = extcon 0;
+ extcon-names = USB;
+
+ status = okay;
+ };
diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
new file mode 100644
index 000..9af4422
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
@@ -0,0 +1,47 @@
+* Wolfson Arizona Extcon Controller
+
+The Wolfson Arizona Extcon Controller is responsible for cable
+detection.
+
+Required Properties:
+
+- compatible: should be wlf,arizona-extcon.
+
+- #extcon-cells: should be 1.
+
+The following is the list of cables detected by the controller. Each
+cable is assigned an identifier and client nodes use this identifies
+to specify the cable which they are interested in.
+
+ CableID
+
+
+ Mechanical 0
+ Microphone 1
+ Headphone2
+ Line-out 3
+
+Example 1: An example of a extcon controller node is listed below.
+
+ extcon: arizona-extcon {
+ compatible = wlf,arizona-extcon;
+ #extcon-cells = 1;
+ };
+
+Example 2: Audio controller node that uses cable from the extcon
+ controller. Refer to the standard extcon
[PATCH 00/13] extcon: major rework
This patchset adds many improvements to extcon class driver and extcon provider drivers. It changes extcon API to faster and safer by replaceing function taking extcon and cable names with functions working with structures representing this objects. It adds more advanced devicetree support which allows to pass specified cables to client drivers. It gives independency from cable naming conventions in individual extcon provider drivers, and allows to simply connect client drivers with providers in way that being transpatent for both of them. It adds also some minor fixes like additional checks for safety increase, and another improvements. Also added some improvements to extcon provider drivers, improved devicetree support and updated them to use faster extcon API. Patches contains also documentation for extcon, and devicetree bindings for all provider drivers. More details can be found in commit messages and Documentation. Best regards Robert Baldyga Samsung RD Institute Poland Robert Baldyga (13): Documentation: add extcon devicetree bindings Documentation: update charger-manager devicetree bindings extcon: extcon-class: remove extcon_set_cable_state() function extcon: extcon-class: match extcon device by devicetree node extcon: extcon-class: improve extcon client API extcon: extcon-class: remove unused functions extcon: extcon-class: improve get_cable_state_()/set_cable_state_() functions extcon: extcon-class: simplify extcon_updata_state() function extcon: extcon-class: move example to Documentation extcon: extcon-gpio: add devicetree support extcon: extcon-adc-jack: add devicetree support extcon: extcon-max8997: check if pdata exists extcon: extcon-max77693: check if pdata exists .../devicetree/bindings/extcon/extcon-adc-jack.txt | 60 +++ .../devicetree/bindings/extcon/extcon-arizona.txt | 47 +++ .../devicetree/bindings/extcon/extcon-bindings.txt | 36 ++ .../devicetree/bindings/extcon/extcon-gpio.txt | 63 +++ .../devicetree/bindings/extcon/extcon-max14577.txt | 49 +++ .../devicetree/bindings/extcon/extcon-max77693.txt | 56 +++ .../devicetree/bindings/extcon/extcon-max8997.txt | 49 +++ .../devicetree/bindings/extcon/extcon-palmas.txt | 37 +- .../bindings/power_supply/charger-manager.txt | 11 +- Documentation/extcon/extcon.txt| 108 + drivers/extcon/extcon-adc-jack.c | 75 drivers/extcon/extcon-arizona.c|1 + drivers/extcon/extcon-class.c | 412 +--- drivers/extcon/extcon-gpio.c | 64 ++- drivers/extcon/extcon-max14577.c | 26 +- drivers/extcon/extcon-max77693.c | 82 ++-- drivers/extcon/extcon-max8997.c| 35 +- drivers/extcon/extcon-palmas.c | 28 +- drivers/power/charger-manager.c| 36 +- drivers/usb/dwc3/dwc3-omap.c | 68 ++-- drivers/usb/phy/phy-omap-otg.c | 72 ++-- include/linux/extcon.h | 157 +++- include/linux/extcon/extcon-gpio.h |2 +- include/linux/platform_data/usb-omap1.h|2 - include/linux/power/charger-manager.h |6 +- 25 files changed, 1067 insertions(+), 515 deletions(-) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-arizona.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-bindings.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max14577.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max77693.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max8997.txt create mode 100644 Documentation/extcon/extcon.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Thursday 10 April 2014 05:46 PM, Sekhar Nori wrote:
This will work. NS_LOCKDOWN is required for L2C-220 as well and so I was
thinking about adding a new l2c220_enable() which will set the
NS_LOCKDOWN and then call l2c_enable()
Here is a patch for what I was saying above.
diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h
b/arch/arm/include/asm/hardware/cache-l2x0.h
index c47ac8f..dc9e03b 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -105,6 +105,8 @@
#define L2X0_AUX_CTRL_DIRTY_LATENCY_MASK (7 9)
#define L2X0_AUX_CTRL_ASSOC_SHIFT 13
#define L2X0_AUX_CTRL_ASSOC_MASK (15 13)
+/* L2C-220/310 common bits */
+#define L2C_AUX_CTRL_NS_LOCKDOWN BIT(26)
/* L2C-210 specific bits */
#define L210_AUX_CTRL_WRAP_DISABLE BIT(12)
#define L210_AUX_CTRL_WA_OVERRIDE BIT(23)
@@ -113,7 +115,6 @@
#define L220_AUX_CTRL_EXCLUSIVE_CACHE BIT(12)
#define L220_AUX_CTRL_FWA_SHIFT23
#define L220_AUX_CTRL_FWA_MASK (3 23)
-#define L220_AUX_CTRL_NS_LOCKDOWN BIT(26)
#define L220_AUX_CTRL_NS_INT_CTRL BIT(27)
/* L2C-310 specific bits */
#define L310_AUX_CTRL_FULL_LINE_ZERO BIT(0) /* R2P0+ */
@@ -122,7 +123,6 @@
#define L310_AUX_CTRL_EXCLUSIVE_CACHE BIT(12)
#define L310_AUX_CTRL_ASSOCIATIVITY_16 BIT(16)
#define L310_AUX_CTRL_CACHE_REPLACE_RR BIT(25) /* R2P0+ */
-#define L310_AUX_CTRL_NS_LOCKDOWN BIT(26)
#define L310_AUX_CTRL_NS_INT_CTRL BIT(27)
#define L310_AUX_CTRL_DATA_PREFETCHBIT(28)
#define L310_AUX_CTRL_INSTR_PREFETCH BIT(29)
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 6b2a056..34cafe0 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -216,8 +216,6 @@ int __init omap4_l2_cache_init(void)
{
/* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */
u32 aux_ctrl = L310_AUX_CTRL_CACHE_REPLACE_RR |
- L310_AUX_CTRL_NS_LOCKDOWN |
- L310_AUX_CTRL_NS_INT_CTRL |
L2C_AUX_CTRL_SHARED_OVERRIDE |
L310_AUX_CTRL_DATA_PREFETCH |
L310_AUX_CTRL_INSTR_PREFETCH;
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index b1f103d..b6af13f 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -498,11 +498,23 @@ static void l2c220_sync(void)
raw_spin_unlock_irqrestore(l2x0_lock, flags);
}
+static void __init l2c220_enable(void __iomem *base, u32 aux, unsigned
num_lock)
+{
+ /*
+* Always enable non-secure access to the lockdown registers -
+* we write to them as part of the L2C enable sequence so they
+* need to be accessible.
+*/
+ aux |= L2C_AUX_CTRL_NS_LOCKDOWN;
+
+ l2c_enable(base, aux, num_lock);
+}
+
static const struct l2c_init_data l2c220_data = {
.type = L2C-220,
.way_size_0 = SZ_8K,
.num_lock = 1,
- .enable = l2c_enable,
+ .enable = l2c220_enable,
.outer_cache = {
.inv_range = l2c220_inv_range,
.clean_range = l2c220_clean_range,
@@ -764,7 +776,7 @@ static void __init l2c310_enable(void __iomem *base, u32
aux, unsigned num_lock)
power_ctrl L310_STNDBY_MODE_EN ? en : dis);
}
- l2c_enable(base, aux, num_lock);
+ l2c220_enable(base, aux, num_lock);
if (aux L310_AUX_CTRL_FULL_LINE_ZERO) {
set_auxcr(get_auxcr() | BIT(3) | BIT(2) | BIT(1));
@@ -1027,7 +1039,7 @@ static const struct l2c_init_data of_l2c220_data
__initconst = {
.way_size_0 = SZ_8K,
.num_lock = 1,
.of_parse = l2x0_of_parse,
- .enable = l2c_enable,
+ .enable = l2c220_enable,
.outer_cache = {
.inv_range = l2c220_inv_range,
.clean_range = l2c220_clean_range,
--
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 12/13] extcon: extcon-max8997: check if pdata exists
This patch adds check if pdata is NULL, to avoid NULL pointer dereference
when platform data is not available. After this changes, in described
situation driver will be configured with default values.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-max8997.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index c071588..d7d12e9 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -726,7 +726,7 @@ static int max8997_muic_probe(struct platform_device *pdev)
goto err_irq;
}
- if (pdata-muic_pdata) {
+ if (pdata pdata-muic_pdata) {
struct max8997_muic_platform_data *muic_pdata
= pdata-muic_pdata;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Thu, Apr 10, 2014 at 06:57:05PM +0530, Sekhar Nori wrote: On Thursday 10 April 2014 05:46 PM, Sekhar Nori wrote: This will work. NS_LOCKDOWN is required for L2C-220 as well and so I was thinking about adding a new l2c220_enable() which will set the NS_LOCKDOWN and then call l2c_enable() Here is a patch for what I was saying above. diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h index c47ac8f..dc9e03b 100644 --- a/arch/arm/include/asm/hardware/cache-l2x0.h +++ b/arch/arm/include/asm/hardware/cache-l2x0.h @@ -105,6 +105,8 @@ #define L2X0_AUX_CTRL_DIRTY_LATENCY_MASK (7 9) #define L2X0_AUX_CTRL_ASSOC_SHIFT13 #define L2X0_AUX_CTRL_ASSOC_MASK (15 13) +/* L2C-220/310 common bits */ +#define L2C_AUX_CTRL_NS_LOCKDOWN BIT(26) /* L2C-210 specific bits */ #define L210_AUX_CTRL_WRAP_DISABLE BIT(12) #define L210_AUX_CTRL_WA_OVERRIDEBIT(23) @@ -113,7 +115,6 @@ #define L220_AUX_CTRL_EXCLUSIVE_CACHEBIT(12) #define L220_AUX_CTRL_FWA_SHIFT 23 #define L220_AUX_CTRL_FWA_MASK (3 23) -#define L220_AUX_CTRL_NS_LOCKDOWNBIT(26) #define L220_AUX_CTRL_NS_INT_CTRLBIT(27) /* L2C-310 specific bits */ #define L310_AUX_CTRL_FULL_LINE_ZERO BIT(0) /* R2P0+ */ @@ -122,7 +123,6 @@ #define L310_AUX_CTRL_EXCLUSIVE_CACHEBIT(12) #define L310_AUX_CTRL_ASSOCIATIVITY_16 BIT(16) #define L310_AUX_CTRL_CACHE_REPLACE_RR BIT(25) /* R2P0+ */ -#define L310_AUX_CTRL_NS_LOCKDOWNBIT(26) NAK. The reason for this split is because the NS lockdown bit is *not* on L2C-210, and so it does not deserve to be a common bit - because it isn't common to all variants. @@ -764,7 +776,7 @@ static void __init l2c310_enable(void __iomem *base, u32 aux, unsigned num_lock) power_ctrl L310_STNDBY_MODE_EN ? en : dis); } - l2c_enable(base, aux, num_lock); + l2c220_enable(base, aux, num_lock); My first reaction to this is to say NAK again - I don't want to create a multi-layered maze of X calls Y calls Z. Who's to say that The 220 won't need to do something different from 310 in the future? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] i2c: omap: Disable default probing of i2c devices for omap i2c.
Hi Wolfram, On Wednesday 09 April 2014 06:07 PM, Wolfram Sang wrote: On Wed, Apr 09, 2014 at 04:06:48PM +0530, Sourav Poddar wrote: I2c core supports defualt probing functionality for devices not registered through dt/board files. If there are any client driver registered, i2c core will try to check if there is any device present corresponding to the address supplied by the client driver. If the device is actually present and not registered, core will register it, else the device default probe will fail and we get a omap i2c controller specific timeout messages. For example, Using multi_v7_config on omap5-uevm, CONFIG_SENSORS_LM90 and CONFIG_ICS932S401 is the driver which is enabled and gets registered. I2c core tries to find a valid corresponding device on each of the address supplied by registered driver, but could not find anyone. Hence, keep dumping the controller timeout speciic message. This is exactly why I2C_CLASS_DEPRECATED was implemented. So, users which are using classes can migrate away. But this needs time. Given that I2C_CLASS_DEPRECATED is new in 3.15, I'd think setting classes to 0 (thus totally disabling them) should not be before 3.17. You don't need to resend, I'll do it for all drivers I added this new class to when I feel it is safe to do. OK then, I am dropping this patch, will wait for your patches on it. Thanks for the review. ~Sourav Thanks, Wolfram -- 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 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On 04/01/2014 08:06 AM, Peter Ujfalusi wrote: Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high priority channels, like audio. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com This looks good, though another way to do it would be to leave default to Queue 0. Put audio in Queue 1, and change QUEPRI to make Queue 1 as higher priority. This is fine, Acked-by: Joel Fernandes jo...@ti.com Regards, -Joel -- 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 08/14] DMA: edma: Use different eventq for cyclic channels
On 04/01/2014 08:06 AM, Peter Ujfalusi wrote: To improve latency with cyclic DMA operation it is preferred to use different eventq/tc than the default which is used by all other drivers (mmc, spi, i2c, etc). When preparing the cyclic dma ask for non default queue for the channel which is going to be used with cyclic mode. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/dma/edma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 1dd9e8806975..10048b40fac8 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -628,6 +628,9 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic( edesc-pset[i].opt |= TCINTEN; } + /* Use different eventq/tc for cyclic DMA to reduce latency */ + edma_request_non_default_queue(echan-ch_num); + return vchan_tx_prep(echan-vchan, edesc-vdesc, tx_flags); } Is there any way to guarantee that the non-default queue is of the highest priority, or in other words default queue is of lowest priority. I know you set queue 1 as default because by default 0 is higher priority. And then assigning non-default queue. When assigning default to Queue 1, it would be good to also call assign_priority_to_queue and set QUEPRI to 7 for Queue 1. Since 0, 2 and 4 are all non-defaults. Thanks, -Joel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] GPIO OMAP driver changes for v3.16
On Sun, Apr 6, 2014 at 4:58 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Now that you have sent your changes for v3.15 to Torvalds, here are some changes for the OMAP GPIO driver targeted to v3.16. Mostly improvements so nothing here is -rc material. I like this series so I have applied them for v3.16, pending some ACK from Kevin | Santosh. The biggest change is Patch 4 that converts the driver to use the newly introduced generic irqchip helpers in the gpiolib core which allows to remove some driver specific logic that should really be generic. Excellent, I will take a closer look at this, it seems there is some cruft still in but let me look. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] gpio: omap: convert to use irq_domain_add_simple()
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
The GPIO OMAP driver supports different OMAP SoC families and
not all of them have the needed support to use the linear IRQ
domain mapping like OMAP1 that use the legacy domain mapping.
But this special check is not necessary since the simple IRQ
domain mapping is able to handle both cases. Having a zero
IRQ offset will be interpreted as a linear domain case while
a non-zero value will be interpreted as a legacy domain case.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..3ee9b8d 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1138,9 +1138,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
const struct omap_gpio_platform_data *pdata;
struct resource *res;
struct gpio_bank *bank;
-#ifdef CONFIG_ARCH_OMAP1
- int irq_base;
-#endif
+ int irq_base = 0;
match = of_match_device(of_match_ptr(omap_gpio_match), dev);
@@ -1185,21 +1183,16 @@ static int omap_gpio_probe(struct platform_device
*pdev)
#ifdef CONFIG_ARCH_OMAP1
/*
* REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop
- * irq_alloc_descs() and irq_domain_add_legacy() and just use a
- * linear IRQ domain mapping for all OMAP platforms.
+ * irq_alloc_descs() since a base IRQ offset will no longer be needed.
*/
irq_base = irq_alloc_descs(-1, 0, bank-width, 0);
if (irq_base 0) {
dev_err(dev, Couldn't allocate IRQ numbers\n);
return -ENODEV;
}
-
- bank-domain = irq_domain_add_legacy(node, bank-width, irq_base,
- 0, irq_domain_simple_ops, NULL);
-#else
- bank-domain = irq_domain_add_linear(node, bank-width,
- irq_domain_simple_ops, NULL);
#endif
+ bank-domain = irq_domain_add_simple(node, bank-width, irq_base,
+ irq_domain_simple_ops, NULL);
if (!bank-domain) {
dev_err(dev, Couldn't register an IRQ domain\n);
return -ENODEV;
Looks good.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] gpio: omap: check gpiochip_add() return value
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote: The gpiochip_add() function can fail if the chip cannot be registered so the return value has to be checked and the error propagated in case it happens. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] gpio: omap: add a GPIO_OMAP option instead of using ARCH_OMAP
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote: The ARCH_OMAP config option was used to built the GPIO OMAP driver but this is not consistent with the rest of the GPIO drivers that have their own Kconfig option. Also, this make it harder to add dependencies or reverse dependencies (i.e: select) since that would mean touching the sub-arch config option. So is better to add a boolean Kconfig option for this driver that defaults to true if ARCH_OMAP is enabled. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] gpio: omap: convert driver to use gpiolib irqchip
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
Converts the GPIO OMAP driver to register its chained irq
handler and irqchip using the helpers in the gpiolib core.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/Kconfig | 1 +
drivers/gpio/gpio-omap.c | 107
++-
2 files changed, 52 insertions(+), 56 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index bfe5cf0..2092b1d 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -247,6 +247,7 @@ config GPIO_OMAP
bool TI OMAP GPIO support
default y if ARCH_OMAP
depends on ARM ARCH_OMAP
+ select GPIOLIB_IRQCHIP
help
Say yes here to enable GPIO support for TI OMAP SoCs.
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index e717888..8cc9e91 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -24,7 +24,6 @@
#include linux/pm.h
#include linux/of.h
#include linux/of_device.h
-#include linux/irqdomain.h
#include linux/irqchip/chained_irq.h
#include linux/gpio.h
#include linux/platform_data/gpio-omap.h
@@ -52,7 +51,6 @@ struct gpio_bank {
struct list_head node;
void __iomem *base;
u16 irq;
- struct irq_domain *domain;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
@@ -95,11 +93,10 @@ static int irq_to_gpio(struct gpio_bank *bank, unsigned
int gpio_irq)
return bank-chip.base + gpio_irq;
}
-static int omap_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
+static inline struct gpio_bank *_irq_data_get_bank(struct irq_data *d)
{
- struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
-
- return irq_find_mapping(bank-domain, offset);
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
+ return container_of(chip, struct gpio_bank, chip);
}
static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int
is_input)
@@ -479,7 +476,7 @@ static int gpio_is_input(struct gpio_bank *bank, int mask)
static int gpio_irq_type(struct irq_data *d, unsigned type)
{
- struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+ struct gpio_bank *bank = _irq_data_get_bank(d);
unsigned gpio = 0;
int retval;
unsigned long flags;
@@ -514,14 +511,6 @@ static int gpio_irq_type(struct irq_data *d, unsigned
type)
return -EINVAL;
}
- retval = gpio_lock_as_irq(bank-chip, offset);
- if (retval) {
- dev_err(bank-dev, unable to lock offset %d for IRQ\n,
- offset);
- spin_unlock_irqrestore(bank-lock, flags);
- return retval;
- }
-
bank-irq_usage |= 1 GPIO_INDEX(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
@@ -664,7 +653,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
/* Use disable_irq_wake() and enable_irq_wake() functions from drivers */
static int gpio_wake_enable(struct irq_data *d, unsigned int enable)
{
- struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+ struct gpio_bank *bank = _irq_data_get_bank(d);
unsigned int gpio = irq_to_gpio(bank, d-hwirq);
return _set_gpio_wakeup(bank, gpio, enable);
@@ -732,11 +721,12 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
unsigned int bit;
struct gpio_bank *bank;
int unmasked = 0;
- struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct irq_chip *irqchip = irq_desc_get_chip(desc);
+ struct gpio_chip *chip = irq_get_handler_data(irq);
- chained_irq_enter(chip, desc);
+ chained_irq_enter(irqchip, desc);
- bank = irq_get_handler_data(irq);
+ bank = container_of(chip, struct gpio_bank, chip);
isr_reg = bank-base + bank-regs-irqstatus;
pm_runtime_get_sync(bank-dev);
@@ -764,7 +754,7 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
configured, we could unmask GPIO bank interrupt immediately */
if (!level_mask !unmasked) {
unmasked = 1;
- chained_irq_exit(chip, desc);
+ chained_irq_exit(irqchip, desc);
}
if (!isr)
@@ -784,7 +774,8 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
if (bank-toggle_mask (1 bit))
_toggle_gpio_edge_triggering(bank, bit);
- generic_handle_irq(irq_find_mapping(bank-domain, bit));
+
generic_handle_irq(irq_find_mapping(bank-chip.irqdomain,
+ bit));
}
}
/* if bank has any level sensitive GPIO pin interrupt
@@ -793,13 +784,13 @@ static void
Re: [PATCH 4/5] gpio: omap: convert driver to use gpiolib irqchip
On Thu, Apr 10, 2014 at 7:39 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
+#ifdef CONFIG_ARCH_OMAP1
+ /*
+ * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop
+ * irq_alloc_descs() since a base IRQ offset will no longer be needed.
+ */
+ irq_base = irq_alloc_descs(-1, 0, bank-width, 0);
+ if (irq_base 0) {
+ dev_err(bank-dev, Couldn't allocate IRQ numbers\n);
+ return -ENODEV;
+ }
+#endif
+
Do we still need above after first patch ? Would be good
to get rid of above ugly #ifdef on the middle of the code.
I don't think so actually, simple irqdomain adds descriptors
for irqbase != 0, and the gpiochip irqchip helpers call
irq_create_mapping() on all offsets.
Preferably a separate patch on top of this removing that code
though so it's bisectable.
Yours,
Linus Walleij
--
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 05/13] extcon: extcon-class: improve extcon client API
Hi,
On Thu, Apr 10, 2014 at 03:16:43PM +0200, Robert Baldyga wrote:
+struct extcon_cable *extcon_get_cable_by_name(struct device *dev,
+ const char *name)
+{
+ return of_extcon_get_cable_by_name(dev-of_node, name);
+}
+EXPORT_SYMBOL_GPL(extcon_get_cable_by_name);
[...]
@@ -96,17 +95,13 @@ static int omap_otg_probe(struct platform_device *pdev)
{
const struct omap_usb_config *config = pdev-dev.platform_data;
^
[...]
- ret = extcon_register_interest(otg_dev-id_dev, config-extcon,
-USB-HOST, otg_dev-id_nb);
+ cable_id = extcon_get_cable_by_name(pdev-dev, USB-HOST);
NACK. OMAP1 is not using DT, so this driver would stop working
with this series.
A.
--
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 4/5] gpio: omap: convert driver to use gpiolib irqchip
Hello Linus and Santosh,
On Thu, Apr 10, 2014 at 7:45 PM, Linus Walleij linus.wall...@linaro.org wrote:
On Thu, Apr 10, 2014 at 7:39 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
+#ifdef CONFIG_ARCH_OMAP1
+ /*
+ * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop
+ * irq_alloc_descs() since a base IRQ offset will no longer be needed.
+ */
+ irq_base = irq_alloc_descs(-1, 0, bank-width, 0);
+ if (irq_base 0) {
+ dev_err(bank-dev, Couldn't allocate IRQ numbers\n);
+ return -ENODEV;
+ }
+#endif
+
Do we still need above after first patch ? Would be good
to get rid of above ugly #ifdef on the middle of the code.
When working on this series I tried to remove the #ifdef but as far as
I understood is not currently possible until OMAP1 supports sparse irq
numbering.
Not so long ago the GPIO OMAP driver used the legacy domain mapping
for all OMAP SoCs and Jon Hunter converted to use linear domain
mapping on commit ede4d7a (gpio/omap: convert gpio irq domain to
linear mapping).
Unfortunately that change caused a regression on OMAP1 platforms as
reported by Aaro [0] so I had to partially revert the linear domain
mapping for OMAP1 platforms on commit 397ead (gpio/omap: don't use
linear domain mapping for OMAP1) introducing this ugly ifdefery in
the middle of the code.
I don't think so actually, simple irqdomain adds descriptors
for irqbase != 0, and the gpiochip irqchip helpers call
irq_create_mapping() on all offsets.
Looking at irq_domain_add_simple() [1] I see that it only calls
irq_alloc_descs() and irq_domain_associate_many() if first_irq 0 and
CONFIG_SPARSE_IRQ is enabled (which is not the case for
omap1_defconfig).
So, if I got this correctly removing the #ifdef for OMAP1 and calling
irq_domain_add_simple() is functionally equivalent to what Jon's patch
did that broke omap1. That is would have the same effect that just
calling irq_domain_add_linear() [2] for OMAP1.
Preferably a separate patch on top of this removing that code
though so it's bisectable.
If I remember correctly we did that partial revert because we were in
a -rc cycle and I didn't have time to investigate why
irq_domain_add_linear() does not work on omap1. I could try to do this
as a follow up patch but unfortunately I don't have access to any
omap1 platform to do further debug.
Please let me know if I got something wrong while looking at the code.
Yours,
Linus Walleij
--
Thanks a lot and best regards,
Javier
[0]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89005.html
[1]: http://lxr.free-electrons.com/source/kernel/irq/irqdomain.c#L123
[2]: http://lxr.free-electrons.com/source/include/linux/irqdomain.h#L139
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] GPIO OMAP driver changes for v3.16
Hi, On Thu, Apr 10, 2014 at 07:29:26PM +0200, Linus Walleij wrote: On Sun, Apr 6, 2014 at 4:58 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Now that you have sent your changes for v3.15 to Torvalds, here are some changes for the OMAP GPIO driver targeted to v3.16. Mostly improvements so nothing here is -rc material. I like this series so I have applied them for v3.16, pending some ACK from Kevin | Santosh. I tried these patches on OMAP1 on top of today's Torvalds git (4ba85265790ba3681deeaf73f018c0eb829a7341). On Amstrad E3 I'm getting the following logs: [0.156491] omap_gpio omap_gpio.0: Runtime PM disabled, clock forced on. [0.164604] genirq: Setting trigger mode 0 for irq 64 failed (gpio_irq_type+0x0/0x1f0) [0.165418] genirq: Setting trigger mode 0 for irq 65 failed (gpio_irq_type+0x0/0x1f0) [0.166133] genirq: Setting trigger mode 0 for irq 66 failed (gpio_irq_type+0x0/0x1f0) [0.166838] genirq: Setting trigger mode 0 for irq 67 failed (gpio_irq_type+0x0/0x1f0) [...] [0.182856] genirq: Setting trigger mode 0 for irq 79 failed (gpio_irq_type+0x0/0x1f0) [0.186887] omap_gpio omap_gpio.1: Could not get gpio dbck [0.189308] genirq: Setting trigger mode 0 for irq 95 failed (gpio_irq_type+0x0/0x1f0) [...] [0.203121] genirq: Setting trigger mode 0 for irq 110 failed (gpio_irq_type+0x0/0x1f0) However it still seems to work. The serio is only GPIO IRQ and it triggers when I press the external keyboard. The same happens also on Nokia 770: [0.118896] genirq: Setting trigger mode 0 for irq 128 failed (gpio_irq_type+0x0/0x220) [0.119201] genirq: Setting trigger mode 0 for irq 129 failed (gpio_irq_type+0x0/0x220) [...] [0.124999] genirq: Setting trigger mode 0 for irq 143 failed (gpio_irq_type +0x0/0x220) [0.126831] omap_gpio omap_gpio.1: Could not get gpio dbck [0.127258] OMAP GPIO hardware version 1.1 [0.127624] omap_gpio omap_gpio.2: Could not get gpio dbck [0.128204] omap_gpio omap_gpio.3: Could not get gpio dbck [0.128753] omap_gpio omap_gpio.4: Could not get gpio dbck Here also GPIO IRQs (touchscreen, Retu) still work. A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] GPIO OMAP driver changes for v3.16
Hello Aaro,
Thanks a lot for testing the series!
On Thu, Apr 10, 2014 at 9:30 PM, Aaro Koskinen aaro.koski...@iki.fi wrote:
Hi,
On Thu, Apr 10, 2014 at 07:29:26PM +0200, Linus Walleij wrote:
On Sun, Apr 6, 2014 at 4:58 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Now that you have sent your changes for v3.15 to Torvalds, here are some
changes for the OMAP GPIO driver targeted to v3.16. Mostly improvements
so nothing here is -rc material.
I like this series so I have applied them for v3.16, pending some ACK
from Kevin | Santosh.
I tried these patches on OMAP1 on top of today's Torvalds git
(4ba85265790ba3681deeaf73f018c0eb829a7341).
On Amstrad E3 I'm getting the following logs:
[0.156491] omap_gpio omap_gpio.0: Runtime PM disabled, clock forced on.
[0.164604] genirq: Setting trigger mode 0 for irq 64 failed
(gpio_irq_type+0x0/0x1f0)
[0.165418] genirq: Setting trigger mode 0 for irq 65 failed
(gpio_irq_type+0x0/0x1f0)
[0.166133] genirq: Setting trigger mode 0 for irq 66 failed
(gpio_irq_type+0x0/0x1f0)
[0.166838] genirq: Setting trigger mode 0 for irq 67 failed
(gpio_irq_type+0x0/0x1f0)
[...]
[0.182856] genirq: Setting trigger mode 0 for irq 79 failed
(gpio_irq_type+0x0/0x1f0)
[0.186887] omap_gpio omap_gpio.1: Could not get gpio dbck
[0.189308] genirq: Setting trigger mode 0 for irq 95 failed
(gpio_irq_type+0x0/0x1f0)
[...]
[0.203121] genirq: Setting trigger mode 0 for irq 110 failed
(gpio_irq_type+0x0/0x1f0)
However it still seems to work. The serio is only GPIO IRQ and it
triggers when I press the external keyboard.
The same happens also on Nokia 770:
[0.118896] genirq: Setting trigger mode 0 for irq 128 failed
(gpio_irq_type+0x0/0x220)
[0.119201] genirq: Setting trigger mode 0 for irq 129 failed
(gpio_irq_type+0x0/0x220)
[...]
[0.124999] genirq: Setting trigger mode 0 for irq 143 failed
(gpio_irq_type
+0x0/0x220)
[0.126831] omap_gpio omap_gpio.1: Could not get gpio dbck
[0.127258] OMAP GPIO hardware version 1.1
[0.127624] omap_gpio omap_gpio.2: Could not get gpio dbck
[0.128204] omap_gpio omap_gpio.3: Could not get gpio dbck
[0.128753] omap_gpio omap_gpio.4: Could not get gpio dbck
Here also GPIO IRQs (touchscreen, Retu) still work.
A.
I don't have those errors when booting on my DM3730 IGEPv2 board but
it seems that for some reason on omap1 __irq_set_trigger() complains
when IRQ_TYPE_NONE is used as a default flag when calling
gpiochip_irqchip_add()
Could you please test the following patch and tell me if your board
still works and makes the errors go away?
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 8cc9e91..5bc8aec 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1122,7 +1122,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
ret = gpiochip_irqchip_add(bank-chip, gpio_irq_chip,
irq_base, gpio_irq_handler,
- IRQ_TYPE_NONE);
+ IRQ_TYPE_LEVEL_LOW);
if (ret) {
dev_err(bank-dev, Couldn't add irqchip to gpiochip
%d\n, ret);
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] GPIO OMAP driver changes for v3.16
Hi,
On Thu, Apr 10, 2014 at 10:17:44PM +0200, Javier Martinez Canillas wrote:
The same happens also on Nokia 770:
[0.118896] genirq: Setting trigger mode 0 for irq 128 failed
(gpio_irq_type+0x0/0x220)
I don't have those errors when booting on my DM3730 IGEPv2 board but
it seems that for some reason on omap1 __irq_set_trigger() complains
when IRQ_TYPE_NONE is used as a default flag when calling
gpiochip_irqchip_add()
Could you please test the following patch and tell me if your board
still works and makes the errors go away?
Now it complains about mode 8...
[0.118835] genirq: Setting trigger mode 8 for irq 128 failed (gpio_irq_type
+0x0/0x220)
A.
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 8cc9e91..5bc8aec 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1122,7 +1122,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
ret = gpiochip_irqchip_add(bank-chip, gpio_irq_chip,
irq_base, gpio_irq_handler,
- IRQ_TYPE_NONE);
+ IRQ_TYPE_LEVEL_LOW);
if (ret) {
dev_err(bank-dev, Couldn't add irqchip to gpiochip
%d\n, ret);
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] serial: omap: Fix missing pm_runtime_resume handling by simplifying code
On Tue, Mar 25, 2014 at 11:48:47AM -0700, Tony Lindgren wrote: The lack of pm_runtime_resume handling for the device state leads into device wake-up interrupts not working after a while for runtime PM. Also, serial-omap is confused about the use of device_may_wakeup. The checks for device_may_wakeup should only be done for suspend and resume, not for pm_runtime_suspend and pm_runtime_resume. The wake-up events for PM runtime should always be enabled. The lack of pm_runtime_resume handling leads into device wake-up interrupts not working after a while for runtime PM. Rather than try to patch over the issue of adding complex tests to the pm_runtime_resume, let's fix the issues properly: 1. Make serial_omap_enable_wakeup deal with all internal PM state handling so we don't need to test for up-wakeups_enabled elsewhere. Later on once omap3 boots in device tree only mode we can also remove the up-wakeups_enabled flag and rely on the wake-up interrupt enable/disable state alone. 2. Do the device_may_wakeup checks in suspend and resume only, for runtime PM the wake-up events need to be always enabled. 3. Finally just call serial_omap_enable_wakeup and make sure we call it also in pm_runtime_resume. 4. Note that we also have to use disable_irq_nosync as serial_omap_irq calls pm_runtime_get_sync. Fixes: 2a0b965cfb6e (serial: omap: Add support for optional wake-up) Cc: sta...@vger.kernel.org # v3.13+ Signed-off-by: Tony Lindgren t...@atomide.com FWIW: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH] irq: crossbar: improve allocate_free_irq() complexity
On Tue, Apr 01, 2014 at 05:44:19PM -0500, Felipe Balbi wrote: current algorithm in allocate_free_irq() is O(n), by just keeping track of last allocated IRQ with a simple unsigned integer, we can find a free IRQ in O(1). Signed-off-by: Felipe Balbi ba...@ti.com --- compile-tested only as J6 DTS is currently missing crossbar altogether :-( There's a drawback with this patch which I'm not sure if we should care a lot because I couldn't entirely grasp when is domain-xlate() called and if we will map/unmap IRQs in runtime or will this *always* be done only during boot. If we're talking about runtime IRQ remapping, then this, clearly, won't work. But if this will be done only during boot up, then we avoid iterating over the irq_map array each time we try to translate a new IRQ prior to mapping it. Comments are highly welcome as I'll probably learn something new about the IRQ subsystem ;-) do not apply this one!!! It won't work in all cases. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 10/14] dma: edma: Simplify direction configuration in edma_config_pset()
On 04/01/2014 08:06 AM, Peter Ujfalusi wrote:
We only support DEV_TO_MEM or MEM_TO_DEV directions with edma driver and the
check for the direction has been already done in the function calling
edma_config_pset().
The error reporting is redundant and also the else if () can be removed.
NAK. Please don't do this. I have been working on MEM_TO_MEM support as
well so leave it as it is for future.
Thanks,
-Joel
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 855766672aa9..d954099650ae 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -372,14 +372,12 @@ static int edma_config_pset(struct dma_chan *chan,
struct edmacc_param *pset,
src_cidx = cidx;
dst_bidx = 0;
dst_cidx = 0;
- } else if (direction == DMA_DEV_TO_MEM) {
+ } else {
+ /* DMA_DEV_TO_MEM */
src_bidx = 0;
src_cidx = 0;
dst_bidx = acnt;
dst_cidx = cidx;
- } else {
- dev_err(dev, %s: direction not implemented yet\n, __func__);
- return -EINVAL;
}
pset-opt = EDMA_TCC(EDMA_CHAN_SLOT(echan-ch_num));
--
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 00/14] dma: edma: Fixes for cyclic (audio) operation
Hi Peter, Other than patches 8/14 and 10/14 which I responded to, you could add my Acked-by, or add it to the series itself once you make the changes and drop 10. Acked-by: Joel Fernandes jo...@ti.com Thanks, -Joel On 04/01/2014 08:06 AM, Peter Ujfalusi wrote: Hi, This is basically a resend of the previous series: https://lkml.org/lkml/2014/3/13/119 with removed ASoC patches (most of them are applied already). Changes since v1: - ASoC patches removed - Comments from Andriy Shevchenko addressed - patch added to fix cases when src/dst_maxburst is set to 0 Adding support for DMA pause/resume Possibility to select non default event queue/TC for cyclic (audio) dma channels: all devices using the eDMA via dmaengine was assigned to the default EQ/TC (mmc, i2c, spi, etc, and audio). This is not optimal from system performance point of view since sharing the same EQ/TC can cause latency spikes for cyclic channels (long DMA transfers for MMC for example). While debugging the edma to get things sorted out I noticed that the debug was too verbose and the important information was hidden even when the we did not asked for verbose dmaengine debug. I have included some debug cleanups for the edma dmaengine driver also. Regards, Peter --- Peter Ujfalusi (14): platform_data: edma: Be precise with the paRAM struct dma: edma: Correct the handling of src/dst_maxburst == 0 dma: edma: Add support for DMA_PAUSE/RESUME operation dma: edma: Set DMA_CYCLIC capability flag arm: common: edma: Select event queue 1 as default when booted with DT arm: common: edma: Save the number of event queues/TCs arm: common: edma: API to request non default queue for a channel DMA: edma: Use different eventq for cyclic channels dma: edma: Implement device_slave_caps callback dma: edma: Simplify direction configuration in edma_config_pset() dma: edma: Reduce debug print verbosity for non verbose debugging dma: edma: Prefix debug prints where the text were identical in prep callbacks dma: edma: Add channel number to debug prints dma: edma: Print the direction value as well when it is not supported arch/arm/common/edma.c | 34 +- drivers/dma/edma.c | 96 +- include/linux/platform_data/edma.h | 20 3 files changed, 119 insertions(+), 31 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 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Hi Joerg, On Wednesday 09 April 2014 17:08:31 Joerg Roedel wrote: On Tue, Apr 08, 2014 at 05:02:37PM +0200, Laurent Pinchart wrote: On Tuesday 08 April 2014 15:43:22 Joerg Roedel wrote: Who is someone in this case? That's exactly the problem :-) The ARM DMA API implementation doesn't care who that someone is. Existing implementations call those functions either from the bus masters device drivers (in which case the drivers need to be IOMMU- aware, even if they use the DMA API and don't need to handle the IOMMU directly) or from the IOMMU drivers (in which case the bus masters device drivers don't have to care about the IOMMU, but without a way for drivers to handle the IOMMU directly when they need to). Possible other candidates are core IOMMU code or bus code. That doesn't sound very transparent for the device drivers. All what you describe above (attaching a device to its default domain for DMA-API) should happen in the IOMMU driver. For the device driver it should make no difference if there is an IOMMU or not. Creating the DMA API mapping and attaching the device to the domain are definitely not transparent when performed by bus master device drivers. That's just the current situation for several drivers, and we obviously want to change it. If we call arm_iommu_attach_device() from the IOMMU driver to get default transparent IOMMU handling, the function will then attach the device to the default domain with a call to iommu_attach_device(). If you have to call a function it is not transparent anymore. Sure it is, IOMMU handling is transparent for the bus master device (which is the goal) when arm_iommu_attach_device() is called from the IOMMU driver. If a driver needs to handle the IOMMU directly, should it start by detaching the device from the ARM IOMMU domain ? We would need to be very careful with the assumptions made by the different layers, as they might not support a driver attaching a new domain to a device that already has a domain attached. I'd feel more comfortable with avoiding to attach the default domain to the device in the first place, but that might not be easily doable. The way this is solved by others is that iommu_attach_device() automatically detaches the device from its default (DMA-API) domain and attach it to the device drivers own domain. On iommu_detach_device() the device is attached back to the default domain. That might work, I'll need to give it a try. It will make the attach/detach operations pretty complex though, with copies of the same code in all IOMMU drivers. Refactoring will probably be needed, but I'll first see if I can get it working properly without modifying the IOMMU core. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/11] ARM: dts: Enable N900 keybaord sleep leds by default
On N900 there are nice LEDs that show the state of the
sys_clkreq and sys_off_mode pins.
These LEDs go low when the system enters deeper idle
states. The left LED shows the state of the sys_clkreq
pin, and goes off during retention idle. The right LED
shows the state of sys_off_mode pin and both go off
during off idle.
As N900 is a battery operated device, these LEDs should
be off most of the time. So let's enable them by default
so we can make sure the system is mostly idle.
This allows the maintainers to also immediately test
patches for PM regressions by looking at the LEDs,
which certainly makes my life easier.
The LED can naturally be disabled during runtime with:
# echo none /sys/class/leds/debug::sleep/trigger
Note that we don't currently have support for omap3
errata 1.158 that remuxes GPIO pins to INPUT_PULLUP |
MUX_MODE7 for the duration of idle. This means that the
GPIO pins set high will go down during off idle. In this
case it does not matter as the sys_off_mode goes down
too, but there's still a slim chance of false off idle
LED signals. If in doubt, false LED signals can be
verified by the sys_off_mode or vdd_core values.
Also note that to allow the UARTs to autoidle, the
following needs to be run on N900 to enable off idle:
#!/bin/sh
uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d)
for uart in $uarts; do
echo 3000 $uart/autosuspend_delay_ms
done
uarts=$(find /sys/class/tty/ttyO*/power/ -type d)
for uart in $uarts; do
echo enabled $uart/wakeup
echo auto $uart/control
done
echo 1 /sys/kernel/debug/pm_debug/enable_off_mode
For retention idle, change the above to set 0 to
enable_off_mode.
Also note that without the twl4030 PM scripts the actual
voltage scaling won't happen for off idle so we only get
voltage scaling over I2C4 for retention idle. I'll do
some device tree patches for those also a bit later on.
Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Kevin Hilman khil...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Pali Rohár pali.ro...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Pavel Machek pa...@ucw.cz
Cc: Sebastian Reichel s...@kernel.org
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3-n900.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 0bf40c9..0d34201 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -21,6 +21,17 @@
};
};
+leds {
+compatible = gpio-leds;
+heartbeat {
+label = debug::sleep;
+gpios = gpio6 2 GPIO_ACTIVE_HIGH; /* gpio162 */
+linux,default-trigger = default-on;
+ pinctrl-names = default;
+ pinctrl-0 = debug_leds;
+};
+};
+
memory {
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
@@ -114,6 +125,12 @@
;
};
+ debug_leds: pinmux_debug_led_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE4)
/* mcbsp1_clkx.gpio_162 */
+ ;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins =
0x114 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc1_clk */
--
1.8.1.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 09/11] ARM: OMAP2+: Enable CPUidle in omap2plus_defconfig
Enable CPUidle so it's easier for maintainers to notice if some future code changes cause regressions. Cc: Kevin Hilman khil...@linaro.org Cc: Nishanth Menon n...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Tero Kristo t-kri...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/configs/omap2plus_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 3a0b53d..9da475a 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -21,6 +21,8 @@ CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y CONFIG_ARCH_MULTI_V6=y +CONFIG_POWER_AVS_OMAP=y +CONFIG_POWER_AVS_OMAP_CLASS3=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_ARCH_OMAP2=y @@ -41,6 +43,7 @@ CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 CONFIG_KEXEC=y CONFIG_FPE_NWFPE=y +CONFIG_CPU_IDLE=y CONFIG_BINFMT_MISC=y CONFIG_PM_DEBUG=y CONFIG_NET=y @@ -158,11 +161,14 @@ CONFIG_GPIO_SYSFS=y CONFIG_GPIO_TWL4030=y CONFIG_W1=y CONFIG_POWER_SUPPLY=y +CONFIG_POWER_AVS=y CONFIG_SENSORS_LM75=m CONFIG_THERMAL=y CONFIG_THERMAL_GOV_FAIR_SHARE=y CONFIG_THERMAL_GOV_USER_SPACE=y +CONFIG_CPU_THERMAL=y CONFIG_TI_SOC_THERMAL=y +CONFIG_TI_THERMAL=y CONFIG_OMAP4_THERMAL=y CONFIG_OMAP5_THERMAL=y CONFIG_DRA752_THERMAL=y @@ -175,6 +181,7 @@ CONFIG_MFD_TPS65910=y CONFIG_TWL6040_CORE=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_PALMAS=y +CONFIG_REGULATOR_TI_ABB=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y -- 1.8.1.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 06/11] ARM: OMAP2+: Fix voltage scaling init for device tree
We are currently disabling the init of voltage scaling
for device tree. With the voltage scaling problems fixed
for omap3 in general, there's no need to disable the voltage
scaling init for device tree based booting.
Cc: Kevin Hilman khil...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/pm.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index e1b4141..ccefd11 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -287,25 +287,21 @@ omap_postcore_initcall(omap2_common_pm_init);
int __init omap2_common_pm_late_init(void)
{
- /*
-* In the case of DT, the PMIC and SR initialization will be done using
-* a completely different mechanism.
-* Disable this part if a DT blob is available.
-*/
- if (!of_have_populated_dt()) {
-
- /* Init the voltage layer */
- omap_pmic_late_init();
- omap_voltage_late_init();
+ if (of_have_populated_dt()) {
+ omap3_twl_init();
+ omap4_twl_init();
+ }
- /* Initialize the voltages */
- omap3_init_voltages();
- omap4_init_voltages();
+ /* Init the voltage layer */
+ omap_pmic_late_init();
+ omap_voltage_late_init();
- /* Smartreflex device init */
- omap_devinit_smartreflex();
+ /* Initialize the voltages */
+ omap3_init_voltages();
+ omap4_init_voltages();
- }
+ /* Smartreflex device init */
+ omap_devinit_smartreflex();
/* cpufreq dummy device instantiation */
omap_init_cpufreq();
--
1.8.1.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 11/11] pinctrl: single: Clear pin interrupts enabled by bootloader
Since we set up device wake-up interrupts as pinctrl-single
interrupts, we now must use the standard request_irq and
related functions to manage them.
If the pin interrupts are enabled for some pins at boot,
the wake-up events can show up as constantly pending
at least on omaps and will hang the system unless the related
device driver clears the event at the device.
To fix this, let's clear the interrupt flags during init,
and print out a warning so the board maintainers can update
their drivers to do proper request_irq for the driver specific
wake-up events.
Cc: Haojian Zhuang haojian.zhu...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/pinctrl/pinctrl-single.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index de64596..ba1f4b1 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -808,6 +808,7 @@ static const struct pinconf_ops pcs_pinconf_ops = {
static int pcs_add_pin(struct pcs_device *pcs, unsigned offset,
unsigned pin_pos)
{
+ struct pcs_soc_data *pcs_soc = pcs-socdata;
struct pinctrl_pin_desc *pin;
struct pcs_name *pn;
int i;
@@ -819,6 +820,18 @@ static int pcs_add_pin(struct pcs_device *pcs, unsigned
offset,
return -ENOMEM;
}
+ if (pcs_soc-irq_enable_mask) {
+ unsigned val;
+
+ val = pcs-read(pcs-base + offset);
+ if (val pcs_soc-irq_enable_mask) {
+ dev_dbg(pcs-dev, irq enabled at boot for pin at %lx
(%x), clearing\n,
+ (unsigned long)pcs-res-start + offset, val);
+ val = ~pcs_soc-irq_enable_mask;
+ pcs-write(val, pcs-base + offset);
+ }
+ }
+
pin = pcs-pins.pa[i];
pn = pcs-names[i];
sprintf(pn-name, %lx.%d,
--
1.8.1.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 02/11] ARM: OMAP3: Fix idle mode signaling for sys_clkreq and sys_off_mode
While debugging legacy mode vs device tree booted PM regressions,
I noticed that omap3 is not toggling sys_clkreq and sys_off_mode
pins like it should.
The sys_clkreq and sys_off_mode pins are not toggling because of
the following issues:
1. The default polarity for the sys_off_mode pin is wrong.
OFFMODE_POL needs to be cleared for sys_off_mode to go down when
hitting off-idle, while CLKREQ_POL needs to be set so sys_clkreq
goes down when hitting retention.
2. The values for voltctrl register need to be updated dynamically.
We need to set either the retention idle bits, or off idle bits
in the voltctrl register depending the idle mode we're targeting
to hit.
Let's fix these two issues as otherwise the system will just
hang if any twl4030 PMIC idle scripts are loaded. The only case
where the system does not hang is if only retention idle over I2C4
is configured by the bootloader.
Note that even without the twl4030 PMIC scripts, these fixes will
do the proper signaling of sys_clkreq and sys_off_mode pins, so
the fixes are needed to fix monitoring of PM states with LEDs or
an oscilloscope.
Cc: Kevin Hilman khil...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/pm34xx.c | 2 +
arch/arm/mach-omap2/prm-regbits-34xx.h | 11 -
arch/arm/mach-omap2/vc.c | 75 +-
arch/arm/mach-omap2/vc.h | 2 +
4 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 87099bb..3119ec2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -50,6 +50,7 @@
#include sdrc.h
#include sram.h
#include control.h
+#include vc.h
/* pm34xx errata defined in pm.h */
u16 pm34xx_errata;
@@ -282,6 +283,7 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
+ omap3_vc_set_pmic_signaling(core_next_state);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h
b/arch/arm/mach-omap2/prm-regbits-34xx.h
index cebad56..106132d 100644
--- a/arch/arm/mach-omap2/prm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
@@ -123,8 +123,15 @@
#define OMAP3430_GLOBAL_SW_RST_SHIFT 1
#define OMAP3430_GLOBAL_COLD_RST_SHIFT 0
#define OMAP3430_GLOBAL_COLD_RST_MASK (1 0)
-#define OMAP3430_SEL_OFF_MASK (1 3)
-#define OMAP3430_AUTO_OFF_MASK (1 2)
+#define OMAP3430_PRM_VOLTCTRL_SEL_VMODE(1 4)
+#define OMAP3430_PRM_VOLTCTRL_SEL_OFF (1 3)
+#define OMAP3430_PRM_VOLTCTRL_AUTO_OFF (1 2)
+#define OMAP3430_PRM_VOLTCTRL_AUTO_RET (1 1)
+#define OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP (1 0)
#define OMAP3430_SETUP_TIME2_MASK (0x 16)
#define OMAP3430_SETUP_TIME1_MASK (0x 0)
+#define OMAP3430_PRM_POLCTRL_OFFMODE_POL (1 3)
+#define OMAP3430_PRM_POLCTRL_CLKOUT_POL(1 2)
+#define OMAP3430_PRM_POLCTRL_CLKREQ_POL(1 1)
+#define OMAP3430_PRM_POLCTRL_EXTVOL_POL(1 0)
#endif
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 49ac797..3d5ba5d 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -220,6 +220,78 @@ static inline u32 omap_usec_to_32k(u32 usec)
return DIV_ROUND_UP_ULL(32768ULL * (u64)usec, 100ULL);
}
+void omap3_vc_set_pmic_signaling(int core_next_state)
+{
+ u32 voltctrl;
+
+ voltctrl = omap2_prm_read_mod_reg(OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTCTRL_OFFSET);
+ switch (core_next_state) {
+ case PWRDM_POWER_OFF:
+ voltctrl = ~(OMAP3430_PRM_VOLTCTRL_AUTO_RET |
+ OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP);
+ voltctrl |= OMAP3430_PRM_VOLTCTRL_AUTO_OFF;
+ break;
+ case PWRDM_POWER_RET:
+ voltctrl = ~(OMAP3430_PRM_VOLTCTRL_AUTO_OFF |
+ OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP);
+ voltctrl |= OMAP3430_PRM_VOLTCTRL_AUTO_RET;
+ break;
+ default:
+ voltctrl = ~(OMAP3430_PRM_VOLTCTRL_AUTO_OFF |
+ OMAP3430_PRM_VOLTCTRL_AUTO_RET);
+ voltctrl |= OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP;
+ break;
+ }
+ omap2_prm_write_mod_reg(voltctrl, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTCTRL_OFFSET);
+}
+
+/*
+ * Configure signal polarity for sys_clkreq and sys_off_mode pins
+ * as the default
[PATCH 04/11] ARM: OMAP3: Fix voltage control for deeper idle states
Currently we're attempting to use a static value for the
voltctrl register that only works for controlling the PMIC
over I2C4. For using sys_off_mode signaling, we need to update
update clksetup, voltsetup1, voltsetup2 and voltctrl registers
dynamically depending on the idle state.
So let's fix this by configuring things for I2C4 controlled idle
and sys_off_mode pin controlled idle, and then write the
configured register values depending on the idle state. This
is similar what N900 kernel is doing too.
Cc: Kevin Hilman khil...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/vc.c | 99 +++-
1 file changed, 73 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index dee4cee..63662e1 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -220,8 +220,18 @@ static inline u32 omap_usec_to_32k(u32 usec)
return DIV_ROUND_UP_ULL(32768ULL * (u64)usec, 100ULL);
}
+struct omap3_vc_config {
+ u32 clksetup;
+ u32 voltsetup1;
+ u32 voltsetup2;
+ u32 voltctrl;
+};
+
+static struct omap3_vc_config omap3_vc_timings[2];
+
void omap3_vc_set_pmic_signaling(int core_next_state)
{
+ struct omap3_vc_config *c = omap3_vc_timings;
u32 voltctrl;
voltctrl = omap2_prm_read_mod_reg(OMAP3430_GR_MOD,
@@ -231,11 +241,20 @@ void omap3_vc_set_pmic_signaling(int core_next_state)
voltctrl = ~(OMAP3430_PRM_VOLTCTRL_AUTO_RET |
OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP);
voltctrl |= OMAP3430_PRM_VOLTCTRL_AUTO_OFF;
+ if (voltctrl OMAP3430_PRM_VOLTCTRL_SEL_OFF)
+ omap2_prm_write_mod_reg(c-voltsetup2, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP2_OFFSET);
+ else
+ omap2_prm_write_mod_reg(c-voltsetup1, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP1_OFFSET);
break;
case PWRDM_POWER_RET:
+ c++;
voltctrl = ~(OMAP3430_PRM_VOLTCTRL_AUTO_OFF |
OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP);
voltctrl |= OMAP3430_PRM_VOLTCTRL_AUTO_RET;
+ omap2_prm_write_mod_reg(c-voltsetup1, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP1_OFFSET);
break;
default:
voltctrl = ~(OMAP3430_PRM_VOLTCTRL_AUTO_OFF |
@@ -292,6 +311,18 @@ static void __init omap3_vc_init_pmic_signaling(void)
omap3_vc_set_pmic_signaling(PWRDM_POWER_ON);
}
+static void omap3_init_voltsetup1(struct voltagedomain *voltdm,
+ struct omap3_vc_config *c, u32 idle)
+{
+ unsigned long val;
+
+ val = (voltdm-vc_param-on - idle) / voltdm-pmic-slew_rate;
+ val *= voltdm-sys_clk.rate / 8 / 100 + 1;
+ val = __ffs(voltdm-vfsm-voltsetup_mask);
+ c-voltsetup1 = ~voltdm-vfsm-voltsetup_mask;
+ c-voltsetup1 |= val;
+}
+
/**
* omap3_set_i2c_timings - sets i2c sleep timings for a channel
* @voltdm: channel to configure
@@ -302,31 +333,21 @@ static void __init omap3_vc_init_pmic_signaling(void)
* or retention. Off mode has additionally an option to use sys_off_mode
* pad, which uses a global signal to program the whole power IC to
* off-mode.
+ *
+ * Note that pmic is not controlling the voltage scaling during
+ * retention signaled over I2C4, so we can keep voltsetup2 as 0.
+ * And the oscillator is not shut off over I2C4, so no need to
+ * set clksetup.
*/
-static void omap3_set_i2c_timings(struct voltagedomain *voltdm, bool off_mode)
+static void omap3_set_i2c_timings(struct voltagedomain *voltdm)
{
- unsigned long voltsetup1;
- u32 tgt_volt;
-
- if (off_mode)
- tgt_volt = voltdm-vc_param-off;
- else
- tgt_volt = voltdm-vc_param-ret;
-
- voltsetup1 = (voltdm-vc_param-on - tgt_volt) /
- voltdm-pmic-slew_rate;
-
- voltsetup1 = voltsetup1 * voltdm-sys_clk.rate / 8 / 100 + 1;
+ struct omap3_vc_config *c = omap3_vc_timings;
- voltdm-rmw(voltdm-vfsm-voltsetup_mask,
- voltsetup1 __ffs(voltdm-vfsm-voltsetup_mask),
- voltdm-vfsm-voltsetup_reg);
-
- /*
-* pmic is not controlling the voltage scaling during retention,
-* thus set voltsetup2 to 0
-*/
- voltdm-write(0, OMAP3_PRM_VOLTSETUP2_OFFSET);
+ /* Configure PRWDM_POWER_OFF over I2C4 */
+ omap3_init_voltsetup1(voltdm, c, voltdm-vc_param-off);
+ c++;
+ /* Configure PRWDM_POWER_RET over I2C4 */
+ omap3_init_voltsetup1(voltdm, c, voltdm-vc_param-ret);
}
/**
@@ -335,22 +356,48 @@ static void omap3_set_i2c_timings(struct
[PATCH 00/11] Fixes for omap PM for making omap3 DT only
Hi all, As we're planning to make omap3 device tree only soon, I was poking around and noticed that PM is not working properly. As we're planning to drop about 20k lines of code, I just had to try to fix this so we know what is going on and don't have to go back. I was pretty bummed out to find that we've had non-working PM code in mainline for really long time. Anyways, I got the voltage scaling and N900 debug leds working, so with those we can notice any future regressions immediately :) These are against v3.14, then you might want to also apply the following two patches: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts https://lkml.org/lkml/2014/4/10/620 [PATCH] serial: omap: Fix missing pm_runtime_resume handling by simplifying code http://www.spinics.net/lists/linux-omap/msg104782.html Note that for the actual voltage scaling to happen, the twl4030 PMIC scripts are also needed. I have some uncleaned patches to load those based on the compatible flag, will post those separately. This series alone fixes the idle state signaling to the PMIC, so we can monitor sys_clkreq and sys_off_idle pins properly. Please review, comment and test, Tony Tero Kristo (1): ARM: OMAP3: PM: remove access to PRM_VOLTCTRL register Tony Lindgren (10): ARM: OMAP3: Fix idle mode signaling for sys_clkreq and sys_off_mode ARM: OMAP3: Disable broken omap3_set_off_timings function ARM: OMAP3: Fix voltage control for deeper idle states ARM: dts: Configure omap3 twl4030 I2C4 pins by default ARM: OMAP2+: Fix voltage scaling init for device tree ARM: dts: Enable N900 keybaord sleep leds by default ARM: dts: Fix omap serial wake-up when booted with device tree ARM: OMAP2+: Enable CPUidle in omap2plus_defconfig mfd: twl-core: Fix idle mode signaling for omaps when booted with device tree pinctrl: single: Clear pin interrupts enabled by bootloader arch/arm/boot/dts/omap3-evm-37xx.dts | 9 ++ arch/arm/boot/dts/omap3-n900.dts | 19 +++ arch/arm/boot/dts/omap3.dtsi | 6 +- arch/arm/boot/dts/omap4-panda-common.dtsi | 15 +++ arch/arm/boot/dts/omap4-sdp.dts | 6 + arch/arm/boot/dts/omap4.dtsi | 6 +- arch/arm/boot/dts/twl4030_omap3.dtsi | 19 ++- arch/arm/configs/omap2plus_defconfig | 7 + arch/arm/mach-omap2/omap_twl.c| 60 - arch/arm/mach-omap2/pm.c | 28 ++-- arch/arm/mach-omap2/pm34xx.c | 6 +- arch/arm/mach-omap2/prm-regbits-34xx.h| 11 +- arch/arm/mach-omap2/vc.c | 212 +++--- arch/arm/mach-omap2/vc.h | 2 + drivers/mfd/twl-core.c| 15 +++ drivers/pinctrl/pinctrl-single.c | 13 ++ include/dt-bindings/pinctrl/omap.h| 12 ++ 17 files changed, 281 insertions(+), 165 deletions(-) -- 1.8.1.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 10/11] mfd: twl-core: Fix idle mode signaling for omaps when booted with device tree
I noticed a regression where the omap sys_clkreq signal will never
trigger for omap3 when booted with device tree while it triggers
when booted in legacy mode. This means voltage scaling does not
do anything when booted with device tree.
Turns out the reason is we fail to initialize the SmartReflex
enable bit in twl4030 with the following error:
twl: not initialized
And that happens because we are wrongly tinkering with the twl4030
registers in arch/arm/mach-omap2/omap_twl.c before the driver is
initialized. Looking at the the SmartReflex bit enable code in
omap_twl.c, we need to always set it.
So let's fix the issue by always enabling the twl4030 SmartReflex
bit in the drivers/mfd/twl-core.c probe, and drop the related
code in omap_twl.c.
Note that we still have some twl4030 tinkering left in omap_twl.c
for the twl6030 case, but that's a different patch.
Cc: Kevin Hilman khil...@linaro.org
Cc: Lee Jones lee.jo...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_twl.c | 60 --
drivers/mfd/twl-core.c | 15 +++
2 files changed, 15 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 615e5b1..6bf6267 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -46,15 +46,8 @@
static bool is_offset_valid;
static u8 smps_offset;
-/*
- * Flag to ensure Smartreflex bit in TWL
- * being cleared in board file is not overwritten.
- */
-static bool __initdata twl_sr_enable_autoinit;
-#define TWL4030_DCDC_GLOBAL_CFG0x06
#define REG_SMPS_OFFSET 0xE0
-#define SMARTREFLEX_ENABLE BIT(3)
static unsigned long twl4030_vsel_to_uv(const u8 vsel)
{
@@ -251,18 +244,6 @@ int __init omap3_twl_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
- /*
-* The smartreflex bit on twl4030 specifies if the setting of voltage
-* is done over the I2C_SR path. Since this setting is independent of
-* the actual usage of smartreflex AVS module, we enable TWL SR bit
-* by default irrespective of whether smartreflex AVS module is enabled
-* on the OMAP side or not. This is because without this bit enabled,
-* the voltage scaling through vp forceupdate/bypass mechanism of
-* voltage scaling will not function on TWL over I2C_SR.
-*/
- if (!twl_sr_enable_autoinit)
- omap3_twl_set_sr_bit(true);
-
voltdm = voltdm_lookup(mpu_iva);
omap_voltage_register_pmic(voltdm, omap3_mpu_pmic);
@@ -271,44 +252,3 @@ int __init omap3_twl_init(void)
return 0;
}
-
-/**
- * omap3_twl_set_sr_bit() - Set/Clear SR bit on TWL
- * @enable: enable SR mode in twl or not
- *
- * If 'enable' is true, enables Smartreflex bit on TWL 4030 to make sure
- * voltage scaling through OMAP SR works. Else, the smartreflex bit
- * on twl4030 is cleared as there are platforms which use OMAP3 and T2 but
- * use Synchronized Scaling Hardware Strategy (ENABLE_VMODE=1) and Direct
- * Strategy Software Scaling Mode (ENABLE_VMODE=0), for setting the voltages,
- * in those scenarios this bit is to be cleared (enable = false).
- *
- * Returns 0 on success, error is returned if I2C read/write fails.
- */
-int __init omap3_twl_set_sr_bit(bool enable)
-{
- u8 temp;
- int ret;
- if (twl_sr_enable_autoinit)
- pr_warning(%s: unexpected multiple calls\n, __func__);
-
- ret = twl_i2c_read_u8(TWL_MODULE_PM_RECEIVER, temp,
- TWL4030_DCDC_GLOBAL_CFG);
- if (ret)
- goto err;
-
- if (enable)
- temp |= SMARTREFLEX_ENABLE;
- else
- temp = ~SMARTREFLEX_ENABLE;
-
- ret = twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, temp,
- TWL4030_DCDC_GLOBAL_CFG);
- if (!ret) {
- twl_sr_enable_autoinit = true;
- return 0;
- }
-err:
- pr_err(%s: Error access to TWL4030 (%d)\n, __func__, ret);
- return ret;
-}
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index ed71832..ad7d04f 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -98,7 +98,11 @@
#define TWL4030_BASEADD_BACKUP 0x0014
#define TWL4030_BASEADD_INT0x002E
#define TWL4030_BASEADD_PM_MASTER 0x0036
+
#define TWL4030_BASEADD_PM_RECEIVER0x005B
+#define TWL4030_DCDC_GLOBAL_CFG0x06
+#define SMARTREFLEX_ENABLE BIT(3)
+
#define TWL4030_BASEADD_RTC0x001C
#define TWL4030_BASEADD_SECURED_REG0x
@@ -1204,6 +1208,11 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
* Disable TWL4030/TWL5030 I2C Pull-up on I2C1 and I2C4(SR) interface.
*
[PATCH 01/11] ARM: OMAP3: PM: remove access to PRM_VOLTCTRL register
From: Tero Kristo t-kri...@ti.com There is a solitary write to this register every wakeup from off-mode, which isn't doing anything, so remove it. Also note that modifying this register trashes any attempted voltage scaling configuration and the change probably should never have gotten merged in the first place. Cc: Nishanth Menon n...@ti.com Cc: Kevin Hilman khil...@linaro.org Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Tero Kristo t-kri...@ti.com [t...@atomide.com: updated comments to describe regression] Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/pm34xx.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 1f3770a..87099bb 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -330,10 +330,6 @@ void omap_sram_idle(void) omap3_sram_restore_context(); omap2_sms_restore_context(); } - if (core_next_state == PWRDM_POWER_OFF) - omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK, - OMAP3430_GR_MOD, - OMAP3_PRM_VOLTCTRL_OFFSET); } omap3_intc_resume_idle(); -- 1.8.1.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 08/11] ARM: dts: Fix omap serial wake-up when booted with device tree
We've had deeper idle states working on omaps for few years now,
but only in the legacy mode. When booted with device tree, the
wake-up events did not have a chance to work until commit
3e6cee1786a1 (pinctrl: single: Add support for wake-up interrupts)
that recently got merged. In addition to that we also needed commit
79d9701559a9 (of/irq: create interrupts-extended property) that's
now also merged.
So let's fix the wake-up events for some selected omaps so devices
booted in device tree mode won't just hang if deeper power states
are enabled, and so systems can wake up from suspend to the serial
port event.
Note that there's no longer need to specify the wake-up bit in
the pinctrl settings, the request_irq on the wake-up pin takes
care of that.
Note that there will be new harmless warnings in dmesg output
without patch of/platform: Fix no irq domain found errors when
populating interrupts:
https://lkml.org/lkml/2014/4/10/620
Cc: devicet...@vger.kernel.org
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3-evm-37xx.dts | 9 +
arch/arm/boot/dts/omap3-n900.dts | 2 ++
arch/arm/boot/dts/omap3.dtsi | 6 +++---
arch/arm/boot/dts/omap4-panda-common.dtsi | 15 +++
arch/arm/boot/dts/omap4-sdp.dts | 6 ++
arch/arm/boot/dts/omap4.dtsi | 6 +++---
include/dt-bindings/pinctrl/omap.h| 12
7 files changed, 50 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts
b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 4df68ad..9cba94b 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -89,7 +89,16 @@
status = disabled;
};
+uart1 {
+ interrupts-extended = intc 72 omap3_pmx_core OMAP3_UART1_RX;
+};
+
+uart2 {
+ interrupts-extended = intc 73 omap3_pmx_core OMAP3_UART2_RX;
+};
+
uart3 {
+ interrupts-extended = intc 74 omap3_pmx_core OMAP3_UART3_RX;
pinctrl-names = default;
pinctrl-0 = uart3_pins;
};
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 0d34201..c5db0af 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -512,11 +512,13 @@
};
uart2 {
+ interrupts-extended = intc 73 omap3_pmx_core OMAP3_UART2_RX;
pinctrl-names = default;
pinctrl-0 = uart2_pins;
};
uart3 {
+ interrupts-extended = intc 74 omap3_pmx_core OMAP3_UART3_RX;
pinctrl-names = default;
pinctrl-0 = uart3_pins;
};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..f61c76b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -246,7 +246,7 @@
uart1: serial@4806a000 {
compatible = ti,omap3-uart;
reg = 0x4806a000 0x2000;
- interrupts = 72;
+ interrupts-extended = intc 72;
dmas = sdma 49 sdma 50;
dma-names = tx, rx;
ti,hwmods = uart1;
@@ -256,7 +256,7 @@
uart2: serial@4806c000 {
compatible = ti,omap3-uart;
reg = 0x4806c000 0x400;
- interrupts = 73;
+ interrupts-extended = intc 73;
dmas = sdma 51 sdma 52;
dma-names = tx, rx;
ti,hwmods = uart2;
@@ -266,7 +266,7 @@
uart3: serial@4902 {
compatible = ti,omap3-uart;
reg = 0x4902 0x400;
- interrupts = 74;
+ interrupts-extended = intc 74;
dmas = sdma 53 sdma 54;
dma-names = tx, rx;
ti,hwmods = uart3;
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..47bbc59 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -396,6 +396,21 @@
usb-supply = vusb;
};
+uart2 {
+ interrupts-extended = gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH
+ omap4_pmx_core OMAP4_UART2_RX;
+};
+
+uart3 {
+ interrupts-extended = gic GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH
+ omap4_pmx_core OMAP4_UART3_RX;
+};
+
+uart4 {
+ interrupts-extended = gic GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH
+ omap4_pmx_core OMAP4_UART4_RX;
+};
+
usb_otg_hs {
interface-type = 1;
mode = 3;
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index dbc81fb..e3f3cfb 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
[PATCH 05/11] ARM: dts: Configure omap3 twl4030 I2C4 pins by default
Almost certainly any sane board has the twl4030 has the I2C4
pins connected as those are needed for voltage control during
idle. If the I2C4 lines are not properly muxed, any voltage
scaling over I2C4 will fail.
Let's mux those pins by default, the boards that are not using
them can still configure things separately.
Cc: Kevin Hilman khil...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/twl4030_omap3.dtsi | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/twl4030_omap3.dtsi
b/arch/arm/boot/dts/twl4030_omap3.dtsi
index c353ef0..3537ae5 100644
--- a/arch/arm/boot/dts/twl4030_omap3.dtsi
+++ b/arch/arm/boot/dts/twl4030_omap3.dtsi
@@ -8,7 +8,7 @@
twl {
pinctrl-names = default;
- pinctrl-0 = twl4030_pins;
+ pinctrl-0 = twl4030_pins twl4030_vpins;
};
omap3_pmx_core {
@@ -23,3 +23,20 @@
;
};
};
+
+/*
+ * If your board is not using the I2C4 pins with twl4030, then don't include
+ * this file. For proper idle mode signaling with sys_clkreq and sys_off_mode
+ * pins we need to configure I2C4, or else use the legacy sys_nvmode1 and
+ * sys_nvmode2 signaling.
+ */
+omap3_pmx_wkup {
+ twl4030_vpins: pinmux_twl4030_vpins {
+ pinctrl-single,pins =
+ OMAP3_WKUP_IOPAD(0x2a00, PIN_INPUT | MUX_MODE0)
/* i2c4_scl.i2c4_scl */
+ OMAP3_WKUP_IOPAD(0x2a02, PIN_INPUT | MUX_MODE0)
/* i2c4_sda.i2c4_sda */
+ OMAP3_WKUP_IOPAD(0x2a06, PIN_OUTPUT | MUX_MODE0)
/* sys_clkreq.sys_clkreq */
+ OMAP3_WKUP_IOPAD(0x2a18, PIN_OUTPUT | MUX_MODE0)
/* sys_off_mode.sys_off_mode */
+ ;
+ };
+};
--
1.8.1.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 03/11] ARM: OMAP3: Disable broken omap3_set_off_timings function
Commit c589eb3869a8 (ARM: OMAP3: VC: calculate ramp times)
started using regulator slew rates for calculating the idle
mode start-up times. This works fine for I2C4 controlled
regulator scaling as the regulators are never completely
turned off.
For sys_off_mode pin controlled PMIC scripts, the slew rate
based calculations won't work at all as the regulators are
completely turned off and the start-up time is much longer.
This means currently omap3_set_off_timings currently has
zero chance of working on any real hardare. The current code
is broken in at least the following ways:
1. It attempts to use the default ULONG_MAX value for the
oscillator start-up value as we're currently never
initializing the start-up value.
2. It relies on a magic number potentially set by the
bootloader for volsetup2 register.
3. If no magic value is passed, it attempts to calculate
voltsetup2 register based on the regulator slew rate.
This won't work as there is roughly at least five
times the delay needed for turning on vdd1 and vdd2
regulators.
4. It does duplicate register write to OMAP3_PRM_VOLTOFFSET
5. It duplicates the code for omap_usec_to_32k unnecessarily
6. It initialized global registers twice, once for each channel
Let's just remove the broken code and call omap3_set_i2c_timings
directly, we're better off with this function doing nothing until
it's fixed. And otherwise further fixes to omap3_set_off_timings
will be unreadable.
And let's get rid of omap3_set_clksetup as that's not needed
for off-idle controlled by I2C4 as in that case the oscillator
is never shut down.
Cc: Kevin Hilman khil...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/vc.c | 62 +---
1 file changed, 1 insertion(+), 61 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 3d5ba5d..dee4cee 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -292,12 +292,6 @@ static void __init omap3_vc_init_pmic_signaling(void)
omap3_vc_set_pmic_signaling(PWRDM_POWER_ON);
}
-/* Set oscillator setup time for omap3 */
-static void omap3_set_clksetup(u32 usec, struct voltagedomain *voltdm)
-{
- voltdm-write(omap_usec_to_32k(usec), OMAP3_PRM_CLKSETUP_OFFSET);
-}
-
/**
* omap3_set_i2c_timings - sets i2c sleep timings for a channel
* @voltdm: channel to configure
@@ -314,12 +308,6 @@ static void omap3_set_i2c_timings(struct voltagedomain
*voltdm, bool off_mode)
unsigned long voltsetup1;
u32 tgt_volt;
- /*
-* Oscillator is shut down only if we are using sys_off_mode pad,
-* thus we set a minimal setup time here
-*/
- omap3_set_clksetup(1, voltdm);
-
if (off_mode)
tgt_volt = voltdm-vc_param-off;
else
@@ -356,61 +344,13 @@ static void omap3_set_i2c_timings(struct voltagedomain
*voltdm, bool off_mode)
*/
static void omap3_set_off_timings(struct voltagedomain *voltdm)
{
- unsigned long clksetup;
- unsigned long voltsetup2;
- unsigned long voltsetup2_old;
- u32 val;
- u32 tstart, tshut;
-
- /* check if sys_off_mode is used to control off-mode voltages */
- val = voltdm-read(OMAP3_PRM_VOLTCTRL_OFFSET);
- if (!(val OMAP3430_PRM_VOLTCTRL_SEL_OFF)) {
- /* No, omap is controlling them over I2C */
- omap3_set_i2c_timings(voltdm, true);
- return;
- }
-
- omap_pm_get_oscillator(tstart, tshut);
- omap3_set_clksetup(tstart, voltdm);
-
- clksetup = voltdm-read(OMAP3_PRM_CLKSETUP_OFFSET);
-
- /* voltsetup 2 in us */
- voltsetup2 = voltdm-vc_param-on / voltdm-pmic-slew_rate;
-
- /* convert to 32k clk cycles */
- voltsetup2 = DIV_ROUND_UP(voltsetup2 * 32768, 100);
-
- voltsetup2_old = voltdm-read(OMAP3_PRM_VOLTSETUP2_OFFSET);
-
- /*
-* Update voltsetup2 if higher than current value (needed because
-* we have multiple channels with different ramp times), also
-* update voltoffset always to value recommended by TRM
-*/
- if (voltsetup2 voltsetup2_old) {
- voltdm-write(voltsetup2, OMAP3_PRM_VOLTSETUP2_OFFSET);
- voltdm-write(clksetup - voltsetup2,
- OMAP3_PRM_VOLTOFFSET_OFFSET);
- } else
- voltdm-write(clksetup - voltsetup2_old,
- OMAP3_PRM_VOLTOFFSET_OFFSET);
-
- /*
-* omap is not controlling voltage scaling during off-mode,
-* thus set voltsetup1 to 0
-*/
- voltdm-rmw(voltdm-vfsm-voltsetup_mask, 0,
- voltdm-vfsm-voltsetup_reg);
-
- /* voltoffset must be clksetup minus voltsetup2 according to TRM */
- voltdm-write(clksetup - voltsetup2, OMAP3_PRM_VOLTOFFSET_OFFSET);
}
static void
Re: [PATCH 07/11] ARM: dts: Enable N900 keybaord sleep leds by default
* Tony Lindgren t...@atomide.com [140410 16:52]:
On N900 there are nice LEDs that show the state of the
sys_clkreq and sys_off_mode pins.
Here's a work in progress related twl4030 script for N900
to play with, I think it can be made more generic though.
This scales vdd_core to zero during off idle for me with
this series.
Regards,
Tony
8
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index 8e15ec3..35b2b5f 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -5,7 +5,9 @@ to control the power resources, including power scripts. For
now, the
binding only supports the complete shutdown of the system after poweroff.
Required properties:
-- compatible : must be ti,twl4030-power
+- compatible : Needs to be one of the following
+ ti,twl4030-power-n900
+ ti,twl4030-power
Optional properties:
- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index c5db0af..3ac2b2d 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -269,6 +269,11 @@
compatible = ti,twl4030-audio;
ti,enable-vibra = 1;
};
+
+ twl_power: power {
+ compatible = ti,twl4030-power-n900;
+ ti,use_poweroff;
+ };
};
twl_gpio {
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 96162b6..d6b05eb 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -29,6 +29,7 @@
#include linux/i2c/twl.h
#include linux/platform_device.h
#include linux/of.h
+#include linux/of_device.h
#include asm/mach-types.h
@@ -493,7 +494,8 @@ int twl4030_remove_script(u8 flags)
return err;
}
-static int twl4030_power_configure_scripts(struct twl4030_power_data *pdata)
+static int
+twl4030_power_configure_scripts(const struct twl4030_power_data *pdata)
{
int err;
int i;
@@ -509,7 +511,8 @@ static int twl4030_power_configure_scripts(struct
twl4030_power_data *pdata)
return 0;
}
-static int twl4030_power_configure_resources(struct twl4030_power_data *pdata)
+static int
+twl4030_power_configure_resources(const struct twl4030_power_data *pdata)
{
struct twl4030_resconfig *resconfig = pdata-resource_config;
int err;
@@ -541,7 +544,7 @@ void twl4030_power_off(void)
pr_err(TWL4030 Unable to power off\n);
}
-static bool twl4030_power_use_poweroff(struct twl4030_power_data *pdata,
+static bool twl4030_power_use_poweroff(const struct twl4030_power_data *pdata,
struct device_node *node)
{
if (pdata pdata-use_poweroff)
@@ -553,10 +556,227 @@ static bool twl4030_power_use_poweroff(struct
twl4030_power_data *pdata,
return false;
}
+#ifdef CONFIG_OF
+
+/* Generic warm reset configuration for omap3 */
+
+static struct twl4030_ins omap3_wrst_seq[] = {
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script omap3_wrst_script = {
+ .script = omap3_wrst_seq,
+ .size = ARRAY_SIZE(omap3_wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *omap3_reset_scripts[] = {
+ omap3_wrst_script,
+};
+
+static struct twl4030_resconfig omap3_rconfig[] = {
+ { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { 0, 0},
+};
+
+static struct twl4030_power_data omap3_reset = {
+ .scripts= omap3_reset_scripts,
+ .num= ARRAY_SIZE(omap3_reset_scripts),
+ .resource_config= omap3_rconfig,
+};
+
+/* Configuration for Nokia N900 */
+
+static struct twl4030_ins n900_sleep_on_seq[] = {
+/*
+ * Turn off everything
+ */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, 1, 0, RES_STATE_SLEEP), 2},
+};
+
+static struct twl4030_script n900_sleep_on_script = {
+ .script = n900_sleep_on_seq,
+ .size = ARRAY_SIZE(n900_sleep_on_seq),
+ .flags = TWL4030_SLEEP_SCRIPT,
+};
+
+static struct twl4030_ins n900_wakeup_seq[] = {
+/*
+ * Reenable everything
+ */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, 1, 0, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script n900_wakeup_script = {
+
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Thursday 10 April 2014 07:10 PM, Russell King - ARM Linux wrote:
On Thu, Apr 10, 2014 at 06:57:05PM +0530, Sekhar Nori wrote:
On Thursday 10 April 2014 05:46 PM, Sekhar Nori wrote:
This will work. NS_LOCKDOWN is required for L2C-220 as well and so I was
thinking about adding a new l2c220_enable() which will set the
NS_LOCKDOWN and then call l2c_enable()
Here is a patch for what I was saying above.
diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h
b/arch/arm/include/asm/hardware/cache-l2x0.h
index c47ac8f..dc9e03b 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -105,6 +105,8 @@
#define L2X0_AUX_CTRL_DIRTY_LATENCY_MASK(7 9)
#define L2X0_AUX_CTRL_ASSOC_SHIFT 13
#define L2X0_AUX_CTRL_ASSOC_MASK(15 13)
+/* L2C-220/310 common bits */
+#define L2C_AUX_CTRL_NS_LOCKDOWNBIT(26)
/* L2C-210 specific bits */
#define L210_AUX_CTRL_WRAP_DISABLE BIT(12)
#define L210_AUX_CTRL_WA_OVERRIDE BIT(23)
@@ -113,7 +115,6 @@
#define L220_AUX_CTRL_EXCLUSIVE_CACHE BIT(12)
#define L220_AUX_CTRL_FWA_SHIFT 23
#define L220_AUX_CTRL_FWA_MASK (3 23)
-#define L220_AUX_CTRL_NS_LOCKDOWN BIT(26)
#define L220_AUX_CTRL_NS_INT_CTRL BIT(27)
/* L2C-310 specific bits */
#define L310_AUX_CTRL_FULL_LINE_ZEROBIT(0) /* R2P0+ */
@@ -122,7 +123,6 @@
#define L310_AUX_CTRL_EXCLUSIVE_CACHE BIT(12)
#define L310_AUX_CTRL_ASSOCIATIVITY_16 BIT(16)
#define L310_AUX_CTRL_CACHE_REPLACE_RR BIT(25) /* R2P0+ */
-#define L310_AUX_CTRL_NS_LOCKDOWN BIT(26)
NAK. The reason for this split is because the NS lockdown bit is *not*
on L2C-210, and so it does not deserve to be a common bit - because it
isn't common to all variants.
Okay.
@@ -764,7 +776,7 @@ static void __init l2c310_enable(void __iomem *base, u32
aux, unsigned num_lock)
power_ctrl L310_STNDBY_MODE_EN ? en : dis);
}
-l2c_enable(base, aux, num_lock);
+l2c220_enable(base, aux, num_lock);
My first reaction to this is to say NAK again - I don't want to create
a multi-layered maze of X calls Y calls Z. Who's to say that The 220
won't need to do something different from 310 in the future?
Here is a revised patch which is just an extension of your patch
with L2C-220 case handled. I dont really have L2C-220 hardware so even
if you want to handle that at a later time, it would be perfectly okay
with me.
Thanks,
Sekhar
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 6b2a056..34cafe0 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -216,8 +216,6 @@ int __init omap4_l2_cache_init(void)
{
/* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */
u32 aux_ctrl = L310_AUX_CTRL_CACHE_REPLACE_RR |
- L310_AUX_CTRL_NS_LOCKDOWN |
- L310_AUX_CTRL_NS_INT_CTRL |
L2C_AUX_CTRL_SHARED_OVERRIDE |
L310_AUX_CTRL_DATA_PREFETCH |
L310_AUX_CTRL_INSTR_PREFETCH;
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index b1f103d..72f41fa 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -498,11 +498,23 @@ static void l2c220_sync(void)
raw_spin_unlock_irqrestore(l2x0_lock, flags);
}
+static void __init l2c220_enable(void __iomem *base, u32 aux, unsigned
num_lock)
+{
+ /*
+* Always enable non-secure access to the lockdown registers -
+* we write to them as part of the L2C enable sequence so they
+* need to be accessible.
+*/
+ aux |= L220_AUX_CTRL_NS_LOCKDOWN;
+
+ l2c_enable(base, aux, num_lock);
+}
+
static const struct l2c_init_data l2c220_data = {
.type = L2C-220,
.way_size_0 = SZ_8K,
.num_lock = 1,
- .enable = l2c_enable,
+ .enable = l2c220_enable,
.outer_cache = {
.inv_range = l2c220_inv_range,
.clean_range = l2c220_clean_range,
@@ -764,6 +776,13 @@ static void __init l2c310_enable(void __iomem *base, u32
aux, unsigned num_lock)
power_ctrl L310_STNDBY_MODE_EN ? en : dis);
}
+ /*
+* Always enable non-secure access to the lockdown registers -
+* we write to them as part of the L2C enable sequence so they
+* need to be accessible.
+*/
+ aux |= L310_AUX_CTRL_NS_LOCKDOWN;
+
l2c_enable(base, aux, num_lock);
if (aux L310_AUX_CTRL_FULL_LINE_ZERO) {
@@ -1027,7 +1046,7 @@ static const struct l2c_init_data of_l2c220_data
__initconst = {
.way_size_0 = SZ_8K,
.num_lock = 1,
.of_parse = l2x0_of_parse,
- .enable = l2c_enable,
+ .enable =
