[U-Boot] [PATCH 2/2] fsl: esdhc: support driver model

[Simon Glass]

Hi Peng,

On 10 March 2016 at 01:57, Peng Fan <van.freenix at gmail.com> wrote:
> Support Driver Model for fsl esdhc driver.
>
> In order to minimize the change, reuse the fsl_esdhc_initialize function.
> This new way is to fill an fsl_esdhc_cfg struture and pass it
> to fsl_esdhc_initialize, just like the code in different board codes.
>
> Introduce a 'struct mmc *mmc' entry in fsl_esdhc_cfg structure,
> otherwise fsl_esdhc_initialize may need to be restructured which will
> cause lots changes for board code.
>
> Since clk driver is not implemented, use mxc_get_clock here to
> fill cfg->sdhc_clk. Anyway we can utilize the pinctrl imx driver
> now, except the SPL part, we can drop the pinmux settings from
> board file for mmc.
>
> There are so many "ifdef" in the file, maybe we can use driver data
> or quirks to cover these. But to minimize changes for this patch,
> these are not included. Later we can try to discard the nasty
> ifdef.
>
> Has been tested on i.MX6UL 9x9 EVK board:
> "
> =>dm tree
> ....
>  simple_bus  [ + ]    |   `-- aips-bus at 02100000
>   mmc        [ + ]    |       |-- usdhc at 02190000
>   mmc        [ + ]    |       |-- usdhc at 02194000
> ....
> => mmc list
> FSL_SDHC: 0 (SD)
> FSL_SDHC: 1 (SD)
> "
>
> Signed-off-by: Peng Fan <van.freenix at gmail.com>
> Cc: York Sun <york.sun at nxp.com>
> Cc: Yangbo Lu <yangbo.lu at nxp.com>
> Cc: Hector Palacios <hector.palacios at digi.com>
> Cc: Eric Nelson <eric at nelint.com>
> Cc: Stefano Babic <sbabic at denx.de>
> Cc: Fabio Estevam <fabio.estevam at nxp.com>
> Cc: Pantelis Antoniou <panto at antoniou-consulting.com>
> Cc: Simon Glass <sjg at chromium.org>
> ---
>  drivers/mmc/fsl_esdhc.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
>  include/fsl_esdhc.h     |  1 +
>  2 files changed, 82 insertions(+)

I'm nervous about this patch. It is calling board code from a driver,
which we should avoid.

Perhaps it would be better to start by refactoring things to fix the
problems you mention, and then come back to this patch? I'm worried
we'll end up with a driver model conversion that never gets properly
finished if we do things in the wrong order.

Regards,
Simon