* pxa:spitz_pm.c: commit b6eede11 breaks spitz resume under certain conditions.
From: Eric Miao @ 2012-10-23 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHod+GfycPnugk0UF6aqFUb4UJwZRM_PHPiSDpGSbF3OXSwMLw@mail.gmail.com>
On Fri, Oct 19, 2012 at 7:37 PM, Marko Kati? <dromede@gmail.com> wrote:
> On Thu, Oct 18, 2012 at 11:28 AM, Marko Kati? <dromede@gmail.com> wrote:
>>> Almost there, but I guess we could do this better and less confusing by having
>>> another array, e.g. tosa_gpio18_config[], which is tosa specific, and only
>>> initialize that MFP setting in the tosa path.
>>>
>>>>
>>>> I also looked at the original sharp kernel sources.
>>>> Only tosa used the RDY signal for it's tc6393tx chip, other machines simply
>>>> configured gpio18 as output in their suspend routines.
>>
>>
>> Actually, tosa doesn't use sharpsl_pm. Tosa uses the pda-power framework.
>> I said that only tosa uses the RDY signal to point out that we
>> probably don't need
>> the mfp-config line in postsuspend. That being said, i still think
>> that the array ordering
>> fix is adequate. Maybe later we may remove the mfp-config line from
>> postsuspend when
>> we're absolutely sure it isn't necessary for devices that use spitz_pm.c.
>
> So Eric what do you think, is the simple gpio array reordering patch
> an adequate fix for this bug?
Sorry for late reply. That simple reordering still looks a bit confusing
to me, i.e. the same pin firstly configured as GPIO then RDY. Do we
have a less confusing way to fix this?
^ permalink raw reply
* Is it too strict for VIPT cache flushing in flush_cache_[mm|range]?
From: Ning Jiang @ 2012-10-23 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH3Oq6SRSeXfrW56j=brCOE5PJgfw31rOSCfm-CgJwGaiJYRsw@mail.gmail.com>
2012/10/16 Ning Jiang <ning.n.jiang@gmail.com>:
> I found that the implementation of flush_cache_mm() and
> flush_cache_range() for VIPT aliasing case is to clean + invalidate
> whole data cache, but for a physically tagged cache, why do we need to
> perform such an operation? Is it because we'll have aliasing issue?
>
> I searched through the git history and found it is brought in the
> commit "d7b6b358" "[ARM] Fix ARMv6 VIPT cache >= 32K", before that,
> there is indeed no flushing, why we "Fix ARMv6 VIPT cache >= 32K"?
>
> Sorry for asking such stupid question, but it really confuses me ;-)
>
> Thanks,
> Ning
Maybe someone in the mail list can give an answer ;-)
^ permalink raw reply
* [PATCH] clk: Make the generic clock API available by default
From: Kelvin Cheung @ 2012-10-23 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350910970-9095-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Hi Mark,
Thanks!
But the common clock infrastructure of Loongson1 has been implemented and
enabled in previous patches.
http://patchwork.linux-mips.org/patch/4268/
Please remove this arch from your patch.
2012/10/22 Mark Brown <broonie@opensource.wolfsonmicro.com>
> Rather than requiring platforms to select the generic clock API to make
> it available make the API available as a user selectable option unless the
> user either selects HAVE_CUSTOM_CLK (if they have their own implementation)
> or selects COMMON_CLK (if they depend on the generic implementation).
>
> All current architectures that HAVE_CLK but don't use the common clock
> framework have selects of HAVE_CUSTOM_CLK added.
>
> This allows drivers to use the generic API on platforms which have no need
> for the clock API at platform level.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Mike, the patch to provide a defualt clkdev.h went in during the merge
> window so it should now be safe to merge this.
>
> arch/arm/Kconfig | 13 +++++++++++++
> arch/avr32/Kconfig | 1 +
> arch/mips/Kconfig | 4 ++++
> arch/mips/loongson/Kconfig | 1 +
> arch/mips/loongson1/Kconfig | 1 +
> arch/mips/txx9/Kconfig | 1 +
> arch/powerpc/Kconfig | 1 +
> arch/unicore32/Kconfig | 1 +
> drivers/clk/Kconfig | 13 ++++++++++---
> 9 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index fe90e60..2248940 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -314,6 +314,7 @@ config ARCH_VERSATILE
> select CLKDEV_LOOKUP
> select GENERIC_CLOCKEVENTS
> select HAVE_MACH_CLKDEV
> + select HAVE_CUSTOM_CLK
> select ICST
> select PLAT_VERSATILE
> select PLAT_VERSATILE_CLCD
> @@ -327,6 +328,7 @@ config ARCH_AT91
> select ARCH_REQUIRE_GPIOLIB
> select CLKDEV_LOOKUP
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select IRQ_DOMAIN
> select NEED_MACH_GPIO_H
> select NEED_MACH_IO_H if PCCARD
> @@ -632,6 +634,7 @@ config ARCH_TEGRA
> select GENERIC_CLOCKEVENTS
> select GENERIC_GPIO
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select HAVE_SMP
> select MIGHT_HAVE_CACHE_L2X0
> select SPARSE_IRQ
> @@ -666,6 +669,7 @@ config ARCH_MSM
> select CLKDEV_LOOKUP
> select GENERIC_CLOCKEVENTS
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> help
> Support for Qualcomm MSM/QSD based systems. This runs on the
> apps processor of the MSM/QSD and depends on a shared memory
> @@ -678,6 +682,7 @@ config ARCH_SHMOBILE
> select CLKDEV_LOOKUP
> select GENERIC_CLOCKEVENTS
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select HAVE_MACH_CLKDEV
> select HAVE_SMP
> select MIGHT_HAVE_CACHE_L2X0
> @@ -728,10 +733,12 @@ config ARCH_SA1100
> config ARCH_S3C24XX
> bool "Samsung S3C24XX SoCs"
> select ARCH_HAS_CPUFREQ
> + select CLKDEV_LOOKUP
> select ARCH_USES_GETTIMEOFFSET
> select CLKDEV_LOOKUP
> select GENERIC_GPIO
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select HAVE_S3C2410_I2C if I2C
> select HAVE_S3C2410_WATCHDOG if WATCHDOG
> select HAVE_S3C_RTC if RTC_CLASS
> @@ -752,6 +759,7 @@ config ARCH_S3C64XX
> select CLKDEV_LOOKUP
> select CPU_V6
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select HAVE_S3C2410_I2C if I2C
> select HAVE_S3C2410_WATCHDOG if WATCHDOG
> select HAVE_TCM
> @@ -775,6 +783,7 @@ config ARCH_S5P64X0
> select GENERIC_CLOCKEVENTS
> select GENERIC_GPIO
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select HAVE_S3C2410_I2C if I2C
> select HAVE_S3C2410_WATCHDOG if WATCHDOG
> select HAVE_S3C_RTC if RTC_CLASS
> @@ -790,6 +799,7 @@ config ARCH_S5PC100
> select CPU_V7
> select GENERIC_GPIO
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select HAVE_S3C2410_I2C if I2C
> select HAVE_S3C2410_WATCHDOG if WATCHDOG
> select HAVE_S3C_RTC if RTC_CLASS
> @@ -808,6 +818,7 @@ config ARCH_S5PV210
> select GENERIC_CLOCKEVENTS
> select GENERIC_GPIO
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select HAVE_S3C2410_I2C if I2C
> select HAVE_S3C2410_WATCHDOG if WATCHDOG
> select HAVE_S3C_RTC if RTC_CLASS
> @@ -826,6 +837,7 @@ config ARCH_EXYNOS
> select GENERIC_CLOCKEVENTS
> select GENERIC_GPIO
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select HAVE_S3C2410_I2C if I2C
> select HAVE_S3C2410_WATCHDOG if WATCHDOG
> select HAVE_S3C_RTC if RTC_CLASS
> @@ -928,6 +940,7 @@ config ARCH_OMAP
> select CLKSRC_MMIO
> select GENERIC_CLOCKEVENTS
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select NEED_MACH_GPIO_H
> help
> Support for TI's OMAP platform (OMAP1/2/3/4).
> diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
> index 06e73bf..bfeb9cc 100644
> --- a/arch/avr32/Kconfig
> +++ b/arch/avr32/Kconfig
> @@ -4,6 +4,7 @@ config AVR32
> # that we usually don't need on AVR32.
> select EXPERT
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select HAVE_OPROFILE
> select HAVE_KPROBES
> select HAVE_GENERIC_HARDIRQS
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index ce6c9a6..e0be02f 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -85,6 +85,7 @@ config AR7
> select ARCH_REQUIRE_GPIOLIB
> select VLYNQ
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> help
> Support for the Texas Instruments AR7 System-on-a-Chip
> family: TNETD7100, 7200 and 7300.
> @@ -97,6 +98,7 @@ config ATH79
> select CSRC_R4K
> select DMA_NONCOHERENT
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select IRQ_CPU
> select MIPS_MACHINE
> select SYS_HAS_CPU_MIPS32_R2
> @@ -134,6 +136,7 @@ config BCM63XX
> select SWAP_IO_SPACE
> select ARCH_REQUIRE_GPIOLIB
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> help
> Support for BCM63XX based boards
>
> @@ -229,6 +232,7 @@ config MACH_JZ4740
> select SYS_HAS_EARLY_PRINTK
> select HAVE_PWM
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select GENERIC_IRQ_CHIP
>
> config LANTIQ
> diff --git a/arch/mips/loongson/Kconfig b/arch/mips/loongson/Kconfig
> index 263beb9..ed42be1 100644
> --- a/arch/mips/loongson/Kconfig
> +++ b/arch/mips/loongson/Kconfig
> @@ -42,6 +42,7 @@ config LEMOTE_MACH2F
> select DMA_NONCOHERENT
> select GENERIC_ISA_DMA_SUPPORT_BROKEN
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select HW_HAS_PCI
> select I8259
> select IRQ_CPU
> diff --git a/arch/mips/loongson1/Kconfig b/arch/mips/loongson1/Kconfig
> index a9a14d6..ddaa7d0 100644
> --- a/arch/mips/loongson1/Kconfig
> +++ b/arch/mips/loongson1/Kconfig
> @@ -16,6 +16,7 @@ config LOONGSON1_LS1B
> select SYS_SUPPORTS_HIGHMEM
> select SYS_HAS_EARLY_PRINTK
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
>
> endchoice
>
> diff --git a/arch/mips/txx9/Kconfig b/arch/mips/txx9/Kconfig
> index 6d40bc7..04e3cdb 100644
> --- a/arch/mips/txx9/Kconfig
> +++ b/arch/mips/txx9/Kconfig
> @@ -21,6 +21,7 @@ config MACH_TXX9
> select SYS_SUPPORTS_LITTLE_ENDIAN
> select SYS_SUPPORTS_BIG_ENDIAN
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
>
> config TOSHIBA_JMR3927
> bool "Toshiba JMR-TX3927 board"
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 5af5aa7..da4ea6c 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -1028,6 +1028,7 @@ config PPC_CLOCK
> bool
> default n
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
>
> config PPC_LIB_RHEAP
> bool
> diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
> index fda37c9..8247d69 100644
> --- a/arch/unicore32/Kconfig
> +++ b/arch/unicore32/Kconfig
> @@ -89,6 +89,7 @@ config ARCH_PUV3
> select CPU_UCV2
> select GENERIC_CLOCKEVENTS
> select HAVE_CLK
> + select HAVE_CUSTOM_CLK
> select ARCH_REQUIRE_GPIOLIB
> select ARCH_HAS_CPUFREQ
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index bace9e9..8dc8391 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -9,16 +9,23 @@ config HAVE_CLK_PREPARE
> config HAVE_MACH_CLKDEV
> bool
>
> -config COMMON_CLK
> +config HAVE_CUSTOM_CLK
> bool
> + ---help---
> + Architectures which provide a custom clk API should select
> + this to disable the common clock API.
> +
> +config COMMON_CLK
> + bool "Common clock framework"
> + depends on !HAVE_CUSTOM_CLK
> select HAVE_CLK_PREPARE
> select CLKDEV_LOOKUP
> ---help---
> The common clock framework is a single definition of struct
> clk, useful across many platforms, as well as an
> implementation of the clock API in include/linux/clk.h.
> - Architectures utilizing the common struct clk should select
> - this option.
> + This provides a generic way for drivers to provide and use
> + clocks without hard coded relationships in the drivers.
>
> menu "Common Clock Framework"
> depends on COMMON_CLK
> --
> 1.7.10.4
>
>
>
--
Best Regards!
Kelvin Cheung
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/2e25a1ff/attachment-0001.html>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Matt Porter @ 2012-10-23 1:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50859505.5010306@ti.com>
On Mon, Oct 22, 2012 at 01:48:37PM -0500, Jon Hunter wrote:
>
> On 10/22/2012 01:35 PM, Paul Walmsley wrote:
> > (including the lists in my reply this time, oops; also adding some more
> > detail)
> >
> > On Mon, 22 Oct 2012, Jon Hunter wrote:
> >
> >> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> >>
> >>> Failing tests: fixed by posted patches
> >>> --------------------------------------
> >>>
> >>> Boot tests:
> >>>
> >>> * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> >>> - due to a GPMC bug
> >>> - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
> >>
> >> This is now addressed and I have verified it is booting on v3.7-rc2. The
> >> following patch address this boot problem ...
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3
> >
> > Great, thanks, will update the README. Did you also enable
> > CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT, or were you able
> > to pass the DTB from the bootloader?
>
> Actually, I built u-boot release 2012.10 for the am335x-evm and that
> worked for the bone board too. So that is what I used. I have not
> checked with Vaibhav and team if that is what they are using. So with
> this u-boot I just passed the dtb to the kernel and did not append.
I've mentioned this a few times in various threads...no need to use
appended DTB on a current U-Boot. Some of us are indeed booting this way
with the DTB properly passed separately from the bootloader and chosen
filled out by the bootloader. And yes, am335x_evm_config applies to all
AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
that is used to determine what board is present so a single
MLO/u-boot.img can be used.
BTW, if you pick up an RS-232 cape, you can avoid using the FTDI->UART0
connection for console and switch to any UART brought out on the Bone
connectors. This is useful for those using a power controller and
console server for local automated testing.
-Matt
^ permalink raw reply
* [PATCH] ARM: Fix page counting in mem_init and show_mem
From: Michael Spang @ 2012-10-23 1:34 UTC (permalink / raw)
To: linux-arm-kernel
The code in mem_init & show_mem to count page usage has two issues:
1. It assumes the memory map for a bank is contiguous. The sparsemem
memory model partitions the memory map into sections, which may not
be contiguous. They are usually contiguous due only to allocation
order. Avoid this by using pfn_to_page for each page.
If the memory map is not contiguous the pointer math works out
badly and crashes the system.
2. A memory bank may have holes. Some regions may be removed using
memblock_remove, and will not have valid page stucts. The code
should not access the page structs for such pages. Avoid this by
skipping pages that fail pfn_valid().
If the memory map has holes, the free & total page counts are
wrong.
Signed-off-by: Michael Spang <spang@chromium.org>
---
arch/arm/mm/init.c | 40 ++++++++++++++++++++++------------------
1 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index c21d06c..97d811a 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -101,16 +101,19 @@ void show_mem(unsigned int filter)
for_each_bank (i, mi) {
struct membank *bank = &mi->bank[i];
- unsigned int pfn1, pfn2;
- struct page *page, *end;
+ unsigned int start, end, pfn;
- pfn1 = bank_pfn_start(bank);
- pfn2 = bank_pfn_end(bank);
+ start = bank_pfn_start(bank);
+ end = bank_pfn_end(bank);
- page = pfn_to_page(pfn1);
- end = pfn_to_page(pfn2 - 1) + 1;
+ for (pfn = start; pfn < end; pfn++) {
+ struct page *page;
+
+ if (!pfn_valid(pfn))
+ continue;
+
+ page = pfn_to_page(pfn);
- do {
total++;
if (PageReserved(page))
reserved++;
@@ -122,8 +125,7 @@ void show_mem(unsigned int filter)
free++;
else
shared += page_count(page) - 1;
- page++;
- } while (page < end);
+ }
}
printk("%d pages of RAM\n", total);
@@ -619,22 +621,24 @@ void __init mem_init(void)
for_each_bank(i, &meminfo) {
struct membank *bank = &meminfo.bank[i];
- unsigned int pfn1, pfn2;
- struct page *page, *end;
+ unsigned int start, end, pfn;
- pfn1 = bank_pfn_start(bank);
- pfn2 = bank_pfn_end(bank);
+ start = bank_pfn_start(bank);
+ end = bank_pfn_end(bank);
- page = pfn_to_page(pfn1);
- end = pfn_to_page(pfn2 - 1) + 1;
+ for (pfn = start; pfn < end; pfn++) {
+ struct page *page;
+
+ if (!pfn_valid(pfn))
+ continue;
+
+ page = pfn_to_page(pfn);
- do {
if (PageReserved(page))
reserved_pages++;
else if (!page_count(page))
free_pages++;
- page++;
- } while (page < end);
+ }
}
/*
--
1.7.7.3
^ permalink raw reply related
* OMAP baseline test results for v3.7-rc2
From: Kevin Hilman @ 2012-10-23 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210202125300.774@utopia.booyaka.com>
+Igor
Paul Walmsley <paul@pwsan.com> writes:
> Here are some basic OMAP test results for Linux v3.7-rc2.
> Logs and other details at:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
[...]
> * 37xx EVM: CORE not entering dynamic off-idle
> - Cause unknown; dynamic retention-idle seems to work; system suspend to
> off works
I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
SPI1 was not idle when going off. A quick hack disabling the
touchscreen showed that after that, core was hitting idle just fine.
I ran out of time today debugging this, but it's definitely realted to
the GPIO debounce setting for the touchscreen. Changing it to zero[1]
makes CORE hit retention again in idle.
Igor, I'm hoping you might know what's going on here since we already
had some problems with this ads7846 init stuff and you're more familiar
with this debounce init.
Kevin
[1]
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index b9b776b..3afdc50 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -734,7 +734,7 @@ static void __init omap3_evm_init(void)
omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
ARRAY_SIZE(omap3evm_nand_partitions));
- omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
+ omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 0, NULL);
omap3evm_init_smsc911x();
omap3_evm_display_init();
omap3_evm_wl12xx_init();
^ permalink raw reply related
* [PATCH V2 0/7] ARM: tegra30: cpuidle: add LP2 support
From: Joseph Lo @ 2012-10-23 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350636526-25920-1-git-send-email-josephl@nvidia.com>
On Fri, 2012-10-19 at 16:48 +0800, Joseph Lo wrote:
> The CPU idle LP2 is a power gating idle mode for Tegra30. It supports the
> secondary CPUs (i.e., CPU1-CPU3) to go into LP2 dynamically. When any of
> the secondary CPUs go into LP2, it can be power gated alone. There is a
> limitation on CPU0. The CPU0 can go into LP2 only when all secondary CPUs
> are already in LP2. After CPU0 is in LP2, the CPU rail can be turned off.
>
> Verified on Seaboard(Tegra20) and Cardhu(Tegra30).
>
> This patch set should depend on these two patches:
> d8be3dc ARM: tegra: rename the file of "sleep-tXX" to "sleep-tegraXX"
> 01b176e ARM: tegra30: clocks: add AHB and APB clocks
>
> Previous work can be found at:
> V1:
> http://www.mail-archive.com/linux-tegra at vger.kernel.org/msg06319.html
>
Hi Stephen,
I need to abandon this patch set. There is a potential issue that will
cause CPU0 corruption. I am investigate on this and will get back to you
later.
Thanks,
Joseph
^ permalink raw reply
* [PATCH] ARM: OMAP3: Beagle: fix OPP customization and initcall ordering
From: Kevin Hilman @ 2012-10-22 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350946719-9583-1-git-send-email-khilman@deeprootsystems.com>
Kevin Hilman <khilman@deeprootsystems.com> writes:
> From: Kevin Hilman <khilman@ti.com>
>
> After commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 (ARM: OMAP2+:
> PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
> using an existing CPU device, not the omap_device for MPU-SS.
>
> First, fix the board file to use get_cpu_device() as required by the
> above commit, otherwise custom OPPs will be added to the wrong device.
>
> Second, the board files OPP init is called from the its init_machine
> method, and the generic CPU devices are not yet created when
> init_machine is run. Therefore OPP initialization will fail. To fix,
> use a device_initcall() for the board file's OPP customization, and
> make the device_initcall board-specific by using a machine_is check.
>
> Reported-by: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> v2: add machine_is* check to the device_initcall.
>
> arch/arm/mach-omap2/board-omap3beagle.c | 20 ++++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
> index 388c431..60729bf 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -24,6 +24,7 @@
> #include <linux/input.h>
> #include <linux/gpio_keys.h>
> #include <linux/opp.h>
> +#include <linux/cpu.h>
>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/partitions.h>
> @@ -444,12 +445,16 @@ static struct omap_board_mux board_mux[] __initdata = {
> };
> #endif
>
> -static void __init beagle_opp_init(void)
> +static int __init beagle_opp_init(void)
> {
> int r = 0;
>
> - /* Initialize the omap3 opp table */
> - if (omap3_opp_init()) {
> + if (!machine_is_omap3_beagle())
> + return 0;
> +
> + /* Initialize the omap3 opp table if not already created. */
> + r = omap3_opp_init();
> + if (IS_ERR_VALUE(r) && (r != -EEXIST)) {
> pr_err("%s: opp default init failed\n", __func__);
> return;
oops, sent wrong version. The one queued locally has 'return r' here.
Kevin
> }
> @@ -458,13 +463,13 @@ static void __init beagle_opp_init(void)
> if (cpu_is_omap3630()) {
> struct device *mpu_dev, *iva_dev;
>
> - mpu_dev = omap_device_get_by_hwmod_name("mpu");
> + mpu_dev = get_cpu_device(0);
> iva_dev = omap_device_get_by_hwmod_name("iva");
>
> if (IS_ERR(mpu_dev) || IS_ERR(iva_dev)) {
> pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
> __func__, mpu_dev, iva_dev);
> - return;
> + return -ENODEV;
> }
> /* Enable MPU 1GHz and lower opps */
> r = opp_enable(mpu_dev, 800000000);
> @@ -484,8 +489,9 @@ static void __init beagle_opp_init(void)
> opp_disable(iva_dev, 660000000);
> }
> }
> - return;
> + return 0;
> }
> +device_initcall(beagle_opp_init);
>
> static void __init omap3_beagle_init(void)
> {
> @@ -522,8 +528,6 @@ static void __init omap3_beagle_init(void)
> /* Ensure SDRC pins are mux'd for self-refresh */
> omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
> omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
> -
> - beagle_opp_init();
> }
>
> MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
^ permalink raw reply
* [PATCH 09/12] tty/console: fix warnings in drivers/tty/serial/kgdboc.c
From: Greg Kroah-Hartman @ 2012-10-22 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50661A81.7000501@windriver.com>
On Fri, Sep 28, 2012 at 04:45:37PM -0500, Jason Wessel wrote:
> On 09/28/2012 04:36 PM, Arnd Bergmann wrote:
> > The con_debug_leave/con_debug_enter functions are stubbed out
> > by defining them to (0), which causes harmless build warnings.
> > Using proper inline functions is the normal way to deal with
> > this.
> >
> > Without this patch, building the ARM bcm2835_defconfig results in:
> >
> > drivers/tty/serial/kgdboc.c: In function 'kgdboc_pre_exp_handler':
> > drivers/tty/serial/kgdboc.c:279:3: warning: statement with no effect [-Wunused-value]
> > drivers/tty/serial/kgdboc.c: In function 'kgdboc_post_exp_handler':
> > drivers/tty/serial/kgdboc.c:293:3: warning: statement with no effect [-Wunused-value]
>
>
> Thanks Arnd!
>
> I'll put this in kgdb-next for the upcoming merge window, unless Greg pulls it into his queue first.
>
> Acked-by: Jason Wessel <jason.wessel@windriver.com>
Feel free to take it in through your kgdb tree.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH] ARM: imx: allow support to be disabled
From: Shawn Guo @ 2012-10-22 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350939621-2892-1-git-send-email-swarren@wwwdotorg.org>
On Mon, Oct 22, 2012 at 03:00:21PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Since ARCH_MXC's Kconfig option has no string name, the user is never
> presented with an option to enable/disable this setting. Rather, it is
> automatically enabled based on the conditions in the def_bool entry.
>
> Add a string, so that the user gets to choose whether to enable ARCH_MXC,
> and rename the i.MX options menu so that it doesn't clash. Also, change
> from "def_bool y" to "bool" to be more consistent with other machines.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Thanks for the patch, Stephen. I have queued a similar fix [1] from
Fabio. Hopefully, arm-soc folks will apply it soon.
Shawn
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/194310
> ---
> Note that if Tegra and i.MX support are enabled at the same time, then
> the build will fail since both Tegra's and i.MX's head.S define symbol
> v7_invalidate_l1. shmobile appears to have the same conflict. Note that
> patches to port Tegra to ARCH_MULTI aren't yet in linux-next, but I can
> point anyone who's interested at my github tree.
> ---
> arch/arm/mach-imx/Kconfig | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 892631f..5cc2417 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -1,5 +1,5 @@
> config ARCH_MXC
> - def_bool y if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
> + bool "Freescale i.MX support" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
> select ARCH_REQUIRE_GPIOLIB
> select ARM_PATCH_PHYS_VIRT
> select AUTO_ZRELADDR if !ZBOOT_ROM
> @@ -13,7 +13,7 @@ config ARCH_MXC
> help
> Support for Freescale MXC/iMX-based family of processors
>
> -menu "Freescale i.MX support"
> +menu "Freescale i.MX options"
> depends on ARCH_MXC
>
> config MXC_IRQ_PRIOR
> --
> 1.7.0.4
>
^ permalink raw reply
* [PATCH] ARM: OMAP3: Beagle: fix OPP customization and initcall ordering
From: Kevin Hilman @ 2012-10-22 22:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Kevin Hilman <khilman@ti.com>
After commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 (ARM: OMAP2+:
PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
using an existing CPU device, not the omap_device for MPU-SS.
First, fix the board file to use get_cpu_device() as required by the
above commit, otherwise custom OPPs will be added to the wrong device.
Second, the board files OPP init is called from the its init_machine
method, and the generic CPU devices are not yet created when
init_machine is run. Therefore OPP initialization will fail. To fix,
use a device_initcall() for the board file's OPP customization, and
make the device_initcall board-specific by using a machine_is check.
Reported-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
v2: add machine_is* check to the device_initcall.
arch/arm/mach-omap2/board-omap3beagle.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 388c431..60729bf 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,6 +24,7 @@
#include <linux/input.h>
#include <linux/gpio_keys.h>
#include <linux/opp.h>
+#include <linux/cpu.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -444,12 +445,16 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
-static void __init beagle_opp_init(void)
+static int __init beagle_opp_init(void)
{
int r = 0;
- /* Initialize the omap3 opp table */
- if (omap3_opp_init()) {
+ if (!machine_is_omap3_beagle())
+ return 0;
+
+ /* Initialize the omap3 opp table if not already created. */
+ r = omap3_opp_init();
+ if (IS_ERR_VALUE(r) && (r != -EEXIST)) {
pr_err("%s: opp default init failed\n", __func__);
return;
}
@@ -458,13 +463,13 @@ static void __init beagle_opp_init(void)
if (cpu_is_omap3630()) {
struct device *mpu_dev, *iva_dev;
- mpu_dev = omap_device_get_by_hwmod_name("mpu");
+ mpu_dev = get_cpu_device(0);
iva_dev = omap_device_get_by_hwmod_name("iva");
if (IS_ERR(mpu_dev) || IS_ERR(iva_dev)) {
pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
__func__, mpu_dev, iva_dev);
- return;
+ return -ENODEV;
}
/* Enable MPU 1GHz and lower opps */
r = opp_enable(mpu_dev, 800000000);
@@ -484,8 +489,9 @@ static void __init beagle_opp_init(void)
opp_disable(iva_dev, 660000000);
}
}
- return;
+ return 0;
}
+device_initcall(beagle_opp_init);
static void __init omap3_beagle_init(void)
{
@@ -522,8 +528,6 @@ static void __init omap3_beagle_init(void)
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
-
- beagle_opp_init();
}
MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
--
1.8.0
^ permalink raw reply related
* [PATCH v2 5/9] document: devicetree: bind pinconf with pin-single
From: Stephen Warren @ 2012-10-22 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350922139-3693-6-git-send-email-haojian.zhuang@gmail.com>
On 10/22/2012 10:08 AM, Haojian Zhuang wrote:
> Add comments with pinconf & gpio range in the document of
> pinctrl-single.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
> ---
> .../devicetree/bindings/pinctrl/pinctrl-single.txt | 52 ++++++++++++++++++++
> arch/arm/boot/dts/pxa910.dtsi | 1 -
> 2 files changed, 52 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> index 2c81e45..6da2f13 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> @@ -17,6 +17,36 @@ Optional properties:
> - pinctrl-single,bit-per-mux : boolean to indicate that one register controls
> more than one pin
>
> +- pinctrl-single,gpio-ranges : gpio range list
> +
> +- pinctrl-single,gpio : array with gpio range start, size & register
> + offset
> +
> +- pinctrl-single,gpio-func : gpio function value in the pinmux register
Some more explanation is needed here; some questions/comments:
1) Looking at the example, pinctrl-single,gpio-ranges is a property
within the main pinctrl node, whereas pinctrl-single,gpio and
pinctrl-single,gpio-func are properties within some other node. There's
no explanation of this in the binding description itself, only in the
example. Related to this, the documentation for
pinctrl-single,gpio-ranges doesn't say what it's a list of; it needs to
say that it's a list of phandles.
2) pinctrl-single,gpio is listed as optional. Presumably it's not; every
GPIO range node must have this property?
3) Why is pinctrl-single,gpio-func optional? Presumably you always need
to program the pinmux HW to select the GPIO function. Yet, the driver
code in an earlier patch seems to deliberately do nothing if this
property is missing. Shouldn't the DT parsing return an error instead?
4) I'm a little confused re: the data model. Is the idea that if
pinctrl-single,gpio-ranges is specified, then the node describes a
combined pin controller and GPIO HW? Are the pin IDs of the pin
controller expected to match the pin IDs of the GPIO HW? I'm left
wondering exactly which numbering space the values in
pinctrl-single,gpio are; do they describe the pin controller IDs that
this GPIO range describes, or do they describe the GPIO IDs that this
range describes and attempt to map them back to pin controller IDs?
Similarly, I'm not sure why there's a register offset here rather than
say a pin controller pin ID number. Shouldn't the property be a list of
<pin-controller-pin-ID GPIO-controller-GPIO-ID number-of-GPIOs>
> +- pinctrl-single,power-source-mask : mask of setting power source in
> + the pinmux register
> +
> +- pinctrl-single,power-source : value of setting power source field
> + in the pinmux register
> +
> +- pinctrl-single,bias-mask : mask of setting bias value in the pinmux
> + register
> +
> +- pinctrl-single,bias-disable : value of disabling bias in the pinmux
> + register
> +
> +- pinctrl-single,bias-pull-down : value of setting bias pull down in
> + the pinmux register
> +
> +- pinctrl-single,bias-pull-up : value of setting bias pull up in the
> + pinmux register
> +
> +- pinctrl-single,bias : value of setting bias in the pinmux register
> +
> +- pinctrl-single,input-schmitt-mask : mask of setting input schmitt
> + in the pinmux register
I suppose it's OK that a generic pin controller binding would use the
generic pin configuration config options. I'm still not convinced that
the semantics of generic pin control make sense. Maybe if they're just
arbitrary names for SoC-specific things it's fine though.
Do these patches expose /all/ generic pin configuration options? It
doesn't seem worth exposing only some of them and ignoring others.
> +/* third controller instance for pins in gpio domain */
> +pmx_gpio: pinmux at d401e000 {
> + compatible = "pinctrl-single";
> + reg = <0xd401e000 0x0330>;
> + #address-cells = <1>;
> + #size-cells = <0>;
#gpio-cells would be needed here for a GPIO controller.
> diff --git a/arch/arm/boot/dts/pxa910.dtsi b/arch/arm/boot/dts/pxa910.dtsi
> - pinctrl-single,gpio-mask = <7>;
I assume that's a mistake; the line shouldn't be removed in this
documentation patch?
^ permalink raw reply
* 3.7-rc2 fails to build exynos target
From: Mark A. Greer @ 2012-10-22 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D9D88B79-F5F0-4C63-9E23-B1A919C7142A@suse.de>
On Tue, Oct 23, 2012 at 12:11:02AM +0200, Alexander Graf wrote:
> Howdy,
>
> While updating to 3.7-rc2, I stumbled over a few compile issues with the exynos target. I won't get around to fix them, but wanted to give you a heads up and would like to see them resolved before 3.7 gets released :).
>
> Config: http://csgraf.de/arm/exynos
>
> Alex
>
> [ 674s] ERROR: "read_current_timer" [lib/rbtree_test.ko] undefined!
> [ 674s] ERROR: "read_current_timer" [lib/interval_tree_test.ko] undefined!
> [ 675s] ERROR: "read_current_timer" [drivers/video/udlfb.ko] undefined!
> [ 675s] ERROR: "cpufreq_cooling_register" [drivers/thermal/exynos_thermal.ko] undefined!
> [ 675s] ERROR: "cpufreq_cooling_unregister" [drivers/thermal/exynos_thermal.ko] undefined!
> [ 677s] ERROR: "s5p_csis_phy_enable" [drivers/media/platform/s5p-fimc/s5p-csis.ko] undefined!
> [ 678s] ERROR: "read_current_timer" [drivers/gpu/drm/udl/udl.ko] undefined!
> [ 678s] ERROR: "set_irq_flags" [drivers/gpio/gpio-adnp.ko] undefined!
> [ 678s] make[3]: *** [__modpost] Error 1
> [ 678s] make[2]: *** [modules] Error 2
> [ 678s] make[1]: *** [sub-make] Error 2
> [ 678s] make: *** [all] Error 2
> [ 678s] + test 2 -eq 0
> [ 678s] + test 00 -gt 0
> [ 678s] + exit 1
> [ 678s] error: Bad exit status from /var/tmp/rpm-tmp.qIAujD (%build)
FYI,
https://patchwork.kernel.org/patch/1540031/
I really hope its fixed before 3.7 too :)
Mark
--
^ permalink raw reply
* [PATCH] arm: sched: stop sched_clock() during suspend
From: Linus Walleij @ 2012-10-22 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <873916h1yi.fsf@deeprootsystems.com>
On Mon, Oct 22, 2012 at 7:05 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> However, in light of RT throttling, this a correctness issue for process
> accounting, so I agree that this should be done for all platforms
> instead of providing an optional 'needs suspend' version of the API,
> even though it means printk times no longer reflect time spent
> suspended.
Maybe we should get printk() to use the best clocksource
instead.
The reason AFAICT that printk() is using sched_clock() is that
it's supposed to be fast. But now it seems that it's not going
to return what printk() needs anymore.
(Dragging Stultz & Gleixner into this...)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 9/9] pinctrl: single: dump pinmux register value
From: Tony Lindgren @ 2012-10-22 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350922139-3693-10-git-send-email-haojian.zhuang@gmail.com>
* Haojian Zhuang <haojian.zhuang@gmail.com> [121022 09:13]:
> Dump pinmux register value, not only function part in the pinmux
> register.
This makes sense, but should be done using pcs_read, not pcs_readl,
see below.
> Also fix the issue on caluclating pin offset. The last parameter
> should be pin number, not register offset.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
> ---
> drivers/pinctrl/pinctrl-single.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
> index a20da78..6ba2a5d 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -284,15 +284,15 @@ static int pcs_get_group_pins(struct pinctrl_dev *pctldev,
>
> static void pcs_pin_dbg_show(struct pinctrl_dev *pctldev,
> struct seq_file *s,
> - unsigned offset)
> + unsigned pin)
> {
> struct pcs_device *pcs;
> - unsigned val;
> + unsigned val, mux_bytes;
>
> pcs = pinctrl_dev_get_drvdata(pctldev);
>
> - val = pcs->read(pcs->base + offset);
> - val &= pcs->fmask;
> + mux_bytes = pcs->width / BITS_PER_BYTE;
> + val = pcs_readl(pcs->base + pin * mux_bytes);
>
> seq_printf(s, "%08x %s " , val, DRIVER_NAME);
> }
You should not use pcs_readl here directly as the register
width can vary. Can you please update the patch for that and
make it independent from the rest of the series? That way we
can merge the fix for v3.7-rc series.
Regards,
Tony
^ permalink raw reply
* [PATCH v3 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
From: Fabio Estevam @ 2012-10-22 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1210222301100.32591@axis700.grange>
Hi Guennadi
On Mon, Oct 22, 2012 at 7:07 PM, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> ? I don't find a clock named "per" and associated with "mx2-camera.0" in
> arch/arm/mach-imx/clk-imx27.c. I only find it in clk-imx25.c. Does this
> mean, that this your patch is for i.MX25? But you're saying it's for
> i.MX27. Confused...
I provide this mx27 clock in the first patch of the series:
http://patchwork.linuxtv.org/patch/14915/
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH V3 3/5] ARM: tegra: decouple uncompress.h and debug-macro.S
From: Russell King - ARM Linux @ 2012-10-22 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50857340.4010403@wwwdotorg.org>
On Mon, Oct 22, 2012 at 10:24:32AM -0600, Stephen Warren wrote:
> On 10/22/2012 02:18 AM, Peter De Schrijver wrote:
> >> +
> >> +#define checkuart(rp, rv, lhu, bit, uart) \
> >> + /* Load address of CLK_RST register */ \
> >> + movw rp, #TEGRA_CLK_RST_DEVICES_##lhu & 0xffff ; \
> >> + movt rp, #TEGRA_CLK_RST_DEVICES_##lhu >> 16 ; \
> >> + /* Load value from CLK_RST register */ \
> >> + ldr rp, [rp, #0] ; \
> >> + /* Test UART's reset bit */ \
> >> + tst rp, #(1 << bit) ; \
> >> + /* If set, can't use UART; jump to save no UART */ \
> >> + bne 90f ; \
> >> + /* Load address of CLK_OUT_ENB register */ \
> >> + movw rp, #TEGRA_CLK_OUT_ENB_##lhu & 0xffff ; \
> >> + movt rp, #TEGRA_CLK_OUT_ENB_##lhu >> 16 ; \
> >> + /* Load value from CLK_OUT_ENB register */ \
> >> + ldr rp, [rp, #0] ; \
> >> + /* Test UART's clock enable bit */ \
> >> + tst rp, #(1 << bit) ; \
> >> + /* If clear, can't use UART; jump to save no UART */ \
> >> + beq 90f ; \
> >> + /* Passed all tests, load address of UART registers */ \
> >> + movw rp, #TEGRA_UART##uart##_BASE & 0xffff ; \
> >> + movt rp, #TEGRA_UART##uart##_BASE >> 16 ; \
> >> + /* Jump to save UART address */ \
> >> + b 91f
> >>
> >
> > Maybe make this a subroutine?
>
> The addruart macro (which in turn uses the checkuart macro) is only
> allowed to use 3 registers; rp, rv, rtmp. I'm also not 100% sure if the
> stack is guaranteed to be set up when addruart is called either. So, I
> don't think making this a function is possible.
There's no stack. Remember, this stuff can be inserted as early as the
front of the kernel assembly code, where there is _nothing_ - the MMU
is off so virtual addresses are meaningless. etc.
^ permalink raw reply
* 3.7-rc2 fails to build exynos target
From: Alexander Graf @ 2012-10-22 22:11 UTC (permalink / raw)
To: linux-arm-kernel
Howdy,
While updating to 3.7-rc2, I stumbled over a few compile issues with the exynos target. I won't get around to fix them, but wanted to give you a heads up and would like to see them resolved before 3.7 gets released :).
Config: http://csgraf.de/arm/exynos
Alex
[ 674s] ERROR: "read_current_timer" [lib/rbtree_test.ko] undefined!
[ 674s] ERROR: "read_current_timer" [lib/interval_tree_test.ko] undefined!
[ 675s] ERROR: "read_current_timer" [drivers/video/udlfb.ko] undefined!
[ 675s] ERROR: "cpufreq_cooling_register" [drivers/thermal/exynos_thermal.ko] undefined!
[ 675s] ERROR: "cpufreq_cooling_unregister" [drivers/thermal/exynos_thermal.ko] undefined!
[ 677s] ERROR: "s5p_csis_phy_enable" [drivers/media/platform/s5p-fimc/s5p-csis.ko] undefined!
[ 678s] ERROR: "read_current_timer" [drivers/gpu/drm/udl/udl.ko] undefined!
[ 678s] ERROR: "set_irq_flags" [drivers/gpio/gpio-adnp.ko] undefined!
[ 678s] make[3]: *** [__modpost] Error 1
[ 678s] make[2]: *** [modules] Error 2
[ 678s] make[1]: *** [sub-make] Error 2
[ 678s] make: *** [all] Error 2
[ 678s] + test 2 -eq 0
[ 678s] + test 00 -gt 0
[ 678s] + exit 1
[ 678s] error: Bad exit status from /var/tmp/rpm-tmp.qIAujD (%build)
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Stephen Warren @ 2012-10-22 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210221443580.1724-100000@iolanthe.rowland.org>
On 10/22/2012 01:00 PM, Alan Stern wrote:
> On Mon, 22 Oct 2012, Stephen Warren wrote:
>
>>>>> +- has-tt : controller has transaction translator(s).
>>>>> +- has-synopsys-hc-bug : controller has the synopsys hc bug
>>>>
>>>> That would normally be determined by the driver based on the particular
>>>> compatible value that is in device tree.
>>>
>>> I don't understand this comment. Isn't "has-synopsys-hc-bug" the
>>> compatible value in question?
>>
>> "compatible value" in this context means that value of the property
>> named "compatible".
>
> I see. But why would it be done this way instead having a separate
> property?
Well, I did say normally:-)
I can certainly see an argument for representing these differences using
custom properties, rather than deriving the information from the
compatible value. It's probably be OK to do so for something generic
like this; it's just perhaps not always the default choice.
Do note that even though this binding document dictates a particular
value for the compatible property, every device tree should additionally
add a separate value alongside it to indicate the specific HW model
that's actually present, so that if some device-specific bug-fix or
workaround needs to be applied, the model can be identified anyway.
So, rather than:
compatible = "usb-ehci";
You should always have e.g.:
compatible = "nvidia,tegra20-ehci", "usb-ehci";
Given that, there is then always enough information in the device tree
for the driver to be able to derive the other values from the compatible
value.
Whether you want to derive the information, or whether you want to
explicitly represent it via properties, is a decision to make based on
the trade-offs.
Oh, and I note that quite a few device trees already use compatible
value "usb-ehci" in their device-trees. Care needs to be taken not to
usurp that value from any existing device drivers if that was to be
picked as the compatible value required by this binding.
> And doesn't the same reasoning apply to has-tt? Doesn't that mean the
> driver would have to match four different hardware types? What happens
> if a third characteristic like these comes around; would the driver
> then have to check against eight different types?
No, the compatible value represents the model, so you'd have a table like:
compatible -> bugX has_tt
nvidia,tegra20-ehci -> 0 1
vendor1,foo-ehci -> 0 1
vendor2,bar-ehci -> 1 1
vendor3,baz-ehci -> 0 1
vendor4,qux-ehci -> 0 1
...
So the table size isn't related to the number of options. The table size
is probably bigger than subset of options combinations that make sense.
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Kevin Hilman @ 2012-10-22 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021135143.GA1855@beef>
Matt Porter <mporter@ti.com> writes:
> On Sat, Oct 20, 2012 at 06:58:10PM +0000, Paul Walmsley wrote:
>> On Sat, 20 Oct 2012, Richard Cochran wrote:
>>
>> > On Sat, Oct 20, 2012 at 06:12:35PM +0000, Paul Walmsley wrote:
>> > > Just tried omap2plus_defconfig here and the board didn't boot, confirming
>> > > your result. Will add a section to the testlog README.txt about that.
>> > >
>> > > > > In terms of differences from your setup, looks like we have different
>> > > > > X-Loader and u-boot; it wouldn't surprise me if we have different kernel
>> > > > > configs too.
>> >
>> > I tried both omap2plus_defconfig and your am33xx_only config, and
>> > neither one work with my (recent) u-boot version.
>>
>> Just sent you the MLO and u-boot.img from here via private E-mail. Those
>> were the files that came with the BeagleBone SD card here.
>>
>> TI also has a u-boot tree for the AM33xx; might be worth trying:
>>
>> git://arago-project.org/git/projects/u-boot-am33x.git
>
> Use of the vendor tree should be discouraged. The best thing to use
> is current ToT U-Boot mainline or the v2012.10 stable U-Boot release.
> X-Loader is deprecated by U-Boot SPL.
Just FYI for anyone else having an older BeagleBone.
On my Rev A2, using u-boot mainline, neither HEAD or v2012.10 result in
a working network interface, so you can't netboot/dhcp.
Kevin
^ permalink raw reply
* [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
From: Kevin Hilman @ 2012-10-22 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350922532-26338-1-git-send-email-t-kristo@ti.com>
Tero Kristo <t-kristo@ti.com> writes:
> When waking up from off-mode, some IP blocks are reset automatically by
> hardware. For this reason, software must wait until the reset has
> completed before attempting to access the IP block.
>
> This patch fixes for example the bug introduced by commit
> 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
> to SYSCONFIG register"), in which the MMC IP block is reset during
> off-mode entry, but the code expects the module to be already available
> during the execution of context restore.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Venkatraman S <svenkatr@ti.com>
I can confirm that this patch the regression in my OMAP3 PM tests where
suspend test (to retention or off) failed if ran after the off-idle
test.
Tested-by: Kevin Hilman <khilman@ti.com>
on 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM
Thanks Tero for the fix,
Kevin
^ permalink raw reply
* [PATCH v2 2/9] pinctrl: single: support gpio request and free
From: Tony Lindgren @ 2012-10-22 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022202805.GG4730@atomide.com>
* Tony Lindgren <tony@atomide.com> [121022 13:29]:
> * Haojian Zhuang <haojian.zhuang@gmail.com> [121022 09:11]:
> > --- a/drivers/pinctrl/pinctrl-single.c
> > +++ b/drivers/pinctrl/pinctrl-single.c
> > @@ -28,8 +28,10 @@
> > #define DRIVER_NAME "pinctrl-single"
> > #define PCS_MUX_PINS_NAME "pinctrl-single,pins"
> > #define PCS_MUX_BITS_NAME "pinctrl-single,bits"
> > +#define PCS_GPIO_FUNC_NAME "pinctrl-single,gpio-func"
>
> I think we can now get rid of these defines, I initially added
> them as we had a bit hard time finding a suitable name for the
> driver. These are only used in one location, so let's not add
> new ones here.
>
> > static int pcs_request_gpio(struct pinctrl_dev *pctldev,
> > - struct pinctrl_gpio_range *range, unsigned offset)
> > + struct pinctrl_gpio_range *range, unsigned pin)
> > {
> > - return -ENOTSUPP;
> > + struct pcs_device *pcs = pinctrl_dev_get_drvdata(pctldev);
> > + struct pcs_gpio_range *gpio = NULL;
> > + int end, mux_bytes;
> > + unsigned data;
> > +
> > + gpio = container_of(range, struct pcs_gpio_range, range);
> > + if (!gpio->func_en)
> > + return 0;
> > + end = range->pin_base + range->npins - 1;
> > + if (pin < range->pin_base || pin > end) {
> > + dev_err(pctldev->dev, "pin %d isn't in the range of "
> > + "%d to %d\n", pin, range->pin_base, end);
> > + return -EINVAL;
> > + }
> > + mux_bytes = pcs->width / BITS_PER_BYTE;
> > + data = pcs_readl(pcs->base + pin * mux_bytes) & ~pcs->fmask;
> > + data |= gpio->gpio_func;
> > + pcs_writel(data, pcs->base + pin * mux_bytes);
> > + return 0;
> > }
>
> I think I already commented on this one.. Is this safe if you don't
> have GPIOs configured? Or should you return -ENODEV in that case?
Oops also you should not use pcs_readl/pcs_writel in the driver
directly but use pcs_read instead as you can have register width other
than 32-bits.
Regards,
Tony
^ permalink raw reply
* Which kirkwood does your DT board use?
From: Adam Baker @ 2012-10-22 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121020113800.GC21046@lunn.ch>
On 20/10/12 12:38, Andrew Lunn wrote:
> Hi Folks
>
> All of you in the To: have contributed a DT based Kirkwood board port.
> Nearly all the DT files we have declare the CPU to be
> marvell,kirkwood-88f6281. For adding DT based pinctrl, to replace the
> mpp code, we need to know the exact kirkwood being used. It should be
> one of MV88F6180, MV88F6190, MV88F6192, MV88F6281 or MV88F6282.
>
> You can see what your hardware has a boot time:
>
> Kirkwood: MV88F6282-Rev-A0, TCLK=200000000.
>
> Please could you check your hardware and let me know what the correct
> CPU is. I can then fix the .dts files and prepare a first attempt at
> converting boards to pinctrl.
>
Hi,
I've not seen a reply from Arnaud yet so I'll offer
Iomega Iconnect
Kirkwood: MV88F6281-A0, TCLK=200000000.
Regards
Adam
^ permalink raw reply
* [PATCH] ARM: OMAP3: Beagle: fix OPP customization and initcall ordering
From: Tony Lindgren @ 2012-10-22 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350938009-22716-1-git-send-email-khilman@deeprootsystems.com>
* Kevin Hilman <khilman@deeprootsystems.com> [121022 13:35]:
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -24,6 +24,7 @@
> #include <linux/input.h>
> #include <linux/gpio_keys.h>
> #include <linux/opp.h>
> +#include <linux/cpu.h>
>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/partitions.h>
> @@ -444,12 +445,13 @@ static struct omap_board_mux board_mux[] __initdata = {
> };
> #endif
>
> -static void __init beagle_opp_init(void)
> +static int __init beagle_opp_init(void)
> {
> int r = 0;
Don't you need to add some check here for machine_is
to prevent this from running on other boards if you now
make this into an initcall?
Regards,
Tony
^ permalink raw reply
* [RFC PATCH 2/2] ARM: OMAP4: clock: use omap4_clks_register API
From: Mike Turquette @ 2012-10-22 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <902E09E6452B0E43903E4F2D568737AB2CA620@DNCE04.ent.ti.com>
Quoting Strashko, Grygorii (2012-10-19 03:34:19)
> Hi Mike,
>
> > In addition to removing CK_443X/CK_446X you could also get rid of struct
> > omap_clk completely (arch/arm/plat-omap/include/plat/clkdev_omap.h) and
> > the CLK macro by changing the clk array to be of type struct clk_lookup
> > and using the CLKDEV_INIT macro.
> Yes. It may be done. As I understand, this approach is applicable for you, if so i can continue working on it. right?
>
> > I wonder if splitting the tables would make initdata any easier. It
> OMAP5,4,2 - there are no so much differences between SOcs, so it looks good and simple.
> OMAP3 - it is a little bit more complex.
> > would be nice to get more functional changes out of this series
> > alongside the data reorganization.
> Could you provide more details, pls?
>
What I mean to say is that this patch doesn't change any functionality.
It just reorganizes data to make things prettier. In order to justify
getting this change upstream (and to combat accusations of "needless
churn") it would be good if this series did more than just shuffle the
data around. Two examples I have already mentioned are getting rid of
the macros in ckdev_omap.h (and maybe getting rid of that entire file)
and also marking data as initdata. Both are functional changes that
make the world a better place.
Regards,
Mike
> > Also have you looked at splitting the tables for OMAP2/3?
> Yes. I think, it can be done.
>
> Best regards,
> Grygorii Strashko | GlobalLogic
>
> ________________________________________
> From: Mike Turquette [mturquette at linaro.org]
> Sent: Thursday, October 18, 2012 8:53 PM
> To: Strashko, Grygorii; Paul Walmsley
> Cc: Hilman, Kevin; Tony Lindgren; linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Strashko, Grygorii
> Subject: Re: [RFC PATCH 2/2] ARM: OMAP4: clock: use omap4_clks_register API
>
> Quoting Grygorii Strashko (2012-10-18 09:38:17)
> > Remove OMAP443x and OMAP446x specific clocks from omap44xx_clks
> > array and add corresponding set of clocks per each SoC:
> > - struct omap_clk omap44xx_clks[]; - common clocks set for all OMAP4
> > - struct omap_clk omap443x_clks[]; - specific clocks set for OMAP443x
> > - struct omap_clk omap446x_clks[]; - specific clocks set for OMAP446x
> > and don't rely on platform specific flags any more.
> >
> > Use omap4_clks_register() API to register and init OMAP4 set of
> > clocks.
> >
> > With this change, we can now safely remove CK_443X/CK_446X etc macro
> > usage. It has not been done in this patch, but if the approach is OK,
> > then, it is possible to do the same.
> >
>
> In addition to removing CK_443X/CK_446X you could also get rid of struct
> omap_clk completely (arch/arm/plat-omap/include/plat/clkdev_omap.h) and
> the CLK macro by changing the clk array to be of type struct clk_lookup
> and using the CLKDEV_INIT macro.
>
> > One additional benefit seen is that the match logic can entirely be
> > skipped.
> >
>
> I wonder if splitting the tables would make initdata any easier. It
> would be nice to get more functional changes out of this series
> alongside the data reorganization.
>
> Also have you looked at splitting the tables for OMAP2/3?
>
> Regards,
> Mike
>
> > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> > ---
> > arch/arm/mach-omap2/clock44xx_data.c | 40 ++++++++++++++++++----------------
> > 1 file changed, 21 insertions(+), 19 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
> > index 6efc30c..4060c9c 100644
> > --- a/arch/arm/mach-omap2/clock44xx_data.c
> > +++ b/arch/arm/mach-omap2/clock44xx_data.c
> > @@ -3145,10 +3145,7 @@ static struct omap_clk omap44xx_clks[] = {
> > CLK(NULL, "aes1_fck", &aes1_fck, CK_443X),
> > CLK(NULL, "aes2_fck", &aes2_fck, CK_443X),
> > CLK(NULL, "aess_fck", &aess_fck, CK_443X),
> > - CLK(NULL, "bandgap_fclk", &bandgap_fclk, CK_443X),
> > - CLK(NULL, "bandgap_ts_fclk", &bandgap_ts_fclk, CK_446X),
> > CLK(NULL, "des3des_fck", &des3des_fck, CK_443X),
> > - CLK(NULL, "div_ts_ck", &div_ts_ck, CK_446X),
> > CLK(NULL, "dmic_sync_mux_ck", &dmic_sync_mux_ck, CK_443X),
> > CLK(NULL, "dmic_fck", &dmic_fck, CK_443X),
> > CLK(NULL, "dsp_fck", &dsp_fck, CK_443X),
> > @@ -3346,19 +3343,27 @@ static struct omap_clk omap44xx_clks[] = {
> > CLK("4903c000.timer", "timer_sys_ck", &syc_clk_div_ck, CK_443X),
> > CLK("4903e000.timer", "timer_sys_ck", &syc_clk_div_ck, CK_443X),
> > CLK(NULL, "cpufreq_ck", &dpll_mpu_ck, CK_443X),
> > + CLK(NULL, NULL, NULL, CK_443X),
> > +};
> > +
> > +static struct omap_clk omap443x_clks[] = {
> > + CLK(NULL, "bandgap_fclk", &bandgap_fclk, CK_443X),
> > + CLK(NULL, NULL, NULL, CK_443X),
> > +};
> > +
> > +
> > +static struct omap_clk omap446x_clks[] = {
> > + CLK(NULL, "div_ts_ck", &div_ts_ck, CK_446X),
> > + CLK(NULL, "bandgap_ts_fclk", &bandgap_ts_fclk, CK_446X),
> > + CLK(NULL, NULL, NULL, CK_446X),
> > };
> >
> > int __init omap4xxx_clk_init(void)
> > {
> > - struct omap_clk *c;
> > - u32 cpu_clkflg;
> > -
> > if (cpu_is_omap443x()) {
> > cpu_mask = RATE_IN_4430;
> > - cpu_clkflg = CK_443X;
> > } else if (cpu_is_omap446x() || cpu_is_omap447x()) {
> > cpu_mask = RATE_IN_4460 | RATE_IN_4430;
> > - cpu_clkflg = CK_446X | CK_443X;
> >
> > if (cpu_is_omap447x())
> > pr_warn("WARNING: OMAP4470 clock data incomplete!\n");
> > @@ -3375,17 +3380,14 @@ int __init omap4xxx_clk_init(void)
> > * omap2_clk_disable_clkdm_control();
> > */
> >
> > - for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
> > - c++)
> > - clk_preinit(c->lk.clk);
> > -
> > - for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
> > - c++)
> > - if (c->cpu & cpu_clkflg) {
> > - clkdev_add(&c->lk);
> > - clk_register(c->lk.clk);
> > - omap2_init_clk_clkdm(c->lk.clk);
> > - }
> > + omap2_clks_register(omap44xx_clks);
> > +
> > + if (cpu_is_omap443x())
> > + omap2_clks_register(omap443x_clks);
> > + else if (cpu_is_omap446x() || cpu_is_omap447x())
> > + omap2_clks_register(omap446x_clks);
> > + else
> > + return 0;
> >
> > /* Disable autoidle on all clocks; let the PM code enable it later */
> > omap_clk_disable_autoidle_all();
> > --
> > 1.7.9.5
^ 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