rpi2: cpufreq(4) support lost ?

[Mark Millard]

[sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c does not
list "brcm,bcm2836": That is what I would have found
if I had looked at the details before babbling
incoherently.]

On 2017-Nov-13, at 1:54 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:

> On Sun, 12 Nov 2017 15:23:39 -0800
> Mark Millard <markmi at dsl-only.net> wrote:
> 
>> [This is a Linux *.dt* source issue, not specific to
>> amrmv6 vs. armv7: FreeBSD has switched to Linux *.dt*
>> source files, 4.13 most recently if I remember right.]
> 
> This we do not use the DTS from Linux for RPI1/2 I doubt that.

My apologies to all for the mistake for the rpi* context.

>> On 2017-Nov-12, at 2:30 PM, Claude Buisson <clbuisson at orange.fr> wrote:
>> 
>>> On 11/12/2017 20:03, Herbert J. Skuhra wrote:
>>> . . .
>>> 
>>> So, something musst be wrong with the dtb file. I'm using now a file from 
>>> r323309, where cpufreq is available again.
>> . . .
> 
> The way to get functionality back is to find the real problem.

Looking around, if I gather right, the only *.dt*
source change after -r323309 was in -r324184
in rpi2.dts :

compatible = "brcm,bcm2709";

was replaced by:

compatible = "brcm,bcm2836";

Folks are reporting that the new code works with
the old .dtb from before this change. This suggests
that may be the differences between the lines:

FDT_PLATFORM_DEF2(bcm2836, bcm2836_legacy, "bcm2836 (legacy)", 0, "brcm,bcm2709", 100);
FDT_PLATFORM_DEF2(bcm2836, bcm2836, "bcm2836", 0, "brcm,bcm2836", 100);

in sys/arm/broadcom/bcm2835/bcm2835_machdep.c might
be involved in some way. In fact:

/usr/src/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c

has:

static struct ofw_compat_data compat_data[] = {
        { "broadcom,bcm2835-vc",        1 },
        { "broadcom,bcm2708-vc",        1 },
        { "brcm,bcm2709",       1 },
        { NULL, 0 }
};

which does not list "brcm,bcm2836" as an alternative
but does list the "brcm,bcm2709" alternative.

My guess is this explains the cpufreq code working
for the older *.dtb files but not the newer ones.

>> . . .
>> 
>> ===
>> Mark Millard
>> markmi at dsl-only.net
> 
> All this is mostly wrong and doesn't have anything to do with the
> cpufreq problem on RPI2.

Again: sorry for the misapplied context.

> Please stay focus.

I clearly did not do appropriate investigation
and incorrectly presumed what context would apply.
My mistake for sure.


Side note relative to BPI-M3 . . .

FYI: The beginning of:

https://lists.freebsd.org/pipermail/freebsd-arm/2017-November/017039.html

lists what I've done locally to keep the BPI-M3 going as
of head -r325700 .

===
Mark Millard
markmi at dsl-only.net