Hi, On Mon, Apr 22, 2013 at 11:54:34AM +0300, yehuda yitchak wrote: > >> >> I want to ask your advice on the best approach for implementing a new > >> >> XHCI host controller. > >> >> I am going to add Linux support for a new XHCI host controller for Marvell SOCs. > >> >> > >> >> I looked around the latest XHCI support code in the kernel and found > >> >> that a platform driver called “xhci-hcd” exists. > >> >> > >> >> And there is also one XHCI device (DRD dwc3 used by Samsung and TI) > >> >> that bounds to this driver. > >> >> > >> >> My case is somewhat simpler than the dwc3 since it’s not a Dual Role Device. > >> >> Basically I need to initialize some SOC level registers and then > >> >> register an xhci-hcd device. Also I need to implement suspend/resume > >> >> hooks to save and restore the SOC registers initialized at the probe > >> >> function. > >> >> > >> >> I was thinking to take the following approach: > >> >> > >> >> 1. Under drivers/usb/host - Register a new platform driver called > >> >> “xhci-mv” which will initialize the SOC specific stuff and register an > >> >> “xhci-hcd” platform device. > >> > > >> > no new xhci-mv. Reuse xhci-plat.c which is supposed to be generic. > >> > >> Then where am i supposed to initialize the SOC specific stuff > > > > before driver probe in your platform initialization ? > > > >> For example in the host controller we have some registers > >> that map the access to the DRAM space. i need a probe, suspend and > >> resume hook to initialize them to save and restore them among other > >> stuff. > > > > these sounds like it can be done in your bus dev_pm_ops, but hey, send a > > patch and we will see how similar will it look to xhci-plat.c, then > > figure out if we should have another glue or not. > > At this time entire machine still doesnt exist in mainline. > Can you review a patch without the machine code in mainline ? sure, no problem -- balbi
Attachment:
signature.asc
Description: Digital signature
