| Message ID | CALT56yO8tktrXo0rfRd91AtXBE4F5vYfYjm9AL+7dcoam6Oq9Q@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > I have sketched a compile-tested only PHY for the Lubbock platform. Could you > please take a look and test. > git://git.infradead.org/users/dbaryshkov/zaurus.git lubbock Okay, now my ADSL line is repaired, thank you Mr farmer "I drive a tractor but I don't care about telephone posts", I'll fetch your changes and make a test. Let's say I schedule this for saturday. Cheers. -- Robert
2014-11-19 23:29 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: > Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > >> I have sketched a compile-tested only PHY for the Lubbock platform. Could you >> please take a look and test. >> git://git.infradead.org/users/dbaryshkov/zaurus.git lubbock > > Okay, now my ADSL line is repaired, thank you Mr farmer "I drive a tractor but I > don't care about telephone posts", I'll fetch your changes and make a > test. Let's say I schedule this for saturday. Fine with me, thank you.
Robert Jarzmik <robert.jarzmik@free.fr> writes: > Okay, now my ADSL line is repaired, thank you Mr farmer "I drive a tractor but I > don't care about telephone posts", I'll fetch your changes and make a > test. Let's say I schedule this for saturday. Removed people from the list for the tests aspect. Well, my lubbock board seem to raise several interrupts in the linux kernel, all the LUBBOCK_IRQ interrupts multiplexed on GPIO0 actually, amongst which are the 2 interrupts for the UDC. That will mean delay I'm afraid, as I have to find out what happens. I'm pretty sure the hardware is OK, because the "blob" loader uses the ethernet card which is amongst the LUBBOCK_IRQs. There is probably a regression in the kernel not seen for several revisions, and I have to fix it before I can test. Cheers.
2014-11-22 16:56 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: > Robert Jarzmik <robert.jarzmik@free.fr> writes: >> Okay, now my ADSL line is repaired, thank you Mr farmer "I drive a tractor but I >> don't care about telephone posts", I'll fetch your changes and make a >> test. Let's say I schedule this for saturday. > > Removed people from the list for the tests aspect. > > Well, my lubbock board seem to raise several interrupts in the linux kernel, all > the LUBBOCK_IRQ interrupts multiplexed on GPIO0 actually, amongst which are the > 2 interrupts for the UDC. This looks normal - GPIO0 is connected to an interrupt pin of the CPLD. lubbock_init_irq function should be setting up a chained handler for the GPIO0. And that chained handler (lubbock_irq_handler) should further decode which IRQ bit is set. Do you see the handler being called? Can you print the (pending) variable in the handler?
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > 2014-11-22 16:56 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: >> Robert Jarzmik <robert.jarzmik@free.fr> writes: >>> Okay, now my ADSL line is repaired, thank you Mr farmer "I drive a tractor but I >>> don't care about telephone posts", I'll fetch your changes and make a >>> test. Let's say I schedule this for saturday. >> >> Removed people from the list for the tests aspect. >> >> Well, my lubbock board seem to raise several interrupts in the linux kernel, all >> the LUBBOCK_IRQ interrupts multiplexed on GPIO0 actually, amongst which are the >> 2 interrupts for the UDC. Arg, what I meant to write was "seem to *never* raise several interrupts". > This looks normal - GPIO0 is connected to an interrupt pin of the CPLD. > lubbock_init_irq function should be setting up a chained handler for the GPIO0. > And that chained handler (lubbock_irq_handler) should further decode which > IRQ bit is set. Do you see the handler being called? Can you print the (pending) > variable in the handler? lubbock_irq_handler() is never called. pxa_gpio_demux_handler() is never called. => this is the one worrying me most. And as the lubbock_irq_handler() is never called there is not point in printing that yet, first should be finding out why on earth the gpio demux is not getting called. Cheers.
Hello, 2014-11-22 20:18 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: > Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > >> 2014-11-22 16:56 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: >>> Robert Jarzmik <robert.jarzmik@free.fr> writes: >>>> Okay, now my ADSL line is repaired, thank you Mr farmer "I drive a tractor but I >>>> don't care about telephone posts", I'll fetch your changes and make a >>>> test. Let's say I schedule this for saturday. >>> >>> Removed people from the list for the tests aspect. >>> >>> Well, my lubbock board seem to raise several interrupts in the linux kernel, all >>> the LUBBOCK_IRQ interrupts multiplexed on GPIO0 actually, amongst which are the >>> 2 interrupts for the UDC. > Arg, what I meant to write was "seem to *never* raise several interrupts". Understood. Just to make me sure - does the upstream kernel work?
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > Hello, > > 2014-11-22 20:18 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: >> >>> 2014-11-22 16:56 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: >>>> Robert Jarzmik <robert.jarzmik@free.fr> writes: >>>>> Okay, now my ADSL line is repaired, thank you Mr farmer "I drive a tractor but I >>>>> don't care about telephone posts", I'll fetch your changes and make a >>>>> test. Let's say I schedule this for saturday. >>>> >>>> Removed people from the list for the tests aspect. >>>> >>>> Well, my lubbock board seem to raise several interrupts in the linux kernel, all >>>> the LUBBOCK_IRQ interrupts multiplexed on GPIO0 actually, amongst which are the >>>> 2 interrupts for the UDC. >> Arg, what I meant to write was "seem to *never* raise several interrupts". > > Understood. Just to make me sure - does the upstream kernel work? Nope, that's the current situation with the upstream kernel. Cheers.
2014-11-22 20:49 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: > Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > >> Hello, >> >> 2014-11-22 20:18 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: >>> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: >>> >>>> 2014-11-22 16:56 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: >>>>> Robert Jarzmik <robert.jarzmik@free.fr> writes: >>>>>> Okay, now my ADSL line is repaired, thank you Mr farmer "I drive a tractor but I >>>>>> don't care about telephone posts", I'll fetch your changes and make a >>>>>> test. Let's say I schedule this for saturday. >>>>> >>>>> Removed people from the list for the tests aspect. >>>>> >>>>> Well, my lubbock board seem to raise several interrupts in the linux kernel, all >>>>> the LUBBOCK_IRQ interrupts multiplexed on GPIO0 actually, amongst which are the >>>>> 2 interrupts for the UDC. >>> Arg, what I meant to write was "seem to *never* raise several interrupts". >> >> Understood. Just to make me sure - does the upstream kernel work? > Nope, that's the current situation with the upstream kernel. Next point would be (from my POV) to make sure that lubbock_unmask_irq() is called and works as expected.
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > 2014-11-22 20:49 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: > Next point would be (from my POV) to make sure that > lubbock_unmask_irq() is called > and works as expected. Actually the problem is probably within the CPLD. Irrespective of the CPLD register LUB_IRQ_MASK_EN, the GPIO0 is always low, indicating an interrupt all the time. The only thing that changes that is the switch SW13, which forces GPIO0 to high, but prevents interrupts. Normally, GPIO0 = (SW13 | ! (LUB_IRQ_MASK_EN && LUB_IRQ_SET_CLR)) This is why I don't have any interrupt, next stage will be to verify U46 and U54 on the IO board for GPIO_INT# and USB_INT# signals ... Cheers.
OK Dmitry, I pulled through, the interrupts are working back. Actually one of the blockers I have is in pxa25x_udc, and it is also in your phy-lubbock.c. The bottom of the error is that disable_irq() is called from within a irq handler, and it deadlocks. A disable_irq_nosync() should be used ... ... but a better approach would be to use a threaded irq for vbus handling. I think that way disable_irq() can be used, no workqueue is needed anymore in phy-lubbock. Would you make that change, I'll test it and review it. Cheers. -- Robert
2014-11-27 1:12 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: > OK Dmitry, I pulled through, the interrupts are working back. What was the problem? Hardware issues? Firmware in CPLD being of old revision? > Actually one of the blockers I have is in pxa25x_udc, and it is also in your > phy-lubbock.c. The bottom of the error is that disable_irq() is called from > within a irq handler, and it deadlocks. A disable_irq_nosync() should be used > ... > > ... but a better approach would be to use a threaded irq for vbus handling. I > think that way disable_irq() can be used, no workqueue is needed anymore in > phy-lubbock. > > Would you make that change, I'll test it and review it. OK, I will take a look in a next few days. BTW: I have also received a pxa270 board (Sophia Sandgate II, the one without the additional graphics accelerator), so after spending some efforts on bringup & bsp, I should be able to also test pxa270 code.
2014-11-27 1:38 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: > Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > >> 2014-11-27 1:12 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: >>> OK Dmitry, I pulled through, the interrupts are working back. >> >> What was the problem? Hardware issues? Firmware in CPLD being of old >> revision? > There were basically 2 problems : > - hardware: switch S13 was in a position that disabled interrupts all the time > One other problem which fooled me was the incorrect gate schematics I had, > and which make my understanding of linear function foo such as > GPIO0 = foo(LUB_IRQ_EN, LUB_SET_CLR) false. > > - software: lubbock.c error > Since gpio-pxa was ported to device/gpio, it is probed *after* > lubbock_init_irq() is called. As lubbock_init_irq() installs > lubbock_irq_handler() and sets the irq to falling edge detect before gpio-pxa > is probed, gpio-pxa probe overwrites this by : > - clearing any edge detection (probe state reset) > - installing generic handle_edge_irq() instead of the lubbock irq handler > > So the conclusion is that I have to rework lubbock_init_irq(), remove from it > the PXA_GPIO_TO_IRQ(0) stuff, and move it to a code in lubbock.c which will > provide the guarantee of being executed _after_ gpio-pxa is probed. When I'm > happy with my patch I'll submit it. Thank you for your explanation.