| Message ID | 87twr4un1h.fsf@belgarion.home |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
Dne 9.9.2015 v 08:25 Robert Jarzmik napsal(a): > Petr Cvek <petr.cvek@tul.cz> writes: > >> Dne 8.9.2015 v 22:24 Petr Cvek napsal(a): >>> >>> Did you defined resources somewhere? Actual resources are in >>> "pxa_ir_resources" variable at: > I have them in patch [1], which is exactly the patch you have made yourself. Is there a mailing list for this specific patch? It seems I did not get any mail with it. > >> I tried to add following patch for new resources, but now it fails with: >> >> [ 141.534545] pxa2xx-ir pxa2xx-ir: can't request region for resource [mem 0x40700000-0x40700100] >> [ 141.534574] pxa2xx-ir pxa2xx-ir: resource stuart not defined >> [ 141.534656] pxa2xx-ir: probe of pxa2xx-ir failed with error -16 >> >> That's because STUART is allocated by normal UART driver at: >> >> http://lxr.free-electrons.com/source/arch/arm/mach-pxa/devices.c#L244 >> >> So somehow there must be configuration for STUART used with FICP and STUART >> alone (probably can be used for normal UART). > That's because you have to remove from magician.c: > pxa_set_stuart_info(NULL); > Thanks, I missed that. BTW This patch required update of my kernel repo. It seems that my: magician.c patches + ficp patch + new dma engine does not work for me at all. Kernel throws some panic about interrupts and then it ends in an infinite stack dumping loop. Fault occurs before rootfs is mounted, so probably around MMC init (with removed SD card it fails normally with no rootfs found error). Is it required to change something in the mach-pxa machine specific files? Which hardware was used for testing new dma engine implementation? Notably MMC driver part, probably commit: 6464b71409511939efce1ae4fb4ec6e3483b11b2 Best regards, Petr -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Petr Cvek <petr.cvek@tul.cz> writes: > Dne 9.9.2015 v 08:25 Robert Jarzmik napsal(a): >> Petr Cvek <petr.cvek@tul.cz> writes: >> >>> Dne 8.9.2015 v 22:24 Petr Cvek napsal(a): >>>> >>>> Did you defined resources somewhere? Actual resources are in >>>> "pxa_ir_resources" variable at: >> I have them in patch [1], which is exactly the patch you have made yourself. > > Is there a mailing list for this specific patch? It seems I did not get any > mail with it. Should have been posted to linux arm kernel mailing list, unless my mailer failed ... > BTW This patch required update of my kernel repo. It seems that my: > > magician.c patches + ficp patch + new dma engine > > does not work for me at all. Kernel throws some panic about interrupts and then > it ends in an infinite stack dumping loop. Fault occurs before rootfs is > mounted, so probably around MMC init (with removed SD card it fails normally > with no rootfs found error). Could you send me (privately) the stack you're getting please. This is something I'd like to catch up early in the -rc releases. > Is it required to change something in the mach-pxa machine specific files? Nope. As long as CONFIG_PXA_DMA is set, it's alright. Building on top of linux-next of the future v4.3-rc1 would be better, as the dmaengine support should be consistent across drivers/dma and arch/arm/mach-pxa in there. > Which hardware was used for testing new dma engine implementation? Notably MMC > driver part, probably commit: Mioa701 (pxa270), cm-x300 (pxa310), zylonite (pxa310). The MMC was specificaly tested on mioa701, on top of linux-next a week ago (about the day v4.2 was released). Now with your stack, could you also give me the upstream commit id of the tip of the tree you're using (before your patches) please ? And it is true I have not tested the rootfs special case, where drivers are not yet initialized (and more specifically gpio and interrupt chip). Your backtrace should tell me if you fall into this category of issues ... but I digress, this has no link with pxaficp. Cheers.
Dne 10.9.2015 v 13:14 Robert Jarzmik napsal(a): > Petr Cvek <petr.cvek@tul.cz> writes: > >> Dne 9.9.2015 v 08:25 Robert Jarzmik napsal(a): >>> Petr Cvek <petr.cvek@tul.cz> writes: >>> >>>> Dne 8.9.2015 v 22:24 Petr Cvek napsal(a): >>>>> >>>>> Did you defined resources somewhere? Actual resources are in >>>>> "pxa_ir_resources" variable at: >>> I have them in patch [1], which is exactly the patch you have made yourself. >> >> Is there a mailing list for this specific patch? It seems I did not get any >> mail with it. > Should have been posted to linux arm kernel mailing list, unless my mailer > failed ... > Searching for: "ARM: pxa: add resources to pxaficp_ir" did not found anything, same was for "ficp" in the linux-arm-kernel/netdev/linux-kernel mailing list archive. >> BTW This patch required update of my kernel repo. It seems that my: >> >> magician.c patches + ficp patch + new dma engine >> >> does not work for me at all. Kernel throws some panic about interrupts and then >> it ends in an infinite stack dumping loop. Fault occurs before rootfs is >> mounted, so probably around MMC init (with removed SD card it fails normally >> with no rootfs found error). > Could you send me (privately) the stack you're getting please. This is something > I'd like to catch up early in the -rc releases. Well this will be problem as I cannot save anything to an SD card after and during the failure. Only viable interfaces would be earlycon on an infraport or high speed camera on LCD :-). But I was able to revert this commit: 6464b71409511939efce1ae4fb4ec6e3483b11b2 mmc: pxamci: switch over to dmaengine use and after that I am able to boot. > > Now with your stack, could you also give me the upstream commit id of the tip of > the tree you're using (before your patches) please ? It is probably irelevant now, but for complete information: Discovered on my working repo: mainline b8889c4fc6ba03e289cec6a4d692f6f080a55e53 Still present on fresh downloaded: linux-next 22dc312d56ba077db27a9798b340e7d161f1df05 > > And it is true I have not tested the rootfs special case, where drivers are not > yet initialized (and more specifically gpio and interrupt chip). Your backtrace > should tell me if you fall into this category of issues ... but I digress, this > has no link with pxaficp. Should I start new thread? (same bug can be present in the FICP too) I will try to configure an initrd rootfs this should create more ways to save kernel log. Anyway after mmc dma revert I was still not able to start FICP. There is an error: Unable to handle kernel paging request at virtual address 32e00004 from pxa_irda_startup() and it seems it is caused by register definitions. For example: writel_relaxed((val), (irda)->stuart_base + (off)); is called by stuart_writel(si, 0, STIER); but STIER is not just an offset, but full register address: __REG(0x40700004) So the definition should be changed, unless there is another patch I did not received (in that case, send me full patchset again please) :-). Best regards, Petr -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Petr Cvek <petr.cvek@tul.cz> writes: >> Should have been posted to linux arm kernel mailing list, unless my mailer >> failed ... >> > Searching for: > > "ARM: pxa: add resources to pxaficp_ir" > > did not found anything, same was for "ficp" in the linux-arm-kernel/netdev/linux-kernel > mailing list archive. Ah ok, I'll resend it then. >>> BTW This patch required update of my kernel repo. It seems that my: >>> >>> magician.c patches + ficp patch + new dma engine >>> >>> does not work for me at all. Kernel throws some panic about interrupts and then >>> it ends in an infinite stack dumping loop. Fault occurs before rootfs is >>> mounted, so probably around MMC init (with removed SD card it fails normally >>> with no rootfs found error). >> Could you send me (privately) the stack you're getting please. This is something >> I'd like to catch up early in the -rc releases. > > Well this will be problem as I cannot save anything to an SD card after and > during the failure. Only viable interfaces would be earlycon on an infraport > or high speed camera on LCD :-). Ah just as on my mioa701. I ended up soldering a JTAG cable :) > But I was able to revert this commit: > > 6464b71409511939efce1ae4fb4ec6e3483b11b2 mmc: pxamci: switch over to dmaengine use > > and after that I am able to boot. Okay. I'll try to reproduce this failure then. If I fail, well, before using the JTAG cable, I used another trick: I was taking a movie from the LCD with a smartphone, and it worked. It was an horrible thing to decrypt ... Let's hope I'll be lucky on one of my platforms. >> Now with your stack, could you also give me the upstream commit id of the tip of >> the tree you're using (before your patches) please ? > > It is probably irelevant now, but for complete information: > > Discovered on my working repo: mainline b8889c4fc6ba03e289cec6a4d692f6f080a55e53 > Still present on fresh downloaded: linux-next > 22dc312d56ba077db27a9798b340e7d161f1df05 Ok, thanks. >> And it is true I have not tested the rootfs special case, where drivers are not >> yet initialized (and more specifically gpio and interrupt chip). Your backtrace >> should tell me if you fall into this category of issues ... but I digress, this >> has no link with pxaficp. > > Should I start new thread? (same bug can be present in the FICP too) Yes, this pxamci bothers me, it deserves a thread. > I will try to configure an initrd rootfs this should create more ways to save > kernel log. Great idea. > > Anyway after mmc dma revert I was still not able to start FICP. There is an error: > > Unable to handle kernel paging request at virtual address 32e00004 > > from pxa_irda_startup() and it seems it is caused by register definitions. For example: > > writel_relaxed((val), (irda)->stuart_base + (off)); > > is called by > > stuart_writel(si, 0, STIER); > > but STIER is not just an offset, but full register address: > > __REG(0x40700004) > > So the definition should be changed, unless there is another patch I did not > received (in that case, send me full patchset again please) :-). Agreed, this is a bug in this patch. With this fix, is the pxaficp working or do you need a bit more time to experiment ? Cheers.
Dne 11.9.2015 v 08:18 Robert Jarzmik napsal(a): > Petr Cvek <petr.cvek@tul.cz> writes: > >>> Should have been posted to linux arm kernel mailing list, unless my mailer >>> failed ... >>> >> Searching for: >> >> "ARM: pxa: add resources to pxaficp_ir" >> >> did not found anything, same was for "ficp" in the linux-arm-kernel/netdev/linux-kernel >> mailing list archive. > Ah ok, I'll resend it then. > >>>> BTW This patch required update of my kernel repo. It seems that my: >>>> >>>> magician.c patches + ficp patch + new dma engine >>>> >>>> does not work for me at all. Kernel throws some panic about interrupts and then >>>> it ends in an infinite stack dumping loop. Fault occurs before rootfs is >>>> mounted, so probably around MMC init (with removed SD card it fails normally >>>> with no rootfs found error). >>> Could you send me (privately) the stack you're getting please. This is something >>> I'd like to catch up early in the -rc releases. >> >> Well this will be problem as I cannot save anything to an SD card after and >> during the failure. Only viable interfaces would be earlycon on an infraport >> or high speed camera on LCD :-). > Ah just as on my mioa701. I ended up soldering a JTAG cable :) Rather not :-D. > >>> And it is true I have not tested the rootfs special case, where drivers are not >>> yet initialized (and more specifically gpio and interrupt chip). Your backtrace >>> should tell me if you fall into this category of issues ... but I digress, this >>> has no link with pxaficp. >> >> Should I start new thread? (same bug can be present in the FICP too) > Yes, this pxamci bothers me, it deserves a thread. Will start soon. >> >> Anyway after mmc dma revert I was still not able to start FICP. There is an error: >> >> Unable to handle kernel paging request at virtual address 32e00004 >> >> from pxa_irda_startup() and it seems it is caused by register definitions. For example: >> >> writel_relaxed((val), (irda)->stuart_base + (off)); >> >> is called by >> >> stuart_writel(si, 0, STIER); >> >> but STIER is not just an offset, but full register address: >> >> __REG(0x40700004) >> >> So the definition should be changed, unless there is another patch I did not >> received (in that case, send me full patchset again please) :-). > Agreed, this is a bug in this patch. With this fix, is the pxaficp working or do > you need a bit more time to experiment ? I have tried with a nasty hack (use only lower part of address, it should equal with reg offset): #undef __REG -#define __REG(x) (x) +#define __REG(x) (x & 0xffff) and it seems to work. The module inits and I am able to see IrDA traffic and ping other machine. FIR mode (mostly impacted by DMA) is still untested as magician unfortunately supports only SIR mode. Petr -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Petr Cvek <petr.cvek@tul.cz> writes: >>>> And it is true I have not tested the rootfs special case, where drivers are not >>>> yet initialized (and more specifically gpio and interrupt chip). Your backtrace >>>> should tell me if you fall into this category of issues ... but I digress, this >>>> has no link with pxaficp. >>> >>> Should I start new thread? (same bug can be present in the FICP too) >> Yes, this pxamci bothers me, it deserves a thread. > > Will start soon. And I think I see your problem now : (a) there is a regression from the commit 8c8fe97b2b8a, for which the fix is here: https://lkml.org/lkml/2015/9/6/112 (b) for gpio expanders, another fix is here : https://lkml.org/lkml/2015/9/12/62 The regression is on dmaengine, that's where the thread belongs I think, at least if that fixes your issue. >>> but STIER is not just an offset, but full register address: >>> >>> __REG(0x40700004) >>> >>> So the definition should be changed, unless there is another patch I did not >>> received (in that case, send me full patchset again please) :-). >> Agreed, this is a bug in this patch. With this fix, is the pxaficp working or do >> you need a bit more time to experiment ? > > I have tried with a nasty hack (use only lower part of address, it should equal with reg offset): > #undef __REG > -#define __REG(x) (x) > +#define __REG(x) (x & 0xffff) > > and it seems to work. The module inits and I am able to see IrDA traffic and > ping other machine. FIR mode (mostly impacted by DMA) is still untested as > magician unfortunately supports only SIR mode. Okay, I'll add a fix in the next iteration, thanks for finding this. Cheers.
Dne 12.9.2015 v 13:03 Robert Jarzmik napsal(a): > Petr Cvek <petr.cvek@tul.cz> writes: > >>>>> And it is true I have not tested the rootfs special case, where drivers are not >>>>> yet initialized (and more specifically gpio and interrupt chip). Your backtrace >>>>> should tell me if you fall into this category of issues ... but I digress, this >>>>> has no link with pxaficp. >>>> >>>> Should I start new thread? (same bug can be present in the FICP too) >>> Yes, this pxamci bothers me, it deserves a thread. >> >> Will start soon. > And I think I see your problem now : > (a) there is a regression from the commit 8c8fe97b2b8a, for which the fix is > here: https://lkml.org/lkml/2015/9/6/112 > (b) for gpio expanders, another fix is here : > https://lkml.org/lkml/2015/9/12/62 > > The regression is on dmaengine, that's where the thread belongs I think, at > least if that fixes your issue. > Great now it finally boots. Thanks. Petr -- To unsubscribe from this list: send the line "unsubscribe netdev" 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/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c index e6ce669b54af..6d5ab8199536 100644 --- a/arch/arm/mach-pxa/devices.c +++ b/arch/arm/mach-pxa/devices.c @@ -395,6 +395,26 @@ static struct resource pxa_ir_resources[] = { .end = IRQ_ICP, .flags = IORESOURCE_IRQ, }, + [3] = { + .start = 0x40800000, + .end = 0x4080001b, + .flags = IORESOURCE_MEM, + }, + [4] = { + .start = 0x40700000, + .end = 0x40700023, + .flags = IORESOURCE_MEM, + }, + [5] = { + .start = 17, + .end = 17, + .flags = IORESOURCE_DMA, + }, + [6] = { + .start = 18, + .end = 18, + .flags = IORESOURCE_DMA, + }, }; struct platform_device pxa_device_ficp = {