Hi Peng,

On 11 March 2016 at 21:21, Peng Fan <van.free...@gmail.com> wrote:
> Hi Simon,
>
> On Fri, Mar 11, 2016 at 05:33:05PM -0700, Simon Glass wrote:
>>Hi Peng,
>>
>>On 10 March 2016 at 01:57, Peng Fan <van.free...@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@02100000
>>>   mmc        [ + ]    |       |-- usdhc@02190000
>>>   mmc        [ + ]    |       |-- usdhc@02194000
>>> ....
>>> => mmc list
>>> FSL_SDHC: 0 (SD)
>>> FSL_SDHC: 1 (SD)
>>> "
>>>
>>> Signed-off-by: Peng Fan <van.free...@gmail.com>
>>> Cc: York Sun <york....@nxp.com>
>>> Cc: Yangbo Lu <yangbo...@nxp.com>
>>> Cc: Hector Palacios <hector.palac...@digi.com>
>>> Cc: Eric Nelson <e...@nelint.com>
>>> Cc: Stefano Babic <sba...@denx.de>
>>> Cc: Fabio Estevam <fabio.este...@nxp.com>
>>> Cc: Pantelis Antoniou <pa...@antoniou-consulting.com>
>>> Cc: Simon Glass <s...@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.
>
> No. I may need to write more in the commit log.
> The current way without driver model is
> board code fill fsl_esdhc_cfg strucure and then call fsl_esdhc_initialize
> which is in driver/mmc/fsl_esdhc.c.
>
> In order to minimize changes, in this patch, the probe function
> will fill fsl_esdhc_cfg structure and call fsl_esdhc_initialize.
>
> Then we can drop the function call to fsl_esdhc_initialize in different board 
> code.
>
> I originally want to rewrite fsl_esdhc_cfg structure, may give it a new name
> such as fsl_esdhc_platdata or priv, but this may incur lots changes in
> board code, because board code also refers to this structure. So I keep in.
>
>>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.
>
> Please kind take my upper words. I am still thinking add "non-removable",
> "cd-gpios" related code in this patch, so I'll write a new version patch.

When will this work be finished, so that the driver does not call board code?

At least, we should have a TODO here

Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to