From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 2/6] arm: shmobile: lager: Add USBHS support
Date: Thu, 03 Oct 2013 09:47:04 +0000 [thread overview]
Message-ID: <6394987.Uanypf6pjs@avalon> (raw)
In-Reply-To: <1380652251-8143-3-git-send-email-valentine.barshak@cogentembedded.com>
Hi Morimoto-san,
On Wednesday 02 October 2013 21:53:26 Kuninori Morimoto wrote:
> Hi Valentine
>
> > >> +static int usbhs_hardware_init(struct platform_device *pdev)
> > >> +{
> > >> + struct usbhs_private *priv = usbhs_get_priv(pdev);
> > >> + struct clk *clk;
> > >> +
> > >> + clk = clk_get(NULL, "hsusb");
> > >> + if (IS_ERR(clk))
> > >> + return -ENODEV;
> > >
> > > It is automatically enable/disabled by driver
> > > if MSTP704 clock name was "renesas_usbhs".
> >
> > The reason I did not bind usbhs clock to renesas_usbhs device is because
> > the same clock is also used by the lager_add_usb_devices() function in
> > the next patches. We need that since the global USB settings that affect
> > USBHS/USBSS and PCI USB host channel sharing are done in the USBHS
> > UGCTRL2 register. So we need this clock even if the renesas_usbhs driver
> > is disabled. IIUC, biding it to "renesas_usbhs" device would make it
> > impossible to use the clock if renesas_usbhs device is not registered.
>
> I understand your situation, but you can use renesas_usbhs binded clock
> anyway ? As Laurent mentioned, pci-rcar-gen2 care about it in driver ?
> Maybe callback function is nice solution in this situation ?
> Like this
>
> --- clock --------------
> CLKDEV_DEV_ID("renesas_usbhs", &mstp_clks[MSTP704]),
> CLKDEV_ICK_ID("hsusb", "pci-rcar-gen2", &mstp_clks[MSTP704]),
>
> --- platform -----------
> int rcar_pci_hw_init(struct platform_device *pdev)
> {
> clk = clk_get("hsusb", pdev->dev);
> if (IS_ERR(clk))
> return -EIO;
>
> clk_enable(clk);
> clk_put(clk);
>
> ...
>
> return 0;
> }
>
> --- driver ---
> static int __init rcar_pci_probe(struct platform_device *pdev)
> {
> ...
> if (info->hw_init)
> ret = info->hw_init(pdev);
> ...
> }
The problem with such a mechanism is that it only works with platform data, as
we don't have callback functions in DT.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2013-10-03 9:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-01 18:30 [PATCH 2/6] arm: shmobile: lager: Add USBHS support Valentine Barshak
2013-10-02 0:09 ` Kuninori Morimoto
2013-10-02 0:18 ` Magnus Damm
2013-10-02 12:06 ` Valentine
2013-10-02 12:13 ` Valentine
2013-10-02 19:45 ` Laurent Pinchart
2013-10-02 20:01 ` Valentine
2013-10-02 22:52 ` Valentine
2013-10-03 1:11 ` Simon Horman
2013-10-03 4:53 ` Kuninori Morimoto
2013-10-03 5:03 ` Kuninori Morimoto
2013-10-03 9:01 ` Magnus Damm
2013-10-03 9:42 ` Valentine
2013-10-03 9:47 ` Laurent Pinchart [this message]
2013-10-03 13:36 ` Valentine
2013-10-04 0:21 ` Kuninori Morimoto
2013-10-04 0:30 ` Valentine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6394987.Uanypf6pjs@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=linux-sh@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox