[U-Boot] [PATCH 00/60] ARM: tegra: cleanup part 1

Simon Glass sjg at chromium.org
Sun May 8 00:32:58 CEST 2016


Hi Stephen,

On 19 April 2016 at 14:58, Stephen Warren <swarren at wwwdotorg.org> wrote:
> From: Stephen Warren <swarren at nvidia.com>
>
> This series cleans up Tegra code:
> - Removes unused definitions.
> - Unifies duplicate definitions and code.
> - Moves Tegra headers from arch/arm/include to arch/arm/mach-tegra so
> all Tegra files are located together. Headers for Tegra-specific APIs
> (intended e.g. for public/driver use) are placed into <mach/>, whereas
> headers intended only for use by code in arch/arm/mach-tegra are placed
> into <soc/>.
> - Hides as much internal Tegra information as possible, to reduce the
> size of the "API" provided to Tegra boards. This will help refactoring
> that "API" later; the next chip is quite different and various parts of
> this API (e.g. clock, reset, GPIO, ...) will need alternative
> implementations. This will hopefully be a bit easier after this series.
> - Cleans up the set of functions the core Tegra "board" support calls and
> which are implemented by Tegra board files.
> - Replaces funcmux with pinmux functions so that pinmux is set up in as
> much the same way across all Tegra SoCs as possible.
> - Various other cleanup.
> - Removes almost 3000 lines!
>
> Future changes/series will likely/hopefully:
> - Refactor C files in arch/arm/mach-tegra to allow Makefiles to easily
> decide which parts to pull in for each chip, and avoid a mess of ifdefs
> in the C files when adding support for the next chip.
> - Convert Tegra to standard clock/reset APIs, since the next chipd will
> use a different implementation, yet we need them to share the same API
> so that drivers don't need conditional code.
> - Add some new drivers for the next chip.

I've reviewed the reset of the patches. It is a huge improvement in
the tegra code. It's more consistent and fixes up some of the weird
code placement and muddy concepts.

If there are any patches I am missed, let me know.

My main comment is that the pinctrl stuff should go in a driver. There
is not way we should be inventing a new pinmux API for tegra now that
we have driver model pinctrl :-)

I am happy to help with this if you like.

Regards,
Simon


More information about the U-Boot mailing list