* [GIT PULL] ARM: tegra: fixes for 3.7-rc2
From: Olof Johansson @ 2012-10-18 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350515426-31517-1-git-send-email-swarren@wwwdotorg.org>
On Wed, Oct 17, 2012 at 4:10 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> This branch contains a couple small fixes for Tegra for 3.7.
>
> * A fix for another clock rate calculation overflow
> * A revert of a change that removed the "timer" clock on Tegra, coupled
> with a fix for the confusing symbol name clash that triggered it.
>
> ----------------------------------------------------------------
>
> BTW, I signed this tag with my swarren at nvidia.com key; it's a different key
> to the one I used before, but has the same signatures and should show up on
> all the same keyservers.
>
> The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
>
> Linux 3.7-rc1
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.7-fixes-for-rc2
Pulled into fixes. Thanks!
-Olof
^ permalink raw reply
* [PATCH v3 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
From: Omar Ramirez Luna @ 2012-10-17 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016172258.GT15569@atomide.com>
On 16 October 2012 12:22, Tony Lindgren <tony@atomide.com> wrote:
> * Omar Ramirez Luna <omar.luna@linaro.org> [121011 18:07]:
>> These patches are needed for remoteproc to work on OMAP4.
>>
>> Introduced iommu hwmod support for OMAP3 (iva, isp) and
>> OMAP4 (ipu, dsp), along with the corresponding runtime PM
>> and routines to deassert reset lines, enable/disable clocks
>> and configure sysc registers.
>>
>> Although IOMMU hwmod patches were already submitted in the past,
>> this series adds few more changes, like:
>> - New reset handling.
>> - Save and restore context code rework.
>> - Device tree bindings for OMAP3 and OMAP4.
>>
>> For this series I just dropped the patches already included in
>> mainline.
>
> These will need to be rebased on omap-for-v3.8/cleanup-headers-iommu
> when I have that pushed out as that removes plat/*iommu*.h files.
Ok, will wait and rebase on top of it.
Thanks,
Omar
^ permalink raw reply
* [PATCH 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm
From: Omar Ramirez Luna @ 2012-10-17 23:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMP44s0LSJhyG89mwJERHW0SsQrU+J4CC6=xhMUR=MSw0dxj-A@mail.gmail.com>
On 15 October 2012 22:23, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> On probe this patch does pm_runtime_enable, however this doesn't mean
>> the device is turned ON or resumed or kept ON all the time.
>
> In fact it's the other way around; pm_runtime_enable turns off the
> power (if it's ON).
pm_runtime_enable just decrements the disable_depth counter. Doesn't
turn off anything by itself.
>>>>>> @@ -1009,7 +1001,8 @@ static int __devexit omap_iommu_remove(struct platform_device *pdev)
>>>>>> release_mem_region(res->start, resource_size(res));
>>>>>> iounmap(obj->regbase);
>>>>>>
>>>>>> - clk_put(obj->clk);
>>>>>> + pm_runtime_disable(obj->dev);
>>>>>
>>>>> This will turn on the device unnecessarily, wasting power, and there's
>>>>> no need for that, kfree will take care of that without resuming.
>>>>
>>>> Left aside the aesthetics of having balanced calls, the device will be
>>>> enabled if there was a pending resume to be executed, otherwise it
>>>> won't, kfree won't increment the disable_depth counter and I don't
>>>> think that freeing the pointer is enough reason to ignore
>>>> pm_runtime_disable.
>>>
>>> You are doing __pm_runtime_disable(dev, true), kfree will do
>>> __pm_runtime_disable(dev, false), which is what we want. Both will
>>> decrement the disable_depth.
>>
>> I'm quite confused here, could you please point me to the kfree snip
>> that does __pm_runtime_disable(dev, false)?
>
> Sorry, not kfree, but the device removal process:
>
> device_del
> device_pm_remove
> pm_runtime_remove
> __pm_runtime_disable <- HERE
I'm not entirely convinced _iommu_ follows this path, it doesn't
create any devices nor register them... whereas mailbox does create
devices and mailbox does follow this path for the devices created
which are child devices.
So this path won't take care of the omap-iommu device pm_runtime_disable.
>>> But at least you agree that there's a chance that the device will be waken up.
>>
>> Of course, if there is a pending resume to be executed, it must honor
>> that resume request and then turn off the device before removing the
>> iommu, IMHO.
>
> Who will turn off the device afterwards?
What I meant is that omap_iommu_detach should turn off the device
before removing the iommu.
Cheers,
Omar
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Tony Lindgren @ 2012-10-17 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210172337170.30902@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121017 16:39]:
> Hi Richard
>
> On Wed, 17 Oct 2012, Richard Cochran wrote:
>
> > Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> > you came from Toni Lindgren. The context where it came from is here:
> >
> > http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
>
> This patch appears to add a new feature, correct? I don't think the CPSW
> could have worked in the past without this data present. So it looks to
> me like this is 3.8 material, unless Tony would like it to go in sooner?
Yeah unless it fixes something, we should just queue it for v3.8 merge
window.
Regards,
Tony
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Paul Walmsley @ 2012-10-17 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017181354.GA2412@netboy.at.omicron.at>
Hi Richard
On Wed, 17 Oct 2012, Richard Cochran wrote:
> Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> you came from Toni Lindgren. The context where it came from is here:
>
> http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
This patch appears to add a new feature, correct? I don't think the CPSW
could have worked in the past without this data present. So it looks to
me like this is 3.8 material, unless Tony would like it to go in sooner?
- Paul
>
> Thanks,
> Richard
>
> ----- Forwarded message from Richard Cochran <richardcochran@gmail.com> -----
>
> Date: Mon, 15 Oct 2012 21:16:32 +0200
> From: Richard Cochran <richardcochran@gmail.com>
> To: netdev at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org, Arnd Bergmann <arnd@arndb.de>,
> David Miller <davem@davemloft.net>,
> Russell King <linux@arm.linux.org.uk>,
> Mugunthan V N <mugunthanvnm@ti.com>
> Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
> X-Mailer: git-send-email 1.7.2.5
>
> From: Mugunthan V N <mugunthanvnm@ti.com>
>
> This patch adds minimal hwmod support for davinci mdio driver. This patch
> requires rework on parent child relation between cpsw and davinci mdio
> hwmod data to support runtime PM.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 34 ++++++++++++++++++++++++++-
> 1 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> index 59d5c1c..f96bbc0 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> @@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc = {
> .rev_offs = 0x0,
> .sysc_offs = 0x8,
> .syss_offs = 0x4,
> - .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
> - SYSS_HAS_RESET_STATUS),
> + .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> .idlemodes = (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
> MSTANDBY_NO),
> .sysc_fields = &omap_hwmod_sysc_type3,
> @@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
> .modulemode = MODULEMODE_SWCTRL,
> },
> },
> + .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> + HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE),
> };
>
> /*
> @@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
> { }
> };
>
> +/* mdio class */
> +static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
> + .name = "davinci_mdio",
> +};
> +
> +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
> + {
> + .pa_start = 0x4A101000,
> + .pa_end = 0x4A101000 + SZ_256 - 1,
> + .flags = ADDR_MAP_ON_INIT,
> + },
> + { }
> +};
> +
> +static struct omap_hwmod am33xx_mdio_hwmod = {
> + .name = "davinci_mdio",
> + .class = &am33xx_mdio_hwmod_class,
> + .clkdm_name = "cpsw_125mhz_clkdm",
> + .main_clk = "cpsw_125mhz_gclk",
> +};
> +
> +struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
> + .master = &am33xx_cpgmac0_hwmod,
> + .slave = &am33xx_mdio_hwmod,
> + .addr = am33xx_mdio_addr_space,
> + .user = OCP_USER_MPU,
> +};
> +
> static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
> .master = &am33xx_l4_ls_hwmod,
> .slave = &am33xx_elm_hwmod,
> @@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
> &am33xx_l3_main__tptc2,
> &am33xx_l3_s__usbss,
> &am33xx_l4_hs__cpgmac0,
> + &am33xx_cpgmac0__mdio,
> NULL,
> };
>
> --
> 1.7.2.5
>
>
> ----- End forwarded message -----
>
- Paul
^ permalink raw reply
* [PATCHv1] arm:socfpga: Enable SMP for socfpga
From: Rob Herring @ 2012-10-17 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017230216.GA25651@elf.ucw.cz>
On 10/17/2012 06:02 PM, Pavel Machek wrote:
> Hi!
>
>>> arch/arm/mach-socfpga/Kconfig | 1 +
>>> arch/arm/mach-socfpga/Makefile | 3 +
>>> arch/arm/mach-socfpga/headsmp.S | 64 +++++++++++
>>> arch/arm/mach-socfpga/include/mach/core.h | 33 ++++++
>>
>> Move core.h to mach-socfpga.
>
>>> +ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include
>>> +
>>
>> This can be removed if core.h is moved.
>
> Ok, makes code nicer. Sorry for copying picoxcell too much.
>
>>> + __INIT
>>> +
>>> +#define CPU1_START_ADDR 0xffd08010
>>> +
>>> +ENTRY(secondary_trampoline)
>>
>> This appears to be your reset code at phys addr 0. How does core 0 boot
>> if you are copying this to 0?
>
> Yes, this is reset code, goes at zero. Core 0 has already booted by
> the time we are trying to boot Core 1 (we don't support CPU hotplug,
> yet). Is that a problem?
It would be better to do both at the same time as the code is
intertwined. More below on this...
>>> +static void __cpuinit socfpga_secondary_init(unsigned int cpu)
>>> +{
>>> + /*
>>> + * if any interrupts are already enabled for the primary
>>> + * core (e.g. timer irq), then they will not have been enabled
>>> + * for us: do so
>>> + */
>>> + gic_secondary_init(0);
>>> +
>>> + /*
>>> + * let the primary processor know we're out of the
>>> + * pen, then head off into the C entry point
>>> + */
>>> + pen_release = -1;
>>> + smp_wmb();
>>> +
>>> + /*
>>> + * Synchronise with the boot thread.
>>> + */
>>> + spin_lock(&boot_lock);
>>> + spin_unlock(&boot_lock);
>>> +}
>>> +
>>> +static int __cpuinit socfpga_boot_secondary(unsigned int cpu, struct task_struct *idle)
>>> +{
>>> + unsigned long timeout;
>>> + extern char secondary_trampoline, secondary_trampoline_end;
>>> +
>>> + int trampoline_size = &secondary_trampoline_end - &secondary_trampoline;
>>> +
>>> + /*
>>> + * Set synchronisation state between this boot processor
>>> + * and the secondary one
>>> + */
>>> + spin_lock(&boot_lock);
>>> +
>>> + memcpy(phys_to_virt(0), &secondary_trampoline, trampoline_size);
>>> +
>>> + __raw_writel(virt_to_phys(secondary_startup), (sys_manager_base_addr+0x10));
>>> +
>>> + pen_release = 0;
>>> + flush_cache_all();
>>> + smp_wmb();
>>> + outer_clean_range(0, trampoline_size);
>>> +
>>> + /* This will release CPU #1 out of reset.*/
>>> + __raw_writel(0, rst_manager_base_addr + 0x10);
>>> +
>>> + timeout = jiffies + (1 * HZ);
>>> + while (time_before(jiffies, timeout)) {
>>> + smp_rmb();
>>> + if (pen_release == -1)
>>> + break;
>>> +
>>> + udelay(10);
>>> + }
>>> +
>>> + /*
>>> + * now the secondary core is starting up let it run its
>>> + * calibrations, then wait for it to finish
>>> + */
>>> + spin_unlock(&boot_lock);
>>> + return pen_release != -1 ? -ENOSYS : 0;
>>
>> You don't need any of this if you can reset secondary cores on
>> hotplug.
>
> What exactly is unneccessary? I'd like to wait for secondary to come
> up so we can raise an error if it does not...?
>
Look at the highbank code.
If hotplug will cause a reset of the core, then none of this pen code is
needed. If hotplug just does a wfi and returns from the wfi when
onlining the core like Versatile Express, then you need this pen code.
There's been several prior discussions about this on the list.
If you will never support hotplug (and therefore suspend), then you
don't need this pen code either.
Rob
> Thanks,
> Pavel
>
> PS: I have this so far...
>
> diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
> index 659fd27..a0fc372 100644
> --- a/arch/arm/mach-socfpga/Makefile
> +++ b/arch/arm/mach-socfpga/Makefile
> @@ -2,7 +2,5 @@
> # Makefile for the linux kernel.
> #
>
> -ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include
> -
> obj-y := socfpga.o
> obj-$(CONFIG_SMP) += headsmp.o platsmp.o hotplug.o
> diff --git a/arch/arm/mach-socfpga/include/mach/core.h b/arch/arm/mach-socfpga/core.h
> similarity index 100%
> rename from arch/arm/mach-socfpga/include/mach/core.h
> rename to arch/arm/mach-socfpga/core.h
> diff --git a/arch/arm/mach-socfpga/headsmp.S b/arch/arm/mach-socfpga/headsmp.S
> index 9597ff7..081b4d1 100644
> --- a/arch/arm/mach-socfpga/headsmp.S
> +++ b/arch/arm/mach-socfpga/headsmp.S
> @@ -20,42 +20,6 @@
> #define CONFIG_CPU1_START_ADDR (CONFIG_SYSTEM_MANAGER + 0x10)
>
> ENTRY(secondary_trampoline)
> - /* From u-boot: start.S */
> - mrs r0, cpsr
> - bic r0, r0, #0x1f
> - orr r0, r0, #0xd3
> - msr cpsr,r0
> -
> -/*************************************************************************
> - *
> - * cpu_init_cp15
> - *
> - * Setup CP15 registers (cache, MMU, TLBs). The I-cache is turned on unless
> - * CONFIG_SYS_ICACHE_OFF is defined.
> - *
> - *************************************************************************/
> -ENTRY(cpu_init_cp15)
> - /*
> - * Invalidate L1 I/D
> - */
> - mov r0, #0 @ set up for MCR
> - mcr p15, 0, r0, c8, c7, 0 @ invalidate TLBs
> - mcr p15, 0, r0, c7, c5, 0 @ invalidate icache
> - mcr p15, 0, r0, c7, c5, 6 @ invalidate BP array
> - mcr p15, 0, r0, c7, c10, 4 @ DSB
> - mcr p15, 0, r0, c7, c5, 4 @ ISB
> -
> - /*
> - * disable MMU stuff and caches
> - */
> - mrc p15, 0, r0, c1, c0, 0
> - bic r0, r0, #0x00002000 @ clear bits 13 (--V-)
> - bic r0, r0, #0x00000007 @ clear bits 2:0 (-CAM)
> - orr r0, r0, #0x00000002 @ set bit 1 (--A-) Align
> - orr r0, r0, #0x00000800 @ set bit 11 (Z---) BTB
> - orr r0, r0, #0x00001000 @ set bit 12 (I) I-cache
> - mcr p15, 0, r0, c1, c0, 0
> -
> movw r0, #:lower16:CONFIG_CPU1_START_ADDR
> movt r0, #:upper16:CONFIG_CPU1_START_ADDR
>
> diff --git a/arch/arm/mach-socfpga/platsmp.c b/arch/arm/mach-socfpga/platsmp.c
> index 34440aa..60c2b4a 100644
> --- a/arch/arm/mach-socfpga/platsmp.c
> +++ b/arch/arm/mach-socfpga/platsmp.c
> @@ -26,7 +26,7 @@
> #include <asm/smp_scu.h>
> #include <asm/smp_plat.h>
>
> -#include <mach/core.h>
> +#include "core.h"
>
> static void __iomem *sys_manager_base_addr;
> static void __iomem *rst_manager_base_addr;
> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
> index 68d32cd..741b9ba 100644
> --- a/arch/arm/mach-socfpga/socfpga.c
> +++ b/arch/arm/mach-socfpga/socfpga.c
> @@ -23,7 +23,7 @@
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
>
> -#include <mach/core.h>
> +#include "core.h"
>
> void __iomem *socfpga_scu_base_addr = ((void __iomem *)(SOCFPGA_SCU_VIRT_BASE));
> void __iomem *rst_manager_base_addr = ((void __iomem *)(SOCFPGA_RST_MANAGER_VIRT_BASE));
>
^ permalink raw reply
* [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug
From: Rob Herring @ 2012-10-17 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507EDB37.1060102@wwwdotorg.org>
On 10/17/2012 11:22 AM, Stephen Warren wrote:
> On 10/17/2012 08:38 AM, Rob Herring wrote:
>> On 10/15/2012 02:07 PM, Stephen Warren wrote:
>>> From: Stephen Warren <swarren@nvidia.com>
>>>
>>> Move Tegra's debug-macro.S over to the common debug macro directory.
>>>
>>> Move Tegra's debug UART selection menu into ARM's Kconfig.debug, so that
>>> all related options are selected in the same place.
>>>
>>> Tegra's uncompress.h is left in mach-tegra/include/mach; it will be
>>> removed whenever Tegra is converted to multi-platform.
>>>
>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>> ---
>>> Rob, Arnd, Olof, I'd particularly like feedback on whether the following:
>>>
>>> #include "../../mach-tegra/iomap.h"
>>>
>>> in arch/arm/include/debug/tegra.S is acceptable. I'd really like to
>>> continue to #include a header to share the defines to Tegra physical
>>> memory layout and virtual based addresses with Tegra's io.c's struct
>>> map_desc entries, so they can't get out of sync. So, the include can
>>> either use the relative path as quoted above (which I don't think will
>>> cause any significant maintenance issue), or Tegra's iomap.h would have
>>> to be moved somewhere public so e.g. <tegra-iomap.h> could be included.
>>
>> We already have a way to get the phys and virt addresses at runtime with
>> addruart macro.
>
> So this discussion is mainly about the implementation of addruart.
>
>> Couldn't we wrap this with a proper function and setup
>> the mapping at runtime. This would move it out of the platforms.
>
> So, the mapping already is set up at run-time at least during early
> boot; __create_page_tables() in arch/arm/kernel/head.S calls addruart
> and sets up an entry for it.
>
> I suppose the implication here is that the virtual address that addruart
> returns doesn't have to match anything that the machine later sets up
> using iotable_init().
>
> If that's true, then Tegra's debug-macro.S only needs to know the UART
> physical address, and can make up almost any arbitrary virtual address
> (perhaps even driven by the logic you mention in your next paragraph
> below) and hence need not rely on Tegra's iomap.h. That said, we'd still
> have to manually remember not to create conflicting virtual address
> setups in the two places, which would still be easier with a shared header.
The virtual address has to remain the same.
A non-platform specific header for a fixed virtual address define would
be cleaner than relative includes.
>
> However, I then have two questions:
>
> 1) How long do the page tables set up by __create_page_tables() last; do
> they stick around forever, or at least as long as the macros from
> debug-macro.S are used, or are they replaced sometime, on the assumption
> that the machine's .map_io() will call iotable_init() and end up setting
> up the same mapping?
It works to...
[ 0.000000] Booting Linux on physical CPU 0
[ 0.000000] Linux version 3.5.4+ (rob at rob-laptop) (gcc version 4.7.2
(Ubuntu/Linaro 4.7.2-1ubuntu1) ) #280 SMP Wed Oct 17 18:00:29 CDT 2012 ()
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7),
cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] Machine: Highbank, model: Calxeda Highbank
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] cma: CMA: reserved 16 MiB at 2e800000
[ 0.000000] Memory policy: ECC disabled, Data cache writealloc
...here with no iotable mapping.
>
> 2) If the virtual address returned by addruart on Tegra is different
> than any virtual addresses set up by Tegra's .map_io(), and Tegra's
> .map_io() sets up a very broad mapping that covers all peripherals
> including the UART, and hence the UART physical registers get mapped
> into two virtual addresses, will this cause any problems? IIRC,
> duplicate mappings can cause some issues on ARM, but perhaps that only
> applies to memory-like mappings, and not completely uncached IO mappings?
The virt address has to match. It can initially be a 1MB section and
then replaced with a 4K entry, but the same DEBUG_LL macros are used
throughout the boot process as the mapping is updated.
Duplicate mappings of different memory types is the problem. Multiple
mapping of the same type are fine and common (the zero page for example).
Rob
^ permalink raw reply
* [GIT PULL] ARM: tegra: fixes for 3.7-rc2
From: Stephen Warren @ 2012-10-17 23:10 UTC (permalink / raw)
To: linux-arm-kernel
This branch contains a couple small fixes for Tegra for 3.7.
* A fix for another clock rate calculation overflow
* A revert of a change that removed the "timer" clock on Tegra, coupled
with a fix for the confusing symbol name clash that triggered it.
----------------------------------------------------------------
BTW, I signed this tag with my swarren at nvidia.com key; it's a different key
to the one I used before, but has the same signatures and should show up on
all the same keyservers.
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.7-fixes-for-rc2
for you to fetch changes up to bf88ef883585ebc1a6c2369483833ed11ca7666c:
ARM: tegra: add tegra_timer clock
----------------------------------------------------------------
Mark Zhang (1):
ARM: tegra30: clk: Fix output_rate overflow
Sivaram Nair (2):
ARM: tegra: rename tegra system timer
ARM: tegra: add tegra_timer clock
arch/arm/mach-tegra/board-dt-tegra20.c | 2 +-
arch/arm/mach-tegra/board-dt-tegra30.c | 2 +-
arch/arm/mach-tegra/board.h | 2 +-
arch/arm/mach-tegra/tegra20_clocks_data.c | 1 +
arch/arm/mach-tegra/tegra30_clocks.c | 2 +-
arch/arm/mach-tegra/tegra30_clocks_data.c | 1 +
arch/arm/mach-tegra/timer.c | 2 +-
7 files changed, 7 insertions(+), 5 deletions(-)
^ permalink raw reply
* RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support")
From: Kevin Hilman @ 2012-10-17 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017143534.GJ11394@arwen.pp.htv.fi>
Felipe Balbi <balbi@ti.com> writes:
> On Wed, Oct 17, 2012 at 05:00:02PM +0300, Felipe Balbi wrote:
>>
>> On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
>> > + peterz, tglx
>> >
>> > Felipe Balbi <balbi@ti.com> writes:
>> >
>> > [...]
>> >
>> > > The problem I see is that even though we properly return IRQ_WAKE_THREAD
>> > > and wake_up_process() manages to wakeup the IRQ thread (it returns 1),
>> > > the thread is never scheduled. To make things even worse, ouw irq thread
>> > > runs once, but doesn't run on a consecutive call. Here's some (rather
>> > > nasty) debug prints showing the problem:
>> >
>> > [...]
>> >
>> > >> [ 88.721923] try_to_wake_up 1411
>> > >> [ 88.725189] ===> irq_wake_thread 139: IRQ 72 wake_up_process 0
>> > >> [ 88.731292] [sched_delayed] sched: RT throttling activated
>> >
>> > This throttling message is the key one.
>> >
>> > With RT throttling activated, the IRQ thread will not be run (it
>> > eventually will be allowed much later on, but by then, the I2C xfers
>> > have timed out.)
>> >
>> > As a quick hack, the throttling can be disabled by seeting the
>> > sched_rt_runtime to RUNTIME_INF:
>> >
>> > # sysctl -w kernel.sched_rt_runtime_us=-1
>> >
>> > and a quick test shows that things go back to working as expected. But
>> > we still need to figure out why the throttling is hapenning...
>> >
>> > So I started digging into why the RT runtime was so high, and noticed
>> > that time spent in suspend was being counted as RT runtime!
>> >
>> > So spending time in suspend anywhere near sched_rt_runtime (0.95s) will
>> > cause the RT throttling to always be triggered, and thus prevent IRQ
>> > threads from running in the resume path. Ouch.
>> >
>> > I think I'm already in over my head in the RT runtime stuff, but
>> > counting the time spent in suspend as RT runtime smells like a bug to
>> > me. no?
>> >
>> > Peter? Thomas?
>>
>> it looks like removing console output completely (echo 0 >
>> /proc/sysrq-trigger) I don't see the issue anymore. Let me just run for
>> a few more iterations to make sure what I'm saying is correct.
>
> Yeah, really looks like removing console output makes the problem go
> away. Ran a few iterations and it always worked fine. Full logs attached
Removing console output during resume is going to significantly change
the timing of what is happening during suspend/resume, so I suspect that
combined with all your other debug prints is somehow masking the
problem. How log are you letting the system stay in suspend?
That being said, I can still easily reproduce the problem, even with
console output disabled.
With vanilla v3.7-rc1 + the debug patch below[1], with and without
console output, I see RT throttling kicking in on resume, and the RT
runtime on resume corresponds to the time spent in suspend. Here's an
example of debug output of my patch below after ~3 sec in suspend:
[ 43.198028] sched_rt_runtime_exceeded: rt_time 2671752930 > runtime 950000000
[ 43.198028] update_curr_rt: RT runtime exceeded: irq/72-omap_i2c
[ 43.198059] update_curr_rt: RT runtime exceeded: irq/72-omap_i2c
[ 43.203704] [sched_delayed] sched: RT throttling activated
I see this rather consistently, and the rt_time value is always roughly the
time I spent in suspend.
So the primary question remains: is RT runtime supposed to include the
time spent suspended? I suspect not.
Kevin
[1]
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 418feb0..39de750 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -891,6 +891,8 @@ static int sched_rt_runtime_exceeded(struct rt_rq *rt_rq)
if (!once) {
once = true;
printk_sched("sched: RT throttling activated\n");
+ pr_warn("%s: rt_time %llu > runtime %llu\n",
+ __func__, rt_rq->rt_time, runtime);
}
} else {
/*
@@ -948,8 +950,11 @@ static void update_curr_rt(struct rq *rq)
if (sched_rt_runtime(rt_rq) != RUNTIME_INF) {
raw_spin_lock(&rt_rq->rt_runtime_lock);
rt_rq->rt_time += delta_exec;
- if (sched_rt_runtime_exceeded(rt_rq))
+ if (sched_rt_runtime_exceeded(rt_rq)) {
+ pr_warn("%s: RT runtime exceeded: %s\n",
+ __func__, curr->comm);
resched_task(curr);
+ }
raw_spin_unlock(&rt_rq->rt_runtime_lock);
}
}
^ permalink raw reply related
* [PATCHv1] arm:socfpga: Enable SMP for socfpga
From: Pavel Machek @ 2012-10-17 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507F01FD.6070403@gmail.com>
Hi!
> > arch/arm/mach-socfpga/Kconfig | 1 +
> > arch/arm/mach-socfpga/Makefile | 3 +
> > arch/arm/mach-socfpga/headsmp.S | 64 +++++++++++
> > arch/arm/mach-socfpga/include/mach/core.h | 33 ++++++
>
> Move core.h to mach-socfpga.
> > +ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include
> > +
>
> This can be removed if core.h is moved.
Ok, makes code nicer. Sorry for copying picoxcell too much.
> > + __INIT
> > +
> > +#define CPU1_START_ADDR 0xffd08010
> > +
> > +ENTRY(secondary_trampoline)
>
> This appears to be your reset code at phys addr 0. How does core 0 boot
> if you are copying this to 0?
Yes, this is reset code, goes at zero. Core 0 has already booted by
the time we are trying to boot Core 1 (we don't support CPU hotplug,
yet). Is that a problem?
> > + /* From u-boot: start.S */
> > + mrs r0, cpsr
> > + bic r0, r0, #0x1f
> > + orr r0, r0, #0xd3
> > + msr cpsr,r0
...
> > + * disable MMU stuff and caches
> > + */
> > + mrc p15, 0, r0, c1, c0, 0
> > + bic r0, r0, #0x00002000 @ clear bits 13 (--V-)
> > + bic r0, r0, #0x00000007 @ clear bits 2:0 (-CAM)
> > + orr r0, r0, #0x00000002 @ set bit 1 (--A-) Align
> > + orr r0, r0, #0x00000800 @ set bit 11 (Z---) BTB
> > + orr r0, r0, #0x00001000 @ set bit 12 (I) I-cache
>
> All this should get done by v7_setup.
It seems it is, as (emulated) system still boots with that code
disabled.
> > +static DEFINE_SPINLOCK(boot_lock);
> > +
> > +static void __cpuinit socfpga_secondary_init(unsigned int cpu)
> > +{
> > + /*
> > + * if any interrupts are already enabled for the primary
> > + * core (e.g. timer irq), then they will not have been enabled
> > + * for us: do so
> > + */
> > + gic_secondary_init(0);
> > +
> > + /*
> > + * let the primary processor know we're out of the
> > + * pen, then head off into the C entry point
> > + */
> > + pen_release = -1;
> > + smp_wmb();
> > +
> > + /*
> > + * Synchronise with the boot thread.
> > + */
> > + spin_lock(&boot_lock);
> > + spin_unlock(&boot_lock);
> > +}
> > +
> > +static int __cpuinit socfpga_boot_secondary(unsigned int cpu, struct task_struct *idle)
> > +{
> > + unsigned long timeout;
> > + extern char secondary_trampoline, secondary_trampoline_end;
> > +
> > + int trampoline_size = &secondary_trampoline_end - &secondary_trampoline;
> > +
> > + /*
> > + * Set synchronisation state between this boot processor
> > + * and the secondary one
> > + */
> > + spin_lock(&boot_lock);
> > +
> > + memcpy(phys_to_virt(0), &secondary_trampoline, trampoline_size);
> > +
> > + __raw_writel(virt_to_phys(secondary_startup), (sys_manager_base_addr+0x10));
> > +
> > + pen_release = 0;
> > + flush_cache_all();
> > + smp_wmb();
> > + outer_clean_range(0, trampoline_size);
> > +
> > + /* This will release CPU #1 out of reset.*/
> > + __raw_writel(0, rst_manager_base_addr + 0x10);
> > +
> > + timeout = jiffies + (1 * HZ);
> > + while (time_before(jiffies, timeout)) {
> > + smp_rmb();
> > + if (pen_release == -1)
> > + break;
> > +
> > + udelay(10);
> > + }
> > +
> > + /*
> > + * now the secondary core is starting up let it run its
> > + * calibrations, then wait for it to finish
> > + */
> > + spin_unlock(&boot_lock);
> > + return pen_release != -1 ? -ENOSYS : 0;
>
> You don't need any of this if you can reset secondary cores on
> hotplug.
What exactly is unneccessary? I'd like to wait for secondary to come
up so we can raise an error if it does not...?
Thanks,
Pavel
PS: I have this so far...
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 659fd27..a0fc372 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -2,7 +2,5 @@
# Makefile for the linux kernel.
#
-ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include
-
obj-y := socfpga.o
obj-$(CONFIG_SMP) += headsmp.o platsmp.o hotplug.o
diff --git a/arch/arm/mach-socfpga/include/mach/core.h b/arch/arm/mach-socfpga/core.h
similarity index 100%
rename from arch/arm/mach-socfpga/include/mach/core.h
rename to arch/arm/mach-socfpga/core.h
diff --git a/arch/arm/mach-socfpga/headsmp.S b/arch/arm/mach-socfpga/headsmp.S
index 9597ff7..081b4d1 100644
--- a/arch/arm/mach-socfpga/headsmp.S
+++ b/arch/arm/mach-socfpga/headsmp.S
@@ -20,42 +20,6 @@
#define CONFIG_CPU1_START_ADDR (CONFIG_SYSTEM_MANAGER + 0x10)
ENTRY(secondary_trampoline)
- /* From u-boot: start.S */
- mrs r0, cpsr
- bic r0, r0, #0x1f
- orr r0, r0, #0xd3
- msr cpsr,r0
-
-/*************************************************************************
- *
- * cpu_init_cp15
- *
- * Setup CP15 registers (cache, MMU, TLBs). The I-cache is turned on unless
- * CONFIG_SYS_ICACHE_OFF is defined.
- *
- *************************************************************************/
-ENTRY(cpu_init_cp15)
- /*
- * Invalidate L1 I/D
- */
- mov r0, #0 @ set up for MCR
- mcr p15, 0, r0, c8, c7, 0 @ invalidate TLBs
- mcr p15, 0, r0, c7, c5, 0 @ invalidate icache
- mcr p15, 0, r0, c7, c5, 6 @ invalidate BP array
- mcr p15, 0, r0, c7, c10, 4 @ DSB
- mcr p15, 0, r0, c7, c5, 4 @ ISB
-
- /*
- * disable MMU stuff and caches
- */
- mrc p15, 0, r0, c1, c0, 0
- bic r0, r0, #0x00002000 @ clear bits 13 (--V-)
- bic r0, r0, #0x00000007 @ clear bits 2:0 (-CAM)
- orr r0, r0, #0x00000002 @ set bit 1 (--A-) Align
- orr r0, r0, #0x00000800 @ set bit 11 (Z---) BTB
- orr r0, r0, #0x00001000 @ set bit 12 (I) I-cache
- mcr p15, 0, r0, c1, c0, 0
-
movw r0, #:lower16:CONFIG_CPU1_START_ADDR
movt r0, #:upper16:CONFIG_CPU1_START_ADDR
diff --git a/arch/arm/mach-socfpga/platsmp.c b/arch/arm/mach-socfpga/platsmp.c
index 34440aa..60c2b4a 100644
--- a/arch/arm/mach-socfpga/platsmp.c
+++ b/arch/arm/mach-socfpga/platsmp.c
@@ -26,7 +26,7 @@
#include <asm/smp_scu.h>
#include <asm/smp_plat.h>
-#include <mach/core.h>
+#include "core.h"
static void __iomem *sys_manager_base_addr;
static void __iomem *rst_manager_base_addr;
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index 68d32cd..741b9ba 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -23,7 +23,7 @@
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
-#include <mach/core.h>
+#include "core.h"
void __iomem *socfpga_scu_base_addr = ((void __iomem *)(SOCFPGA_SCU_VIRT_BASE));
void __iomem *rst_manager_base_addr = ((void __iomem *)(SOCFPGA_RST_MANAGER_VIRT_BASE));
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply related
* PDF documentation
From: Peter Stuge @ 2012-10-17 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017222955.GQ21164@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> If there was not a problem here, all documentation would explicitly
> state that it is able to be freely distributed.
Lawyers like job security as much as the guy on the floor, theirs
just involves different psychology.
//Peter
^ permalink raw reply
* PDF documentation
From: Russell King - ARM Linux @ 2012-10-17 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017222520.10925.qmail@stuge.se>
On Thu, Oct 18, 2012 at 12:25:20AM +0200, Peter Stuge wrote:
> Russell King - ARM Linux wrote:
> > You have to be careful of copyright infringement.
>
> Yeah, because a company might sue for datasheet copyright
> infringement when someone is (if only potentially) buying
> their product.
>
> I would think that one through one more time. :)
No, I did. You take a copy of the data sheet and republish it publically.
Take a moment to think about that...
Consider also, from their point of view, the issue of documentation
control. Notice that most companies don't provide download links for
old documentation...
If there was not a problem here, all documentation would explicitly
state that it is able to be freely distributed. However, this is not
the case. Maybe you should read the legal status of documentation from
ARM? It explicitly states that you are not permitted to redistribute
it... why put that in if you don't mean it?
^ permalink raw reply
* [Celinux-dev] PDF documentation
From: Constantine Shulyupin @ 2012-10-17 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507F2B6D.9070607@am.sony.com>
On Thu, Oct 18, 2012 at 12:04 AM, Tim Bird <tim.bird@am.sony.com> wrote:
> Being able to identify a page of an existing online PDF is already
> possible with URLs. See
> http://stackoverflow.com/questions/125632/is-it-possible-to-link-to-a-bookmark-within-a-pdf-using-url-parameters
Yes, I know. I already wrote about it the fist e-mail. It is not
applicable in all cases.
> So, the following would get you to page 34, in the original PDF:
> http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/DBACA1C90564EBB248257639003A563A/$File/MX29GL128E,%203V%20(VI-O),%20128Mb,%20v1.5.pdf#page=34
Yes, it works when pdf is hosted properly (not forced for download),
not archived and relatively small.
This method will not work with
http://focus.ti.com/pdfs/wtbu/OMAP4460_ES1.x_PUBLIC_TRM_vI.zip
Even unzipped pdf is 23 MB - too heavy for online browning.
> Careful there. These documents are copyright. Even though the OMAP4460 document
> says it is "public", I'm not sure it's legal to post verbatim contents to a web site.
>
> So - useful or not, I'm worried it's not legal.
> -- Tim
Quote:
Reproduction of significant portions of TI information in TI data
books or data sheets is permissible only if reproduction is without
alteration and is accompanied by all associated warranties,
conditions, limitations, and notices.
from http://makelinux.net/lib/ti/OMAP4460/doc-5864
Thank you, Tim.
>
> =============================
> Tim Bird
> Architecture Group Chair, CE Workgroup of the Linux Foundation
> Senior Staff Engineer, Sony Network Entertainment
> =============================
>
--
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci
^ permalink raw reply
* PDF documentation
From: Peter Stuge @ 2012-10-17 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017221940.GP21164@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> You have to be careful of copyright infringement.
Yeah, because a company might sue for datasheet copyright
infringement when someone is (if only potentially) buying
their product.
I would think that one through one more time. :)
//Peter
^ permalink raw reply
* PDF documentation
From: Russell King - ARM Linux @ 2012-10-17 22:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016140555.12139.qmail@stuge.se>
On Tue, Oct 16, 2012 at 04:05:55PM +0200, Peter Stuge wrote:
> > Sometimes it is more easy just to copy paste and send by email part
> > of documentation instead of using hyperlinks.
>
> A group collaborating around a given hardware certainly needs a
> common repository of documentation. A file server is often used
> internally. I like to use wikis for public projects. They make it
> easy to upload PDF files, references can be made to page
> number+section.
This actually depends. You have to be careful of copyright infringement.
Generally, you are allowed to download and store one copy of the
documentation for your own personal use and not redistribute it. Whether
it says for personal use or not is another gotcha there.
Most places have fair use allowed in law, which means that the copy and
paste of limited extracts is permitted - but in this day and age of global
networks, you have to be really careful because your local law may not
be the applicable law.
> > I found, that it is more easy work (and work collaboratively) with
> > documentation in HTML format. Sometimes it is possible just to
> > convert PDF to HTML.
>
> I strongly prefer working with PDF because it is the canonical
> documentation made available by the manufacturer and because my
> PDF readers are much much better than my HTML readers.
Again, copyright may be an issue with this kind of approach, because
you're technically redistributing someone elses work. You need to
check what you're permitted to do with each document before you do it,
and if you aren't permitted to redistribute it, seek permission from the
copyright owner.
I'm not sure how the various datasheet sites get around this, but I
suspect they may have negotiated blanket permissions with most of the
silicon manufacturers, espsecially as some modify the PDFs adding
a final page to them.
> More useful for initial impression, yes, but under no circumstance do
> I think HTML would be a good replacement for PDF. Already the fact
> that PDF is self-contained but HTML is not should suggest that HTML
> is a poor representation outside the web browser, for anything
> really.
The big problem with anything online is that you must be online to access
it. If your connection to the Internet goes down, you lose access to
that information. If the site hosting it goes down, same problem...
(In the old days of databooks, companies used to either be given the
databook by the sales rep, or -rarely- they bought the databook, and
the book sat in the companies library... and any employee could make
use of that single copy...)
^ permalink raw reply
* [Celinux-dev] PDF documentation
From: Tim Bird @ 2012-10-17 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAE7jHC_PL_C-4eY6LaKsfqdYhT2AR-djo3Swn6dmYZYPKJOX3w@mail.gmail.com>
On 10/17/2012 12:26 PM, Constantine Shulyupin wrote:
> On Wed, Oct 17, 2012 at 6:51 PM, Peter Stuge <peter@stuge.se> wrote:
>> Constantine Shulyupin wrote:
>>> Peter, can you please just send me some links to most frequently
>>> used online PDF?
>>
>> I don't have a particular PDF that is used more frequently than
>> others. Here's one I used recently, for a common flash chip:
>>
>> http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/DBACA1C90564EBB248257639003A563A/$File/MX29GL128E,%203V%20(VI-O),%20128Mb,%20v1.5.pdf
>>
>>> I would like to convert them to html and see how usable it is.
>
> I've converted you pdf and uploaded to a site:
> http://makelinux.net/lib/macronix/MX29GL128E/
>
> It can't even approach to replase PDF, but it adds possibility to
> send in a e-mail link to a specific page:
> COMMON FLASH MEMORY INTERFACE (CFI) MODE:
> http://makelinux.net/lib/macronix/MX29GL128E/doc-34
> http://makelinux.net/lib/macronix/MX29GL128E/doc-35
Being able to reference an individual page, table or section of a PDF
with a click would indeed be a nice feature.
Being able to identify a page of an existing online PDF is already
possible with URLs. See
http://stackoverflow.com/questions/125632/is-it-possible-to-link-to-a-bookmark-within-a-pdf-using-url-parameters
So, the following would get you to page 34, in the original PDF:
http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/DBACA1C90564EBB248257639003A563A/$File/MX29GL128E,%203V%20(VI-O),%20128Mb,%20v1.5.pdf#page=34
> Here is jet another document, huge 5K pages DS of OMAP4460:
> http://makelinux.net/lib/ti/OMAP4460/
> http://makelinux.net/lib/ti/OMAP4460/doc-outline
> OMAP4460 USBPHY Registers: http://makelinux.net/lib/ti/OMAP4460/doc-5464
> Debug Modules Memory Mapping: http://makelinux.net/lib/ti/OMAP4460/doc-5845
>
> How it looks?
> Can it be useful?
Careful there. These documents are copyright. Even though the OMAP4460 document
says it is "public", I'm not sure it's legal to post verbatim contents to a web site.
So - useful or not, I'm worried it's not legal.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* [GIT PULL] omap fixes ready to go for v3.7-rc1
From: Tony Lindgren @ 2012-10-17 22:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd & Olof,
Here are the fixes ready to pull, there's at least one more fix in works
but it still requires minor changes. The two top commits are recent as
Jon Hunter noticed an issue freeing resources in his fix and I did a
new branch to swap in the fixed patch.
Regards,
Tony
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc1/fixes-take5-signed
for you to fetch changes up to 8119024ef7363591fd958ec89ebfaee7c18209e3:
ARM: OMAP2+: Allow kernel to boot even if GPMC fails to reserve memory (2012-10-17 09:01:14 -0700)
----------------------------------------------------------------
A boot problem fix for am33xx beaglebone caused by GPMC,
a regression fix for local timer, and a clockdomain locking fix.
Also few minor fixes for boot time and sparse warnings.
----------------------------------------------------------------
Benoit Cousson (1):
ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck
Jon Hunter (1):
ARM: OMAP2+: Allow kernel to boot even if GPMC fails to reserve memory
Paul Walmsley (1):
ARM: OMAP: resolve sparse warning concerning debug_card_init()
Sebastien Guiriec (1):
ARM: OMAP4: devices: fixup OMAP4 DMIC platform device error message
Tero Kristo (1):
ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable
Tony Lindgren (1):
ARM: OMAP4: Fix twd_local_timer_register regression
arch/arm/mach-omap2/clock44xx_data.c | 2 +-
arch/arm/mach-omap2/clockdomain.c | 15 +++++++++++----
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/gpmc.c | 24 +++++++++++++++++++-----
arch/arm/mach-omap2/timer.c | 2 +-
arch/arm/plat-omap/debug-devices.c | 1 +
6 files changed, 34 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PULL REQ] IXP4xx changes for Linux 3.7
From: Krzysztof Halasa @ 2012-10-17 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210142002.55841.arnd@arndb.de>
Hi,
Arnd Bergmann <arnd@arndb.de> writes:
> as mentioned before, all arch/arm/mach-* patches should go through the
> arm-soc tree or get an Ack from the arm-soc maintainers. The same thing
> is true for the char-misc and the crypto trees.
You've seen the changes. They were trivial fixes, touched only
IXP4xx-related areas, there was nothing related to char or crypto
subsystems there, except file location (well, IXP4xx drivers have to be
located somewhere).
The patches have been posted to linux-arm-kernel and you knew about
them. That they were obviously correct and clean is probably not
that important.
Nobody bothered to comment the patches.
> Also, never rebase your tree immediately before sending a pull
> request.
I did not, of course. My mail stated:
"Build-tested for now. This is based on your current tree tip because it
depends on commits following 3.6 release."
Normally I wouldn't rebase, but had to (as you well knew) - because you
commited a conflicting patch to this very IXP4xx arch. Using your logic,
you were supposed to get an Ack from me (or from Imre) for this patch.
Actually it wasn't a problem for me, I simply had to rebase.
> Finally when sending bug fixes, please annotate any patches with
> 'Cc: stable at vger.kernel.org' if they address bugs that are already
> present in older kernels, so that the stable and longterm maintainers
> can easily backport the fixes.
I do that when I think it makes sense. In this case (two patches for
Goramo MultiLink platform) practically all such devices use kernels
prepared by me, and I think Greg (and others) have more efficient ways
to spend their time than handling almost unused patches. Also, I have
much more efficient ways to spend time. Anyway, if I can't have my
patches upstream, why should they end up in stable?
> Almost all of the platform patches in your tree seem to be bug fixes,
> so they are still good for inclusion in v3.7 if you submit them to
> arm-soc soon, but please make sure you separate bug fixes from other
> changes so we can group them appropriately when forwarding them to
> Linus.
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.
BTW since Imre has probably even much less time, it would be a good time
to find someone to maintain IXP4xx code. I will be publishing (from time
to time) my tree (I'm using the hw myself), so even simple
cherry-picking would probably make some sense.
--
Krzysztof Halasa
^ permalink raw reply
* IS_ERR_OR_NULL - please STOP telling people to use this on a whim
From: Russell King - ARM Linux @ 2012-10-17 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017202848.GF22812@fatphil.org>
On Wed, Oct 17, 2012 at 11:28:48PM +0300, Phil Carmody wrote:
> So, what to do? It can and has been used sensibly, so I don't think removing
> it is the best option.
Well, the first thing that needs to be done is a full review of every user
and fixes applied.
The second thing is that we need eyes on code _and_ review comments, and
educate those who are telling people to use IS_ERR_OR_NULL() whenever they
see an IS_ERR() to think about the code a little more - that's kind of the
purpose of my email.
Unfortunately, it's going to take time to achieve a change, and if I end
up being the only one who's spotting these errors, I'm going to get
incredibly pissed off at doing so (because it will feel like I'm being
ignored when there's a constant stream of it.)
Another thing would be to work out whether we can get checkpatch to
detect usage of IS_ERR_OR_NULL(p) followed by PTR_ERR(p) without any
explicit NULL checks against p in the same block. That's probably
going to be interesting to code up in perl.
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Only write the sysconfig on idle when necessary
From: Jon Hunter @ 2012-10-17 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210172046100.9767@utopia.booyaka.com>
On 10/17/2012 03:58 PM, Paul Walmsley wrote:
> On Wed, 17 Oct 2012, Jon Hunter wrote:
>
>> Are you looking to go one step further and only update the sysconfig on
>> enabling when the context has been lost? That would require more
>> changes.
>
> Yes that's exactly it. That would avoid adding a special case for what
> should be the common case. From a quick glance it looks like the cache
> needs to be loaded in _reset(), omap_hwmod_softreset(), and _enable().
> Other than that, seems like the cached value should work.
>
> It should also be possible to avoid the reload in _enable() in most cases
> since the PM code should know whether the IP block's powerdomain was
> programmed to go off and indeed whether it did so. It shouldn't involve
> any extra register reads. But I wouldn't expect you to add that
> optimization; would just be nice to have a comment to that effect.
Ah, so you really want the cache to behave like a cache. That would be nice!
> If the meta-theme of your message is that commit
> 233cbe5b94096f95ba7bca2162d63275b0b90b5b should have had closer scrutiny,
> I agree with you, but we're beyond that point now...
No under-lying theme here, just more of a "I stumbled across this while
debugging something else" and I am a nut-case about saving cpu cycles
where I can. Although not always possible and I am probably responsible
for burning more cycles than I am saving these days!
Cheers
Jon
^ permalink raw reply
* [PATCH] Nokia N9/N900/N950 -- mention product names
From: Aaro Koskinen @ 2012-10-17 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017210300.GB12560@elf.ucw.cz>
On Wed, Oct 17, 2012 at 11:03:00PM +0200, Pavel Machek wrote:
>
> This adds product names (that most users know) to Kconfig and board
> comments.
>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 346fd26..f03f19a 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -263,14 +263,14 @@ config MACH_NOKIA_N8X0
> select MACH_NOKIA_N810_WIMAX
>
> config MACH_NOKIA_RM680
> - bool "Nokia RM-680/696 board"
> + bool "Nokia N950 (RM-680) / N9 (RM-696) phones"
> depends on ARCH_OMAP3
> default y
> select OMAP_PACKAGE_CBB
> select MACH_NOKIA_RM696
>
> config MACH_NOKIA_RX51
> - bool "Nokia RX-51 board"
> + bool "Nokia N900 (RX-51) phone"
> depends on ARCH_OMAP3
> default y
> select OMAP_PACKAGE_CBB
> diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c
> index 0ad1bb3b..96f8757 100644
> --- a/arch/arm/mach-omap2/board-rm680.c
> +++ b/arch/arm/mach-omap2/board-rm680.c
> @@ -1,5 +1,5 @@
> /*
> - * Board support file for Nokia RM-680/696.
> + * Board support file for Nokia N950 (RM-680) / N9 (RM-696).
> *
> * Copyright (C) 2010 Nokia
> *
> diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
> index 345dd93..b60ca9d 100644
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
> @@ -1,5 +1,5 @@
> /*
> - * linux/arch/arm/mach-omap2/board-rx51.c
> + * Board support file for Nokia N900 (aka RX-51).
> *
> * Copyright (C) 2007, 2008 Nokia
> *
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug
From: Stephen Warren @ 2012-10-17 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507EDB37.1060102@wwwdotorg.org>
On 10/17/2012 10:22 AM, Stephen Warren wrote:
> On 10/17/2012 08:38 AM, Rob Herring wrote:
>> On 10/15/2012 02:07 PM, Stephen Warren wrote:
>>> From: Stephen Warren <swarren@nvidia.com>
>>>
>>> Move Tegra's debug-macro.S over to the common debug macro directory.
>>>
>>> Move Tegra's debug UART selection menu into ARM's Kconfig.debug, so that
>>> all related options are selected in the same place.
>>>
>>> Tegra's uncompress.h is left in mach-tegra/include/mach; it will be
>>> removed whenever Tegra is converted to multi-platform.
>>>
>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>> ---
>>> Rob, Arnd, Olof, I'd particularly like feedback on whether the following:
>>>
>>> #include "../../mach-tegra/iomap.h"
>>>
>>> in arch/arm/include/debug/tegra.S is acceptable. I'd really like to
>>> continue to #include a header to share the defines to Tegra physical
>>> memory layout and virtual based addresses with Tegra's io.c's struct
>>> map_desc entries, so they can't get out of sync. So, the include can
>>> either use the relative path as quoted above (which I don't think will
>>> cause any significant maintenance issue), or Tegra's iomap.h would have
>>> to be moved somewhere public so e.g. <tegra-iomap.h> could be included.
>>
>> We already have a way to get the phys and virt addresses at runtime with
>> addruart macro.
>
> So this discussion is mainly about the implementation of addruart.
>
>> Couldn't we wrap this with a proper function and setup
>> the mapping at runtime. This would move it out of the platforms.
>
> So, the mapping already is set up at run-time at least during early
> boot; __create_page_tables() in arch/arm/kernel/head.S calls addruart
> and sets up an entry for it.
>
> I suppose the implication here is that the virtual address that addruart
> returns doesn't have to match anything that the machine later sets up
> using iotable_init().
>
> If that's true, then Tegra's debug-macro.S only needs to know the UART
> physical address, and can make up almost any arbitrary virtual address
> (perhaps even driven by the logic you mention in your next paragraph
> below) and hence need not rely on Tegra's iomap.h. That said, we'd still
> have to manually remember not to create conflicting virtual address
> setups in the two places, which would still be easier with a shared header.
>
> However, I then have two questions:
>
> 1) How long do the page tables set up by __create_page_tables() last; do
> they stick around forever, or at least as long as the macros from
> debug-macro.S are used, or are they replaced sometime, on the assumption
> that the machine's .map_io() will call iotable_init() and end up setting
> up the same mapping?
So answering my own question here after testing this:
If I use a different (to iomap.h) virtual address in debug-macro.S, then
the very very early output from earlyprintk does work:
> [ 0.000000] Booting Linux on physical CPU 0
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Linux version 3.7.0-rc1-next-20121016-...
> [ 0.000000] CPU: ARMv7 Processor [411fc090] revision 0 (ARMv7), cr=10c5387d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [ 0.000000] Machine: nVidia Tegra20 (Flattened Device Tree), model: NVIDIA Tegra2 Harmony evaluation board
> [ 0.000000] bootconsole [earlycon0] enabled
> [ 0.000000] Memory policy: ECC disabled, Data cache writealloc
However, the kernel either hangs or output simply stops working at that
point. If I modify Tegra's iotable_init() call to add an entry to map
the UART to the virtual address debug-macro.S assumes, then everything
works again.
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:
a) Move mach-${mach}/include/mach/iomap.h to iomap-${mach}.h in some
standard include path.
b) Rework debug-macro.S so that it isn't an include file, but rather a
regular top-level file. In other words, rather than compiling
arch/arm/kernel/debug.S, and having that #include DEBUG_LL_INCLUDE,
instead compile DEBUG_LL_SOURCE (i.e. arch/arm/mach-${mach}/debug.S by
default), and have that #include any common parts (e.g. implementation
of printhex8). This has benefits of:
b1) arch/arm/mach-${mach}/debug.S is in the mach directory that owns it,
rather than having them all dumped into a common location.
b2) Can use #include "iomap.h", a non-relative include, to pick up the
shared header
b3) Perhaps we can simplify the current debug.S e.g. have a common
debug-semihosting.S that contains the semihosting stuff, and only
include that from mach-*/debug.S if that machine uses semihosting, or
similar?
(b) seems like a lot of work. I don't see any advantage of (a) over just
using the relative include.
^ permalink raw reply
* discrepancy while save and restore of debounce registers
From: Jon Hunter @ 2012-10-17 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1BAFE6F6C881BF42822005164F1491C33EAA9A7C@DBDE01.ent.ti.com>
Hi Gururaja,
On 10/17/2012 01:13 AM, Hebbar, Gururaja wrote:
> Hi,
>
> I came across a peculiar issue while updating GPIO debounce registers on
> OMAP platform.
>
> According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537
>
> gpio/omap: save and restore debounce registers
>
> GPIO debounce registers need to be saved and restored for proper functioning
> of driver.
>
> ...
> @@ -1363,6 +1369,12 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
> __raw_writel(bank->context.fallingdetect,
> bank->base + bank->regs->fallingdetect);
> __raw_writel(bank->context.dataout, bank->base + bank->regs->dataout);
> + if (bank->dbck_enable_mask) {
> + __raw_writel(bank->context.debounce, bank->base +
> + bank->regs->debounce);
> + __raw_writel(bank->context.debounce_en,
> + bank->base + bank->regs->debounce_en);
> + }
> }
>
>
> Due to copy/paste of this commit into my local tree, I missed the check for
> bank->dbck_enable_mask, and directly restored the saved value from context.
>
> After this, I saw random crashes when accessing different registers (sometimes
> its OE register and sometime its DATAOUT register).
>
> These crashes were seen across 2nd and subsequent suspend/resume.
>
> My doubt/questions are
> 1. Why should debounce registers be updated only when it's accessed previously?
If debounce is not being used by any of the gpios, then there is no need
to restore them as there are no bits set. So this makes sense and saves
a couple register writes.
> 2. What is the relation between updating debounce registers and crash seen on
> others registers?
This I am not sure about. I gave this a quick try on my omap3430 beagle
board, but I did not see any side-effects from doing this. However, if
you are always restoring the debounce context regardless of whether
debounce is being used, then you could be writing bad values to the
debounce registers as the context variables bank->context.debouce and
bank->context.debouce_en may not initialised. So that is bad. However,
that said I am still not sure how this could cause a crash.
Can you share more details on ...
1. The OMAP platform you are using?
2. What linux distro/environment you are using?
3. If there are any specific steps to reproduce this 100% of the time?
Cheers
Jon
^ permalink raw reply
* hai
From: kristian @ 2012-10-17 21:03 UTC (permalink / raw)
To: linux-arm-kernel
How are you ? !
I looked at your main picture on fb. I really like you a lot. Let us talk !
I could send you my picture if you want
Sweet Kisses
^ permalink raw reply
* [PATCH] Nokia N9/N900/N950 -- mention product names
From: Pavel Machek @ 2012-10-17 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017192525.GD1613@blackmetal.musicnaut.iki.fi>
This adds product names (that most users know) to Kconfig and board
comments.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 346fd26..f03f19a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -263,14 +263,14 @@ config MACH_NOKIA_N8X0
select MACH_NOKIA_N810_WIMAX
config MACH_NOKIA_RM680
- bool "Nokia RM-680/696 board"
+ bool "Nokia N950 (RM-680) / N9 (RM-696) phones"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
select MACH_NOKIA_RM696
config MACH_NOKIA_RX51
- bool "Nokia RX-51 board"
+ bool "Nokia N900 (RX-51) phone"
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c
index 0ad1bb3b..96f8757 100644
--- a/arch/arm/mach-omap2/board-rm680.c
+++ b/arch/arm/mach-omap2/board-rm680.c
@@ -1,5 +1,5 @@
/*
- * Board support file for Nokia RM-680/696.
+ * Board support file for Nokia N950 (RM-680) / N9 (RM-696).
*
* Copyright (C) 2010 Nokia
*
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 345dd93..b60ca9d 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -1,5 +1,5 @@
/*
- * linux/arch/arm/mach-omap2/board-rx51.c
+ * Board support file for Nokia N900 (aka RX-51).
*
* Copyright (C) 2007, 2008 Nokia
*
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply related
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