[U-Boot] [PATCH v4 3/4] tegra2: Modify MMC driver to handle power and cd GPIOs

Simon Glass sjg at chromium.org
Thu Nov 17 05:38:55 CET 2011


Hi Thierry,

On Wed, Nov 16, 2011 at 1:05 PM, Stephen Warren <swarren at nvidia.com> wrote:
> Thierry Reding wrote at Wednesday, November 16, 2011 1:29 PM:
>> * Stephen Warren wrote:
>> > Pass the GPIO numbers for power and card detect to tegra2_mmc_init(), and
>> > modify that function to perform all required GPIO initialization. This
>> > removes the need for board files to perform these operations.
>> >
>> > Move board_mmc_getcd() into tegra2_mmc.c now that the driver knows which
>> > GPIOs to use.
>> >
>> > Update affected call-sites in seaboard.c and harmony.c. Note that this
>> > change should make all SD ports work on Harmony, since the required GPIO
>> > setup is now being performed.
> ...
>> > diff --git a/board/nvidia/common/board.h b/board/nvidia/common/board.h
> ...
>> >  void tegra2_start(void);
>> >  void gpio_config_uart(void);
>> > -void gpio_config_mmc(void);
>> > -int tegra2_mmc_init(int dev_index, int bus_width);
>> > +int tegra2_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio);
>> [...]
>>
>> Can we move tegra2_start() and tegra2_mmc_init() into a common Tegra2 header
>> instead of a board-specific one, please? Both functions are not implemented
>> below board/nvidia/common, so there is no need to make their prototype only
>> visible for board/nvidia. Otherwise other boards will have to duplicate this
>> prototype and need to keep it in sync.
>>
>> tegra2_start() can probably go into arch/arm/include/asm/arch-tegra2/tegra2.h

That header file is supported to just be for #defines. How about
ap20.h? Anyway, sorry to say that this has been refactored and
simplified already. Patches are upstream - it's just that they are not
yet applied. Please see my patchwork if you want to base on top of
those as well (yes I know this is a pain, sorry).

Regards,
Simon

>> and tegra2_mmc_init() could for example go into a new mmc.h in the same
>> directory.
>
> I'd certainly be fine with that.
>
> It's probably simplest if you include that change in your patchset though;
> my patchset doesn't change the location of these functions, so I'd have to
> introduce another patch for that.
>
> --
> nvpublic
>
>


More information about the U-Boot mailing list