Hi Sergei
> >>>> 0xAAAA0000 ===========
> >>>> EHCI
> >>>> ----------
> >>>> 0xAAAA0094 PHY
> >>>> 0xAAAA009C PHY
> >>>> ----------
> >>>> EHCI
> >>>> 0xAAAA0400 ==========
> >>>> ...
> >>>> 0xAAAA0800 ----------
> >>>> PHY
> >>>> 0xAAAA0900 ----------
>
> >>>> This driver couldn't probe if it used "request_mem_region()"
>
> >>> Fair enough. I must say, though. That's a peculiar register mapping ;-)
>
> >> Not peculiar enough to not be able to overcome it. Those registers
> >> at 0xAAAA009[4C]
> >> are not really PHY related, they control EHCI internal buffering. They
> >> probably shouldn't
> >> have been a part of this driver even...
>
> > I'm not sure what is the best solution.
>
> I suspect that these registers should be intialized as a part of
> ehci-platform driver's power_on() platform callback.
I had same opinion before, and of course I agree your opinion.
But, not in power_on() callback.
I guess you need to create new callback (for init),
since power_on() and ioremap() timing
if (pdata->power_on) {
err = pdata->power_on(dev);
if (err < 0)
return err;
}
...
hcd->regs = devm_ioremap_resource(&dev->dev, res_mem);
if (IS_ERR(hcd->regs)) {
err = PTR_ERR(hcd->regs);
goto err_put_hcd;
}
# init() here ?
if (pdata->init)
err = pdata->init(dev, hcd->regs);
Best regards
---
Kuninori Morimoto
--
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
