Message ID | 5165CED4.1040800@ti.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
* Jon Hunter <jon-hunter@ti.com> [130410 13:47]: > > On 04/10/2013 01:20 PM, Tony Lindgren wrote: > > * Jon Hunter <jon-hunter@ti.com> [130410 10:35]: > >> Hi Tony, > >> > >> On 04/09/2013 04:23 PM, Tony Lindgren wrote: > >>> Hi Jon, > >>> > >>> Looks like at least 4430sdp nfsroot got broken with commit > >>> ff5c9059 (ARM: dts: OMAP3+: Correct gpio #interrupts-cells > >>> property). > >> > >> Thanks for reporting. I am actually amazed that ethernet is > >> working on any OMAP board (with device-tree) that requires a > >> gpio as an interrupt because we have still not come to an > >> agreement on [1]. Looking at the OMAP4 SDP I believe this is > >> working by luck because there are other gpios in the same > >> bank that are active and so the bank is enabled. If that were > >> not the case then this would not work. > >> > >> Hence, I have not been testing ethernet when booting with > >> device-tree because we need to fix [1] which has been really > >> crippling my testing. So this needs to be resolved so ethernet > >> can work consistently on all omap boards. > > > > Cool. > > > >>> Do we need to pass the GPIO edge/level info now? > >> > >> Yes and here is a patch. I have tested on my OMAP4 SDP this > >> morning. Reviewing all the OMAP/AM dts(i) files I believe > >> that only the SDP and OMAP4-VAR-SOM are impacted by this. I > >> don't see any other boards currently using the gpio as an > >> interrupt-controller. > > > > Great. Just one comment: You might be able to already use > > the DT preprocessor now easily with linux next for the edge > > info. > > Good idea. We could do something like the below, but it would > be better to include the "arm-gic.h" from the omap4.dtsi file > so that the definitions can be used there too. The problem is > that if I include "arm-gic.h" in the omap4.dtsi file I get a > DTC compiler error because of the "#include" statement. It > appears that the compiler does not like it if a file includes > a file using "/include/" and the file it is including uses > "#include". So really I think that we need to switch all the > dts/dtsi files to use "#include" first. OK maybe note that in the description too. Also, is there need to back port these two patches to v3.9-rc? If nobody has noticed, I guess not? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/10/2013 03:54 PM, Tony Lindgren wrote: > * Jon Hunter <jon-hunter@ti.com> [130410 13:47]: >> >> On 04/10/2013 01:20 PM, Tony Lindgren wrote: >>> * Jon Hunter <jon-hunter@ti.com> [130410 10:35]: >>>> Hi Tony, >>>> >>>> On 04/09/2013 04:23 PM, Tony Lindgren wrote: >>>>> Hi Jon, >>>>> >>>>> Looks like at least 4430sdp nfsroot got broken with commit >>>>> ff5c9059 (ARM: dts: OMAP3+: Correct gpio #interrupts-cells >>>>> property). >>>> >>>> Thanks for reporting. I am actually amazed that ethernet is >>>> working on any OMAP board (with device-tree) that requires a >>>> gpio as an interrupt because we have still not come to an >>>> agreement on [1]. Looking at the OMAP4 SDP I believe this is >>>> working by luck because there are other gpios in the same >>>> bank that are active and so the bank is enabled. If that were >>>> not the case then this would not work. >>>> >>>> Hence, I have not been testing ethernet when booting with >>>> device-tree because we need to fix [1] which has been really >>>> crippling my testing. So this needs to be resolved so ethernet >>>> can work consistently on all omap boards. >>> >>> Cool. >>> >>>>> Do we need to pass the GPIO edge/level info now? >>>> >>>> Yes and here is a patch. I have tested on my OMAP4 SDP this >>>> morning. Reviewing all the OMAP/AM dts(i) files I believe >>>> that only the SDP and OMAP4-VAR-SOM are impacted by this. I >>>> don't see any other boards currently using the gpio as an >>>> interrupt-controller. >>> >>> Great. Just one comment: You might be able to already use >>> the DT preprocessor now easily with linux next for the edge >>> info. >> >> Good idea. We could do something like the below, but it would >> be better to include the "arm-gic.h" from the omap4.dtsi file >> so that the definitions can be used there too. The problem is >> that if I include "arm-gic.h" in the omap4.dtsi file I get a >> DTC compiler error because of the "#include" statement. It >> appears that the compiler does not like it if a file includes >> a file using "/include/" and the file it is including uses >> "#include". So really I think that we need to switch all the >> dts/dtsi files to use "#include" first. > > OK maybe note that in the description too. Are you saying that you want to use the version with that is using the pre-processor definitions? I was thinking that may be we could do that as a clean-up for v3.11 and just use the original version I posted earlier. Seems cleaner to me. > Also, is there need to back port these two patches to v3.9-rc? > If nobody has noticed, I guess not? This should only be applicable to v3.10 so no need to backport. Or are you saying that you are seeing this with v3.9 also? That would be odd. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Jon Hunter <jon-hunter@ti.com> [130410 15:30]: > > Are you saying that you want to use the version with that is using the > pre-processor definitions? I was thinking that may be we could do that > as a clean-up for v3.11 and just use the original version I posted > earlier. Seems cleaner to me. No let's do that the preprocessor conversion for v3.11. > > Also, is there need to back port these two patches to v3.9-rc? > > If nobody has noticed, I guess not? > > This should only be applicable to v3.10 so no need to backport. Or are > you saying that you are seeing this with v3.9 also? That would be odd. Not seeing it in v3.9, but I was wondering if it's lurking there too in some format. But I guess not. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tony Lindgren <tony@atomide.com> [130410 15:32]: > * Jon Hunter <jon-hunter@ti.com> [130410 15:30]: > > > > Are you saying that you want to use the version with that is using the > > pre-processor definitions? I was thinking that may be we could do that > > as a clean-up for v3.11 and just use the original version I posted > > earlier. Seems cleaner to me. > > No let's do that the preprocessor conversion for v3.11. Hmm looks like there are few more 3430sdp dt nfsroot exposed issues in today's linux next. To get nfsroot to behave, I had to have your earlier fix from this thread and also revert a2797bea (gpio/omap: force restore if context loss is not detectable). Otherwise nfsroot fails, but not necessarily every time? I could not git bisect it down to the commit above, had to manually figure it out.. There may also be DMA related issues, but I don't know for sure any longer. I made a patch to fix SPI PIO mode and then hacked SPI to always use PIO to leave out the DMA related parts. Anyways, will post that separately, let's hope the DMA related issues I saw earlier are also related to dt + a2797bea. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/12/2013 07:06 PM, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [130410 15:32]: >> * Jon Hunter <jon-hunter@ti.com> [130410 15:30]: >>> >>> Are you saying that you want to use the version with that is using the >>> pre-processor definitions? I was thinking that may be we could do that >>> as a clean-up for v3.11 and just use the original version I posted >>> earlier. Seems cleaner to me. >> >> No let's do that the preprocessor conversion for v3.11. > > Hmm looks like there are few more 3430sdp dt nfsroot exposed > issues in today's linux next. I don't even see any ethernet devices defined in the omap3430-sdp.dts file. Is this something that you have added on top? > To get nfsroot to behave, I had to have your earlier fix > from this thread and also revert a2797bea (gpio/omap: force > restore if context loss is not detectable). > > Otherwise nfsroot fails, but not necessarily every time? Well this patch is going to force a gpio restore everytime we call pm_runtime_get() when the use-count is 0. Yes this is not efficient, however, without this patch you run the risk of context being lost and you would never know. Per the changelog, long term a better solution is needed. > I could not git bisect it down to the commit above, had to > manually figure it out.. There may also be DMA related > issues, but I don't know for sure any longer. I made a > patch to fix SPI PIO mode and then hacked SPI to always use > PIO to leave out the DMA related parts. Anyways, will post > that separately, let's hope the DMA related issues I saw > earlier are also related to dt + a2797bea. Ok, I don't follow that. I am not sure how gpio is related to DMA in this case. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Jon Hunter <jon-hunter@ti.com> [130412 19:22]: > > On 04/12/2013 07:06 PM, Tony Lindgren wrote: > > * Tony Lindgren <tony@atomide.com> [130410 15:32]: > >> * Jon Hunter <jon-hunter@ti.com> [130410 15:30]: > >>> > >>> Are you saying that you want to use the version with that is using the > >>> pre-processor definitions? I was thinking that may be we could do that > >>> as a clean-up for v3.11 and just use the original version I posted > >>> earlier. Seems cleaner to me. > >> > >> No let's do that the preprocessor conversion for v3.11. > > > > Hmm looks like there are few more 3430sdp dt nfsroot exposed > > issues in today's linux next. > > I don't even see any ethernet devices defined in the omap3430-sdp.dts > file. Is this something that you have added on top? Oops sorry I meant the ks8851 on SPI on 4430sdp, not 3430. > > To get nfsroot to behave, I had to have your earlier fix > > from this thread and also revert a2797bea (gpio/omap: force > > restore if context loss is not detectable). > > > > Otherwise nfsroot fails, but not necessarily every time? > > Well this patch is going to force a gpio restore everytime we call > pm_runtime_get() when the use-count is 0. Yes this is not efficient, > however, without this patch you run the risk of context being lost and > you would never know. Per the changelog, long term a better solution is > needed. It seems that this patch kills the ks8851 GPIO interrupt somehow, at least most of the time. > > I could not git bisect it down to the commit above, had to > > manually figure it out.. There may also be DMA related > > issues, but I don't know for sure any longer. I made a > > patch to fix SPI PIO mode and then hacked SPI to always use > > PIO to leave out the DMA related parts. Anyways, will post > > that separately, let's hope the DMA related issues I saw > > earlier are also related to dt + a2797bea. > > Ok, I don't follow that. I am not sure how gpio is related to DMA in > this case. I think the DMA issues might be related to the GPIO interrupt not working properly. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/13/2013 11:50 AM, Tony Lindgren wrote: > * Jon Hunter <jon-hunter@ti.com> [130412 19:22]: >> >> On 04/12/2013 07:06 PM, Tony Lindgren wrote: >>> * Tony Lindgren <tony@atomide.com> [130410 15:32]: >>>> * Jon Hunter <jon-hunter@ti.com> [130410 15:30]: >>>>> >>>>> Are you saying that you want to use the version with that is using the >>>>> pre-processor definitions? I was thinking that may be we could do that >>>>> as a clean-up for v3.11 and just use the original version I posted >>>>> earlier. Seems cleaner to me. >>>> >>>> No let's do that the preprocessor conversion for v3.11. >>> >>> Hmm looks like there are few more 3430sdp dt nfsroot exposed >>> issues in today's linux next. >> >> I don't even see any ethernet devices defined in the omap3430-sdp.dts >> file. Is this something that you have added on top? > > Oops sorry I meant the ks8851 on SPI on 4430sdp, not 3430. Ok makes sense. >>> To get nfsroot to behave, I had to have your earlier fix >>> from this thread and also revert a2797bea (gpio/omap: force >>> restore if context loss is not detectable). >>> >>> Otherwise nfsroot fails, but not necessarily every time? >> >> Well this patch is going to force a gpio restore everytime we call >> pm_runtime_get() when the use-count is 0. Yes this is not efficient, >> however, without this patch you run the risk of context being lost and >> you would never know. Per the changelog, long term a better solution is >> needed. > > It seems that this patch kills the ks8851 GPIO interrupt somehow, > at least most of the time. Hmmm, let me go back and re-test this. >>> I could not git bisect it down to the commit above, had to >>> manually figure it out.. There may also be DMA related >>> issues, but I don't know for sure any longer. I made a >>> patch to fix SPI PIO mode and then hacked SPI to always use >>> PIO to leave out the DMA related parts. Anyways, will post >>> that separately, let's hope the DMA related issues I saw >>> earlier are also related to dt + a2797bea. >> >> Ok, I don't follow that. I am not sure how gpio is related to DMA in >> this case. > > I think the DMA issues might be related to the GPIO interrupt > not working properly. What is the use-case? DMA + SPI? Talking to what on what board? Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts index c387bdc..5d0c925 100644 --- a/arch/arm/boot/dts/omap4-sdp.dts +++ b/arch/arm/boot/dts/omap4-sdp.dts @@ -9,6 +9,7 @@ /include/ "omap443x.dtsi" /include/ "elpida_ecb240abacn.dtsi" +#include <dt-bindings/interrupt-controller/arm-gic.h> / { model = "TI OMAP4 SDP board"; @@ -363,7 +364,7 @@ spi-max-frequency = <24000000>; reg = <0>; interrupt-parent = <&gpio2>; - interrupts = <2>; /* gpio line 34 */ + interrupts = <2 IRQ_TYPE_LEVEL_LOW>; /* gpio line 34 */ vdd-supply = <&vdd_eth>; }; }; diff --git a/arch/arm/boot/dts/omap4-var-som.dts b/arch/arm/boot/dts/omap4-var-som.dts index 222a413..ade7d46 100644 --- a/arch/arm/boot/dts/omap4-var-som.dts +++ b/arch/arm/boot/dts/omap4-var-som.dts @@ -8,6 +8,7 @@ /dts-v1/; /include/ "omap443x.dtsi" +#include <dt-bindings/interrupt-controller/arm-gic.h> / { model = "Variscite OMAP4 SOM"; @@ -68,7 +69,7 @@ spi-max-frequency = <24000000>; reg = <0>; interrupt-parent = <&gpio6>; - interrupts = <11>; /* gpio line 171 */ + interrupts = <11 IRQ_TYPE_LEVEL_LOW>; /* gpio line 171 */ vdd-supply = <&vdd_eth>; }; };