From: Anton Vorontsov <hidden> Date: 2012-09-11 08:07:34
On Tue, Sep 11, 2012 at 12:54:29AM -0700, Anton Vorontsov wrote:
On Tue, Sep 11, 2012 at 03:12:44PM +0800, Chang-Ming.Huang@freescale.com wrote:
quoted
From: Jerry Huang <redacted>
Below SOCs don't support the cmd23 command for MMC card,
therefore, disable it in device tree:
P1020, P1021, P1022, P1024, P1025 and P4080
Signed-off-by: Jerry Huang <redacted>
Acked-by: Anton Vorontsov <redacted>
Btw, although the patch is trivial, I guess you still want to let know
PowerPC folks about it. Adding Cc and copying the patch:
- - - -
From: Jerry Huang <redacted>
Below SOCs don't support the cmd23 command for MMC card,
therefore, disable it in device tree:
P1020, P1021, P1022, P1024, P1025 and P4080
Signed-off-by: Jerry Huang <redacted>
CC: Anton Vorontsov <redacted>
---
arch/powerpc/boot/dts/fsl/p1020si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 1 +
4 files changed, 4 insertions(+)
From: Kumar Gala <hidden> Date: 2012-09-11 12:43:24
On Sep 11, 2012, at 4:36 AM, Huang Changming-R66093 wrote:
Thanks, Anton.
If it is necessary, I will resend this patch to =
linuxppc-dev@lists.ozlabs.org.
=20
Best Regards
Jerry Huang
I'm still not convinced this is the way to handle this issue. It seems =
as if the linux driver code makes some assumptions about CMD23 support =
that it shouldn't.
- k
=20
=20
quoted
-----Original Message-----
From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]
Sent: Tuesday, September 11, 2012 4:05 PM
To: Huang Changming-R66093
Cc: linux-mmc@vger.kernel.org; Kumar Gala; =
linuxppc-dev@lists.ozlabs.org
quoted
Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the =
CMD23
quoted
=20
On Tue, Sep 11, 2012 at 12:54:29AM -0700, Anton Vorontsov wrote:
quoted
On Tue, Sep 11, 2012 at 03:12:44PM +0800, Chang-
Ming.Huang@freescale.com wrote:
quoted
quoted
From: Jerry Huang <redacted>
=20
Below SOCs don't support the cmd23 command for MMC card, therefore,
disable it in device tree:
P1020, P1021, P1022, P1024, P1025 and P4080
=20
Signed-off-by: Jerry Huang <redacted>
=20
Acked-by: Anton Vorontsov <redacted>
=20
Btw, although the patch is trivial, I guess you still want to let =
know
quoted
PowerPC folks about it. Adding Cc and copying the patch:
=20
- - - -
From: Jerry Huang <redacted>
=20
Below SOCs don't support the cmd23 command for MMC card, therefore,
disable it in device tree:
P1020, P1021, P1022, P1024, P1025 and P4080
=20
Signed-off-by: Jerry Huang <redacted>
CC: Anton Vorontsov <redacted>
---
arch/powerpc/boot/dts/fsl/p1020si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 1 +
4 files changed, 4 insertions(+)
=20
From: Kumar Gala <hidden> Date: 2012-09-11 12:49:17
In sdhci_add_host()
We have the following
...
mmc->caps |=3D MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE | MMC_CAP_CMD23;
if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
host->flags |=3D SDHCI_AUTO_CMD12;
/* Auto-CMD23 stuff only works in ADMA or PIO. */
if ((host->version >=3D SDHCI_SPEC_300) &&
((host->flags & SDHCI_USE_ADMA) ||
!(host->flags & SDHCI_USE_SDMA))) {
host->flags |=3D SDHCI_AUTO_CMD23;
DBG("%s: Auto-CMD23 available\n", mmc_hostname(mmc));
} else {
DBG("%s: Auto-CMD23 unavailable\n", mmc_hostname(mmc));
}
...
I'm not clear what the difference is between mmc->caps & host->flags, =
but shouldn't we move setting MMC_CAP_CMD23 inside the 'Auto-CMD23' if =
check?
- k=
From: Chris Ball <hidden> Date: 2012-09-11 15:04:28
Hi,
On Tue, Sep 11 2012, Kumar Gala wrote:
In sdhci_add_host()
We have the following
...
mmc->caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE | MMC_CAP_CMD23;
if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
host->flags |= SDHCI_AUTO_CMD12;
/* Auto-CMD23 stuff only works in ADMA or PIO. */
if ((host->version >= SDHCI_SPEC_300) &&
((host->flags & SDHCI_USE_ADMA) ||
!(host->flags & SDHCI_USE_SDMA))) {
host->flags |= SDHCI_AUTO_CMD23;
DBG("%s: Auto-CMD23 available\n", mmc_hostname(mmc));
} else {
DBG("%s: Auto-CMD23 unavailable\n", mmc_hostname(mmc));
}
...
I'm not clear what the difference is between mmc->caps & host->flags, but shouldn't we move setting MMC_CAP_CMD23 inside the 'Auto-CMD23' if check?
The main answer is: No, because CMD23 is distinct from Auto-CMD23.
Multiblock transfers (CMD23) date back from MMC cards (which is why
they're an MMC host capability) and can also be used in SDHCI.
Auto-CMD23 is a new feature in SDHCI 3.0 that reduces the overhead
of sending CMD23. It doesn't work if we're using SDMA, though.
As for capability vs. flags, the capability is more of an inherent
property of the controller, and flags are runtime decisions on whether
to use that capability, based on e.g. the presence of a quirk.
So, I think the code's correct as written. Feel free to ask more
questions if you're investigating a specific problem that you haven't
mentioned yet.
Thanks,
- Chris.
--
Chris Ball [off-list ref] <http://printf.net/>
One Laptop Per Child
From: Scott Wood <hidden> Date: 2012-09-11 18:28:32
On 09/11/2012 03:04 AM, Anton Vorontsov wrote:
quoted hunk
On Tue, Sep 11, 2012 at 12:54:29AM -0700, Anton Vorontsov wrote:
quoted
On Tue, Sep 11, 2012 at 03:12:44PM +0800, Chang-Ming.Huang@freescale.com wrote:
quoted
From: Jerry Huang <redacted>
Below SOCs don't support the cmd23 command for MMC card,
therefore, disable it in device tree:
P1020, P1021, P1022, P1024, P1025 and P4080
Signed-off-by: Jerry Huang <redacted>
Acked-by: Anton Vorontsov <redacted>
Btw, although the patch is trivial, I guess you still want to let know
PowerPC folks about it. Adding Cc and copying the patch:
- - - -
From: Jerry Huang <redacted>
Below SOCs don't support the cmd23 command for MMC card,
therefore, disable it in device tree:
P1020, P1021, P1022, P1024, P1025 and P4080
Signed-off-by: Jerry Huang <redacted>
CC: Anton Vorontsov <redacted>
---
arch/powerpc/boot/dts/fsl/p1020si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 1 +
4 files changed, 4 insertions(+)
This won't help people with old device trees (forked for a custom board,
tied to an old U-Boot, etc). The driver should infer this from the
compatible string or version registers (ideally block-specific version
registers, but if these are absent or inconclusive, SVR can be used).
-Scott
From: Kumar Gala <hidden> Date: 2012-09-11 20:26:49
On Sep 11, 2012, at 9:44 AM, Chris Ball wrote:
Hi,
=20
On Tue, Sep 11 2012, Kumar Gala wrote:
quoted
In sdhci_add_host()
=20
We have the following
=20
...
mmc->caps |=3D MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE | =
MMC_CAP_CMD23;
quoted
=20
if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
host->flags |=3D SDHCI_AUTO_CMD12;
=20
/* Auto-CMD23 stuff only works in ADMA or PIO. */
if ((host->version >=3D SDHCI_SPEC_300) &&
((host->flags & SDHCI_USE_ADMA) ||
!(host->flags & SDHCI_USE_SDMA))) {
host->flags |=3D SDHCI_AUTO_CMD23;
DBG("%s: Auto-CMD23 available\n", mmc_hostname(mmc));
} else {
DBG("%s: Auto-CMD23 unavailable\n", =
mmc_hostname(mmc));
quoted
}
=20
...
=20
I'm not clear what the difference is between mmc->caps & host->flags, =
but shouldn't we move setting MMC_CAP_CMD23 inside the 'Auto-CMD23' if =
check?
=20
The main answer is: No, because CMD23 is distinct from Auto-CMD23.
=20
Multiblock transfers (CMD23) date back from MMC cards (which is why
they're an MMC host capability) and can also be used in SDHCI.
=20
Auto-CMD23 is a new feature in SDHCI 3.0 that reduces the overhead
of sending CMD23. It doesn't work if we're using SDMA, though.
=20
As for capability vs. flags, the capability is more of an inherent
property of the controller, and flags are runtime decisions on whether
to use that capability, based on e.g. the presence of a quirk.
=20
So, I think the code's correct as written. Feel free to ask more
questions if you're investigating a specific problem that you haven't
mentioned yet.
Chris,
thanks for the info. Do you know what's required on controller side to =
handle cards that support CMD23?
I'm trying to figure out if older controller's on FSL SoCs are missing =
some feature to allow CMD23 to work (vs Auto-CMD23).
- k=
From: Chris Ball <hidden> Date: 2012-09-11 20:59:18
Hi,
On Tue, Sep 11 2012, Kumar Gala wrote:
thanks for the info. Do you know what's required on controller side
to handle cards that support CMD23?
I'm trying to figure out if older controller's on FSL SoCs are missing
some feature to allow CMD23 to work (vs Auto-CMD23).
It seems plausible that it's just not implemented on these controllers.
It's a little strange, since the command's been specified for so long
and we haven't seen any other controllers with problems. The patch
would be correct if this is true.
- Chris.
--
Chris Ball [off-list ref] <http://printf.net/>
One Laptop Per Child
From: Anton Vorontsov <hidden> Date: 2012-09-12 03:40:52
On Wed, Sep 12, 2012 at 03:19:18AM +0000, Huang Changming-R66093 wrote:
[...]
I don't think it is the best way to do it. For the VVN2.2 or older,
some silicon support this feature (mpc8536 and p2020), but other
silicones don't support it (e.g. p4080, p102x). Though, the current
p5/p4/p3 has supported this feature, can we sure the future silicon
support it? So I think the best way is to specify it in device tree
as 'sdhci,auto-cmd12'
In addition to your current patches, you could just add another patch
that blacklists affected SOC revisions based on the info from PVR/SVR.
For example, see gfar_detect_errata() in
drivers/net/ethernet/freescale/gianfar.c.
That way you could help users that don't have the newest device trees.
Thanks,
Anton.
-----Original Message-----
From: Chris Ball [mailto:cjb@laptop.org]
Sent: Wednesday, September 12, 2012 4:59 AM
To: Kumar Gala
Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list; linux-
mmc@vger.kernel.org; Anton Vorontsov
Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23
=20
Hi,
=20
On Tue, Sep 11 2012, Kumar Gala wrote:
quoted
thanks for the info. Do you know what's required on controller side
to handle cards that support CMD23?
I'm trying to figure out if older controller's on FSL SoCs are missing
some feature to allow CMD23 to work (vs Auto-CMD23).
=20
It seems plausible that it's just not implemented on these controllers.
It's a little strange, since the command's been specified for so long and
we haven't seen any other controllers with problems. The patch would be
correct if this is true.
=20
I didn't find any description about it, but after testing on FSL silicones,=
I got this result:
Some silicones support this command, and some silicones don't support it, w=
hich will cause I/O error.
From: Kumar Gala <hidden> Date: 2012-09-12 12:13:53
On Sep 12, 2012, at 1:18 AM, Huang Changming-R66093 wrote:
=20
=20
Best Regards
Jerry Huang
=20
=20
quoted
-----Original Message-----
From: Chris Ball [mailto:cjb@laptop.org]
Sent: Wednesday, September 12, 2012 4:59 AM
To: Kumar Gala
Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list; =
linux-
quoted
mmc@vger.kernel.org; Anton Vorontsov
Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the =
CMD23
quoted
=20
Hi,
=20
On Tue, Sep 11 2012, Kumar Gala wrote:
quoted
thanks for the info. Do you know what's required on controller side
to handle cards that support CMD23?
=20
I'm trying to figure out if older controller's on FSL SoCs are =
missing
quoted
quoted
some feature to allow CMD23 to work (vs Auto-CMD23).
=20
It seems plausible that it's just not implemented on these =
controllers.
quoted
It's a little strange, since the command's been specified for so long =
and
quoted
we haven't seen any other controllers with problems. The patch would =
be
quoted
correct if this is true.
=20
=20
I didn't find any description about it, but after testing on FSL =
silicones, I got this result:
Some silicones support this command, and some silicones don't support =
it, which will cause I/O error.
Can you list out which SoCs support it and which don't. Having this =
list will be useful in understanding which controller versions supported =
it.
- k=
-----Original Message-----
From: Chris Ball [mailto:cjb@laptop.org]
Sent: Wednesday, September 12, 2012 4:59 AM
To: Kumar Gala
Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list;
linux- mmc@vger.kernel.org; Anton Vorontsov
Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the
CMD23
Hi,
On Tue, Sep 11 2012, Kumar Gala wrote:
quoted
thanks for the info. Do you know what's required on controller side
to handle cards that support CMD23?
I'm trying to figure out if older controller's on FSL SoCs are
missing some feature to allow CMD23 to work (vs Auto-CMD23).
It seems plausible that it's just not implemented on these controllers=
.
quoted
quoted
It's a little strange, since the command's been specified for so long
and we haven't seen any other controllers with problems. The patch
would be correct if this is true.
I didn't find any description about it, but after testing on FSL
silicones, I got this result:
quoted
Some silicones support this command, and some silicones don't support
it, which will cause I/O error.
=20
Can you list out which SoCs support it and which don't. Having this list
will be useful in understanding which controller versions supported it.
=20
P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041) supp=
ort it.
From: Kumar Gala <hidden> Date: 2012-09-13 12:47:55
On Sep 12, 2012, at 9:02 PM, Huang Changming-R66093 wrote:
quoted
quoted
=20
quoted
-----Original Message-----
From: Chris Ball [mailto:cjb@laptop.org]
Sent: Wednesday, September 12, 2012 4:59 AM
To: Kumar Gala
Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list;
linux- mmc@vger.kernel.org; Anton Vorontsov
Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the
CMD23
=20
Hi,
=20
On Tue, Sep 11 2012, Kumar Gala wrote:
quoted
thanks for the info. Do you know what's required on controller =
side
quoted
quoted
quoted
quoted
to handle cards that support CMD23?
=20
I'm trying to figure out if older controller's on FSL SoCs are
missing some feature to allow CMD23 to work (vs Auto-CMD23).
=20
It seems plausible that it's just not implemented on these =
controllers.
quoted
quoted
quoted
It's a little strange, since the command's been specified for so =
long
quoted
quoted
quoted
and we haven't seen any other controllers with problems. The patch
would be correct if this is true.
=20
=20
I didn't find any description about it, but after testing on FSL
silicones, I got this result:
quoted
Some silicones support this command, and some silicones don't =
support
quoted
it, which will cause I/O error.
=20
Can you list out which SoCs support it and which don't. Having this =
list
quoted
will be useful in understanding which controller versions supported =
it.
quoted
=20
P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041) =
support it.
Based on this, why don't we use the HOSTVER register to detect instead =
of device tree:
#define FSL_SDHC_VER_1_0 0x00
#define FSL_SDHC_VER_1_1 0x01
#define FSL_SDHC_VER_2_0 0x10
#define FSL_SDHC_VER_2_1 0x11
#define FSL_SDHC_VER_2_2 0x12
#define FSL_SDHC_VER_2_3 0x13
unsigned int vendor_version;
vendor_version =3D sdhci_readw(host, SDHCI_HOST_VERSION);
vendor_version =3D (vendor_version & SDHCI_VENDOR_VER_MASK) >> =
SDHCI_VENDOR_VER_SHIFT;
if ((vendor_version =3D=3D FSL_SDHC_VER_1_1) || (vendor_version =3D=3D =
FSL_SDHC_VER_2_2))
host->quirks2 |=3D SDHCI_QUIRK2_HOST_NO_CMD23;
- k
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Thursday, September 13, 2012 8:48 PM
To: Huang Changming-R66093
Cc: Chris Ball; linuxppc-dev@lists.ozlabs.org list; linux-
mmc@vger.kernel.org; Anton Vorontsov
Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23
=20
=20
On Sep 12, 2012, at 9:02 PM, Huang Changming-R66093 wrote:
=20
quoted
quoted
quoted
quoted
-----Original Message-----
From: Chris Ball [mailto:cjb@laptop.org]
Sent: Wednesday, September 12, 2012 4:59 AM
To: Kumar Gala
Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list;
linux- mmc@vger.kernel.org; Anton Vorontsov
Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the
CMD23
Hi,
On Tue, Sep 11 2012, Kumar Gala wrote:
quoted
thanks for the info. Do you know what's required on controller
side to handle cards that support CMD23?
I'm trying to figure out if older controller's on FSL SoCs are
missing some feature to allow CMD23 to work (vs Auto-CMD23).
It seems plausible that it's just not implemented on these
controllers.
quoted
quoted
quoted
quoted
It's a little strange, since the command's been specified for so
long and we haven't seen any other controllers with problems. The
patch would be correct if this is true.
I didn't find any description about it, but after testing on FSL
silicones, I got this result:
quoted
Some silicones support this command, and some silicones don't
support
it, which will cause I/O error.
Can you list out which SoCs support it and which don't. Having this
list will be useful in understanding which controller versions
supported it.
quoted
quoted
P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041)
support it.
=20
Based on this, why don't we use the HOSTVER register to detect instead of
device tree:
=20
=20
#define FSL_SDHC_VER_1_0 0x00
#define FSL_SDHC_VER_1_1 0x01
#define FSL_SDHC_VER_2_0 0x10
#define FSL_SDHC_VER_2_1 0x11
#define FSL_SDHC_VER_2_2 0x12
#define FSL_SDHC_VER_2_3 0x13
=20
unsigned int vendor_version;
=20
vendor_version =3D sdhci_readw(host, SDHCI_HOST_VERSION); vendor_version =
From: Kumar Gala <hidden> Date: 2012-09-14 12:40:17
quoted
quoted
quoted
quoted
=20
quoted
-----Original Message-----
From: Chris Ball [mailto:cjb@laptop.org]
Sent: Wednesday, September 12, 2012 4:59 AM
To: Kumar Gala
Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list;
linux- mmc@vger.kernel.org; Anton Vorontsov
Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable =
the
quoted
quoted
quoted
quoted
quoted
CMD23
=20
Hi,
=20
On Tue, Sep 11 2012, Kumar Gala wrote:
quoted
thanks for the info. Do you know what's required on controller
side to handle cards that support CMD23?
=20
I'm trying to figure out if older controller's on FSL SoCs are
missing some feature to allow CMD23 to work (vs Auto-CMD23).
=20
It seems plausible that it's just not implemented on these
controllers.
quoted
quoted
quoted
quoted
It's a little strange, since the command's been specified for so
long and we haven't seen any other controllers with problems. =
The
quoted
quoted
quoted
quoted
quoted
patch would be correct if this is true.
=20
=20
I didn't find any description about it, but after testing on FSL
silicones, I got this result:
quoted
Some silicones support this command, and some silicones don't
support
it, which will cause I/O error.
=20
Can you list out which SoCs support it and which don't. Having =
this
quoted
quoted
quoted
list will be useful in understanding which controller versions
supported it.
quoted
quoted
=20
P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, =
p3041)
quoted
support it.
=20
Based on this, why don't we use the HOSTVER register to detect =
From: Chris Ball <hidden> Date: 2012-09-17 12:36:12
Hi,
On Thu, Sep 13 2012, Kumar Gala wrote:
quoted
quoted
Can you list out which SoCs support it and which don't. Having this list
will be useful in understanding which controller versions supported it.
P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041) support it.
Based on this, why don't we use the HOSTVER register to detect instead of device tree:
I've got a mild preference for handling quirk assignment in the DT
rather than in driver code, so I'd prefer to just push the original
patch to mmc-next as-is. Does that sound okay?
(I think the argument that there isn't going to be any new hardware
with this problem is equally in favor of both methods.)
Thanks,
- Chris.
--
Chris Ball [off-list ref] <http://printf.net/>
One Laptop Per Child
From: Kumar Gala <hidden> Date: 2012-09-17 13:13:11
On Sep 17, 2012, at 7:36 AM, Chris Ball wrote:
Hi,
=20
On Thu, Sep 13 2012, Kumar Gala wrote:
quoted
quoted
quoted
Can you list out which SoCs support it and which don't. Having =
this list
quoted
quoted
quoted
will be useful in understanding which controller versions supported =
it.
quoted
quoted
quoted
=20
P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, =
p3041) support it.
quoted
=20
Based on this, why don't we use the HOSTVER register to detect =
instead of device tree:
=20
I've got a mild preference for handling quirk assignment in the DT
rather than in driver code, so I'd prefer to just push the original
patch to mmc-next as-is. Does that sound okay?
Why? I only ask because I agree with Scott that this means you have to =
update your device tree to get proper functionality.
(I think the argument that there isn't going to be any new hardware
with this problem is equally in favor of both methods.)
From: Chris Ball <hidden> Date: 2012-09-17 13:45:22
Hi,
On Mon, Sep 17 2012, Kumar Gala wrote:
quoted
quoted
quoted
P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041) support it.
Based on this, why don't we use the HOSTVER register to detect instead of device tree:
I've got a mild preference for handling quirk assignment in the DT
rather than in driver code, so I'd prefer to just push the original
patch to mmc-next as-is. Does that sound okay?
Why? I only ask because I agree with Scott that this means you have to update your device tree to get proper functionality.
Thanks, I'd missed that. I withdraw my preference; I'll pick up
whichever method you all prefer.
- Chris.
--
Chris Ball [off-list ref] <http://printf.net/>
One Laptop Per Child
On Sep 17, 2012, at 7:36 AM, Chris Ball wrote:
=20
quoted
Hi,
On Thu, Sep 13 2012, Kumar Gala wrote:
quoted
quoted
quoted
Can you list out which SoCs support it and which don't. Having
this list will be useful in understanding which controller versions
supported it.
quoted
quoted
quoted
quoted
P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041=
)
support it.
quoted
quoted
Based on this, why don't we use the HOSTVER register to detect instead
of device tree:
quoted
I've got a mild preference for handling quirk assignment in the DT
rather than in driver code, so I'd prefer to just push the original
patch to mmc-next as-is. Does that sound okay?
=20
Why? I only ask because I agree with Scott that this means you have to
update your device tree to get proper functionality.
=20
When the new silicon does not support CMD23,
if we don't update the device tree, then we must update the SDHC driver.
I prefer to add the property in device tree,
because we just add this property in new device tree, we don't need more ef=
fort to modify driver.
From: Kumar Gala <hidden> Date: 2012-09-18 05:01:07
On Sep 17, 2012, at 8:09 PM, Huang Changming-R66093 wrote:
quoted
On Sep 17, 2012, at 7:36 AM, Chris Ball wrote:
=20
quoted
Hi,
=20
On Thu, Sep 13 2012, Kumar Gala wrote:
quoted
quoted
quoted
Can you list out which SoCs support it and which don't. Having
this list will be useful in understanding which controller =
versions
quoted
supported it.
quoted
quoted
quoted
quoted
=20
P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, =
p3041)
quoted
support it.
quoted
quoted
=20
Based on this, why don't we use the HOSTVER register to detect =
instead
quoted
of device tree:
quoted
=20
I've got a mild preference for handling quirk assignment in the DT
rather than in driver code, so I'd prefer to just push the original
patch to mmc-next as-is. Does that sound okay?
=20
Why? I only ask because I agree with Scott that this means you have =
to
quoted
update your device tree to get proper functionality.
=20
When the new silicon does not support CMD23,
if we don't update the device tree, then we must update the SDHC =
driver.
I prefer to add the property in device tree,
because we just add this property in new device tree, we don't need =
more effort to modify driver.
=20
Jerry,
I think doing it driver makes more sense because:
1. means older device tree's still work
2. odds that CMD23 not being supported in future devices is near 0%
(Now that we support AutoCMD23 [and thus CMD23] we aren't likely to =
stop supporting it in future)
3. If IP changes you are going to have to update driver anyways for new =
features
I really think we should NOT utilize device tree for this.
- k
From: Chris Ball <hidden> Date: 2012-09-18 05:07:46
Hi,
On Tue, Sep 18 2012, Kumar Gala wrote:
quoted
quoted
quoted
I've got a mild preference for handling quirk assignment in the DT
rather than in driver code, so I'd prefer to just push the original
patch to mmc-next as-is. Does that sound okay?
Why? I only ask because I agree with Scott that this means you have to
update your device tree to get proper functionality.
When the new silicon does not support CMD23,
if we don't update the device tree, then we must update the SDHC driver.
I prefer to add the property in device tree,
because we just add this property in new device tree, we don't need more effort to modify driver.
Jerry,
I think doing it driver makes more sense because:
1. means older device tree's still work
2. odds that CMD23 not being supported in future devices is near 0%
(Now that we support AutoCMD23 [and thus CMD23] we aren't likely to stop supporting it in future)
3. If IP changes you are going to have to update driver anyways for new features
I really think we should NOT utilize device tree for this.
Of course, we could also make both (or perhaps neither) of you happy by
merging both: if your DT says you don't support cmd23 *or* you hit the
driver's blacklist, we avoid it.
- Chris.
--
Chris Ball [off-list ref] <http://printf.net/>
One Laptop Per Child