lkml.org 
[lkml]   [2015]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: similar files: fusbh200-hcd.c and fotg210-hcd.c
From
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


\
 
 \ /
  Last update: 2015-09-14 20:01    [W:0.149 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site