DSP Bridge driver DVFS: two Kconfig oddities

[Paul Bolle]

Omar,

On Tue, 2013-05-14 at 18:50 -0500, Omar Ramirez Luna wrote:
> On Tue, May 14, 2013 at 3:28 PM, Paul Bolle <pebolle at tiscali.nl> wrote:
> Initially, it was meant to support custom kernels which had TI SRF PM
> (aka OMAP_PM_SRF), at some point it should have been migrated to
> OMAP_PM_NOOP but this didn't happen, according to the documentation
> OMAP_PM_NOOP is meant to be temporary, but I don't know its current
> status.

First some background, so I do not need to figure this out again. (This
is boring and you are advised to skip to "Summary:".)

TI DSP Bridges are an ARCH_OMAP3 specific feature.
arch/arm/mach-omap2/Kconfig tells us that ARCH_OMAP3 depends on
ARCH_OMAP2PLUS and that ARCH_OMAP2PLUS selects ARCH_OMAP. This brings us
to arch/arm/plat-omap/Kconfig, which reads in part:
    choice
            prompt "OMAP PM layer selection"
            depends on ARCH_OMAP
            default OMAP_PM_NOOP

    config OMAP_PM_NOOP
            bool "No-op/debug PM layer"

    endchoice

The net effect of that Kconfig choice entry is that OMAP_PM_NOOP is
always set for, well, anything OMAP related. But in arch/arm/Makefile we
find
    machine-$(CONFIG_ARCH_OMAP2PLUS)        += omap2

and in arch/arm/mach-omap2/Makefile we see
    obj-$(CONFIG_OMAP_PM_NOOP)              += omap-pm-noop.o

There's no corresponding line in arch/arm/mach-omap1/Makefile. It seems
that the choice entry could be simply removed and that omap-pm-noop.o
could be moved to the "Common support" list in
arch/arm/mach-omap2/Makefile.

(I still don't entirely grasp the differences between "arch",
"platform", and "machine" in the arch/arm universe. And when when I see
lines like
    plat-$(CONFIG_ARCH_OMAP)        += omap

in arch/arm/Makefile things start to get confusing. But that's an
unrelated issue.)

Summary: if one builds the TI DSP Bridge code OMAP_PM_NOOP will always
be set, like it is for all OMAP code. 

Anyhow, I assume that you want build coverage for the DVFS feature. In
that case the dependency to OMAP_PM_SRF needs to be dropped. Or will
that break the DVFS code somehow?

> Yes, this dependency is wrong... but node.c and proc.c could use a cleanup too.
> 
> Please let me know if you want to work on these or would be happy with
> a Reported-by.

I'm afraid I won't be able to effectively clean the CPU_FREQ oddity. I
don't know anything about the code here, I don't have the hardware at
hand, etc. It's just that I noticed that the Kconfig entry for
TIDSPBRIDGE_DVFS and the preprocessor checks in node.c and proc.c are
conflicting. But feel free to add a Reported-by.


Paul Bolle