Re: [PATCH 1/3] misc: Add crossbar driver
On Friday 23 August 2013 03:06 PM, Linus Walleij wrote: > On Fri, Aug 23, 2013 at 6:28 PM, Sekhar Nori wrote: >> On 8/23/2013 7:08 PM, Santosh Shilimkar wrote: > >>> The whole point we are moving to domain is not have any default >>> mapping(connection done) at DT level. Rather DT only specifies the >>> peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). >>> This will be the driver input as a IRQ line from DT. The cross-bar >>> driver needs to map any of the free list available on *request* only. >> >> Right, the mapping can be done on request. That will be cleaner. > > I like where this design is going now :-) > Sure and thanks for good discussion. Debates are useful regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Fri, Aug 23, 2013 at 6:28 PM, Sekhar Nori wrote: > On 8/23/2013 7:08 PM, Santosh Shilimkar wrote: >> The whole point we are moving to domain is not have any default >> mapping(connection done) at DT level. Rather DT only specifies the >> peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). >> This will be the driver input as a IRQ line from DT. The cross-bar >> driver needs to map any of the free list available on *request* only. > > Right, the mapping can be done on request. That will be cleaner. I like where this design is going now :-) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On 8/23/2013 7:08 PM, Santosh Shilimkar wrote: > On Friday 23 August 2013 04:14 AM, Sekhar Nori wrote: >> On Friday 23 August 2013 12:23 PM, Sricharan R wrote: >>> 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 = <> 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. >> >> Right, so in my suggestion there is nothing like a "default mapping" and >> entire 160 GIC interrupt number space is up for grabs. I think this will >> be much simpler to write and maintain. >> >> If you really want to maintain default mapping as far as possible, you >> can do two passes on the crossbar interrupt numbers requested. Once to >> assign the default map - for numbers less that 160 - and then look at >> the free GIC interrupt slots and use those for numbers greater than 160. >> > The whole point we are moving to domain is not have any default > mapping(connection done) at DT level. Rather DT only specifies the > peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). > This will be the driver input as a IRQ line from DT. The cross-bar > driver needs to map any of the free list available on *request* only. Right, the mapping can be done on request. That will be cleaner. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Friday 23 August 2013 04:14 AM, Sekhar Nori wrote: > On Friday 23 August 2013 12:23 PM, Sricharan R wrote: >> 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 = <> 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. > > Right, so in my suggestion there is nothing like a "default mapping" and > entire 160 GIC interrupt number space is up for grabs. I think this will > be much simpler to write and maintain. > > If you really want to maintain default mapping as far as possible, you > can do two passes on the crossbar interrupt numbers requested. Once to > assign the default map - for numbers less that 160 - and then look at > the free GIC interrupt slots and use those for numbers greater than 160. > The whole point we are moving to domain is not have any default mapping(connection done) at DT level. Rather DT only specifies the peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). This will be the driver input as a IRQ line from DT. The cross-bar driver needs to map any of the free list available on *request* only. Of-course you have 320 inputs out of which only 160 can be mapped and once you run out of it, you just return error on request IRQ. That way there is no contention. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Friday 23 August 2013 12:23 PM, Sricharan R wrote: > 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 = <> 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. Right, so in my suggestion there is nothing like a "default mapping" and entire 160 GIC interrupt number space is up for grabs. I think this will be much simpler to write and maintain. If you really want to maintain default mapping as far as possible, you can do two passes on the crossbar interrupt numbers requested. Once to assign the default map - for numbers less that 160 - and then look at the free GIC interrupt slots and use those for numbers greater than 160. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
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 = <> 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
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 = <> 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. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
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. > > This should be ok right ? yeah, sounds ok. > > Regards, > Sricharan > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
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. This should be ok right ? Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
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. This should be ok right ? Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
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. This should be ok right ? yeah, sounds ok. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
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. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
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-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Friday 23 August 2013 12:23 PM, Sricharan R wrote: 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. Right, so in my suggestion there is nothing like a default mapping and entire 160 GIC interrupt number space is up for grabs. I think this will be much simpler to write and maintain. If you really want to maintain default mapping as far as possible, you can do two passes on the crossbar interrupt numbers requested. Once to assign the default map - for numbers less that 160 - and then look at the free GIC interrupt slots and use those for numbers greater than 160. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Friday 23 August 2013 04:14 AM, Sekhar Nori wrote: On Friday 23 August 2013 12:23 PM, Sricharan R wrote: 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. Right, so in my suggestion there is nothing like a default mapping and entire 160 GIC interrupt number space is up for grabs. I think this will be much simpler to write and maintain. If you really want to maintain default mapping as far as possible, you can do two passes on the crossbar interrupt numbers requested. Once to assign the default map - for numbers less that 160 - and then look at the free GIC interrupt slots and use those for numbers greater than 160. The whole point we are moving to domain is not have any default mapping(connection done) at DT level. Rather DT only specifies the peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). This will be the driver input as a IRQ line from DT. The cross-bar driver needs to map any of the free list available on *request* only. Of-course you have 320 inputs out of which only 160 can be mapped and once you run out of it, you just return error on request IRQ. That way there is no contention. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On 8/23/2013 7:08 PM, Santosh Shilimkar wrote: On Friday 23 August 2013 04:14 AM, Sekhar Nori wrote: On Friday 23 August 2013 12:23 PM, Sricharan R wrote: 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. Right, so in my suggestion there is nothing like a default mapping and entire 160 GIC interrupt number space is up for grabs. I think this will be much simpler to write and maintain. If you really want to maintain default mapping as far as possible, you can do two passes on the crossbar interrupt numbers requested. Once to assign the default map - for numbers less that 160 - and then look at the free GIC interrupt slots and use those for numbers greater than 160. The whole point we are moving to domain is not have any default mapping(connection done) at DT level. Rather DT only specifies the peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). This will be the driver input as a IRQ line from DT. The cross-bar driver needs to map any of the free list available on *request* only. Right, the mapping can be done on request. That will be cleaner. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Fri, Aug 23, 2013 at 6:28 PM, Sekhar Nori nsek...@ti.com wrote: On 8/23/2013 7:08 PM, Santosh Shilimkar wrote: The whole point we are moving to domain is not have any default mapping(connection done) at DT level. Rather DT only specifies the peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). This will be the driver input as a IRQ line from DT. The cross-bar driver needs to map any of the free list available on *request* only. Right, the mapping can be done on request. That will be cleaner. I like where this design is going now :-) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Friday 23 August 2013 03:06 PM, Linus Walleij wrote: On Fri, Aug 23, 2013 at 6:28 PM, Sekhar Nori nsek...@ti.com wrote: On 8/23/2013 7:08 PM, Santosh Shilimkar wrote: The whole point we are moving to domain is not have any default mapping(connection done) at DT level. Rather DT only specifies the peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). This will be the driver input as a IRQ line from DT. The cross-bar driver needs to map any of the free list available on *request* only. Right, the mapping can be done on request. That will be cleaner. I like where this design is going now :-) Sure and thanks for good discussion. Debates are useful regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 22 August 2013 07:33 AM, Sricharan R wrote: > Hi Linus, > > On Thursday 22 August 2013 02:40 AM, Linus Walleij wrote: >> On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar >> wrote: >>> On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: >> (...) Sorry I don't understand what thread that is... can you point me there? My previous statement on this issue what this: http://marc.info/?l=linux-kernel=137442541628641=2 >> (...) > I don't see how you can make this happen with an irqchip > infrastructure. I think my post above describes this. >>> Sorry for being dumb but I don't think cascaded irqchip examples >>> like GPIO and cross-bars are same. If you take an example of >>> GPIO irqchip, it always have a physical connection even if it >>> is 1 IRQ line for (32 logical/sparse IRQs). That goes with >>> other MFD examples too. >>> >>> So may be I am still missing something in your proposal. >> Why does it matter if it is a GPIO or MFD or whatever? >> The point is that the IRQ line passes thru something else, >> and this we model as an irqdomain. >> >> Anyway here is a silicon cascaded IRQ chip: >> arch/arm/mach-versatile/core.c >> See versatile_init_irq(): >> >> __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np); >> (...) >> fpga_irq_init(VA_SIC_BASE, "SIC", IRQ_SIC_START, >> IRQ_VICSOURCE31, PIC_VALID, np); >> >> The VIC in the versatile has the SIC cascaded from one of >> its IRQ lines. Both the VIC and SIC (fpga IRQ) are >> using irqdomains so the SIC spawns a child irqdomain >> from IRQ 31 (last IRQ) of the VIC. > Ok, this is a typical example of irqchip cascaded. >> The difference with a crossbar is that it can software-config >> which IRQ goes where, and does not have a callback >> to clear interrupts or anything like that, it just passes them >> thru. But it is best modeled as an irqdomain IMO. > We can model crossbar as irqchip and gic as its interrupt parent > and peripherals to have crossbar as interrupt-parent. > > peripherals will do request_irq(crossbar_number) > | > | > crossbar_unmask() > | > | > maps crossbar number<-> to interrupt number and > calls request_irq(int_no, crossbar_handler,..) > > > crossbar_handler(interrupt number) > | > | > get crossbar number from interrupt number > | > | > handle_irq(crossbar_domain(crossbar number)) > > > So this means a extra dummy handler. Its not optimal to go through the dummy call stack on fast path but considering its not going to eat too many instructions, its fine to have dummy handler. We should try this out. > Also the concern is by modelling it as irqchip, we will have > to find a different solution for DMA crossbar. > DMAEngine has a notion of logical channel and that was actually used in the EDMA support series by Matt [1] We can do something similar to handle that scenario. [1] https://lkml.org/lkml/2013/6/18/56 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
Hi Linus, On Thursday 22 August 2013 02:40 AM, Linus Walleij wrote: > On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar > wrote: >> On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: > (...) >>> Sorry I don't understand what thread that is... can you point me there? >>> My previous statement on this issue what this: >>> http://marc.info/?l=linux-kernel=137442541628641=2 > (...) I don't see how you can make this happen with an irqchip infrastructure. >>> I think my post above describes this. >>> >> Sorry for being dumb but I don't think cascaded irqchip examples >> like GPIO and cross-bars are same. If you take an example of >> GPIO irqchip, it always have a physical connection even if it >> is 1 IRQ line for (32 logical/sparse IRQs). That goes with >> other MFD examples too. >> >> So may be I am still missing something in your proposal. > Why does it matter if it is a GPIO or MFD or whatever? > The point is that the IRQ line passes thru something else, > and this we model as an irqdomain. > > Anyway here is a silicon cascaded IRQ chip: > arch/arm/mach-versatile/core.c > See versatile_init_irq(): > > __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np); > (...) > fpga_irq_init(VA_SIC_BASE, "SIC", IRQ_SIC_START, > IRQ_VICSOURCE31, PIC_VALID, np); > > The VIC in the versatile has the SIC cascaded from one of > its IRQ lines. Both the VIC and SIC (fpga IRQ) are > using irqdomains so the SIC spawns a child irqdomain > from IRQ 31 (last IRQ) of the VIC. Ok, this is a typical example of irqchip cascaded. > The difference with a crossbar is that it can software-config > which IRQ goes where, and does not have a callback > to clear interrupts or anything like that, it just passes them > thru. But it is best modeled as an irqdomain IMO. We can model crossbar as irqchip and gic as its interrupt parent and peripherals to have crossbar as interrupt-parent. peripherals will do request_irq(crossbar_number) | | crossbar_unmask() | | maps crossbar number<-> to interrupt number and calls request_irq(int_no, crossbar_handler,..) crossbar_handler(interrupt number) | | get crossbar number from interrupt number | | handle_irq(crossbar_domain(crossbar number)) So this means a extra dummy handler. Also the concern is by modelling it as irqchip, we will have to find a different solution for DMA crossbar. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
Hi Linus, On Thursday 22 August 2013 02:40 AM, Linus Walleij wrote: On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: (...) Sorry I don't understand what thread that is... can you point me there? My previous statement on this issue what this: http://marc.info/?l=linux-kernelm=137442541628641w=2 (...) I don't see how you can make this happen with an irqchip infrastructure. I think my post above describes this. Sorry for being dumb but I don't think cascaded irqchip examples like GPIO and cross-bars are same. If you take an example of GPIO irqchip, it always have a physical connection even if it is 1 IRQ line for (32 logical/sparse IRQs). That goes with other MFD examples too. So may be I am still missing something in your proposal. Why does it matter if it is a GPIO or MFD or whatever? The point is that the IRQ line passes thru something else, and this we model as an irqdomain. Anyway here is a silicon cascaded IRQ chip: arch/arm/mach-versatile/core.c See versatile_init_irq(): __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np); (...) fpga_irq_init(VA_SIC_BASE, SIC, IRQ_SIC_START, IRQ_VICSOURCE31, PIC_VALID, np); The VIC in the versatile has the SIC cascaded from one of its IRQ lines. Both the VIC and SIC (fpga IRQ) are using irqdomains so the SIC spawns a child irqdomain from IRQ 31 (last IRQ) of the VIC. Ok, this is a typical example of irqchip cascaded. The difference with a crossbar is that it can software-config which IRQ goes where, and does not have a callback to clear interrupts or anything like that, it just passes them thru. But it is best modeled as an irqdomain IMO. We can model crossbar as irqchip and gic as its interrupt parent and peripherals to have crossbar as interrupt-parent. peripherals will do request_irq(crossbar_number) | | crossbar_unmask() | | maps crossbar number- to interrupt number and calls request_irq(int_no, crossbar_handler,..) crossbar_handler(interrupt number) | | get crossbar number from interrupt number | | handle_irq(crossbar_domain(crossbar number)) So this means a extra dummy handler. Also the concern is by modelling it as irqchip, we will have to find a different solution for DMA crossbar. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 22 August 2013 07:33 AM, Sricharan R wrote: Hi Linus, On Thursday 22 August 2013 02:40 AM, Linus Walleij wrote: On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: (...) Sorry I don't understand what thread that is... can you point me there? My previous statement on this issue what this: http://marc.info/?l=linux-kernelm=137442541628641w=2 (...) I don't see how you can make this happen with an irqchip infrastructure. I think my post above describes this. Sorry for being dumb but I don't think cascaded irqchip examples like GPIO and cross-bars are same. If you take an example of GPIO irqchip, it always have a physical connection even if it is 1 IRQ line for (32 logical/sparse IRQs). That goes with other MFD examples too. So may be I am still missing something in your proposal. Why does it matter if it is a GPIO or MFD or whatever? The point is that the IRQ line passes thru something else, and this we model as an irqdomain. Anyway here is a silicon cascaded IRQ chip: arch/arm/mach-versatile/core.c See versatile_init_irq(): __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np); (...) fpga_irq_init(VA_SIC_BASE, SIC, IRQ_SIC_START, IRQ_VICSOURCE31, PIC_VALID, np); The VIC in the versatile has the SIC cascaded from one of its IRQ lines. Both the VIC and SIC (fpga IRQ) are using irqdomains so the SIC spawns a child irqdomain from IRQ 31 (last IRQ) of the VIC. Ok, this is a typical example of irqchip cascaded. The difference with a crossbar is that it can software-config which IRQ goes where, and does not have a callback to clear interrupts or anything like that, it just passes them thru. But it is best modeled as an irqdomain IMO. We can model crossbar as irqchip and gic as its interrupt parent and peripherals to have crossbar as interrupt-parent. peripherals will do request_irq(crossbar_number) | | crossbar_unmask() | | maps crossbar number- to interrupt number and calls request_irq(int_no, crossbar_handler,..) crossbar_handler(interrupt number) | | get crossbar number from interrupt number | | handle_irq(crossbar_domain(crossbar number)) So this means a extra dummy handler. Its not optimal to go through the dummy call stack on fast path but considering its not going to eat too many instructions, its fine to have dummy handler. We should try this out. Also the concern is by modelling it as irqchip, we will have to find a different solution for DMA crossbar. DMAEngine has a notion of logical channel and that was actually used in the EDMA support series by Matt [1] We can do something similar to handle that scenario. [1] https://lkml.org/lkml/2013/6/18/56 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar wrote: > On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: (...) >> Sorry I don't understand what thread that is... can you point me there? >> My previous statement on this issue what this: >> http://marc.info/?l=linux-kernel=137442541628641=2 (...) >>> I don't see how you can make this happen with an irqchip >>> infrastructure. >> >> I think my post above describes this. >> > Sorry for being dumb but I don't think cascaded irqchip examples > like GPIO and cross-bars are same. If you take an example of > GPIO irqchip, it always have a physical connection even if it > is 1 IRQ line for (32 logical/sparse IRQs). That goes with > other MFD examples too. > > So may be I am still missing something in your proposal. Why does it matter if it is a GPIO or MFD or whatever? The point is that the IRQ line passes thru something else, and this we model as an irqdomain. Anyway here is a silicon cascaded IRQ chip: arch/arm/mach-versatile/core.c See versatile_init_irq(): __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np); (...) fpga_irq_init(VA_SIC_BASE, "SIC", IRQ_SIC_START, IRQ_VICSOURCE31, PIC_VALID, np); The VIC in the versatile has the SIC cascaded from one of its IRQ lines. Both the VIC and SIC (fpga IRQ) are using irqdomains so the SIC spawns a child irqdomain from IRQ 31 (last IRQ) of the VIC. The difference with a crossbar is that it can software-config which IRQ goes where, and does not have a callback to clear interrupts or anything like that, it just passes them thru. But it is best modeled as an irqdomain IMO. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: (...) Sorry I don't understand what thread that is... can you point me there? My previous statement on this issue what this: http://marc.info/?l=linux-kernelm=137442541628641w=2 (...) I don't see how you can make this happen with an irqchip infrastructure. I think my post above describes this. Sorry for being dumb but I don't think cascaded irqchip examples like GPIO and cross-bars are same. If you take an example of GPIO irqchip, it always have a physical connection even if it is 1 IRQ line for (32 logical/sparse IRQs). That goes with other MFD examples too. So may be I am still missing something in your proposal. Why does it matter if it is a GPIO or MFD or whatever? The point is that the IRQ line passes thru something else, and this we model as an irqdomain. Anyway here is a silicon cascaded IRQ chip: arch/arm/mach-versatile/core.c See versatile_init_irq(): __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np); (...) fpga_irq_init(VA_SIC_BASE, SIC, IRQ_SIC_START, IRQ_VICSOURCE31, PIC_VALID, np); The VIC in the versatile has the SIC cascaded from one of its IRQ lines. Both the VIC and SIC (fpga IRQ) are using irqdomains so the SIC spawns a child irqdomain from IRQ 31 (last IRQ) of the VIC. The difference with a crossbar is that it can software-config which IRQ goes where, and does not have a callback to clear interrupts or anything like that, it just passes them thru. But it is best modeled as an irqdomain IMO. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: > On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar > wrote: >> On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: >>> On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R wrote: >>> Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. >>> >>> I think it is better to use irqchip. >>> >> Did you happen to read the thread why irqchip is in-appropriate >> for such an IP. > > Sorry I don't understand what thread that is... can you point me there? > My previous statement on this issue what this: > http://marc.info/?l=linux-kernel=137442541628641=2 > It was discussed in couple of threads but the main point was the need of a link needed for the irqchip. >> As I said earlier, an IRQ-chip always need a >> real IRQ link (even for the chained one) to the primary irqchip. >> >> This IP is just dummy IP makes the connections for the primary >> irqchip(read GIC). And its use only limited to make the >> connection between the peripheral IRQ event to the GIC IRQ line. >> >> I don't see how you can make this happen with an irqchip >> infrastructure. > > I think my post above describes this. > Sorry for being dumb but I don't think cascaded irqchip examples like GPIO and cross-bars are same. If you take an example of GPIO irqchip, it always have a physical connection even if it is 1 IRQ line for (32 logical/sparse IRQs). That goes with other MFD examples too. So may be I am still missing something in your proposal. >>> I don't see any way to really abstract this pretty simple crossbar >>> for reuse across subsystems. >>> >> This exactly the reason, i am against idea of over-engineering the >> simple IP whose only job is to make the physical wire connection >> in software where as this is generally done in RTL by default on >> most of the SOCs. > > Well, it was made accessible by software, and if someone has a > usecase that requires this do be done dynamically, i.e. not just > being set up by firmware and never touched, and that use case > is valid, then I guess we need to do something... > > I think it was mentioned in the thread that there is really such > a usecase? > Actually there is no practical usecase but one but one can manufacture it ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar wrote: > On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: >> On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R wrote: >> >>> Initially irqchip was discussed, but we also have a DMA crossbar >>> to map the dma-requests. Since both irq/dma crossbars should be handled, >>> pinctrl was suggested as the appropriate place to handle this. >> >> I think it is better to use irqchip. >> > Did you happen to read the thread why irqchip is in-appropriate > for such an IP. Sorry I don't understand what thread that is... can you point me there? My previous statement on this issue what this: http://marc.info/?l=linux-kernel=137442541628641=2 > As I said earlier, an IRQ-chip always need a > real IRQ link (even for the chained one) to the primary irqchip. > > This IP is just dummy IP makes the connections for the primary > irqchip(read GIC). And its use only limited to make the > connection between the peripheral IRQ event to the GIC IRQ line. > > I don't see how you can make this happen with an irqchip > infrastructure. I think my post above describes this. >> I don't see any way to really abstract this pretty simple crossbar >> for reuse across subsystems. >> > This exactly the reason, i am against idea of over-engineering the > simple IP whose only job is to make the physical wire connection > in software where as this is generally done in RTL by default on > most of the SOCs. Well, it was made accessible by software, and if someone has a usecase that requires this do be done dynamically, i.e. not just being set up by firmware and never touched, and that use case is valid, then I guess we need to do something... I think it was mentioned in the thread that there is really such a usecase? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: > On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R wrote: > >> Initially irqchip was discussed, but we also have a DMA crossbar >> to map the dma-requests. Since both irq/dma crossbars should be handled, >> pinctrl was suggested as the appropriate place to handle this. > > I think it is better to use irqchip. > Did you happen to read the thread why irqchip is in-appropriate for such an IP. As I said earlier, an IRQ-chip always need a real IRQ link (even for the chained one) to the primary irqchip. This IP is just dummy IP makes the connections for the primary irqchip(read GIC). And its use only limited to make the connection between the peripheral IRQ event to the GIC IRQ line. I don't see how you can make this happen with an irqchip infrastructure. If you have a idea to make that work, we can go with that since for time being we can ignore the DMA event related need of this IP. > For DMA there is already an arbiter mechanism for arbitration of > virtual channels over physical channels, this is not much different, > the DMA might need some different tweaking but should be solved > in that subsystem I think. > Sure. The IP won't be limited to DMA and IRQ lines but any other events like gpio etc in future. > I don't see any way to really abstract this pretty simple crossbar > for reuse across subsystems. > This exactly the reason, i am against idea of over-engineering the simple IP whose only job is to make the physical wire connection in software where as this is generally done in RTL by default on most of the SOCs. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R wrote: > Initially irqchip was discussed, but we also have a DMA crossbar > to map the dma-requests. Since both irq/dma crossbars should be handled, > pinctrl was suggested as the appropriate place to handle this. I think it is better to use irqchip. For DMA there is already an arbiter mechanism for arbitration of virtual channels over physical channels, this is not much different, the DMA might need some different tweaking but should be solved in that subsystem I think. I don't see any way to really abstract this pretty simple crossbar for reuse across subsystems. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R r.sricha...@ti.com wrote: Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. I think it is better to use irqchip. For DMA there is already an arbiter mechanism for arbitration of virtual channels over physical channels, this is not much different, the DMA might need some different tweaking but should be solved in that subsystem I think. I don't see any way to really abstract this pretty simple crossbar for reuse across subsystems. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R r.sricha...@ti.com wrote: Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. I think it is better to use irqchip. Did you happen to read the thread why irqchip is in-appropriate for such an IP. As I said earlier, an IRQ-chip always need a real IRQ link (even for the chained one) to the primary irqchip. This IP is just dummy IP makes the connections for the primary irqchip(read GIC). And its use only limited to make the connection between the peripheral IRQ event to the GIC IRQ line. I don't see how you can make this happen with an irqchip infrastructure. If you have a idea to make that work, we can go with that since for time being we can ignore the DMA event related need of this IP. For DMA there is already an arbiter mechanism for arbitration of virtual channels over physical channels, this is not much different, the DMA might need some different tweaking but should be solved in that subsystem I think. Sure. The IP won't be limited to DMA and IRQ lines but any other events like gpio etc in future. I don't see any way to really abstract this pretty simple crossbar for reuse across subsystems. This exactly the reason, i am against idea of over-engineering the simple IP whose only job is to make the physical wire connection in software where as this is generally done in RTL by default on most of the SOCs. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R r.sricha...@ti.com wrote: Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. I think it is better to use irqchip. Did you happen to read the thread why irqchip is in-appropriate for such an IP. Sorry I don't understand what thread that is... can you point me there? My previous statement on this issue what this: http://marc.info/?l=linux-kernelm=137442541628641w=2 As I said earlier, an IRQ-chip always need a real IRQ link (even for the chained one) to the primary irqchip. This IP is just dummy IP makes the connections for the primary irqchip(read GIC). And its use only limited to make the connection between the peripheral IRQ event to the GIC IRQ line. I don't see how you can make this happen with an irqchip infrastructure. I think my post above describes this. I don't see any way to really abstract this pretty simple crossbar for reuse across subsystems. This exactly the reason, i am against idea of over-engineering the simple IP whose only job is to make the physical wire connection in software where as this is generally done in RTL by default on most of the SOCs. Well, it was made accessible by software, and if someone has a usecase that requires this do be done dynamically, i.e. not just being set up by firmware and never touched, and that use case is valid, then I guess we need to do something... I think it was mentioned in the thread that there is really such a usecase? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R r.sricha...@ti.com wrote: Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. I think it is better to use irqchip. Did you happen to read the thread why irqchip is in-appropriate for such an IP. Sorry I don't understand what thread that is... can you point me there? My previous statement on this issue what this: http://marc.info/?l=linux-kernelm=137442541628641w=2 It was discussed in couple of threads but the main point was the need of a link needed for the irqchip. As I said earlier, an IRQ-chip always need a real IRQ link (even for the chained one) to the primary irqchip. This IP is just dummy IP makes the connections for the primary irqchip(read GIC). And its use only limited to make the connection between the peripheral IRQ event to the GIC IRQ line. I don't see how you can make this happen with an irqchip infrastructure. I think my post above describes this. Sorry for being dumb but I don't think cascaded irqchip examples like GPIO and cross-bars are same. If you take an example of GPIO irqchip, it always have a physical connection even if it is 1 IRQ line for (32 logical/sparse IRQs). That goes with other MFD examples too. So may be I am still missing something in your proposal. I don't see any way to really abstract this pretty simple crossbar for reuse across subsystems. This exactly the reason, i am against idea of over-engineering the simple IP whose only job is to make the physical wire connection in software where as this is generally done in RTL by default on most of the SOCs. Well, it was made accessible by software, and if someone has a usecase that requires this do be done dynamically, i.e. not just being set up by firmware and never touched, and that use case is valid, then I guess we need to do something... I think it was mentioned in the thread that there is really such a usecase? Actually there is no practical usecase but one but one can manufacture it ;-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
* Santosh Shilimkar [130813 06:35]: > On Tuesday 13 August 2013 04:10 AM, Tony Lindgren wrote: > > * Santosh Shilimkar [130724 12:06]: > >> On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: > >>> On 07/24/2013 01:43 PM, Sricharan R wrote: > On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: > > On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: > >> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: > >>> That said, maybe a intermediate pinctrl approach might be more > >>> pragmatic and less theoretically flexible. > >>> an option might be to "statically allocate" default number of > >>> interrupts to a domain - example: > >>> * GIC IRQ 72->78 allotted to UARTs > >>> * pinctrl mapping provided for those but only 6 can be used (rest are > >>> marked status="disabled" as default) at any given time (choice of > >>> pinctrl option determines GIC interrupt line to use) > >>> * All modules will have a pinctrl definition to have a mapping - to > >>> avoid bootloader overriding default cross bar setting in ways > >>> un-expected by kernel. > >>> > >>> Does that sound fair trade off? > >> This sounds better. That way we can get all the devices in the DT at > >> least. > > > > Fair enough - if Linus and Tony are still ok with this approach to the > > problem, seeing a patch series with the effect would be beneficial. > > > Ok, i will use this idea of certain number interrupts to groups. > Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device > inputs contending for it. > 1:2 and fully arbitrary. But will we be really exhausting them ? > > >>> Depends on how we allocate :). The default arbitary allocation can be > >>> made more logical in your series ofcourse :). > >>> > >> I would just most logical peripherals rather than providing every single > >> IP connected to cross bar. Otherwise we will end up wth hwmod like > >> scenario where now started removing the unused stuff because of > >> maintenance and loc issues ;-) > > > > Sorry for the delay on this, I think the best way to set this up > > is as a separate drivers/irqchip controller. Then just map the > > configured interrupts for the board with interrupt-map and > > interrupt-map-mask binding. No need to stuff all the SoC specific > > maps to the .dts, just the ones used for the board. > > > Interrupt mask/unmask, really ? Thats like abusing those irqchip > hooks completely. Your point is to just setup events which we need > and thats what I also suggested. But the use of irqchip hooks is > certainly not the right idea since they are for masking/unmasking > interrupts in running system and not for joining the interrupt > line which needs to happen once during probe. Well if it's an interrupt controller. Doing a chained IRQ pinctrl driver might work too. But yes, the idea with interrupt-map was to only map what's used rather than have data for each SoC. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
* Santosh Shilimkar santosh.shilim...@ti.com [130813 06:35]: On Tuesday 13 August 2013 04:10 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130724 12:06]: On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. Interrupt mask/unmask, really ? Thats like abusing those irqchip hooks completely. Your point is to just setup events which we need and thats what I also suggested. But the use of irqchip hooks is certainly not the right idea since they are for masking/unmasking interrupts in running system and not for joining the interrupt line which needs to happen once during probe. Well if it's an interrupt controller. Doing a chained IRQ pinctrl driver might work too. But yes, the idea with interrupt-map was to only map what's used rather than have data for each SoC. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Tuesday 13 August 2013 05:56 AM, Sricharan R wrote: > Hi Tony, > > On Tuesday 13 August 2013 01:40 PM, Tony Lindgren wrote: >> * Santosh Shilimkar [130724 12:06]: >>> On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: > On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: >> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: >>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to "statically allocate" default number of interrupts to a domain - example: * GIC IRQ 72->78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status="disabled" as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? >>> This sounds better. That way we can get all the devices in the DT at >>> least. >> Fair enough - if Linus and Tony are still ok with this approach to the >> problem, seeing a patch series with the effect would be beneficial. >> > Ok, i will use this idea of certain number interrupts to groups. > Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device > inputs contending for it. > 1:2 and fully arbitrary. But will we be really exhausting them ? > Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). >>> I would just most logical peripherals rather than providing every single >>> IP connected to cross bar. Otherwise we will end up wth hwmod like >>> scenario where now started removing the unused stuff because of >>> maintenance and loc issues ;-) >> Sorry for the delay on this, I think the best way to set this up >> is as a separate drivers/irqchip controller. Then just map the >> configured interrupts for the board with interrupt-map and >> interrupt-map-mask binding. No need to stuff all the SoC specific >> maps to the .dts, just the ones used for the board. >> >> Regards, >> >> Tony >> > Initially irqchip was discussed, but we also have a DMA crossbar > to map the dma-requests. Since both irq/dma crossbars should be handled, > pinctrl was suggested as the appropriate place to handle this. > I replied on other thread. I guess Tony's point is to setup only required events for a board rather than setting up every possible event. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Tuesday 13 August 2013 04:10 AM, Tony Lindgren wrote: > * Santosh Shilimkar [130724 12:06]: >> On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: >>> On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: > On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: >> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: >>> That said, maybe a intermediate pinctrl approach might be more >>> pragmatic and less theoretically flexible. >>> an option might be to "statically allocate" default number of >>> interrupts to a domain - example: >>> * GIC IRQ 72->78 allotted to UARTs >>> * pinctrl mapping provided for those but only 6 can be used (rest are >>> marked status="disabled" as default) at any given time (choice of >>> pinctrl option determines GIC interrupt line to use) >>> * All modules will have a pinctrl definition to have a mapping - to >>> avoid bootloader overriding default cross bar setting in ways >>> un-expected by kernel. >>> >>> Does that sound fair trade off? >> This sounds better. That way we can get all the devices in the DT at >> least. > > Fair enough - if Linus and Tony are still ok with this approach to the > problem, seeing a patch series with the effect would be beneficial. > Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? >>> Depends on how we allocate :). The default arbitary allocation can be made >>> more logical in your series ofcourse :). >>> >> I would just most logical peripherals rather than providing every single >> IP connected to cross bar. Otherwise we will end up wth hwmod like >> scenario where now started removing the unused stuff because of >> maintenance and loc issues ;-) > > Sorry for the delay on this, I think the best way to set this up > is as a separate drivers/irqchip controller. Then just map the > configured interrupts for the board with interrupt-map and > interrupt-map-mask binding. No need to stuff all the SoC specific > maps to the .dts, just the ones used for the board. > Interrupt mask/unmask, really ? Thats like abusing those irqchip hooks completely. Your point is to just setup events which we need and thats what I also suggested. But the use of irqchip hooks is certainly not the right idea since they are for masking/unmasking interrupts in running system and not for joining the interrupt line which needs to happen once during probe. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
Hi Tony, On Tuesday 13 August 2013 01:40 PM, Tony Lindgren wrote: > * Santosh Shilimkar [130724 12:06]: >> On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: >>> On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: > On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: >> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: >>> That said, maybe a intermediate pinctrl approach might be more >>> pragmatic and less theoretically flexible. >>> an option might be to "statically allocate" default number of >>> interrupts to a domain - example: >>> * GIC IRQ 72->78 allotted to UARTs >>> * pinctrl mapping provided for those but only 6 can be used (rest are >>> marked status="disabled" as default) at any given time (choice of >>> pinctrl option determines GIC interrupt line to use) >>> * All modules will have a pinctrl definition to have a mapping - to >>> avoid bootloader overriding default cross bar setting in ways >>> un-expected by kernel. >>> >>> Does that sound fair trade off? >> This sounds better. That way we can get all the devices in the DT at >> least. > Fair enough - if Linus and Tony are still ok with this approach to the > problem, seeing a patch series with the effect would be beneficial. > Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? >>> Depends on how we allocate :). The default arbitary allocation can be made >>> more logical in your series ofcourse :). >>> >> I would just most logical peripherals rather than providing every single >> IP connected to cross bar. Otherwise we will end up wth hwmod like >> scenario where now started removing the unused stuff because of >> maintenance and loc issues ;-) > Sorry for the delay on this, I think the best way to set this up > is as a separate drivers/irqchip controller. Then just map the > configured interrupts for the board with interrupt-map and > interrupt-map-mask binding. No need to stuff all the SoC specific > maps to the .dts, just the ones used for the board. > > Regards, > > Tony > Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
* Santosh Shilimkar [130724 12:06]: > On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: > > On 07/24/2013 01:43 PM, Sricharan R wrote: > >> On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: > >>> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: > On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: > > That said, maybe a intermediate pinctrl approach might be more > > pragmatic and less theoretically flexible. > > an option might be to "statically allocate" default number of > > interrupts to a domain - example: > > * GIC IRQ 72->78 allotted to UARTs > > * pinctrl mapping provided for those but only 6 can be used (rest are > > marked status="disabled" as default) at any given time (choice of > > pinctrl option determines GIC interrupt line to use) > > * All modules will have a pinctrl definition to have a mapping - to > > avoid bootloader overriding default cross bar setting in ways > > un-expected by kernel. > > > > Does that sound fair trade off? > This sounds better. That way we can get all the devices in the DT at > least. > >>> > >>> Fair enough - if Linus and Tony are still ok with this approach to the > >>> problem, seeing a patch series with the effect would be beneficial. > >>> > >> Ok, i will use this idea of certain number interrupts to groups. > >> Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device > >> inputs contending for it. > >> 1:2 and fully arbitrary. But will we be really exhausting them ? > >> > > Depends on how we allocate :). The default arbitary allocation can be made > > more logical in your series ofcourse :). > > > I would just most logical peripherals rather than providing every single > IP connected to cross bar. Otherwise we will end up wth hwmod like > scenario where now started removing the unused stuff because of > maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
* Santosh Shilimkar santosh.shilim...@ti.com [130724 12:06]: On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
Hi Tony, On Tuesday 13 August 2013 01:40 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130724 12:06]: On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. Regards, Tony Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Tuesday 13 August 2013 04:10 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130724 12:06]: On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. Interrupt mask/unmask, really ? Thats like abusing those irqchip hooks completely. Your point is to just setup events which we need and thats what I also suggested. But the use of irqchip hooks is certainly not the right idea since they are for masking/unmasking interrupts in running system and not for joining the interrupt line which needs to happen once during probe. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Tuesday 13 August 2013 05:56 AM, Sricharan R wrote: Hi Tony, On Tuesday 13 August 2013 01:40 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130724 12:06]: On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. Regards, Tony Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. I replied on other thread. I guess Tony's point is to setup only required events for a board rather than setting up every possible event. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: > On 07/24/2013 01:43 PM, Sricharan R wrote: >> On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: >>> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: > That said, maybe a intermediate pinctrl approach might be more pragmatic > and less theoretically flexible. > an option might be to "statically allocate" default number of interrupts > to a domain - example: > * GIC IRQ 72->78 allotted to UARTs > * pinctrl mapping provided for those but only 6 can be used (rest are > marked status="disabled" as default) at any given time (choice of pinctrl > option determines GIC interrupt line to use) > * All modules will have a pinctrl definition to have a mapping - to avoid > bootloader overriding default cross bar setting in ways un-expected by > kernel. > > Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. >>> >>> Fair enough - if Linus and Tony are still ok with this approach to the >>> problem, seeing a patch series with the effect would be beneficial. >>> >> Ok, i will use this idea of certain number interrupts to groups. >> Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device >> inputs contending for it. >> 1:2 and fully arbitrary. But will we be really exhausting them ? >> > Depends on how we allocate :). The default arbitary allocation can be made > more logical in your series ofcourse :). > I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to "statically allocate" default number of interrupts to a domain - example: * GIC IRQ 72->78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status="disabled" as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: > On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: >> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: >>> That said, maybe a intermediate pinctrl approach might be more pragmatic >>> and less theoretically flexible. >>> an option might be to "statically allocate" default number of interrupts to >>> a domain - example: >>> * GIC IRQ 72->78 allotted to UARTs >>> * pinctrl mapping provided for those but only 6 can be used (rest are >>> marked status="disabled" as default) at any given time (choice of pinctrl >>> option determines GIC interrupt line to use) >>> * All modules will have a pinctrl definition to have a mapping - to avoid >>> bootloader overriding default cross bar setting in ways un-expected by >>> kernel. >>> >>> Does that sound fair trade off? >> This sounds better. That way we can get all the devices in the DT at least. > > Fair enough - if Linus and Tony are still ok with this approach to the > problem, seeing a patch series with the effect would be beneficial. > Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to "statically allocate" default number of interrupts to a domain - example: * GIC IRQ 72->78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status="disabled" as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: > On 07/22/2013 11:23 AM, Santosh Shilimkar wrote: >> To summaries it again, what I understood from Sricharan's proposal, >> >> - Setup all the routing at cross-bar probe so that kernel continue to >> work like normal IRQ controller with cross-bar scope vanishes once >> the routing is done. Cross-bar does this before any of the devices >> are created. >> - Something similar needs to happen for DMA lines as well or for any >> other event routing in future. >> - Cross-bar callbacks for device drivers for error paths. >> (Sricharan, you have to drop these because it doesn't bring any >> functionality and rather can create a side effects of drivers >> getting polluted.) > Ack. > >> >> The concern raised on above was instead of fixing the routing at DT >> statically, doing at the driver probes where the loop-up for IRQ or DMA >> lines should happen in background transparently on drivers call of >> request_irq/request_dma_channel etc with cross-bar number as >> an input to it. Though it will be nice to have >> such feature, it doesn't bring anything special and brings the >> notion of these APIs which expect that you know what IRQ and DMA >> lines you want while calling these. > Unfortunately, we do have a constraint without allocating dynamic IRQs - what > IP instances should hwmod and dts contain? > > If we go with current series of patches[1] [2] for DRA7 dts which assumes > default mapping, hence, uart7-10, GPTimers12-16 dont have default irq - hence > they dont exist in dts etc. > > How would we like to support those with pinctrl approach? > The whole reason the cross-bar being there because all the peripherals IRQs can not me routed to the IRQ controller. So You pick up a configuration would like to support and stick to it. It will be good to specify all the peripheral devices but tsome of them might not have the IRQ/DMA lines associated with them because of limited slots on IRQ/DMA controller. >> >> Note that mux inputs are pretty much fixed. Its his connection >> to IRQ controller or DMA controller is what needs to be programmed. >> So scope is pretty much limited. I felt this requirement is pretty >> similar to pin-mux and hence thought of it as a viable option. >> >> Having said all of above, if there is a better alternative than >> enhanced pin-mux we surely can do that. > We could look at it as a signal mux problem as this thread suggests OR look > at it as interrupt distribution problem (which is how it looks like at the > face of it). Its not interrupt distribution problem but rather setting up the signal routing which otherwise generally hardwired in SOC. Hence the pin-control analogy. Pinmux also lets you set many possible combinations but we pick one for a board design. > That said, maybe a intermediate pinctrl approach might be more pragmatic > andless theoretically flexible. > an option might be to "statically allocate" default number of interrupts to a > domain - example: > * GIC IRQ 72->78 allotted to UARTs > * pinctrl mapping provided for those but only 6 can be used (rest are marked > status="disabled" as default) at any given time (choice of pinctrl option > determines GIC interrupt line to use) > * All modules will have a pinctrl definition to have a mapping - to avoid > bootloader overriding default cross bar setting in ways un-expected by kernel. > > Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On 07/22/2013 11:23 AM, Santosh Shilimkar wrote: To summaries it again, what I understood from Sricharan's proposal, - Setup all the routing at cross-bar probe so that kernel continue to work like normal IRQ controller with cross-bar scope vanishes once the routing is done. Cross-bar does this before any of the devices are created. - Something similar needs to happen for DMA lines as well or for any other event routing in future. - Cross-bar callbacks for device drivers for error paths. (Sricharan, you have to drop these because it doesn't bring any functionality and rather can create a side effects of drivers getting polluted.) Ack. The concern raised on above was instead of fixing the routing at DT statically, doing at the driver probes where the loop-up for IRQ or DMA lines should happen in background transparently on drivers call of request_irq/request_dma_channel etc with cross-bar number as an input to it. Though it will be nice to have such feature, it doesn't bring anything special and brings the notion of these APIs which expect that you know what IRQ and DMA lines you want while calling these. Unfortunately, we do have a constraint without allocating dynamic IRQs - what IP instances should hwmod and dts contain? If we go with current series of patches[1] [2] for DRA7 dts which assumes default mapping, hence, uart7-10, GPTimers12-16 dont have default irq - hence they dont exist in dts etc. How would we like to support those with pinctrl approach? Note that mux inputs are pretty much fixed. Its his connection to IRQ controller or DMA controller is what needs to be programmed. So scope is pretty much limited. I felt this requirement is pretty similar to pin-mux and hence thought of it as a viable option. Having said all of above, if there is a better alternative than enhanced pin-mux we surely can do that. We could look at it as a signal mux problem as this thread suggests OR look at it as interrupt distribution problem (which is how it looks like at the face of it). That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to "statically allocate" default number of interrupts to a domain - example: * GIC IRQ 72->78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status="disabled" as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? [1] http://marc.info/?l=linux-omap=137335524702155=2 [2] http://marc.info/?l=linux-omap=137335522802144=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On 07/22/2013 11:23 AM, Santosh Shilimkar wrote: To summaries it again, what I understood from Sricharan's proposal, - Setup all the routing at cross-bar probe so that kernel continue to work like normal IRQ controller with cross-bar scope vanishes once the routing is done. Cross-bar does this before any of the devices are created. - Something similar needs to happen for DMA lines as well or for any other event routing in future. - Cross-bar callbacks for device drivers for error paths. (Sricharan, you have to drop these because it doesn't bring any functionality and rather can create a side effects of drivers getting polluted.) Ack. The concern raised on above was instead of fixing the routing at DT statically, doing at the driver probes where the loop-up for IRQ or DMA lines should happen in background transparently on drivers call of request_irq/request_dma_channel etc with cross-bar number as an input to it. Though it will be nice to have such feature, it doesn't bring anything special and brings the notion of these APIs which expect that you know what IRQ and DMA lines you want while calling these. Unfortunately, we do have a constraint without allocating dynamic IRQs - what IP instances should hwmod and dts contain? If we go with current series of patches[1] [2] for DRA7 dts which assumes default mapping, hence, uart7-10, GPTimers12-16 dont have default irq - hence they dont exist in dts etc. How would we like to support those with pinctrl approach? Note that mux inputs are pretty much fixed. Its his connection to IRQ controller or DMA controller is what needs to be programmed. So scope is pretty much limited. I felt this requirement is pretty similar to pin-mux and hence thought of it as a viable option. Having said all of above, if there is a better alternative than enhanced pin-mux we surely can do that. We could look at it as a signal mux problem as this thread suggests OR look at it as interrupt distribution problem (which is how it looks like at the face of it). That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? [1] http://marc.info/?l=linux-omapm=137335524702155w=2 [2] http://marc.info/?l=linux-omapm=137335522802144w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: On 07/22/2013 11:23 AM, Santosh Shilimkar wrote: To summaries it again, what I understood from Sricharan's proposal, - Setup all the routing at cross-bar probe so that kernel continue to work like normal IRQ controller with cross-bar scope vanishes once the routing is done. Cross-bar does this before any of the devices are created. - Something similar needs to happen for DMA lines as well or for any other event routing in future. - Cross-bar callbacks for device drivers for error paths. (Sricharan, you have to drop these because it doesn't bring any functionality and rather can create a side effects of drivers getting polluted.) Ack. The concern raised on above was instead of fixing the routing at DT statically, doing at the driver probes where the loop-up for IRQ or DMA lines should happen in background transparently on drivers call of request_irq/request_dma_channel etc with cross-bar number as an input to it. Though it will be nice to have such feature, it doesn't bring anything special and brings the notion of these APIs which expect that you know what IRQ and DMA lines you want while calling these. Unfortunately, we do have a constraint without allocating dynamic IRQs - what IP instances should hwmod and dts contain? If we go with current series of patches[1] [2] for DRA7 dts which assumes default mapping, hence, uart7-10, GPTimers12-16 dont have default irq - hence they dont exist in dts etc. How would we like to support those with pinctrl approach? The whole reason the cross-bar being there because all the peripherals IRQs can not me routed to the IRQ controller. So You pick up a configuration would like to support and stick to it. It will be good to specify all the peripheral devices but tsome of them might not have the IRQ/DMA lines associated with them because of limited slots on IRQ/DMA controller. Note that mux inputs are pretty much fixed. Its his connection to IRQ controller or DMA controller is what needs to be programmed. So scope is pretty much limited. I felt this requirement is pretty similar to pin-mux and hence thought of it as a viable option. Having said all of above, if there is a better alternative than enhanced pin-mux we surely can do that. We could look at it as a signal mux problem as this thread suggests OR look at it as interrupt distribution problem (which is how it looks like at the face of it). Its not interrupt distribution problem but rather setting up the signal routing which otherwise generally hardwired in SOC. Hence the pin-control analogy. Pinmux also lets you set many possible combinations but we pick one for a board design. That said, maybe a intermediate pinctrl approach might be more pragmatic andless theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Monday 22 July 2013 08:20 AM, Sricharan R wrote:
> Hi Linus,
> On Sunday 21 July 2013 10:19 PM, Linus Walleij wrote:
>> On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon wrote:
>>
>>> I carry forward my TI internal objection to this approach:
>> It is actually a very good sign of FOSS-maturity that you as a company
>> take unresolved architectural issues to the community. Kudos!
>>
>>> Lets see what happens as a result of this:
>>>
>>> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
>>> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
>>> uart1: serial@4806a000 {
>>>
>>> + interrupts = <0 72 0x4>;
>>> Assumes that GIC interrupt by default mapping used.
>> So introducing this inbetween the GIC lines and its actual device IRQ
>> lines inevitably means that the GIC three-cell concept is completely
>> ill-devised to handle this.
>>
>> For routing IRQs, I think the proper solution would be to use a
>> cascaded struct irqchip, which in turn contains an irqdomain
>> translation to remux the signal onto the GIC inputs.
>>
>> I.e. the interrupt-controller given to that serial would be the
>> crossbar irqchip, and that in turn will hog and allocate apropriate
>> lines from the gic to it would probably itself list *all* the IRQs
>> of the GIC as "its" IRQs.
>>
>> We already have plenty of cascading irqchips such as GPIO
>> controller providing IRQs, just that they only multiplex on a
>> single GIC line instead of the whole lot.
>>
>> Mock example:
>>
>> intc: interrupt-controller@0 {
>> compatible = "arm,cortex-a9-gic";
>> #interrupt-cells = <3>;
>> #address-cells = <1>;
>> interrupt-controller;
>> reg = ...;
>> };
>>
>> crossbar: crossbar@0 {
>> compatible = "...";
>> interrupt-controller;
>> #interrupt-cells = <1>;
>> interrupt-parent = <>;
>> interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
>> <0 1 IRQ_TYPE_LEVEL_HIGH>,
>> <0 2 IRQ_TYPE_LEVEL_HIGH>,
>>
>> <0 n IRQ_TYPE_LEVEL_HIGH>;
>> };
>>
>> uart0: serial@0 {
>> compatible = "...";
>> interrupt-parent = <>;
>> interrupts = <1234>;
>> };
>>
>> Maybe the interrupts provided from crossbar cannot even be
>> specified by a number, maybe a line name need to be used
>> or so. I don't know the particulars.
>>
>> Whether this as a whole is a good idea, I don't know,
>> but you would have to go about it something like this.
>>
>> What happens if there is no line to mux in a certain IRQ?
> Thanks for this.
> Was thinking of a similar kind of approach with irqchip.
> But then, there was a GAP since crossbar does not have an irq unlike
> other irqchips. But as you said this can be done by setting the crossbar
> to map and receive the GIC interrupts and then direct to devices.
> Only thing is, this is fine for IRQs, and something different has to be done
> for DMA crossbars again. Also when we allocate dynamically here,
> finding out a irq line when there is no free line is a question.
>
> With the other approach of using/extending the pinctrl framework that you
> gave, it is good to handle both irqs/dma. I looked at the other example in
> drivers/dma/amba-pl08x.c and i see that data is getting populated and passed
> from the platform. I initially started with something similar, where the data
> was passed statically from DT and a driver to use that. So now it looks good
> to extend the pinctrl fw. I will try a approach for that first and see how
> it looks.
>
Right. Thats the reason its not a typical chained IRQChip like GPIO, MFD PMIC
etc etc.
Those chips always has a primary interrupt line and then secondary interrupts
which
are kind of controlled at SW level(secondary logical IRQs) using some common
registers.
Cross-bar is just a dummy hardware. The only interesting part from IRQ chip
or DMA subsystem is "request_irq" or "request_dma" look-up which happens
at driver probe ideally should be transparent and then program the appropriate
cross-bar mux for IRQ or DMA routing. The actual IRQ assertion reporting or ISR
execution etc all has to be handled by primary IRQ controller since the
cross-bar
has no intelligence or IRQ controller like capability.
To summaries it again, what I understood from Sricharan's proposal,
- Setup all the routing at cross-bar probe so that kernel continue to
work like normal IRQ controller with cross-bar scope vanishes once
the routing is done. Cross-bar does this before any of the devices
Re: [PATCH 1/3] misc: Add crossbar driver
Hi Linus,
On Sunday 21 July 2013 10:19 PM, Linus Walleij wrote:
> On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon wrote:
>
>> I carry forward my TI internal objection to this approach:
> It is actually a very good sign of FOSS-maturity that you as a company
> take unresolved architectural issues to the community. Kudos!
>
>> Lets see what happens as a result of this:
>>
>> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
>> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
>> uart1: serial@4806a000 {
>>
>> + interrupts = <0 72 0x4>;
>> Assumes that GIC interrupt by default mapping used.
> So introducing this inbetween the GIC lines and its actual device IRQ
> lines inevitably means that the GIC three-cell concept is completely
> ill-devised to handle this.
>
> For routing IRQs, I think the proper solution would be to use a
> cascaded struct irqchip, which in turn contains an irqdomain
> translation to remux the signal onto the GIC inputs.
>
> I.e. the interrupt-controller given to that serial would be the
> crossbar irqchip, and that in turn will hog and allocate apropriate
> lines from the gic to it would probably itself list *all* the IRQs
> of the GIC as "its" IRQs.
>
> We already have plenty of cascading irqchips such as GPIO
> controller providing IRQs, just that they only multiplex on a
> single GIC line instead of the whole lot.
>
> Mock example:
>
> intc: interrupt-controller@0 {
> compatible = "arm,cortex-a9-gic";
> #interrupt-cells = <3>;
> #address-cells = <1>;
> interrupt-controller;
> reg = ...;
> };
>
> crossbar: crossbar@0 {
> compatible = "...";
> interrupt-controller;
> #interrupt-cells = <1>;
> interrupt-parent = <>;
> interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
> <0 1 IRQ_TYPE_LEVEL_HIGH>,
> <0 2 IRQ_TYPE_LEVEL_HIGH>,
>
> <0 n IRQ_TYPE_LEVEL_HIGH>;
> };
>
> uart0: serial@0 {
> compatible = "...";
> interrupt-parent = <>;
> interrupts = <1234>;
> };
>
> Maybe the interrupts provided from crossbar cannot even be
> specified by a number, maybe a line name need to be used
> or so. I don't know the particulars.
>
> Whether this as a whole is a good idea, I don't know,
> but you would have to go about it something like this.
>
> What happens if there is no line to mux in a certain IRQ?
Thanks for this.
Was thinking of a similar kind of approach with irqchip.
But then, there was a GAP since crossbar does not have an irq unlike
other irqchips. But as you said this can be done by setting the crossbar
to map and receive the GIC interrupts and then direct to devices.
Only thing is, this is fine for IRQs, and something different has to be done
for DMA crossbars again. Also when we allocate dynamically here,
finding out a irq line when there is no free line is a question.
With the other approach of using/extending the pinctrl framework that you
gave, it is good to handle both irqs/dma. I looked at the other example in
drivers/dma/amba-pl08x.c and i see that data is getting populated and passed
from the platform. I initially started with something similar, where the data
was passed statically from DT and a driver to use that. So now it looks good
to extend the pinctrl fw. I will try a approach for that first and see how it
looks.
Regards,
Sricharan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
Hi Linus,
On Sunday 21 July 2013 10:19 PM, Linus Walleij wrote:
On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon n...@ti.com wrote:
I carry forward my TI internal objection to this approach:
It is actually a very good sign of FOSS-maturity that you as a company
take unresolved architectural issues to the community. Kudos!
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+ interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
So introducing this inbetween the GIC lines and its actual device IRQ
lines inevitably means that the GIC three-cell concept is completely
ill-devised to handle this.
For routing IRQs, I think the proper solution would be to use a
cascaded struct irqchip, which in turn contains an irqdomain
translation to remux the signal onto the GIC inputs.
I.e. the interrupt-controller given to that serial would be the
crossbar irqchip, and that in turn will hog and allocate apropriate
lines from the gic to it would probably itself list *all* the IRQs
of the GIC as its IRQs.
We already have plenty of cascading irqchips such as GPIO
controller providing IRQs, just that they only multiplex on a
single GIC line instead of the whole lot.
Mock example:
intc: interrupt-controller@0 {
compatible = arm,cortex-a9-gic;
#interrupt-cells = 3;
#address-cells = 1;
interrupt-controller;
reg = ...;
};
crossbar: crossbar@0 {
compatible = ...;
interrupt-controller;
#interrupt-cells = 1;
interrupt-parent = intc;
interrupts = 0 0 IRQ_TYPE_LEVEL_HIGH,
0 1 IRQ_TYPE_LEVEL_HIGH,
0 2 IRQ_TYPE_LEVEL_HIGH,
0 n IRQ_TYPE_LEVEL_HIGH;
};
uart0: serial@0 {
compatible = ...;
interrupt-parent = crossbar;
interrupts = 1234;
};
Maybe the interrupts provided from crossbar cannot even be
specified by a number, maybe a line name need to be used
or so. I don't know the particulars.
Whether this as a whole is a good idea, I don't know,
but you would have to go about it something like this.
What happens if there is no line to mux in a certain IRQ?
Thanks for this.
Was thinking of a similar kind of approach with irqchip.
But then, there was a GAP since crossbar does not have an irq unlike
other irqchips. But as you said this can be done by setting the crossbar
to map and receive the GIC interrupts and then direct to devices.
Only thing is, this is fine for IRQs, and something different has to be done
for DMA crossbars again. Also when we allocate dynamically here,
finding out a irq line when there is no free line is a question.
With the other approach of using/extending the pinctrl framework that you
gave, it is good to handle both irqs/dma. I looked at the other example in
drivers/dma/amba-pl08x.c and i see that data is getting populated and passed
from the platform. I initially started with something similar, where the data
was passed statically from DT and a driver to use that. So now it looks good
to extend the pinctrl fw. I will try a approach for that first and see how it
looks.
Regards,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Monday 22 July 2013 08:20 AM, Sricharan R wrote:
Hi Linus,
On Sunday 21 July 2013 10:19 PM, Linus Walleij wrote:
On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon n...@ti.com wrote:
I carry forward my TI internal objection to this approach:
It is actually a very good sign of FOSS-maturity that you as a company
take unresolved architectural issues to the community. Kudos!
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+ interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
So introducing this inbetween the GIC lines and its actual device IRQ
lines inevitably means that the GIC three-cell concept is completely
ill-devised to handle this.
For routing IRQs, I think the proper solution would be to use a
cascaded struct irqchip, which in turn contains an irqdomain
translation to remux the signal onto the GIC inputs.
I.e. the interrupt-controller given to that serial would be the
crossbar irqchip, and that in turn will hog and allocate apropriate
lines from the gic to it would probably itself list *all* the IRQs
of the GIC as its IRQs.
We already have plenty of cascading irqchips such as GPIO
controller providing IRQs, just that they only multiplex on a
single GIC line instead of the whole lot.
Mock example:
intc: interrupt-controller@0 {
compatible = arm,cortex-a9-gic;
#interrupt-cells = 3;
#address-cells = 1;
interrupt-controller;
reg = ...;
};
crossbar: crossbar@0 {
compatible = ...;
interrupt-controller;
#interrupt-cells = 1;
interrupt-parent = intc;
interrupts = 0 0 IRQ_TYPE_LEVEL_HIGH,
0 1 IRQ_TYPE_LEVEL_HIGH,
0 2 IRQ_TYPE_LEVEL_HIGH,
0 n IRQ_TYPE_LEVEL_HIGH;
};
uart0: serial@0 {
compatible = ...;
interrupt-parent = crossbar;
interrupts = 1234;
};
Maybe the interrupts provided from crossbar cannot even be
specified by a number, maybe a line name need to be used
or so. I don't know the particulars.
Whether this as a whole is a good idea, I don't know,
but you would have to go about it something like this.
What happens if there is no line to mux in a certain IRQ?
Thanks for this.
Was thinking of a similar kind of approach with irqchip.
But then, there was a GAP since crossbar does not have an irq unlike
other irqchips. But as you said this can be done by setting the crossbar
to map and receive the GIC interrupts and then direct to devices.
Only thing is, this is fine for IRQs, and something different has to be done
for DMA crossbars again. Also when we allocate dynamically here,
finding out a irq line when there is no free line is a question.
With the other approach of using/extending the pinctrl framework that you
gave, it is good to handle both irqs/dma. I looked at the other example in
drivers/dma/amba-pl08x.c and i see that data is getting populated and passed
from the platform. I initially started with something similar, where the data
was passed statically from DT and a driver to use that. So now it looks good
to extend the pinctrl fw. I will try a approach for that first and see how
it looks.
Right. Thats the reason its not a typical chained IRQChip like GPIO, MFD PMIC
etc etc.
Those chips always has a primary interrupt line and then secondary interrupts
which
are kind of controlled at SW level(secondary logical IRQs) using some common
registers.
Cross-bar is just a dummy hardware. The only interesting part from IRQ chip
or DMA subsystem is request_irq or request_dma look-up which happens
at driver probe ideally should be transparent and then program the appropriate
cross-bar mux for IRQ or DMA routing. The actual IRQ assertion reporting or ISR
execution etc all has to be handled by primary IRQ controller since the
cross-bar
has no intelligence or IRQ controller like capability.
To summaries it again, what I understood from Sricharan's proposal,
- Setup all the routing at cross-bar probe so that kernel continue to
work like normal IRQ controller with cross-bar scope vanishes once
the routing is done. Cross-bar does this before any of the devices
are created.
- Something similar needs to happen for DMA lines as well or for any
other event routing in future.
- Cross-bar callbacks for device drivers for error
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon wrote:
> I carry forward my TI internal objection to this approach:
It is actually a very good sign of FOSS-maturity that you as a company
take unresolved architectural issues to the community. Kudos!
> Lets see what happens as a result of this:
>
> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
> uart1: serial@4806a000 {
>
> + interrupts = <0 72 0x4>;
> Assumes that GIC interrupt by default mapping used.
So introducing this inbetween the GIC lines and its actual device IRQ
lines inevitably means that the GIC three-cell concept is completely
ill-devised to handle this.
For routing IRQs, I think the proper solution would be to use a
cascaded struct irqchip, which in turn contains an irqdomain
translation to remux the signal onto the GIC inputs.
I.e. the interrupt-controller given to that serial would be the
crossbar irqchip, and that in turn will hog and allocate apropriate
lines from the gic to it would probably itself list *all* the IRQs
of the GIC as "its" IRQs.
We already have plenty of cascading irqchips such as GPIO
controller providing IRQs, just that they only multiplex on a
single GIC line instead of the whole lot.
Mock example:
intc: interrupt-controller@0 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
#address-cells = <1>;
interrupt-controller;
reg = ...;
};
crossbar: crossbar@0 {
compatible = "...";
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <>;
interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
<0 1 IRQ_TYPE_LEVEL_HIGH>,
<0 2 IRQ_TYPE_LEVEL_HIGH>,
<0 n IRQ_TYPE_LEVEL_HIGH>;
};
uart0: serial@0 {
compatible = "...";
interrupt-parent = <>;
interrupts = <1234>;
};
Maybe the interrupts provided from crossbar cannot even be
specified by a number, maybe a line name need to be used
or so. I don't know the particulars.
Whether this as a whole is a good idea, I don't know,
but you would have to go about it something like this.
What happens if there is no line to mux in a certain IRQ?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Jul 18, 2013 at 8:25 PM, Felipe Balbi wrote: >> The Peripheral irq/dma requests are connected to one crossbar's input >> and the output of the crossbar is connected to controller's input >> line. On POR, there are some mappings which are done by default. >> Those peripherals which do not have a mapping on POR, should be configured >> to route its requests using the crossbar. (...) > why isn't this done under pinctrl ? If all it does is mux DMA and IRQ > request lines, it should be written as a pinctrl driver no ? Actually I was thinking about this at one time when designing pinctrl, "what if we face the problem of arbitrary signal multiplexing?" However pin control is named for what it does and also controls things like the electrical properties of pins, biasing and so on which is ill applicable here. I would rather say that the pin multiplexing portions of pin control could be rewritten to use a more generic component dealing with arbitrary line multiplexing, i.e. something under /lib and maybe then move over some generic concepts such as the function to group mapping. The same concept as found here is found in the muxes used by drivers/dma/amba-pl08x.c back-ends on ARM reference hardware which is also multiplexing DMA signals. In that case we have done platform-specific hooks and implemented this in the per-machine platform code. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Jul 18, 2013 at 8:25 PM, Felipe Balbi ba...@ti.com wrote: The Peripheral irq/dma requests are connected to one crossbar's input and the output of the crossbar is connected to controller's input line. On POR, there are some mappings which are done by default. Those peripherals which do not have a mapping on POR, should be configured to route its requests using the crossbar. (...) why isn't this done under pinctrl ? If all it does is mux DMA and IRQ request lines, it should be written as a pinctrl driver no ? Actually I was thinking about this at one time when designing pinctrl, what if we face the problem of arbitrary signal multiplexing? However pin control is named for what it does and also controls things like the electrical properties of pins, biasing and so on which is ill applicable here. I would rather say that the pin multiplexing portions of pin control could be rewritten to use a more generic component dealing with arbitrary line multiplexing, i.e. something under /lib and maybe then move over some generic concepts such as the function to group mapping. The same concept as found here is found in the muxes used by drivers/dma/amba-pl08x.c back-ends on ARM reference hardware which is also multiplexing DMA signals. In that case we have done platform-specific hooks and implemented this in the per-machine platform code. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon n...@ti.com wrote:
I carry forward my TI internal objection to this approach:
It is actually a very good sign of FOSS-maturity that you as a company
take unresolved architectural issues to the community. Kudos!
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+ interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
So introducing this inbetween the GIC lines and its actual device IRQ
lines inevitably means that the GIC three-cell concept is completely
ill-devised to handle this.
For routing IRQs, I think the proper solution would be to use a
cascaded struct irqchip, which in turn contains an irqdomain
translation to remux the signal onto the GIC inputs.
I.e. the interrupt-controller given to that serial would be the
crossbar irqchip, and that in turn will hog and allocate apropriate
lines from the gic to it would probably itself list *all* the IRQs
of the GIC as its IRQs.
We already have plenty of cascading irqchips such as GPIO
controller providing IRQs, just that they only multiplex on a
single GIC line instead of the whole lot.
Mock example:
intc: interrupt-controller@0 {
compatible = arm,cortex-a9-gic;
#interrupt-cells = 3;
#address-cells = 1;
interrupt-controller;
reg = ...;
};
crossbar: crossbar@0 {
compatible = ...;
interrupt-controller;
#interrupt-cells = 1;
interrupt-parent = intc;
interrupts = 0 0 IRQ_TYPE_LEVEL_HIGH,
0 1 IRQ_TYPE_LEVEL_HIGH,
0 2 IRQ_TYPE_LEVEL_HIGH,
0 n IRQ_TYPE_LEVEL_HIGH;
};
uart0: serial@0 {
compatible = ...;
interrupt-parent = crossbar;
interrupts = 1234;
};
Maybe the interrupts provided from crossbar cannot even be
specified by a number, maybe a line name need to be used
or so. I don't know the particulars.
Whether this as a whole is a good idea, I don't know,
but you would have to go about it something like this.
What happens if there is no line to mux in a certain IRQ?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
Hi,
On Friday 19 July 2013 05:43 AM, Nishanth Menon wrote:
> On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
> wrote:
>> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
>>> On 07/18/2013 11:43 AM, Sricharan R wrote:
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.
The Peripheral irq/dma requests are connected to one crossbar's input
and the output of the crossbar is connected to controller's input
line. On POR, there are some mappings which are done by default.
Those peripherals which do not have a mapping on POR, should be configured
to route its requests using the crossbar.
The drivers identifies every controller's crossbar as individual devices.
The mappings can be specified from the DT crossbar nodes and those gets
mapped
during the crossbar device's probe. The mappings can also be specified by
adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.
Signed-off-by: Sricharan R
---
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1 +
drivers/misc/crossbar.c| 258
include/linux/crossbar.h | 71 ++
5 files changed, 362 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/omap/crossbar.txt
create mode 100644 drivers/misc/crossbar.c
create mode 100644 include/linux/crossbar.h
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000..02a8a28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,24 @@
+* TI - IRQ/DMA Crossbar
+
+This version is an implementation of the Crossbar IRQ/DMA IP
+
+Required properties:
+- compatible : Should be "ti,dra-crossbar"
+- crossbar-name: Name of the controller to which crossbar output is routed
+- reg:Contains crossbar register address range
+- reg-width: Represents the width of the individual registers
+- crossbar-lines: Default mappings.Should contain the crossbar-name
+ device name, int/dma request number, crossbar number,
+ register offset in the same order.
+
+Examples:
+crossbar_mpu: mpuirq@4a002a48 {
+compatible = "crossbar";
+crossbar-name = "mpu-irq";
+reg = <0x4a002a48 0x0130>;
+reg-width = <16>;
+crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9 0x12c>,
+ "mpu-irq", "mcasp3-arevt", <0x9e 0x96 0x12a>,
+ "mpu-irq", "mcasp3-axevt", <0x9d 0x97 0x128>;
+};
>>> I carry forward my TI internal objection to this approach:
>>>
>>> NAK.
>>>
>>> DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is
>>> as follows:
>>> hardware IP block -interrupt line-> IRQ Cross bar -> GIC IRQ line --> MPU
>>> IRQ.
>>>
>>>
>>> What we have done today for DRA is to provide IRQ numbers as direct maps
>>> from hardware IP block to GIC based on default IRQ cross bar mapping.
>>>
>>> Lets see what happens as a result of this:
>>>
>>> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
>>> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
>>> uart1: serial@4806a000 {
>>>
>>> +interrupts = <0 72 0x4>;
>>> Assumes that GIC interrupt by default mapping used.
>>>
>>> Now, think of a product that wants to use UART10 instead of UART1, SoC
>>> design allows you do that by doing a remapping of GIC interrupt to UART10 -
>>> which is awesome.
>>>
>>> Option 1: u-boot/bootloader
>>> mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
>>>
>>> Option 2: in kernel do a raw_writel version of option 1.
>>> This patch does option 1 in kernel in a "fancy way" - why the heck would I
>>> want to do that when u-boot allows me to do the same thing in uEnv.txt
>>>
>>> Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
>>> a) Allows us to define every single IP available on DRA7 SoC.
>>> b) GIC allocation happens dynamically
>>> c) allow products use IPs as needed.
>>>
>>> Sorry, Conceptually option 3 is the right approach in my view.
>>> instead of
Re: [PATCH 1/3] misc: Add crossbar driver
On Friday 19 July 2013 12:47 PM, Tony Lindgren wrote: >> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote: >> >> Since the cross-bar is not limited t0 IRQ lines and applicable for >> DMA request lines as well, making it IRQ chip doesn't make sense. Its >> not typical pin control functionality either but at least that framework >> is much closer to consider as an option. >> >> Actually its more of setting up the IRQ and DMA pins maps once >> at boot for a given SOC based on chosen configuration by the >> board. So I am leaning towards pinctrl as well. Just haven't >> thought enough about whether thats the best approach. >> >> CC'ing Linus W and Tony L whether we can use pinctrl framework >> for such an IP and if yes how ;-). > If it really muxes signals then using pinctrl seems logical. > Especially if the registers are in the SCM block. > > It might be already possible to handle it already with > pinctrl-single,bits for the muxing part. I also thought of using the pinctrl itself. But then i wanted to have the error handling as well, hence did this. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote: > > Since the cross-bar is not limited t0 IRQ lines and applicable for > DMA request lines as well, making it IRQ chip doesn't make sense. Its > not typical pin control functionality either but at least that framework > is much closer to consider as an option. > > Actually its more of setting up the IRQ and DMA pins maps once > at boot for a given SOC based on chosen configuration by the > board. So I am leaning towards pinctrl as well. Just haven't > thought enough about whether thats the best approach. > > CC'ing Linus W and Tony L whether we can use pinctrl framework > for such an IP and if yes how ;-). If it really muxes signals then using pinctrl seems logical. Especially if the registers are in the SCM block. It might be already possible to handle it already with pinctrl-single,bits for the muxing part. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote: Since the cross-bar is not limited t0 IRQ lines and applicable for DMA request lines as well, making it IRQ chip doesn't make sense. Its not typical pin control functionality either but at least that framework is much closer to consider as an option. Actually its more of setting up the IRQ and DMA pins maps once at boot for a given SOC based on chosen configuration by the board. So I am leaning towards pinctrl as well. Just haven't thought enough about whether thats the best approach. CC'ing Linus W and Tony L whether we can use pinctrl framework for such an IP and if yes how ;-). If it really muxes signals then using pinctrl seems logical. Especially if the registers are in the SCM block. It might be already possible to handle it already with pinctrl-single,bits for the muxing part. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
Hi,
On Friday 19 July 2013 05:43 AM, Nishanth Menon wrote:
On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
On 07/18/2013 11:43 AM, Sricharan R wrote:
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.
The Peripheral irq/dma requests are connected to one crossbar's input
and the output of the crossbar is connected to controller's input
line. On POR, there are some mappings which are done by default.
Those peripherals which do not have a mapping on POR, should be configured
to route its requests using the crossbar.
The drivers identifies every controller's crossbar as individual devices.
The mappings can be specified from the DT crossbar nodes and those gets
mapped
during the crossbar device's probe. The mappings can also be specified by
adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1 +
drivers/misc/crossbar.c| 258
include/linux/crossbar.h | 71 ++
5 files changed, 362 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/omap/crossbar.txt
create mode 100644 drivers/misc/crossbar.c
create mode 100644 include/linux/crossbar.h
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000..02a8a28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,24 @@
+* TI - IRQ/DMA Crossbar
+
+This version is an implementation of the Crossbar IRQ/DMA IP
+
+Required properties:
+- compatible : Should be ti,dra-crossbar
+- crossbar-name: Name of the controller to which crossbar output is routed
+- reg:Contains crossbar register address range
+- reg-width: Represents the width of the individual registers
+- crossbar-lines: Default mappings.Should contain the crossbar-name
+ device name, int/dma request number, crossbar number,
+ register offset in the same order.
+
+Examples:
+crossbar_mpu: mpuirq@4a002a48 {
+compatible = crossbar;
+crossbar-name = mpu-irq;
+reg = 0x4a002a48 0x0130;
+reg-width = 16;
+crossbar-lines = mpu-irq, rtc-ss-alarm, 0x9f 0xd9 0x12c,
+ mpu-irq, mcasp3-arevt, 0x9e 0x96 0x12a,
+ mpu-irq, mcasp3-axevt, 0x9d 0x97 0x128;
+};
I carry forward my TI internal objection to this approach:
NAK.
DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is
as follows:
hardware IP block -interrupt line- IRQ Cross bar - GIC IRQ line -- MPU
IRQ.
What we have done today for DRA is to provide IRQ numbers as direct maps
from hardware IP block to GIC based on default IRQ cross bar mapping.
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
Now, think of a product that wants to use UART10 instead of UART1, SoC
design allows you do that by doing a remapping of GIC interrupt to UART10 -
which is awesome.
Option 1: u-boot/bootloader
mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
Option 2: in kernel do a raw_writel version of option 1.
This patch does option 1 in kernel in a fancy way - why the heck would I
want to do that when u-boot allows me to do the same thing in uEnv.txt
Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
a) Allows us to define every single IP available on DRA7 SoC.
b) GIC allocation happens dynamically
c) allow products use IPs as needed.
Sorry, Conceptually option 3 is the right approach in my view.
instead of doing
uart1: serial@4806a000 {
snip
+interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH;
we should be able to do the following:
uart1: serial@4806a000 {
snip
+interrupts = TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH;
and not worry about the GIC interrupt number used
Since the cross-bar is not limited t0 IRQ lines and applicable for
DMA request lines as
Re: [PATCH 1/3] misc: Add crossbar driver
On Friday 19 July 2013 12:47 PM, Tony Lindgren wrote: On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote: Since the cross-bar is not limited t0 IRQ lines and applicable for DMA request lines as well, making it IRQ chip doesn't make sense. Its not typical pin control functionality either but at least that framework is much closer to consider as an option. Actually its more of setting up the IRQ and DMA pins maps once at boot for a given SOC based on chosen configuration by the board. So I am leaning towards pinctrl as well. Just haven't thought enough about whether thats the best approach. CC'ing Linus W and Tony L whether we can use pinctrl framework for such an IP and if yes how ;-). If it really muxes signals then using pinctrl seems logical. Especially if the registers are in the SCM block. It might be already possible to handle it already with pinctrl-single,bits for the muxing part. I also thought of using the pinctrl itself. But then i wanted to have the error handling as well, hence did this. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
wrote:
> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
>> On 07/18/2013 11:43 AM, Sricharan R wrote:
>>> Some socs have a large number of interrupts/dma requests to service
>>> the needs of its many peripherals and subsystems. All of the
>>> requests lines from the subsystems are not needed at the same
>>> time, so they have to be muxed to the controllers appropriately.
>>> In such places a interrupt/dma controllers are preceded by an
>>> IRQ/DMA CROSSBAR that provides flexibility in muxing the device
>>> requests to the controller inputs.
>>>
>>> The Peripheral irq/dma requests are connected to one crossbar's input
>>> and the output of the crossbar is connected to controller's input
>>> line. On POR, there are some mappings which are done by default.
>>> Those peripherals which do not have a mapping on POR, should be configured
>>> to route its requests using the crossbar.
>>>
>>> The drivers identifies every controller's crossbar as individual devices.
>>> The mappings can be specified from the DT crossbar nodes and those gets
>>> mapped
>>> during the crossbar device's probe. The mappings can also be specified by
>>> adding
>>> the crossbar lines to the peripheral device nodes and map it with
>>> crossbar_map/unmap apis.
>>>
>>> Signed-off-by: Sricharan R
>>> ---
>>> .../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
>>> drivers/misc/Kconfig |8 +
>>> drivers/misc/Makefile |1 +
>>> drivers/misc/crossbar.c| 258
>>>
>>> include/linux/crossbar.h | 71 ++
>>> 5 files changed, 362 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> create mode 100644 drivers/misc/crossbar.c
>>> create mode 100644 include/linux/crossbar.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> new file mode 100644
>>> index 000..02a8a28
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> @@ -0,0 +1,24 @@
>>> +* TI - IRQ/DMA Crossbar
>>> +
>>> +This version is an implementation of the Crossbar IRQ/DMA IP
>>> +
>>> +Required properties:
>>> +- compatible : Should be "ti,dra-crossbar"
>>> +- crossbar-name: Name of the controller to which crossbar output is routed
>>> +- reg:Contains crossbar register address range
>>> +- reg-width: Represents the width of the individual registers
>>> +- crossbar-lines: Default mappings.Should contain the crossbar-name
>>> + device name, int/dma request number, crossbar number,
>>> + register offset in the same order.
>>> +
>>> +Examples:
>>> +crossbar_mpu: mpuirq@4a002a48 {
>>> +compatible = "crossbar";
>>> +crossbar-name = "mpu-irq";
>>> +reg = <0x4a002a48 0x0130>;
>>> +reg-width = <16>;
>>> +crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9 0x12c>,
>>> + "mpu-irq", "mcasp3-arevt", <0x9e 0x96 0x12a>,
>>> + "mpu-irq", "mcasp3-axevt", <0x9d 0x97 0x128>;
>>> +};
>>
>> I carry forward my TI internal objection to this approach:
>>
>> NAK.
>>
>> DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is
>> as follows:
>> hardware IP block -interrupt line-> IRQ Cross bar -> GIC IRQ line --> MPU
>> IRQ.
>>
>>
>> What we have done today for DRA is to provide IRQ numbers as direct maps
>> from hardware IP block to GIC based on default IRQ cross bar mapping.
>>
>> Lets see what happens as a result of this:
>>
>> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
>> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
>> uart1: serial@4806a000 {
>>
>> +interrupts = <0 72 0x4>;
>> Assumes that GIC interrupt by default mapping used.
>>
>> Now, think of a product that wants to use UART10 instead of UART1, SoC
>> design allows you do that by doing a remapping of GIC interrupt to UART10 -
>> which is awesome.
>>
>> Option 1: u-boot/bootloader
>> mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
>>
>> Option 2: in kernel do a raw_writel version of option 1.
>> This patch does option 1 in kernel in a "fancy way" - why the heck would I
>> want to do that when u-boot allows me to do the same thing in uEnv.txt
>>
>> Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
>> a) Allows us to define every single IP available on DRA7 SoC.
>> b) GIC allocation happens dynamically
>> c) allow products use IPs as needed.
>>
>> Sorry, Conceptually option 3 is the right approach in my view.
>> instead of doing
>> uart1: serial@4806a000 {
>>
>> +interrupts = ;
>>
>> we should be able to do the following:
>> uart1: serial@4806a000 {
>>
>> +interrupts = ;
Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
> On 07/18/2013 11:43 AM, Sricharan R wrote:
>> Some socs have a large number of interrupts/dma requests to service
>> the needs of its many peripherals and subsystems. All of the
>> requests lines from the subsystems are not needed at the same
>> time, so they have to be muxed to the controllers appropriately.
>> In such places a interrupt/dma controllers are preceded by an
>> IRQ/DMA CROSSBAR that provides flexibility in muxing the device
>> requests to the controller inputs.
>>
>> The Peripheral irq/dma requests are connected to one crossbar's input
>> and the output of the crossbar is connected to controller's input
>> line. On POR, there are some mappings which are done by default.
>> Those peripherals which do not have a mapping on POR, should be configured
>> to route its requests using the crossbar.
>>
>> The drivers identifies every controller's crossbar as individual devices.
>> The mappings can be specified from the DT crossbar nodes and those gets
>> mapped
>> during the crossbar device's probe. The mappings can also be specified by
>> adding
>> the crossbar lines to the peripheral device nodes and map it with
>> crossbar_map/unmap apis.
>>
>> Signed-off-by: Sricharan R
>> ---
>> .../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
>> drivers/misc/Kconfig |8 +
>> drivers/misc/Makefile |1 +
>> drivers/misc/crossbar.c| 258
>>
>> include/linux/crossbar.h | 71 ++
>> 5 files changed, 362 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> create mode 100644 drivers/misc/crossbar.c
>> create mode 100644 include/linux/crossbar.h
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> new file mode 100644
>> index 000..02a8a28
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> @@ -0,0 +1,24 @@
>> +* TI - IRQ/DMA Crossbar
>> +
>> +This version is an implementation of the Crossbar IRQ/DMA IP
>> +
>> +Required properties:
>> +- compatible : Should be "ti,dra-crossbar"
>> +- crossbar-name: Name of the controller to which crossbar output is routed
>> +- reg:Contains crossbar register address range
>> +- reg-width: Represents the width of the individual registers
>> +- crossbar-lines: Default mappings.Should contain the crossbar-name
>> + device name, int/dma request number, crossbar number,
>> + register offset in the same order.
>> +
>> +Examples:
>> +crossbar_mpu: mpuirq@4a002a48 {
>> +compatible = "crossbar";
>> +crossbar-name = "mpu-irq";
>> +reg = <0x4a002a48 0x0130>;
>> +reg-width = <16>;
>> +crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9 0x12c>,
>> + "mpu-irq", "mcasp3-arevt", <0x9e 0x96 0x12a>,
>> + "mpu-irq", "mcasp3-axevt", <0x9d 0x97 0x128>;
>> +};
>
> I carry forward my TI internal objection to this approach:
>
> NAK.
>
> DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is as
> follows:
> hardware IP block -interrupt line-> IRQ Cross bar -> GIC IRQ line --> MPU IRQ.
>
>
> What we have done today for DRA is to provide IRQ numbers as direct maps from
> hardware IP block to GIC based on default IRQ cross bar mapping.
>
> Lets see what happens as a result of this:
>
> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
> uart1: serial@4806a000 {
>
> +interrupts = <0 72 0x4>;
> Assumes that GIC interrupt by default mapping used.
>
> Now, think of a product that wants to use UART10 instead of UART1, SoC design
> allows you do that by doing a remapping of GIC interrupt to UART10 - which is
> awesome.
>
> Option 1: u-boot/bootloader
> mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
>
> Option 2: in kernel do a raw_writel version of option 1.
> This patch does option 1 in kernel in a "fancy way" - why the heck would I
> want to do that when u-boot allows me to do the same thing in uEnv.txt
>
> Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
> a) Allows us to define every single IP available on DRA7 SoC.
> b) GIC allocation happens dynamically
> c) allow products use IPs as needed.
>
> Sorry, Conceptually option 3 is the right approach in my view.
> instead of doing
> uart1: serial@4806a000 {
>
> +interrupts = ;
>
> we should be able to do the following:
> uart1: serial@4806a000 {
>
> +interrupts = ;
>
> and not worry about the GIC interrupt number used
>
>
Since the cross-bar is not limited t0 IRQ lines and applicable for
DMA request lines as well, making it
Re: [PATCH 1/3] misc: Add crossbar driver
On 07/18/2013 11:43 AM, Sricharan R wrote:
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.
The Peripheral irq/dma requests are connected to one crossbar's input
and the output of the crossbar is connected to controller's input
line. On POR, there are some mappings which are done by default.
Those peripherals which do not have a mapping on POR, should be configured
to route its requests using the crossbar.
The drivers identifies every controller's crossbar as individual devices.
The mappings can be specified from the DT crossbar nodes and those gets mapped
during the crossbar device's probe. The mappings can also be specified by adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.
Signed-off-by: Sricharan R
---
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1 +
drivers/misc/crossbar.c| 258
include/linux/crossbar.h | 71 ++
5 files changed, 362 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
create mode 100644 drivers/misc/crossbar.c
create mode 100644 include/linux/crossbar.h
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000..02a8a28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,24 @@
+* TI - IRQ/DMA Crossbar
+
+This version is an implementation of the Crossbar IRQ/DMA IP
+
+Required properties:
+- compatible : Should be "ti,dra-crossbar"
+- crossbar-name: Name of the controller to which crossbar output is routed
+- reg: Contains crossbar register address range
+- reg-width: Represents the width of the individual registers
+- crossbar-lines: Default mappings.Should contain the crossbar-name
+ device name, int/dma request number, crossbar number,
+ register offset in the same order.
+
+Examples:
+ crossbar_mpu: mpuirq@4a002a48 {
+ compatible = "crossbar";
+ crossbar-name = "mpu-irq";
+ reg = <0x4a002a48 0x0130>;
+ reg-width = <16>;
+ crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9
0x12c>,
+"mpu-irq", "mcasp3-arevt", <0x9e 0x96
0x12a>,
+"mpu-irq", "mcasp3-axevt", <0x9d 0x97
0x128>;
+ };
I carry forward my TI internal objection to this approach:
NAK.
DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt
is as follows:
hardware IP block -interrupt line-> IRQ Cross bar -> GIC IRQ line -->
MPU IRQ.
What we have done today for DRA is to provide IRQ numbers as direct maps
from hardware IP block to GIC based on default IRQ cross bar mapping.
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
+ interrupts = <0 72 0x4>;
Assumes that GIC interrupt by default mapping used.
Now, think of a product that wants to use UART10 instead of UART1, SoC
design allows you do that by doing a remapping of GIC interrupt to
UART10 - which is awesome.
Option 1: u-boot/bootloader
mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
Option 2: in kernel do a raw_writel version of option 1.
This patch does option 1 in kernel in a "fancy way" - why the heck would
I want to do that when u-boot allows me to do the same thing in uEnv.txt
Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
a) Allows us to define every single IP available on DRA7 SoC.
b) GIC allocation happens dynamically
c) allow products use IPs as needed.
Sorry, Conceptually option 3 is the right approach in my view.
instead of doing
uart1: serial@4806a000 {
+ interrupts = ;
we should be able to do the following:
uart1: serial@4806a000 {
+ interrupts = ;
and not worry about the GIC interrupt number used
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
Hi, On Thu, Jul 18, 2013 at 10:13:48PM +0530, Sricharan R wrote: > Some socs have a large number of interrupts/dma requests to service > the needs of its many peripherals and subsystems. All of the > requests lines from the subsystems are not needed at the same > time, so they have to be muxed to the controllers appropriately. > In such places a interrupt/dma controllers are preceded by an > IRQ/DMA CROSSBAR that provides flexibility in muxing the device > requests to the controller inputs. > > The Peripheral irq/dma requests are connected to one crossbar's input > and the output of the crossbar is connected to controller's input > line. On POR, there are some mappings which are done by default. > Those peripherals which do not have a mapping on POR, should be configured > to route its requests using the crossbar. > > The drivers identifies every controller's crossbar as individual devices. > The mappings can be specified from the DT crossbar nodes and those gets mapped > during the crossbar device's probe. The mappings can also be specified by > adding > the crossbar lines to the peripheral device nodes and map it with > crossbar_map/unmap apis. > > Signed-off-by: Sricharan R why isn't this done under pinctrl ? If all it does is mux DMA and IRQ request lines, it should be written as a pinctrl driver no ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, 2013-07-18 at 22:13 +0530, Sricharan R wrote:
> Some socs have a large number of interrupts/dma requests to service
> the needs of its many peripherals and subsystems. All of the
> requests lines from the subsystems are not needed at the same
> time, so they have to be muxed to the controllers appropriately.
> In such places a interrupt/dma controllers are preceded by an
> IRQ/DMA CROSSBAR that provides flexibility in muxing the device
> requests to the controller inputs.
[]
> diff --git a/drivers/misc/crossbar.c b/drivers/misc/crossbar.c
[]
> +int crossbar_unmap(struct device_node *cbdev_node, unsigned index)
[]
> + list_for_each_entry(cbdev, _devlist, node) {
> + if (strcmp(cbdev->name, tmp.cb_name))
> + continue;
[]
> + dev_warn(cbdev->dev,
> + "unmapped int_no %x mapped to cb %x\n",
> + tmp.int_no, tmp.cb_no);
> + return 0;
[]
> + dev_warn(cbdev->dev, "%s cb entry %d not found\n",
> + __func__, tmp.cb_no);
> + return -ENOENT;
Why does this function always emit a dev_warn
before return? Maybe the first should be dev_info?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, 2013-07-18 at 22:13 +0530, Sricharan R wrote:
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.
[]
diff --git a/drivers/misc/crossbar.c b/drivers/misc/crossbar.c
[]
+int crossbar_unmap(struct device_node *cbdev_node, unsigned index)
[]
+ list_for_each_entry(cbdev, cb_devlist, node) {
+ if (strcmp(cbdev-name, tmp.cb_name))
+ continue;
[]
+ dev_warn(cbdev-dev,
+ unmapped int_no %x mapped to cb %x\n,
+ tmp.int_no, tmp.cb_no);
+ return 0;
[]
+ dev_warn(cbdev-dev, %s cb entry %d not found\n,
+ __func__, tmp.cb_no);
+ return -ENOENT;
Why does this function always emit a dev_warn
before return? Maybe the first should be dev_info?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] misc: Add crossbar driver
Hi, On Thu, Jul 18, 2013 at 10:13:48PM +0530, Sricharan R wrote: Some socs have a large number of interrupts/dma requests to service the needs of its many peripherals and subsystems. All of the requests lines from the subsystems are not needed at the same time, so they have to be muxed to the controllers appropriately. In such places a interrupt/dma controllers are preceded by an IRQ/DMA CROSSBAR that provides flexibility in muxing the device requests to the controller inputs. The Peripheral irq/dma requests are connected to one crossbar's input and the output of the crossbar is connected to controller's input line. On POR, there are some mappings which are done by default. Those peripherals which do not have a mapping on POR, should be configured to route its requests using the crossbar. The drivers identifies every controller's crossbar as individual devices. The mappings can be specified from the DT crossbar nodes and those gets mapped during the crossbar device's probe. The mappings can also be specified by adding the crossbar lines to the peripheral device nodes and map it with crossbar_map/unmap apis. Signed-off-by: Sricharan R r.sricha...@ti.com why isn't this done under pinctrl ? If all it does is mux DMA and IRQ request lines, it should be written as a pinctrl driver no ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] misc: Add crossbar driver
On 07/18/2013 11:43 AM, Sricharan R wrote:
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.
The Peripheral irq/dma requests are connected to one crossbar's input
and the output of the crossbar is connected to controller's input
line. On POR, there are some mappings which are done by default.
Those peripherals which do not have a mapping on POR, should be configured
to route its requests using the crossbar.
The drivers identifies every controller's crossbar as individual devices.
The mappings can be specified from the DT crossbar nodes and those gets mapped
during the crossbar device's probe. The mappings can also be specified by adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1 +
drivers/misc/crossbar.c| 258
include/linux/crossbar.h | 71 ++
5 files changed, 362 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
create mode 100644 drivers/misc/crossbar.c
create mode 100644 include/linux/crossbar.h
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000..02a8a28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,24 @@
+* TI - IRQ/DMA Crossbar
+
+This version is an implementation of the Crossbar IRQ/DMA IP
+
+Required properties:
+- compatible : Should be ti,dra-crossbar
+- crossbar-name: Name of the controller to which crossbar output is routed
+- reg: Contains crossbar register address range
+- reg-width: Represents the width of the individual registers
+- crossbar-lines: Default mappings.Should contain the crossbar-name
+ device name, int/dma request number, crossbar number,
+ register offset in the same order.
+
+Examples:
+ crossbar_mpu: mpuirq@4a002a48 {
+ compatible = crossbar;
+ crossbar-name = mpu-irq;
+ reg = 0x4a002a48 0x0130;
+ reg-width = 16;
+ crossbar-lines = mpu-irq, rtc-ss-alarm, 0x9f 0xd9
0x12c,
+mpu-irq, mcasp3-arevt, 0x9e 0x96
0x12a,
+mpu-irq, mcasp3-axevt, 0x9d 0x97
0x128;
+ };
I carry forward my TI internal objection to this approach:
NAK.
DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt
is as follows:
hardware IP block -interrupt line- IRQ Cross bar - GIC IRQ line --
MPU IRQ.
What we have done today for DRA is to provide IRQ numbers as direct maps
from hardware IP block to GIC based on default IRQ cross bar mapping.
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+ interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
Now, think of a product that wants to use UART10 instead of UART1, SoC
design allows you do that by doing a remapping of GIC interrupt to
UART10 - which is awesome.
Option 1: u-boot/bootloader
mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
Option 2: in kernel do a raw_writel version of option 1.
This patch does option 1 in kernel in a fancy way - why the heck would
I want to do that when u-boot allows me to do the same thing in uEnv.txt
Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
a) Allows us to define every single IP available on DRA7 SoC.
b) GIC allocation happens dynamically
c) allow products use IPs as needed.
Sorry, Conceptually option 3 is the right approach in my view.
instead of doing
uart1: serial@4806a000 {
snip
+ interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH;
we should be able to do the following:
uart1: serial@4806a000 {
snip
+ interrupts = TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH;
and not worry about the GIC interrupt number used
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
On 07/18/2013 11:43 AM, Sricharan R wrote:
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.
The Peripheral irq/dma requests are connected to one crossbar's input
and the output of the crossbar is connected to controller's input
line. On POR, there are some mappings which are done by default.
Those peripherals which do not have a mapping on POR, should be configured
to route its requests using the crossbar.
The drivers identifies every controller's crossbar as individual devices.
The mappings can be specified from the DT crossbar nodes and those gets
mapped
during the crossbar device's probe. The mappings can also be specified by
adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1 +
drivers/misc/crossbar.c| 258
include/linux/crossbar.h | 71 ++
5 files changed, 362 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
create mode 100644 drivers/misc/crossbar.c
create mode 100644 include/linux/crossbar.h
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000..02a8a28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,24 @@
+* TI - IRQ/DMA Crossbar
+
+This version is an implementation of the Crossbar IRQ/DMA IP
+
+Required properties:
+- compatible : Should be ti,dra-crossbar
+- crossbar-name: Name of the controller to which crossbar output is routed
+- reg:Contains crossbar register address range
+- reg-width: Represents the width of the individual registers
+- crossbar-lines: Default mappings.Should contain the crossbar-name
+ device name, int/dma request number, crossbar number,
+ register offset in the same order.
+
+Examples:
+crossbar_mpu: mpuirq@4a002a48 {
+compatible = crossbar;
+crossbar-name = mpu-irq;
+reg = 0x4a002a48 0x0130;
+reg-width = 16;
+crossbar-lines = mpu-irq, rtc-ss-alarm, 0x9f 0xd9 0x12c,
+ mpu-irq, mcasp3-arevt, 0x9e 0x96 0x12a,
+ mpu-irq, mcasp3-axevt, 0x9d 0x97 0x128;
+};
I carry forward my TI internal objection to this approach:
NAK.
DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is as
follows:
hardware IP block -interrupt line- IRQ Cross bar - GIC IRQ line -- MPU IRQ.
What we have done today for DRA is to provide IRQ numbers as direct maps from
hardware IP block to GIC based on default IRQ cross bar mapping.
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
Now, think of a product that wants to use UART10 instead of UART1, SoC design
allows you do that by doing a remapping of GIC interrupt to UART10 - which is
awesome.
Option 1: u-boot/bootloader
mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
Option 2: in kernel do a raw_writel version of option 1.
This patch does option 1 in kernel in a fancy way - why the heck would I
want to do that when u-boot allows me to do the same thing in uEnv.txt
Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
a) Allows us to define every single IP available on DRA7 SoC.
b) GIC allocation happens dynamically
c) allow products use IPs as needed.
Sorry, Conceptually option 3 is the right approach in my view.
instead of doing
uart1: serial@4806a000 {
snip
+interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH;
we should be able to do the following:
uart1: serial@4806a000 {
snip
+interrupts = TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH;
and not worry about the GIC interrupt number used
Since the cross-bar is not limited t0 IRQ lines and applicable for
DMA request lines as well, making it IRQ chip doesn't make sense. Its
not typical pin control functionality either but at least that framework
is much closer
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
On 07/18/2013 11:43 AM, Sricharan R wrote:
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.
The Peripheral irq/dma requests are connected to one crossbar's input
and the output of the crossbar is connected to controller's input
line. On POR, there are some mappings which are done by default.
Those peripherals which do not have a mapping on POR, should be configured
to route its requests using the crossbar.
The drivers identifies every controller's crossbar as individual devices.
The mappings can be specified from the DT crossbar nodes and those gets
mapped
during the crossbar device's probe. The mappings can also be specified by
adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1 +
drivers/misc/crossbar.c| 258
include/linux/crossbar.h | 71 ++
5 files changed, 362 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
create mode 100644 drivers/misc/crossbar.c
create mode 100644 include/linux/crossbar.h
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000..02a8a28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,24 @@
+* TI - IRQ/DMA Crossbar
+
+This version is an implementation of the Crossbar IRQ/DMA IP
+
+Required properties:
+- compatible : Should be ti,dra-crossbar
+- crossbar-name: Name of the controller to which crossbar output is routed
+- reg:Contains crossbar register address range
+- reg-width: Represents the width of the individual registers
+- crossbar-lines: Default mappings.Should contain the crossbar-name
+ device name, int/dma request number, crossbar number,
+ register offset in the same order.
+
+Examples:
+crossbar_mpu: mpuirq@4a002a48 {
+compatible = crossbar;
+crossbar-name = mpu-irq;
+reg = 0x4a002a48 0x0130;
+reg-width = 16;
+crossbar-lines = mpu-irq, rtc-ss-alarm, 0x9f 0xd9 0x12c,
+ mpu-irq, mcasp3-arevt, 0x9e 0x96 0x12a,
+ mpu-irq, mcasp3-axevt, 0x9d 0x97 0x128;
+};
I carry forward my TI internal objection to this approach:
NAK.
DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is
as follows:
hardware IP block -interrupt line- IRQ Cross bar - GIC IRQ line -- MPU
IRQ.
What we have done today for DRA is to provide IRQ numbers as direct maps
from hardware IP block to GIC based on default IRQ cross bar mapping.
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
Now, think of a product that wants to use UART10 instead of UART1, SoC
design allows you do that by doing a remapping of GIC interrupt to UART10 -
which is awesome.
Option 1: u-boot/bootloader
mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
Option 2: in kernel do a raw_writel version of option 1.
This patch does option 1 in kernel in a fancy way - why the heck would I
want to do that when u-boot allows me to do the same thing in uEnv.txt
Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
a) Allows us to define every single IP available on DRA7 SoC.
b) GIC allocation happens dynamically
c) allow products use IPs as needed.
Sorry, Conceptually option 3 is the right approach in my view.
instead of doing
uart1: serial@4806a000 {
snip
+interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH;
we should be able to do the following:
uart1: serial@4806a000 {
snip
+interrupts = TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH;
and not worry about the GIC interrupt number used
Since the cross-bar is not limited t0 IRQ lines and applicable for
DMA request lines as well, making it IRQ chip doesn't make sense. Its
not typical
