Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 12:21-20141210, Nishanth Menon wrote:
> On 12/09/2014 12:40 PM, Marc Zyngier wrote:
> > On 09/12/14 18:17, Nishanth Menon wrote:
> >> On 09:53-20141209, Marc Zyngier wrote:
> >>> On 08/12/14 22:41, Nishanth Menon wrote:
> >>>
> Anyways.. The following diff[1] on top of your branch makes DRA7 work - I
> assume you will squash as needed and repost with linux-omap mailing list
> in CC.
> >>>
> >>> Brilliant. I'll squash that into my tree and repost at some point.
> >>
> >> K, it will be nice to have a reflow of the series based on v3.19-rc1
> >> since there are dts dependencies and we dont want folks to have
> >> regressions on their platforms of choice..
> >>
> >> Obviously, my tests are basic boot tests and should get a few weeks(as
> >> you already mentioned) on linux-next to get properly soaked
> >>
> >>>
> I increased the scope of testing knowing that WUGEN is present in many
> A9 based TI platforms as well.. and at least OMAP4 showed flakiness in
> my testing.. Also a few notes:
>
> Stuff like: am437x is a bit questionable (interrupt-parent probably
> should be wugen?)
> 175: 0 GIC 39 tps65218
>
> OMAP5: (should be wugen?)
> 308: 4323 0 GIC 106 OMAP UART2
> 411: 0 0 GIC 151 twl6040
> 405: 1 0 GIC 39 palmas
> >>>
> >>> Well, I can't really tell. Someone with access to the documentation
> >>> should be able to find out.
> >>
> >> AM437x: http://www.ti.com/lit/pdf/spruhl7
> >> OMAP5: http://www.ti.com/lit/pdf/swpu249
> >>
> >> yeah, we should be able to do them as well - trivially since they follow
> >> the same structure as other SoCs without crossbar.
> >
> > Done some stuff in that department.
> >
> >>>
> OMAP4 serial port is flaky -> not sure if it is due to routing of GIC to
> UART2 and not via WUGEN
> IRQ branch: with my fix applied:
> -
> >>>
> >>> [...]
> >>>
> 18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not
> expected)
> 19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not
> expected)
> >>>
> >>> If I read the log correctly, the serial port stops responding after a
> >>> while?
> >>
> >> yeah - dug at the omap4 ones a bit, obviously once the deeper c states
> >> are hit, we'd like wakeupgen to wakeup CPU else we will be "sluggish" in
> >> the sense that the event is detected when some other wakeupgen enabled
> >> interrupt takes place.
> >
> > I realised that as well once I got a panda up and running.
> >
> >> Adding the following makes my panda work fine.
> >> 1: pandaboard-es: Boot PASS: http://slexy.org/raw/s20o8DaBvh
> >> 2: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s222JndDdh
> >>
> >>
> >> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> >> b/arch/arm/boot/dts/omap4-panda-common.dtsi
> >> index 1505135..8b6d50e 100644
> >> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> >> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> >> @@ -371,8 +371,8 @@
> >>twl: twl@48 {
> >>reg = <0x48>;
> >>/* IRQ# = 7 */
> >> - interrupts = ; /* IRQ_SYS_1N
> >> cascaded to gic */
> >> - interrupt-parent = <&gic>;
> >> + interrupts = ; /* IRQ_SYS_1N
> >> cascaded to wakeupgen to gic */
> >> + interrupt-parent = <&wakeupgen>;
> >>};
> >
> > [...]
> >
> > I already fixed those in my tree, in a slightly different way: no need
> > to have an interrupt parent at all, as we're going to inherit the
> > default anyway.
> >
> > I've pushed another version of the branch, with the crossbar rework
> > sitting *before* the WUGEN hacks. That should hopefully make bisection work.
> >
> > If you can give it a shake, that'd be most appreciated. I'll repost the
> > branch in a couple of days.
> >
>
> Did a quick run.. and thought of testing power management and found
> that CPUFreq for my platforms are broken in v3.18-rc7 and my scripts
> broke (so much for my cronjob testing daily boot... now I gotta add
> some PM test as well.. Sigh..) anyways.. just boot log..
>
> based on
> irq/die-gic-arch-extn-die-die-die c0024cb irqchip: gic: Drop support
> for gic_arch_extn
>
>
> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s201YeK4dW
> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20nydiyVx
> 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2aTrenePo
> 4: am437x-sk: Boot FAIL: http://slexy.org/raw/s20NNiEa4W
> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2gghhhyOy
> 6: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s2LY4Cb75N
> 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2e8iJMUXu
> 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20wqxUmvr
> 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s21I0g2Ba3
> 10: beaglebone: Boot PASS: http://slexy.org/raw/s2lpED0qW4
> 11: craneboard: Boot PASS: http://slexy.org/raw
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On Tue, Dec 09, 2014 at 06:40:35PM +, Marc Zyngier wrote:
> On 09/12/14 18:17, Nishanth Menon wrote:
> > On 09:53-20141209, Marc Zyngier wrote:
> >> On 08/12/14 22:41, Nishanth Menon wrote:
> >>
> >>> Anyways.. The following diff[1] on top of your branch makes DRA7 work - I
> >>> assume you will squash as needed and repost with linux-omap mailing list
> >>> in CC.
> >>
> >> Brilliant. I'll squash that into my tree and repost at some point.
> >
> > K, it will be nice to have a reflow of the series based on v3.19-rc1
> > since there are dts dependencies and we dont want folks to have
> > regressions on their platforms of choice..
> >
> > Obviously, my tests are basic boot tests and should get a few weeks(as
> > you already mentioned) on linux-next to get properly soaked
> >
> >>
> >>> I increased the scope of testing knowing that WUGEN is present in many
> >>> A9 based TI platforms as well.. and at least OMAP4 showed flakiness in
> >>> my testing.. Also a few notes:
> >>>
> >>> Stuff like: am437x is a bit questionable (interrupt-parent probably
> >>> should be wugen?)
> >>> 175: 0 GIC 39 tps65218
> >>>
> >>> OMAP5: (should be wugen?)
> >>> 308: 4323 0 GIC 106 OMAP UART2
> >>> 411: 0 0 GIC 151 twl6040
> >>> 405: 1 0 GIC 39 palmas
> >>
> >> Well, I can't really tell. Someone with access to the documentation
> >> should be able to find out.
> >
> > AM437x: http://www.ti.com/lit/pdf/spruhl7
> > OMAP5: http://www.ti.com/lit/pdf/swpu249
> >
> > yeah, we should be able to do them as well - trivially since they follow
> > the same structure as other SoCs without crossbar.
>
> Done some stuff in that department.
>
> >>
> >>> OMAP4 serial port is flaky -> not sure if it is due to routing of GIC to
> >>> UART2 and not via WUGEN
> >>> IRQ branch: with my fix applied:
> >>> -
> >>
> >> [...]
> >>
> >>> 18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not
> >>> expected)
> >>> 19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not
> >>> expected)
> >>
> >> If I read the log correctly, the serial port stops responding after a
> >> while?
> >
> > yeah - dug at the omap4 ones a bit, obviously once the deeper c states
> > are hit, we'd like wakeupgen to wakeup CPU else we will be "sluggish" in
> > the sense that the event is detected when some other wakeupgen enabled
> > interrupt takes place.
>
> I realised that as well once I got a panda up and running.
>
> > Adding the following makes my panda work fine.
> > 1: pandaboard-es: Boot PASS: http://slexy.org/raw/s20o8DaBvh
> > 2: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s222JndDdh
> >
> >
> > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> > b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > index 1505135..8b6d50e 100644
> > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > @@ -371,8 +371,8 @@
> > twl: twl@48 {
> > reg = <0x48>;
> > /* IRQ# = 7 */
> > - interrupts = ; /* IRQ_SYS_1N
> > cascaded to gic */
> > - interrupt-parent = <&gic>;
> > + interrupts = ; /* IRQ_SYS_1N
> > cascaded to wakeupgen to gic */
> > + interrupt-parent = <&wakeupgen>;
> > };
>
> [...]
>
> I already fixed those in my tree, in a slightly different way: no need
> to have an interrupt parent at all, as we're going to inherit the
> default anyway.
>
> I've pushed another version of the branch, with the crossbar rework
> sitting *before* the WUGEN hacks. That should hopefully make bisection work.
>
> If you can give it a shake, that'd be most appreciated. I'll repost the
> branch in a couple of days.
Hmmm, I'm sensing a pattern here :) My email, only to the MLs, was
messed up for a few days. I probably missed it in there...
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 12/09/2014 12:40 PM, Marc Zyngier wrote:
> On 09/12/14 18:17, Nishanth Menon wrote:
>> On 09:53-20141209, Marc Zyngier wrote:
>>> On 08/12/14 22:41, Nishanth Menon wrote:
>>>
Anyways.. The following diff[1] on top of your branch makes DRA7 work - I
assume you will squash as needed and repost with linux-omap mailing list
in CC.
>>>
>>> Brilliant. I'll squash that into my tree and repost at some point.
>>
>> K, it will be nice to have a reflow of the series based on v3.19-rc1
>> since there are dts dependencies and we dont want folks to have
>> regressions on their platforms of choice..
>>
>> Obviously, my tests are basic boot tests and should get a few weeks(as
>> you already mentioned) on linux-next to get properly soaked
>>
>>>
I increased the scope of testing knowing that WUGEN is present in many
A9 based TI platforms as well.. and at least OMAP4 showed flakiness in
my testing.. Also a few notes:
Stuff like: am437x is a bit questionable (interrupt-parent probably should
be wugen?)
175: 0 GIC 39 tps65218
OMAP5: (should be wugen?)
308: 4323 0 GIC 106 OMAP UART2
411: 0 0 GIC 151 twl6040
405: 1 0 GIC 39 palmas
>>>
>>> Well, I can't really tell. Someone with access to the documentation
>>> should be able to find out.
>>
>> AM437x: http://www.ti.com/lit/pdf/spruhl7
>> OMAP5: http://www.ti.com/lit/pdf/swpu249
>>
>> yeah, we should be able to do them as well - trivially since they follow
>> the same structure as other SoCs without crossbar.
>
> Done some stuff in that department.
>
>>>
OMAP4 serial port is flaky -> not sure if it is due to routing of GIC to
UART2 and not via WUGEN
IRQ branch: with my fix applied:
-
>>>
>>> [...]
>>>
18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not
expected)
19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not
expected)
>>>
>>> If I read the log correctly, the serial port stops responding after a while?
>>
>> yeah - dug at the omap4 ones a bit, obviously once the deeper c states
>> are hit, we'd like wakeupgen to wakeup CPU else we will be "sluggish" in
>> the sense that the event is detected when some other wakeupgen enabled
>> interrupt takes place.
>
> I realised that as well once I got a panda up and running.
>
>> Adding the following makes my panda work fine.
>> 1: pandaboard-es: Boot PASS: http://slexy.org/raw/s20o8DaBvh
>> 2: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s222JndDdh
>>
>>
>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> index 1505135..8b6d50e 100644
>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> @@ -371,8 +371,8 @@
>> twl: twl@48 {
>> reg = <0x48>;
>> /* IRQ# = 7 */
>> -interrupts = ; /* IRQ_SYS_1N
>> cascaded to gic */
>> -interrupt-parent = <&gic>;
>> +interrupts = ; /* IRQ_SYS_1N
>> cascaded to wakeupgen to gic */
>> +interrupt-parent = <&wakeupgen>;
>> };
>
> [...]
>
> I already fixed those in my tree, in a slightly different way: no need
> to have an interrupt parent at all, as we're going to inherit the
> default anyway.
>
> I've pushed another version of the branch, with the crossbar rework
> sitting *before* the WUGEN hacks. That should hopefully make bisection work.
>
> If you can give it a shake, that'd be most appreciated. I'll repost the
> branch in a couple of days.
>
Did a quick run.. and thought of testing power management and found
that CPUFreq for my platforms are broken in v3.18-rc7 and my scripts
broke (so much for my cronjob testing daily boot... now I gotta add
some PM test as well.. Sigh..) anyways.. just boot log..
based on
irq/die-gic-arch-extn-die-die-die c0024cb irqchip: gic: Drop support
for gic_arch_extn
1: am335x-evm: Boot PASS: http://slexy.org/raw/s201YeK4dW
2: am335x-sk: Boot PASS: http://slexy.org/raw/s20nydiyVx
3: am3517-evm: Boot PASS: http://slexy.org/raw/s2aTrenePo
4: am437x-sk: Boot FAIL: http://slexy.org/raw/s20NNiEa4W
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2gghhhyOy
6: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s2LY4Cb75N
7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2e8iJMUXu
8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20wqxUmvr
9: beaglebone-black: Boot PASS: http://slexy.org/raw/s21I0g2Ba3
10: beaglebone: Boot PASS: http://slexy.org/raw/s2lpED0qW4
11: craneboard: Boot PASS: http://slexy.org/raw/s230RKflY3
12: dra72x-evm: Boot FAIL: http://slexy.org/raw/s21fWVnjaB
13: dra7xx-evm: Boot PASS: http://slexy.org/raw/s20yEhfruO
14: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s20qZaXwz0
15: n900: Boot PASS: http://slexy.org/raw/s21LNTXZP7
16: omap5
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 09/12/14 18:17, Nishanth Menon wrote:
> On 09:53-20141209, Marc Zyngier wrote:
>> On 08/12/14 22:41, Nishanth Menon wrote:
>>
>>> Anyways.. The following diff[1] on top of your branch makes DRA7 work - I
>>> assume you will squash as needed and repost with linux-omap mailing list
>>> in CC.
>>
>> Brilliant. I'll squash that into my tree and repost at some point.
>
> K, it will be nice to have a reflow of the series based on v3.19-rc1
> since there are dts dependencies and we dont want folks to have
> regressions on their platforms of choice..
>
> Obviously, my tests are basic boot tests and should get a few weeks(as
> you already mentioned) on linux-next to get properly soaked
>
>>
>>> I increased the scope of testing knowing that WUGEN is present in many
>>> A9 based TI platforms as well.. and at least OMAP4 showed flakiness in
>>> my testing.. Also a few notes:
>>>
>>> Stuff like: am437x is a bit questionable (interrupt-parent probably should
>>> be wugen?)
>>> 175: 0 GIC 39 tps65218
>>>
>>> OMAP5: (should be wugen?)
>>> 308: 4323 0 GIC 106 OMAP UART2
>>> 411: 0 0 GIC 151 twl6040
>>> 405: 1 0 GIC 39 palmas
>>
>> Well, I can't really tell. Someone with access to the documentation
>> should be able to find out.
>
> AM437x: http://www.ti.com/lit/pdf/spruhl7
> OMAP5: http://www.ti.com/lit/pdf/swpu249
>
> yeah, we should be able to do them as well - trivially since they follow
> the same structure as other SoCs without crossbar.
Done some stuff in that department.
>>
>>> OMAP4 serial port is flaky -> not sure if it is due to routing of GIC to
>>> UART2 and not via WUGEN
>>> IRQ branch: with my fix applied:
>>> -
>>
>> [...]
>>
>>> 18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not
>>> expected)
>>> 19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not
>>> expected)
>>
>> If I read the log correctly, the serial port stops responding after a while?
>
> yeah - dug at the omap4 ones a bit, obviously once the deeper c states
> are hit, we'd like wakeupgen to wakeup CPU else we will be "sluggish" in
> the sense that the event is detected when some other wakeupgen enabled
> interrupt takes place.
I realised that as well once I got a panda up and running.
> Adding the following makes my panda work fine.
> 1: pandaboard-es: Boot PASS: http://slexy.org/raw/s20o8DaBvh
> 2: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s222JndDdh
>
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 1505135..8b6d50e 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -371,8 +371,8 @@
> twl: twl@48 {
> reg = <0x48>;
> /* IRQ# = 7 */
> - interrupts = ; /* IRQ_SYS_1N
> cascaded to gic */
> - interrupt-parent = <&gic>;
> + interrupts = ; /* IRQ_SYS_1N
> cascaded to wakeupgen to gic */
> + interrupt-parent = <&wakeupgen>;
> };
[...]
I already fixed those in my tree, in a slightly different way: no need
to have an interrupt parent at all, as we're going to inherit the
default anyway.
I've pushed another version of the branch, with the crossbar rework
sitting *before* the WUGEN hacks. That should hopefully make bisection work.
If you can give it a shake, that'd be most appreciated. I'll repost the
branch in a couple of days.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 09:53-20141209, Marc Zyngier wrote:
> On 08/12/14 22:41, Nishanth Menon wrote:
>
> > Anyways.. The following diff[1] on top of your branch makes DRA7 work - I
> > assume you will squash as needed and repost with linux-omap mailing list
> > in CC.
>
> Brilliant. I'll squash that into my tree and repost at some point.
K, it will be nice to have a reflow of the series based on v3.19-rc1
since there are dts dependencies and we dont want folks to have
regressions on their platforms of choice..
Obviously, my tests are basic boot tests and should get a few weeks(as
you already mentioned) on linux-next to get properly soaked
>
> > I increased the scope of testing knowing that WUGEN is present in many
> > A9 based TI platforms as well.. and at least OMAP4 showed flakiness in
> > my testing.. Also a few notes:
> >
> > Stuff like: am437x is a bit questionable (interrupt-parent probably should
> > be wugen?)
> > 175: 0 GIC 39 tps65218
> >
> > OMAP5: (should be wugen?)
> > 308: 4323 0 GIC 106 OMAP UART2
> > 411: 0 0 GIC 151 twl6040
> > 405: 1 0 GIC 39 palmas
>
> Well, I can't really tell. Someone with access to the documentation
> should be able to find out.
AM437x: http://www.ti.com/lit/pdf/spruhl7
OMAP5: http://www.ti.com/lit/pdf/swpu249
yeah, we should be able to do them as well - trivially since they follow
the same structure as other SoCs without crossbar.
>
> > OMAP4 serial port is flaky -> not sure if it is due to routing of GIC to
> > UART2 and not via WUGEN
> > IRQ branch: with my fix applied:
> > -
>
> [...]
>
> > 18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not
> > expected)
> > 19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not
> > expected)
>
> If I read the log correctly, the serial port stops responding after a while?
yeah - dug at the omap4 ones a bit, obviously once the deeper c states
are hit, we'd like wakeupgen to wakeup CPU else we will be "sluggish" in
the sense that the event is detected when some other wakeupgen enabled
interrupt takes place.
Adding the following makes my panda work fine.
1: pandaboard-es: Boot PASS: http://slexy.org/raw/s20o8DaBvh
2: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s222JndDdh
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 1505135..8b6d50e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -371,8 +371,8 @@
twl: twl@48 {
reg = <0x48>;
/* IRQ# = 7 */
- interrupts = ; /* IRQ_SYS_1N
cascaded to gic */
- interrupt-parent = <&gic>;
+ interrupts = ; /* IRQ_SYS_1N
cascaded to wakeupgen to gic */
+ interrupt-parent = <&wakeupgen>;
};
twl6040: twl@4b {
@@ -383,8 +383,8 @@
pinctrl-0 = <&twl6040_pins>;
/* IRQ# = 119 */
- interrupts = ; /* IRQ_SYS_2N
cascaded to gic */
- interrupt-parent = <&gic>;
+ interrupts = ; /* IRQ_SYS_2N
cascaded to wakeupgen to gic */
+ interrupt-parent = <&wakeupgen>;
ti,audpwron-gpio = <&gpio4 31 GPIO_ACTIVE_HIGH>; /* gpio line
127 */
vio-supply = <&v1v8>;
@@ -479,17 +479,17 @@
};
&uart2 {
- interrupts-extended = <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH
+ interrupts-extended = <&wakeupgen GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH
&omap4_pmx_core OMAP4_UART2_RX>;
};
&uart3 {
- interrupts-extended = <&gic GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH
+ interrupts-extended = <&wakeupgen GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH
&omap4_pmx_core OMAP4_UART3_RX>;
};
&uart4 {
- interrupts-extended = <&gic GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH
+ interrupts-extended = <&wakeupgen GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH
&omap4_pmx_core OMAP4_UART4_RX>;
};
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 08/12/14 22:41, Nishanth Menon wrote: > Anyways.. The following diff[1] on top of your branch makes DRA7 work - I > assume you will squash as needed and repost with linux-omap mailing list > in CC. Brilliant. I'll squash that into my tree and repost at some point. > I increased the scope of testing knowing that WUGEN is present in many > A9 based TI platforms as well.. and at least OMAP4 showed flakiness in > my testing.. Also a few notes: > > Stuff like: am437x is a bit questionable (interrupt-parent probably should be > wugen?) > 175: 0 GIC 39 tps65218 > > OMAP5: (should be wugen?) > 308: 4323 0 GIC 106 OMAP UART2 > 411: 0 0 GIC 151 twl6040 > 405: 1 0 GIC 39 palmas Well, I can't really tell. Someone with access to the documentation should be able to find out. > OMAP4 serial port is flaky -> not sure if it is due to routing of GIC to > UART2 and not via WUGEN > IRQ branch: with my fix applied: > - [...] > 18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not expected) > 19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not > expected) If I read the log correctly, the serial port stops responding after a while? [...] > I suggest skipping 3.19 if possible and giving it a more detailed time > in linux-next with omap4 etc being more thoroughly being tested before > letting it through, if possible. None of that code is for 3.19 (that ship has sailed a long time ago). My plan is to hit 3.20, so it should be in -next by -rc4 or so. > [1] - diff > arch/arm/boot/dts/dra7-evm.dts |2 +- > arch/arm/boot/dts/dra7.dtsi| 23 +-- > drivers/irqchip/irq-crossbar.c |4 ++-- > 3 files changed, 16 insertions(+), 13 deletions(-) > > diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts > index c6ce625..d024429 100644 > --- a/arch/arm/boot/dts/dra7-evm.dts > +++ b/arch/arm/boot/dts/dra7-evm.dts > @@ -323,7 +323,7 @@ > status = "okay"; > pinctrl-names = "default"; > pinctrl-0 = <&uart1_pins>; > - interrupts-extended = <&gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>, > + interrupts-extended = <&crossbar_mpu GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>, > <&dra7_pmx_core 0x3e0>; > }; Ah, I obviously missed quite a few of these... [...] > diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c > index b44915a..f7daff0 100644 > --- a/drivers/irqchip/irq-crossbar.c > +++ b/drivers/irqchip/irq-crossbar.c > @@ -99,7 +99,7 @@ static int allocate_gic_irq(struct irq_domain *domain, > unsigned virq, > if (err) > cb->irq_map[i] = IRQ_FREE; > else > - cb->write(hwirq, i); > + cb->write(i, hwirq); > > return err; > } > @@ -353,4 +353,4 @@ static int __init irqcrossbar_init(struct device_node > *node, > return 0; > } > > -IRQCHIP_DECLARE(ti_irqcrossbar, "ti,irqcrossbar", irqcrossbar_init); > +IRQCHIP_DECLARE(ti_irqcrossbar, "ti,irq-crossbar", irqcrossbar_init); Ah, nice catch. Thanks a lot for the testing and the fixes. I'll try to get a panda up and running (I'm sure I have one collecting dust somewhere), and see if I can get it to behave. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 09:10-20141208, Marc Zyngier wrote: > On 07/12/14 18:03, Nishanth Menon wrote: [..] > > dra7xx-evm(3.18-rc7): Boot PASS: http://slexy.org/raw/s2PXWFB47A > > dra7xx-evm(irq branch): Boot FAIL: http://slexy.org/raw/s2xMgD4zkP > > > > Would you want me to debug more - dts changes perhaps? > > Yes, it would be useful to find out. One thing that strikes me is that > the kernel boots all the way, so I assume IRQs are actually up and running. Nope, we dont usually need peripheral interrupts untill we use them.. mmc is the first to use it, followed by serial port of course :).. > > One thing though. The "irq" branch shows this: > [ 15.359025] pbias_mmc_omap5: disabling > > and the MMC subsystem never initializes. I'm pretty sure this is > related. Config option? nope. just the request mmc card was never detected (crossbar was misconfigured) Anyways.. The following diff[1] on top of your branch makes DRA7 work - I assume you will squash as needed and repost with linux-omap mailing list in CC. I increased the scope of testing knowing that WUGEN is present in many A9 based TI platforms as well.. and at least OMAP4 showed flakiness in my testing.. Also a few notes: Stuff like: am437x is a bit questionable (interrupt-parent probably should be wugen?) 175: 0 GIC 39 tps65218 OMAP5: (should be wugen?) 308: 4323 0 GIC 106 OMAP UART2 411: 0 0 GIC 151 twl6040 405: 1 0 GIC 39 palmas OMAP4 serial port is flaky -> not sure if it is due to routing of GIC to UART2 and not via WUGEN IRQ branch: with my fix applied: - 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2aN42JkKi 2: am335x-sk: Boot PASS: http://slexy.org/raw/s21w2OG3hL 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21Tlp6ZLq 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21Vqp6P1B 5: am437x-sk: Boot PASS: http://slexy.org/raw/s2UhY45mJc 6: am43xx-epos: Boot PASS: http://slexy.org/raw/s20l5l2fj4 7: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s2aRwhAtau 8: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2GbGmM7xU 9: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s209bMoHPd 10: beaglebone-black: Boot PASS: http://slexy.org/raw/s2IzmRPyVI 11: beaglebone: Boot PASS: http://slexy.org/raw/s2053lNp5G 12: craneboard: Boot PASS: http://slexy.org/raw/s2kKkEoR4A 13: dra72x-evm: Boot FAIL: http://slexy.org/raw/s21jb0oCBm (this one is known -> mmc node is missing) 14: dra7xx-evm: Boot PASS: http://slexy.org/raw/s2ho2KH2rh 15: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s21U4McCJp 16: n900: Boot PASS: http://slexy.org/raw/s2Np9wQrYd 17: omap5-evm: Boot PASS: http://slexy.org/raw/s21Dd4tS2M 18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not expected) 19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not expected) 20:sdp2430: Boot PASS: http://slexy.org/raw/s21AygxGRg 21:sdp3430: Boot PASS: http://slexy.org/raw/s207290wN9 TOTAL = 21 boards, Booted Boards = 18, No Boot boards = 3 comparitive reference v3.18-rc7: 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2ASdqrwQx 2: am335x-sk: Boot PASS: http://slexy.org/raw/s208zUIeql 3: am3517-evm: Boot PASS: http://slexy.org/raw/s20dx70o4a 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20qKJVqIQ (ignore this: board farm issue/PMIC power script issue - unrelated and known). 5: am437x-sk: Boot PASS: http://slexy.org/raw/s20K8unGsM 6: am43xx-epos: Boot PASS: http://slexy.org/raw/s21hPfz6DC 7: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s2voHleSYO 8: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s208GPH7nx 9: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20jOW13Ig 10: beaglebone-black: Boot PASS: http://slexy.org/raw/s2I60jGnCI 11: beaglebone: Boot PASS: http://slexy.org/raw/s29u4NiShX 12: craneboard: Boot PASS: http://slexy.org/raw/s2T7etBuGm 13: dra72x-evm: Boot FAIL: http://slexy.org/raw/s21dmHgoXn (known issue - mmc node is missing) 14: dra7xx-evm: Boot PASS: http://slexy.org/raw/s21cFgrB0f 15: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2FBPPQ3ML 16: n900: Boot PASS: http://slexy.org/raw/s2RmlkVWvN 17: omap5-evm: Boot PASS: http://slexy.org/raw/s2YKl1szpz 18: pandaboard-es: Boot PASS: http://slexy.org/raw/s2hvXLDMoS 19: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2056IOHsT 20:sdp2430: Boot PASS: http://slexy.org/raw/s2PYPNr7jm 21:sdp3430: Boot PASS: http://slexy.org/raw/s2Iyc9K8I6 TOTAL = 21 boards, Booted Boards = 19, No Boot boards = 2 I suggest skipping 3.19 if possible and giving it a more detailed time in linux-next with omap4 etc being more thoroughly being tested before letting it through, if possible. [1] - diff arch/arm/boot/dts/dra7-evm.dts |2 +- arch/arm/boot/dts/dra7.dtsi| 23 +-- drivers/irqchip/irq-crossbar.c |
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 07/12/14 18:03, Nishanth Menon wrote: > Marc, > > On 11:16-20141207, Nishanth Menon wrote: >> On 13:46-20141206, Marc Zyngier wrote: >>> After my series removing the gic_arch_extn hack, I figured that the >>> next step was to expunge the GIC driver of the routable domain horror. >>> >>> There is a few reasons for this: >>> >>> - The allocation of interrupts in this domain is fairly similar to >>> what we do for MSI (see the GICv2m driver), and stacked domains have >>> proved to be a fitting solution. >>> >>> - The current description in DT is currently entierely inaccurate, and >>> as we already broke it for the OMAP WUGEN block, we might as well do >>> it again for the TI crossbar. >>> >>> - The way crossbar, WUGEN and GIC interract is quite complex (this is >>> effectively a stack of three interrupt controllers with interesting >>> exceptions and braindead routing), and stacked domains are the right >>> abstraction for that. >>> >>> - Other platforms (Freescale Vybrid) are starting to come up with the >>> same type of things, and it'd be good to avoid them following the >>> same broken model. >>> >>> - It removes a few lines from the code base so it can't completely be >>> a bad idea! >>> >>> So this patch series does exactly that: make the crossbar a stacked >>> interrupt controller that only takes care of setting up the routing, >>> fix the DTs to represent the actual HW, and remove a bit of the >>> craziness from the GIC code. >>> >>> As for the previous series: >>> >>> - I haven't been able to test this at all, I don't have access to the >>> HW. TI people, please test and post fixes, as I expect I introduced >>> a few bugs. >>> >>> - This actively *breaks* existing setups. If you boot a new kernel >>> with an old DT, interrupt routing *will* be broken. Old kernels on a >>> new DT won't boot either! You've been warned. This really outline >>> the necessity of actually describing the HW in device trees... >>> >>> As for the patches, they are on top of 3.18-rc7 + tip/irq/irqdomain-arm + >>> the gic_arch_extn removal series. >>> >>> I've pushed the code to: >>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git >>> irq/die-gic-arch-extn-die-die-die >>> >>> Comments welcome, >>> >>> M. >>> >>> Marc Zyngier (5): >>> genirq: Add irqchip_set_wake_parent >>> irqchip: crossbar: convert dra7 crossbar to stacked domains >>> DT: update ti,irq-crossbar binding >>> irqchip: GIC: get rid of routable domain >>> DT: arm,gic: kill arm,routable-irqs >>> >>> Documentation/devicetree/bindings/arm/gic.txt | 6 - >>> .../devicetree/bindings/arm/omap/crossbar.txt | 18 +- >>> arch/arm/boot/dts/dra7.dtsi| 10 +- >>> arch/arm/boot/dts/dra72x.dtsi | 3 +- >>> arch/arm/boot/dts/dra74x.dtsi | 5 +- >>> arch/arm/mach-omap2/omap4-common.c | 4 - >>> drivers/irqchip/irq-crossbar.c | 202 >>> - >>> drivers/irqchip/irq-gic.c | 59 +- >>> include/linux/irq.h| 1 + >>> include/linux/irqchip/arm-gic.h| 6 - >>> include/linux/irqchip/irq-crossbar.h | 11 -- >>> kernel/irq/chip.c | 16 ++ >>> 12 files changed, 153 insertions(+), 188 deletions(-) >>> delete mode 100644 include/linux/irqchip/irq-crossbar.h >>> >>> -- >>> 2.1.3 >>> >> >> Patches are available here: >> https://patchwork.kernel.org/patch/5449231/ >> https://patchwork.kernel.org/patch/5449241/ >> https://patchwork.kernel.org/patch/5449271/ >> https://patchwork.kernel.org/patch/5449261/ >> https://patchwork.kernel.org/patch/5449251/ > > dra7xx-evm(3.18-rc7): Boot PASS: http://slexy.org/raw/s2PXWFB47A > dra7xx-evm(irq branch): Boot FAIL: http://slexy.org/raw/s2xMgD4zkP > > Would you want me to debug more - dts changes perhaps? Yes, it would be useful to find out. One thing that strikes me is that the kernel boots all the way, so I assume IRQs are actually up and running. One thing though. The "irq" branch shows this: [ 15.359025] pbias_mmc_omap5: disabling and the MMC subsystem never initializes. I'm pretty sure this is related. Config option? Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
Marc, On 11:16-20141207, Nishanth Menon wrote: > On 13:46-20141206, Marc Zyngier wrote: > > After my series removing the gic_arch_extn hack, I figured that the > > next step was to expunge the GIC driver of the routable domain horror. > > > > There is a few reasons for this: > > > > - The allocation of interrupts in this domain is fairly similar to > > what we do for MSI (see the GICv2m driver), and stacked domains have > > proved to be a fitting solution. > > > > - The current description in DT is currently entierely inaccurate, and > > as we already broke it for the OMAP WUGEN block, we might as well do > > it again for the TI crossbar. > > > > - The way crossbar, WUGEN and GIC interract is quite complex (this is > > effectively a stack of three interrupt controllers with interesting > > exceptions and braindead routing), and stacked domains are the right > > abstraction for that. > > > > - Other platforms (Freescale Vybrid) are starting to come up with the > > same type of things, and it'd be good to avoid them following the > > same broken model. > > > > - It removes a few lines from the code base so it can't completely be > > a bad idea! > > > > So this patch series does exactly that: make the crossbar a stacked > > interrupt controller that only takes care of setting up the routing, > > fix the DTs to represent the actual HW, and remove a bit of the > > craziness from the GIC code. > > > > As for the previous series: > > > > - I haven't been able to test this at all, I don't have access to the > > HW. TI people, please test and post fixes, as I expect I introduced > > a few bugs. > > > > - This actively *breaks* existing setups. If you boot a new kernel > > with an old DT, interrupt routing *will* be broken. Old kernels on a > > new DT won't boot either! You've been warned. This really outline > > the necessity of actually describing the HW in device trees... > > > > As for the patches, they are on top of 3.18-rc7 + tip/irq/irqdomain-arm + > > the gic_arch_extn removal series. > > > > I've pushed the code to: > > git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git > > irq/die-gic-arch-extn-die-die-die > > > > Comments welcome, > > > > M. > > > > Marc Zyngier (5): > > genirq: Add irqchip_set_wake_parent > > irqchip: crossbar: convert dra7 crossbar to stacked domains > > DT: update ti,irq-crossbar binding > > irqchip: GIC: get rid of routable domain > > DT: arm,gic: kill arm,routable-irqs > > > > Documentation/devicetree/bindings/arm/gic.txt | 6 - > > .../devicetree/bindings/arm/omap/crossbar.txt | 18 +- > > arch/arm/boot/dts/dra7.dtsi| 10 +- > > arch/arm/boot/dts/dra72x.dtsi | 3 +- > > arch/arm/boot/dts/dra74x.dtsi | 5 +- > > arch/arm/mach-omap2/omap4-common.c | 4 - > > drivers/irqchip/irq-crossbar.c | 202 > > - > > drivers/irqchip/irq-gic.c | 59 +- > > include/linux/irq.h| 1 + > > include/linux/irqchip/arm-gic.h| 6 - > > include/linux/irqchip/irq-crossbar.h | 11 -- > > kernel/irq/chip.c | 16 ++ > > 12 files changed, 153 insertions(+), 188 deletions(-) > > delete mode 100644 include/linux/irqchip/irq-crossbar.h > > > > -- > > 2.1.3 > > > > Patches are available here: > https://patchwork.kernel.org/patch/5449231/ > https://patchwork.kernel.org/patch/5449241/ > https://patchwork.kernel.org/patch/5449271/ > https://patchwork.kernel.org/patch/5449261/ > https://patchwork.kernel.org/patch/5449251/ dra7xx-evm(3.18-rc7): Boot PASS: http://slexy.org/raw/s2PXWFB47A dra7xx-evm(irq branch): Boot FAIL: http://slexy.org/raw/s2xMgD4zkP Would you want me to debug more - dts changes perhaps? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 13:46-20141206, Marc Zyngier wrote: > After my series removing the gic_arch_extn hack, I figured that the > next step was to expunge the GIC driver of the routable domain horror. > > There is a few reasons for this: > > - The allocation of interrupts in this domain is fairly similar to > what we do for MSI (see the GICv2m driver), and stacked domains have > proved to be a fitting solution. > > - The current description in DT is currently entierely inaccurate, and > as we already broke it for the OMAP WUGEN block, we might as well do > it again for the TI crossbar. > > - The way crossbar, WUGEN and GIC interract is quite complex (this is > effectively a stack of three interrupt controllers with interesting > exceptions and braindead routing), and stacked domains are the right > abstraction for that. > > - Other platforms (Freescale Vybrid) are starting to come up with the > same type of things, and it'd be good to avoid them following the > same broken model. > > - It removes a few lines from the code base so it can't completely be > a bad idea! > > So this patch series does exactly that: make the crossbar a stacked > interrupt controller that only takes care of setting up the routing, > fix the DTs to represent the actual HW, and remove a bit of the > craziness from the GIC code. > > As for the previous series: > > - I haven't been able to test this at all, I don't have access to the > HW. TI people, please test and post fixes, as I expect I introduced > a few bugs. > > - This actively *breaks* existing setups. If you boot a new kernel > with an old DT, interrupt routing *will* be broken. Old kernels on a > new DT won't boot either! You've been warned. This really outline > the necessity of actually describing the HW in device trees... > > As for the patches, they are on top of 3.18-rc7 + tip/irq/irqdomain-arm + > the gic_arch_extn removal series. > > I've pushed the code to: > git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git > irq/die-gic-arch-extn-die-die-die > > Comments welcome, > >M. > > Marc Zyngier (5): > genirq: Add irqchip_set_wake_parent > irqchip: crossbar: convert dra7 crossbar to stacked domains > DT: update ti,irq-crossbar binding > irqchip: GIC: get rid of routable domain > DT: arm,gic: kill arm,routable-irqs > > Documentation/devicetree/bindings/arm/gic.txt | 6 - > .../devicetree/bindings/arm/omap/crossbar.txt | 18 +- > arch/arm/boot/dts/dra7.dtsi| 10 +- > arch/arm/boot/dts/dra72x.dtsi | 3 +- > arch/arm/boot/dts/dra74x.dtsi | 5 +- > arch/arm/mach-omap2/omap4-common.c | 4 - > drivers/irqchip/irq-crossbar.c | 202 > - > drivers/irqchip/irq-gic.c | 59 +- > include/linux/irq.h| 1 + > include/linux/irqchip/arm-gic.h| 6 - > include/linux/irqchip/irq-crossbar.h | 11 -- > kernel/irq/chip.c | 16 ++ > 12 files changed, 153 insertions(+), 188 deletions(-) > delete mode 100644 include/linux/irqchip/irq-crossbar.h > > -- > 2.1.3 > Patches are available here: https://patchwork.kernel.org/patch/5449231/ https://patchwork.kernel.org/patch/5449241/ https://patchwork.kernel.org/patch/5449271/ https://patchwork.kernel.org/patch/5449261/ https://patchwork.kernel.org/patch/5449251/ -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
