Message-ID: <CAP05o4K2EzAKDgC9EdfEURCfcM=M7TRJdBuAtRafL2RHg+qTag@mail.gmail.com>
Date:	Thu, 13 Oct 2011 12:42:41 +0530
From:	"Munegowda, Keshava" <keshava_mgowda@...com>
To:	t-kristo@...com, Paul Walmsley <paul@...an.com>,
	"Cousson, Benoit" <b-cousson@...com>
Cc:	"Basak, Partha" <p-basak2@...com>, "Balbi, Felipe" <balbi@...com>,
	parthab@...ia.ti.com, linux-usb@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Gadiyar, Anand" <gadiyar@...com>, sameo@...ux.intel.com,
	tony@...mide.com, "Hilman, Kevin" <khilman@...com>,
	johnstul@...ibm.com, "Sripathy, Vishwanath" <vishwanath.bs@...com>
Subject: 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_mgowda@...com> wrote:
> On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo <t-kristo@...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_mgowda@...com]
>>> >Sent: Monday, September 26, 2011 7:49 PM
>>> >To: Paul Walmsley; Tero Kristo; b-cousson@...com; balbi@...com;
>>> >parthab@...ia.ti.com
>>> >Cc: linux-usb@...r.kernel.org; linux-omap@...r.kernel.org; linux-
>>> >kernel@...r.kernel.org; gadiyar@...com; sameo@...ux.intel.com;
>>> >tony@...mide.com; khilman@...com; johnstul@...ibm.com;
>>> >vishwanath.bs@...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 <paul@...an.com> wrote:
>>> >> On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
>>> >>
>>> >>> On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley <paul@...an.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.
>>>  But fundamentally, if you are aligned to the approach, we can go ahead
>>> collapsing the EHCI & OHCI hwmods into one.
>>
>> Hi,
>>
>> 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.

Hi Tero
           Are you posting the patches with these changes?
please let me know when you will be able to post the patches.
so that I start the design of usb host remote wakeup using your changes.

regards
keshava




>
>>
>> Is it okay to do this:
>>
>> pad a...d wakeup -> irq0 and irq1?
>
> No, we dont need multiple irq handlers for single wakeup source.
>
>>
>> I am okay doing something like this, we just need to agree how this
>> would be represented from the hwmod point of view. Currently the chain
>> handler set does not change hwmod structures at all to provide what it
>> does.
>
> paul and benoit are the people to design the mechanisam for this.
>
> paul/Benoit
>            please give you thoughts on this.
>
> regards
> keshava
>
>
>>
>> -Tero
>>
>>> >
>>> >>
>>> >> or
>>> >>
>>> >> 2. using shared interrupts?
>>> >>
>>> >>
>>> >> - Paul
>>> >>
>>
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists