Re: OOPS: musb_hdrc
Hi Matwey, On 09/09/2014 01:58 PM, Matwey V. Kornilov wrote: Hi, Can you add a few printks around drivers/usb/musb/musb_cppi41.c to further narrow down where the problem is ? I ran v3.17-rc1 on my beaglebone black (a while back) and didn't have any issues. Now I am rebuilding the kernel to see where the problem is. Are you sure you're running v3.16.1 vanilla ? I just tested on my end and it's working fine. Please provide full boot logs including u-boot all the way to the error scenario. I am sure that I am running 3.16.1 opensuse, where no patches affecting musb applied. Full log is quite big, please find it at http://susepaste.org/31032538 attached you can find my logs (couldn't paste it anywhere as my test case for mass storage devices outputs quite a bit of data) Could you please share your kernel config? My config is attached. Please set CONFIG_USB_TI_CPPI41_DMA=y and re-run your tests. -George -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OOPS: musb_hdrc
Hi George, Many thanks for the hint. Am I right that we can not have multiple MUSB DMA modes within the same kernel? It is a pity. 2014-09-09 12:40 GMT+04:00 George Cherian george.cher...@ti.com: Hi Matwey, On 09/09/2014 01:58 PM, Matwey V. Kornilov wrote: Hi, Can you add a few printks around drivers/usb/musb/musb_cppi41.c to further narrow down where the problem is ? I ran v3.17-rc1 on my beaglebone black (a while back) and didn't have any issues. Now I am rebuilding the kernel to see where the problem is. Are you sure you're running v3.16.1 vanilla ? I just tested on my end and it's working fine. Please provide full boot logs including u-boot all the way to the error scenario. I am sure that I am running 3.16.1 opensuse, where no patches affecting musb applied. Full log is quite big, please find it at http://susepaste.org/31032538 attached you can find my logs (couldn't paste it anywhere as my test case for mass storage devices outputs quite a bit of data) Could you please share your kernel config? My config is attached. Please set CONFIG_USB_TI_CPPI41_DMA=y and re-run your tests. -George -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OOPS: musb_hdrc
Hi George, Why dma_controller_create can not be set in struct musb_platform_ops? Then each module would be able to set dma_controller_create it wants, and musb_init_controller would use musb-ops-dma_controller_create instead of just dma_controller_create. 2014-09-09 13:15 GMT+04:00 Matwey V. Kornilov matwey.korni...@gmail.com: Hi George, Many thanks for the hint. Am I right that we can not have multiple MUSB DMA modes within the same kernel? It is a pity. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabb -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OOPS: musb_hdrc
On Tue, Sep 09, 2014 at 01:28:55PM +0400, Matwey V. Kornilov wrote: Hi George, Why dma_controller_create can not be set in struct musb_platform_ops? Then each module would be able to set dma_controller_create it wants, and musb_init_controller would use musb-ops-dma_controller_create instead of just dma_controller_create. patches are welcome :-) 2014-09-09 13:15 GMT+04:00 Matwey V. Kornilov matwey.korni...@gmail.com: Hi George, Many thanks for the hint. Am I right that we can not have multiple MUSB DMA modes within the same kernel? It is a pity. This driver is still full of details to be fixed. Originally you couldn't even build support for several devices in one go. That has been fixed a while back but I never got around to fixing the DMA part. If you wanna help, patches are more than welcome. -- balbi signature.asc Description: Digital signature
Re: OOPS: musb_hdrc
2014-09-09 18:45 GMT+04:00 Felipe Balbi ba...@ti.com: On Tue, Sep 09, 2014 at 01:28:55PM +0400, Matwey V. Kornilov wrote: Hi George, Why dma_controller_create can not be set in struct musb_platform_ops? Then each module would be able to set dma_controller_create it wants, and musb_init_controller would use musb-ops-dma_controller_create instead of just dma_controller_create. patches are welcome :-) Will the following approach be acceptable? 1. musbhsdma.o cppi_dma.o tusb6010_omap.o ux500_dma.o musb_cppi41.o became independent modules (tristate), each module exports two symbols: PREFIX_dma_controller_create and ..._destroy. 2. add two callbacks to musb_platform_ops, when pointers are NULL then no DMA is used 3. every module uses appropriate PREFIX_dma_controller_create in its PREFIX_ops structure 4. musb_core uses wrappers which calls musb-ops-dma_controller_create and destroy In this case every DMA mode can be reused more by several drivers if necessarily. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OOPS: musb_hdrc
On Tue, Sep 09, 2014 at 07:00:10PM +0400, Matwey V. Kornilov wrote: 2014-09-09 18:45 GMT+04:00 Felipe Balbi ba...@ti.com: On Tue, Sep 09, 2014 at 01:28:55PM +0400, Matwey V. Kornilov wrote: Hi George, Why dma_controller_create can not be set in struct musb_platform_ops? Then each module would be able to set dma_controller_create it wants, and musb_init_controller would use musb-ops-dma_controller_create instead of just dma_controller_create. patches are welcome :-) Will the following approach be acceptable? 1. musbhsdma.o cppi_dma.o tusb6010_omap.o ux500_dma.o musb_cppi41.o became independent modules (tristate), each module exports two symbols: PREFIX_dma_controller_create and ..._destroy. 2. add two callbacks to musb_platform_ops, when pointers are NULL then no DMA is used 3. every module uses appropriate PREFIX_dma_controller_create in its PREFIX_ops structure 4. musb_core uses wrappers which calls musb-ops-dma_controller_create and destroy In this case every DMA mode can be reused more by several drivers if necessarily. the proper way would be to move everything to dma_engine. OMAP already has support for DMA engine and both CPPI and Ux500 are already using that. What we need it move inventra dma and cppi 3.x to DMA engine, then move DMA engine into the core driver and have it grab a DMA through that, instead of using this private API. -- balbi signature.asc Description: Digital signature
Re: OOPS: musb_hdrc
2014-09-09 19:11 GMT+04:00 Felipe Balbi ba...@ti.com: the proper way would be to move everything to dma_engine. OMAP already has support for DMA engine and both CPPI and Ux500 are already using that. If so, ux500_dma.c and musb_cppi41.c should be almost identically wrapping dmaengine, but they aren't. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OOPS: musb_hdrc
On Tue, Sep 09, 2014 at 07:52:59PM +0400, Matwey V. Kornilov wrote: 2014-09-09 19:11 GMT+04:00 Felipe Balbi ba...@ti.com: the proper way would be to move everything to dma_engine. OMAP already has support for DMA engine and both CPPI and Ux500 are already using that. If so, ux500_dma.c and musb_cppi41.c should be almost identically wrapping dmaengine, but they aren't. heh, the difference is mostly because ux500 supports scatter-gather while cppi41 doesn't. That can be handled generically. The other differences are due to silicon errata, and that should be hidden inside DMA engine driver itself, not in MUSB. -- balbi signature.asc Description: Digital signature
Re: OOPS: musb_hdrc
2014-09-09 20:09 GMT+04:00 Felipe Balbi ba...@ti.com: On Tue, Sep 09, 2014 at 07:52:59PM +0400, Matwey V. Kornilov wrote: 2014-09-09 19:11 GMT+04:00 Felipe Balbi ba...@ti.com: the proper way would be to move everything to dma_engine. OMAP already has support for DMA engine and both CPPI and Ux500 are already using that. If so, ux500_dma.c and musb_cppi41.c should be almost identically wrapping dmaengine, but they aren't. heh, the difference is mostly because ux500 supports scatter-gather while cppi41 doesn't. That can be handled generically. The other differences are due to silicon errata, and that should be hidden inside DMA engine driver itself, not in MUSB. That is, If I understand correctly, one may start from the other side. Firstly create musb_dmaengine.c using generic dmaengine API (not relying on hardware model) and providing private API and then drop one by one existing DMA implementations from musb. Eventually, only musb_dmaengine.c will be kept suitable for all kinds of drivers. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OOPS: musb_hdrc
Hi, On Tue, Sep 09, 2014 at 08:17:32PM +0400, Matwey V. Kornilov wrote: 2014-09-09 20:09 GMT+04:00 Felipe Balbi ba...@ti.com: On Tue, Sep 09, 2014 at 07:52:59PM +0400, Matwey V. Kornilov wrote: 2014-09-09 19:11 GMT+04:00 Felipe Balbi ba...@ti.com: the proper way would be to move everything to dma_engine. OMAP already has support for DMA engine and both CPPI and Ux500 are already using that. If so, ux500_dma.c and musb_cppi41.c should be almost identically wrapping dmaengine, but they aren't. heh, the difference is mostly because ux500 supports scatter-gather while cppi41 doesn't. That can be handled generically. The other differences are due to silicon errata, and that should be hidden inside DMA engine driver itself, not in MUSB. That is, If I understand correctly, one may start from the other side. Firstly create musb_dmaengine.c using generic dmaengine API (not relying on hardware model) and providing private API and then drop one by one existing DMA implementations from musb. Eventually, only musb_dmaengine.c will be kept suitable for all kinds of drivers. you've just read my mind and that's a bit freaky :-) But you're right. At the time we drop all other implementations, we might as well merge musb_dmaengine.c into the core driver itself and completely rid ourselves of MUSB private DMA API :-) Clearly, that cannot be done in one development cycle, so we need to find a way to introduce all this code and, meanwhile, not break anything :-) cheers -- balbi signature.asc Description: Digital signature
OOPS: musb_hdrc
Hi, Running 3.16.1 on beaglebone black, I have the following issue with musb_hdrc on boot: [ 11.151063] Unable to handle kernel paging request at virtual address e09bb05c [ 11.158774] pgd = de5d8000 [ 11.161613] [e09bb05c] *pgd=9e02d811, *pte=, *ppte= [ 11.168247] Internal error: Oops: 807 [#1] SMP ARM [ 11.173269] Modules linked in: musb_dsps(+) musb_hdrc udc_core davinci_mdio(+) mmc_block phy_am335x usbcore phy_am335x_control phy_generic usb_common ti_cpsw davinci_cpdma omap_hsmmc mmc_core musb_am335x [ 11.192315] CPU: 0 PID: 205 Comm: systemd-udevd Not tainted 3.16.1-2.g2ab6585-default #1 [ 11.200799] task: de58a080 ti: de5cc000 task.ti: de5cc000 [ 11.206541] PC is at dma_controller_create+0x18/0x120 [musb_hdrc] [ 11.212943] LR is at musb_probe+0x528/0x664 [musb_hdrc] [ 11.218420] pc : [bf13175c]lr : [bf125fec]psr: a013 [ 11.218420] sp : de5cdbf8 ip : de5ee8d8 fp : 0010 [ 11.230454] r10: r9 : 0003 r8 : de5ee810 [ 11.235930] r7 : 0023 r6 : de5ee800 r5 : de71aec0 r4 : de2ec010 [ 11.242771] r3 : e09ba800 r2 : 7fff r1 : e09b8c00 r0 : de2ec010 [ 11.249615] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 11.257096] Control: 10c5387d Table: 9e5d8019 DAC: 0015 [ 11.263118] Process systemd-udevd (pid: 205, stack limit = 0xde5cc250) [ 11.269959] Stack: (0xde5cdbf8 to 0xde5ce000) [ 11.274527] dbe0: de2ec010 de71aec0 [ 11.283102] dc00: de5ee800 0023 de5ee810 0003 bf125fec c0b21088 de71b5d8 [ 11.291678] dc20: 0001 de71b0d8 0010 de5ee810 bf134a84 c0ddfbc8 bf134a84 [ 11.300254] dc40: 0010 de5ee800 bf146760 c065a1bc c065a19c de5ee810 c0eaee3c c0658318 [ 11.308830] dc60: 1304 c065a2c8 bf134a84 de5ee810 c0658570 de5f1210 [ 11.317405] dc80: c06565d4 de0bff70 de79c7b8 de5ee810 de5ee844 c0d9c810 c0658154 [ 11.325981] dca0: de5ee818 de5ee810 c0d9c810 c0657648 de5ee818 de5ee810 c06557b4 [ 11.334558] dcc0: 8000 c0de8840 c0d35e54 de7f6f40 de5f1200 0002 de5ee800 de5ee810 [ 11.343134] dce0: de5f1200 de7f3790 dfadf0a0 c0659edc 0001 de5f1210 [ 11.351710] dd00: de5f1200 bf145ef4 bf146870 01f4 de01c901 25f0 0007 de71b6fa [ 11.360286] dd20: c0e97a00 de71af10 de71b628 bf146760 47401c00 47401fff c8005480 0200 [ 11.368861] dd40: 0023 0023 c80054a8 0400 [ 11.377436] dd60: 0010 de5f1210 bf14679c c0ddfbc8 bf14679c [ 11.386011] dd80: 0010 bf146870 c065a1bc c065a19c de5f1210 c0eaee3c c0658318 [ 11.394587] dda0: c065a2a8 de5f1210 bf14679c de5f1210 bf14679c de5f1244 bf149000 [ 11.403164] ddc0: de5cc020 c0658650 bf14679c c06585bc c0656524 de0bff5c de5924b4 [ 11.411739] dde0: bf14679c de79ce00 c0d9c810 c0657924 bf146664 c04df5e8 bf14679c bf14679c [ 11.420315] de00: c0cf1aa0 de7ed340 de5cdf18 c0658e14 c0cf1aa0 c0cf1aa0 c0209ab4 [ 11.428891] de20: c0ad03e8 c0ad03d4 c034195c c0cf1984 dfebf820 0008 [ 11.437467] de40: dfaf1000 c034338c 0007 dfebf820 c0e93d08 c036d8e0 [ 11.446043] de60: bf146870 0005 de7ed340 c036f26c 0005 de5cdf54 bf14687c [ 11.454618] de80: de5cdf18 de5cc018 bf146870 c02df0d8 8000 7fff [ 11.463194] dea0: c02dc1f4 c0390948 e09a6000 de5cdf18 c0ced560 b6e7fc80 [ 11.471770] dec0: e09a8880 00ae de5cdf5c de5cdf88 1c7e 0002 de5c81a4 [ 11.480344] dee0: 0001 [ 11.488919] df00: [ 11.497496] df20: de5cc000 000b b6e7fc80 017b c021b008 de5cc000 1000 [ 11.506071] df40: 009fadb0 c02df738 0002 de5cdf5c e09a6000 4b2e e09a8880 [ 11.514647] df60: e09a8707 e09a9928 1a04 1fb4 bf1467e0 0006 0023 [ 11.523223] df80: 0024 001b 0016 0012 0001 0001 [ 11.531798] dfa0: c021ae20 0001 0001 000b b6e7fc80 b6f1d370 [ 11.540374] dfc0: 0001 0001 017b 0002 009fadb0 [ 11.548949] dfe0: beeb12d8 beeb12c8 b6e76530 b6da66a0 60010010 000b [ 11.557582] [bf13175c] (dma_controller_create [musb_hdrc]) from [bf125fec] (musb_probe+0x528/0x664 [musb_hdrc]) [ 11.568554] [bf125fec] (musb_probe [musb_hdrc]) from [c065a1bc] (platform_drv_probe+0x20/0x50) [ 11.577969] [c065a1bc] (platform_drv_probe) from [c0658318] (driver_probe_device+0x154/0x3ac) [ 11.587278] [c0658318] (driver_probe_device) from [c06565d4] (bus_for_each_drv+0x60/0x94) [ 11.596221] [c06565d4] (bus_for_each_drv) from [c0658154] (device_attach+0x7c/0x90) [ 11.604617] [c0658154] (device_attach) from [c0657648]
Re: OOPS: musb_hdrc
Hi, it kinda helps if you Cc the maintainer :-) scripts/get_maintainer.pl helps by returning a (usually) correct (and extensive) list of people and mailing lists to Cc :-) anyway... On Mon, Sep 08, 2014 at 09:08:07PM +0400, Matwey V. Kornilov wrote: Hi, Running 3.16.1 on beaglebone black, I have the following issue with musb_hdrc on boot: [ 11.151063] Unable to handle kernel paging request at virtual address e09bb05c [ 11.158774] pgd = de5d8000 [ 11.161613] [e09bb05c] *pgd=9e02d811, *pte=, *ppte= [ 11.168247] Internal error: Oops: 807 [#1] SMP ARM [ 11.173269] Modules linked in: musb_dsps(+) musb_hdrc udc_core davinci_mdio(+) mmc_block phy_am335x usbcore phy_am335x_control phy_generic usb_common ti_cpsw davinci_cpdma omap_hsmmc mmc_core musb_am335x [ 11.192315] CPU: 0 PID: 205 Comm: systemd-udevd Not tainted 3.16.1-2.g2ab6585-default #1 [ 11.200799] task: de58a080 ti: de5cc000 task.ti: de5cc000 [ 11.206541] PC is at dma_controller_create+0x18/0x120 [musb_hdrc] Can you add a few printks around drivers/usb/musb/musb_cppi41.c to further narrow down where the problem is ? I ran v3.17-rc1 on my beaglebone black (a while back) and didn't have any issues. cheers -- balbi signature.asc Description: Digital signature
