* [PATCHv5 01/16] arm: arch_timer: balance device_node refcounting
From: Catalin Marinas @ 2013-01-31 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359634539-9580-2-git-send-email-mark.rutland@arm.com>
On Thu, Jan 31, 2013 at 12:15:24PM +0000, Mark Rutland wrote:
> When we get the device_node for the arch timer, it's refcount is
> automatically incremented in of_find_matching_node, but it is
> never decremented.
>
> This patch decrements the refcount on the node after we're finished
> using it.
>
> Reported-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Get rid of custom OMAP_32K_TIMER_HZ
From: Santosh Shilimkar @ 2013-01-31 15:32 UTC (permalink / raw)
To: linux-arm-kernel
The timekeeping doesn't depend on HZ value in presence of fine grained
clocksource and hence there should not be any time drift because of HZ
value which was chosen to be divisor of 32768.
OMAP has been using HZ = 128 value to avoid any time drift issues
because of 32768 HZ clock. But with various measurements performed
with HZ = 100, no time drift is observed and it also proves the
point about HZ not having impact on time keeping on OMAP.
Very informative thread on this topic is here:
https://lkml.org/lkml/2013/1/29/435
Special thanks to John Stulz, Arnd Bergmann and Russell King for their
valuable suggestions.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/Kconfig | 1 -
arch/arm/plat-omap/Kconfig | 9 ---------
arch/arm/plat-omap/include/plat/timex.h | 8 --------
3 files changed, 18 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b35b27f..5493164 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1648,7 +1648,6 @@ config HZ
int
default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \
ARCH_S5PV210 || ARCH_EXYNOS4
- default OMAP_32K_TIMER_HZ if ARCH_OMAP && OMAP_32K_TIMER
default AT91_TIMER_HZ if ARCH_AT91
default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
default 100
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 67c859c..ce66eb9 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -147,15 +147,6 @@ config OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
help
PPA routine service ID for setting L2 auxiliary control register.
-config OMAP_32K_TIMER_HZ
- int "Kernel internal timer frequency for 32KHz timer"
- range 32 1024
- depends on OMAP_32K_TIMER
- default "128"
- help
- Kernel internal timer frequency should be a divisor of 32768,
- such as 64 or 128.
-
config OMAP_DM_TIMER
bool "Use dual-mode timer"
depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
diff --git a/arch/arm/plat-omap/include/plat/timex.h b/arch/arm/plat-omap/include/plat/timex.h
index 6d35767..e27d2da 100644
--- a/arch/arm/plat-omap/include/plat/timex.h
+++ b/arch/arm/plat-omap/include/plat/timex.h
@@ -28,14 +28,6 @@
#if !defined(__ASM_ARCH_OMAP_TIMEX_H)
#define __ASM_ARCH_OMAP_TIMEX_H
-/*
- * OMAP 32KHz timer updates time one jiffie at a time from a secondary timer,
- * and that's why the CLOCK_TICK_RATE is not 32768.
- */
-#ifdef CONFIG_OMAP_32K_TIMER
-#define CLOCK_TICK_RATE (CONFIG_OMAP_32K_TIMER_HZ)
-#else
#define CLOCK_TICK_RATE (HZ * 100000UL)
-#endif
#endif /* __ASM_ARCH_OMAP_TIMEX_H */
--
1.7.9.5
^ permalink raw reply related
* [Patch v2 2/2] ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check" bug
From: Paul Walmsley @ 2013-01-31 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359642327-5542-3-git-send-email-gururaja.hebbar@ti.com>
+ Koen
Hi
On Thu, 31 Jan 2013, Hebbar Gururaja wrote:
> am33xx_cm_wait_module_ready() checks if register offset is NULL.
>
> int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
> {
> int i = 0;
>
> if (!clkctrl_offs)
> return 0;
>
> In case of AM33xx, CLKCTRL register offset for different clock domains
> are not uniformly placed. An example of this would be the RTC clock
> domain with CLKCTRL offset at 0x00.
> In such cases the module ready check is skipped which leads to a data
> abort during boot-up when RTC registers is accessed.
>
> Remove this check here to avoid checking module readiness for modules
> with clkctrl register offset at 0x00.
>
> Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
Some text has been added to the patch description to describe Koen's test
results, and the updated patch has been queued for v3.8-rc fixes. Updated
patch follows.
- Paul
From: Hebbar Gururaja <gururaja.hebbar@ti.com>
Date: Thu, 31 Jan 2013 19:55:27 +0530
Subject: [PATCH] ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check"
bug
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Koen Kooi notes that this patch fixes a crash on boot with
CONFIG_RTC_DRV_OMAP=y with v3.8-rc5.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
Cc: Koen Kooi <koen@dominion.thruhere.net>
[paul at pwsan.com: noted Koen's test in the patch description]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/cm33xx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 058ce3c..325a515 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -241,9 +241,6 @@ int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
--
1.7.10.4
^ permalink raw reply related
* [Patch v2 1/2] ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST flags
From: Paul Walmsley @ 2013-01-31 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359642327-5542-2-git-send-email-gururaja.hebbar@ti.com>
Hi
On Thu, 31 Jan 2013, Hebbar Gururaja wrote:
> struct omap_hwmod records belonging to wkup m3 domain is missing
> HWMOD_NO_IDLEST flags; add them.
>
> Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
I've modified this patch to add some more description of why it's needed
as a fix, and queued it for v3.8-rc fixes.
Updated patch follows.
- Paul
From: Hebbar Gururaja <gururaja.hebbar@ti.com>
Date: Thu, 31 Jan 2013 19:55:26 +0530
Subject: [PATCH] ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST
flags
struct omap_hwmod records belonging to wkup m3 domain is missing
HWMOD_NO_IDLEST flags; add them.
This patch is a prerequisite for a subsequent patch, 'ARM: OMAP2:
am33xx-hwmod: Fix "register offset NULL check" bug'. That patch would
otherwise attempt to read from reserved bits.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
[paul at pwsan.com: add some more explanation in the patch description]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 646c14d..1ab693e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -262,7 +262,8 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.name = "wkup_m3",
.class = &am33xx_wkup_m3_hwmod_class,
.clkdm_name = "l4_wkup_aon_clkdm",
- .flags = HWMOD_INIT_NO_RESET, /* Keep hardreset asserted */
+ /* Keep hardreset asserted */
+ .flags = HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
.mpu_irqs = am33xx_wkup_m3_irqs,
.main_clk = "dpll_core_m4_div2_ck",
.prcm = {
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-31 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131150801.GA23505@n2100.arm.linux.org.uk>
Dear Russell King - ARM Linux,
On Thu, 31 Jan 2013 15:08:01 +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 31, 2013 at 03:57:37PM +0100, Thomas Petazzoni wrote:
> > Indeed. But this function never gets called with bus->number == 0, only
> > with bus->number = 1, 2, 3, 4, 5, 6. So those are child busses, and
> > therefore they have a parent.
>
> Having thought about it, yes, that's what I expect, because root bus
> resources are never resized. Root bus resources are normally setup
> before probing to indicate what size they _can_ be and define what
> space is available to the downstream devices.
>
> Child busses (behind a PCI-2-PCI bridge) are a different matter - these
> will be adjusted according to their on-bus devices and the windows for
> them sized and allocated appropriately _within_ the confines of the
> root bus resource.
Ok.
> > I am talking about the PCI-to-PCI bridges. I want the I/O windows
> > assigned to each PCI-to-PCI bridge to be 64K aligned. The PCI-to-PCI
> > bridges are devices that sit on bus 0, each giving access to the child
> > buses 1, 2, 3, 4, 5, 6.
>
> Right, so you've just confirmed that this _is_ the right hook and it
> _is_ being called at the right time.
Ok.
> However, I had interpreted your requirement as the _host_ bridge only
> (insufficient information in your previous emails, or I missed it).
Might be insufficient information, or wrong terminology on my side.
> If that's what your bridge requires, then we need to detect it via
> its vendor and device IDs and only apply this fixup to those bridges
> which require a 64K alignment.
>
> So, the IDs are vendor:device = 0x11ab:0x1092 ? And let me get this
> straight, it _is_ a specific requirement for this particular bridge
> P2P bridge?
The vendor/device ID will change. This P2P bridge is emulated. However,
I'm not sure why you need to know the vendor:device ID to make the
fixup specific.
The fixup is already specific to those bridges, since I am just setting
pci_sys_data->win_align_io to 64K for the particular buses that are
downstream the problematic bridges. So it doesn't affect any other bus
on the system, and therefore I don't think this fixup needs to be made
specific to a given vendor:device, no?
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* OMAP4 PM bootloader dependency problems
From: Paul Walmsley @ 2013-01-31 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359622829.10415.40.camel@sokoban>
Hi,
On Thu, 31 Jan 2013, Tero Kristo wrote:
> Personally I don't like too much to have just extra spam during boot,
> which in many cases is even unnecessary (e.g. people who actually have
> good u-boot in use.)
The impact of two or three informative lines sent to the kernel console on
boot is lower than the cost of people spending hours trying to figure out
why chip retention idle doesn't work.
Linux distributions that control the bootloader version can easily
comment out the warning.
I'm hoping the console messages will inspire someone out there to fix the
root cause of the problem -- that the kernel is missing device
reset and initialization code for several OMAP4 devices.
> Personally I would like to have some sort of test during boot which
> detects broken PM and maybe prevents core idle completely if this is the
> case.
As far as I know, a simple, clean test for this that can be merged
right now doesn't exist, and has never been posted to the lists.
Personally, it's unclear how such a test can be implemented reliably.
You've proposed checking IP block idle/standby states during PM init in
previous E-mails. But the problem with this is that those IP blocks might
already be in use by their drivers by the time the OMAP4 PM code
initializes.
It's also important to keep in mind that adding any significant amount of
new code this late in the 3.8-rc cycle is not acceptable for my upstreams.
That said, if you have a clean, reliable, and short solution for this,
please post it by the end of the week.
> Alternatively we can add extra info to the failed suspend dump and
> mention a good u-boot to try out (v2012-07 or newer.)
Folks might be using dynamic idle, so just adding a message on resume from
suspend isn't enough.
> If we could detect boot loader version from kernel side, that would work
> also.
I haven't seen any proposals for how to do this. Even if one were
available, it would require maintaining kernel blacklists. Considering
that the fault is in the kernel OMAP4 integration code and data, adding
such a blacklist seems like the wrong approach.
...
In any case, all of the options that you've mentioned are workarounds, not
real solutions. Fixing the root cause would involve adding reset and
initialization code for the remaining devices. No one is working on this
as far as I'm aware. And even if they were, it would be too much code to
add during the v3.8-rc fixes cycle.
I understand that you don't want to add an unconditional message on boot.
But right now, it's the best approach. Please post a patch for this by
the end of this week that I or Kevin can send upstream ASAP.
regards,
- Paul
^ permalink raw reply
* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
From: Viresh Kumar @ 2013-01-31 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1520678.Zm627xxIN3@amdc1227>
On 31 January 2013 20:34, Tomasz Figa <t.figa@samsung.com> wrote:
> Well, the fact that it isn't used at the moment doesn't mean that it
> shouldn't be set correctly. The field is present in the structure and has
> a set of defined values - one of which should be selected. For example,
> I can imagine some governor taking this information into account.
Governors already take this information but from a different variable:
policy->cpus.
Look at the patch which added it:
commit 3b2d99429e3386b6e2ac949fc72486509c8bbe36
Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Date: Wed Dec 14 15:05:00 2005 -0500
P-state software coordination for ACPI core
http://bugzilla.kernel.org/show_bug.cgi?id=5737
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
---
drivers/acpi/processor_perflib.c | 228
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/acpi/processor.h | 27 ++++++++++++-
include/linux/cpufreq.h | 4 ++
3 files changed, 258 insertions(+), 1 deletion(-)
It was clearly for ACPI, but was probably named badly and we people
got confused that it is for our use.
--
viresh
^ permalink raw reply
* [RFC 1/3] net: freescale: fec: add support for optional enet_out clk
From: Wolfram Sang @ 2013-01-31 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130052547.GA23670@S2100-06.ap.freescale.net>
On Wed, Jan 30, 2013 at 01:25:50PM +0800, Shawn Guo wrote:
> Thanks for working on this, Wolfram.
>
> On Tue, Jan 29, 2013 at 03:46:11PM +0100, Wolfram Sang wrote:
> > Some MX28 boards need the internal enet_out clock to be enabled. So, do
> > this in the driver iff the clock was referenced via devicetree.
> >
> > Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
>
> > ---
> >
> > davidm: Please don't apply before Shawn as the mxs-maintainer has given his ack
> > on the general procedure. Or maybe he can merge it via his tree?
> >
> I prefer to have the patch go via net tree for 3.9, and then we clean
> up mxs platform code from 3.9-rc1.
Fine with me, too.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130131/57a58704/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/2] ARM: memory: define TASK_UNMAPPED_BASE in terms of TASK_SIZE
From: Will Deacon @ 2013-01-31 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359644949-18550-1-git-send-email-will.deacon@arm.com>
TASK_UNMAPPED_BASE is defined directly in terms of PAGE_OFFSET, which is
confusing given that the modules area sits between here and TASK_SIZE
and is not available for user allocations.
This patch defines TASK_UNMAPPED_BASE in terms of TASK_SIZE instead and
fixes a bug introduced by 394ef6403abc ("mm: use vm_unmapped_area() on
arm architecture") whereby TASK_UNMAPPED_BASE is no longer page-aligned
for bottom-up mmap, causing get_unmapped_area to choke on misaligned
addresses.
Reported-by: Christoffer Dall <cdall@cs.columbia.edu>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/memory.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 924320f..64c770d 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -37,7 +37,7 @@
*/
#define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)
#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
-#define TASK_UNMAPPED_BASE (UL(CONFIG_PAGE_OFFSET) / 3)
+#define TASK_UNMAPPED_BASE ALIGN(TASK_SIZE / 3, SZ_16M)
/*
* The maximum size of a 26-bit user space task.
--
1.8.0
^ permalink raw reply related
* [PATCH v2 1/2] ARM: memory: use SZ_ constants for defining the virtual memory layout
From: Will Deacon @ 2013-01-31 15:09 UTC (permalink / raw)
To: linux-arm-kernel
Parts of the virtual memory layout (mainly the modules area) are
described using open-coded immediate values.
Use the SZ_ definitions from linux/sizes.h instead to make the code
clearer.
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/memory.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 73cf03a..924320f 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -36,23 +36,23 @@
* TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area
*/
#define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)
-#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(0x01000000))
+#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
#define TASK_UNMAPPED_BASE (UL(CONFIG_PAGE_OFFSET) / 3)
/*
* The maximum size of a 26-bit user space task.
*/
-#define TASK_SIZE_26 UL(0x04000000)
+#define TASK_SIZE_26 (UL(1) << 26)
/*
* The module space lives between the addresses given by TASK_SIZE
* and PAGE_OFFSET - it must be within 32MB of the kernel text.
*/
#ifndef CONFIG_THUMB2_KERNEL
-#define MODULES_VADDR (PAGE_OFFSET - 16*1024*1024)
+#define MODULES_VADDR (PAGE_OFFSET - SZ_16M)
#else
/* smaller range for Thumb-2 symbols relocation (2^24)*/
-#define MODULES_VADDR (PAGE_OFFSET - 8*1024*1024)
+#define MODULES_VADDR (PAGE_OFFSET - SZ_8M)
#endif
#if TASK_SIZE > MODULES_VADDR
--
1.8.0
^ permalink raw reply related
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Russell King - ARM Linux @ 2013-01-31 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131155737.4ab97a0b@skate>
On Thu, Jan 31, 2013 at 03:57:37PM +0100, Thomas Petazzoni wrote:
> Indeed. But this function never gets called with bus->number == 0, only
> with bus->number = 1, 2, 3, 4, 5, 6. So those are child busses, and
> therefore they have a parent.
Having thought about it, yes, that's what I expect, because root bus
resources are never resized. Root bus resources are normally setup
before probing to indicate what size they _can_ be and define what
space is available to the downstream devices.
Child busses (behind a PCI-2-PCI bridge) are a different matter - these
will be adjusted according to their on-bus devices and the windows for
them sized and allocated appropriately _within_ the confines of the
root bus resource.
> I am talking about the PCI-to-PCI bridges. I want the I/O windows
> assigned to each PCI-to-PCI bridge to be 64K aligned. The PCI-to-PCI
> bridges are devices that sit on bus 0, each giving access to the child
> buses 1, 2, 3, 4, 5, 6.
Right, so you've just confirmed that this _is_ the right hook and it
_is_ being called at the right time.
However, I had interpreted your requirement as the _host_ bridge only
(insufficient information in your previous emails, or I missed it).
If that's what your bridge requires, then we need to detect it via
its vendor and device IDs and only apply this fixup to those bridges
which require a 64K alignment.
So, the IDs are vendor:device = 0x11ab:0x1092 ? And let me get this
straight, it _is_ a specific requirement for this particular bridge
P2P bridge?
^ permalink raw reply
* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
From: Tomasz Figa @ 2013-01-31 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpombSKY-HMXovBAyZd5Ce8ZAEo2+yiwYL1G4=OEUJM1u5g@mail.gmail.com>
On Thursday 31 of January 2013 20:22:50 Viresh Kumar wrote:
> On 31 January 2013 20:15, Tomasz Figa <t.figa@samsung.com> wrote:
> > On Thursday 31 of January 2013 09:50:37 Viresh Kumar wrote:
> >> > + policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> >>
> >> I couldn't understand the use of this change. Can you please explain
> >> ?
> >
> > All cores on Exynos SoCs share the same clock source, which means that
> > they all always run at the same frequency. So setting frequency on one
> > core sets the frequency on all cores and so it doesn't matter on which
> > core the frequency setting operation is done.
>
> Great, that's like most other platforms and for this you just need to
> set mask of all the possible cpus (online or offline) into policy->cpus
> > As you can see in include/linux/cpufreq.h:
> >
> > #define CPUFREQ_SHARED_TYPE_ANY (3) /* Freq can be set from any
> > dependent CPU*/
> >
> > which basically tells (together with rest of the patch) the cpufreq
> > subsystem about what I wrote earlier.
>
> I don't think so. Because i wasn't using it on my system and it was
> working well.
> Then i grepped it in kernel source
>
> viresh at blr-linut-001:$ git grep shared_type drivers/cpufreq/
> drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type !=
> CPUFREQ_SHARED_TYPE_ANY)
> drivers/cpufreq/acpi-cpufreq.c: policy->shared_type = perf->shared_type;
> drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type ==
> CPUFREQ_SHARED_TYPE_ALL ||
> drivers/cpufreq/acpi-cpufreq.c: policy->shared_type ==
> CPUFREQ_SHARED_TYPE_ANY) {
> drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
> CPUFREQ_SHARED_TYPE_ALL;
> drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
> CPUFREQ_SHARED_TYPE_HW;
> drivers/cpufreq/cpufreq-cpu0.c: policy->shared_type =
> CPUFREQ_SHARED_TYPE_ANY; drivers/cpufreq/db8500-cpufreq.c:
> policy->shared_type =
> CPUFREQ_SHARED_TYPE_ALL;
> drivers/cpufreq/omap-cpufreq.c: policy->shared_type =
> CPUFREQ_SHARED_TYPE_ANY;
> drivers/cpufreq/speedstep-centrino.c: if
> (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
> drivers/cpufreq/speedstep-centrino.c: if
> (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
>
> I couldn't see any core file using this stuff other than acpi-cpufreq.c,
> which is for x86 only systems if i am not wrong.
>
> @Rafael: You view on this.. ? Actually i believe it was just used by
> many ARM drivers without knowing the real use of it and new drivers
> have just followed it.
>
> I can get a patch to fix it at all places if you agree.
>
> BTW, grep in full kernel source gave, which is again acpi only:
>
> viresh at blr-linut-001:$ git grep shared_type
>
> arch/arm/mach-tegra/cpu-tegra.c: policy->shared_type =
> CPUFREQ_SHARED_TYPE_ALL;
> drivers/acpi/processor_perflib.c:
> pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL;
> drivers/acpi/processor_perflib.c:
> pr->performance->shared_type = CPUFREQ_SHARED_TYPE_HW;
> drivers/acpi/processor_perflib.c:
> pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> drivers/acpi/processor_perflib.c:
> match_pr->performance->shared_type =
> drivers/acpi/processor_perflib.c:
> pr->performance->shared_type;
> drivers/acpi/processor_perflib.c:
> pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL;
> drivers/acpi/processor_throttling.c:
> pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
> drivers/acpi/processor_throttling.c: pthrottling->shared_type =
> pdomain->coord_type;
> drivers/acpi/processor_throttling.c:
> pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
> drivers/acpi/processor_throttling.c: if (p_throttling->shared_type
> == DOMAIN_COORD_TYPE_SW_ANY) {
> drivers/acpi/processor_throttling.c:
> pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
> drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type !=
> CPUFREQ_SHARED_TYPE_ANY)
> drivers/cpufreq/acpi-cpufreq.c: policy->shared_type = perf->shared_type;
> drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type ==
> CPUFREQ_SHARED_TYPE_ALL ||
> drivers/cpufreq/acpi-cpufreq.c: policy->shared_type ==
> CPUFREQ_SHARED_TYPE_ANY) {
> drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
> CPUFREQ_SHARED_TYPE_ALL;
> drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
> CPUFREQ_SHARED_TYPE_HW;
> drivers/cpufreq/cpufreq-cpu0.c: policy->shared_type =
> CPUFREQ_SHARED_TYPE_ANY; drivers/cpufreq/db8500-cpufreq.c:
> policy->shared_type =
> CPUFREQ_SHARED_TYPE_ALL;
> drivers/cpufreq/omap-cpufreq.c: policy->shared_type =
> CPUFREQ_SHARED_TYPE_ANY;
> drivers/cpufreq/speedstep-centrino.c: if
> (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
> drivers/cpufreq/speedstep-centrino.c: if
> (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
> drivers/net/wireless/rtlwifi/rtl8192ce/hw.c:
> rtlpcipriv->bt_coexist.bt_radio_shared_type =
> drivers/net/wireless/rtlwifi/rtl8723ae/hw.c:
> pcipriv->bt_coexist.bt_radio_shared_type =
> drivers/net/wireless/rtlwifi/rtl8723ae/hw.c:
> pcipriv->bt_coexist.bt_radio_shared_type);
> drivers/net/wireless/rtlwifi/wifi.h: u8 bt_radio_shared_type;
> drivers/xen/xen-acpi-processor.c: dst->shared_type =
> _pr->performance->shared_type;
> drivers/xen/xen-acpi-processor.c:
> dst->shared_type = CPUFREQ_SHARED_TYPE_ALL;
> drivers/xen/xen-acpi-processor.c:
> dst->shared_type = CPUFREQ_SHARED_TYPE_HW;
> drivers/xen/xen-acpi-processor.c:
> dst->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> include/acpi/processor.h: unsigned int shared_type;
> include/acpi/processor.h: unsigned int shared_type;
> include/linux/cpufreq.h: unsigned int shared_type;
> /* ANY or ALL affected CPUs
> include/xen/interface/platform.h: uint32_t shared_type; /*
> coordination type of this processor */
> tools/perf/util/dwarf-aux.c: tag == DW_TAG_shared_type);
Well, the fact that it isn't used at the moment doesn't mean that it
shouldn't be set correctly. The field is present in the structure and has
a set of defined values - one of which should be selected. For example,
I can imagine some governor taking this information into account.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-31 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131145002.GZ23505@n2100.arm.linux.org.uk>
Dear Russell King - ARM Linux,
On Thu, 31 Jan 2013 14:50:02 +0000, Russell King - ARM Linux wrote:
> > > + /* Ignore downstream buses */
> > > + if (!bus->parent) {
> > > + if (type & IORESOURCE_MEM)
> > > + return sys->win_align_mem;
> > > + if (type & IORESOURCE_IO)
> > > + return sys->win_align_io;
> > > + }
> > > + return 1;
> > > +}
> > > +
> >
> > Unfortunately, this doesn't work as is for me: the if (!bus->parent)
> > prevents the thing from being effective. Here my lspci output:
> >
> > # /usr/sbin/lspci
> > 00:00.0 Host bridge: Marvell Technology Group Ltd. Device 102d
> > 00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> > 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> > 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> > 00:04.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> > 00:05.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> > 00:06.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> > 03:00.0 SCSI storage controller: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II (rev 02)
> > 05:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
> >
> > And the function pcibios_window_alignment() only gets called for bus 1,
> > 2, 3, 4, 5, 6 and never for bus 0.
>
> That's the exact reverse of what I'd expect: the child buses should
> have a non-NULL parent pointer.
Indeed. But this function never gets called with bus->number == 0, only
with bus->number = 1, 2, 3, 4, 5, 6. So those are child busses, and
therefore they have a parent.
If I had a debug message in this pcibios_window_alignment() function
(which gets shown unconditionally, i.e the debug message is outside the
if condition we are discussing), then I get:
pcibios_window_alignment: called for bus ef371c00 (sysdata=ef2f6bc0), number 1
pcibios_window_alignment: called for bus ef371c00 (sysdata=ef2f6bc0), number 1
pcibios_window_alignment: called for bus ef371c00 (sysdata=ef2f6bc0), number 1
pcibios_window_alignment: called for bus ef371a00 (sysdata=ef2f6bc0), number 2
pcibios_window_alignment: called for bus ef371a00 (sysdata=ef2f6bc0), number 2
pcibios_window_alignment: called for bus ef371a00 (sysdata=ef2f6bc0), number 2
pcibios_window_alignment: called for bus ef371800 (sysdata=ef2f6bc0), number 3
pcibios_window_alignment: called for bus ef371800 (sysdata=ef2f6bc0), number 3
pcibios_window_alignment: called for bus ef371800 (sysdata=ef2f6bc0), number 3
pcibios_window_alignment: called for bus ef371600 (sysdata=ef2f6bc0), number 4
pcibios_window_alignment: called for bus ef371600 (sysdata=ef2f6bc0), number 4
pcibios_window_alignment: called for bus ef371600 (sysdata=ef2f6bc0), number 4
pcibios_window_alignment: called for bus ef371400 (sysdata=ef2f6bc0), number 5
pcibios_window_alignment: called for bus ef371400 (sysdata=ef2f6bc0), number 5
pcibios_window_alignment: called for bus ef371400 (sysdata=ef2f6bc0), number 5
pcibios_window_alignment: called for bus ef371200 (sysdata=ef2f6bc0), number 6
pcibios_window_alignment: called for bus ef371200 (sysdata=ef2f6bc0), number 6
pcibios_window_alignment: called for bus ef371200 (sysdata=ef2f6bc0), number 6
See, never called bus bus number 0.
> Hmm. Try changing that for !bus->self -
> that should make it effective only on the host bridge.
>
> But... hang on...
>
> /*
> * Returns true if the pci bus is root (behind host-pci bridge),
> * false otherwise
> */
> static inline bool pci_is_root_bus(struct pci_bus *pbus)
> {
> return !(pbus->parent);
> }
>
> So the original test _is_ correct, and should only be triggered for
> the _root_ bus, that being bus 0 in the above case.
Except that this pcibios_window_alignement() function is apparently
never called for the root bus.
>
> But... wait a moment, what are you saying? Which bridges need this
> fixup? The Marvell PCI-to-PCI bridges or the host bridge?
I am talking about the PCI-to-PCI bridges. I want the I/O windows
assigned to each PCI-to-PCI bridge to be 64K aligned. The PCI-to-PCI
bridges are devices that sit on bus 0, each giving access to the child
buses 1, 2, 3, 4, 5, 6.
I have the impression that the pcibios_window_alignment() function is
called on the *child* bus to know the requested alignments for the
bridge that sits on the parent bus and gives access to this child bus.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
From: Viresh Kumar @ 2013-01-31 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1520677.WES295RohH@amdc1227>
On 31 January 2013 20:15, Tomasz Figa <t.figa@samsung.com> wrote:
> On Thursday 31 of January 2013 09:50:37 Viresh Kumar wrote:
>> > + policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
>> I couldn't understand the use of this change. Can you please explain ?
>
> All cores on Exynos SoCs share the same clock source, which means that
> they all always run at the same frequency. So setting frequency on one
> core sets the frequency on all cores and so it doesn't matter on which
> core the frequency setting operation is done.
Great, that's like most other platforms and for this you just need to set mask
of all the possible cpus (online or offline) into policy->cpus
> As you can see in include/linux/cpufreq.h:
>
> #define CPUFREQ_SHARED_TYPE_ANY (3) /* Freq can be set from any dependent
> CPU*/
>
> which basically tells (together with rest of the patch) the cpufreq
> subsystem about what I wrote earlier.
I don't think so. Because i wasn't using it on my system and it was
working well.
Then i grepped it in kernel source
viresh at blr-linut-001:$ git grep shared_type drivers/cpufreq/
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type !=
CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type = perf->shared_type;
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type ==
CPUFREQ_SHARED_TYPE_ALL ||
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type ==
CPUFREQ_SHARED_TYPE_ANY) {
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_HW;
drivers/cpufreq/cpufreq-cpu0.c: policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/db8500-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/omap-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/speedstep-centrino.c: if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/speedstep-centrino.c: if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
I couldn't see any core file using this stuff other than acpi-cpufreq.c,
which is for x86 only systems if i am not wrong.
@Rafael: You view on this.. ? Actually i believe it was just used by many
ARM drivers without knowing the real use of it and new drivers have just
followed it.
I can get a patch to fix it at all places if you agree.
BTW, grep in full kernel source gave, which is again acpi only:
viresh at blr-linut-001:$ git grep shared_type
arch/arm/mach-tegra/cpu-tegra.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_HW;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ANY;
drivers/acpi/processor_perflib.c:
match_pr->performance->shared_type =
drivers/acpi/processor_perflib.c:
pr->performance->shared_type;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL;
drivers/acpi/processor_throttling.c:
pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
drivers/acpi/processor_throttling.c: pthrottling->shared_type =
pdomain->coord_type;
drivers/acpi/processor_throttling.c:
pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
drivers/acpi/processor_throttling.c: if (p_throttling->shared_type
== DOMAIN_COORD_TYPE_SW_ANY) {
drivers/acpi/processor_throttling.c:
pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type !=
CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type = perf->shared_type;
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type ==
CPUFREQ_SHARED_TYPE_ALL ||
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type ==
CPUFREQ_SHARED_TYPE_ANY) {
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_HW;
drivers/cpufreq/cpufreq-cpu0.c: policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/db8500-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/omap-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/speedstep-centrino.c: if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/speedstep-centrino.c: if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c:
rtlpcipriv->bt_coexist.bt_radio_shared_type =
drivers/net/wireless/rtlwifi/rtl8723ae/hw.c:
pcipriv->bt_coexist.bt_radio_shared_type =
drivers/net/wireless/rtlwifi/rtl8723ae/hw.c:
pcipriv->bt_coexist.bt_radio_shared_type);
drivers/net/wireless/rtlwifi/wifi.h: u8 bt_radio_shared_type;
drivers/xen/xen-acpi-processor.c: dst->shared_type =
_pr->performance->shared_type;
drivers/xen/xen-acpi-processor.c:
dst->shared_type = CPUFREQ_SHARED_TYPE_ALL;
drivers/xen/xen-acpi-processor.c:
dst->shared_type = CPUFREQ_SHARED_TYPE_HW;
drivers/xen/xen-acpi-processor.c:
dst->shared_type = CPUFREQ_SHARED_TYPE_ANY;
include/acpi/processor.h: unsigned int shared_type;
include/acpi/processor.h: unsigned int shared_type;
include/linux/cpufreq.h: unsigned int shared_type;
/* ANY or ALL affected CPUs
include/xen/interface/platform.h: uint32_t shared_type; /*
coordination type of this processor */
tools/perf/util/dwarf-aux.c: tag == DW_TAG_shared_type);
^ permalink raw reply
* [PATCH v3] arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP)
From: Gregory CLEMENT @ 2013-01-31 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359643812-32654-1-git-send-email-gregory.clement@free-electrons.com>
This is the new Armada XP evaluation board from Marvell. It comes with
a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
Gigabit links.
Support for USB (Host and device), SDIO, PCIe will be added as drivers
when they become available for Armada XP in mainline.
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Tested-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-xp-gp.dts | 101 ++++++++++++++++++++++++++++++++++++
2 files changed, 102 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5ebb44f..51aab4b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-370-mirabox.dtb \
armada-xp-db.dtb \
+ armada-xp-gp.dtb \
armada-xp-openblocks-ax3-4.dtb
dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
imx53-ard.dtb \
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
new file mode 100644
index 0000000..3eea531
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -0,0 +1,101 @@
+/*
+ * Device Tree file for Marvell Armada XP development board
+ * (DB-MV784MP-GP)
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "armada-xp-mv78460.dtsi"
+
+/ {
+ model = "Marvell Armada XP Development Board DB-MV784MP-GP";
+ compatible = "marvell,axp-gp", "marvell,armadaxp-mv78460", "marvell,armadaxp", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+
+ /*
+ * 4 GB of plug-in RAM modules by default but only 3GB
+ * are visible, the amount of memory available can be
+ * changed by the bootloader according the size of the
+ * module actually plugged
+ */
+ reg = <0x00000000 0xC0000000>;
+ };
+
+ soc {
+ serial at d0012000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012100 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012200 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012300 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+
+ sata at d00a0000 {
+ nr-ports = <2>;
+ status = "okay";
+ };
+
+ mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <16>;
+ };
+
+ phy1: ethernet-phy at 1 {
+ reg = <17>;
+ };
+
+ phy2: ethernet-phy at 2 {
+ reg = <18>;
+ };
+
+ phy3: ethernet-phy at 3 {
+ reg = <19>;
+ };
+ };
+
+ ethernet at d0070000 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0074000 {
+ status = "okay";
+ phy = <&phy1>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0030000 {
+ status = "okay";
+ phy = <&phy2>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0034000 {
+ status = "okay";
+ phy = <&phy3>;
+ phy-mode = "rgmii-id";
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3] Adding support for the new Armada XP development board from Marvell
From: Gregory CLEMENT @ 2013-01-31 14:50 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This is the third version (and hopefully the last) of a single patch
to add the dts support for new Armada XP development board from
Marvell called DB-MV784MP-GP.
The branch GP-board is available at
https://github.com/MISL-EBU-System-SW/mainline-public.git
Changelog:
V2->v3
- fixed typos in comments
- fixed the compatible string for the board and use marvell,axp-gp
instead of marvell,axp-db which was already used by an other board
- fixed the model name by remove the colon
v2->v1:
- added tested-by from Simon Guinot and Florian Fainelli
- added some comments to emphasize that the amount of memory may
change.
- named the board ``development board''
Gregory CLEMENT (1):
arm: mvebu: support for the new Armada XP development
board(DB-MV784MP-GP)
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-xp-gp.dts | 101 ++++++++++++++++++++++++++++++++++++
2 files changed, 102 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Russell King - ARM Linux @ 2013-01-31 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131153041.35fa3b60@skate>
On Thu, Jan 31, 2013 at 03:30:41PM +0100, Thomas Petazzoni wrote:
> Dear Russell King - ARM Linux,
>
> On Wed, 30 Jan 2013 15:46:02 +0000, Russell King - ARM Linux wrote:
>
> > +resource_size_t pcibios_window_alignment(struct pci_bus *bus,
> > + unsigned long type)
> > +{
> > + struct pci_sys_data *sys = bus->sysdata;
> > +
> > + /* Ignore downstream buses */
> > + if (!bus->parent) {
> > + if (type & IORESOURCE_MEM)
> > + return sys->win_align_mem;
> > + if (type & IORESOURCE_IO)
> > + return sys->win_align_io;
> > + }
> > + return 1;
> > +}
> > +
>
> Unfortunately, this doesn't work as is for me: the if (!bus->parent)
> prevents the thing from being effective. Here my lspci output:
>
> # /usr/sbin/lspci
> 00:00.0 Host bridge: Marvell Technology Group Ltd. Device 102d
> 00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> 00:04.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> 00:05.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> 00:06.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
> 03:00.0 SCSI storage controller: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II (rev 02)
> 05:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
>
> And the function pcibios_window_alignment() only gets called for bus 1,
> 2, 3, 4, 5, 6 and never for bus 0.
That's the exact reverse of what I'd expect: the child buses should
have a non-NULL parent pointer. Hmm. Try changing that for !bus->self -
that should make it effective only on the host bridge.
But... hang on...
/*
* Returns true if the pci bus is root (behind host-pci bridge),
* false otherwise
*/
static inline bool pci_is_root_bus(struct pci_bus *pbus)
{
return !(pbus->parent);
}
So the original test _is_ correct, and should only be triggered for
the _root_ bus, that being bus 0 in the above case.
But... wait a moment, what are you saying? Which bridges need this
fixup? The Marvell PCI-to-PCI bridges or the host bridge?
^ permalink raw reply
* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
From: Tomasz Figa @ 2013-01-31 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOh2x==GeK4qM=kjy-tzhbEh4L9AmRXoG_0tUzov1SK+uRFxcw@mail.gmail.com>
Hi Viresh,
On Thursday 31 of January 2013 09:50:37 Viresh Kumar wrote:
> On Tue, Nov 13, 2012 at 2:56 PM, Tomasz Figa <t.figa@samsung.com> wrote:
> > On Exynos SoCs all cores share the same frequency setting, so changing
> > frequency of one core will affect rest of cores.
> >
> > This patch modifies the exynos-cpufreq driver to inform cpufreq core
> > about this behavior and broadcast frequency change notifications for
> > all cores.
> >
> > /* When the new frequency is lower than current frequency */
> > if ((freqs.new < freqs.old) ||
> >
> > @@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct
> > cpufreq_policy *policy)>
> > cpumask_copy(policy->related_cpus, cpu_possible_mask);
> > cpumask_copy(policy->cpus, cpu_online_mask);
> >
> > } else {
> >
> > + policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> >
> > cpumask_setall(policy->cpus);
>
> I couldn't understand the use of this change. Can you please explain ?
All cores on Exynos SoCs share the same clock source, which means that
they all always run at the same frequency. So setting frequency on one
core sets the frequency on all cores and so it doesn't matter on which
core the frequency setting operation is done.
As you can see in include/linux/cpufreq.h:
#define CPUFREQ_SHARED_TYPE_ANY (3) /* Freq can be set from any dependent
CPU*/
which basically tells (together with rest of the patch) the cpufreq
subsystem about what I wrote earlier.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
* Failure to boot...
From: Santosh Shilimkar @ 2013-01-31 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131142758.GS2637@n2100.arm.linux.org.uk>
On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote:
> On Thu, Jan 31, 2013 at 07:50:15PM +0530, Santosh Shilimkar wrote:
>> On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote:
>>> On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote:
>>>> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote:
>>>>> Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well.
>>>>> The pull request from Tony [1] fixed the multi-platform boot issue
>>>>> for OMAP.
>>>>>
>>>>> Now trying to merge your for-next and test.
>>>>
>>>> Well, my tip (which is based on Linus' 6abb7c25) also builds and
>>>> boots fine.
>>>>
>>>> Hang on...
>>>>
>>>> # CONFIG_ARCH_OMAP2PLUS is not set
>>>> CONFIG_ARCH_VEXPRESS=y
>>>>
>>>> which of course won't boot, and this happens on both oldconfigs because
>>>> of the change to multiplatform support.
>>>
>>> And no, the instructions given last time around to add:
>>>
>>> # 13 Jan 2013: Update for OMAP moving to multiplatform
>>> CONFIG_ARCH_MULTIPLATFORM=y
>>> CONFIG_ARCH_MULTI_V7=y
>>>
>>> don't fix it either, it needs more options defined...
>>>
>> Linus' tip + Tony's pull [1] request also makes things work
>> on OMAP.
>
> Thanks to all this multiplatform stuff, the autobuilder has been building
> nothing but Versatile Express kernels for the last 20 days. That totally
> explains why it won't boot.
>
> The only thing I was told is to add the above two config symbols. That
> is not the complete story. There's also other symbols which need adding
> too. It also looks like Versatile Express support _can't_ be disabled in
> a multiplatform kernel, which is ludicrous.
>
> And... fixing the config finally results in something that boots on the
> SDP4430.
>
Great. Thanks for the confirmation.
Regards,
Santosh
^ permalink raw reply
* [GIT PULL] ux500 <mach/id.h> removal
From: Linus Walleij @ 2013-01-31 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301302315.22357.arnd@arndb.de>
On Thu, Jan 31, 2013 at 12:15 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> Unrelated to this: The mach/id.h removal seems to have caused a few
> build errors in the for-next tree with u8500_defconfig. Can you have
> a look at what went wrong there?
Yes ... hm.
I have no clue how this happened, somehow new dependencues
have appeared and I've somehow had a config that builds without
some of the drivers or something :-(
Or I built the wrong branch and thought it was clear to go.
Shall we just drop it until I've fixed it up?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-31 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130154602.GL23505@n2100.arm.linux.org.uk>
Dear Russell King - ARM Linux,
On Wed, 30 Jan 2013 15:46:02 +0000, Russell King - ARM Linux wrote:
> +resource_size_t pcibios_window_alignment(struct pci_bus *bus,
> + unsigned long type)
> +{
> + struct pci_sys_data *sys = bus->sysdata;
> +
> + /* Ignore downstream buses */
> + if (!bus->parent) {
> + if (type & IORESOURCE_MEM)
> + return sys->win_align_mem;
> + if (type & IORESOURCE_IO)
> + return sys->win_align_io;
> + }
> + return 1;
> +}
> +
Unfortunately, this doesn't work as is for me: the if (!bus->parent)
prevents the thing from being effective. Here my lspci output:
# /usr/sbin/lspci
00:00.0 Host bridge: Marvell Technology Group Ltd. Device 102d
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
00:04.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
00:05.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
00:06.0 PCI bridge: Marvell Technology Group Ltd. Device 1092
03:00.0 SCSI storage controller: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II (rev 02)
05:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
And the function pcibios_window_alignment() only gets called for bus 1,
2, 3, 4, 5, 6 and never for bus 0. And therefore, the !bus->parent test
is always false. So, if I keep your implementation, I have the following
addresses assigned to my bridges:
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:00:03.0: bridge window [io 0xc0000000-0xc0000fff]
pci 0000:00:03.0: bridge window [mem 0xc1000000-0xc10fffff]
pci 0000:00:03.0: bridge window [mem 0xc1100000-0xc11fffff pref]
pci 0000:00:05.0: PCI bridge to [bus 05]
pci 0000:00:05.0: bridge window [io 0xc0001000-0xc0001fff]
pci 0000:00:05.0: bridge window [mem 0xc1200000-0xc12fffff]
pci 0000:00:05.0: bridge window [mem 0xc1300000-0xc13fffff pref]
Notice how the io window of the second bridge starts 4K after the io
window of the first bridge. Which cannot work on Marvell SoC, due to
the 64KB alignment.
If, however, I remove the !bus->parent test, the I/O addresses
correctly take into account the 64K requirement:
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:00:03.0: bridge window [io 0xc0000000-0xc000ffff]
pci 0000:00:03.0: bridge window [mem 0xc1000000-0xc10fffff]
pci 0000:00:03.0: bridge window [mem 0xc1100000-0xc11fffff pref]
pci 0000:00:05.0: PCI bridge to [bus 05]
pci 0000:00:05.0: bridge window [io 0xc0010000-0xc001ffff]
pci 0000:00:05.0: bridge window [mem 0xc1200000-0xc12fffff]
pci 0000:00:05.0: bridge window [mem 0xc1300000-0xc13fffff pref]
Any idea?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Failure to boot...
From: Russell King - ARM Linux @ 2013-01-31 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A7D9F.7040507@ti.com>
On Thu, Jan 31, 2013 at 07:50:15PM +0530, Santosh Shilimkar wrote:
> On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote:
>> On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote:
>>> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote:
>>>> Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well.
>>>> The pull request from Tony [1] fixed the multi-platform boot issue
>>>> for OMAP.
>>>>
>>>> Now trying to merge your for-next and test.
>>>
>>> Well, my tip (which is based on Linus' 6abb7c25) also builds and
>>> boots fine.
>>>
>>> Hang on...
>>>
>>> # CONFIG_ARCH_OMAP2PLUS is not set
>>> CONFIG_ARCH_VEXPRESS=y
>>>
>>> which of course won't boot, and this happens on both oldconfigs because
>>> of the change to multiplatform support.
>>
>> And no, the instructions given last time around to add:
>>
>> # 13 Jan 2013: Update for OMAP moving to multiplatform
>> CONFIG_ARCH_MULTIPLATFORM=y
>> CONFIG_ARCH_MULTI_V7=y
>>
>> don't fix it either, it needs more options defined...
>>
> Linus' tip + Tony's pull [1] request also makes things work
> on OMAP.
Thanks to all this multiplatform stuff, the autobuilder has been building
nothing but Versatile Express kernels for the last 20 days. That totally
explains why it won't boot.
The only thing I was told is to add the above two config symbols. That
is not the complete story. There's also other symbols which need adding
too. It also looks like Versatile Express support _can't_ be disabled in
a multiplatform kernel, which is ludicrous.
And... fixing the config finally results in something that boots on the
SDP4430.
^ permalink raw reply
* [PATCH v2] arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP)
From: Gregory CLEMENT @ 2013-01-31 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A7C66.40906@openwrt.org>
On 01/31/2013 03:15 PM, Florian Fainelli wrote:
> On 01/31/2013 03:08 PM, Gregory CLEMENT wrote:
>> This is the new Armada XP evaluation board from Marvell. It comes with
>> a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
>> Gigabit links.
>>
>> Support for USB (Host and device), SDIO, PCIe will be added as drivers
>> when they become available for Armada XP in mainline.
>>
>> Tested-by: Simon Guinot <simon.guinot@sequanux.org>
>> Tested-by: Florian Fainelli <florian@openwrt.org>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/armada-xp-gp.dts | 101 ++++++++++++++++++++++++++++++++++++
>> 2 files changed, 102 insertions(+)
>> create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 5ebb44f..51aab4b 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>> armada-370-mirabox.dtb \
>> armada-xp-db.dtb \
>> + armada-xp-gp.dtb \
>> armada-xp-openblocks-ax3-4.dtb
>> dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
>> imx53-ard.dtb \
>> diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
>> new file mode 100644
>> index 0000000..50e44e7
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
>> @@ -0,0 +1,101 @@
>> +/*
>> + * Device Tree file for Marvell Armada XP development board
>> + * (DB-MV784MP-GP)
>> + *
>> + * Copyright (C) 2013 Marvell
>> + *
>> + * Lior Amsalem <alior@marvell.com>
>> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +/dts-v1/;
>> +/include/ "armada-xp-mv78460.dtsi"
>> +
>> +/ {
>> + model = "Marvell Armada XP Development Board: DB-MV784MP-GP";
>
> I noticed this just now, please do not use ":" for consistency with the
> other DTS files for Armada XP/370.
Well Thomas also pointed me a few typos, and the worst is that I use the compatible
name "marvell,axp-db" already used by an other. So a 3rd version is coming soon.
> --
> Florian
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [REGRESSION+BISECT] imx6: 3.8+: sata failure with 24d340ac "ARM i.MX6: Fix ethernet PLL clocks"
From: Shawn Guo @ 2013-01-31 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131135351.GB5452@luxor.wired.org>
On Thu, Jan 31, 2013 at 02:53:51PM +0100, Paolo Pisati wrote:
> On Thu, Jan 31, 2013 at 09:30:56PM +0800, Shawn Guo wrote:
> >
> > Can you please try to see if the following change bring that SATA back
> > to work?
> >
> > Shawn
> >
> > diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> > index c0c4e72..8f756af 100644
> > --- a/arch/arm/mach-imx/clk-imx6q.c
> > +++ b/arch/arm/mach-imx/clk-imx6q.c
> > @@ -436,6 +436,9 @@ int __init mx6q_clocks_init(void)
> > for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> > clk_prepare_enable(clk[clks_init_on[i]]);
> >
> > + if (IS_ENABLED(CONFIG_SATA_AHCI_PLATFORM))
> > + clk_prepare_enable(clk[sata_ref_100m]);
> > +
> > /* Set initial power mode */
> > imx6q_set_lpm(WAIT_CLOCKED);
>
> yes, it fixes SATA.
>
> Tested-by: <p.pisati@gmail.com>
Just to be clear, I'm not sending this change to mainline, as I expect
someone who cares about SATA function adds this code when he submits
imx6q SATA support (that out of tree patch).
Shawn
^ permalink raw reply
* [Patch v2 2/2] ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check" bug
From: Hebbar Gururaja @ 2013-01-31 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359642327-5542-1-git-send-email-gururaja.hebbar@ti.com>
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
---
Change in v2:
- No change
:100644 100644 058ce3c... 325a515... M arch/arm/mach-omap2/cm33xx.c
arch/arm/mach-omap2/cm33xx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 058ce3c..325a515 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -241,9 +241,6 @@ int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
--
1.7.9.5
^ 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