Hello.
On 20-03-2014 10:42, Arnd Bergmann wrote:
Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
The idea at the time was to just ioremap() this register but I was not
very eager.
... also it was suggested to pass the CFGCHIP2 address as a resource. I
certainly wasn't eager to do that since if done for both MUSB and OHCI, it
would cause sort of a resource conflict (platform device resources are
automatically registered in the resource tree, although without marking them
exclusive), even if we don't call request_mem_region() on them (we can't do
that since in this case the resource would be registered as exclusive, and the
second call would fail).
Yes, that would work, too. However, that would cause problems later
if we ever try to make the davinci platform "multiplatform", unless we also
pass the physical address in a platform resource and make this a larger
driver.
In my opinion, we don't have to pass CFGCHIP2 as a resource and could just
ioremap() the raw physical address.
I think we can reasonably have an exported set of functions
declared in the platform data header file for these drivers, but passing
the physical address through a header file
That's how it's passed today (however, thru <mach/da8xx.h>).
wouldn't be much of an improvement
over passing the virtual address.
Not sure I understood about passing virtual address.
There was no USB PHY driver subsystem yet.
to control the clock, phy
Note that it only controls PHY clock (PLL) which could be covered by an
USB PHY driver.
Good point.
and host/gadget mode switch.
The main mode the USB 2.0 PHY should function now is OTG. The host/gadged
modes are forced overrides of the ID pin. Unfortunately, the board code has to
force host mode when host-only driver config is selected (these MUSB's
host/gadget only modes were removed at one point but got reintroduced again).
I think they are also required for 'randconfig' builds to some degree, because
you can build a kernel without host mode for instance.
Yes.
In the modern world, we'd probably want to have a clock driver and
Not sure about the clock driver...
a phy driver for these,
Yes, that's what the MUSB maintainer wants too. The issue is the driver
should somehow differ which USB controller it's bound too and do different
things depending on that (at least that's how it looks now). I'm not sure it's
possible, so probably should be rethought.
Yes, a phy driver seems the right approach if we can find someone to do it.
Perhaps a person that tried to unbreak the DA8xx MUSB driver could be
interested (and competent) enough to do it...
Ideally that should let us use generic versions of the ohci and musb drivers
even, if that's the only davinci specific part of these drivers.
No, not really. MUSB ceratinly has DaVinci specific register set mapped in
its register space. OHCI has up to 2 clocks to enable since USB 1.1 PHY can be
clocked from USB 2.0 PHY clock.
based on a syscon driver.
I don't know what syscon is...
The syscon (system controller) framework helps share a set of registers
across multiple drivers. If all accesses to the CFGCHIP2 register are
in a single PHY driver, we wouldn't need it.
Where can I find it in the kernel tree?
In all honesty I don't see that happening on davinci.
I don't think people use USB 1.1 controllers these days, especially when
there is USB 2.0 in the same SoC. For MUSB, there were recent attempt to get
the DA8xx driver out of the broken state but it was turned down as well, IIRC,
since it didn't offer a PHY driver.
For USB 2.0 compliance you actually need to provide something to handle the
low speed modes. A lot of people use a hub to do that nowadays rather than
an OHCI or UHCI, but I don't know if that works with OTG.
MUSB handles all speeds. I think the reason TI also included USB 1.1
controller lies in the somewhat dubious reputation of both MUSB hardware and
the Linux driver.
Arnd
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
