Date: Sun, 19 Aug 2012 20:28:24 -0600 From: Warner Losh <imp@bsdimp.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Andrew Turner <andrew@fubar.geek.nz> Subject: Re: Recent changes in AT91 kernel code causes USB to not work [WAS: r239214 - in head/sys: dev/usb dev/usb/controller sys] Message-ID: <4BC29F9C-B068-4464-9619-3ACD00D7C388@bsdimp.com> In-Reply-To: <201208191832.39569.hselasky@c2i.net> References: <20120819202622.6db6a8dd@fubar.geek.nz> <zarafa.5030d8f9.78da.3793f9461199bff8@eric2.bitfrost> <201208191832.39569.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 19, 2012, at 10:32 AM, Hans Petter Selasky wrote:
> Hi,
>=20
> I'm trying to reproduce using "src/sys/KB920X arm".
>=20
> So far the platform doesn't boot, because recent commits removed one =
ore more=20
> of these clocks:
>=20
> sc->sc_iclk =3D at91_pmc_clock_ref("udc_clk");
> sc->sc_fclk =3D 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.
>=20
> 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:
>=20
> sys/dev/usb/controller/ohci_atmelarm.c
>=20
> + 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=20
> bus_space_write_4(sc->sc_ohci.sc_io_tag, sc->sc_ohci.sc_io_hdl,
> OHCI_CONTROL, 0);
>=20
> + printf("INIT\n");
>=20
> I see the clock ON printout, and then nothing more! Not sure if this =
is caused=20
> by IRQ's hanging or not.
>=20
> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BC29F9C-B068-4464-9619-3ACD00D7C388>