Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Fri, 28 Oct 2011 15:03:36 +0300, Tero Kristo said: Hi Again, I created a new version of the patch which should be better than this hack, I'll send it as an RFC to the l-o list in a bit. On Thu, 2011-10-13 at 13:49 +0200, Munegowda, Keshava wrote: On Thu, Oct 13, 2011 at 4:58 PM, Tero Kristo t-kri...@ti.com wrote: On Thu, 2011-10-13 at 09:12 +0200, Munegowda, Keshava wrote: On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo t-kri...@ti.com wrote: On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote: Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID: 0115040-6. Domicile: Helsinki Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID: 0115040-6. Domicile: Helsinki Moral: Just leave current street addresses out of it. :) And can we *please* trim irrelevant stuff? You top-posted a 2 line reply, followed by the entire note, which a bunch of kernel developers got to scroll through and wonder if they missed an in-line comment. *Especially* after the top part had one line that it wasn't clear if it was a top-posted sig line gone wrong, or 3 attempts to get an address right for inclusion in a patch. pgpPuwI7FKr6i.pgp Description: PGP signature
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
Hi Again,
I created a new version of the patch which should be better than this
hack, I'll send it as an RFC to the l-o list in a bit.
On Thu, 2011-10-13 at 13:49 +0200, Munegowda, Keshava wrote:
On Thu, Oct 13, 2011 at 4:58 PM, Tero Kristo t-kri...@ti.com wrote:
On Thu, 2011-10-13 at 09:12 +0200, Munegowda, Keshava wrote:
On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus:
0115040-6. Kotipaikka: Helsinki
Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business
ID: 0115040-6. Domicile: Helsinki
Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID:
0115040-6. Domicile: Helsinki
-Original Message-
From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, September 26, 2011 7:49 PM
To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
part...@india.ti.com
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
vishwanath...@ti.com
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
structures for omap3
On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com
wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
wrote:
But the question arises here , why do we need these ehci and ohci
as
two
different hwmods containing only irq and base address? It is
required
for future - to implement remote wakeup feature for ehci and ohci
ports
depending on irq-chain handler patches by Tero. Separate hwmods for
ehci
and ohci are needed to enable prcm chain-handler to uniquely
identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci
and
ohci hwmods to enable I/O wakeup capability for respective IO-pads.
Depending on the particular wakeup source(ehci/ohci), the
corresponding
ehci or ohci irq handler will be called.
If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for ohci
wakeup
, only ehci interrupt will get called; which will break the
functionality.
Any reason why this couldn't be handled either by:
1. adding an IRQ number field to struct omap_hwmod_mux_info, and
changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?
yes, it is possible by changing the existing irq-chain handler by tero
Kristo
I am looping tero too.
So here are new requirements for the irq-chain handler
1. The hwmod should have have option to have multiple mux structures
This is something like:
The existing mux structure definition in omap_hwmod [file:
/arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure
struct omap_hwmod_mux_info *mux;
it should changed to
struct omap_hwmod_mux_info **pmux;
U32mux_cnt;
pmux - pointers to mux ; array of mux structures.
mux_cnt - number of mux per hwmod.
2. The mux omap_hwmod_mux_info structure should have new member
called irq, like as follows:
struct omap_hwmod_mux_info {
int nr_pads;
...
u32 irq;
};
Upon wakeup of the I/O pad of the mux , the irq-chain handler should
invoke the irq handler of the irq numbered map_hwmod_mux_info.irq
3. There should be SOME WAY to supply the irqs from hwmod
structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)
if you , tero and other opensource people are aligned on the proposed
changes on the irq-handler ;
then it is possible to have two hwmods ( usbhs and tll) for usbhost
driver.
please let me know you comments on the above approach.
Hello Tero,
I would like to draw your attention to the following thread:
We need to support the following:
1. Ability to associate multiple mux info to a hwmod.
2. Able to associate a particular irq handler to a mux info.
3. PRCM Chain handler should loop through all mux-info arrays
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Fri, Oct 28, 2011 at 5:33 PM, Tero Kristo t-kri...@ti.com wrote:
Hi Again,
I created a new version of the patch which should be better than this
hack, I'll send it as an RFC to the l-o list in a bit.
cool ! our discussion helped me.
please send the patch..
On Thu, 2011-10-13 at 13:49 +0200, Munegowda, Keshava wrote:
On Thu, Oct 13, 2011 at 4:58 PM, Tero Kristo t-kri...@ti.com wrote:
On Thu, 2011-10-13 at 09:12 +0200, Munegowda, Keshava wrote:
On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus:
0115040-6. Kotipaikka: Helsinki
Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business
ID: 0115040-6. Domicile: Helsinki
Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID:
0115040-6. Domicile: Helsinki
-Original Message-
From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, September 26, 2011 7:49 PM
To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
part...@india.ti.com
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
vishwanath...@ti.com
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
structures for omap3
On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com
wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
wrote:
But the question arises here , why do we need these ehci and ohci
as
two
different hwmods containing only irq and base address? It is
required
for future - to implement remote wakeup feature for ehci and ohci
ports
depending on irq-chain handler patches by Tero. Separate hwmods
for
ehci
and ohci are needed to enable prcm chain-handler to uniquely
identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci
and
ohci hwmods to enable I/O wakeup capability for respective
IO-pads.
Depending on the particular wakeup source(ehci/ohci), the
corresponding
ehci or ohci irq handler will be called.
If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for
ohci
wakeup
, only ehci interrupt will get called; which will break the
functionality.
Any reason why this couldn't be handled either by:
1. adding an IRQ number field to struct omap_hwmod_mux_info, and
changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?
yes, it is possible by changing the existing irq-chain handler by
tero
Kristo
I am looping tero too.
So here are new requirements for the irq-chain handler
1. The hwmod should have have option to have multiple mux structures
This is something like:
The existing mux structure definition in omap_hwmod [file:
/arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure
struct omap_hwmod_mux_info *mux;
it should changed to
struct omap_hwmod_mux_info **pmux;
U32 mux_cnt;
pmux - pointers to mux ; array of mux structures.
mux_cnt - number of mux per hwmod.
2. The mux omap_hwmod_mux_info structure should have new member
called irq, like as follows:
struct omap_hwmod_mux_info {
int nr_pads;
...
u32 irq;
};
Upon wakeup of the I/O pad of the mux , the irq-chain handler should
invoke the irq handler of the irq numbered map_hwmod_mux_info.irq
3. There should be SOME WAY to supply the irqs from hwmod
structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)
if you , tero and other opensource people are aligned on the proposed
changes on the irq-handler ;
then it is possible to have two hwmods ( usbhs and tll) for usbhost
driver.
please let me know you comments on the above approach.
Hello Tero,
I would like to draw your attention to the following thread:
We need to support the following:
1. Ability to associate
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
-Original Message-
From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, September 26, 2011 7:49 PM
To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
part...@india.ti.com
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
vishwanath...@ti.com
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
structures for omap3
On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
wrote:
But the question arises here , why do we need these ehci and ohci as
two
different hwmods containing only irq and base address? It is required
for future - to implement remote wakeup feature for ehci and ohci
ports
depending on irq-chain handler patches by Tero. Separate hwmods for
ehci
and ohci are needed to enable prcm chain-handler to uniquely identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci and
ohci hwmods to enable I/O wakeup capability for respective IO-pads.
Depending on the particular wakeup source(ehci/ohci), the
corresponding
ehci or ohci irq handler will be called.
If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for ohci
wakeup
, only ehci interrupt will get called; which will break the
functionality.
Any reason why this couldn't be handled either by:
1. adding an IRQ number field to struct omap_hwmod_mux_info, and
changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?
yes, it is possible by changing the existing irq-chain handler by tero
Kristo
I am looping tero too.
So here are new requirements for the irq-chain handler
1. The hwmod should have have option to have multiple mux structures
This is something like:
The existing mux structure definition in omap_hwmod [file:
/arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure
struct omap_hwmod_mux_info *mux;
it should changed to
struct omap_hwmod_mux_info **pmux;
U32 mux_cnt;
pmux - pointers to mux ; array of mux structures.
mux_cnt - number of mux per hwmod.
2. The mux omap_hwmod_mux_info structure should have new member
called irq, like as follows:
struct omap_hwmod_mux_info {
int nr_pads;
...
u32 irq;
};
Upon wakeup of the I/O pad of the mux , the irq-chain handler should
invoke the irq handler of the irq numbered map_hwmod_mux_info.irq
3. There should be SOME WAY to supply the irqs from hwmod
structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)
if you , tero and other opensource people are aligned on the proposed
changes on the irq-handler ;
then it is possible to have two hwmods ( usbhs and tll) for usbhost
driver.
please let me know you comments on the above approach.
Hello Tero,
I would like to draw your attention to the following thread:
We need to support the following:
1. Ability to associate multiple mux info to a hwmod.
2. Able to associate a particular irq handler to a mux info.
3. PRCM Chain handler should loop through all mux-info arrays
for a particular hwmod to identify the possible wakeup source(s)
and call the appropriate irq handler for that mux-info.
(It is possible that both mux-info are woken up in which case both
handlers should be called).
To give you a little more perspective, EHCI OHCI are co-controllers
under UHH/TLL.
They do not get presented separately to the OCP bus, hence do not qualify
as separate hwmods
(Paul had objected to the design approach representing EHCI OHCI as
different hwmods).
However, we need a mechanism to efficiently identify/distinguish
remote-wakeup, connect/disconnect
On to an EHCI port vs an OHCI port call only the correct interrupt
handler(EHCI or OHCI).
To incorporate this, chain handler implementation would need some
enhancements.
We can look into the details in the next merge
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Fri, Sep 30, 2011 at 11:46 PM, Paul Walmsley p...@pwsan.com wrote: 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 on when I invoke pm_runtime_get_sync ; so there are couple of options to do this 1. use clk_get with hard coded usbhost_120m_fck name in usbhs driver enable this clock after invoking pm_runtime_get_sync 2. add an additional flag in hwmod ; so that pm_runtime_get_sync will enable main clock as well as optional clocks please comment on these two approaches.. Looks like you picked approach #1 which is fine with me. Here's what I don't understand about how this clock is used, though. According to the 34xx TRM vZR Section 24.2.3.1.2 High-Speed USB Host Subsystem Clocks, this is only used to clock EHCI controller internal logic. So if EHCI is not being used, it would seem to me that this clock shouldn't be enabled? But patch #5 seems to enable and disable it unconditionally. Am I missing something here? OK. are you suggesting that this clock should be enabled/disabled; only if atleast one port is selected for ehci? Seems to make sense to me? If the clock really isn't needed for OHCI, then it shouldn't be enabled when only OHCI is in use? thanks. I will make this :-) regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
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 usbhost_120m_fck name in usbhs driver enable this clock after invoking pm_runtime_get_sync 2. add an additional flag in hwmod ; so that pm_runtime_get_sync will enable main clock as well as optional clocks please comment on these two approaches.. Looks like you picked approach #1 which is fine with me. Here's what I don't understand about how this clock is used, though. According to the 34xx TRM vZR Section 24.2.3.1.2 High-Speed USB Host Subsystem Clocks, this is only used to clock EHCI controller internal logic. So if EHCI is not being used, it would seem to me that this clock shouldn't be enabled? But patch #5 seems to enable and disable it unconditionally. Am I missing something here? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
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 couple of options to do this 1. use clk_get with hard coded usbhost_120m_fck name in usbhs driver enable this clock after invoking pm_runtime_get_sync 2. add an additional flag in hwmod ; so that pm_runtime_get_sync will enable main clock as well as optional clocks please comment on these two approaches.. Looks like you picked approach #1 which is fine with me. Here's what I don't understand about how this clock is used, though. According to the 34xx TRM vZR Section 24.2.3.1.2 High-Speed USB Host Subsystem Clocks, this is only used to clock EHCI controller internal logic. So if EHCI is not being used, it would seem to me that this clock shouldn't be enabled? But patch #5 seems to enable and disable it unconditionally. Am I missing something here? OK. are you suggesting that this clock should be enabled/disabled; only if atleast one port is selected for ehci? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
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 on when I invoke pm_runtime_get_sync ; so there are couple of options to do this 1. use clk_get with hard coded usbhost_120m_fck name in usbhs driver enable this clock after invoking pm_runtime_get_sync 2. add an additional flag in hwmod ; so that pm_runtime_get_sync will enable main clock as well as optional clocks please comment on these two approaches.. Looks like you picked approach #1 which is fine with me. Here's what I don't understand about how this clock is used, though. According to the 34xx TRM vZR Section 24.2.3.1.2 High-Speed USB Host Subsystem Clocks, this is only used to clock EHCI controller internal logic. So if EHCI is not being used, it would seem to me that this clock shouldn't be enabled? But patch #5 seems to enable and disable it unconditionally. Am I missing something here? OK. are you suggesting that this clock should be enabled/disabled; only if atleast one port is selected for ehci? Seems to make sense to me? If the clock really isn't needed for OHCI, then it shouldn't be enabled when only OHCI is in use? - Paul
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Mon, Sep 26, 2011 at 8:15 PM, Paul Walmsley p...@pwsan.com wrote:
On Mon, 26 Sep 2011, Munegowda, Keshava wrote:
On Sat, Sep 24, 2011 at 12:45 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271
1 files changed, 271 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d79f728 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk = usbhost_120m_fck,
This doesn't look right. This is an interface structure record, so it
should be associated with an interface clock. Is the hardware really
using the functional clock as the interface clock? Or, as seems more
likely...
Agreed, how about:
main clock: usbhost_120m_fck
optional f clock: usbhost_48m_fck
Assuming the interface clock is enabled, which one of these clocks is
needed for UHH register accesses to complete successfully?
it is usbhost_48m_fck ;
so,
main clock: usbhost_48m_fck
optional clock : usbhost_120m_fck
do you agree?
Yes.
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 usbhost_120m_fck name in usbhs driver
enable this clock after invoking pm_runtime_get_sync
2. add an additional flag in hwmod ; so that pm_runtime_get_sync will enable
main clock as well as optional clocks
please comment on these two approaches..
regards
keshava
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
-Original Message-
From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, September 26, 2011 7:49 PM
To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
part...@india.ti.com
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
vishwanath...@ti.com
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
structures for omap3
On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
wrote:
But the question arises here , why do we need these ehci and ohci as
two
different hwmods containing only irq and base address? It is required
for future - to implement remote wakeup feature for ehci and ohci
ports
depending on irq-chain handler patches by Tero. Separate hwmods for
ehci
and ohci are needed to enable prcm chain-handler to uniquely identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci and
ohci hwmods to enable I/O wakeup capability for respective IO-pads.
Depending on the particular wakeup source(ehci/ohci), the
corresponding
ehci or ohci irq handler will be called.
If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for ohci
wakeup
, only ehci interrupt will get called; which will break the
functionality.
Any reason why this couldn't be handled either by:
1. adding an IRQ number field to struct omap_hwmod_mux_info, and
changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?
yes, it is possible by changing the existing irq-chain handler by tero
Kristo
I am looping tero too.
So here are new requirements for the irq-chain handler
1. The hwmod should have have option to have multiple mux structures
This is something like:
The existing mux structure definition in omap_hwmod [file:
/arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure
struct omap_hwmod_mux_info *mux;
it should changed to
struct omap_hwmod_mux_info **pmux;
U32mux_cnt;
pmux - pointers to mux ; array of mux structures.
mux_cnt - number of mux per hwmod.
2. The mux omap_hwmod_mux_info structure should have new member
called irq, like as follows:
struct omap_hwmod_mux_info {
int nr_pads;
...
u32 irq;
};
Upon wakeup of the I/O pad of the mux , the irq-chain handler should
invoke the irq handler of the irq numbered map_hwmod_mux_info.irq
3. There should be SOME WAY to supply the irqs from hwmod
structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)
if you , tero and other opensource people are aligned on the proposed
changes on the irq-handler ;
then it is possible to have two hwmods ( usbhs and tll) for usbhost
driver.
please let me know you comments on the above approach.
Hello Tero,
I would like to draw your attention to the following thread:
We need to support the following:
1. Ability to associate multiple mux info to a hwmod.
2. Able to associate a particular irq handler to a mux info.
3. PRCM Chain handler should loop through all mux-info arrays
for a particular hwmod to identify the possible wakeup source(s)
and call the appropriate irq handler for that mux-info.
(It is possible that both mux-info are woken up in which case both
handlers should be called).
To give you a little more perspective, EHCI OHCI are co-controllers
under UHH/TLL.
They do not get presented separately to the OCP bus, hence do not qualify
as separate hwmods
(Paul had objected to the design approach representing EHCI OHCI as
different hwmods).
However, we need a mechanism to efficiently identify/distinguish
remote-wakeup, connect/disconnect
On to an EHCI port vs an OHCI port call only the correct interrupt
handler(EHCI or OHCI).
To incorporate this, chain handler implementation would need some
enhancements.
We can look into the details in the next merge window cycle in
conjunction with aggressive clock management support for EHCI/OHCI.
But fundamentally, if you are aligned to the approach, we can go ahead
collapsing the EHCI OHCI hwmods into one.
or
2. using shared interrupts?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
RE: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
-Original Message-
From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, September 26, 2011 7:49 PM
To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
part...@india.ti.com
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
vishwanath...@ti.com
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
structures for omap3
On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
wrote:
But the question arises here , why do we need these ehci and ohci as
two
different hwmods containing only irq and base address? It is required
for future - to implement remote wakeup feature for ehci and ohci
ports
depending on irq-chain handler patches by Tero. Separate hwmods for
ehci
and ohci are needed to enable prcm chain-handler to uniquely identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci and
ohci hwmods to enable I/O wakeup capability for respective IO-pads.
Depending on the particular wakeup source(ehci/ohci), the
corresponding
ehci or ohci irq handler will be called.
If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for ohci
wakeup
, only ehci interrupt will get called; which will break the
functionality.
Any reason why this couldn't be handled either by:
1. adding an IRQ number field to struct omap_hwmod_mux_info, and
changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?
yes, it is possible by changing the existing irq-chain handler by tero
Kristo
I am looping tero too.
So here are new requirements for the irq-chain handler
1. The hwmod should have have option to have multiple mux structures
This is something like:
The existing mux structure definition in omap_hwmod [file:
/arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure
struct omap_hwmod_mux_info *mux;
it should changed to
struct omap_hwmod_mux_info **pmux;
U32mux_cnt;
pmux - pointers to mux ; array of mux structures.
mux_cnt - number of mux per hwmod.
2. The mux omap_hwmod_mux_info structure should have new member
called irq, like as follows:
struct omap_hwmod_mux_info {
int nr_pads;
...
u32 irq;
};
Upon wakeup of the I/O pad of the mux , the irq-chain handler should
invoke the irq handler of the irq numbered map_hwmod_mux_info.irq
3. There should be SOME WAY to supply the irqs from hwmod
structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)
if you , tero and other opensource people are aligned on the proposed
changes on the irq-handler ;
then it is possible to have two hwmods ( usbhs and tll) for usbhost
driver.
please let me know you comments on the above approach.
Hello Tero,
I would like to draw your attention to the following thread:
We need to support the following:
1. Ability to associate multiple mux info to a hwmod.
2. Able to associate a particular irq handler to a mux info.
3. PRCM Chain handler should loop through all mux-info arrays
for a particular hwmod to identify the possible wakeup source(s)
and call the appropriate irq handler for that mux-info.
(It is possible that both mux-info are woken up in which case both
handlers should be called).
To give you a little more perspective, EHCI OHCI are co-controllers
under UHH/TLL.
They do not get presented separately to the OCP bus, hence do not qualify
as separate hwmods
(Paul had objected to the design approach representing EHCI OHCI as
different hwmods).
However, we need a mechanism to efficiently identify/distinguish
remote-wakeup, connect/disconnect
On to an EHCI port vs an OHCI port call only the correct interrupt
handler(EHCI or OHCI).
To incorporate this, chain handler implementation would need some
enhancements.
We can look into the details in the next merge window cycle in
conjunction with aggressive clock management support for EHCI/OHCI.
But fundamentally, if you are aligned to the approach, we can
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
-Original Message-
From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, September 26, 2011 7:49 PM
To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
part...@india.ti.com
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
vishwanath...@ti.com
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
structures for omap3
On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
wrote:
But the question arises here , why do we need these ehci and ohci as
two
different hwmods containing only irq and base address? It is required
for future - to implement remote wakeup feature for ehci and ohci
ports
depending on irq-chain handler patches by Tero. Separate hwmods for
ehci
and ohci are needed to enable prcm chain-handler to uniquely identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci and
ohci hwmods to enable I/O wakeup capability for respective IO-pads.
Depending on the particular wakeup source(ehci/ohci), the
corresponding
ehci or ohci irq handler will be called.
If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for ohci
wakeup
, only ehci interrupt will get called; which will break the
functionality.
Any reason why this couldn't be handled either by:
1. adding an IRQ number field to struct omap_hwmod_mux_info, and
changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?
yes, it is possible by changing the existing irq-chain handler by tero
Kristo
I am looping tero too.
So here are new requirements for the irq-chain handler
1. The hwmod should have have option to have multiple mux structures
This is something like:
The existing mux structure definition in omap_hwmod [file:
/arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure
struct omap_hwmod_mux_info *mux;
it should changed to
struct omap_hwmod_mux_info **pmux;
U32 mux_cnt;
pmux - pointers to mux ; array of mux structures.
mux_cnt - number of mux per hwmod.
2. The mux omap_hwmod_mux_info structure should have new member
called irq, like as follows:
struct omap_hwmod_mux_info {
int nr_pads;
...
u32 irq;
};
Upon wakeup of the I/O pad of the mux , the irq-chain handler should
invoke the irq handler of the irq numbered map_hwmod_mux_info.irq
3. There should be SOME WAY to supply the irqs from hwmod
structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)
if you , tero and other opensource people are aligned on the proposed
changes on the irq-handler ;
then it is possible to have two hwmods ( usbhs and tll) for usbhost
driver.
please let me know you comments on the above approach.
Hello Tero,
I would like to draw your attention to the following thread:
We need to support the following:
1. Ability to associate multiple mux info to a hwmod.
2. Able to associate a particular irq handler to a mux info.
3. PRCM Chain handler should loop through all mux-info arrays
for a particular hwmod to identify the possible wakeup source(s)
and call the appropriate irq handler for that mux-info.
(It is possible that both mux-info are woken up in which case both
handlers should be called).
To give you a little more perspective, EHCI OHCI are co-controllers
under UHH/TLL.
They do not get presented separately to the OCP bus, hence do not qualify
as separate hwmods
(Paul had objected to the design approach representing EHCI OHCI as
different hwmods).
However, we need a mechanism to efficiently identify/distinguish
remote-wakeup, connect/disconnect
On to an EHCI port vs an OHCI port call only the correct interrupt
handler(EHCI or OHCI).
To incorporate this, chain handler implementation would need some
enhancements.
We can look into the details in the next merge window cycle in
conjunction with aggressive clock management support for EHCI/OHCI
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
Hi, On Tue, Sep 27, 2011 at 06:48:35PM +0530, Munegowda, Keshava wrote: So, you would need a mechanism to do something like this: pad a or b wakeup detected - irq0 pad c or d wakeup detected - irq1? yes, if get something like this , its perfect. can't you have different IRQs for each pad ? I mean, allocate one irq_desc for each pad and let drivers request a pad/pin as an IRQ source. Then, when you detect a pad wakeup, you can: unsignedpad_irq = pad_number - pad-irq_base; handle_nested_thread(pad_irq); this will make use of threaded IRQ handlers even. Could it be something like that ? -- balbi signature.asc Description: Digital signature
RE: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
-Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Tuesday, September 27, 2011 6:55 PM To: Munegowda, Keshava Cc: t-kri...@ti.com; Paul Walmsley; Cousson, Benoit; Basak, Partha; Balbi, Felipe; part...@india.ti.com; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; linux-ker...@vger.kernel.org; Gadiyar, Anand; sa...@linux.intel.com; t...@atomide.com; Hilman, Kevin; johns...@us.ibm.com; Sripathy, Vishwanath Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3 Hi, On Tue, Sep 27, 2011 at 06:48:35PM +0530, Munegowda, Keshava wrote: So, you would need a mechanism to do something like this: pad a or b wakeup detected - irq0 pad c or d wakeup detected - irq1? yes, if get something like this , its perfect. can't you have different IRQs for each pad ? I mean, allocate one irq_desc for each pad and let drivers request a pad/pin as an IRQ source. Then, when you detect a pad wakeup, you can: unsigned pad_irq = pad_number - pad-irq_base; handle_nested_thread(pad_irq); this will make use of threaded IRQ handlers even. Could it be something like that ? Felipe, your suggestion would mean more design change from the existing implementation of Tero. I would propose something like what Tero said initially: For each mux-info have an associated irq handler. So, say pads a..d form mux info1. This gets associated to irq_handler1. Similarly, say pads e..h form mux info2. This gets associated to irq_handler2. Both get associated to the same uhh_hwmod. Now, when chain handler scans for wakeup sources, it scans both mux-info1 mux-info2. If at-least one pad in mux-info1 is woken up, irqhandler1 is called same for irqhandler2. This mechanism would need multiple mux-infos to be attached to the same hwmod. So, fundamentally, if we are in alignment, can we go ahead now to collapse the ehci ohci hwmods into one? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Tue, 2011-09-27 at 15:24 +0200, Balbi, Felipe wrote: Hi, On Tue, Sep 27, 2011 at 06:48:35PM +0530, Munegowda, Keshava wrote: So, you would need a mechanism to do something like this: pad a or b wakeup detected - irq0 pad c or d wakeup detected - irq1? yes, if get something like this , its perfect. can't you have different IRQs for each pad ? I mean, allocate one irq_desc for each pad and let drivers request a pad/pin as an IRQ source. Then, when you detect a pad wakeup, you can: Direct pad to irq mapping was turned down on some previous version of the prcm chain handler set, but yes, it is a potential approach. However the irq_desc allocation mechanism should be dynamic... there are some 200 programmable pads anyway. unsigned pad_irq = pad_number - pad-irq_base; handle_nested_thread(pad_irq); this will make use of threaded IRQ handlers even. Could it be something like that ? Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
hi, On Tue, Sep 27, 2011 at 05:38:51PM +0300, Tero Kristo wrote: On Tue, Sep 27, 2011 at 06:48:35PM +0530, Munegowda, Keshava wrote: So, you would need a mechanism to do something like this: pad a or b wakeup detected - irq0 pad c or d wakeup detected - irq1? yes, if get something like this , its perfect. can't you have different IRQs for each pad ? I mean, allocate one irq_desc for each pad and let drivers request a pad/pin as an IRQ source. Then, when you detect a pad wakeup, you can: Direct pad to irq mapping was turned down on some previous version of the prcm chain handler set, but yes, it is a potential approach. However do you remember what was the reason for that being turned down ? Maybe I can search the archives... the irq_desc allocation mechanism should be dynamic... there are some 200 programmable pads anyway. I wouldn't worry too much about that. If you try to allocate irq_desc dynamically, you would have to keep track of an irq_base for each irq_desc you allocate, otherwise it's difficult to map it back to mux number. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
But the question arises here , why do we need these ehci and ohci as two
different hwmods containing only irq and base address? It is required
for future - to implement remote wakeup feature for ehci and ohci ports
depending on irq-chain handler patches by Tero. Separate hwmods for ehci
and ohci are needed to enable prcm chain-handler to uniquely identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci and
ohci hwmods to enable I/O wakeup capability for respective IO-pads.
Depending on the particular wakeup source(ehci/ohci), the corresponding
ehci or ohci irq handler will be called.
If ehci and ohci are combined with usbhs hwmod as a single hwmod , then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for ohci wakeup
, only ehci interrupt will get called; which will break the functionality.
Any reason why this couldn't be handled either by:
1. adding an IRQ number field to struct omap_hwmod_mux_info, and changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?
yes, it is possible by changing the existing irq-chain handler by tero Kristo
I am looping tero too.
So here are new requirements for the irq-chain handler
1. The hwmod should have have option to have multiple mux structures
This is something like:
The existing mux structure definition in omap_hwmod [file:
/arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure
struct omap_hwmod_mux_info *mux;
it should changed to
struct omap_hwmod_mux_info **pmux;
U32mux_cnt;
pmux - pointers to mux ; array of mux structures.
mux_cnt - number of mux per hwmod.
2. The mux omap_hwmod_mux_info structure should have new member
called irq, like as follows:
struct omap_hwmod_mux_info {
int nr_pads;
...
u32 irq;
};
Upon wakeup of the I/O pad of the mux , the irq-chain handler should
invoke the irq handler of the irq numbered map_hwmod_mux_info.irq
3. There should be SOME WAY to supply the irqs from hwmod
structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)
if you , tero and other opensource people are aligned on the proposed
changes on the irq-handler ;
then it is possible to have two hwmods ( usbhs and tll) for usbhost driver.
please let me know you comments on the above approach.
or
2. using shared interrupts?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Sat, Sep 24, 2011 at 12:45 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271
1 files changed, 271 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d79f728 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk = usbhost_120m_fck,
This doesn't look right. This is an interface structure record, so it
should be associated with an interface clock. Is the hardware really
using the functional clock as the interface clock? Or, as seems more
likely...
Agreed, how about:
main clock: usbhost_120m_fck
optional f clock: usbhost_48m_fck
Assuming the interface clock is enabled, which one of these clocks is
needed for UHH register accesses to complete successfully?
it is usbhost_48m_fck ;
so,
main clock: usbhost_48m_fck
optional clock : usbhost_120m_fck
do you agree?
interface clock: usbhost_ick.
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
... is this just a hack? OCPIF_SWSUP_IDLE is intended to work around
hardware autoidle bugs only. Are you sure this shouldn't be defined as an
optional clock instead?
yes ! it was causeing resets, hence you this flag.
usbhost_120m_fck is not an interface clock. That is probably what was
causing the problem you describe.
yes , you are right ! its not an interface clock.
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
Is this really the main clock? The main clock is the clock that drives
the register logic in the IP block. Looks to me, based on the integration
document in the 34xx TRM vZR, that this module has a functional clock. In
general, the only time that the main_clk should be an interface clock is
when the clock is a combined interface and functional clock. The mailbox
IP block is a classic example.
As I mentioned above; I can make
main clock: usbhost_120m_fck
optional f clock: usbhost_48m_fck
interface clock: usbhost_ick.
do you agree?
The interface clock should definitely be usbhost_ick, no doubt about it.
But, as I mentioned above, to determine which functional clock should be
the main clock, you first need to know which of those two clocks need to
be enabled for register accesses to that module to succeed.
I did this work a few years ago, by trial and error since it was largely
undocumented. It was needed since the OMAP3 clk_enable() code waits for
the PRCM to request that the IP block exit idle before returning.
You might want to take a look at arch/arm/mach-omap2/clock3xxx_data.c.
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod = {
+ .name = usb_tll_hs,
+ .class = omap34xx_usb_tll_hs_hwmod_class,
+ .mpu_irqs = omap34xx_usb_tll_hs_irqs,
+ .main_clk = usbtll_ick,
Is this really the main clock? The main clock is the clock that drives
the register logic in the IP block. Looks to me, based on the integration
document in the 34xx TRM vZR, that this module has a functional clock.
I can make
main clock: usbtll_fck
interface clock: usbtll_ick.
do you agree?
Doesn't that make more sense?
yes, I will do this change.
keshava
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Mon, 26 Sep 2011, Munegowda, Keshava wrote:
On Sat, Sep 24, 2011 at 12:45 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271
1 files changed, 271 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d79f728 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk = usbhost_120m_fck,
This doesn't look right. This is an interface structure record, so it
should be associated with an interface clock. Is the hardware really
using the functional clock as the interface clock? Or, as seems more
likely...
Agreed, how about:
main clock: usbhost_120m_fck
optional f clock: usbhost_48m_fck
Assuming the interface clock is enabled, which one of these clocks is
needed for UHH register accesses to complete successfully?
it is usbhost_48m_fck ;
so,
main clock: usbhost_48m_fck
optional clock : usbhost_120m_fck
do you agree?
Yes.
- Paul
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Fri, 23 Sep 2011, Munegowda, Keshava wrote: On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote: But the question arises here , why do we need these ehci and ohci as two different hwmods containing only irq and base address? It is required for future - to implement remote wakeup feature for ehci and ohci ports depending on irq-chain handler patches by Tero. Separate hwmods for ehci and ohci are needed to enable prcm chain-handler to uniquely identify the wakeup source as ehci or ohci and call only the corresponding interrupt handler. We will be using omap_hwmod_mux_init for ehci and ohci hwmods to enable I/O wakeup capability for respective IO-pads. Depending on the particular wakeup source(ehci/ohci), the corresponding ehci or ohci irq handler will be called. If ehci and ohci are combined with usbhs hwmod as a single hwmod , then for every wakeup (either ehci or ohci port wakeup) only the first interrupt handler will be called (please look at the function omap_hwmod_mux_handle_irq of /arch/arm/mach-omap2/mux.c file ; in tero's latest patch: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html) , so in this case, if ehci interrupt is the first interrupt , then even for ohci wakeup , only ehci interrupt will get called; which will break the functionality. Any reason why this couldn't be handled either by: 1. adding an IRQ number field to struct omap_hwmod_mux_info, and changing _omap_hwmod_mux_handle_irq() to raise that IRQ number? or 2. using shared interrupts? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271
1 files changed, 271 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d79f728 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk = usbhost_120m_fck,
This doesn't look right. This is an interface structure record, so it
should be associated with an interface clock. Is the hardware really
using the functional clock as the interface clock? Or, as seems more
likely...
Agreed, how about:
main clock: usbhost_120m_fck
optional f clock: usbhost_48m_fck
Assuming the interface clock is enabled, which one of these clocks is
needed for UHH register accesses to complete successfully?
interface clock: usbhost_ick.
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
... is this just a hack? OCPIF_SWSUP_IDLE is intended to work around
hardware autoidle bugs only. Are you sure this shouldn't be defined as an
optional clock instead?
yes ! it was causeing resets, hence you this flag.
usbhost_120m_fck is not an interface clock. That is probably what was
causing the problem you describe.
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
Is this really the main clock? The main clock is the clock that drives
the register logic in the IP block. Looks to me, based on the integration
document in the 34xx TRM vZR, that this module has a functional clock. In
general, the only time that the main_clk should be an interface clock is
when the clock is a combined interface and functional clock. The mailbox
IP block is a classic example.
As I mentioned above; I can make
main clock: usbhost_120m_fck
optional f clock: usbhost_48m_fck
interface clock: usbhost_ick.
do you agree?
The interface clock should definitely be usbhost_ick, no doubt about it.
But, as I mentioned above, to determine which functional clock should be
the main clock, you first need to know which of those two clocks need to
be enabled for register accesses to that module to succeed.
I did this work a few years ago, by trial and error since it was largely
undocumented. It was needed since the OMAP3 clk_enable() code waits for
the PRCM to request that the IP block exit idle before returning.
You might want to take a look at arch/arm/mach-omap2/clock3xxx_data.c.
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod = {
+ .name = usb_tll_hs,
+ .class = omap34xx_usb_tll_hs_hwmod_class,
+ .mpu_irqs = omap34xx_usb_tll_hs_irqs,
+ .main_clk = usbtll_ick,
Is this really the main clock? The main clock is the clock that drives
the register logic in the IP block. Looks to me, based on the integration
document in the 34xx TRM vZR, that this module has a functional clock.
I can make
main clock: usbtll_fck
interface clock: usbtll_ick.
do you agree?
Doesn't that make more sense?
- Paul
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
a few comments
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
following 4 hwmod structures are added
1. usb_host_hs hwmod of usbhs with uhh base address and functional clock,
2. usb_ehci_hs hwmod with irq and base address,
3. usb_ohci_hs hwmod with irq and base address,
- the ehci and ohci hwmods does not require functional clock
because usb_host_hs has functional clock which is sufficient
to access ehci and ohci address space.
Every hwmod should have a functional clock defined. If they use the same
functional clock as usb_host_hs, then the same main_clk should be listed
for ehci/ohci also.
yes it is right in general convention.
But USB host is different case. :-)
Yes, Ehci and Ohci are embedded within usbhs ; hence they do not need
separate functional clocks.
But the question arises here , why do we need these ehci and ohci as two
different hwmods containing only irq and base address?
It is required for future - to implement remote wakeup feature for ehci
and ohci ports depending on irq-chain handler patches by Tero.
Separate hwmods for ehci and ohci are needed to enable prcm chain-handler
to uniquely identify the wakeup source as ehci or ohci and call only the
corresponding interrupt handler.
We will be using omap_hwmod_mux_init for ehci and ohci hwmods to enable
I/O wakeup capability for respective IO-pads. Depending on the particular
wakeup source(ehci/ohci), the corresponding ehci or ohci irq handler will
be called.
If ehci and ohci are combined with usbhs hwmod as a single hwmod , then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of
/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for ohci wakeup
, only ehci interrupt will get called; which will break the functionality.
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271
1 files changed, 271 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d79f728 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,266 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk = core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
This is missing a bunch of SYSC bits, according to Table 24-152
UHH_SYSCONFIG of the 34xx public TRM, version ZR.
some time back i had extended this , but it was causing system resets;
I will check this and add the remaining flags.
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields = omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
[PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
following 4 hwmod structures are added
1. usb_host_hs hwmod of usbhs with uhh base address and functional clock,
2. usb_ehci_hs hwmod with irq and base address,
3. usb_ohci_hs hwmod with irq and base address,
- the ehci and ohci hwmods does not require functional clock
because usb_host_hs has functional clock which is sufficient
to access ehci and ohci address space.
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271
1 files changed, 271 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d79f728 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,266 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk= l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk= usbhost_120m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk= usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters= omap34xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+/*
+ * The usbhs controller prevents the enter omap to low power mode
+ * if other than FORCE IDLE and FORCE STANDBY are used.
+ */
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/* 'usb_ohci_hs' class */
+static struct omap_hwmod_class
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
Hi
a few comments
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
following 4 hwmod structures are added
1. usb_host_hs hwmod of usbhs with uhh base address and functional clock,
2. usb_ehci_hs hwmod with irq and base address,
3. usb_ohci_hs hwmod with irq and base address,
- the ehci and ohci hwmods does not require functional clock
because usb_host_hs has functional clock which is sufficient
to access ehci and ohci address space.
Every hwmod should have a functional clock defined. If they use the same
functional clock as usb_host_hs, then the same main_clk should be listed
for ehci/ohci also.
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271
1 files changed, 271 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d79f728 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,266 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
This is missing a bunch of SYSC bits, according to Table 24-152
UHH_SYSCONFIG of the 34xx public TRM, version ZR.
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk= l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk= usbhost_120m_fck,
This doesn't look right. This is an interface structure record, so it
should be associated with an interface clock. Is the hardware really
using the functional clock as the interface clock? Or, as seems more
likely...
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
... is this just a hack? OCPIF_SWSUP_IDLE is intended to work around
hardware autoidle bugs only. Are you sure this shouldn't be defined as an
optional clock instead?
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk= usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
Same comments as the above.
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
Is this really the main clock? The main clock is the clock that drives
the register logic in the IP block. Looks to me, based on the
