MMC3 support

also sdhc.c in the OMAP3530\SDHC folder.

Also I thought the PBIAS stuff only applied to SDHC1? Looks like it is altered for SDHC2 also?

The clocking mode DEVCONF1_MMCSDIO2ADPCLKISEL needs a BSP_xxx define or registry setting to select eather clocking mode (not hard coded).

even more...

Could someone explane to me how the PBIASLITE is suspose to work?

I thought I understood it in the 6.15 BSP where the PBIAS bits were toggled off in the PreparePowerChange and set in the PostPowerChange after setting the registry flag to allow for pre and post power change function calls.  This was done in the BSP specific SDController.cpp file.

In the A8_01_01 implementation they do nothing in the  PreparePowerChange and PostPowerChange (3530) functions and it looks like the PBIAS function has been consolated in to a common function where they just clear the bits then immediately set them again a few microseconds later??? Does this really do anything? It looks screwy to me.

This PBIAS bit needs to be set at a specific time during the initialization of the MMC controller, and needs to be reset whenever we reinitialize the controller (i.e. after suspend/resume). The way it was implemented in the 6.15 BSP broke proper suspend/resume of the board on the unified BSP.

 In your case where you want to use MMC3, there is nothing special you should do about that because MMC3 only supports 1.8V.

Thank you for the reply.

What about MMC2? I see you are changing it there also. I thought it was only for MMC1 as this is the only controller that can operate at 3.0v natively an therefor needs special pad biasing?

MMC2, as I understand it is only 1.8v, like MMC3, but can be used at 3v if external voltage translator is used, which should have nothing to do with pad biasing. ??

The bit we have to change for MMC2 is not related to PBIAS (only valid for MMC1) but is rather some clock path selection (DEVCONF1_MMCSDIO2ADPCLKISEL). The code indeed changes the PBIAS_LITE register as well, which looks wrong indeed. This might conflict with MMC1 if we enable the MMC2 port in the BSP, which actually never happened on the EVM as there is no slot for MMC2. We need to investigate further on this to check if this has an impact when both ports are included in the image.

Thank you for the reply. I concur with your conclusions.

I understand the clocking options on MMC2. It would be nice if this was a BSP define or option instead of hard coded.

It is quite a pain copying over from the common directory just to modify and build a local library for something that should be a configuration option. Another example is the card detect and write protect functions. These should be optional and, if not specified in the registry, CD should default to TRUE and WP default to "not protected". Looks like there was a half attempt to do this on the WP pin but CD fails if not specified in both registery AND defined in bsp_def.h file. I understand this is probably because of the need to use these defines in the bootloader. ...in which case the driver version should not be using the define.  

You are right about the SDHC driver and the CD pin that should rely on the registry value and should not attempt to get the pin number from the BSP configuration. This is the kind of improvements that could be part of maintenance releases, thanks for noticing and giving feedback.

We are using latest WinCE 6.0 BSP from Adeneo for new device. We are planning use MMC3 channel for device connection. Code in COMMON_TI has part definition of OMAP MMC1/MMC2/MMC3. But total MMC3 support is absent yet.

We also join to David Vescovi original question.