mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sekhar Nori <nsekhar@ti.com>
To: Adam Ford <aford173@gmail.com>, Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Kevin Hilman <khilman@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	David Lechner <david@lechnology.com>,
	devicetree <devicetree@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	arm-soc <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 1/4] ARM: davinci: fix cpufreq registration on da850-evm
Date: Mon, 8 Apr 2019 14:18:14 +0530	[thread overview]
Message-ID: <3a31a498-232c-5f8f-5f4c-9dfaee0ad15a@ti.com> (raw)
In-Reply-To: <CAHCN7x+kAPYgFJ9iZQTPm2Vypni4CgmWmBw96fgbQr0ch456bw@mail.gmail.com>

On 04/04/19 4:44 PM, Adam Ford wrote:
> On Thu, Apr 4, 2019 at 5:01 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>
>> śr., 3 kwi 2019 o 17:49 Adam Ford <aford173@gmail.com> napisał(a):
>>>
>>> On Wed, Apr 3, 2019 at 7:50 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>
>>>> śr., 27 mar 2019 o 12:14 Sekhar Nori <nsekhar@ti.com> napisał(a):
>>>>>
>>>>> Hi Bart,
>>>>>
>>>>> On 26/03/19 11:21 PM, Bartosz Golaszewski wrote:
>>>>>> wt., 26 mar 2019 o 15:00 Adam Ford <aford173@gmail.com> napisał(a):
>>>>>>>
>>>>>>> On Fri, Mar 22, 2019 at 8:31 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>>>>>
>>>>>>>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>>>>>>
>>>>>>>> The system_rev variable is never set on davinci and is always 0, so
>>>>>>>> we're using the default max operating point of 300MHz. The cvdd supply
>>>>>>>> comes from the tps6507 pmic and the voltage can go all the way to 1.3V
>>>>>>>> so the maximum supported rate should be 456MHz.
>>>>>>>
>>>>>>> My understanding is that only certain revisions of the silicon can go
>>>>>>> to 456MHz.   The L138's Datasheet lists both a 456 and 375 version.  I
>>>>>>> cannot find a way to read a register to determine which version of the
>>>>>>> silicon is available. Maybe Sekhar can confirm.
>>>>>>>
>>>>>>
>>>>>> Commit 28bd2c341120 ("davinci: am18x/da850/omap-l138 evm: add support
>>>>>> for higher speed grades") mentions the following:
>>>>>>
>>>>>> ---
>>>>>> U-Boot on the EVM sets up ATAG_REVISION to inform the OS
>>>>>> regarding the speed grade supported by the silicon. We use
>>>>>> this information to pass on the speed grade information to
>>>>>> the SoC code.
>>>>>> ---
>>>>>>
>>>>>> Should the system_rev somehow reflect that revision? Any way I can check it?
>>>>>
>>>>> Can you check if the procedure in doc/README.davinci in U-Boot sources
>>>>> still works?
>>>>>
>>>>> Environment Variables
>>>>> =====================
>>>>>
>>>>> The DA850 EVM allows the user to specify the maximum cpu clock allowed by the
>>>>> silicon, in Hz, via an environment variable "maxcpuclk".
>>>>>
>>>>> The maximum clock rate allowed depends on the silicon populated on the EVM.
>>>>> Please make sure you understand the restrictions placed on this clock in the
>>>>> device specific datasheet before setting up this variable. This information is
>>>>> passed to the Linux kernel using the ATAG_REVISION atag.
>>>>>
>>>>> If "maxcpuclk" is not defined, the configuration CONFIG_DA850_EVM_MAX_CPU_CLK
>>>>> is used to obtain this information.
>>>>>
>>>>> Thanks,
>>>>> Sekhar
>>>>
>>>> Hi Sekhar,
>>>>
>>>> I built the current upstream u-boot and the get_board_rev() function
>>>> for da850-evm doesn't seem to be called at all. For instance the
>>>> lego-ev3 platform does this:
>>>>
>>>> ./lego/ev3/legoev3.c:108: board_rev = get_board_rev();
>>>>
>>>> but in davinci this function seems to be unused and I don't see it
>>>> called from any other core u-boot component. I don't see any commit
>>>> that would mention this function but there are a lot of commits
>>>> removing get_board_rev() for other boards in git log. Is it possible
>>>> it stopped being used at some point?
>>>
>>> Look for setup_revision_tag in arch/arm/lib/bootm.c
>>>
>>> The function appears to be called from there.
>>>
>>> There is a __weak reference in the header file which I think allows
>>> people to remove them without breaking bootm.
>>>
>>> adam
>>>>
>>>> Bart
>>
>> Thanks, now verified that this still works in board file mode for
>> da850-evm. Now the questions is - what about DT mode? Should we only
>> enable the lowest possible mode (300MHz) and leave it to the user to
>> enable any higher frequencies?
> 
> From everything that I can find in Logic PD's database, the standard
> da850-evm kits and SOM's are 375MHz, so I think it's safe to run up to
> that speed.  I would disable the speed options for 408 and 456, but
> leave them shown for anyone who may have purchased a custom version
> with the 456MHz variant which I can also see there are some.  At least
> for the L138 and AM1808 SOM's, those customers who who they are, so
> making it obvious how to enable it would be a good thing.
> 
> Just my two cents.

Sounds good to me.

Thanks,
Sekhar

  reply	other threads:[~2019-04-08  8:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22 13:31 [PATCH v2 0/4] ARM: da850: enable cpufreq in DT mode Bartosz Golaszewski
2019-03-22 13:31 ` [PATCH v2 1/4] ARM: davinci: fix cpufreq registration on da850-evm Bartosz Golaszewski
2019-03-26 14:00   ` Adam Ford
2019-03-26 17:51     ` Bartosz Golaszewski
2019-03-27 11:14       ` Sekhar Nori
2019-04-03 12:50         ` Bartosz Golaszewski
2019-04-03 15:49           ` Adam Ford
2019-04-04 10:01             ` Bartosz Golaszewski
2019-04-04 11:14               ` Adam Ford
2019-04-08  8:48                 ` Sekhar Nori [this message]
2019-03-22 13:31 ` [PATCH v2 2/4] ARM: dts: da850: add cpu node and operating points to DT Bartosz Golaszewski
2019-03-22 13:31 ` [PATCH v2 3/4] ARM: dts: da850-evm: enable cpufreq Bartosz Golaszewski
2019-03-26 14:15   ` Adam Ford
2019-03-22 13:31 ` [PATCH v2 4/4] ARM: davinci_all_defconfig: Enable CPUFREQ_DT Bartosz Golaszewski

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=3a31a498-232c-5f8f-5f4c-9dfaee0ad15a@ti.com \
    --to=nsekhar@ti.com \
    --cc=aford173@gmail.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=brgl@bgdev.pl \
    --cc=david@lechnology.com \
    --cc=devicetree@vger.kernel.org \
    --cc=khilman@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@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

all inboxes | Powered by JetHome®