Hi Stefano,
Even if the two controllers can have different clocks, this is not supported by the driver. In fact, in drivers/mmc/fsl_esdhc.c:
int sdhc_clk = gd->sdhc_clk;
The driver uses always the same clock, stored in the global structure. Before extending the code as in this patch, the driver should be modified to handle separate clocks. Currently the driver supports multiple controller, but they share the same clock or at least the same frequency.
Indeed, I had seen that. I didn't know what to decide as to the driver clocks, so I made this change to select the correct clock if a single clock or frequency is used.
If several clock frequencies are to be supported at once, what kind of API would you like? gd->sdhc_clk could be changed to an array, then the corresponding index could be passed to the init function through the fsl_esdhc_cfg struct.
But there is also the issue of fsl_esdhc_mmc_init() that would need a new config just to pass this index. I don't like that. Any suggestion?
There is another issue. The driver is used by both ARM (i.MX) and PowerPCs (PowerQuickIII, ...).
fsl_esdhc_mmc_init() is already the interface when one parameter is enough. If we need more than one controller, we should already call fsl_esdhc_initialize() with the cfg structure.
Then adding a field to the struct fsl_esdhc_cfg is maybe not too bad. Instead of an index, we can add directly the frequency - reading the driver this is all that the driver needs.
OK, then this patch does the job for the single eSDHC instance use case, which will still use gd->sdhc_clk. I will make another patch before or after this one for the multi-instance use case. I will do the same in the v2 of my mx5 clock series (for gd->sdhc_clk). I think I also have the same stuff for mx25.
Best regards, Benoît