On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote: > On Friday 23 August 2013 11:41 AM, Sricharan R wrote: >> Hi, >> On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote: >>> On Thursday 22 August 2013 05:03 PM, Sricharan R wrote: >>>> maps crossbar number<-> to interrupt number and >>>> calls request_irq(int_no, crossbar_handler,..) >>> So will this mapping happen based on some data passed from DT or >>> just based on whats available when the device does a request_irq()? >>> >>> If its based on whats available then I see an issue when you need >>> to remap something thats already mapped by default (and not used) >>> since you run out of all free ones. >> Yes, when done based on what is available then there is a >> problem when we run out of free ones because we do not >> know which one to replace. I was thinking of something like >> this, >> 1) DT would give a list of all free ones, and also if some are >> mapped as default and not used, mark those also as free. >> >> 2) While mapping see if it has a default mapping and use it. >> otherwise, pick from free list. > Since the entire DT is available to you at boot time, you should be able > to find each node where interrupt-parent = <&crossbar> and then allocate > one of 0-160 GIC interrupt numbers for that node, no? Where would there > be a need for default mapping and remapping? From one the mails in the > thread the crossbar is completely flexible - any of the 320 crossbar > interrupts can be mapped to any of the 160 GIC interrupts. > > Any GIC interrupts left after this boot-time scan can be added to an > unused list for use with runtime DT fragments (when that support comes). > > Sorry if I misunderstood, but above proposal sounds like maintaining a > separate free interrupt lines list in DT. That will quickly go out of sync. Say, peripheral x uses crossbar 1 and specifies this in DT. During boot crossbar 1 gets mapped int 10. So if by default some other crossbar has its interrupt mapped to 10, then it should be removed. Instead clear all crossbar registers once and mark all as free, then allocate only during request. Correct ?. In this the free no need to maintain any list. Regards, Sricharan -- 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
