From: krzk@kernel.org (Krzysztof Kozlowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 2/2] phy: exynos5-usbdrd: remove disable and enable of phy clk
Date: Mon, 9 Oct 2017 18:34:16 +0200 [thread overview]
Message-ID: <20171009163416.u6rfwtqmhqn6vxcw@kozik-lap> (raw)
In-Reply-To: <CANAwSgSMFBS8n48=_OnNNs_=Di9Oqq2tNeiwZM9u1qaLevLP4w@mail.gmail.com>
On Mon, Oct 09, 2017 at 02:37:14AM +0530, Anand Moon wrote:
> Hi Krzysztof,
>
> On 8 October 2017 at 21:20, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Sun, Oct 08, 2017 at 06:11:12PM +0530, Anand Moon wrote:
> >> Hi Krzysztof,
> >>
> >> On 6 October 2017 at 12:12, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> > On Fri, Oct 6, 2017 at 6:36 AM, Anand Moon <linux.amoon@gmail.com> wrote:
> >> >> remove the disable and enable of phy clk.
> >> >> phy clk is needed to tune the phy controller.
> >> >
> >> > Drivers should in general enable and disable the clocks they use. Just
> >> > like in patch #1 please describe why you are doing this, what kind of
> >> > problem are you trying to solve and what exactly are you trying to do
> >> > here.
> >> >
> >> > BR,
> >> > Krzysztof
> >> >
> >>
> >> [snip]
> >>
> >> Usually we would disable the clk on error patch and return with failed.
> >> but in the current code we disable the clk in init routine and
> >> enable the clk in disable routine which seem incorrect.
> >
> > No. For example for exynos5_usbdrd_phy_exit() the driver enables the
> > clock only for the access to PHY block (PHY registers).
> >
>
> But I dont get it why we disable code phy clk, which could be used in
> future phy tune or link control as it part of CLK_FSYS.
Clock is being disabled when it is not used. AFAIU, current code follows
this logic.
>
> >>
> >> [0] https://github.com/torvalds/linux/blob/master/drivers/phy/samsung/phy-exynos5-usbdrd.c#L362-L412
> >> [1] https://github.com/torvalds/linux/blob/master/drivers/phy/samsung/phy-exynos5-usbdrd.c#L424-L446
> >>
> >> On 3.10.x kernel clk_summary all the clk are enables.
> >>
> >> mout_usbdrd300 3 3 24000000
> >> dout_usbdrd300 2 2 24000000
> >> sclk_usbdrd300 1 1 24000000
> >> dout_usbphy300 2 2 24000000
> >> sclk_usbphy300 1 1 24000000
> >> mout_usbdrd301 3 3 24000000
> >> dout_usbdrd301 2 2 24000000
> >> sclk_usbdrd301 1 1 24000000
> >> dout_usbphy301 2 2 24000000
> >> sclk_usbphy301 1 1 24000000
> >>
> >> Some more changes in clk driver might be required to stabilize the usb module.
> >
> > Please describe the issues with stability first.
> >
> > Best regards,
> > Krzysztof
> >
> On stability:
>
> USB 3.0 read / write performance is not up to mark with moderate data
> read / write speed,
> If you give long compilation of kernel or any source code it would
> likely be slow
> It work pretty good with USB 3.0 SSD but generally failed with 2.5' inc HDD.
>
> If needed I will share you some performance test result with and
> without these patches.
Yes, such results are essential for this (and any) commit.
Best regards,
Krzysztof
>
> I have some more changes related to usbdrd phy change queued along this on.
>
> Best Regards
> -Anand
next prev parent reply other threads:[~2017-10-09 16:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-06 4:36 [RFC 1/2] ARM: dts: exynos: update the usbdrd phy and ref clk Anand Moon
2017-10-06 4:36 ` [RFC 2/2] phy: exynos5-usbdrd: remove disable and enable of phy clk Anand Moon
2017-10-06 6:42 ` Krzysztof Kozlowski
2017-10-08 12:41 ` Anand Moon
2017-10-08 15:50 ` Krzysztof Kozlowski
2017-10-08 21:07 ` Anand Moon
2017-10-09 15:16 ` Anand Moon
2017-10-09 16:59 ` Krzysztof Kozlowski
2017-10-09 16:34 ` Krzysztof Kozlowski [this message]
2017-10-06 6:38 ` [RFC 1/2] ARM: dts: exynos: update the usbdrd phy and ref clk Krzysztof Kozlowski
2017-10-08 12:36 ` Anand Moon
2017-10-08 15:47 ` Krzysztof Kozlowski
2017-10-08 21:06 ` Anand Moon
2017-10-09 17:05 ` Krzysztof Kozlowski
2017-10-10 6:27 ` Vivek Gautam
2017-10-11 5:46 ` Anand Moon
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=20171009163416.u6rfwtqmhqn6vxcw@kozik-lap \
--to=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.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