U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lokesh Vutla <lokeshvutla@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state
Date: Tue, 28 Aug 2018 14:42:56 +0530	[thread overview]
Message-ID: <68d9b595-5d3a-25ad-c19f-15ca9bd0e91b@ti.com> (raw)
In-Reply-To: <20180827160614.grphsgjcaipuqtvo@jiji>



On Monday 27 August 2018 09:36 PM, Andreas Dannenberg wrote:
> Hi Kever,
> 
> On Mon, Aug 27, 2018 at 11:26:52AM +0800, Kever Yang wrote:
>> Hi Philipp, Andreas,
>>
>>
>> On 08/25/2018 12:00 AM, Dr. Philipp Tomsich wrote:
>>>> On 24 Aug 2018, at 17:54, Andreas Dannenberg <dannenberg@ti.com> wrote:
>>>>
>>>> Philipp,
>>>>
>>>> On Fri, Aug 24, 2018 at 04:42:15PM +0200, Dr. Philipp Tomsich wrote:
>>>>> +Kever
>>>>>
>>>>>> On 24 Aug 2018, at 16:12, Tom Rini <trini@konsulko.com> wrote:
>>>>>>
>>>>>> On Tue, Aug 21, 2018 at 08:01:49PM +0530, Lokesh Vutla wrote:
>>>>>>
>>>>>>> From: Andreas Dannenberg <dannenberg@ti.com>
>>>>>>>
>>>>>>> The earlier commit f4fcba5c5ba ("clk: implement clk_set_defaults()")
>>>>>>> which introduced the functionality for setting clock defaults such as
>>>>>>> rates and parents will skip the processing when executing in a re-reloc
>>>>>>> state. This for example can prevent the assigning of clock parents
>>>>>>> when running in SPL code. Go ahead and remove this limitation.
>>>>>>>
>>>>>>> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
>>>>>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>>>>>> ---
>>>>>>> drivers/clk/clk-uclass.c | 4 ----
>>>>>>> 1 file changed, 4 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
>>>>>>> index 2b15978e14..04b369aa5a 100644
>>>>>>> --- a/drivers/clk/clk-uclass.c
>>>>>>> +++ b/drivers/clk/clk-uclass.c
>>>>>>> @@ -243,10 +243,6 @@ int clk_set_defaults(struct udevice *dev)
>>>>>>> {
>>>>>>> 	int ret;
>>>>>>>
>>>>>>> -	/* If this is running pre-reloc state, don't take any action. */
>>>>>>> -	if (!(gd->flags & GD_FLG_RELOC))
>>>>>>> -		return 0;
>>>>>>> -
>>>>>>> 	debug("%s(%s)\n", __func__, dev_read_name(dev));
>>>>>>>
>>>>>>> 	ret = clk_set_default_parents(dev);
>>>>>> Philipp? David?  Comments?  Thanks!
>>>>> If I remember correctly, David had a concern regarding an increase in
>>>>> boottime if we ran this twice… adding Kever, as he was also involved
>>>>> in the discussion.
>>>>>
>>>>> I settled on skipping it for pre-reloc, but it’s an imperfect solution: the
>>>>> boottime increase comes from the fact that some devices have a large
>>>>> number of assigned-clocks, that the device-tree processing has a cost,
>>>>> and that we don’t have a way of synchronising between SPL and full
>>>>> U-Boot to avoid redoing the complete init-flow.
>>>> Good to know some of the background; when I did this patch initially it
>>>> was not really clear why this was removed and it obviously was an issue
>>>> for what I was doing that I had to overcome and re-adding this was the
>>>> simpliest thing to do at that time.
>>>>
>>>>> Maybe we should have a SPL-specific property for the assigned-clocks
>>>>> to be set pre-reloc?
>>>> Need to think about this some more. Generally we probably want to do as
>>>> little as possible before relocation. Unfortunately for the K3 family of
>>>> SoCs much is dependent on loading/installing the system firmware (SYSFW)
>>>> image including to get DDR operational which itself requires us to use a
>>>> lot of DT/DM stuff pre-reloc. So a little bit of a chicken and egg
>>>> problem…
>> 'pre-reloc' is used in SPL and U-Boot before relocate, I think this
>> should be
>> clear to be as simple as possible, but now it's going to much like U-Boot
>> proper. It have 2 problem: code size and boot time.
>> Every feature will increase the code size, in Rockchip platform, we run SPL
>> in sram which have size limit, and the common code of upstream feature
>> update often break the size limit. In this case I want to add TPL for
>> all Rockchip
>> SoCs and used for ddr init only so that SPL will not have the size limit.
>> For boot time, you need to understand that the module tag as 'pre-reloc'
>> will
>> be binded twice in U-Boot proper and also twice in SPL. I hope we only
>> do things
>> we need for SPL and U-Boot proper, but not too much overhead by framework.
>> The API like clk_set_defaults() is able to used in every module, better
>> to use in
>> U-Boot Proper while the SPL should have a clear white list modules.
>>
>> For example, we get everything from DTS for ddr node, but not using the
>> clk_set_defaults().
> 
> As Lokesh noted in the other email, we technically no longer need the
> patch to undo the setting of the clock defaults as we since hard-coded
> the UART clock frequency which in an earlier (pre-public) version of our
> tree was derived from the central "System Management Controller" and
> was dependent on this patch.
> 
> Yes doing the same thing twice or three times is not efficient also from
> a boot time POV. In addition, parsing the DT over and over takes a
> significant amount of time (I work on "simulated" devices in a silicon
> design environment so I know exactly how many minutes in that case are
> spent parsing the DT... :)
> 
> But I think it would be cleaner to not abort clk_set_defaults() if
> GD_FLG_RELOC is not set, but rather what Lokesh suggested to use
> CONFIG_OF_SPL_REMOVE_PROPS? Would that work for RK?

Right. I still feel that $patch as such is fine.
CONFIG_OF_SPL_REMOVE_PROPS should be used to not set the clock rates in SPL.

Any opinions on this? We can repost this patch alone.

Thanks and regards,
Lokesh

  reply	other threads:[~2018-08-28  9:12 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-21 14:31 [U-Boot] [PATCH 00/25] [2/3] Initial support Texas Instrument's AM654 Platform Lokesh Vutla
2018-08-21 14:31 ` [U-Boot] [PATCH 01/25] firmware: Add basic support for TI System Control Interface (TI SCI) protocol Lokesh Vutla
2018-08-24 14:11   ` Tom Rini
2018-08-24 15:00     ` Lokesh Vutla
2018-08-21 14:31 ` [U-Boot] [PATCH 02/25] firmware: ti_sci: Add support for board configuration Lokesh Vutla
2018-08-24 14:11   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 03/25] firmware: ti_sci: Add support for device control Lokesh Vutla
2018-08-24 14:11   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 04/25] firmware: ti_sci: Add support for clock control Lokesh Vutla
2018-08-24 14:11   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 05/25] firmware: ti_sci: Add support for reboot core service Lokesh Vutla
2018-08-24 14:11   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 06/25] firmware: ti_sci: Add support for processor control services Lokesh Vutla
2018-08-24 14:11   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 07/25] dm: firmware: Automatically bind child devices Lokesh Vutla
2018-08-24 14:11   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 08/25] dm: reset: Update uclass to allow querying reset status Lokesh Vutla
2018-08-24 14:11   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 09/25] reset: Extend reset control with an optional data field Lokesh Vutla
2018-08-24 14:11   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 10/25] reset: Introduce TI System Control Interface (TI SCI) reset driver Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-24 14:42     ` Dr. Philipp Tomsich
2018-08-24 15:54       ` Andreas Dannenberg
2018-08-24 16:00         ` Dr. Philipp Tomsich
2018-08-24 16:28           ` Andreas Dannenberg
2018-08-27  3:26           ` Kever Yang
2018-08-27 16:06             ` Andreas Dannenberg
2018-08-28  9:12               ` Lokesh Vutla [this message]
2018-08-27  6:02       ` Lokesh Vutla
2018-08-21 14:31 ` [U-Boot] [PATCH 12/25] clk: Extend clock control with an optional data field Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 13/25] clk: Introduce TI System Control Interface (TI SCI) clock driver Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 14/25] power domain: Add support for multiple powerdomains per device Lokesh Vutla
2018-08-22  9:21   ` Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 15/25] power domain: Introduce TI System Control Interface (TI SCI) power domain driver Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 16/25] sysreset: Add TI System Control Interface (TI SCI) sysreset driver Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 17/25] mailbox: Allow attaching private data for mbox_chan Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 18/25] mailbox: Introduce K3 Secure Proxy Driver Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 19/25] spl: Allow mailbox drivers to be used within SPL Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 20/25] remoteproc: Allow for individual remoteproc initialization Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:31 ` [U-Boot] [PATCH 21/25] remoteproc: Introduce K3 system controller Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-24 15:02     ` Lokesh Vutla
2018-08-21 14:32 ` [U-Boot] [PATCH 22/25] remoteproc: Introduce K3 remoteproc driver Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:32 ` [U-Boot] [PATCH 23/25] spl: Allow remoteproc drivers to be used within SPL Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:32 ` [U-Boot] [PATCH 24/25] mmc: k3_arasan: Add sdhci driver support for K3 family SoCs Lokesh Vutla
2018-08-24 14:12   ` Tom Rini
2018-08-21 14:32 ` [U-Boot] [PATCH 25/25] gpio: do not include <asm/arch/gpio.h> for ARCH_K3 Lokesh Vutla
2018-08-24 14:13   ` Tom Rini

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=68d9b595-5d3a-25ad-c19f-15ca9bd0e91b@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox