Hi,
On Tue, Oct 13, 2015 at 05:57:59PM -0500, Felipe Balbi wrote:
> Sebastian Reichel <sre@xxxxxxxxxx> writes:
> > On Tue, Oct 13, 2015 at 10:50:45AM -0500, Felipe Balbi wrote:
> >> Rolf Peukert <rolf.peukert@xxxxxxx> writes:
> >> > On 13.10.2015 10:15, Tero Kristo wrote:
> >> >> On 10/12/2015 06:22 PM, Rolf Peukert wrote:
> >> >>> The glue code in drivers/usb/musb/am35x.c calls clk_get() to get its
> >> >>> interface and function clocks for the M-USB controller. These calls fail
> >> >>> in the current kernel. This patch adds clock definitions containing the
> >> >>> device ID to the list in clk-3xxx.c, so the calls to clk_get() in
> >> >>> am35x.c can succeed.
> >> >>>
> >> >>> Signed-off-by: Rolf Peukert <rolf.peukert@xxxxxxx>
> >> >>>
> >> >>> ---
> >> >>> drivers/clk/ti/clk-3xxx.c | 2 ++
> >> >>> 1 file changed, 2 insertions(+)
> >> >>>
> >> >>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
> >> >>> index 8831e1a..b635deb 100644
> >> >>> --- a/drivers/clk/ti/clk-3xxx.c
> >> >>> +++ b/drivers/clk/ti/clk-3xxx.c
> >> >>> @@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
> >> >>> DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
> >> >>> DT_CLK("vpfe-capture", "master", "vpfe_ick"),
> >> >>> DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
> >> >>> + DT_CLK("5c040000.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
> >> >>> DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
> >> >>> + DT_CLK("5c040000.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
> >> >>> DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
> >> >>> DT_CLK(NULL, "hecc_ck", "hecc_ck"),
> >> >>> DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),
> >> >>>
> >> >>
> >> >> Adding clock aliases should be avoided, isn't there any other way to fix
> >> >> this issue? Like adding clocks = <&xyz> references under the DT node?
> >> >>
> >> >> -Tero
> >> >>
> >> >
> >> > Yes, I just tried adding the lines
> >> >
> >> > clocks = <&hsotgusb_ick_am35xx>, <&hsotgusb_fck_am35xx>;
> >> > clock-names = "ick", "fck";
> >> >
> >> > to am3517.dtsi and this works too. But wouldn't this mean the driver
> >> > will not work anymore in kernels without DT support?
> >>
> >> I have this doubt myself. This will break on non-DT boots and,
> >> while we're trying to move to DT-only, IMO meanwhile we should
> >> allow for fixes to DT and non-DT world. Once the conversion is
> >> done, fine.
> >
> > Isn't am35xx already DT-only? The remaining omap2+ boards are both
> > omap3430 based:
>
> yeah, and this system is omap3 based, not am335x based ;-)
Sure, am35xx depends on omap3 and omap3 still supports platform
based booting because of the mentioned boards, but that does not
mean, that am35xx also needs to support legacy booting. From what
I can see, the last am35xx board has been removed in v4.0 [0]
together with the am35xx platform headers.
So while omap3 can still be booted the legacy way, am35xx cannot
without modifying the kernel. Other omap3 based SoCs will initialize
musb's omap2430 gluecode, so they are not affected.
[0] https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/tag/?id=omap-for-v3.20/drop-legacy-3517-v2
-- Sebastian
Attachment:
signature.asc
Description: PGP signature
