On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo <t-kristo@xxxxxx> 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@xxxxxx] >> >Sent: Monday, September 26, 2011 7:49 PM >> >To: Paul Walmsley; Tero Kristo; b-cousson@xxxxxx; balbi@xxxxxx; >> >parthab@xxxxxxxxxxxx >> >Cc: linux-usb@xxxxxxxxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx; linux- >> >kernel@xxxxxxxxxxxxxxx; gadiyar@xxxxxx; sameo@xxxxxxxxxxxxxxx; >> >tony@xxxxxxxxxxx; khilman@xxxxxx; johnstul@xxxxxxxxxx; >> >vishwanath.bs@xxxxxx >> >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@xxxxxxxxx> wrote: >> >> On Fri, 23 Sep 2011, Munegowda, Keshava wrote: >> >> >> >>> On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley <paul@xxxxxxxxx> >> >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@xxxxxxxxxxxxxxx/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. > > 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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
