From: Eric Anholt <eric@anholt.net>
To: Martin Sperl <kernel@martin.sperl.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@codeaurora.org>,
linux-kernel@vger.kernel.org,
linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/3] clk: bcm2835: critical clocks and parent selection
Date: Thu, 12 May 2016 11:23:15 -0700 [thread overview]
Message-ID: <87oa8b9lv0.fsf@eliezer.anholt.net> (raw)
In-Reply-To: <FD44F435-512C-49A5-B1F5-3C62AAF805AC@martin.sperl.org>
[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]
Martin Sperl <kernel@martin.sperl.org> writes:
>> On 10.05.2016, at 19:37, Eric Anholt <eric@anholt.net> wrote:
>>
>> Martin Sperl <kernel@martin.sperl.org> writes:
>>> and also hsm (probably hardware security module):
>>> root@raspcm:~# cat /sys/kernel/debug/clk/hsm/regdump
>>> ctl = 0x000002d6
>>> div = 0x000030e0
>>> root@raspcm:~# cat /sys/kernel/debug/clk/hsm/clk_rate
>>> 163551916
>>
>> That's the HDMI state machine (there's even a comment saying so),
>> controlled by the vc4 driver.
>>
>>> So turning plld off stops sdram and hsm - at least that is my
>>> interpretation.
>>>
>>> This means we need to define a clock property in firmware or
>>> we need a ram node making use of "mmio-sram" maybe?
>>>
>>> Marking sdram as "critical" or "hand_off" could also solve that
>>> for the moment (but it does not solve all the other hidden
>>> clock dependencies of the firmware)
>>
>> If there are other hidden dependencies, then we should figure them out.
>
> But strangely the sdram (plus the below) is the only one with
> plld that is enabled (unless it is one of the clocks we have not
> added to the kernel side yet)
>
> Maybe there is something that derives directly from plld_core
> or any of the other plld-dividers?
Nothing I can find.
> Core would indicate anything central to the videocore...
> Anyway both plld_core as well as plld_per ad well as both
> Pll_dsi that are running by default (but I doubt that the
> Dsi would be relevant)
>
> I guess you are in a better situation to figure out which
> hidden HW blocks uses plld...
>
>>
>>> --- a/drivers/clk/bcm/clk-bcm2835.c
>>> +++ b/drivers/clk/bcm/clk-bcm2835.c
>>> @@ -1655,7 +1655,8 @@ static const struct bcm2835_clk_desc
>>> clk_desc_array[] = {
>>> .ctl_reg = CM_SDCCTL,
>>> .div_reg = CM_SDCDIV,
>>> .int_bits = 6,
>>> - .frac_bits = 0),
>>> + .frac_bits = 0,
>>> + .flags = CLK_IS_CRITICAL),
>>> [BCM2835_CLOCK_V3D] = REGISTER_VPU_CLK(
>>> .name = "v3d",
>>> .ctl_reg = CM_V3DCTL,
>>
>> The Pi foundation folks believe that the cprman SDRAM clock isn't ever
>> used (there's a separate PLL in the SDRAM controller, and cprman is only
>> intended for unused low-power states), and at least in your sample of
>> the reg, it's not enabled. Instead of grepping for clk_enable_count, it
> See my comment above - it must be configured for some reason
> during the boot process by the firmware .
You have to write the register to configure the sdram controller's clock
parent.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
prev parent reply other threads:[~2016-05-12 18:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-10 1:01 Eric Anholt
2016-05-10 1:01 ` [PATCH 1/3 v2] clk: bcm2835: Mark the VPU clock as critical Eric Anholt
2016-05-10 1:01 ` [PATCH 2/3] clk: bcm2835: Mark GPIO clocks enabled at boot " Eric Anholt
2016-05-10 1:01 ` [PATCH 3/3] clk: bcm2835: Skip PLLC clocks when deciding on a new clock parent Eric Anholt
2016-05-11 22:58 ` Stephen Boyd
2016-05-12 1:45 ` Eric Anholt
2016-05-10 10:32 ` [PATCH 0/3] clk: bcm2835: critical clocks and parent selection Martin Sperl
2016-05-10 17:37 ` Eric Anholt
2016-05-10 19:58 ` Martin Sperl
2016-05-11 8:21 ` Martin Sperl
2016-05-11 16:09 ` Martin Sperl
2016-05-12 18:24 ` Eric Anholt
2016-05-12 18:23 ` Eric Anholt [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=87oa8b9lv0.fsf@eliezer.anholt.net \
--to=eric@anholt.net \
--cc=kernel@martin.sperl.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@codeaurora.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
Powered by JetHome