Re: [PATCH 1/3] mmc: esdhc: enable polling to detect card by itself
On Fri, Sep 28, 2012 at 06:28:31PM +0800, yongd wrote: > In the current code logic, sdhci_add_host() will enable the polling > method (set MMC_CAP_NEEDS_POLL) for a removable card (MMC_CAP_ > NONREMOVABLE is not set) whose host's internal card detection method > is disabled for some reason (SDHCI_QUIRK_BROKEN_CARD_DETECTION is set). > > However, this is improper since we can have some other card detection > methods besides host internal card detection and polling method. For > example, if the card detection type is ESDHC_CD_GPIO (external gpio pin > for CD), we will keep SDHCI_QUIRK_BROKEN_CARD_DETECTION set. This is right. > But, just as above said, sdhci_add_host() will also enable polling for such > a card. This is redundant. > At least for sdhci-esdhc-imx, SDHCI_QUIRK_BROKEN_CARD_DETECTION will be set only when neither ESDHC_CD_GPIO nor ESDHC_CD_CONTROLLER works. Shawn > On the other hand, for the card with ESDHC_CD_NONE detection type(no CD, > neither > controller nor gpio, so use polling), we currently rely on sdhci_add_host() to > enable polling for us. > > Here proposed a solution for such an embarrassing case. 1st, this patch will > de-couple polling enabling with sdhci_add_host() by doing this in host driver > itself, just as some other vendors. 2nd, one more patch will remove such > improper > MMC_CAP_NEEDS_POLL enabling in sdhci_add_host(). > > Change-Id: Ia7525009d8fd188e3f0169f225e4a76ff9e94b47 > Signed-off-by: yongd > --- > drivers/mmc/host/sdhci-esdhc-imx.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c > b/drivers/mmc/host/sdhci-esdhc-imx.c > index e23f813..f70079c 100644 > --- a/drivers/mmc/host/sdhci-esdhc-imx.c > +++ b/drivers/mmc/host/sdhci-esdhc-imx.c > @@ -569,6 +569,7 @@ static int __devinit sdhci_esdhc_imx_probe(struct > platform_device *pdev) > break; > > case ESDHC_CD_NONE: > + host->mmc->caps = MMC_CAP_NEEDS_POLL; > break; > } > > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6 v7] cpufreq, highbank: add support for highbank cpufreq
On Tue, Dec 04, 2012 at 08:34:02AM -0600, Mark Langsdorf wrote:
> Highbank processors depend on the external ECME to perform voltage
> management based on a requested frequency. Communication between the
> A9 cores and the ECME happens over the pl320 IPC channel.
>
> Signed-off-by: Mark Langsdorf
> Cc: shawn@linaro.org
> Cc: mturque...@ti.com
> ---
> Changes from v6
> Removed devicetree bindings documentation.
> Restructured driver to use clk notifications.
> Core driver logic is now cpufreq-clk0.
Great. It saves some codes :)
> Changes from v5
> Changed ipc_transmit() to pl320_ipc_transmit().
> Changes from v4
> Removed erroneous changes to arch/arm/Kconfig.
> Removed unnecessary changes to drivers/cpufreq/Kconfig.arm
> Alphabetized additions to arch/arm/mach-highbank/Kconfig
> Changed ipc call and header to match new ipc location in
> drivers/mailbox.
> Changes from v3
> None.
> Changes from v2
> Changed transition latency binding in code to match documentation.
> Changes from v1
> Added highbank specific Kconfig changes.
>
> arch/arm/boot/dts/highbank.dts | 10
> arch/arm/mach-highbank/Kconfig | 2 +
> drivers/cpufreq/Kconfig.arm| 16 ++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/highbank-cpufreq.c | 106
> +
> 5 files changed, 135 insertions(+)
> create mode 100644 drivers/cpufreq/highbank-cpufreq.c
>
> diff --git a/arch/arm/boot/dts/highbank.dts b/arch/arm/boot/dts/highbank.dts
> index 0c6fc34..7c4c27d 100644
> --- a/arch/arm/boot/dts/highbank.dts
> +++ b/arch/arm/boot/dts/highbank.dts
> @@ -36,6 +36,16 @@
> next-level-cache = <&L2>;
> clocks = <&a9pll>;
> clock-names = "cpu";
> + operating-points = <
> + /* kHzignored */
> + 130 100
> + 120 100
> + 110 100
> + 80 100
> + 40 100
> + 20 100
> + >;
> + clock-latency = <10>;
> };
>
> cpu@1 {
> diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
> index 2896881..b7862da 100644
> --- a/arch/arm/mach-highbank/Kconfig
> +++ b/arch/arm/mach-highbank/Kconfig
> @@ -1,5 +1,7 @@
> config ARCH_HIGHBANK
> bool "Calxeda ECX-1000 (Highbank)" if ARCH_MULTI_V7
> + select ARCH_HAS_CPUFREQ
> + select ARCH_HAS_OPP
> select ARCH_WANT_OPTIONAL_GPIOLIB
> select ARM_AMBA
> select ARM_GIC
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 5961e64..7aaac9f 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -76,3 +76,19 @@ config ARM_EXYNOS5250_CPUFREQ
> help
> This adds the CPUFreq driver for Samsung EXYNOS5250
> SoC.
> +
> +config ARM_HIGHBANK_CPUFREQ
> + tristate "Calxeda Highbank-based"
> + depends on ARCH_HIGHBANK
> + select CPU_FREQ_TABLE
> + select GENERIC_CPUFREQ_CPU0
> + select PM_OPP
> + select REGULATOR
> +
> + default m
> + help
> + This adds the CPUFreq driver for Calxeda Highbank SoC
> + based boards.
> +
> + If in doubt, say N.
> +
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 1bc90e1..9e8f12a 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)+=
> exynos4210-cpufreq.o
> obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
> obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
> obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
> +obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
>
>
> ##
> # PowerPC platform drivers
> diff --git a/drivers/cpufreq/highbank-cpufreq.c
> b/drivers/cpufreq/highbank-cpufreq.c
> new file mode 100644
> index 000..25ef437
> --- /dev/null
> +++ b/drivers/cpufreq/highbank-cpufreq.c
> @@ -0,0 +1,106 @@
> +/*
> + * Copyright (C) 2012 Calxeda, Inc.
> + *
> + * derived from cpufreq-cpu0 by Freescale Semiconductor
It's not any more, right?
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Do you need this header?
> +#include
> +#include
> +
> +#define HB_CPUFREQ_CHANGE_NOTE 0x8001
> +
> +static struct devic
Re: [PATCH 1/3] mmc: esdhc: enable polling to detect card by itself
On Tue, Oct 16, 2012 at 09:01:40PM -0700, Yong Ding wrote:
> Shawn,
> Thanks for your comment. And sorry for my so late due to illness:-)
> SDHCI_QUIRK_BROKEN_CARD_DETECTION is used for notifying we don't use the host
> internal card detection method so that we don't need enable/disable those
> relevant interrupt bits of host(sdhci_set_card_detection in sdhci.c).
> And as I double-checked the latest kernel code, actually sdhci-esdhc-imx sets
> this flag by default, and then will clear it only when the detection type is
> ESDHC_CD_CONTROLLER. So this aligns with my understanding.
What I was saying is the bit will be cleared when the detection type is
ESDHC_CD_CONTROLLE or ESDHC_CD_GPIO. You may have missed the fact that
there is no "break" in case ESDHC_CD_GPIO but a "fall through" comment.
switch (boarddata->cd_type) {
case ESDHC_CD_GPIO:
err = gpio_request_one(boarddata->cd_gpio, GPIOF_IN,
"ESDHC_CD");
if (err) {
dev_err(mmc_dev(host->mmc),
"no card-detect pin available!\n");
goto no_card_detect_pin;
}
err = request_irq(gpio_to_irq(boarddata->cd_gpio), cd_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
mmc_hostname(host->mmc), host);
if (err) {
dev_err(mmc_dev(host->mmc), "request irq error\n");
goto no_card_detect_irq;
}
/* fall through */
case ESDHC_CD_CONTROLLER:
/* we have a working card_detect back */
host->quirks &= ~SDHCI_QUIRK_BROKEN_CARD_DETECTION;
break;
case ESDHC_CD_PERMANENT:
host->mmc->caps = MMC_CAP_NONREMOVABLE;
break;
case ESDHC_CD_NONE:
break;
}
Shawn
> What I want to do is that 1st we shall set MMC_CAP_NEEDS_POLL by our host
> driver itself and 2nd remove the improper logic in sdhci_add_host() . How do
> u think? Thanks.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] gpio/tegra: convert to use linear irqdomain
On Tue, Oct 16, 2012 at 09:23:33PM +0200, Linus Walleij wrote: > The MXS driver tries to do the work of irq_domain_add_linear() s/MXS/tegra > by reserving a bunch of descriptors somewhere and keeping track > of the base offset, then calling irq_domain_add_legacy(). Let's > stop doing that and simply use the linear IRQ domain. > > Cc: Rob Herring > Cc: Grant Likely > Cc: Stephen Warren > Signed-off-by: Linus Walleij > --- > drivers/gpio/gpio-tegra.c | 12 > 1 file changed, 4 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] gpio/mxs: convert to use linear irqdomain
On Tue, Oct 16, 2012 at 09:22:56PM +0200, Linus Walleij wrote:
> The MXS driver tries to do the work of irq_domain_add_linear()
> by reserving a bunch of descriptors somewhere and keeping track
> of the base offset, then calling irq_domain_add_legacy(). Let's
> stop doing that and simply use the linear IRQ domain.
>
> Cc: Rob Herring
> Cc: Grant Likely
> Cc: Shawn Guo
> Signed-off-by: Linus Walleij
> ---
> drivers/gpio/gpio-mxs.c | 19 ++-
> 1 file changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c
> index 796fb13..71fd5b1 100644
> --- a/drivers/gpio/gpio-mxs.c
> +++ b/drivers/gpio/gpio-mxs.c
> @@ -223,7 +223,6 @@ static int __devinit mxs_gpio_probe(struct
> platform_device *pdev)
> static void __iomem *base;
> struct mxs_gpio_port *port;
> struct resource *iores = NULL;
> - int irq_base;
...
> int err;
>
> port = devm_kzalloc(&pdev->dev, sizeof(*port), GFP_KERNEL);
> @@ -272,16 +271,10 @@ static int __devinit mxs_gpio_probe(struct
> platform_device *pdev)
> /* clear address has to be used to clear IRQSTAT bits */
> writel(~0U, port->base + PINCTRL_IRQSTAT(port) + MXS_CLR);
>
> - irq_base = irq_alloc_descs(-1, 0, 32, numa_node_id());
> - if (irq_base < 0)
> - return irq_base;
> -
> - port->domain = irq_domain_add_legacy(np, 32, irq_base, 0,
> + port->domain = irq_domain_add_linear(np, 32,
>&irq_domain_simple_ops, NULL);
> - if (!port->domain) {
> - err = -ENODEV;
> - goto out_irqdesc_free;
> - }
> + if (!port->domain)
> + return -ENODEV;
>
> /* gpio-mxs can be a generic irq chip */
> mxs_gpio_init_gc(port, irq_base);
So I know this one is not compile-tested.
This is exactly the reason why I have to use irq_domain_add_legacy
other than irq_domain_add_linear when I add irqdomain support for the
driver. The driver uses generic-irq infrastructural which needs
irq_base for setup. So sadly, before generic-irq gets improved, any
irq chip that uses generic-irq will have to use irq_domain_add_legacy.
Shawn
> @@ -295,7 +288,7 @@ static int __devinit mxs_gpio_probe(struct
> platform_device *pdev)
>port->base + PINCTRL_DOUT(port), NULL,
>port->base + PINCTRL_DOE(port), NULL, 0);
> if (err)
> - goto out_irqdesc_free;
> + goto out_irqdomain_remove;
>
> port->bgc.gc.to_irq = mxs_gpio_to_irq;
> port->bgc.gc.base = port->id * 32;
> @@ -308,8 +301,8 @@ static int __devinit mxs_gpio_probe(struct
> platform_device *pdev)
>
> out_bgpio_remove:
> bgpio_remove(&port->bgc);
> -out_irqdesc_free:
> - irq_free_descs(irq_base, 32);
> +out_irqdomain_remove:
> + irq_domain_remove(port->domain);
> return err;
> }
>
> --
> 1.7.11.7
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mmc: esdhc: enable polling to detect card by itself
Can you fix your mailer to use bottom posting rather than top posting, and have texts wrap around column 70? Otherwise, you message stands a good chance to be ignored by people. On Wed, Oct 17, 2012 at 11:27:17PM -0700, Yong Ding wrote: > Shawn, > Thanks. Oh, sorry I really have missed the fact u mentioned. U are right in > the current code, the bit will also be cleared for ESDHC_CD_GPIO. > But I think this is improper since for GPIO detection type, we don't use the > host controller internal card detection(ESDHC_CD_CONTROLLER), but with > SDHCI_QUIRK_BROKEN_CARD_DETECTION cleared, we'll still enable/disable > relevant INT bits (in sdhci_set_card_detection in sdhci.c). This is my > biggest concern. And I think the SDHCI_QUIRK_BROKEN_CARD_DETECTION shall be > purely used to notify whether the host controller detection method is used or > not. So even for the ESDHC_CD_GPIO type, we should still set this flag. How > do u think? > I'm fine with that. Just remind you a fact you seem missed in case you need to change sdhci-esdhc-imx.c to adapt the changes you are going to make on sdhci.c. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] gpio/mxs: convert to use linear irqdomain
On 19 October 2012 18:22, Linus Walleij wrote: > No, which defconfig shall I use for this driver? > mxs_defconfig Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6 v8] cpufreq, highbank: add support for highbank cpufreq
On Wed, Dec 05, 2012 at 10:48:41AM -0600, Mark Langsdorf wrote: > Highbank processors depend on the external ECME to perform voltage > management based on a requested frequency. Communication between the > A9 cores and the ECME happens over the pl320 IPC channel. > > Signed-off-by: Mark Langsdorf > Cc: shawn@linaro.org Reviewed-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: mxs: Remove unneeded NULL pointer check
On Tue, Dec 11, 2012 at 08:33:34AM -0200, Fabio Estevam wrote: > Shawn/Mike, > > On Wed, Nov 21, 2012 at 7:33 PM, Fabio Estevam wrote: > > From: Fabio Estevam > > > > mxs platform has been converted to device tree. > > > > There is no need to check if np is NULL after doing: > > > > np = of_find_compatible_node(NULL, NULL, "fsl,imx[23/28]-clkctrl"); > > > > ,as it will always be non-NULL. > > > > Signed-off-by: Fabio Estevam > > Does this patch look good? Hmm, technically the check is still valid, as np can be NULL if the clkctrl node with correct compatible string is not present. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] pinctrl: mxs: Make PINCTRL_MXS select PINMUX && PINCONF
On Sun, Nov 11, 2012 at 10:22:42AM +0800, Axel Lin wrote:
> Then we can remove "select PINMUX && PINCONF" from PINCTRL_IMX{23,28}.
> This simplifies the dependency.
>
> Signed-off-by: Axel Lin
> ---
> drivers/pinctrl/Kconfig |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index fc0f49a..d5c9431 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -99,18 +99,16 @@ config PINCTRL_MMP2
> select PINCONF
>
> config PINCTRL_MXS
> + select PINMUX
> + select PINCONF
Better have them after 'bool' below, otherwise,
Acked-by: Shawn Guo
> bool
>
> config PINCTRL_IMX23
> bool
> - select PINMUX
> - select PINCONF
> select PINCTRL_MXS
>
> config PINCTRL_IMX28
> bool
> - select PINMUX
> - select PINCONF
> select PINCTRL_MXS
>
> config PINCTRL_NOMADIK
> --
> 1.7.9.5
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ARM: dts: imx6q-sabresd: add volume up/down gpio keys
On Mon, Nov 12, 2012 at 04:26:18PM +0800, Liu Ying wrote: > Add volume up/down gpio keys support in imx6q-sabresd.dts. > > Signed-off-by: Liu Ying Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] mmc: esdhc: enable polling to detect card by itself
On Tue, Nov 06, 2012 at 04:49:42PM +0800, yongd wrote: > From your info, we can see that on your platform, those pins (including > power, clk, DATA) necessary for MMC_SEND_STATUS transaction still keep > connected for some time just after the GPIO's level changes due to card > removable. And if we remove the card very slowly, such time duration can be > such long that the MMC_SEND_STATUS query can still succeed. > I was not removing the card as slowly as you think. It's actually a normal speed. That's why I thought your patch breaks the card-detection functionality before I found the cause. > So I think we can add a proper delay(maybe 100ms) before the gpio interrupt > triggers the MMC_SEND_STATUS query, and maybe this can probably fix this > issue:-) > I do not think it's a proper fixing. > Anyway, I 100% agree with you that for a ESDHC_CD_GPIO card, we shall query > gpio > state to know such card's presence rather than sending MMC_SEND_STATUS rudely. > > But just as I mentioned before, I don't think using > SDHCI_QUIRK_BROKEN_CARD_DETECTION > as the flag to determine whether and how we can know card's presence before > sending > command is a proper way. > > I haven't gotten any good idea. Do u have any idea on this? > I guess what we need is to call mmc_gpio_get_cd() trying to know card's presence before sending MMC_SEND_STATUS command. sdhci-esdhc-imx driver will surely need some changes to cope with that. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION][3.8.-rc1][ INFO: possible circular locking dependency detected ]
It seems that I'm running into the same locking issue. My setup is:
- i.MX28 (ARM)
- v3.8-rc1
- mxs_defconfig
Shawn
[ 602.229899] ==
[ 602.229905] [ INFO: possible circular locking dependency detected ]
[ 602.229926] 3.8.0-rc1-3-gde4ae7f #767 Not tainted
[ 602.229933] ---
[ 602.229951] kworker/0:1/21 is trying to acquire lock:
[ 602.230037] ((fb_notifier_list).rwsem){.+.+.+}, at: []
__blocking_notifier_call_chain+0x2c/0x60
[ 602.230047]
[ 602.230047] but task is already holding lock:
[ 602.230090] (console_lock){+.+.+.}, at: []
console_callback+0xc/0x12c
[ 602.230098]
[ 602.230098] which lock already depends on the new lock.
[ 602.230098]
[ 602.230104]
[ 602.230104] the existing dependency chain (in reverse order) is:
[ 602.230126]
[ 602.230126] -> #1 (console_lock){+.+.+.}:
[ 602.230174][] lock_acquire+0x9c/0x124
[ 602.230205][] console_lock+0x58/0x6c
[ 602.230250][] register_con_driver+0x38/0x138
[ 602.230284][] take_over_console+0x18/0x44
[ 602.230314][] fbcon_takeover+0x64/0xc8
[ 602.230352][] notifier_call_chain+0x44/0x80
[ 602.230386][] __blocking_notifier_call_chain+0x48/0x60
[ 602.230416][] blocking_notifier_call_chain+0x18/0x20
[ 602.230459][] register_framebuffer+0x170/0x250
[ 602.230492][] mxsfb_probe+0x574/0x738
[ 602.230528][] platform_drv_probe+0x14/0x18
[ 602.230556][] driver_probe_device+0x78/0x20c
[ 602.230583][] __driver_attach+0x94/0x98
[ 602.230610][] bus_for_each_dev+0x54/0x7c
[ 602.230636][] bus_add_driver+0x180/0x250
[ 602.230662][] driver_register+0x78/0x144
[ 602.230690][] do_one_initcall+0x30/0x16c
[ 602.230721][] kernel_init+0xf4/0x290
[ 602.230756][] ret_from_fork+0x14/0x2c
[ 602.230781]
[ 602.230781] -> #0 ((fb_notifier_list).rwsem){.+.+.+}:
[ 602.230825][] __lock_acquire+0x1354/0x19b0
[ 602.230854][] lock_acquire+0x9c/0x124
[ 602.230895][] down_read+0x3c/0x4c
[ 602.230933][] __blocking_notifier_call_chain+0x2c/0x60
[ 602.230962][] blocking_notifier_call_chain+0x18/0x20
[ 602.230997][] fb_blank+0x34/0x98
[ 602.231024][] fbcon_blank+0x1dc/0x27c
[ 602.231065][] do_blank_screen+0x1b0/0x268
[ 602.231093][] console_callback+0x68/0x12c
[ 602.231121][] process_one_work+0x1a8/0x560
[ 602.231145][] worker_thread+0x160/0x480
[ 602.231180][] kthread+0xa4/0xb0
[ 602.231210][] ret_from_fork+0x14/0x2c
[ 602.231218]
[ 602.231218] other info that might help us debug this:
[ 602.231218]
[ 602.231225] Possible unsafe locking scenario:
[ 602.231225]
[ 602.231230]CPU0CPU1
[ 602.231235]
[ 602.231249] lock(console_lock);
[ 602.231263]lock((fb_notifier_list).rwsem);
[ 602.231275]lock(console_lock);
[ 602.231287] lock((fb_notifier_list).rwsem);
[ 602.231292]
[ 602.231292] *** DEADLOCK ***
[ 602.231292]
[ 602.231305] 3 locks held by kworker/0:1/21:
[ 602.231345] #0: (events){.+.+.+}, at: []
process_one_work+0x128/0x560
[ 602.231388] #1: (console_work){+.+...}, at: []
process_one_work+0x128/0x560
[ 602.231430] #2: (console_lock){+.+.+.}, at: []
console_callback+0xc/0x12c
[ 602.231437]
[ 602.231437] stack backtrace:
[ 602.231491] [] (unwind_backtrace+0x0/0xf0) from []
(print_circular_bug+0x254/0x2a0)
[ 602.231547] [] (print_circular_bug+0x254/0x2a0) from []
(__lock_acquire+0x1354/0x19b0)
[ 602.231596] [] (__lock_acquire+0x1354/0x19b0) from []
(lock_acquire+0x9c/0x124)
[ 602.231640] [] (lock_acquire+0x9c/0x124) from []
(down_read+0x3c/0x4c)
[ 602.231694] [] (down_read+0x3c/0x4c) from []
(__blocking_notifier_call_chain+0x2c/0x60)
[ 602.231741] [] (__blocking_notifier_call_chain+0x2c/0x60) from
[] (blocking_notifier_call_chain+0x18/0x20)
[ 602.231791] [] (blocking_notifier_call_chain+0x18/0x20) from
[] (fb_blank+0x34/0x98)
[ 602.231836] [] (fb_blank+0x34/0x98) from []
(fbcon_blank+0x1dc/0x27c)
[ 602.231886] [] (fbcon_blank+0x1dc/0x27c) from []
(do_blank_screen+0x1b0/0x268)
[ 602.231931] [] (do_blank_screen+0x1b0/0x268) from []
(console_callback+0x68/0x12c)
[ 602.231970] [] (console_callback+0x68/0x12c) from []
(process_one_work+0x1a8/0x560)
[ 602.232010] [] (process_one_work+0x1a8/0x560) from []
(worker_thread+0x160/0x480)
[ 602.232054] [] (worker_thread+0x160/0x480) from []
(kthread+0xa4/0xb0)
[ 602.232100] [] (kthread+0xa4/0xb0) from []
(ret_from_fork+0x14/0x2c)
On Sat, Dec 22, 2012 at 04:28:26PM +0100, Maciej Rutecki wrote:
> Got during suspend to disk:
>
> [ 269.784867] [ INFO: possible circular locking dependency detected ]
> [ 269.784869] 3.8.0-rc1 #1 Not tainted
> [ 269.784870] ---
Re: [PATCH V7 2/7] ARM: dt: change .dtb build rules to build in dts directory
On Tue, Nov 27, 2012 at 04:29:11PM -0700, Stephen Warren wrote: > From: Grant Likely > > The current rules have the .dtb files build in a different directory > from the .dts files. The only reason for this is that it was what > PowerPC has done historically. This patch changes ARM to use the generic > dtb rule which builds .dtb files in the same directory as the source .dts. > It's a pity that after merging the patch, all the enabled dts files will be rebuilt anyway no matter whether they are actually changed or not. Shawn > Cc: Russell King > Cc: Arnd Bergmann > Cc: Olof Johansson > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Grant Likely > [swarren: added rm command for old stale .dtb files] > Signed-off-by: Stephen Warren > --- > v7: New patch. > --- > arch/arm/Makefile |4 ++-- > arch/arm/boot/Makefile | 12 > arch/arm/boot/dts/Makefile |8 > 3 files changed, 10 insertions(+), 14 deletions(-) > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index 1ec5f67..5f92252 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -291,10 +291,10 @@ zinstall uinstall install: vmlinux > $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@ > > %.dtb: scripts > - $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@ > + $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@ > > dtbs: scripts > - $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@ > + $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) dtbs > > # We use MRPROPER_FILES and CLEAN_FILES now > archclean: > diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile > index 9137df5..abfce28 100644 > --- a/arch/arm/boot/Makefile > +++ b/arch/arm/boot/Makefile > @@ -15,8 +15,6 @@ ifneq ($(MACHINE),) > include $(srctree)/$(MACHINE)/Makefile.boot > endif > > -include $(srctree)/arch/arm/boot/dts/Makefile > - > # Note: the following conditions must always be true: > # ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET) > # PARAMS_PHYS must be within 4MB of ZRELADDR > @@ -59,16 +57,6 @@ $(obj)/zImage: $(obj)/compressed/vmlinux FORCE > > endif > > -targets += $(dtb-y) > - > -# Rule to build device tree blobs > -$(obj)/%.dtb: $(src)/dts/%.dts FORCE > - $(call if_changed_dep,dtc) > - > -$(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y)) > - > -clean-files := *.dtb > - > ifneq ($(LOADADDR),) >UIMAGE_LOADADDR=$(LOADADDR) > else > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index a17d5ab..cb217f8 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -136,4 +136,12 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \ > wm8650-mid.dtb > dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb > > +targets += dtbs > endif > + > +dtbs: $(addprefix $(obj)/, $(dtb-y)) > + # *.dtb used to be generated in the directory above. Clean out the > + # old build results so people don't accidentally use them. > + rm -f $(obj)/../*.dtb > + > +clean-files := *.dtb > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION][3.8.-rc1][ INFO: possible circular locking dependency detected ]
On Wed, Dec 26, 2012 at 10:34:39AM +0800, Shawn Guo wrote:
> It seems that I'm running into the same locking issue. My setup is:
>
> - i.MX28 (ARM)
> - v3.8-rc1
> - mxs_defconfig
- The warning is seen when LCD is blanking
>
The warning disappears after reverting patch daee779 (console: implement
lockdep support for console_lock). Is it suggesting that the mxs
frame buffer driver (drivers/video/mxsfb.c) is doing something bad?
Shawn
>
> [ 602.229899] ==
> [ 602.229905] [ INFO: possible circular locking dependency detected ]
> [ 602.229926] 3.8.0-rc1-3-gde4ae7f #767 Not tainted
> [ 602.229933] ---
> [ 602.229951] kworker/0:1/21 is trying to acquire lock:
> [ 602.230037] ((fb_notifier_list).rwsem){.+.+.+}, at: []
> __blocking_notifier_call_chain+0x2c/0x60
> [ 602.230047]
> [ 602.230047] but task is already holding lock:
> [ 602.230090] (console_lock){+.+.+.}, at: []
> console_callback+0xc/0x12c
> [ 602.230098]
> [ 602.230098] which lock already depends on the new lock.
> [ 602.230098]
> [ 602.230104]
> [ 602.230104] the existing dependency chain (in reverse order) is:
> [ 602.230126]
> [ 602.230126] -> #1 (console_lock){+.+.+.}:
> [ 602.230174][] lock_acquire+0x9c/0x124
> [ 602.230205][] console_lock+0x58/0x6c
> [ 602.230250][] register_con_driver+0x38/0x138
> [ 602.230284][] take_over_console+0x18/0x44
> [ 602.230314][] fbcon_takeover+0x64/0xc8
> [ 602.230352][] notifier_call_chain+0x44/0x80
> [ 602.230386][] __blocking_notifier_call_chain+0x48/0x60
> [ 602.230416][] blocking_notifier_call_chain+0x18/0x20
> [ 602.230459][] register_framebuffer+0x170/0x250
> [ 602.230492][] mxsfb_probe+0x574/0x738
> [ 602.230528][] platform_drv_probe+0x14/0x18
> [ 602.230556][] driver_probe_device+0x78/0x20c
> [ 602.230583][] __driver_attach+0x94/0x98
> [ 602.230610][] bus_for_each_dev+0x54/0x7c
> [ 602.230636][] bus_add_driver+0x180/0x250
> [ 602.230662][] driver_register+0x78/0x144
> [ 602.230690][] do_one_initcall+0x30/0x16c
> [ 602.230721][] kernel_init+0xf4/0x290
> [ 602.230756][] ret_from_fork+0x14/0x2c
> [ 602.230781]
> [ 602.230781] -> #0 ((fb_notifier_list).rwsem){.+.+.+}:
> [ 602.230825][] __lock_acquire+0x1354/0x19b0
> [ 602.230854][] lock_acquire+0x9c/0x124
> [ 602.230895][] down_read+0x3c/0x4c
> [ 602.230933][] __blocking_notifier_call_chain+0x2c/0x60
> [ 602.230962][] blocking_notifier_call_chain+0x18/0x20
> [ 602.230997][] fb_blank+0x34/0x98
> [ 602.231024][] fbcon_blank+0x1dc/0x27c
> [ 602.231065][] do_blank_screen+0x1b0/0x268
> [ 602.231093][] console_callback+0x68/0x12c
> [ 602.231121][] process_one_work+0x1a8/0x560
> [ 602.231145][] worker_thread+0x160/0x480
> [ 602.231180][] kthread+0xa4/0xb0
> [ 602.231210][] ret_from_fork+0x14/0x2c
> [ 602.231218]
> [ 602.231218] other info that might help us debug this:
> [ 602.231218]
> [ 602.231225] Possible unsafe locking scenario:
> [ 602.231225]
> [ 602.231230]CPU0CPU1
> [ 602.231235]
> [ 602.231249] lock(console_lock);
> [ 602.231263]lock((fb_notifier_list).rwsem);
> [ 602.231275]lock(console_lock);
> [ 602.231287] lock((fb_notifier_list).rwsem);
> [ 602.231292]
> [ 602.231292] *** DEADLOCK ***
> [ 602.231292]
> [ 602.231305] 3 locks held by kworker/0:1/21:
> [ 602.231345] #0: (events){.+.+.+}, at: []
> process_one_work+0x128/0x560
> [ 602.231388] #1: (console_work){+.+...}, at: []
> process_one_work+0x128/0x560
> [ 602.231430] #2: (console_lock){+.+.+.}, at: []
> console_callback+0xc/0x12c
> [ 602.231437]
> [ 602.231437] stack backtrace:
> [ 602.231491] [] (unwind_backtrace+0x0/0xf0) from []
> (print_circular_bug+0x254/0x2a0)
> [ 602.231547] [] (print_circular_bug+0x254/0x2a0) from
> [] (__lock_acquire+0x1354/0x19b0)
> [ 602.231596] [] (__lock_acquire+0x1354/0x19b0) from []
> (lock_acquire+0x9c/0x124)
> [ 602.231640] [] (lock_acquire+0x9c/0x124) from []
> (down_read+0x3c/0x4c)
> [ 602.231694] [] (down_read+0x3c/0x4c) from []
> (__blocking_notifier_call_chain+0x2c/0x60)
> [ 602.231741] [] (__blocking_notifier_call_chain+0x2c/0x60) from
> [] (blocking_notifier_call_chain+0x18/0x20)
> [ 602.231791] [] (blocking_notifier_call_chain+0x18/0x20) from
> [] (fb_blank+0x34/0x98)
>
Re: [REGRESSION][3.8.-rc1][ INFO: possible circular locking dependency detected ]
On Thu, Dec 27, 2012 at 08:03:24AM -0500, Peter Hurley wrote:
> On Thu, 2012-12-27 at 16:36 +0800, Shawn Guo wrote:
> > On Wed, Dec 26, 2012 at 10:34:39AM +0800, Shawn Guo wrote:
> > > It seems that I'm running into the same locking issue. My setup is:
> > >
> > > - i.MX28 (ARM)
> > > - v3.8-rc1
> > > - mxs_defconfig
> > - The warning is seen when LCD is blanking
> > >
> >
> > The warning disappears after reverting patch daee779 (console: implement
> > lockdep support for console_lock). Is it suggesting that the mxs
> > frame buffer driver (drivers/video/mxsfb.c) is doing something bad?
> >
> > Shawn
> >
> > >
> > > [ 602.229899] ==
> > > [ 602.229905] [ INFO: possible circular locking dependency detected ]
> > > [ 602.229926] 3.8.0-rc1-3-gde4ae7f #767 Not tainted
> > > [ 602.229933] ---
> > > [ 602.229951] kworker/0:1/21 is trying to acquire lock:
> > > [ 602.230037] ((fb_notifier_list).rwsem){.+.+.+}, at: []
> > > __blocking_notifier_call_chain+0x2c/0x60
>
> You want this patch https://patchwork.kernel.org/patch/1757061/
>
Thanks for the pointer, Peter. It does fix the problem for me.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fb: Rework locking to fix lock ordering on takeover
On Thu, Dec 27, 2012 at 05:53:01AM +0100, Borislav Petkov wrote: > On Wed, Dec 26, 2012 at 01:09:51PM -0500, Sasha Levin wrote: > > > This patch can fix the following warning we saw? > > > http://lkml.org/lkml/2012/12/22/53 > > > > > > I will give it a try. > > > > Yup, that's the same error I've reported couple of months ago. > > > > It looks like the fb maintains are still absent, so it'll probably > > need a different way to get upstream. > > Adding to the bug pressure: just got a very similar splat on -rc1 (see > below). Alan, I'll run your patch to verify. > +1 http://thread.gmane.org/gmane.linux.kernel/1413953/focus=1415070 Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ehci-mxc: remove Efika MX-specific CHRGVBUS hack
On Sun, Dec 23, 2012 at 05:16:02AM -0600, Matt Sealey wrote: > Since Efika MX platform support (pre-devicetree) was removed from the tree > this code no longer has any possibility of running and clutters up the > driver which is being replaced by the chipidea host in the future anyway. > > Signed-off-by: Matt Sealey > Tested-by: Steev Klimazewski > CC: Sascha Hauer > CC: Alan Stern Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mxs timer: use ahbx bus clock to drive the timers on timrotv2
On Fri, Dec 21, 2012 at 03:06:15PM +0100, Torben Hohn wrote: > timer resolution of ~32us is pretty low. > v2 has 32bits resolution, so we have quite some headroom, and > can use the 24MHz clock. > v1 has only 16bits, so we only increase v2. > > So we just exchange the timrot clock in imx28. > On imx23 we have timrotv1 and everything stays the same. > > Signed-off-by: Torben Hohn 1) s/ahbx/apbx on patch subject. 2) The patch prefix should look like "ARM: mxs: ..." Fixed them and applied both patches. Thanks. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: mxs: Use a better name for the USB PHY clock
On Sat, Sep 22, 2012 at 01:54:55PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Use a better name for the USB PHY clock.
>
> Signed-off-by: Fabio Estevam
Mike,
I was planning send a pull-request to you with all mxs clock patches
collected for 3.8. It turns out this is the only one I queued for
this cycle. I do not bother to send you a pull-request containing
single patch, so can you please just apply it for 3.8? Thanks.
Shawn
> ---
> .../devicetree/bindings/clock/imx23-clock.txt |2 +-
> .../devicetree/bindings/clock/imx28-clock.txt |4 ++--
> drivers/clk/mxs/clk-imx23.c|6 +++---
> drivers/clk/mxs/clk-imx28.c| 10 +-
> 4 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.txt
> b/Documentation/devicetree/bindings/clock/imx23-clock.txt
> index a0b867e..baadbb1 100644
> --- a/Documentation/devicetree/bindings/clock/imx23-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/imx23-clock.txt
> @@ -52,7 +52,7 @@ clocks and IDs.
> lcdif 38
> etm 39
> usb 40
> - usb_pwr 41
> + usb_phy 41
>
> Examples:
>
> diff --git a/Documentation/devicetree/bindings/clock/imx28-clock.txt
> b/Documentation/devicetree/bindings/clock/imx28-clock.txt
> index aa2af28..52a49a4 100644
> --- a/Documentation/devicetree/bindings/clock/imx28-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/imx28-clock.txt
> @@ -73,8 +73,8 @@ clocks and IDs.
> can159
> usb060
> usb161
> - usb0_pwr62
> - usb1_pwr63
> + usb0_phy62
> + usb1_phy63
> enet_out64
>
> Examples:
> diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
> index f00dffb..8dd476e 100644
> --- a/drivers/clk/mxs/clk-imx23.c
> +++ b/drivers/clk/mxs/clk-imx23.c
> @@ -85,7 +85,7 @@ enum imx23_clk {
> cpu_xtal, hbus, xbus, lcdif_div, ssp_div, gpmi_div, emi_pll,
> emi_xtal, etm_div, saif_div, clk32k_div, rtc, adc, spdif_div,
> clk32k, dri, pwm, filt, uart, ssp, gpmi, spdif, emi, saif,
> - lcdif, etm, usb, usb_pwr,
> + lcdif, etm, usb, usb_phy,
> clk_max
> };
>
> @@ -143,8 +143,8 @@ int __init mx23_clocks_init(void)
> clks[saif] = mxs_clk_gate("saif", "saif_div", SAIF, 31);
> clks[lcdif] = mxs_clk_gate("lcdif", "lcdif_div", PIX, 31);
> clks[etm] = mxs_clk_gate("etm", "etm_div", ETM, 31);
> - clks[usb] = mxs_clk_gate("usb", "usb_pwr", DIGCTRL, 2);
> - clks[usb_pwr] = clk_register_gate(NULL, "usb_pwr", "pll", 0, PLLCTRL0,
> 18, 0, &mxs_lock);
> + clks[usb] = mxs_clk_gate("usb", "usb_phy", DIGCTRL, 2);
> + clks[usb_phy] = clk_register_gate(NULL, "usb_phy", "pll", 0, PLLCTRL0,
> 18, 0, &mxs_lock);
>
> for (i = 0; i < ARRAY_SIZE(clks); i++)
> if (IS_ERR(clks[i])) {
> diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
> index 42978f1b..db3af08 100644
> --- a/drivers/clk/mxs/clk-imx28.c
> +++ b/drivers/clk/mxs/clk-imx28.c
> @@ -140,7 +140,7 @@ enum imx28_clk {
> emi_xtal, lcdif_div, etm_div, ptp, saif0_div, saif1_div,
> clk32k_div, rtc, lradc, spdif_div, clk32k, pwm, uart, ssp0,
> ssp1, ssp2, ssp3, gpmi, spdif, emi, saif0, saif1, lcdif, etm,
> - fec, can0, can1, usb0, usb1, usb0_pwr, usb1_pwr, enet_out,
> + fec, can0, can1, usb0, usb1, usb0_phy, usb1_phy, enet_out,
> clk_max
> };
>
> @@ -218,10 +218,10 @@ int __init mx28_clocks_init(void)
> clks[fec] = mxs_clk_gate("fec", "hbus", ENET, 30);
> clks[can0] = mxs_clk_gate("can0", "ref_xtal", FLEXCAN, 30);
> clks[can1] = mxs_clk_gate("can1", "ref_xtal", FLEXCAN, 28);
> - clks[usb0] = mxs_clk_gate("usb0", "usb0_pwr", DIGCTRL, 2);
> - clks[usb1] = mxs_clk_gate("usb1", "usb1_pwr", DIGCTRL, 16);
> - clks[usb0_pwr] = clk_register_gate(NULL, "usb0_pwr", "pll0", 0,
> PLL0CTRL0, 18, 0, &mxs_lock);
> - clks[usb1_pwr] = clk_register_gate(NULL, "usb1_pwr", "pll1", 0,
> PLL1CTRL0, 18, 0, &mxs_lock);
> + clks[usb0] = mxs_clk_gate("usb0", "usb0_phy", DIGCTRL, 2);
> + clks[usb1] = mxs_clk_gate("usb1", "usb1_phy", DIGCTRL, 16);
> + clks[usb0_phy] = clk_register_gate(NULL, "usb0_phy", "pll0", 0,
> PLL0CTRL0, 18, 0, &mxs_lock);
> + clks[usb1_phy] = clk_register_gate(NULL, "usb1_phy", "pll1", 0,
> PLL1CTRL0, 18, 0, &mxs_lock);
> clks[enet_out] = clk_register_gate(NULL, "enet_out", "pll2", 0, ENET,
> 18, 0, &mxs_lock);
>
> for (i = 0; i < ARRAY_SIZE(clks); i++)
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: mxsfb: Fix colors display on lower color depth
Copy Sascha. Shawn On Thu, Apr 18, 2013 at 11:23:52AM +0200, Maxime Ripard wrote: > The current code always registers as a 32 bits display, and uses the > hardware to drop the MSB of each color to abjust to the interface width > used by the panel. > > This results on 18 bits (and probably 16 bits display as well) in colors > being displayed poorly, because the MSB are obviously the most important > bits for each color definition. > > The default controller behaviour when using an interface width smaller > than the color depth is to drop the LSBs of each color, which makes more > sense because you lose the least important part of the color definition. > > So, to fix the colors display, just get back to the default controller > behaviour. > > Signed-off-by: Maxime Ripard > --- > drivers/video/mxsfb.c |5 - > 1 file changed, 5 deletions(-) > > diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c > index 76c..2cfaf8b 100644 > --- a/drivers/video/mxsfb.c > +++ b/drivers/video/mxsfb.c > @@ -424,11 +424,6 @@ static int mxsfb_set_par(struct fb_info *fb_info) > return -EINVAL; > case STMLCDIF_16BIT: > case STMLCDIF_18BIT: > - /* 24 bit to 18 bit mapping */ > - ctrl |= CTRL_DF24; /* ignore the upper 2 bits in > - * each colour component > - */ > - break; > case STMLCDIF_24BIT: > /* real 24 bit */ > break; > -- > 1.7.10.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: [PATCH] clocksource: tcb: fix min_delta calculation
On Tue, Apr 23, 2013 at 03:11:33PM +0200, Marc Kleine-Budde wrote: > On 04/23/2013 03:08 PM, Marc Kleine-Budde wrote: > > The commit > > > > 77cc982 clocksource: use clockevents_config_and_register() where > > possible > > > > switches from manually calculating min_delta_ns (and others) and > > clockevents_register_device() to automatic calculation via > > clockevents_config_and_register(). During this conversation the "+ 1" in > > > > min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1; > > > > was lost. This leads to problems with schedule_delayed_work() with a delay > > of > > "1". Resulting in the work not scheduled in time. > > > > This patch fixes the problem by increasing the min_delta to "2" ticks. > > > > Signed-off-by: Marc Kleine-Budde > > The problem appears on at91sam9263. This patch successfully fixes the > problem and applies to current linus/master (post v3.9-rc8). Thanks for the fixing, Marc. Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: cfa10036: Add USB0 OTG port
On Fri, Jun 14, 2013 at 12:06:51AM +0200, Arnd Bergmann wrote:
> On Thursday 13 June 2013 15:43:42 Maxime Ripard wrote:
> > +
> > + ahb@8008 {
> > + usb0: usb@8008 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&usb0_otg_cfa10036>;
> > + status = "okay";
> > };
> > };
> >
>
> The patches all look good, just one trivial comment about the fragment above:
>
> There is already a "usb0" label in the imx28.dtsi file for the same
> node. When you refer to the node from a board.dts file, either leave
> out the redundant label, or use it to simplify the statements above
> to the brief version:
>
> &usb0 {
> pinctrl-names = "default";
> pinctrl-0 = <&usb0_otg_cfa10036>;
> status = "okay";
> };
Yeah, I moved all imx board level dts files to use this. But I was told
by Olof that the change does not gain too much and looks like a churn.
That's why I haven't made the same move for mxs. So I will remove the
redundant label when applying this patch.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: cfa10036: Add USB0 OTG port
On Fri, Jun 14, 2013 at 02:30:53PM +0800, Shawn Guo wrote:
> On Fri, Jun 14, 2013 at 12:06:51AM +0200, Arnd Bergmann wrote:
> > On Thursday 13 June 2013 15:43:42 Maxime Ripard wrote:
> > > +
> > > + ahb@8008 {
> > > + usb0: usb@8008 {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&usb0_otg_cfa10036>;
> > > + status = "okay";
> > > };
> > > };
> > >
> >
> > The patches all look good, just one trivial comment about the fragment
> > above:
> >
> > There is already a "usb0" label in the imx28.dtsi file for the same
> > node. When you refer to the node from a board.dts file, either leave
> > out the redundant label, or use it to simplify the statements above
> > to the brief version:
> >
> > &usb0 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&usb0_otg_cfa10036>;
> > status = "okay";
> > };
>
> Yeah, I moved all imx board level dts files to use this. But I was told
> by Olof that the change does not gain too much and looks like a churn.
> That's why I haven't made the same move for mxs. So I will remove the
> redundant label when applying this patch.
I would have the label stay there, because I found it's there like a
comment telling the controller instance.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] ARM: mxs: Various Crystalfontz DT additions
On Thu, Jun 13, 2013 at 03:43:41PM +0200, Maxime Ripard wrote: > Brian Lilly (3): > ARM: cfa10049: Switch the chip select pin of the LCD controller > ARM: mxs: dt: Add the Crystalfontz CFA-10055 device tree > ARM: mxs: dt: Add Crystalfontz CFA-10057 device tree > > Maxime Ripard (1): > ARM: cfa10036: Add USB0 OTG port All applied, thanks. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] clk: divider: replace bitfield width with mask
On Sun, Jun 16, 2013 at 07:58:21PM -0700, Mike Turquette wrote: > The forthcoming Device Tree binding for the divider clock type will use > a bitfield mask instead of bitfield width, which is what the current > basic divider implementation uses. > > This patch replaces the u8 width in struct clk_divider with a u32 mask. > The divider code is updated to use the bit mask internally but the two > registration functions still accept the width to maintain compatibility > with existing users. > > Also updated in this patch is the clk-private.h divider macro and two > Freescale clock divider implementations that are based on struct > clk_divider. > > Cc: Sascha Hauer > Cc: Shawn Guo > Signed-off-by: Mike Turquette > --- > No change since v1, new patch > > arch/arm/mach-imx/clk-busy.c | 2 +- > drivers/clk/clk-divider.c| 31 +++ > drivers/clk/mxs/clk-div.c| 2 +- > include/linux/clk-private.h | 2 +- > include/linux/clk-provider.h | 2 +- > 5 files changed, 19 insertions(+), 20 deletions(-) On imx and mxs, Tested-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/3] clk: dt: bindings for mux & divider clocks
Mike, On Mon, Jun 03, 2013 at 10:53:07AM -0700, Mike Turquette wrote: > I am using this code while converting the OMAP4 clock data over to DT I see these basic clk bindings can be useful for platforms that have a relatively simple clock tree, but I'm a little surprised that you plan to move OMAP4 to it. I'm wondering how many nodes you will have to add to OMAP4 device tree. For imx6q example, it means ~200 nodes addition to device tree, which is obviously a bloating of device tree. Shawn > and some common boilerplate code can be factored out of several clock > drivers if this is merged. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/13] cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases
On Wed, Jun 19, 2013 at 02:23:01PM +0530, Viresh Kumar wrote: > PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both > should be called or both shouldn't be. > > In case we have started PRECHANGE notifier and found an error, we must call > POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of > calling notifiers is complete. > > This patch fixes it. > > This also moves PRECHANGE notifier down so that we call it just before > starting > frequency transition. > > Cc: Shawn Guo Acked-by: Shawn Guo > Signed-off-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 001/001] gpio-mxs: Select faster gpio-generic set methods
On Fri, Jun 21, 2013 at 11:14:07AM -0700, Simon Pearson wrote: > From: Simon Pearson > > Kernel 3.8.4. By defining both the set and clear registers, > the speed of the gpio isimproved. gpio-generic.c, selects the > bgpio_set_with_clear() which isfaster than the current > bgpio_set_set(). This has performance implications for all > bitbang drivers (i2c, spi, etc). Slow SPI as compared to > 2.6.35.33 improved by a factor of 10 (80kHz CLK to 800kHz CLK). > > Signed-off-by: Simon Pearson The latest mainline kernel already has the improvement made by commit 90dae4e (gpio: mxs: Use set and clear capabilities of the gpio controller). Shawn > > --- > --- a/drivers/gpio/gpio-mxs.c.orig2013-03-20 13:11:19.0 -0700 > +++ b/drivers/gpio/gpio-mxs.c2013-06-21 10:02:33.0 -0700 > @@ -292,7 +292,8 @@ static int mxs_gpio_probe(struct platfor > > err = bgpio_init(&port->bgc, &pdev->dev, 4, > port->base + PINCTRL_DIN(port), > - port->base + PINCTRL_DOUT(port), NULL, > + port->base + PINCTRL_DOUT(port) + MXS_SET, > + port->base + PINCTRL_DOUT(port) + MXS_CLR, > port->base + PINCTRL_DOE(port), NULL, 0); > if (err) > goto out_irqdesc_free; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] apf27dev: add rtc ds1374 to the device tree
On Fri, Jun 21, 2013 at 06:24:13PM +0200, Philippe Reynes wrote:
>
> Signed-off-by: Philippe Reynes
Applied, thanks.
Shawn
> ---
> arch/arm/boot/dts/imx27-apf27dev.dts |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx27-apf27dev.dts
> b/arch/arm/boot/dts/imx27-apf27dev.dts
> index 66b8e1c..2a377ca 100644
> --- a/arch/arm/boot/dts/imx27-apf27dev.dts
> +++ b/arch/arm/boot/dts/imx27-apf27dev.dts
> @@ -53,6 +53,11 @@
> &i2c1 {
> clock-frequency = <40>;
> status = "okay";
> +
> + rtc@68 {
> + compatible = "dallas,ds1374";
> + reg = <0x68>;
> + };
> };
>
> &i2c2 {
> --
> 1.7.4.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] clocksource: vf_pit_timer: Fix build breakage
On Tue, Jun 25, 2013 at 05:16:20PM +0530, Sachin Kamat wrote:
> asm/sched_clock.h does not exist. Use linux/sched_clock.h instead.
> Without this patch we get the following build error (introduced by commit
> c1967249 ("clocksource: Add Freescale Vybrid pit timer support")):
>
> drivers/clocksource/vf_pit_timer.c:15:29: fatal error: asm/sched_clock.h:
> No such file or directory
>
> Signed-off-by: Sachin Kamat
> Cc: Jingchang Lu
> Cc: Daniel Lezcano
> Cc: Shawn Guo
Thanks. But there is already a patch [1].
Shawn
[1]
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=2699339361a9bacb3fa663e6b8981a040cfca4ee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/3] clk: dt: bindings for mux & divider clocks
On Fri, Jun 07, 2013 at 10:52:54AM -0700, Mike Turquette wrote: > Yes, there was a time when I was firmly against doing such a thing. > However I'm not sure it is so bad now. More and more SoCs are going to > keep getting merged into the kernel and that just means more and more > clock data. Perhaps DT is best suited to handle this bloat. I broke > the clock data out into a separate file so that it didn't overwhelm the > existing omap4.dtsi. I'm actually more concerned by run-time impact. Any of_find_node_*() call will possibly have to scan all those hundreds of nodes to find the desired one. Anyway, it's an OMAP folks decision, and the impact might not be that much on those fast CPUs. Shawn > > Either way I marked this series as RFC precisely due to your point. I > want feedback on how the OMAP folks feel about this. So far no has has > NACKed it ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/11] cpufreq: imx: select CPU_FREQ_TABLE
On Wed, Jun 12, 2013 at 01:45:13PM +0530, Viresh Kumar wrote: > CPUFreq driver of this platform uses APIs from freq_table.c and so must select > CPU_FREQ_TABLE. > > Cc: Shawn Guo > Signed-off-by: Viresh Kumar Acked-by: Shawn Guo > --- > drivers/cpufreq/Kconfig.arm | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > index 891dd1c..dc26303 100644 > --- a/drivers/cpufreq/Kconfig.arm > +++ b/drivers/cpufreq/Kconfig.arm > @@ -72,6 +72,7 @@ config ARM_IMX6Q_CPUFREQ > tristate "Freescale i.MX6Q cpufreq support" > depends on SOC_IMX6Q > depends on REGULATOR_ANATOP > + select CPU_FREQ_TABLE > help > This adds cpufreq driver support for Freescale i.MX6Q SOC. > > -- > 1.7.12.rc2.18.g61b472e > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mainline crashes in wm8962_probe() on i.MX6
On Thu, Jul 04, 2013 at 10:44:11AM +, Stehle Vincent-B46079 wrote: > Hi, > > Mainline of today* will not boot anymore on i.MX6 with ARM config > imx_v6_v7_defconfig. It crashes in wm8962_probe() (see log below). > > Bisecting points at merge commit 1286da8bc009cb2aee7f285e94623fc974c0c983, > but its two "parents" commits do not crash. Yeah, I just ran into it with linux-next and reported it there [1]. I will send a formal patch for it soon. Shawn [1] http://thread.gmane.org/gmane.linux.alsa.devel/109844 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 5/8] ARM: mxs: dt: cfa10037: make hogpins grabbed by respective drivers
On Sun, Jun 30, 2013 at 06:11:16PM +0200, Alexandre Belloni wrote: > Do you want me to send a reordered serie or will you do it when applying > the patches ? You can just apply patch 4/8 last. Please resend, since you have some comments from Maxime on patch #2 unresolved? Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 0/8] ARM: mxs: Various Crystalfontz DT additions
On Mon, Jul 01, 2013 at 03:23:21PM +0200, Alexandre Belloni wrote: > Alexandre Belloni (6): > ARM: mxs: Simplify detection of CrystalFontz boards > ARM: mxs: dt: cfa10037: make hogpins grabbed by respective drivers > ARM: mxs: dt: cfa10049: make hogpins grabbed by respective drivers > ARM: mxs: dt: cfa10055: make hogpins grabbed by respective drivers > ARM: mxs: dt: cfa10057: remove hogpins > ARM: mxs: dt: cfa10036: make hogpins grabbed by respective drivers > > Brian Lilly (2): > ARM: mxs: dt: Add Crystalfontz CFA-10056 device tree > ARM: mxs: dt: Add Crystalfontz CFA-10058 device tree All applied, thanks. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: soft lockup when recording audio on MX28EVK with ASoC sgtl5000
On Mon, Mar 25, 2013 at 01:10:54PM +0100, Marek Vasut wrote: > Dear Hector Palacios, > > CCing Shawn, this might also explain the touchscreen issue. > > > Hello, > > > > I just tried recording audio on Freescale's MX28EVK that uses ASoC sgtl5000 > > (kernel v3.8) with: > > > > arecord -M -f cd sound.wav --duration 10 > > > > and got a scheduler message: > > > > [ 789.041847] [sched_delayed] sched: RT throttling activated Hmm, I'm not sure if v3.8 is the first place where audio recording gets broken. Does v3.7 even work for you? Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] regulator: pfuze100: add pfuze100 regulator driver
The patch looks good. Comments below are mostly random coding style
nitpicks.
On Fri, Jul 12, 2013 at 12:54:15PM +0800, Robin Gong wrote:
> Add pfuze100 regulator driver.
>
> Signed-off-by: Robin Gong
> ---
> .../devicetree/bindings/regulator/pfuze100.txt | 113 +
> drivers/regulator/Kconfig |7 +
> drivers/regulator/Makefile |1 +
> drivers/regulator/pfuze100-regulator.c | 489
>
> include/linux/regulator/pfuze.h| 49 ++
We should probably name the header in the same way as driver file, so
pfuze100.h?
> 5 files changed, 659 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/pfuze100.txt
> create mode 100644 drivers/regulator/pfuze100-regulator.c
> create mode 100644 include/linux/regulator/pfuze.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt
> b/Documentation/devicetree/bindings/regulator/pfuze100.txt
> new file mode 100644
> index 000..d9fc752
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
> @@ -0,0 +1,113 @@
> +PFUZE100 family of regulators
> +
> +Required properties:
> +- compatible: "fsl,pfuze100"
> +- reg: I2C slave address
> +- regulators: This is the list of child nodes that specify the regulator
> + initialization data for defined regulators. Please refer to below doc
> + Documentation/devicetree/bindings/regulator/regulator.txt.
> +
> + The valid names for regulators are:
> + sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6
> +
> +Each regulator is defined using the standard binding for regulators.
> +
> +Example:
> +
> + pmic: pfuze100@08 {
> + compatible = "fsl,pfuze100";
> + reg = <0x08>;
> +
> + regulators {
> + sw1a_reg: sw1ab {
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw1c_reg: sw1c {
> + regulator-min-microvolt = <11>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw2_reg: sw2 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3a_reg: sw3a {
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3b_reg: sw3b {
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw4_reg: sw4 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + swbst_reg: swbst {
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <515>;
> + };
> +
> + snvs_reg: vsnvs {
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <300>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vref_reg: vrefddr {
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen1_reg: vgen1 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <155>;
> + };
> +
> + vgen2_reg: vgen2 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <155>;
> + };
> +
> + vgen3_reg: vgen3 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> +
Re: [PATCH v2] regulator: pfuze100: add pfuze100 regulator driver
On Mon, Jul 15, 2013 at 02:40:39PM +0800, Robin Gong wrote:
> > > +static const struct of_device_id pfuze_dt_ids[] = {
> > > + { .compatible = "fsl,pfuze100", .data = (void *)PFUZE_ID_PFUZE100},
> >
> > You do not use .data in the driver at all, and can just drop it.
> >
> good catch. .driver_data of i2c_device_id and .data of of_device_id are two
> different ways to let driver know which chip used now by DTS or not. I should
> use them to know which chip used now ,although I can know by reading chipid
> register.
>
If you can figure out the chip ID from hardware, it should be used as
the preference over compatible and .driver_data.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 07/11] cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
On Mon, Jul 15, 2013 at 11:22:08AM +0100, sudeep.karkadanage...@arm.com wrote: > From: Sudeep KarkadaNagesha > > Now that the cpu device registration initialises the of_node(if available) > appropriately for all the cpus, parsing here is redundant. > > This patch removes all DT parsing and uses cpu->of_node instead. > > Signed-off-by: Sudeep KarkadaNagesha Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] ARM: dts: imx23-evk: enable USB PHY and controller
On Mon, Jul 15, 2013 at 01:39:13PM -0300, Otavio Salvador wrote: > On Mon, Jul 15, 2013 at 12:39 PM, Fabio Estevam wrote: > > Hi Otavio, > > > > On Mon, Jul 15, 2013 at 11:22 AM, Otavio Salvador > > wrote: > >> The i.MX23EVK board provides a USB port so the USB PHY and controller > >> need to be enabled for it to be usable. > >> > >> Signed-off-by: Otavio Salvador > >> --- > > > > You should have Cc'd Shawn Guo on this series. > > Oh; thanks for fix my mistake. I am new to kernel development :-) I'm on copy of patches 1, 3 and 4. 2 and 5 are missing? Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 06/11] cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes
On Mon, Jul 15, 2013 at 11:22:07AM +0100, sudeep.karkadanage...@arm.com wrote: > From: Sudeep KarkadaNagesha > > Now that the cpu device registration initialises the of_node(if available) > appropriately for all the cpus, parsing here is redundant. > > This patch removes all DT parsing and uses cpu->of_node instead. > > Signed-off-by: Sudeep KarkadaNagesha Acked-by: Shawn Guo > --- > arch/arm/mach-imx/mach-imx6q.c | 3 +-- > drivers/cpufreq/imx6q-cpufreq.c | 4 +--- > 2 files changed, 2 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: imx-sgtl5000: fix error return code in imx_sgtl5000_probe()
On Tue, Jul 16, 2013 at 08:05:07PM +0800, Wei Yongjun wrote: > From: Wei Yongjun > > Fix to return a negative error code from the error handling > case instead of 0, as done elsewhere in this function. > > Signed-off-by: Wei Yongjun Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: imx23-evk: enable USB PHY and controller
On Tue, Jul 16, 2013 at 09:56:12AM -0300, Otavio Salvador wrote: > The i.MX23EVK board provides a USB port so the USB PHY and controller > need to be enabled for it to be usable. > > Signed-off-by: Otavio Salvador There is a typo i.XM23 in commit log of patch #2 and #3. I fixed them up and applied all 3. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] imx2_wdt: expose module alias for loading from device-tree
On Mon, Jul 29, 2013 at 09:38:18AM +0200, Niels de Vos wrote:
> Enable auto loading by udev when imx2_wdt is compiled as a module.
>
> Signed-off-by: Niels de Vos
> Cc: Shawn Guo
Acked-by: Shawn Guo
> ---
> drivers/watchdog/imx2_wdt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> index 693ac3f..17680aa 100644
> --- a/drivers/watchdog/imx2_wdt.c
> +++ b/drivers/watchdog/imx2_wdt.c
> @@ -322,6 +322,7 @@ static const struct of_device_id imx2_wdt_dt_ids[] = {
> { .compatible = "fsl,imx21-wdt", },
> { /* sentinel */ }
> };
> +MODULE_DEVICE_TABLE(of, imx2_wdt_dt_ids);
>
> static struct platform_driver imx2_wdt_driver = {
> .remove = __exit_p(imx2_wdt_remove),
> --
> 1.7.11.7
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dts: wandboard: Add support for SDIO bcm4329
On Sun, Jul 28, 2013 at 12:00:20PM +1200, Tony Prisk wrote: > The wandboard has a Broadcom 4329 WiFi connected via SDIO. This patch > sets the required pins to enable the wifi module. > > Signed-off-by: Tony Prisk Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/15] cpufreq: cpufreq-cpu0: initialize .owner field with THIS_MODULE
On Wed, Jul 31, 2013 at 07:49:11PM +0530, Viresh Kumar wrote:
> CPUFreq core does following at multiple places:
> module_{get|put}(cpufreq_driver->owner)).
>
> This is done to make sure module doesn't get unloaded if it is currently in
> use.
> This will work only if the .owner field of cpufreq driver is initialized with
> a
> valid pointer.
>
> This field wasn't initialized for this driver, lets initialize it with
> THIS_MODULE.
>
> Cc: Shawn Guo
> Signed-off-by: Viresh Kumar
For this and imx6q-cpufreq one,
Acked-by: Shawn Guo
> ---
> drivers/cpufreq/cpufreq-cpu0.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index ad1fde2..a087bf1 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -169,6 +169,7 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
> .init = cpu0_cpufreq_init,
> .exit = cpu0_cpufreq_exit,
> .name = "generic_cpu0",
> + .owner = THIS_MODULE,
> .attr = cpu0_cpufreq_attr,
> };
>
> --
> 1.7.12.rc2.18.g61b472e
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] dma: Add Freescale eDMA engine driver support
On Fri, Aug 02, 2013 at 03:55:48PM +0800, Jingchang Lu wrote:
> Add Freescale enhanced direct memory(eDMA) controller support.
> The eDMA controller deploys DMAMUXs routing DMA request sources(slot)
> to eDMA channels.
> This module can be found on Vybrid and LS-1 SoCs.
>
> Signed-off-by: Alison Wang
> Signed-off-by: Xiaochun Li
> Signed-off-by: Jingchang Lu
> ---
> .../devicetree/bindings/dma/fsl-vf610-edma.txt | 84 +++
> drivers/dma/Kconfig| 10 +
> drivers/dma/Makefile | 1 +
> drivers/dma/fsl-edma.c | 826
> +
> 4 files changed, 921 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/fsl-vf610-edma.txt
> create mode 100644 drivers/dma/fsl-edma.c
>
> diff --git a/Documentation/devicetree/bindings/dma/fsl-vf610-edma.txt
> b/Documentation/devicetree/bindings/dma/fsl-vf610-edma.txt
> new file mode 100644
> index 000..e6dc5cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/fsl-vf610-edma.txt
> @@ -0,0 +1,84 @@
> +* Freescale enhanced direct memory access(eDMA) Controller
> +
> +The eDMA engine deploys DMAMUXs routing request sources(slot) to
> +eDMA controller channels.
> +
> +* eDMA Controller
> +Required properties:
> +- compatible : Should be "fsl,-edma"
> +- reg : Should contain eDMA registers location and length
> +- interrupts : Should contain eDMA interrupt
> +- interrupt-names : Should be "edma-tx" for tx interrupt and
> + "edma-err" for err interrupt
> +- #dma-cells : Must be <2>.
> + The first cell specifies the DMAMUX ID. Specific request source
> + can only be routed by specific DMAMUXs.
> + the second cell specifies the request source(slot) ID.
> + See include/dt-bindings/dma/-edma.h for all the supported
> + request source IDs.
> +- fsl,dma-channels : Number of channels supported by the controller
The generic dma bindings Documentation/devicetree/bindings/dma/dma.txt
defines property dma-channels. You shouldn't need a vendor specific
definition.
> +- fsl,dma-mux : Phandle of the DMAMUXs deployed by the controller
> +
> +
> +* DMAMUX
> +Required properties:
> +- reg : Should contain DMAMUX registers location and length
> +- fsl,dmamux-id : DMAMUX ID. DMAMUX IDs are unique in each eDMA controller.
> + inside one eDMA controller, specific request source can only be routed by
> + one of its DMAMUXs.
> + However Specific request source may be routed to different eDMA controller,
> + thus all the DMAMUXs sharing a the same request sources have the same ID.
> +- clocks : Phandle of the clock used by the DMAMUX
> +- clock-names : The clock names
> +
> +Below is the eDMA controller and DMAMUX association, and DMAMUX IDs
> assignment
> +On Vybrid vf610 SoC, DMAMUX0 and DMAMU3 share the same request source group,
> +and DMAMUX1 and DMAMU2 share the same request source group.
> +
> +eDMA controller DMAMUXs DMAMUX ID
> +-
> +eDMA0DMAMUX0 0
> + DMAMUX1 1
> +
> +eDMA1DMAMUX2 1
> + DMAMUX3 0
> +
> +Examples:
> +
> +edma0: edma@40018000 {
> + #dma-cells = <2>;
> + compatible = "fsl,vf610-edma";
> + reg = <0x40018000 0x2000>;
> + interrupts = <0 8 0x04>, <0 9 0x04>;
> + interrupt-names = "edma-tx", "edma-err";
> + fsl,edma-channels = <32>;
> + fsl,edma-mux = <&dmamux0>, <&dmamux1>;
> + };
Broken indentation.
> +
> +dmamux0: dmamux@40024000 {
> + reg = <0x40024000 0x1000>;
> + fsl,dmamux-id = <0>;
> + clocks = <&clks VF610_CLK_DMAMUX0>;
> + clock-names = "dmamux";
> +};
> +
> +
> +* DMA clients
> +DMA client drivers that uses the DMA function must use the format described
> +in the dma.txt file, using a three-cell specifier for each channel: a phandle
> +plus two integer cells as described above.
> +
> +Examples:
> +
> +sai2: sai@40031000 {
> + compatible = "fsl,vf610-sai";
> + reg = <0x40031000 0x1000>;
> + interrupts = <0 86 0x04>;
> + clocks = <&clks VF610_CLK_SAI2>;
> + clock-names = "sai";
> + fsl,sai-dma-events = <21 20>;
This should be dropped, right?
Shawn
> + dma-names = "tx", "rx";
> + dmas = <&edma0 0 DMA_MUXID0_SAI2_TX>,
> + <&edma0 0 DMA_MUXID0_SAI2_RX>;
> + status = "disabled";
> +};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
On Tue, Aug 20, 2013 at 02:18:27PM -0700, Mike Turquette wrote: > Quoting Fabio Estevam (2013-08-20 08:40:52) > > On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > > > > > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > index 5a90a72..90e923e 100644 > > > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > @@ -89,8 +89,6 @@ clocks and IDs. > > > gpu3d_shader74 > > > ipu1_podf 75 > > > ipu2_podf 76 > > > - ldb_di0_podf77 > > > - ldb_di1_podf78 > > > ipu1_di0_pre79 > > > ipu1_di1_pre80 > > > ipu2_di0_pre81 > > > > This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc > > How does this fit in with the idea of having a stable binding/ABI? Seems > like changing this would be a bad idea for devices in the field that > have older DTBs. We should be safe since none of existing DTBs refers to the clocks (they are not leaf clocks in the whole clock tree but some interconnection ones). Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] refactor some ldb related clocks
Hi Ying, On Tue, Aug 20, 2013 at 06:08:48PM +0800, Liu Ying wrote: > > While I admit to having introduced the combination of 1/3.5 fixed > > divider and configurable 1/1,1/2 divder clocks to describe this > > fractional divider for the reasons you state, I think the correct > > solution would be to improve the table divider to support fractional > > values and get rid of the virtual ldb_di_div_3_5 clocks, not > > introduce more virtual clocks. > > Yes, it's good to support fractional values for the table divider(not sure if > there is any plan for this). > I see there is something similar in 'include/linux/sh_clk.h'. Yeah, I agree with Philipp on improving table divider to support fractional values. Would you like to work on that? Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: ipu: remove unnecessary platform_set_drvdata()
On Wed, Aug 21, 2013 at 06:52:54PM +0900, Jingoo Han wrote: > The driver core clears the driver data to NULL after device_release > or on probe failure. Thus, it is not needed to manually clear the > device driver data to NULL. > > Signed-off-by: Jingoo Han Acked-by: Shawn Guo > --- > drivers/dma/ipu/ipu_idmac.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c > index 608d4a2..cb9c0bc 100644 > --- a/drivers/dma/ipu/ipu_idmac.c > +++ b/drivers/dma/ipu/ipu_idmac.c > @@ -1764,7 +1764,6 @@ static int ipu_remove(struct platform_device *pdev) > iounmap(ipu->reg_ic); > iounmap(ipu->reg_ipu); > tasklet_kill(&ipu->tasklet); > - platform_set_drvdata(pdev, NULL); > > return 0; > } > -- > 1.7.10.4 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] w1: mxc_w1: remove unnecessary platform_set_drvdata()
On Thu, Aug 22, 2013 at 11:20:58AM +0900, Jingoo Han wrote: > The driver core clears the driver data to NULL after device_release > or on probe failure. Thus, it is not needed to manually clear the > device driver data to NULL. > > Signed-off-by: Jingoo Han Acked-by: Shawn Guo > --- > drivers/w1/masters/mxc_w1.c |2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c > index 47e12cf..15c7251 100644 > --- a/drivers/w1/masters/mxc_w1.c > +++ b/drivers/w1/masters/mxc_w1.c > @@ -152,8 +152,6 @@ static int mxc_w1_remove(struct platform_device *pdev) > > clk_disable_unprepare(mdev->clk); > > - platform_set_drvdata(pdev, NULL); > - > return 0; > } > > -- > 1.7.10.4 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] of: add update device node status via cmdline feature
The device tree mailing list is changed to devicet...@vger.kernel.org.
On Fri, Aug 23, 2013 at 03:09:08PM +0800, Dong Aisheng wrote:
> I tried the uboot way with fdt command to change the node status, it can work.
> However, it seems using fdt command is much complicated than the way i did
> with kernel
> command line and it also does not support enable/disable multi nodes at the
> same time.
> e.g, in order to enable ecspi1 and uart3 and disable gpmi:
> with uboot fdt command:
> U-Boot > fdt addr ${dtbaddr}
> U-Boot > fdt set /soc/aips-bus@0200/spba-bus@0200/ecspi@02008000
> status "okay"
> U-Boot > fdt set /soc/aips-bus@0210/serial@021e8000 status "okay"
> U-Boot > fdt set /soc/gpmi-nand@00112000 status "disabled"
Oh, you can use the U-Boot environment and scripting function to make
it even easier than your kernel cmdline approach to use.
> with kernel cmdline:
> fdt.enable=ecspi@02008000,serial@021e8000 fdt.disable=gpmi-nand@00112000
> So from the using perspective, kernel command line is much more simple and
> easy than uboot.
NAK.
It's not about simple or easy. The approach completely defects the
point of the whole device tree project - moving stuff that kernel does
not care out of kernel. Choosing device from mutually exclusive ones
(due to pin conflict of board design) should NOT be something that
kernel cares.
Kernel gets device tree blob from firmware/bootloader and instantiates
drivers for devices found in device tree. That's all what kernel should
do, nothing more. Asking kernel to manipulate the device availability
property in device tree is plainly wrong to me.
If your board is designed with so many pin conflicts between devices,
you have to do whatever you can do to get the decision made in device
tree blob, before it gets passed to kernel. Kernel does NOT care about
that decision making.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] of: add update device node status via cmdline feature
On Fri, Aug 23, 2013 at 03:51:07PM +0800, Shawn Guo wrote:
> The device tree mailing list is changed to devicet...@vger.kernel.org.
>
> On Fri, Aug 23, 2013 at 03:09:08PM +0800, Dong Aisheng wrote:
> > I tried the uboot way with fdt command to change the node status, it can
> > work.
> > However, it seems using fdt command is much complicated than the way i did
> > with kernel
> > command line and it also does not support enable/disable multi nodes at the
> > same time.
> > e.g, in order to enable ecspi1 and uart3 and disable gpmi:
> > with uboot fdt command:
> > U-Boot > fdt addr ${dtbaddr}
> > U-Boot > fdt set /soc/aips-bus@0200/spba-bus@0200/ecspi@02008000
> > status "okay"
> > U-Boot > fdt set /soc/aips-bus@0210/serial@021e8000 status "okay"
> > U-Boot > fdt set /soc/gpmi-nand@00112000 status "disabled"
>
> Oh, you can use the U-Boot environment and scripting function to make
> it even easier than your kernel cmdline approach to use.
>
> > with kernel cmdline:
> > fdt.enable=ecspi@02008000,serial@021e8000 fdt.disable=gpmi-nand@00112000
> > So from the using perspective, kernel command line is much more simple and
> > easy than uboot.
>
> NAK.
>
> It's not about simple or easy. The approach completely defects the
s/defects/defeats
Shawn
> point of the whole device tree project - moving stuff that kernel does
> not care out of kernel. Choosing device from mutually exclusive ones
> (due to pin conflict of board design) should NOT be something that
> kernel cares.
>
> Kernel gets device tree blob from firmware/bootloader and instantiates
> drivers for devices found in device tree. That's all what kernel should
> do, nothing more. Asking kernel to manipulate the device availability
> property in device tree is plainly wrong to me.
>
> If your board is designed with so many pin conflicts between devices,
> you have to do whatever you can do to get the decision made in device
> tree blob, before it gets passed to kernel. Kernel does NOT care about
> that decision making.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] of: add update device node status via cmdline feature
On Fri, Aug 23, 2013 at 04:49:55PM +0800, Dong Aisheng wrote:
> On Fri, Aug 23, 2013 at 03:51:07PM +0800, Shawn Guo wrote:
> > The device tree mailing list is changed to devicet...@vger.kernel.org.
> >
> > On Fri, Aug 23, 2013 at 03:09:08PM +0800, Dong Aisheng wrote:
> > > I tried the uboot way with fdt command to change the node status, it can
> > > work.
> > > However, it seems using fdt command is much complicated than the way i
> > > did with kernel
> > > command line and it also does not support enable/disable multi nodes at
> > > the same time.
> > > e.g, in order to enable ecspi1 and uart3 and disable gpmi:
> > > with uboot fdt command:
> > > U-Boot > fdt addr ${dtbaddr}
> > > U-Boot > fdt set /soc/aips-bus@0200/spba-bus@0200/ecspi@02008000
> > > status "okay"
> > > U-Boot > fdt set /soc/aips-bus@0210/serial@021e8000 status "okay"
> > > U-Boot > fdt set /soc/gpmi-nand@00112000 status "disabled"
> >
> > Oh, you can use the U-Boot environment and scripting function to make
> > it even easier than your kernel cmdline approach to use.
> >
>
> Hmm?
> Can you give an example to make it easier than kernel cmdline?
For imx6q-sabreauto example,
setenv loadaddr 0x1200
setenv fdtaddr 0x1800
setenv fdt_file imx6q-sabreauto.dtb
setenv bootcmd 'tftpboot zImage; tftpboot ${fdtaddr} ${fdt_file}; fdt addr
${fdtaddr}; run select_${devsel}; bootz ${loadaddr} - ${fdtaddr}'
setenv select_gpmi 'fdt set
/soc/aips-bus@0200/spba-bus@0200/ecspi@02008000 status disabled; fdt
set /soc/aips-bus@0210/serial@021e8000 status disabled; fdt set
/soc/gpmi-nand@00112000 status okay'
setenv select_ecspi '...'
setenv select_serial '...'
You can have all above environments defined in U-Boot mx6qsabreauto.h
at compile time. Then at runtime, you only need the following two
commands to boot kernel with the device that you want.
U-Boot > setenv devsel gpmi
U-Boot > boot
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 10/17] clocksource: mxs_timer: Switch to sched_clock_register()
On Thu, Jul 18, 2013 at 04:21:23PM -0700, Stephen Boyd wrote:
> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> the 64 bit function to allow us to remove the 32 bit registration
> interface.
>
> Cc: Shawn Guo
Acked-by: Shawn Guo
BTW, will the series break setup_sched_clock() users that are not
converted, like arch/arm/mach-imx/time.c? I can understand that's the
consequence of not moving things into drivers/ folder :)
Shawn
> Signed-off-by: Stephen Boyd
> ---
> drivers/clocksource/mxs_timer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clocksource/mxs_timer.c b/drivers/clocksource/mxs_timer.c
> index 0f5e65f..445b68a 100644
> --- a/drivers/clocksource/mxs_timer.c
> +++ b/drivers/clocksource/mxs_timer.c
> @@ -222,7 +222,7 @@ static struct clocksource clocksource_mxs = {
> .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> };
>
> -static u32 notrace mxs_read_sched_clock_v2(void)
> +static u64 notrace mxs_read_sched_clock_v2(void)
> {
> return ~readl_relaxed(mxs_timrot_base + HW_TIMROT_RUNNING_COUNTn(1));
> }
> @@ -236,7 +236,7 @@ static int __init mxs_clocksource_init(struct clk
> *timer_clk)
> else {
> clocksource_mmio_init(mxs_timrot_base +
> HW_TIMROT_RUNNING_COUNTn(1),
> "mxs_timer", c, 200, 32, clocksource_mmio_readl_down);
> - setup_sched_clock(mxs_read_sched_clock_v2, 32, c);
> + sched_clock_register(mxs_read_sched_clock_v2, 32, c);
> }
>
> return 0;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] regulator: pfuze100: add pfuze100 regulator driver
On Sun, Jul 21, 2013 at 05:17:27PM +0800, Robin Gong wrote:
> Add pfuze100 regulator driver.
>
> Signed-off-by: Robin Gong
> ---
> .../devicetree/bindings/regulator/pfuze100.txt | 113 +
> drivers/regulator/Kconfig |7 +
> drivers/regulator/Makefile |1 +
> drivers/regulator/pfuze100-regulator.c | 462
>
> include/linux/regulator/pfuze100.h | 44 ++
> 5 files changed, 627 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/pfuze100.txt
> create mode 100644 drivers/regulator/pfuze100-regulator.c
> create mode 100644 include/linux/regulator/pfuze100.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt
> b/Documentation/devicetree/bindings/regulator/pfuze100.txt
> new file mode 100644
> index 000..22e1a48
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
> @@ -0,0 +1,113 @@
> +PFUZE100 family of regulators
> +
> +Required properties:
> +- compatible: "fsl,pfuze100"
> +- reg: I2C slave address
> +- regulators: This is the list of child nodes that specify the regulator
> + initialization data for defined regulators. Please refer to below doc
> + Documentation/devicetree/bindings/regulator/regulator.txt.
"regulators" is not a property but a sub-node.
> +
> + The valid names for regulators are:
> + sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6
> +
> +Each regulator is defined using the standard binding for regulators.
> +
> +Example:
> +
> + pmic: pfuze100@08 {
> + compatible = "fsl,pfuze100";
> + reg = <0x08>;
> +
> + regulators {
> + sw1a_reg: sw1ab {
> + regulator-min-microvolt = <30>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw1c_reg: sw1c {
> + regulator-min-microvolt = <30>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw2_reg: sw2 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3a_reg: sw3a {
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3b_reg: sw3b {
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw4_reg: sw4 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + swbst_reg: swbst {
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <515>;
> + };
> +
> + snvs_reg: vsnvs {
> + regulator-min-microvolt = <100>;
> + regulator-max-microvolt = <300>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vref_reg: vrefddr {
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen1_reg: vgen1 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <155>;
> + };
> +
> + vgen2_reg: vgen2 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <155>;
> + };
> +
> + vgen3_reg: vgen3 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + vgen4_reg: vgen4 {
> + regulator-mi
Re: [PATCH v4] regulator: pfuze100: add pfuze100 regulator driver
On Mon, Jul 22, 2013 at 06:39:36PM +0800, Robin Gong wrote:
> > > +static int pfuze_parse_regulators_dt(struct pfuze_chip *chip)
> > > +{
> > > + struct device *dev = chip->dev;
> > > + struct device_node *parent;
> > > + int ret;
> > > +
> > > + of_node_get(dev->parent->of_node);
> > > + parent = of_find_node_by_name(dev->parent->of_node, "regulators");
> > > + if (!parent) {
> > > + dev_err(dev, "regulators node not found\n");
> > > + return -EINVAL;
> >
> > So you leave dev->parent->of_node unbalanced.
> >
> Seems of_find_node_by_name will of_node_put the parent node.
Ah, yes. I missed that.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: pinctrl-imx: Remove unneeded check for platform_get_resource()
On Sun, Jul 21, 2013 at 10:16:21PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > As devm_ioremap_resource() is used on probe, there is no need to explicitly > check the return value from platform_get_resource(), as this is something that > devm_ioremap_resource() takes care by itself. > > Signed-off-by: Fabio Estevam Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] regulator: pfuze100: add pfuze100 regulator driver
On Thu, Jul 25, 2013 at 11:33:18AM +0800, Robin Gong wrote: > @@ -0,0 +1,113 @@ > +PFUZE100 family of regulators > + > +Required properties: > +- compatible: "fsl,pfuze100" > +- reg: I2C slave address > +- regulators: This is the list of child nodes that specify the regulator > + initialization data for defined regulators. Please refer to below doc > + Documentation/devicetree/bindings/regulator/regulator.txt. I had the comment on v4 patch. The "regulators" should not be documented as a property but a sub-node, because it's not a property but sub-node. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jul 25 (ahci_imx.c)
On Fri, Jul 26, 2013 at 03:46:42AM +, Zhu Richard-R65037 wrote: > -Original Message- > From: Randy Dunlap [mailto:rdun...@infradead.org] > Sent: Friday, July 26, 2013 2:32 AM > To: Stephen Rothwell > Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org; Zhu Richard-R65037 > Subject: Re: linux-next: Tree for Jul 25 (ahci_imx.c) > > On 07/24/13 22:12, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20130724: > > > > on i386: > > # CONFIG_MFD_SYSCON is not set > > > when ahci_imx.c is built as a loadable module: > > ERROR: "syscon_regmap_lookup_by_compatible" [drivers/ata/ahci_imx.ko] > undefined! > > or when it is builtin: > > ahci_imx.c:(.text+0x182e54): undefined reference to > `syscon_regmap_lookup_by_compatible' > We should have it depend on MFD_SYSCON. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jul 25 (ahci_imx.c)
On Fri, Jul 26, 2013 at 04:58:14AM +, Zhu Richard-R65037 wrote: > Hi Shawn: > yes, it is. > > BTW, Should I re-send the AHCI_IMX patch-set or send out one stand-alone > patch to fix this issue? > I think an incremental fixing patch is good. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/35] cpufreq: cpufreq-cpu0: use cpufreq_table_validate_and_show()
On Thu, Aug 08, 2013 at 07:18:10PM +0530, Viresh Kumar wrote: > Lets use cpufreq_table_validate_and_show() instead of calling > cpufreq_frequency_table_cpuinfo() and cpufreq_frequency_table_get_attr(). > > Cc: Shawn Guo > Signed-off-by: Viresh Kumar I'm not copied on the patch that introduces function cpufreq_table_validate_and_show(). So if it does the right/equivalent thing, for cpufreq-cpu0 and imx6q-cpufreq: Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/44] cpufreq: cpu0: Use generic cpufreq routines
On Sat, Aug 10, 2013 at 12:14:09PM +0530, Viresh Kumar wrote: > Most of the CPUFreq drivers do similar things in .exit() and .verify() > routines > and .attr. So its better if we have generic routines for them which can be > used > by cpufreq drivers then. > > This patch uses these generic routines for this driver. > > Cc: Shawn Guo > Signed-off-by: Viresh Kumar Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/44] cpufreq: imx6q: Use generic cpufreq routines
On Sat, Aug 10, 2013 at 12:14:17PM +0530, Viresh Kumar wrote: > Most of the CPUFreq drivers do similar things in .exit() and .verify() > routines > and .attr. So its better if we have generic routines for them which can be > used > by cpufreq drivers then. > > This patch uses these generic routines for this driver. > > Cc: Shawn Guo > Signed-off-by: Viresh Kumar Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/44] cpufreq: imx6q: Use generic cpufreq routines
On Mon, Aug 12, 2013 at 01:40:36PM +0530, Viresh Kumar wrote: > On 12 August 2013 13:28, Shawn Guo wrote: > > On Sat, Aug 10, 2013 at 12:14:17PM +0530, Viresh Kumar wrote: > >> Most of the CPUFreq drivers do similar things in .exit() and .verify() > >> routines > >> and .attr. So its better if we have generic routines for them which can be > >> used > >> by cpufreq drivers then. > >> > >> This patch uses these generic routines for this driver. > >> > >> Cc: Shawn Guo > >> Signed-off-by: Viresh Kumar > > > > Shawn Guo > > I assume you meant an Ack here :) Ah, yeah. Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
v3.9-rc1: [BUG: swapper/1 still has locks held!]
I'm running v3.9-rc1 kernel on an ARM platform (i.MX28) with
arch/arm/mxs_defconfig and getting the following BUG warning.
Shawn
[5.681034] =
[5.685885] [ BUG: swapper/1 still has locks held! ]
[5.690885] 3.9.0-rc1 #774 Not tainted
[5.694734] -
[5.699475] 2 locks held by swapper/1:
[5.703323] #0: (&sig->cred_guard_mutex){+.+.+.}, at: []
prepare_bprm_creds+0x28/0x64
[5.712326] #1: (&type->i_mutex_dir_key){+.+.+.}, at: []
lookup_slow+0x2c/0xa0
[5.720966]
[5.720966] stack backtrace:
[5.725528] [] (unwind_backtrace+0x0/0xf0) from []
(rpc_wait_bit_killable+0x94/0xb4)
[5.735184] [] (rpc_wait_bit_killable+0x94/0xb4) from []
(__wait_on_bit+0x74/0xb8)
[5.744645] [] (__wait_on_bit+0x74/0xb8) from []
(out_of_line_wait_on_bit+0x64/0x70)
[5.754278] [] (out_of_line_wait_on_bit+0x64/0x70) from
[] (__rpc_execute+0xf4/0x370)
[5.763991] [] (__rpc_execute+0xf4/0x370) from []
(rpc_run_task+0xa4/0xb0)
[5.772660] [] (rpc_run_task+0xa4/0xb0) from []
(rpc_call_sync+0x40/0xac)
[5.781335] [] (rpc_call_sync+0x40/0xac) from []
(nfs3_rpc_wrapper.constprop.6+0x58/0xdc)
[5.791406] [] (nfs3_rpc_wrapper.constprop.6+0x58/0xdc) from
[] (nfs3_proc_lookup+0x88/0xf4)
[5.801751] [] (nfs3_proc_lookup+0x88/0xf4) from []
(nfs_lookup+0xe8/0x18c)
[5.810659] [] (nfs_lookup+0xe8/0x18c) from []
(lookup_real+0x20/0x50)
[5.819097] [] (lookup_real+0x20/0x50) from []
(__lookup_hash+0x34/0x44)
[5.827696] [] (__lookup_hash+0x34/0x44) from []
(lookup_slow+0x3c/0xa0)
[5.836297] [] (lookup_slow+0x3c/0xa0) from []
(link_path_walk+0x2a4/0x848)
[5.845144] [] (link_path_walk+0x2a4/0x848) from []
(path_openat+0x278/0x444)
[5.854176] [] (path_openat+0x278/0x444) from []
(do_filp_open+0x2c/0x80)
[5.862755] [] (do_filp_open+0x2c/0x80) from []
(open_exec+0x30/0x10c)
[5.871166] [] (open_exec+0x30/0x10c) from []
(do_execve+0x1b8/0x4c4)
[5.879500] [] (do_execve+0x1b8/0x4c4) from []
(kernel_init+0x80/0xe4)
[5.887963] [] (kernel_init+0x80/0xe4) from []
(ret_from_fork+0x14/0x2c)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: v3.9-rc1: [BUG: swapper/1 still has locks held!]
On Mon, Mar 04, 2013 at 10:52:10AM +0800, Shawn Guo wrote:
> I'm running v3.9-rc1 kernel on an ARM platform (i.MX28) with
> arch/arm/mxs_defconfig and getting the following BUG warning.
>
git bisect points me to the commit 6aa9707 (lockdep: check that no locks
held at freeze time).
Shawn
> [5.681034] =
> [5.685885] [ BUG: swapper/1 still has locks held! ]
> [5.690885] 3.9.0-rc1 #774 Not tainted
> [5.694734] -
> [5.699475] 2 locks held by swapper/1:
> [5.703323] #0: (&sig->cred_guard_mutex){+.+.+.}, at: []
> prepare_bprm_creds+0x28/0x64
> [5.712326] #1: (&type->i_mutex_dir_key){+.+.+.}, at: []
> lookup_slow+0x2c/0xa0
> [5.720966]
> [5.720966] stack backtrace:
> [5.725528] [] (unwind_backtrace+0x0/0xf0) from []
> (rpc_wait_bit_killable+0x94/0xb4)
> [5.735184] [] (rpc_wait_bit_killable+0x94/0xb4) from
> [] (__wait_on_bit+0x74/0xb8)
> [5.744645] [] (__wait_on_bit+0x74/0xb8) from []
> (out_of_line_wait_on_bit+0x64/0x70)
> [5.754278] [] (out_of_line_wait_on_bit+0x64/0x70) from
> [] (__rpc_execute+0xf4/0x370)
> [5.763991] [] (__rpc_execute+0xf4/0x370) from []
> (rpc_run_task+0xa4/0xb0)
> [5.772660] [] (rpc_run_task+0xa4/0xb0) from []
> (rpc_call_sync+0x40/0xac)
> [5.781335] [] (rpc_call_sync+0x40/0xac) from []
> (nfs3_rpc_wrapper.constprop.6+0x58/0xdc)
> [5.791406] [] (nfs3_rpc_wrapper.constprop.6+0x58/0xdc) from
> [] (nfs3_proc_lookup+0x88/0xf4)
> [5.801751] [] (nfs3_proc_lookup+0x88/0xf4) from []
> (nfs_lookup+0xe8/0x18c)
> [5.810659] [] (nfs_lookup+0xe8/0x18c) from []
> (lookup_real+0x20/0x50)
> [5.819097] [] (lookup_real+0x20/0x50) from []
> (__lookup_hash+0x34/0x44)
> [5.827696] [] (__lookup_hash+0x34/0x44) from []
> (lookup_slow+0x3c/0xa0)
> [5.836297] [] (lookup_slow+0x3c/0xa0) from []
> (link_path_walk+0x2a4/0x848)
> [5.845144] [] (link_path_walk+0x2a4/0x848) from []
> (path_openat+0x278/0x444)
> [5.854176] [] (path_openat+0x278/0x444) from []
> (do_filp_open+0x2c/0x80)
> [5.862755] [] (do_filp_open+0x2c/0x80) from []
> (open_exec+0x30/0x10c)
> [5.871166] [] (open_exec+0x30/0x10c) from []
> (do_execve+0x1b8/0x4c4)
> [5.879500] [] (do_execve+0x1b8/0x4c4) from []
> (kernel_init+0x80/0xe4)
> [5.887963] [] (kernel_init+0x80/0xe4) from []
> (ret_from_fork+0x14/0x2c)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 32/42] drivers/video: don't check resource with devm_ioremap_resource
On Sat, May 11, 2013 at 02:33:56PM +0900, Jingoo Han wrote: > On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote: > > > > devm_ioremap_resource does sanity checks on the given resource. No need to > > duplicate this in the driver. > > > > Signed-off-by: Wolfram Sang > > CC'ed Tomi Valkeinen, Shawn Guo, Fabio Estevam Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] ARM: mxs: remove the .map_io declaration
On Mon, May 13, 2013 at 12:16:08PM +0200, Maxime Ripard wrote:
> Now that the ARM core code calls debug_ll_io_init, we can remove it from
> the machine_desc declaration.
>
> Signed-off-by: Maxime Ripard
Acked-by: Shawn Guo
> ---
> arch/arm/mach-mxs/mach-mxs.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
> index 5b62b64..d67ecc1 100644
> --- a/arch/arm/mach-mxs/mach-mxs.c
> +++ b/arch/arm/mach-mxs/mach-mxs.c
> @@ -434,7 +434,6 @@ static const char *mxs_dt_compat[] __initdata = {
> };
>
> DT_MACHINE_START(MXS, "Freescale MXS (Device Tree)")
> - .map_io = debug_ll_io_init,
> .init_irq = irqchip_init,
> .handle_irq = icoll_handle_irq,
> .init_time = mxs_timer_init,
> --
> 1.8.1.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: imx23-olinuxino: mark sdcard cd as broken
On Sat, Apr 06, 2013 at 10:42:10AM -0300, Alexandre Pereira da Silva wrote: > The imx23-olinuxino sdcard doesn't have card detect. > > Signed-off-by: Alexandre Pereira da Silva Applied, thanks. > --- > arch/arm/boot/dts/imx23-olinuxino.dts |1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts > b/arch/arm/boot/dts/imx23-olinuxino.dts > index a43141a..d4cc9f8 100644 > --- a/arch/arm/boot/dts/imx23-olinuxino.dts > +++ b/arch/arm/boot/dts/imx23-olinuxino.dts > @@ -29,6 +29,7 @@ > pinctrl-names = "default"; > pinctrl-0 = <&mmc0_4bit_pins_a > &mmc0_pins_fixup>; > bus-width = <4>; > + broken-cd; > status = "okay"; > }; > > -- > 1.7.10 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: cfa10036: Add touchscreen support to the CFA-10049
On Fri, Apr 05, 2013 at 02:33:02PM +0200, Alexandre Belloni wrote:
> Signed-off-by: Alexandre Belloni
Applied, thanks.
> ---
> arch/arm/boot/dts/imx28-cfa10049.dts |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts
> b/arch/arm/boot/dts/imx28-cfa10049.dts
> index b9dad4e..f16c1e2 100644
> --- a/arch/arm/boot/dts/imx28-cfa10049.dts
> +++ b/arch/arm/boot/dts/imx28-cfa10049.dts
> @@ -192,6 +192,11 @@
> usbphy1: usbphy@8007e000 {
> status = "okay";
> };
> +
> + lradc@8005 {
> + status = "okay";
> + fsl,lradc-touchscreen-wires = <4>;
> + };
> };
> };
>
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] dt: run C pre-processor on *.dts, create some standard headers
On Fri, Apr 05, 2013 at 12:46:50PM -0600, Stephen Warren wrote: > Rob, it might be worth keeping this in a separate branch in linux-next > so you can pull it out if it causes any issues. I've been using these > patches for quite a while now, but there's always opportunity for > surprises on architectures I don't use. I did just fix a bug when > building with O= a few days back, hence the V2 that I posted as patches. > > > > This branch enhances the support for running dtc on device tree files. > > A dedicated directory is created for header files that provide constants > for device-tree bindings. > > The kbuild dependency script processor is enhanced to support processing > the dependency outputs from multiple separate commands at once. > > The kbuild dtc rule is modified so that the C pre-processor is always > applied when compiling any device tree. > > Some standard headers are created which define common constants for GPIO, > IRQ, and ARM GIC device tree bindings. > > > > The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: > > Linux 3.9-rc1 > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git > tegra-for-3.10-dtc-cpp-chroot-std-headers > I just rebuilt my imx/dt branch based on this to avoid all those dts files renaming. So regardless of the path it goes to mainline, I will need it as a dependency in arm-soc tree. Shawn > for you to fetch changes up to 4be505d4fc7a07371a2b658469ca1dda3ca3: > > ARM: dt: create a DT header for the GIC > > > > Stephen Warren (7): > kbuild: create an "include chroot" for DT bindings > kbuild: fixdep: support concatenated dep files > kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc > kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp > ARM: dt: add header to define GPIO flags > ARM: dt: add header to define IRQ flags > ARM: dt: create a DT header for the GIC > > arch/arm/boot/dts/include/dt-bindings |1 + > include/dt-bindings/gpio/gpio.h | 15 +++ > .../dt-bindings/interrupt-controller/arm-gic.h | 22 + > include/dt-bindings/interrupt-controller/irq.h | 19 > scripts/Makefile.lib| 17 ++-- > scripts/basic/fixdep.c | 93 -- > 6 files changed, 125 insertions(+), 42 deletions(-) > create mode 12 arch/arm/boot/dts/include/dt-bindings > create mode 100644 include/dt-bindings/gpio/gpio.h > create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h > create mode 100644 include/dt-bindings/interrupt-controller/irq.h > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: dts: mxs: leave card detect out of common mmc pins config
On Mon, Apr 08, 2013 at 12:12:20PM +0200, Hector Palacios wrote: > MicroSD card sockets don't usually have card detect line. This pin > is actually not needed for the MMC to work and it is more of a > platform design decission to have it. > The card detect pin already has a configuration entry of its own: > 'mmc0_cd_cfg' so we complete the iomux configuration here and let > platforms to include it or not depending on whether the card detect > line is routed to the SD socket. > Sounds sensible. > Signed-off-by: Hector Palacios > --- > > Hello, > > All imx28 based platforms except 'bluegiga,apx4devkit' and > 'schulercontrol,imx28-sps1', use 'mmc0_cd_cfg' in their mmc configuration > so please check whether this patch would break these platforms. > I just tested the patch on imx28-evk and card-detection still works. So patches applied, thanks. Shawn > arch/arm/boot/dts/imx28.dtsi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi > index 9b18e81..4222e4e 100644 > --- a/arch/arm/boot/dts/imx28.dtsi > +++ b/arch/arm/boot/dts/imx28.dtsi > @@ -449,7 +449,6 @@ > 0x2060 /* > MX28_PAD_SSP0_DATA6__SSP0_D6 */ > 0x2070 /* > MX28_PAD_SSP0_DATA7__SSP0_D7 */ > 0x2080 /* > MX28_PAD_SSP0_CMD__SSP0_CMD */ > - 0x2090 /* > MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT */ > 0x20a0 /* > MX28_PAD_SSP0_SCK__SSP0_SCK */ > >; > fsl,drive-strength = <1>; > @@ -465,7 +464,6 @@ > 0x2020 /* > MX28_PAD_SSP0_DATA2__SSP0_D2 */ > 0x2030 /* > MX28_PAD_SSP0_DATA3__SSP0_D3 */ > 0x2080 /* > MX28_PAD_SSP0_CMD__SSP0_CMD */ > - 0x2090 /* > MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT */ > 0x20a0 /* > MX28_PAD_SSP0_SCK__SSP0_SCK */ > >; > fsl,drive-strength = <1>; > @@ -477,6 +475,8 @@ > fsl,pinmux-ids = < > 0x2090 /* > MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT */ > >; > + fsl,drive-strength = <1>; > + fsl,voltage = <1>; > fsl,pull-up = <0>; > }; > > -- > 1.8.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: dts: mxs: leave card detect out of common mmc pins config
On Mon, Apr 08, 2013 at 03:58:05PM +0200, Hector Palacios wrote: > On 04/08/2013 02:48 PM, Shawn Guo wrote: > >On Mon, Apr 08, 2013 at 12:12:20PM +0200, Hector Palacios wrote: > >>MicroSD card sockets don't usually have card detect line. This pin > >>is actually not needed for the MMC to work and it is more of a > >>platform design decission to have it. > >>The card detect pin already has a configuration entry of its own: > >>'mmc0_cd_cfg' so we complete the iomux configuration here and let > >>platforms to include it or not depending on whether the card detect > >>line is routed to the SD socket. > >> > >Sounds sensible. > > > >>Signed-off-by: Hector Palacios > >>--- > >> > >>Hello, > >> > >>All imx28 based platforms except 'bluegiga,apx4devkit' and > >>'schulercontrol,imx28-sps1', use 'mmc0_cd_cfg' in their mmc configuration > >>so please check whether this patch would break these platforms. > >> > >I just tested the patch on imx28-evk and card-detection still works. So > >patches applied, thanks. > > The EVK and most platforms will work because they are using > 'mmc0_cd_cfg' so actually this patch does not change anything on > them. > Platforms 'bluegiga,apx4devkit' and 'schulercontrol,imx28-sps1' > however are not referencing 'mmc0_cd_cfg' so after applying this > patch they will have unconfigured CD line and they may break. Ah, yes. I thought that any board that has CD support has to reference 'mmc0_cd_cfg'. That's not necessarily true. > The driver will call get_cd() upon probing, which returns the status of the > CD line. > Please check these two platforms before applying. Ok, let's wait for people owning the boards to confirm. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: mx28: add auart2 2 pins pinmux to imx28.dtsi
On Mon, Apr 08, 2013 at 02:57:31PM +0200, Eric Bénard wrote:
> Add auart2 2 pins configuration on its main pads
>
> Signed-off-by: Eric Bénard
All 3 patches applied, thanks.
> ---
> arch/arm/boot/dts/imx28.dtsi | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 7ba4966..13799cf 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -308,6 +308,17 @@
> fsl,pull-up = <0>;
> };
>
> + auart2_2pins_b: auart2-2pins@1 {
> + reg = <1>;
> + fsl,pinmux-ids = <
> + 0x3080 /*
> MX28_PAD_AUART2_RX__AUART2_RX */
> + 0x3090 /*
> MX28_PAD_AUART2_TX__AUART2_TX */
> + >;
> + fsl,drive-strength = <0>;
> + fsl,voltage = <1>;
> + fsl,pull-up = <0>;
> + };
> +
> auart3_pins_a: auart3@0 {
> reg = <0>;
> fsl,pinmux-ids = <
> --
> 1.7.11.7
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mxs: icoll: Add function to register an interrupt as FIQ source
On Mon, Apr 29, 2013 at 03:58:37PM +0200, Maxime Ripard wrote:
> MXS, unlike other ARM platforms,
How are other ARM platforms handling that?
> has no way to make a FIQ from an
> interrupt from a driver, without poking directly into the icoll.
>
> Add an exported function to do this.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/mach-mxs/icoll.c | 11 +++
This will become drivers/irqchip/irq-mxs.c after the merge window.
Shawn
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/mach-mxs/icoll.c b/arch/arm/mach-mxs/icoll.c
> index 8fb23af..1bb16da 100644
> --- a/arch/arm/mach-mxs/icoll.c
> +++ b/arch/arm/mach-mxs/icoll.c
> @@ -16,6 +16,7 @@
> * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> */
>
> +#include
> #include
> #include
> #include
> @@ -34,6 +35,7 @@
> #define HW_ICOLL_INTERRUPTn_SET(n) (0x0124 + (n) * 0x10)
> #define HW_ICOLL_INTERRUPTn_CLR(n) (0x0128 + (n) * 0x10)
> #define BM_ICOLL_INTERRUPTn_ENABLE 0x0004
> +#define BM_ICOLL_INTERRUPTn_FIQ_ENABLE 0x0010
> #define BV_ICOLL_LEVELACK_IRQLEVELACK__LEVEL00x1
>
> #define ICOLL_NUM_IRQS 128
> @@ -41,6 +43,15 @@
> static void __iomem *icoll_base = MXS_IO_ADDRESS(MXS_ICOLL_BASE_ADDR);
> static struct irq_domain *icoll_domain;
>
> +void mxs_icoll_set_irq_fiq(unsigned int irq)
> +{
> + struct irq_data *d = irq_get_irq_data(irq);
> +
> + __raw_writel(BM_ICOLL_INTERRUPTn_FIQ_ENABLE,
> + icoll_base + HW_ICOLL_INTERRUPTn_SET(d->hwirq));
> +}
> +EXPORT_SYMBOL(mxs_icoll_set_irq_fiq);
> +
> static void icoll_ack_irq(struct irq_data *d)
> {
> /*
> --
> 1.8.1.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: mxs: Use set and clear capabilities of the gpio controller
On Mon, Apr 29, 2013 at 04:07:18PM +0200, Maxime Ripard wrote: > The current driver doesn't use the set and clear registers found on the > mxs gpio controller. > > This leads the generic gpio controller to be using some internal value > to avoid looking up the value stored in the registers, making it behave > pretty much like a cache. > > This raises some coherency problem when a gpio is not modified by the > gpio controller, while it can easily be fixed by using the set and clear > registers. > > Signed-off-by: Maxime Ripard Acked-by: Shawn Guo > --- > drivers/gpio/gpio-mxs.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c > index 25000b0..f8e6af2 100644 > --- a/drivers/gpio/gpio-mxs.c > +++ b/drivers/gpio/gpio-mxs.c > @@ -326,7 +326,8 @@ static int mxs_gpio_probe(struct platform_device *pdev) > > err = bgpio_init(&port->bgc, &pdev->dev, 4, >port->base + PINCTRL_DIN(port), > - port->base + PINCTRL_DOUT(port), NULL, > + port->base + PINCTRL_DOUT(port) + MXS_SET, > + port->base + PINCTRL_DOUT(port) + MXS_CLR, >port->base + PINCTRL_DOE(port), NULL, 0); > if (err) > goto out_irqdesc_free; > -- > 1.8.1.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: cpu0: Free parent node for error cases
On Wed, May 01, 2013 at 10:34:43AM +0530, Viresh Kumar wrote:
> We are freeing parent node in success cases but not in failure cases. Lets do
> it.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/cpufreq-cpu0.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index 3ab8294..c025714 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -189,7 +189,8 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
>
> if (!np) {
> pr_err("failed to find cpu0 node\n");
> - return -ENOENT;
> + ret = -ENOENT;
> + goto out_put_parent;
> }
>
> cpu_dev = &pdev->dev;
> @@ -199,7 +200,7 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
> if (IS_ERR(cpu_clk)) {
> ret = PTR_ERR(cpu_clk);
> pr_err("failed to get cpu0 clock: %d\n", ret);
> - goto out_put_node;
> + goto out_put_np;
> }
>
> cpu_reg = devm_regulator_get(cpu_dev, "cpu0");
> @@ -211,13 +212,13 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
> ret = of_init_opp_table(cpu_dev);
> if (ret) {
> pr_err("failed to init OPP table: %d\n", ret);
> - goto out_put_node;
> + goto out_put_np;
> }
>
> ret = opp_init_cpufreq_table(cpu_dev, &freq_table);
> if (ret) {
> pr_err("failed to init cpufreq table: %d\n", ret);
> - goto out_put_node;
> + goto out_put_np;
> }
>
> of_property_read_u32(np, "voltage-tolerance", &voltage_tolerance);
> @@ -262,8 +263,10 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
>
> out_free_table:
> opp_free_cpufreq_table(cpu_dev, &freq_table);
> -out_put_node:
> +out_put_np:
Unnecessary renaming brings unnecessary diffstat?
Shawn
> of_node_put(np);
> +out_put_parent:
> + of_node_put(parent);
> return ret;
> }
>
> --
> 1.7.12.rc2.18.g61b472e
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC 04/22] staging/drm: imx: add missing dependencies
On Thu, May 02, 2013 at 05:16:08PM +0200, Arnd Bergmann wrote: > The imx DRM driver needs a couple of extra Kconfig dependencies > to avoid random build failures: > > drivers/staging/imx-drm/ipuv3-crtc.c:448: > undefined reference to `ipu_idmac_put' > drivers/staging/imx-drm/ipuv3-crtc.c:450: undefined reference to > `ipu_dmfc_put' drivers/staging/imx-drm/ipuv3-crtc.c:452: > undefined reference to `ipu_dp_put' > drivers/staging/imx-drm/ipuv3-crtc.c:454: undefined reference to > `ipu_di_put' > drivers/built-in.o: In function `ipu_probe': > :(.text+0x4b4174): undefined reference to `device_reset' > drivers/built-in.o: In function `imx_tve_probe': > drivers/staging/imx-drm/imx-tve.c:648: undefined reference to > `devm_regmap_init_mmio_clk' > drivers/built-in.o: In function > `imx_pd_connector_get_modes': > drivers/staging/imx-drm/parallel-display.c:78: undefined > reference to `of_get_drm_display_mode' There is a patch [1] from Marek fixing this one. Shawn [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/233449 > > Cc: Greg Kroah-Hartman > Cc: Shawn Guo > Cc: Philipp Zabel > Signed-off-by: Arnd Bergmann > --- > drivers/staging/imx-drm/Kconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig > index 8c9e403..35ccda5 100644 > --- a/drivers/staging/imx-drm/Kconfig > +++ b/drivers/staging/imx-drm/Kconfig > @@ -1,6 +1,7 @@ > config DRM_IMX > tristate "DRM Support for Freescale i.MX" > select DRM_KMS_HELPER > + select VIDEOMODE_HELPERS > select DRM_GEM_CMA_HELPER > select DRM_KMS_CMA_HELPER > depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM) > @@ -23,6 +24,7 @@ config DRM_IMX_PARALLEL_DISPLAY > config DRM_IMX_TVE > tristate "Support for TV and VGA displays" > depends on DRM_IMX > + select REGMAP_MMIO > help > Choose this to enable the internal Television Encoder (TVe) > found on i.MX53 processors. > @@ -30,6 +32,7 @@ config DRM_IMX_TVE > config DRM_IMX_IPUV3_CORE > tristate "IPUv3 core support" > depends on DRM_IMX > + depends on RESET_CONTROLLER > help > Choose this if you have a i.MX5/6 system and want > to use the IPU. This option only enables IPU base > @@ -38,5 +41,6 @@ config DRM_IMX_IPUV3_CORE > config DRM_IMX_IPUV3 > tristate "DRM Support for i.MX IPUv3" > depends on DRM_IMX > + depends on DRM_IMX_IPUV3_CORE > help > Choose this if you have a i.MX5 or i.MX6 processor. > -- > 1.8.1.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC 20/22] media: coda: select GENERIC_ALLOCATOR
On Thu, May 02, 2013 at 09:53:19PM +0200, Arnd Bergmann wrote: > Unfortunately, linux-next as of today is still broken. Shawn, did I > miss a pull request from you? No, I haven't sent you a pull request for that. I have queued it for 3.10-rc but am still waiting for a stable base (3.10-rc1 where coda and genalloc changes should be merged together) to send it out. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] cpufreq: cpu0: Free parent node for error cases
On Fri, May 03, 2013 at 10:14:25AM +0530, Viresh Kumar wrote:
> We are freeing parent node in success cases but not in failure cases. Lets do
> it.
>
> Signed-off-by: Viresh Kumar
Acked-by: Shawn Guo
> ---
> drivers/cpufreq/cpufreq-cpu0.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index 3ab8294..8565d41 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -189,7 +189,8 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
>
> if (!np) {
> pr_err("failed to find cpu0 node\n");
> - return -ENOENT;
> + ret = -ENOENT;
> + goto out_put_parent;
> }
>
> cpu_dev = &pdev->dev;
> @@ -264,6 +265,8 @@ out_free_table:
> opp_free_cpufreq_table(cpu_dev, &freq_table);
> out_put_node:
> of_node_put(np);
> +out_put_parent:
> + of_node_put(parent);
> return ret;
> }
>
> --
> 1.7.12.rc2.18.g61b472e
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC 04/22] staging/drm: imx: add missing dependencies
On Fri, May 03, 2013 at 05:21:37PM +0200, Arnd Bergmann wrote: > On Friday 03 May 2013, Shawn Guo wrote: > > On Thu, May 02, 2013 at 05:16:08PM +0200, Arnd Bergmann wrote: > > > The imx DRM driver needs a couple of extra Kconfig dependencies > > > to avoid random build failures: > > > > > > drivers/staging/imx-drm/ipuv3-crtc.c:448: > > > undefined reference to `ipu_idmac_put' > > > drivers/staging/imx-drm/ipuv3-crtc.c:450: undefined reference to > > > `ipu_dmfc_put' drivers/staging/imx-drm/ipuv3-crtc.c:452: > > > undefined reference to `ipu_dp_put' > > > drivers/staging/imx-drm/ipuv3-crtc.c:454: undefined reference to > > > `ipu_di_put' > > > drivers/built-in.o: In function `ipu_probe': > > > :(.text+0x4b4174): undefined reference to `device_reset' > > > drivers/built-in.o: In function `imx_tve_probe': > > > drivers/staging/imx-drm/imx-tve.c:648: undefined reference to > > > `devm_regmap_init_mmio_clk' > > > drivers/built-in.o: In function > > > `imx_pd_connector_get_modes': > > > > > drivers/staging/imx-drm/parallel-display.c:78: undefined > > > reference to `of_get_drm_display_mode' > > > > There is a patch [1] from Marek fixing this one. > > > > Shawn > > > > [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/233449 > > > > That patch only addresses one of the four missing dependencies. > I originally had four separate patches, but did not want to > bother everyone with those so I combined them into one. Yea, I agree we can address all of them in one patch. But it seems people agreed that there is a more correct way [1] to fix of_get_drm_display_mode one, and that's how v2 of Marek's patch comes. Shawn [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/232861/focus=232898 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] pinctrl: mxs: remove unnecessary platform_set_drvdata()
On Mon, May 06, 2013 at 12:42:13PM +0900, Jingoo Han wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
> (device-core: Ensure drvdata = NULL when no driver is bound).
> Thus, it is not needed to manually clear the device driver data to NULL.
>
> Signed-off-by: Jingoo Han
Acked-by: Shawn Guo
> ---
> drivers/pinctrl/pinctrl-mxs.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-mxs.c b/drivers/pinctrl/pinctrl-mxs.c
> index b45c4eb..f5d5643 100644
> --- a/drivers/pinctrl/pinctrl-mxs.c
> +++ b/drivers/pinctrl/pinctrl-mxs.c
> @@ -515,7 +515,6 @@ int mxs_pinctrl_probe(struct platform_device *pdev,
> return 0;
>
> err:
> - platform_set_drvdata(pdev, NULL);
> iounmap(d->base);
> return ret;
> }
> @@ -525,7 +524,6 @@ int mxs_pinctrl_remove(struct platform_device *pdev)
> {
> struct mxs_pinctrl_data *d = platform_get_drvdata(pdev);
>
> - platform_set_drvdata(pdev, NULL);
> pinctrl_unregister(d->pctl);
> iounmap(d->base);
>
> --
> 1.7.2.5
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ARM: dts: cfa10036: Change the OLED display to SSD1306
On Mon, Apr 22, 2013 at 11:55:55AM +0200, Maxime Ripard wrote: > The SSD1307 was used in an early prototype that will never get > distributed. The final board now has a SSD1306 instead, that has its own > power generation unit and thus doesn't need any PWM. The panel attached > to it also changed. > > Signed-off-by: Maxime Ripard Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: cfa10036: dt: Change i2c0 clock frequency
On Mon, Apr 22, 2013 at 12:02:22PM +0200, Maxime Ripard wrote: > The OLED display can work faster. Change the i2c controller clock > frequency to remove the tearing effect that can be seen on the display. > > Signed-off-by: Maxime Ripard Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/13] pwm: pwm-mxs: Let device core handle pinctrl
On Wed, May 08, 2013 at 02:51:33PM +0300, Alexander Shishkin wrote: > Fabio Estevam writes: > > > Since commit ab78029 (drivers/pinctrl: grab default handles from device > > core), > > we can rely on device core for handling pinctrl. > > > > So remove devm_pinctrl_get_select_default() from the driver. > > > > Cc: Thierry Reding > > Cc: > > Signed-off-by: Fabio Estevam > > --- > > drivers/pwm/pwm-mxs.c |6 -- > > 1 file changed, 6 deletions(-) > > Looks good, can we have some tested-by from imx guys? I'm not sure why you're interested in this patch instead of "[PATCH 01/13] usb: chipidea: ci13xxx_imx: Let device core handle pinctrl". I tested both patches, so Tested-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: don't call of_dma_request_slave_channel directly
On Tue, Apr 23, 2013 at 05:54:33PM +0200, Arnd Bergmann wrote:
> The exported interface for device drivers is dma_request_slave_channel,
> not of_dma_request_slave_channel. The former does not depend on device
> tree but also works with ACPI and other interfaces providing an
> abstraction for DMA channels.
>
> This fixes link errors when building ALSA as a loadable module.
>
> Signed-off-by: Arnd Bergmann
I had already sent a similar patch [1] for that.
Shawn
[1] http://thread.gmane.org/gmane.linux.alsa.devel/107568/
> Cc: alsa-de...@alsa-project.org
> Cc: Lars-Peter Clausen
> Cc: Shawn Guo
> Cc: Mark Brown
> ---
> sound/soc/soc-generic-dmaengine-pcm.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/soc-generic-dmaengine-pcm.c
> b/sound/soc/soc-generic-dmaengine-pcm.c
> index 5fd5ed4..8ee9859 100644
> --- a/sound/soc/soc-generic-dmaengine-pcm.c
> +++ b/sound/soc/soc-generic-dmaengine-pcm.c
> @@ -219,19 +219,20 @@ static const char * const
> dmaengine_pcm_dma_channel_names[] = {
> };
>
> static void dmaengine_pcm_request_chan_of(struct dmaengine_pcm *pcm,
> - struct device_node *of_node)
> + struct device *dev)
> {
> unsigned int i;
> + struct device_node *of_node = dev->of_node;
>
> if ((pcm->flags & SND_DMAENGINE_PCM_FLAG_NO_DT) || !of_node)
> return;
>
> if (pcm->flags & SND_DMAENGINE_PCM_FLAG_HALF_DUPLEX) {
> - pcm->chan[0] = of_dma_request_slave_channel(of_node, "tx_rx");
> + pcm->chan[0] = dma_request_slave_channel(dev, "tx_rx");
> pcm->chan[1] = pcm->chan[0];
> } else {
> for (i = SNDRV_PCM_STREAM_PLAYBACK; i <=
> SNDRV_PCM_STREAM_CAPTURE; i++) {
> - pcm->chan[i] = of_dma_request_slave_channel(of_node,
> + pcm->chan[i] = dma_request_slave_channel(dev,
> dmaengine_pcm_dma_channel_names[i]);
> }
> }
> @@ -255,7 +256,7 @@ int snd_dmaengine_pcm_register(struct device *dev,
> pcm->config = config;
> pcm->flags = flags;
>
> - dmaengine_pcm_request_chan_of(pcm, dev->of_node);
> + dmaengine_pcm_request_chan_of(pcm, dev);
>
> if (flags & SND_DMAENGINE_PCM_FLAG_NO_RESIDUE)
> return snd_soc_add_platform(dev, &pcm->platform,
> --
> 1.8.1.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch -v3 1/4] Migrate shutdown/reboot to boot cpu.
On Mon, Apr 15, 2013 at 12:14:29PM -0500, Robin Holt wrote: > We recently noticed that reboot of a 1024 cpu machine takes approx 16 > minutes of just stopping the cpus. The slowdown was tracked to commit > f96972f. > > The current implementation does all the work of hot removing the cpus > before halting the system. We are switching to just migrating to the > boot cpu and then continuing with shutdown/reboot. > > This also has the effect of not breaking x86's command line parameter for > specifying the reboot cpu. Note, this code was shamelessly copied from > arch/x86/kernel/reboot.c with bits removed pertaining to the reboot_cpu > command line parameter. > > Signed-off-by: Robin Holt > To: Shawn Guo It works on my hardware - i.MX6 Quad. Tested-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: cpu0: Put cpu parent node after using it
On Mon, Apr 15, 2013 at 12:39:37PM +0530, Viresh Kumar wrote: > Parent node must be put after using it to balance its usage count. This was > missing in cpufreq-cpu0 driver. Fix it. > > Signed-off-by: Viresh Kumar Acked-by: Shawn Guo > --- > drivers/cpufreq/cpufreq-cpu0.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c > index 31282fc..3ab8294 100644 > --- a/drivers/cpufreq/cpufreq-cpu0.c > +++ b/drivers/cpufreq/cpufreq-cpu0.c > @@ -257,6 +257,7 @@ static int cpu0_cpufreq_probe(struct platform_device > *pdev) > } > > of_node_put(np); > + of_node_put(parent); > return 0; > > out_free_table: > -- > 1.7.12.rc2.18.g61b472e > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/20] ARM: mxs: Remove init_irq declaration in machine description
On Tue, May 14, 2013 at 05:38:49PM +0200, Maxime Ripard wrote:
> Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> specified") removed the need to explictly setup the init_irq field in
> the machine description when using only irqchip_init. Remove that
> declaration for mxs as well.
>
> Signed-off-by: Maxime Ripard
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] can: flexcan: allow compilation on arm and powerpc
Hi Marc,
On Thu, May 16, 2013 at 03:42:36PM +0200, Marc Kleine-Budde wrote:
> This patch removes the Kconfig symbols HAVE_CAN_FLEXCAN and
> IMX_HAVE_PLATFORM_FLEXCAN from arch/{arm,powerpc} and allowing compilation on
> all arm and powerpc platforms.
I'm generally fine with the approach. But with Kconfig symbol
IMX_HAVE_PLATFORM_FLEXCAN removed, how does the build of
platform-flexcan.o work?
arch/arm/mach-imx/devices/Makefile:obj-$(CONFIG_IMX_HAVE_PLATFORM_FLEXCAN) +=
platform-flexcan.o
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] can: flexcan: remove HAVE_CAN_FLEXCAN Kconfig symbol
On Fri, May 17, 2013 at 10:59:17AM +0200, Marc Kleine-Budde wrote:
> This patch removes the Kconfig symbol HAVE_CAN_FLEXCAN from arch/{arm,powerpc}
> and allowing compilation unconditionally on all arm and powerpc platforms.
>
> This brings a bigger compile time coverage and removes the following
> dependency
> warning found by Arnd Bergmann:
>
> warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 &&
> IMX_HAVE_PLATFORM_FLEXCAN &&
> SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
> which has unmet direct dependencies (NET && CAN && CAN_DEV)
>
> Cc: Arnd Bergmann
> Cc: Shawn Guo
Acked-by: Shawn Guo
> Cc: Sascha Hauer
> Cc: Kumar Gala
> Cc: U Bhaskar-B22300
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Marc Kleine-Budde
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] clocksource: add MVF600 pit timer support
On Thu, May 16, 2013 at 02:15:24PM +0800, Jingchang Lu wrote:
> Add Freescale Vybrid MVF600 period interrupt timer support.
>
> Signed-off-by: Jingchang Lu
> ---
> v3:
> move the pit driver to drivers/clocksource.
>
> drivers/clocksource/Kconfig| 5 +
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/mvf600_pit_timer.c | 224
> +
This is a driver for PIT, a timer IP block found on mvf family. Even
though we prefer to use particular SoC name to specify the compatibility
and version of the block, all the versions of the IP block should be
ideally supported by single PIT driver. This is just like we have
drivers spi-imx and i2c-imx support all SPI and I2C controllers found on
IMX SoCs.
That said, I suggest you use family name "mvf" to name the driver,
Kconfig symbol etc. and use "mvf600" only in compatible string.
> 3 files changed, 230 insertions(+)
> create mode 100644 drivers/clocksource/mvf600_pit_timer.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index f151c6c..2808a76 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -85,3 +85,8 @@ config CLKSRC_SAMSUNG_PWM
> Samsung S3C, S5P and Exynos SoCs, replacing an earlier driver
> for all devicetree enabled platforms. This driver will be
> needed only on systems that do not have the Exynos MCT available.
> +
> +config MVF600_PIT_TIMER
> + bool
> + help
> + Support for Period Interrupt Timer on Freescale Vybrid MVF600 SoC.
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index 8d979c7..f471ca3 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_ARCH_BCM) += bcm_kona_timer.o
> obj-$(CONFIG_CADENCE_TTC_TIMER) += cadence_ttc_timer.o
> obj-$(CONFIG_CLKSRC_EXYNOS_MCT) += exynos_mct.o
> obj-$(CONFIG_CLKSRC_SAMSUNG_PWM) += samsung_pwm_timer.o
> +obj-$(CONFIG_MVF600_PIT_TIMER) += mvf600_pit_timer.o
>
> obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
> obj-$(CONFIG_CLKSRC_METAG_GENERIC) += metag_generic.o
> diff --git a/drivers/clocksource/mvf600_pit_timer.c
> b/drivers/clocksource/mvf600_pit_timer.c
> new file mode 100644
> index 000..74f7963
> --- /dev/null
> +++ b/drivers/clocksource/mvf600_pit_timer.c
> @@ -0,0 +1,224 @@
> +/*
> + * Copyright 2012-2013 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * 8 timers: pit0 - pit7,
> + * Each takes 0x10 Bytes register sapce
s/sapce/space
> + */
> +#define PITMCR 0x00
> +#define PIT0_OFFSET 0x100
> +#define PITn_OFFSET(n) (PIT0_OFFSET + 0x10 * (n))
> +#define PITLDVAL 0x00
> +#define PITCVAL 0x04
> +#define PITTCTRL 0x08
> +#define PITTFLG 0x0c
> +
> +#define PITTCTRL_TEN (0x1 << 0)
> +#define PITTCTRL_TIE (0x1 << 1)
> +#define PITCTRL_CHN (0x1 << 2)
Use space than tab between "#define" and macro name.
> +
> +#define PITTFLG_TIF 0x1
> +
> +static struct clock_event_device clockevent_pit;
> +static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_UNUSED;
> +
> +static void __iomem *clksrc_base;
> +static void __iomem *clkevt_base;
> +static void __iomem *sched_clock_reg;
> +static unsigned long pit_cycle_per_jiffy;
> +
> +static inline void pit_timer_enable(void)
> +{
> + __raw_writel(PITTCTRL_TEN | PITTCTRL_TIE, clkevt_base + PITTCTRL);
> +}
> +
> +static inline void pit_timer_disable(void)
> +{
> + __raw_writel(0, clkevt_base + PITTCTRL);
> +}
> +
> +static inline void pit_irq_disable(void)
> +{
> + unsigned long val;
> +
> + val = __raw_readl(clkevt_base + PITTCTRL);
> + val &= ~PITTCTRL_TIE;
> + __raw_writel(val, clkevt_base + PITTCTRL);
> +}
> +
> +static inline void pit_irq_enable(void)
> +{
> + unsigned long val;
> +
> + val = __raw_readl(clkevt_base + PITTCTRL);
> + val |= PITTCTRL_TIE;
> + __raw_writel(val, clkevt_base + PITTCTRL);
> +}
> +
> +static void pit_irq_acknowledge(void)
> +{
> + __raw_writel(PITTFLG_TIF, clkevt_base + PITTFLG);
> +}
> +
> +static unsigned int pit_read_sched_clock(void)
> +{
> + return __raw_readl(sched_clock_reg);
> +}
> +
> +
> +static int __init pit_clocksource_init(struct clk *pit_clk)
> +{
> + unsigned int c = clk_get_rate(pit_clk);
> +
> + sched_clock_reg = clksrc_base + PITCVAL;
> +
> + setup_sched_clock(pit_read_sched_clock, 32, c);
> + return clocksource_mmio_init(clksrc_base + PITCVAL, "mvf600-pit", c,
> + 300, 32, clo
Re: [PATCH v3] clocksource: add MVF600 pit timer support
On Mon, May 20, 2013 at 03:08:54AM +, Lu Jingchang-B35083 wrote: > [Lu Jingchang-B35083] > I am not sure MVF5xx and MVF7xx have the same PIT block, if you have > information that it is the same on other Vybrid SoCs, it is ok to change the > driver name to mvf. Thanks! Even the PIT block on other Vybrid SoCs have differences from the one integrated on mvf600, we can handle them using device tree compatible string. And that's why we need to encode SoC name in compatible. > [Lu Jingchang-B35083] > PIT0 and PIT1 can be chained to build a 64-bit timer, so PIT2 and PIT3 are > selected as the clocksource and clockevent device, and leave PIT0 and PIT1 > unused for anyone else who needs them. Thanks! This could be an useful info to be in the comment. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] imx-drm: imx-tve: Check the return value of 'regulator_enable()'
On Mon, May 20, 2013 at 10:55:49AM -0300, Fabio Estevam wrote:
> Check the return value of 'regulator_enable()' to fix the following build
> error:
>
s/error/warning
It may be helpful to mention that the warning shows up since commit
c8801a8 (regulator: core: Mark all get and enable calls as
__must_check).
Other than these,
Acked-by: Shawn Guo
> drivers/staging/imx-drm/imx-tve.c: In function 'imx_tve_probe':
> drivers/staging/imx-drm/imx-tve.c:671:19: warning: ignoring return value of
> 'regulator_enable', declared with attribute warn_unused_result
> [-Wunused-result]
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/staging/imx-drm/imx-tve.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/imx-drm/imx-tve.c
> b/drivers/staging/imx-drm/imx-tve.c
> index a6efa8f6..ce65ad3 100644
> --- a/drivers/staging/imx-drm/imx-tve.c
> +++ b/drivers/staging/imx-drm/imx-tve.c
> @@ -668,7 +668,9 @@ static int imx_tve_probe(struct platform_device *pdev)
> tve->dac_reg = devm_regulator_get(&pdev->dev, "dac");
> if (!IS_ERR(tve->dac_reg)) {
> regulator_set_voltage(tve->dac_reg, 275, 275);
> - regulator_enable(tve->dac_reg);
> + ret = regulator_enable(tve->dac_reg);
> + if (ret)
> + return ret;
> }
>
> tve->clk = devm_clk_get(&pdev->dev, "tve");
> --
> 1.8.1.2
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] imx-drm: imx-tve: Let device core handle pinctrl
On Mon, May 20, 2013 at 10:55:50AM -0300, Fabio Estevam wrote: > Since commit ab78029 (drivers/pinctrl: grab default handles from device core) > we can rely on device core for handling pinctrl, so remove > devm_pinctrl_get_select_default() from the driver. > > Signed-off-by: Fabio Estevam Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] imx-drm: parallel-display: Let device core handle pinctrl
On Mon, May 20, 2013 at 10:55:51AM -0300, Fabio Estevam wrote: > Since commit ab78029 (drivers/pinctrl: grab default handles from device core) > we can rely on device core for handling pinctrl, so remove > devm_pinctrl_get_select_default() from the driver. > > Signed-off-by: Fabio Estevam Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] drivers: bus: add a new driver for WEIM
On Mon, May 20, 2013 at 04:48:57PM +0800, Huang Shijie wrote:
> The WEIM(Wireless External Interface Module) works like a bus.
> You can attach many different devices on it, such as NOR, onenand.
>
> In the case of i.MX6q-sabreauto, the NOR is connected to WEIM.
>
> This patch also adds the devicetree binding document.
> The driver only works when the devicetree is enabled.
>
> Signed-off-by: Huang Shijie
> ---
> Documentation/devicetree/bindings/bus/imx-weim.txt | 69 +
> drivers/bus/Kconfig|9 ++
> drivers/bus/Makefile |1 +
> drivers/bus/imx-weim.c | 145
>
> 4 files changed, 224 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/bus/imx-weim.txt
> create mode 100644 drivers/bus/imx-weim.c
>
> diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt
> b/Documentation/devicetree/bindings/bus/imx-weim.txt
> new file mode 100644
> index 000..9913454
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
> @@ -0,0 +1,69 @@
> +Device tree bindings for i.MX Wireless External Interface Module (WEIM)
> +
> +The term ???wireless??? does not imply that the WEIM is literally an
> interface
"wireless"
> +without wires. It simply means that this module was originally designed for
> +wireless and mobile applications that use low-power technology.
> +
> +The actual devices are instantiated from the child nodes of a WEIM node.
> +But now we only have the NOR device.
> +
> +NOR flash connected to the WEIM (found on i.MX boards) are represented as
> +child nodes with a name of "nor".
I doubt that WEIM should care the particular device type connected on
it.
> +
> +Required properties:
> +
> + - compatible: Should be set to "fsl, imx6q-weim"
Drop the space in middle of compatible string.
> + - reg: A resource specifier for the register space
> + (see the example below)
> + - interrupts: the interrupt number, see the example below.
> + - clocks: the clock, see the example below.
> + - #address-cells: Must be set to 2 to allow memory address translation
> + - #size-cells: Must be set to 1 to allow CS address passing
> + - ranges: Must be set up to reflect the memory layout with four
> + integer values for each chip-select line in use:
> +
> + 0
> +
> +Timing properties for child nodes. All are mandatory, not optional.
> +
> + -weim-cs-index: The CS index which the device is attaching on.
It seems we can find it out from "reg" property, so that we can save
this property?
> + -weim-cs-timing:The timing array, contains 6 timing values for the
> + weim-cs-index.
This is a vendor specific property, and should have a vendor (fsl)
perfix. Also please put a space after the first "-" which acts as
a bullet symbol here.
> +
> +Example for an i.MX6q-sabreauto board:
You can write it as i.MX6Q SABRE Auto or imx6q-sabreauto.
> + weim: weim@021b8000 {
> + compatible = "fsl,imx6q-weim";
> + reg = <0x021b8000 0x4000>;
> + interrupts = <0 14 0x04>;
> + clocks = <&clks 196>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0 0 0x0800 0x0800>;
> +
> + nor@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 0x0200>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + bank-width = <2>;
> +
> + weim-cs-index = <0>;
> + weim-cs-timing = <0x00620081 0x0001 0x1C022000
> + 0xC000 0x1404a38e 0x>;
> + partition@0 {
> + label = "U-Boot";
> + reg = <0x0 0x4>;
> + };
> +
> + partition@4 {
> + label = "U-Boot-ENV";
> + reg = <0x4 0x1>;
> + read-only;
> + };
> +
> + partition@5 {
> + label = "Kernel";
> + reg = <0x5 0x3b>;
> + };
> + };
> + };
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index b05ecab..0f997af 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -4,6 +4,15 @@
>
> menu "Bus devices"
>
> +config IMX_WEIM
> + tristate "Freescale EIM DRIVER"
> + depends on ARCH_MXC && MTD_PHYSMAP_OF
I do not see how this driver depends on MTD_PHYSMAP_OF.
> + help
> + Driver for i.MX6 WEIM controller.
> + The WEIM(Wireless External Interface Module)
Re: [PATCH 2/6] ARM: dts: imx6q{dl}: fix the pin conflict between SPI and WEIM
On Mon, May 20, 2013 at 04:48:58PM +0800, Huang Shijie wrote:
> In the imx6q-sabreauto and imx6dl-sabreauto boards,
> the pin MX6Q{DL}_PAD_EIM_D19 is used as a GPIO for SPI NOR, but
> it is used as a data pin for the WEIM NOR.
>
> In order to fix the conflict, this patch removes the pin from the hog,
> and adds a new pinctrl item: pinctrl_ecspi1_2.
>
> The SPI NOR selects this pinctrl_ecspi1_2 when it is enabled.
>
> Signed-off-by: Huang Shijie
> ---
> arch/arm/boot/dts/imx6dl-sabreauto.dts |9 -
> arch/arm/boot/dts/imx6q-sabreauto.dts|9 -
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi |2 +-
> 3 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6dl-sabreauto.dts
> b/arch/arm/boot/dts/imx6dl-sabreauto.dts
> index 60f3038..7695f70 100644
> --- a/arch/arm/boot/dts/imx6dl-sabreauto.dts
> +++ b/arch/arm/boot/dts/imx6dl-sabreauto.dts
> @@ -25,7 +25,14 @@
> fsl,pins = <
> MX6DL_PAD_NANDF_CS2__GPIO6_IO15 0x8000
> MX6DL_PAD_SD2_DAT2__GPIO1_IO13 0x8000
> - MX6DL_PAD_EIM_D19__GPIO3_IO19 0x8000
> + >;
> + };
> + };
> +
> + ecspi1 {
> + pinctrl_ecspi1_2: ecspi1grp-2 {
The naming sounds like another ecspi1 pin groups beside
pinctrl_ecspi1_1, both of which should be ecspi1 pin groups defined by
SoC. Please encode the board name in there to suggest this is a board
specific pin setup for ecspi1, something like pinctrl_ecspi1_sabreauto.
Shawn
> + fsl,pins = <
> + MX6DL_PAD_EIM_D19__GPIO3_IO19 0x8000
> >;
> };
> };
> diff --git a/arch/arm/boot/dts/imx6q-sabreauto.dts
> b/arch/arm/boot/dts/imx6q-sabreauto.dts
> index 9fb3e99..67a3a6b 100644
> --- a/arch/arm/boot/dts/imx6q-sabreauto.dts
> +++ b/arch/arm/boot/dts/imx6q-sabreauto.dts
> @@ -29,7 +29,14 @@
> fsl,pins = <
> MX6Q_PAD_NANDF_CS2__GPIO6_IO15 0x8000
> MX6Q_PAD_SD2_DAT2__GPIO1_IO13 0x8000
> - MX6Q_PAD_EIM_D19__GPIO3_IO19 0x8000
> + >;
> + };
> + };
> +
> + ecspi1 {
> + pinctrl_ecspi1_2: ecspi1grp-2 {
> + fsl,pins = <
> + MX6Q_PAD_EIM_D19__GPIO3_IO19 0x8000
> >;
> };
> };
> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> index d6baa51..eb293f5 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -20,7 +20,7 @@
> fsl,spi-num-chipselects = <1>;
> cs-gpios = <&gpio3 19 0>;
> pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_ecspi1_1>;
> + pinctrl-0 = <&pinctrl_ecspi1_1 &pinctrl_ecspi1_2>;
> status = "disabled"; /* pin conflict with WEIM NOR */
>
> flash: m25p80@0 {
> --
> 1.7.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
