>-----Original Message----- >From: Felipe Balbi [mailto:balbi@xxxxxx] >Sent: Tuesday, September 27, 2011 6:55 PM >To: Munegowda, Keshava >Cc: t-kristo@xxxxxx; Paul Walmsley; Cousson, Benoit; Basak, Partha; >Balbi, Felipe; parthab@xxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; linux- >omap@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Gadiyar, Anand; >sameo@xxxxxxxxxxxxxxx; tony@xxxxxxxxxxx; Hilman, Kevin; >johnstul@xxxxxxxxxx; 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
