On Thursday 06 October 2011 07:12 AM, Tony Lindgren wrote:
> * Santosh Shilimkar [111004 23:29]:
>>
>> Will look at this series in next couple of days and do some testing.
>
> Thanks, turns out there were a few issues with early ioremap
> that I fixed. Care to check the L4_IO_ADDRESS changes?
>
T
On Thursday 06 October 2011 07:06 AM, Tony Lindgren wrote:
> * Nicolas Pitre [111004 18:17]:
>> On Tue, 4 Oct 2011, Tony Lindgren wrote:
>>
>>> Otherwise we can't do generic map_io as we currently rely on
>>> static mappings that work only because of arch_ioremap.
>>>
>>> Signed-off-by: Tony Lindg
On Thursday 06 October 2011 03:43 AM, Tony Lindgren wrote:
> * Nicolas Pitre [111004 17:34]:
>> On Tue, 4 Oct 2011, Tony Lindgren wrote:
>>
>>> This allows us to remove omap hacks for map_io.
>>>
>>> Signed-off-by: Tony Lindgren
>>
>> Nice cleanup.
>>
>> Acked-by: Nicolas Pitre
>
> This one nee
On Fri, Oct 07, 2011 at 10:33:05AM +0500, G, Manjunath Kondaiah wrote:
Why did you send this series of patches out twice? Were they different?
confused,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More m
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
>
> From: Grant Likely
>
> Allow drivers to report at probe time that they cannot get all the
> resources required by the device, and should be retried at a
> later time.
>
> This should completely solve the problem of gett
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
>
> Add new error value so that drivers can request deferred probe
> from drivercore.
>
> Signed-off-by: G, Manjunath Kondaiah
> Reported-by: Grant Likely
> ---
> Cc: linux-omap@vger.kernel.org
> Cc: linux-...@vger.kernel.or
On Wednesday 05 October 2011 06:15 AM, Tony Lindgren wrote:
> This way we don't need to initialize SoC detection early
> and can start using generic map_io.
>
> Signed-off-by: Tony Lindgren
> ---
Reviewed-by: Santosh Shilimkar
Tested-by: Santosh Shilimkar
--
To unsubscribe from this list: send
On Thursday 06 October 2011 03:36 AM, Tony Lindgren wrote:
> * Nicolas Pitre [111004 17:26]:
>> On Tue, 4 Oct 2011, Tony Lindgren wrote:
>>
>>> This allows mapping external memory such as SRAM for use.
>>>
>>> This is needed for some small chunks of code, such as reprogramming
>>> SDRAM memory sou
Existing omap hsmmc driver uses "platform_driver_probe" in init
function. Change it to use "platform_driver_register" in order to
use deferral probe mechanism.
Signed-off-by: G, Manjunath Kondaiah
Reported-by: Grant Likely
---
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: lin
The gpio library should return -EPROBE_DEFER in gpio_request
if gpio driver is not ready. If drivers pass this error code through to
their caller (which they really should) then this will ensure that the
probe is retried later when further devices become available.
Signed-off-by: G, Manjunath Kon
From: Mark Brown
If we fail to locate a requested regulator return -EPROBE_DEFER. If drivers
pass this error code through to their caller (which they really should)
then this will ensure that the probe is retried later when further devices
become available.
Signed-off-by: Mark Brown
[manj...@t
From: Grant Likely
Allow drivers to report at probe time that they cannot get all the
resources required by the device, and should be retried at a
later time.
This should completely solve the problem of getting devices
initialized in the right order. Right now this is mostly handled by
muckin
Add new error value so that drivers can request deferred probe
from drivercore.
Signed-off-by: G, Manjunath Kondaiah
Reported-by: Grant Likely
---
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Grant Likely
Cc: Greg Kroah-Hartman
Cc: Dilan Le
Original patch posted at:
http://comments.gmane.org/gmane.linux.kernel/1194346
Enhancements done to above patch:
- checkpatch warning fixes
- added Kconfig symbol CONFIG_PROBE_DEFER
- replacing normal workqueue with singlethread_workqueue
- handling -EPROBE_DEFER error
Apart from that, OMAP
From: Mark Brown
If we fail to locate a requested regulator return -EPROBE_DEFER. If drivers
pass this error code through to their caller (which they really should)
then this will ensure that the probe is retried later when further devices
become available.
Signed-off-by: Mark Brown
[manj...@t
From: Grant Likely
Allow drivers to report at probe time that they cannot get all the
resources required by the device, and should be retried at a
later time.
This should completely solve the problem of getting devices
initialized in the right order. Right now this is mostly handled by
muckin
Add new error value so that drivers can request deferred probe
from drivercore.
Signed-off-by: G, Manjunath Kondaiah
Reported-by: Grant Likely
---
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Grant Likely
Cc: Greg Kroah-Hartman
Cc: Dilan Le
Original patch posted at:
http://comments.gmane.org/gmane.linux.kernel/1194346
Enhancements done to above patch:
- checkpatch warning fixes
- added Kconfig symbol CONFIG_PROBE_DEFER
- replacing normal workqueue with singlethread_workqueue
- handling -EPROBE_DEFER error
Apart from that, OMAP
Existing omap hsmmc driver uses "platform_driver_probe" in init
function. Change it to use "platform_driver_register" in order to
use deferral probe mechanism.
Signed-off-by: G, Manjunath Kondaiah
Reported-by: Grant Likely
---
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: lin
The gpio library should return -EPROBE_DEFER in gpio_request
if gpio driver is not ready. If drivers pass this error code through to
their caller (which they really should) then this will ensure that the
probe is retried later when further devices become available.
Signed-off-by: G, Manjunath Kon
Hi Jean
On Wed, 21 Sep 2011, jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> Figures are added to the power domains structs for RET and OFF modes.
>
> Note: the latency figures for MPU, PER, CORE, NEON have been obtained
> from actual measurements.
> The latency figures for the other p
On Tue, Oct 04, 2011 at 05:35:04PM -0600, Grant Likely wrote:
> On Wed, Oct 05, 2011 at 12:05:16AM +0530, G, Manjunath Kondaiah wrote:
> > On Tue, Oct 04, 2011 at 09:58:10AM -0600, Grant Likely wrote:
> > > On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah
> > > wrote:
> > > > On Thu, Sep 22,
Tony Lindgren wrote on Friday, October 07, 2011 12:47 AM:
> * Pedanekar, Hemant [111004 02:07]:
>> Igor Grinberg wrote on Tuesday, October 04, 2011 2:31 PM:
>>
>>> On 10/03/11 18:45, Pedanekar, Hemant wrote:
Hi Igor,
Igor Grinberg wrote on Sunday, October 02, 2011 5:38 PM:
Hi
a comment:
On Wed, 21 Sep 2011, jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> Hwmod is queried from the OMAP_PM layer to manage the power domains
> wake-up latency constraints. Hwmod retrieves the correct power domain
> and if it exists it calls the corresponding power domain func
+ Benoît
On Fri, 16 Sep 2011, Jon Hunter wrote:
> From: Jon Hunter
>
> Currently the interface clocks for the two SLIMBUS peripherals are
> named slimbus1_fck and slimbus2_fck. Rename these clocks to be
> slimbus1_ick and slimbus2_ick so it is clear that these are
> interface clocks and not fun
On Fri, 16 Sep 2011, Jon Hunter wrote:
> From: Jon Hunter
>
> The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
> clock frequency (fint) operating range than OMAP3430. Update the
> dpll_test_fint() function to check for the correct frequency ranges
> for OMAP36xx and OMAP4xxx.
Fix "Enable 32kHz OS timer in order to allow sleep states in idle"
warning. We are now compiling in bothe MPU timer and 32 KiHz timer,
so this warning is only valid when CONFIG_OMAP_32K_TIMER is not set.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.
Hi Tony,
The following changes since commit be73246058737beec52ae232bcab7776332a9e06:
ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37
-0700)
are available in the git repository at:
git://git.pwsan.com/linux-2.6 hwmod_dss_fixes_3.2
Archit Taneja (1):
ARM:
Paul Walmsley writes:
> Based on the documents that I have here, there doesn't appear to be an
> equivalent to erratum i443 for OMAP3630, so restrict this one to OMAP34xx
> chips.
>
> Also, explicitly restrict this erratum to EMU and HS devices.
>
> Signed-off-by: Paul Walmsley
> Cc: Kevin Hilma
Paul Walmsley writes:
> The way that we detect which OMAP3 chips support I/O wakeup and
> software I/O chain clock control is broken.
>
> Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
> than the AM3505/3517. The TI81xx family of SoCs are at present
> considered to be OMAP3
* Paul Walmsley [111006 15:50]:
>
> Commit d6504acd2125984c61dce24727dd3842d0144015 ("OMAP2+: hwmod:
> remove OMAP_CHIP*") tests the inverse condition of what it should be
> testing for the return value from omap_hwmod_register(). This causes
> several IP blocks to not be registered on several O
Commit d6504acd2125984c61dce24727dd3842d0144015 ("OMAP2+: hwmod:
remove OMAP_CHIP*") tests the inverse condition of what it should be
testing for the return value from omap_hwmod_register(). This causes
several IP blocks to not be registered on several OMAP3 family devices.
Fixing that bug also
On Thu, 6 Oct 2011, Russell King - ARM Linux wrote:
> On Thu, Oct 06, 2011 at 02:39:28PM -0600, Paul Walmsley wrote:
> > @@ -3240,7 +3240,7 @@ int __init omap3xxx_hwmod_init(void)
> >
> > /* Register hwmods common to all OMAP3 */
> > r = omap_hwmod_register(omap3xxx_hwmods);
> > - if (
The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chain clock control is broken.
Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
than the AM3505/3517. The TI81xx family of SoCs are at present
considered to be OMAP3 SoCs, but don't support I/O wakeup
* Paul Walmsley [111006 15:37]:
> On Thu, 9 Jun 2011, Tomi Valkeinen wrote:
>
> > get_context_loss_count functions return context loss count as u32, and
> > zero means an error. However, zero is also returned when context has
> > never been lost and could also be returned when the context loss co
On Thu, 9 Jun 2011, Tomi Valkeinen wrote:
> get_context_loss_count functions return context loss count as u32, and
> zero means an error. However, zero is also returned when context has
> never been lost and could also be returned when the context loss count
> has wrapped and goes to zero.
>
> Ch
* hvaib...@ti.com [110920 06:59]:
> From: Afzal Mohammed
>
> Add support for low level debugging on AM335X EVM (AM33XX family).
> Currently only support for UART1 console, which is used on AM335X EVM
> is added.
Let's wait a bit on this one as there are other DEBUG_LL patches
pending from Nico.
* hvaib...@ti.com [110920 06:59]:
> From: Afzal Mohammed
>
> This patch adds minimal support and build configuration for
> AM335X EVM.
...
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-am335xevm.c
> +
> +MACHINE_START(AM335XEVM, "am335xevm")
> + /* Maintainer: Texas Instruments */
> +
On Thu, 6 Oct 2011, Russell King - ARM Linux wrote:
> On Thu, Oct 06, 2011 at 01:47:22PM -0600, Paul Walmsley wrote:
> > + if ((omap_rev() == OMAP3430_REV_ES3_1 ||
> > +omap_rev() == OMAP3430_REV_ES3_1_2) ||
> > + cpu_is_omap3630())
> > + omap_features |= OMAP3_HAS_IO_CHA
* hvaib...@ti.com [110920 06:59]:
> From: Afzal Mohammed
>
> This patch updates the common platform files with AM335X device
> support (AM33XX family).
>
> The approach taken in this patch is,
> AM33XX device will be considered as OMAP3 variant, and a separate
> SoC class created for AM33XX fam
* Kevin Hilman [110930 09:35]:
> "Premi, Sanjeev" writes:
>
> Actually, looking at this closer, I think the infrastructure is already
> there to handle this cleanly.
>
> Basically, dpll5 should not even be registered for SoCs where it doesn't
> exist. Then, any attempts to use DPLL5 would know
Convert to use matrix keyboard to remove the warning
"Please update the board to use matrix-keypad driver".
Based on similar setup in palmtc.c. Note that this
patch is compile tested only because of lack of working
hardware.
Signed-off-by: Tony Lindgren
--- a/arch/arm/mach-omap2/board-h4.c
+++
Convert to use matrix keyboard to remove the warning
"Please update the board to use matrix-keypad driver".
Based on similar setup in palmtc.c. Note that this
patch is compile tested only because of lack of working
hardware.
Signed-off-by: Tony Lindgren
--- a/arch/arm/mach-omap2/board-h4.c
+++
On Thu, Oct 06, 2011 at 02:39:28PM -0600, Paul Walmsley wrote:
> @@ -3240,7 +3240,7 @@ int __init omap3xxx_hwmod_init(void)
>
> /* Register hwmods common to all OMAP3 */
> r = omap_hwmod_register(omap3xxx_hwmods);
> - if (!r)
> + if (IS_ERR_VALUE(r))
> return r;
On Thu, Oct 06, 2011 at 01:47:22PM -0600, Paul Walmsley wrote:
> + if ((omap_rev() == OMAP3430_REV_ES3_1 ||
> + omap_rev() == OMAP3430_REV_ES3_1_2) ||
> + cpu_is_omap3630())
> + omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
(a || b) || c === a || b || c
IOW, n
>From 253cd48082df008c8e952fe8a4b8c0388c37d334 Mon Sep 17 00:00:00 2001
From: Paul Walmsley
Date: Thu, 6 Oct 2011 12:29:46 -0600
Subject: [PATCH] ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control
detection
The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chai
On Thu, Oct 6, 2011 at 12:47 PM, Paul Walmsley wrote:
>
> The way that we detect which OMAP3 chips support I/O wakeup and
> software I/O chain clock control is broken.
>
> Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
> than the AM3505/3517. The TI81xx family of SoCs are at
The HSMMC1/HSMMC2 host controllers on OMAP34xx and
OMAP3503/3515/3525/3530 chips at ES levels prior to 3.0 can't do multiple
block reads[1]. Mark the hwmod data appropriately.
Reported by Dave Hylands and Steve Sakoman
.
1. See for example Advisory 2.1.1.128 "MMC: Multiple Block Read
Operat
When device data indicates that multiple block reads are not supported on
a given HSMMC controller instance, log a message to the console, and
pass the appropriate MMC capability flag to the MMC core.
Signed-off-by: Paul Walmsley
Cc: Dave Hylands
Cc: Steve Sakoman
Cc: Chris Ball
---
arch/arm/
Due to hardware bugs, some MMC host controllers don't support
multiple-block reads[1]. To resolve, add a new MMC capability flag,
MMC_CAP_NO_MULTI_READ, which can be set by affected host controller
drivers. When this capability is set, all reads will be issued one
sector at a time.
1. See for ex
Hello,
Some MMC controller instances integrated on older OMAP34xx/35xx chips
don't work correctly with multiple-block reads, due to a hardware bug.
This series fixes the problem by adding an MMC capability flag for this
case and making the appropriate changes to the MMC core code and OMAP HSMMC
dr
* Paul Walmsley [111006 13:05]:
>
> Commit d6504acd2125984c61dce24727dd3842d0144015 ("OMAP2+: hwmod:
> remove OMAP_CHIP*") tests the inverse condition of what it should be
> testing for the return value from omap_hwmod_register(). This causes
> several IP blocks to not be registered on several O
Commit d6504acd2125984c61dce24727dd3842d0144015 ("OMAP2+: hwmod:
remove OMAP_CHIP*") tests the inverse condition of what it should be
testing for the return value from omap_hwmod_register(). This causes
several IP blocks to not be registered on several OMAP3 family devices.
Fixing that bug also
* Víctor Manuel Jáquez Leal [111006 09:56]:
> Convert a printk(KERN_ERR) message in the driver to pr_err(), and
> use WARN() instead of a custom log message with a stack dump.
>
> Signed-off-by: Víctor Manuel Jáquez Leal
Looks like this won't apply with the changes we have queued up,
care to re
* Benoit Cousson [111004 13:46]:
> Hi Tony,
>
> Here is the series to fix the warning and remove the redundant
> latency structure that be removed since the timer runtime PM
> adaptation was just pulled.
>
> I was just able to test that on OMAP4.
>
> Patches are based on Kevin's for_3.2/omap_de
* Tony Lindgren [111004 08:19]:
> * Igor Grinberg [111004 02:20]:
> > Hi Tony,
> >
> > (git.)kernel.org is back online recently, but there is no tmlind/*
> > project(s) on it?
> > What are your intentions on this?
> > Should we just wait for while, or will it stay on the github?
>
> OK thanks
* Rob Herring [111001 13:21]:
> On 09/30/2011 05:29 PM, Kevin Hilman wrote:
> > Hi Arnd,
> >
> > Kevin Hilman writes:
> >
> >> The upcoming OMAP4 PM series from Santosh[1] that we're planning to
> >> queue for v3.2 has a dependency[2] on a patch currently queued for v3.2
> >> in the irq/core br
* Balaji T K [111003 04:48]:
> MMC1 pbias and speed control fix for SDMMC1 extended I/O cell
> Rebase to git://github.com/tmlind/linux.git fixes
> commit 122a98589349fe3388ffb7b996b54614951c934a
> Author: Tapani Utriainen
> Date: Fri Sep 30 11:05:56 2011 -0700
>
> A
* Afzal Mohammed [110928 23:10]:
> Fix,
>
> arch/arm/mach-omap2/timer.c: In function 'omap_timer_init':
> arch/arm/mach-omap2/timer.c:482: warning: assignment from incompatible
> pointer type
This should already be fixed when I merged together the
dt-base branch.
Regards,
Tony
> Signed-off-
* Thomas Weber [110906 07:38]:
> Remove the init of card detect pin because
> omap_mux_init_gpio() is called during hsmmc initialization
> for the write protect and card detect pin.
Thanks, adding this into fixes-part2 branch.
Tony
--
To unsubscribe from this list: send the line "unsubscribe lin
* S, Venkatraman [110825 07:23]:
> On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit wrote:
> > Hi Venkat,
> >
> > On 8/24/2011 9:46 PM, S, Venkatraman wrote:
> >>
> >> As part of an effort to get single ARM kernel binary [1],
> >> multiple definitions of NR_IRQS under various platforms
> >> have
Hi Kevin,
I'm assuming you'll want to handle merging this one ... when you do, it
would be good to add a cc line to sta...@kernel.org so it can be
integrated into previous kernel releases.
regards
- Paul
-- Forwarded message --
Date: Thu, 6 Oct 2011 13:47:22 -0600 (MDT)
From:
The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chain clock control is broken.
Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
than the AM3505/3517. The TI81xx family of SoCs are at present
considered to be OMAP3 SoCs, but don't support I/O wakeup
On Thu, 6 Oct 2011, Steve Sakoman wrote:
> Perhaps I'm confused but shouldn't it be an || instead of &&?
>
> We're testing for ES3.1 *or* ES3.12?
You're correct - thanks for catching this. v2 on its way.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the bod
Based on the documents that I have here, there doesn't appear to be an
equivalent to erratum i443 for OMAP3630, so restrict this one to OMAP34xx
chips.
Also, explicitly restrict this erratum to EMU and HS devices.
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
---
Unfortunately, I don't have an
On Thu, Oct 6, 2011 at 12:11 PM, Paul Walmsley wrote:
>
> The way that we detect which OMAP3 chips support I/O wakeup and
> software I/O chain clock control is broken.
>
> Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
> than the AM3505/3517. The TI81xx family of SoCs are at
* Abhilash K V [110819 04:19]:
> This patch-set adds support for MMC1 slot on the
> AM3517 EVM's base-board.
> These patches are dependent on the following patch-set
> http://marc.info/?l=linux-omap&m=131247357813228&w=2
> which gets the AM3517 EVM booting.
>
> The patches are tested on master o
* Pedanekar, Hemant [111004 02:07]:
> Igor Grinberg wrote on Tuesday, October 04, 2011 2:31 PM:
>
> > On 10/03/11 18:45, Pedanekar, Hemant wrote:
> >> Hi Igor,
> >>
> >> Igor Grinberg wrote on Sunday, October 02, 2011 5:38 PM:
> >>
> >>> Hi Hemant,
> >>>
> >>> On 09/29/11 04:09, Hemant Pedanek
The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chain clock control is broken.
Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
than the AM3505/3517. The TI81xx family of SoCs are at present
considered to be OMAP3 SoCs, but don't support I/O wakeup
* Shilimkar, Santosh [111003 22:50]:
> On Tue, Oct 4, 2011 at 9:21 AM, Paul Walmsley wrote:
> > + Rajendra, Santosh, Benoît
> >
> > Hi
> >
> > On Mon, 3 Oct 2011, Tony Lindgren wrote:
> >
> >> * Paul Walmsley [110929 17:40]:
> >> > On Thu, 22 Sep 2011, Keerthy wrote:
> >> >
> >> > > From: Vishwa
Convert a printk(KERN_ERR) message in the driver to pr_err(), and
use WARN() instead of a custom log message with a stack dump.
Signed-off-by: Víctor Manuel Jáquez Leal
---
arch/arm/plat-omap/dmtimer.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-om
Hi Keshava,
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
> Following 2 hwmod structures are added
> 1. usb_host_hs
> The hwmod of usbhs with uhh, ehci and ohci base addresses
> functional clock and ehci, ohci irqs
>
> 2. usb_tll_hs
> hwmod of usbhs with the TL
On Thu, Oct 06, 2011 at 08:19:39AM -0700, Joe Perches wrote:
> On Thu, 2011-10-06 at 12:48 +0200, Víctor Manuel Jáquez Leal wrote:
> > Convert all the printk() messages in the driver to pr_().
> []
> > diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> []
> > @@ -397,8 +397,
* Tomi Valkeinen [111006 01:04]:
> On Wed, 2011-10-05 at 15:41 -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen [111004 23:11]:
> > > On Tue, 2011-10-04 at 17:45 -0700, Tony Lindgren wrote:
> > > > This assumes fixed mappings which will not work once we move
> > > > to use ioremap_exec(). It seem
Hi Dave,
On Wed, 5 Oct 2011, Dave Hylands wrote:
> On Wed, Oct 5, 2011 at 11:09 AM, Paul Walmsley wrote:
> > On Wed, 5 Oct 2011, Dave Hylands wrote:
> >
> >> I have an older overo board, which has an OMAP3503
> >>
> >> U-booot reports:
> >> OMAP3503-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 6
On Thu, 2011-10-06 at 12:48 +0200, Víctor Manuel Jáquez Leal wrote:
> Convert all the printk() messages in the driver to pr_().
[]
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
[]
> @@ -397,8 +397,7 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int
> id)
>
On Wed, Oct 5, 2011 at 11:09 AM, Paul Walmsley wrote:
> Looking at the 2.6.39 kernel sources, those messages are coming from
> mach-omap2/pm34xx.c:omap3_enable_io_chain(). That means that something is
> seriously wrong since that code should only be executing on ES3.1 chips
> and higher.
>
> Cou
From: Keshava Munegowda
The usbhs core driver does not enable/disable the interface and
functional clocks directly, These clocks are handled by runtime pm,
hence instead of the clock enable/disable, the runtime pm APIS are
used. however,the optional clocks and port clocks are handled by
the usbhs
From: Keshava Munegowda
The ehci and ohci drivers does not use the APIs of the usbhs
core driver; the runtime pm APIs are used for clock
enable/disable. Since usbhs is parent platform device of the
ehci and ohci devices, the runtime apis indirectly uses the
usb hs core device as input parameter t
From: Keshava Munegowda
device name usbhs clocks are changed from
usbhs-omap.0 to usbhs_omap; this is because
in the hwmod registration the device name is set
as usbhs_omap; The redudant clock nodes are removed.
Signed-off-by: Keshava Munegowda
Reviewed-by: Partha Basak
---
arch/arm/mach-omap
The hwmod structure of usb_host_hs and usb_tll are
retrieved and registered with omap device
Signed-off-by: Keshava Munegowda
Reviewed-by: Partha Basak
---
arch/arm/mach-omap2/usb-host.c | 100 ++--
1 files changed, 34 insertions(+), 66 deletions(-)
diff -
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda
Reviewed-by: P
From: Benoit Cousson
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson
- rebased to
From: Keshava Munegowda
The Hwmod structures for ehci and ohci drivers are implemented for
EHCI and OHCI drivers of OMAP3 and OMAP4.
The ehci and ohci drivers does not use the APIs of the usbhs
core driver; the runtime pm APIs are used for clock
enable/disable.
TODO:
- Adding mux-information
Convert all the printk() messages in the driver to pr_().
Signed-off-by: Víctor Manuel Jáquez Leal
---
arch/arm/plat-omap/dmtimer.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index ee9f6eb..34384b0 1006
On Wed, Sep 14, 2011 at 07:57:13PM +0530, Kishon Vijay Abraham I wrote:
> In one particular place the old form of checking for TLL mode is used.
> This patch fixes the same by using macros to check for TLL mode.
>
> Signed-off-by: Kishon Vijay Abraham I
looks good to me, but this should go via S
On Wed, 2011-10-05 at 15:41 -0700, Tony Lindgren wrote:
> * Tomi Valkeinen [111004 23:11]:
> > On Tue, 2011-10-04 at 17:45 -0700, Tony Lindgren wrote:
> > > This assumes fixed mappings which will not work once we move
> > > to use ioremap_exec(). It seems that these are currently
> > > not in use,
Thanks for the review.
On Thu, Oct 6, 2011 at 12:34 AM, Kevin Hilman wrote:
> "Govindraj.R" writes:
>
>> Prior to this change rx-pad wakeup was done by writing to rx-pad offset value
>> populated in serial.c idle_init. Now with mux framework support we can use
>> mux_utilities along with hmwod f
On Thu, Oct 6, 2011 at 12:12 AM, Kevin Hilman wrote:
> Govindraj writes:
>
>> Hi Kevin,
>>
>> Thanks for the review,
>>
>>
>> On Wed, Oct 5, 2011 at 3:12 AM, Kevin Hilman wrote:
>>> "Govindraj.R" writes:
>>>
We had been using traditional 8250 driver as uart console driver
prior to oma
89 matches
Mail list logo
