Skip to content

RFC Adaptive Body-Bias for OMAP

Kevin Hilman linux-arm-kernel linux-omap 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest0 of 7 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 7 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [RFC][PATCH v4? 0/7] Adaptive Body-Bias for OMAP
Quoted 33 lines · Mike Turquette

Quoting Tony Lindgren (2012-10-16 09:32:25)

Quoted 32 lines · Mike Turquette
Quoted 20 lines

Quoting Nishanth Menon (2012-10-11 06:33:04)

Quoted 15 lines · Mike Turquette
Quoted 1 line

From: Mike Turquette <[email protected]>

[...]

Quoted 4 lines
 arch/arm/mach-omap2/Makefile                  |    8 +-
 arch/arm/mach-omap2/abb.c                     |  322 +++++++++++++++++++++++++
 arch/arm/mach-omap2/abb.h                     |   94 ++++++++

[...]

Quoted 6 lines
 arch/arm/plat-omap/include/plat/voltage.h     |    1 +
 18 files changed, 699 insertions(+), 37 deletions(-)
 create mode 100644 arch/arm/mach-omap2/abb.c
 create mode 100644 arch/arm/mach-omap2/abb.h
 create mode 100644 arch/arm/mach-omap2/abb36xx_data.c
 create mode 100644 arch/arm/mach-omap2/abb44xx_data.c
Quoted 3 lines

dumb question: with the request to move everything out of mach-omap2 directory, do we still want to add more files into mach-omap2?

Quoted 7 lines

Not a dumb question at all. I approached this problem by modeling it after existing voltage layer code (in particular the vp and vc drivers).

My hope is to get it merged as-is and then bundle the abb code up with the vp/vc migration to drivers/* when that happens some day. People using omap36xx and above need this code now, so it seems prudent to take this approach today.

This is needed, but makes moving the vc code to drivers a bit more complex.

Quoted 6 lines
Quoted 4 lines

So we also need a plan to move this all to drivers in the follow up patches. And we need a maintainer for the code. Who is going to be doing all that?

Is there already somebody committed to moving vp/vc code out to drivers?

Yes, VC/VP is part of the bigger PRM/CM move in progress.

For now, I'm ok with adding a little more VC/VP stuff since it's already well isolated in the prmXXXX.c files (though it might need a rebase on Paul's recent PRM/CM cleanup stuff.)

Quoted 2 lines

If so then I can take responsibility for moving the abb code and coordinate with that person.

Thanks,

Kevin