Hi Otavio,
On 16/06/2014 02:46, Otavio Salvador wrote:
There are board were we cannot do voltage negotiation but want to set the VSELECT bit forcely to ensure it to work at 1.8V.
This commit adds CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT flag for this use.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
drivers/mmc/fsl_esdhc.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index c75b38f..b3870e2 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -517,6 +517,10 @@ static int esdhc_init(struct mmc *mmc) /* Set timout to the maximum value */ esdhc_clrsetbits32(®s->sysctl, SYSCTL_TIMEOUT_MASK, 14 << 16);
+#ifdef CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT
- esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
+#endif
Instead of adding a new compiler switch that should be documented (I have already read Marek's comments), what do you think to extend struct fsl_esdhc_cfg, putting for exmaple an "options" field with this kind of specialization ?
I see also a CONFIG_SYS_FSL_ESDHC_USE_PIO that slipped into mainline (you are both right : Otavio is not the first to add such kind of configuration switches that are still undocumented, but according to rules should be documented as Marek said).
I would suggest to get rid as much as possible with these CONFIG_ switches. If we have some specialization for this driver before calling esdhc_init (better: fsl_esdhc_initialize), they are self explaining and we do not need further documentation. What do you think ?
Best regards, Stefano