From: Abhilash K V abhilash...@ti.com
This patch-set gets the kernel booting up on a AM3517 EVM.
The board is able to boot with ramdisk after this,but the MMC and Ethernet
drivers are not up yet. Lots of warnings remain which will be addressed in
subsequent patches.
The patches are tested on
From: Abhilash K V abhilash...@ti.com
In case of AM3517 AM3505, SmartReflex is not applicable so
we must not enable it. So omap3_twl_init() is now not called
when the processor does not support SR.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
From: Abhilash K V abhilash...@ti.com
If PMIC info is not available in omap_vp_init(), abort.
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/vp.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c
From: Abhilash K V abhilash...@ti.com
Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
the base omap3xxx_hwmods list, so that they can be excluded
for am35x.
Signed-off-by: Abhilash K V abhilash...@ti.com
---
New in v5: reworked to use the new approach to select
device-specific hwmods
Hi
a few comments
On Fri, 30 Sep 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
Hi
On Fri, 30 Sep 2011, Keshava Munegowda wrote:
The hwmod structure of usb_host_hs and usb_tll are
retrieved and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/usb-host.c | 100
Hi,
On Fri, Sep 30, 2011 at 01:15:55AM -0600, Paul Walmsley wrote:
The hwmod structure of usb_host_hs and usb_tll are
retrieved and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
On 9/30/2011 6:27 AM, Nayak, Rajendra wrote:
[...]
They need both. We need to reference the device that provides the
supply and use a name to say which of the potentially multiple supplies
on the consumer device is which.
Mark, I still seem to be a little confused with this one as to why
we
Hi
a few more comments
On Fri, 30 Sep 2011, Paul Walmsley wrote:
On Fri, 30 Sep 2011, Keshava Munegowda wrote:
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk
Hi Abhilash,
On Fri, 30 Sep 2011, Abhilash K V wrote:
From: Abhilash K V abhilash...@ti.com
Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
the base omap3xxx_hwmods list, so that they can be excluded
for am35x.
Signed-off-by: Abhilash K V abhilash...@ti.com
Looks good to me,
On Wed, 28 Sep 2011, Munegowda, Keshava wrote:
Thanks paul,
But In USB Host case, there is a challenge!
I need both usbhost_48m_fck and usbhost_120m_fck to be turned on when
I invoke pm_runtime_get_sync ; so there are couple of options to do this
1. use clk_get with hard coded
On Fri, Sep 30, 2011 at 12:42 AM, Paul Walmsley p...@pwsan.com wrote:
Hi Santosh,
On Thu, 8 Sep 2011, Santosh Shilimkar wrote:
Local timer clock is sourced from the CPU clock and hence changes
along with CPU clock. These per CPU local timers are used as
clock-events, so they need to be
On Fri, Sep 30, 2011 at 1:04 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Sep 30, 2011 at 01:15:55AM -0600, Paul Walmsley wrote:
The hwmod structure of usb_host_hs and usb_tll are
retrieved and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
On Fri, Sep 30, 2011 at 3:00 AM, Linus Walleij linus.wall...@linaro.org wrote:
2011/9/8 Santosh Shilimkar santosh.shilim...@ti.com:
Local timer clock is sourced from the CPU clock and hence changes
along with CPU clock. These per CPU local timers are used as
clock-events, so they need to be
Hi,
On Fri, Sep 30, 2011 at 02:45:32PM +0530, Munegowda, Keshava wrote:
On Fri, Sep 30, 2011 at 1:04 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Sep 30, 2011 at 01:15:55AM -0600, Paul Walmsley wrote:
The hwmod structure of usb_host_hs and usb_tll are
retrieved and registered
On Fri, Sep 30, 2011 at 2:49 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Sep 30, 2011 at 02:45:32PM +0530, Munegowda, Keshava wrote:
On Fri, Sep 30, 2011 at 1:04 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Sep 30, 2011 at 01:15:55AM -0600, Paul Walmsley wrote:
The hwmod
On Friday 30 September 2011 07:08 AM, Grant Likely wrote:
On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
Look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.
Devices can
Hi,
On Fri, Sep 30, 2011 at 02:56:40PM +0530, Munegowda, Keshava wrote:
Usually there's something wrong with omap_devices that contain
multiple hwmods. Is there some reason why there isn't a separate driver
for the TLL? Judging by a brief look at drivers/mfd/omap_usb_host.c,
the
On Wednesday 28 September 2011 05:56 PM, Mark Brown wrote:
On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
On 9/27/2011 8:59 PM, Mark Brown wrote:
I'm not sure how this should work in a device tree world, I'd *hope*
we'd get a device tree node for the CPU and could then just
On Fri, Sep 30, 2011 at 2:02 PM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 28 Sep 2011, Munegowda, Keshava wrote:
Thanks paul,
But In USB Host case, there is a challenge!
I need both usbhost_48m_fck and usbhost_120m_fck to be turned on when
I invoke pm_runtime_get_sync ; so there are
On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
Mark, I still seem to be a little confused with this one as to why
we would need a phandle *and* a supply-name to reference a parent
regulator/supply.
The phandle would point to a regulator dt node and that node internally
would
On Fri, Sep 30, 2011 at 12:42 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
a few comments
On Fri, 30 Sep 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
On Fri, Sep 30, 2011 at 1:32 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
a few more comments
On Fri, 30 Sep 2011, Paul Walmsley wrote:
On Fri, 30 Sep 2011, Keshava Munegowda wrote:
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master =
On Fri, Sep 30, 2011 at 03:04:45PM +0530, Rajendra Nayak wrote:
On Wednesday 28 September 2011 05:56 PM, Mark Brown wrote:
On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
And even before DT migration, we used to build statically some
omap_device to represent the various
On Fri, Sep 30, 2011 at 11:28:49AM +0100, Mark Brown wrote:
On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
+ init_data-supply_regulator = (char *)of_get_property(dev-of_node,
+ regulator-supplies, NULL);
Mark, I still seem to be a
On Fri, Sep 30, 2011 at 09:58:04AM +0200, Cousson, Benoit wrote:
I think as well that we should avoid considering a regulator with
several outputs. I saw the same pattern used for the clock binding
in DT as well.
This binding is for the consumer side, not the producer side. A binding
which
Converting uart driver to adapt to pm runtime API's.
Code re-org + cleanup.
Moving some functionality from serial.c to omap-serial.c
Changes involves:
1.) Cleaning up certain uart calls from sram_idle func.
2.) Removed all types of uart clock handling code from serial.c
3.) Using
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Wake up event set will be cleared on pad mux_read.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c| 30 ++
arch/arm/mach-omap2/mux.h
In preparation to runtime conversion add missing uart regs to
port structure which can be used in context restore.
Also ensuring all uart reg info's are part of port structure.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h |3 ++
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
during hwmod idle transition based on whether
In preparation to UART runtime conversion remove uart specific calls
from pm24xx/34xx files and their definition from serial.c
These func calls will no more be used with upcoming uart runtime design.
1.) omap_uart_prepare_suspend :- can be taken care with driver suspend hooks.
2.)
Removing some of the uart info that is maintained in omap_uart_state struct
used for UART PM in serial.c.
Remove omap_uart_state struct dependency from omap_serial_init,
omap_serial_init_port, omap_serial_early_init and omap_uart_idle_init functions.
And populate the same info in
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 framework to handle io-pad configuration and
enable rx-pad wake-up mechanism.
Add default mux data for all uart's
Adapts omap-serial driver to use pm_runtime API's.
Use runtime runtime API's to handle uart clocks and obtain
device_usage statics. Set runtime API's usage to irq_safe so that
we can use get_sync from irq context. Auto-suspend for port specific
activities and put for reg access. Use
We had been using traditional 8250 driver as uart console driver
prior to omap-serial driver. Since we have omap-serial driver
in mainline kernel for some time now it has been used as default
uart console driver on omap2+ platforms. Remove 8250 support for
omap-uarts.
Serial_in and serial_out
Currently we use a shared irq handler to identify uart activity and then
trigger a timer. Based the timeout value set from sysfs the timer used to
expire. If no uart-activity was detected timer-expiry func sets can_sleep
flag. Based on this we will disable the uart clocks in idle path.
Since the
Modify the omap_uart_can_sleep function to check uart is active
or not to be used by pm code to enter low power states.
Removing this check can cause console response little sluggish.
However no characters will be lost until uart clocks are gated
and woken up using rx-pad. UART interface clocks
For the early console probing we had avoided hwmod reset and idling
and uart was idled using hwmod API and enabled back using omap_device API
after omap_device registration.
Now since we are using runtime API's to enable back uart, move hwmod idling and
use runtime API to enable back UART.
If OMAP UART is used as console uart and debug is enabled,
avoid gating of uart clocks to print all debug prints.
If uart clocks are gated then the debug prints from omap_device
framework or hwmod framework can cause uart to enter recursive pm_runtime calls,
which can cause a deadlock over power
In suspend path the console_lock is taken by uart_port_suspend
however when no_console_suspend is used console_lock is not taken.
During system wide suspend omap_pwr_domain hooks cut all
clocks that are left enabled. So its unsafe to proceed printing after
clocks are cut by pwr_domain hooks. Also
From: Jon Hunter jon-hun...@ti.com
When using DMA there are two timeouts defined. The first timeout,
rx_timeout, is really a polling rate in which software polls the
DMA status to see if the DMA has finished. This is necessary for
the RX side because we do not know how much data we will receive.
Move the errata handling mechanism from serial.c to omap-serial file
and utilise the same func in driver file.
Errata i202, i291 are moved to be handled with omap-serial
Moving the errata macro from serial.c file to driver header file
as from on errata will be handled in driver file itself.
From: Deepak K deepa...@ti.com
The following UART parameters are defined within the UART driver:
1). Whether the UART uses DMA (dma_enabled), by default set to 0
2). The size of dma buffer (set to 4096 bytes)
3). The time after which the dma should stop if no more data is received.
4). The auto
On Friday 30 September 2011 04:18 PM, Mark Brown wrote:
On Fri, Sep 30, 2011 at 11:28:49AM +0100, Mark Brown wrote:
On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
+ init_data-supply_regulator = (char *)of_get_property(dev-of_node,
+
On 9/30/2011 1:09 PM, Nayak, Rajendra wrote:
On Friday 30 September 2011 04:18 PM, Mark Brown wrote:
On Fri, Sep 30, 2011 at 11:28:49AM +0100, Mark Brown wrote:
On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
+ init_data-supply_regulator = (char
Second thought... I was too fast to say OK :-)
On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
[...]
+ if (match) {
+ of_property_read_u32(node, bank-width,bank-width);
Bank width should be u32.
I guess you
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin
Sent: Tuesday, September 27, 2011 12:16 AM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; p...@pwsan.com;
t...@atomide.com;
On Fri, Sep 30, 2011 at 04:39:02PM +0530, Rajendra Nayak wrote:
The regulator-supplies is used to specific the regulator *parent*.
Same as what was earlier passed by using the
supply_regulator field of regulator_init_data structure.
Grant wanted the bindings to support specifying multiple
Arnd,
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 branch of Thomas' tip tree[3].
In the past, I noticed you merged external trees like this to solve
dependencies.
Could you pull the
Hi,
Here is a patch which adds a PM_QOS_MEMORY_THROUGHPUT class to the PM
QoS framework. The idea is to provide a memory or SDMA throughput
constraints class, which can be applied to the low level platform code
using the callback notification mechanism and also a MISC /dev entry
for the
From: Jean Pihet j-pi...@ti.com
Provide a memory or SDMA throughput constraints class,
which can be applied to the low level platform code using the
callback notification mechanism and
also a MISC /dev entry for the constraints from user space.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
On Thu, Sep 29, 2011 at 9:50 PM, Tony Lindgren t...@atomide.com wrote:
* Balaji T K balaj...@ti.com [110929 07:11]:
MMC1 data line IO's are powered down in before set regulator function.
IO's should not be powered ON when regulator is OFF.
Keep the IO's in power pown mode after regulator OFF.
Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin
Sent: Tuesday, September 27, 2011 12:16 AM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; p...@pwsan.com;
Munegowda, Keshava keshava_mgo...@ti.com writes:
[...]
+
+static struct omap_hwmod_ocp_if omap34xx_f_cfg__usb_tll_hs = {
+ .clk = usbtll_ick,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
Does this really need OCPIF_SWSUP_IDLE? If so,
* T Krishnamoorthy, Balaji balaj...@ti.com [110930 07:43]:
On Thu, Sep 29, 2011 at 9:50 PM, Tony Lindgren t...@atomide.com wrote:
* Balaji T K balaj...@ti.com [110929 07:11]:
MMC1 data line IO's are powered down in before set regulator function.
IO's should not be powered ON when regulator
* Felipe Balbi ba...@ti.com [110928 23:35]:
On Tue, Sep 20, 2011 at 04:50:29PM +0800, Axel Lin wrote:
Current code calls omap4430_phy_init() twice in usb_musb_init().
Calling omap4430_phy_init() once is enough.
This patch removes the first omap4430_phy_init() call, which using an
On Fri, 30 Sep 2011, Munegowda, Keshava wrote:
On Fri, Sep 30, 2011 at 2:02 PM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 28 Sep 2011, Munegowda, Keshava wrote:
Thanks paul,
But In USB Host case, there is a challenge!
I need both usbhost_48m_fck and usbhost_120m_fck to be turned
Hi
On Fri, 30 Sep 2011, Abhilash K V wrote:
From: Abhilash K V abhilash...@ti.com
If PMIC info is not available in omap_vp_init(), abort.
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/vp.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
On Fri, 23 Sep 2011, Kevin Hilman wrote:
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Signed-off-by: Kevin Hilman khil...@ti.com
Queued for 3.3 cleanups (to avoid potential
Hi Keshava,
by the way, when you repost these, can you split this into two series --
one for the arch/arm/*omap* changes, and the other for changes that should
go in through the MFD tree? Then just note in the second series that it
has a dependency on the first. That will make it easier to
Hi Arnd,
Please pull omap cleanup part3 into cleanup from:
git://github.com/tmlind/linux.git cleanup-part3
If you did not already pull the earlier updated
cleanup, pulling this is enough and will bring that
in too.
Regards,
Tony
The following changes since commit
On Friday 23 September 2011, Tony Lindgren wrote:
Please pull omap cleanup branch again from:
git://github.com/tmlind/linux.git cleanup
This contains a fix for earlier cleanup patches and has omap_device
cleanup and PM cleanup merged in.
As some of the later cleanup was based on a -rc6
On Saturday 24 September 2011, Tony Lindgren wrote:
If this one is OK, I'll push to my for_3.2/voltage-cleanup branch (which
is already pulled into arm-soc/next/voltage) so just re-pulling will
pick up the fix.
Arnd, care to pull this in directly from Kevin into voltage branch?
It's
On Thursday 29 September 2011, Tony Lindgren wrote:
Please pull omap dmtimer changes from:
git://github.com/tmlind/linux.git dmtimer
This series completes the system timer separation from the
driver like features. It also adds support for v2 ip that is
available for some timers starting
Hi,
On Friday, September 30, 2011, Jean Pihet wrote:
Hi,
Here is a patch which adds a PM_QOS_MEMORY_THROUGHPUT class to the PM
QoS framework. The idea is to provide a memory or SDMA throughput
constraints class, which can be applied to the low level platform code
using the callback
Hi Tony,
Please pull the initial OMAP device tree support for v3.2.
Thanks,
Benoit
The following changes since commit 1c3543a34a8ce3e050d7706135bdffd5921c42f5:
Tony Lindgren (1):
Merge branch 'for_3.2/omap_device-2' of
git://github.com/khilman/linux-omap-pm into dt
are available
* Arnd Bergmann a...@arndb.de [110930 12:40]:
On Thursday 29 September 2011, Tony Lindgren wrote:
Please pull omap dmtimer changes from:
git://github.com/tmlind/linux.git dmtimer
This series completes the system timer separation from the
driver like features. It also adds support
On Friday 30 September 2011, Tony Lindgren wrote:
How about a branch called driver?
There are still lots of pieces of code under arch/arm that should
be eventually moved to live under drivers. For example the mux
code and most of PM code can eventually be under drivers.
Yes, good idea! For
Tony,
Please pull the following omap_device series that finishes up the
preparation the rest of the device tree work from Benoit.
Kevin
The following changes since commit 0f9b8dd0120cca55b73620c2a6e0dd8c1575f677:
Merge branches 'cleanup', 'voltage' and 'dmtimer' into dt-base (2011-09-30
On Friday 30 September 2011, Tony Lindgren wrote:
Please pull omap cleanup part3 into cleanup from:
git://github.com/tmlind/linux.git cleanup-part3
If you did not already pull the earlier updated
cleanup, pulling this is enough and will bring that
in too.
Ok, I've ended up replacing the
Abhilash K V abhilash...@ti.com writes:
From: Abhilash K V abhilash...@ti.com
In case of AM3517 AM3505, SmartReflex is not applicable so
we must not enable it. So omap3_twl_init() is now not called
when the processor does not support SR.
This still isn't right.
The reason to skip the TWL
* Kevin Hilman khil...@ti.com [110930 13:21]:
Tony,
Please pull the following omap_device series that finishes up the
preparation the rest of the device tree work from Benoit.
Thanks, this is now in dt branch.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
Abhilash K V abhilash...@ti.com writes:
From: Abhilash K V abhilash...@ti.com
If PMIC info is not available in omap_vp_init(), abort.
Signed-off-by: Abhilash K V abhilash...@ti.com
Looks good.
After minor fixup below, adding to the next round of voltage cleanups
(branch:
* Cousson, Benoit b-cous...@ti.com [110930 13:08]:
Hi Tony,
Please pull the initial OMAP device tree support for v3.2.
Great, thanks. And thanks for updating the two patches below
to say ARM: OMAP2+: in the subject :)
This is now in dt branch. Will merge into linux-omap master
branch and
* Arnd Bergmann a...@arndb.de [110930 13:22]:
On Friday 30 September 2011, Tony Lindgren wrote:
Please pull omap cleanup part3 into cleanup from:
git://github.com/tmlind/linux.git cleanup-part3
If you did not already pull the earlier updated
cleanup, pulling this is enough and will
Hi Paul,
Paul Walmsley p...@pwsan.com writes:
On Fri, 30 Sep 2011, Abhilash K V wrote:
From: Abhilash K V abhilash...@ti.com
If PMIC info is not available in omap_vp_init(), abort.
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/vp.c |7 +++
1 files
Hi Arnd,
Kevin Hilman khil...@ti.com 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 branch of Thomas' tip tree[3].
In the past, I noticed you merged external trees like this
Abhilash,
Kevin Hilman khil...@ti.com writes:
Abhilash K V abhilash...@ti.com writes:
From: Abhilash K V abhilash...@ti.com
In case of AM3517 AM3505, SmartReflex is not applicable so
we must not enable it. So omap3_twl_init() is now not called
when the processor does not support SR.
Hi Paul,
Paul Walmsley wrote on Friday, September 30, 2011 2:17 AM:
Hello Hemant,
a few comments:
On Thu, 29 Sep 2011, Hemant Pedanekar wrote:
This patch adds cpu type, macros for identification of TI814X device.
Note that following update to common OMAP data structures is made:
79 matches
Mail list logo
