The 4460 platform has no difference in the clockdomains as compared
to the 4430 platform. Hence just update the .omap_chip field to make
sure the same clockdomain data can be reused on the 4460 platform.
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
R
The 4460 platform has no difference in the powerdomains as compared
to the 4430 platform. Hence just update the .omap_chip field to make
sure the same powerdomain data can be reused on the 4460 platform.
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
R
Add the new clock nodes (bandgap_ts_fclk, div_ts_ck) for omap4460.
Handle these nodes using the clock flags (CK_*).
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
Reviewed-by: Kevin Hilman
---
arch/arm/mach-omap2/clock44xx_data.c | 39
This patch adds additional register bitshifts for
registers added in OMAP4460 platform.
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
Reviewed-by: Kevin Hilman
---
arch/arm/mach-omap2/cm-regbits-44xx.h | 36
arch/
From: Aneesh V
Macros for identifying the max frequency supported by various
OMAP4 variants - Expanding along the lines of OMAP3's feature
handling.
[n...@ti.com: minor fixes for checks that should only for 443x|446x]
Signed-off-by: Nishanth Menon
Signed-off-by: Aneesh V
Signed-off-by: Rajendr
From: Aneesh V
Add support for detecting the latest in the OMAP4 family: OMAP4460
Among other changes, the new chip also can support 1.5GHz A9s,
1080p stereoscopic 3D and 12 MP stereo (dual camera). In addition,
we have changes to OPPs supported, clock tree etc, hence having a
chip detection is r
This series adds base support needed to be able
to boot on a OMAP4460 device.
Patches are based on
git://gitorious.org/omap-pm/linux.git for_3.1/7_hwmod_modulemode
and boot tested on 4430sdp and 4460sdp boards.
The series updates the prcm/clock and clockdomain/powerdomain
data files which are also
--- On Fri, 7/1/11, Jon Hunter wrote:
> From: Jon Hunter
> Subject: Re: gpio interrupt is not invoked on Panda board
> To: "hong zhang"
> Cc: linux-omap@vger.kernel.org
> Date: Friday, July 1, 2011, 4:17 PM
> Hi Henry
>
> On 7/1/2011 1:10 PM, hong zhang wrote:
> > List,
> >
> > I try to get gp
On Sun, Jun 26, 2011 at 11:52 PM, Daniel Seifert wrote:
> Yes, I experience the same problem. On a 35xx board the watchdog
> worked fine, but on a DM3730 one it just freezes up. Tried with 2.6.35
> and 3.0.0-rc3-g19a1166 (omap2plus defconfig). Has anybody seen a patch
> for this yet?
did you try
"Rafael J. Wysocki" writes:
> From: Rafael J. Wysocki
>
> Commit e1866b33b1e89f077b7132daae3dfd9a594e9a1a (PM / Runtime: Rework
> runtime PM handling during driver removal) forgot to update the
> documentation in Documentation/power/runtime_pm.txt to match the new
> code in drivers/base/dd.c. U
Tero Kristo writes:
> PRCM chain interrupt registration is done now as part of
> omap_hwmod_enable_wakeup() and omap_hwmod_disable_wakeup() calls. This
> allows module ISR:s to be called when the module is idle but an IO_PAD
> event is detected on the module input pads.
These functions are the e
From: Rafael J. Wysocki
Commit e1866b33b1e89f077b7132daae3dfd9a594e9a1a (PM / Runtime: Rework
runtime PM handling during driver removal) forgot to update the
documentation in Documentation/power/runtime_pm.txt to match the new
code in drivers/base/dd.c. Update that documentation to match the
cod
Tero Kristo writes:
> Prevents a hang when omap_device would want to print something for
> serial console device while enabling / disabling its clocks.
hang is still there if you boot with 'debug' on the cmdline.
This needs a fix in the UART driver using console locking.
This should be marked
Tero Kristo writes:
> PRCM interrupt handler will now parse registered pads to see whether there
> is an active wakeup event. If there is a pending wakeup event, the registered
> ISR will be called.
>
> Signed-off-by: Tero Kristo
This patch adds a new, duplicate mapping of pad-to-IRQ which is a
Tero Kristo writes:
> Introduce a chained interrupt handler mechanism for the PRCM
> interrupt, so that individual PRCM event can cleanly be handled by
> handlers in separate drivers. We do this by introducing PRCM event
> names, which are then matched to the particular PRCM interrupt bit
> depen
Previously, main_clk was a fake clock node that was accessing the
PRCM modulemode register. Since the module mode is directly
controlled by the hwmod fmwk, these fake clock node are not
needed anymore. The hwmod main_clk will point directly to the
input clock node if applicable.
For example, some I
Add the GPMC hwmod data.
The GPMC hwmod does need the flags HWMOD_INIT_NO_IDLE and
HWMOD_INIT_NO_RESET due to a bug described in the previous commit:
OMAP4: clock: Keep GPMC clocks always enabled and hardware managed
On OMAP4, CPU accesses on unmapped addresses are redirected to GPMC by
L3 in
Hi Paul,
Here is the second part of the modulemode series.
The goal here is to do the cleanup on the clock nodes and PRCM macros
that are not needed anymore by the hwmod data.
Some macros are still needed because of clock data. It should be removed
once the clock data will be cleaned.
Since the
On Friday, July 01, 2011, Alan Stern wrote:
> On Fri, 1 Jul 2011, Rafael J. Wysocki wrote:
>
> > Hi,
> >
> > On Friday, July 01, 2011, Kevin Hilman wrote:
> > > Alan Stern writes:
> > >
> > > > On Fri, 1 Jul 2011, Kevin Hilman wrote:
> > > >
> > > >> OK, so the ->probe() part has been explained
On Friday, July 01, 2011, Kevin Hilman wrote:
> Continuing on the theme of runtime PM interactions with other parts of
> the driver core...
>
> In drivers/base/dd.c:driver_probe_device(), the driver core increments
> the usage count around ->probe():
>
> [...]
> pm_runtime_get_nores
From: Rajendra Nayak
On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is:
-1- Force clkdm to SW_WKUP
-2- Enabling the clocks
-3- Configure desired module mode to "enable" or "auto"
-4- Wait for the desired module idle status to be FUNC
-5- Program clkdm in HW_AUT
From: Rajendra Nayak
Since the clkdm state programming is now done from within the hwmod
framework (which uses a per-hwmod lock) instead of the being done
from the clock framework (which used a global lock), there is now a
need to have per-clkdm locking to prevent races between different
hwmods/m
Duplicate the existing API for clockdomain enable from clock to enable
a clock domain from hwmod framework.
This will be needed when the hwmod framework will move from the current
clock centric approach to the module based approach.
These APIs are returning 0 for the moment for OMAP2 and OMAP3 unt
From: Rajendra Nayak
The omap_set_pwrdm_state function forces clockdomains
to idle, without checking the existing idle state
programmed, instead based solely on the HW capability
of the clockdomain to support idle.
This is wrong and the clockdomains should be idled
post a state_switch *only* if i
From: Rajendra Nayak
Add the SoC specific implementation for clkdm_allows_idle
for OMAP2/3 and OMAP4.
Signed-off-by: Rajendra Nayak
[b-cous...@ti.com: Update the changelog and subject]
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
---
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 12 +
From: Rajendra Nayak
sleep_switch which is initialised to 0 in omap_set_pwrdm_state
happens to be a valid sleep_switch type (FORCEWAKEUP_SWITCH)
which are defined as:
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH1
This causes the function to wrongly program some clock dom
From: Rajendra Nayak
Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.
Thanks to Todd Poynor for a
better function name suggestion.
Signed-off-by: Rajendra Nayak
Cc: Paul Walmsley
Cc: Todd Poynor
---
arch/arm/mach-omap2/clockdomain.c | 2
Hi Paul,
Here is an updated version of the series started by Rajendra.
It takes into account comments from Todd.
I had to update it because this series is mandatory for the hwmod
modulemodule control series.
I rebased it on top of the various fixes done on hwmod framework
to take advantage of the
Extend the existing function to create clkdev for every optional
clocks to add a well one "fck" alias for the main_clk of the
omap_hwmod.
It will allow to remove these static clkdev entries from the
clockXXX_data.c file.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Todd
Hi Henry
On 7/1/2011 1:10 PM, hong zhang wrote:
List,
I try to get gpio_191 ping interrupted on panda but never succeeded. What I do
is
1. set 0x410b on dpm_emu19 register to enable interrupt and wakeup
on gpio_191
2. set bit 31 to 1 on GPIO_IRQSTATUS_SET_0 register at 0x4805d034
3. set b
On Fri, 1 Jul 2011, Rafael J. Wysocki wrote:
> Hi,
>
> On Friday, July 01, 2011, Kevin Hilman wrote:
> > Alan Stern writes:
> >
> > > On Fri, 1 Jul 2011, Kevin Hilman wrote:
> > >
> > >> OK, so the ->probe() part has been explained and makes sense, but I
> > >> would expect ->remove() to be sim
Take advantage of the explicit modulemode control to fix
the way parents clocks are managed.
A module must be disabled before any parents are disabled.
That programming model was not possible with the previous
implementation that was considering a modulemode as a leaf
clock node managed by the cloc
Add a 'context_offs' entry in the prcm.omap4 structure to all
IPs when applicable.
The offset will be used to retrieve the per module context lost
information now available on OMAP4.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod_44xx_data
Add a new field to provide the mode supported by the module.
The mode will control the way mandatory clocks are managed by the PRCM.
0 : Module is temporarily disabled by SW. OCP access to module are stalled.
Can be used to change timing parameter of GPMC module.
1 : Module is managed au
The CLKCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of a offset will allow future improvement like migration from
the current architecture code toward a module driv
In OMAP4, a new programming model based on module control instead
of clock control was introduced.
Expose two APIs to allow the upper layer (omap_hwmod) to control
the module mode independently of the parent clocks management.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Nayak
-
The interconnect modules were using a slightly different layout than
the regular modules.
Align the layout for better consitency.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 48 ++--
1 files chang
The RSTCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of an offset will allow future improvement like migration from
the current architecture code toward a module dri
The warm reset function was still using the obsolete API.
Replace it by the new one and move the file to the proper c file.
Change the function names to stick to the file convention as
suggested by Paul Walmsley :
prm_xxx -> prminst_xxx
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajend
The new prminst_xxx accessors based on partition and offset
is now used, so removed all the previous prcm_xxx accessors.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/prm44xx.c | 37 -
1 files changed, 0 inserti
In OMAP PRCM terminology, the clock domain is defined as a group of IPs
that share some clocks and most of the time an interface clock.
Every IP does belong to a clockdomain.
For the moment the clock domain attribute is affected to a clock node.
The issue with that approach, is that a clock might o
Since the clkdm is now part of the omap_hwmod structure, there is no need
to retrieve it from the main_clock or interface clock.
The code can be simplified a little bit with a direct access.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod.c
It is mandatory to wait for a module to be in disabled state before
potentially disabling source clock or re-asserting a reset.
omap_hwmod_idle and omap_hwmod_shutdown does not wait for
the module to be fully idle.
Add a cm_xxx accessor to wait the clkctrl idle status to be disabled.
Fix hwmod_[i
Hi Paul,
Here is the series that finally add the management of the modulemode
directly from hwmod fmwk instead of using a fake clock node to represent
the IP.
This v2 update is fixing a couple of regressions I introduced in the first
release.
A second series will clean most of the remaining data
At boot time, lookup the clkdm_name to get the clkdm
structure pointer for further usage.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod.c | 34 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
Move the pr_debug at the top of the function
to trace the entry even if the first test is failing.
That help understanding that we entered the function
but failed in it.
Move the _enable last part out of the test to reduce
indentation and improve readability.
Signed-off-by: Benoit Cousson
Cc: Pa
Change the debug into warning to check what IPs are failing.
Signed-off-by: Benoit Cousson
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index
The HW reset must be de-assert after the clocks are enabled
but before waiting for the target to be ready. Otherwise the
reset might not work properly since the clock is not running
to proceed the reset.
De-assert the reset after _enable_clocks and before
_wait_target_ready.
Re-assert it only when
It is perfectly valid for some hwmod to not have any
register target address for sysconfig. This is especially
true for interconnect hwmods.
Remove the warning.
Signed-off-by: Benoit Cousson
Acked-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c |3 ---
1 files changed, 0 insertions(+
The Type 2 type of IPs will not have any enawakeup bit in their sysconfig.
Writing to that bit will instead trigger a softreset.
Check the flag to write this bit only if the module supports it.
Reported-by: Miguel Vadillo
Signed-off-by: Benoit Cousson
Acked-by: Paul Walmsley
---
arch/arm/mach-
From: Miguel Vadillo
When calling the shutdown, the module may be already in idle.
Accessing the sysconfig register will then lead to a crash.
In that case, re-enable the module in order to allow the access
to the sysconfig register.
Signed-off-by: Miguel Vadillo
Signed-off-by: Benoit Cousson
Add the flag to every IPs that support it to allow the
framework to enable it instead of the SMART_STANDBY default
mode.
Without that, an IP with busmaster capability will not
be able to wakeup the interconnect at all.
Signed-off-by: Benoit Cousson
Acked-by: Paul Walmsley
---
arch/arm/mach-omap
The commit 86009eb326afde34ffdc5648cd344aa86b8d58d4 was adding
the wakeup support for new OMAP4 IPs. This support is incomplete for
busmaster IPs that need as well to use smart-standby with wakeup.
This new standbymode is suported on HSI and USB_HOST_FS for the moment.
Add the new MSTANDBY_SMART_
Hi Paul,
Here are the latest bug fixes done on the hwmod framework.
There are mainly around wakeup capability added in OMAP4.
The series is based on for_3.1/2_prcm_files_cleanup and tested
on OMAP4430 ES2.1 + SDP.
The patches are available here:
git://gitorious.org/omap-pm/linux.git for_3.1/3_hw
Hi,
On Friday, July 01, 2011, Kevin Hilman wrote:
> Alan Stern writes:
>
> > On Fri, 1 Jul 2011, Kevin Hilman wrote:
> >
> >> OK, so the ->probe() part has been explained and makes sense, but I
> >> would expect ->remove() to be similarily protected (as the documentation
> >> states.) But that
In order to make hwmod data usable for all OMAP4430 variants,
rename chip macro CHIP_IS_OMAP44XX.
Create the macro as well in cpu.h
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 164 ++--
arch/arm/plat-omap/include/pla
Based on a patch from Jon Hunter , but extented
to remove remaining references.
The peripherals CCPTX, EMAC, MMC6, P1500, PCIESS, SATA, TPPSS, XHPI,
MGATE, MSPROHG, EMIF_H1, EMIF_H2, HECC1, HECC2, ADC, MDMINTC, DEISS
and RTC do not exist for the OMAP4 devices.
Remove all references to these modul
From: Tomi Valkeinen
Currently using pm_runtime with DSS requires the DSS driver to enable
the DSS functional clock before calling pm_runtime_get(). That makes it
impossible to use pm_runtime in DSS as it is meant to be used, with
pm_runtime callbacks.
This patch changes the hwmod database for O
From: Rajendra Nayak
Rename current 4430 definitions to 44XX in oder to make this file
applicable for the next revision (OMAP4460).
Create new flags for 44XX. They will be extented when OMAP4460
will be introduced.
Fix as well the clkdev indentation that were previously broken.
Replace a coupl
From: Tomi Valkeinen
Add missing DSS optional clocks to HWMOD data for OMAP4xxx.
Add HWMOD_CONTROL_OPT_CLKS_IN_RESET flag for dispc to fix dispc reset.
Signed-off-by: Tomi Valkeinen
[b-cous...@ti.com: Remove a comment and update the subject]
Signed-off-by: Benoit Cousson
---
arch/arm/mach-om
Fix .prcm alignement and usb_otg_hs class and hwmod structures.
Add a couple of more potential hwmods in the comment.
Remove hsi, since it is already included in the data.
Remove one blank line.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |
A couple of parens were added around some flags.
Remove them, since they are not needed and not used
for any other hwmods.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/
Change the position of the ocp_if structure to match the template.
Remove unneeded comma at the end of address space flag field.
Remove USER_SDMA since this ocp link is only from the l3_main_1
path that is accessible only from the MPU in that case and not
the SDMA.
Signed-off-by: Benoit Cousson
From: Jon Hunter
McASP2, 3 and MMC6 modules are not present in the OMAP4 family.
Remove the fclk and the clksel related to these nodes.
Rename the references that were potentially re-used in order nodes.
Remove related macros in prcm header files.
Update TI copyright date.
Signed-off-by: Jon H
From: Jon Hunter
UNIPRO was removed from OMAP4 devices from ES2.0 onwards.
Since this IP was anyway non-functional and not supported,
it is best to remove it completely.
Signed-off-by: Jon Hunter
[b-cous...@ti.com: Update the changelog]
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
---
arc
From: Rajendra Nayak
On OMAP4 the auxclk nodes (part of SCRM) support both
divider as well as parent selection.
Supporting this requires splitting the existing nodes
(which support only parent selection) into two nodes,
one for parent and another for divider selection.
The nodes for parent select
The DPLL USB can generate higher speed (x2) than the regular ones.
The max multiplication value is then twice the previous value.
Fix both max_mult and max_div with that correct values.
Change the max_div variable type to u16 to allow storing up to 256.
Replace as well the define with the value
A couple of fieds were edited manually and thus do not stick
to the template used by the generator and by other structures.
Move them to the correct location.
Fix the wrong .ops for the dpll_unipro_x2_ck node.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
---
arch/arm/mach-omap2/clock44xx_d
usb_host_fs_fck does have a clkdev mapping with "usbhs-omap.0"
and "fs_fck" alias used by the driver.
The entry with NULL dev is thus not needed anymore.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Felipe Balbi
---
arch/arm/mach-omap2/clock44xx_data.c |3 ---
1 files changed, 0 ins
MPUSS was renamed MPU and L3_D2D D2D.
The rename will slightly change the order of the structure
and thus generate some structures moves.
Add a comment and remove a comma.
Update Copyright for TI and Nokia and add back Paul
in the author list.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc
The USB DPLL is a J-Type DPLL with the sddiv extra parameter.
On the other hand, the UNIPRO is not a J-Type and thus does
not require this flag.
Add it in USB DPLL and remove it in UNIPRO DPLL.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
---
arch/arm/mach-omap2/clock44xx_data.c |2 +-
Some maros were not well aligned. Re-align them.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/prcm_mpu44xx.h | 69 +--
1 files changed, 34 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm_mpu44
Hi Paul,
Here are a bunch of cleanups on almost every PRCM related data files.
Some of them are purely code moves, and will look like a lot of
noise for nothing, but this is needed if we want to keep the files
aligned with generator tool and thus ease the future migration to
whatever format (commo
The following commit introduced new macros to define an offset
per clock domain in an instance.
commit e4156ee52fe617c2c2d80b5db993ff4bf07d7c3c
OMAP4: CM instances: add clockdomain register offsets
The PRM contains only two clock controls management entities:
EMU and WKUP.
Remove the other o
From: Santosh Shilimkar
On OMAP4430 devices, because of boot ROM code bug, MPU OFF state can't
be attempted independently. When coming out of MPU OFF state, ROM code
disables the clocks of IVAHD, TESLA which is not desirable. Hence the
MPU OFF state is not usable on OMAP4430 devices.
OMAP4460 on
Since ES2.0, the core ocmram does not support a different state
than the main power domain anymore during both ON and RET power
domain state.
Since PM is not supported at all in ES1.0, update the common
structure.
LOWPOWERSTATECHANGE is supported by the cefuse power domain but
the flag was missing
From: Santosh Shilimkar
On OMAP4, CPU accesses on unmapped addresses are redirected to GPMC by
L3 interconnect. Because of CPU speculative nature, such accesses are
possible which can lead to indirect access to GPMC and if it's clock is
not running, it can result in hang/abort on the platform.
A
A couple of macros were wrongly changed during the _MOD to _INST
rename done in the following commit:
OMAP4: PRCM: rename _MOD macros to _INST
cdb54c4457d68994da7c2e16907adfbfc130060d
Fix them to their original name.
Some CM and PRM instances were not well aligned. Align them.
Remove one bl
Hi Paul & Rajendra,
Here are a couple of fixes on PRCM header files and powerdomain data.
There are as well 2 HW bugs fixes from Santosh.
The series is based on v3.0-rc5 and tested on OMAP4430 ES2.1 + SDP.
The patches are available here:
git://gitorious.org/omap-pm/linux.git for_3.1/1_prcm_files
Tero Kristo writes:
> This prevents system hang while attempting to access suspended console.
Please add more detail. Who is accessing console? This sounds more
like it's masking a UART/console bug.
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/pm34xx.c |6 ++
> 1 files
On Sat, 2 Jul 2011, Keshava Munegowda wrote:
> From: Keshava Munegowda
>
> The global suspend and resume functions for ehci and ohci
> drivers are implemented; these functions does the
> pm_runtime_get_sync and pm_runtime_put_sync of the
> parent device usbhs core driver respectively.
>
> Signe
From: Benoit Cousson
Following 4 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson
Signed-off-b
From: Keshava Munegowda
The usbhs core driver does not enable/disable the intefrace and
fucntional clocks; These clocks are handled by hwmod and runtime pm,
hence insted of the clock enable/disable, the runtime pm APIS are
used. however,the port clocks and tll clocks are handled
by the usbhs core
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
Signed-off-by: Keshava Munegowda
---
arch/arm/mach-omap2/clock3xxx_data.c | 28 ++--
arch/arm/m
From: Keshava Munegowda
The global suspend and resume functions for ehci and ohci
drivers are implemented; these functions does the
pm_runtime_get_sync and pm_runtime_put_sync of the
parent device usbhs core driver respectively.
Signed-off-by: Keshava Munegowda
---
drivers/usb/host/ehci-omap.c
The hwmod structure of uhh, ohci, ehci and tll are
retrived and registered with omap device
Signed-off-by: Keshava Munegowda
---
arch/arm/mach-omap2/usb-host.c | 113 +--
1 files changed, 49 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-omap2/usb
From: Keshava Munegowda
Following 4 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda L4_COR
From: Keshava Munegowda
The Hwmod structures and Runtime PM features are implemented
For EHCI and OHCI drivers of OMAP3 and OMAP4.
The global suspend/resume of EHCI and OHCI
is validated on OMAP3430 sdp board with these patches.
Benoit Cousson (1):
arm: omap: usb: ehci and ohci hwmod structure
List,
I try to get gpio_191 ping interrupted on panda but never succeeded. What I do
is
1. set 0x410b on dpm_emu19 register to enable interrupt and wakeup
on gpio_191
2. set bit 31 to 1 on GPIO_IRQSTATUS_SET_0 register at 0x4805d034
3. set bit 31 to 1 on GPIO_IRQWAKEN_0 register at 0x4805d04
"S, Venkatraman" writes:
> On Fri, Jul 1, 2011 at 2:37 AM, wrote:
>> From: Madhusudhan Chikkature
>>
>> Removing the OMAP HS MMC entry from the MAINTAINERS file as I will
>> no longer be able to maintain this driver.
>>
>> Signed-off-by: Madhusudhan Chikkature
[...]
> It would be better to
From: Madhusudhan Chikkature
Update the OMAP HS MMC entry from the MAINTAINERS file as I will
no longer be able to maintain this driver.
Signed-off-by: Madhusudhan Chikkature
[khil...@ti.com: change to Orphan rather than complete removal]
Signed-off-by: Kevin Hilman
---
Applies to v3.0-rc5
M
On 7/1/2011 9:40 AM, Kevin Hilman wrote:
On Fri, 2011-07-01 at 09:36 -0700, Kevin Hilman wrote:
Rajendra Nayak writes:
This series adds base support needed to be able
to boot on a OMAP4460 device.
Patches are based on Benoit's for_3.0.1/7_hwmod_modulemode
branch and boot tested on both 4460sd
Alan Stern writes:
> On Fri, 1 Jul 2011, Kevin Hilman wrote:
>
>> >> --- a/drivers/base/dd.c
>> >> +++ b/drivers/base/dd.c
>> >> @@ -329,13 +329,13 @@ static void __device_release_driver(struct device
>> >> *dev)
>> >> blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
>>
add runtime pm support to HSMMC host controller
Use runtime pm API to enable/disable HSMMC clock
Use runtime autosuspend APIs to enable auto suspend delay
Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala
Signed-off-by: Balaji T K
---
changes since v3
remove "host:" pr
After runtime conversion to handle clk,
iclk node is not used
However fclk node is still used to get clock rate.
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/
lazy_disable framework in OMAP HSMMC manages multiple low power states
and Card is powered off after inactivity time of 8 seconds.
Based on previous discussion on the list, card power (regulator)
handling (when to power OFF/ON) should ideally be handled by core layer.
Remove usage of lazy disable t
Removing the custom state machine - lazy disable framework in omap_hsmmc
to make way for runtime pm to handle host controller
power states.
This allows mmc_host_enable/mmc_host_disable to be replaced by
runtime get_sync and put_sync at host controller driver.
Enable runtime PM in omap_hsmmc
Rebas
On Fri, 2011-07-01 at 09:36 -0700, Kevin Hilman wrote:
> Rajendra Nayak writes:
>
> > This series adds base support needed to be able
> > to boot on a OMAP4460 device.
> > Patches are based on Benoit's for_3.0.1/7_hwmod_modulemode
> > branch and boot tested on both 4460sdp as well as 4430sdp.
>
Rajendra Nayak writes:
> This series adds base support needed to be able
> to boot on a OMAP4460 device.
> Patches are based on Benoit's for_3.0.1/7_hwmod_modulemode
> branch and boot tested on both 4460sdp as well as 4430sdp.
Can you also briefly summarize the dependencies between this series a
Hi Rajendra,
Rajendra Nayak writes:
> This series adds base support needed to be able
> to boot on a OMAP4460 device.
> Patches are based on Benoit's for_3.0.1/7_hwmod_modulemode
> branch and boot tested on both 4460sdp as well as 4430sdp.
Since you're on the delivery path of these patches, the
1 - 100 of 187 matches
Mail list logo
