* Re: [PATCH v17 0/5] ZII RAVE platform driver
From: Pavel Machek @ 2017-12-21 9:30 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Lee Jones, Greg Kroah-Hartman, cphealy-Re5JQEeQqe8AvxtiuMwx3w,
Andy Shevchenko, Lucas Stach, Nikita Yushchenko, Guenter Roeck,
Rob Herring, Mark Rutland, Johan Hovold,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel,
Philippe Ombredanne
In-Reply-To: <20171221065118.29726-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
> Everyone:
>
> This patch series is v17 of the driver for supervisory processor found
> on RAVE series of devices from ZII. Supervisory processor is a PIC
> microcontroller connected to various electrical subsystems on RAVE
> devices whose firmware implements protocol to command/qery them.
query.
Can we please get this patch merged? We really don't want to see v34
of this patch...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v5 12/15] devicetree: bindings: Document qcom,krait-cc
From: Sricharan R @ 2017-12-21 9:28 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, rjw-LthD3rsA81gm4RdzfppkhA,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
viresh.kumar-QSEj5FYQhm4dnm+yROfE0A,
andy.gross-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171220211450.z2v54bfk53ktpfkz@rob-hp-laptop>
On 12/21/2017 2:44 AM, Rob Herring wrote:
> On Tue, Dec 19, 2017 at 09:24:57PM +0530, Sricharan R wrote:
>> From: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>
>> The Krait clock controller controls the krait CPU and the L2 clocks
>> consisting a primary mux and secondary mux. Add document for that.
>>
>> Signed-off-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> .../devicetree/bindings/clock/qcom,krait-cc.txt | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
>
> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks !!
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
--
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 v5 10/15] devicetree: bindings: Document qcom,kpss-gcc
From: Sricharan R @ 2017-12-21 9:27 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, mturquette, sboyd, linux, andy.gross, david.brown,
rjw, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-clk, linux-arm-msm, linux-soc, linux-pm
In-Reply-To: <20171220211328.wbhaxcisz6bzxxql@rob-hp-laptop>
On 12/21/2017 2:43 AM, Rob Herring wrote:
> On Tue, Dec 19, 2017 at 09:24:55PM +0530, Sricharan R wrote:
>> From: Stephen Boyd <sboyd@codeaurora.org>
>>
>> The ACC and GCC regions present in KPSSv1 contain registers to
>> control clocks and power to each Krait CPU and L2. Documenting
>> the bindings here.
>>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>> .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 7 +++++
>> .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt | 32 ++++++++++++++++++++++
>> 2 files changed, 39 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Thanks !!
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v5 05/15] devicetree: bindings: Document qcom,hfpll
From: Sricharan R @ 2017-12-21 9:26 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, devicetree, linux-pm, rjw, mturquette, sboyd, linux,
linux-kernel, david.brown, viresh.kumar, andy.gross,
linux-arm-msm, linux-soc, linux-clk, linux-arm-kernel
In-Reply-To: <20171220211147.p555i5eest3ycsbc@rob-hp-laptop>
Hi Rob,
On 12/21/2017 2:41 AM, Rob Herring wrote:
> On Tue, Dec 19, 2017 at 09:24:50PM +0530, Sricharan R wrote:
>> From: Stephen Boyd <sboyd@codeaurora.org>
>>
>> Adds bindings document for qcom,hfpll instantiated within
>> the Krait processor subsystem as separate register region.
>>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>> .../devicetree/bindings/clock/qcom,hfpll.txt | 46 ++++++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
>
> "dt-bindings: " is the preferred subject prefix. Otherwise,
>
ok, will update for the next version.
> Reviewed-by: Rob Herring <robh@kernel.org>
Thanks.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v6 00/18] dwc MSI fixes, ARTPEC-6 EP mode support, ARTPEC-7 SoC support
From: Joao Pinto @ 2017-12-21 9:23 UTC (permalink / raw)
To: Niklas Cassel, Joao Pinto
Cc: Lorenzo Pieralisi, Jingoo Han, linux-arm-kernel, linux-pci,
linux-omap, devicetree, linux-kernel, gustavo.pimentel, kishon
In-Reply-To: <20171220232251.GA27011@axis.com>
Hi Niklas,
Às 11:22 PM de 12/20/2017, Niklas Cassel escreveu:
> On Wed, Dec 20, 2017 at 07:47:41PM +0000, Joao Pinto wrote:
>>
>> Hello to all,
>>
>> Às 5:34 PM de 12/20/2017, Lorenzo Pieralisi escreveu:
>>> On Wed, Dec 20, 2017 at 12:29:21AM +0100, Niklas Cassel wrote:
>>>> This is a series that adds:
>>>> - PCI endpoint mode support in the ARTPEC-6 driver.
>>>> - ARTPEC-7 SoC support in the ARTPEC-6 driver (the SoCs are very similar).
>>>> - Small fixes for MSI in designware-ep and designware-host,
>>>> needed to get endpoint mode support working for ARTPEC-6.
>>>> - Cleanups in pci-dra7xx to better prepare for endpoint mode in other
>>>> DWC based PCIe drivers.
>>>
>>> Joao, Jingoo,
>>>
>>> Gustavo tested the series and Kishon ACK'ed the relevant patches,
>>> I need your ACKs on designware patches to queue this series for
>>> v4.16.
>>>
>>> I am away from tomorrow (noon) till beginning of January which means
>>> that either I queue this series tomorrow or at -rc6, please do
>>> chime in if you can.
>>
>> Sorry, I have been a bit tied up! Already checked each patch related to DWC.
>> Could anyone from artpec finish the revision, since there are some patches
>> related to that SoC?
>
> Thanks for looking at the patches.
>
> Thanks to everyone that has helped in any way.
>
> Since I am the maintainer for pcie-artpec6.c
> (at least according to MAINTAINERS ;)),
> I'm supposing that my sign-off will suffice.
You're right :), I didn't remember you were the maintainer.
Have a Merry Christmas.
Thanks,
Joao
>
> Regards,
> Niklas
>
^ permalink raw reply
* Re: [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board
From: Linus Walleij @ 2017-12-21 9:18 UTC (permalink / raw)
To: Alexandre Torgue
Cc: Ludovic Barre, Russell King, Rob Herring, Arnd Bergmann,
Maxime Coquelin, Gerald Baeza, Linux ARM,
linux-kernel@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <27a339f7-33a7-eb73-27fe-9927838729d6@st.com>
On Wed, Dec 20, 2017 at 10:19 AM, Alexandre Torgue
<alexandre.torgue@st.com> wrote:
> On 12/20/2017 08:44 AM, Linus Walleij wrote:
>> gpio-line-names = "foo", "bar" ...;
>>
>> See for example
>> arch/arm/boot/dts/bcm2835-rpi-a.dts
>> arch/arm/boot/dts/ste-snowball.dts
(...)
>
> It looks like useful for pins used as gpio line. Are you saying that we also
> have to describe pins used as Alternate Function ?
No. The use of the names is up to the platform maintainer (you),
leaving a blank string for non-GPIO lines is just fine.
Some platforms add the name of the actual function used by the
line on the design, if it is not GPIO, sometimes something in
brachets like "[i2c0-SDA]" that says what it is used for and explains
why you can't use it for GPIO on this setup.
But just leaving it blank is just as good.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 11/12] mmc: sdhci-omap: Add support for MMC/SD controller in k2g SoC
From: Adrian Hunter @ 2017-12-21 9:15 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Ulf Hansson, Rob Herring, Tony Lindgren
Cc: Mark Rutland, Russell King, linux-mmc, devicetree, linux-kernel,
linux-omap, linux-arm-kernel, nsekhar
In-Reply-To: <20171214130941.26666-12-kishon@ti.com>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> Add support for the new compatible added specifically to support
> k2g's MMC/SD controller.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-omap.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index cddc3ad1331f..5e81e29383d9 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -767,6 +767,10 @@ static const struct sdhci_pltfm_data sdhci_omap_pdata = {
> .ops = &sdhci_omap_ops,
> };
>
> +static const struct sdhci_omap_data k2g_data = {
> + .offset = 0x200,
> +};
> +
> static const struct sdhci_omap_data dra7_data = {
> .offset = 0x200,
> .flags = SDHCI_OMAP_REQUIRE_IODELAY,
> @@ -774,6 +778,7 @@ static const struct sdhci_omap_data dra7_data = {
>
> static const struct of_device_id omap_sdhci_match[] = {
> { .compatible = "ti,dra7-sdhci", .data = &dra7_data },
> + { .compatible = "ti,k2g-sdhci", .data = &k2g_data },
> {},
> };
> MODULE_DEVICE_TABLE(of, omap_sdhci_match);
> @@ -882,6 +887,7 @@ static int sdhci_omap_probe(struct platform_device *pdev)
> int ret;
> u32 offset;
> struct device *dev = &pdev->dev;
> + struct device_node *node = dev->of_node;
> struct sdhci_host *host;
> struct sdhci_pltfm_host *pltfm_host;
> struct sdhci_omap_host *omap_host;
> @@ -908,6 +914,9 @@ static int sdhci_omap_probe(struct platform_device *pdev)
> return PTR_ERR(host);
> }
>
> + if (of_device_is_compatible(node, "ti,k2g-sdhci"))
> + host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
> +
> pltfm_host = sdhci_priv(host);
> omap_host = sdhci_pltfm_priv(pltfm_host);
> omap_host->host = host;
>
^ permalink raw reply
* Re: [PATCH 08/12] mmc: sdhci-omap: Add support to override f_max and iodelay from pdata
From: Adrian Hunter @ 2017-12-21 9:13 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Ulf Hansson, Rob Herring, Tony Lindgren
Cc: Mark Rutland, Russell King, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nsekhar-l0cyMroinI0
In-Reply-To: <20171214130941.26666-9-kishon-l0cyMroinI0@public.gmane.org>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> DRA74x EVM Rev H EVM comes with revision 2.0 silicon. However, earlier
> versions of EVM can come with either revision 1.1 or revision 1.0 of
> silicon.
>
> The device-tree file is written to support rev 2.0 of silicon.
> pdata-quirks are used to then override the settings needed for
> PG 1.1 silicon.
>
> PG 1.1 silicon has limitations w.r.t frequencies at which MMC1/2/3
> can operate as well as different IOdelay numbers.
>
> Add support in sdhci-omap driver to get platform data if available
> (added using pdata quirks) and override the data (max-frequency and
> iodelay data) obtained from device tree.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> ---
> drivers/mmc/host/sdhci-omap.c | 17 ++++++++++++++++
> include/linux/platform_data/sdhci-omap.h | 35 ++++++++++++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
> create mode 100644 include/linux/platform_data/sdhci-omap.h
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index 6dee275b2e57..cddc3ad1331f 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -22,6 +22,7 @@
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> +#include <linux/platform_data/sdhci-omap.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> #include <linux/regulator/consumer.h>
> @@ -102,6 +103,7 @@ struct sdhci_omap_data {
> };
>
> struct sdhci_omap_host {
> + char *version;
> void __iomem *base;
> struct device *dev;
> struct regulator *pbias;
> @@ -781,11 +783,18 @@ static struct pinctrl_state
> u32 *caps, u32 capmask)
> {
> struct device *dev = omap_host->dev;
> + char *version = omap_host->version;
> struct pinctrl_state *pinctrl_state = ERR_PTR(-ENODEV);
> + char str[20];
>
> if (!(*caps & capmask))
> goto ret;
>
> + if (version) {
> + sprintf(str, "%s-%s", mode, version);
snprintf please
> + pinctrl_state = pinctrl_lookup_state(omap_host->pinctrl, str);
Doesn't look like this 'pinctrl_state' is used?
> + }
> +
> pinctrl_state = pinctrl_lookup_state(omap_host->pinctrl, mode);
> if (IS_ERR(pinctrl_state)) {
> dev_err(dev, "no pinctrl state for %s mode", mode);
> @@ -879,6 +888,7 @@ static int sdhci_omap_probe(struct platform_device *pdev)
> struct mmc_host *mmc;
> const struct of_device_id *match;
> struct sdhci_omap_data *data;
> + struct sdhci_omap_platform_data *platform_data;
>
> match = of_match_device(omap_sdhci_match, dev);
> if (!match)
> @@ -913,6 +923,13 @@ static int sdhci_omap_probe(struct platform_device *pdev)
> if (ret)
> goto err_pltfm_free;
>
> + platform_data = dev_get_platdata(dev);
> + if (platform_data) {
> + omap_host->version = platform_data->version;
> + if (platform_data->max_freq)
> + mmc->f_max = platform_data->max_freq;
> + }
> +
> pltfm_host->clk = devm_clk_get(dev, "fck");
> if (IS_ERR(pltfm_host->clk)) {
> ret = PTR_ERR(pltfm_host->clk);
> diff --git a/include/linux/platform_data/sdhci-omap.h b/include/linux/platform_data/sdhci-omap.h
> new file mode 100644
> index 000000000000..a46e1240956a
> --- /dev/null
> +++ b/include/linux/platform_data/sdhci-omap.h
> @@ -0,0 +1,35 @@
> +/**
> + * SDHCI Controller Platform Data for TI's OMAP SoCs
> + *
> + * Copyright (C) 2017 Texas Instruments
> + * Author: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 of
> + * the License as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +#ifndef __SDHCI_OMAP_PDATA_H__
> +#define __SDHCI_OMAP_PDATA_H__
> +
> +struct sdhci_omap_platform_data {
> + const char *name;
> +
> + /*
> + * set if your board has components or wiring that limits the
> + * maximum frequency on the MMC bus
> + */
> + unsigned int max_freq;
> +
> + /* string specifying a particular variant of hardware */
> + char *version;
> +};
> +
> +#endif
>
--
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 07/12] mmc: sdhci_omap: Fix sdhci-omap quirks
From: Adrian Hunter @ 2017-12-21 9:12 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Ulf Hansson, Rob Herring, Tony Lindgren
Cc: Mark Rutland, Russell King, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nsekhar-l0cyMroinI0
In-Reply-To: <20171214130941.26666-8-kishon-l0cyMroinI0@public.gmane.org>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> Remove SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk as gpio card detection
> is supported in sdhci-omap.
SDHCI_QUIRK_BROKEN_CARD_DETECTION is for native card detection not gpio card
detection.
>
> Add SDHCI_QUIRK2_PRESET_VALUE_BROKEN quirk as setting preset values loads
> incorrect CLKD values (for UHS modes).
>
> Remove SDHCI_QUIRK2_NO_1_8_V quirk as sdhci-omap now supports UHS modes.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> ---
> drivers/mmc/host/sdhci-omap.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index 594e41200d8a..6dee275b2e57 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -755,13 +755,12 @@ static int sdhci_omap_set_capabilities(struct sdhci_omap_host *omap_host)
> }
>
> static const struct sdhci_pltfm_data sdhci_omap_pdata = {
> - .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
> - SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> + .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN |
> SDHCI_QUIRK_NO_HISPD_BIT |
> SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC,
> - .quirks2 = SDHCI_QUIRK2_NO_1_8_V |
> - SDHCI_QUIRK2_ACMD23_BROKEN |
> + .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN |
> + SDHCI_QUIRK2_PRESET_VALUE_BROKEN |
> SDHCI_QUIRK2_RSP_136_HAS_CRC,
> .ops = &sdhci_omap_ops,
> };
>
--
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 05/12] mmc: sdhci-omap: Workaround for Errata i802
From: Adrian Hunter @ 2017-12-21 9:09 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Ulf Hansson, Rob Herring, Tony Lindgren
Cc: Mark Rutland, Russell King, linux-mmc, devicetree, linux-kernel,
linux-omap, linux-arm-kernel, nsekhar
In-Reply-To: <20171214130941.26666-6-kishon@ti.com>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> Errata i802 in AM572x Sitara Processors Silicon Revision 2.0, 1.1
> (SPRZ429K July 2014–Revised March 2017 [1]) mentions
> DCRC error interrupts (MMCHS_STAT[21] DCRC=0x1) can occur
> during the tuning procedure and it has to be disabled during the
> tuning procedure Implement workaround for Errata i802 here..
>
> [1] -> http://www.ti.com/lit/er/sprz429k/sprz429k.pdf
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-omap.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index df8a0a472996..b20f4c79ccc6 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -266,6 +266,7 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode)
> struct sdhci_pltfm_host *pltfm_host;
> struct sdhci_omap_host *omap_host;
> struct device *dev;
> + u32 ier = host->ier;
>
> pltfm_host = sdhci_priv(host);
> omap_host = sdhci_pltfm_priv(pltfm_host);
> @@ -283,6 +284,16 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode)
> reg |= DLL_SWT;
> sdhci_omap_writel(omap_host, SDHCI_OMAP_DLL, reg);
>
> + /*
> + * OMAP5/DRA74X/DRA72x Errata i802:
> + * DCRC error interrupts (MMCHS_STAT[21] DCRC=0x1) can occur
> + * during the tuning procedure. So disable it during the
> + * tuning procedure.
> + */
> + ier &= ~SDHCI_INT_DATA_CRC;
> + sdhci_writel(host, ier, SDHCI_INT_ENABLE);
> + sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
> +
> while (phase_delay <= MAX_PHASE_DELAY) {
> sdhci_omap_set_dll(omap_host, phase_delay);
>
> @@ -328,6 +339,8 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode)
>
> ret:
> sdhci_reset(host, SDHCI_RESET_CMD | SDHCI_RESET_DATA);
> + sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
> + sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
> return ret;
> }
>
>
^ permalink raw reply
* Re: [PATCH 04/12] mmc: sdhci-omap: Add tuning support
From: Adrian Hunter @ 2017-12-21 9:09 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Ulf Hansson, Rob Herring, Tony Lindgren
Cc: Mark Rutland, Russell King, linux-mmc, devicetree, linux-kernel,
linux-omap, linux-arm-kernel, nsekhar
In-Reply-To: <20171214130941.26666-5-kishon@ti.com>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> MMC tuning procedure is required to support SD card
> UHS1-SDR104 mode and EMMC HS200 mode.
>
> SDR104/HS200 DLL Tuning Procedure for AM572x platform is mentioned
> in Figure 25-51. SDR104/HS200 DLL Tuning Procedure of
> AM572x Sitara Processors Silicon Revision 2.0, 1.1 TRM
> (SPRUHZ6I - October 2014–Revised April 2017 [1]).
>
> The tuning function sdhci_omap_execute_tuning() will only be
> called by the MMC/SD core if the corresponding speed modes
> are supported by the OMAP silicon which is set in the mmc
> host "caps" field.
>
> [1] -> http://www.ti.com/lit/ug/spruhz6i/spruhz6i.pdf
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Apart from 1 minor comment below:
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-omap.c | 130 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 130 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index 8f7239e2edc2..df8a0a472996 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -37,6 +37,13 @@
> #define CON_INIT BIT(1)
> #define CON_OD BIT(0)
>
> +#define SDHCI_OMAP_DLL 0x0134
> +#define DLL_SWT BIT(20)
> +#define DLL_FORCE_SR_C_SHIFT 13
> +#define DLL_FORCE_SR_C_MASK (0x7f << DLL_FORCE_SR_C_SHIFT)
> +#define DLL_FORCE_VALUE BIT(12)
> +#define DLL_CALIB BIT(1)
> +
> #define SDHCI_OMAP_CMD 0x20c
>
> #define SDHCI_OMAP_PSTATE 0x0224
> @@ -66,12 +73,16 @@
>
> #define SDHCI_OMAP_AC12 0x23c
> #define AC12_V1V8_SIGEN BIT(19)
> +#define AC12_SCLK_SEL BIT(23)
>
> #define SDHCI_OMAP_CAPA 0x240
> #define CAPA_VS33 BIT(24)
> #define CAPA_VS30 BIT(25)
> #define CAPA_VS18 BIT(26)
>
> +#define SDHCI_OMAP_CAPA2 0x0244
> +#define CAPA2_TSDR50 BIT(13)
> +
> #define SDHCI_OMAP_TIMEOUT 1 /* 1 msec */
>
> #define SYSCTL_CLKD_MAX 0x3FF
> @@ -80,6 +91,8 @@
> #define IOV_3V0 3000000 /* 300000 uV */
> #define IOV_3V3 3300000 /* 330000 uV */
>
> +#define MAX_PHASE_DELAY 0x7C
> +
> struct sdhci_omap_data {
> u32 offset;
> };
> @@ -204,6 +217,120 @@ static void sdhci_omap_conf_bus_power(struct sdhci_omap_host *omap_host,
> }
> }
>
> +static inline void sdhci_omap_set_dll(struct sdhci_omap_host *omap_host,
> + int count)
> +{
> + int i;
> + u32 reg;
> +
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_DLL);
> + reg |= DLL_FORCE_VALUE;
> + reg &= ~DLL_FORCE_SR_C_MASK;
> + reg |= (count << DLL_FORCE_SR_C_SHIFT);
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_DLL, reg);
> +
> + reg |= DLL_CALIB;
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_DLL, reg);
> + for (i = 0; i < 1000; i++) {
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_DLL);
> + if (reg & DLL_CALIB)
> + break;
> + }
> + reg &= ~DLL_CALIB;
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_DLL, reg);
> +}
> +
> +static void sdhci_omap_disable_tuning(struct sdhci_omap_host *omap_host)
> +{
> + u32 reg;
> +
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_AC12);
> + reg &= ~AC12_SCLK_SEL;
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_AC12, reg);
> +
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_DLL);
> + reg &= ~(DLL_FORCE_VALUE | DLL_SWT);
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_DLL, reg);
> +}
> +
> +static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode)
> +{
> + u32 reg;
> + int ret = 0;
> + u8 cur_match, prev_match = 0;
> + u32 phase_delay = 0;
> + u32 start_window = 0, max_window = 0;
> + u32 length = 0, max_len = 0;
> + struct mmc_ios *ios = &mmc->ios;
> + struct sdhci_host *host = mmc_priv(mmc);
> + struct sdhci_pltfm_host *pltfm_host;
> + struct sdhci_omap_host *omap_host;
> + struct device *dev;
> +
> + pltfm_host = sdhci_priv(host);
> + omap_host = sdhci_pltfm_priv(pltfm_host);
> + dev = omap_host->dev;
These initializations can be combined with the declarations. Also try to
arrange local variable declaration lines in descending order of length e.g.
struct sdhci_host *host = mmc_priv(mmc);
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
struct device *dev = omap_host->dev;
struct mmc_ios *ios = &mmc->ios;
u32 start_window = 0, max_window = 0;
u8 cur_match, prev_match = 0;
u32 length = 0, max_len = 0;
u32 phase_delay = 0;
int ret = 0;
u32 reg;
> +
> + /* clock tuning is not needed for upto 52MHz */
> + if (ios->clock <= 52000000)
> + return 0;
> +
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_CAPA2);
> + if (ios->timing == MMC_TIMING_UHS_SDR50 && !(reg & CAPA2_TSDR50))
> + return 0;
> +
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_DLL);
> + reg |= DLL_SWT;
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_DLL, reg);
> +
> + while (phase_delay <= MAX_PHASE_DELAY) {
> + sdhci_omap_set_dll(omap_host, phase_delay);
> +
> + cur_match = !mmc_send_tuning(mmc, opcode, NULL);
> + if (cur_match) {
> + if (prev_match) {
> + length++;
> + } else {
> + start_window = phase_delay;
> + length = 1;
> + }
> + }
> +
> + if (length > max_len) {
> + max_window = start_window;
> + max_len = length;
> + }
> +
> + prev_match = cur_match;
> + phase_delay += 4;
> + }
> +
> + if (!max_len) {
> + dev_err(dev, "Unable to find match\n");
> + ret = -EIO;
> + goto tuning_error;
> + }
> +
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_AC12);
> + if (!(reg & AC12_SCLK_SEL)) {
> + ret = -EIO;
> + goto tuning_error;
> + }
> +
> + phase_delay = max_window + 4 * (max_len >> 1);
> + sdhci_omap_set_dll(omap_host, phase_delay);
> +
> + goto ret;
> +
> +tuning_error:
> + dev_err(dev, "Tuning failed\n");
> + sdhci_omap_disable_tuning(omap_host);
> +
> +ret:
> + sdhci_reset(host, SDHCI_RESET_CMD | SDHCI_RESET_DATA);
> + return ret;
> +}
> +
> static int sdhci_omap_card_busy(struct mmc_host *mmc)
> {
> int i;
> @@ -312,6 +439,8 @@ static int sdhci_omap_start_signal_voltage_switch(struct mmc_host *mmc,
> static void sdhci_omap_set_power_mode(struct sdhci_omap_host *omap_host,
> u8 power_mode)
> {
> + if (omap_host->bus_mode == MMC_POWER_OFF)
> + sdhci_omap_disable_tuning(omap_host);
> omap_host->power_mode = power_mode;
> }
>
> @@ -648,6 +777,7 @@ static int sdhci_omap_probe(struct platform_device *pdev)
> sdhci_omap_start_signal_voltage_switch;
> host->mmc_host_ops.set_ios = sdhci_omap_set_ios;
> host->mmc_host_ops.card_busy = sdhci_omap_card_busy;
> + host->mmc_host_ops.execute_tuning = sdhci_omap_execute_tuning;
>
> sdhci_read_caps(host);
> host->caps |= SDHCI_CAN_DO_ADMA2;
>
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Andrew Lunn @ 2017-12-21 9:06 UTC (permalink / raw)
To: Russell King
Cc: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo, Stefan Agner,
Florian Fainelli, Linus Walleij,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1eRnWr-0006VS-1m-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
On Wed, Dec 20, 2017 at 11:12:01PM +0000, Russell King wrote:
> The 88e1545 PHY has its interrupts wired to the VF610, so we might as
> well use them.
>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> ---
> This is certainly not correct, as all PHYs on this device share the
> same interrupt line, but we can't specify the pinmux settings
> individually on each PHY. How should this be handled?
Hi Russell
You could put it as a hog on the gpio controller node. However, i
don't think that is much better.
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
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] devicetree: Add video bus switch
From: Sakari Ailus @ 2017-12-21 9:05 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Pavel Machek, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
sre-DgEjT+Ai2ygdnm+yROfE0A, pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA, galak-sgV2jX0FEOL9JmXXK+q4OQ,
mchehab-JPH+aEBZ4P+UEJcrhfAQsw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <75694885.3PuLWzx4qN@avalon>
On Wed, Dec 20, 2017 at 07:54:12PM +0200, Laurent Pinchart wrote:
> Hi Pavel,
>
> On Saturday, 4 February 2017 23:56:10 EET Pavel Machek wrote:
> > Hi!
> >
> > >>>> +Required properties
> > >>>> +===================
> > >>>> +
> > >>>> +compatible : must contain "video-bus-switch"
> > >>>
> > >>> How generic is this? Should we have e.g. nokia,video-bus-switch? And
> > >>> if so, change the file name accordingly.
> > >>
> > >> Generic for "single GPIO controls the switch", AFAICT. But that should
> > >> be common enough...
> > >
> > > Um, yes. Then... how about: video-bus-switch-gpio? No Nokia prefix.
> >
> > Ok, done. I also fixed the english a bit.
> >
> > >>>> +reg : The interface:
> > >>>> + 0 - port for image signal processor
> > >>>> + 1 - port for first camera sensor
> > >>>> + 2 - port for second camera sensor
> > >>>
> > >>> I'd say this must be pretty much specific to the one in N900. You
> > >>> could have more ports. Or you could say that ports beyond 0 are
> > >>> camera sensors. I guess this is good enough for now though, it can be
> > >>> changed later on with the source if a need arises.
> > >>
> > >> Well, I'd say that selecting between two sensors is going to be the
> > >> common case. If someone needs more than two, it will no longer be
> > >> simple GPIO, so we'll have some fixing to do.
> > >
> > > It could be two GPIOs --- that's how the GPIO I2C mux works.
> > >
> > > But I'd be surprised if someone ever uses something like that
> > > again. ;-)
> >
> > I'd say.. lets handle that when we see hardware like that.
> >
> > >>> Btw. was it still considered a problem that the endpoint properties
> > >>> for the sensors can be different? With the g_routing() pad op which is
> > >>> to be added, the ISP driver (should actually go to a framework
> > >>> somewhere) could parse the graph and find the proper endpoint there.
> > >>
> > >> I don't know about g_routing. I added g_endpoint_config method that
> > >> passes the configuration, and that seems to work for me.
> > >>
> > >> I don't see g_routing in next-20170201 . Is there place to look?
> > >
> > > I think there was a patch by Laurent to LMML quite some time ago. I
> > > suppose that set will be repicked soonish.
> > >
> > > I don't really object using g_endpoint_config() as a temporary solution;
> > > I'd like to have Laurent's opinion on that though. Another option is to
> > > wait, but we've already waited a looong time (as in total).
> >
> > Laurent, do you have some input here? We have simple "2 cameras
> > connected to one signal processor" situation here. We need some way of
> > passing endpoint configuration from the sensors through the switch. I
> > did this:
>
> Could you give me a bit more information about the platform you're targeting:
> how the switch is connected, what kind of switch it is, and what endpoint
> configuration data you need ?
>
> > >> @@ -415,6 +416,8 @@ struct v4l2_subdev_video_ops {
> > >> const struct v4l2_mbus_config *cfg);
> > >> int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
> > >> unsigned int *size);
> > >> + int (*g_endpoint_config)(struct v4l2_subdev *sd,
> > >> + struct v4l2_of_endpoint *cfg);
> >
> > Google of g_routing tells me:
> >
> > 9) Highly reconfigurable hardware - Julien Beraud
> >
> > - 44 sub-devices connected with an interconnect.
> > - As long as formats match, any sub-device could be connected to any
> > - other sub-device through a link.
> > - The result is 44 * 44 links at worst.
> > - A switch sub-device proposed as the solution to model the
> > - interconnect. The sub-devices are connected to the switch
> > - sub-devices through the hardware links that connect to the
> > - interconnect.
> > - The switch would be controlled through new IOCTLs S_ROUTING and
> > - G_ROUTING.
> > - Patches available:
> > http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
> >
> > but the patches are from 2005. So I guess I'll need some guidance here...
>
> You made me feel very old for a moment. The patches are from 2015 :-)
There are up-to-date patches here:
<URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=vc>
--
Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@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
* Re: [PATCH v9 1/2] of: documentation: add bindings documentation for TS-4600
From: Shawn Guo @ 2017-12-21 9:05 UTC (permalink / raw)
To: Sebastien Bourdelin
Cc: linux-kernel, linux-arm-kernel, kernel, fabio.estevam, kernel,
linux, mark.rutland, robh+dt, devicetree, mark, kris
In-Reply-To: <20171207171118.5448-1-sebastien.bourdelin@savoirfairelinux.com>
On Thu, Dec 07, 2017 at 12:11:17PM -0500, Sebastien Bourdelin wrote:
> This adds the documentation for the TS-4600 by Technologic Systems.
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
> Acked-by: Rob Herring <robh@kernel.org>
Applied both, thanks.
^ permalink raw reply
* Re: [PATCH v4 2/2] ARM: dts: TS-7970: add basic device tree
From: Shawn Guo @ 2017-12-21 9:02 UTC (permalink / raw)
To: Sebastien Bourdelin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
fabio.estevam-3arQi8VN3Tc, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
mark-L1vi/lXTdtvnC/t2CciAbw, kris-L1vi/lXTdtvnC/t2CciAbw
In-Reply-To: <20171207160550.2782-2-sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
On Thu, Dec 07, 2017 at 11:05:50AM -0500, Sebastien Bourdelin wrote:
> These device trees add support for TS-7970 by Technologic Systems.
>
> More details here:
> https://wiki.embeddedarm.com/wiki/TS-7970
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
Applied both, thanks.
--
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 3/4] ARM: dts: vf610-zii-dev-rev-b: add PHYs for switch2
From: Andrew Lunn @ 2017-12-21 9:01 UTC (permalink / raw)
To: Russell King
Cc: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo, Stefan Agner,
Florian Fainelli, Linus Walleij,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1eRnWl-0006VL-TL-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
On Wed, Dec 20, 2017 at 11:11:55PM +0000, Russell King wrote:
> Switch 2 has an 88e1545 PHY behind it, which is a quad PHY. Only the
> first three PHYs are used, the remaining PHY is unused. When we wire
> up the SFF sockets in a later commit, the omission of this causes the
> fourth PHY to be used for port 3. Specifying the PHYs in DT avoids
> the auto-probing of the bus, and discovery of this PHY.
>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
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 03/12] mmc: sdhci-omap: Add custom set_uhs_signaling sdhci_host ops
From: Adrian Hunter @ 2017-12-21 9:01 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Ulf Hansson, Rob Herring, Tony Lindgren
Cc: Mark Rutland, Russell King, linux-mmc, devicetree, linux-kernel,
linux-omap, linux-arm-kernel, nsekhar
In-Reply-To: <20171214130941.26666-4-kishon@ti.com>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> UHS-1 DDR50 and MMC DDR52 mode require DDR bit to be
> set in the configuration register (MMCHS_CON). Add
> sdhci-omap specific set_uhs_signaling ops to set
> this bit. Also while setting the UHSMS bit, clock should be
> disabled.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Apart from 1 minor comment below:
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-omap.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index defe4eac020d..8f7239e2edc2 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -31,6 +31,7 @@
> #define SDHCI_OMAP_CON 0x12c
> #define CON_DW8 BIT(5)
> #define CON_DMA_MASTER BIT(20)
> +#define CON_DDR BIT(19)
> #define CON_CLKEXTFREE BIT(16)
> #define CON_PADEN BIT(15)
> #define CON_INIT BIT(1)
> @@ -93,6 +94,9 @@ struct sdhci_omap_host {
> u8 power_mode;
> };
>
> +static void sdhci_omap_start_clock(struct sdhci_omap_host *omap_host);
> +static void sdhci_omap_stop_clock(struct sdhci_omap_host *omap_host);
These forward declarations aren't needed are they.
> +
> static inline u32 sdhci_omap_readl(struct sdhci_omap_host *host,
> unsigned int offset)
> {
> @@ -471,6 +475,26 @@ static void sdhci_omap_init_74_clocks(struct sdhci_host *host, u8 power_mode)
> enable_irq(host->irq);
> }
>
> +static void sdhci_omap_set_uhs_signaling(struct sdhci_host *host,
> + unsigned int timing)
> +{
> + u32 reg;
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
> +
> + sdhci_omap_stop_clock(omap_host);
> +
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_CON);
> + if (timing == MMC_TIMING_UHS_DDR50 || timing == MMC_TIMING_MMC_DDR52)
> + reg |= CON_DDR;
> + else
> + reg &= ~CON_DDR;
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_CON, reg);
> +
> + sdhci_set_uhs_signaling(host, timing);
> + sdhci_omap_start_clock(omap_host);
> +}
> +
> static struct sdhci_ops sdhci_omap_ops = {
> .set_clock = sdhci_omap_set_clock,
> .set_power = sdhci_omap_set_power,
> @@ -480,7 +504,7 @@ static struct sdhci_ops sdhci_omap_ops = {
> .set_bus_width = sdhci_omap_set_bus_width,
> .platform_send_init_74_clocks = sdhci_omap_init_74_clocks,
> .reset = sdhci_reset,
> - .set_uhs_signaling = sdhci_set_uhs_signaling,
> + .set_uhs_signaling = sdhci_omap_set_uhs_signaling,
> };
>
> static int sdhci_omap_set_capabilities(struct sdhci_omap_host *omap_host)
>
^ permalink raw reply
* Re: [PATCH 2/4] ARM: dts: vf610-zii-dev-rev-b: fix interrupt for GPIO expander
From: Andrew Lunn @ 2017-12-21 9:00 UTC (permalink / raw)
To: Russell King
Cc: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo, Stefan Agner,
Florian Fainelli, Linus Walleij,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1eRnWg-0006VE-GI-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
On Wed, Dec 20, 2017 at 11:11:50PM +0000, Russell King wrote:
> The interrupt specification for the GPIO expander is wrong - the
> expander is wired to PTB28, which is GPIO98. GPIO98 is on gpio chip
> 3, not 2.
Hi Russell
I'd also seen this interrupt storm. The whole interrupt architecture
for this expander does not look so good, so i just assumed it was a
design issue. Instead, it was me who probably made a typ0 :-(
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
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 02/12] mmc: sdhci-omap: Add card_busy host ops
From: Adrian Hunter @ 2017-12-21 8:59 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Ulf Hansson, Rob Herring, Tony Lindgren
Cc: Mark Rutland, Russell King, linux-mmc, devicetree, linux-kernel,
linux-omap, linux-arm-kernel, nsekhar
In-Reply-To: <20171214130941.26666-3-kishon@ti.com>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> card_busy ops is used by mmc core in
> 1) mmc_set_uhs_voltage to verify voltage switch
> 2) __mmc_start_request/mmc_poll_for_busy to check the card busy status
>
> While only DAT0 can be used to check the card busy status (in '2' above),
> CMD and DAT[0..3] is used to verify voltage switch (in '1' above).
>
> The voltage switching sequence for AM572x platform is mentioned
> in Figure 25-48. eMMC/SD/SDIO Power Switching Procedure of
> AM572x Sitara Processors Silicon Revision 2.0, 1.1 TRM
> (SPRUHZ6I - October 2014–Revised April 2017 [1]).
>
> Add card_busy host ops in sdhci_omap that checks for both CMD and
> DAT[0..3]. card_busy here returns true if one of CMD and DAT[0..3] is
> low though during voltage switch sequence all of CMD and DAT[0..3] has
> to be low (however haven't observed a case where some DAT lines are low
> and some are high).
Isn't it better to check DAT0 only since that is all that is defined for 'busy'.
>
> In the voltage switching sequence, CLKEXTFREE bit in MMCHS_CON
> should also be set after switching to 1.8v which is also taken
> care in the card_busy ops.
>
> [1] -> http://www.ti.com/lit/ug/spruhz6i/spruhz6i.pdf
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/mmc/host/sdhci-omap.c | 62 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index 96985786cadf..defe4eac020d 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -31,11 +31,20 @@
> #define SDHCI_OMAP_CON 0x12c
> #define CON_DW8 BIT(5)
> #define CON_DMA_MASTER BIT(20)
> +#define CON_CLKEXTFREE BIT(16)
> +#define CON_PADEN BIT(15)
> #define CON_INIT BIT(1)
> #define CON_OD BIT(0)
>
> #define SDHCI_OMAP_CMD 0x20c
>
> +#define SDHCI_OMAP_PSTATE 0x0224
> +#define PSTATE_CLEV BIT(24)
> +#define PSTATE_DLEV_SHIFT 20
> +#define PSTATE_DLEV_DAT(x) (1 << (PSTATE_DLEV_SHIFT + (x)))
> +#define PSTATE_DLEV (PSTATE_DLEV_DAT(0) | PSTATE_DLEV_DAT(1) | \
> + PSTATE_DLEV_DAT(2) | PSTATE_DLEV_DAT(3))
> +
> #define SDHCI_OMAP_HCTL 0x228
> #define HCTL_SDBP BIT(8)
> #define HCTL_SDVS_SHIFT 9
> @@ -191,6 +200,58 @@ static void sdhci_omap_conf_bus_power(struct sdhci_omap_host *omap_host,
> }
> }
>
> +static int sdhci_omap_card_busy(struct mmc_host *mmc)
> +{
> + int i;
> + u32 reg, ac12;
> + int ret = true;
> + struct sdhci_host *host = mmc_priv(mmc);
> + struct sdhci_pltfm_host *pltfm_host;
> + struct sdhci_omap_host *omap_host;
> + u32 ier = host->ier;
> +
> + pltfm_host = sdhci_priv(host);
> + omap_host = sdhci_pltfm_priv(pltfm_host);
> +
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_CON);
> + ac12 = sdhci_omap_readl(omap_host, SDHCI_OMAP_AC12);
> + reg &= ~CON_CLKEXTFREE;
> + if (ac12 & AC12_V1V8_SIGEN)
> + reg |= CON_CLKEXTFREE;
> + reg |= CON_PADEN;
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_CON, reg);
> +
> + disable_irq(host->irq);
> + ier |= SDHCI_INT_CARD_INT;
> + sdhci_writel(host, ier, SDHCI_INT_ENABLE);
> + sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
> +
> + for (i = 0; i < 5; i++) {
> + /*
> + * Delay is required for PSTATE to correctly reflect
> + * DLEV/CLEV values after PADEM is set.
> + */
> + usleep_range(100, 200);
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_PSTATE);
> + if ((reg & PSTATE_CLEV) &&
> + ((reg & PSTATE_DLEV) == PSTATE_DLEV)) {
> + ret = false;
> + goto ret;
'break' is better than 'goto'
> + }
> + }
> +
> +ret:
> + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_CON);
> + reg &= ~(CON_CLKEXTFREE | CON_PADEN);
> + sdhci_omap_writel(omap_host, SDHCI_OMAP_CON, reg);
> +
> + sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
> + sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
> + enable_irq(host->irq);
> +
> + return ret;
> +}
> +
> static int sdhci_omap_start_signal_voltage_switch(struct mmc_host *mmc,
> struct mmc_ios *ios)
> {
> @@ -562,6 +623,7 @@ static int sdhci_omap_probe(struct platform_device *pdev)
> host->mmc_host_ops.start_signal_voltage_switch =
> sdhci_omap_start_signal_voltage_switch;
> host->mmc_host_ops.set_ios = sdhci_omap_set_ios;
> + host->mmc_host_ops.card_busy = sdhci_omap_card_busy;
>
> sdhci_read_caps(host);
> host->caps |= SDHCI_CAN_DO_ADMA2;
>
^ permalink raw reply
* Re: [PATCH 01/12] mmc: sdhci-omap: Update 'power_mode' outside sdhci_omap_init_74_clocks
From: Adrian Hunter @ 2017-12-21 8:57 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Ulf Hansson, Rob Herring, Tony Lindgren
Cc: Mark Rutland, Russell King, linux-mmc, devicetree, linux-kernel,
linux-omap, linux-arm-kernel, nsekhar
In-Reply-To: <20171214130941.26666-2-kishon@ti.com>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> Updating 'power_mode' in sdhci_omap_init_74_clocks results in
> 'power_mode' never updated to MMC_POWER_OFF during card
> removal. This results in initialization sequence not sent to the
> card during re-insertion.
> Fix it here by adding sdhci_omap_set_power_mode to update power_mode.
> This function can also be used later to perform operations that
> are specific to a power mode (e.g, disable tuning during power off).
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-omap.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index 628bfe9a3d17..96985786cadf 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -244,6 +244,12 @@ static int sdhci_omap_start_signal_voltage_switch(struct mmc_host *mmc,
> return 0;
> }
>
> +static void sdhci_omap_set_power_mode(struct sdhci_omap_host *omap_host,
> + u8 power_mode)
> +{
> + omap_host->power_mode = power_mode;
> +}
> +
> static void sdhci_omap_set_bus_mode(struct sdhci_omap_host *omap_host,
> unsigned int mode)
> {
> @@ -273,6 +279,7 @@ static void sdhci_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>
> sdhci_omap_set_bus_mode(omap_host, ios->bus_mode);
> sdhci_set_ios(mmc, ios);
> + sdhci_omap_set_power_mode(omap_host, ios->power_mode);
> }
>
> static u16 sdhci_omap_calc_divisor(struct sdhci_pltfm_host *host,
> @@ -401,8 +408,6 @@ static void sdhci_omap_init_74_clocks(struct sdhci_host *host, u8 power_mode)
> sdhci_omap_writel(omap_host, SDHCI_OMAP_STAT, INT_CC_EN);
>
> enable_irq(host->irq);
> -
> - omap_host->power_mode = power_mode;
> }
>
> static struct sdhci_ops sdhci_omap_ops = {
> @@ -504,6 +509,7 @@ static int sdhci_omap_probe(struct platform_device *pdev)
> omap_host->host = host;
> omap_host->base = host->ioaddr;
> omap_host->dev = dev;
> + omap_host->power_mode = MMC_POWER_UNDEFINED;
> host->ioaddr += offset;
>
> mmc = host->mmc;
>
^ permalink raw reply
* Re: [PATCH v3 1/9] ARM: dts: imx7-colibri: move and rename USB Host power regulator
From: Shawn Guo @ 2017-12-21 8:29 UTC (permalink / raw)
To: Stefan Agner
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171219181038.1369-1-stefan-XLVq0VzYD2Y@public.gmane.org>
On Tue, Dec 19, 2017 at 07:10:30PM +0100, Stefan Agner wrote:
> The Colibri default which enables USB Host power is not necessarily
> tied to the OTG2 controller, some carrier board use the pin to
> control USB power for both controllers. Hence name the pinctrl
> group more generic.
>
> Also move the regulator to the generic eval-v3 device tree since
> the regulator is always on the carrier board. In the Colibri iMX7S
> case the regulator is just not used. This allows to reuse the
> regulator in a upcoming SKU Colibri iMX7D 1GB with eMMC.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Applied all, thanks.
--
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 v3 1/3] ARM: dts: imx6sx-sdb: Convert from fbdev to drm bindings
From: Shawn Guo @ 2017-12-21 8:22 UTC (permalink / raw)
To: Marco Franchi
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
festevam-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1512573319-6624-1-git-send-email-marcofrk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Dec 06, 2017 at 01:15:17PM -0200, Marco Franchi wrote:
> It is preferred to use the panel compatible string rather than passing
> the LCD timing in the device tree.
>
> So pass the "sii,43wvf1g" compatible string, which describes the parallel
> LCD.
>
> Also pass the 'backlight' property as described in
> Documentation/devicetree/bindings/display/panel/simple-panel.txt
>
> Signed-off-by: Marco Franchi <marcofrk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied all, thanks.
--
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] ARM: dts: colibri/apalis: use correct compatible for RTC
From: Shawn Guo @ 2017-12-21 8:14 UTC (permalink / raw)
To: Stefan Agner
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sanchayan Maity,
Marcel Ziswiler
In-Reply-To: <20171206102929.4755-1-stefan-XLVq0VzYD2Y@public.gmane.org>
On Wed, Dec 06, 2017 at 11:29:29AM +0100, Stefan Agner wrote:
> All Toradex Carrier Boards use a st,m41t0 compatible RTC. Compared
> to a st,m41t00 this RTC has also an oscillator fail bit which allows
> to detect when the RTC lost track of time.
>
> Cc: Sanchayan Maity <maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Marcel Ziswiler <marcel.ziswiler-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
Applied, thanks.
--
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] ARM: dts: colibri/apalis: use correct compatible for RTC
From: Shawn Guo @ 2017-12-21 8:13 UTC (permalink / raw)
To: Stefan Agner
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sanchayan Maity,
Marcel Ziswiler
In-Reply-To: <20171206102929.4755-1-stefan-XLVq0VzYD2Y@public.gmane.org>
On Wed, Dec 06, 2017 at 11:29:29AM +0100, Stefan Agner wrote:
> All Toradex Carrier Boards use a st,m41t0 compatible RTC. Compared
> to a st,m41t00 this RTC has also an oscillator fail bit which allows
> to detect when the RTC lost track of time.
>
> Cc: Sanchayan Maity <maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Marcel Ziswiler <marcel.ziswiler-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
Applied, thanks.
--
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 RESEND v6 0/6] provide power off support for iMX6 with external PMIC
From: Shawn Guo @ 2017-12-21 8:12 UTC (permalink / raw)
To: Mark Brown
Cc: Oleksij Rempel, Linus Torvalds, Rob Herring, Mark Rutland,
Michael Turquette, Stephen Boyd, Fabio Estevam, Russell King,
kernel, devicetree, linux-arm-kernel, linux-clk, linux-kernel,
Andrew Morton, Liam Girdwood, Leonard Crestez
In-Reply-To: <20171206184844.uqbu6rmj4bponpuw@sirena.org.uk>
On Wed, Dec 06, 2017 at 06:48:44PM +0000, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 08:23:56AM +0100, Oleksij Rempel wrote:
> > 2017.12.06:
> > Adding Linus. Probably there is no maintainer for this patch set.
> > No changes are made, tested on v4.15-rc1.
>
> Have any of the i.MX maintainers said anything about this? I was about
> to reply to this asking if they were ever going to review it as it keeps
> on getting resent but I'm not seeing any interest from any of them but
> the main immediate audience is i.MX systems.
I will be happy to take the dts changes, after kernel/reboot and
regulator get accepted (ideally landed on mainline).
Shawn
^ permalink raw reply
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