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@xxxxxxxxxx> 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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
