Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
On Wednesday 20 June 2012 05:09 PM, Tony Lindgren wrote: * Rajendra Nayakrna...@ti.com [120606 22:33]: Hi Tony, On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote: * Rajendra Nayakrna...@ti.com [120601 05:13]: The data is autogenerated using the OMAP autogeneration scripts (python scripts). Thanks to Mike Turquette for the initial efforts in updating the script which was later updated by me. All data is added into a new cclock44xx_data.c file, a later patch will get rid of clock44xx_data.c file. Signed-off-by: Rajendra Nayakrna...@ti.com --- arch/arm/mach-omap2/cclock44xx_data.c | 2602 +++ arch/arm/mach-omap2/clock.h | 17 + arch/arm/mach-omap2/clock_common_data.c | 14 + arch/arm/mach-omap2/scrm44xx.h |2 + 4 files changed, 2635 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c If you are adding new data anyways, why not add it to drivers/clock/omap to start with? Sorry, I missed out on responding to this one. We won't be able to move just the new data but will need all clkops handling around clksel/dpll etc also to be moved, and I was thinking we might end up with 2 issues doing that. We should sort out those issues, sounds like we're missing few interfaces.. -1- We have low level PRM/CM headers and apis used across multiple frameworks for clocks/clockdomains/powerdomains and also some low level PM code. This might get duplicated in drivers/clk and mach-omap2/ Well the PM code should be a loadable module using standard driver interfaces.. Maybe all it takes is adding few functions that both drivers/clk and mach-omap2 code can use without exposing all the registers? Then we may have a better idea what infrastructure pieces are missing. -2- We still need to control clockdomains along with clocks atleast for OMAP2/3 (We should be able to get rid of it for OMAP4+ once all drivers start using omap_device/runtime) and I am not sure how to do it with the clockdomain framework residing in mach-omap2/ Maybe clockdomains could be also handled with some functions without exposing all the registers in the headers? Is moving some of the mach-omap2 headers into mach/include and plat/include and using them in drivers/clk/omap an acceptable first step? I see both the other architectures (imx and spear) in drivers/clk already doing it. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] gpio/omap: cleanups for v3.5
On Thu, Jun 21, 2012 at 8:46 AM, NeilBrown ne...@suse.de wrote:
On Thu, 14 Jun 2012 23:24:10 +0530 DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Jun 14, 2012 at 5:45 AM, NeilBrown ne...@suse.de wrote:
On Fri, 11 May 2012 17:30:48 -0700 Kevin Hilman khil...@ti.com wrote:
Hi Grant,
Here's the final round of GPIO cleanups for v3.5. This branch is based
on my for_3.5/fixes/gpio branch you just pulled.
Kevin
Hi.
I'm not sure if it was this series or the following cleanups which broke
things for me, but I've been trying 3.5-rc2 on my GTA04 and the serial
console (ttyO2) dies as soon as the omap-gpio driver initialises.
After some digging I came up with this patch to gpio-omap.c
@@ -1124,6 +1124,9 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, bank);
+ if (bank-get_context_loss_count)
+ bank-context_loss_count =
+ bank-get_context_loss_count(bank-dev);
pm_runtime_enable(bank-dev);
pm_runtime_irq_safe(bank-dev);
pm_runtime_get_sync(bank-dev);
which fixes it.
What was happening was that when omap_gpio_probe calls
pm_runtime_get_sync,
it calls
_od_runtime_resume - pm_generic_runtime_resume -
omap_gpio_runtime_resume
- omap_gpio_restore_context
and then the serial port stops.
I reasoned that the context probably hadn't been set up yet, so restoring
from it broke things.
Initialising bank-context_loss_count seems sensible and would ensure that
we didn't try to restore the context until it has actually been lost.
I thought the following code exactly does that. That is
context_lost_cnt_after
would be zero until there is context loss. The bank-context_loss_count is
zero
at the beginning. So, (context_lost_cnt_after != bank-context_loss_count)
would
be false and hence context restore should NOT happen? Not sure if I am
over looking
anything here
omap_gpio_runtime_resume(...)
{
...
if (bank-get_context_loss_count) {
context_lost_cnt_after =
bank-get_context_loss_count(bank-dev);
if (context_lost_cnt_after != bank-context_loss_count) {
omap_gpio_restore_context(bank);
} else {
spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
}
...
}
Hi,
I've looked more closely at this now.
The problem is that the initial context loss count is *not* zero. Not always.
The context loss count is the sum of
count = pwrdm-state_counter[PWRDM_POWER_OFF];
count += pwrdm-ret_logic_off_counter;
for (i = 0; i pwrdm-banks; i++)
count += pwrdm-ret_mem_off_counter[i];
(from pwrdm_get_context_loss_count()).
These are initlialised in _pwrdm_register
/* Initialize the powerdomain's state counter */
for (i = 0; i PWRDM_MAX_PWRSTS; i++)
pwrdm-state_counter[i] = 0;
pwrdm-ret_logic_off_counter = 0;
for (i = 0; i pwrdm-banks; i++)
pwrdm-ret_mem_off_counter[i] = 0;
pwrdm_wait_transition(pwrdm);
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
What I'm seeing is that for wkup_pwrdm and dpll{3,4,5}_pwrdm,
the state that pwrdm_read_pwrst returns is PWRDM_POWER_OFF.
So that state_counter gets initialised to '1', and so the initial
context_loss_count, which includes that counter, is also '1'.
I think it is the wkup_pwrdm that covers the GPIOs that are causing problems
for me.
I just put a log in omap_gpio_probe() to see the value of context_loss_count.
GPIO Bank 0 (WKUP Domain) always shows the count as '1'.
[0.169494] omap_gpio omap_gpio.0: context_loss_count=1
[0.170227] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[0.170471] OMAP GPIO hardware version 0.1
[0.170623] omap_gpio omap_gpio.1: context_loss_count=0
[0.170928] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[0.171295] omap_gpio omap_gpio.2: context_loss_count=0
[0.171600] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[0.171936] omap_gpio omap_gpio.3: context_loss_count=0
[0.172241] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[0.172576] omap_gpio omap_gpio.4: context_loss_count=0
[0.172882] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[0.173217] omap_gpio omap_gpio.5: context_loss_count=0
[0.173522] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
--
Tarun
So either there is something seriously wrong with pwrdm_read_pwrst and it
shouldn't be reporting that the wkup_pwrdm is off, or we need to initialise
bank-context_loss_count like my patch does.
NeilBrown
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
RE: [PATCH v2 2/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Jon, On Thu, Jun 21, 2012 at 03:41:39, Hunter, Jon wrote: Ok, I see your point. So today the _set_async_mode() is really doing two things ... 1. It is calculating the timings 2. Programming the timings and setting async mode. I think that it would be best if we were to make _set_async_mode() into two functions, for example ... 1. omap2_onenand_get_async_timings() 2. omap2_onenand_set_async_timings() Where the omap2_onenand_get_async_timings() calculates the timings and can be used in both legacy mode and with the driver. Then omap2_onenand_set_sync_timings() is just used in the legacy mode where we don't have the driver to configure the chip-select. Do you think that could work? We could also do the same for omap2_onenand_set_sync_mode(). Seems it should work Not sure whether the best time to do such kind of refactoring is at the time of cleaning up / generalizing timing calculation, one reason to think that way being removal of legacy mode once driver migration is completed. Goal for this series was to do the minimal of changes, without creating any disruptive changes to prepare for gpmc driver series so that both interfaces would work. Either way I will go ahead and make change as per your suggestions, seems at least there is one advantage; w.r.t bringing setting bool type time settings to gpmc_cs_set_timings (even though may not be necessary for this change, it will certainly simplify it) and make it part of driver preparation series and this will help us discover if any board depends on these kinds of settings unknowingly with the preparation series itself rather than hunting for it in driver series 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: [PATCHv8 06/13] I2C: OMAP: Correct I2C revision for OMAP3
On Wed, Jun 20, 2012 at 7:44 PM, Tony Lindgren t...@atomide.com wrote:
* Shubhrajyoti shubhrajy...@ti.com [120620 06:06]:
On Wednesday 20 June 2012 04:02 PM, Tony Lindgren wrote:
* Shubhrajyoti D shubhrajy...@ti.com [120618 07:35]:
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has
the
same I2C revision as OMAP4. Correct the revision definition to reflect
this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
...
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
dev-syscstate = SYSC_AUTOIDLE_MASK;
dev-syscstate |= SYSC_ENAWAKEUP_MASK;
dev-syscstate |= (SYSC_IDLEMODE_SMART
Having to patch all over the place for these revision defines leads
into unmaintainable code as new SoCs get added.
Please instead just check the revision once during init, then set
up some feature bits like I2C_OMAP_NEEDS_XYZ_RESET that the runtime
code can check.
Even now at probe
dev-rev is set by reading the rev register.
The (macro)name used to identify is only changed.
Also all the ips need reset the difference is that 2430 has less bits eg
only autoidle and reset.
So a flag needs reset may not be meaningful.
Hmm OK so this is a cosmetic/readability fix..
Yes
..but your earlier patch now spreads the checking of revision
to the new non-init function omap_i2c_reset.
Why don't you just do this cosmetic/readability rename fix
before your 03/13 patch?
OK thats doable.I can reorder the patch.
Then set the already existing
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE during init for some
revisions and use that instead of the rev check in
omap_i2c_reset?
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE is a hwmod flag whose intention is to find
know if it can lose context after idle.
The rev check that we have is because post reset( triggered by driver)
to know if we have to restore only autoidle or other bits like clockactivity
sidle , enable wakeup .
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
* Rajendra Nayak rna...@ti.com [120620 23:33]: On Wednesday 20 June 2012 05:09 PM, Tony Lindgren wrote: * Rajendra Nayakrna...@ti.com [120606 22:33]: Hi Tony, On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote: * Rajendra Nayakrna...@ti.com [120601 05:13]: The data is autogenerated using the OMAP autogeneration scripts (python scripts). Thanks to Mike Turquette for the initial efforts in updating the script which was later updated by me. All data is added into a new cclock44xx_data.c file, a later patch will get rid of clock44xx_data.c file. Signed-off-by: Rajendra Nayakrna...@ti.com --- arch/arm/mach-omap2/cclock44xx_data.c | 2602 +++ arch/arm/mach-omap2/clock.h | 17 + arch/arm/mach-omap2/clock_common_data.c | 14 + arch/arm/mach-omap2/scrm44xx.h |2 + 4 files changed, 2635 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c If you are adding new data anyways, why not add it to drivers/clock/omap to start with? Sorry, I missed out on responding to this one. We won't be able to move just the new data but will need all clkops handling around clksel/dpll etc also to be moved, and I was thinking we might end up with 2 issues doing that. We should sort out those issues, sounds like we're missing few interfaces.. -1- We have low level PRM/CM headers and apis used across multiple frameworks for clocks/clockdomains/powerdomains and also some low level PM code. This might get duplicated in drivers/clk and mach-omap2/ Well the PM code should be a loadable module using standard driver interfaces.. Maybe all it takes is adding few functions that both drivers/clk and mach-omap2 code can use without exposing all the registers? Then we may have a better idea what infrastructure pieces are missing. -2- We still need to control clockdomains along with clocks atleast for OMAP2/3 (We should be able to get rid of it for OMAP4+ once all drivers start using omap_device/runtime) and I am not sure how to do it with the clockdomain framework residing in mach-omap2/ Maybe clockdomains could be also handled with some functions without exposing all the registers in the headers? Is moving some of the mach-omap2 headers into mach/include and plat/include and using them in drivers/clk/omap an acceptable first step? I see both the other architectures (imx and spear) in drivers/clk already doing it. Yes if it helps to get things going. But it would be best to split the headers into common and private headers so only minimal amount of shared registers are defined in plat/include and mach/include. Otherwise those defines will get misused all over the place. Also note that names for the headers in plat/include and mach/include need to be omap specific for common zImage support. 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: [PATCHv8 03/13] I2C: OMAP: Remove reset at init
On Wednesday 20 June 2012 03:59 PM, Tony Lindgren wrote: See the comments regarding driver specific resets in hwmod code. you mean omap_hwmod.c The way to set this up is to have a shared inline function in i2c-omap.h that both the driver and hwmod code can use. hwmod reset function uses oh (omap_hwmod). How could the driver also pass oh ? Could we keep a local copy in driver data? Eventually hwmod code will do the reset only in late initcall if no driver is loaded for the device in question. -- To unsubscribe from this list: send the line unsubscribe 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: MFD USB host: prevents CORE retention in idle
On Wed, Jun 20, 2012 at 7:53 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. Failing in what way? Did you debug any further? It may be failing because of problems with the USB host driver, which is what I'm needing you to debug. The suspend/resume was failing even without USB in the mainline kernel image. I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume. Anyways... To get current l-o master to succesfully suspend/resume, you need 3 things: 1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master) 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n 3) for for 32k timer which is also preventing CORE retention http://marc.info/?l=linux-omapm=13453229888w=2 With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms. Kevin I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB on beagle XM. I suggested using l-o master as a baseline, not -rc2. I just pushed a branch with this baseline so we are sure to be testing the same baseline. Please use the 'tmp/test/usb-host' branch from my tree[1] as the starting point. Build using omap2plus_defconfig, boot, then suspend/resume and send the output of 'cat /debug/pm_debug/count' This baseline is working fine for me on 3430/n900, 3530/Overo and 3630/Beagle-xM. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host' I am seeing only the branch /wip/arm-nohz-cpusets other than master. I didn't any usb-host branch here too: http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 03/13] I2C: OMAP: Remove reset at init
* Shubhrajyoti shubhrajy...@ti.com [120621 00:08]: On Wednesday 20 June 2012 03:59 PM, Tony Lindgren wrote: See the comments regarding driver specific resets in hwmod code. you mean omap_hwmod.c The way to set this up is to have a shared inline function in i2c-omap.h that both the driver and hwmod code can use. hwmod reset function uses oh (omap_hwmod). How could the driver also pass oh ? Could we keep a local copy in driver data? Eventually hwmod code will do the reset only in late initcall if no driver is loaded for the device in question. There's no need for the driver to know anything about oh. The driver just needs to know the iobase. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data
Hi Ricardo,
Thanks for the update.
On 6/21/2012 1:10 AM, Ricardo Neri wrote:
As per the OMAP4 documentation, audio over HDMI should be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmode uses
no-idle/force-idle settings instead of smart-idle mode.
This is required as the DSS interface clock is used as functional clock
for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
be choppy, have bad quality or not be audible at all.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
Paul,
Will you take it as part of your fixes series for 3.5-rc?
Regards,
Benoit
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..0cd6ee1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -865,6 +865,11 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
},
.opt_clks = dss_hdmi_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(dss_hdmi_opt_clks),
+ /*
+* HDMI audio requires to use no-idle mode. Hence,
+* set idle mode by software.
+*/
+ .flags = HWMOD_SWSUP_SIDLE,
};
/*
--
To unsubscribe from this list: send the line unsubscribe 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] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
On Tue, Jun 19, 2012 at 3:56 PM, Tony Lindgren t...@atomide.com wrote: Below is the pinctrl-single patch updated with hopefully all the Stephen's comments addressed. The binding still needs to be looked at, see relevant parts of the discussion below. I am happy with the code and the way it interacts with the pinctrl subsystem! Now all I need to merge this is a few ACKs from select people, and since this has a deep impact on the way device tree is used I would *really* like for Grant or Rob to ACK it. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data
Hi Ricardo,
In fact the flags attribute was not located correctly with regard to the
template used by the scripts.
I updated the script, the patch, the subject and fix a typo in the changelog.
Please find below the updated version.
Regards,
Benoit
---
From 9a89d06f9de9a4efbfc49d0c5adf0fa0d0031bdf Mon Sep 17 00:00:00 2001
From: Ricardo Neri ricardo.n...@ti.com
Date: Thu, 21 Jun 2012 10:08:53 +0200
Subject: [PATCH] ARM: OMAP4: hwmod data: Force HDMI in no-idle while enabled
As per the OMAP4 documentation, audio over HDMI must be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmod uses
no-idle/force-idle settings instead of smart-idle mode.
This is required as the DSS interface clock is used as functional clock
for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
be choppy, have bad quality or not be audible at all.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
[b-cous...@ti.com: Update the subject and align the .flags
location with the script template]
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index aae6e5e..f51b35f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -858,6 +858,11 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
.name = dss_hdmi,
.class = omap44xx_hdmi_hwmod_class,
.clkdm_name = l3_dss_clkdm,
+ /*
+* HDMI audio requires to use no-idle mode. Hence,
+* set idle mode by software.
+*/
+ .flags = HWMOD_SWSUP_SIDLE,
.mpu_irqs = omap44xx_dss_hdmi_irqs,
.sdma_reqs = omap44xx_dss_hdmi_sdma_reqs,
.main_clk = dss_48mhz_clk,
--
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: [PATCHv8 03/13] I2C: OMAP: Remove reset at init
On Thursday 21 June 2012 12:50 PM, Tony Lindgren wrote: * Shubhrajyoti shubhrajy...@ti.com [120621 00:08]: On Wednesday 20 June 2012 03:59 PM, Tony Lindgren wrote: See the comments regarding driver specific resets in hwmod code. you mean omap_hwmod.c The way to set this up is to have a shared inline function in i2c-omap.h that both the driver and hwmod code can use. hwmod reset function uses oh (omap_hwmod). How could the driver also pass oh ? Could we keep a local copy in driver data? Eventually hwmod code will do the reset only in late initcall if no driver is loaded for the device in question. There's no need for the driver to know anything about oh. The driver just needs to know the iobase. I will rework to make the hwmod and driver use the same function. In the meanwhile I will send a minimal/ remaining cleanups/ fixes so that it might get some time to bake in the next branch. 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] OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays
This is a fix for v3.4 stable kernel. Mainline commit is
3568f2a46f2a73bab18c914df06afd98a97e0e0e. As a clarification to the original
commit description below: when the bug happens the display does not show
anything.
There is a problem related to DSS FIFO thresholds and power management
on OMAP3. It seems that when the full PM hits in, we get underflows. The
core reason is unknown, but after experiments it looks like only
particular FIFO thresholds work correctly.
This bug is related to an earlier patch, which added special FIFO
threshold configuration for OMAP3, because DSI command mode output
didn't work with the normal threshold configuration.
However, as the above work-around worked fine for other output types
also, we currently always configure thresholds in this special way on
OMAP3. In theory there should be negligible difference with this special
way and the standard way. The first paragraph explains what happens in
practice.
This patch changes the driver to use the special threshold configuration
only when the output is a manual update display on OMAP3. This does
include RFBI displays also, and although it hasn't been tested (no
boards using RFBI) I suspect the similar behaviour is present there
also, as the DISPC side should work similarly for DSI command mode and
RFBI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Joe Woodward j...@terrafix.co.uk
---
drivers/video/omap2/dss/apply.c |2 +-
drivers/video/omap2/dss/dispc.c |5 +++--
drivers/video/omap2/dss/dss.h |3 ++-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index b10b3bc..cb19af2 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -927,7 +927,7 @@ static void dss_ovl_setup_fifo(struct omap_overlay *ovl,
dssdev = ovl-manager-device;
dispc_ovl_compute_fifo_thresholds(ovl-id, fifo_low, fifo_high,
- use_fifo_merge);
+ use_fifo_merge, ovl_manual_update(ovl));
dss_apply_ovl_fifo_thresholds(ovl, fifo_low, fifo_high);
}
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ee30937..c4d0e44 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1063,7 +1063,8 @@ void dispc_enable_fifomerge(bool enable)
}
void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
- u32 *fifo_low, u32 *fifo_high, bool use_fifomerge)
+ u32 *fifo_low, u32 *fifo_high, bool use_fifomerge,
+ bool manual_update)
{
/*
* All sizes are in bytes. Both the buffer and burst are made of
@@ -1091,7 +1092,7 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane
plane,
* combined fifo size
*/
- if (dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
+ if (manual_update dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
*fifo_low = ovl_fifo_size - burst_size * 2;
*fifo_high = total_fifo_size - burst_size;
} else {
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index d4b3dff..d0638da 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -424,7 +424,8 @@ int dispc_calc_clock_rates(unsigned long dispc_fclk_rate,
void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high);
void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
- u32 *fifo_low, u32 *fifo_high, bool use_fifomerge);
+ u32 *fifo_low, u32 *fifo_high, bool use_fifomerge,
+ bool manual_update);
int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
bool ilace, bool replication);
int dispc_ovl_enable(enum omap_plane plane, bool enable);
--
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
[PATCHv9 5/8] I2C: OMAP: Do not initialise the completion everytime
Use INIT_COMPLETION instead of init_completion in transfer. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index ccb2fc4..2a50094 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -493,7 +493,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, w |= OMAP_I2C_BUF_RXFIF_CLR | OMAP_I2C_BUF_TXFIF_CLR; omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, w); - init_completion(dev-cmd_complete); + INIT_COMPLETION(dev-cmd_complete); dev-cmd_err = 0; w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT; @@ -997,6 +997,7 @@ omap_i2c_probe(struct platform_device *pdev) dev-irq = irq-start; platform_set_drvdata(pdev, dev); + init_completion(dev-cmd_complete); dev-reg_shift = (dev-flags OMAP_I2C_FLAG_BUS_SHIFT__SHIFT) 3; -- 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
[PATCHv9 6/8] I2C: OMAP: Remove the definition of SYSS_RESETDONE_MASK
Remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Also fixes the warning
CC drivers/i2c/busses/i2c-omap.o
drivers/i2c/busses/i2c-omap.c:163: warning: SYSS_RESETDONE_MASK redefined
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2a50094..cbf7ecd 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -159,9 +159,6 @@ enum {
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
#endif
-/* OCP_SYSSTATUS bit definitions */
-#define SYSS_RESETDONE_MASK(1 0)
-
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
#define SYSC_SIDLEMODE_MASK(0x3 3)
--
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
[PATCHv9 4/8] I2C: OMAP: Use SET_RUNTIME_PM_OPS
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 328a022..ccb2fc4 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1115,6 +1115,7 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
#ifdef CONFIG_PM_RUNTIME
static void omap_i2c_restore(struct omap_i2c_dev *dev)
{
@@ -1176,15 +1177,16 @@ static int omap_i2c_runtime_resume(struct device *dev)
return 0;
}
+#endif /* CONFIG_PM_RUNTIME */
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
#else
#define OMAP_I2C_PM_OPS NULL
-#endif
+#endif /* CONFIG_PM */
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
--
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
[PATCHv9 7/8] I2C: OMAP: Correct I2C revision for OMAP3
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index cbf7ecd..a492d93 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -50,8 +50,8 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
-#define OMAP_I2C_REV_ON_3430 0x3C
-#define OMAP_I2C_REV_ON_3530_4430 0x40
+#define OMAP_I2C_REV_ON_3430_3530 0x3C
+#define OMAP_I2C_REV_ON_3630_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -305,7 +305,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
dev-syscstate = SYSC_AUTOIDLE_MASK;
dev-syscstate |= SYSC_ENAWAKEUP_MASK;
dev-syscstate |= (SYSC_IDLEMODE_SMART
@@ -1015,7 +1015,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207)
dev-errata |= I2C_OMAP_ERRATA_I207;
- if (dev-rev = OMAP_I2C_REV_ON_3430)
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
@@ -1033,7 +1033,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
+ if (dev-rev = OMAP_I2C_REV_ON_3630_4430)
dev-b_hw = 0; /* Disable hardware fixes */
else
dev-b_hw = 1; /* Enable hardware fixes */
--
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
[PATCHv9 3/8] I2C: OMAP: use devm_* functions
The various devm_* functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc, devm_request_and_ioremap for data
that is allocated in the probe function of a platform device and is only
freed in the remove function.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 33 +
1 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d704f64..328a022 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -943,7 +943,7 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq, *ioarea;
+ struct resource *mem, *irq;
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
@@ -962,17 +962,16 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem-start, resource_size(mem),
- pdev-name);
- if (!ioarea) {
- dev_err(pdev-dev, I2C region already claimed\n);
- return -EBUSY;
+ dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(pdev-dev, Menory allocation failed\n);
+ return -ENOMEM;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
- if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev-base = devm_request_and_ioremap(pdev-dev, mem);
+ if (!dev-base) {
+ dev_err(pdev-dev, I2C region already claimed\n);
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
@@ -996,11 +995,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq-start;
- dev-base = ioremap(mem-start, resource_size(mem));
- if (!dev-base) {
- r = -ENOMEM;
- goto err_free_mem;
- }
platform_set_drvdata(pdev, dev);
@@ -1095,13 +1089,9 @@ err_free_irq:
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
- iounmap(dev-base);
pm_runtime_disable(pdev-dev);
err_free_mem:
platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem-start, resource_size(mem));
return r;
}
@@ -1109,7 +1099,6 @@ err_release_region:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
int ret;
platform_set_drvdata(pdev, NULL);
@@ -1123,10 +1112,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
- iounmap(dev-base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start, resource_size(mem));
return 0;
}
--
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
[PATCHv9 0/8] I2C cleanups
The patch series does the following - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - Adds a patch to use devm_* functions - Adds a pdata function pointer to do context save restore - Split the omap_i2c_isr to increase readability - Make the i2c use SET_RUNTIME_PM_OPS - Use INIT_COMPLETION instead of init_completion - the reset patch is dropped will try to rework it as per the review comments recieved. This applies on Wolfram's i2c-embedded/for-next branch. Functional testing on omap4430 , 4460 panda and omap3sdp. Previous discurssions http://www.spinics.net/lists/linux-i2c/msg07748.html This series mainly is the cleanups rebased on i2c-embedded/for-next branch. The following changes since commit 0f009a914b40be8786fa67b1f4345cacc263b48c: i2c: tegra: make all resource allocation through devm_* (2012-06-13 16:01:38 +0200) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git for_next/i2c_minimal_cleanup Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (6): I2C: OMAP: I2C register restore only if context is lost I2C: OMAP: Optimise the remove code I2C: OMAP: use devm_* functions I2C: OMAP: Use SET_RUNTIME_PM_OPS I2C: OMAP: Do not initialise the completion everytime I2C: OMAP: Remove the definition of SYSS_RESETDONE_MASK Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition arch/arm/plat-omap/i2c.c |3 + drivers/i2c/busses/i2c-omap.c | 128 include/linux/i2c-omap.h |1 + 3 files changed, 81 insertions(+), 51 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 1/8] I2C: OMAP: I2C register restore only if context is lost
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost
or in case of error to be on the safe side.
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/plat-omap/i2c.c |3 +++
drivers/i2c/busses/i2c-omap.c | 35 ++-
include/linux/i2c-omap.h |1 +
3 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index db071bc..4ccab07 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -179,6 +179,9 @@ static inline int omap2_i2c_add_bus(int bus_id)
*/
if (cpu_is_omap34xx())
pdata-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
+
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9895fa7..9a54e88 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,6 +43,7 @@
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
+#include plat/omap_device.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -185,6 +186,7 @@ struct omap_i2c_dev {
u32 latency;/* maximum mpu wkup latency */
void(*set_mpu_wkup_lat)(struct device *dev,
long latency);
+ int (*get_context_loss_count)(struct device *dev);
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -207,6 +209,7 @@ struct omap_i2c_dev {
u16 syscstate;
u16 westate;
u16 errata;
+ int dev_lost_count;
};
static const u8 reg_map_ip_v1[] = {
@@ -987,6 +990,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-speed = pdata-clkrate;
dev-flags = pdata-flags;
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
+ dev-get_context_loss_count = pdata-get_context_loss_count;
dev-dtrev = pdata-rev;
}
@@ -1128,12 +1132,26 @@ omap_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_RUNTIME
+static void omap_i2c_restore(struct omap_i2c_dev *dev)
+{
+ 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_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+
+}
static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
u16 iv;
+ if (_dev-get_context_loss_count)
+ _dev-dev_lost_count = _dev-get_context_loss_count(dev);
+
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
@@ -1154,16 +1172,15 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ int loss_cnt;
+
+ if (!(_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE))
+ return 0;
- 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);
+ if (_dev-get_context_loss_count) {
+ loss_cnt = _dev-get_context_loss_count(dev);
+ if (_dev-dev_lost_count != loss_cnt)
+ omap_i2c_restore(_dev);
}
/*
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index 92a0dc7..c76cbc0 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@
[PATCHv9 2/8] I2C: OMAP: Optimise the remove code
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9a54e88..d704f64 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1106,8 +1106,7 @@ err_release_region:
return r;
}
-static int
-omap_i2c_remove(struct platform_device *pdev)
+static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
struct resource *mem;
@@ -1204,7 +1203,7 @@ static struct dev_pm_ops omap_i2c_pm_ops = {
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
- .remove = omap_i2c_remove,
+ .remove = __devexit_p(omap_i2c_remove),
.driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
--
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
[PATCHv9 8/8] I2C: OMAP: Recover from Bus Busy condition
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that controller is in a good state.
Based upon Vikram Pandita's patch from TI Android 3.0.
I acknowledge the contributions and suggestions of Jon and Hemant.
A couple differences from the original patch ...
1. Add a new function for bus clear
2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
output a permanent clock. This bit needs to be set and typically it would
be set by the unidle function but this is not the case for all OMAP
generations.
3. Program the SYSTEST setting only the bits we care about. However, restore
SYSTEST registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a492d93..23c8e78 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -148,16 +148,15 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test enable */
#define OMAP_I2C_SYSTEST_FREE (1 14) /* Free running mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK(3 12) /* Test mode select */
-#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_TEST(2 12) /* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_LOOP(3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-#endif
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
@@ -460,6 +459,29 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
}
+/*
+ * Bus Clear
+ */
+static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
+{
+ u16 w;
+
+ /*
+* Per the I2C specification, if we are stuck in a bus busy state
+* we can attempt a bus clear to try and recover the bus by sending
+* at least 9 clock pulses on SCL. Put the I2C in a test mode so it
+* will output a continuous clock on SCL.
+*/
+ w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, (OMAP_I2C_SYSTEST_ST_EN
+ | OMAP_I2C_SYSTEST_TMODE_TEST));
+ msleep(1);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_init(dev);
+ return omap_i2c_wait_for_bb(dev);
+}
/*
* Low level master read/write transaction.
@@ -586,6 +608,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
r = omap_i2c_wait_for_bb(dev);
if (r 0)
+ r = omap_i2c_bus_clear(dev);
+ if (r 0)
goto out;
if (dev-set_mpu_wkup_lat != NULL)
@@ -654,6 +678,7 @@ static inline void i2c_omap_errata_i207(struct omap_i2c_dev
*dev, u16 stat)
}
}
+ return 0;
}
/* rev1 devices are apparently only on some 15xx */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path
A recent commit, [PATCH] Fix OMAP EHCI suspend/resume failure
(i693) '354ab856' causes ehci probe to fail on omap3xxx. This
exposed bugs in the ehci_hcd_omap_probe error path causing
an oops.
On the error path, call usb_remove_hcd if usb_add_hcd has been
called, and call usb_put_hcd if usb_alloc_hcd has been called.
Tested on BB-xM.
Signed-off-by: russ.d...@ti.com
---
drivers/usb/host/ehci-omap.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 17cfb8a..6e15fc8 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -347,7 +347,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret) {
dev_err(dev, failed to add hcd with err %d\n, ret);
- goto err_add_hcd;
+ goto err_pm_runtime;
}
/* root ports should always stay powered */
@@ -424,8 +424,12 @@ err_utmi_p1_fck:
clk_put(utmi_p1_fck);
err_add_hcd:
+ usb_remove_hcd(hcd);
+
+err_pm_runtime:
disable_put_regulator(pdata);
pm_runtime_put_sync(dev);
+ usb_put_hcd(hcd);
err_io:
iounmap(regs);
--
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 2/2] ARM: OMAP: USB: Fix omap3xxx EHCI regression caused by i693 errata fix.
[PATCH] Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes
an oops on boot for all omap3xxx platforms that use usbhs_omap for
EHCI. The actual oops comes from faulty ehci-omap cleanup, but the
failure caused by the change is evidenced here:
[3.655059] ehci-omap ehci-omap.0: utmi_p1_gfclk failed error:-2
[3.661376] ehci-omap: probe of ehci-omap.0 failed with error -2
utmi_p1_gfclk is a clock that exists on OMAP4, but not OMAP3. In the
OMAP3 case, it is configured as a dummy clock. However, OMAP4 lists
the dev_id as NULL, but OMAP3 lists it as usbhs_omap.
Attempting to get that clock from ehci-omap then fails. The solution
is to just change the clock3xxx_data.c for dummy clocks used in the
errata fix to match the dev_id, NULL, used in clock44xx_data.c.
Tested on BB-xM.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 4e1a3b0..59d5315 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3391,15 +3391,15 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(usbhs_omap, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
+ CLK(NULL, utmi_p1_gfclk,dummy_ck, CK_3XXX),
+ CLK(NULL, utmi_p2_gfclk,dummy_ck, CK_3XXX),
+ CLK(NULL, xclk60mhsp1_ck, dummy_ck, CK_3XXX),
+ CLK(NULL, xclk60mhsp2_ck, dummy_ck, CK_3XXX),
+ CLK(NULL, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
+ CLK(NULL, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, init_60m_fclk,dummy_ck,
CK_3XXX),
+ CLK(NULL, init_60m_fclk,dummy_ck, CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
--
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: MFD USB host: prevents CORE retention in idle
On Thu, Jun 21, 2012 at 10:12 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host' I am seeing only the branch /wip/arm-nohz-cpusets other than master. I didn't any usb-host branch here too: http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary It seems Kevin linked the wrong git tree, try this one: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
Hi Arnd
Sorry for a delayed reply, we had to discuss this your idea internally
first before replying.
On Fri, 15 Jun 2012, Arnd Bergmann wrote:
On Friday 15 June 2012, Guennadi Liakhovetski wrote:
In the common case, you could have one device connected to the third
slave ID of the first controller but the fifth slave ID of the
second controller. In this case, you really have to specify each
controller with its slave ID separately, even if that means a lot
of duplicate data for shmobile.
So, you don't think it's worth making a short-cut possible to specify a
DMAC type instead of each instance phandle? It really would mean __a lot__
of duplication - with 3 generic controllers on (some) current chips and
possibly more on those, that I'm not aware about.
It's certainly possible to make that short-cut, but I'm not convinced
if it's worth it. One thing you can do is create a meta-device for
all of the identical DMA controllers, and refer to that one from the
devices, but make it a separate device node from the actual controllers,
of which you can have more than one. This makes the binding for your
dma controller more complex but reduces the amount of data required
in the other device nodes.
In case of sh7372, this could look something like
dma: dmac-mux {
compatible = renesas,sh-dma-mux;
#dma-cells = 4; /* slave-id, addr, chcr, mid-rid */
#address-cells = 1;
#size-cells = 1;
ranges;
dmae@0xfe008020{
compatible = renesas,sh-dma;
reg = 0xfe008020 0xfe00828f
0xfe009000 0xfe00900b
interrupts = 0x20c0 0x2000 0x2020 0x2040 0x2060 0x2080
0x20a0;
};
dmae@0xfe018020{
compatible = renesas,sh-dma;
reg = 0xfe018020 0xfe01828f
0xfe019000 0xfe01900b
interrupts = 0x21c0 0x2100 0x2120 0x2140 0x2160 0x2180
0x21a0;
};
dmae@0xfe028020{
compatible = renesas,sh-dma;
reg = 0xfe028020 0xfe02828f
0xfe029000 0xfe02900b
interrupts = 0x22c0 0x2200 0x2220 0x2240 0x2260 0x2280
0x22a0;
};
};
This way, a slave would refer to the dmac-mux node and while
the device driver binds to the child nodes.
Indeed, this solution should be good enough, thanks! I'm not sure, whether
making this multiplexing available requires any additional code to the
generic DMA DT binding implementation. If it does - please, let's make
this a part of the implementation.
It is also important to provide a flexible multiple channel per device
configuration support to let slave drivers distinguish between different
DMA channels, that they get back from the API. But I think this is a part
of the current proposal and is being taken care of.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path
Hello. On 21-06-2012 14:44, Russ Dill wrote: A recent commit, [PATCH] Fix OMAP EHCI suspend/resume failure (i693) '354ab856' Usually commit ID follows the word commit, and then the commit summary. causes ehci probe to fail on omap3xxx. This exposed bugs in the ehci_hcd_omap_probe error path causing an oops. On the error path, call usb_remove_hcd if usb_add_hcd has been called, and call usb_put_hcd if usb_alloc_hcd has been called. Tested on BB-xM. Signed-off-by: russ.d...@ti.com It should be: Signed-off-by: Russ Dill russ.d...@ti.com WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] Prepare for GPMC driver conversion
Hi,
Objective of this series is to make things easy for GPMC driver
conversion series by separating out more things from driver
conversion series.
This series,
1. Unifies NAND platform initialization functions
2. Prepares OneNAND platform code for gpmc driver migration
3. Handles additional timings in Kernel
This series is based on 3.5-rc1 made on top of
[PATCH v2 00/10] Prepare for GPMC driver conversion (w.r.t MTD)
{http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70096.html}
These changes has been tested with omap3evm beagle board. Relevant
GPMC peripherals that got tested by this were NAND (beagle) and
OneNAND (using local patches for omap3evm)
Regards
Afzal
v3:
1. Refactor OneNAND set_sync/async functions to separate out timing
and configurations
2. Handle bool type timings too
3. Swap patches 2 3 due to dependency of OneNAND change on newly
added bool type timings
v2:
1. Make use of timing api for setting clock activation time, and
remove direct writing to register for clock activation. Peripherals
making use of it were tusb6010 onenand
2. Move ensuring that async mode in OneNAND has been setup from
set_sync to setup function, improve commit message
Afzal Mohammed (3):
ARM: OMAP2+: nand: unify init functions
ARM: OMAP2+: gpmc: handle additional timings
ARM: OMAP2+: onenand: prepare for gpmc driver migration
arch/arm/mach-omap2/board-devkit8000.c |8 +-
arch/arm/mach-omap2/board-flash.c | 45 -
arch/arm/mach-omap2/board-flash.h |6 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c|4 +-
arch/arm/mach-omap2/board-omap3beagle.c|8 +-
arch/arm/mach-omap2/board-omap3touchbook.c |8 +-
arch/arm/mach-omap2/board-overo.c |7 +-
arch/arm/mach-omap2/board-zoom.c |5 +-
arch/arm/mach-omap2/common-board-devices.c | 46 --
arch/arm/mach-omap2/common-board-devices.h |1 -
arch/arm/mach-omap2/gpmc-onenand.c | 137 ++--
arch/arm/mach-omap2/gpmc.c | 45 +
arch/arm/mach-omap2/usb-tusb6010.c |3 +-
arch/arm/plat-omap/include/plat/gpmc.h | 19
15 files changed, 193 insertions(+), 151 deletions(-)
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] ARM: OMAP2+: nand: unify init functions
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things similar to
board_nand_init except that NAND CS# were being acquired
based on bootloader setting. As CS# is hardwired for a given
board, acquiring gpmc CS# has been removed, and updated with
the value on board.
NAND CS# used in beagle board was found to be CS0.
Thomas Weber thomas.weber.li...@googlemail.com reported
that value of devkit8000 to be CS0. Overo board was found
to be using CS0 based on u-boot, while google grep says
omap3touchbook too has CS0.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-devkit8000.c |8 +++--
arch/arm/mach-omap2/board-flash.c | 45 ++-
arch/arm/mach-omap2/board-flash.h |6 ++--
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c|4 +--
arch/arm/mach-omap2/board-omap3beagle.c|8 +++--
arch/arm/mach-omap2/board-omap3touchbook.c |8 +++--
arch/arm/mach-omap2/board-overo.c |7 +++--
arch/arm/mach-omap2/board-zoom.c |5 +--
arch/arm/mach-omap2/common-board-devices.c | 46
arch/arm/mach-omap2/common-board-devices.h |1 -
11 files changed, 56 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 6567c1c..6ee429a 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -59,8 +59,11 @@
#include mux.h
#include hsmmc.h
+#include board-flash.h
#include common-board-devices.h
+#defineNAND_CS 0
+
#define OMAP_DM9000_GPIO_IRQ 25
#define OMAP3_DEVKIT_TS_GPIO 27
@@ -628,8 +631,9 @@ static void __init devkit8000_init(void)
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
- omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
-ARRAY_SIZE(devkit8000_nand_partitions));
+ board_nand_init(devkit8000_nand_partitions,
+ ARRAY_SIZE(devkit8000_nand_partitions), NAND_CS,
+ NAND_BUSWIDTH_16, NULL);
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 70a81f9..0ee820b 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -108,41 +108,41 @@ __init board_onenand_init(struct mtd_partition
*nor_parts, u8 nr_parts, u8 cs)
defined(CONFIG_MTD_NAND_OMAP2_MODULE)
/* Note that all values in this struct are in nanoseconds */
-static struct gpmc_timings nand_timings = {
+struct gpmc_timings nand_default_timings[1] = {
+ {
+ .sync_clk = 0,
- .sync_clk = 0,
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
- .cs_on = 0,
- .cs_rd_off = 36,
- .cs_wr_off = 36,
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
- .adv_on = 6,
- .adv_rd_off = 24,
- .adv_wr_off = 36,
+ .we_off = 30,
+ .oe_off = 48,
- .we_off = 30,
- .oe_off = 48,
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
- .access = 54,
- .rd_cycle = 72,
- .wr_cycle = 72,
-
- .wr_access = 30,
- .wr_data_mux_bus = 0,
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+ },
};
-static struct omap_nand_platform_data board_nand_data = {
- .gpmc_t = nand_timings,
-};
+static struct omap_nand_platform_data board_nand_data;
void
-__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs,
+ int nand_type, struct gpmc_timings *gpmc_t)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+ board_nand_data.gpmc_t = gpmc_t;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
@@ -243,5 +243,6 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
pr_err(NAND: Unable to find configuration in GPMC\n);
else
board_nand_init(partition_info[2].parts,
- partition_info[2].nr_parts, nandcs, nand_type);
+ partition_info[2].nr_parts, nandcs,
+ nand_type,
[PATCH v3 2/3] ARM: OMAP2+: gpmc: handle additional timings
Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
clkactivationtime in gpmc_cs_set_timings(). This is done so
that boards can configure these parameters of gpmc in Kernel
instead of relying on bootloader. Also configure bool type
timings like extradelay.
This needed change to two existing users that were configuring
clk activation time by directly writing to registers. Thanks to
Tony for making me aware of the issue being kind enough to
test this change.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v3:
Handle bool type timings too
v2:
Make use of timing api for setting clock activation time, and
remove direct writing to register for clock activation. Peripherals
making use of it were tusb6010 onenand
arch/arm/mach-omap2/gpmc-onenand.c |3 ++-
arch/arm/mach-omap2/gpmc.c | 45
arch/arm/mach-omap2/usb-tusb6010.c |3 ++-
arch/arm/plat-omap/include/plat/gpmc.h | 19 ++
4 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 71d7c07..8863e0a 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -329,6 +329,8 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
t.rd_cycle = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div +
ticks_cez);
+ t.clk_activation = fclk_offset_ns;
+
/* Write */
if (sync_write) {
t.adv_wr_off = t.adv_rd_off;
@@ -362,7 +364,6 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
(sync_read ? GPMC_CONFIG1_READTYPE_SYNC : 0) |
(sync_write ? GPMC_CONFIG1_WRITEMULTIPLE_SUPP : 0) |
(sync_write ? GPMC_CONFIG1_WRITETYPE_SYNC : 0) |
- GPMC_CONFIG1_CLKACTIVATIONTIME(fclk_offset) |
GPMC_CONFIG1_PAGE_LEN(2) |
(cpu_is_omap34xx() ? 0 :
(GPMC_CONFIG1_WAIT_READ_MON |
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 578fd4c..8b0978f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -64,6 +64,13 @@
#define GPMC_ECC_CTRL_ECCREG8 0x008
#define GPMC_ECC_CTRL_ECCREG9 0x009
+#defineGPMC_CONFIG2_CSEXTRADELAY BIT(7)
+#defineGPMC_CONFIG3_ADVEXTRADELAY BIT(7)
+#defineGPMC_CONFIG4_OEEXTRADELAY BIT(7)
+#defineGPMC_CONFIG4_WEEXTRADELAY BIT(23)
+#defineGPMC_CONFIG6_CYCLE2CYCLEDIFFCSENBIT(6)
+#defineGPMC_CONFIG6_CYCLE2CYCLESAMECSENBIT(7)
+
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
@@ -220,6 +227,36 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
return ticks * gpmc_get_fclk_period() / 1000;
}
+static inline void gpmc_cs_modify_reg(int cs, int reg, u32 mask, bool value)
+{
+ u32 l;
+
+ l = gpmc_cs_read_reg(cs, reg);
+ if (value)
+ l |= mask;
+ else
+ l = ~mask;
+ gpmc_cs_write_reg(cs, reg, l);
+}
+
+static void gpmc_cs_bool_timings(int cs, const struct gpmc_bool_timings *p)
+{
+ gpmc_cs_modify_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_TIME_PARA_GRAN, p-time_para_granularity);
+ gpmc_cs_modify_reg(cs, GPMC_CS_CONFIG2,
+ GPMC_CONFIG2_CSEXTRADELAY, p-cs_extra_delay);
+ gpmc_cs_modify_reg(cs, GPMC_CS_CONFIG3,
+ GPMC_CONFIG3_ADVEXTRADELAY, p-adv_extra_delay);
+ gpmc_cs_modify_reg(cs, GPMC_CS_CONFIG4,
+ GPMC_CONFIG4_OEEXTRADELAY, p-oe_extra_delay);
+ gpmc_cs_modify_reg(cs, GPMC_CS_CONFIG4,
+ GPMC_CONFIG4_OEEXTRADELAY, p-we_extra_delay);
+ gpmc_cs_modify_reg(cs, GPMC_CS_CONFIG6,
+ GPMC_CONFIG6_CYCLE2CYCLESAMECSEN, p-cycle2cyclesamecsen);
+ gpmc_cs_modify_reg(cs, GPMC_CS_CONFIG6,
+ GPMC_CONFIG6_CYCLE2CYCLEDIFFCSEN, p-cycle2cyclediffcsen);
+}
+
#ifdef DEBUG
static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
int time, const char *name)
@@ -313,6 +350,12 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay);
+
+ GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring);
+ GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation);
+
if (cpu_is_omap34xx()) {
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
@@ -332,6 +375,8 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
[PATCH v3 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Reorganize gpmc-onenand initialization so that changes
required for gpmc driver migration can be made smooth.
Ensuring sync read/write are disabled in onenand cannot
be expected to work properly unless GPMC is setup, this
has been removed.
Refactor set_async_mode set_sync_mode functions to
separate out timing calculation actual configuration
(GPMC OneNAND side).
Thanks to Jon for his suggestions.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v3:
Refactor set_sync/async functions to separate out timing and
configurations
v2:
Move ensuring that async mode in OneNAND has been setup from
set_sync to setup function, improve commit message
arch/arm/mach-omap2/gpmc-onenand.c | 134 +++-
1 file changed, 69 insertions(+), 65 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 8863e0a..789ca8c9 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/mtd/onenand_regs.h
#include linux/io.h
+#include linux/err.h
#include asm/mach/flash.h
@@ -25,6 +26,7 @@
#defineONENAND_IO_SIZE SZ_128K
+static int hf, vhf, sync_read, sync_write, latency;
static struct omap_onenand_platform_data *gpmc_onenand_data;
static struct resource gpmc_onenand_resource = {
@@ -38,11 +40,9 @@ static struct platform_device gpmc_onenand_device = {
.resource = gpmc_onenand_resource,
};
-static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
+static struct gpmc_timings omap2_onenand_calc_async_timings(void)
{
struct gpmc_timings t;
- u32 reg;
- int err;
const int t_cer = 15;
const int t_avdp = 12;
@@ -55,11 +55,6 @@ static int omap2_onenand_set_async_mode(int cs, void __iomem
*onenand_base)
const int t_wpl = 40;
const int t_wph = 30;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
-
memset(t, 0, sizeof(t));
t.sync_clk = 0;
t.cs_on = 0;
@@ -86,12 +81,21 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
t.wr_cycle = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
+ return t;
+}
+
+static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base,
+ struct gpmc_timings *t)
+{
+ u32 reg;
+ int err;
+
/* Configure GPMC for asynchronous read */
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
GPMC_CONFIG1_DEVICESIZE_16 |
GPMC_CONFIG1_MUXADDDATA);
- err = gpmc_cs_set_timings(cs, t);
+ err = gpmc_cs_set_timings(cs, t);
if (err)
return err;
@@ -103,8 +107,7 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
return 0;
}
-static void set_onenand_cfg(void __iomem *onenand_base, int latency,
- int sync_read, int sync_write, int hf, int vhf)
+static void set_onenand_cfg(void __iomem *onenand_base)
{
u32 reg;
@@ -172,9 +175,9 @@ static int omap2_onenand_get_freq(struct
omap_onenand_platform_data *cfg,
return freq;
}
-static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
- void __iomem *onenand_base,
- int *freq_ptr)
+static struct gpmc_timings
+omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
+ int freq, bool clk_dep)
{
struct gpmc_timings t;
const int t_cer = 15;
@@ -184,28 +187,15 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
const int t_wpl = 40;
const int t_wph = 30;
int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
- int div, fclk_offset_ns, fclk_offset, gpmc_clk_ns, latency;
- int first_time = 0, hf = 0, vhf = 0, sync_read = 0, sync_write = 0;
- int err, ticks_cez;
- int cs = cfg-cs, freq = *freq_ptr;
- u32 reg;
- bool clk_dep = false;
+ int div, fclk_offset_ns, fclk_offset, gpmc_clk_ns;
+ int ticks_cez;
+ int cs = cfg-cs;
if (cfg-flags ONENAND_SYNC_READ) {
sync_read = 1;
} else if (cfg-flags ONENAND_SYNC_READWRITE) {
sync_read = 1;
sync_write = 1;
- } else
- return omap2_onenand_set_async_mode(cs, onenand_base);
-
- if (!freq) {
- /* Very first call freq is not known */
- err = omap2_onenand_set_async_mode(cs,
Re: Audio support on OMAP 3430LDP or 4430SDP boards
On Mon, Apr 30, 2012 at 10:26:45AM +0300, Peter Ujfalusi wrote: On 04/29/2012 11:35 PM, Russell King - ARM Linux wrote: Please can someone at TI take a current mainline kernel, build it, and test out audio support on the 4430SDP - specifically output through the headset jack into a line input, and report when it works. Thanks. Try to use my attached aconf for SDP4430 to configure the HS playback. Note that the HS is not a line out, so on your line-in device it will cause distortion. If you have a headset/headphone you will have better quality. alsactl -f blaze.aconf restore To play samples with aplay: aplay -Dplughw:0,0 wav file The sample format fot Legacy McPDM is S32_LE, 96KHz, 24bit (32 bit sample with 24 LSB). I'm just having another go with OMAP4430 audio... and again I find that I can't get anything out of the board. I've followed what you've said above, and it doesn't work. I've undone my DMA engine changes. Still doesn't work. I've checked /sys/kernel/debug/asoc for the codecs and DAIs, and they're there, and the SDP4430 audio is shown in /proc/asound/cards too, and yes, you guessed it, it still doesn't work. It's just a really expensive /dev/null from what I can tell at the moment. Frustrated. -- To unsubscribe from this list: send the line unsubscribe 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: Audio support on OMAP 3430LDP or 4430SDP boards
On Thu, Jun 21, 2012 at 01:59:03PM +0100, Russell King - ARM Linux wrote: On Mon, Apr 30, 2012 at 10:26:45AM +0300, Peter Ujfalusi wrote: On 04/29/2012 11:35 PM, Russell King - ARM Linux wrote: Please can someone at TI take a current mainline kernel, build it, and test out audio support on the 4430SDP - specifically output through the headset jack into a line input, and report when it works. Thanks. Try to use my attached aconf for SDP4430 to configure the HS playback. Note that the HS is not a line out, so on your line-in device it will cause distortion. If you have a headset/headphone you will have better quality. alsactl -f blaze.aconf restore To play samples with aplay: aplay -Dplughw:0,0 wav file The sample format fot Legacy McPDM is S32_LE, 96KHz, 24bit (32 bit sample with 24 LSB). I'm just having another go with OMAP4430 audio... and again I find that I can't get anything out of the board. I've followed what you've said above, and it doesn't work. I've undone my DMA engine changes. Still doesn't work. I've checked /sys/kernel/debug/asoc for the codecs and DAIs, and they're there, and the SDP4430 audio is shown in /proc/asound/cards too, and yes, you guessed it, it still doesn't work. It's just a really expensive /dev/null from what I can tell at the moment. Frustrated. Okay, reverting back to v3.4-rc4 works. -- To unsubscribe from this list: send the line unsubscribe 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: Audio support on OMAP 3430LDP or 4430SDP boards
On Thu, Jun 21, 2012 at 02:16:42PM +0100, Russell King - ARM Linux wrote: On Thu, Jun 21, 2012 at 01:59:03PM +0100, Russell King - ARM Linux wrote: On Mon, Apr 30, 2012 at 10:26:45AM +0300, Peter Ujfalusi wrote: On 04/29/2012 11:35 PM, Russell King - ARM Linux wrote: Please can someone at TI take a current mainline kernel, build it, and test out audio support on the 4430SDP - specifically output through the headset jack into a line input, and report when it works. Thanks. Try to use my attached aconf for SDP4430 to configure the HS playback. Note that the HS is not a line out, so on your line-in device it will cause distortion. If you have a headset/headphone you will have better quality. alsactl -f blaze.aconf restore To play samples with aplay: aplay -Dplughw:0,0 wav file The sample format fot Legacy McPDM is S32_LE, 96KHz, 24bit (32 bit sample with 24 LSB). I'm just having another go with OMAP4430 audio... and again I find that I can't get anything out of the board. I've followed what you've said above, and it doesn't work. I've undone my DMA engine changes. Still doesn't work. I've checked /sys/kernel/debug/asoc for the codecs and DAIs, and they're there, and the SDP4430 audio is shown in /proc/asound/cards too, and yes, you guessed it, it still doesn't work. It's just a really expensive /dev/null from what I can tell at the moment. Frustrated. Okay, reverting back to v3.4-rc4 works. As does reverting to v3.4, of course. So, it was broken during the last merge window. -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
Fix OMAP EHCI suspend/resume failure (i693) is causing
the usb hub and device detection fails in beagle XM
causeing NFS not functional. This affects the core retention too.
The same commit logic needs to be revisted adhering to hwmod and
device tree framework.
for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
titled Fix OMAP EHCI suspend/resume failure (i693) reverted.
This patch is validated on BeagleXM with NFS support over
usb ethernet and USB mass storage and other device detection.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
drivers/usb/host/ehci-omap.c | 164 +-
1 file changed, 1 insertion(+), 163 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 17cfb8a..272e661 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -56,15 +56,6 @@
#defineEHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#defineEHCI_INSNREG05_ULPI_WRDATA_SHIFT0
-/* Errata i693 */
-static struct clk *utmi_p1_fck;
-static struct clk *utmi_p2_fck;
-static struct clk *xclk60mhsp1_ck;
-static struct clk *xclk60mhsp2_ck;
-static struct clk *usbhost_p1_fck;
-static struct clk *usbhost_p2_fck;
-static struct clk *init_60m_fclk;
-
/*-*/
static const struct hc_driver ehci_omap_hc_driver;
@@ -80,40 +71,6 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
-/* Erratum i693 workaround sequence */
-static void omap_ehci_erratum_i693(struct ehci_hcd *ehci)
-{
- int ret = 0;
-
- /* Switch to the internal 60 MHz clock */
- ret = clk_set_parent(utmi_p1_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, init_60m_fclk set parent
- failed error:%d\n, ret);
-
- ret = clk_set_parent(utmi_p2_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, init_60m_fclk set parent
- failed error:%d\n, ret);
-
- clk_enable(usbhost_p1_fck);
- clk_enable(usbhost_p2_fck);
-
- /* Wait 1ms and switch back to the external clock */
- mdelay(1);
- ret = clk_set_parent(utmi_p1_fck, xclk60mhsp1_ck);
- if (ret != 0)
- ehci_err(ehci, xclk60mhsp1_ck set parent
- failed error:%d\n, ret);
-
- ret = clk_set_parent(utmi_p2_fck, xclk60mhsp2_ck);
- if (ret != 0)
- ehci_err(ehci, xclk60mhsp2_ck set parent
- failed error:%d\n, ret);
-
- clk_disable(usbhost_p1_fck);
- clk_disable(usbhost_p2_fck);
-}
static void omap_ehci_soft_phy_reset(struct platform_device *pdev, u8 port)
{
@@ -145,50 +102,6 @@ static void omap_ehci_soft_phy_reset(struct
platform_device *pdev, u8 port)
}
}
-static int omap_ehci_hub_control(
- struct usb_hcd *hcd,
- u16 typeReq,
- u16 wValue,
- u16 wIndex,
- char*buf,
- u16 wLength
-)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- u32 __iomem *status_reg = ehci-regs-port_status[
- (wIndex 0xff) - 1];
- u32 temp;
- unsigned long flags;
- int retval = 0;
-
- spin_lock_irqsave(ehci-lock, flags);
-
- if (typeReq == SetPortFeature wValue == USB_PORT_FEAT_SUSPEND) {
- temp = ehci_readl(ehci, status_reg);
- if ((temp PORT_PE) == 0 || (temp PORT_RESET) != 0) {
- retval = -EPIPE;
- goto done;
- }
-
- temp = ~PORT_WKCONN_E;
- temp |= PORT_WKDISC_E | PORT_WKOC_E;
- ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
-
- omap_ehci_erratum_i693(ehci);
-
- set_bit((wIndex 0xff) - 1, ehci-suspended_ports);
- goto done;
- }
-
- spin_unlock_irqrestore(ehci-lock, flags);
-
- /* Handle the hub control events here */
- return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
-done:
- spin_unlock_irqrestore(ehci-lock, flags);
- return retval;
-}
-
static void disable_put_regulator(
struct ehci_hcd_omap_platform_data *pdata)
{
@@ -353,76 +266,9 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
/* root ports should always stay powered */
ehci_port_power(omap_ehci, 1);
- /* get clocks */
- utmi_p1_fck = clk_get(dev, utmi_p1_gfclk);
- if (IS_ERR(utmi_p1_fck)) {
- ret = PTR_ERR(utmi_p1_fck);
- dev_err(dev, utmi_p1_gfclk failed error:%d\n, ret);
- goto err_add_hcd;
- }
-
- xclk60mhsp1_ck = clk_get(dev,
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
Fix OMAP EHCI suspend/resume failure (i693) is causing
the usb hub and device detection fails in beagle XM
causeing NFS not functional. This affects the core retention too.
The same commit logic needs to be revisted adhering to hwmod and
device tree framework.
for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
titled Fix OMAP EHCI suspend/resume failure (i693) reverted.
This patch is validated on BeagleXM with NFS support over
usb ethernet and USB mass storage and other device detection.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
drivers/usb/host/ehci-omap.c | 164
+-
1 file changed, 1 insertion(+), 163 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 17cfb8a..272e661 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -56,15 +56,6 @@
#define EHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#define EHCI_INSNREG05_ULPI_WRDATA_SHIFT 0
-/* Errata i693 */
-static struct clk *utmi_p1_fck;
-static struct clk *utmi_p2_fck;
-static struct clk *xclk60mhsp1_ck;
-static struct clk *xclk60mhsp2_ck;
-static struct clk *usbhost_p1_fck;
-static struct clk *usbhost_p2_fck;
-static struct clk *init_60m_fclk;
-
/*-*/
static const struct hc_driver ehci_omap_hc_driver;
@@ -80,40 +71,6 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
-/* Erratum i693 workaround sequence */
-static void omap_ehci_erratum_i693(struct ehci_hcd *ehci)
-{
- int ret = 0;
-
- /* Switch to the internal 60 MHz clock */
- ret = clk_set_parent(utmi_p1_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, init_60m_fclk set parent
- failed error:%d\n, ret);
-
- ret = clk_set_parent(utmi_p2_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, init_60m_fclk set parent
- failed error:%d\n, ret);
-
- clk_enable(usbhost_p1_fck);
- clk_enable(usbhost_p2_fck);
-
- /* Wait 1ms and switch back to the external clock */
- mdelay(1);
- ret = clk_set_parent(utmi_p1_fck, xclk60mhsp1_ck);
- if (ret != 0)
- ehci_err(ehci, xclk60mhsp1_ck set parent
- failed error:%d\n, ret);
-
- ret = clk_set_parent(utmi_p2_fck, xclk60mhsp2_ck);
- if (ret != 0)
- ehci_err(ehci, xclk60mhsp2_ck set parent
- failed error:%d\n, ret);
-
- clk_disable(usbhost_p1_fck);
- clk_disable(usbhost_p2_fck);
-}
static void omap_ehci_soft_phy_reset(struct platform_device *pdev, u8 port)
{
@@ -145,50 +102,6 @@ static void omap_ehci_soft_phy_reset(struct
platform_device *pdev, u8 port)
}
}
-static int omap_ehci_hub_control(
- struct usb_hcd *hcd,
- u16 typeReq,
- u16 wValue,
- u16 wIndex,
- char *buf,
- u16 wLength
-)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- u32 __iomem *status_reg = ehci-regs-port_status[
- (wIndex 0xff) - 1];
- u32 temp;
- unsigned long flags;
- int retval = 0;
-
- spin_lock_irqsave(ehci-lock, flags);
-
- if (typeReq == SetPortFeature wValue == USB_PORT_FEAT_SUSPEND) {
- temp = ehci_readl(ehci, status_reg);
- if ((temp PORT_PE) == 0 || (temp PORT_RESET) != 0) {
- retval = -EPIPE;
- goto done;
- }
-
- temp = ~PORT_WKCONN_E;
- temp |= PORT_WKDISC_E | PORT_WKOC_E;
- ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
-
- omap_ehci_erratum_i693(ehci);
-
- set_bit((wIndex 0xff) - 1, ehci-suspended_ports);
- goto done;
- }
-
- spin_unlock_irqrestore(ehci-lock, flags);
-
- /* Handle the hub control events here */
- return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
-done:
- spin_unlock_irqrestore(ehci-lock, flags);
- return retval;
-}
-
static void disable_put_regulator(
struct ehci_hcd_omap_platform_data *pdata)
{
@@ -353,76 +266,9 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
/* root ports should always stay powered */
ehci_port_power(omap_ehci, 1);
- /* get clocks */
- utmi_p1_fck = clk_get(dev, utmi_p1_gfclk);
- if (IS_ERR(utmi_p1_fck)) {
-
Re: Current state of AM33xx patches
On 18.06.2012 10:15, Hiremath, Vaibhav wrote: On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote: From: Daniel Mack zon...@gmail.com Hey, can anybody give me a quick wrap-up about the current state of AM33xx based SoCs in mainline? What are the next steps to get things merged? There is a wiki page [1] that is intended to provide a summary, but I'm confident it is not up-to-date. Page updated now... http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status Great, thanks. So if things get upstreamed, which is the repo/branch they appear in? In other words: where is the code people should write patches against? I couldn't find an answer to that yet. 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 V3 1/2] of: Add generic device tree DMA helpers
On Thursday 21 June 2012, Guennadi Liakhovetski wrote: Indeed, this solution should be good enough, thanks! I'm not sure, whether making this multiplexing available requires any additional code to the generic DMA DT binding implementation. If it does - please, let's make this a part of the implementation. It depends how the dma engine gets represented in Linux then: Either we make the common dmaengine code handle multiple dma-engines with the same of_node pointer, or you make the driver register a single dma-engine to Linux that is backed by the three physical devices but just one of_node pointer. I think either way will work, and someone has to try it to determine which one is simpler. It is also important to provide a flexible multiple channel per device configuration support to let slave drivers distinguish between different DMA channels, that they get back from the API. But I think this is a part of the current proposal and is being taken care of. Yes, it is. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path
On Thu, 21 Jun 2012, Russ Dill wrote: A recent commit, [PATCH] Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes ehci probe to fail on omap3xxx. This exposed bugs in the ehci_hcd_omap_probe error path causing an oops. On the error path, call usb_remove_hcd if usb_add_hcd has been called, and call usb_put_hcd if usb_alloc_hcd has been called. Tested on BB-xM. Signed-off-by: russ.d...@ti.com Acked-by: Alan Stern st...@rowland.harvard.edu -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Early oops on 3.4.3
Hi,
I have a custom dm3730 board, which is booting fines with 3.2.x kernel.
However it oopses very early in the boot process with 3.4.x kernel.
I have some trouble interpreting the oops so some help is welcome.
I think what makes this board quite different from other setup is the absence
of Power Management IC.
Here is a patch that tries to hide the problem, and was needed for 3.2 not
to oopse :
Index: b/arch/arm/mach-omap2/io.c
===
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -394,7 +394,7 @@
{
omap2_set_globals_3xxx();
omap_common_init_early();
- omap3xxx_voltagedomains_init();
+ // omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
omap3xxx_clockdomains_init();
omap3xxx_hwmod_init();
I guess this is a possible culprit, but any help on booting without
PMIC is welcome.
Below is the boot log.
Thank you for your help
Starting kernel ...
6Booting Linux on physical CPU 0
5Linux version 3.4.3 (cynove@jp) (gcc version 4.3.2 (Sourcery G++
Lite 2008q3-41) ) #1 PREEMPT Thu Jun 21 16:39:44 CEST 2012
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Cynove CYDM3730
6Reserving 4194304 bytes SDRAM for VRAM
Memory policy: ECC disabled, Data cache writeback
7On node 0 totalpages: 45568
7free_area_init_node: node 0, pgdat c0429404, node_mem_map c043f000
7 Normal zone: 512 pages used for memmap
7 Normal zone: 0 pages reserved
7 Normal zone: 45056 pages, LIFO batch:15
6OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
3powerdomain: wkup_pwrdm: voltagedomain wakeup does not exist
3powerdomain: iva2_pwrdm: voltagedomain mpu_iva does not exist
3powerdomain: mpu_pwrdm: voltagedomain mpu_iva does not exist
3powerdomain: neon_pwrdm: voltagedomain mpu_iva does not exist
3powerdomain: cam_pwrdm: voltagedomain core does not exist
3powerdomain: dss_pwrdm: voltagedomain core does not exist
3powerdomain: per_pwrdm: voltagedomain core does not exist
3powerdomain: emu_pwrdm: voltagedomain core does not exist
3powerdomain: dpll1_pwrdm: voltagedomain mpu_iva does not exist
3powerdomain: dpll2_pwrdm: voltagedomain mpu_iva does not exist
3powerdomain: dpll3_pwrdm: voltagedomain core does not exist
3powerdomain: dpll4_pwrdm: voltagedomain core does not exist
3powerdomain: core_pwrdm: voltagedomain core does not exist
3powerdomain: sgx_pwrdm: voltagedomain core does not exist
3powerdomain: usbhost_pwrdm: voltagedomain core does not exist
3powerdomain: dpll5_pwrdm: voltagedomain core does not exist
3clockdomain: wkup_clkdm: powerdomain wkup_pwrdm does not exist
3clockdomain: cm_clkdm: powerdomain core_pwrdm does not exist
3clockdomain: prm_clkdm: powerdomain wkup_pwrdm does not exist
3clockdomain: mpu_clkdm: powerdomain mpu_pwrdm does not exist
3clockdomain: neon_clkdm: powerdomain neon_pwrdm does not exist
3clockdomain: iva2_clkdm: powerdomain iva2_pwrdm does not exist
3clockdomain: d2d_clkdm: powerdomain core_pwrdm does not exist
3clockdomain: core_l3_clkdm: powerdomain core_pwrdm does not exist
3clockdomain: core_l4_clkdm: powerdomain core_pwrdm does not exist
3clockdomain: dss_clkdm: powerdomain dss_pwrdm does not exist
3clockdomain: cam_clkdm: powerdomain cam_pwrdm does not exist
3clockdomain: per_clkdm: powerdomain per_pwrdm does not exist
3clockdomain: emu_clkdm: powerdomain emu_pwrdm does not exist
3clockdomain: dpll1_clkdm: powerdomain dpll1_pwrdm does not exist
3clockdomain: dpll2_clkdm: powerdomain dpll2_pwrdm does not exist
3clockdomain: dpll3_clkdm: powerdomain dpll3_pwrdm does not exist
3clockdomain: dpll4_clkdm: powerdomain dpll4_pwrdm does not exist
3clockdomain: sgx_clkdm: powerdomain sgx_pwrdm does not exist
3clockdomain: dpll5_clkdm: powerdomain dpll5_pwrdm does not exist
3clockdomain: usbhost_clkdm: powerdomain usbhost_pwrdm does not exist
6Clocking rate (Crystal/Core/MPU): 19.2/400/832 MHz
7pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768c
7pcpu-alloc: c[0] c0 c
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 45056
5Kernel command line: console=ttyO2,115200n8 rdinit=/sbin/init
initrd=0x8300,1536k
mtdparts=omap2-nand.0:1024k(bootloaders),3072k(linux),1536k(ramfs),-(usr)
ubi.mtd=3,2048 mem=55M@0x8000 mem=128M@0x8800
6PID hash table entries: 1024 (order: 0, 4096 bytes)
6Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
6Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
6Memory: 55MB 123MB = 178MB total
5Memory: 174676k/174676k available, 12716k reserved, 0K highmem
5Virtual kernel memory layout:
vector : 0x - 0x1000 ( 4 kB)
fixmap : 0xfff0 - 0xfffe ( 896 kB)
vmalloc : 0xd080 - 0xff00 ( 744 MB)
lowmem : 0xc000 - 0xd000 ( 256 MB)
modules : 0xbf00 - 0xc000 ( 16 MB)
.text : 0xc0008000 - 0xc03c84b8 (3842 kB)
.init :
[GIT PULL] omap fixes for v3.5-rc3
The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71: Linux 3.5-rc3 (2012-06-16 17:25:17 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-fixes-for-v3.5-rc3 for you to fetch changes up to aef2b89662b8a7506846d0dc0df672d196ddf8d0: ARM: OMAP: Fix Beagleboard DVI reset gpio (2012-06-20 07:18:21 -0700) Here are a few fixes with the biggest one being fix for Beagle DVI reset. All of them are regression fixes, except for the missing omap2 interrupt controller binding that somehow got missed earlier. Jon Hunter (1): arm/dts: OMAP2: Fix interrupt controller binding Russ Dill (1): ARM: OMAP: Fix Beagleboard DVI reset gpio Tony Lindgren (2): ARM: OMAP2+: Fix MUSB ifdefs for platform init code ARM: OMAP2: Fix tusb6010 GPIO interrupt for n8x0 arch/arm/boot/dts/omap2.dtsi|2 ++ arch/arm/mach-omap2/board-n8x0.c|6 ++ arch/arm/mach-omap2/board-omap3beagle.c | 28 arch/arm/mach-omap2/omap_phy_internal.c |6 -- arch/arm/mach-omap2/usb-musb.c |6 ++ arch/arm/mach-omap2/usb-tusb6010.c |2 +- 6 files changed, 19 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
5912OSK NFS root broken on v3.5-rc3
The 5912OSK here no longer mounts NFS root: http://www.pwsan.com/omap/bootlogs/20120620/omap_cleanup_a_3.6__07b3a13957aa250ff5b5409b8ed756b113544112/ This broke at some point between v3.4-rc2 and v3.5-rc3. - 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
N800 MMC broken on v3.5-rc3
N800 no longer mounts MMC on v3.5-rc3: http://www.pwsan.com/omap/bootlogs/20120620/omap_cleanup_a_3.6__07b3a13957aa250ff5b5409b8ed756b113544112/n800_bootlog.txt This broke at some point between v3.4-rc2 and v3.5-rc3. - 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
[no subject]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71: Linux 3.5-rc3 (2012-06-16 17:25:17 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.6 for you to fetch changes up to 07b3a13957aa250ff5b5409b8ed756b113544112: Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 (2012-06-20 20:11:36 -0600) - Some OMAP hwmod, clock, and System Control Module cleanup patches for 3.6. - Testing logs are available at http://www.pwsan.com/omap/bootlogs/20120620/omap_cleanup_a_3.6__07b3a13957aa250ff5b5409b8ed756b113544112/ The summary is that 5912OSK NFS root and N800 MMC don't boot to userspace; this broke between v3.4-rc2 and v3.5-rc3. 3517 boards are still broken with NFS root and also several stack tracebacks during boot. In terms of PM, core isn't entering idle on OMAP3 or OMAP4. These problems all exist in v3.5-rc3 - they aren't caused by this series. object size (delta in bytes from v3.5-rc3 (485802a6c524e62b5924849dd727ddbb1497cc71)): textdata bss total kernel 0 0 0 0 5912osk_testconfig/vmlinux +4636-400 0 +4236 am33xx_testconfig/vmlinux +440-408 +32 +64 n800_multi_omap2xxx/vmlinux +416-192 +32+256 n800_testconfig/vmlinux 0 0 0 0 omap1510_defconfig/vmlinux 0 0 0 0 omap1_defconfig/vmlinux +732-456 0+276 omap2_4_testconfig/vmlinux +4776-624 0 +4152 omap2plus_defconfig/vmlinux +684-664 0 +20 omap2plus_no_pm/vmlinux +616-336 +64+344 omap3_4_testconfig/vmlinux +360-384 0 -24 omap3_testconfig/vmlinux +580-120 +64+524 omap4_testconfig/vmlinux Kevin Hilman (7): ARM: OMAP4: hwmod: rename _enable_module to _omap4_enable_module() ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module ARM: OMAP4: hwmod: drop extra cpu_is check from _wait_target_disable() ARM: OMAP2+: hwmod: use init-time function pointer for wait_target_ready ARM: OMAP2+: hwmod: use init-time function pointer for hardreset ARM: OMAP2+: hwmod: use init-time function pointer for _init_clkdm ARM: OMAP2+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_data Omar Ramirez Luna (2): ARM: OMAP2+: control: new APIs to configure boot address and mode ARM: OMAP: dsp: interface to control module functions Paul Walmsley (2): ARM: OMAP2+: hwmod: remove prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 Peter Ujfalusi (3): ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2420 ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2430 ARM: OMAP3: Move McBSP fck clock alias to hwmod data arch/arm/mach-omap2/Makefile |1 - arch/arm/mach-omap2/clock2420_data.c |4 - arch/arm/mach-omap2/clock2430_data.c | 10 - arch/arm/mach-omap2/clock3xxx_data.c | 10 - arch/arm/mach-omap2/clockdomain.h |2 - arch/arm/mach-omap2/clockdomains2420_data.c|2 - arch/arm/mach-omap2/clockdomains2430_data.c|2 - arch/arm/mach-omap2/clockdomains3xxx_data.c|2 - arch/arm/mach-omap2/clockdomains44xx_data.c|2 - arch/arm/mach-omap2/clockdomains_common_data.c | 24 -- arch/arm/mach-omap2/control.c | 43 ++ arch/arm/mach-omap2/control.h |2 + arch/arm/mach-omap2/dsp.c |4 + .../include/mach/ctrl_module_core_44xx.h |1 + arch/arm/mach-omap2/omap_hwmod.c | 427 ++-- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 10 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 16 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 23 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 +- arch/arm/plat-omap/include/plat/clock.h|2 - arch/arm/plat-omap/include/plat/dsp.h |3 + arch/arm/plat-omap/include/plat/omap_hwmod.h |2 + 22 files changed, 409 insertions(+), 187 deletions(-) delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12
Re: MFD USB host: prevents CORE retention in idle
Grazvydas Ignotas nota...@gmail.com writes: On Thu, Jun 21, 2012 at 10:12 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host' I am seeing only the branch /wip/arm-nohz-cpusets other than master. I didn't any usb-host branch here too: http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary It seems Kevin linked the wrong git tree, try this one: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git Oops, sorry. Grazvydas is right. It's my linux-omap-pm tree that has this test branch. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio support on OMAP 3430LDP or 4430SDP boards
Hi Russel, On Thu, Jun 21, 2012 at 4:22 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Okay, reverting back to v3.4-rc4 works. As does reverting to v3.4, of course. So, it was broken during the last merge window. Strange... I had no problem with the SDP4430/Blaze audio with 3.5-rc2 last week. Have you restored the mixers with alsactl -f blaze.aconf restore command? Does aplay (seemingly) plays the file OK or is it times out with an error after a while? -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio support on OMAP 3430LDP or 4430SDP boards
On Thu, Jun 21, 2012 at 09:36:12PM +0300, Ujfalusi, Peter wrote: Hi Russel, On Thu, Jun 21, 2012 at 4:22 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Okay, reverting back to v3.4-rc4 works. As does reverting to v3.4, of course. So, it was broken during the last merge window. Strange... I had no problem with the SDP4430/Blaze audio with 3.5-rc2 last week. Have you restored the mixers with alsactl -f blaze.aconf restore command? Does aplay (seemingly) plays the file OK or is it times out with an error after a while? It is as I said: v3.5-rc3: # alsactl -f blaze.aconf restore # aplay -f S16_LE -r 48000 -c 2 file.raw ... plays in about the right time but no audio ... v3.5-rc3 with the diff from v3.4..v3.5-rc5 for sound/soc/omap totally reverted: # alsactl -f blaze.aconf restore # aplay -f S16_LE -r 48000 -c 2 file.raw ... plays perfectly ... Exactly the same procedure. Only difference is I've backed out _all_ the updates to sound/soc/omap. Clearly something in there is buggered. -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: USB : Fix the EHCI enumeration and core retention issue
Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com [...] hi kevin here is pm count log on beagle XM with the above patch: What are you meaning to show by this log? This dump shows that neither PER or CORE are hitting retention in idle. Which sounds to me like you have not enabled UART runtime suspend: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms My test with your patch shows that it fixes the oops during boot, and doesn't hang during suspend, but that USB host is still preventing CORE retention during idle (after UART runtime suspend is enabled.) This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again. Kevin cat ./debug/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:3,INA:0,ON:4,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm-usbhost_pwrdm (3) sgx_clkdm-sgx_pwrdm (0) per_clkdm-per_pwrdm (19) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) core_l4_clkdm-core_pwrdm (25) core_l3_clkdm-core_pwrdm (4) d2d_clkdm-core_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) neon_clkdm-neon_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) prm_clkdm-wkup_pwrdm (0) cm_clkdm-core_pwrdm (0) regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe 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: N800 MMC broken on v3.5-rc3
On Thu, 21 Jun 2012, Paul Walmsley wrote: N800 no longer mounts MMC on v3.5-rc3: http://www.pwsan.com/omap/bootlogs/20120620/omap_cleanup_a_3.6__07b3a13957aa250ff5b5409b8ed756b113544112/n800_bootlog.txt This broke at some point between v3.4-rc2 and v3.5-rc3. Hmm looks like Tony has some fixes for this that will hopefully resolve this problem as of -rc4. - 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
[RFC] ARM: OMAP: Remove nodes dynamically at runtime
Hi all,
I am in the process of adding a device-tree binding for OMAP timers and
I have encountered a scenario where ideally it would be useful to remove
a device-tree node at runtime.
The scenario is this ...
1. OMAP3 devices may or may not have security features enabled. Security
enabled devices are known as high-secure (HS) and devices without
security are known as general purpose (GP).
2. For OMAP3 devices there are 12 general purpose timers available.
3. On secure devices the 12th timer is reserved for secure usage and so
cannot be used by the kernel, where as for a GP device it is available.
4. We can detect the OMAP device type, secure or GP, at runtime via an
on-chip register.
5. Today, when not using DT, we do not register the 12th timer as a linux
device if the device is secure.
When migrating the timers to DT, I need a way to prevent this 12th timer
from being registered as a device on a secure device. The options I have
considered are ...
a. Have separate a omap3.dtsi for GP and secure devices or place the
node for the 12th timer in a omap3-gp.dtsi that is only used for
boards with GP devices. The downside of this is that for boards
that can support GP and secure device (such as the omap3 SDP) we
require a separate dtb blob.
b. Remove the timer node dynamically at runtime using the
of_node_detach() API. In this solution we define a ti,timer-secure
property that the 12th timer on omap3 devices would have and at
runtime if we are a secure omap3 device, we search the timer nodes
for any nodes with this property and remove them.
Option B, seems to be the better option but requires me to enable
CONFIG_OF_DYNAMIC for all omap devices and I was not sure if there is any
downside to doing so. Enabling this feature does not seem to add much code
as far as I can tell, however, I wanted to get some feedback before
proposing this. Also if there are any other options I should consider then
please let me know.
For option B, the timer node would look like ...
+ timer12: timer@48304000 {
+ compatible = ti,omap3-timer;
+ ti,hwmods = timer12;
+ ti,timer-alwon;
+ ti,timer-secure;
+ };
I would then add the following function to the omap timer code to search
for any timers with the ti,timer-secure on a secure device and enable
the OF_DYNAMIC option. Right now it is only timer 12 on OMAP3 that
requires this, but I have made the function generic so that it could
handle other devices (but none exist today that I am aware of).
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 8c22a8e..5e38946 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -36,6 +36,7 @@
#include linux/clocksource.h
#include linux/clockchips.h
#include linux/slab.h
+#include linux/of.h
#include asm/mach/time.h
#include plat/dmtimer.h
@@ -482,6 +483,35 @@ static int __init omap2_dm_timer_init(void)
}
arch_initcall(omap2_dm_timer_init);
+static struct of_device_id omap3_timer_match[] __initdata = {
+ { .compatible = ti,omap3-timer, },
+ { }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with property ti,timer-secure cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the
+ * kernel registering these devices remove them dynamically from the device
+ * tree on boot.
+ */
+void __init omap_dmtimer_init(void)
+{
+ struct device_node *np;
+
+ if (!cpu_is_omap34xx())
+ return;
+
+ /* If we are a secure device, remove any secure timer nodes */
+ if ((omap_type() == OMAP2_DEVICE_TYPE_GP)) {
+ for_each_matching_node(np, omap3_timer_match) {
+ if (of_get_property(np, ti,timer-secure, NULL))
+ of_detach_node(np);
+ }
+ }
+}
+
/**
* omap2_override_clocksource - clocksource override with user configuration
*
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..d2daee0 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -27,6 +27,7 @@ config ARCH_OMAP2PLUS
select GENERIC_IRQ_CHIP
select OMAP_DM_TIMER
select USE_OF
+ select OF_DYNAMIC
select PROC_DEVICETREE if PROC_FS
help
Systems based on OMAP2, OMAP3 or OMAP4
If you prefer I send out my complete series (I believe it is only 3 patches)
for adding the timers I can do that too.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe 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: 5912OSK NFS root broken on v3.5-rc3
On Thu, 21 Jun 2012, Paul Walmsley wrote: The 5912OSK here no longer mounts NFS root: http://www.pwsan.com/omap/bootlogs/20120620/omap_cleanup_a_3.6__07b3a13957aa250ff5b5409b8ed756b113544112/ This broke at some point between v3.4-rc2 and v3.5-rc3. This one wass due to a bogus kernel command line on my 5912OSK board that started failing after commit 377485f6244af255b04d662cf19cddbbc4ae4310 (init: don't try mounting device as nfs root unless type fully matches). - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data
On Thu, 21 Jun 2012, Cousson, Benoit wrote: Paul, Will you take it as part of your fixes series for 3.5-rc? Yes, I'll take your updated version. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data
On Thu, 21 Jun 2012, Cousson, Benoit wrote:
Hi Ricardo,
In fact the flags attribute was not located correctly with regard to the
template used by the scripts.
I updated the script, the patch, the subject and fix a typo in the changelog.
Please find below the updated version.
Thanks, queued for 3.5-rc.
- Paul
---
From 9a89d06f9de9a4efbfc49d0c5adf0fa0d0031bdf Mon Sep 17 00:00:00 2001
From: Ricardo Neri ricardo.n...@ti.com
Date: Thu, 21 Jun 2012 10:08:53 +0200
Subject: [PATCH] ARM: OMAP4: hwmod data: Force HDMI in no-idle while enabled
As per the OMAP4 documentation, audio over HDMI must be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmod uses
no-idle/force-idle settings instead of smart-idle mode.
This is required as the DSS interface clock is used as functional clock
for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
be choppy, have bad quality or not be audible at all.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
[b-cous...@ti.com: Update the subject and align the .flags
location with the script template]
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index aae6e5e..f51b35f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -858,6 +858,11 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
.name = dss_hdmi,
.class = omap44xx_hdmi_hwmod_class,
.clkdm_name = l3_dss_clkdm,
+ /*
+ * HDMI audio requires to use no-idle mode. Hence,
+ * set idle mode by software.
+ */
+ .flags = HWMOD_SWSUP_SIDLE,
.mpu_irqs = omap44xx_dss_hdmi_irqs,
.sdma_reqs = omap44xx_dss_hdmi_sdma_reqs,
.main_clk = dss_48mhz_clk,
--
1.7.0.4
- 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: [PATCHv3 6/7] ARM: OMAP2+: CM: increase the module disable timeout
Hello Sergei, On Tue, 19 Jun 2012, Sergei Shtylyov wrote: diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 6b0aedc..a428305 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -30,6 +30,7 @@ #includeplat/mmc.h #includeplat/dmtimer.h #includeplat/common.h +#includeplat/usb.h How this hunk is related? Indeed, it's not. Thanks for pointing this out. Updated patch below. - Paul From: Paul Walmsley p...@pwsan.com Date: Sun, 17 Jun 2012 11:57:53 -0600 Subject: [PATCH] ARM: OMAP2+: CM: increase the module disable timeout Increase the timeout for disabling an IP block to five milliseconds. This is to handle the usb_host_fs idle latency, which takes almost four milliseconds after a host controller reset. This is the second of two patches needed to resolve the following boot warning: omap_hwmod: usb_host_fs: _wait_target_disable failed Thanks to Sergei Shtylyov sshtyl...@mvista.com for finding an unrelated hunk in a previous version of this patch. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Sergei Shtylyov sshtyl...@mvista.com Cc: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/cm.h | 11 +++ arch/arm/mach-omap2/cminst44xx.c |4 ++-- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index a7bc096..f24e3f7 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -22,4 +22,15 @@ */ #define MAX_MODULE_READY_TIME 2000 +/* + * MAX_MODULE_DISABLE_TIME: max duration in microseconds to wait for + * the PRCM to request that a module enter the inactive state in the + * case of OMAP2 3. In the case of OMAP4 this is the max duration + * in microseconds for the module to reach the inactive state from + * a functional state. + * XXX FSUSB on OMAP4430 takes ~4ms to idle after reset during + * kernel init. + */ +#define MAX_MODULE_DISABLE_TIME5000 + #endif diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c index 8c86d29..1a39945 100644 --- a/arch/arm/mach-omap2/cminst44xx.c +++ b/arch/arm/mach-omap2/cminst44xx.c @@ -313,9 +313,9 @@ int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_off omap_test_timeout((_clkctrl_idlest(part, inst, cdoffs, clkctrl_offs) == CLKCTRL_IDLEST_DISABLED), - MAX_MODULE_READY_TIME, i); + MAX_MODULE_DISABLE_TIME, i); - return (i MAX_MODULE_READY_TIME) ? 0 : -EBUSY; + return (i MAX_MODULE_DISABLE_TIME) ? 0 : -EBUSY; } /** -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe 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] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
On 06/19/2012 07:56 AM, Tony Lindgren wrote: Hi, Below is the pinctrl-single patch updated with hopefully all the Stephen's comments addressed. The binding still needs to be looked at, see relevant parts of the discussion below. ... From: Tony Lindgren t...@atomide.com Date: Wed, 6 Jun 2012 04:18:18 -0700 Subject: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver Add one-register-per-pin type device tree based pinctrl driver. Currently this driver only works on omap2+ series of processors, where there is either an 8 or 16-bit padconf register for each pin. Support for other similar pinmux controllers can be added. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt new file mode 100644 index 000..929254c --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt @@ -0,0 +1,106 @@ +One-register-per-pin type device tree based pinctrl driver + +Required properties: +- compatible : pinctrl-single + +- reg : offset and length of the register set for the mux registers + +- pinctrl-single,register-width : pinmux register access width in bits + +- pinctrl-single,function-mask : mask of allowed pinmux function bits + in the pinmux register + +- pinctrl-single,pinconf-mask : mask of allowed pinconf bits in the + pinmux register; this gets combined with pinconf mask but is a separate + mask to allow the option of setting pinconf separatately from the + function Given that this binding doesn't allow describing pin configuration at present, I would simply remove all mention of that property in the binding documentation. It can be added back if/when that feature is added. Any future driver using this binding can refuse to allow pin configuration if that property is missing. +- pinctrl-single,function-off : function off mode for disabled state if + available and same for all registers; if not, use a value larger than + function-mask to ignore disabling of registers Rather than requiring an invalid value in this property, shouldn't the lack of a valid function-off value be represented by the property not being present in the DT? +This driver assumes that there is only one register for each pin, +and uses the common pinctrl bindings as specified in the pinctrl-bindings.txt +document in this directory. At this point in the file, I think you need to mention that you're switching from describing the top-level device node to describing pin configuration nodes. +The pinctrl register offsets and default values are specified as pairs I thought we were going to remove default here? +using pinctrl-single,pins. For example, setting a pin for a device +could be done with: + + pinctrl-single,pins = 0xdc 0x118; + +Where 0xdc is the offset from the pinctrl register base address for the +device pinctrl register, and 0x118 contains the desired value of the +pinctrl register. See the device example and static board pins example +below for more information. There should be some explanation only the portion of this value covered by the pinctrl-single,function-mask value is updated in the register. +This driver tries to avoid understanding pin and function names because of +the extra bloat they would cause especially in the case of a large number +of pins. This driver just sets what is specified for the board in the .dts file. +Further user space debugging tools can be developed to decipher the pin and +function names using debugfs. There shouldn't be any discussion of a driver here; the binding is a HW description. +Example: I only reviewed the binding document, not the code. -- To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP: Remove nodes dynamically at runtime
On 06/21/2012 02:15 PM, Jon Hunter wrote:
Hi all,
I am in the process of adding a device-tree binding for OMAP timers and
I have encountered a scenario where ideally it would be useful to remove
a device-tree node at runtime.
The scenario is this ...
1. OMAP3 devices may or may not have security features enabled. Security
enabled devices are known as high-secure (HS) and devices without
security are known as general purpose (GP).
2. For OMAP3 devices there are 12 general purpose timers available.
3. On secure devices the 12th timer is reserved for secure usage and so
cannot be used by the kernel, where as for a GP device it is available.
4. We can detect the OMAP device type, secure or GP, at runtime via an
on-chip register.
5. Today, when not using DT, we do not register the 12th timer as a linux
device if the device is secure.
When migrating the timers to DT, I need a way to prevent this 12th timer
from being registered as a device on a secure device. The options I have
considered are ...
a. Have separate a omap3.dtsi for GP and secure devices or place the
node for the 12th timer in a omap3-gp.dtsi that is only used for
boards with GP devices. The downside of this is that for boards
that can support GP and secure device (such as the omap3 SDP) we
require a separate dtb blob.
b. Remove the timer node dynamically at runtime using the
of_node_detach() API. In this solution we define a ti,timer-secure
property that the 12th timer on omap3 devices would have and at
runtime if we are a secure omap3 device, we search the timer nodes
for any nodes with this property and remove them.
Option B, seems to be the better option but requires me to enable
CONFIG_OF_DYNAMIC for all omap devices and I was not sure if there is any
downside to doing so. Enabling this feature does not seem to add much code
as far as I can tell, however, I wanted to get some feedback before
proposing this. Also if there are any other options I should consider then
please let me know.
For option B, the timer node would look like ...
+ timer12: timer@48304000 {
+ compatible = ti,omap3-timer;
+ ti,hwmods = timer12;
+ ti,timer-alwon;
+ ti,timer-secure;
+ };
I would then add the following function to the omap timer code to search
for any timers with the ti,timer-secure on a secure device and enable
the OF_DYNAMIC option. Right now it is only timer 12 on OMAP3 that
requires this, but I have made the function generic so that it could
handle other devices (but none exist today that I am aware of).
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 8c22a8e..5e38946 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -36,6 +36,7 @@
#include linux/clocksource.h
#include linux/clockchips.h
#include linux/slab.h
+#include linux/of.h
#include asm/mach/time.h
#include plat/dmtimer.h
@@ -482,6 +483,35 @@ static int __init omap2_dm_timer_init(void)
}
arch_initcall(omap2_dm_timer_init);
+static struct of_device_id omap3_timer_match[] __initdata = {
+ { .compatible = ti,omap3-timer, },
+ { }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with property ti,timer-secure cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the
+ * kernel registering these devices remove them dynamically from the device
+ * tree on boot.
+ */
+void __init omap_dmtimer_init(void)
+{
+ struct device_node *np;
+
+ if (!cpu_is_omap34xx())
+ return;
+
+ /* If we are a secure device, remove any secure timer nodes */
+ if ((omap_type() == OMAP2_DEVICE_TYPE_GP)) {
Oops! Bug in the above code. Meant to be ...
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
+ for_each_matching_node(np, omap3_timer_match) {
+ if (of_get_property(np, ti,timer-secure, NULL))
+ of_detach_node(np);
+ }
+ }
+}
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP2+: clock/hwmod/warning fixes for 3.5-rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71: Linux 3.5-rc3 (2012-06-16 17:25:17 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-fixes-a-for-3.5rc for you to fetch changes up to dc57aef503859dbf724f6126c58b2e1672e215f3: ARM: OMAP4: hwmod data: Force HDMI in no-idle while enabled (2012-06-21 18:08:47 -0600) - Some uncontroversial OMAP clock, hwmod, and compiler warning fixes for 3.5-rc - Testing logs are at http://www.pwsan.com/omap/bootlogs/20120621/omap_fixes_a_3.5rc__dc57aef503859dbf724f6126c58b2e1672e215f3/ N800 doesn't boot due to MMC problems; 3517 boards won't NFS-mount root and WARN() during boot; 37xx EVM and Beagle don't wake up from the serial port from off-mode system suspend, and the CORE powerdomain doesn't enter retention or off-mode during either dynamic idle or system suspend; and OMAP4430 Panda doesn't return from system suspend. All of these problems were pre-existing with v3.5-rc3; none of them were added by this patch set. object size (delta in bytes from v3.5-rc3 (485802a6c524e62b5924849dd727ddbb1497cc71)): textdata bss total kernel 0 0 0 0 5912osk_testconfig/vmlinux 0 0 0 0 am33xx_testconfig/vmlinux +32 0 0 +32 n800_b_testconfig/vmlinux 0 0 0 0 n800_multi_omap2xxx/vmlinux +32 0 0 +32 n800_testconfig/vmlinux 0 0 0 0 omap1510_defconfig/vmlinux 0 0 0 0 omap1_defconfig/vmlinux +32 0 0 +32 omap2_4_testconfig/vmlinux +4160 0 0 +4160 omap2plus_defconfig/vmlinux 0 0 0 0 omap2plus_no_pm/vmlinux 0 0 0 0 omap3_4_testconfig/vmlinux 0 0 0 0 omap3_testconfig/vmlinux 0 0 0 0 omap4_testconfig/vmlinux Djamil Elaidi (1): ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby Paul Walmsley (4): ARM: OMAP4: hwmod data: fix 32k sync timer idle modes ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks ARM: OMAP2+: CM: increase the module disable timeout ARM: OMAP2+: mux: fix sparse warning Ricardo Neri (1): ARM: OMAP4: hwmod data: Force HDMI in no-idle while enabled Todd Poynor (1): ARM: OMAP: PM: Lock clocks list while generating summary arch/arm/mach-omap2/clock44xx_data.c |5 + arch/arm/mach-omap2/cm.h | 11 +++ arch/arm/mach-omap2/cminst44xx.c |4 ++-- arch/arm/mach-omap2/mux.c |1 + arch/arm/mach-omap2/omap_hwmod.c |2 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8 ++-- arch/arm/plat-omap/clock.c |2 ++ 7 files changed, 28 insertions(+), 5 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJP48aYAAoJEMePsQ0LvSpLE2EQAIvqIGIieWWlNYfGCQ74wK5F zZydqjd3teFqxLbbTXRSKjhyQxKFNkPKMNAnGVOidA8y9nqu6Kcx4L7lSHyZBEow Uq7bEzDjrRgpB7ThlQvYvGHc2cKbkY2QM4duST7AeJMiDwndPbMyL0k9uonTsNmb N9TKw7un5/nck+30BUgDt/JVzUl+CuhojfNzs5ZNQ/Ad5hnRqg3s5RE4mZQIot06 s6vAdOTEKqlutYmxHNrJ7oFcTc/h0t0dE5JvR9+oDDPcALQ7BVHoaaf+94G3m4od pVmYktcS3Jkqm3dUE2bWzno9yTKgJGEBUauT0wW8yZcNa2Pk3cmEqu5WQ/V5AiAy ziOYUglLa64EKcz7P7TauRciPFNiNCk7BRAr/YkBoeIee2heTVt2TseEOOk7hxIy 3iQalfEmSNe/fuSHj9gKIa0qqP/GiaJEQzGJ7WPQqwCGovn+38je7MOAtoCx+XGr fySjYYG8PYtwac7xpHdki7xp/iBNDCMWuIETwZC33kWMsiUlI1sZDXXlU41oFdZH MszwY8uZCvYpg+e78Mz+NChjcL27Ubcbpf+XXL+839ZPVlWs4FDU2f2wpQnWNCZ/ VWlbANdDUFNUI+Fj5dzS7WCswlMWVMdkcYOLd5aAXFkWOumW/sXNWzNATSExESUQ 4SXhheBjiDe0dLo0MIHL =/3fz -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
