* [PATCH v3 03/15] ARM: mcpm: introduce helpers for platform coherency exit/setup
From: Santosh Shilimkar @ 2013-01-31 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359445870-18925-4-git-send-email-nicolas.pitre@linaro.org>
On Tuesday 29 January 2013 01:20 PM, Nicolas Pitre wrote:
> From: Dave Martin <dave.martin@linaro.org>
>
> This provides helper methods to coordinate between CPUs coming down
> and CPUs going up, as well as documentation on the used algorithms,
> so that cluster teardown and setup
> operations are not done for a cluster simultaneously.
>
> For use in the power_down() implementation:
> * __mcpm_cpu_going_down(unsigned int cluster, unsigned int cpu)
> * __mcpm_outbound_enter_critical(unsigned int cluster)
> * __mcpm_outbound_leave_critical(unsigned int cluster)
> * __mcpm_cpu_down(unsigned int cluster, unsigned int cpu)
>
> The power_up_setup() helper should do platform-specific setup in
> preparation for turning the CPU on, such as invalidating local caches
> or entering coherency. It must be assembler for now, since it must
> run before the MMU can be switched on. It is passed the affinity level
> which should be initialized.
>
> Because the mcpm_sync_struct content is looked-up and modified
> with the cache enabled or disabled depending on the code path, it is
> crucial to always ensure proper cache maintenance to update main memory
> right away. Therefore, any cached write must be followed by a cache
> clean operation and any cached read must be preceded by a cache
> invalidate operation (actually a cache flush i.e. clean+invalidate to
> avoid discarding possible concurrent writes) on the accessed memory.
>
> Also, in order to prevent a cached writer from interfering with an
> adjacent non-cached writer, we ensure each state variable is located to
> a separate cache line.
>
> Thanks to Nicolas Pitre and Achin Gupta for the help with this
> patch.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
> ---
[..]
> diff --git a/arch/arm/common/mcpm_entry.c b/arch/arm/common/mcpm_entry.c
> index c8c0e2113e..2b83121966 100644
> --- a/arch/arm/common/mcpm_entry.c
> +++ b/arch/arm/common/mcpm_entry.c
> @@ -18,6 +18,7 @@
> #include <asm/proc-fns.h>
> #include <asm/cacheflush.h>
> #include <asm/idmap.h>
> +#include <asm/cputype.h>
>
> extern volatile unsigned long mcpm_entry_vectors[MAX_NR_CLUSTERS][MAX_CPUS_PER_CLUSTER];
>
[...]
> +/*
> + * Ensure preceding writes to *p by other CPUs are visible to
> + * subsequent reads by this CPU. We must be careful not to
> + * discard data simultaneously written by another CPU, hence the
> + * usage of flush rather than invalidate operations.
> + */
> +static void __sync_range_r(volatile void *p, size_t size)
> +{
> + char *_p = (char *)p;
> +
> +#ifdef CONFIG_OUTER_CACHE
> + if (outer_cache.flush_range) {
> +
You don't need above #ifdef. In case of non-outer
cache the function pointer is null anyways.
/*
> + * Ensure dirty data migrated from other CPUs into our cache
> + * are cleaned out safely before the outer cache is cleaned:
> + */
> + __cpuc_clean_dcache_area(_p, size);
> +
> + /* Clean and invalidate stale data for *p from outer ... */
> + outer_flush_range(__pa(_p), __pa(_p + size));
> + }
> +#endif
> +
> + /* ... and inner cache: */
> + __cpuc_flush_dcache_area(_p, size);
This will be un-necessary when inner cache is available, no ?
May be you can re-arrange the code like below, unless and until
you would like to invalidate any speculative fetches during the
outer_flush_range()
__cpuc_clean_dcache_area(_p, size);
if (outer_cache.flush_range)
outer_flush_range(__pa(_p), __pa(_p + size));
Rest of the patch looks fine to me.
Regards,
Santosh
^ permalink raw reply
* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
From: Viresh Kumar @ 2013-01-31 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1604688.EafV1ohaV9@amdc1227>
On 31 January 2013 21:37, Tomasz Figa <t.figa@samsung.com> wrote:
> Hmm. Now as I think of it, there might be another confusing aspect:
>
> Could you explain what "sw coordination" and "any coordination" mean?
> I mean specifically cpufreq_policy.cpus and cpufreq_policy.related_cpus
> masks.
Check this out:
https://lkml.org/lkml/2013/1/30/587
^ permalink raw reply
* BogoMIPS change in 3.6+
From: Rob Herring @ 2013-01-31 16:15 UTC (permalink / raw)
To: linux-arm-kernel
The BogoMIPS value has changed on highbank since the commit below in
3.6. It is now half the value it used to be. Does that matter other than
perception (I've checked that I'm not running at half the freq)?
Rob
commit d0a533b18235d36206b9b422efadb7cee444dfdb
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Jul 6 15:47:17 2012 +0100
ARM: 7452/1: delay: allow timer-based delay implementation to be
selected
This patch allows a timer-based delay implementation to be selected by
switching the delay routines over to use get_cycles, which is
implemented in terms of read_current_timer. This further allows us to
skip the loop calibration and have a consistent delay function in the
face of core frequency scaling.
To avoid the pain of dealing with memory-mapped counters, this
implementation uses the co-processor interface to the architected timers
when they are available. The previous loop-based implementation is
kept around for CPUs without the architected timers and we retain both
the maximum delay (2ms) and the corresponding conversion factors for
determining the number of loops required for a given interval. Since the
indirection of the timer routines will only work when called from C,
the sa1100 sleep routines are modified to branch to the loop-based delay
functions directly.
^ permalink raw reply
* Failure to boot...
From: Russell King - ARM Linux @ 2013-01-31 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BrGcffzd2YBrF6YQTs7X38RuniYhm010fpLMnigecnTw@mail.gmail.com>
On Thu, Jan 31, 2013 at 02:01:14PM -0200, Fabio Estevam wrote:
> On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>
> > too. It also looks like Versatile Express support _can't_ be disabled in
> > a multiplatform kernel, which is ludicrous.
>
> Should we go with this approach?
> https://patchwork.kernel.org/patch/1774521/
We need to go with an approach which isn't going to break allnoconfig
and randconfig.
I've suggested that we should have a basic, minimalist platform always
built in for DT supporting kernels. I've actually suggested that we
should end up not having a machine_desc at all once the DT conversion
is complete. Either of those solves the problem of us ending up with
no platform support built with these configurations.
The alternative is we end up with quite a long disgusting Kconfig
option which becomes enabled when everything but Versatile Express
is disabled...
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Arnd Bergmann @ 2013-01-31 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131153625.GB23505@n2100.arm.linux.org.uk>
On Thursday 31 January 2013 15:36:25 Russell King - ARM Linux wrote:
> The pci_sys_data is not specific to one bus. It's specific from the
> root bus downwards, and is shared by all child busses.
>
> The problem is if you have some card or a conventional P2P bridge which
> has 4K windows. If you merely set the alignment to 64K for all bridges,
> then all bridges get this treatment whether or not they need it. That's
> what I'm trying to avoid.
>
> Take, for instance, a cardbus bridge (remember, there are PCI cards which
> can be plugged in to give you a cardbus slot.) I have a device here which
> can be plugged into a cardbus slot which has not just one P2P bridge but
> two, and a bunch of downsteam devices, including VGA, ethernet, USB, PS/2
> etc. (Okay, Linux doesn't support this hardware because of crappy X86
> stuff, despite the fact Windows cope with it just fine.)
>
> There have been cards in the past which have had P2P bridges on them as
> well.
>
> So, simply believing that the only P2P bridges in the system will be
> those on the physical board is a mistake.
I was going to write something similar. Actually I think it's worse because
the case of an extra P2P bridge is quite likely for devices that actually
use I/O space, given that the use of I/O space is deprecated on PCIe.
This also means that a lot of devices using I/O space are legacy crap
and have random bugs regarding PCI standard compliance. I would not
expect those devices in general to do the right thing when I/O ports
beyond 65535 are used, although a lot of them would work.
For all I could tell, the safest solution with the I/O space would
be to pretend we had a shared 64K I/O space for all of the PCIe
ports on Armada XP, and map a separate 64K window for each port
using a different io_offset for each one.
This way, you can have a device on the second PCIe port use e.g. I/O
port number 0x3f8 for a legacy UART on the bus, which gets translated
into the Linux-visible port number 0x103f8.
The currently used method to have io_offset=0 for all PCIe ports
and use separate I/O port ranges of 64K for each PCIe port probably
still works for most devices, except those where we hardcode a port
number in the Linux device driver, or where the high address bits
don't get decoded properly.
Arnd
^ permalink raw reply
* [PATCH v2] ARM: omap4: clock data: Add missing clkdm association for dpll_usb
From: Paul Walmsley @ 2013-01-31 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359632112-9808-1-git-send-email-rnayak@ti.com>
On Thu, 31 Jan 2013, Rajendra Nayak wrote:
> dpll_usb needs the clkdm association so the clkdm can be
> turned on before a relock. All other dplls for omap4 belong
> to the ALWON (always on) domain.
>
> The association was present as part of the older data file
> (clock44xx_data.c) but looks like got accidently dropped with
> the common clk convertion.
>
> More details of the patch which fixed this up in the older
> data file can be dound here..
> http://www.spinics.net/lists/linux-omap/msg63076.html
>
> Adding the .clkdm_name as part of the clk_hw_omap struct also
> means a new .init needs to be part of the clk_ops for dpll_usb
> to initialise the clkdm.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Thanks, queued for v3.8-rc in place of v1.
- Paul
^ permalink raw reply
* [PATCH] ARM: omap4: clock data: Add missing clkdm association for dpll_usb
From: Paul Walmsley @ 2013-01-31 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A5908.30804@ti.com>
On Thu, 31 Jan 2013, Rajendra Nayak wrote:
> Hi Paul,
>
> > > dpll_usb needs the clkdm association so the clkdm can be
> > > turned on before a relock. All other dplls for omap4 belong
> > > to the ALWON (always on) domain.
> > >
> > > The association was present as part of the older data file
> > > (clock44xx_data.c) but looks like was accidently dropped with
> > > the common clk convertion.
> >
> > Thanks, queued for v3.8-rc fixes.
>
> I just realized that apart from adding the missing .clkdm_name, I
> also need to populate a .init as part of clk_ops for dpll_usb
> so the clockdomain lookup can then happen based on the .clkdm_name.
>
> I have updated the $Subject patch and posted a v2 (http://marc.info
> /?l=linux-omap&m=135963212530790&w=2). Would it be possible for you to
> pick the v2 instead and drop this one from your fixes branch.
No problem.
- Paul
^ permalink raw reply
* Failure to boot...
From: Russell King - ARM Linux @ 2013-01-31 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131160000.GW15361@atomide.com>
On Thu, Jan 31, 2013 at 08:00:02AM -0800, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130131 06:45]:
> > On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote:
> > >>>
> > >>># 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...
>
> Just trying to figure out what was the missing entry in case
> others have the same problem.
>
> In addition to the ones above, I had also CONFIG_ARCH_OMAP2PLUS=y
> listed in my comments. Did you also need something else added
> manually?
Interesting, that's the one which got missed. The ones which did get
updated on the 13th were just the noconfigs which were failing to build,
and not the two oldconfigs which are the booted ones. The noconfigs
already had OMAP2PLUS enabled in them which is probably how it got
lost.
^ permalink raw reply
* BogoMIPS change in 3.6+
From: Arnd Bergmann @ 2013-01-31 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A988F.6030508@gmail.com>
On Thursday 31 January 2013 10:15:11 Rob Herring wrote:
> The BogoMIPS value has changed on highbank since the commit below in
> 3.6. It is now half the value it used to be. Does that matter other than
> perception (I've checked that I'm not running at half the freq)?
I think the only danger is that your customers might think they
are running at half the clock rate. Nothing in the kernel should
be using the BogoMIPS value.
Arnd
^ permalink raw reply
* [PATCH] arm: mvebu: support for the new Armada XP evaluation board(DB-MV784MP-GP)
From: Andrew Lunn @ 2013-01-31 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A689B.6040407@free-electrons.com>
> Well in fact it is 4GB RAM but we can only use 3GB (we need the last GB
> of address space for peripheral, CPU registers and IOmem).
Hi Gregory
Does the CPU support Large Physical Addressing, LPA? Is that on the
roadmap for Armada?
Andrew
^ permalink raw reply
* BogoMIPS change in 3.6+
From: Will Deacon @ 2013-01-31 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A988F.6030508@gmail.com>
Hi Rob,
On Thu, Jan 31, 2013 at 04:15:11PM +0000, Rob Herring wrote:
> The BogoMIPS value has changed on highbank since the commit below in
> 3.6. It is now half the value it used to be. Does that matter other than
> perception (I've checked that I'm not running at half the freq)?
Are you registering a delay timer? If not, then the delay loop should be
identical to what it was before, so that's certainly a surprise...
Are your delays ballpark correct (try 2ms)?
Will
^ permalink raw reply
* BogoMIPS change in 3.6+
From: Santosh Shilimkar @ 2013-01-31 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A988F.6030508@gmail.com>
On Thursday 31 January 2013 09:45 PM, Rob Herring wrote:
> The BogoMIPS value has changed on highbank since the commit below in
> 3.6. It is now half the value it used to be. Does that matter other than
> perception (I've checked that I'm not running at half the freq)?
>
I also stumbled on this while testing Will's series.[1]
There should be no other functional issue apart from getting surprised.
Regards,
Santosh
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/109281.html
^ permalink raw reply
* BogoMIPS change in 3.6+
From: Will Deacon @ 2013-01-31 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A9AD8.8060003@ti.com>
On Thu, Jan 31, 2013 at 04:24:56PM +0000, Santosh Shilimkar wrote:
> On Thursday 31 January 2013 09:45 PM, Rob Herring wrote:
> > The BogoMIPS value has changed on highbank since the commit below in
> > 3.6. It is now half the value it used to be. Does that matter other than
> > perception (I've checked that I'm not running at half the freq)?
> >
> I also stumbled on this while testing Will's series.[1]
> There should be no other functional issue apart from getting surprised.
Right, but you were using the arch-timers w/ Cortex-A15. I thought Highbank
was A9?
Will
^ permalink raw reply
* [PATCH 3/4] ARM: OMAP2+: clock: DEFINE_STRUCT_CLK_FLAGS helper
From: Paul Walmsley @ 2013-01-31 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <abe7aceb564b97ab00b88b13a9aac487363e01c1.1358871018.git.afzal@ti.com>
On Tue, 22 Jan 2013, Afzal Mohammed wrote:
> DEFINE_STRUCT_CLK does not have the capability to set flags, define
> DEFINE_STRUCT_CLK_FLAGS to handle flags. This is needed to add
> SET_RATE_PARENT flag in statically defined lcd clock in am335x.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
Thanks, queued for 3.9.
- Paul
^ permalink raw reply
* [PATCH 4/4] ARM: AM33XX: clock: SET_RATE_PARENT in lcd path
From: Paul Walmsley @ 2013-01-31 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <24c9e4241b2988e66abd053508991d96cac964b7.1358871018.git.afzal@ti.com>
On Tue, 22 Jan 2013, Afzal Mohammed wrote:
> LCDC clock node is a one that does not have set rate capability. It
> just passes on the rate that is sent downstream by it's parent. While
> lcdc clock parent and it's grand parent - dpll_disp_m2_ck and
> dpll_disp_ck has the capability to configure rate.
>
> And the default rates provided by LCDC clock's ancestors are not
> sufficient to obtain pixel clock for current LCDC use cases, hence
> currently display would not work on AM335x SoC's (with driver
> modifications in platfrom independent way).
>
> Hence inform clock framework to propogate set rate for LCDC clock as
> well as it's parent - dpll_disp_m2_ck. With this change, set rate on
> LCDC clock would get propogated till dpll_disp_ck via dpll_disp_m2_ck,
> hence allowing the driver (same driver is used in DaVinci too) to set
> rates using LCDC clock without worrying about platform dependent clock
> details.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
This one doesn't apply for me on v3.8-rc5 + your patches 2 and 3. Could
you please update it and re-send?
- Paul
^ permalink raw reply
* Failure to boot...
From: Arnd Bergmann @ 2013-01-31 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131161823.GT2637@n2100.arm.linux.org.uk>
On Thursday 31 January 2013 16:18:23 Russell King - ARM Linux wrote:
> On Thu, Jan 31, 2013 at 02:01:14PM -0200, Fabio Estevam wrote:
> > On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >
> > > too. It also looks like Versatile Express support _can't_ be disabled in
> > > a multiplatform kernel, which is ludicrous.
> >
> > Should we go with this approach?
> > https://patchwork.kernel.org/patch/1774521/
>
> We need to go with an approach which isn't going to break allnoconfig
> and randconfig.
>
> I've suggested that we should have a basic, minimalist platform always
> built in for DT supporting kernels. I've actually suggested that we
> should end up not having a machine_desc at all once the DT conversion
> is complete. Either of those solves the problem of us ending up with
> no platform support built with these configurations.
Yes, I like the idea a lot. I think we should be pretty close to
being able to do that just now, with generic hooks to initialize
the interrupt controller and clocksouroce drivers.
> The alternative is we end up with quite a long disgusting Kconfig
> option which becomes enabled when everything but Versatile Express
> is disabled...
Yes, I've tried that in the past, it wasn't nice. It also gets
much more complex if you want to do it for all configurations instead
of just those that enable ARMv7.
Arnd
^ permalink raw reply
* [PATCH 4/4] ARM: AM33XX: clock: SET_RATE_PARENT in lcd path
From: Paul Walmsley @ 2013-01-31 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301311625290.32145@utopia.booyaka.com>
On Thu, 31 Jan 2013, Paul Walmsley wrote:
> This one doesn't apply for me on v3.8-rc5 + your patches 2 and 3. Could
> you please update it and re-send?
Oops, looks like I accidentally tried to apply the first version of this
patch rather than the second one. The second one applies cleanly, so it's
queued now for 3.9.
- Paul
^ permalink raw reply
* OMAP4 PM bootloader dependency problems
From: Santosh Shilimkar @ 2013-01-31 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301311537530.23099@utopia.booyaka.com>
On Thursday 31 January 2013 09:10 PM, Paul Walmsley wrote:
> Hi,
>
> On Thu, 31 Jan 2013, Rajendra Nayak wrote:
>
>> Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note
>> that it isn't enabled by default in omap2plus_defconfig. Also
>> throw one when a suspend fails, saying bootloader *could be* a possible
>> cause specifying the right version to be used.
>
> In my view, these steps aren't sufficient, for the reasons described in
>
> http://marc.info/?l=linux-omap&m=135964568904053&w=2
>
> Even with CONFIG_CPU_IDLE=n, it's still possible to attempt to enter
> full-chip retention idle on OMAP4 via 'echo mem > /sys/power/state', so it
> doesn't seem right to restrict a solution to that case.
>
I think rajendra also mentioned adding one in suspend path too
when it fails.
" Also throw one when a suspend fails, saying bootloader
*could be* a possible cause specifying the right version to be used."
I find Rajendra's suggestion reasonable because some one might
just miss the boot message but getting the message on failure
case cant' be missed.
Regards
Santosh
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Bjorn Helgaas @ 2013-01-31 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131170401.4b3bfbbf@skate>
On Thu, Jan 31, 2013 at 9:04 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Bjorn Helgaas,
>
> On Wed, 30 Jan 2013 11:52:15 -0700, Bjorn Helgaas wrote:
>
>> The secondary/subordinate registers effectively define a bus number
>> aperture that tells the bridge which transactions to claim and forward
>> downstream. When enumerating devices, we may update the subordinate
>> bus number to widen the aperture so we can enumerate an arbitrary tree
>> behind the bridge. When we're finished, we'll probably narrow it by
>> updating the subordinate again, so the unused bus number space can be
>> used for other bridges. I don't know the exact details of the
>> algorithm, and they're likely to change anyway, but pci_scan_bridge()
>> is where most of it happens.
>>
>> It looks like your current system doesn't support trees below the
>> bridges, but hopefully we can make it so the generic enumeration
>> algorithms still work.
>
> The PCI-to-PCI bridge specification says that the Primary Bus Number
> Register, Secondary Bus Number Register and Subordinate Bus Number
> Register of the PCI configuration space of a PCI-to-PCI bridge should
> all be set to 0 after reset.
>
> Until now, I was forcing a specific value of the Secondary Bus Number
> and Subordinate Bus Number (1 for my first bridge, 2 for my second
> bridge, etc.).
>
> Following you're recommendation, I've changed this, and left those
> values initialized to 0 by default, in order to let Linux set correct
> values. Yes, Linux does assign appropriate values in the Secondary Bus
> Number Register. But before that Linux also complains loudly that the
> bridge configuration is invalid:
>
> pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:00:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:00:04.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:00:05.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:00:06.0: bridge configuration invalid ([bus 00-00]), reconfiguring
Linux makes the unwarranted assumption that the PCI hierarchy has
already been configured by firmware. If the only problem is the
messages above, I think we could just rework the message so it doesn't
look like an error. I would guess that we probably also see the same
distressing message when we hot-add a card with a bridge on it,
because firmware won't have initialized the bridge.
My rule of thumb is that I like to note something in dmesg about the
initial configuration of bus/mem/io apertures and BARs, as well as
indications when we update them. That way, the dmesg log should
contain enough information to debug most enumeration and configuration
defects. pci_scan_bridge() is somewhat lacking in this regard.
Bjorn
^ permalink raw reply
* [PATCH 1/2] ARM: shmobile: sh73a0: Add CPU sleep suspend
From: Bastian Hecht @ 2013-01-31 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130042218.GK28230@verge.net.au>
Looks perfect, thanks!
2013/1/30 Simon Horman <horms@verge.net.au>:
> On Sat, Jan 12, 2013 at 04:43:29PM +0100, Bastian Hecht wrote:
>> Hi Guennadi, hi Simon,
>>
>> yes somehow a chunk is missing from my original patch in the patch of
>> the next branch that got merged from soc2. I've prepared a revert of
>> the bad patch and a corrected version, but now I'm unsure if that
>> helps at all. Finally you don't want to get that fixups pulled into
>> the mainline.
>>
>> It seems to me to be a real mess to correct some patch somewhere in
>> the middle of merged patch stacks. If I can help Simon, please let me
>> know.
>
> Could you see if the following is correct?
> If not could you please prepare whichever of the following makes sense.
>
> * An incremental patch to add the missing hunk
>
> * A revert patch and a new patch
>
> * A revert patch
>
> http://git.kernel.org/?p=linux/kernel/git/horms/renesas.git;a=commitdiff;h=13baf88bd69ed3cf7e2374eec4a7128f62ae9c1f
>
>
> From 13baf88bd69ed3cf7e2374eec4a7128f62ae9c1f Mon Sep 17 00:00:00 2001
> From: Bastian Hecht <hechtb@gmail.com>
> Date: Wed, 5 Dec 2012 12:13:06 +0000
> Subject: [PATCH] ARM: shmobile: sh73a0: Add CPU sleep suspend
>
> Add the lighest possible sleep mode on Cortex-A9 cores: CPU sleep. It is
> entered by a simple dsb and wfi instruction via cpu_do_idle(). As just
> clocks are stopped there is no need to save or restore any state of the
> system.
>
> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
> Acked-by: Magnus Damm <damm@opensource.se>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> arch/arm/mach-shmobile/Makefile | 1 +
> arch/arm/mach-shmobile/board-kzm9g.c | 2 ++
> arch/arm/mach-shmobile/include/mach/common.h | 1 +
> arch/arm/mach-shmobile/pm-sh73a0.c | 32 ++++++++++++++++++++++++++
> 4 files changed, 36 insertions(+)
> create mode 100644 arch/arm/mach-shmobile/pm-sh73a0.c
>
> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
> index 0b71479..f6aba6d 100644
> --- a/arch/arm/mach-shmobile/Makefile
> +++ b/arch/arm/mach-shmobile/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_ARCH_SHMOBILE) += pm-rmobile.o
> obj-$(CONFIG_ARCH_SH7372) += pm-sh7372.o sleep-sh7372.o
> obj-$(CONFIG_ARCH_R8A7740) += pm-r8a7740.o
> obj-$(CONFIG_ARCH_R8A7779) += pm-r8a7779.o
> +obj-$(CONFIG_ARCH_SH73A0) += pm-sh73a0.o
>
> # Board objects
> obj-$(CONFIG_MACH_AP4EVB) += board-ap4evb.o
> diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board-kzm9g.c
> index ac94285..363c6ed 100644
> --- a/arch/arm/mach-shmobile/board-kzm9g.c
> +++ b/arch/arm/mach-shmobile/board-kzm9g.c
> @@ -772,6 +772,8 @@ static void __init kzm_init(void)
>
> sh73a0_add_standard_devices();
> platform_add_devices(kzm_devices, ARRAY_SIZE(kzm_devices));
> +
> + sh73a0_pm_init();
> }
>
> static void kzm9g_restart(char mode, const char *cmd)
> diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
> index 2d1686b..f221c11 100644
> --- a/arch/arm/mach-shmobile/include/mach/common.h
> +++ b/arch/arm/mach-shmobile/include/mach/common.h
> @@ -40,6 +40,7 @@ extern void sh73a0_add_early_devices(void);
> extern void sh73a0_add_standard_devices(void);
> extern void sh73a0_clock_init(void);
> extern void sh73a0_pinmux_init(void);
> +extern void sh73a0_pm_init(void);
> extern struct clk sh73a0_extal1_clk;
> extern struct clk sh73a0_extal2_clk;
> extern struct clk sh73a0_extcki_clk;
> diff --git a/arch/arm/mach-shmobile/pm-sh73a0.c b/arch/arm/mach-shmobile/pm-sh73a0.c
> new file mode 100644
> index 0000000..99086e9
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/pm-sh73a0.c
> @@ -0,0 +1,32 @@
> +/*
> + * sh73a0 Power management support
> + *
> + * Copyright (C) 2012 Bastian Hecht <hechtb+renesas@gmail.com>
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License. See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */
> +
> +#include <linux/suspend.h>
> +#include <mach/common.h>
> +
> +#ifdef CONFIG_SUSPEND
> +static int sh73a0_enter_suspend(suspend_state_t suspend_state)
> +{
> + cpu_do_idle();
> + return 0;
> +}
> +
> +static void sh73a0_suspend_init(void)
> +{
> + shmobile_suspend_ops.enter = sh73a0_enter_suspend;
> +}
> +#else
> +static void sh73a0_suspend_init(void) {}
> +#endif
> +
> +void __init sh73a0_pm_init(void)
> +{
> + sh73a0_suspend_init();
> +}
> --
> 1.7.10.4
>
^ permalink raw reply
* BogoMIPS change in 3.6+
From: Santosh Shilimkar @ 2013-01-31 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131162523.GE835@mudshark.cambridge.arm.com>
On Thursday 31 January 2013 09:55 PM, Will Deacon wrote:
> On Thu, Jan 31, 2013 at 04:24:56PM +0000, Santosh Shilimkar wrote:
>> On Thursday 31 January 2013 09:45 PM, Rob Herring wrote:
>>> The BogoMIPS value has changed on highbank since the commit below in
>>> 3.6. It is now half the value it used to be. Does that matter other than
>>> perception (I've checked that I'm not running at half the freq)?
>>>
>> I also stumbled on this while testing Will's series.[1]
>> There should be no other functional issue apart from getting surprised.
>
> Right, but you were using the arch-timers w/ Cortex-A15. I thought Highbank
> was A9?
>
Ahh.. Sorry looking at description I just thought it could be the same
issue.
Regards,
Santosh
^ permalink raw reply
* OMAP4 PM bootloader dependency problems
From: Paul Walmsley @ 2013-01-31 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A9BFB.5070802@ti.com>
Hi,
On Thu, 31 Jan 2013, Santosh Shilimkar wrote:
> On Thursday 31 January 2013 09:10 PM, Paul Walmsley wrote:
> > On Thu, 31 Jan 2013, Rajendra Nayak wrote:
> >
> > > Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note
> > > that it isn't enabled by default in omap2plus_defconfig. Also
> > > throw one when a suspend fails, saying bootloader *could be* a possible
> > > cause specifying the right version to be used.
> >
> > In my view, these steps aren't sufficient, for the reasons described in
> >
> > http://marc.info/?l=linux-omap&m=135964568904053&w=2
> >
> > Even with CONFIG_CPU_IDLE=n, it's still possible to attempt to enter
> > full-chip retention idle on OMAP4 via 'echo mem > /sys/power/state', so it
> > doesn't seem right to restrict a solution to that case.
> >
>
> I think rajendra also mentioned adding one in suspend path too
> when it fails.
> " Also throw one when a suspend fails, saying bootloader
> *could be* a possible cause specifying the right version to be used."
>
> I find Rajendra's suggestion reasonable because some one might
> just miss the boot message but getting the message on failure
> case cant' be missed.
Right. I don't have any problem with adding a message to the suspend path
also. But I'd like to see a boot-time message added even if
CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention
idle with dynamic idle. In other words, not everyone might use 'echo mem
> /sys/power/state'.
- Paul
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-31 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo7fPzrF_OZSL7Ss0LT70Qz+veXLW-ihA7fAXCwsn142cQ@mail.gmail.com>
Dear Bjorn Helgaas,
On Thu, 31 Jan 2013 09:30:07 -0700, Bjorn Helgaas wrote:
> > Following you're recommendation, I've changed this, and left those
> > values initialized to 0 by default, in order to let Linux set correct
> > values. Yes, Linux does assign appropriate values in the Secondary Bus
> > Number Register. But before that Linux also complains loudly that the
> > bridge configuration is invalid:
> >
> > pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> > pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> > pci 0000:00:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> > pci 0000:00:04.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> > pci 0000:00:05.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> > pci 0000:00:06.0: bridge configuration invalid ([bus 00-00]), reconfiguring
>
> Linux makes the unwarranted assumption that the PCI hierarchy has
> already been configured by firmware. If the only problem is the
> messages above, I think we could just rework the message so it doesn't
> look like an error. I would guess that we probably also see the same
> distressing message when we hot-add a card with a bridge on it,
> because firmware won't have initialized the bridge.
>
> My rule of thumb is that I like to note something in dmesg about the
> initial configuration of bus/mem/io apertures and BARs, as well as
> indications when we update them. That way, the dmesg log should
> contain enough information to debug most enumeration and configuration
> defects. pci_scan_bridge() is somewhat lacking in this regard.
Ok. Would something like:
"bridge configuration with unassigned bus numbers ([bus 00-00]), reconfiguring"
be an acceptable to replace this one?
Thanks for your quick feedback,
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 2/4] drm/i2c: nxp-tda998x (v3)
From: Russell King - ARM Linux @ 2013-01-31 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGsYzyefOpeHnsRh-YczVfaTh2d5AtoTFfT7AEWuukJZUA@mail.gmail.com>
On Thu, Jan 31, 2013 at 08:23:53AM -0600, Rob Clark wrote:
> On Wed, Jan 30, 2013 at 8:23 PM, Sebastian Hesselbarth
> <sebastian.hesselbarth@gmail.com> wrote:
> > On 01/29/2013 06:23 PM, Rob Clark wrote:
> >>
> >> Driver for the NXP TDA998X i2c hdmi encoder slave.
> >
> >
> > Rob,
> >
> > good to see a driver for TDA998x comming! I'd love to test
> > it on CuBox (mach-dove) but there is no gpu driver I can hook up,
> > yet. Anyway, I will make some comments how I think the driver
> > should be improved.
I will eventually pick this up and give it a whirl with my cubox DRM
stuff. I've yet to receive my round tuit.
^ permalink raw reply
* [PATCH] arm: mvebu: support for the new Armada XP evaluation board(DB-MV784MP-GP)
From: Andrew Lunn @ 2013-01-31 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131162254.GD20242@lunn.ch>
On Thu, Jan 31, 2013 at 05:22:54PM +0100, Andrew Lunn wrote:
> > Well in fact it is 4GB RAM but we can only use 3GB (we need the last GB
> > of address space for peripheral, CPU registers and IOmem).
>
> Hi Gregory
>
> Does the CPU support Large Physical Addressing, LPA? Is that on the
> roadmap for Armada?
I did a bit of googling:
http://www.linleygroup.com/newsletters/newsletter_detail.php?num=3982
To address the cloud-computing market, the company added
40-bit physical addressing to Armada XP, using a method
similar to what ARM implemented in Cortex-A15. This feature
allows the memory controller to support up to one terabyte
(1TB) of DRAM.
Also:
http://www.theregister.co.uk/2012/10/24/dell_zinc_arm_server_apache_software/
talks about 40-bit.
So it should be possible to use the full 4GBytes of RAM, in theory.
Andrew
^ 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