Hello.
David Brownell wrote:
Oops. Somehow this mail went unnoticed by me -- I've noticed it only
yesterday, hence there was no reply. Replying now...
Texas Instruments DA830/OMAP-L137 glue layer for the MUSBMHRDC driver.
Please hold off on these patches -- except maybe as
an RFC -- until the DA830 stuff merges to mainline.
OK, will mark them as RFC on the next repost. In the meanwhile, DA830
support has mede it into the linux-davinci tree...
A noted before, it can't build yet, so it's nowhere
near suitable for merging...
That said, a quick look over this code suggests that
it's basically OK. Though:
+ /* Workaround: setup IRQs through both register sets. */
Workaround *what* problem? Please reference an erratum
No idea, actually. This comment was just copied from the DaVinci code.
or something, so that if a better workaround (perhaps more
sensitive to chip revisions, like "not needed on rev C")
becomes available, this can be properly removed.
+ musb->clock = clk_get(NULL, "USB20CLK");
You should provide the device.
OK.
I tihnk with the latest
rework of the DaVinci clock framework, the NULL is best
passed for the clock name instead.
I'm not sure -- the clock name still gets passed via MUSB platform data,
although da830.c has this, unlike dm{355|644x}.c:
CLK("musb_hdrc", NULL, &usb20_clk),
Probably you're right.
Also:
- that OTG timer is still messy, and probably at
least partially wrong ... likely it'll get cleaned
up on "normal" DaVinci chips first though.
Now wonder, I've blindly copied that part from davinci.c.
- Is this still using the 1.3 RTL instead of something
newer?
I'm not sure TBH -- let me see. Aha, it uses 1.8:
musb_hdrc: MHDRC RTL version 1.800
- Didn't you fix all the "ret != IRQ_HANDLED" cases
for the IRQ handler?
I was also getting unhandled SOF interrupts (but perhaps in my internal
tree only). The other ugliness that caused me to check for (ret !=
IRQ_HANDLED) is the interrupt storms in periperal mode: long interrupt
series with no status that caused the kernel to mask off the interrupt
finally. Thed I didn't know the reason and suspected undocumented eraatum,
now this erratum seems to be documented as "advisory 1.1.2" but suggested
workaround is somewhat clumsy (the DMA scheduler needs to be reprogrammed to
and fro)... maybe there's another workaround (like only enabling CPPI 4.1
channels while actually transferring the data) -- I haven't tried it yet.
- Handling of the PHY is no better here than in the
DaVinci support ... sigh.
No wonder, I mostly copied the code from davinci.c. Still, it's somewhat
better I think as I have at least avoided machine_is_*() calls like plague
-- putting all machine specific CFGCHIP2 register initialization into
arch/arm/ (to be submitted yet). Your suggestions?
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
