Re: [PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support
Hi, On Sat, Oct 27, 2012 at 05:57:48PM +0530, kishon wrote: Hi, On Saturday 27 October 2012 01:29 AM, Felipe Balbi wrote: Hi, On Fri, Oct 26, 2012 at 10:16:55AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [121025 23:55]: On Thu, Oct 25, 2012 at 10:44:47AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [121024 23:24]: Hi, On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [121016 09:53]: * Kishon Vijay Abraham I kis...@ti.com [121007 23:01]: ocp2scp was not having pdata support which makes *musb* fail for non-dt boot in OMAP platform. The pdata will have information about the devices that is connected to ocp2scp. ocp2scp driver will now make use of this information to create the devices that is attached to ocp2scp. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com This fixes the regression on my panda es for musb port: Acked-by: Tony Lindgren t...@atomide.com Looks like nobody has picked this one up and we need it to fix the musb regression on omap, so I'll queue these up. I don't seem to have the patches around in any mailbox :-( Bounced them to you. Do you have any better ideas for the -rc cycle to fix the MUSB regression on omap4? Well, there are two regressions that I know of. One is caused by the mode1 DMA changes, which I'll just revert, and the other is the missing platform_data support on the new PHY driver which these patches are supposed to solve, right ? Yes that's it AFAIK. Kishon, any other patches I need to take to get MUSB working on v3.7 ? These should be good enough to get MUSB working.. nothing needed for omap-usb2.c ? That's great, cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] Add FDT support to Pandaboard initialization
On Sat, Oct 27, 2012 at 08:50:00PM +0200, Constantine Shulyupin wrote: From: Constantine Shulyupin co...@makelinux.com Problem: - FDT is supported only by generic OMAP board initialization in arch/arm/mach-omap2/board-generic.c and lacks some configurations, which are not yet configured in FDT (USB for example). Solution: - arch/arm/mach-omap2/board-omap4panda.c supports initialization with FDT and without it. Signed-off-by: Constantine Shulyupin co...@makelinux.com NAK, the whole idea of DT is to drop board-*.c. It would be best to see the missing initialization being added to board-generic/dts files. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support
Hi, On Monday 29 October 2012 11:40 AM, Felipe Balbi wrote: Hi, On Sat, Oct 27, 2012 at 05:57:48PM +0530, kishon wrote: Hi, On Saturday 27 October 2012 01:29 AM, Felipe Balbi wrote: Hi, On Fri, Oct 26, 2012 at 10:16:55AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [121025 23:55]: On Thu, Oct 25, 2012 at 10:44:47AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [121024 23:24]: Hi, On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [121016 09:53]: * Kishon Vijay Abraham I kis...@ti.com [121007 23:01]: ocp2scp was not having pdata support which makes *musb* fail for non-dt boot in OMAP platform. The pdata will have information about the devices that is connected to ocp2scp. ocp2scp driver will now make use of this information to create the devices that is attached to ocp2scp. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com This fixes the regression on my panda es for musb port: Acked-by: Tony Lindgren t...@atomide.com Looks like nobody has picked this one up and we need it to fix the musb regression on omap, so I'll queue these up. I don't seem to have the patches around in any mailbox :-( Bounced them to you. Do you have any better ideas for the -rc cycle to fix the MUSB regression on omap4? Well, there are two regressions that I know of. One is caused by the mode1 DMA changes, which I'll just revert, and the other is the missing platform_data support on the new PHY driver which these patches are supposed to solve, right ? Yes that's it AFAIK. Kishon, any other patches I need to take to get MUSB working on v3.7 ? These should be good enough to get MUSB working.. nothing needed for omap-usb2.c ? That's great, cheers No. Nothing of pdata sort is used in omap-usb2.c Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: omap-gpio: add support for pm_runtime autosuspend
+ Jon,
On Friday 26 October 2012 06:49 PM, Tim Niemeyer wrote:
Adds support for configuring the omap-gpio driver use autosuspend for
runtime power management. This can reduce the latency in using it by
not suspending the device immediately on idle. If another access takes
place before the autosuspend timeout (2 secs), the call to resume the
device can return immediately saving some save/ restore cycles.
This removes also the bank-mod_usage counter, because this is already
handled in pm_runtime.
I use a gpio to monitor a spi transfer which occurs every 250µs. The
suspend overhead is to high, so almost every second transfer is lost.
This patch fixes that.
Signed-off-by: Tim Niemeyer tim.nieme...@corscience.de
---
drivers/gpio/gpio-omap.c | 81 -
1 files changed, 43 insertions(+), 38 deletions(-)
From patch it appears your main motive is to delay the idle kicking in
with a timeout to avoid GPIO on cpuidle path. Some comments
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..708d5a9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -31,6 +31,7 @@
#include asm/mach/irq.h
#define OFF_MODE 1
+#define GPIO_AUTOSUSPEND_TIMEOUT2000
static LIST_HEAD(omap_gpio_list);
@@ -64,7 +65,6 @@ struct gpio_bank {
spinlock_t lock;
struct gpio_chip chip;
struct clk *dbck;
- u32 mod_usage;
How have you tested 'mod_suage' change ?
u32 dbck_enable_mask;
bool dbck_enabled;
struct device *dev;
@@ -557,10 +557,9 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
/*
* If this is the first gpio_request for the bank,
-* enable the bank module.
+* resume the bank module.
Since you removing bank notion, If this is the first gpio_request
for the bank, becomes irrelevant from code perspective.
[..]
@@ -608,28 +594,15 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
__raw_readl(bank-base + bank-regs-wkup_en);
}
- bank-mod_usage = ~(1 offset);
-
- if (bank-regs-ctrl !bank-mod_usage) {
- void __iomem *reg = bank-base + bank-regs-ctrl;
- u32 ctrl;
-
- ctrl = __raw_readl(reg);
- /* Module is disabled, clocks are gated */
- ctrl |= GPIO_MOD_CTRL_BIT;
- __raw_writel(ctrl, reg);
- bank-context.ctrl = ctrl;
- }
-
_reset_gpio(bank, bank-chip.base + offset);
spin_unlock_irqrestore(bank-lock, flags);
/*
* If this is the last gpio to be freed in the bank,
-* disable the bank module.
+* put the bank module into suspend.
*/
- if (!bank-mod_usage)
- pm_runtime_put(bank-dev);
+ pm_runtime_mark_last_busy(bank-dev);
+ pm_runtime_put_autosuspend(bank-dev);
Waiting for 2 seconds timeout even on GPIO free
seems to be wrong.
}
/*
@@ -715,7 +688,8 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
exit:
if (!unmasked)
chained_irq_exit(chip, desc);
- pm_runtime_put(bank-dev);
+ pm_runtime_mark_last_busy(bank-dev);
+ pm_runtime_put_autosuspend(bank-dev);
This is what is the main change from this patch which helps your
case.
}
static void gpio_irq_shutdown(struct irq_data *d)
@@ -1132,6 +1106,8 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, bank);
+ pm_runtime_use_autosuspend(bank-dev);
+ pm_runtime_set_autosuspend_delay(bank-dev, GPIO_AUTOSUSPEND_TIMEOUT);
Can you please report how have you tested this change ? What other PM
tests you have done?
Removing mod usage might just break this driver because now individual
banks which can idle before, can no longer idle.
Just to expand a bit, Out of 6 GPIO banks, GPIO1 bank is in always ON
domain where as remaing 5 are in peripheral domain. Letting individual
banks idle allowed you let the clock domain idle than keeping all the
6 banks and hence respective clock/power domain in ON state.
So the adding timeout might be reasonable but I am not sure about
the mod_usage change here.
Jon, What you say ?
--
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] drivers: bus: omap_interconnect: Fix rand-config build warning
Hi Tony, On Friday 26 October 2012 12:05 PM, Santosh Shilimkar wrote: On Friday 26 October 2012 12:45 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [121024 23:34]: On Thursday 25 October 2012 06:12 AM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [121024 17:36]: * Santosh Shilimkar santosh.shilim...@ti.com [121017 06:35]: (Looping Arnd and Olof) On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote: When building omap_l3_noc/smx drivers as modules, the following warning appears: CC [M] drivers/bus/omap_l3_smx.o drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage class drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration of 'postcore_initcall_sync' drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in function declaration drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used CC [M] drivers/bus/omap_l3_noc.o drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage class drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration of 'arch_initcall_sync' drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in function declaration drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used Adding module_init() and macros in omap_l3_noc/smx drivers when building as modules to remove the above warning. Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- Thanks for the fix Lokesh. Looks fine to me. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Looks like nobody else has picked this up so I'll queue this along with few other omap warnings and regressions. Hmm actually this might require some more discussion. If we make it use regular initcalls, then the ugly ifdefs can be left out. Is there a reason to init this early, can't we just use regular initcalls? I thought about it. The whole reason we want interconnect errors enabled early in the boot to avoid bad accesses issued on interconnect in early boot by various init codes. We managed to discovered many init sequence issues where the a driver is trying to access registers when clocks are not active, or drivers are using bad mapping. At times these errors gets un-noticed because of the behavior of interconnect and later causes serious issues. Leaving the driver init late in the boot means we can't catch any of the issues happen till the L3 driver init happens. OK yeah that makes sense. How about let's just make it just postcore_initcall instead of postcore_initcall_sync? _sync was added by purpose since the driver has depedency on the hwmod initialisation which is postcore_initcall. Without the sync, we open the race condition and the l3 driver registration will fail. In include/linux/module.h we have: ... #else /* MODULE */ /* Don't use these in loadable modules, but some people do... */ #define early_initcall(fn) module_init(fn) #define core_initcall(fn) module_init(fn) #define postcore_initcall(fn) module_init(fn) ... While the postcore_initcall_sync does not have those. No idea what the current plan is, but I sort of remember reading that the _sync versions are going away at some point anyways? I have no idea either. As mentioned sync was added to avoid the race. If and when _sync is removed, something should come as an alternative to avoid initcall completion dependencies for the one which falls in same group. Is the above discussion fine for you ? Will you pick this patch or you want any more modifications ? Thanks Lokesh Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/20] OMAPDSS: DISPC: remove dssdev depependency from error handler
Hi, On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote: The dispc error handler tries to fix issues by disabling and enabling panel. This is problematic, as we're trying to remove the dependency from omapdss to the omap_dss_devices. It's also racy, and doesn't really fix anything. This patch removes the use of omap_dss_device from the error handler, and just disables and enables the associated overlay manager. This should produce similar results as the previous solution, without using dssdev. Calling APPLY functions from the DISPC driver seems a bit incorrect. Instead of disabling/enabling the panel, can't we disable/enable the manger by just using DISPC funcs? Archit -- 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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
On Mon, Oct 29, 2012 at 04:58:23AM +, Hiremath, Vaibhav wrote: Now the expectation has grown to the level where people expect everything in the Mainline kernel and not in some custom kernel release. You are right, except for the has grown part. I have always expected the official kernel releases to be working and complete, without the kind of half baked stumps that the embedded vendors are pushing. In my experience with Freescale (and now TI also), the vendor supports Linux on their platform by providing a heavily patched, quick and dirty, customized kernel that is kinda, sorta working, somehow. This provides a way for their customers to get started with the development kits right away, and as such I have no problem with it. What I do have a problem with is the fact the vendors then drop the ball and don't follow through by getting their changes into mainline. This makes a huge problem for the vendor's customers later on, when the choice becomes either stay with the dead end vendor kernel, or try to get mainline working all by themselves. And so I am pleased to hear that the Ethernet ports on the am335x will be working in v3.8. Better late than never. Thanks, Richard -- 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 19/20] OMAPDSS: DISPC: remove dssdev depependency from error handler
On 2012-10-29 09:12, Archit Taneja wrote: Hi, On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote: The dispc error handler tries to fix issues by disabling and enabling panel. This is problematic, as we're trying to remove the dependency from omapdss to the omap_dss_devices. It's also racy, and doesn't really fix anything. This patch removes the use of omap_dss_device from the error handler, and just disables and enables the associated overlay manager. This should produce similar results as the previous solution, without using dssdev. Calling APPLY functions from the DISPC driver seems a bit incorrect. Instead of disabling/enabling the panel, can't we disable/enable the manger by just using DISPC funcs? I agree, but if we don't call apply functions, we're bypassing the locks/etc from apply, and we could end up messing up what apply.c thinks is going on. With my omapdss+omapdrm compatibility patch series I'm moving the error handler to the apply mechanism, so it becomes a bit saner. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 06/14] mtd: onenand: omap: use pdata info instead of cpu_is
On Friday 26 October 2012 10:11 PM, Tony Lindgren wrote: * Paul Walmsleyp...@pwsan.com [121025 22:05]: It also breaks an OMAP3+4 config: Fix below. Thanks, I'd like to pull this fix in too along with the others. Thanks Paul and Tony for taking care of this issue. I am sorry about the issue and had been on vacation last week. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: AM33xx: add support for reboot
Hi Daniel, On Monday 29 October 2012 12:49 AM, Daniel Mack wrote: Afzal, are you planning to resubmit this for mainline? My version can of course be disposed then. I am not planning to submit it as of now, and Vaibhav H has a better suggestion on this, you may co-ordinate with him. Regards Afzal -- 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/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
Hi Daniel, On Thursday 25 October 2012 01:30 PM, Daniel Mack wrote: Hmm, that number is currently hard-coded in GPMC_CS_NUM. It would take some effort to make that dynamic but I agree that this would be a good thing to have. Afzal? It would be good to have (to the best of my knowledge am335x has only 7 pinned out, even though IP has 8) Regards Afzal -- 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/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
Hi Daniel, On Thursday 25 October 2012 05:01 AM, Daniel Mack wrote: Thanks for the review. I'll wait for feedback from Afzal next week and then repost. Wanted to see first if that goes in the right direction at all before bordering the DT people with binding details :) I was thinking of a generic approach, where there won't be any check for peripheral device type. But going that path would delay achieving DT, may be let's proceed with your approach to start with so that we can have a minimal level of DT support for GPMC and probably we can make it generic later. While adding new properties, it would be better to keep in mind that we need not change these later once gpmc DT is made generic. Regarding the bindings, there are some generic nand properties like ecc already available, may be that be made use here. Also perhaps memory size (and offset if needed) to be mapped for peripherals can go with reg property of child. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: omap-gpio: add support for pm_runtime autosuspend
On Mon, Oct 29, 2012 at 12:17:08PM +0530, Santosh Shilimkar wrote:
+ Jon,
On Friday 26 October 2012 06:49 PM, Tim Niemeyer wrote:
Adds support for configuring the omap-gpio driver use autosuspend for
runtime power management. This can reduce the latency in using it by
not suspending the device immediately on idle. If another access takes
place before the autosuspend timeout (2 secs), the call to resume the
device can return immediately saving some save/ restore cycles.
This removes also the bank-mod_usage counter, because this is already
handled in pm_runtime.
I use a gpio to monitor a spi transfer which occurs every 250µs. The
suspend overhead is to high, so almost every second transfer is lost.
This patch fixes that.
Signed-off-by: Tim Niemeyer tim.nieme...@corscience.de
---
drivers/gpio/gpio-omap.c | 81
-
1 files changed, 43 insertions(+), 38 deletions(-)
From patch it appears your main motive is to delay the idle kicking in
with a timeout to avoid GPIO on cpuidle path. Some comments
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..708d5a9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -31,6 +31,7 @@
#include asm/mach/irq.h
#define OFF_MODE 1
+#define GPIO_AUTOSUSPEND_TIMEOUT2000
static LIST_HEAD(omap_gpio_list);
@@ -64,7 +65,6 @@ struct gpio_bank {
spinlock_t lock;
struct gpio_chip chip;
struct clk *dbck;
-u32 mod_usage;
How have you tested 'mod_suage' change ?
u32 dbck_enable_mask;
bool dbck_enabled;
struct device *dev;
@@ -557,10 +557,9 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
/*
* If this is the first gpio_request for the bank,
- * enable the bank module.
+ * resume the bank module.
Since you removing bank notion, If this is the first gpio_request
for the bank, becomes irrelevant from code perspective.
[..]
@@ -608,28 +594,15 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
__raw_readl(bank-base + bank-regs-wkup_en);
}
-bank-mod_usage = ~(1 offset);
-
-if (bank-regs-ctrl !bank-mod_usage) {
-void __iomem *reg = bank-base + bank-regs-ctrl;
-u32 ctrl;
-
-ctrl = __raw_readl(reg);
-/* Module is disabled, clocks are gated */
-ctrl |= GPIO_MOD_CTRL_BIT;
-__raw_writel(ctrl, reg);
-bank-context.ctrl = ctrl;
-}
-
_reset_gpio(bank, bank-chip.base + offset);
spin_unlock_irqrestore(bank-lock, flags);
/*
* If this is the last gpio to be freed in the bank,
- * disable the bank module.
+ * put the bank module into suspend.
*/
-if (!bank-mod_usage)
-pm_runtime_put(bank-dev);
+pm_runtime_mark_last_busy(bank-dev);
+pm_runtime_put_autosuspend(bank-dev);
Waiting for 2 seconds timeout even on GPIO free
seems to be wrong.
}
/*
@@ -715,7 +688,8 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
exit:
if (!unmasked)
chained_irq_exit(chip, desc);
-pm_runtime_put(bank-dev);
+pm_runtime_mark_last_busy(bank-dev);
+pm_runtime_put_autosuspend(bank-dev);
This is what is the main change from this patch which helps your
case.
}
static void gpio_irq_shutdown(struct irq_data *d)
@@ -1132,6 +1106,8 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, bank);
+pm_runtime_use_autosuspend(bank-dev);
+pm_runtime_set_autosuspend_delay(bank-dev, GPIO_AUTOSUSPEND_TIMEOUT);
Can you please report how have you tested this change ? What other PM
tests you have done?
Removing mod usage might just break this driver because now individual
banks which can idle before, can no longer idle.
why's that ?
Just to expand a bit, Out of 6 GPIO banks, GPIO1 bank is in always ON
domain where as remaing 5 are in peripheral domain. Letting individual
banks idle allowed you let the clock domain idle than keeping all the
6 banks and hence respective clock/power domain in ON state.
So the adding timeout might be reasonable but I am not sure about
the mod_usage change here.
IMHO that whole mod_usage is broken. I remember sending a big series of
patches getting rid of that long ago. I _did_ break a few things but
just because of omap_gpio_prepare_for_idle() /
omap_gpio_resume_from_idle() hackery to get GPIO suspended early enough.
I still think mod_usage needs to go, so does
omap_gpio_prepare_for_idle() and omap_gpio_resume_from_idle(). To me, it
looks like that needs to be done on -prepare()/-complete() callbacks
of system suspend and the gpio driver needs to learn proper runtime
suspend.
The way it is today (get() on gpio_request() and put() on gpio_free())
is just wrong and
Re: [RFC PATCH v3 11/16] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
On 10/18/2012 6:56 PM, Matt Porter wrote: The EDMA DMAC has a hardware limitation that prevents supporting scatter gather lists with any number of segments. Since the EDMA DMA Engine driver sets the maximum segments to 16, we do the same. TODO: this will be replaced once the DMA Engine API supports an API to query the DMAC's segment size limit. Signed-off-by: Matt Porter mpor...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index b327cd0..52bab01 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1828,6 +1828,16 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev) * as we want. */ mmc-max_segs = 1024; + /* Eventually we should get our max_segs limitation for EDMA by + * querying the dmaengine API */ Nit picking: This is not as per multi-line comment style in Documentation/CodingStyle. 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
[PATCH-V2 0/4] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
This patch-series adds support for, [1/4]: Typo mistake in CPSW driver while invoking runtime_pm api's [2/4]: Adds parent-child relation between CPSW MDIO module inside cpsw driver, as in case of AM33XX, the resources are shared and common register bit-field is provided to control module/clock enable/disable, makes it difficult to handle common resource. So the solution here is, to create parent-child relation between them. [3/4]: Add hwmod entry for MDIO module, required for MDIO driver. [4/4]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, am335x-evm.dts and am335x-bone.dts file This patch series has been created on top of linux-omap/master and tested on both AM335x-EVM and BeagleBone platforms for NFS boot and basic ping test cases. All the patches are also available at, g...@github.com:hvaibhav/am335x-linux.git am335x-upstream-staging-cpsw Mugunthan V N (2): ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX Vaibhav Hiremath (2): net: davinci_mdio: Fix typo mistake in calling runtime-pm api net: cpsw: Add parent-child relation support between cpsw and mdio arch/arm/boot/dts/am335x-bone.dts |8 arch/arm/boot/dts/am335x-evm.dts |8 arch/arm/boot/dts/am33xx.dtsi | 50 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 32 ++ drivers/net/ethernet/ti/cpsw.c | 16 - drivers/net/ethernet/ti/davinci_mdio.c |2 +- 6 files changed, 113 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] net: davinci_mdio: Fix typo mistake in calling runtime-pm api
By mistake (most likely a copy-paste), instead of pm_runtime_get_sync() api, driver is calling pm_runtime_put_sync() api in resume callback function. The bug was introduced by commit id (ae2c07aaf74: davinci_mdio: runtime PM support). Now, the reason why it didn't impact functionality is, the patch has been tested on AM335x-EVM and BeagleBone platform while submitting; and in case of AM335x the MDIO driver doesn't control the module enable/disable part, which is handled by CPSW driver. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Mugunthan V N mugunthan...@ti.com Cc: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/davinci_mdio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c index 51a96db..ae74280 100644 --- a/drivers/net/ethernet/ti/davinci_mdio.c +++ b/drivers/net/ethernet/ti/davinci_mdio.c @@ -465,7 +465,7 @@ static int davinci_mdio_resume(struct device *dev) u32 ctrl; spin_lock(data-lock); - pm_runtime_put_sync(data-dev); + pm_runtime_get_sync(data-dev); /* restart the scan state machine */ ctrl = __raw_readl(data-regs-control); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] net: cpsw: Add parent-child relation support between cpsw and mdio
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci family
of devices. Now based on requirement, use-case and available technology
nodes the integration of these sub-modules varies across devices.
So coming back to Linux net driver, currently separate and independent
platform devices drivers for CPSW and MDIO is implemented. In case of
Davinci they both has separate control, from resources perspective,
like clock.
In case of AM33XX, the resources are shared and only one register
bit-field is provided to control module/clock enable/disable, makes it
difficult to handle common resource.
So the solution here implemented in this patch is,
Create parent-child relationship between both the drivers, making
CPSW as a parent and MDIO as its child and enumerate all the child nodes
under CPSW module.
Both the drivers will function exactly the way it was operating before,
including runtime-pm functionality. No change is required in MDIO driver
(for that matter to any child driver).
As this is only supported during DT boot, the parent-child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making MDIO as a child to CPSW node.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Mugunthan V N mugunthan...@ti.com
Cc: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/ti/cpsw.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index df55e24..fb1a692 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -827,7 +827,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
data-mac_control = prop;
- for_each_child_of_node(node, slave_node) {
+ for_each_node_by_name(slave_node, slave) {
struct cpsw_slave_data *slave_data = data-slave_data + i;
const char *phy_id = NULL;
const void *mac_addr = NULL;
@@ -862,6 +862,14 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
i++;
}
+ /*
+* Populate all the child nodes here...
+*/
+ ret = of_platform_populate(node, NULL, NULL, pdev-dev);
+ /* We do not want to force this, as in some cases may not have child */
+ if (ret)
+ pr_warn(Doesn't have any child node\n);
+
return 0;
error_ret:
@@ -895,6 +903,11 @@ static int __devinit cpsw_probe(struct platform_device
*pdev)
priv-msg_enable = netif_msg_init(debug_level, CPSW_DEBUG);
priv-rx_packet_max = max(rx_packet_max, 128);
+ /*
+* This may be required here for child devices.
+*/
+ pm_runtime_enable(pdev-dev);
+
if (cpsw_probe_dt(priv-data, pdev)) {
pr_err(cpsw: platform data missing\n);
ret = -ENODEV;
@@ -921,7 +934,6 @@ static int __devinit cpsw_probe(struct platform_device
*pdev)
for (i = 0; i data-slaves; i++)
priv-slaves[i].slave_num = i;
- pm_runtime_enable(pdev-dev);
priv-clk = clk_get(pdev-dev, fck);
if (IS_ERR(priv-clk)) {
dev_err(pdev-dev, fck is not found\n);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
From: Mugunthan V N mugunthan...@ti.com
This patch adds hwmod entry for davinci MDIO module,
creating parent-child relationship between CPSW and MDIO module.
This Parent-child relation is required in order to use common resources
like, clock, but still maintaining the logical separation between them.
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci
family of devices, so separate and independent platform devices
drivers for CPSW and MDIO is implemented.
In case of AM33XX, the resources are shared and common register
bit-field is provided to control module/clock enable/disable,
makes it difficult to handle common resources from both drivers.
So the solution is, create parent-child relationship between
CPGMAC MDIO modules.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Richard Cochran richardcoch...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..3c235d8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -674,6 +674,7 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
.name = cpgmac0,
.class = am33xx_cpgmac0_hwmod_class,
.clkdm_name = cpsw_125mhz_clkdm,
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
.mpu_irqs = am33xx_cpgmac0_irqs,
.main_clk = cpsw_125mhz_gclk,
.prcm = {
@@ -685,6 +686,20 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
};
/*
+ * mdio class
+ */
+static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
+ .name = davinci_mdio,
+};
+
+static struct omap_hwmod am33xx_mdio_hwmod = {
+ .name = davinci_mdio,
+ .class = am33xx_mdio_hwmod_class,
+ .clkdm_name = cpsw_125mhz_clkdm,
+ .main_clk = cpsw_125mhz_gclk,
+};
+
+/*
* dcan class
*/
static struct omap_hwmod_class am33xx_dcan_hwmod_class = {
@@ -2501,6 +2516,22 @@ static struct omap_hwmod_ocp_if am33xx_l4_hs__cpgmac0 = {
.user = OCP_USER_MPU,
};
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ .flags = ADDR_MAP_ON_INIT,
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = am33xx_cpgmac0_hwmod,
+ .slave = am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
{
.pa_start = 0x4808,
@@ -3371,6 +3402,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
am33xx_l3_main__tptc2,
am33xx_l3_s__usbss,
am33xx_l4_hs__cpgmac0,
+ am33xx_cpgmac0__mdio,
NULL,
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: Mugunthan V N mugunthan...@ti.com
Add CPSW and MDIO related device tree data for AM33XX.
Also enable them into board/evm dts files by providing
respective phy-id.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Richard Cochran richardcoch...@gmail.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |8 ++
arch/arm/boot/dts/am335x-evm.dts |8 ++
arch/arm/boot/dts/am33xx.dtsi | 50 +
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..e233cfa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..415c3b3 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -118,3 +118,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..f6bea04 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,55 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ mac: ethernet@4A10 {
+ compatible = ti,cpsw;
+ ti,hwmods = cpgmac0;
+ cpdma_channels = 8;
+ host_port_no = 0;
+ cpdma_reg_ofs = 0x800;
+ cpdma_sram_ofs = 0xa00;
+ ale_reg_ofs = 0xd00;
+ ale_entries = 1024;
+ host_port_reg_ofs = 0x108;
+ hw_stats_reg_ofs = 0x900;
+ bd_ram_ofs = 0x2000;
+ bd_ram_size = 0x2000;
+ no_bd_ram = 0;
+ rx_descs = 64;
+ mac_control = 0x20;
+ slaves = 2;
+ reg = 0x4a10 0x800
+ 0x4a101200 0x100
+ 0x4a101000 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = intc;
+ /* c0_rx_thresh_pend c0_rx_pend c0_tx_pend
c0_misc_pend*/
+ interrupts = 40 41 42 43;
+ ranges;
+ cpsw_emac0: slave@0 {
+ slave_reg_ofs = 0x208;
+ sliver_reg_ofs = 0xd80;
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+ cpsw_emac1: slave@1 {
+ slave_reg_ofs = 0x308;
+ sliver_reg_ofs = 0xdc0;
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ davinci_mdio: mdio@4a101000 {
+ compatible = ti,davinci_mdio;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = davinci_mdio;
+ bus_freq = 100;
+ reg = 0x4a101000 0x100;
+ };
+
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: omap-gpio: add support for pm_runtime autosuspend
On Monday 29 October 2012 01:35 PM, Felipe Balbi wrote:
On Mon, Oct 29, 2012 at 12:17:08PM +0530, Santosh Shilimkar wrote:
+ Jon,
On Friday 26 October 2012 06:49 PM, Tim Niemeyer wrote:
Adds support for configuring the omap-gpio driver use autosuspend for
runtime power management. This can reduce the latency in using it by
not suspending the device immediately on idle. If another access takes
place before the autosuspend timeout (2 secs), the call to resume the
device can return immediately saving some save/ restore cycles.
This removes also the bank-mod_usage counter, because this is already
handled in pm_runtime.
I use a gpio to monitor a spi transfer which occurs every 250µs. The
suspend overhead is to high, so almost every second transfer is lost.
This patch fixes that.
Signed-off-by: Tim Niemeyer tim.nieme...@corscience.de
---
drivers/gpio/gpio-omap.c | 81 -
1 files changed, 43 insertions(+), 38 deletions(-)
From patch it appears your main motive is to delay the idle kicking in
with a timeout to avoid GPIO on cpuidle path. Some comments
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..708d5a9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -31,6 +31,7 @@
#include asm/mach/irq.h
#define OFF_MODE 1
+#define GPIO_AUTOSUSPEND_TIMEOUT2000
static LIST_HEAD(omap_gpio_list);
@@ -64,7 +65,6 @@ struct gpio_bank {
spinlock_t lock;
struct gpio_chip chip;
struct clk *dbck;
- u32 mod_usage;
How have you tested 'mod_suage' change ?
u32 dbck_enable_mask;
bool dbck_enabled;
struct device *dev;
@@ -557,10 +557,9 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
/*
* If this is the first gpio_request for the bank,
-* enable the bank module.
+* resume the bank module.
Since you removing bank notion, If this is the first gpio_request
for the bank, becomes irrelevant from code perspective.
[..]
@@ -608,28 +594,15 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
__raw_readl(bank-base + bank-regs-wkup_en);
}
- bank-mod_usage = ~(1 offset);
-
- if (bank-regs-ctrl !bank-mod_usage) {
- void __iomem *reg = bank-base + bank-regs-ctrl;
- u32 ctrl;
-
- ctrl = __raw_readl(reg);
- /* Module is disabled, clocks are gated */
- ctrl |= GPIO_MOD_CTRL_BIT;
- __raw_writel(ctrl, reg);
- bank-context.ctrl = ctrl;
- }
-
_reset_gpio(bank, bank-chip.base + offset);
spin_unlock_irqrestore(bank-lock, flags);
/*
* If this is the last gpio to be freed in the bank,
-* disable the bank module.
+* put the bank module into suspend.
*/
- if (!bank-mod_usage)
- pm_runtime_put(bank-dev);
+ pm_runtime_mark_last_busy(bank-dev);
+ pm_runtime_put_autosuspend(bank-dev);
Waiting for 2 seconds timeout even on GPIO free
seems to be wrong.
}
/*
@@ -715,7 +688,8 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
exit:
if (!unmasked)
chained_irq_exit(chip, desc);
- pm_runtime_put(bank-dev);
+ pm_runtime_mark_last_busy(bank-dev);
+ pm_runtime_put_autosuspend(bank-dev);
This is what is the main change from this patch which helps your
case.
}
static void gpio_irq_shutdown(struct irq_data *d)
@@ -1132,6 +1106,8 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, bank);
+ pm_runtime_use_autosuspend(bank-dev);
+ pm_runtime_set_autosuspend_delay(bank-dev, GPIO_AUTOSUSPEND_TIMEOUT);
Can you please report how have you tested this change ? What other PM
tests you have done?
Removing mod usage might just break this driver because now individual
banks which can idle before, can no longer idle.
why's that ?
Just to expand a bit, Out of 6 GPIO banks, GPIO1 bank is in always ON
domain where as remaing 5 are in peripheral domain. Letting individual
banks idle allowed you let the clock domain idle than keeping all the
6 banks and hence respective clock/power domain in ON state.
So the adding timeout might be reasonable but I am not sure about
the mod_usage change here.
IMHO that whole mod_usage is broken. I remember sending a big series of
patches getting rid of that long ago. I _did_ break a few things but
just because of omap_gpio_prepare_for_idle() /
omap_gpio_resume_from_idle() hackery to get GPIO suspended early enough.
Well so far I haven't seen/come across a patch/proposal which fixes it.
I still think mod_usage needs to go, so does
omap_gpio_prepare_for_idle() and omap_gpio_resume_from_idle(). To me, it
looks like that needs to be done on -prepare()/-complete() callbacks
of system suspend
RE: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
On Mon, Oct 29, 2012 at 13:20:03, Richard Cochran wrote: On Mon, Oct 29, 2012 at 04:58:23AM +, Hiremath, Vaibhav wrote: Now the expectation has grown to the level where people expect everything in the Mainline kernel and not in some custom kernel release. You are right, except for the has grown part. I have always expected the official kernel releases to be working and complete, without the kind of half baked stumps that the embedded vendors are pushing. In my experience with Freescale (and now TI also), the vendor supports Linux on their platform by providing a heavily patched, quick and dirty, customized kernel that is kinda, sorta working, somehow. This provides a way for their customers to get started with the development kits right away, and as such I have no problem with it. What I do have a problem with is the fact the vendors then drop the ball and don't follow through by getting their changes into mainline. This makes a huge problem for the vendor's customers later on, when the choice becomes either stay with the dead end vendor kernel, or try to get mainline working all by themselves. I completely understand and I can only say that, we have learned our lessons long time back on this and we now try to push all our code to Mainline. Even with TI release kernel we try to stay closer to mainline, so that later it would be easier to submit the patches to mainline. For example, in some cases we have back-ported some of the framework changes to v3.2 kernel to stay closer to mainline. And so I am pleased to hear that the Ethernet ports on the am335x will be working in v3.8. Better late than never. Just submitted patches to the list, care to ack them. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2 0/4] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
On Mon, Oct 29, 2012 at 01:51:17PM +0530, Vaibhav Hiremath wrote: This patch-series adds support for, [1/4]: Typo mistake in CPSW driver while invoking runtime_pm api's [2/4]: Adds parent-child relation between CPSW MDIO module inside cpsw driver, as in case of AM33XX, the resources are shared and common register bit-field is provided to control module/clock enable/disable, makes it difficult to handle common resource. So the solution here is, to create parent-child relation between them. [3/4]: Add hwmod entry for MDIO module, required for MDIO driver. [4/4]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, am335x-evm.dts and am335x-bone.dts file Many Thanks! Acked-by: Richard Cochran richardcoch...@gmail.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] gpio: omap-gpio: add support for pm_runtime autosuspend
Am Montag, den 29.10.2012, 12:17 +0530 schrieb Santosh Shilimkar:
+ Jon,
On Friday 26 October 2012 06:49 PM, Tim Niemeyer wrote:
Adds support for configuring the omap-gpio driver use autosuspend for
runtime power management. This can reduce the latency in using it by
not suspending the device immediately on idle. If another access takes
place before the autosuspend timeout (2 secs), the call to resume the
device can return immediately saving some save/ restore cycles.
This removes also the bank-mod_usage counter, because this is already
handled in pm_runtime.
I use a gpio to monitor a spi transfer which occurs every 250µs. The
suspend overhead is to high, so almost every second transfer is lost.
This patch fixes that.
Signed-off-by: Tim Niemeyer tim.nieme...@corscience.de
---
drivers/gpio/gpio-omap.c | 81
-
1 files changed, 43 insertions(+), 38 deletions(-)
From patch it appears your main motive is to delay the idle kicking in
with a timeout to avoid GPIO on cpuidle path. Some comments
cpuidle? I set 'CPU_IDLE=n' in my .config..
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..708d5a9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -31,6 +31,7 @@
#include asm/mach/irq.h
#define OFF_MODE 1
+#define GPIO_AUTOSUSPEND_TIMEOUT2000
static LIST_HEAD(omap_gpio_list);
@@ -64,7 +65,6 @@ struct gpio_bank {
spinlock_t lock;
struct gpio_chip chip;
struct clk *dbck;
- u32 mod_usage;
How have you tested 'mod_suage' change ?
Nothing special, just applied the patch to a 3.4.14 kernel and used one
gpio to show the status of my spi communication.
u32 dbck_enable_mask;
bool dbck_enabled;
struct device *dev;
@@ -557,10 +557,9 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
/*
* If this is the first gpio_request for the bank,
-* enable the bank module.
+* resume the bank module.
Since you removing bank notion, If this is the first gpio_request
for the bank, becomes irrelevant from code perspective.
Hu, i thought pm_runtime_get_sync(bank-dev) handles the use counting
per bank?
@@ -608,28 +594,15 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
__raw_readl(bank-base + bank-regs-wkup_en);
}
- bank-mod_usage = ~(1 offset);
-
- if (bank-regs-ctrl !bank-mod_usage) {
- void __iomem *reg = bank-base + bank-regs-ctrl;
- u32 ctrl;
-
- ctrl = __raw_readl(reg);
- /* Module is disabled, clocks are gated */
- ctrl |= GPIO_MOD_CTRL_BIT;
- __raw_writel(ctrl, reg);
- bank-context.ctrl = ctrl;
- }
-
_reset_gpio(bank, bank-chip.base + offset);
spin_unlock_irqrestore(bank-lock, flags);
/*
* If this is the last gpio to be freed in the bank,
-* disable the bank module.
+* put the bank module into suspend.
*/
- if (!bank-mod_usage)
- pm_runtime_put(bank-dev);
+ pm_runtime_mark_last_busy(bank-dev);
+ pm_runtime_put_autosuspend(bank-dev);
Waiting for 2 seconds timeout even on GPIO free
seems to be wrong.
Yes, you are right, if something frees the gpio it should suspend
immediately.
}
/*
@@ -715,7 +688,8 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
exit:
if (!unmasked)
chained_irq_exit(chip, desc);
- pm_runtime_put(bank-dev);
+ pm_runtime_mark_last_busy(bank-dev);
+ pm_runtime_put_autosuspend(bank-dev);
This is what is the main change from this patch which helps your
case.
}
static void gpio_irq_shutdown(struct irq_data *d)
@@ -1132,6 +1106,8 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, bank);
+ pm_runtime_use_autosuspend(bank-dev);
+ pm_runtime_set_autosuspend_delay(bank-dev, GPIO_AUTOSUSPEND_TIMEOUT);
Can you please report how have you tested this change ? What other PM
tests you have done?
My main goal isn't to have a good power-saving, i need a small latency.
The runtime-pm disturbed that. I tested to disable CONFIG_PM_RUNTIME,
but than the gptimer couldn't be initialized.
My scenario: gptimer triggers every 250µs and starts an async_spi
transfer while it sets one gpio line to high. The spi_complete then puts
this gpio to low again.
Every second interrupt was lost and i wanted to know why so i removed
the spi stuff and just turned a gpio on and off in the timer-isr. It
turned out that the system wasn't able to tick with 4kHz. I then
disabled the CONFIG_PM_RUNTIME and fiddled the gptimer to start without
runtime-pm. Then i was able to use gpio with up to 100kHz. I enabled
CONFIG_PM_RUNTIME again and disabled the gpio runtime_pm via sysfs (echo
on
Re: [PATCH] gpio: omap-gpio: add support for pm_runtime autosuspend
Hello Am Freitag, den 26.10.2012, 23:01 +0300 schrieb Felipe Balbi: Hi, On Fri, Oct 26, 2012 at 03:19:13PM +0200, Tim Niemeyer wrote: Adds support for configuring the omap-gpio driver use autosuspend for runtime power management. This can reduce the latency in using it by not suspending the device immediately on idle. If another access takes place before the autosuspend timeout (2 secs), the call to resume the device can return immediately saving some save/ restore cycles. This removes also the bank-mod_usage counter, because this is already handled in pm_runtime. I use a gpio to monitor a spi transfer which occurs every 250µs. The suspend overhead is to high, so almost every second transfer is lost. This patch fixes that. Signed-off-by: Tim Niemeyer tim.nieme...@corscience.de --- drivers/gpio/gpio-omap.c | 81 - 1 files changed, 43 insertions(+), 38 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 94cbc84..708d5a9 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -31,6 +31,7 @@ #include asm/mach/irq.h #define OFF_MODE 1 +#define GPIO_AUTOSUSPEND_TIMEOUT2000 something just hit me... If you keep timeout at 2000 ms and you hook this up to an IRQ line, it's very unlikely GPIO will ever sleep. Why did you choose 2000 ms ? Arbitrary value ? Got it from the spi driver (27b5284cfbe187732ebb184b03ea693f44837f9d). I have no problem with reducing this. As i don't know how much power-overhead the suspend needs, what do you think is a good value in terms of power-saving? -- Tim Niemeyer Corscience GmbH Co. KG Henkestr. 91 D-91052 Erlangen Germany e-mail: tim.nieme...@corscience.de Internet: www.corscience.de -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
Adds AM33XX SPI support for am335x-bone and am335x-evm.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 17 +++
arch/arm/boot/dts/am335x-evm.dts |9
arch/arm/boot/dts/am33xx.dtsi | 43
+
3 files changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5510979..23edfd8 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,6 +18,17 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am3358_pinmux: pinmux@44e10800 {
+ spi1_pins: pinmux_spi1_pins {
+ pinctrl-single,pins =
+ 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
OUTPUT_PULLUP | MODE3 */
+ 0x194 0x33 /* mcasp0_fsx.spi1_d0,
INPUT_PULLUP | MODE3 */
+ 0x198 0x13 /* mcasp0_axr0.spi1_d1,
OUTPUT_PULLUP | MODE3 */
+ 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
OUTPUT_PULLUP | MODE3 */
+ ;
+ };
+ };
+
Change to am33xx_pinmux.
ocp {
uart1: serial@44e09000 {
status = okay;
@@ -84,3 +95,9 @@
mmc1 {
vmmc-supply = ldo3_reg;
};
+
+spi1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = spi1_pins;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index d63fce8..8d5f660 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -124,3 +124,12 @@
mmc1 {
vmmc-supply = vmmc_reg;
};
+
+spi0 {
+ status = okay;
+ spi-flash@0 {
+ compatible = spansion,s25fl064k, m25p80;
+ spi-max-frequency = 2400;
+ reg = 0;
+ };
+};
In AM335x-evm, SPI flash available in profile #2 (am335x evm specific profiles).
So can you drop this changes as if I understood correctly, am335x-evm.dts will
be
populated for devices present only on profile #0.
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 26a6af7..063ecea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux@44e10800 {
+ compatible = pinctrl-single;
+ reg = 0x44e10800 0x0238;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x7f;
+ };
+
Pin ctrl support already submitted
http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=commitdiff;h=3e0603e905d9ba662e8c1885ecb1d28bc454e448
Thanks
Avinash
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex.Since
@@ -261,6 +270,40 @@
status = disabled;
};
+ spi0: spi@4803 {
+ compatible = ti,omap4-mcspi;
+ ti,hwmods = spi0;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x4803 0x400;
+ interrupt-parent = intc;
+ interrupt = 65;
+ dmas = edma 16
+ edma 17
+ edma 18
+ edma 19;
+ dma-names = tx0, rx0, tx1, rx1;
+ ti,spi-num-cs = 2;
+ status = disabled;
+ };
+
+ spi1: spi@481a {
+ compatible = ti,omap4-mcspi;
+ ti,hwmods = spi1;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x481a 0x400;
+ interrupt-parent = intc;
+ interrupt = 125;
+ dmas = edma 42
+ edma 43
+ edma 44
+ edma 45;
+ dma-names = tx0, rx0, tx1, rx1;
+ ti,spi-num-cs = 2;
+ status = disabled;
+ };
+
wdt2: wdt@44e35000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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
Re: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
Hi, On Monday 29 October 2012 02:31 PM, Roger Quadros wrote: Hi Tony, On 10/26/2012 07:36 PM, Tony Lindgren wrote: * Benoit Cousson b-cous...@ti.com [121026 08:23]: Hi Roger, On 10/26/2012 05:16 PM, Roger Quadros wrote: Hi Kishon Benoit, On 09/24/2012 12:06 PM, Rabin Vincent wrote: 2012/9/24 ABRAHAM, KISHON VIJAY kis...@ti.com: On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent ra...@rab.in wrote: USB doesn't work on pandaboard on linux-next, and bisection shows this patch. Unfortunately, I can't provide a dmesg log because USB is the only way I currently have to get one out(!), but presumably it's because this omap-usb2 device is never registered? Looks like this breaks non-dt USB on pandaboard; is that intended? Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the old non-dt support). Well, USB used to work fine on Pandaboard without DT before the introduction of omap-usb2, so one would expected it to continue working (until the board file is completely removed). Anyway, I've moved to DT now. Some patches are queued only for 3.7. In case you want to use MUSB please use these patches on linux-next.. [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entries (from Benoit) [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series) [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series) I got these by merging in Benoit's for_3.7/dts_part2 on top of next-20120921. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I still can't get musb to work on 3.7-rc2. Apparently it is still missing the patches from Benoit's for_3.7/dts_part2. Maybe I just need to wait for it to be merged? They are now in a for_3.8/dts. Unfortunately, one patch that was adding ctrl_module address in the USB data was rejected and thus I'm not sure it will work without that. I think Tony had an idea to map the ctrl_register to regulator fmwk or something like that. For device tree, we may be eventually able to handle the ctrl_register using pinctrl-single.c and pinconf API. It probably does not make sense to set it up as a regulator as the comparator can trigger errors also for the pinconf related bits at least for MMC PBIAS. Till then, where can I get a tree where musb works on Panda? On panda, without using device tree, use v3.7-rc2 + the following patches: ARM: OMAP: ocp2scp: create omap device for ocp2scp ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy drivers: bus: ocp2scp: add pdata support The above 3 patches got it to work for me. Thanks for the hint. Also you need to enable CONFIG_OMAP_USB2. No idea what all is needed to use MUSB with device tree at this point. Yes, you need to enable a bunch of other things which are not so easy to figure out for someone who has not worked with MUSB. Do you think we should enable musb and all dependencies in omap2plus_defconfig? One more thing to note is that building CONFIG_OMAP_USB2 as module breaks the kernel build with the following error. drivers/built-in.o: In function `twl4030_usb_irq': /work/linux-2.6/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /work/linux-2.6/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' make: *** [vmlinux] Error 1 I bet the error would come while building twl6030-usb.c too. There are couple of fixes floating in the list to fix this. https://patchwork.kernel.org/patch/1370291/ and an alternative fix here: https://patchwork.kernel.org/patch/1409671/ Thanks Kishon -- 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: # (c) 2007, Joe Perches j...@perches.com
On 10/29/2012 1:51 PM, Vaibhav Hiremath wrote: Ignore this patch/mail, I screwed up with my command while sending patches. Sorry for noise. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: AM33xx: add support for reboot
On 29.10.2012 05:31, Hiremath, Vaibhav wrote:
On Sun, Oct 28, 2012 at 23:47:55, Daniel Mack wrote:
This patch adds the ability to reboot am33xx-based systems.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/prcm.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..6a69ceb 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -114,6 +114,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened
Device Tree))
.init_machine = omap_generic_init,
.timer = omap3_am33xx_timer,
.dt_compat = am33xx_boards_compat,
+.restart= omap_prcm_restart,
MACHINE_END
#endif
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 0f51e03..8a3068a 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -32,6 +32,7 @@
#include clock2xxx.h
#include cm2xxx_3xxx.h
#include prm2xxx_3xxx.h
+#include prm33xx.h
#include prm44xx.h
#include prminst44xx.h
#include cminst44xx.h
@@ -72,6 +73,11 @@ void omap_prcm_restart(char mode, const char *cmd)
omap3_ctrl_write_boot_mode((cmd ? (u8)*cmd : 0));
} else if (cpu_is_omap44xx()) {
omap4_prminst_global_warm_sw_reset(); /* never returns */
+} else if (soc_is_am33xx()) {
+prcm_offs = AM33XX_PRM_DEVICE_MOD;
+omap2_prm_set_mod_reg_bits(OMAP4430_RST_GLOBAL_COLD_SW_MASK,
+ prcm_offs,
+ AM33XX_PRM_RSTCTRL_OFFSET);
This is not clean way of handling it, we should have something similar to
omap4. Also we should use warm-reset here instead of cold.
I have quickly created patch, can you please review and test is?
I have tested it on AM335x EVM and Bone platform.
Works for me as well, thanks!
You can take my
Tested-by: Daniel Mack zon...@gmail.com
if you wish ...
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..6a69ceb 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -114,6 +114,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened
Device Tree))
.init_machine = omap_generic_init,
.timer = omap3_am33xx_timer,
.dt_compat = am33xx_boards_compat,
+ .restart= omap_prcm_restart,
MACHINE_END
#endif
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 0f51e03..490f8f6 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -33,6 +33,7 @@
#include cm2xxx_3xxx.h
#include prm2xxx_3xxx.h
#include prm44xx.h
+#include prm33xx.h
#include prminst44xx.h
#include cminst44xx.h
#include prm-regbits-24xx.h
@@ -72,6 +73,8 @@ void omap_prcm_restart(char mode, const char *cmd)
omap3_ctrl_write_boot_mode((cmd ? (u8)*cmd : 0));
} else if (cpu_is_omap44xx()) {
omap4_prminst_global_warm_sw_reset(); /* never returns */
+ } else if (soc_is_am33xx()) {
+ am33xx_prm_global_warm_sw_reset(); /* never returns */
} else {
WARN_ON(1);
}
diff --git a/arch/arm/mach-omap2/prm33xx.c b/arch/arm/mach-omap2/prm33xx.c
index e7dbb6c..505219d 100644
--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -133,3 +133,18 @@ int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0;
}
+
+void am33xx_prm_global_warm_sw_reset(void)
+{
+ u32 v;
+
+ v = am33xx_prm_read_reg(AM33XX_PRM_DEVICE_MOD,
+ AM33XX_PRM_RSTCTRL_OFFSET);
+ v |= AM33XX_GLOBAL_WARM_SW_RST_MASK;
+ am33xx_prm_write_reg(v, AM33XX_PRM_DEVICE_MOD,
+AM33XX_PRM_RSTCTRL_OFFSET);
+
+ /* OCP barrier */
+ v = am33xx_prm_read_reg(AM33XX_PRM_DEVICE_MOD,
+ AM33XX_PRM_RSTCTRL_OFFSET);
+}
diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 3f25c56..cdfc694 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -126,4 +126,5 @@ extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16
inst,
extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs);
extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
u16 rstctrl_offs, u16 rstst_offs);
+extern void am33xx_prm_global_warm_sw_reset(void);
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/20] OMAPDSS: DISPC: fix dispc_mgr_lclk_rate for DIGIT output
On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote: dispc_mgr_lclk_rate() cannot currently be called with DIGIT channel parameter, even if dispc_ovl_lclk_rate() can. Fix this by making It's called dispc_plane_lclk_rate() right now. dispc_mgr_lclk_rate() handle DIGIT channel also. Did you see a bug with this? Or is this just a cleanup? Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: AM33xx: add support for reboot
On Mon, Oct 29, 2012 at 15:19:21, Daniel Mack wrote:
On 29.10.2012 05:31, Hiremath, Vaibhav wrote:
On Sun, Oct 28, 2012 at 23:47:55, Daniel Mack wrote:
This patch adds the ability to reboot am33xx-based systems.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/prcm.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..6a69ceb 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -114,6 +114,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened
Device Tree))
.init_machine = omap_generic_init,
.timer = omap3_am33xx_timer,
.dt_compat = am33xx_boards_compat,
+ .restart= omap_prcm_restart,
MACHINE_END
#endif
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 0f51e03..8a3068a 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -32,6 +32,7 @@
#include clock2xxx.h
#include cm2xxx_3xxx.h
#include prm2xxx_3xxx.h
+#include prm33xx.h
#include prm44xx.h
#include prminst44xx.h
#include cminst44xx.h
@@ -72,6 +73,11 @@ void omap_prcm_restart(char mode, const char *cmd)
omap3_ctrl_write_boot_mode((cmd ? (u8)*cmd : 0));
} else if (cpu_is_omap44xx()) {
omap4_prminst_global_warm_sw_reset(); /* never returns */
+ } else if (soc_is_am33xx()) {
+ prcm_offs = AM33XX_PRM_DEVICE_MOD;
+ omap2_prm_set_mod_reg_bits(OMAP4430_RST_GLOBAL_COLD_SW_MASK,
+ prcm_offs,
+ AM33XX_PRM_RSTCTRL_OFFSET);
This is not clean way of handling it, we should have something similar to
omap4. Also we should use warm-reset here instead of cold.
I have quickly created patch, can you please review and test is?
I have tested it on AM335x EVM and Bone platform.
Works for me as well, thanks!
You can take my
Tested-by: Daniel Mack zon...@gmail.com
Thanks Daniel for confirming. I will send out this patch ASAP with your
tested by.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/20] OMAPDSS: DISPC: fix dispc_mgr_lclk_rate for DIGIT output
On 2012-10-29 11:50, Archit Taneja wrote: On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote: dispc_mgr_lclk_rate() cannot currently be called with DIGIT channel parameter, even if dispc_ovl_lclk_rate() can. Fix this by making It's called dispc_plane_lclk_rate() right now. Right, that was a typo on the description. dispc_mgr_lclk_rate() handle DIGIT channel also. Did you see a bug with this? Or is this just a cleanup? Yes, I had a crash when I was implementing a function to check the scaling and overlay parameters in such a way that all the parameters are given to the function, i.e. the func doesn't get any config from the hardware registers. So not a bug that happens in the current driver. Tomi signature.asc Description: OpenPGP digital signature
[PATCH] ARM: OMAP2+: am33xx: Add PRM warm reset/reboot support
This patch adds reboot capability to all AM33XX based boards/EVM's,
by asserting PRM warm reset bit on 'reboot' command.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Daniel Mack zon...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Cc: Afzal Mohammed af...@ti.com
---
Tested on AM335xEVM and BeagleBone platform.
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/prcm.c |3 +++
arch/arm/mach-omap2/prm33xx.c | 15 +++
arch/arm/mach-omap2/prm33xx.h |1 +
4 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..6a69ceb 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -114,6 +114,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened
Device Tree))
.init_machine = omap_generic_init,
.timer = omap3_am33xx_timer,
.dt_compat = am33xx_boards_compat,
+ .restart= omap_prcm_restart,
MACHINE_END
#endif
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index cff270a..07f163c 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -34,6 +34,7 @@
#include cm2xxx_3xxx.h
#include prm2xxx_3xxx.h
#include prm44xx.h
+#include prm33xx.h
#include prminst44xx.h
#include cminst44xx.h
#include prm-regbits-24xx.h
@@ -73,6 +74,8 @@ void omap_prcm_restart(char mode, const char *cmd)
omap3_ctrl_write_boot_mode((cmd ? (u8)*cmd : 0));
} else if (cpu_is_omap44xx()) {
omap4_prminst_global_warm_sw_reset(); /* never returns */
+ } else if (soc_is_am33xx()) {
+ am33xx_prm_global_warm_sw_reset(); /* never returns */
} else {
WARN_ON(1);
}
diff --git a/arch/arm/mach-omap2/prm33xx.c b/arch/arm/mach-omap2/prm33xx.c
index 53ec9cb..657c3d0 100644
--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -135,6 +135,21 @@ int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0;
}
+void am33xx_prm_global_warm_sw_reset(void)
+{
+ u32 v;
+
+ v = am33xx_prm_read_reg(AM33XX_PRM_DEVICE_MOD,
+ AM33XX_PRM_RSTCTRL_OFFSET);
+ v |= AM33XX_GLOBAL_WARM_SW_RST_MASK;
+ am33xx_prm_write_reg(v, AM33XX_PRM_DEVICE_MOD,
+AM33XX_PRM_RSTCTRL_OFFSET);
+
+ /* OCP barrier */
+ v = am33xx_prm_read_reg(AM33XX_PRM_DEVICE_MOD,
+ AM33XX_PRM_RSTCTRL_OFFSET);
+}
+
static int am33xx_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
{
am33xx_prm_rmw_reg_bits(OMAP_POWERSTATE_MASK,
diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 3f25c56..cdfc694 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -126,4 +126,5 @@ extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16
inst,
extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs);
extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
u16 rstctrl_offs, u16 rstst_offs);
+extern void am33xx_prm_global_warm_sw_reset(void);
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/20] OMAPDSS: remove initial display code from omapdss
On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote:
Currently omapdss driver sets up the initial connections between
overlays, overlay manager and a panel, based on default display
parameter coming from the board file or via module parameters.
This is unnecessary, as it's the higher level component that should
decide what display to use and how. This patch removes the code from
omapdss, and implements similar code to omapfb.
The def_disp module parameter and the default display platform_data
parameter are kept in omapdss, but omapdss doesn't do anything with
them. It will just return the default display name with
dss_get_default_display_name() call, which omapfb uses. This is done to
keep the backward compatibility.
We might need to do something similar for omap_vout and omapdrm also to
set the initial connections.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c |1 +
drivers/video/omap2/dss/display.c| 78 +++---
drivers/video/omap2/omapfb/omapfb-main.c | 77 -
include/video/omapdss.h |1 +
4 files changed, 75 insertions(+), 82 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 685d9a9..4cb669e 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -57,6 +57,7 @@ const char *dss_get_default_display_name(void)
{
return core.default_display_name;
}
+EXPORT_SYMBOL(dss_get_default_display_name);
Since we are exporting this, it might be better to name it
omapdss_get_default_display_name
enum omapdss_version omapdss_get_version(void)
{
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 1e58730..6d33112 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -320,86 +320,21 @@ void omapdss_default_get_timings(struct omap_dss_device
*dssdev,
}
EXPORT_SYMBOL(omapdss_default_get_timings);
-/*
- * Connect dssdev to a manager if the manager is free or if force is specified.
- * Connect all overlays to that manager if they are free or if force is
- * specified.
- */
-static int dss_init_connections(struct omap_dss_device *dssdev, bool force)
+int dss_init_device(struct platform_device *pdev,
+ struct omap_dss_device *dssdev)
{
+ struct device_attribute *attr;
struct omap_dss_output *out;
- struct omap_overlay_manager *mgr;
int i, r;
out = omapdss_get_output_from_dssdev(dssdev);
- WARN_ON(dssdev-output);
- WARN_ON(out-device);
-
r = omapdss_output_set_device(out, dssdev);
if (r) {
DSSERR(failed to connect output to new device\n);
return r;
}
So, we still manage the output-device links in the omapdss driver, but
move the manager-output and overlay-manager links to omapfb. I guess
this is fine. But maybe this split might change based on how generic
panel framework looks like, and how much we want to expose outputs to
fb/drm.
Archit
--
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 09/20] OMAPDSS: add dispc_ovl_enabled()
On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote: Add new dispc function, dispc_ovl_enabled(). This returns if the overlay enable bit is set in the registers. Is this function used by omapdrm? I can't see it being used in the later patches. Archit -- 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] watchdog: omap_wdt: removed disabling in the probe
In NOWAYOUT case it is better to have watchdog always enabled at boot, in order not to leave the system in undefined state in case of userspace failure. Signed-off-by: Raffaele Recalcati lamiapost...@gmail.com --- Tested using http://arago-project.org/git/projects/linux-omap3.git v2.6.37_OMAPPSP_04.02.00.07 commit. drivers/watchdog/omap_wdt.c |8 1 file changed, 8 insertions(+) diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c index 27ab8db..181b939 100644 --- a/drivers/watchdog/omap_wdt.c +++ b/drivers/watchdog/omap_wdt.c @@ -304,8 +304,16 @@ static int __devinit omap_wdt_probe(struct platform_device *pdev) pm_runtime_enable(wdev-dev); pm_runtime_get_sync(wdev-dev); +#ifndef CONFIG_WATCHDOG_NOWAYOUT omap_wdt_disable(wdev); omap_wdt_adjust_timeout(timer_margin); +#else + omap_wdt_adjust_timeout(timer_margin); + omap_wdt_disable(wdev); + omap_wdt_set_timeout(wdev); + omap_wdt_enable(wdev); + omap_wdt_ping(wdev); +#endif wdev-omap_wdt_miscdev.parent = pdev-dev; wdev-omap_wdt_miscdev.minor = WATCHDOG_MINOR; -- 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 11/20] OMAPDSS: HDMI: split power_on/off to two parts
On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote:
There's currently just one power-on function for HDMI, which enables the
IP and the video output. When reading EDID or detecting if a monitor is
connected, we don't need the video output.
Enabling the video output for these operations is not a big problem in
itself, but the quick enable/disable cycles caused by the operations
seem to cause sync lost errors from time to time. Also, this makes it
possible to read the EDID before the full video path has been set up.
This patch splits the hdmi_power_on into two parts, hdmi_power_on_core
and hdmi_power_on_full. The full version does what hdmi_power_on does
currently, and hdmi_power_on_core only enables the core IP. Similar
changes are made for power_off.
Note that these don't allow the HDMI IP to be first enabled, and later
enable the video output, but the HDMI IP will first need to be powered
off before calling the full version. So this is rather limited
implementation, but it fills the needs for reading EDID.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 75
1 file changed, 46 insertions(+), 29 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index c1c5488..50d5a10 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -500,12 +500,9 @@ static void hdmi_compute_pll(struct omap_dss_device
*dssdev, int phy,
DSSDBG(range = %d sd = %d\n, pi-dcofreq, pi-regsd);
}
-static int hdmi_power_on(struct omap_dss_device *dssdev)
+static int hdmi_power_on_core(struct omap_dss_device *dssdev)
{
int r;
- struct omap_video_timings *p;
- struct omap_overlay_manager *mgr = dssdev-output-manager;
- unsigned long phy;
gpio_set_value(hdmi.ct_cp_hpd_gpio, 1);
gpio_set_value(hdmi.ls_oe_gpio, 1);
@@ -521,6 +518,46 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
if (r)
goto err_runtime_get;
+ /* Make selection of HDMI in DSS */
+ dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
+
+ /* Select the dispc clock source as PRCM clock, to ensure that it is not
+* DSI PLL source as the clock selected by DSI PLL might not be
+* sufficient for the resolution selected / that can be changed
+* dynamically by user. This can be moved to single location , say
+* Boardfile.
+*/
+ dss_select_dispc_clk_source(dssdev-clocks.dispc.dispc_fclk_src);
+
+ return 0;
+
+err_runtime_get:
+ regulator_disable(hdmi.vdda_hdmi_dac_reg);
+err_vdac_enable:
+ gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
+ gpio_set_value(hdmi.ls_oe_gpio, 0);
+ return r;
+}
+
+static void hdmi_power_off_core(struct omap_dss_device *dssdev)
+{
+ hdmi_runtime_put();
+ regulator_disable(hdmi.vdda_hdmi_dac_reg);
+ gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
+ gpio_set_value(hdmi.ls_oe_gpio, 0);
We might want to set the DISPC clock source back to DSS_FCK here. Just
in case it was using something else. Having this still won't make things
full proof, but probably slightly better.
Archit
--
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 19/20] OMAPDSS: DISPC: remove dssdev depependency from error handler
On Monday 29 October 2012 01:34 PM, Tomi Valkeinen wrote: On 2012-10-29 09:12, Archit Taneja wrote: Hi, On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote: The dispc error handler tries to fix issues by disabling and enabling panel. This is problematic, as we're trying to remove the dependency from omapdss to the omap_dss_devices. It's also racy, and doesn't really fix anything. This patch removes the use of omap_dss_device from the error handler, and just disables and enables the associated overlay manager. This should produce similar results as the previous solution, without using dssdev. Calling APPLY functions from the DISPC driver seems a bit incorrect. Instead of disabling/enabling the panel, can't we disable/enable the manger by just using DISPC funcs? I agree, but if we don't call apply functions, we're bypassing the locks/etc from apply, and we could end up messing up what apply.c thinks is going on. With my omapdss+omapdrm compatibility patch series I'm moving the error handler to the apply mechanism, so it becomes a bit saner. Okay. Having the error handler in apply would make things better. Archit -- 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/20] OMAPDSS: remove initial display code from omapdss
On 2012-10-29 12:04, Archit Taneja wrote:
On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote:
Currently omapdss driver sets up the initial connections between
overlays, overlay manager and a panel, based on default display
parameter coming from the board file or via module parameters.
This is unnecessary, as it's the higher level component that should
decide what display to use and how. This patch removes the code from
omapdss, and implements similar code to omapfb.
The def_disp module parameter and the default display platform_data
parameter are kept in omapdss, but omapdss doesn't do anything with
them. It will just return the default display name with
dss_get_default_display_name() call, which omapfb uses. This is done to
keep the backward compatibility.
We might need to do something similar for omap_vout and omapdrm also to
set the initial connections.
I believe omapdrm already does this.
For omap_vout... I'm not sure if we can do that. Both omapfb and
omap_vout work at the same time, so they could be setting up the
settings at the same time, perhaps with conflicting values. The reason I
left omap_vout out is that I think omapfb is always used with omap_vout,
thus the config can be left for omapfb. I didn't test this, though.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c |1 +
drivers/video/omap2/dss/display.c| 78
+++---
drivers/video/omap2/omapfb/omapfb-main.c | 77
-
include/video/omapdss.h |1 +
4 files changed, 75 insertions(+), 82 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c
b/drivers/video/omap2/dss/core.c
index 685d9a9..4cb669e 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -57,6 +57,7 @@ const char *dss_get_default_display_name(void)
{
return core.default_display_name;
}
+EXPORT_SYMBOL(dss_get_default_display_name);
Since we are exporting this, it might be better to name it
omapdss_get_default_display_name
True.
enum omapdss_version omapdss_get_version(void)
{
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 1e58730..6d33112 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -320,86 +320,21 @@ void omapdss_default_get_timings(struct
omap_dss_device *dssdev,
}
EXPORT_SYMBOL(omapdss_default_get_timings);
-/*
- * Connect dssdev to a manager if the manager is free or if force is
specified.
- * Connect all overlays to that manager if they are free or if force is
- * specified.
- */
-static int dss_init_connections(struct omap_dss_device *dssdev, bool
force)
+int dss_init_device(struct platform_device *pdev,
+struct omap_dss_device *dssdev)
{
+struct device_attribute *attr;
struct omap_dss_output *out;
-struct omap_overlay_manager *mgr;
int i, r;
out = omapdss_get_output_from_dssdev(dssdev);
-WARN_ON(dssdev-output);
-WARN_ON(out-device);
-
r = omapdss_output_set_device(out, dssdev);
if (r) {
DSSERR(failed to connect output to new device\n);
return r;
}
So, we still manage the output-device links in the omapdss driver, but
move the manager-output and overlay-manager links to omapfb. I guess
this is fine. But maybe this split might change based on how generic
panel framework looks like, and how much we want to expose outputs to
fb/drm.
We can set the output-device link in omapdss because it's a hardware
configuration. A panel is connected to an output, so there's nothing to
configure there. ovls and ovl-mgrs, on the other hand, may be configured
depending on the use cases.
But yes, I wouldn't be surprised if this will be changed with common
panel framework.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 09/20] OMAPDSS: add dispc_ovl_enabled()
On 2012-10-29 12:09, Archit Taneja wrote: On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote: Add new dispc function, dispc_ovl_enabled(). This returns if the overlay enable bit is set in the registers. Is this function used by omapdrm? I can't see it being used in the later patches. Yes, it will be used by omapdrm (or, at least, it can be used). I guess some of these patches don't quite make sense without the final compat-layer work, and modifications to omapdrm. But mostly the doesn't make sense parts are probably just exposing functions that aren't used yet. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 11/20] OMAPDSS: HDMI: split power_on/off to two parts
On 2012-10-29 12:14, Archit Taneja wrote:
On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote:
There's currently just one power-on function for HDMI, which enables the
IP and the video output. When reading EDID or detecting if a monitor is
connected, we don't need the video output.
Enabling the video output for these operations is not a big problem in
itself, but the quick enable/disable cycles caused by the operations
seem to cause sync lost errors from time to time. Also, this makes it
possible to read the EDID before the full video path has been set up.
This patch splits the hdmi_power_on into two parts, hdmi_power_on_core
and hdmi_power_on_full. The full version does what hdmi_power_on does
currently, and hdmi_power_on_core only enables the core IP. Similar
changes are made for power_off.
Note that these don't allow the HDMI IP to be first enabled, and later
enable the video output, but the HDMI IP will first need to be powered
off before calling the full version. So this is rather limited
implementation, but it fills the needs for reading EDID.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 75
1 file changed, 46 insertions(+), 29 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c
b/drivers/video/omap2/dss/hdmi.c
index c1c5488..50d5a10 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -500,12 +500,9 @@ static void hdmi_compute_pll(struct
omap_dss_device *dssdev, int phy,
DSSDBG(range = %d sd = %d\n, pi-dcofreq, pi-regsd);
}
-static int hdmi_power_on(struct omap_dss_device *dssdev)
+static int hdmi_power_on_core(struct omap_dss_device *dssdev)
{
int r;
-struct omap_video_timings *p;
-struct omap_overlay_manager *mgr = dssdev-output-manager;
-unsigned long phy;
gpio_set_value(hdmi.ct_cp_hpd_gpio, 1);
gpio_set_value(hdmi.ls_oe_gpio, 1);
@@ -521,6 +518,46 @@ static int hdmi_power_on(struct omap_dss_device
*dssdev)
if (r)
goto err_runtime_get;
+/* Make selection of HDMI in DSS */
+dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
+
+/* Select the dispc clock source as PRCM clock, to ensure that it
is not
+ * DSI PLL source as the clock selected by DSI PLL might not be
+ * sufficient for the resolution selected / that can be changed
+ * dynamically by user. This can be moved to single location , say
+ * Boardfile.
+ */
+dss_select_dispc_clk_source(dssdev-clocks.dispc.dispc_fclk_src);
+
+return 0;
+
+err_runtime_get:
+regulator_disable(hdmi.vdda_hdmi_dac_reg);
+err_vdac_enable:
+gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
+gpio_set_value(hdmi.ls_oe_gpio, 0);
+return r;
+}
+
+static void hdmi_power_off_core(struct omap_dss_device *dssdev)
+{
+hdmi_runtime_put();
+regulator_disable(hdmi.vdda_hdmi_dac_reg);
+gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
+gpio_set_value(hdmi.ls_oe_gpio, 0);
We might want to set the DISPC clock source back to DSS_FCK here. Just
in case it was using something else. Having this still won't make things
full proof, but probably slightly better.
In this patch I only split the code, keeping the current behavior. But
true, setting the clk src back to DSS_FCK makes sense. Although I'd
rather remove the whole dispc clk src call, as the output drivers
calling it can easily mess things up.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 00/13] ARM: OMAP: remove prcm.[ch]
On 10/26/2012 4:51 AM, Paul Walmsley wrote: Remove arch/arm/mach-omap2/prcm.c and arch/arm/plat-omap/include/plat/prcm.h. This is in preparation for moving the PRM/CM code to drivers/, although to be fair, these files should have been removed a long time ago. Intended for 3.8 cleanup. Applies on top of the existing PRM/CM split cleanup series, and the WDTIMER cleanup series. Paul, By any chance you have branch available with these patches, so that I can validate them here at my end? Thanks, Vaibhav - Paul --- omap2_prcm_cleanup_3.8 text data bss dec hex filename 7521423696876 5613996 13832295 d31067 vmlinux.omap2plus_defconfig.orig 7522239696612 5613996 13832847 d3128f vmlinux.omap2plus_defconfig Paul Walmsley (13): ARM: OMAP2+: common: remove mach-omap2/common.c and map_common_io code ARM: OMAP2/3: PRM: add SoC reset functions (using the CORE DPLL method) ARM: OMAP2xxx: clock: remove global 'dclk' variable ARM: OMAP2xxx: clock: move virt_prcm_set code into clkt2xxx_virt_prcm_set.c ARM: OMAP2+: PRCM: create SoC-specific chip restart functions ARM: OMAP2+: board files: use SoC-specific system restart functions ARM: OMAP2xxx: APLL/CM: convert to use omap2_cm_wait_module_ready() ARM: OMAP2+: CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM functions ARM: OMAP2+: PRCM: remove omap2_cm_wait_idlest() ARM: OMAP2+: PRCM: split and relocate the PRM/CM globals setup ARM: OMAP2+: PRCM: consolidate PRCM-related timeout macros ARM: OMAP2+: hwmod: call to _omap4_disable_module() should use the SoC-specific call ARM: OMAP2+: PRCM: remove obsolete prcm.[ch] arch/arm/mach-omap1/reset.c |2 arch/arm/mach-omap2/Makefile |9 + arch/arm/mach-omap2/am33xx.h |1 arch/arm/mach-omap2/board-2430sdp.c |2 arch/arm/mach-omap2/board-3430sdp.c |2 arch/arm/mach-omap2/board-3630sdp.c |2 arch/arm/mach-omap2/board-4430sdp.c |2 arch/arm/mach-omap2/board-am3517crane.c |2 arch/arm/mach-omap2/board-am3517evm.c|2 arch/arm/mach-omap2/board-apollon.c |2 arch/arm/mach-omap2/board-cm-t35.c | 18 +- arch/arm/mach-omap2/board-cm-t3517.c |2 arch/arm/mach-omap2/board-devkit8000.c |2 arch/arm/mach-omap2/board-generic.c | 10 + arch/arm/mach-omap2/board-h4.c |2 arch/arm/mach-omap2/board-igep0020.c |4 - arch/arm/mach-omap2/board-ldp.c |2 arch/arm/mach-omap2/board-n8x0.c |6 - arch/arm/mach-omap2/board-omap3beagle.c |2 arch/arm/mach-omap2/board-omap3evm.c |2 arch/arm/mach-omap2/board-omap3logic.c |4 - arch/arm/mach-omap2/board-omap3pandora.c |2 arch/arm/mach-omap2/board-omap3stalker.c |2 arch/arm/mach-omap2/board-omap3touchbook.c |2 arch/arm/mach-omap2/board-omap4panda.c |2 arch/arm/mach-omap2/board-overo.c|2 arch/arm/mach-omap2/board-rm680.c|4 - arch/arm/mach-omap2/board-rx51.c |2 arch/arm/mach-omap2/board-ti8168evm.c|4 - arch/arm/mach-omap2/board-zoom.c |4 - arch/arm/mach-omap2/clkt2xxx_apll.c | 57 ++- arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 36 - arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 70 - arch/arm/mach-omap2/clkt_iclk.c |1 arch/arm/mach-omap2/clock.c | 15 +- arch/arm/mach-omap2/clock.h | 28 arch/arm/mach-omap2/clock2420_data.c | 26 +-- arch/arm/mach-omap2/clock2430_data.c | 26 +-- arch/arm/mach-omap2/clock2xxx.c | 16 -- arch/arm/mach-omap2/clock2xxx.h |9 + arch/arm/mach-omap2/cm-regbits-24xx.h|2 arch/arm/mach-omap2/cm.h | 20 ++- arch/arm/mach-omap2/cm2xxx.c | 128 arch/arm/mach-omap2/cm2xxx.h |4 + arch/arm/mach-omap2/cm2xxx_3xxx.h|8 + arch/arm/mach-omap2/cm3xxx.c | 66 arch/arm/mach-omap2/cm3xxx.h |5 + arch/arm/mach-omap2/cm_common.c | 70 + arch/arm/mach-omap2/cminst44xx.h |2 arch/arm/mach-omap2/common.c | 202 -- arch/arm/mach-omap2/common.h | 111 ++ arch/arm/mach-omap2/control.c| 10 + arch/arm/mach-omap2/control.h|2 arch/arm/mach-omap2/cpuidle34xx.c|1 arch/arm/mach-omap2/display.c|2 arch/arm/mach-omap2/hdq1w.c |4 -
Re: [PATCH 05/20] OMAPDSS: remove initial display code from omapdss
On Monday 29 October 2012 03:55 PM, Tomi Valkeinen wrote:
On 2012-10-29 12:04, Archit Taneja wrote:
On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote:
Currently omapdss driver sets up the initial connections between
overlays, overlay manager and a panel, based on default display
parameter coming from the board file or via module parameters.
This is unnecessary, as it's the higher level component that should
decide what display to use and how. This patch removes the code from
omapdss, and implements similar code to omapfb.
The def_disp module parameter and the default display platform_data
parameter are kept in omapdss, but omapdss doesn't do anything with
them. It will just return the default display name with
dss_get_default_display_name() call, which omapfb uses. This is done to
keep the backward compatibility.
We might need to do something similar for omap_vout and omapdrm also to
set the initial connections.
I believe omapdrm already does this.
For omap_vout... I'm not sure if we can do that. Both omapfb and
omap_vout work at the same time, so they could be setting up the
settings at the same time, perhaps with conflicting values. The reason I
left omap_vout out is that I think omapfb is always used with omap_vout,
thus the config can be left for omapfb. I didn't test this, though.
I thought we could have omap_vout without omapfb, at least we can build
it separately. Anyway, setting initial connections in omap_vout doesn't
seem very important as we generally have both of them together.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c |1 +
drivers/video/omap2/dss/display.c| 78
+++---
drivers/video/omap2/omapfb/omapfb-main.c | 77
-
include/video/omapdss.h |1 +
4 files changed, 75 insertions(+), 82 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c
b/drivers/video/omap2/dss/core.c
index 685d9a9..4cb669e 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -57,6 +57,7 @@ const char *dss_get_default_display_name(void)
{
return core.default_display_name;
}
+EXPORT_SYMBOL(dss_get_default_display_name);
Since we are exporting this, it might be better to name it
omapdss_get_default_display_name
True.
enum omapdss_version omapdss_get_version(void)
{
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 1e58730..6d33112 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -320,86 +320,21 @@ void omapdss_default_get_timings(struct
omap_dss_device *dssdev,
}
EXPORT_SYMBOL(omapdss_default_get_timings);
-/*
- * Connect dssdev to a manager if the manager is free or if force is
specified.
- * Connect all overlays to that manager if they are free or if force is
- * specified.
- */
-static int dss_init_connections(struct omap_dss_device *dssdev, bool
force)
+int dss_init_device(struct platform_device *pdev,
+struct omap_dss_device *dssdev)
{
+struct device_attribute *attr;
struct omap_dss_output *out;
-struct omap_overlay_manager *mgr;
int i, r;
out = omapdss_get_output_from_dssdev(dssdev);
-WARN_ON(dssdev-output);
-WARN_ON(out-device);
-
r = omapdss_output_set_device(out, dssdev);
if (r) {
DSSERR(failed to connect output to new device\n);
return r;
}
So, we still manage the output-device links in the omapdss driver, but
move the manager-output and overlay-manager links to omapfb. I guess
this is fine. But maybe this split might change based on how generic
panel framework looks like, and how much we want to expose outputs to
fb/drm.
We can set the output-device link in omapdss because it's a hardware
configuration. A panel is connected to an output, so there's nothing to
configure there. ovls and ovl-mgrs, on the other hand, may be configured
depending on the use cases.
Yes, that makes sense.
Archit
--
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
[PATCHv5] Input: keypad: Add smsc ece1099 keypad driver
From: G, Manjunath Kondaiah manj...@ti.com
SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
supports a keypad scan matrix of 23*8.This driver uses this
device as a keypad driver.
Tested on omap5430 evm with 3.7-rc1 kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
v4-v5
- changed to use manage resource input framework
- rearrange report event into a seperate api.
- change hex values to lowercase throughout.
- Implement -open and -close apis.
- cleanup of unused variable and structure.
drivers/input/keyboard/Kconfig | 13 +
drivers/input/keyboard/Makefile |1 +
drivers/input/keyboard/smsc-ece1099-keypad.c | 310 ++
3 files changed, 324 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index b4b65af..af3f3d0 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -593,6 +593,19 @@ config KEYBOARD_TWL4030
To compile this driver as a module, choose M here: the
module will be called twl4030_keypad.
+config KEYBOARD_SMSC
+ tristate SMSC ECE1099 keypad support
+ depends on I2C OF
+ depends on MFD_SMSC
+ select INPUT_MATRIXKMAP
+ help
+ Say Y here if your board use the smsc keypad controller
+ for omap5 defconfig. It's safe to say enable this
+ even on boards that don't use the keypad controller.
+
+ To compile this driver as a module, choose M here: the
+ module will be called smsc-ece1099-keypad.
+
config KEYBOARD_XTKBD
tristate XT keyboard
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 44e7600..0f2aa26 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X)+=
tc3589x-keypad.o
obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
+obj-$(CONFIG_KEYBOARD_SMSC)+= smsc-ece1099-keypad.o
obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
diff --git a/drivers/input/keyboard/smsc-ece1099-keypad.c
b/drivers/input/keyboard/smsc-ece1099-keypad.c
new file mode 100644
index 000..04e04fb
--- /dev/null
+++ b/drivers/input/keyboard/smsc-ece1099-keypad.c
@@ -0,0 +1,310 @@
+/*
+ * SMSC_ECE1099 Keypad driver
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/i2c.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/input.h
+#include linux/gpio.h
+#include linux/slab.h
+#include linux/jiffies.h
+#include linux/input/matrix_keypad.h
+#include linux/delay.h
+#include linux/mfd/core.h
+#include linux/mfd/smsc.h
+#include linux/of_gpio.h
+#include linux/of.h
+
+#define KEYPRESS_TIME 200
+
+struct smsc_keypad {
+ unsigned int last_key_state[16];
+ unsigned int last_col;
+ unsigned int last_key_ms[16];
+ unsigned short *keymap;
+ struct i2c_client *client;
+ struct input_dev *input;
+ int rows, cols;
+ int row_shift;
+ bool no_autorepeat;
+ unsignedirq;
+ struct device *dev;
+};
+
+static void smsc_kp_report_event(struct smsc_keypad *kp, int col, int temp)
+{
+ struct input_dev *input = kp-input;
+ int j, code, row;
+ unsigned int new_state[16];
+ unsigned int bits_changed;
+ int this_ms;
+
+ for (j = 0; j kp-rows; j++) {
+ if ((temp 0x01) != 0x00) {
+ temp = temp 1;
+ continue;
+ }
+
+ row = j;
+ new_state[col] = (1 row);
+ bits_changed = kp-last_key_state[col] ^ new_state[col];
+ this_ms = jiffies_to_msecs(jiffies);
+ if (bits_changed != 0 || (!bits_changed
+ ((this_ms - kp-last_key_ms[col]) =
KEYPRESS_TIME))) {
+ code = MATRIX_SCAN_CODE(row, col, kp-row_shift);
+ input_event(input, EV_MSC, MSC_SCAN, code);
+ input_report_key(input, kp-keymap[code], 1);
+ input_report_key(input, kp-keymap[code], 0);
+ kp-last_key_state[col] = new_state[col];
+
Re: Problem with OHCI on OMAP4430
Alan,
On Fri, Oct 26, 2012 at 8:49 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 26 Oct 2012, Mohan V wrote:
When the USB bus is in suspend, a device connected to OHCI port does
not get detected, whereas the device connected to EHCI port is getting
detected.
Can you provide a dmesg log showing the OHCI problem with
CONFIG_USB_DEBUG enabled?
Please find the attached log (ohci-detect.log), where the device is
disconnected from the
OHCI port and then does not get detected when connected again.
We are using android 3.0 kernel.
I'm not going to be able to help very much with an Android kernel.
Does the same problem occur with a vanilla non-Android 3.6 kernel? If
it doesn't, that indicates the problem was caused by some
Android-specific changes.
With the vanilla 3.6 kernel, the device connected to OHCI port is not even
detected. The below messages are seen:
[5.343780] usb 2-2: new low-speed USB device number 5 using ohci-omap3
[5.351776] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out
5ec2 cc 5 -- status -62
[5.570770] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out
5ec2 cc 5 -- status -62
[5.789062] usb 2-2: device not accepting address 5, error -62
[5.795288] hub 2-0:1.0: unable to enumerate USB device on port 2
-
We think it may not be hardware issue, since the device gets detected on
android-3.0 kernel. The support for OHCI on OMAP4430 SDP board
seems to be missing in Linux mainline (3.6).
We ported some OMAP specific patches from android kernel, with this the
device gets detected only if it is connected at boot.
If the system is booted and then device is connected, it doesn't get detected.
Are you referring to this part of the log?
Device not getting detected when
connected---
/ # [ 135.621002] usbhs_wakeup: Enabling clocks
[ 135.625762] usbhs_runtime_resume:++
[ 135.630371] usbhs_runtime_resume:--
[ 135.638183] USB IO PAD Wakeup event triggered##
[ 135.644958] usbhs_runtime_suspend:++
[ 135.649749] usbhs_runtime_suspend:-
It appears that ohci_irq() didn't run. Did
ohci_finish_controller_resume() get called?
This function is not used in ohci-omap3.c and is used only in ohci-omap.c.
Is it necessary to call this function?
My guess is your usbhs_runtime_resume() routine has a bug. Maybe the
usbhs_runtime_suspend() routine does too.
We sometime see the crash in ohci_hub_status_data function. So, when
we add the
below check at the entry of the function, there is no crash. Please
find attached crash log.
(ohci-crash.log)
I don't understand the crash log. What is the cause of the crash? Is
there some error involving spin_lock_irqrestore() in
ohci_hub_status_data()
if (!HC_IS_RUNNING(hcd-state)) {
return 0;
}
But the device does not get detected subsequently with this change. There is
a similar check in ehci-hub.c.
No, there isn't. Not since the 3.1 kernel. In any case, ehci-hcd is
different from ohci-hcd; you shouldn't expect their hub_status_data
routines to be the same.
Ok, I understand.
Thanks,
Mohan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Tested on omap5430 evm with 3.7-rc1 kernel.
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Tested on omap5430 sdp with 3.7-rc1 kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 95 +++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..b812d6d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -140,3 +140,98 @@
mcbsp3 {
status = disabled;
};
+
+i2c5 {
+ clock-frequency = 40;
+
+ smsc@38 {
+ compatible = smscece1099;
+ reg = 0x38;
+ clock = 0x13;
+ keypad {
+ compatible = smsc,keypad;
+ interrupt-parent = gpio5;
+ interrupts = 23; /* gpio line 151 */
+ keypad,num-rows = 8;
+ keypad,num-columns = 16;
+ linux,keymap = 0x20041 /* KEY_F7 */
+ 0x30001 /* KEY_ESC */
+ 0x4003e /* KEY_F4 */
+ 0x50022 /* KEY_G */
+ 0x70023 /* KEY_H */
+ 0x9009a /* KEY_CYCLEWINDOWS */
+ 0xc000e /* KEY_BACKSPACE */
+ 0xd0057 /* KEY_F11 */
+ 0xe009f /* KEY_FORWARD */
+ 0xf006e /* KEY_INSERT */
+ 0x1020036 /* KEY_RIGHTSHIFT */
+ 0x1030011 /* KEY_W */
+ 0x1040010 /* KEY_Q */
+ 0x1050012 /* KEY_E */
+ 0x1070013 /* KEY_R */
+ 0x1080016 /* KEY_U */
+ 0x10c0017 /* KEY_I */
+ 0x10d0067 /* KEY_UP */
+ 0x10e0018 /* KEY_O */
+ 0x10f0019 /* KEY_LEFT */
+ 0x2020003 /* KEY_2 */
+ 0x2040004 /* KEY_1 */
+ 0x2050005 /* KEY_3 */
+ 0x2070008 /* KEY_4 */
+ 0x2080009 /* KEY_7 */
+ 0x20b0064 /* KEY_8 */
+ 0x20c006c /* KEY_RIGHTALT */
+ 0x20d000a /* KEY_DOWN */
+ 0x20e0001 /* KEY_0 */
+ 0x20f006a /* KEY_RIGHT */
+ 0x3010061 /* KEY_RIGHTCTRL */
+ 0x302001f /* KEY_S */
+ 0x303001e /* KEY_A */
+ 0x3040020 /* KEY_D */
+ 0x3050021 /* KEY_F */
+ 0x3070024 /* KEY_J */
+ 0x3080025 /* KEY_K */
+ 0x30c001c /* KEY_ENTER */
+ 0x30d0026 /* KEY_L */
+ 0x30e0027 /* KEY_SEMICOLON */
+ 0x42a /* KEY_LEFTSHIFT */
+ 0x402002d /* KEY_X */
+ 0x403002c /* KEY_Z */
+ 0x404002e /* KEY_C */
+ 0x405002f /* KEY_V */
+ 0x4070032 /* KEY_M */
+ 0x4080033 /* KEY_COMMA */
+ 0x40c0039 /* KEY_SPACE */
+ 0x40d0033 /* KEY_DOT */
+ 0x40e0035 /* KEY_SLASH */
+ 0x40f006b /* KEY_END */
+ 0x501001d /* KEY_LEFTCTRL */
+ 0x5020040 /* KEY_F6 */
+ 0x503000f /* KEY_TAB */
+ 0x504003d /* KEY_F3 */
+ 0x5050014 /* KEY_T */
+ 0x5070015 /* KEY_Y */
+ 0x508001a /* KEY_LEFTBRACE */
+ 0x50d0044 /* KEY_F10 */
+ 0x50e001b /*
Re: [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
Hi Afzal, On 29.10.2012 09:10, Afzal Mohammed wrote: On Thursday 25 October 2012 05:01 AM, Daniel Mack wrote: Thanks for the review. I'll wait for feedback from Afzal next week and then repost. Wanted to see first if that goes in the right direction at all before bordering the DT people with binding details :) I was thinking of a generic approach, where there won't be any check for peripheral device type. But going that path would delay achieving DT, may be let's proceed with your approach to start with so that we can have a minimal level of DT support for GPMC and probably we can make it generic later. While adding new properties, it would be better to keep in mind that we need not change these later once gpmc DT is made generic. Regarding the bindings, there are some generic nand properties like ecc already available, may be that be made use here. Ah, of_get_nand_ecc_mode() - nice. Also perhaps memory size (and offset if needed) to be mapped for peripherals can go with reg property of child. Which detail are you referring to here? The only size property that is effective is the one of the generic GPMC block, and there it's in the reg-property. I'll take the other feedback that I got and quickly do a v2. Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
Hi Daniel, On Monday 29 October 2012 04:45 PM, Daniel Mack wrote: On 29.10.2012 09:10, Afzal Mohammed wrote: Also perhaps memory size (and offset if needed) to be mapped for peripherals can go with reg property of child. Which detail are you referring to here? The only size property that is effective is the one of the generic GPMC block, and there it's in the reg-property. I was referring to that of child, now in gpmc_nand_init(), gpmc_cs_request() is being done, later on if we want to make it generic and remove gpmc_nand_init(), additional information that would be required from DT at least is the memory size to be reserved in gpmc address space for the connected peripheral (assuming gpmc_cs_request() would be done by gpmc driver generically later) What I had in mind was example for external bus in [1], but I had not looked deep into this aspect yet. Regards Afzal [1] http://devicetree.org/Device_Tree_Usage#Memory_Mapped_Devices -- 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/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
Hi Afzal,
On 29.10.2012 12:28, Afzal Mohammed wrote:
On Monday 29 October 2012 04:45 PM, Daniel Mack wrote:
On 29.10.2012 09:10, Afzal Mohammed wrote:
Also perhaps memory size (and offset if
needed) to be mapped for peripherals can go with reg
property of child.
Which detail are you referring to here? The only size property that is
effective is the one of the generic GPMC block, and there it's in the
reg-property.
I was referring to that of child, now in gpmc_nand_init(),
gpmc_cs_request() is being done, later on if we want to
make it generic and remove gpmc_nand_init(), additional
information that would be required from DT at least is the
memory size to be reserved in gpmc address space for
the connected peripheral (assuming gpmc_cs_request()
would be done by gpmc driver generically later)
What I had in mind was example for external bus in [1],
but I had not looked deep into this aspect yet.
Ok, now I see what you mean.
I would say we can use the reg property in child node for CS numbers
purely and if we want to get rid of the memory node allocation, we
should use a property in the gpmc top-node for this, something like:
gpmc: gpmc@5000 {
compatible = ti,gpmc;
cs-regs = 0x5100 0x1000 ...;
};
Changing the meaning of the reg property of children from cs number to
memory sub-region later is something I would like to avoid.
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
Hi Daniel,
On Monday 29 October 2012 06:02 PM, Daniel Mack wrote:
On 29.10.2012 12:28, Afzal Mohammed wrote:
I was referring to that of child, now in gpmc_nand_init(),
gpmc_cs_request() is being done, later on if we want to
make it generic and remove gpmc_nand_init(), additional
information that would be required from DT at least is the
memory size to be reserved in gpmc address space for
the connected peripheral (assuming gpmc_cs_request()
would be done by gpmc driver generically later)
What I had in mind was example for external bus in [1],
but I had not looked deep into this aspect yet.
Ok, now I see what you mean.
I would say we can use the reg property in child node for CS numbers
purely and if we want to get rid of the memory node allocation, we
should use a property in the gpmc top-node for this, something like:
gpmc: gpmc@5000 {
compatible = ti,gpmc;
cs-regs =0x5100 0x1000 ...;
I think you meant cs-regs = 0x ..
0x0 - 0x1fff is gpmc external memory address space, while
0x5000 to plus 16MB is gpmc configuration address space.
You may refer other gpmc peripheral init's that are NOR type.
Changing the meaning of the reg property of children from cs number to
memory sub-region later is something I would like to avoid.
Changing any of the properties later is something we have
to avoid. Let us get feedback from DT maintainers.
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA support for AM335x is not yet added
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 8b4e4f2... 346af5b... M arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 54bfd0c... 3fd95cb... M drivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 30 +++-
3 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 0)
#define HSMMC_HAS_UPDATED_RESET(1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 54bfd0c..3fd95cb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -62,6 +62,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS(1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -89,6 +90,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
@@ -489,6 +491,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -496,7 +499,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
@@ -507,6 +511,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax();
+ /*
+* Enable High-Speed Support
+* Pre-Requisites
+* - Controller should support High-Speed-Enable Bit
+* - Controller should not be using DDR Mode
+* - Controller should advertise that it supports High Speed
+*in capabilities register
+* - MMC/SD clock coming out of controller 25MHz
+*/
+ if ((mmc_slot(host).features HSMMC_HAS_HSPE_SUPPORT)
+ (ios-timing != MMC_TIMING_UHS_DDR50)
+ ((OMAP_HSMMC_READ(host-base, CAPA) HSS) == HSS)) {
+ regval = OMAP_HSMMC_READ(host-base, HCTL);
+ if
Re: [PATCH v2] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND commands
On Fri, Oct 26, 2012 at 08:36:43PM +0100, Christopher Harvey wrote:
In 16bit NAND mode the GPMC would send the command 0xNN as 0xFFNN
instead of 0x00NN on the bus. The 0xFFs were actually uninitialized
bits that were left unset in the GPMC command output register. The
reason they weren't initialized in 16bit mode is that if the same code
that writes to this register was used in 8bit mode then 2 commands
would be output in 8bit mode. One for the low byte, and an extra 0x0
command for the high byte. This commit uses writew if we're using
16bit NAND.
Most chips seem fine with the extra 0xFFs, but the ONFI spec says
otherwise.
Hi Christopher,
Nitpick: I think you should replace 'command' with 'address' in your commit
message.
The ONFI spec says Host should send _address_ byte NN as 0x00NN. It is OK to
send
command NN as 0xFFNN, as explicitly mentioned in ONFI 3.1 spec (section 2.16):
2.16. Bus Width Requirements
All NAND Targets per device shall use the same data bus width. All targets
shall either have an
8-bit bus width or a 16-bit bus width. Note that devices that support the
NV-DDR or NV-DDR2
data interface shall have an 8-bit bus width.
When the host supports a 16-bit bus width, only data is transferred at the
16-bit width. All
address and command line transfers shall use only the lower 8-bits of the data
bus. During
command transfers, the host may place any value on the upper 8-bits of the data
bus. During
address transfers, the host shall set the upper 8-bits of the data bus to 00h.
Your patch deals with both command and address bytes, which does not hurt.
BR,
--
Ivan
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/mtd/nand/omap2.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5b31386..ae6738f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -225,16 +225,20 @@ static void omap_hwcontrol(struct mtd_info *mtd, int
cmd, unsigned int ctrl)
{
struct omap_nand_info *info = container_of(mtd,
struct omap_nand_info, mtd);
+ void __iomem *reg;
if (cmd != NAND_CMD_NONE) {
if (ctrl NAND_CLE)
- writeb(cmd, info-reg.gpmc_nand_command);
-
+ reg = info-reg.gpmc_nand_command;
else if (ctrl NAND_ALE)
- writeb(cmd, info-reg.gpmc_nand_address);
-
+ reg = info-reg.gpmc_nand_address;
else /* NAND_NCE */
- writeb(cmd, info-reg.gpmc_nand_data);
+ reg = info-reg.gpmc_nand_data;
+
+ if (info-nand.options NAND_BUSWIDTH_16)
+ writew(cmd, reg);
+ else
+ writeb(cmd, reg);
}
}
--
1.7.8.6
__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
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] usb: otg: Fix build errors if USB_MUSB_OMAP2PLUS is selected as module
TWL4030_USB TWL6030_USB must depend on USB_MUSB_OMAP2PLUS in Kconfig else we get build errors with CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_OMAP2PLUS=m CONFIG_TWL4030_USB=y CONFIG_TWL6030_USB=y LD init/built-in.o drivers/built-in.o: In function `twl4030_usb_irq': drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl6030_usb_irq': drivers/usb/otg/twl6030-usb.c:230: undefined reference to `omap_musb_mailbox' drivers/usb/otg/twl6030-usb.c:225: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl6030_usbotg_irq': drivers/usb/otg/twl6030-usb.c:259: undefined reference to `omap_musb_mailbox' CC: Peter Meerwald pme...@pmeerw.net Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/otg/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index d8c8a42..6223062 100644 --- a/drivers/usb/otg/Kconfig +++ b/drivers/usb/otg/Kconfig @@ -58,7 +58,7 @@ config USB_ULPI_VIEWPORT config TWL4030_USB tristate TWL4030 USB Transceiver Driver - depends on TWL4030_CORE REGULATOR_TWL4030 + depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL4030 @@ -68,7 +68,7 @@ config TWL4030_USB config TWL6030_USB tristate TWL6030 USB Transceiver Driver - depends on TWL4030_CORE OMAP_USB2 + depends on TWL4030_CORE OMAP_USB2 USB_MUSB_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL6030 -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with OHCI on OMAP4430
On Mon, 29 Oct 2012, Mohan V wrote: I'm not going to be able to help very much with an Android kernel. Does the same problem occur with a vanilla non-Android 3.6 kernel? If it doesn't, that indicates the problem was caused by some Android-specific changes. With the vanilla 3.6 kernel, the device connected to OHCI port is not even detected. The below messages are seen: [5.343780] usb 2-2: new low-speed USB device number 5 using ohci-omap3 [5.351776] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out 5ec2 cc 5 -- status -62 [5.570770] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out 5ec2 cc 5 -- status -62 [5.789062] usb 2-2: device not accepting address 5, error -62 [5.795288] hub 2-0:1.0: unable to enumerate USB device on port 2 It looks like the device was detected just fine but the host was unable to communicate with it. I don't know why; maybe a clock or power line wasn't turned on properly or a PHY wasn't enabled. We think it may not be hardware issue, since the device gets detected on android-3.0 kernel. The support for OHCI on OMAP4430 SDP board seems to be missing in Linux mainline (3.6). We ported some OMAP specific patches from android kernel, with this the device gets detected only if it is connected at boot. If the system is booted and then device is connected, it doesn't get detected. Doesn't get detected, or does get detected but then doesn't communicate? Perhaps you should send some questions to the maintainers of the various ohci-omap drivers or the Android maintainers. Are you referring to this part of the log? Device not getting detected when connected--- / # [ 135.621002] usbhs_wakeup: Enabling clocks [ 135.625762] usbhs_runtime_resume:++ [ 135.630371] usbhs_runtime_resume:-- [ 135.638183] USB IO PAD Wakeup event triggered## [ 135.644958] usbhs_runtime_suspend:++ [ 135.649749] usbhs_runtime_suspend:- It appears that ohci_irq() didn't run. Did ohci_finish_controller_resume() get called? This function is not used in ohci-omap3.c and is used only in ohci-omap.c. Is it necessary to call this function? It is necessary if the driver supports suspend/resume. As far as I can tell, the ohci-omap3 driver does not have this support (at least, not in the 3.6 kernel) whereas the ohci-omap driver does. What driver produced the usbhs_runtime_suspend and usbhs_runtime_resume messages above? (No such messages are present in ohci-omap3.c.) Apparently that driver _does_ support suspend/resume. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
Matt, On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage exposes a bug in the AM33XX clock data for mcasp. After moving to clk_get() usage, the _init() of all registered hwmods fails on mcasp0 due to incorrect clock data causing clk_get() to fail. This causes all successive hwmods to fail to _init() leaving them in a bad state. This patch updates the mcasp clock entries so clk_get() will succeed. It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx boot. I want to test Audio on AM335x Evm with your EDMA patches. I have few patches for AM335x. Can you share the link to the repo branch on which I need to rebase? The patches are related to mcasp dt node, mcasp pinmux in dt, etc... ..snip.. ..snip.. Thanks Regards, Gururaja -- 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] Add FDT support to Pandaboard initialization
* Felipe Balbi ba...@ti.com [121028 23:22]: On Sat, Oct 27, 2012 at 08:50:00PM +0200, Constantine Shulyupin wrote: From: Constantine Shulyupin co...@makelinux.com Problem: - FDT is supported only by generic OMAP board initialization in arch/arm/mach-omap2/board-generic.c and lacks some configurations, which are not yet configured in FDT (USB for example). Solution: - arch/arm/mach-omap2/board-omap4panda.c supports initialization with FDT and without it. Signed-off-by: Constantine Shulyupin co...@makelinux.com NAK, the whole idea of DT is to drop board-*.c. It would be best to see the missing initialization being added to board-generic/dts files. Yes I agree, let's rather get board-generic.c to work with panda. The other board-*.c files will be dropped as soon as we have things usable with devicetree. And we're only two board-*.c files away from making omap4 device tree only ;) I think we are only missing DSS, USB and WLAN bindings to have blaze and panda usable with device tree to the point where everything else can be added later on. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
Hi,
On Mon, Oct 29, 2012 at 06:26:48PM +0530, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA support for AM335x is not yet added
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 8b4e4f2... 346af5b... M
arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 54bfd0c... 3fd95cb... Mdrivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 30
+++-
3 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
High Speed
can't you do runtime revision detection for this ?
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS (1 0)
#define HSMMC_HAS_UPDATED_RESET (1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 54bfd0c..3fd95cb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -62,6 +62,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS (1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -89,6 +90,7 @@
#define MSBS (1 5)
#define BCE (1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR (1 19)
#define DW8 (1 5)
#define CC 0x1
@@ -489,6 +491,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -496,7 +499,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO 16);
not part of $SUBJECT
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
@@ -507,6 +511,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax();
+ /*
+ * Enable High-Speed Support
+ * Pre-Requisites
+ * - Controller should support High-Speed-Enable Bit
+ * - Controller should not be using DDR Mode
+ * - Controller should advertise that it supports High Speed
+ *in capabilities register
+ * - MMC/SD clock coming out of controller 25MHz
+ */
+ if ((mmc_slot(host).features
Re: [RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
On Mon, Oct 29, 2012 at 04:10:26PM +0530, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Tested on omap5430 evm with 3.7-rc1 kernel.
Cc: Felipe Balbi ba...@ti.com
you can change this into an Acked-by: Felipe Balbi ba...@ti.com if you
wish.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Tested on omap5430 sdp with 3.7-rc1 kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 95
+++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..b812d6d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -140,3 +140,98 @@
mcbsp3 {
status = disabled;
};
+
+i2c5 {
+ clock-frequency = 40;
+
+ smsc@38 {
+ compatible = smscece1099;
+ reg = 0x38;
+ clock = 0x13;
+ keypad {
+ compatible = smsc,keypad;
+ interrupt-parent = gpio5;
+ interrupts = 23; /* gpio line 151 */
+ keypad,num-rows = 8;
+ keypad,num-columns = 16;
+ linux,keymap = 0x20041 /* KEY_F7 */
+ 0x30001 /* KEY_ESC */
+ 0x4003e /* KEY_F4 */
+ 0x50022 /* KEY_G */
+ 0x70023 /* KEY_H */
+ 0x9009a /* KEY_CYCLEWINDOWS */
+ 0xc000e /* KEY_BACKSPACE */
+ 0xd0057 /* KEY_F11 */
+ 0xe009f /* KEY_FORWARD */
+ 0xf006e /* KEY_INSERT */
+ 0x1020036 /* KEY_RIGHTSHIFT */
+ 0x1030011 /* KEY_W */
+ 0x1040010 /* KEY_Q */
+ 0x1050012 /* KEY_E */
+ 0x1070013 /* KEY_R */
+ 0x1080016 /* KEY_U */
+ 0x10c0017 /* KEY_I */
+ 0x10d0067 /* KEY_UP */
+ 0x10e0018 /* KEY_O */
+ 0x10f0019 /* KEY_LEFT */
+ 0x2020003 /* KEY_2 */
+ 0x2040004 /* KEY_1 */
+ 0x2050005 /* KEY_3 */
+ 0x2070008 /* KEY_4 */
+ 0x2080009 /* KEY_7 */
+ 0x20b0064 /* KEY_8 */
+ 0x20c006c /* KEY_RIGHTALT */
+ 0x20d000a /* KEY_DOWN */
+ 0x20e0001 /* KEY_0 */
+ 0x20f006a /* KEY_RIGHT */
+ 0x3010061 /* KEY_RIGHTCTRL */
+ 0x302001f /* KEY_S */
+ 0x303001e /* KEY_A */
+ 0x3040020 /* KEY_D */
+ 0x3050021 /* KEY_F */
+ 0x3070024 /* KEY_J */
+ 0x3080025 /* KEY_K */
+ 0x30c001c /* KEY_ENTER */
+ 0x30d0026 /* KEY_L */
+ 0x30e0027 /* KEY_SEMICOLON */
+ 0x42a /* KEY_LEFTSHIFT */
+ 0x402002d /* KEY_X */
+ 0x403002c /* KEY_Z */
+ 0x404002e /* KEY_C */
+ 0x405002f /* KEY_V */
+ 0x4070032 /* KEY_M */
+ 0x4080033 /* KEY_COMMA */
+ 0x40c0039 /* KEY_SPACE */
+ 0x40d0033 /* KEY_DOT */
+ 0x40e0035 /* KEY_SLASH */
+ 0x40f006b /* KEY_END */
+ 0x501001d /* KEY_LEFTCTRL */
+ 0x5020040 /* KEY_F6 */
+ 0x503000f /* KEY_TAB */
+ 0x504003d /* KEY_F3 */
+ 0x5050014 /* KEY_T */
+ 0x5070015 /* KEY_Y */
+ 0x508001a /* KEY_LEFTBRACE */
+
Re: [PATCHv5] Input: keypad: Add smsc ece1099 keypad driver
Hi,
On Mon, Oct 29, 2012 at 04:08:49PM +0530, Sourav Poddar wrote:
+static int __devinit
+smsc_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct input_dev *input;
+ struct smsc_keypad *kp;
+ int ret = 0;
+ int i, max_keys, row_shift;
+ int irq;
+ int addr;
+
+ kp = devm_kzalloc(dev, sizeof(*kp), GFP_KERNEL);
+
+ input = devm_input_allocate_device(dev);
+ if (!kp || !input)
+ ret = -ENOMEM;
+
+ ret = smsc_keypad_parse_dt(dev, kp);
+ if (ret)
+ return ret;
+
+ /* Get the debug Device */
+ kp-input = input;
+ kp-irq = platform_get_irq(pdev, 0);
+ kp-dev = dev;
+
+ /* setup input device */
+ __set_bit(EV_KEY, input-evbit);
+
+ /* Enable auto repeat feature of Linux input subsystem */
+ if (!kp-no_autorepeat)
+ __set_bit(EV_REP, input-evbit);
+
+ input_set_capability(input, EV_MSC, MSC_SCAN);
+ input-name = SMSC Keypad;
+ input-phys = smsc_keypad/input0;
+ input-dev.parent = pdev-dev;
+ input-id.bustype = BUS_HOST;
+ input-id.vendor= 0x0001;
+ input-id.product = 0x0001;
+ input-id.version = 0x0003;
+
+ input-open = smsc_keypad_open;
+ input-close = smsc_keypad_close;
+ input_set_drvdata(input, kp);
+
+ /* Mask all GPIO interrupts (0x37-0x3B) */
+ for (addr = SMSC_GPIO_INT_MASK_START;
+ addr SMSC_GPIO_INT_MASK_START + 4; addr++)
+ smsc_write(dev, addr, 0);
+
+ /* Set all outputs high (0x05-0x09) */
+ for (addr = SMSC_GPIO_DATA_OUT_START;
+ addr SMSC_GPIO_DATA_OUT_START + 4; addr++)
+ smsc_write(dev, addr, 0xff);
+
+ /* Clear all GPIO interrupts (0x32-0x36) */
+ for (addr = SMSC_GPIO_INT_STAT_START;
+ addr SMSC_GPIO_INT_STAT_START + 4; addr++)
+ smsc_write(dev, addr, 0xff);
+
+ /* Configure the smsc pins as Keyboard scan Input */
+ for (i = 0; i kp-rows; i++) {
+ addr = 0x12 + i;
+ smsc_write(dev, addr, SMSC_KP_KSI);
+ }
+
+ /* Configure the smsc pins as Keyboard scan output */
+ for (i = 0; i kp-cols; i++) {
+ addr = 0x1a + i;
+ smsc_write(dev, addr, SMSC_KP_KSO);
+ }
+
+ smsc_write(dev, SMSC_KP_INT_STAT, SMSC_KP_SET_HIGH);
+ smsc_write(dev, SMSC_WKUP_CTRL, SMSC_KP_SET_LOW_PWR);
+ smsc_write(dev, SMSC_KP_OUT, SMSC_KSO_ALL_LOW);
+
+ row_shift = get_count_order(kp-cols);
+ max_keys = kp-rows row_shift;
+
+ kp-row_shift = row_shift;
+ kp-keymap = devm_kzalloc(dev, max_keys * sizeof(kp-keymap[0]),
+ GFP_KERNEL);
+ if (!kp-keymap) {
+ dev_err(dev, Not enough memory for keymap\n);
+ return -ENOMEM;
+ }
+
+ ret = matrix_keypad_build_keymap(NULL, NULL, kp-rows,
+ kp-cols, kp-keymap, input);
+ if (ret) {
+ dev_err(dev, failed to build keymap\n);
+ return ret;
+ }
+
+ /*
+ * This ISR will always execute in kernel thread context because of
+ * the need to access the SMSC over the I2C bus.
+ */
+ ret = devm_request_threaded_irq(dev, kp-irq, NULL, do_kp_irq,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT, pdev-name, kp);
+ if (ret) {
+ dev_dbg(dev, request_irq failed for irq no=%d\n,
+ irq);
+ return ret;
+ }
+
+ ret = input_register_device(input);
+ if (ret) {
+ dev_err(kp-dev,
+ Unable to register twl4030 keypad device\n);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __devexit smsc_remove(struct platform_device *pdev)
+{
shouldn't you unregister the input device here ??
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] ARM: OMAP1: usb: fix sparse warnings
On Fri, Oct 26, 2012 at 09:28:58PM +, Paul Walmsley wrote:
Resolve the following sparse warnings:
arch/arm/mach-omap1/usb.c:304:12: warning: symbol 'omap1_usb0_init' was not
declared. Should it be static?
arch/arm/mach-omap1/usb.c:412:12: warning: symbol 'omap1_usb1_init' was not
declared. Should it be static?
arch/arm/mach-omap1/usb.c:478:12: warning: symbol 'omap1_usb2_init' was not
declared. Should it be static?
by declaring those functions as static.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Cc: Felipe Balbi ba...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
Applies on linux-omap/omap-for-v3.8/cleanup-headers.
arch/arm/mach-omap1/usb.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 84267ed..104fed3 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -301,7 +301,7 @@ static inline void otg_device_init(struct omap_usb_config
*pdata)
#endif
-u32 __init omap1_usb0_init(unsigned nwires, unsigned is_device)
+static u32 __init omap1_usb0_init(unsigned nwires, unsigned is_device)
{
u32 syscon1 = 0;
@@ -409,7 +409,7 @@ u32 __init omap1_usb0_init(unsigned nwires, unsigned
is_device)
return syscon1 16;
}
-u32 __init omap1_usb1_init(unsigned nwires)
+static u32 __init omap1_usb1_init(unsigned nwires)
{
u32 syscon1 = 0;
@@ -475,7 +475,7 @@ bad:
return syscon1 20;
}
-u32 __init omap1_usb2_init(unsigned nwires, unsigned alt_pingroup)
+static u32 __init omap1_usb2_init(unsigned nwires, unsigned alt_pingroup)
{
u32 syscon1 = 0;
--
1.7.10.4
--
balbi
signature.asc
Description: Digital signature
Re: [RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Tested on omap5430 evm with 3.7-rc1 kernel.
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Tested on omap5430 sdp with 3.7-rc1 kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 95
+++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..b812d6d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -140,3 +140,98 @@
mcbsp3 {
status = disabled;
};
+
+i2c5 {
+ clock-frequency = 40;
+
+ smsc@38 {
+ compatible = smscece1099;
+ reg = 0x38;
+ clock = 0x13;
What does that clock mean?
I cannot find that in the binding documentation. BTW, did you add that
documentation in the driver patch?
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mmc: omap_hsmmc: Fix NULL pointer dereference for dt boot
Hi, On Mon, Oct 15 2012, Venkatraman S wrote: From: Balaji T K balaj...@ti.com dev-platform_data is NULL in case of device tree boot, instead use the saved version in struct omap_hsmmc_host. Signed-off-by: Balaji T K balaj...@ti.com Signed-off-by: Venkatraman S svenk...@ti.com Thanks, pushed to mmc-next for 3.7. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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/4] MMC: omap_hsmmc: claim pinctrl at probe time
Hi, On Mon, Oct 15 2012, Venkatraman S wrote: From: Daniel Mack zon...@gmail.com This allows DT-driven board to set up the pin mux only when the driver is in use. Signed-off-by: Daniel Mack zon...@gmail.com Thanks, pushed to mmc-next for 3.8. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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/4] MMC: omap_hsmmc: add DT property for max bus frequency
Hi, On Mon, Oct 15 2012, Venkatraman S wrote: From: Daniel Mack zon...@gmail.com Maximum bus frequency can be limited by external circuitry like level shifters etc. Allow passing this value from DT. Signed-off-by: Daniel Mack zon...@gmail.com Thanks, pushed to mmc-next for 3.8. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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/4] mmc: omap_hsmmc: fix host reference after mmc_free_host
Hi, On Mon, Oct 15 2012, Venkatraman S wrote: From: Balaji T K balaj...@ti.com struct omap_hsmmc_host *host should not be accessed after mmc_free_host(). Reorder mmc_free_host() after iounmap(host-base). Signed-off-by: Balaji T K balaj...@ti.com Signed-off-by: Venkatraman S svenk...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index a33ab74..a3929b7 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2019,8 +2019,8 @@ static int __devexit omap_hsmmc_remove(struct platform_device *pdev) clk_put(host-dbclk); } - mmc_free_host(host-mmc); iounmap(host-base); + mmc_free_host(host-mmc); omap_hsmmc_gpio_free(pdev-dev.platform_data); res = platform_get_resource(pdev, IORESOURCE_MEM, 0); Thanks, pushed to mmc-next for 3.7. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND commands
On Mon, Oct 29, 2012 at 02:49:03PM +0100, Ivan Djelic wrote:
On Fri, Oct 26, 2012 at 08:36:43PM +0100, Christopher Harvey wrote:
In 16bit NAND mode the GPMC would send the command 0xNN as 0xFFNN
instead of 0x00NN on the bus. The 0xFFs were actually uninitialized
bits that were left unset in the GPMC command output register. The
reason they weren't initialized in 16bit mode is that if the same code
that writes to this register was used in 8bit mode then 2 commands
would be output in 8bit mode. One for the low byte, and an extra 0x0
command for the high byte. This commit uses writew if we're using
16bit NAND.
Most chips seem fine with the extra 0xFFs, but the ONFI spec says
otherwise.
Hi Christopher,
Nitpick: I think you should replace 'command' with 'address' in your commit
message.
The ONFI spec says Host should send _address_ byte NN as 0x00NN. It is OK to
send
command NN as 0xFFNN, as explicitly mentioned in ONFI 3.1 spec (section 2.16):
2.16. Bus Width Requirements
All NAND Targets per device shall use the same data bus width. All targets
shall either have an
8-bit bus width or a 16-bit bus width. Note that devices that support the
NV-DDR or NV-DDR2
data interface shall have an 8-bit bus width.
When the host supports a 16-bit bus width, only data is transferred at the
16-bit width. All
address and command line transfers shall use only the lower 8-bits of the
data bus. During
command transfers, the host may place any value on the upper 8-bits of the
data bus. During
address transfers, the host shall set the upper 8-bits of the data bus to 00h.
Your patch deals with both command and address bytes, which does not hurt.
BR,
--
Ivan
Ok, makes sense. Thanks for pointing that out. I'll update the wording.
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/mtd/nand/omap2.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5b31386..ae6738f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -225,16 +225,20 @@ static void omap_hwcontrol(struct mtd_info *mtd, int
cmd, unsigned int ctrl)
{
struct omap_nand_info *info = container_of(mtd,
struct omap_nand_info, mtd);
+ void __iomem *reg;
if (cmd != NAND_CMD_NONE) {
if (ctrl NAND_CLE)
- writeb(cmd, info-reg.gpmc_nand_command);
-
+ reg = info-reg.gpmc_nand_command;
else if (ctrl NAND_ALE)
- writeb(cmd, info-reg.gpmc_nand_address);
-
+ reg = info-reg.gpmc_nand_address;
else /* NAND_NCE */
- writeb(cmd, info-reg.gpmc_nand_data);
+ reg = info-reg.gpmc_nand_data;
+
+ if (info-nand.options NAND_BUSWIDTH_16)
+ writew(cmd, reg);
+ else
+ writeb(cmd, reg);
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mailbox: OMAP: introduce mailbox framework
Actually moving it from plat-omap code as this is supposed to be
under drivers/ folder. This framework should work with the current
OMAP processors that have mailbox and can be used as a method of
interprocessor communication.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/plat-omap/Kconfig | 16 --
arch/arm/plat-omap/Makefile |3 -
arch/arm/plat-omap/mailbox.c | 435 --
drivers/Kconfig |2 +
drivers/Makefile |1 +
drivers/mailbox/Kconfig | 28 +++
drivers/mailbox/Makefile |1 +
drivers/mailbox/mailbox.c| 435 ++
8 files changed, 467 insertions(+), 454 deletions(-)
delete mode 100644 arch/arm/plat-omap/mailbox.c
create mode 100644 drivers/mailbox/Kconfig
create mode 100644 drivers/mailbox/Makefile
create mode 100644 drivers/mailbox/mailbox.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 82fcb20..419648f 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -116,22 +116,6 @@ config OMAP_MUX_WARNINGS
to change the pin multiplexing setup. When there are no warnings
printed, it's safe to deselect OMAP_MUX for your product.
-config OMAP_MBOX_FWK
- tristate Mailbox framework support
- depends on ARCH_OMAP
- help
- Say Y here if you want to use OMAP Mailbox framework support for
- DSP, IVA1.0 and IVA2 in OMAP1/2/3.
-
-config OMAP_MBOX_KFIFO_SIZE
- int Mailbox kfifo default buffer size (bytes)
- depends on OMAP_MBOX_FWK
- default 256
- help
- Specify the default size of mailbox's kfifo buffers (bytes).
- This can also be changed at runtime (via the mbox_kfifo_size
- module parameter).
-
config OMAP_IOMMU_IVA2
bool
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 4bd0ace..4702d1f 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -16,7 +16,4 @@ obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o
obj-y += $(i2c-omap-m) $(i2c-omap-y)
-# OMAP mailbox framework
-obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
-
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
deleted file mode 100644
index cae8692..000
--- a/arch/arm/plat-omap/mailbox.c
+++ /dev/null
@@ -1,435 +0,0 @@
-/*
- * OMAP mailbox driver
- *
- * Copyright (C) 2006-2009 Nokia Corporation. All rights reserved.
- *
- * Contact: Hiroshi DOYU hiroshi.d...@nokia.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include linux/interrupt.h
-#include linux/spinlock.h
-#include linux/mutex.h
-#include linux/delay.h
-#include linux/slab.h
-#include linux/kfifo.h
-#include linux/err.h
-#include linux/notifier.h
-#include linux/module.h
-
-#include linux/platform_data/omap_mailbox.h
-
-static struct omap_mbox **mboxes;
-
-static int mbox_configured;
-static DEFINE_MUTEX(mbox_configured_lock);
-
-static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
-module_param(mbox_kfifo_size, uint, S_IRUGO);
-MODULE_PARM_DESC(mbox_kfifo_size, Size of omap's mailbox kfifo (bytes));
-
-/* Mailbox FIFO handle functions */
-static inline mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
-{
- return mbox-ops-fifo_read(mbox);
-}
-static inline void mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
-{
- mbox-ops-fifo_write(mbox, msg);
-}
-static inline int mbox_fifo_empty(struct omap_mbox *mbox)
-{
- return mbox-ops-fifo_empty(mbox);
-}
-static inline int mbox_fifo_full(struct omap_mbox *mbox)
-{
- return mbox-ops-fifo_full(mbox);
-}
-
-/* Mailbox IRQ handle functions */
-static inline void ack_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
- if (mbox-ops-ack_irq)
- mbox-ops-ack_irq(mbox, irq);
-}
-static inline int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
- return mbox-ops-is_irq(mbox, irq);
-}
-
-/*
- * message sender
- */
-static int __mbox_poll_for_space(struct omap_mbox *mbox)
-{
- int ret = 0, i = 1000;
-
- while (mbox_fifo_full(mbox)) {
- if (mbox-ops-type == OMAP_MBOX_TYPE2)
- return -1;
- if (--i == 0)
-
Re: [PATCHv5] Input: keypad: Add smsc ece1099 keypad driver
On Mon, Oct 29, 2012 at 06:20:45PM +0200, Felipe Balbi wrote:
Hi,
On Mon, Oct 29, 2012 at 04:08:49PM +0530, Sourav Poddar wrote:
+static int __devinit
+smsc_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct input_dev *input;
+ struct smsc_keypad *kp;
+ int ret = 0;
+ int i, max_keys, row_shift;
+ int irq;
+ int addr;
+
+ kp = devm_kzalloc(dev, sizeof(*kp), GFP_KERNEL);
+
+ input = devm_input_allocate_device(dev);
+ if (!kp || !input)
+ ret = -ENOMEM;
+
+ ret = smsc_keypad_parse_dt(dev, kp);
+ if (ret)
+ return ret;
+
+ /* Get the debug Device */
+ kp-input = input;
+ kp-irq = platform_get_irq(pdev, 0);
+ kp-dev = dev;
+
+ /* setup input device */
+__set_bit(EV_KEY, input-evbit);
+
+ /* Enable auto repeat feature of Linux input subsystem */
+ if (!kp-no_autorepeat)
+ __set_bit(EV_REP, input-evbit);
+
+ input_set_capability(input, EV_MSC, MSC_SCAN);
+ input-name = SMSC Keypad;
+ input-phys = smsc_keypad/input0;
+ input-dev.parent = pdev-dev;
+ input-id.bustype = BUS_HOST;
+ input-id.vendor= 0x0001;
+ input-id.product = 0x0001;
+ input-id.version = 0x0003;
+
+ input-open = smsc_keypad_open;
+ input-close = smsc_keypad_close;
+ input_set_drvdata(input, kp);
+
+ /* Mask all GPIO interrupts (0x37-0x3B) */
+ for (addr = SMSC_GPIO_INT_MASK_START;
+ addr SMSC_GPIO_INT_MASK_START + 4; addr++)
+ smsc_write(dev, addr, 0);
+
+ /* Set all outputs high (0x05-0x09) */
+ for (addr = SMSC_GPIO_DATA_OUT_START;
+ addr SMSC_GPIO_DATA_OUT_START + 4; addr++)
+ smsc_write(dev, addr, 0xff);
+
+ /* Clear all GPIO interrupts (0x32-0x36) */
+ for (addr = SMSC_GPIO_INT_STAT_START;
+ addr SMSC_GPIO_INT_STAT_START + 4; addr++)
+ smsc_write(dev, addr, 0xff);
+
+ /* Configure the smsc pins as Keyboard scan Input */
+ for (i = 0; i kp-rows; i++) {
+ addr = 0x12 + i;
+ smsc_write(dev, addr, SMSC_KP_KSI);
+ }
+
+ /* Configure the smsc pins as Keyboard scan output */
+ for (i = 0; i kp-cols; i++) {
+ addr = 0x1a + i;
+ smsc_write(dev, addr, SMSC_KP_KSO);
+ }
+
+ smsc_write(dev, SMSC_KP_INT_STAT, SMSC_KP_SET_HIGH);
+ smsc_write(dev, SMSC_WKUP_CTRL, SMSC_KP_SET_LOW_PWR);
+ smsc_write(dev, SMSC_KP_OUT, SMSC_KSO_ALL_LOW);
+
+ row_shift = get_count_order(kp-cols);
+ max_keys = kp-rows row_shift;
+
+ kp-row_shift = row_shift;
+ kp-keymap = devm_kzalloc(dev, max_keys * sizeof(kp-keymap[0]),
+ GFP_KERNEL);
+ if (!kp-keymap) {
+ dev_err(dev, Not enough memory for keymap\n);
+ return -ENOMEM;
+ }
+
+ ret = matrix_keypad_build_keymap(NULL, NULL, kp-rows,
+ kp-cols, kp-keymap, input);
+ if (ret) {
+ dev_err(dev, failed to build keymap\n);
+ return ret;
+ }
+
+ /*
+ * This ISR will always execute in kernel thread context because of
+ * the need to access the SMSC over the I2C bus.
+ */
+ ret = devm_request_threaded_irq(dev, kp-irq, NULL, do_kp_irq,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT, pdev-name, kp);
+ if (ret) {
+ dev_dbg(dev, request_irq failed for irq no=%d\n,
+ irq);
+ return ret;
+ }
+
+ ret = input_register_device(input);
+ if (ret) {
+ dev_err(kp-dev,
+ Unable to register twl4030 keypad device\n);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __devexit smsc_remove(struct platform_device *pdev)
+{
shouldn't you unregister the input device here ??
And that is why I do not like devm_* interface myself... But no, since
input device was allocated with devm_input_allocate_device() it does not
need to be explicitly freed or unregistered.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
CC: de...@driverdev.osuosl.org
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/mailbox.c |2 +-
arch/arm/plat-omap/include/plat/mailbox.h | 105
arch/arm/plat-omap/mailbox.c |2 +-
.../tidspbridge/include/dspbridge/host_os.h|2 +-
include/linux/platform_data/omap_mailbox.h | 105
5 files changed, 108 insertions(+), 108 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h
create mode 100644 include/linux/platform_data/omap_mailbox.h
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0d97456..f69e659 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -17,7 +17,7 @@
#include linux/io.h
#include linux/pm_runtime.h
-#include plat/mailbox.h
+#include linux/platform_data/omap_mailbox.h
#include soc.h
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
deleted file mode 100644
index cc3921e..000
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ /dev/null
@@ -1,105 +0,0 @@
-/* mailbox.h */
-
-#ifndef MAILBOX_H
-#define MAILBOX_H
-
-#include linux/spinlock.h
-#include linux/workqueue.h
-#include linux/interrupt.h
-#include linux/device.h
-#include linux/kfifo.h
-
-typedef u32 mbox_msg_t;
-struct omap_mbox;
-
-typedef int __bitwise omap_mbox_irq_t;
-#define IRQ_TX ((__force omap_mbox_irq_t) 1)
-#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-
-typedef int __bitwise omap_mbox_type_t;
-#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
-#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
-
-struct omap_mbox_ops {
- omap_mbox_type_ttype;
- int (*startup)(struct omap_mbox *mbox);
- void(*shutdown)(struct omap_mbox *mbox);
- /* fifo */
- mbox_msg_t (*fifo_read)(struct omap_mbox *mbox);
- void(*fifo_write)(struct omap_mbox *mbox, mbox_msg_t msg);
- int (*fifo_empty)(struct omap_mbox *mbox);
- int (*fifo_full)(struct omap_mbox *mbox);
- /* irq */
- void(*enable_irq)(struct omap_mbox *mbox,
- omap_mbox_irq_t irq);
- void(*disable_irq)(struct omap_mbox *mbox,
- omap_mbox_irq_t irq);
- void(*ack_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
- int (*is_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
- /* ctx */
- void(*save_ctx)(struct omap_mbox *mbox);
- void(*restore_ctx)(struct omap_mbox *mbox);
-};
-
-struct omap_mbox_queue {
- spinlock_t lock;
- struct kfifofifo;
- struct work_struct work;
- struct tasklet_struct tasklet;
- struct omap_mbox*mbox;
- bool full;
-};
-
-struct omap_mbox {
- char*name;
- unsigned intirq;
- struct omap_mbox_queue *txq, *rxq;
- struct omap_mbox_ops*ops;
- struct device *dev;
- void*priv;
- int use_count;
- struct blocking_notifier_head notifier;
-};
-
-int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
-void omap_mbox_init_seq(struct omap_mbox *);
-
-struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
-
-int omap_mbox_register(struct device *parent, struct omap_mbox **);
-int omap_mbox_unregister(void);
-
-static inline void omap_mbox_save_ctx(struct omap_mbox *mbox)
-{
- if (!mbox-ops-save_ctx) {
- dev_err(mbox-dev, %s:\tno save\n, __func__);
- return;
- }
-
- mbox-ops-save_ctx(mbox);
-}
-
-static inline void omap_mbox_restore_ctx(struct omap_mbox *mbox)
-{
- if (!mbox-ops-restore_ctx) {
- dev_err(mbox-dev, %s:\tno restore\n, __func__);
- return;
- }
-
- mbox-ops-restore_ctx(mbox);
-}
-
-static inline void omap_mbox_enable_irq(struct omap_mbox *mbox,
- omap_mbox_irq_t irq)
-{
- mbox-ops-enable_irq(mbox, irq);
-}
-
-static inline void omap_mbox_disable_irq(struct omap_mbox *mbox,
-omap_mbox_irq_t irq)
-{
- mbox-ops-disable_irq(mbox, irq);
-}
-
-#endif /* MAILBOX_H */
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 42377ef..cae8692 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -31,7 +31,7 @@
#include linux/notifier.h
#include linux/module.h
-#include plat/mailbox.h
+#include linux/platform_data/omap_mailbox.h
static struct omap_mbox **mboxes;
diff
[PATCH 0/2] ARM: OMAP: mailbox out of plat code
From: Omar Ramirez Luna omar.rami...@copitl.com Move Mailbox's headers and driver out of platform code as per current plat-omap cleanup activities. While at it move mailbox code out of platform and to drivers/ folder, given that this is an OMAP specific framework, some people might frown upon this, however it seemed worth to try to move it now. I was expecting this could also pull out the mailbox code from ux-500 platform, but the platform with a similar mailbox mechanism has been deleted during 3.5 rc cycle. So, are there any other mailbox-like drivers out there? Omar Ramirez Luna (2): ARM: OMAP2+: move mailbox.h out of plat-omap headers mailbox: OMAP: introduce mailbox framework arch/arm/mach-omap2/mailbox.c |2 +- arch/arm/plat-omap/Kconfig | 16 - arch/arm/plat-omap/Makefile|3 - arch/arm/plat-omap/include/plat/mailbox.h | 105 - arch/arm/plat-omap/mailbox.c | 435 drivers/Kconfig|2 + drivers/Makefile |1 + drivers/mailbox/Kconfig| 28 ++ drivers/mailbox/Makefile |1 + drivers/mailbox/mailbox.c | 435 .../tidspbridge/include/dspbridge/host_os.h|2 +- include/linux/platform_data/omap_mailbox.h | 105 + 12 files changed, 574 insertions(+), 561 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h delete mode 100644 arch/arm/plat-omap/mailbox.c create mode 100644 drivers/mailbox/Kconfig create mode 100644 drivers/mailbox/Makefile create mode 100644 drivers/mailbox/mailbox.c create mode 100644 include/linux/platform_data/omap_mailbox.h -- 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
tidspbridge: ARM common zImage?
Hi, On 26 October 2012 13:00, Tony Lindgren t...@atomide.com wrote: ... I would also like to move the tidspbridge to the DMA API, but I think we'll need to move step by step there, and using the OMAP IOMMU and IOVMM APIs as an intermediate step would allow splitting patches in reviewable chunks. I know it's a step backwards in term of OMAP IOMMU usage, but that's in my opinion a temporary nuisance to make the leap easier. Since tidspbridge is in staging I guess it's not a problem, though it sounds to me like using the correct API in the first place is going to make less churn. Not related to these patches, but also sounds like we may need to drop some staging/tidspbridge code to be able to move forward with the ARM common zImage plans. See the [GIT PULL] omap plat header removal for v3.8 merge window, part1 thread for more info. I was trying to find some more info on this, but only found one patch for tidspbridge to delete an include... it seems that I must try with these patches and see what explodes since we heavily abuse prcm code too. Thanks, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: igep0020: Set WIFI/BT GPIO pins in correct mux mode
Configure the WIFI/BT GPIO pin muxes unless the bootloader hasn't already
done so.
Signed-off-by: Anders Hedlund anders.j.hedl...@gmail.com
Cc: Jonas Zetterberg j...@jozz.se
Cc: Enric Balletbo i Serra eballe...@gmail.com
---
arch/arm/mach-omap2/board-igep0020.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index dbc705a..17e45bc 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -579,6 +579,13 @@ static void __init igep_wlan_bt_init(void)
} else
return;
+#ifdef CONFIG_OMAP_MUX
+ /* Make sure that the GPIO pins are muxed correctly */
+ omap_mux_init_gpio(igep_wlan_bt_gpios[0].gpio, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(igep_wlan_bt_gpios[1].gpio, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(igep_wlan_bt_gpios[2].gpio, OMAP_PIN_OUTPUT);
+#endif
+
err = gpio_request_array(igep_wlan_bt_gpios,
ARRAY_SIZE(igep_wlan_bt_gpios));
if (err) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
Hi, --- /dev/null +++ b/include/linux/platform_data/omap_mailbox.h @@ -0,0 +1,105 @@ This file should only contain pure platform data needed by the core omap code to pass to the mailbox driver. The mailbox API header should be somewhere else, like include/linux/mailbox/mailbox-omap.h or similar. But shouldn't this all now be handled by using the remoteproc framework? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [PATCH] remove pcm049 from Makefile
--- arch/arm/mach-omap2/Makefile |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index fe40d9e..d1155be 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -236,8 +236,6 @@ obj-$(CONFIG_MACH_TOUCHBOOK)+= board-omap3touchbook.o obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o -obj-$(CONFIG_MACH_PCM049) += board-omap4pcm049.o - obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o -- 1.7.9.5 -- _ R-S-I Elektrotechnik GmbH Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen Fon: +49 8444 9204-0 Fax: +49 8444 9204-50 www.rsi-elektrotechnik.de _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: igep0020: Set WIFI/BT GPIO pins in correct mux mode
Hi,
Thanks for the patch, just one comment below.
2012/10/29 Anders Hedlund anders.j.hedl...@gmail.com:
Configure the WIFI/BT GPIO pin muxes unless the bootloader hasn't already
done so.
Signed-off-by: Anders Hedlund anders.j.hedl...@gmail.com
Cc: Jonas Zetterberg j...@jozz.se
Cc: Enric Balletbo i Serra eballe...@gmail.com
---
arch/arm/mach-omap2/board-igep0020.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index dbc705a..17e45bc 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -579,6 +579,13 @@ static void __init igep_wlan_bt_init(void)
} else
return;
+#ifdef CONFIG_OMAP_MUX
The ifdef is not required here (the mux.h file does this for you)
+ /* Make sure that the GPIO pins are muxed correctly */
+ omap_mux_init_gpio(igep_wlan_bt_gpios[0].gpio, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(igep_wlan_bt_gpios[1].gpio, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(igep_wlan_bt_gpios[2].gpio, OMAP_PIN_OUTPUT);
+#endif
+
err = gpio_request_array(igep_wlan_bt_gpios,
ARRAY_SIZE(igep_wlan_bt_gpios));
if (err) {
--
1.7.10.4
Tony, after corrections, as this is a fix could be included ? Or we
need to wait to the next merge window.
The problem is, with recent u-boot these pins are not muxed because
u-boot sets only the minimum required for uboot functionality and
kernel boot. In kernel these pins must be muxed in order to get the
wifi and bluetooth work.
( CCing: Javier Martinez and Matthias Brugger )
--
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: igep0020: Set WIFI/BT GPIO pins in correct mux mode
Setup the WIFI/BT GPIO pin muxes to enable WIFI/BT functionality.
Signed-off-by: Anders Hedlund anders.j.hedl...@gmail.com
Cc: Jonas Zetterberg j...@jozz.se
Cc: Enric Balletbo i Serra eballe...@gmail.com
Cc: Javier Martinez Canillas martinez.jav...@gmail.com
Cc: Matthias Brugger mbrug...@iseebcn.com
---
arch/arm/mach-omap2/board-igep0020.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 2821448..2a21947 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -583,6 +583,11 @@ static void __init igep_wlan_bt_init(void)
} else
return;
+ /* Make sure that the GPIO pins are muxed correctly */
+ omap_mux_init_gpio(igep_wlan_bt_gpios[0].gpio, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(igep_wlan_bt_gpios[1].gpio, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(igep_wlan_bt_gpios[2].gpio, OMAP_PIN_OUTPUT);
+
err = gpio_request_array(igep_wlan_bt_gpios,
ARRAY_SIZE(igep_wlan_bt_gpios));
if (err) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5] Input: keypad: Add smsc ece1099 keypad driver
Hi,
On Mon, Oct 29, 2012 at 10:06:33AM -0700, Dmitry Torokhov wrote:
[ big snip ]
+static int __devexit smsc_remove(struct platform_device *pdev)
+{
shouldn't you unregister the input device here ??
And that is why I do not like devm_* interface myself... But no, since
input device was allocated with devm_input_allocate_device() it does not
need to be explicitly freed or unregistered.
IMHO, that's a fragility on current devm implementation for input
devices, then.
devm_input_allocate_device() is *only* allocating the input device (at
least judging by the name). Looks like you should introduce
devm_input_register_device() ? What happens if I
devm_input_allocate_device() but don't go as far as
input_register_device() (some error happens in-between) ?
I'm sure you have some proper handling for it, but it's quite misleading
the way this was implemented.
--
balbi
signature.asc
Description: Digital signature
[PATCH v2] ARM: OMAP3: igep0020: Set WIFI/BT GPIO pins in correct mux mode
Setup the WIFI/BT GPIO pin muxes to enable WIFI/BT functionality.
Signed-off-by: Anders Hedlund anders.j.hedl...@gmail.com
Cc: Jonas Zetterberg j...@jozz.se
Cc: Enric Balletbo i Serra eballe...@gmail.com
Cc: Javier Martinez Canillas martinez.jav...@gmail.com
Cc: Matthias Brugger mbrug...@iseebcn.com
---
arch/arm/mach-omap2/board-igep0020.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 2821448..2a21947 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -583,6 +583,11 @@ static void __init igep_wlan_bt_init(void)
} else
return;
+ /* Make sure that the GPIO pins are muxed correctly */
+ omap_mux_init_gpio(igep_wlan_bt_gpios[0].gpio, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(igep_wlan_bt_gpios[1].gpio, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(igep_wlan_bt_gpios[2].gpio, OMAP_PIN_OUTPUT);
+
err = gpio_request_array(igep_wlan_bt_gpios,
ARRAY_SIZE(igep_wlan_bt_gpios));
if (err) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
In 16bit NAND mode the GPMC would send the address 0xNN as 0xFFNN
instead of 0x00NN on the bus. The 0xFFs were actually uninitialized
bits that were left unset in the GPMC command output register. The
reason they weren't initialized in 16bit mode is that if the same code
that writes to this register was used in 8bit mode then 2 commands
would be output in 8bit mode. One for the low byte, and an extra 0x0
command for the high byte. This commit uses writew if we're using
16bit NAND. This commit also changes the high byte in the command
output register, but they are ignored by NAND chips anyway.
Most chips seem fine with the extra 0xFFs, but the ONFI spec says
otherwise.
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/mtd/nand/omap2.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5b31386..ae6738f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -225,16 +225,20 @@ static void omap_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
{
struct omap_nand_info *info = container_of(mtd,
struct omap_nand_info, mtd);
+ void __iomem *reg;
if (cmd != NAND_CMD_NONE) {
if (ctrl NAND_CLE)
- writeb(cmd, info-reg.gpmc_nand_command);
-
+ reg = info-reg.gpmc_nand_command;
else if (ctrl NAND_ALE)
- writeb(cmd, info-reg.gpmc_nand_address);
-
+ reg = info-reg.gpmc_nand_address;
else /* NAND_NCE */
- writeb(cmd, info-reg.gpmc_nand_data);
+ reg = info-reg.gpmc_nand_data;
+
+ if (info-nand.options NAND_BUSWIDTH_16)
+ writew(cmd, reg);
+ else
+ writeb(cmd, reg);
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi, On Fri, Oct 26, 2012 at 05:03:16PM +0100, Mark Brown wrote: On Fri, Oct 26, 2012 at 09:20:36AM +0300, Felipe Balbi wrote: On Thu, Oct 25, 2012 at 09:59:01PM +0100, Mark Brown wrote: I suspect that's not actually a big deal and that if we went down this route we'd have the driver take over control from the core code during probe() with the core still setting up the default state. Personally I do think we want to be factoring bolierplate out of drivers, if they're not doing anything constructive with pinctrl they should be able to avoid having code for it. There definitely are issues to work through but it seems like we ought to be able to do something. IMHO this will come back to bite you in the *ss. Specially when the same driver is shared among multiple revisions of the same SoC or multiple different SoCs. I'm not entirely sure you fully understood the proposal... Hypothetical situation: OMAP4 has keypad as the default pin mode and low power is handled by the HW, so keypad could have pinctlr boilerplate factored out. Then comes OMAP5 and low power mode has to be handled by SW for whatever reason (maybe there are more than one low power mode). Then we will need to patch omap4-keypad.c to remove dont_touch_my_pins flag and add pinctrl support. This isn't going to make any practical difference at all, as soon as the driver starts using pinctrl explicitly a flag gets set in the driver and the default code does nothing more. The only difference will be that we may get a default configuration applied prior to probe. You could have the driver explicitly set the flag, it would just be one extra line, but it seems marginally nicer to just do it. You didn't get the whole picture I'm afraid. Consider the situation where the same e.g. keypad driver is being used on OMAP4 and OMAP5 and those have different requirements towards pinctrl. Let's just assume for the sake of argument that OMAP4 would set the flag on the driver structure which would tell drivers/base/ to handle pinctrl default automatically and let's assume that's just fine for OMAP4 since sleep mode is handled by HW (all of this is just for the sake of argument, I'm not claiming this is how OMAP4/5 work). Now, we need to add OMAP5 support *to the same keypad driver*. Unfortunately, OMAP5 needs to handle pinctrl explicitly for whatever reason (SW-controlled sleep mode, errata fix, whatever). This will mean that we will have to remove the flag from the keypad driver because that's not valid anymore for OMAP5. What I'm claiming below is that quite possibly all drivers will go through that: - start with transparent pinctrl default mode by letting drivers/base/ automagically take care of that for us. - remove the 'handle-pinctrl-automatically-for-me' flag because of new requirements on different version of the IP. This is why I think hiding things from drivers makes no sense. Also consider the situations Linus W exposed on another subthread. If you change ordering of certain calls, you will really break the functionality of the IP. Because we can't make sure this won't work automagically in all cases (just like we can't make sure $size memory allocation is enough for all drivers) we don't hide that from the driver. We require driver to manage its resources properly. When you think of the possibilities of every single driver going throught that it sounds a lot nicer to not make that decision IMHO and keep pinctrl explicit. I'm just not seeing any impact on drivers that do something interesting here. that's because you didn't consider enough possibilities. See above. How can you make sure that this will work for at least 50% of the drivers ? You just can't. We don't know the implementation details of every arch/soc/platform supported by Linux today to make that decision. IMHO, it's best to require drivers to explicitly setup pin muxing by calling into pinctrl framework. -- balbi signature.asc Description: Digital signature
Re: [PATCHv4 1/2] i2c: omap: re-factor omap_i2c_init function
On Thu, Oct 25, 2012 at 08:13:18PM +0530, Shubhrajyoti D wrote:
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
FWIW:
Reviewed-by: Felipe Balbi ba...@ti.com
(if I have time I will test this tomorrow and reply with a Tested-by)
---
v4: add spaces for readability
drivers/i2c/busses/i2c-omap.c | 74 +++-
1 files changed, 35 insertions(+), 39 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index be329e9..38acf1a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -209,7 +209,6 @@ struct omap_i2c_dev {
u16 pscstate;
u16 scllstate;
u16 sclhstate;
- u16 bufstate;
u16 syscstate;
u16 westate;
u16 errata;
@@ -285,9 +284,34 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
}
}
+static void __omap_i2c_init(struct omap_i2c_dev *dev)
+{
+
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+
+ /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+
+ /* SCL low and high time values */
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+
+ /* Take the I2C module out of reset: */
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+
+ /*
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (dev-iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+}
+
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -337,11 +361,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
dev-westate = OMAP_I2C_WE_ALL;
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- dev-westate);
}
}
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -426,28 +447,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
sclh = fclk_rate / (dev-speed * 2) - 7 + psc;
}
- /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
-
- /* SCL low and high time values */
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
-
- /* Take the I2C module out of reset: */
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
-
/* Enable interrupts */
dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) |
((dev-fifo_size) ? (OMAP_I2C_IE_RDR |
OMAP_I2C_IE_XDR) : 0);
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
- if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- dev-pscstate = psc;
- dev-scllstate = scll;
- dev-sclhstate = sclh;
- dev-bufstate = buf;
- }
+
+ dev-pscstate = psc;
+ dev-scllstate = scll;
+ dev-sclhstate = sclh;
+
+ __omap_i2c_init(dev);
+
return 0;
}
@@ -1267,23 +1278,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
- if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
- * Don't write to this register if the
Re: [PATCHv4 2/2] i2c: omap: make reset a seperate function
On Thu, Oct 25, 2012 at 08:13:19PM +0530, Shubhrajyoti D wrote:
Implement reset as a separate function.
This will enable us to make sure that we don't do the
calculation again on every transfer.
Also at probe the reset is not added as the hwmod is doing that
for us.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
(again, will test tomorrow if I have time)
Next step would be to figure out if it is necessary to reset the IP in
case of error. I don't think so, but only testing will say...
---
some of the errors may not need a reset.
will check and post separate patch.
drivers/i2c/busses/i2c-omap.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 38acf1a..a25b7b0 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -309,15 +309,9 @@ static void __omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
}
-static int omap_i2c_init(struct omap_i2c_dev *dev)
+static int omap_i2c_reset(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0;
- u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
- unsigned long fclk_rate = 1200;
unsigned long timeout;
- unsigned long internal_clk = 0;
- struct clk *fclk;
-
if (dev-rev = OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -363,6 +357,17 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-westate = OMAP_I2C_WE_ALL;
}
}
+ return 0;
+}
+
+static int omap_i2c_init(struct omap_i2c_dev *dev)
+{
+ u16 psc = 0, scll = 0, sclh = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
+ unsigned long fclk_rate = 1200;
+ unsigned long internal_clk = 0;
+ struct clk *fclk;
+
if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -595,7 +600,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
ret = -ETIMEDOUT;
- omap_i2c_init(dev);
+ omap_i2c_reset(dev);
+ __omap_i2c_init(dev);
goto out;
}
@@ -606,7 +612,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
ret = -EIO;
- omap_i2c_init(dev);
+ omap_i2c_reset(dev);
+ __omap_i2c_init(dev);
goto out;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
signature.asc
Description: Digital signature
Re: OMAP baseline test results for v3.7-rc1
Hi, On Fri, Oct 26, 2012 at 10:03:11PM +, Paul Walmsley wrote: Hi Felipe, On Fri, 26 Oct 2012, Felipe Balbi wrote: On Thu, Oct 25, 2012 at 01:12:12PM +0300, Felipe Balbi wrote: On Tue, Oct 23, 2012 at 09:23:03PM +0200, Jean Pihet wrote: On Tue, Oct 23, 2012 at 9:19 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 22 Oct 2012, Jean Pihet wrote: On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Do you have CPU_IDLE enabled? FYI the issue is not present with CPU_IDLE enabled. Hmm, how can you tell? I thought you weren't able to reproduce it with CPU_IDLE disabled either? I could not reproduce the issue, with and without CPU_IDLE enabled. What puzzles me is that the PM QoS code only has influence on the states chosen by cpuidle, so the change should not have any impact with CPU_IDLE enabled. I reallt need to reproduce the issue. Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). I just sent a patch to fix a bug I found on OMAP4 panda but while reading this thread again, I think it could be that it's the same bug which is just easier to reproduce on Paul's setup. Paul, Aaro, can you see if [1] makes the problem go away ? that would be another reason to push [1] during this -rc cycle. [1] http://marc.info/?l=linux-omapm=135115602407925w=2 Thanks for mentioning it, but this patch doesn't fix the I2C timeout problem here. Log fragment below from the 3530ES3 Beagle. that's too bad :-( Can you compile with: CONFIG_I2C_DEBUG_CORE=y CONFIG_I2C_DEBUG_ALGO=y CONFIG_I2C_DEBUG_BUS=y CONFIG_DEFAULT_MESSAGE_LOGLEVEL=9 so that I can see all transfers ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] gpio: omap-gpio: add support for pm_runtime autosuspend
Hi, On Mon, Oct 29, 2012 at 01:53:37PM +0530, Santosh Shilimkar wrote: Just to expand a bit, Out of 6 GPIO banks, GPIO1 bank is in always ON domain where as remaing 5 are in peripheral domain. Letting individual banks idle allowed you let the clock domain idle than keeping all the 6 banks and hence respective clock/power domain in ON state. So the adding timeout might be reasonable but I am not sure about the mod_usage change here. IMHO that whole mod_usage is broken. I remember sending a big series of patches getting rid of that long ago. I _did_ break a few things but just because of omap_gpio_prepare_for_idle() / omap_gpio_resume_from_idle() hackery to get GPIO suspended early enough. Well so far I haven't seen/come across a patch/proposal which fixes it. fair point I still think mod_usage needs to go, so does omap_gpio_prepare_for_idle() and omap_gpio_resume_from_idle(). To me, it looks like that needs to be done on -prepare()/-complete() callbacks of system suspend and the gpio driver needs to learn proper runtime suspend. I am not saying it shouldn't go :-) The $subject patch isn't fixing it correctly is what I said. Don't get hung up on suspend case because thats the easiest way to address it. The issue is with idle where GPIO can prevent SOC idle if it isn't taken care. And since its just an IO, its not easy to implement something like inactivity timer towards autosupend. I don't see the relation here. Care to expand a bit ? Co-processor also makes use of GPIO via syslink proxy and thats make things even harder. that's supposed to be solved with hwspinlock, isn't it ? cheers -- balbi signature.asc Description: Digital signature
Re: [PATCHv5] Input: keypad: Add smsc ece1099 keypad driver
On Mon, Oct 29, 2012 at 09:05:53PM +0200, Felipe Balbi wrote:
Hi,
On Mon, Oct 29, 2012 at 10:06:33AM -0700, Dmitry Torokhov wrote:
[ big snip ]
+static int __devexit smsc_remove(struct platform_device *pdev)
+{
shouldn't you unregister the input device here ??
And that is why I do not like devm_* interface myself... But no, since
input device was allocated with devm_input_allocate_device() it does not
need to be explicitly freed or unregistered.
IMHO, that's a fragility on current devm implementation for input
devices, then.
devm_input_allocate_device() is *only* allocating the input device (at
least judging by the name). Looks like you should introduce
devm_input_register_device() ? What happens if I
devm_input_allocate_device() but don't go as far as
input_register_device() (some error happens in-between) ?
It will be freed automatically.
I'm sure you have some proper handling for it, but it's quite misleading
the way this was implemented.
Well, I could add devm_input_register_device(),
devm_input_unregister_device(), devm_input_free_device() and then add
checks to normal input_register_device(), input_unregister_device()
and input_free_device() to throw warnings and errors if they are used
with managed resources, and similarly add checks to devm_* API so that
they are not called with unmanaged devices and make a big mess out of
it.
_OR_ I could just add one new call devm_input_allocate_device() to
create managed input devices and make the rest of old API work with both
managed and unmanaged input devices. I think the latter is much better.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP3: igep0020: Set WIFI/BT GPIO pins in correct mux mode
Hi Tony and all,
Sorry... please ignore this one. Sent with incorrect Message-Id. A new
(hopefully correct) patch mail has already been sent...
Br,
Anders
2012/10/29 Anders Hedlund anders.j.hedl...@gmail.com:
Setup the WIFI/BT GPIO pin muxes to enable WIFI/BT functionality.
Signed-off-by: Anders Hedlund anders.j.hedl...@gmail.com
Cc: Jonas Zetterberg j...@jozz.se
Cc: Enric Balletbo i Serra eballe...@gmail.com
Cc: Javier Martinez Canillas martinez.jav...@gmail.com
Cc: Matthias Brugger mbrug...@iseebcn.com
---
arch/arm/mach-omap2/board-igep0020.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 2821448..2a21947 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -583,6 +583,11 @@ static void __init igep_wlan_bt_init(void)
} else
return;
+ /* Make sure that the GPIO pins are muxed correctly */
+ omap_mux_init_gpio(igep_wlan_bt_gpios[0].gpio, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(igep_wlan_bt_gpios[1].gpio, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(igep_wlan_bt_gpios[2].gpio, OMAP_PIN_OUTPUT);
+
err = gpio_request_array(igep_wlan_bt_gpios,
ARRAY_SIZE(igep_wlan_bt_gpios));
if (err) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mmc: omap_hsmmc: remove warning message for debounce clock
Hi, On Thu, Oct 25 2012, Tony Lindgren wrote: * Balaji T K balaj...@ti.com [121025 09:00]: MMC debounce clock is applicable only for omap2430, warning message gets printed when enable fails for debounce clock. Remove the get debounce clock failure message as it is noisy for other platforms. Signed-off-by: Balaji T K balaj...@ti.com Reported-by: Russell King rmk+ker...@arm.linux.org.uk This would be good to get in during the -rc cycle if possible to remove the bogus warnings on non-2430 omaps. But since it's been there for a long time, we can wait too if needed. Acked-by: Tony Lindgren t...@atomide.com Thanks; pushed to mmc-next, I'll send it for 3.7. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
[resending, because the first post got rejected due to non-plaintext] Hi Guraraja, I am interested in this thread. I've been trying Gururaja's patches for audio as well. I rebased Guraja's patches on top of Matt's EDMA patches which were applied to the beaglebone 3.7 kernel repo. With some fixes to make it compile with CONFIG_DUMMY_REGULATOR enabled, Currently it breaks at set_dai_fmt in davinci-mcasp.c when an audio file is played. Could you try my tree on EVM? dts changes may be required to use mcasp1 on EVM, https://github.com/joelagnel/linux-kernel/commits/3.7 v3.7-rc2-fixes to v3.7-rc2-audio commits are Gururaja's patches which I applied, and after that are my commits to enable config , add dt data and some fixes. Thanks, Joel On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: Matt, On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage exposes a bug in the AM33XX clock data for mcasp. After moving to clk_get() usage, the _init() of all registered hwmods fails on mcasp0 due to incorrect clock data causing clk_get() to fail. This causes all successive hwmods to fail to _init() leaving them in a bad state. This patch updates the mcasp clock entries so clk_get() will succeed. It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx boot. I want to test Audio on AM335x Evm with your EDMA patches. I have few patches for AM335x. Can you share the link to the repo branch on which I need to rebase? The patches are related to mcasp dt node, mcasp pinmux in dt, etc... ..snip.. ..snip.. Thanks Regards, Gururaja -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.7-rc3
Here are some basic OMAP test results for Linux v3.7-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/ Passing tests - Boot to userspace: 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle: (none) Failing tests: fixed by posted patches -- Boot tests: * 2430sdp: vfp_reload_hw oops during MMC initialization - Kernel attempts to save FP registers that don't exist; fix posted: - http://www.spinics.net/lists/arm-kernel/msg200646.html - added to rmk's patch system as 7566/1 * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - Due to GPMC missing support for DT - Temporary workaround at http://www.spinics.net/lists/arm-kernel/msg200787.html - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 PM tests: * 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend - Causes MMC to become unusable since regulators are not reenabled - Caused by RT throttling - Fixed by http://www.spinics.net/lists/arm-kernel/msg202224.html - Patch in rmk's patch system as 7565/1 * 37xx EVM: CORE not entering dynamic off-idle - Dynamic retention-idle seems to work; system suspend to off works - Happens on both MMC root and NFS root - Can be detected by comparing the CORE off/ret counts from /debug/pm_debug/count before after serial autosuspend occurs - Fixed by http://marc.info/?l=linux-arm-kernelm=135127961519817w=2 * 3530es3beagle: hangs during off-mode dynamic idle test - Appears to be caused by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c: - http://marc.info/?l=linux-omapm=135075364705188w=2 - Fixed by http://www.spinics.net/lists/arm-kernel/msg202116.html Other: * 2420N800: powers down 30 seconds after boot - Presumably due to missing CBUS patches for watchdog control - http://lkml.org/lkml/2012/9/3/265 * 4430es2panda: omap_hwmod: mcpdm: cannot be enabled for reset (3) - clock source is from an external I2C-controlled source - must skip reset until the switchover to hwmod late init - http://www.spinics.net/lists/arm-kernel/msg178138.html Failing tests: needing investigation Boot tests: * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC * CM-T3517: boot hangs with MMC boot - Due to missing MMC setup in board file * 4460pandaes: boot fails early - Appears to be due to X-loader problems here - Need to note the X-loader version so we know it's broken * 3530ES3 Beagle: I2C timeouts during userspace init - Intermittent, appears on 5 out of 6 boots here - Aaro Koskinen observes this also on N900 - Appears to be caused by commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc - http://marc.info/?l=linux-arm-kernelm=135071372426971w=2 PM tests: * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not shown in the current test logs; cause unknown - Pending re-test Other: * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed - Unknown cause; could be due to the lack of hierarchical enable/disable in hwmod code - Jon Hunter reports this does not appear with the same X-loader/bootloader on his 4430ES2.3 Panda, so could be ES-level dependent vmlinux object size (delta in bytes from test_v3.7-rc2 (6f0c0580b70c89094b3422ba81118c7b959c7556)): text data bsstotal kernel +1141 +88 -64+1165 am33xx_only +1037 +32 -48+1021 n800_multi_omap2xxx +1053 +32 -48+1037 n800_only_a +1317 +400+1357 omap1_defconfig +1285 +80+1293 omap1_defconfig_1510innovator_only +1333 +400+1373 omap1_defconfig_5912osk_only +1433 +80 -64+1449 omap2plus_defconfig +10890 -32+1057 omap2plus_defconfig_2430sdp_only +1429 +56 -64+1421 omap2plus_defconfig_cpupm +1377 +880+1465 omap2plus_defconfig_no_pm +1273 -240+1249 omap2plus_defconfig_omap2_4_only +150900+1509 omap2plus_defconfig_omap3_4_only +1746800 +17468 rmk_omap3430_ldp_oldconfig +1033 +560+1089 rmk_omap4430_sdp_oldconfig The 17k increase in the rmk_omap3430_ldp_oldconfig text appears to be due to the automatic selection of CONFIG_PINCTRL by 'make oldnoconfig', new in v3.7-rc3. Boot-time memory difference (delta in bytes from test_v3.7-rc2 (6f0c0580b70c89094b3422ba81118c7b959c7556)) avail rsrvd high freed board
Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
Hi Tero, On Tue, 23 Oct 2012, Tero Kristo wrote: Looks good to me. Only reason I pushed the reset wait to the end of the function was a minimal potential timing optimization. As the beginning of the function will write a register, it will consume a bit of time (especially if in 32k domain), so it can maybe save a single register read in the delay loop if ordered that way. Ah, OK. Your way is probably safer, it might cause problems in some cases if the config is written before reset has completed (can it?) Not sure, but seems to make sense to wait until the reset is done before doing anything to the IP block's registers. Queuing for 3.7-rc fixes, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 12/12] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init
Hi,
On Mon, 11 Jun 2012, Cousson, Benoit wrote:
On 6/11/2012 2:46 AM, Paul Walmsley wrote:
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3613054..86fc513 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2091,6 +2091,18 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
.name = mcpdm,
.class = omap44xx_mcpdm_hwmod_class,
.clkdm_name = abe_clkdm,
+ /*
+* It's suspected that the McPDM requires an off-chip main
+* functional clock, controlled via I2C.
Nit: Is it not suspected, it is a fact. The clock tree clearly indicate that
the mcpdm fclk is generated from the pad_clks.
The IP is a custom link for the Audio IC control / data. using the Audio IC as
a source clock is standard. Since that IP is done only for that purpose, there
is no optional clock path from the PRCM like it is the case for the McASP /
McBSP.
This IP block is
+* currently reset very early during boot, before I2C is
+* available, so it doesn't seem that we have any choice in
+* the kernel other than to avoid resetting it. XXX This is
+* really a hardware issue workaround: every IP block should
+* be able to source its main functional clock from either
+* on-chip or off-chip sources. McPDM seems to be the only
+* current exception.
I do not think this is the right place to put some complaint about the HW :-).
I guess we should just describe the facts.
+*/
+ .flags = HWMOD_EXT_OPT_MAIN_CLK,
I've updated this one to take your comments into account for 3.7-rc fixes.
But...
Could you please update the hints for this IP in the autogen scripts?
I added a comment attribute to add a custom comment on top of the flags entry.
The latest branch is omap5430_for_3.6.
... could you please take care of updating the autogen side? Updated
patch is below.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Mon, 29 Oct 2012 22:02:14 -0600
Subject: [PATCH] ARM: OMAP4: hwmod data: do not enable or reset the McPDM
during kernel init
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Resolve this kernel boot message:
omap_hwmod: mcpdm: cannot be enabled for reset (3)
The McPDM on OMAP4 can only receive its functional clock from an
off-chip source. This source is not guaranteed to be present on the
board, and when present, it is controlled by I2C. This would
introduce a board dependency to the early hwmod code which it was not
designed to handle. Also, neither the driver for this off-chip clock
provider nor the I2C code is available early in boot when the hwmod
code is attempting to enable and reset IP blocks. This effectively
makes it impossible to enable and reset this device during hwmod init.
At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source. (This is true for almost
every IP block on the chip. As far as I know, McPDM is the only
exception.) If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state. Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.
This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag. This prevents the hwmod
code from touching the device early during boot.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Péter Ujfalusi peter.ujfal...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..7bddfa5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2125,6 +2125,14 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
.name = mcpdm,
.class = omap44xx_mcpdm_hwmod_class,
.clkdm_name = abe_clkdm,
+ /*
+* It's suspected that the McPDM requires an off-chip main
+* functional clock, controlled via I2C. This IP block is
+* currently reset very early during boot, before I2C is
+* available, so it doesn't seem that we have any choice in
+* the kernel other than to avoid resetting it.
+*/
+ .flags = HWMOD_EXT_OPT_MAIN_CLK,
.mpu_irqs = omap44xx_mcpdm_irqs,
.sdma_reqs = omap44xx_mcpdm_sdma_reqs,
.main_clk = mcpdm_fck,
--
1.7.10.4
Re: OMAP baseline test results for v3.7-rc1
Hello Jean, On Tue, 23 Oct 2012, Jean Pihet wrote: Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). Had any luck reproducing this one that Aaro I are seeing? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc3
On 10/30/2012 8:06 AM, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/ Passing tests - Boot to userspace: 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle: (none) Failing tests: fixed by posted patches -- Boot tests: * 2430sdp: vfp_reload_hw oops during MMC initialization - Kernel attempts to save FP registers that don't exist; fix posted: - http://www.spinics.net/lists/arm-kernel/msg200646.html - added to rmk's patch system as 7566/1 * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - Due to GPMC missing support for DT - Temporary workaround at http://www.spinics.net/lists/arm-kernel/msg200787.html - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform and its booting up for me without any issues. Jon had submitted another patch which fixes boot issue on Bone. https://patchwork.kernel.org/patch/1606471/ ==Boot Log U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 8000 am335x-bone.dtb reading am335x-bone.dtb 4391 bytes read U-Boot# fatload mmc 0 8100 uImage reading uImage 3841320 bytes read U-Boot# fatload mmc 0 8200 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial U-Boot# bootm 8100 - 8000 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.7.0-rc3 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3841256 Bytes = 3.7 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Kernel Image ... OK OK Loading Device Tree to 8fe65000, end 8fe69126 ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.7.0-rc3 (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Oct 30 09:46:04 IST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] AM335X ES1.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f03000 s12928 r8192 d15744 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 229112k/229112k available, 33032k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06c4b68 (6899 kB) [0.00] .init : 0xc06c5000 - 0xc0715280 ( 321 kB) [0.00] .data : 0xc0716000 - 0xc07a13a0 ( 557 kB) [0.00].bss : 0xc07a13c4 - 0xc0cfbd6c (5483 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 interrupts [0.00] Total of 128 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 2400 Hz [0.00] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [0.00] OMAP clocksource: GPTIMER2 at 2400 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE:
Re: [PATCH] watchdog: omap_wdt: removed disabling in the probe
Hi Raffaele,
On Monday 29 October 2012 04:41 PM, Raffaele Recalcati wrote:
In NOWAYOUT case it is better to have watchdog always enabled at boot,
in order not to leave the system in undefined state in case of userspace
failure.
Signed-off-by: Raffaele Recalcati lamiapost...@gmail.com
---
Tested using http://arago-project.org/git/projects/linux-omap3.git
v2.6.37_OMAPPSP_04.02.00.07 commit.
drivers/watchdog/omap_wdt.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 27ab8db..181b939 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -304,8 +304,16 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
pm_runtime_enable(wdev-dev);
pm_runtime_get_sync(wdev-dev);
+#ifndef CONFIG_WATCHDOG_NOWAYOUT
omap_wdt_disable(wdev);
omap_wdt_adjust_timeout(timer_margin);
+#else
+ omap_wdt_adjust_timeout(timer_margin);
+ omap_wdt_disable(wdev);
+ omap_wdt_set_timeout(wdev);
+ omap_wdt_enable(wdev);
+ omap_wdt_ping(wdev);
IMHO this is not the correct procedure to start the watchdog.
The sequence to start watchdog is something similar in omap_wdt_open()
the steps are:
1) Increment omap_wdt_users
2) Set prescalar value
3) Enable prescalar value
4) Load timer counter value
5) Enable watchdog timer.
In your case you are missing first 3 steps.
After starting the watchdog, there should be some daemon
which pets the watchdog before timeout, if not it will reset the board.
This is also missing in your case.
( This daemon can be achieved by enabling delay interrupt and period)
And there is a pm_runtime_put_sync after you enable your watchdog.
Because of which you get the following warning
omap_hwmod: wd_timer2: _wait_target_disable failed
Below is the patch which might meet your aims.
Please comment on the patch.
Here I enabled delay interrupt and delay period
for petting watchdog before timeout.
watchdog is enabled for all the cases(not only for NOWAYOUT)
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/watchdog/omap_wdt.c | 82
-
drivers/watchdog/omap_wdt.h | 4 +++
2 files changed, 78 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index f5db18db..38e36c1 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -45,6 +45,7 @@
#include linux/uaccess.h
#include linux/slab.h
#include linux/pm_runtime.h
+#include linux/interrupt.h
#include mach/hardware.h
#include plat/cpu.h
#include plat/prcm.h
@@ -57,6 +58,10 @@ static unsigned timer_margin;
module_param(timer_margin, uint, 0);
MODULE_PARM_DESC(timer_margin, initial watchdog timeout (in seconds));
+static int kernelpet = 1;
+module_param(kernelpet, int, 0);
+MODULE_PARM_DESC(kernelpet, pet watchdog in kernel via irq);
+
static unsigned int wdt_trgr_pattern = 0x1234;
static DEFINE_SPINLOCK(wdt_lock);
@@ -66,6 +71,7 @@ struct omap_wdt_dev {
int omap_wdt_users;
struct resource *mem;
struct miscdevice omap_wdt_miscdev;
+ int irq;
};
static void omap_wdt_ping(struct omap_wdt_dev *wdev)
@@ -125,6 +131,7 @@ static void omap_wdt_adjust_timeout(unsigned
new_timeout)
static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
{
u32 pre_margin = GET_WLDR_VAL(timer_margin);
+ u32 delay_period = GET_WLDR_VAL(timer_margin / 2);
void __iomem *base = wdev-base;
/* just count up at 32 KHz */
@@ -134,14 +141,29 @@ static void omap_wdt_set_timeout(struct
omap_wdt_dev *wdev)
__raw_writel(pre_margin, base + OMAP_WATCHDOG_LDR);
while (__raw_readl(base + OMAP_WATCHDOG_WPS) 0x04)
cpu_relax();
+
+ /* Set delay interrupt to half the watchdog interval. */
+ while (__raw_readl(base + OMAP_WATCHDOG_WPS) 1 5)
+ cpu_relax();
+ __raw_writel(delay_period, base + OMAP_WATCHDOG_WDLY);
}
-/*
- * Allow only one task to hold it open
- */
-static int omap_wdt_open(struct inode *inode, struct file *file)
+static irqreturn_t omap_wdt_interrupt(int irq, void *dev_id)
+{
+ struct omap_wdt_dev *wdev = dev_id;
+ void __iomem *base = wdev-base;
+ u32 i;
+
+ i = __raw_readl(base + OMAP_WATCHDOG_WIRQSTAT);
+ __raw_writel(i, base + OMAP_WATCHDOG_WIRQSTAT);
+
+ omap_wdt_ping(wdev);
+
+ return IRQ_HANDLED;
+}
+
+static int omap_wdt_setup(struct omap_wdt_dev *wdev)
{
- struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
void __iomem *base = wdev-base;
if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users)))
@@ -157,12 +179,31 @@ static int omap_wdt_open(struct inode *inode,
struct file *file)
while (__raw_readl(base + OMAP_WATCHDOG_WPS) 0x01)
cpu_relax();
- file-private_data = (void *) wdev;
-
Re: [RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
Hi Benoit,
On Monday 29 October 2012 10:14 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Tested on omap5430 evm with 3.7-rc1 kernel.
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Tested on omap5430 sdp with 3.7-rc1 kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 95 +++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..b812d6d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -140,3 +140,98 @@
mcbsp3 {
status = disabled;
};
+
+i2c5 {
+ clock-frequency = 40;
+
+ smsc@38 {
+ compatible = smscece1099;
+ reg = 0x38;
+ clock = 0x13;
What does that clock mean?
This chip supports a clock control register which is used to enable the
interface used by the chip to communicate. Here, the interface which you
can are
SMBUS interface or BC-LINK interface.
I cannot find that in the binding documentation. BTW, did you add that
documentation in the driver patch?
Nope, I missed out on the dt binding documentation for the driver. :(
Will send a seperate patch for the bindings.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5] Input: keypad: Add smsc ece1099 keypad driver
Hi Felipe,
On Monday 29 October 2012 09:50 PM, Felipe Balbi wrote:
Hi,
On Mon, Oct 29, 2012 at 04:08:49PM +0530, Sourav Poddar wrote:
+static int __devinit
+smsc_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct input_dev *input;
+ struct smsc_keypad *kp;
+ int ret = 0;
+ int i, max_keys, row_shift;
+ int irq;
+ int addr;
+
+ kp = devm_kzalloc(dev, sizeof(*kp), GFP_KERNEL);
+
+ input = devm_input_allocate_device(dev);
+ if (!kp || !input)
+ ret = -ENOMEM;
+
+ ret = smsc_keypad_parse_dt(dev, kp);
+ if (ret)
+ return ret;
+
+ /* Get the debug Device */
+ kp-input = input;
+ kp-irq = platform_get_irq(pdev, 0);
+ kp-dev = dev;
+
+ /* setup input device */
+__set_bit(EV_KEY, input-evbit);
+
+ /* Enable auto repeat feature of Linux input subsystem */
+ if (!kp-no_autorepeat)
+ __set_bit(EV_REP, input-evbit);
+
+ input_set_capability(input, EV_MSC, MSC_SCAN);
+ input-name = SMSC Keypad;
+ input-phys = smsc_keypad/input0;
+ input-dev.parent = pdev-dev;
+ input-id.bustype = BUS_HOST;
+ input-id.vendor= 0x0001;
+ input-id.product = 0x0001;
+ input-id.version = 0x0003;
+
+ input-open = smsc_keypad_open;
+ input-close = smsc_keypad_close;
+ input_set_drvdata(input, kp);
+
+ /* Mask all GPIO interrupts (0x37-0x3B) */
+ for (addr = SMSC_GPIO_INT_MASK_START;
+ addr SMSC_GPIO_INT_MASK_START + 4; addr++)
+ smsc_write(dev, addr, 0);
+
+ /* Set all outputs high (0x05-0x09) */
+ for (addr = SMSC_GPIO_DATA_OUT_START;
+ addr SMSC_GPIO_DATA_OUT_START + 4; addr++)
+ smsc_write(dev, addr, 0xff);
+
+ /* Clear all GPIO interrupts (0x32-0x36) */
+ for (addr = SMSC_GPIO_INT_STAT_START;
+ addr SMSC_GPIO_INT_STAT_START + 4; addr++)
+ smsc_write(dev, addr, 0xff);
+
+ /* Configure the smsc pins as Keyboard scan Input */
+ for (i = 0; i kp-rows; i++) {
+ addr = 0x12 + i;
+ smsc_write(dev, addr, SMSC_KP_KSI);
+ }
+
+ /* Configure the smsc pins as Keyboard scan output */
+ for (i = 0; i kp-cols; i++) {
+ addr = 0x1a + i;
+ smsc_write(dev, addr, SMSC_KP_KSO);
+ }
+
+ smsc_write(dev, SMSC_KP_INT_STAT, SMSC_KP_SET_HIGH);
+ smsc_write(dev, SMSC_WKUP_CTRL, SMSC_KP_SET_LOW_PWR);
+ smsc_write(dev, SMSC_KP_OUT, SMSC_KSO_ALL_LOW);
+
+ row_shift = get_count_order(kp-cols);
+ max_keys = kp-rows row_shift;
+
+ kp-row_shift = row_shift;
+ kp-keymap = devm_kzalloc(dev, max_keys * sizeof(kp-keymap[0]),
+ GFP_KERNEL);
+ if (!kp-keymap) {
+ dev_err(dev, Not enough memory for keymap\n);
+ return -ENOMEM;
+ }
+
+ ret = matrix_keypad_build_keymap(NULL, NULL, kp-rows,
+ kp-cols, kp-keymap, input);
+ if (ret) {
+ dev_err(dev, failed to build keymap\n);
+ return ret;
+ }
+
+ /*
+ * This ISR will always execute in kernel thread context because of
+ * the need to access the SMSC over the I2C bus.
+ */
+ ret = devm_request_threaded_irq(dev, kp-irq, NULL, do_kp_irq,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT, pdev-name, kp);
+ if (ret) {
+ dev_dbg(dev, request_irq failed for irq no=%d\n,
+ irq);
+ return ret;
+ }
+
+ ret = input_register_device(input);
+ if (ret) {
+ dev_err(kp-dev,
+ Unable to register twl4030 keypad device\n);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __devexit smsc_remove(struct platform_device *pdev)
+{
shouldn't you unregister the input device here ??
As Dmitry already pointed out, I was also thinking on the same line that
using devm_* variants
will automatically take care of unregistering your device.
--
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 v3 13/16] ARM: dts: add AM33XX MMC support
On Thu, Oct 18, 2012 at 18:56:52, Porter, Matt wrote:
Adds AM33XX MMC support for am335x-bone and am335x-evm.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |6 ++
arch/arm/boot/dts/am335x-evm.dts |6 ++
arch/arm/boot/dts/am33xx.dtsi | 27 +++
3 files changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..5510979 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -70,6 +70,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
I think these min max limits are regulator limits. Are these fields
required? Add details of these additions. AFAIK fine-tuned (board
specific) min/max limits should be add here(like mpu and core
regulator nodes)
regulator-always-on;
};
@@ -78,3 +80,7 @@
};
};
};
+
+mmc1 {
+ vmmc-supply = ldo3_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..d63fce8 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -114,7 +114,13 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
=same=
regulator-always-on;
};
};
};
+
+mmc1 {
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index ab9c78f..26a6af7 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -234,6 +234,33 @@
status = disabled;
};
+ mmc1: mmc@4806 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
Add status = disabled here and okay in corresponding
.dts file
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc2;
+ ti,needs-special-reset;
+ dmas = edma 2
+ edma 3;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc3: mmc@4781 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc3;
+ ti,needs-special-reset;
What about DMA resources for mmc3?
AnilKumar
+ status = disabled;
+ };
+
wdt2: wdt@44e35000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
--
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
