* [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
From: Philip Rakity @ 2012-10-23 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350976740-19284-3-git-send-email-pkunapuli@nvidia.com>
On 23 Oct 2012, at 09:19, Pavan Kunapuli <pkunapuli@nvidia.com> wrote:
> vmmc and vqmmc regulators control the voltage to
> the host and device. Defer the probe if either of
> them is not registered.
>
> Signed-off-by: Pavan Kunapuli <pkunapuli@nvidia.com>
> ---
> drivers/mmc/host/sdhci.c | 25 ++++++++++++++++++++++---
> 1 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 7922adb..925c403 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
> !(host->mmc->caps & MMC_CAP_NONREMOVABLE))
> mmc->caps |= MMC_CAP_NEEDS_POLL;
>
> - /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
> + /*
> + * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
> + * vqmmc regulator should be present. If it's not present,
> + * assume the regulator driver registration is not yet done and
> + * defer the probe.
> + */
> host->vqmmc = regulator_get(mmc_dev(mmc), "vqmmc");
> if (IS_ERR(host->vqmmc)) {
> - pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> + pr_err("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> host->vqmmc = NULL;
> + return -EPROBE_DEFER;
Some systems exist where vmmc regulator exists and vqmmc regulator does not. The vmmc regular is fixed at 3.3v.
Deferring the probe will cause issues.
> }
> else if (regulator_is_supported_voltage(host->vqmmc, 1800000, 1800000))
> regulator_enable(host->vqmmc);
> @@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
>
> ocr_avail = 0;
>
> + /*
> + * vmmc regulator should be present. If it's not present,
> + * assume the regulator driver registration is not yet done
> + * and defer the probe.
> + */
> host->vmmc = regulator_get(mmc_dev(mmc), "vmmc");
> if (IS_ERR(host->vmmc)) {
> - pr_info("%s: no vmmc regulator found\n", mmc_hostname(mmc));
> + pr_err("%s: no vmmc regulator found\n", mmc_hostname(mmc));
> host->vmmc = NULL;
> + ret = -EPROBE_DEFER;
> + goto vmmc_err;
> } else
> regulator_enable(host->vmmc);
>
> @@ -3121,7 +3134,13 @@ reset:
> untasklet:
> tasklet_kill(&host->card_tasklet);
> tasklet_kill(&host->finish_tasklet);
> +vmmc_err:
> + if (host->vqmmc) {
> + if (regulator_is_enabled(host->vqmmc))
> + regulator_disable(host->vqmmc);
>
> + regulator_put(host->vqmmc);
> + }
> return ret;
> }
>
> --
> 1.7.1.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS
From: Prabhakar Lad @ 2012-10-23 13:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Lad, Prabhakar <prabhakar.lad@ti.com>
This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
out.
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
---
Changes for v2:
1: fixed code alignment as pointed by Sergei
arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 2924d61..8519d2d 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -514,7 +514,7 @@ static struct vpbe_output dm365evm_vpbe_outputs[] = {
.index = 1,
.name = "Component",
.type = V4L2_OUTPUT_TYPE_ANALOG,
- .capabilities = V4L2_OUT_CAP_CUSTOM_TIMINGS,
+ .capabilities = V4L2_OUT_CAP_DV_TIMINGS,
},
.subdev_name = VPBE_VENC_SUBDEV_NAME,
.default_mode = "480p59_94",
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/2] qt1070 & gpio_keys add pinctrl consumer
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-23 13:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The following patch series add the pinctrl support to the follwing
keybords:
- gpio_keys
- qt1070
The pinctrl is optionnal as not everyone need it
If no objection I'll apply them via at91 as I have a long patch series
of pinctrl for at91
----------------------------------------------------------------
Jean-Christophe PLAGNIOL-VILLARD (2):
input: qt1070: add pinctrl consumer
input: gpio_keys: add pinctrl consumer
drivers/input/keyboard/gpio_keys.c | 11 +++++++++++
drivers/input/keyboard/qt1070.c | 11 +++++++++++
2 files changed, 22 insertions(+)
Best Regards,
J.
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Matt Porter @ 2012-10-23 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023122436.GC1855@beef>
On Tue, Oct 23, 2012 at 08:24:36AM -0400, Matt Porter wrote:
> On Tue, Oct 23, 2012 at 03:15:44AM +0000, Paul Walmsley wrote:
> > On Mon, 22 Oct 2012, Matt Porter wrote:
> >
> > > I've mentioned this a few times in various threads...no need to use
> > > appended DTB on a current U-Boot. Some of us are indeed booting this way
> > > with the DTB properly passed separately from the bootloader and chosen
> > > filled out by the bootloader. And yes, am335x_evm_config applies to all
> > > AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
> > > that is used to determine what board is present so a single
> > > MLO/u-boot.img can be used.
> >
> > As Kevin mentioned earlier, this is unfortunately not true for those of us
> > with earlier BeagleBoards:
> >
> > http://marc.info/?l=linux-omap&m=135094296931913&w=2
>
> Yes, we spoke about this a bit.
>
> > Do you know what the minimum board revision is that you all are
> > supporting in U-boot?
>
> It's not so much a revision as it is getting the right contents in the
> EEPROM. As it's a community board, it's generally only supported over at
> beagleboard at googlegroups.com. Jason Kridner recommends posting support
> questions there (like why isn't my A2 supported in U-Boot?). If there
> isn't some solution suggested there for updating the A2 I would contact
> him directly. I have an A1 Bone here that also doesn't work with
> mainline U-Boot even after configuring the EEPROM. You can try this
> procedure if you want to write the proper contents in, an A2 may work
> but for some reason there's no available history on Bone revisions prior
> to A3. I vaguely recall a lot of chatter around the phy and so forth in
> the A1 to A2 timeframe so it's entirely possible that your A2 will work
> with just the eeprom contents programmed. Without it, it's guaranteed to
> fail as the pin muxing is tied to detecting the board this way. Also,
> you may need to change <offset>.1 in the below example to <offset>.2 for
> your eeprom i/o to work as A2 may require an address length of 2.
Ok, very quick update...no need to mess around with the eeprom. I just
received the official word on what will be supported. Since A2 is
pre-release, simply go to http://beagleboard.org/support/rma and fill
out the form to have it replaced with the current revision (A6).
This applies to *anyone* that received a pre-release A2 board.
-Matt
^ permalink raw reply
* [PATCH] Revert "spi/pl022: enable runtime PM"
From: Mark Brown @ 2012-10-23 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350994116-9127-1-git-send-email-ulf.hansson@stericsson.com>
On Tue, Oct 23, 2012 at 02:08:36PM +0200, Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> This reverts commit 2fb30d1147c599f5657e8c62c862f9a0f58d9d99.
>
> This patch introduced runtime PM issues and is not needed at all.
> Thus we should revert it.
As covered elsewhere I applied a revert myself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/41af29aa/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] Revert "spi/pl022: enable runtime PM"
From: Mark Brown @ 2012-10-23 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023114842.GA4293@n2100.arm.linux.org.uk>
On Tue, Oct 23, 2012 at 12:48:42PM +0100, Russell King - ARM Linux wrote:
> Oh, and if you're unwilling to do that, then I'm taking both of Ulf's
> patches, committing them to my fixes branch, and sending them off to
> Linus tonight - because they are _NEEDED_ for the -rc series to fix
> this driver.
As I said in my previous e-mail I've now done the revert myself; I'll
send the fixes to Linus. If you wish to check the other patches that
are queued they're in -next like I said; I'd appreciate someone who's
actively using the driver taking a look at them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/8bb0e238/attachment.sig>
^ permalink raw reply
* pxa:spitz_pm.c: commit b6eede11 breaks spitz resume under certain conditions.
From: Marko Katić @ 2012-10-23 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO9PFfHDWL6sx+4O4LYtTBXoT7QRTQq=t6YhQ+C7GT8UBQ@mail.gmail.com>
On Tue, Oct 23, 2012 at 5:10 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Fri, Oct 19, 2012 at 7:37 PM, Marko Kati? <dromede@gmail.com> wrote:
>> On Thu, Oct 18, 2012 at 11:28 AM, Marko Kati? <dromede@gmail.com> wrote:
>>>> Almost there, but I guess we could do this better and less confusing by having
>>>> another array, e.g. tosa_gpio18_config[], which is tosa specific, and only
>>>> initialize that MFP setting in the tosa path.
>>>>
>>>>>
>>>>> I also looked at the original sharp kernel sources.
>>>>> Only tosa used the RDY signal for it's tc6393tx chip, other machines simply
>>>>> configured gpio18 as output in their suspend routines.
>>>
>>>
>>> Actually, tosa doesn't use sharpsl_pm. Tosa uses the pda-power framework.
>>> I said that only tosa uses the RDY signal to point out that we
>>> probably don't need
>>> the mfp-config line in postsuspend. That being said, i still think
>>> that the array ordering
>>> fix is adequate. Maybe later we may remove the mfp-config line from
>>> postsuspend when
>>> we're absolutely sure it isn't necessary for devices that use spitz_pm.c.
>>
>> So Eric what do you think, is the simple gpio array reordering patch
>> an adequate fix for this bug?
>
> Sorry for late reply. That simple reordering still looks a bit confusing
> to me, i.e. the same pin firstly configured as GPIO then RDY. Do we
> have a less confusing way to fix this?
well, we could also remove the mfp-config line in postsuspend. I
suspect that it's only there because tosa was supposed to use
sharpsl_pm and it currently doesn't (and certainly never will). And as
i said, the original sharp kernels never did configure gpio 18 as RDY,
except for tosa.
^ permalink raw reply
* [PATCH 2/2] Revert "spi/pl022: enable runtime PM"
From: Linus Walleij @ 2012-10-23 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023114130.GW4477@opensource.wolfsonmicro.com>
On Tue, Oct 23, 2012 at 1:41 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> I have to say I had been under the impression that Linus' series that I
> applied the other day dealt with all the outstanding stuff here; the
> issues with this have been the awful changelogs and the overalapping
> sets of patches.
It did I think it was patch [1/4] (same subject as this thread),
http://sourceforge.net/mailarchive/forum.php?thread_name=1350476818-13056-1-git-send-email-linus.walleij%40stericsson.com&forum_name=spi-devel-general
to which you replied:
> This was already applied, applied the rest thanks.
So it probably wasn't and it's just some mishap so
that 2,3,4 /4 were applied while 1/4 was actually needed
to.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/4] ARM: EXYNOS: Kconfig: Group EXYNOS{4212,4412} into EXYNOS4X12
From: Kukjin Kim @ 2012-10-23 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349701345-2681-4-git-send-email-t.figa@samsung.com>
Tomasz Figa wrote:
>
> This patch adds CONFIG_EXYNOS4X12, which is automatically selected
> whenever there is at least one SoC from Exynos4x12 line enabled. All the
> shared dependencies of EXYNOS{4212,4412} are moved to this new
> option.
>
> This fixes build with Exynos4412 enabled and Exynos4212 and Exynos4210
> disabled and also allows to simplify conditional compilation in several
> places.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/mach-exynos/Kconfig | 15 +++++++++------
> arch/arm/mach-exynos/Makefile | 2 +-
> arch/arm/mach-exynos/common.h | 2 +-
> drivers/cpufreq/Kconfig.arm | 2 +-
> 4 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 9f91892..6ea95f0 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -38,22 +38,25 @@ config SOC_EXYNOS4210
> help
> Enable EXYNOS4210 CPU support
>
> -config SOC_EXYNOS4212
> - bool "SAMSUNG EXYNOS4212"
> - default y
> +config SOC_EXYNOS4X12
> + def_bool n
> select ARCH_EXYNOS4
> select SAMSUNG_DMADEV
> + select ARM_CPU_SUSPEND if PM
> select S5P_PM if PM
> select S5P_SLEEP if PM
> +
> +config SOC_EXYNOS4212
> + bool "SAMSUNG EXYNOS4212"
> + select SOC_EXYNOS4X12
> + default y
> help
> Enable EXYNOS4212 SoC support
>
> config SOC_EXYNOS4412
> bool "SAMSUNG EXYNOS4412"
> - select ARCH_EXYNOS4
> + select SOC_EXYNOS4X12
> default y
> - depends on ARCH_EXYNOS4
> - select SAMSUNG_DMADEV
> help
> Enable EXYNOS4412 SoC support
>
> diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
> index ceeb8c9..f88fcb6 100644
> --- a/arch/arm/mach-exynos/Makefile
> +++ b/arch/arm/mach-exynos/Makefile
> @@ -16,7 +16,7 @@ obj-$(CONFIG_ARCH_EXYNOS) += common.o
> obj-$(CONFIG_ARCH_EXYNOS4) += clock-exynos4.o
> obj-$(CONFIG_ARCH_EXYNOS5) += clock-exynos5.o
> obj-$(CONFIG_SOC_EXYNOS4210) += clock-exynos4210.o
> -obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o
> +obj-$(CONFIG_SOC_EXYNOS4X12) += clock-exynos4212.o
>
> obj-$(CONFIG_PM) += pm.o
> obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index 054c786..a8cb3e6 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -52,7 +52,7 @@ void exynos4210_register_clocks(void);
> #define exynos4210_register_clocks()
> #endif
>
> -#ifdef CONFIG_SOC_EXYNOS4212
> +#ifdef CONFIG_SOC_EXYNOS4X12
> void exynos4212_register_clocks(void);
>
> #else
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index ca4ede3..d0ff91a 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -66,7 +66,7 @@ config ARM_EXYNOS4210_CPUFREQ
> SoC (S5PV310 or S5PC210).
>
> config ARM_EXYNOS4X12_CPUFREQ
> - def_bool (SOC_EXYNOS4212 || SOC_EXYNOS4412)
> + def_bool SOC_EXYNOS4X12
> help
> This adds the CPUFreq driver for Samsung EXYNOS4X12
> SoC (EXYNOS4212 or EXYNOS4412).
> --
> 1.7.12
Well, do we _really_ need to define CONFIG_SOC_EXYNOS4X12 for supporting
common part of exynos4212 and exynos4412? In my opinion, it will cause
confusion rather than reducing code size. Let's just use its own name for
SoC.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] usb: remove CONFIG_USB_MUSB_HOST etc
From: Felipe Balbi @ 2012-10-23 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50868EED.7050909@ti.com>
Hi,
On Tue, Oct 23, 2012 at 06:04:53PM +0530, Sekhar Nori wrote:
> On 10/8/2012 6:47 PM, Constantine Shulyupin wrote:
> > From: Constantine Shulyupin <const@MakeLinux.com>
> >
> > Remove USB configuration in arch/arm/mach-davinci/usb.c accordingly
> > CONFIG_USB_MUSB_OTG CONFIG_USB_MUSB_PERIPHERAL CONFIG_USB_MUSB_HOST
> > and set MUSB_OTG configuration by default
> > because this configuration options are removed from Kconfig.
> >
> > Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
>
> Queuing this patch for v3.8. Since the config options are removed there
> is no use having code which refers to them. The patch has been tested on
> DM644x and DM365 in both host and gadget mode (I will add this
> information to commit text while committing). Without this patch .mode
> seems to be defaulting to MUSB_UNDEFINED which I think is definitely wrong.
sorry for the delay, this looks ok:
Acked-by: Felipe Balbi <balbi@ti.com>
>
> Thanks,
> Sekhar
>
> >
> > ---
> > arch/arm/mach-davinci/usb.c | 6 ------
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c
> > index f77b953..34509ff 100644
> > --- a/arch/arm/mach-davinci/usb.c
> > +++ b/arch/arm/mach-davinci/usb.c
> > @@ -42,14 +42,8 @@ static struct musb_hdrc_config musb_config = {
> > };
> >
> > static struct musb_hdrc_platform_data usb_data = {
> > -#if defined(CONFIG_USB_MUSB_OTG)
> > /* OTG requires a Mini-AB connector */
> > .mode = MUSB_OTG,
> > -#elif defined(CONFIG_USB_MUSB_PERIPHERAL)
> > - .mode = MUSB_PERIPHERAL,
> > -#elif defined(CONFIG_USB_MUSB_HOST)
> > - .mode = MUSB_HOST,
> > -#endif
> > .clock = "usb",
> > .config = &musb_config,
> > };
> >
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/5395fac4/attachment.sig>
^ permalink raw reply
* [PATCH RESEND 0/9] ARM: davinci: DT boot support for DA850
From: Sekhar Nori @ 2012-10-23 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347467732-1332-1-git-send-email-nsekhar@ti.com>
On 9/12/2012 10:05 PM, Sekhar Nori wrote:
> This series adds basic DT boot support for DA850 EVM and EnBW CMC board.
> It applies to master branch of Linux DaVinci tree[1].
>
> Resending this because I missed copying the DT and Documentation folks
> last time around. Sorry about that. There is no change in patch contents.
I will be queuing these patches for inclusion in v3.8.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/4] ARM: EXYNOS: Kconfig: Sort out dependencies between options
From: Kukjin Kim @ 2012-10-23 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349701345-2681-3-git-send-email-t.figa@samsung.com>
Tomasz Figa wrote:
>
> This patch modifies the dependencies between Exynos-related Kconfig
> options to represent the real dependencies between code units more
> closely.
>
> Originally it was possible to enable ARCH_EXYNOS{4,5} without any
> SOC_EXYNOS_{4,5}.* enabled, which could end with compilation or link
> errors. Now ARCH_EXYNOS{4,5} is only selected when there is a
> SOC_EXYNOS_{4,5}.* enabled, which requires it.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/mach-exynos/Kconfig | 15 ++++++---------
> drivers/devfreq/Kconfig | 2 +-
> drivers/mmc/host/sdhci-s3c.c | 2 +-
> drivers/tty/serial/samsung.c | 3 +--
> 4 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 05dcd07..9f91892 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -12,15 +12,14 @@ if ARCH_EXYNOS
> menu "SAMSUNG EXYNOS SoCs Support"
>
> config ARCH_EXYNOS4
> - bool "SAMSUNG EXYNOS4"
> - default y
> + def_bool n
> select HAVE_SMP
> select MIGHT_HAVE_CACHE_L2X0
> help
> Samsung EXYNOS4 SoCs based systems
>
> config ARCH_EXYNOS5
> - bool "SAMSUNG EXYNOS5"
> + def_bool n
> select HAVE_SMP
> help
> Samsung EXYNOS5 (Cortex-A15) SoC based systems
> @@ -30,7 +29,7 @@ comment "EXYNOS SoCs"
> config SOC_EXYNOS4210
> bool "SAMSUNG EXYNOS4210"
> default y
> - depends on ARCH_EXYNOS4
> + select ARCH_EXYNOS4
> select SAMSUNG_DMADEV
> select ARM_CPU_SUSPEND if PM
> select S5P_PM if PM
> @@ -42,7 +41,7 @@ config SOC_EXYNOS4210
> config SOC_EXYNOS4212
> bool "SAMSUNG EXYNOS4212"
> default y
> - depends on ARCH_EXYNOS4
> + select ARCH_EXYNOS4
> select SAMSUNG_DMADEV
> select S5P_PM if PM
> select S5P_SLEEP if PM
> @@ -51,6 +50,7 @@ config SOC_EXYNOS4212
>
> config SOC_EXYNOS4412
> bool "SAMSUNG EXYNOS4412"
> + select ARCH_EXYNOS4
> default y
> depends on ARCH_EXYNOS4
> select SAMSUNG_DMADEV
> @@ -60,7 +60,7 @@ config SOC_EXYNOS4412
> config SOC_EXYNOS5250
> bool "SAMSUNG EXYNOS5250"
> default y
> - depends on ARCH_EXYNOS5
> + select ARCH_EXYNOS5
> select SAMSUNG_DMADEV
> select S5P_PM if PM
> select S5P_SLEEP if PM
> @@ -176,8 +176,6 @@ config EXYNOS_SETUP_SPI
>
Basically, I agree with your approach. Its CONFIG_ARCH_EXYNOSx depends on
selecting own SOC.
BTW, I'm thinking, which one selecting is better to us board? Or SoC?...
> # machine support
>
> -if ARCH_EXYNOS4
> -
Well, according to removing above, we can select following exynos4210 boards
on other stuff. Of course, when select board, regarding soc is selected
though. So I'm thinking I said as above.
> comment "EXYNOS4210 Boards"
>
> config MACH_SMDKC210
> @@ -397,7 +395,6 @@ config MACH_SMDK4412
> select MACH_SMDK4212
> help
> Machine support for Samsung SMDK4412
> -endif
>
> comment "Flattened Device Tree based board for EXYNOS SoCs"
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 8545069..c559609 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -67,7 +67,7 @@ comment "DEVFREQ Drivers"
>
> config ARM_EXYNOS4_BUS_DEVFREQ
> bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
> - depends on SOC_EXYNOS4210 || CPU_EXYNOS4212 || CPU_EXYNOS4412
> + depends on ARCH_EXYNOS4
I don't think so, because it depends on SoC not architecture. In addition,
we don't know ARM_EXYNOS4_BUS_DEVFREQ is available on upcoming exynos4...
> select ARCH_HAS_OPP
> select DEVFREQ_GOV_SIMPLE_ONDEMAND
> help
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index b090415..5e2083b 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -716,7 +716,7 @@ static const struct dev_pm_ops sdhci_s3c_pmops = {
> #define SDHCI_S3C_PMOPS NULL
> #endif
>
> -#if defined(CONFIG_SOC_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212)
> +#if defined(CONFIG_ARCH_EXYNOS4)
Same as above.
> static struct sdhci_s3c_drv_data exynos4_sdhci_drv_data = {
> .sdhci_quirks = SDHCI_QUIRK_NONSTANDARD_CLOCK,
> };
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index 175ba6e..c689091 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -1594,8 +1594,7 @@ static struct s3c24xx_serial_drv_data
> s5pv210_serial_drv_data = {
> #define S5PV210_SERIAL_DRV_DATA (kernel_ulong_t)NULL
> #endif
>
> -#if defined(CONFIG_SOC_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212) || \
> - defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250)
> +#if defined(CONFIG_ARCH_EXYNOS4) || defined(CONFIG_ARCH_EXYNOS5)
Same as above.
> static struct s3c24xx_serial_drv_data exynos4210_serial_drv_data = {
> .info = &(struct s3c24xx_uart_info) {
> .name = "Samsung Exynos4 UART",
> --
> 1.7.12
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] usb: remove CONFIG_USB_MUSB_HOST etc
From: Sekhar Nori @ 2012-10-23 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349702227-24875-1-git-send-email-const@MakeLinux.com>
On 10/8/2012 6:47 PM, Constantine Shulyupin wrote:
> From: Constantine Shulyupin <const@MakeLinux.com>
>
> Remove USB configuration in arch/arm/mach-davinci/usb.c accordingly
> CONFIG_USB_MUSB_OTG CONFIG_USB_MUSB_PERIPHERAL CONFIG_USB_MUSB_HOST
> and set MUSB_OTG configuration by default
> because this configuration options are removed from Kconfig.
>
> Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
Queuing this patch for v3.8. Since the config options are removed there
is no use having code which refers to them. The patch has been tested on
DM644x and DM365 in both host and gadget mode (I will add this
information to commit text while committing). Without this patch .mode
seems to be defaulting to MUSB_UNDEFINED which I think is definitely wrong.
Thanks,
Sekhar
>
> ---
> arch/arm/mach-davinci/usb.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c
> index f77b953..34509ff 100644
> --- a/arch/arm/mach-davinci/usb.c
> +++ b/arch/arm/mach-davinci/usb.c
> @@ -42,14 +42,8 @@ static struct musb_hdrc_config musb_config = {
> };
>
> static struct musb_hdrc_platform_data usb_data = {
> -#if defined(CONFIG_USB_MUSB_OTG)
> /* OTG requires a Mini-AB connector */
> .mode = MUSB_OTG,
> -#elif defined(CONFIG_USB_MUSB_PERIPHERAL)
> - .mode = MUSB_PERIPHERAL,
> -#elif defined(CONFIG_USB_MUSB_HOST)
> - .mode = MUSB_HOST,
> -#endif
> .clock = "usb",
> .config = &musb_config,
> };
>
^ permalink raw reply
* [PATCH 2/2] Revert "spi/pl022: enable runtime PM"
From: Mark Brown @ 2012-10-23 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023114723.GU21164@n2100.arm.linux.org.uk>
On Tue, Oct 23, 2012 at 12:47:23PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 23, 2012 at 12:41:31PM +0100, Mark Brown wrote:
> > I have to say I had been under the impression that Linus' series that I
> > applied the other day dealt with all the outstanding stuff here; the
> > issues with this have been the awful changelogs and the overalapping
> > sets of patches.
> Given that Linus is the one who introduced the fuckups in the first place,
> and afaics Linus' series has not been posted anywhere I can see, and I
> have been through the issues and worked with Ulf to get them fixed, I find
> that to be down right insulting by you.
Linus' patches were all posted to spi-devel-general. I can understand
why you wouldn't subscribe to it given that it's a sourceforge list and
hence full of spam but it is the list of record for SPI unfortunately.
> You received *BOTH* of Ulf's patches on the 5th October. Both needed
> to be applied *TOGETHER* to reduce the window where things got worse
> before they got better. But for some goddamned unknown reason you decided
> to only take the first but totally and utterly ignored the second.
Unfortunately Ulf's original posting of the patches didn't include any
analysis of the problems or explanation as to why the reverts were
needed. Since I had no idea what the patches were supposed to do having
not been involved in whatever discussion of the bugs were I didn't apply
them then.
Ulf did repost with a slightly clarified changelog and I *suspect* that
the second patch just got fat fingered due to the multiple different
revisions of the series that were floating around.
> Well done, you've probably crapped this driver up again. Way to go Mark.
> Now, tell us _exactly_ what patches you've applied to this driver. Post
> them to this mailing list so we can see them, and see what state this
> driver is now in.
> IMHO, you're being a terrible "maintainer" here - and this is being shown
> by the need to get you to post all the patches you've currently queued up
> for this.
As one would expect all the patches that are currently sitting there for
the driver are in -next already; one of the nice things about -next is
that it does tend to help remove doubt about things like this.
You just pointed me at the discussion of the original issue that
happened prior to Ulf's revert posting; I now see what's going on, your
analysis is crystal clear [1]. I'm just generating the extra revert of
2fb30d (spi/pl022: enable runtime PM) which I'll squash down into the
existing revert and send to Linus tomorrow.
[1] http://lists.arm.linux.org.uk/lurker/message/20120927.152412.d281a899.en.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/7acb8549/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/4] ARM: EXYNOS: Kconfig: Rename CPU_EXYNOS4210 to SOC_EXYNOS4210
From: Kukjin Kim @ 2012-10-23 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349701345-2681-2-git-send-email-t.figa@samsung.com>
Tomasz Figa wrote:
>
> This patch renames CONFIG_CPU_EXYNOS4210 to CONFIG_SOC_EXYNOS4210 to
> match the convention used by rest of Exynos SoCs and correctly represent
> the reality (Exynos4210 is a SoC, not a CPU).
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Zhang Rui <rui.zhang@intel.com>
> ---
> arch/arm/mach-exynos/Kconfig | 14 +++++++-------
> arch/arm/mach-exynos/Makefile | 2 +-
> arch/arm/mach-exynos/common.h | 2 +-
> arch/arm/plat-samsung/include/plat/cpu.h | 2 +-
> drivers/cpufreq/Kconfig.arm | 2 +-
> drivers/devfreq/Kconfig | 2 +-
> drivers/mmc/host/sdhci-s3c.c | 2 +-
> drivers/tty/serial/samsung.c | 2 +-
> 8 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 4372075..05dcd07 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -27,7 +27,7 @@ config ARCH_EXYNOS5
>
> comment "EXYNOS SoCs"
>
> -config CPU_EXYNOS4210
> +config SOC_EXYNOS4210
> bool "SAMSUNG EXYNOS4210"
> default y
> depends on ARCH_EXYNOS4
> @@ -188,7 +188,7 @@ config MACH_SMDKC210
>
> config MACH_SMDKV310
> bool "SMDKV310"
> - select CPU_EXYNOS4210
> + select SOC_EXYNOS4210
> select S5P_DEV_FIMD0
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> @@ -227,7 +227,7 @@ config MACH_SMDKV310
>
> config MACH_ARMLEX4210
> bool "ARMLEX4210"
> - select CPU_EXYNOS4210
> + select SOC_EXYNOS4210
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> select S3C_DEV_HSMMC
> @@ -241,7 +241,7 @@ config MACH_ARMLEX4210
>
> config MACH_UNIVERSAL_C210
> bool "Mobile UNIVERSAL_C210 Board"
> - select CPU_EXYNOS4210
> + select SOC_EXYNOS4210
> select S5P_HRT
> select CLKSRC_MMIO
> select HAVE_SCHED_CLOCK
> @@ -282,7 +282,7 @@ config MACH_UNIVERSAL_C210
>
> config MACH_NURI
> bool "Mobile NURI Board"
> - select CPU_EXYNOS4210
> + select SOC_EXYNOS4210
> select S5P_GPIO_INT
> select S3C_DEV_WDT
> select S3C_DEV_RTC
> @@ -323,7 +323,7 @@ config MACH_NURI
>
> config MACH_ORIGEN
> bool "ORIGEN"
> - select CPU_EXYNOS4210
> + select SOC_EXYNOS4210
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> select S3C_DEV_HSMMC
> @@ -404,7 +404,7 @@ comment "Flattened Device Tree based board for EXYNOS
> SoCs"
> config MACH_EXYNOS4_DT
> bool "Samsung Exynos4 Machine using device tree"
> depends on ARCH_EXYNOS4
> - select CPU_EXYNOS4210
> + select SOC_EXYNOS4210
> select USE_OF
> select ARM_AMBA
> select HAVE_SAMSUNG_KEYPAD if INPUT_KEYBOARD
> diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
> index 9b58024..ceeb8c9 100644
> --- a/arch/arm/mach-exynos/Makefile
> +++ b/arch/arm/mach-exynos/Makefile
> @@ -15,7 +15,7 @@ obj- :=
> obj-$(CONFIG_ARCH_EXYNOS) += common.o
> obj-$(CONFIG_ARCH_EXYNOS4) += clock-exynos4.o
> obj-$(CONFIG_ARCH_EXYNOS5) += clock-exynos5.o
> -obj-$(CONFIG_CPU_EXYNOS4210) += clock-exynos4210.o
> +obj-$(CONFIG_SOC_EXYNOS4210) += clock-exynos4210.o
> obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o
>
> obj-$(CONFIG_PM) += pm.o
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index aed2eeb..054c786 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -45,7 +45,7 @@ void exynos5_setup_clocks(void);
> #define exynos5_setup_clocks()
> #endif
>
> -#ifdef CONFIG_CPU_EXYNOS4210
> +#ifdef CONFIG_SOC_EXYNOS4210
> void exynos4210_register_clocks(void);
>
> #else
> diff --git a/arch/arm/plat-samsung/include/plat/cpu.h b/arch/arm/plat-
> samsung/include/plat/cpu.h
> index ace4451..021fff0 100644
> --- a/arch/arm/plat-samsung/include/plat/cpu.h
> +++ b/arch/arm/plat-samsung/include/plat/cpu.h
> @@ -102,7 +102,7 @@ IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID,
> EXYNOS5_SOC_MASK)
> # define soc_is_s5pv210() 0
> #endif
>
> -#if defined(CONFIG_CPU_EXYNOS4210)
> +#if defined(CONFIG_SOC_EXYNOS4210)
> # define soc_is_exynos4210() is_samsung_exynos4210()
> #else
> # define soc_is_exynos4210() 0
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 5961e64..ca4ede3 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -60,7 +60,7 @@ config ARM_EXYNOS_CPUFREQ
> If in doubt, say N.
>
> config ARM_EXYNOS4210_CPUFREQ
> - def_bool CPU_EXYNOS4210
> + def_bool SOC_EXYNOS4210
> help
> This adds the CPUFreq driver for Samsung EXYNOS4210
> SoC (S5PV310 or S5PC210).
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index f6b0a6e2..8545069 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -67,7 +67,7 @@ comment "DEVFREQ Drivers"
>
> config ARM_EXYNOS4_BUS_DEVFREQ
> bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
> - depends on CPU_EXYNOS4210 || CPU_EXYNOS4212 || CPU_EXYNOS4412
> + depends on SOC_EXYNOS4210 || CPU_EXYNOS4212 || CPU_EXYNOS4412
(+ MyungJoo Ham)
MyungJoo, should be fixed separately with this.
8<--------------------------------------
From: Kukjin Kim <kgene.kim@samsung.com>
Subject: PM / devfreq: fix the dependency for EXYNOS4212 and EXYNOS4412
The CPU_EXYNOS4212 and CPU_EXYNOS4412 should be fixed.
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index f6b0a6e2..e73cede 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -67,7 +67,7 @@ comment "DEVFREQ Drivers"
config ARM_EXYNOS4_BUS_DEVFREQ
bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
- depends on CPU_EXYNOS4210 || CPU_EXYNOS4212 || CPU_EXYNOS4412
+ depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412
select ARCH_HAS_OPP
select DEVFREQ_GOV_SIMPLE_ONDEMAND
help
8<--------------------------------------
> select ARCH_HAS_OPP
> select DEVFREQ_GOV_SIMPLE_ONDEMAND
> help
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index a50c205..b090415 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -716,7 +716,7 @@ static const struct dev_pm_ops sdhci_s3c_pmops = {
> #define SDHCI_S3C_PMOPS NULL
> #endif
>
> -#if defined(CONFIG_CPU_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212)
> +#if defined(CONFIG_SOC_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212)
> static struct sdhci_s3c_drv_data exynos4_sdhci_drv_data = {
> .sdhci_quirks = SDHCI_QUIRK_NONSTANDARD_CLOCK,
> };
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index 02d07bf..175ba6e 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -1594,7 +1594,7 @@ static struct s3c24xx_serial_drv_data
> s5pv210_serial_drv_data = {
> #define S5PV210_SERIAL_DRV_DATA (kernel_ulong_t)NULL
> #endif
>
> -#if defined(CONFIG_CPU_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212) || \
> +#if defined(CONFIG_SOC_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212) || \
> defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250)
> static struct s3c24xx_serial_drv_data exynos4210_serial_drv_data = {
> .info = &(struct s3c24xx_uart_info) {
> --
> 1.7.12
Tomasz, looks ok to me but I think, accordingly, following should be updated
together?
8<--------------------------------
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index a006f0d..3a665ff 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -2790,7 +2790,7 @@ static __init void exynos_gpiolib_attach_ofnode(struct
samsung_gpio_chip *chip,
static __init void exynos4_gpiolib_init(void)
{
-#ifdef CONFIG_CPU_EXYNOS4210
+#ifdef CONFIG_SOC_EXYNOS4210
struct samsung_gpio_chip *chip;
int i, nr_chips;
void __iomem *gpio_base1, *gpio_base2, *gpio_base3;
@@ -2887,7 +2887,7 @@ static __init void exynos4_gpiolib_init(void)
samsung_gpiolib_add_4bit_chips(exynos4_gpios_3,
nr_chips, gpio_base3);
-#if defined(CONFIG_CPU_EXYNOS4210) && defined(CONFIG_S5P_GPIO_INT)
+#if defined(CONFIG_SOC_EXYNOS4210) && defined(CONFIG_S5P_GPIO_INT)
s5p_register_gpioint_bank(IRQ_GPIO_XA, 0, IRQ_GPIO1_NR_GROUPS);
s5p_register_gpioint_bank(IRQ_GPIO_XB, IRQ_GPIO1_NR_GROUPS,
IRQ_GPIO2_NR_GROUPS);
#endif
@@ -2900,7 +2900,7 @@ err_ioremap2:
iounmap(gpio_base1);
err_ioremap1:
return;
-#endif /* CONFIG_CPU_EXYNOS4210 */
+#endif /* CONFIG_SOC_EXYNOS4210 */
}
static __init void exynos5_gpiolib_init(void)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index fd03e85..8be9282 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -728,7 +728,7 @@ static struct thermal_sensor_conf exynos_sensor_conf = {
.read_temperature = (int (*)(void *))exynos_tmu_read,
};
-#if defined(CONFIG_CPU_EXYNOS4210)
+#if defined(CONFIG_SOC_EXYNOS4210)
static struct exynos_tmu_platform_data const exynos4210_default_tmu_data =
{
.threshold = 80,
.trigger_levels[0] = 5,
8<--------------------------------
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply related
* OMAP baseline test results for v3.7-rc2
From: Matt Porter @ 2012-10-23 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210230311490.31118@utopia.booyaka.com>
On Tue, Oct 23, 2012 at 03:15:44AM +0000, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Matt Porter wrote:
>
> > I've mentioned this a few times in various threads...no need to use
> > appended DTB on a current U-Boot. Some of us are indeed booting this way
> > with the DTB properly passed separately from the bootloader and chosen
> > filled out by the bootloader. And yes, am335x_evm_config applies to all
> > AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
> > that is used to determine what board is present so a single
> > MLO/u-boot.img can be used.
>
> As Kevin mentioned earlier, this is unfortunately not true for those of us
> with earlier BeagleBoards:
>
> http://marc.info/?l=linux-omap&m=135094296931913&w=2
Yes, we spoke about this a bit.
> Do you know what the minimum board revision is that you all are
> supporting in U-boot?
It's not so much a revision as it is getting the right contents in the
EEPROM. As it's a community board, it's generally only supported over at
beagleboard at googlegroups.com. Jason Kridner recommends posting support
questions there (like why isn't my A2 supported in U-Boot?). If there
isn't some solution suggested there for updating the A2 I would contact
him directly. I have an A1 Bone here that also doesn't work with
mainline U-Boot even after configuring the EEPROM. You can try this
procedure if you want to write the proper contents in, an A2 may work
but for some reason there's no available history on Bone revisions prior
to A3. I vaguely recall a lot of chatter around the phy and so forth in
the A1 to A2 timeframe so it's entirely possible that your A2 will work
with just the eeprom contents programmed. Without it, it's guaranteed to
fail as the pin muxing is tied to detecting the board this way. Also,
you may need to change <offset>.1 in the below example to <offset>.2 for
your eeprom i/o to work as A2 may require an address length of 2.
-Matt
U-Boot 2012.10-00286-gfe27b3b (Oct 22 2012 - 16:40:21)
I2C: ready
DRAM: 256 MiB
WARNING: Caches not enabled
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
Net: PHY reset timed out
cpsw
Hit any key to stop autoboot: 0
U-Boot# i2c dev 0
Setting bus to 0
U-Boot# i2c md 50 0.1
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
U-Boot# mm.b 84000000
84000000: 55 ? aa
84000001: 51 ? 55
84000002: 16 ? 33
84000003: 00 ? ee
84000004: 40 ? 41
84000005: 94 ? 33
84000006: 28 ? 33
84000007: 41 ? 35
84000008: 11 ? 42
84000009: 55 ? 4f
8400000a: 80 ? 4e
8400000b: 8e ? 45
8400000c: 03 ? 30
8400000d: 5d ? 30
8400000e: 44 ? 41
8400000f: a0 ? 32
84000010: 46 ? .
U-Boot# i2c write 84000000 50 0.1 10
U-Boot# i2c md 50 0.1 10
0000: aa 55 33 ee 41 33 33 35 42 4f 4e 45 30 30 41 32
.U3.A335BONE00A2
U-Boot#
^ permalink raw reply
* [PATCH] Revert "spi/pl022: enable runtime PM"
From: Ulf Hansson @ 2012-10-23 12:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Ulf Hansson <ulf.hansson@linaro.org>
This reverts commit 2fb30d1147c599f5657e8c62c862f9a0f58d9d99.
This patch introduced runtime PM issues and is not needed at all.
Thus we should revert it.
Conflicts:
drivers/spi/spi-pl022.c
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
This patch is based on linux next as of 2012-10-23.
Latest patch for spi-pl022 driver was this one:
spi/pl022: add IDLE state pin management
---
drivers/spi/spi-pl022.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 0205d47..1361868 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2192,9 +2192,6 @@ pl022_probe(struct amba_device *adev, const struct amba_id *id)
printk(KERN_INFO "pl022: mapped registers from 0x%08x to %p\n",
adev->res.start, pl022->virtbase);
- pm_runtime_enable(dev);
- pm_runtime_resume(dev);
-
pl022->clk = devm_clk_get(&adev->dev, NULL);
if (IS_ERR(pl022->clk)) {
status = PTR_ERR(pl022->clk);
@@ -2298,7 +2295,6 @@ pl022_remove(struct amba_device *adev)
clk_disable(pl022->clk);
clk_unprepare(pl022->clk);
- pm_runtime_disable(&adev->dev);
amba_release_regions(adev);
tasklet_disable(&pl022->pump_transfers);
spi_unregister_master(pl022->master);
--
1.7.10
^ permalink raw reply related
* [PATCH] ARM: dts: exynos4: Enable serial controllers on Origen and SMDKV310
From: Kukjin Kim @ 2012-10-23 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16890730.oeOgcP5xf2@flatron>
Tomasz Figa wrote:
>
> However I think this should be considered a fix, because without it serial
> console on Origen and SMDKV310 will be broken.
>
Well, I couldn't find any broken due to miss this for v3.7. I think, there
is no usage of serial controller in mainline for Origen and SMDKV310 now. So
this should be queued for -next. If not, please let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v3 1/4] net/macb: fix truncate warnings
From: Lothar Waßmann @ 2012-10-23 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023.044829.1915412359769438159.davem@davemloft.net>
Hi,
David Miller writes:
> From: "David Laight" <David.Laight@ACULAB.COM>
> Date: Tue, 23 Oct 2012 09:21:11 +0100
>
> >> When building macb on x86_64 the following warnings show up:
> >> drivers/net/ethernet/cadence/macb.c: In function macb_interrupt:
> >> drivers/net/ethernet/cadence/macb.c:556:4: warning: large integer implicitly truncated to unsigned type [-Woverflow]
> > ...
> >> - macb_writel(bp, IDR, ~0UL);
> >> + macb_writel(bp, IDR, -1);
> >
> > Seems wrong to fix an error with an unsigned value
> > by using -1.
>
> -1 is equally an unsigned value of all 1's and completely legitimate.
> The correction being made here is one of size not signedness.
>
You could use '~0' (without the 'UL').
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH 03/10] tty: pxa: configure pin
From: Mark Brown @ 2012-10-23 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb+DkZbTDZamGMN+9t07kPktuA_3QtHQJFv+Vu859r7KA@mail.gmail.com>
On Tue, Oct 23, 2012 at 11:59:30AM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 11:37 AM, Mark Brown
> > On Tue, Oct 23, 2012 at 11:26:40AM +0200, Linus Walleij wrote:
> > Can we handle this with power domains - if different devices require
> > different orderings they can be placed in power domains which implement
> > the appropriate orderings for them?
> clocks, regulators, pins and all in power domains?
> Then we should rename them "device resource domains" or
> something...
We can call them Ichabod for all I care...
> I have a strong sense of system-wide all-or-nothing approaches
> to this problem.
> - Either we use "power" domains to handle every resource the
> device has.
> - Or the device driver manages it's own resources.
> I find it pretty hard to build consensus around either idea.
Well, I don't think we want all or nothing approaches here. One problem
is that we don't have a home for the SoC integration so we're trying to
shove it all into the drivers which just leads to a stack of pointless
boilerplate when the driver isn't actually doing anything beyond the
basic pattern of turning everything off when it goes idle and turning it
on again when it needs to do something. Having to open code that stuff
in the drivers and then deal with the stubbing and error handling so the
error handling in the drivers is painful. There's also another axis
where things aren't part of a SoC but are separate devices so you want
to carry things along with the driver rather than have a separate bit of
code which is required to glue things into the platform.
For example it seems fairly clear to me that things like the pinctrl
integration I see in something like sound/soc/fsl/imx-audmux.c shouldn't
really be there as we're just setting up a static configration on boot.
On the other hand where things are directly involved with the active
operation of a device like changing clock rates then clearly the driver
needs to know about and manage things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/48f227e3/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: EXYNOS: Add support for secondary CPU bring-up on Exynos4412
From: Kukjin Kim @ 2012-10-23 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1393767.3tjq8gL245@amdc1227>
Tomasz Figa wrote:
>
> Exynos4412 uses different information register for each core. This patch
> adjusts the bring-up code to take that into account.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/mach-exynos/platsmp.c | 27 +++++++++++++++++++++------
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-
> exynos/platsmp.c
> index 36c3984..816a27d 100644
> --- a/arch/arm/mach-exynos/platsmp.c
> +++ b/arch/arm/mach-exynos/platsmp.c
> @@ -34,8 +34,19 @@
>
> extern void exynos4_secondary_startup(void);
>
> -#define CPU1_BOOT_REG (samsung_rev() == EXYNOS4210_REV_1_1
? \
> - S5P_INFORM5 : S5P_VA_SYSRAM)
> +static inline void __iomem *cpu_boot_reg_base(void)
> +{
> + if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_1_1)
> + return S5P_INFORM5;
> + return S5P_VA_SYSRAM;
> +}
> +
> +static inline void __iomem *cpu_boot_reg(int cpu)
> +{
> + if (soc_is_exynos4412())
> + return cpu_boot_reg_base() + 4*cpu;
> + return cpu_boot_reg_base();
> +}
>
> /*
> * control for which core is the next to come out of the secondary
> @@ -89,6 +100,7 @@ void __cpuinit platform_secondary_init(unsigned int
cpu)
> int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> unsigned long timeout;
> + unsigned long phys_cpu = cpu_logical_map(cpu);
>
> /*
> * Set synchronisation state between this boot processor
> @@ -104,7 +116,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
> task_struct *idle)
> * Note that "pen_release" is the hardware CPU ID, whereas
> * "cpu" is Linux's internal ID.
> */
> - write_pen_release(cpu_logical_map(cpu));
> + write_pen_release(phys_cpu);
>
> if (!(__raw_readl(S5P_ARM_CORE1_STATUS) & S5P_CORE_LOCAL_PWR_EN)) {
> __raw_writel(S5P_CORE_LOCAL_PWR_EN,
> @@ -138,7 +150,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
> task_struct *idle)
> smp_rmb();
>
> __raw_writel(virt_to_phys(exynos4_secondary_startup),
> - CPU1_BOOT_REG);
> +
cpu_boot_reg(phys_cpu));
> gic_raise_softirq(cpumask_of(cpu), 1);
>
> if (pen_release == -1)
> @@ -186,6 +198,8 @@ void __init smp_init_cpus(void)
>
> void __init platform_smp_prepare_cpus(unsigned int max_cpus)
> {
> + int i;
> +
> if (!soc_is_exynos5250())
> scu_enable(scu_base_addr());
>
> @@ -195,6 +209,7 @@ void __init platform_smp_prepare_cpus(unsigned int
> max_cpus)
> * until it receives a soft interrupt, and then the
> * secondary CPU branches to this address.
> */
> - __raw_writel(virt_to_phys(exynos4_secondary_startup),
> - CPU1_BOOT_REG);
> + for (i = 1; i < max_cpus; ++i)
> + __raw_writel(virt_to_phys(exynos4_secondary_startup),
> + cpu_boot_reg(cpu_logical_map(i)));
> }
> --
> 1.7.12
Looks ok to me, applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 2/2] Revert "spi/pl022: enable runtime PM"
From: Russell King - ARM Linux @ 2012-10-23 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023114723.GU21164@n2100.arm.linux.org.uk>
On Tue, Oct 23, 2012 at 12:47:23PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 23, 2012 at 12:41:31PM +0100, Mark Brown wrote:
> > On Tue, Oct 23, 2012 at 12:16:56PM +0100, Russell King - ARM Linux wrote:
> > > On Tue, Oct 23, 2012 at 12:10:19PM +0100, Mark Brown wrote:
> >
> > > > I *really* should not need to remind you to:
> >
> > > > - Not top post
> > > > - Send patches in a form which can be applied if you want them applying
> >
> > > How about actually applying the damned patch from the two-part patch set,
> > > rather than only the first, both of which has been around for almost a
> > > month now, and fixes what should never have gone into mainline in the
> > > first place?
> >
> > Well, the reason for the second point is that I don't have a copy of the
> > patch any more, I need a copy of it before I can do anything. Half the
> > reason these contentless top posts are annoying is that even if there's
> > something to do it's not actionable.
> >
> > I have to say I had been under the impression that Linus' series that I
> > applied the other day dealt with all the outstanding stuff here; the
> > issues with this have been the awful changelogs and the overalapping
> > sets of patches.
>
> Given that Linus is the one who introduced the fuckups in the first place,
> and afaics Linus' series has not been posted anywhere I can see, and I
> have been through the issues and worked with Ulf to get them fixed, I find
> that to be down right insulting by you.
>
> You received *BOTH* of Ulf's patches on the 5th October. Both needed
> to be applied *TOGETHER* to reduce the window where things got worse
> before they got better. But for some goddamned unknown reason you decided
> to only take the first but totally and utterly ignored the second.
>
> Well done, you've probably crapped this driver up again. Way to go Mark.
> Now, tell us _exactly_ what patches you've applied to this driver. Post
> them to this mailing list so we can see them, and see what state this
> driver is now in.
>
> IMHO, you're being a terrible "maintainer" here - and this is being shown
> by the need to get you to post all the patches you've currently queued up
> for this.
Oh, and if you're unwilling to do that, then I'm taking both of Ulf's
patches, committing them to my fixes branch, and sending them off to
Linus tonight - because they are _NEEDED_ for the -rc series to fix
this driver.
^ permalink raw reply
* [PATCH 2/2] Revert "spi/pl022: enable runtime PM"
From: Russell King - ARM Linux @ 2012-10-23 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023114130.GW4477@opensource.wolfsonmicro.com>
On Tue, Oct 23, 2012 at 12:41:31PM +0100, Mark Brown wrote:
> On Tue, Oct 23, 2012 at 12:16:56PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Oct 23, 2012 at 12:10:19PM +0100, Mark Brown wrote:
>
> > > I *really* should not need to remind you to:
>
> > > - Not top post
> > > - Send patches in a form which can be applied if you want them applying
>
> > How about actually applying the damned patch from the two-part patch set,
> > rather than only the first, both of which has been around for almost a
> > month now, and fixes what should never have gone into mainline in the
> > first place?
>
> Well, the reason for the second point is that I don't have a copy of the
> patch any more, I need a copy of it before I can do anything. Half the
> reason these contentless top posts are annoying is that even if there's
> something to do it's not actionable.
>
> I have to say I had been under the impression that Linus' series that I
> applied the other day dealt with all the outstanding stuff here; the
> issues with this have been the awful changelogs and the overalapping
> sets of patches.
Given that Linus is the one who introduced the fuckups in the first place,
and afaics Linus' series has not been posted anywhere I can see, and I
have been through the issues and worked with Ulf to get them fixed, I find
that to be down right insulting by you.
You received *BOTH* of Ulf's patches on the 5th October. Both needed
to be applied *TOGETHER* to reduce the window where things got worse
before they got better. But for some goddamned unknown reason you decided
to only take the first but totally and utterly ignored the second.
Well done, you've probably crapped this driver up again. Way to go Mark.
Now, tell us _exactly_ what patches you've applied to this driver. Post
them to this mailing list so we can see them, and see what state this
driver is now in.
IMHO, you're being a terrible "maintainer" here - and this is being shown
by the need to get you to post all the patches you've currently queued up
for this.
^ permalink raw reply
* [PATCH 2/2] Revert "spi/pl022: enable runtime PM"
From: Mark Brown @ 2012-10-23 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023111656.GT21164@n2100.arm.linux.org.uk>
On Tue, Oct 23, 2012 at 12:16:56PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 23, 2012 at 12:10:19PM +0100, Mark Brown wrote:
> > I *really* should not need to remind you to:
> > - Not top post
> > - Send patches in a form which can be applied if you want them applying
> How about actually applying the damned patch from the two-part patch set,
> rather than only the first, both of which has been around for almost a
> month now, and fixes what should never have gone into mainline in the
> first place?
Well, the reason for the second point is that I don't have a copy of the
patch any more, I need a copy of it before I can do anything. Half the
reason these contentless top posts are annoying is that even if there's
something to do it's not actionable.
I have to say I had been under the impression that Linus' series that I
applied the other day dealt with all the outstanding stuff here; the
issues with this have been the awful changelogs and the overalapping
sets of patches.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/160443fc/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ARM: dma-mapping: support debug_dma_mapping_error
From: Marek Szyprowski @ 2012-10-23 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350909843-5273-1-git-send-email-ming.lei@canonical.com>
Hello,
On 10/22/2012 2:44 PM, Ming Lei wrote:
> Without the patch, kind of below warning will be dumped if DMA-API
> debug is enabled:
>
> [ 11.069763] ------------[ cut here ]------------
> [ 11.074645] WARNING: at lib/dma-debug.c:948 check_unmap+0x770/0x860()
> [ 11.081420] ehci-omap ehci-omap.0: DMA-API: device driver failed to
> check map error[device address=0x0000000
> 0adb78e80] [size=8 bytes] [mapped as single]
> [ 11.095611] Modules linked in:
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Ming Lei <ming.lei@canonical.com>
Thanks for the patch, I've applied it to my kernel tree.
> ...
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox