* ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined
From: Marc Zyngier @ 2012-10-23 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <022101cdb12d$724e9650$56ebc2f0$@org>
On 23/10/12 15:48, Kukjin Kim wrote:
> Hi all,
>
> Now, v3.7-rc2 happens following build error with s3c2410_defconfig...
>
> ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined!
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
> Any idea on this?
This is becoming a recurring pattern...
Please see:
https://patchwork.kernel.org/patch/1570611/
https://lkml.org/lkml/2012/10/9/393
and probably a few other instances...
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] ASoC: Samsung: Update Kconfig for Exynos5250 and Exynos4412
From: Olof Johansson @ 2012-10-23 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01ca01cdb110$a48783b0$ed968b10$%kim@samsung.com>
2012/10/23 Kukjin Kim <kgene.kim@samsung.com>:
> Tushar Behera wrote:
>>
>> On 09/28/2012 03:23 PM, Sangsu Park wrote:
>> >
>> > On Thu, Sep 27, 2012 at 07:30 PM, Padmavathi Venna wrote:
>> >
>
> [...]
>
>> >> @@ -63,7 +63,7 @@ config SND_SOC_SAMSUNG_SMDK_WM8580
>> >>
>> >> config SND_SOC_SAMSUNG_SMDK_WM8994
>> >> tristate "SoC I2S Audio support for WM8994 on SMDK"
>> >> - depends on SND_SOC_SAMSUNG && (MACH_SMDKV310 || MACH_SMDKC210 ||
>> >> MACH_SMDK4212)
>> >> + depends on SND_SOC_SAMSUNG && (MACH_SMDKV310 || MACH_SMDKC210 ||
>> >> MACH_SMDK4212 || MACH_SMDK4412 || MACH_EXYNOS5_DT)
>> >> depends on I2C=y && GENERIC_HARDIRQS
>> >> select MFD_WM8994
>> >> select SND_SOC_WM8994
>> >
>> > I'm not sure about this since MACH_EXYNOS5_DT can have others instead of
>> SMDK.
>> >
>>
>> But there is no other way we can differentiate between two EXYNOS5_DT
>> based boards in the kernel. So, support for all possible codecs and
>> sound-cards should be enabled in the kernel. The instantiation of the
>> drivers should depend on the device-tree entries.
>>
> Hmm...any idea on this?
Tushar is right. In particular, there is absolutely no reason to
enforce driver selection based on platform enablement, as long as it
still builds no matter what (and if it doesn't, that should probably
be fixed).
It should be possible to enable a superset of all drivers, and only
have the ones that are actually instantiated by platform devices or
device tree entries probe and configure. That's how the kernel works
on nearly all platforms.
So, removing as much "depends on" as possible (probably only keep
SND_SOC_SAMSUNG here) seems like a good choice, and fixing any
compilation errors caused by it.
-Olof
^ permalink raw reply
* [PATCH v2 2/4] zynq: move static peripheral mappings
From: Arnd Bergmann @ 2012-10-23 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022211219.GC31538@beefymiracle.amer.corp.natinst.com>
On Monday 22 October 2012, Josh Cartwright wrote:
> Shifting them up into the vmalloc region prevents the following warning,
> when booting a zynq qemu target with more than 512mb of RAM:
>
> BUG: mapping for 0xe0000000 at 0xe0000000 out of vmalloc space
>
> In addition, it allows for reuse of these mappings when the proper
> drivers issue requests via ioremap().
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
This looks like a bug fix that should be backported to older kernels,
so it would be good to add 'Cc: stable at vger.kernel.org' below your
Signed-off-by.
> diff --git a/arch/arm/mach-zynq/include/mach/zynq_soc.h b/arch/arm/mach-zynq/include/mach/zynq_soc.h
> index d0d3f8f..ae3b236 100644
> --- a/arch/arm/mach-zynq/include/mach/zynq_soc.h
> +++ b/arch/arm/mach-zynq/include/mach/zynq_soc.h
> @@ -15,33 +15,37 @@
> #ifndef __MACH_XILINX_SOC_H__
> #define __MACH_XILINX_SOC_H__
>
> +#include <asm/pgtable.h>
> +
> #define PERIPHERAL_CLOCK_RATE 2500000
>
> -/* For now, all mappings are flat (physical = virtual)
> +/* Static peripheral mappings are mapped at the top of the
> + * vmalloc region
> */
> -#define UART0_PHYS 0xE0000000
> -#define UART0_VIRT UART0_PHYS
> +#define UART0_PHYS 0xE0000000
> +#define UART0_SIZE SZ_4K
> +#define UART0_VIRT (VMALLOC_END - UART0_SIZE)
There are plans to move the uart location into a fixed virtual
address in the future, but it hasn't been decided yet.
It will still need a fixed mapping though, just to a different
address.
> -#define TTC0_PHYS 0xF8001000
> -#define TTC0_VIRT TTC0_PHYS
> +#define TTC0_PHYS 0xF8001000
> +#define TTC0_SIZE SZ_4K
> +#define TTC0_VIRT (UART0_VIRT - TTC0_SIZE)
It's quite likely that this does not have to be a fixed mapping
any more. Just have a look at how drivers/clocksource/dw_apb_timer_of.c
calls of_iomap() to get the address.
> -#define PL310_L2CC_PHYS 0xF8F02000
> -#define PL310_L2CC_VIRT PL310_L2CC_PHYS
> +#define PL310_L2CC_PHYS 0xF8F02000
> +#define PL310_L2CC_SIZE SZ_4K
> +#define PL310_L2CC_VIRT (TTC0_VIRT - PL310_L2CC_SIZE)
This address would not need a fixed mapping by calling l2x0_of_init
rather than l2x0_init.
> -#define SCU_PERIPH_PHYS 0xF8F00000
> -#define SCU_PERIPH_VIRT SCU_PERIPH_PHYS
> +#define SCU_PERIPH_PHYS 0xF8F00000
> +#define SCU_PERIPH_SIZE SZ_8K
> +#define SCU_PERIPH_VIRT (PL310_L2CC_VIRT - SCU_PERIPH_SIZE)
And your patch 3 already obsoletes this mapping.
Arnd
^ permalink raw reply
* [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
From: Jon Hunter @ 2012-10-23 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350981432-6750-2-git-send-email-s-guiriec@ti.com>
Hi Seb,
On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
> Add base address and interrupt line inside Device Tree data for
> OMAP5
>
> Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
> ---
> arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 42c78be..9e39f9f 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -104,6 +104,8 @@
>
> gpio1: gpio at 4ae10000 {
> compatible = "ti,omap4-gpio";
> + reg = <0x4ae10000 0x200>;
> + interrupts = <0 29 0x4>;
> ti,hwmods = "gpio1";
> gpio-controller;
> #gpio-cells = <2>;
I am wondering if we should add the "interrupt-parent" property to add
nodes in the device-tree source. I know that today the interrupt-parent
is being defined globally, but when device-tree maps an interrupt for a
device it searches for the interrupt-parent starting the current device
node.
So in other words, for gpio1 it will search the gpio1 binding for
"interrupt-parent" and if not found move up a level and search again. It
will keep doing this until it finds the "interrupt-parent".
Therefore, I believe it will improve search time and hence, boot time if
we have interrupt-parent defined in each node.
Cheers
Jon
^ permalink raw reply
* [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
From: Santosh Shilimkar @ 2012-10-23 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87txtlb6v7.fsf@deeprootsystems.com>
On Tuesday 23 October 2012 07:58 PM, Kevin Hilman wrote:
> Paul Walmsley <paul@pwsan.com> writes:
>
>> Hi Tero,
>>
>> On Mon, 22 Oct 2012, Tero Kristo wrote:
>>
>>> When waking up from off-mode, some IP blocks are reset automatically by
>>> hardware. For this reason, software must wait until the reset has
>>> completed before attempting to access the IP block.
>>>
>>> This patch fixes for example the bug introduced by commit
>>> 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
>>> to SYSCONFIG register"), in which the MMC IP block is reset during
>>> off-mode entry, but the code expects the module to be already available
>>> during the execution of context restore.
>>>
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> Cc: Paul Walmsley <paul@pwsan.com>
>>> Cc: Benoit Cousson <b-cousson@ti.com>
>>> Cc: Venkatraman S <svenkatr@ti.com>
>>
>> What do you think about these modifications? The code is quite similar to
>> what was in the _ocp_softreset() function, so just moved it into a
>> function. Also moved the callsite from the end of _enable_sysc() to the
>> beginning, which makes more sense to me, but would like to get your
>> opinion.
>
> FYI, after some more testing with this patch, I noticed that this patch
> (and the original from Tero) cause some sluggishness on UART1 console my
> 37xx/EVM platform as soon as off-mode is enabled (even without the UART
> autosuspend timeouts enabled.) I don't see this on any other OMAP3
> platform but all the others I have have UART3 console (in PER), the EVM
> is the only one with UART1 console (in CORE.)
>
> I haven't debugged this any furhter, but thought it should be reported
> before this gets merged.
>
Trying to shoot in the dark but the UART sluggishness I observed in the
past on OMAP4 was due to improper setting of sysconfig which is
what $subject + Tero's patch is dealing with. Good to check the
value of UART sysconfig before and after the offmode entry to
see if the smart-idle/smart-idle wakeup setting getting disturbed
for some reason.
Below is the OMAP4 commit am referring to.
commit 5ae256dcd91bf308826a4ac19598b27ebb86a536
Author: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Fri Apr 13 23:25:04 2012 +0530
ARM: OMAP: serial: Fix the ocp smart idlemode handling bug
Regards,
Santosh
^ permalink raw reply
* ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined
From: Kukjin Kim @ 2012-10-23 14:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Now, v3.7-rc2 happens following build error with s3c2410_defconfig...
ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make[1]: *** Waiting for unfinished jobs....
Any idea on this?
Thanks.
K-Gene <kgene@kernel.org>
^ permalink raw reply
* [PATCH v2 0/4] zynq subarch cleanups
From: Arnd Bergmann @ 2012-10-23 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022211040.GA31538@beefymiracle.amer.corp.natinst.com>
On Monday 22 October 2012, Josh Cartwright wrote:
> Hey all-
>
> Things have been relatively quiet on the Zynq front lately. This
> patchset does a bit of cleanup of the Zynq subarchitecture. It was the
> necessary set of things I had to do to get a zynq target booting with
> the upstream qemu model. It removes some unused clock infrastructure,
> adds DT support for the GIC, and moves around peripheral mappings.
Ok, thanks for these patches. As we have moved on for some of these issues,
I'll comment on how to go even further. On a global scale, I wonder
if there are any obstacles for enabling CONFIG_MULTIPLATFORM on Zynq
as we have done for most of the other recently added platform.
Arnd
^ permalink raw reply
* [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
From: Kevin Hilman @ 2012-10-23 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210230745160.32436@utopia.booyaka.com>
Paul Walmsley <paul@pwsan.com> writes:
> Hi Tero,
>
> On Mon, 22 Oct 2012, Tero Kristo wrote:
>
>> When waking up from off-mode, some IP blocks are reset automatically by
>> hardware. For this reason, software must wait until the reset has
>> completed before attempting to access the IP block.
>>
>> This patch fixes for example the bug introduced by commit
>> 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
>> to SYSCONFIG register"), in which the MMC IP block is reset during
>> off-mode entry, but the code expects the module to be already available
>> during the execution of context restore.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> Cc: Paul Walmsley <paul@pwsan.com>
>> Cc: Benoit Cousson <b-cousson@ti.com>
>> Cc: Venkatraman S <svenkatr@ti.com>
>
> What do you think about these modifications? The code is quite similar to
> what was in the _ocp_softreset() function, so just moved it into a
> function. Also moved the callsite from the end of _enable_sysc() to the
> beginning, which makes more sense to me, but would like to get your
> opinion.
FYI, after some more testing with this patch, I noticed that this patch
(and the original from Tero) cause some sluggishness on UART1 console my
37xx/EVM platform as soon as off-mode is enabled (even without the UART
autosuspend timeouts enabled.) I don't see this on any other OMAP3
platform but all the others I have have UART3 console (in PER), the EVM
is the only one with UART1 console (in CORE.)
I haven't debugged this any furhter, but thought it should be reported
before this gets merged.
Kevin
^ permalink raw reply
* [PATCH 1/2] ARM: SAMSUNG: Insert bitmap_gpio_int member in samsung_gpio_chip
From: Kukjin Kim @ 2012-10-23 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000001cd9c63$e95c7b60$bc157220$@com>
Eunki Kim wrote:
>
> When a device uses GPIO interrupt, its driver assumes that GPIO
> should be INPUT mode. However, GPIO of SAMSUNG SoC is sepated to
> INPUT mode and INTERRUPT mode. They are set by 0x0 and 0xF in GPIO
> control register. If the register is set to INPUT mode, the
> interrupt never occur. Therefore, it's necessary to set INTERRUPT
> mode instead of INPUT mode when the pin is used for GPIO interrupt.
>
> This patch inserts the bitmap_gpio_int member in struct samsung_
> gpio_chip in order to represent use of GPIO interrupt for each pin
> and sets the related bit when s5p_register_gpio_interrupt function
> is called.
>
> Signed-off-by: Eunki Kim <eunki_kim@samsung.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/plat-samsung/include/plat/gpio-core.h | 2 ++
> arch/arm/plat-samsung/s5p-irq-gpioint.c | 8 ++++++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/include/plat/gpio-core.h
> b/arch/arm/plat-samsung/include/plat/gpio-core.h
> index 1fe6917..dfd8b7a 100644
> --- a/arch/arm/plat-samsung/include/plat/gpio-core.h
> +++ b/arch/arm/plat-samsung/include/plat/gpio-core.h
> @@ -48,6 +48,7 @@ struct samsung_gpio_cfg;
> * @config: special function and pull-resistor control information.
> * @lock: Lock for exclusive access to this gpio bank.
> * @pm_save: Save information for suspend/resume support.
> + * @bitmap_gpio_int: Bitmap for representing GPIO interrupt or not.
> *
> * This wrapper provides the necessary information for the Samsung
> * specific gpios being registered with gpiolib.
> @@ -71,6 +72,7 @@ struct samsung_gpio_chip {
> #ifdef CONFIG_PM
> u32 pm_save[4];
> #endif
> + u32 bitmap_gpio_int;
> };
>
> static inline struct samsung_gpio_chip *to_samsung_gpio(struct gpio_chip
> *gpc)
> diff --git a/arch/arm/plat-samsung/s5p-irq-gpioint.c b/arch/arm/plat-
> samsung/s5p-irq-gpioint.c
> index f9431fe..d981c61 100644
> --- a/arch/arm/plat-samsung/s5p-irq-gpioint.c
> +++ b/arch/arm/plat-samsung/s5p-irq-gpioint.c
> @@ -185,7 +185,7 @@ int __init s5p_register_gpio_interrupt(int pin)
>
> /* check if the group has been already registered */
> if (my_chip->irq_base)
> - return my_chip->irq_base + offset;
> + goto success;
>
> /* register gpio group */
> ret = s5p_gpioint_add(my_chip);
> @@ -193,9 +193,13 @@ int __init s5p_register_gpio_interrupt(int pin)
> my_chip->chip.to_irq = samsung_gpiolib_to_irq;
> printk(KERN_INFO "Registered interrupt support for gpio
> group %d.\n",
> group);
> - return my_chip->irq_base + offset;
> + goto success;
> }
> return ret;
> +success:
> + my_chip->bitmap_gpio_int |= BIT(offset);
> +
> + return my_chip->irq_base + offset;
> }
>
> int __init s5p_register_gpioint_bank(int chain_irq, int start, int
> nr_groups)
> --
> 1.7.1
OK, 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] arm: sched: stop sched_clock() during suspend
From: Kevin Hilman @ 2012-10-23 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023092231.GE28061@n2100.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> On Tue, Oct 23, 2012 at 12:28:32AM +0200, Linus Walleij wrote:
>> On Mon, Oct 22, 2012 at 7:05 PM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>
>> > However, in light of RT throttling, this a correctness issue for process
>> > accounting, so I agree that this should be done for all platforms
>> > instead of providing an optional 'needs suspend' version of the API,
>> > even though it means printk times no longer reflect time spent
>> > suspended.
>>
>> Maybe we should get printk() to use the best clocksource
>> instead.
>>
>> The reason AFAICT that printk() is using sched_clock() is that
>> it's supposed to be fast. But now it seems that it's not going
>> to return what printk() needs anymore.
>
> No, printk() does not need this. You think it does, but it doesn't. What
> we have is a difference between ARM and x86, and this difference is breaking
> the scheduler.
>
> The fact that the printk timestamp increments while suspended is a bug. It
> doesn't on x86.
Russell, I agree that it's a bug, but does it qualify as a something
you're willing to take for v3.7-rc?
For OMAP, we need to know if this will go for v3.7 or not because
there's a regression in the OMAP I2C driver, and if this doesn't go in,
we'll need to revert something in the I2C driver until it does.
Thanks,
Kevin
^ permalink raw reply
* [PATCH 2/2] gpio: samsung: Fix input mode setting function for GPIO int
From: Kukjin Kim @ 2012-10-23 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZuED59F2FfewXNxBeYauZEaXUxUiY5GHJDxdQvzxGtZA@mail.gmail.com>
Linus Walleij wrote:
>
> On Thu, Sep 27, 2012 at 5:55 AM, Eunki Kim <eunki_kim@samsung.com> wrote:
>
> > This patch makes GPIO pin to INTERRUPT mode or INPUT mode according
> > to bitmap_gpio_int. When the related bit of bitmap_gpio_int is set,
> > it makes GPIO pin to INTERRUPT mode instrad of INPUT mode in the
> > samsung_gpiolib_4bit_input function.
> >
> > Signed-off-by: Eunki Kim <eunki_kim@samsung.com>
> > Cc: Kukjin Kim <kgene.kim@samsung.com>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Are you taking this into the Samsung tree or shall I merge it
> into my GPIO tree? In the latter case I need an ACK from
> some Samsung maintainer.
>
Hi, Linus
Let me pick this into Samsung tree with your ack :)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v2] arm: sched: stop sched_clock() during suspend
From: Kevin Hilman @ 2012-10-23 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350971854-9161-1-git-send-email-balbi@ti.com>
Felipe Balbi <balbi@ti.com> writes:
> The scheduler imposes a requirement to sched_clock()
> which is to stop the clock during suspend, if we don't
> do that any RT thread will be rescheduled in the future
> which might cause any sort of problems.
>
> This became an issue on OMAP when we converted omap-i2c.c
> to use threaded IRQs, it turned out that depending on how
> much time we spent on suspend, the I2C IRQ thread would
> end up being rescheduled so far in the future that I2C
> transfers would timeout and, because omap_hsmmc depends
> on an I2C-connected device to detect if an MMC card is
> inserted in the slot, our rootfs would just vanish.
>
> arch/arm/kernel/sched_clock.c already had an optional
> implementation (sched_clock_needs_suspend()) which would
> handle scheduler's requirement properly, what this patch
> does is simply to make that implementation non-optional.
>
> Note that this has the side-effect that printk timings
> won't reflect the actual time spent on suspend so other
> methods to measure that will have to be used.
>
> This has been tested with beagleboard XM (OMAP3630) and
> pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
> after this patch.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
^ permalink raw reply
* [PATCH] ARM: Remove obsolete reference to subsystem_init().
From: Robert P. J. Day @ 2012-10-23 14:12 UTC (permalink / raw)
To: linux-arm-kernel
Since subsystem_init() doesn't exist anymore, reword the comment to
reflect the more general subsys_initcalls.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
obviously, just a pedantic documentation tweak.
diff --git a/arch/arm/plat-versatile/leds.c b/arch/arm/plat-versatile/leds.c
index d2490d0..536c69a 100644
--- a/arch/arm/plat-versatile/leds.c
+++ b/arch/arm/plat-versatile/leds.c
@@ -98,6 +98,6 @@ static int __init versatile_leds_init(void)
/*
* Since we may have triggers on any subsystem, defer registration
- * until after subsystem_init.
+ * until after the subsys_initcalls.
*/
fs_initcall(versatile_leds_init);
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply related
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-23 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5085C470.4040707@wwwdotorg.org>
On Mon, 22 Oct 2012, Stephen Warren wrote:
> > I see. But why would it be done this way instead having a separate
> > property?
>
> Well, I did say normally:-)
>
> I can certainly see an argument for representing these differences using
> custom properties, rather than deriving the information from the
> compatible value. It's probably be OK to do so for something generic
> like this; it's just perhaps not always the default choice.
>
> Do note that even though this binding document dictates a particular
> value for the compatible property, every device tree should additionally
> add a separate value alongside it to indicate the specific HW model
> that's actually present, so that if some device-specific bug-fix or
> workaround needs to be applied, the model can be identified anyway.
>
> So, rather than:
>
> compatible = "usb-ehci";
>
> You should always have e.g.:
>
> compatible = "nvidia,tegra20-ehci", "usb-ehci";
>
> Given that, there is then always enough information in the device tree
> for the driver to be able to derive the other values from the compatible
> value.
Yes, I get it.
> Whether you want to derive the information, or whether you want to
> explicitly represent it via properties, is a decision to make based on
> the trade-offs.
>
> Oh, and I note that quite a few device trees already use compatible
> value "usb-ehci" in their device-trees. Care needs to be taken not to
> usurp that value from any existing device drivers if that was to be
> picked as the compatible value required by this binding.
Right. I think Tony's new binding should use compatible value
"usb-ehci-platform". It will essentially be a superset of "usb-ehci".
> > And doesn't the same reasoning apply to has-tt? Doesn't that mean the
> > driver would have to match four different hardware types? What happens
> > if a third characteristic like these comes around; would the driver
> > then have to check against eight different types?
>
> No, the compatible value represents the model, so you'd have a table like:
>
> compatible -> bugX has_tt
> nvidia,tegra20-ehci -> 0 1
> vendor1,foo-ehci -> 0 1
> vendor2,bar-ehci -> 1 1
> vendor3,baz-ehci -> 0 1
> vendor4,qux-ehci -> 0 1
> ...
>
> So the table size isn't related to the number of options. The table size
> is probably bigger than subset of options combinations that make sense.
Under the circumstances, and considering that usb-ehci-platform will be
rather generic, IMO it will be better to make has-tt,
has-synopsys-hc-bug, and no-io-watchdog separate properties, each
naturally defaulting to "not present". That will avoid the need to
update the driver's table each time a new board comes along.
Alan Stern
^ permalink raw reply
* [PATCH v4 5/5] ARM: EXYNOS: Add arm-pmu DT binding for exynos421x
From: Kukjin Kim @ 2012-10-23 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349662630-11607-6-git-send-email-chanho61.park@samsung.com>
Chanho Park wrote:
>
> This patch adds a arm-pmu node to bind device tree for exynos4210.
> The exynos4210 and 4212 have two cpus which includes a pmu. In contrast,
> the
> exynos4412 has 4 cpus and pmus. We need to define two more pmus for this
> type
> board. However, supporting arm-pmu for the exynos4412 will handle it later
> because there is no dts support for 4412 based board.
>
> Signed-off-by: Chanho Park <chanho61.park@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/boot/dts/exynos4210.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> b/arch/arm/boot/dts/exynos4210.dtsi
> index 214c557..90f9aed 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -42,6 +42,12 @@
> <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
> };
>
> + pmu {
> + compatible = "arm,cortex-a9-pmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <2 2>, <3 2>;
> + };
> +
> pinctrl_0: pinctrl at 11400000 {
> compatible = "samsung,pinctrl-exynos4210";
> reg = <0x11400000 0x1000>;
> --
> 1.7.9.5
Looks OK, 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 v4 4/5] ARM: EXYNOS: Add arm-pmu DT binding for exynos5250
From: Kukjin Kim @ 2012-10-23 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349662630-11607-5-git-send-email-chanho61.park@samsung.com>
Chanho Park wrote:
>
> This patch enables arm-pmu to bind device tree for exynos5250. The
> exynos5250
> has two pmus which have combiner irq type.
>
> Reviewed-by: Thomas Abraham <thomas.abraham@linaro.org>
> Signed-off-by: Chanho Park <chanho61.park@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index dddfd6e..fab3eae 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -56,6 +56,12 @@
> <0 28 0>, <0 29 0>, <0 30 0>, <0 31 0>;
> };
>
> + pmu {
> + compatible = "arm,cortex-a15-pmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <1 2>, <22 4>;
> + };
> +
> watchdog {
> compatible = "samsung,s3c2410-wdt";
> reg = <0x101D0000 0x100>;
> --
> 1.7.9.5
OK, 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 v4 3/5] ARM: EXYNOS: Enable PMUs for exynos4
From: Kukjin Kim @ 2012-10-23 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349662630-11607-4-git-send-email-chanho61.park@samsung.com>
Chanho Park wrote:
>
> This patch defines irq numbers of ARM performance monitoring unit for
> exynos4.
> Firs of all, we need to fix IRQ_PMU correctly and to split pmu
> initialization
> of exynos from plat-samsung for easily defining it.
>
> The number of CPU cores and PMU irq numbers are vary according to soc
> types.
> So, we need to identify each soc type using soc_is_xxx function and to
> define
> the pmu irqs dynamically. For example, the exynos4412 has 4 cpu cores and
> pmus.
>
> Signed-off-by: Chanho Park <chanho61.park@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/mach-exynos/common.c | 28
++++++++++++++++++++++++++++
> arch/arm/mach-exynos/include/mach/irqs.h | 8 ++++++--
> arch/arm/plat-samsung/devs.c | 2 +-
> 3 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index fdd582a..5183426 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -35,6 +35,7 @@
> #include <mach/regs-pmu.h>
> #include <mach/regs-gpio.h>
> #include <mach/pmu.h>
> +#include <mach/irqs.h>
>
> #include <plat/cpu.h>
> #include <plat/clock.h>
> @@ -1093,3 +1094,30 @@ static int __init exynos_init_irq_eint(void)
> return 0;
> }
> arch_initcall(exynos_init_irq_eint);
> +
> +static struct resource exynos4_pmu_resource[] = {
> + DEFINE_RES_IRQ(EXYNOS4_IRQ_PMU),
> + DEFINE_RES_IRQ(EXYNOS4_IRQ_PMU_CPU1),
> +#if defined(CONFIG_SOC_EXYNOS4412)
> + DEFINE_RES_IRQ(EXYNOS4_IRQ_PMU_CPU2),
> + DEFINE_RES_IRQ(EXYNOS4_IRQ_PMU_CPU3),
> +#endif
> +};
> +
> +static struct platform_device exynos4_device_pmu = {
> + .name = "arm-pmu",
> + .num_resources = ARRAY_SIZE(exynos4_pmu_resource),
> + .resource = exynos4_pmu_resource,
> +};
> +
> +static int __init exynos_armpmu_init(void)
> +{
> + if (!of_have_populated_dt()) {
> + if (soc_is_exynos4210() || soc_is_exynos4212())
> + exynos4_device_pmu.num_resources = 2;
> + platform_device_register(&exynos4_device_pmu);
> + }
> +
> + return 0;
> +}
> +arch_initcall(exynos_armpmu_init);
> diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-
> exynos/include/mach/irqs.h
> index 3a83546..c67a54e 100644
> --- a/arch/arm/mach-exynos/include/mach/irqs.h
> +++ b/arch/arm/mach-exynos/include/mach/irqs.h
> @@ -128,7 +128,7 @@
> #define EXYNOS4_IRQ_ADC1 IRQ_SPI(107)
> #define EXYNOS4_IRQ_PEN1 IRQ_SPI(108)
> #define EXYNOS4_IRQ_KEYPAD IRQ_SPI(109)
> -#define EXYNOS4_IRQ_PMU IRQ_SPI(110)
> +#define EXYNOS4_IRQ_POWER_PMU IRQ_SPI(110)
> #define EXYNOS4_IRQ_GPS IRQ_SPI(111)
> #define EXYNOS4_IRQ_INTFEEDCTRL_SSS IRQ_SPI(112)
> #define EXYNOS4_IRQ_SLIMBUS IRQ_SPI(113)
> @@ -136,6 +136,11 @@
> #define EXYNOS4_IRQ_TSI IRQ_SPI(115)
> #define EXYNOS4_IRQ_SATA IRQ_SPI(116)
>
> +#define EXYNOS4_IRQ_PMU COMBINER_IRQ(2, 2)
> +#define EXYNOS4_IRQ_PMU_CPU1 COMBINER_IRQ(3, 2)
> +#define EXYNOS4_IRQ_PMU_CPU2 COMBINER_IRQ(18, 2)
> +#define EXYNOS4_IRQ_PMU_CPU3 COMBINER_IRQ(19, 2)
> +
> #define EXYNOS4_IRQ_SYSMMU_MDMA0_0 COMBINER_IRQ(4, 0)
> #define EXYNOS4_IRQ_SYSMMU_SSS_0 COMBINER_IRQ(4, 1)
> #define EXYNOS4_IRQ_SYSMMU_FIMC0_0 COMBINER_IRQ(4, 2)
> @@ -232,7 +237,6 @@
> #define IRQ_TC EXYNOS4_IRQ_PEN0
>
> #define IRQ_KEYPAD EXYNOS4_IRQ_KEYPAD
> -#define IRQ_PMU EXYNOS4_IRQ_PMU
>
> #define IRQ_FIMD0_FIFO EXYNOS4_IRQ_FIMD0_FIFO
> #define IRQ_FIMD0_VSYNC EXYNOS4_IRQ_FIMD0_VSYNC
> diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
> index 03f654d..ace76b4 100644
> --- a/arch/arm/plat-samsung/devs.c
> +++ b/arch/arm/plat-samsung/devs.c
> @@ -1125,7 +1125,7 @@ struct platform_device s5p_device_onenand = {
>
> /* PMU */
>
> -#ifdef CONFIG_PLAT_S5P
> +#if defined(CONFIG_PLAT_S5P) && !defined(CONFIG_ARCH_EXYNOS)
> static struct resource s5p_pmu_resource[] = {
> DEFINE_RES_IRQ(IRQ_PMU)
> };
> --
> 1.7.9.5
Looks OK to me, will apply with your updated 2nd patch.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v4 2/5] ARM: EXYNOS: Correct combined IRQs for exynos4
From: Kukjin Kim @ 2012-10-23 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349662630-11607-3-git-send-email-chanho61.park@samsung.com>
Chanho Park wrote:
>
> This patch corrects combined IRQs for exynos4 series platform. The
> exynos4412
> has four extra combined irq group and the exynos4212 has two more combined
> irqs
> than exynos4210. Each irq is mapped to IRQ_SPI(xx). Unfortunately, extra 4
> combined IRQs isn't sequential. So, we need to map the irqs manually.
>
> Signed-off-by: Chanho Park <chanho61.park@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/mach-exynos/common.c | 42
+++++++++++++++++++++++++----
> -
> arch/arm/mach-exynos/include/mach/irqs.h | 4 ++-
> 2 files changed, 39 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index 709245e..fdd582a 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -560,23 +560,50 @@ static struct irq_domain_ops combiner_irq_domain_ops
> = {
> .map = combiner_irq_domain_map,
> };
>
> +static unsigned int combiner_extra_irq(int group)
This is only for exynos4212 and exynos4412 so how about to use
exynos4x12_combiner_extra_irq()?
> +{
> + switch (group) {
> + case 16:
> + return IRQ_SPI(107);
> + case 17:
> + return IRQ_SPI(108);
> + case 18:
> + return IRQ_SPI(48);
> + case 19:
> + return IRQ_SPI(42);
> + default:
> + return 0;
> + }
> +}
> +
> +static unsigned int max_combiner_nr(void)
> +{
> + if (soc_is_exynos5250())
> + return EXYNOS5_MAX_COMBINER_NR;
> + else if (soc_is_exynos4412())
> + return EXYNOS4_MAX_COMBINER_NR;
EXYNOS4412_MAX_COMBINER_NR is more clear?
> + else if (soc_is_exynos4212())
> + return EXYNOS4212_MAX_COMBINER_NR;
> + else
> + return EXYNOS4210_MAX_COMBINER_NR;
> +}
> +
> static void __init combiner_init(void __iomem *combiner_base,
> struct device_node *np)
> {
> int i, irq, irq_base;
> unsigned int max_nr, nr_irq;
>
> + max_nr = max_combiner_nr();
> +
> if (np) {
> if (of_property_read_u32(np, "samsung,combiner-nr",
&max_nr))
> {
> pr_warning("%s: number of combiners not specified, "
Hmm...the message should be changed, because it is just defined by checking
SoC with this changes not property of device tree...So how about just using
pr_info() with proper message?
> "setting default as %d.\n",
> - __func__, EXYNOS4_MAX_COMBINER_NR);
> - max_nr = EXYNOS4_MAX_COMBINER_NR;
> + __func__, max_nr);
> }
> - } else {
> - max_nr = soc_is_exynos5250() ? EXYNOS5_MAX_COMBINER_NR :
> - EXYNOS4_MAX_COMBINER_NR;
> }
> +
> nr_irq = max_nr * MAX_IRQ_IN_COMBINER;
>
> irq_base = irq_alloc_descs(COMBINER_IRQ(0, 0), 1, nr_irq, 0);
> @@ -593,7 +620,10 @@ static void __init combiner_init(void __iomem
> *combiner_base,
> }
>
> for (i = 0; i < max_nr; i++) {
> - irq = IRQ_SPI(i);
> + if (i < EXYNOS4210_MAX_COMBINER_NR || soc_is_exynos5250())
> + irq = IRQ_SPI(i);
> + else
> + irq = combiner_extra_irq(i);
> #ifdef CONFIG_OF
> if (np)
> irq = irq_of_parse_and_map(np, i);
> diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-
> exynos/include/mach/irqs.h
> index 35bced6..3a83546 100644
> --- a/arch/arm/mach-exynos/include/mach/irqs.h
> +++ b/arch/arm/mach-exynos/include/mach/irqs.h
> @@ -165,7 +165,9 @@
> #define EXYNOS4_IRQ_FIMD0_VSYNC COMBINER_IRQ(11, 1)
> #define EXYNOS4_IRQ_FIMD0_SYSTEM COMBINER_IRQ(11, 2)
>
> -#define EXYNOS4_MAX_COMBINER_NR 16
> +#define EXYNOS4210_MAX_COMBINER_NR 16
> +#define EXYNOS4212_MAX_COMBINER_NR 18
> +#define EXYNOS4_MAX_COMBINER_NR 20
EXYNOS4412_MAX_COMBINER_NR ?
>
> #define EXYNOS4_IRQ_GPIO1_NR_GROUPS 16
> #define EXYNOS4_IRQ_GPIO2_NR_GROUPS 9
> --
> 1.7.9.5
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 1/1] gpio/at91: auto request and configure the pio as input when the interrupt is used via DT
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-23 13:56 UTC (permalink / raw)
To: linux-arm-kernel
If we do this
interrupt-parent = <&pioA>;
interrupts = <7 0x0>;
The current core map the irq correctly but the gpio is not configured as input.
The pinctrl configure the pin as gpio with the correct mux parameter but is
not responsible to configure it as input.
So do it during the xlate
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
drivers/pinctrl/pinctrl-at91.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 01bf924..7d95c80 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -1255,9 +1255,33 @@ static int at91_gpio_irq_map(struct irq_domain *h, unsigned int virq,
return 0;
}
+int at91_gpio_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
+ const u32 *intspec, unsigned int intsize,
+ irq_hw_number_t *out_hwirq, unsigned int *out_type)
+{
+ struct at91_gpio_chip *at91_gpio = d->host_data;
+ int ret;
+ int pin = at91_gpio->chip.base + intspec[0];
+
+ if (WARN_ON(intsize < 2))
+ return -EINVAL;
+ *out_hwirq = intspec[0];
+ *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
+
+ ret = gpio_request(pin, ctrlr->full_name);
+ if (ret)
+ return ret;
+
+ ret = gpio_direction_input(pin);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
static struct irq_domain_ops at91_gpio_ops = {
.map = at91_gpio_irq_map,
- .xlate = irq_domain_xlate_twocell,
+ .xlate = at91_gpio_irq_domain_xlate,
};
static int at91_gpio_of_irq_setup(struct device_node *node,
--
1.7.10.4
^ permalink raw reply related
* [PATCH v4 1/5] ARM: EXYNOS: Add set_irq_affinity function for combiner_irq
From: Kukjin Kim @ 2012-10-23 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349662630-11607-2-git-send-email-chanho61.park@samsung.com>
Chanho Park wrote:
>
> This patch adds set_irq_affinity function for combiner_irq. We need this
> function to enable a arm-pmu because the pmu of exynos has combined type
> irqs.
>
> Reviewed-by: Thomas Abraham <thomas.abraham@linaro.org>
> Signed-off-by: Chanho Park <chanho61.park@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/mach-exynos/common.c | 30 +++++++++++++++++++++++++-----
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index 715b690..709245e 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -405,6 +405,7 @@ struct combiner_chip_data {
> unsigned int irq_offset;
> unsigned int irq_mask;
> void __iomem *base;
> + unsigned int parent_irq;
> };
>
> static struct irq_domain *combiner_irq_domain;
> @@ -461,10 +462,28 @@ static void combiner_handle_cascade_irq(unsigned int
> irq, struct irq_desc *desc)
> chained_irq_exit(chip, desc);
> }
>
> +#ifdef CONFIG_SMP
> +static int combiner_set_affinity(struct irq_data *d,
> + const struct cpumask *mask_val, bool force)
> +{
> + struct combiner_chip_data *chip_data =
> irq_data_get_irq_chip_data(d);
> + struct irq_chip *chip = irq_get_chip(chip_data->parent_irq);
> + struct irq_data *data = irq_get_irq_data(chip_data->parent_irq);
> +
> + if (chip && chip->irq_set_affinity)
> + return chip->irq_set_affinity(data, mask_val, force);
> + else
> + return -EINVAL;
> +}
> +#endif
> +
> static struct irq_chip combiner_chip = {
> - .name = "COMBINER",
> - .irq_mask = combiner_mask_irq,
> - .irq_unmask = combiner_unmask_irq,
> + .name = "COMBINER",
> + .irq_mask = combiner_mask_irq,
> + .irq_unmask = combiner_unmask_irq,
> +#ifdef CONFIG_SMP
> + .irq_set_affinity = combiner_set_affinity,
> +#endif
> };
>
> static void __init combiner_cascade_irq(unsigned int combiner_nr,
> unsigned int irq)
> @@ -484,12 +503,13 @@ static void __init combiner_cascade_irq(unsigned int
> combiner_nr, unsigned int i
> }
>
> static void __init combiner_init_one(unsigned int combiner_nr,
> - void __iomem *base)
> + void __iomem *base, unsigned int irq)
> {
> combiner_data[combiner_nr].base = base;
> combiner_data[combiner_nr].irq_offset = irq_find_mapping(
> combiner_irq_domain, combiner_nr * MAX_IRQ_IN_COMBINER);
> combiner_data[combiner_nr].irq_mask = 0xff << ((combiner_nr % 4) <<
> 3);
> + combiner_data[combiner_nr].parent_irq = irq;
>
> /* Disable all interrupts */
> __raw_writel(combiner_data[combiner_nr].irq_mask,
> @@ -573,12 +593,12 @@ static void __init combiner_init(void __iomem
> *combiner_base,
> }
>
> for (i = 0; i < max_nr; i++) {
> - combiner_init_one(i, combiner_base + (i >> 2) * 0x10);
> irq = IRQ_SPI(i);
> #ifdef CONFIG_OF
> if (np)
> irq = irq_of_parse_and_map(np, i);
> #endif
> + combiner_init_one(i, combiner_base + (i >> 2) * 0x10, irq);
> combiner_cascade_irq(i, irq);
> }
> }
> --
> 1.7.9.5
Looks good 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] mmc: sdhci: Defer probe if regulator_get fails
From: Russell King - ARM Linux @ 2012-10-23 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F1DF342-A2C4-434A-B878-A11374089E6E@nvidia.com>
On Tue, Oct 23, 2012 at 03:21:58PM +0200, Philip Rakity wrote:
> On 23 Oct 2012, at 09:19, Pavan Kunapuli <pkunapuli@nvidia.com> wrote:
> > - /* 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.
That's one of the issues of deferred probing: you don't know if one of the
_get() functions failed because it just isn't present, or whether it's
failed because it hasn't been registered yet.
The two conditions are indistinguishable from the driver point of view.
The solution to it is to ensure that those drivers where hardware resource
X is optional provide a dummy resource to the driver when the hardware
resource is not available. That means, as far as the driver is concerned,
that it will always expect to get a full set of resources whether or not
the hardware has them.
If drivers care about such stuff, then we should have xxx_is_dummy()
functions (eg, clk_is_dummy(clk)) which return TRUE when the hardware
resource is not available. (which we could use NULL to indicate and
would be in keeping with the specified IS_ERR() usage of these APIs.)
^ permalink raw reply
* [PATCH 2/2] input: gpio_keys: add pinctrl consumer
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-23 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350998942-713-1-git-send-email-plagnioj@jcrosoft.com>
If no pinctrl available just report a warning as some architecture may not
need to do anything.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-input at vger.kernel.org
---
drivers/input/keyboard/gpio_keys.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 6a68041..c0432fe 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -29,6 +29,7 @@
#include <linux/of_platform.h>
#include <linux/of_gpio.h>
#include <linux/spinlock.h>
+#include <linux/pinctrl/consumer.h>
struct gpio_button_data {
const struct gpio_keys_button *button;
@@ -666,6 +667,7 @@ static int __devinit gpio_keys_probe(struct platform_device *pdev)
struct input_dev *input;
int i, error;
int wakeup = 0;
+ struct pinctrl *pinctrl;
if (!pdata) {
pdata = gpio_keys_get_devtree_pdata(dev);
@@ -673,6 +675,15 @@ static int __devinit gpio_keys_probe(struct platform_device *pdev)
return PTR_ERR(pdata);
}
+ pinctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR(pinctrl)) {
+ error = PTR_ERR(pinctrl);
+ if (error == -EPROBE_DEFER)
+ return error;
+
+ dev_warn(dev, "No pinctrl provided\n");
+ }
+
ddata = kzalloc(sizeof(struct gpio_keys_drvdata) +
pdata->nbuttons * sizeof(struct gpio_button_data),
GFP_KERNEL);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] input: qt1070: add pinctrl consumer
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-23 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023131627.GE18964@game.jcrosoft.org>
If no pinctrl available just report a warning as some architecture may not
need to do anything.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-input at vger.kernel.org
---
drivers/input/keyboard/qt1070.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/input/keyboard/qt1070.c b/drivers/input/keyboard/qt1070.c
index ca68f29..967734e 100644
--- a/drivers/input/keyboard/qt1070.c
+++ b/drivers/input/keyboard/qt1070.c
@@ -33,6 +33,7 @@
#include <linux/interrupt.h>
#include <linux/jiffies.h>
#include <linux/delay.h>
+#include <linux/pinctrl/consumer.h>
/* Address for each register */
#define CHIP_ID 0x00
@@ -147,6 +148,7 @@ static int __devinit qt1070_probe(struct i2c_client *client,
struct input_dev *input;
int i;
int err;
+ struct pinctrl *pinctrl;
err = i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE);
if (!err) {
@@ -155,6 +157,15 @@ static int __devinit qt1070_probe(struct i2c_client *client,
return -ENODEV;
}
+ pinctrl = devm_pinctrl_get_select_default(&client->dev);
+ if (IS_ERR(pinctrl)) {
+ err = PTR_ERR(pinctrl);
+ if (err == -EPROBE_DEFER)
+ return err;
+
+ dev_warn(&client->dev, "No pinctrl provided\n");
+ }
+
if (!client->irq) {
dev_err(&client->dev, "please assign the irq to this device\n");
return -EINVAL;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/4] ARM: EXYNOS: Kconfig: Remove dependencies on particular SoCs from DT machines
From: Kukjin Kim @ 2012-10-23 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349701345-2681-5-git-send-email-t.figa@samsung.com>
Tomasz Figa wrote:
>
> MACH_EXYNOS{4,5}_DT are used for whole SoC lines, so they should depend
> on ARCH_EXYNOS{4,5} rather than on particular SoCs.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/mach-exynos/Kconfig | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 6ea95f0..2e82ce7 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -404,7 +404,6 @@ 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 SOC_EXYNOS4210
> select USE_OF
> select ARM_AMBA
> select HAVE_SAMSUNG_KEYPAD if INPUT_KEYBOARD
> @@ -419,7 +418,6 @@ config MACH_EXYNOS4_DT
> config MACH_EXYNOS5_DT
> bool "SAMSUNG EXYNOS5 Machine using device tree"
> depends on ARCH_EXYNOS5
> - select SOC_EXYNOS5250
> select USE_OF
> select ARM_AMBA
> help
> --
> 1.7.12
Hmm...your comment is correct, but we need to think again its selecting
order, between ARCH name, SoC and board. In addition, in case of MACH_XXX_DT
depending on SoC is rather to be supposed...
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] 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
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