| Message ID | 1416236863-20898-3-git-send-email-dbaryshkov@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > Change clk_enable/disable() calls to clk_prepare_enable() and > clk_disable_unprepare(). > > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > --- > drivers/usb/gadget/udc/pxa25x_udc.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c b/drivers/usb/gadget/udc/pxa25x_udc.c > index 42f7eeb..e4964ee 100644 > --- a/drivers/usb/gadget/udc/pxa25x_udc.c > +++ b/drivers/usb/gadget/udc/pxa25x_udc.c > @@ -103,8 +103,8 @@ static const char ep0name [] = "ep0"; > > /* IXP doesn't yet support <linux/clk.h> */ > #define clk_get(dev,name) NULL > -#define clk_enable(clk) do { } while (0) > -#define clk_disable(clk) do { } while (0) > +#define clk_prepare_enable(clk) do { } while (0) > +#define clk_disable_unprepare(clk) do { } while (0) > #define clk_put(clk) do { } while (0) > > #endif > @@ -932,7 +932,7 @@ static int pullup(struct pxa25x_udc *udc) > if (!udc->active) { > udc->active = 1; > /* Enable clock for USB device */ > - clk_enable(udc->clk); > + clk_prepare_enable(udc->clk); Guess what, Russell's remark on i2c and serial made me cross-check. And there is a case where this will be called in irq context too ... See : -> do_IRQ -> lubbock_vbus_irq() -> pxa25x_udc_vbus_session() -> pullup() -> clk_prepare_enable() -> CRACK Note that your patch is not really the faulty one, I think a threaded irq instead of the "raw" irq should do the trick. And it is granted on UDC api that vbus function is called in a "sleeping" context (Felipe correct me if I'm wrong), so a patch to fix this before your current code would be fine. Cheers. -- Robert
Hello, 2014-11-17 21:44 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: > Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > >> Change clk_enable/disable() calls to clk_prepare_enable() and >> clk_disable_unprepare(). >> >> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> >> --- >> drivers/usb/gadget/udc/pxa25x_udc.c | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c b/drivers/usb/gadget/udc/pxa25x_udc.c >> index 42f7eeb..e4964ee 100644 >> --- a/drivers/usb/gadget/udc/pxa25x_udc.c >> +++ b/drivers/usb/gadget/udc/pxa25x_udc.c >> @@ -103,8 +103,8 @@ static const char ep0name [] = "ep0"; >> >> /* IXP doesn't yet support <linux/clk.h> */ >> #define clk_get(dev,name) NULL >> -#define clk_enable(clk) do { } while (0) >> -#define clk_disable(clk) do { } while (0) >> +#define clk_prepare_enable(clk) do { } while (0) >> +#define clk_disable_unprepare(clk) do { } while (0) >> #define clk_put(clk) do { } while (0) >> >> #endif >> @@ -932,7 +932,7 @@ static int pullup(struct pxa25x_udc *udc) >> if (!udc->active) { >> udc->active = 1; >> /* Enable clock for USB device */ >> - clk_enable(udc->clk); >> + clk_prepare_enable(udc->clk); > > Guess what, Russell's remark on i2c and serial made me cross-check. And there > is a case where this will be called in irq context too ... > > See : > -> do_IRQ > -> lubbock_vbus_irq() > -> pxa25x_udc_vbus_session() > -> pullup() > -> clk_prepare_enable() > -> CRACK > > Note that your patch is not really the faulty one, I think a threaded irq > instead of the "raw" irq should do the trick. And it is granted on UDC api that > vbus function is called in a "sleeping" context (Felipe correct me if I'm > wrong), so a patch to fix this before your current code would be fine. OK, I will take a look. It seems the correct way would be to strip this code away to a phy, like gpio-vbus or nop phys. Do you have access to lubbock (or maybe Daniel, Haojian or Russell has?)? Also, as we are at it. Imre, Krzysztof, IIRC ixp4xx platform does not provide clock api either in a form of COMMON_CLK or in a local hacked form (like sa1100 does). Do you plan to add any in future, or it just does not make sense to support this API for ixp4xx?
On Tue, Nov 18, 2014 at 12:05:45AM +0400, Dmitry Eremin-Solenikov wrote: > Hello, > > 2014-11-17 21:44 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: > > Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > > > >> Change clk_enable/disable() calls to clk_prepare_enable() and > >> clk_disable_unprepare(). > >> > >> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > >> --- > >> drivers/usb/gadget/udc/pxa25x_udc.c | 8 ++++---- > >> 1 file changed, 4 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c b/drivers/usb/gadget/udc/pxa25x_udc.c > >> index 42f7eeb..e4964ee 100644 > >> --- a/drivers/usb/gadget/udc/pxa25x_udc.c > >> +++ b/drivers/usb/gadget/udc/pxa25x_udc.c > >> @@ -103,8 +103,8 @@ static const char ep0name [] = "ep0"; > >> > >> /* IXP doesn't yet support <linux/clk.h> */ > >> #define clk_get(dev,name) NULL > >> -#define clk_enable(clk) do { } while (0) > >> -#define clk_disable(clk) do { } while (0) > >> +#define clk_prepare_enable(clk) do { } while (0) > >> +#define clk_disable_unprepare(clk) do { } while (0) > >> #define clk_put(clk) do { } while (0) > >> > >> #endif > >> @@ -932,7 +932,7 @@ static int pullup(struct pxa25x_udc *udc) > >> if (!udc->active) { > >> udc->active = 1; > >> /* Enable clock for USB device */ > >> - clk_enable(udc->clk); > >> + clk_prepare_enable(udc->clk); > > > > Guess what, Russell's remark on i2c and serial made me cross-check. And there > > is a case where this will be called in irq context too ... > > > > See : > > -> do_IRQ > > -> lubbock_vbus_irq() > > -> pxa25x_udc_vbus_session() > > -> pullup() > > -> clk_prepare_enable() > > -> CRACK > > > > Note that your patch is not really the faulty one, I think a threaded irq > > instead of the "raw" irq should do the trick. And it is granted on UDC api that > > vbus function is called in a "sleeping" context (Felipe correct me if I'm > > wrong), so a patch to fix this before your current code would be fine. > > OK, I will take a look. It seems the correct way would be to strip this code > away to a phy, like gpio-vbus or nop phys. Do you have access to lubbock > (or maybe Daniel, Haojian or Russell has?)? Robert has my Lubbock now.
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > Hello, > OK, I will take a look. It seems the correct way would be to strip this code > away to a phy, like gpio-vbus or nop phys. Do you have access to lubbock > (or maybe Daniel, Haojian or Russell has?)? Actually Russell kindly gave me his, so I do have one for testing :) > Also, as we are at it. Imre, Krzysztof, IIRC ixp4xx platform does not provide > clock api either in a form of COMMON_CLK or in a local hacked form > (like sa1100 does). Do you plan to add any in future, or it just does not > make sense to support this API for ixp4xx? I don't have any plans for ixp4xx. Cheers.
On Tue, Nov 18, 2014 at 12:05:45AM +0400, Dmitry Eremin-Solenikov wrote: > Hello, > > 2014-11-17 21:44 GMT+03:00 Robert Jarzmik <robert.jarzmik@free.fr>: > > Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> writes: > > > >> Change clk_enable/disable() calls to clk_prepare_enable() and > >> clk_disable_unprepare(). > >> > >> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > >> --- > >> drivers/usb/gadget/udc/pxa25x_udc.c | 8 ++++---- > >> 1 file changed, 4 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c b/drivers/usb/gadget/udc/pxa25x_udc.c > >> index 42f7eeb..e4964ee 100644 > >> --- a/drivers/usb/gadget/udc/pxa25x_udc.c > >> +++ b/drivers/usb/gadget/udc/pxa25x_udc.c > >> @@ -103,8 +103,8 @@ static const char ep0name [] = "ep0"; > >> > >> /* IXP doesn't yet support <linux/clk.h> */ > >> #define clk_get(dev,name) NULL > >> -#define clk_enable(clk) do { } while (0) > >> -#define clk_disable(clk) do { } while (0) > >> +#define clk_prepare_enable(clk) do { } while (0) > >> +#define clk_disable_unprepare(clk) do { } while (0) > >> #define clk_put(clk) do { } while (0) > >> > >> #endif > >> @@ -932,7 +932,7 @@ static int pullup(struct pxa25x_udc *udc) > >> if (!udc->active) { > >> udc->active = 1; > >> /* Enable clock for USB device */ > >> - clk_enable(udc->clk); > >> + clk_prepare_enable(udc->clk); > > > > Guess what, Russell's remark on i2c and serial made me cross-check. And there > > is a case where this will be called in irq context too ... > > > > See : > > -> do_IRQ > > -> lubbock_vbus_irq() > > -> pxa25x_udc_vbus_session() > > -> pullup() > > -> clk_prepare_enable() > > -> CRACK > > > > Note that your patch is not really the faulty one, I think a threaded irq > > instead of the "raw" irq should do the trick. And it is granted on UDC api that > > vbus function is called in a "sleeping" context (Felipe correct me if I'm > > wrong), so a patch to fix this before your current code would be fine. Well, from the framework point of view, ->pullup() is only called outside of IRQ context. But I see you're calling it from vbus_irq(), so you brought this upon yourself :-)
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.
diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c b/drivers/usb/gadget/udc/pxa25x_udc.c index 42f7eeb..e4964ee 100644 --- a/drivers/usb/gadget/udc/pxa25x_udc.c +++ b/drivers/usb/gadget/udc/pxa25x_udc.c @@ -103,8 +103,8 @@ static const char ep0name [] = "ep0"; /* IXP doesn't yet support <linux/clk.h> */ #define clk_get(dev,name) NULL -#define clk_enable(clk) do { } while (0) -#define clk_disable(clk) do { } while (0) +#define clk_prepare_enable(clk) do { } while (0) +#define clk_disable_unprepare(clk) do { } while (0) #define clk_put(clk) do { } while (0) #endif @@ -932,7 +932,7 @@ static int pullup(struct pxa25x_udc *udc) if (!udc->active) { udc->active = 1; /* Enable clock for USB device */ - clk_enable(udc->clk); + clk_prepare_enable(udc->clk); udc_enable(udc); } } else { @@ -945,7 +945,7 @@ static int pullup(struct pxa25x_udc *udc) } udc_disable(udc); /* Disable clock for USB device */ - clk_disable(udc->clk); + clk_disable_unprepare(udc->clk); udc->active = 0; }
Change clk_enable/disable() calls to clk_prepare_enable() and clk_disable_unprepare(). Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> --- drivers/usb/gadget/udc/pxa25x_udc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)