Hi,
Here is an initial set of fixes for power management and OMAP core
infrastructure for 3.5-rc. Most of these patches address boot
warnings and power management problems on OMAP4, although a few of
them address more general issues.
Thanks to (in alphabetical order) Benoît Cousson, Tero
The 32k sync timer IP block target idle modes in the hwmod data are
incorrect. The IP block does not support any smart-idle modes.
Update the data to reflect the correct modes.
This problem was initially identified and a diff fragment posted to
the lists by Benoît Cousson b-cous...@ti.com. A
Commit bbd707acee279a61177a604822db92e8164d00db (ARM: omap2: use
machine specific hook for late init) resulted in the addition of this
sparse warning:
arch/arm/mach-omap2/mux.c:791:12: warning: symbol 'omap_mux_late_init' was not
declared. Should it be static?
Fix by including the header file
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:
From: Todd Poynor toddpoy...@google.com
Commit a53025724052b2b1edbc982a4a248784638f563d (OMAP: Add debugfs
node to show the summary of all clocks) introduced clock summary,
however, we are interested in seeing snapshot of the clock state, not
in dynamically changing clock configurations as the
From: Djamil Elaidi d-ela...@ti.com
If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature
the
IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup.
Signed-off-by: Djamil Elaidi d-ela...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it. This
patch populates some clock structure clockdomain names to resolve the
following warnings
Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
(ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database) broke CORE idle on OMAP3. This prevents device low power
states.
The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and
On Thursday 14 June 2012 06:20 PM, Russell King - ARM Linux wrote:
because, at the time when omap2_mcspi_setup() is called, spi-dev is
not bound, and so is outside of the devres valid lifetime of that
struct device.
Agree,
Apologies for breaking in the initial commit.
--
To unsubscribe from
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
On Sat, 2012-06-16 at 03:31 +0530, jaswinder.si...@linaro.org wrote:
From: Jassi Brar jaswinder.si...@linaro.org
Explicitly maintaining HDMI phy power state using a flag is prone to
race and un-necessary when we have a zero-cost alternative of checking
the state before trying to set it.
Why
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
On Fri, Jun 15, 2012 at 12:36 AM, Sarashetti, Mantesh mant...@ti.com wrote:
'Acked-by: mant...@ti.com'
'Tested-by: mant...@ti.com'
Regards,
Mantesh
-Original Message-
From: Russ Dill [mailto:russ.d...@gmail.com] On Behalf Of Dill, Russ
Sent: Thursday, June 14, 2012 11:24 AM
To:
The support for using a timer to wake from suspend was removed in:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864
I found an alternative patch
(http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47836.html)
that
Hi Kevin,
On Tue, Jun 12, 2012 at 10:37 PM, Kevin Hilman khil...@ti.com wrote:
ABRAHAM, KISHON VIJAY kis...@ti.com writes:
Hi Kevin, Benoit, Paul,
On Fri, Jun 1, 2012 at 2:16 AM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote:
I would mark the
Hi Paul,
On 6/18/2012 8:16 AM, Paul Walmsley wrote:
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it. This
patch populates some clock structure
The commit 503d0ea24d1d3dd3db95e5e0edd693da7a2a23eb
ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks
added a wrong prcm_clk alias for PRCM clock whereas the McBSP
driver and previous OMAPs are using prcm_fck.
It thus lead to the following warning.
[ 47.409729] omap-mcbsp: clks:
On Mon, Jun 18, 2012 at 2:48 PM, Tasslehoff Kjappfot
tasskj...@gmail.com wrote:
The support for using a timer to wake from suspend was removed in:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864
I found an alternative
No file includes omap730.h or omap850.h. That's not surprising, as
commit e6684f7132c6e6333e96407b06910bebaa4c1935 (OMAP7XX: Create
omap7xx.h) created a header that was intended to replace omap730.h and
omap850.h, while all values defined [in omap7xx.h] are identical to
those in both the old
On 18 June 2012 13:41, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Explicitly maintaining HDMI phy power state using a flag is prone to
race and un-necessary when we have a zero-cost alternative of checking
the state before trying to set it.
Why would reading the value from the register be
I have a GUMSTIX Overo AirSTORM module (AM3703-based).
When booting the kernel the following features are listed:
OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk )
After booting I get the following (repeating every few seconds):
[ 81.122558] voltdm_scale: No voltage scale API registered for
On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
On 18 June 2012 13:41, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Explicitly maintaining HDMI phy power state using a flag is prone to
race and un-necessary when we have a zero-cost alternative of checking
the state before trying to
On Monday 18 June 2012 09:57 AM, Paul Walmsley wrote:
On Thu, 14 Jun 2012, Rajendra Nayak wrote:
OMAP3 has suspend broken in mainline, so I tested it on an
older kernel (3.4-rc4 using my RFC series)
Idle and OFF mode however seem to be broken for a long time,
I wasn;t able to get it working
Hello.
This is a next version of series of patches(based on Eduardo Valentin's patch
set) adding a basic support for system control module, on OMAP4+ context. It is
a working in progress.
Main changes since previous patch set version:
- Bandgap and usb phy: drivers are now independent from
This patch exposes the definitions under control.h to
drivers outside the machine code.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/mach-omap2/am35xx-emac.c|2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
This patch introduces a MFD core device driver for
OMAP system control module.
The control module allows software control of
various static modes supported by the device. It is
composed of two control submodules: general control
module and device (padconfiguration) control
module.
Changes since
Created a new platform driver for the platform device created by the
control module mfd core, wrt usb. This driver has API's to power on/off
the phy and the API's to write to musb mailbox.
Changes since previous version:
- Bandgap and usb phy: drivers are now independent from control module
OMAP4460 specific temperature sensor register bit fields are added.
Existing OMAP4 entries are renamed to OMAP4430.
Signed-off-by: Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/mach-omap2/include/mach/control.h | 116
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
---
arch/arm/mach-omap2/id.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index:
In the System Control Module, OMAP supplies a voltage reference
and a temperature sensor feature that are gathered in the band
gap voltage and temperature sensor (VBGAPTS) module. The band
gap provides current and voltage reference for its internal
circuits and other analog IP blocks. The
This patch exposes OMAP4 thermal sensor as a thermal zone
named cpu. Only thermal creation is done here.
TODO:
- Add cooling bindings
- Add extrapolation rules
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/Kconfig | 12 ++
drivers/thermal/Makefile
This patch adds device tree entries on OMAP4 based boards
for System Control Module (SCM).
TODO:
The IOMEM windows of ctrl_module_core, bandgap, usbphy overlap, so
probably only specific registers should be specified in dts for
bandgap and usb phy entries.
Signed-off-by: Konstantin Baydarov
On 18 June 2012 16:24, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
BTW, coming to think about it, I am not sure what we need the
spin_lock_irqsave() protection for in hdmi_check_hpd_state() ? It
can't control HPD gpio state change and
Hello.
On 18-06-2012 15:32, Konstantin Baydarov wrote:
This patch adds device tree entries on OMAP4 based boards
for System Control Module (SCM).
TODO:
The IOMEM windows of ctrl_module_core, bandgap, usbphy overlap, so
probably only specific registers should be specified in dts for
bandgap
On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
On 18 June 2012 16:24, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
BTW, coming to think about it, I am not sure what we need the
spin_lock_irqsave() protection for in
On 18 June 2012 17:54, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
So preferably I would move request_threaded_irq() to after
hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the
No, you can't move the check. If you move
On Mon, 2012-06-18 at 18:37 +0530, Jassi Brar wrote:
On 18 June 2012 17:54, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
So preferably I would move request_threaded_irq() to after
hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and
Thanks Keshava.
Regards
Sunil Matange
-Original Message-
From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, June 18, 2012 1:59 PM
To: Samuel Ortiz
Cc: Dill, Russ; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Balbi, Felipe; Partha Basak; Igor
On 18 June 2012 18:41, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-06-18 at 18:37 +0530, Jassi Brar wrote:
On 18 June 2012 17:54, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
So preferably I would move request_threaded_irq()
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
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
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
---
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
From: Felipe Balbi ba...@ti.com
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git
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
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
From: Felipe Balbi ba...@ti.com
stat BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D
From: Felipe Balbi ba...@ti.com
trivial patch, no functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 63
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
From: Felipe Balbi ba...@ti.com
trivial patch, no functional changes
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2
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
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
Dear all,
when configuring our platform (DM8148 based) to work with USB0 as device
and USB1 as host I've found some problems.
It was fine if I configure both as device or both as host or enable only
one port, but configure both in different modes lead to a not working
configuration.
After a
Hi Mathias,
On Fri, Jun 01, 2012 at 08:06:00PM +0200, Mathias Leblanc wrote:
* STMicroelectronics version 1.2.0, Copyright (C) 2010
* STMicroelectronics comes with ABSOLUTELY NO WARRANTY.
* This is free software, and you are welcome to redistribute it
* under certain conditions.
This
On Mon, Jun 18, 2012 at 08:00:25PM +0530, Shubhrajyoti D wrote:
From: Felipe Balbi ba...@ti.com
trivial patch, no functional changes
Wrong. This patch does change some behaviour, are you aware of that?
So, please check if the side-effect is affectong the code and adapt the
commit message, if
On Mon, Jun 18, 2012 at 08:00:26PM +0530, Shubhrajyoti D wrote:
From: Felipe Balbi ba...@ti.com
trivial patch, no functional changes.
This patch seems to be correct, but it is not trivial. In fact, it is
pretty easy to miss a ! here which can cause subtle bugs.
Signed-off-by: Felipe Balbi
On Mon, Jun 18, 2012 at 08:00:28PM +0530, Shubhrajyoti D wrote:
From: Felipe Balbi ba...@ti.com
stat BIT(1) is the same as BIT(1),
Not true. I'd guess you are missing some context in the patch
description.
so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat()
On Mon, Jun 18, 2012 at 08:00:15PM +0530, Shubhrajyoti D wrote:
The patch series does the following
- I2C register restore only if context if the context is lost
- Bus busy recovery mechanism.
- the reset is not done in init.
- Adds a patch to use devm_* functions
- Adds a pdata function
Hi
On Mon, 18 Jun 2012, Cousson, Benoit wrote:
I guess that patch need to be revisited based on discussion we had and
the patch you proposed in [1]. Assuming Tony is OK, it should be
probably part of the -rc, because this domain should not have been
introduced in 3.5-rc1 at all for OMAP4.
On Mon, 18 Jun 2012, Cousson, Benoit wrote:
The commit 503d0ea24d1d3dd3db95e5e0edd693da7a2a23eb
ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks
added a wrong prcm_clk alias for PRCM clock whereas the McBSP
driver and previous OMAPs are using prcm_fck.
It thus lead to the
Hi Afzal,
Thanks for sending the update.
On 06/16/2012 03:03 AM, Afzal Mohammed wrote:
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
Hi
On Thu, 14 Jun 2012, Peter Ujfalusi wrote:
To keep the McBSP fck alias handling in sync among OMAP versions.
Change the legacy implementation for OMAP2/3 regarding to McBSP fck alias.
OMAP4 (and OMAP5) uses the hwmod data to specify the aliases for the fcks and
it is also needed for the
Hi,
On Fri, 20 Apr 2012, Tarun Kanti DebBarma wrote:
Add an API to get main clock name associated with a given @oh.
This will avoid the need to construct fclk names during early
initialization in order to get fclk handle using clk_get().
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Paul
On Thu, 7 Jun 2012, Rajendra Nayak wrote:
On Thursday 07 June 2012 11:43 AM, Paul Walmsley wrote:
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated
Tasslehoff Kjappfot tasskj...@gmail.com writes:
The support for using a timer to wake from suspend was removed in:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864
I found an alternative patch
Hi Vaibhav,
On Thu, 14 Jun 2012, Hiremath, Vaibhav wrote:
Leaving HWMOD data patch aside, both the above patches should be
considered for acceptance, can you please review the same and if there
are no review comments, can it be merged?
I don't quite understand the part about leaving the
On Mon, Jun 18, 2012 at 23:36:58, Paul Walmsley wrote:
Hi Vaibhav,
On Thu, 14 Jun 2012, Hiremath, Vaibhav wrote:
Leaving HWMOD data patch aside, both the above patches should be
considered for acceptance, can you please review the same and if there
are no review comments, can it be
On Mon, 18 Jun 2012, Hiremath, Vaibhav wrote:
I would really recommend you to look at the proposal of getting the clock-
tree and hwmod patches to the linux-next until merge window, so that it will
get tested for some time.
I've thought about this, but I'm not sure it has much point unless
On Mon, Jun 18, 2012 at 23:58:36, Paul Walmsley wrote:
On Mon, 18 Jun 2012, Hiremath, Vaibhav wrote:
I would really recommend you to look at the proposal of getting the clock-
tree and hwmod patches to the linux-next until merge window, so that it
will
get tested for some time.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following changes since commit 08f3098928c991560408e8c71d4af8b1a3ff2d67:
ARM: OMAP2+: am33xx: Add AM335XEVM machine support (2012-06-05 00:52:37 -0700)
are available in the git repository at:
On 20120614-18:16, Rajendra Nayak wrote:
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index e548c43..e4911ee 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -32,30 +32,69 @@
#define div_mask(d) ((1 (d-width)) - 1)
#define
On Tue, 15 May 2012, Hiremath, Vaibhav wrote:
Paul,
Can you please add above statement, when you merge it into your repo?
Added this, and added Santosh's ack, and queued for 3.6.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Hi Jon,
On Thu, 7 Jun 2012, Jon Hunter wrote:
The problem is that currently none of the clocks are being registered for
OMAP4470 devices and so on boot-up no clocks can be found and the kernel
panics.
This fix always the kernel to boot without failure using a simple RAMDISK file
system.
Hi
On Sat, 16 Jun 2012, Ricardo Neri wrote:
I would like to revive an old discussion regarding how to use a particular
idle mode for a specific use-case[1].
As per the OMAP4 documentation, audio over HDMI should be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that
Hi Paul,
On 6/18/2012 5:45 PM, Paul Walmsley wrote:
Hi
On Mon, 18 Jun 2012, Cousson, Benoit wrote:
I guess that patch need to be revisited based on discussion we had and
the patch you proposed in [1]. Assuming Tony is OK, it should be
probably part of the -rc, because this domain should not
The beagleboard USB Host Port that is used is Port 2. The platform driver sets
MODE_PHY for port 1 causing pin muxing to override the pins on the expansion
connector P17 when using board_mux[]. Since USBHS Port 1 is not connected
remove the case for muxing the USB Port1 pins by default.
Patch
Hi Afzal,
I just wanted to follow back up. We are still trying to find this slab bug,
but so far we've not found any smoking guns. Less than stable power is our
current main suspect. As has been the custom however, the error was here 2
weeks ago nearly non-stop, and then as suddenly as it
On 20120614-18:16, Rajendra Nayak wrote:
plat/clock.c which has most of usecounting/locking infrastructure will
be used only for OMAP1 until that is moved to use COMMON clk.
reuse most of what plat/clock.h has while we move to common clk, and
move most of what 'struct clk' was as 'struct
On Mon, Jun 18, 2012 at 2:42 PM, Brian Austin brian.aus...@cirrus.com wrote:
The beagleboard USB Host Port that is used is Port 2. The platform driver
sets MODE_PHY for port 1 causing pin muxing to override the pins on the
expansion
connector P17 when using board_mux[]. Since USBHS Port 1 is
On Monday 18 June 2012 11:11 PM, Paul Walmsley wrote:
On Thu, 7 Jun 2012, Rajendra Nayak wrote:
On Thursday 07 June 2012 11:43 AM, Paul Walmsley wrote:
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a
On Tuesday 19 June 2012 01:34 AM, Mike Turquette wrote:
On 20120614-18:16, Rajendra Nayak wrote:
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index e548c43..e4911ee 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -32,30 +32,69 @@
#define
Hi Jon,
On Mon, Jun 18, 2012 at 21:31:46, Hunter, Jon wrote:
@@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
if (err)
return err;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base +
82 matches
Mail list logo
