* Re: [PATCH 13/13] Documentation: synopsys-dw-mshc: remove the unused properties
From: Rob Herring @ 2016-11-10 18:47 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, krzk-DgEjT+Ai2ygdnm+yROfE0A,
heiko-4mtYJXux2i+zQB+pC5nmwQ, shawn.lin-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <20161103062135.10697-14-jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Thu, Nov 03, 2016 at 03:21:35PM +0900, Jaehoon Chung wrote:
> "support-highspeed" was the obsoleted property.
> And "broken-cd" is not synopsys specific property.
> It can be referred to mmc.txt binding Documentation.
>
> Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 5 -----
> 1 file changed, 5 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL] MMC fixes for v.4.9 rc5
From: Ulf Hansson @ 2016-11-10 21:39 UTC (permalink / raw)
To: Linus, linux-mmc, linux-kernel@vger.kernel.org
Cc: Jaehoon Chung, Adrian Hunter
Hi Linus,
Here are some mmc fixes intended for v4.9 rc5. They are based on v4.9-rc5.
Details are as usual found in the signed tag. Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit bc33b0ca11e3df467777a4fa7639ba488c9d4911:
Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v4.9-rc4
for you to fetch changes up to f91346e8b5f46aaf12f1df26e87140584ffd1b3f:
mmc: mxs: Initialize the spinlock prior to using it (2016-11-07
13:30:08 +0100)
----------------------------------------------------------------
MMC core:
- Fix mmc card initialization for hosts not supporting HW busy detection
- Fix mmc_test for sending commands during non-blocking write
MMC host:
- mxs: Avoid using an uninitialized
- sdhci: Restore enhanced strobe setting during runtime resume
- sdhci: Fix a couple of reset related issues
- dw_mmc: Fix a reset controller issue
----------------------------------------------------------------
Adrian Hunter (5):
mmc: sdhci: Fix CMD line reset interfering with ongoing data transfer
mmc: sdhci: Fix unexpected data interrupt handling
mmc: sdhci: Reset cmd and data circuits after tuning failure
mmc: sdhci: Fix missing enhanced strobe setting during runtime resume
mmc: mmc_test: Fix "Commands during non-blocking write" tests
Fabio Estevam (1):
mmc: mxs: Initialize the spinlock prior to using it
Jaehoon Chung (2):
Documentation: synopsys-dw-mshc: add binding for reset-names
mmc: dw_mmc: add the "reset" as name of reset controller
Ulf Hansson (1):
mmc: mmc: Use 500ms as the default generic CMD6 timeout
.../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 5 +++
drivers/mmc/card/mmc_test.c | 8 ++---
drivers/mmc/core/mmc.c | 3 ++
drivers/mmc/host/dw_mmc.c | 2 +-
drivers/mmc/host/mxs-mmc.c | 4 +--
drivers/mmc/host/sdhci.c | 36 ++++++++++++++++------
6 files changed, 41 insertions(+), 17 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] mmc: sdhci-pci: Let devices define their own private data
From: Ulf Hansson @ 2016-11-10 22:16 UTC (permalink / raw)
To: Shyam Sundar S K
Cc: Adrian Hunter, linux-mmc, Sen, Pankaj, Agrawal, Nitesh-kumar,
Shah, Nehal-bakulchandra
In-Reply-To: <78fc9537-4fea-1938-ba1d-b0c6030bd777@amd.com>
On 10 November 2016 at 13:50, Shyam Sundar S K <ssundark@amd.com> wrote:
> Let devices define their own private data to facilitate device-specific
> operations. The size of the private structure is specified in the
> sdhci_pci_fixes structure,then sdhci_pci_probe_slot() will allocate extra
> space for it, and sdhci_pci_priv() can be used to get a reference to it.
>
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Still not Adrian as author...
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-pci-core.c | 3 ++-
> drivers/mmc/host/sdhci-pci.h | 7 +++++++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
> index 1d9e00a..782c8d2 100644
> --- a/drivers/mmc/host/sdhci-pci-core.c
> +++ b/drivers/mmc/host/sdhci-pci-core.c
> @@ -1646,6 +1646,7 @@ static struct sdhci_pci_slot *sdhci_pci_probe_slot(
> struct sdhci_pci_slot *slot;
> struct sdhci_host *host;
> int ret, bar = first_bar + slotno;
> + size_t priv_size = chip->fixes ? chip->fixes->priv_size : 0;
>
> if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) {
> dev_err(&pdev->dev, "BAR %d is not iomem. Aborting.\n", bar);
> @@ -1667,7 +1668,7 @@ static struct sdhci_pci_slot *sdhci_pci_probe_slot(
> return ERR_PTR(-ENODEV);
> }
>
> - host = sdhci_alloc_host(&pdev->dev, sizeof(struct sdhci_pci_slot));
> + host = sdhci_alloc_host(&pdev->dev, sizeof(*slot) + priv_size);
> if (IS_ERR(host)) {
> dev_err(&pdev->dev, "cannot allocate host\n");
> return ERR_CAST(host);
> diff --git a/drivers/mmc/host/sdhci-pci.h b/drivers/mmc/host/sdhci-pci.h
> index 6bccf56..0bfd568 100644
> --- a/drivers/mmc/host/sdhci-pci.h
> +++ b/drivers/mmc/host/sdhci-pci.h
> @@ -67,6 +67,7 @@ struct sdhci_pci_fixes {
> int (*resume) (struct sdhci_pci_chip *);
>
> const struct sdhci_ops *ops;
> + size_t priv_size;
> };
>
> struct sdhci_pci_slot {
> @@ -87,6 +88,7 @@ struct sdhci_pci_slot {
> struct mmc_card *card,
> unsigned int max_dtr, int host_drv,
> int card_drv, int *drv_type);
> + unsigned long private[0] ____cacheline_aligned;
> };
>
> struct sdhci_pci_chip {
> @@ -101,4 +103,9 @@ struct sdhci_pci_chip {
> struct sdhci_pci_slot *slots[MAX_SLOTS]; /* Pointers to host slots */
> };
>
> +static inline void *sdhci_pci_priv(struct sdhci_pci_slot *slot)
> +{
> + return (void *)slot->private;
> +}
> +
> #endif /* __SDHCI_PCI_H */
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH v8 0/6] UHS-I SDR-104 support for sh_mobile_sdhi
From: Ulf Hansson @ 2016-11-10 22:21 UTC (permalink / raw)
To: Wolfram Sang, Simon Horman
Cc: Wolfram Sang, Magnus Damm, linux-mmc, Linux-Renesas
In-Reply-To: <20161110114549.GC1436@katana>
On 10 November 2016 at 12:45, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Thu, Nov 03, 2016 at 03:15:58PM +0100, Simon Horman wrote:
>> Hi,
>>
>> this series is based on work by Ai Kyuse to add UHS-I SDR-104 support for
>> sh_mobile_sdhi. It builds on work by Shinobu Uehara, Rob Taylor, William
>> Towle and Ian Molton, Ben Hutchings, Wolfram Sang and others to add UHS-I
>> SDR-50 support to the same driver.
>>
>> It is based on the next branch of the mmc tree.
>>
>> To aid review the following git branch is provided:
>> * https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/sdr104-driver-v8
>>
>> Overview of changes since v7:
>> * Correct inverted logic in sh_mobile_sdhi_hw_reset
>> * Correct value of SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN
>>
>> Please see http://elinux.org/Tests:SD-SDHI-SDR104 for indicative tests
>> results.
>
> Successfully tested on a Lager Board with a SanDisk card and a Samsung
> card which used to cause issues before.
>
> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> Ulf, I think this series is ready to go for v4.10. All issues we know of
> are related to pinmuxing and will be solved elsewhere. We currently have
> hacks for that so it is quite clear the issues are not caused by this
> series.
>
Thanks, applied for next!
I did have to fix conflict and also to resolve some checkpatch
warnings - but no worries this time!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v2 1/2] mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings document
From: Ulf Hansson @ 2016-11-10 22:21 UTC (permalink / raw)
To: Scott Branden
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Adrian Hunter,
BCM Kernel Feedback, linux-mmc, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Anup Patel
In-Reply-To: <1478018277-10097-2-git-send-email-scott.branden@broadcom.com>
On 1 November 2016 at 17:37, Scott Branden <scott.branden@broadcom.com> wrote:
> Adds brcm,sdhci-iproc compat string to DT bindings document for
> the iProc SDHCI driver.
>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> index be56d2b..954561d 100644
> --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> +++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> @@ -7,6 +7,15 @@ Required properties:
> - compatible : Should be one of the following
> "brcm,bcm2835-sdhci"
> "brcm,sdhci-iproc-cygnus"
> + "brcm,sdhci-iproc"
> +
> +Use brcm2835-sdhci for Rasperry PI.
> +
> +Use sdhci-iproc-cygnus for Broadcom SDHCI Controllers
> +restricted to 32bit host accesses to SDHCI registers.
> +
> +Use sdhci-iproc for Broadcom SDHCI Controllers that allow standard
> +8, 16, 32-bit host access to SDHCI register.
>
> - clocks : The clock feeding the SDHCI controller.
>
> --
> 2.5.0
>
^ permalink raw reply
* Re: [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Ulf Hansson @ 2016-11-10 22:21 UTC (permalink / raw)
To: Scott Branden
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Adrian Hunter,
BCM Kernel Feedback, linux-mmc, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Srinath Mannam
In-Reply-To: <1478018277-10097-3-git-send-email-scott.branden@broadcom.com>
On 1 November 2016 at 17:37, Scott Branden <scott.branden@broadcom.com> wrote:
> Add bytewise register accesses support for newer versions of IPROC
> SDHCI controllers.
> Previous sdhci-iproc versions of SDIO controllers
> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
> accesses.
>
> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-iproc.c | 35 +++++++++++++++++++++++++++++++++--
> 1 file changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index 7262466..d7046d6 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -143,6 +143,14 @@ static void sdhci_iproc_writeb(struct sdhci_host *host, u8 val, int reg)
> }
>
> static const struct sdhci_ops sdhci_iproc_ops = {
> + .set_clock = sdhci_set_clock,
> + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> + .set_bus_width = sdhci_set_bus_width,
> + .reset = sdhci_reset,
> + .set_uhs_signaling = sdhci_set_uhs_signaling,
> +};
> +
> +static const struct sdhci_ops sdhci_iproc_32only_ops = {
> .read_l = sdhci_iproc_readl,
> .read_w = sdhci_iproc_readw,
> .read_b = sdhci_iproc_readb,
> @@ -156,6 +164,28 @@ static const struct sdhci_ops sdhci_iproc_ops = {
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> };
>
> +static const struct sdhci_pltfm_data sdhci_iproc_cygnus_pltfm_data = {
> + .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
> + .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
> + .ops = &sdhci_iproc_32only_ops,
> +};
> +
> +static const struct sdhci_iproc_data iproc_cygnus_data = {
> + .pdata = &sdhci_iproc_cygnus_pltfm_data,
> + .caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
> + & SDHCI_MAX_BLOCK_MASK) |
> + SDHCI_CAN_VDD_330 |
> + SDHCI_CAN_VDD_180 |
> + SDHCI_CAN_DO_SUSPEND |
> + SDHCI_CAN_DO_HISPD |
> + SDHCI_CAN_DO_ADMA2 |
> + SDHCI_CAN_DO_SDMA,
> + .caps1 = SDHCI_DRIVER_TYPE_C |
> + SDHCI_DRIVER_TYPE_D |
> + SDHCI_SUPPORT_DDR50,
> + .mmc_caps = MMC_CAP_1_8V_DDR,
> +};
> +
> static const struct sdhci_pltfm_data sdhci_iproc_pltfm_data = {
> .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
> .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
> @@ -182,7 +212,7 @@ static const struct sdhci_pltfm_data sdhci_bcm2835_pltfm_data = {
> .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
> SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> SDHCI_QUIRK_MISSING_CAPS,
> - .ops = &sdhci_iproc_ops,
> + .ops = &sdhci_iproc_32only_ops,
> };
>
> static const struct sdhci_iproc_data bcm2835_data = {
> @@ -194,7 +224,8 @@ static const struct sdhci_iproc_data bcm2835_data = {
>
> static const struct of_device_id sdhci_iproc_of_match[] = {
> { .compatible = "brcm,bcm2835-sdhci", .data = &bcm2835_data },
> - { .compatible = "brcm,sdhci-iproc-cygnus", .data = &iproc_data },
> + { .compatible = "brcm,sdhci-iproc-cygnus", .data = &iproc_cygnus_data},
> + { .compatible = "brcm,sdhci-iproc", .data = &iproc_data },
> { }
> };
> MODULE_DEVICE_TABLE(of, sdhci_iproc_of_match);
> --
> 2.5.0
>
^ permalink raw reply
* Re: [PATCH 0/2] mmc: allow mmc_alloc_host() and tmio_mmc_host_alloc()
From: Masahiro Yamada @ 2016-11-11 3:19 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Ulf Hansson, Adrian Hunter, Wolfram Sang, Sascha Sommer,
Johan Hovold, Sonic Zhang, devel, Russell King, Jaehoon Chung,
Chen-Yu Tsai, Pierre Ossman, Harald Welte, Alex Dubov,
adi-buildroot-devel, Michał Mirosław,
moderated list:ARM/Mediatek SoC support, Ben Dooks, Tony Olech,
Matthias Brugger, linux-omap, linux-arm-kernel
In-Reply-To: <20161110133559.GA10191@kroah.com>
2016-11-10 22:35 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> On Thu, Nov 10, 2016 at 10:24:21PM +0900, Masahiro Yamada wrote:
>>
>> sdhci_alloc_host() returns an error pointer when it fails.
>> but mmc_alloc_host() cannot.
>>
>> This series allow to propagate a proper error code
>> when host-allocation fails.
>
> Why? What can we really do about the error except give up? Why does
> having a explicit error value make any difference to the caller, they
> can't do anything different, right?
The error code is shown in the console, like
probe of 5a000000.sdhc failed with error -12
The proper error code will give a clue
why the driver failed to probe.
> I suggest just leaving it as-is, it's simple, and you don't have to mess
> with PTR_ERR() anywhere.
Why?
Most of driver just give up probing for any error,
but we still do ERR_PTR()/PTR_ERR() here and there.
I think this patch is the same pattern.
If a function returns NULL on failure, we need to think about
"what is the most common failure case".
Currently, MMC drivers assume -ENOMEM is the best
fit for mmc_alloc_host(), but the assumption is fragile.
Already, mmc_alloc_host() calls a function
that returns not only -ENOMEM, but also -ENOSPC.
In the future, some other failure cases might be
added to mmc_alloc_host().
Once we decide the API returns an error pointer,
drivers just propagate the return value from the API.
This is much more stable implementation.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Jisheng Zhang @ 2016-11-11 3:22 UTC (permalink / raw)
To: Ziji Hu, Rob Herring
Cc: Gregory CLEMENT, Ulf Hansson, Adrian Hunter,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, devicetree-u79uwXL29TY76Z2rM5mHXA,
Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jack(SH) Zhu,
Jimmy Xu, Nadav Haklai, Ryan Gao, Doug Jones, Shiwu Zhang,
Victor Gu, Wei(SOCP) Liu, Wilson Ding, Xueping Liu, Hilbert
In-Reply-To: <15b06a12-ed69-03a7-ccc7-0c133ce1ac1e-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Hi Rob, Ziji,
On Thu, 10 Nov 2016 19:44:19 +0800 Ziji Hu wrote:
> Hi Rob,
>
> On 2016/11/10 2:24, Rob Herring wrote:
> > On Mon, Oct 31, 2016 at 12:09:54PM +0100, Gregory CLEMENT wrote:
> >> From: Ziji Hu <huziji-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
> >>
> >> Marvell Xenon SDHC can support eMMC/SD/SDIO.
> >> Add Xenon-specific properties.
> >> Also add properties for Xenon PHY setting.
> >>
> >> Signed-off-by: Hu Ziji <huziji-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >> ---
> >> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 +++++++-
> >> MAINTAINERS | 1 +-
> >> 2 files changed, 162 insertions(+), 0 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> >> new file mode 100644
> >> index 000000000000..0d2d139494d3
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> >> @@ -0,0 +1,161 @@
> >> +Marvell's Xenon SDHCI Controller device tree bindings
> >> +This file documents differences between the core mmc properties
> >> +described by mmc.txt and the properties used by the Xenon implementation.
> >> +
> >> +A single Xenon IP can support multiple slots.
> >> +Each slot acts as an independent SDHC. It owns independent resources, such
> >> +as register sets clock and PHY.
> >> +Each slot should have an independent device tree node.
> >> +
> >> +Required Properties:
> >> +- compatible: should be one of the following
> >> + - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SOC.
> >> + Must provide a second register area and marvell,pad-type.
> >> + - "marvell,xenon-sdhci": For controllers on all the SOCs, other than
> >> + Armada-3700.
> >
> > Need SoC specific compatible strings.
> >
>
> Xenon SDHC is a common IP for all Marvell SOCs.
> It is difficult to use a single SOC specific compatible to represent Xenon SDHC.
> There will be so many SOC compatible strings in list if each specific SOC owns a compatible.
> Actually only few SOCs require special properties.
> Any suggestion please?
>
> >> +
> >> +- clocks:
> >> + Array of clocks required for SDHCI.
> >> + Requires at least one for Xenon IP core.
> >> + Some SOCs require additional clock for AXI bus.
> >> +
> >> +- clock-names:
> >> + Array of names corresponding to clocks property.
> >> + The input clock for Xenon IP core should be named as "core".
> >> + The optional AXI clock should be named as "axi".
> >
> > When is AXI clock optional? This should be required for ?? compatible
> > strings.
> >
> It is required on some SOCs.
> I will double check if a suitable compatible string can be determined for those SOCs.
Besides the core clk, berlin SoCs have one AXI clock. Usually, we have two
solutions:
solA: as current patch does, take "marvell,xenon-sdhci" as compatible string
and make the AXI clock property optional. Usually for berlin SoCs, we don't need
special properties.
PS: this solution is also what sdhci-pxav3.c takes
solB: As Rob said, add extra SoC compatible strings, so we'll have
something like:
static const struct of_device_id sdhci_xenon_of_match[] = {
{ .compatible = "marvell,armada-3700-sdhci", },
{ .compatible = "marvell,berlin4ct-sdhci", },
...
{ .compatible = "marvell,berlinxxx-mmc", },
}
then we take care the AXI clk for berlin SoCs in the code.
Which solution do you prefer?
Thanks,
Jisheng
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Jisheng Zhang @ 2016-11-11 3:33 UTC (permalink / raw)
To: Ziji Hu, Rob Herring
Cc: Gregory CLEMENT, Ulf Hansson, Adrian Hunter, linux-mmc,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, devicetree,
Thomas Petazzoni, linux-arm-kernel, Jack(SH) Zhu, Jimmy Xu,
Nadav Haklai, Ryan Gao, Doug Jones, Shiwu Zhang, Victor Gu,
Wei(SOCP) Liu, Wilson Ding, Xueping Liu, Hilbert
In-Reply-To: <20161111112243.7431625d@xhacker>
On Fri, 11 Nov 2016 11:22:43 +0800 Jisheng Zhang wrote:
> Hi Rob, Ziji,
>
> On Thu, 10 Nov 2016 19:44:19 +0800 Ziji Hu wrote:
>
> > Hi Rob,
> >
> > On 2016/11/10 2:24, Rob Herring wrote:
> > > On Mon, Oct 31, 2016 at 12:09:54PM +0100, Gregory CLEMENT wrote:
> > >> From: Ziji Hu <huziji@marvell.com>
> > >>
> > >> Marvell Xenon SDHC can support eMMC/SD/SDIO.
> > >> Add Xenon-specific properties.
> > >> Also add properties for Xenon PHY setting.
> > >>
> > >> Signed-off-by: Hu Ziji <huziji@marvell.com>
> > >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > >> ---
> > >> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 +++++++-
> > >> MAINTAINERS | 1 +-
> > >> 2 files changed, 162 insertions(+), 0 deletions(-)
> > >> create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> > >> new file mode 100644
> > >> index 000000000000..0d2d139494d3
> > >> --- /dev/null
> > >> +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> > >> @@ -0,0 +1,161 @@
> > >> +Marvell's Xenon SDHCI Controller device tree bindings
> > >> +This file documents differences between the core mmc properties
> > >> +described by mmc.txt and the properties used by the Xenon implementation.
> > >> +
> > >> +A single Xenon IP can support multiple slots.
> > >> +Each slot acts as an independent SDHC. It owns independent resources, such
> > >> +as register sets clock and PHY.
> > >> +Each slot should have an independent device tree node.
> > >> +
> > >> +Required Properties:
> > >> +- compatible: should be one of the following
> > >> + - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SOC.
> > >> + Must provide a second register area and marvell,pad-type.
> > >> + - "marvell,xenon-sdhci": For controllers on all the SOCs, other than
> > >> + Armada-3700.
> > >
> > > Need SoC specific compatible strings.
> > >
> >
> > Xenon SDHC is a common IP for all Marvell SOCs.
> > It is difficult to use a single SOC specific compatible to represent Xenon SDHC.
> > There will be so many SOC compatible strings in list if each specific SOC owns a compatible.
> > Actually only few SOCs require special properties.
> > Any suggestion please?
> >
> > >> +
> > >> +- clocks:
> > >> + Array of clocks required for SDHCI.
> > >> + Requires at least one for Xenon IP core.
> > >> + Some SOCs require additional clock for AXI bus.
> > >> +
> > >> +- clock-names:
> > >> + Array of names corresponding to clocks property.
> > >> + The input clock for Xenon IP core should be named as "core".
> > >> + The optional AXI clock should be named as "axi".
> > >
> > > When is AXI clock optional? This should be required for ?? compatible
> > > strings.
> > >
> > It is required on some SOCs.
> > I will double check if a suitable compatible string can be determined for those SOCs.
>
> Besides the core clk, berlin SoCs have one AXI clock. Usually, we have two
> solutions:
>
> solA: as current patch does, take "marvell,xenon-sdhci" as compatible string
> and make the AXI clock property optional. Usually for berlin SoCs, we don't need
> special properties.
Personally, I prefer solA: use the IP name as compatible string. This is IP
specific rather than SoC specific. The HW itself supports two clks
Thanks,
Jisheng
>
> PS: this solution is also what sdhci-pxav3.c takes
>
> solB: As Rob said, add extra SoC compatible strings, so we'll have
> something like:
>
> static const struct of_device_id sdhci_xenon_of_match[] = {
> { .compatible = "marvell,armada-3700-sdhci", },
> { .compatible = "marvell,berlin4ct-sdhci", },
> ...
> { .compatible = "marvell,berlinxxx-mmc", },
> }
>
> then we take care the AXI clk for berlin SoCs in the code.
>
>
> Which solution do you prefer?
>
> Thanks,
> Jisheng
^ permalink raw reply
* Re: [PATCH 1/2] mmc: sdhci-pci: Let devices define their own private data
From: Shyam Sundar S K @ 2016-11-11 4:12 UTC (permalink / raw)
To: Ulf Hansson
Cc: Adrian Hunter, linux-mmc, Sen, Pankaj, Agrawal, Nitesh-kumar,
Shah, Nehal-bakulchandra
In-Reply-To: <CAPDyKFpZb+2ArPs46UaLTB1jnDPjnNwCs6UZUSwRYRjDyM8sSA@mail.gmail.com>
On 11/11/2016 3:46 AM, Ulf Hansson wrote:
> On 10 November 2016 at 13:50, Shyam Sundar S K <ssundark@amd.com> wrote:
>> Let devices define their own private data to facilitate device-specific
>> operations. The size of the private structure is specified in the
>> sdhci_pci_fixes structure,then sdhci_pci_probe_slot() will allocate extra
>> space for it, and sdhci_pci_priv() can be used to get a reference to it.
>>
>> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>
> Still not Adrian as author...
Hi Ulf,
It shows Adrian as author in my git log. I have done
git commit --amend --author="Adrian Hunter <adrian.hunter@intel.com>"
before generating the patch. Here is the git log output.
commit 169dce57501d234f436ba25e2a8c51aabc6792b5
Author: Adrian Hunter <adrian.hunter@intel.com>
Date: Thu Nov 10 17:52:51 2016 +0530
mmc: sdhci-pci: Let devices define their own private data
Let devices define their own private data to facilitate device-specific
operations. The size of the private structure is specified in the
sdhci_pci_fixes structure,then sdhci_pci_probe_slot() will allocate extra
space for it, and sdhci_pci_priv() can be used to get a reference to it.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Thanks,
Shyam
>
> Kind regards
> Uffe
>
>> ---
>> drivers/mmc/host/sdhci-pci-core.c | 3 ++-
>> drivers/mmc/host/sdhci-pci.h | 7 +++++++
>> 2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
>> index 1d9e00a..782c8d2 100644
>> --- a/drivers/mmc/host/sdhci-pci-core.c
>> +++ b/drivers/mmc/host/sdhci-pci-core.c
>> @@ -1646,6 +1646,7 @@ static struct sdhci_pci_slot *sdhci_pci_probe_slot(
>> struct sdhci_pci_slot *slot;
>> struct sdhci_host *host;
>> int ret, bar = first_bar + slotno;
>> + size_t priv_size = chip->fixes ? chip->fixes->priv_size : 0;
>>
>> if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) {
>> dev_err(&pdev->dev, "BAR %d is not iomem. Aborting.\n", bar);
>> @@ -1667,7 +1668,7 @@ static struct sdhci_pci_slot *sdhci_pci_probe_slot(
>> return ERR_PTR(-ENODEV);
>> }
>>
>> - host = sdhci_alloc_host(&pdev->dev, sizeof(struct sdhci_pci_slot));
>> + host = sdhci_alloc_host(&pdev->dev, sizeof(*slot) + priv_size);
>> if (IS_ERR(host)) {
>> dev_err(&pdev->dev, "cannot allocate host\n");
>> return ERR_CAST(host);
>> diff --git a/drivers/mmc/host/sdhci-pci.h b/drivers/mmc/host/sdhci-pci.h
>> index 6bccf56..0bfd568 100644
>> --- a/drivers/mmc/host/sdhci-pci.h
>> +++ b/drivers/mmc/host/sdhci-pci.h
>> @@ -67,6 +67,7 @@ struct sdhci_pci_fixes {
>> int (*resume) (struct sdhci_pci_chip *);
>>
>> const struct sdhci_ops *ops;
>> + size_t priv_size;
>> };
>>
>> struct sdhci_pci_slot {
>> @@ -87,6 +88,7 @@ struct sdhci_pci_slot {
>> struct mmc_card *card,
>> unsigned int max_dtr, int host_drv,
>> int card_drv, int *drv_type);
>> + unsigned long private[0] ____cacheline_aligned;
>> };
>>
>> struct sdhci_pci_chip {
>> @@ -101,4 +103,9 @@ struct sdhci_pci_chip {
>> struct sdhci_pci_slot *slots[MAX_SLOTS]; /* Pointers to host slots */
>> };
>>
>> +static inline void *sdhci_pci_priv(struct sdhci_pci_slot *slot)
>> +{
>> + return (void *)slot->private;
>> +}
>> +
>> #endif /* __SDHCI_PCI_H */
>> --
>> 2.7.4
^ permalink raw reply
* Re: [PATCH 1/2] mmc: sdhci-pci: Let devices define their own private data
From: Adrian Hunter @ 2016-11-11 7:00 UTC (permalink / raw)
To: Shyam Sundar S K, Ulf Hansson
Cc: linux-mmc, Sen, Pankaj, Agrawal, Nitesh-kumar,
Shah, Nehal-bakulchandra
In-Reply-To: <d2b209d9-0d7e-fa61-49a7-cf5db4fcb372@amd.com>
On 11/11/16 06:12, Shyam Sundar S K wrote:
>
>
> On 11/11/2016 3:46 AM, Ulf Hansson wrote:
>> On 10 November 2016 at 13:50, Shyam Sundar S K <ssundark@amd.com> wrote:
>>> Let devices define their own private data to facilitate device-specific
>>> operations. The size of the private structure is specified in the
>>> sdhci_pci_fixes structure,then sdhci_pci_probe_slot() will allocate extra
>>> space for it, and sdhci_pci_priv() can be used to get a reference to it.
>>>
>>> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>>
>> Still not Adrian as author...
>
> Hi Ulf,
>
> It shows Adrian as author in my git log. I have done
>
> git commit --amend --author="Adrian Hunter <adrian.hunter@intel.com>"
>
> before generating the patch. Here is the git log output.
>
> commit 169dce57501d234f436ba25e2a8c51aabc6792b5
> Author: Adrian Hunter <adrian.hunter@intel.com>
> Date: Thu Nov 10 17:52:51 2016 +0530
>
> mmc: sdhci-pci: Let devices define their own private data
>
> Let devices define their own private data to facilitate device-specific
> operations. The size of the private structure is specified in the
> sdhci_pci_fixes structure,then sdhci_pci_probe_slot() will allocate extra
> space for it, and sdhci_pci_priv() can be used to get a reference to it.
>
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
"git am" takes the author from the "From" line of email messages. If that
is not the author, then you can add a "From" line in the message body. Read
'man git am' and please try sending patches to yourself, applying them, and
checking they are correct before sending again.
>
>
> Thanks,
> Shyam
>>
>> Kind regards
>> Uffe
>>
>>> ---
>>> drivers/mmc/host/sdhci-pci-core.c | 3 ++-
>>> drivers/mmc/host/sdhci-pci.h | 7 +++++++
>>> 2 files changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
>>> index 1d9e00a..782c8d2 100644
>>> --- a/drivers/mmc/host/sdhci-pci-core.c
>>> +++ b/drivers/mmc/host/sdhci-pci-core.c
>>> @@ -1646,6 +1646,7 @@ static struct sdhci_pci_slot *sdhci_pci_probe_slot(
>>> struct sdhci_pci_slot *slot;
>>> struct sdhci_host *host;
>>> int ret, bar = first_bar + slotno;
>>> + size_t priv_size = chip->fixes ? chip->fixes->priv_size : 0;
>>>
>>> if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) {
>>> dev_err(&pdev->dev, "BAR %d is not iomem. Aborting.\n", bar);
>>> @@ -1667,7 +1668,7 @@ static struct sdhci_pci_slot *sdhci_pci_probe_slot(
>>> return ERR_PTR(-ENODEV);
>>> }
>>>
>>> - host = sdhci_alloc_host(&pdev->dev, sizeof(struct sdhci_pci_slot));
>>> + host = sdhci_alloc_host(&pdev->dev, sizeof(*slot) + priv_size);
>>> if (IS_ERR(host)) {
>>> dev_err(&pdev->dev, "cannot allocate host\n");
>>> return ERR_CAST(host);
>>> diff --git a/drivers/mmc/host/sdhci-pci.h b/drivers/mmc/host/sdhci-pci.h
>>> index 6bccf56..0bfd568 100644
>>> --- a/drivers/mmc/host/sdhci-pci.h
>>> +++ b/drivers/mmc/host/sdhci-pci.h
>>> @@ -67,6 +67,7 @@ struct sdhci_pci_fixes {
>>> int (*resume) (struct sdhci_pci_chip *);
>>>
>>> const struct sdhci_ops *ops;
>>> + size_t priv_size;
>>> };
>>>
>>> struct sdhci_pci_slot {
>>> @@ -87,6 +88,7 @@ struct sdhci_pci_slot {
>>> struct mmc_card *card,
>>> unsigned int max_dtr, int host_drv,
>>> int card_drv, int *drv_type);
>>> + unsigned long private[0] ____cacheline_aligned;
>>> };
>>>
>>> struct sdhci_pci_chip {
>>> @@ -101,4 +103,9 @@ struct sdhci_pci_chip {
>>> struct sdhci_pci_slot *slots[MAX_SLOTS]; /* Pointers to host slots */
>>> };
>>>
>>> +static inline void *sdhci_pci_priv(struct sdhci_pci_slot *slot)
>>> +{
>>> + return (void *)slot->private;
>>> +}
>>> +
>>> #endif /* __SDHCI_PCI_H */
>>> --
>>> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v8 0/6] UHS-I SDR-104 support for sh_mobile_sdhi
From: Simon Horman @ 2016-11-11 7:20 UTC (permalink / raw)
To: Ulf Hansson
Cc: Wolfram Sang, Wolfram Sang, Magnus Damm, linux-mmc, Linux-Renesas
In-Reply-To: <CAPDyKFq-tZheBD_dqkKDeKy11r1UZGt2_NRpFYCqw0SsC-hBJw@mail.gmail.com>
On Thu, Nov 10, 2016 at 11:21:08PM +0100, Ulf Hansson wrote:
> On 10 November 2016 at 12:45, Wolfram Sang <wsa@the-dreams.de> wrote:
> > On Thu, Nov 03, 2016 at 03:15:58PM +0100, Simon Horman wrote:
> >> Hi,
> >>
> >> this series is based on work by Ai Kyuse to add UHS-I SDR-104 support for
> >> sh_mobile_sdhi. It builds on work by Shinobu Uehara, Rob Taylor, William
> >> Towle and Ian Molton, Ben Hutchings, Wolfram Sang and others to add UHS-I
> >> SDR-50 support to the same driver.
> >>
> >> It is based on the next branch of the mmc tree.
> >>
> >> To aid review the following git branch is provided:
> >> * https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/sdr104-driver-v8
> >>
> >> Overview of changes since v7:
> >> * Correct inverted logic in sh_mobile_sdhi_hw_reset
> >> * Correct value of SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN
> >>
> >> Please see http://elinux.org/Tests:SD-SDHI-SDR104 for indicative tests
> >> results.
> >
> > Successfully tested on a Lager Board with a SanDisk card and a Samsung
> > card which used to cause issues before.
> >
> > Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> >
> > Ulf, I think this series is ready to go for v4.10. All issues we know of
> > are related to pinmuxing and will be solved elsewhere. We currently have
> > hacks for that so it is quite clear the issues are not caused by this
> > series.
> >
>
> Thanks, applied for next!
>
> I did have to fix conflict and also to resolve some checkpatch
> warnings - but no worries this time!
Thanks, sorry for letting those slip through.
^ permalink raw reply
* Re: [PATCH] mmc: sdhci: remove unneeded (void *) casts in sdhci_(pltfm_)priv()
From: Adrian Hunter @ 2016-11-11 12:43 UTC (permalink / raw)
To: Masahiro Yamada, linux-mmc; +Cc: linux-kernel, Ulf Hansson
In-Reply-To: <1478784138-18594-1-git-send-email-yamada.masahiro@socionext.com>
On 10/11/16 15:22, Masahiro Yamada wrote:
> The type of host->private is (unsigned long *). No cast is needed
> to return an opaque pointer.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
>
> drivers/mmc/host/sdhci-pltfm.h | 2 +-
> drivers/mmc/host/sdhci.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
> index 3280f20..957839d 100644
> --- a/drivers/mmc/host/sdhci-pltfm.h
> +++ b/drivers/mmc/host/sdhci-pltfm.h
> @@ -106,7 +106,7 @@ extern int sdhci_pltfm_register(struct platform_device *pdev,
>
> static inline void *sdhci_pltfm_priv(struct sdhci_pltfm_host *host)
> {
> - return (void *)host->private;
> + return host->private;
> }
>
> extern const struct dev_pm_ops sdhci_pltfm_pmops;
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 766df17..9886115 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -655,7 +655,7 @@ extern struct sdhci_host *sdhci_alloc_host(struct device *dev,
>
> static inline void *sdhci_priv(struct sdhci_host *host)
> {
> - return (void *)host->private;
> + return host->private;
> }
>
> extern void sdhci_card_detect(struct sdhci_host *host);
>
^ permalink raw reply
* Re: [PATCH 2/2] mmc: sdhci-pci: Add support for HS200 tuning mode on AMD, eMMC-4.5.1
From: Adrian Hunter @ 2016-11-11 12:41 UTC (permalink / raw)
To: Shyam Sundar S K, Ulf Hansson
Cc: linux-mmc, Sen, Pankaj, Agrawal, Nitesh-kumar,
Shah, Nehal-bakulchandra
In-Reply-To: <49d59018-a294-9cea-b92c-f74935314dc8@amd.com>
On 10/11/16 14:51, Shyam Sundar S K wrote:
> This patch adds support for HS200 tuning mode on AMD eMMC-4.5.1
>
> Reviewed-by: Sen, Pankaj <Pankaj.Sen@amd.com>
> Reviewed-by: Shah, Nehal-bakulchandra <Nehal-bakulchandra.Shah@amd.com>
> Signed-off-by: S-k, Shyam-sundar <Shyam-sundar.S-k@amd.com>
> ---
> drivers/mmc/host/sdhci-pci-core.c | 178 +++++++++++++++++++++++++++++++++++++-
> 1 file changed, 177 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
> index 782c8d2..9576f82 100644
> --- a/drivers/mmc/host/sdhci-pci-core.c
> +++ b/drivers/mmc/host/sdhci-pci-core.c
> @@ -817,6 +817,171 @@ enum amd_chipset_gen {
> AMD_CHIPSET_UNKNOWN,
> };
>
> +static const struct sdhci_ops amd_sdhci_pci_ops;
> +
> +struct amd_tuning_descriptor {
> + u8 tune_around;
> + bool this_tune_ok;
> + bool last_tune_ok;
> + u8 valid_front;
> + u8 valid_window_max;
> + u8 tune_low_max;
> + u8 tune_low;
> + u8 valid_window;
> + u8 tune_result;
> +};
> +
> +static int amd_tuning_reset(struct sdhci_host *host)
> +{
> + unsigned int val;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&host->lock, flags);
> +
> + val = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> + val |= SDHCI_CTRL_PRESET_VAL_ENABLE | SDHCI_CTRL_EXEC_TUNING;
> + sdhci_writew(host, val, SDHCI_HOST_CONTROL2);
> +
> + val = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> + val &= ~SDHCI_CTRL_EXEC_TUNING;
> + sdhci_writew(host, val, SDHCI_HOST_CONTROL2);
> +
> + spin_unlock_irqrestore(&host->lock, flags);
> +
> + return 0;
> +}
> +
> +static int amd_config_tuning_phase(struct sdhci_host *host, u8 phase)
> +{
> + struct sdhci_pci_slot *slot = sdhci_priv(host);
> + struct pci_dev *pdev = slot->chip->pdev;
> + unsigned int val;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&host->lock, flags);
> +
> + pci_read_config_dword(pdev, 0xb8, &val);
> + val &= ~0x1f;
> + val |= (0x10800 | (phase << 1));
> + pci_write_config_dword(pdev, 0xb8, val);
> +
> + spin_unlock_irqrestore(&host->lock, flags);
> +
> + return 0;
> +}
> +
> +static int amd_find_good_phase(struct sdhci_host *host)
> +{
> + struct sdhci_pci_slot *slot = sdhci_priv(host);
> + struct pci_dev *pdev = slot->chip->pdev;
> + struct amd_tuning_descriptor *td = sdhci_pci_priv(slot);
> +
> + unsigned int val;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&host->lock, flags);
> +
> + if (td->this_tune_ok)
> + td->valid_front += 1;
> + if ((!td->this_tune_ok && td->last_tune_ok) ||
> + (td->tune_around == 11)) {
> + if (td->valid_window > td->valid_window_max) {
> + td->valid_window_max = td->valid_window;
> + td->tune_low_max = td->tune_low;
> + }
> + }
> + if (td->this_tune_ok && (!td->last_tune_ok))
> + td->tune_low = td->tune_around;
> + if (!td->this_tune_ok && td->last_tune_ok)
> + td->valid_window = 0;
> + else if (td->this_tune_ok)
> + td->valid_window += 1;
> +
> + td->last_tune_ok = td->this_tune_ok;
> +
> + if (td->tune_around == 11) {
> + if ((td->valid_front + td->valid_window) >
> + td->valid_window_max) {
> + if (td->valid_front > td->valid_window)
> + td->tune_result = ((td->valid_front -
> + td->valid_window) >> 1);
> + else
> + td->tune_result = td->tune_low +
> + ((td->valid_window + td->valid_front) >> 1);
> + } else {
> + td->tune_result = td->tune_low_max +
> + (td->valid_window_max >> 1);
> + }
> +
> + if (td->tune_result > 0x0b)
> + td->tune_result = 0x0b;
> +
> + pci_read_config_dword(pdev, 0xb8, &val);
> + val &= ~0x1f;
> + val |= (0x10800 | (td->tune_result << 1));
> + pci_write_config_dword(pdev, 0xb8, val);
> + }
> +
> + spin_unlock_irqrestore(&host->lock, flags);
> +
> + return 0;
> +}
> +
> +static int amd_enable_manual_tuning(struct sdhci_pci_slot *slot)
> +{
> + struct pci_dev *pdev = slot->chip->pdev;
> + unsigned int val;
> +
> + pci_read_config_dword(pdev, 0xd0, &val);
> + val &= 0xffffffcf;
> + val |= 0x30;
> + pci_write_config_dword(pdev, 0xd0, val);
> +
> + return 0;
> +}
> +
> +static int amd_execute_tuning(struct sdhci_host *host, u32 opcode)
> +{
> + struct sdhci_pci_slot *slot = sdhci_priv(host);
> + struct amd_tuning_descriptor *td = sdhci_pci_priv(slot);
> + u8 ctrl;
> +
> + amd_tuning_reset(host);
> + memset(td, 0, sizeof(struct amd_tuning_descriptor));
I didn't notice last time that you are always clearing all the values in the
tuning descriptor, so it doesn't need to be kept between calls to
amd_execute_tuning(). So it should be a local variable that you pass to the
functions that need it. Then you don't need the patch I sent at all.
Does that make sense?
> +
> + /*********************************************************************/
> + /* Enabling Software Tuning */
> + /********************************************************************/
> + /* 1. First switch the eMMC to HS200 Mode
> + * 2. Prepare the registers by using the sampling clock select
> + * 3. Send the CMD21 12 times with block length of 64 bytes
> + * 4. Everytime change the clk phase and check for CRC error
> + * (CMD and DATA),if error, soft reset the CMD and DATA line
> + * 5. Calculate the window and set the clock phase.
> + */
> +
> + for (td->tune_around = 0; td->tune_around < 12; td->tune_around++) {
> + amd_config_tuning_phase(host, td->tune_around);
> +
> + if (mmc_send_tuning(host->mmc, opcode, NULL)) {
> + td->this_tune_ok = false;
> + host->mmc->need_retune = 0;
> + mdelay(4);
> + ctrl = SDHCI_RESET_CMD | SDHCI_RESET_DATA;
> + sdhci_writeb(host, ctrl, SDHCI_SOFTWARE_RESET);
> + } else {
> + td->this_tune_ok = true;
> + }
> +
> + amd_find_good_phase(host);
> + }
> +
> + host->mmc->retune_period = 0;
> +
> + amd_enable_manual_tuning(slot);
> + return 0;
> +}
> +
> static int amd_probe(struct sdhci_pci_chip *chip)
> {
> struct pci_dev *smbus_dev;
> @@ -841,7 +1006,6 @@ static int amd_probe(struct sdhci_pci_chip *chip)
>
> if ((gen == AMD_CHIPSET_BEFORE_ML) || (gen == AMD_CHIPSET_CZ)) {
> chip->quirks2 |= SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD;
> - chip->quirks2 |= SDHCI_QUIRK2_BROKEN_HS200;
> }
>
> return 0;
> @@ -849,6 +1013,7 @@ static int amd_probe(struct sdhci_pci_chip *chip)
>
> static const struct sdhci_pci_fixes sdhci_amd = {
> .probe = amd_probe,
> + .ops = &amd_sdhci_pci_ops,
> };
>
> static const struct pci_device_id pci_ids[] = {
> @@ -1469,6 +1634,17 @@ static const struct sdhci_ops sdhci_pci_ops = {
> .select_drive_strength = sdhci_pci_select_drive_strength,
> };
>
> +static const struct sdhci_ops amd_sdhci_pci_ops = {
> + .set_clock = sdhci_set_clock,
> + .enable_dma = sdhci_pci_enable_dma,
> + .set_bus_width = sdhci_pci_set_bus_width,
> + .reset = sdhci_reset,
> + .set_uhs_signaling = sdhci_set_uhs_signaling,
> + .hw_reset = sdhci_pci_hw_reset,
> + .select_drive_strength = sdhci_pci_select_drive_strength,
> + .platform_execute_tuning = amd_execute_tuning,
> +};
> +
> /*****************************************************************************\
> * *
> * Suspend/resume *
>
^ permalink raw reply
* Re: [PATCH] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
From: Adrian Hunter @ 2016-11-11 13:15 UTC (permalink / raw)
To: Michael Walle, linux-kernel; +Cc: linux-mmc, Ulf Hansson, yangbo lu
In-Reply-To: <1478796456-30549-1-git-send-email-michael@walle.cc>
On 10/11/16 18:47, Michael Walle wrote:
> Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
> cards in __mmc_switch()") the ESDHC driver is broken:
> mmc0: Card stuck in programming state! __mmc_switch
> mmc0: error -110 whilst initialising MMC card
>
> Since this commit __mmc_switch() uses ->card_busy(), which is
> sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
> PRESENT_STATE register, specifically the DAT0 signal level bit. But the
> ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
> required to make the driver work again.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
Could add a Fixes tag here.
> ---
> drivers/mmc/host/sdhci-of-esdhc.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
> index fb71c86..243fee9 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -66,6 +66,18 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> return ret;
> }
> }
> + /*
> + * The DAT[3:0] line signal levels and the CMD line signal level is
> + * not compatible with standard SDHC reegister. Move the corresponding
reegister -> register
> + * bits around.
> + */
> + if (spec_reg == SDHCI_PRESENT_STATE) {
> + ret = value & 0xf8000000;
> + ret |= (value >> 4) & SDHCI_DATA_LVL_MASK;
> + ret |= (value << 1) & 0x01000000;
> + return ret;
SDHCI also uses other bits in SDHCI_PRESENT_STATE like SDHCI_CMD_INHIBIT and
SDHCI_DATA_INHIBIT etc, but this looks like all those bits will be zero. Is
that right?
> + }
> +
> ret = value;
> return ret;
> }
>
^ permalink raw reply
* Re: [PATCH] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
From: Michael Walle @ 2016-11-11 13:25 UTC (permalink / raw)
To: Adrian Hunter; +Cc: linux-kernel, linux-mmc, Ulf Hansson, yangbo lu
In-Reply-To: <0a5454e6-efa6-744e-4a2d-123a47e7cc40@intel.com>
Am 2016-11-11 14:15, schrieb Adrian Hunter:
> On 10/11/16 18:47, Michael Walle wrote:
>> Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
>> cards in __mmc_switch()") the ESDHC driver is broken:
>> mmc0: Card stuck in programming state! __mmc_switch
>> mmc0: error -110 whilst initialising MMC card
>>
>> Since this commit __mmc_switch() uses ->card_busy(), which is
>> sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
>> PRESENT_STATE register, specifically the DAT0 signal level bit. But
>> the
>> ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup
>> is
>> required to make the driver work again.
>>
>> Signed-off-by: Michael Walle <michael@walle.cc>
>
> Could add a Fixes tag here.
ah, right, will do :)
>
>> ---
>> drivers/mmc/host/sdhci-of-esdhc.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
>> b/drivers/mmc/host/sdhci-of-esdhc.c
>> index fb71c86..243fee9 100644
>> --- a/drivers/mmc/host/sdhci-of-esdhc.c
>> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
>> @@ -66,6 +66,18 @@ static u32 esdhc_readl_fixup(struct sdhci_host
>> *host,
>> return ret;
>> }
>> }
>> + /*
>> + * The DAT[3:0] line signal levels and the CMD line signal level is
>> + * not compatible with standard SDHC reegister. Move the
>> corresponding
>
> reegister -> register
ok
>
>> + * bits around.
>> + */
>> + if (spec_reg == SDHCI_PRESENT_STATE) {
>> + ret = value & 0xf8000000;
>> + ret |= (value >> 4) & SDHCI_DATA_LVL_MASK;
>> + ret |= (value << 1) & 0x01000000;
>> + return ret;
>
> SDHCI also uses other bits in SDHCI_PRESENT_STATE like
> SDHCI_CMD_INHIBIT and
> SDHCI_DATA_INHIBIT etc, but this looks like all those bits will be
> zero. Is
> that right?
ugh, thanks for spotting that. actually all lower bits should be taken
from the original value. Therefore the first statement should be
ret = value & ~0xf8000000;
Will post a v2 soon.
-michael
^ permalink raw reply
* [PATCH] mmc: sd: Meet alignment requirements for raw_ssr DMA
From: Paul Burton @ 2016-11-11 14:22 UTC (permalink / raw)
To: linux-mmc; +Cc: Paul Burton, Ulf Hansson
The mmc_read_ssr() function results in DMA to the raw_ssr member of
struct mmc_card, which is not guaranteed to be cache line aligned & thus
might not meet the requirements set out in Documentation/DMA-API.txt:
Warnings: Memory coherency operates at a granularity called the cache
line width. In order for memory mapped by this API to operate
correctly, the mapped region must begin exactly on a cache line
boundary and end exactly on one (to prevent two separately mapped
regions from sharing a single cache line). Since the cache line size
may not be known at compile time, the API will not enforce this
requirement. Therefore, it is recommended that driver writers who
don't take special care to determine the cache line size at run time
only map virtual regions that begin and end on page boundaries (which
are guaranteed also to be cache line boundaries).
On some systems where DMA is non-coherent this can lead to us losing
data that shares cache lines with the raw_ssr array.
Fix this by kmalloc'ing a temporary buffer to perform DMA into. kmalloc
will ensure the buffer is suitably aligned, allowing the DMA to be
performed without any loss of data.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc@vger.kernel.org
---
drivers/mmc/core/sd.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 73c762a..f6f40a1 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -223,6 +223,7 @@ static int mmc_decode_scr(struct mmc_card *card)
static int mmc_read_ssr(struct mmc_card *card)
{
unsigned int au, es, et, eo;
+ u32 *raw_ssr;
int i;
if (!(card->csd.cmdclass & CCC_APP_SPEC)) {
@@ -231,14 +232,21 @@ static int mmc_read_ssr(struct mmc_card *card)
return 0;
}
- if (mmc_app_sd_status(card, card->raw_ssr)) {
+ raw_ssr = kmalloc(sizeof(card->raw_ssr), GFP_KERNEL);
+ if (!raw_ssr)
+ return -ENOMEM;
+
+ if (mmc_app_sd_status(card, raw_ssr)) {
pr_warn("%s: problem reading SD Status register\n",
mmc_hostname(card->host));
+ kfree(raw_ssr);
return 0;
}
for (i = 0; i < 16; i++)
- card->raw_ssr[i] = be32_to_cpu(card->raw_ssr[i]);
+ card->raw_ssr[i] = be32_to_cpu(raw_ssr[i]);
+
+ kfree(raw_ssr);
/*
* UNSTUFF_BITS only works with four u32s so we have to offset the
--
2.10.2
^ permalink raw reply related
* [PATCH v2] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
From: Michael Walle @ 2016-11-11 16:04 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mmc, Ulf Hansson, Adrian Hunter, yangbo lu, Michael Walle
Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
cards in __mmc_switch()") the ESDHC driver is broken:
mmc0: Card stuck in programming state! __mmc_switch
mmc0: error -110 whilst initialising MMC card
Since this commit __mmc_switch() uses ->card_busy(), which is
sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
PRESENT_STATE register, specifically the DAT0 signal level bit. But the
ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
required to make the driver work again.
Signed-off-by: Michael Walle <michael@walle.cc>
Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in __mmc_switch()")
---
v2:
- use lower bits of the original value (that was actually a typo)
- add fixes tag
- fix typo
drivers/mmc/host/sdhci-of-esdhc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index fb71c86..f9c84bb 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -66,6 +66,18 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
return ret;
}
}
+ /*
+ * The DAT[3:0] line signal levels and the CMD line signal level is
+ * not compatible with standard SDHC register. Move the corresponding
+ * bits around.
+ */
+ if (spec_reg == SDHCI_PRESENT_STATE) {
+ ret = value & ~0xf8000000;
+ ret |= (value >> 4) & SDHCI_DATA_LVL_MASK;
+ ret |= (value << 1) & 0x01000000;
+ return ret;
+ }
+
ret = value;
return ret;
}
--
2.1.4
^ permalink raw reply related
* Re: [RFC 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio host controller sub-vended by NI
From: Julia Cartwright @ 2016-11-11 19:49 UTC (permalink / raw)
To: Zach Brown; +Cc: Adrian Hunter, ulf.hansson, linux-mmc, linux-kernel
In-Reply-To: <20161109160827.GA6138@zach-desktop>
On Wed, Nov 09, 2016 at 10:08:29AM -0600, Zach Brown wrote:
> On Wed, Nov 09, 2016 at 03:24:24PM +0200, Adrian Hunter wrote:
> > On 08/11/16 22:07, Zach Brown wrote:
> > > On NI 9037 boards the max SDIO frequency is limited by trace lengths
> > > and other layout choices. The max SDIO frequency is stored in an ACPI
> > > table, as MXFQ.
> > >
> > > The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the
> > > f_max field of the host with it.
> > >
> > > Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
> > > Reviewed-by: Jaeden Amero <jaeden.amero@ni.com>
> > > Reviewed-by: Josh Cartwright <joshc@ni.com>
> > > Signed-off-by: Zach Brown <zach.brown@ni.com>
[..]
> > > static int ni_byt_sdio_probe_slot(struct sdhci_pci_slot *slot)
> > > {
> > > +#ifdef CONFIG_ACPI
> > > + /* Get max freq from ACPI for NI hardware */
> > > + acpi_handle acpi_hdl;
> > > + acpi_status status;
> > > + struct acpi_buffer acpi_result = {
> > > + ACPI_ALLOCATE_BUFFER, NULL };
> > > + union acpi_object *acpi_buffer;
> > > + int max_freq;
> > > +
> > > + status = acpi_get_handle(ACPI_HANDLE(&slot->chip->pdev->dev), "MXFQ",
> > > + &acpi_hdl);
> >
> > Is "MXFQ" an object that has already been deployed or are you inventing it
> > now? In the latter case, did you consider device properties as an alternative?
> >
> "MXFQ" is an object that we have already deployed on some of our devices.
Unfortunately, the whole ACPI device properties table discussion was
just starting at the point where we were putting the firmware together
for these devices :(. Had we engineered the firmware today, we would
certainly have looked at using it.
Thanks,
Julia
^ permalink raw reply
* [PATCH] mmc: wbsd: implement check for dma mapping error
From: Alexey Khoroshilov @ 2016-11-11 21:42 UTC (permalink / raw)
To: Pierre Ossman, Ulf Hansson
Cc: Alexey Khoroshilov, linux-mmc, linux-kernel, ldv-project
wbsd_request_dma() does not check for dma mapping errors.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
drivers/mmc/host/wbsd.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/wbsd.c b/drivers/mmc/host/wbsd.c
index c3fd16d997ca..80a3b11f3217 100644
--- a/drivers/mmc/host/wbsd.c
+++ b/drivers/mmc/host/wbsd.c
@@ -1395,23 +1395,25 @@ static void wbsd_request_dma(struct wbsd_host *host, int dma)
*/
host->dma_addr = dma_map_single(mmc_dev(host->mmc), host->dma_buffer,
WBSD_DMA_SIZE, DMA_BIDIRECTIONAL);
+ if (dma_mapping_error(mmc_dev(host->mmc), host->dma_addr))
+ goto kfree;
/*
* ISA DMA must be aligned on a 64k basis.
*/
if ((host->dma_addr & 0xffff) != 0)
- goto kfree;
+ goto unmap;
/*
* ISA cannot access memory above 16 MB.
*/
else if (host->dma_addr >= 0x1000000)
- goto kfree;
+ goto unmap;
host->dma = dma;
return;
-kfree:
+unmap:
/*
* If we've gotten here then there is some kind of alignment bug
*/
@@ -1421,6 +1423,7 @@ static void wbsd_request_dma(struct wbsd_host *host, int dma)
WBSD_DMA_SIZE, DMA_BIDIRECTIONAL);
host->dma_addr = 0;
+kfree:
kfree(host->dma_buffer);
host->dma_buffer = NULL;
@@ -1434,7 +1437,7 @@ static void wbsd_request_dma(struct wbsd_host *host, int dma)
static void wbsd_release_dma(struct wbsd_host *host)
{
- if (host->dma_addr) {
+ if (!dma_mapping_error(mmc_dev(host->mmc), host->dma_addr)) {
dma_unmap_single(mmc_dev(host->mmc), host->dma_addr,
WBSD_DMA_SIZE, DMA_BIDIRECTIONAL);
}
--
2.7.4
^ permalink raw reply related
* RT throttling and mmc hardware interrupt timeout
From: Jamie Huang @ 2016-11-12 9:56 UTC (permalink / raw)
To: linux-mmc
Hi all:
Recently, I do test with btrfs filesystem on emmc. When I see
the message "sched: RT throttling activated", uart, network and
other peripherals are not responding.
But, the timer is ok, so I can see the following messages:
"mmc0: Timeout waiting for hardware interrupt." again and again.
Finally, "I/O error" messages are coming and the btrfs
filesystem crashes.
I think, because I use threadirqs, so most irqs are processed
in threads, yes, RT threads. When "sched: RT throttling
activated" comes out, RT threads can not be execute for some
time, so, we can see mmc interrupt timeout message.
My kernel version is 3.10.55, I know that's very old. Still,
I want to know, is there any patch for this problem? Or does
any one encounter the same problem? Thank you.
^ permalink raw reply
* Re: [PATCH 0/2] mmc: allow mmc_alloc_host() and tmio_mmc_host_alloc()
From: Greg Kroah-Hartman @ 2016-11-13 10:58 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Ulf Hansson, Adrian Hunter, Wolfram Sang, Sascha Sommer,
Johan Hovold, Sonic Zhang, devel, Russell King, Jaehoon Chung,
Chen-Yu Tsai, Pierre Ossman, Harald Welte, Alex Dubov,
adi-buildroot-devel, Michał Mirosław,
moderated list:ARM/Mediatek SoC support, Ben Dooks, Tony Olech
In-Reply-To: <CAK7LNAThxsE3QW4EdPUyxmxbnt_PPjeogi8Fox5AHkddsuu-Sg@mail.gmail.com>
On Fri, Nov 11, 2016 at 12:19:05PM +0900, Masahiro Yamada wrote:
> 2016-11-10 22:35 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> > On Thu, Nov 10, 2016 at 10:24:21PM +0900, Masahiro Yamada wrote:
> >>
> >> sdhci_alloc_host() returns an error pointer when it fails.
> >> but mmc_alloc_host() cannot.
> >>
> >> This series allow to propagate a proper error code
> >> when host-allocation fails.
> >
> > Why? What can we really do about the error except give up? Why does
> > having a explicit error value make any difference to the caller, they
> > can't do anything different, right?
>
>
> The error code is shown in the console, like
>
> probe of 5a000000.sdhc failed with error -12
>
>
> The proper error code will give a clue why the driver failed to probe.
Can't the mmc core show the reason once, and not require each and every
individual driver to show/say the same thing? All a driver needs to
know is if it worked or didn't work. Every time it didn't work, it
needs to unwind stuff and then recover properly.
The drivers do not do different things based on what type of error
happened, as they don't care at all.
So I strongly suggest leaving it simple, as it is today, as this makes
drivers simpler, they don't have to duplicate the same type of error
reporting all over the place, and it's easy to audit for.
It also makes it so that large patchsets that touch every driver like
this are not needed at all.
> > I suggest just leaving it as-is, it's simple, and you don't have to mess
> > with PTR_ERR() anywhere.
>
>
> Why?
>
> Most of driver just give up probing for any error,
> but we still do ERR_PTR()/PTR_ERR() here and there.
> I think this patch is the same pattern.
I think we need to get rid of more of the ERR_PTR() stuff, as again,
it's useless. All we need to know is an error happened, that's it.
> If a function returns NULL on failure, we need to think about
> "what is the most common failure case".
>
> Currently, MMC drivers assume -ENOMEM is the best
> fit for mmc_alloc_host(), but the assumption is fragile.
>
> Already, mmc_alloc_host() calls a function
> that returns not only -ENOMEM, but also -ENOSPC.
>
> In the future, some other failure cases might be
> added to mmc_alloc_host().
>
> Once we decide the API returns an error pointer,
> drivers just propagate the return value from the API.
> This is much more stable implementation.
Again, no, it makes more work for the different drivers, duplicates code
all over the place, and really doesn't help any user, or developer, out
at all.
Just have the mmc core properly log what went wrong, and all should be
fine.
Again, keep it simple, that's the best policy for the kernel, and
really, most software :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH 1/2] mmc: tmio: fix wrong bitmask for SDIO irqs
From: Wolfram Sang @ 2016-11-13 14:29 UTC (permalink / raw)
To: linux-mmc; +Cc: linux-renesas-soc, Simon Horman, Wolfram Sang
In-Reply-To: <20161113142912.4041-1-wsa+renesas@sang-engineering.com>
Commit 7729c7a232a953 ("mmc: tmio: Provide separate interrupt handlers")
refactored the sdio irq handler and wrongly used the mask for SD irqs,
not for SDIO irqs. This doesn't really matter in practice because both
values keep the only interrupt we are interested in. But still, this is
wrong and wants to be fixed.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/mmc/host/tmio_mmc_pio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index dbc3cb14f3321b..2b04e6e87192c7 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -741,7 +741,7 @@ static void tmio_mmc_sdio_irq(int irq, void *devid)
return;
status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
- ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdcard_irq_mask;
+ ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdio_irq_mask;
sdio_status = status & ~TMIO_SDIO_MASK_ALL;
if (pdata->flags & TMIO_MMC_SDIO_STATUS_QUIRK)
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] mmc: tmio: minor SDIO updates
From: Wolfram Sang @ 2016-11-13 14:29 UTC (permalink / raw)
To: linux-mmc; +Cc: linux-renesas-soc, Simon Horman, Wolfram Sang
Here are two small fixes I found while evaluating SDIO with UHS.
Wolfram Sang (2):
mmc: tmio: fix wrong bitmask for SDIO irqs
mmc: tmio: remove SDIO from TODO list
drivers/mmc/host/tmio_mmc_pio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 2/2] mmc: tmio: remove SDIO from TODO list
From: Wolfram Sang @ 2016-11-13 14:29 UTC (permalink / raw)
To: linux-mmc; +Cc: linux-renesas-soc, Simon Horman, Wolfram Sang
In-Reply-To: <20161113142912.4041-1-wsa+renesas@sang-engineering.com>
We surely have SDIO support by now :)
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/mmc/host/tmio_mmc_pio.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 2b04e6e87192c7..87fea67a743674 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -22,7 +22,6 @@
* TODO:
* Investigate using a workqueue for PIO transfers
* Eliminate FIXMEs
- * SDIO support
* Better Power management
* Handle MMC errors better
* double buffer support
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox