From: Lokesh Vutla <lokeshvutla@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/4] ARM: AM33xx: Cleanup dplls data
Date: Tue, 25 Jun 2013 13:47:43 +0530 [thread overview]
Message-ID: <51C95227.5060307@ti.com> (raw)
In-Reply-To: <51C9412B.2000203@denx.de>
Hi Heiko,
On Tuesday 25 June 2013 12:35 PM, Heiko Schocher wrote:
> Hello Lokesh,
>
> Am 25.06.2013 07:39, schrieb Lokesh Vutla:
>> Hi Heiko,
>> On Tuesday 25 June 2013 10:24 AM, Heiko Schocher wrote:
>>> Hello Lokesh,
>>>
>>> Am 25.06.2013 05:48, schrieb Lokesh Vutla:
>>>> Hi Heiko,
>>>> On Tuesday 25 June 2013 12:42 AM, Heiko Schocher wrote:
>>>>> Hello Lokesh,
>>>>>
>>>>> Am 24.06.2013 15:15, schrieb Lokesh Vutla:
>>>>>> Locking sequence for all the dplls is same.
>>>>>> In the current code same sequence is done repeatedly
>>>>>> for each dpll. Instead have a generic function
>>>>>> for locking dplls and pass dpll data to that function.
>>>>>>
>>>>>> This is derived from OMAP4 boards.
>>>>>>
>>>>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>>>>> ---
>>>>>> arch/arm/cpu/armv7/am33xx/Makefile | 1 +
>>>>>> arch/arm/cpu/armv7/am33xx/clock.c | 116 ++++++++++++++
>>>>>> arch/arm/cpu/armv7/am33xx/clock_am33xx.c | 222 +++++---------------------
>>>>>> arch/arm/cpu/armv7/am33xx/emif4.c | 4 +
>>>>>> arch/arm/include/asm/arch-am33xx/clock.h | 68 ++++++++
>>>>>> arch/arm/include/asm/arch-am33xx/ddr_defs.h | 2 +
>>>>>> arch/arm/include/asm/arch-am33xx/sys_proto.h | 1 +
>>>>>> 7 files changed, 232 insertions(+), 182 deletions(-)
>>>>>> create mode 100644 arch/arm/cpu/armv7/am33xx/clock.c
>>>>>>
>>>>> [...]
>>>>>> diff --git a/arch/arm/cpu/armv7/am33xx/clock.c b/arch/arm/cpu/armv7/am33xx/clock.c
>>>>>> new file mode 100644
>>>>>> index 0000000..a7f1d83
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm/cpu/armv7/am33xx/clock.c
>>>>>> @@ -0,0 +1,116 @@
>>>>> [...]
>>>>>> +static void do_setup_dpll(const struct dpll_regs *dpll_regs,
>>>>>> + const struct dpll_params *params)
>>>>>> +{
>>>>>
>>>>> Could we have this function not only static? I posted a patch:
>>>>>
>>>>> [U-Boot] arm, am335x: make mpu pll config configurable
>>>>> http://patchwork.ozlabs.org/patch/248509/
>>>>>
>>>>> which uses mpu_pll_config() for switching mpu pll clock
>>>>> from board code ... you delete this function later in this patch,
>>>>> so I think, I can switch to do_setup_pll() ... if this is not
>>>>> static code ...
>>>> Yes I saw that patch. No need to make this non-static.
>>>> Please have your own struct "const struct dpll_params dpll_mpu"
>>>> and update your values accordingly.
>>>
>>> Hmm.. maybe I miss something here. You call setup_dplls()
>>> in arch/arm/cpu/armv7/am33xx/clock.c using &dpll_mpu defined
>>> in arch/arm/cpu/armv7/am33xx/clock_am33xx.c ... so how to
>>> make here a board specific struct?
>>>
>>> The MPUCLK is configurable through the define CONFIG_SYS_MPUCLK
>>> which is good, but I have on this board a PMIC, which in board SPL
>>> code change MPU and core voltage ... and after that I change
>>> the MPU clock again ...
>> Ohk.
>> Can't we scale the voltages before calling setup_dplls()
>> (Why do you want to configure the MPU clocks twice?
>
> I speak with the customer ...
>
>> I don't know much about your board, so I am just asking..:) )
>> What I meant is something like below:
>> void __weak scale_vcores(void)
>> {}
>>
>> void prcm_init()
>> {
>> enable_basic_clocks();
>> scale_vcores();
>> setup_dplls();
>> }
>>
>> have your own scale_vcores in your board file.
>> and for dpll_mpu have something like this:
>> #ifdef CONFIG_<BOARD>
>> const struct dpll_params dpll_mpu = {
>> M, N, 1, -1, -1, -1, -1};
>> #else
>> const struct dpll_params dpll_mpu = {
>> CONFIG_SYS_MPUCLK, OSC-1, 1, -1, -1, -1, -1};
>> #endif
>
> No, that is not good. We should prevent such board specific
> defines in common code. I think this define is not necessary,
> as, if we have a scale_vcore() function, I can set
> CONFIG_SYS_MPUCLK to the end value ! I try this out! Thanks!
My idea here is to populate data according to the board.
Its good if you use the same value.
>
>> I hope this should be possible on your board.
>> I am telling this because it will be easy for me during my next cleanup
>> during
>> which I planned to combine omap-common and am33xx code..:)
>
> Ok, i try it ...
>
>> This is the exactly what is done for omap( program voltages and then
>> setup dplls)
>> You can refer to arch/arm/cpu/armv7/omap-common/clocks-common.c
>> prcm_init() function.
>>
>> Please correct me if I am wrong..
>
> Yes, that looks good. Hmm... have we access to an pmic connected
> over i2c at this time?
you can do an i2c_init() here.
Thanks and regards,
Lokesh
>
> bye,
> Heiko
>
next prev parent reply other threads:[~2013-06-25 8:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-24 13:15 [U-Boot] [PATCH 0/4] ARM: AM33xx: Cleanup clocks and hwinit Lokesh Vutla
2013-06-24 13:15 ` [U-Boot] [PATCH 1/4] ARM: AM33xx: Cleanup dplls data Lokesh Vutla
2013-06-24 19:12 ` Heiko Schocher
2013-06-25 3:48 ` Lokesh Vutla
2013-06-25 4:54 ` Heiko Schocher
2013-06-25 5:39 ` Lokesh Vutla
2013-06-25 7:05 ` Heiko Schocher
2013-06-25 8:17 ` Lokesh Vutla [this message]
2013-06-25 14:09 ` Heiko Schocher
2013-06-25 14:53 ` Tom Rini
2013-06-26 4:39 ` Heiko Schocher
2013-06-26 4:40 ` Heiko Schocher
2013-06-24 13:15 ` [U-Boot] [PATCH 2/4] ARM: AM33xx: Cleanup clocks layer Lokesh Vutla
2013-06-26 4:42 ` Heiko Schocher
2013-06-24 13:15 ` [U-Boot] [PATCH 3/4] ARM: AM33xx: Move s_init to a common place Lokesh Vutla
2013-06-24 19:17 ` Heiko Schocher
2013-06-24 19:31 ` Tom Rini
2013-06-24 19:44 ` Heiko Schocher
2013-06-25 5:09 ` Sumit Gemini
2013-06-25 5:19 ` Heiko Schocher
2013-06-24 13:15 ` [U-Boot] [PATCH 4/4] musb: Disable extra prints Lokesh Vutla
2013-06-24 19:33 ` Heiko Schocher
2013-06-26 4:24 ` [U-Boot] [PATCH 0/4] ARM: AM33xx: Cleanup clocks and hwinit Lokesh Vutla
2013-06-26 12:09 ` Tom Rini
2013-06-26 12:49 ` Lokesh Vutla
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=51C95227.5060307@ti.com \
--to=lokeshvutla@ti.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.