linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: paulius.zaleckas@gmail.com (Paulius Zaleckas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC/RFT] ARM: S5P: Fix USB and 48M clock enable procedure
Date: Fri, 15 Oct 2010 19:12:29 +0300	[thread overview]
Message-ID: <4CB87D6D.6020303@gmail.com> (raw)
In-Reply-To: <01de01cb6c68$5ede0bc0$1c9a2340$%kim@samsung.com>

On 10/15/2010 03:56 PM, Kukjin Kim wrote:
> Paulius Zaleckas wrote:
>>
>> On Thu, Oct 14, 2010 at 12:03 PM, Kukjin Kim<kgene.kim@samsung.com>
> wrote:
>>> Paulius Zaleckas wrote:
>>>>
>>>> Signed-off-by: Paulius Zaleckas<paulius.zaleckas@gmail.com>
>>>> ---
>>>>
>>>>   arch/arm/mach-s5p6440/clock.c              |   23 -------
>>>>   arch/arm/plat-s5p/clock.c                  |   86
>>>> ++++++++++++++++++++++++++++
>>>>   arch/arm/plat-s5p/include/plat/s5p-clock.h |    1
>>>>   3 files changed, 86 insertions(+), 24 deletions(-)
>>>>
>>> Hi Paulius,
>>>
>>> There are some comments about your patches which includes previous
> S3C64XX
>> patches.
>>>
>>> Basically your approach looks good trial and structure...but I'm not
> sure
>> whether your approach can be used commonly on Samsung's all SoCs or not.
>>> Need to do more test on boards and I already informed your patches to
> USB
>> engineers in my team, actually need to discuss about this.
>>>
>>> As a note, I know, 'xusbxti' clock is structure for external xtal which
> is
>> used for generating USB clock on board... it depends on board condition,
>> because can be used 12/24/48Mhz on board. The clk_48m means generated
> actual
>> USB clock, 48Mhz. So should be implemented enable function by using
> clk_48m...
>>
>> I don't agree that enable should be for clk_48m. The reason is that
>> IMO it is possible
>> to enable 48m clock, but suspend the clock for USB device part (I am
>> not sure about this yet...).
> 
> Umm...please see below.
> 
>            |\
> xxti------|O|
>            |M|-----..System..-- HCLK -->  usb_device...
> xusbxti---| |  |
>          | |/   |
>          |      |
>         (1)    (2)  -------------
>           ---------| USB OTG Phy | -->  clk_48M
>                     -------------
> 
> Firstly, 'xusbxti' can be used to system clock when selected by OM pin.
> As I said, the rate of xusbxti can be 12/24/48Mhz and there is it on
> board...usually is used 12Mhz or 24Mhz on SMDK board.
> It means depends on board and always enabled, so no need following 'rate'
> and 'enable' in your following patch.
> 
>   struct clk clk_xusbxti = {
>   	.name		= "xusbxti",
>   	.id		= -1,
> +	.rate		= 48000000,
> +	.enable		= clk_xusbxti_ctrl,
>   };
> 
>   struct clk s5p_clk_27m = {
> @@ -49,6 +134,7 @@ struct clk clk_48m = {
>   	.name		= "clk_48m",
>   	.id		= -1,
>   	.rate		= 48000000,
> +	.parent		=&clk_xusbxti,
>   };
> 
> According to above clock diagram, the parent of 'clk_48m' can be 'xxti' or
> 'xusbxti', it is decided by SoC and OM pin. For example, there is line (1)
> on S5P6440 so your patch is right, but there is line (2) on S5PC100 but
> line (1) so it's wrong..the parent of clk_48m can be xxti by OM Pin.
> 
> It means the parent of clk_48m depends on SoC, can't define it in the plat-
> s5p. And maybe as you know, in the S5PV210/S5PC110 case, need two clk_48m
> structures for Host and Device...
> 
> So its clock structure has SoC(ARCH) dependency and it's difficult to merge
> it into plat-s5p now.

I see... So maybe the best option is to define enable function not per
platform, but per machine.

Originally I was trying to solve bug where OHCI was not working on
S3C6410. I discovered that I need to select different clock source for
it or fix enable procedure for 48M. For S5P platform I have datasheet
only for S5PC100 and yes you are right about clock structure there.

> We need to re-think to implement it...and I and my team will sort out it.

Looking forward!

>>
>> If that is true than I think we will need one more clk for USB device:
>>
>>          /->clk_48m
>> xusbxti-|
>>          \->clk_usb_device
>>
> Actually, it's different on each SoCs...
> 
>>> Anyway let you know about the result of internal discussion soon, then
>> let's talk.
>>>
> 
> Thanks.
> 
> Best regards,
> Kgene.
> --
> Kukjin Kim<kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
> 
> 

      reply	other threads:[~2010-10-15 16:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-12 19:40 [PATCH RFC/RFT] ARM: S5P: Fix USB and 48M clock enable procedure Paulius Zaleckas
2010-10-14  9:03 ` Kukjin Kim
2010-10-14 14:19   ` Paulius Zaleckas
2010-10-15 12:56     ` Kukjin Kim
2010-10-15 16:12       ` Paulius Zaleckas [this message]

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=4CB87D6D.6020303@gmail.com \
    --to=paulius.zaleckas@gmail.com \
    --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;
as well as URLs for NNTP newsgroup(s).