From: Yangbo Lu <hidden> Date: 2015-07-21 09:50:38
For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
version value and sdhc spec version value. This will break down
the ADMA data transfer. So add workaround to get right value
VVN=0x13, SVN = 0x1.
Signed-off-by: Yangbo Lu <redacted>
---
drivers/mmc/host/sdhci-esdhc.h | 5 +++++
drivers/mmc/host/sdhci-of-esdhc.c | 18 ++++++++++++++++++
2 files changed, 23 insertions(+)
On 21 July 2015 at 11:45, Yangbo Lu [off-list ref] wrote:
For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
version value and sdhc spec version value. This will break down
the ADMA data transfer. So add workaround to get right value
VVN=0x13, SVN = 0x1.
So T4240-R1.0-R2.0 is the version of the controller, right?
If I understand correct you are checking what CPU/SoC you are running
on, to figure out which controller version you are using, as that
can't be fetched (trusted) from the registers of the esdhc controller
itself!?
Instead, you could deal with this directly in the DTS files. I assume
you have some DTS file for each SoC/board variant, right?
In principle, in your DTS file specific for the board/SoC that holds
the T4240-R1.0-R2.0 version of the controller, should add a specific
esdhc DT property to indicate this errata. This DT property will then
be parsed by the esdhc driver.
From: Scott Wood <hidden> Date: 2015-07-25 02:27:38
On Tue, 2015-07-21 at 15:02 +0200, Ulf Hansson wrote:
On 21 July 2015 at 11:45, Yangbo Lu [off-list ref] wrote:
quoted
For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
version value and sdhc spec version value. This will break down
the ADMA data transfer. So add workaround to get right value
VVN=0x13, SVN = 0x1.
So T4240-R1.0-R2.0 is the version of the controller, right?
If I understand correct you are checking what CPU/SoC you are running
on, to figure out which controller version you are using, as that
can't be fetched (trusted) from the registers of the esdhc controller
itself!?
Instead, you could deal with this directly in the DTS files. I assume
you have some DTS file for each SoC/board variant, right?
No, we do not have a separate DTS file for each revision of an SoC -- and if
we did, we'd constantly have people using the wrong one.
In principle, in your DTS file specific for the board/SoC that holds
the T4240-R1.0-R2.0 version of the controller, should add a specific
esdhc DT property to indicate this errata.
No, because (in addition to the above issue about chip revisions) the device
tree is stable ABI and errata are often discovered after device trees are
deployed.
-Scott
On 25 July 2015 at 04:27, Scott Wood [off-list ref] wrote:
On Tue, 2015-07-21 at 15:02 +0200, Ulf Hansson wrote:
quoted
On 21 July 2015 at 11:45, Yangbo Lu [off-list ref] wrote:
quoted
For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
version value and sdhc spec version value. This will break down
the ADMA data transfer. So add workaround to get right value
VVN=0x13, SVN = 0x1.
So T4240-R1.0-R2.0 is the version of the controller, right?
If I understand correct you are checking what CPU/SoC you are running
on, to figure out which controller version you are using, as that
can't be fetched (trusted) from the registers of the esdhc controller
itself!?
Instead, you could deal with this directly in the DTS files. I assume
you have some DTS file for each SoC/board variant, right?
No, we do not have a separate DTS file for each revision of an SoC -- and if
we did, we'd constantly have people using the wrong one.
quoted
In principle, in your DTS file specific for the board/SoC that holds
the T4240-R1.0-R2.0 version of the controller, should add a specific
esdhc DT property to indicate this errata.
No, because (in addition to the above issue about chip revisions) the device
tree is stable ABI and errata are often discovered after device trees are
deployed.
Fair enough. Then what is your suggestion for the solution here?
As I understand it, you can't update the already deployed DTB. Shall
we make Linux patch the DTB during boot instead, depending on the chip
revision?
Kind regards
Uffe
From: Scott Wood <hidden> Date: 2015-07-27 20:39:19
On Mon, 2015-07-27 at 09:58 +0200, Ulf Hansson wrote:
On 25 July 2015 at 04:27, Scott Wood [off-list ref] wrote:
quoted
On Tue, 2015-07-21 at 15:02 +0200, Ulf Hansson wrote:
quoted
On 21 July 2015 at 11:45, Yangbo Lu [off-list ref] wrote:
quoted
For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
version value and sdhc spec version value. This will break down
the ADMA data transfer. So add workaround to get right value
VVN=0x13, SVN = 0x1.
So T4240-R1.0-R2.0 is the version of the controller, right?
If I understand correct you are checking what CPU/SoC you are running
on, to figure out which controller version you are using, as that
can't be fetched (trusted) from the registers of the esdhc controller
itself!?
Instead, you could deal with this directly in the DTS files. I assume
you have some DTS file for each SoC/board variant, right?
No, we do not have a separate DTS file for each revision of an SoC -- and
if
we did, we'd constantly have people using the wrong one.
quoted
In principle, in your DTS file specific for the board/SoC that holds
the T4240-R1.0-R2.0 version of the controller, should add a specific
esdhc DT property to indicate this errata.
No, because (in addition to the above issue about chip revisions) the
device
tree is stable ABI and errata are often discovered after device trees are
deployed.
Fair enough. Then what is your suggestion for the solution here?
As I said in my comment on patch 2/3, read SVR from the device-config/guts
MMIO block, which works on both PPC and ARM.
-Scott
On 27 July 2015 at 17:57, Scott Wood [off-list ref] wrote:
On Mon, 2015-07-27 at 09:58 +0200, Ulf Hansson wrote:
quoted
On 25 July 2015 at 04:27, Scott Wood [off-list ref] wrote:
quoted
On Tue, 2015-07-21 at 15:02 +0200, Ulf Hansson wrote:
quoted
On 21 July 2015 at 11:45, Yangbo Lu [off-list ref] wrote:
quoted
For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
version value and sdhc spec version value. This will break down
the ADMA data transfer. So add workaround to get right value
VVN=0x13, SVN = 0x1.
So T4240-R1.0-R2.0 is the version of the controller, right?
If I understand correct you are checking what CPU/SoC you are running
on, to figure out which controller version you are using, as that
can't be fetched (trusted) from the registers of the esdhc controller
itself!?
Instead, you could deal with this directly in the DTS files. I assume
you have some DTS file for each SoC/board variant, right?
No, we do not have a separate DTS file for each revision of an SoC -- and
if
we did, we'd constantly have people using the wrong one.
quoted
In principle, in your DTS file specific for the board/SoC that holds
the T4240-R1.0-R2.0 version of the controller, should add a specific
esdhc DT property to indicate this errata.
No, because (in addition to the above issue about chip revisions) the
device
tree is stable ABI and errata are often discovered after device trees are
deployed.
Fair enough. Then what is your suggestion for the solution here?
As I said in my comment on patch 2/3, read SVR from the device-config/guts
MMIO block, which works on both PPC and ARM.
That's okay, as long as don't have include sections of non generic
header files in the driver.
To be more clear, this is not okay to have:
#include <mach/*>
Kind regards
Uffe
From: Scott Wood <hidden> Date: 2015-08-26 14:16:34
On Wed, 2015-08-26 at 02:49 -0500, Lu Yangbo-B47093 wrote:
quoted
quoted
quoted
quoted
quoted
For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender
version value and sdhc spec version value. This will break down
the ADMA data transfer. So add workaround to get right value
VVN=0x13, SVN = 0x1.
So T4240-R1.0-R2.0 is the version of the controller, right?
If I understand correct you are checking what CPU/SoC you are
running on, to figure out which controller version you are using,
as that can't be fetched (trusted) from the registers of the esdhc
controller itself!?
Instead, you could deal with this directly in the DTS files. I
assume you have some DTS file for each SoC/board variant, right?
No, we do not have a separate DTS file for each revision of an SoC
-- and if we did, we'd constantly have people using the wrong one.
quoted
In principle, in your DTS file specific for the board/SoC that
holds the T4240-R1.0-R2.0 version of the controller, should add a
specific esdhc DT property to indicate this errata.
No, because (in addition to the above issue about chip revisions)
the device tree is stable ABI and errata are often discovered after
device trees are deployed.
Fair enough. Then what is your suggestion for the solution here?
As I said in my comment on patch 2/3, read SVR from the device-
config/guts MMIO block, which works on both PPC and ARM.
-Scott
Thanks, Scott.
I checked the device nodes of device-config/guts, finding all the platforms
has not a uniform compatible name.
Could I add a compatible name called "fsl, dcfg"("fsl, guts" if using guts)
for PowerPC P series, T series, B series boards, so that I could get this
device node by compatible without knowing platform?
No. It's too vague. Linux should keep a list of all the nodes it can match
against for this. Centralize it in one place rather than having each driver
that cares about SVR do it.
-Scott