Re: [PATCH v2 00/14] ARM: shmobile: Add CPG Clock Domains

[Geert Uytterhoeven]

Hi Mike,

On Mon, Jun 22, 2015 at 10:46 PM, Michael Turquette
<mturquette@xxxxxxxxxx> wrote:
>> The MSTP block provides two functions:
>>   1. Module Standby: "Clock supply to specified modules is stopped by
>>      setting the module stop control register bits."
>>      However, the clock supply to a module is not stopped until all CPUs
>>      in the SoC agree.  Indeed, there are separate MSTP registers for
>>      application (Cortex-A) and real-time (SH and/or Cortex-R) cores.
>>   2. Reset control. to perform a software reset of a specific module.
>>
>> Given the second function, perhaps the MSTP bits shouldn't have been
>> moduled as clocks, but it made sense at the time of introduction, and
>> IMHO it still does.
>
> Does the clk.enable_count refcount for an MSTP "clock" mirror your
> statement, "the clock supply to a module is not stopped until all CPUs
> in the SoC agree"? Put another way, is it possble in a shmobile system
> for an MSTP "clock" to have an enable_count of zero, but still by
> physically enabled in hardware?

Yes. The enable_count only matches the bit in the application core MSTP
control register. The real-time core MSTP control register may still have the
same module clock enabled (i.e. module not put in standby).
On some SoCs (e.g. R-Mobile APE6) there can be 3 sets of control registers
(for application, real-time, and baseband core).

Most (not all) module clocks have a status register to check if the module
clock is actually enabled or not. This shows that the module clock is stopped
iff all cores agree to stop it.

However, I found a few module clocks that never can be stopped, according to
the status register. Perhaps there's another set of control registers for an
undocumented core...

In addition, there are many undocumented bits in the MSTP control registers,
which may represent existing but undocumented clocks. Disabling such bits
may lock up the system.

As Linux doesn't touch the control registers for other CPU cores (they're
not described in DT), a module clock may be enabled (read: not stopped) in
a control registers meant for another CPU core, depending on reset state or
on the boot loader. Or by another OS running on another CPU core.
I've been running for quite some time with extra code that disables all module
clocks (for all cores) at early boot time, which let me find lots of drivers
that relied on implicit module clocks. Most got fixed, the only major
offender left is the module clock for the GIC ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/