Recent changes in AT91 kernel code causes USB to not work [WAS: r239214 - in head/sys: dev/usb dev/usb/controller sys]

[Warner Losh]

On Aug 19, 2012, at 10:32 AM, Hans Petter Selasky wrote:

> Hi,
> 
> I'm trying to reproduce using "src/sys/KB920X arm".
> 
> So far the platform doesn't boot, because recent commits removed one ore more 
> of these clocks:
> 
>        sc->sc_iclk = at91_pmc_clock_ref("udc_clk");
>        sc->sc_fclk = at91_pmc_clock_ref("udpck");

AT91RM9200 hasn't supported clocks very well at all.  But I don't think that these clocks have ever been defined on the 9200 platform.

> So I get a crash at a NULL pointer when trying to access one of these clocks.
> 
> How to fix this?

Hmmmm, the code didn't even compile until recently, and has crashed every time I used it.

> I simply added a NULL check. Now the platform hangs when setting up the OHCI:
> 
> sys/dev/usb/controller/ohci_atmelarm.c
> 
> +       printf("CLOCK ON\n");
>        at91_pmc_clock_enable(sc->iclk);
>        at91_pmc_clock_enable(sc->fclk);

These should be nops, because we enable all the pmc clocks early in the attach process.  that's likely the problem, if we aren't turning on the clocks to the usb device (gadget), then 

>        bus_space_write_4(sc->sc_ohci.sc_io_tag, sc->sc_ohci.sc_io_hdl,
>            OHCI_CONTROL, 0);
> 
> +       printf("INIT\n");
> 
> I see the clock ON printout, and then nothing more! Not sure if this is caused 
> by IRQ's hanging or not.
> 
> Andrew Turner: Can you fix these issues so that I can reproduce?

It would help if you could pin-point where this stuff fails in the stream of commits.  I know mine were purposely small and isolated so that they would be easy to bisect.

Warner