Messages in this thread | | | Date | Mon, 14 Sep 2015 19:50:02 +0200 | Subject | Re: similar files: fusbh200-hcd.c and fotg210-hcd.c | From | Peter Senna Tschudin <> |
| |
On Mon, Sep 14, 2015 at 5:01 PM, Felipe Balbi <balbi@ti.com> wrote: > On Sat, Sep 12, 2015 at 03:14:50PM +0200, Peter Senna Tschudin wrote: >> >> Should these files be consolidated? And if so how? >> > if you can find an easy way, that would be a very, very welcome patch. >> >> Is the ideal solution to consolidate both fusbh200-hcd.c and >> fotg210-hcd.c in a single module? If this is the case, how to detect >> at run time which version of the hw is present? Both are registered as > > does it matter ? If they work the same way, why does it matter which > one's running?
I may be missing something simple, but based on a 2 page product brief, fotg210 has more resources like memory. So even if the .c files are _very_ similar, there are some configuration parameters that differ, for example:
fusbh200.h: #define BMCSR_VBUS_OFF (1<<4) #define BMCSR_INT_POLARITY (1<<3)
fotg210.h: #define OTGCSR_A_BUS_DROP (1 << 5) #define OTGCSR_A_BUS_REQ (1 << 4)
which are used by {fusbh200,fotg210}_init:
fusbh200-hcd.c: static void fusbh200_init(struct fusbh200_hcd *fusbh200) { u32 reg;
reg = fusbh200_readl(fusbh200, &fusbh200->regs->bmcsr); reg |= BMCSR_INT_POLARITY; reg &= ~BMCSR_VBUS_OFF; fusbh200_writel(fusbh200, reg, &fusbh200->regs->bmcsr);
reg = fusbh200_readl(fusbh200, &fusbh200->regs->bmier); fusbh200_writel(fusbh200, reg | BMIER_OVC_EN | BMIER_VBUS_ERR_EN, &fusbh200->regs->bmier); }
fotg210-hcd.c: static void fotg210_init(struct fotg210_hcd *fotg210) { u32 value;
iowrite32(GMIR_MDEV_INT | GMIR_MOTG_INT | GMIR_INT_POLARITY, &fotg210->regs->gmir);
value = ioread32(&fotg210->regs->otgcsr); value &= ~OTGCSR_A_BUS_DROP; value |= OTGCSR_A_BUS_REQ; iowrite32(value, &fotg210->regs->otgcsr); }
Then:
fusbh200.h: #define BMCSR_HOST_SPD_TYP (3<<9)
static inline unsigned int fusbh200_get_speed(struct fusbh200_hcd *fusbh200, unsigned int portsc) { return (readl(&fusbh200->regs->bmcsr) & BMCSR_HOST_SPD_TYP) >> 9; }
fotg210.h: #define OTGCSR_HOST_SPD_TYP (3 << 22) static inline unsigned int
fotg210_get_speed(struct fotg210_hcd *fotg210, unsigned int portsc) { return (readl(&fotg210->regs->otgcsr) & OTGCSR_HOST_SPD_TYP) >> 22; }
So my concern is to have a way to identify which is the device version to use the right parameters. I think that the BMCSR_HOST_SPD_TYP vs OTGCSR_HOST_SPD_TYP can be solved, but I'm not sure about the initialization. Ideas?
> >> platform devices and I could not find an obvious way to detect the >> model at run time. I could successfully load fusbh200-hcd on my fedora > > is there a revision register ? Or you may use different platform_device > names with platform_device_id table.
I don't know about revision registers. That would be good. I could not find complete datasheets, only a 2 page product brief, no registry information there.
> >> notebook (hp elitebook 840), and on a VM, even if neither has the hw >> ($ sudo modprobe fusbh200-hcd). The module loads with the warning >> "fusbh200_hcd should always be loaded before uhci_hcd and ohci_hcd, >> not after". On another workstation running ubuntu, I could load both >> modules at the same time, producing the same warning for each module. >> Should the module load if the device is not present? >> >> Other solution for consolidation would be to create a common_code.c, >> keeping both fusbh200-hcd.c and fotg210-hcd.c only with the code that >> differ. Is this better than what is there now? >> >> Other ideas? > > just combine them :-p Use platform_device_id to differentiate.
I'm afraid the combined version will use the correct parameters for only one of the two. But I may be missing something simple. I did a diff between the two files after removing white space differences, and after replacing fusbh200 by fotg210 on the fusbh200 driver. The files are very similar. See: http://pastebin.com/ZRY3xePv
> > -- > balbi
-- Peter
| |