mmc: sunxi: Handle the 'New Timing' mode
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH v3 1/1 mmc: sunxi: Handle the 'New Timing' mode
Quoted 30 lines · Jean-Francois Moine
Some MMC devices as mmc2 in the A83T or mmc1 and mmc2 in the H3 have a 'New Timing' mode.
When aware about this capability, and when this is possible (clock rate great enough), the clock driver switches the MMC clock to the 'new mode', meaning that the phase delays are defined in the MMC registers instead of in the clock registers.
To alert the MMC driver about this switch, the clock driver returns the error code EPERM on callingclk_set_phase().This patch makes the MMC driver to handle this returned code and to activate or not the 'New Timing' mode on the MMC side.
Signed-off-by Jean-Francois Moine <[email protected]>---
Some explanations:
In the old timing, the phase delays are set in the clock only (that's why there is a functionclk_set_phase()which is called from the MMC side).
In the new timing, the delays are in the MMC registerSDXC_REG_NTSRonly.
The new timing works only when the clock rate is greater or equal to 50MHz.There are 2 flags saying that the new timing is used:
- the bit 'mode select' in the clock register, and
- the bit 'new timing' in the MMC register.
Both bits must be set/reset at the same time, otherwise the device does not work (tested with wifi and eMMC in H3 and A83T boards). So, some synchronization must exist.
Quoted 3 lines
The previous versions was using a DT property for the MMC and a flag in the clock driver. This did work with a correct configuration on both sides, but experiment showed that it was easy to do an error.
I still believe that we will need a property, at least to identify on which we can try the new mode, and on which clocks it's irrelevant (at least for the A33 and A83T).
However, I also believe we should make that mode switching explicit through a function call, instead of relying on some side effect (of some non-upstream code).
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160830/b503a2fa/attachment.sig>
PATCH v3 1/1 mmc: sunxi: Handle the 'New Timing' mode
Quoted 7 lines · On Tue, 30 Aug 2016 18:26:13 +0200 Maxime Ripard…
Quoted 7 lines
There are 2 flags saying that the new timing is used:
- the bit 'mode select' in the clock register, and
- the bit 'new timing' in the MMC register.
Both bits must be set/reset at the same time, otherwise the device does not work (tested with wifi and eMMC in H3 and A83T boards). So, some synchronization must exist.
Quoted 7 lines
Quoted 3 lines
The previous versions was using a DT property for the MMC and a flag in the clock driver. This did work with a correct configuration on both sides, but experiment showed that it was easy to do an error.
I still believe that we will need a property, at least to identify on which we can try the new mode, and on which clocks it's irrelevant (at least for the A33 and A83T).
As told above, setting the new mode on side (clock or MMC) and not on the other one prevents the devices to work. Then, it is safer to have the new mode capability flag only once for both sides.
Now, as the clocks are defined by memory tables and not by the DT, it seems natural to have the flag on the clock side.
Quoted 3 lines
However, I also believe we should make that mode switching explicit through a function call, instead of relying on some side effect (of some non-upstream code).
Do you mean a direct call from the MMC driver to the clock driver?
Signature · 2 lines
Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
PATCH v3 1/1 mmc: sunxi: Handle the 'New Timing' mode
Quoted 18 lines · Jean-Francois Moine
Quoted 7 lines · On Tue, 30 Aug 2016 18:26:13 +0200 Maxime Ripard…
Quoted 7 lines
There are 2 flags saying that the new timing is used:
- the bit 'mode select' in the clock register, and
- the bit 'new timing' in the MMC register.
Both bits must be set/reset at the same time, otherwise the device does not work (tested with wifi and eMMC in H3 and A83T boards). So, some synchronization must exist.Quoted 7 lines
Quoted 3 lines
The previous versions was using a DT property for the MMC and a flag in the clock driver. This did work with a correct configuration on both sides, but experiment showed that it was easy to do an error.
I still believe that we will need a property, at least to identify on which we can try the new mode, and on which clocks it's irrelevant (at least for the A33 and A83T).
Quoted 6 lines
As told above, setting the new mode on side (clock or MMC) and not on the other one prevents the devices to work. Then, it is safer to have the new mode capability flag only once for both sides.
Now, as the clocks are defined by memory tables and not by the DT, it seems natural to have the flag on the clock side.
You can look at it from two sides.
Either you try to switch to the new mode all the time, or you try to do it only for MMC controllers (and their associated clocks) that support it.
In the former case, you'll need to ignore a failure in the switch (mostly if the clock doesn't support it) only for the MMC controllers that do not have that mode. For the controllers that support it, you cannot ignore that error anymore. So you have to have some way to identify in which case you are.
And you need to have that in the former case too, so there's really no way you can go without such a flag.
Quoted 5 lines
Quoted 3 lines
However, I also believe we should make that mode switching explicit through a function call, instead of relying on some side effect (of some non-upstream code).
Do you mean a direct call from the MMC driver to the clock driver?
Yes.
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161011/69218957/attachment.sig>