* [PATCH V2 0/2] ARM: OMAP2+: Add device-tree support for 32kHz counter
From: Jon Hunter @ 2012-10-19 15:05 UTC (permalink / raw)
To: linux-arm-kernel
This series adds device-tree support for the 32kHz counter on OMAP2+ devices,
which is used as the default kernel clock-source for OMAP devices.
Boot tested on OMAP2420 H4, OMAP3430 Beagle Board and OMAP4430 Panda Board
with and without device-tree present.
Based and dependent upon OMAP2+ series that adds device-tree support for
DMTIMERs [1].
V2 changes:
- Updated counter name in binding per Benoit Cousson's feedback
[1] http://marc.info/?l=linux-omap&m=135065875808614&w=2
Jon Hunter (2):
ARM: dts: OMAP: Add counter-32k nodes
ARM: OMAP2+: Add device-tree support for 32kHz counter
.../devicetree/bindings/arm/omap/counter.txt | 15 +++++++++++
arch/arm/boot/dts/omap2420.dtsi | 6 +++++
arch/arm/boot/dts/omap2430.dtsi | 6 +++++
arch/arm/boot/dts/omap3.dtsi | 6 +++++
arch/arm/boot/dts/omap4.dtsi | 6 +++++
arch/arm/mach-omap2/timer.c | 28 +++++++++++++++++++-
6 files changed, 66 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/counter.txt
--
1.7.9.5
^ permalink raw reply
* [PATCH V2 1/2] ARM: dts: OMAP: Add counter-32k nodes
From: Jon Hunter @ 2012-10-19 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350659151-13898-1-git-send-email-jon-hunter@ti.com>
Adds the counter-32k timers nodes present in OMAP2/3/4 devices and
device-tree binding documentation for OMAP counter-32k.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
.../devicetree/bindings/arm/omap/counter.txt | 15 +++++++++++++++
arch/arm/boot/dts/omap2420.dtsi | 6 ++++++
arch/arm/boot/dts/omap2430.dtsi | 6 ++++++
arch/arm/boot/dts/omap3.dtsi | 6 ++++++
arch/arm/boot/dts/omap4.dtsi | 6 ++++++
5 files changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/counter.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/counter.txt b/Documentation/devicetree/bindings/arm/omap/counter.txt
new file mode 100644
index 0000000..f6baa09
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/counter.txt
@@ -0,0 +1,15 @@
+OMAP Counter-32K bindings
+
+Required properties:
+- compatible: Must be "ti,omap-counter32k" for OMAP controllers
+- reg: Contains timer register address range (base address and length)
+- ti,hwmods: Name of the hwmod associated to the counter, which is typically
+ "counter_32k"
+
+Example:
+
+counter32k: counter at 4a304000 {
+ compatible = "ti,omap-counter32k";
+ reg = <0x4a304000 0x001f>;
+ ti,hwmods = "counter_32k";
+};
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 13cfa2c..7f1a705 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -14,6 +14,12 @@
compatible = "ti,omap2420", "ti,omap2";
ocp {
+ counter32k: counter at 48004000 {
+ compatible = "ti,omap-counter32k";
+ reg = <0x48004000 0x001f>;
+ ti,hwmods = "counter_32k";
+ };
+
omap2420_pmx: pinmux at 48000030 {
compatible = "ti,omap2420-padconf", "pinctrl-single";
reg = <0x48000030 0x0113>;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 886b825..c3f9f2d 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -14,6 +14,12 @@
compatible = "ti,omap2430", "ti,omap2";
ocp {
+ counter32k: counter at 49020000 {
+ compatible = "ti,omap-counter32k";
+ reg = <0x49020000 0x001f>;
+ ti,hwmods = "counter_32k";
+ };
+
omap2430_pmx: pinmux at 49002030 {
compatible = "ti,omap2430-padconf", "pinctrl-single";
reg = <0x49002030 0x0154>;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1fba998..4e958a7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -60,6 +60,12 @@
ranges;
ti,hwmods = "l3_main";
+ counter32k: counter at 48320000 {
+ compatible = "ti,omap-counter32k";
+ reg = <0x48320000 0x001f>;
+ ti,hwmods = "counter_32k";
+ };
+
intc: interrupt-controller at 48200000 {
compatible = "ti,omap2-intc";
interrupt-controller;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index f9572bf..321839d 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -95,6 +95,12 @@
ranges;
ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
+ counter32k: counter at 4a304000 {
+ compatible = "ti,omap-counter32k";
+ reg = <0x4a304000 0x001f>;
+ ti,hwmods = "counter_32k";
+ };
+
omap4_pmx_core: pinmux at 4a100040 {
compatible = "ti,omap4-padconf", "pinctrl-single";
reg = <0x4a100040 0x0196>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 2/2] ARM: OMAP2+: Add device-tree support for 32kHz counter
From: Jon Hunter @ 2012-10-19 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350659151-13898-1-git-send-email-jon-hunter@ti.com>
For OMAP devices, the 32kHz counter is the default clock-source for the kernel.
However, this is not the only possible clock-source the kernel can use for OMAP
devices.
When booting with device-tree, if the 32kHz counter is the desired clock-source
for the kernel, then parse the device-tree blob to ensure that the counter is
present and if so map memory for the counter using the device-tree of_iomap()
function so we are no longer reliant on the OMAP HWMOD framework to do this for
us.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/timer.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 9a47f3d..6375dfa 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -159,6 +159,11 @@ static struct of_device_id omap_timer_match[] __initdata = {
{ }
};
+static struct of_device_id omap_counter_match[] __initdata = {
+ { .compatible = "ti,omap-counter32k", },
+ { }
+};
+
/**
* omap_get_timer_dt - get a timer using device-tree
* @match - device-tree match structure for matching a device type
@@ -377,11 +382,26 @@ static u32 notrace dmtimer_read_sched_clock(void)
static int __init omap2_sync32k_clocksource_init(void)
{
int ret;
+ struct device_node *np = NULL;
struct omap_hwmod *oh;
void __iomem *vbase;
const char *oh_name = "counter_32k";
/*
+ * If device-tree is present, then search the DT blob
+ * to see if the 32kHz counter is supported.
+ */
+ if (of_have_populated_dt()) {
+ np = omap_get_timer_dt(omap_counter_match, NULL);
+ if (!np)
+ return -ENODEV;
+
+ of_property_read_string_index(np, "ti,hwmods", 0, &oh_name);
+ if (!oh_name)
+ return -ENODEV;
+ }
+
+ /*
* First check hwmod data is available for sync32k counter
*/
oh = omap_hwmod_lookup(oh_name);
@@ -390,7 +410,13 @@ static int __init omap2_sync32k_clocksource_init(void)
omap_hwmod_setup_one(oh_name);
- vbase = omap_hwmod_get_mpu_rt_va(oh);
+ if (np) {
+ vbase = of_iomap(np, 0);
+ of_node_put(np);
+ } else {
+ vbase = omap_hwmod_get_mpu_rt_va(oh);
+ }
+
if (!vbase) {
pr_warn("%s: failed to get counter_32k resource\n", __func__);
return -ENXIO;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3] ARM: mach-imx: Fix selection of ARCH_MXC
From: Shawn Guo @ 2012-10-19 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350583470-15500-1-git-send-email-fabio.estevam@freescale.com>
On Thu, Oct 18, 2012 at 03:04:30PM -0300, Fabio Estevam wrote:
> Since commit c5a0d497(ARM: imx: enable multi-platform build),
> ARCH_MXC is selected by the following logic:
>
> config ARCH_MXC
> def_bool y if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
>
> , which causes build error on vexpress_defconfig:
>
> arch/arm/mach-imx/hotplug.c:49: undefined reference to `imx_enable_cpu'
> arch/arm/mach-imx/platsmp.c:57: undefined reference to `imx_set_cpu_jump'
> arch/arm/mach-imx/platsmp.c:58: undefined reference to `imx_enable_cpu'
>
> Make ARCH_MXC a user selectable option, so that it does not get built
> by default on other defconfigs that select ARCH_MULTI_V4_V5 or ARCH_MULTI_V6_V7.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Arnd, Olof,
I just applied this patch on my imx/multi-platform. Can you please
pull it to update the branch in arm-soc? Thanks.
Shawn
^ permalink raw reply
* [PATCH] pinctrl/nomadik: use irq_create_mapping()
From: Linus Walleij @ 2012-10-19 15:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
Since in the DT case, the linear domain path will not allocate
descriptors for the IRQs, we need to use irq_create_mapping()
for mapping hwirqs to Linux IRQs, so these descriptors get
created on-the-fly in this case.
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-nomadik.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index 01aea1c..d1d3cb9 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -931,7 +931,7 @@ static void __nmk_gpio_irq_handler(unsigned int irq, struct irq_desc *desc,
while (status) {
int bit = __ffs(status);
- generic_handle_irq(irq_find_mapping(nmk_chip->domain, bit));
+ generic_handle_irq(irq_create_mapping(nmk_chip->domain, bit));
status &= ~BIT(bit);
}
@@ -1056,7 +1056,7 @@ static int nmk_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
struct nmk_gpio_chip *nmk_chip =
container_of(chip, struct nmk_gpio_chip, chip);
- return irq_find_mapping(nmk_chip->domain, offset);
+ return irq_create_mapping(nmk_chip->domain, offset);
}
#ifdef CONFIG_DEBUG_FS
--
1.7.11.3
^ permalink raw reply related
* [PATCH 0/8] Convert Ux500 to SPARSE_IRQ
From: Linus Walleij @ 2012-10-19 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210190742.58900.arnd@arndb.de>
On Fri, Oct 19, 2012 at 9:42 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 18 October 2012, Linus Walleij wrote:
>> After this series I tried turning on multiplatform for ux500
>> but there are still headers in <mach/*> creating problems
>> so we are still just halfway.
>
> Which ones are still left? This is the list of inclusions I saw
> in the 3.6-rc1 version of my multiplatform branch being included
> from outside of the mach-ux500 directory.
>
> I should probably redo that branch to see which ones are gone now,
> but you would also catch most of these with a simple defconfig build.
>
> 3 include <mach-ux500/board-mop500-msp.h>
> 2 include <mach-ux500/crypto-ux500.h>
> 1 include <mach-ux500/db8500-regs.h>
> 1 include <mach-ux500/gpio.h>
> 8 include <mach-ux500/hardware.h>
This is the one causing the build to fail.
> 3 include <mach-ux500/id.h>
I'm working on a patch for this one.
> 3 include <mach-ux500/irqs.h>
> 1 include <mach-ux500/setup.h>
> 1 include <mach-ux500/usb.h>
Basically I think it's pretty easy to hack something that builds
multiplatform on top of the SPARSE_IRQ patch set.
I just need to do it :-) (famous last words...)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/4] OMAP-GPMC generic timing migration
From: Afzal Mohammed @ 2012-10-19 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5076B166.2020006@gmail.com>
Hi Daniel,
On Thursday 11 October 2012 05:15 PM, Daniel Mack wrote:
> Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
> would like to augment this to make GPMC attached NAND probable in DT, in
> case this is still an open topic.
In case you can help on making gpmc nand dt probable, please
proceed. I would be on vacation next week, may be we can
discuss after I am back.
am335x based boards like beagle bone should be booting on
l-o master and it has gpmc header cleanup changes with
minimal driver support.
As I don't have the sufficient time to explain in detail, some
pointers. Discussion between us [1] hopefully explains it in brief.
It would be like peripherals connected to gpmc being represented
as child nodes in dt. gpmc driver probably in probe would have to
invoke of_platform_populate to create child nodes (for devices like
nand). And driver would have to be enhanced to configure gpmc
based on information passed through dt for each child nodes.
Or roughly have a dt equivalent of driver as in [2].
One issue would be the memory resource creation by gpmc
driver and which has to be provided to client resource data.
And a decision has to be taken whether a generic routine is
going to be used or initially a custom routine invocation
based on child compatible fields would be sufficient.
Regards
Afzal
[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg74397.html
[2] git://gitorious.org/x0148406-public/linux-kernel tags/gpmc-drv-v6
^ permalink raw reply
* [PATCH] ARM: dt: tegra: ventana: define pinmux for ddc
From: Stephen Warren @ 2012-10-19 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350626311-18131-1-git-send-email-markz@nvidia.com>
On 10/18/2012 11:58 PM, Mark Zhang wrote:
> Define pinmux for DDC. The DDC pinmux in Ventana is 2 pins in I2C2.
> +++ b/arch/arm/boot/dts/tegra20-ventana.dts
> - ddc {
> - nvidia,pins = "ddc", "owc", "spdi", "spdo",
> - "uac";
> - nvidia,function = "rsvd2";
> - };
So that removes the entries for 5 pin groups, yet below, entries are
only added for the ddc and pta pingroups, so the other 4 pin groups
become unconfigured.
> +
> + state_i2cmux_ddc: pinmux_i2cmux_ddc {
> + ddc {
> + nvidia,pins = "ddc";
> + nvidia,function = "i2c2";
> + };
> + pta {
> + nvidia,pins = "pta";
> + nvidia,function = "rsvd4";
> + };
Does this actually work? The pta pingroup is configured by the "hog"
pinctrl state of the pinctrl node itself, so this state should fail to
be applied since it attempts to touch the same pingroup.
> + i2cmux {
...
> + i2c at 1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + smart-battery at b {
> + compatible = "ti,bq24617", "smart-battery-1.1";
> + reg = <0xb>;
> + ti,i2c-retry-count = <2>;
> + ti,poll-retry-count = <10>;
> + };
That wasn't there before. Does that device actually exist on Ventana?
Adding it should be a separate patch if so, since this one is just about
introducing the I2C mux, not adding an SBS device. Was this all just
cut/paste from Seaboard without validation?
^ permalink raw reply
* [PATCH] ARM: tegra30: clocks: add AHB and APB clocks
From: Stephen Warren @ 2012-10-19 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350628693-1190-1-git-send-email-josephl@nvidia.com>
On 10/19/2012 12:38 AM, Joseph Lo wrote:
> Adding the AHB and APB bus clock control interface for Tegra30.
Not really "clock control interface" but just "clocks". I can reword
that when applying the patch though.
The code seems reasonable. I'd like review from Prashant or Peter though.
^ permalink raw reply
* [ath9k-devel] [PATCH net-next 00/21] treewide: Use consistent api style for address testing
From: Pavel Roskin @ 2012-10-19 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350630254.2293.183.camel@edumazet-glaptop>
On Fri, 19 Oct 2012 09:04:14 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Yes they are some names discrepancies, thats a big deal.
>
> And we have alloc_skb() / kfree_skb() / skb_clone()
>
> Why not skb_alloc() / skb_free() / skb_clone() ?
>
> Some people actually know current code by name of functions, they dont
> want to change their mind and having to grep include files and git log
> to learn the new names of an old function, especially when traveling
> and using a laptop.
I agree.
Also, it makes sense to introduce a more consistent name for a function
when it's improved in some way and the callers need to be adjusted or
re-checked.
That way, the old name can be phased out as the code is made compatible
with the new function.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH v2] arm: omap: move OMAP USB platform data to <linux/platform_data/omap-usb.h>
From: Tony Lindgren @ 2012-10-19 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019065500.GD12235@arwen.pp.htv.fi>
* Felipe Balbi <balbi@ti.com> [121019 00:01]:
> On Thu, Oct 18, 2012 at 06:49:17PM -0700, Tony Lindgren wrote:
> >
> > Yes. Figured it out, it fails to apply with quilt, but applies
> > with git.
>
> probably because of file rename.
Yeh so it seems.
> > But it does not compile with all configs though, and does
> > not remove plat/usb.h. Thanks anyways. I'll post a proper
> > series shortly with your patch fixed up.
>
> ok... I'll check it out. I kept the non-static functions in plat/usb.h
> because they didn't belong on platform_data/usb-omap.h. What should be
> done with those, then ? move to mach/ ?
I made a clean-up patch that creates local usb.h file for those
that applies before your patch.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/5] ARM: tegra: dts: add slink controller dt entry
From: Stephen Warren @ 2012-10-19 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5081190D.50200@nvidia.com>
On 10/19/2012 03:10 AM, Laxman Dewangan wrote:
> On Friday 19 October 2012 04:11 AM, Stephen Warren wrote:
>> On 10/18/2012 04:56 AM, Laxman Dewangan wrote:
>>> Add slink controller details in the dts file of
>>> Tegra20 and Tegra30.
>>> diff --git a/arch/arm/boot/dts/tegra20.dtsi
>>> b/arch/arm/boot/dts/tegra20.dtsi
>>> + slink at 7000d400 {
>>> + compatible = "nvidia,tegra20-slink";
>>> + reg =<0x7000d400 0x200>;
>>> + interrupts =<0 59 0x04>;
>>> + nvidia,dma-req-sel =<15>;
>
(Oh, you need a space before and after the = in all the lines above)
>> I thought the common DT DMA bindings were going to be in 3.7, and hence
>> we could just use them here rather than inventing another custom
>> property for this purpose?
>
> Adding Vinod here.
>
> I looked the dma devicetree bingind document and did not found the
> generic binding name. Howvere, for arm-pl330.txt, it is explained as ...
That's not the generic bindings. I guess they didn't get merged then. I
guess we can continue with custom bindings until they are.
^ permalink raw reply
* [PATCH 3/5] ARM: tegra: fix clock entry of slink controller
From: Stephen Warren @ 2012-10-19 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508119CE.9070408@nvidia.com>
On 10/19/2012 03:13 AM, Laxman Dewangan wrote:
> On Friday 19 October 2012 04:13 AM, Stephen Warren wrote:
>>> + OF_DEV_AUXDATA("nvidia,tegra20-slink", TEGRA_SLINK1_BASE,
>>> "spi-tegra-slink.0", NULL),
>> Here, can't we just use the existing device names in the clock files...
>>
>> So we can completely drop the changes to these two files:
>
> I want to name the driver as spi-tegra-slink. When we add the sflash spi
> driver for tegra20, the driver name will be spi-tegra-sflash.
> Also current name is "spi_tegra" I do not want to name with "_". So it
> is require to convert as "-".
The driver name is whatever you put into the driver file. The AUXDATA
only affects the device name. There should be no conflict with the
"sflash" driver, since that clock is set up to expect driver name "spi"
which doesn't conflict with "spi_tegra.*".
So, there's really no point in churning the clock names any more,
especially since it's temporary. If you feel strongly about this, the
best thing to do is help push Tegra's support of DT clock bindings forward.
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Tony Lindgren @ 2012-10-19 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019061630.GB2983@netboy.at.omicron.at>
* Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> >
> > Another important point is, this driver is also required and used for
> > Davinci family of devices (arch/mach/mach-davinci/).
>
> That is really beside the point. If the code isn't ready yet, then
> don't merge it.
>
> When I asked about the beaglebone, I was given the impression that it
> will be ready for v3.7-rc1. But, as I know realize, at the current
> rate, it might not even be ready for v3.8.
>
> I don't mind waiting, but please make sure that whatever lands into a
> release is really, truly working.
Indeed. This has been a problem with many of the TI patches in
general. People are working on separate product trees and then produce
patches for the mainline kernel that are poorly tested.
The requirement should be: Do your patch on an omap board then send the
patch from your omap board after booting your board with the patch :)
Regards,
Tony
^ permalink raw reply
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Tony Lindgren @ 2012-10-19 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2071397.IU49JkAq1T@avalon>
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [121019 02:41]:
>
> Nitpicking, please keep the headers sorted alphabetically, here and in all
> locations below (especially the OMAP3 ISP driver).
>
> (OK, there's already one misplaced #include, but let's not make it worse :-))
Sure I'll check that.
> I plan to push cleanup patches for the staging tidspbridge driver that get rid
> of the local register definitions and use plat/iommu.h instead. That's
> obviously an interim solution as in the long run the driver should use the
> IOMMU API, but in the meantime it's a step in the right direction. Would it
> then make sense to move all those definitions to include/linux/omap-iommu.h,
> not just the ones used by the OMAP3 ISP driver ?
Well these patches are just intended to fix the platform data interface
between core ARM code and iommu. At this point I really don't want to
get involved in the iommu framework.
What you are asking should be coordinated with Joerg and Ohad. Ideally
the iommu framework would provide the API to the drivers to use, and there
would not be any need to have include/linux/omap-iommu.h.
If you ask me, I would just rip out the code that's not following the
iommu API immediately and have it resubmitted in a sane way :)
> Shouldn't this header be split in include/linux/omap-iommu.h and
> include/linux/omap-iovmm.h ? I would also move all the hardware IOVMF flags to
> include/linux/omap-iovmm.h, not just the two currently used by the OMAP3 ISP
> driver. The software flags can be kept in drivers/iommu/omap-iovmm.c.
I just fixed up things to follow what's being done with the iommu
framework currently. Probably keeping only omap-iommu.h available is
the best way to go until the iommu framework provides the interfaces,
but again that's up to Joerg and Ohad.
> > +extern void omap_iommu_save_ctx(struct device *dev);
> > +extern void omap_iommu_restore_ctx(struct device *dev);
>
> Do we really need to prefix functions with 'extern' ?
Yes since they are exported, I just moved them. Again, this is something
that should be handled eventually via the iommu framework using runtime PM
and not be exported at all. Again, I would just rip out that code
if you ask me and replace it with comments until fixed.
Regards,
Tony
^ permalink raw reply
* [PATCH v2] ARM: SMP_TWD: make setup()/stop() reentrant
From: Shawn Guo @ 2012-10-19 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350640589-31821-1-git-send-email-linus.walleij@linaro.org>
On Fri, Oct 19, 2012 at 11:56:29AM +0200, Linus Walleij wrote:
> This makes the SMP_TWD clock .setup()/.stop() pair reentrant by
> not re-fetching the clk and re-registering the clock event every
> time .setup() is called. We also make sure to call the
> clk_enable()/clk_disable() pair on subsequent calls.
>
> As it has been brought to my knowledge that this pair is going
> to be called from atomic contexts for CPU clusters coming and
> going, the clk_prepare()/clk_unprepare() calls cannot be called
> on subsequent .setup()/.stop() iterations.
>
> The patch assumes that the code will make sure that
> twd_set_mode() is called through .set_mode() on the clock
> event *after* the .setup() call, so that the timer registers
> are fully re-programmed after a new .setup() cycle.
>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Reported-by: Peter Chen <peter.chen@freescale.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Peter/Shawn: can you please respond with a Tested-by from your
> system(s) to indicate if this works as expected?
Yes, it fixes the sleep-in-atomic warning. However I'm having some
issue with the resume function now. See below for details.
It's getting late here. I will investigate it tomorrow if I do not
anything back from you.
Shawn
$ echo mem > /sys/power/state
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
mmc1: card e1c3 removed
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.03 seconds) done.
PM: Entering mem sleep
PM: suspend of devices complete after 4.651 msecs
PM: suspend devices took 0.010 seconds
PM: late suspend of devices complete after 1.437 msecs
PM: noirq suspend of devices complete after 2.167 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Enabling non-boot CPUs ...
CPU1: Booted secondary processor
CPU1 is up
CPU2: Booted secondary processor
CPU2 is up
CPU3: Booted secondary processor
CPU3 is up
PM: noirq resume of devices complete after 1.030 msecs
PM: early resume of devices complete after 1.553 msecs
PM: resume of devices complete after 4.179 msecs
PM: resume devices took 0.010 seconds
PM: Finishing wakeup.
Restarting tasks ... done.
mmc1: new high speed SDHC card at address e1c3
mmcblk0: mmc1:e1c3 SD04G 3.69 GiB
mmcblk0: p1 p2 p3
libphy: 2188000.ethernet:01 - Link is Down
libphy: 2188000.ethernet:01 - Link is Up - 100/Full
INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 0, t=6002 jiffies)
Backtrace:
[<80011e74>] (dump_backtrace+0x0/0x10c) from [<804d8d84>] (dump_stack+0x18/0x1c)
r6:8069db00 r5:806b4800 r4:8144bb00 r3:00000000
[<804d8d6c>] (dump_stack+0x0/0x1c) from [<80080d78>] (rcu_check_callbacks+0x598/0x624)
[<800807e0>] (rcu_check_callbacks+0x0/0x624) from [<8002e31c>] (update_process_times+0x40/0x54)
[<8002e2dc>] (update_process_times+0x0/0x54) from [<8005f928>] (tick_sched_timer+0x88/0xec)
r6:8144ba18 r5:00000014 r4:9c341e08 r3:20000013
[<8005f8a0>] (tick_sched_timer+0x0/0xec) from [<80043214>] (__run_hrtimer.isra.18+0x4c/0xe0)
r8:9c341767 r7:8005f8a0 r6:8144b880 r5:8144b8d0 r4:8144ba18
[<800431c8>] (__run_hrtimer.isra.18+0x0/0xe0) from [<80043c68>] (hrtimer_interrupt+0x120/0x2c0)
r7:00000001 r6:8144b880 r5:00000000 r4:8144b8d0
[<80043b48>] (hrtimer_interrupt+0x0/0x2c0) from [<8001401c>] (twd_handler+0x34/0x48)
[<80013fe8>] (twd_handler+0x0/0x48) from [<8007b5e8>] (handle_percpu_devid_irq+0x88/0xa8)
r4:bf807600 r3:80013fe8
[<8007b560>] (handle_percpu_devid_irq+0x0/0xa8) from [<80077cb8>] (generic_handle_irq+0x28/0x38)
r8:00000000 r7:0000001d r6:806a0000 r5:8069e02c r4:0000001d
r3:8007b560
[<80077c90>] (generic_handle_irq+0x0/0x38) from [<8000ee94>] (handle_IRQ+0x54/0xb4)
r4:806a9258 r3:00000180
[<8000ee40>] (handle_IRQ+0x0/0xb4) from [<80008504>] (gic_handle_irq+0x30/0x64)
r8:806ad048 r7:f4000100 r6:806a1f00 r5:806a8970 r4:f400010c
r3:00000000
[<800084d4>] (gic_handle_irq+0x0/0x64) from [<8000e124>] (__irq_svc+0x44/0x5c)
Exception stack(0x806a1f00 to 0x806a1f48)
1f00: 00000001 00000001 00000000 806abd48 806a0000 806a0000 806e9088 804e2aa4
1f20: 806ad048 806a0000 00000000 806a1f54 806a1f18 806a1f48 8006629c 8000f1c0
1f40: 20000013 ffffffff
r7:806a1f34 r6:ffffffff r5:20000013 r4:8000f1c0
[<8000f198>] (default_idle+0x0/0x44) from [<8000f338>] (cpu_idle+0x54/0x104)
[<8000f2e4>] (cpu_idle+0x0/0x104) from [<804c8534>] (rest_init+0xc4/0xec)
[<804c8470>] (rest_init+0x0/0xec) from [<8066183c>] (start_kernel+0x2bc/0x30c)
r7:80691f50 r6:806e8fc0 r5:ffffffff r4:806a8f90
[<80661580>] (start_kernel+0x0/0x30c) from [<10008044>] (0x10008044)
^ permalink raw reply
* [PATCH 5/6] ARM: OMAP2+: Make some definitions local
From: Tony Lindgren @ 2012-10-19 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2153737.CkcY4HqKKl@avalon>
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [121019 02:45]:
> On Thursday 18 October 2012 13:28:48 Tony Lindgren wrote:
> > @@ -117,13 +112,6 @@ static inline struct omap_iommu
> > *dev_to_omap_iommu(struct device *dev) }
> > #endif
> >
> > -/* IOMMU errors */
> > -#define OMAP_IOMMU_ERR_TLB_MISS (1 << 0)
> > -#define OMAP_IOMMU_ERR_TRANS_FAULT (1 << 1)
> > -#define OMAP_IOMMU_ERR_EMU_MISS (1 << 2)
> > -#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 << 3)
> > -#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 << 4)
> > -
>
> I'll use those in the tidspbridge driver, in patches that I plan to push soon.
>
> I will apply this patch set on top of mine, see what breaks. Would you like me
> to propose a modified version of this set, or add additional patches in my set
> ?
Sure, let's try to expose only the minimal amount of omap
iommu things with this patch set so we don't break things.
Then the iommu development can continue on it's own independent
of the core omap code except for the platform data.
But again, if there are nasty layering violations using this
code, I would just remove those features. Those things tend to
just get worse unless they are fixed properly to start with.
Regards,
Tony
^ permalink raw reply
* [PATCH v2] pinctrl: reserve pins when states are activated
From: Stephen Warren @ 2012-10-19 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350651909-5337-1-git-send-email-linus.walleij@stericsson.com>
On 10/19/2012 07:05 AM, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This switches the way that pins are reserved for multiplexing:
>
> We used to do this when the map was parsed, at the creation of
> the settings inside the pinctrl handle, in pinmux_map_to_setting().
>
> However this does not work for us, because we want to use the
> same set of pins with different devices at different times: the
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> @@ -689,7 +691,6 @@ static void pinctrl_put_locked(struct pinctrl *p, bool inlist)
> case PIN_MAP_TYPE_MUX_GROUP:
> if (state == p->state)
> pinmux_disable_setting(setting);
> - pinmux_free_setting(setting);
Personally, I would keep that function, and just remove the body. I
believe that even though it currently doesn't have to do anything, it
provides documentation for where any required cleanup would be placed if
needed in the future.
If you still want to remove the function, pinconf_free_setting() should
also be removed, since that's empty right now.
Irrespective,
Acked-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply
* [PATCH] pinctrl/nomadik: use irq_create_mapping()
From: Stephen Warren @ 2012-10-19 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350659375-7335-1-git-send-email-linus.walleij@stericsson.com>
On 10/19/2012 09:09 AM, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> Since in the DT case, the linear domain path will not allocate
> descriptors for the IRQs, we need to use irq_create_mapping()
> for mapping hwirqs to Linux IRQs, so these descriptors get
> created on-the-fly in this case.
> @@ -931,7 +931,7 @@ static void __nmk_gpio_irq_handler(unsigned int irq, struct irq_desc *desc,
> while (status) {
> int bit = __ffs(status);
>
> - generic_handle_irq(irq_find_mapping(nmk_chip->domain, bit));
> + generic_handle_irq(irq_create_mapping(nmk_chip->domain, bit));
Surely this one can remain as irq_find_mapping() since isn't
nmk_gpio_to_irq() guaranteed to have been called first for this GPIO/IRQ?
^ permalink raw reply
* [PULL REQ] IXP4xx changes for Linux 3.7
From: Jason Cooper @ 2012-10-19 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m3a9vkahci.fsf@intrepid.localdomain>
On Thu, Oct 18, 2012 at 12:01:17AM +0200, Krzysztof Halasa wrote:
...
> Unfortunately, as I already explained to you in
> https://lkml.org/lkml/2012/9/29/37, my resources for IXP4xx are very
> limited (and this isn't a paid job) and I'm in no way able to do what
> you require. This, coupled with my inability to make the patches end
> up upstream any other way, will make me post relevant MAINTAINERS
> changes shortly.
>
> Don't get me wrong. If I had time for this it could be different.
> Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby
> at this point. Given the raised barriers to participate, probably
> aimed at paid maintainers, I have to quit doing this.
Krzysztof, please reconsider. I'm also a hobbyist maintainer
(kirkwood,orion5x,mv78xx0,dove,mvebu). I'd hate to see the community
lose a valuable maintainer because arch/arm/ has grown so much.
If you would like, I could pull your patches through my tree and send
them on to arm-soc. I'm already familiar with arm-soc process, and I'll
admit I have a soft spot for mach-ixp4xx. It was my first experience
with embedded Linux (nslu2, gateworks boards).
This way, you could see the process first hand without having to do the
labor.
We could do this for a few release cycles so you can see how it goes.
After that, we can reassess things. If you still don't wish to lend
your experience, so be it. But I hope we can change your mind.
thx,
Jason.
^ permalink raw reply
* RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support")
From: Felipe Balbi @ 2012-10-19 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350655227.2768.11.camel@twins>
Hi,
On Fri, Oct 19, 2012 at 04:00:27PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-10-18 at 08:51 +0300, Felipe Balbi wrote:
> > > So the primary question remains: is RT runtime supposed to include the
> > > time spent suspended? I suspect not.
> >
> > you might be right there, though we need Thomas or Peter to answer :-s
>
> re, sorry both tglx and I have been traveling, he still is, I'm trying
> to play catch-up :-)
>
> Anyway, yeah I'm somewhat surprised the clock is 'running' when the
> machine isn't. From what I could gather, this is !x86 hardware, right?
>
> x86 explicitly makes sure our clocks are 'stopped' during suspend, see
> commit cd7240c0b900eb6d690ccee088a6c9b46dae815a.
>
> Can you do something similar for ARM? A quick look at
> arch/arm/kernel/sched_clock.c shows there's already suspend/resume
> hooks, do they do the wrong thing?
if I understand correctly, then below should be enough. I did't test it
though:
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index 87ba8dd..c9260e6 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -116,7 +116,7 @@ int __init omap_init_clocksource_32k(void __iomem *vbase)
return ret;
}
- setup_sched_clock(omap_32k_read_sched_clock, 32, 32768);
+ setup_sched_clock_needs_suspend(omap_32k_read_sched_clock, 32, 32768);
register_persistent_clock(NULL, omap_read_persistent_clock);
pr_info("OMAP clocksource: 32k_counter at 32768 Hz\n");
Russell, would you have any comments here ? Should we make sure all ARMs
call setup_sched_clock_needs_suspend() and 'stop' counting during
suspend ?
I will test the above diff tomorrow, unless you have any other (better)
idea on how to deal with the problem.
cheers
--
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/20121019/df3b447e/attachment.sig>
^ permalink raw reply related
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Matt Porter @ 2012-10-19 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019160041.GB4730@atomide.com>
On Fri, Oct 19, 2012 at 09:00:41AM -0700, Tony Lindgren wrote:
> * Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > >
> > > Another important point is, this driver is also required and used for
> > > Davinci family of devices (arch/mach/mach-davinci/).
> >
> > That is really beside the point. If the code isn't ready yet, then
> > don't merge it.
> >
> > When I asked about the beaglebone, I was given the impression that it
> > will be ready for v3.7-rc1. But, as I know realize, at the current
> > rate, it might not even be ready for v3.8.
> >
> > I don't mind waiting, but please make sure that whatever lands into a
> > release is really, truly working.
>
> Indeed. This has been a problem with many of the TI patches in
> general. People are working on separate product trees and then produce
> patches for the mainline kernel that are poorly tested.
>
> The requirement should be: Do your patch on an omap board then send the
> patch from your omap board after booting your board with the patch :)
s/should be/is/
I fixed that for you. :) That's always been the requirement for the
kernel, period. There's also a lot of dead/unused code in the davinci
driver world too...so omap isn't alone with this phenomenon.
-Matt
^ permalink raw reply
* [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug
From: Stephen Warren @ 2012-10-19 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018095328.GS21164@n2100.arm.linux.org.uk>
On 10/18/2012 03:53 AM, Russell King - ARM Linux wrote:
> On Wed, Oct 17, 2012 at 03:12:17PM -0600, Stephen Warren wrote:
>> That implies we really do need to keep the two pieces of code completely
>> in sync, so a shared header is the right way to go. It also implies that
>> having duplicate mappings of the same physical address doesn't cause any
>> immediate obvious catastrophic problems.
>>
>> Ways we might avoid files in arch/arm/include/debug having to use
>> relative include paths to pick up that header are:
>
> Why not take the opposite approach. Treat the platform as setting up the
> addresses for the UART. Then arrange for the debug macros to match that.
Well, wouldn't the debug macros match it by including a common header
file that defined the virtual address:-)
> Or we define a common virtual address for debug UARTs (which platforms
> would not be able to use).
That seems like good idea.
>> b) Rework debug-macro.S so that it isn't an include file, but rather a
>> regular top-level file.
>
> No, that won't work. It's used in two places - the kernel and the
> decompressor. Hence why it is an include file (it's not an include
> file just for the fun of it.)
Can't the file just be compiled twice by the two different Makefiles?
^ permalink raw reply
* [PATCH v3 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
From: Omar Ramirez Luna @ 2012-10-19 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018235246.GK30550@atomide.com>
Tony,
On 18 October 2012 18:52, Tony Lindgren <tony@atomide.com> wrote:
> Thanks, the related patches are now posted in thread
> "[PATCH v3 0/6] omap iommu changes to remove plat includes".
Ok.
> Also, can you please take a look at the "Updated status of the removal
> of plat headers" thread?
>
> I've tagged you to remove the omap plat/mailbox.h :)
Yes, got the request from Benoit too, but just now had the time to look at it.
Cheers,
Omar
^ permalink raw reply
* [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug
From: Stephen Warren @ 2012-10-19 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5080088C.9090607@gmail.com>
On 10/18/2012 07:47 AM, Rob Herring wrote:
...
> Here is what I mentioned previously. This removes the static mapping from
> the platforms. This is untested and probably breaks on different DEBUG_LL
> options. For now, platforms call debug_ll_io_init, but once all platforms
> are converted, this can be called from devicemaps_init.
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> +void __init debug_ll_io_init(void)
> +{
> + struct map_desc map;
> +
> + if (!IS_ENABLED(CONFIG_DEBUG_LL))
> + return;
> +
> + debug_ll_addr(&map.pfn, &map.virtual);
> + map.pfn = __phys_to_pfn(map.pfn);
> + map.length = PAGE_SIZE;
> + map.type = MT_DEVICE;
> + create_mapping(&map);
> +}
OK, so I just call this new function from Tegra's tegra_map_common_io().
That looks pretty neat. I'll give it a try.
^ 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