* [PATCH v2] ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
From: Arnd Bergmann @ 2016-11-18 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479453418-25314-1-git-send-email-krzk@kernel.org>
On Friday, November 18, 2016 9:16:58 AM CET Krzysztof Kozlowski wrote:
> All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
> 200 Hz. Unfortunately in case of multiplatform image this affects also
> other platforms when Exynos is enabled.
>
> This looks like an very old legacy code, dating back to initial
> upstreaming of S3C24xx. Probably it was required for s3c24xx timer
> driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
> unused plat-samsung/time.c").
>
> Since then, this fixed 200 Hz spread everywhere, including out-of-tree
> Samsung kernels (SoC vendor's and Tizen's). I believe this choice
> was rather an effect of coincidence instead of conscious choice.
>
> Exynos uses its own MCT or arch timer and can work with all HZ values.
> Older platforms use newer Samsung PWM timer driver which should handle
> down to 100 Hz.
>
> Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
> A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
> other values.
>
> Reported-by: Lee Jones <lee.jones@linaro.org>
> [Dropping 200_HZ from S3C/S5P suggested by Arnd]
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Maybe add a paragraph about the specific problem:
"On s3c24xx, the PWM counter is only 16 bit wide, and with the
typical 12MHz input clock that overflows every 5.5ms. This works
with HZ=200 or higher but not with HZ=100 which needs a 10ms
interval between ticks. On Later chips (S3C64xx, S5P and EXYNOS),
the counter is 32 bits and does not have this problem.
The new samsung_pwm_timer driver solves the problem by scaling
the input clock by a factor of 50 on s3c24xx, which makes it
less accurate but allows HZ=100 as well as CONFIG_NO_HZ with
fewer wakeups".
Arnd
^ permalink raw reply
* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Thomas Petazzoni @ 2016-11-18 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117230830.31047-10-gregory.clement@free-electrons.com>
Hello,
On Fri, 18 Nov 2016 00:08:26 +0100, Gregory CLEMENT wrote:
> - soc {
> + /* The following unit address is composed of the target
> + * value (bit [40-47]), attributes value (bits [32-39],
> + * and the address value in the window memory: [0-31].
> + */
> + soc at f00100000000 {
Where is this value coming from? Why does the soc node needs to have a
unit address? It doesn't have a 'reg' property if I remember correctly.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
From: Thomas Petazzoni @ 2016-11-18 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117230830.31047-7-gregory.clement@free-electrons.com>
Hello,
On Fri, 18 Nov 2016 00:08:23 +0100, Gregory CLEMENT wrote:
> - crypto_sram0: sa-sram0 {
> + /* The following unit addresses (for sa-sram) are composed of
> + * the target value (bit [40-47]), attributes value (bits
> + * [32-39], and the address value in the window memory: [0-31].
> + */
The "address value in the window memory" part doesn't make a lot of
sense. Maybe:
"The following unit addresses are composed of the window target ID
(bits 40-47), the window target attributes (bits 32-39) and the offset
inside the window."
Also, the comment formatting is not compliant with the coding style,
should be:
/*
* ...
* ...
*/
But do we really want this comment above each node? Couldn't we instead
add this explanation in the mvebu-mbus.txt DT binding?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Gregory CLEMENT @ 2016-11-18 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118095455.00bfe007@free-electrons.com>
Hi Thomas,
On ven., nov. 18 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 18 Nov 2016 00:08:26 +0100, Gregory CLEMENT wrote:
>
>> - soc {
>> + /* The following unit address is composed of the target
>> + * value (bit [40-47]), attributes value (bits [32-39],
>> + * and the address value in the window memory: [0-31].
>> + */
>> + soc at f00100000000 {
>
> Where is this value coming from? Why does the soc node needs to have a
It cames from the dts files.
> unit address? It doesn't have a 'reg' property if I remember
> correctly.
But it has a range property.
Gregory
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Thomas Petazzoni @ 2016-11-18 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d1htb1qr.fsf@free-electrons.com>
Hello,
On Fri, 18 Nov 2016 10:01:32 +0100, Gregory CLEMENT wrote:
> >> + soc at f00100000000 {
> >
> > Where is this value coming from? Why does the soc node needs to have a
>
> It cames from the dts files.
Where?
> > unit address? It doesn't have a 'reg' property if I remember
> > correctly.
>
> But it has a range property.
And? There are multiple ranges, and you randomly took the first one for
the unit address of the soc node?
You realize that the ranges property is a list of ranges, and they
could be in any order? Why would you pick the base address of one of
the ranges rather than any of the others?
I believe there is simply no unit address for the soc {} node. There is
definitely one for the internal-regs {} node, but not for the soc {}
node.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins
From: Linus Walleij @ 2016-11-18 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ea02ec937a12d6ca2a2e0d8bbea5c484@theobroma-systems.com>
[Notice this reply has little to do with the patch in question: I think
it should be applied. I just want to involve some MMC/SD people here]
On Thu, Nov 17, 2016 at 9:57 PM, <klaus.goger@theobroma-systems.com> wrote:
> On 2016-11-17 10:34, Chen-Yu Tsai wrote:
>>
>> Given that MMC starts in open-drain mode and the pull-ups are required,
>> it's best to enable it for all the pin settings.
>
> It's even more complicated than that with MMC. It starts in open-drain mode
> for
> CMD during initialization but changes to push-pull afterwards. The card has
> internal pull-ups to prevent bus floating during setup and will disable them
> after switching to 4bit mode (or 8bit for eMMC when available).
> But even after switching to push-pull drivers there are states the bus would
> float and pull ups have to ensure a high level on the bus.
>
> See JESD84-A441 chapter 7.15 ff as reference.
>
> The difference between the P-bit and Z-bit is that a P-bit is actively
> driven
> to HIGH by the card respectively host output driver, while Z-bit is driven
> to
> (respectively kept) HIGH by the pull-up resistors Rcmd respectively Rdat.
>
> Enabling the pull ups on the CPU would be the right choice considering that
> most boards will not have external pull-ups. Even if they would have one,
> adding the internal in parallel would work in almost all cases and the
> increase in power consumption would be negligible.
I guess you are referring to software-controlled pull up on the pad ring of
the SoC. Nominally that should be handled by pin control like in this
patch.
It is not clear from context to me which of the lines need to be handled
like this? Just the data lines? DAT0 would be the critical line to pull up
in that case, since the others will not be used until bus switch anyways
right?
But what about CMD?
I assume CLK should always be push-pull?
Also: if the pins have an explicit Open Drain setting, should that
be used? I guess so?
Overall I think this construction is pretty common.
We essentially have two classes of connections:
- Those connecting the eMMC or even MMC/SD card directly to
the SoC. No pull-ups on the board. Here it makes sense to have:
1. A pin control default state with open drain and pull-ups
enabled for those lines
and it then needs
2. A second "4/8bit mode" that will switch these
pins to push-pull mode and turn off the pull-ups.
If the OD+pull-up state is the default we should probably
standardize a default name for the state when we kick in 4/8bit
mode from the IOS operation.
- Those connection the MMC/SD on an external slot through a
levelshifter/EMI filter. In that case I guess it is pretty much
dependent on the levelshifter or EMI thing how the lines out
of the SoC should be configured, and usually it is static so
you do not need to worry about it after boot configuration
of pins. (Mostly no bias, push-pull I think.)
I highly suspect a whole bunch of SoC drivers are not getting
this business right today. Not even in out-of-tree vendor kernels.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Arnd Bergmann @ 2016-11-18 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5825984B.3030303@hisilicon.com>
On Friday, November 11, 2016 6:07:07 PM CET zhichang.yuan wrote:
>
> I have similar idea as your PPC MMIO.
>
> We notice the prototype of {in/out()} is something like that:
>
> static inline u8 inb(unsigned long addr)
> static inline void outb(u8 value, unsigned long addr)
>
> The type of parameter 'addr' is unsigned long. For I/O space, it is big enough.
> So, could you divide this 'addr' into several bit segments? The top 8 bits is
> defined as bus index. For normal direct IO, the bus index is 0. For those bus
> device which need indirectIO or some special I/O accessors, when these devices
> are initializing, can request to allocate an unique ID to them, and register
> their own accessors to the entry which is corresponding to the ID.
Ah, have you looked at the IA64 code? It does exactly this.
For ARM64 we decided to use the same basic approach as powerpc with
a single range of virtual memory for mapping it as that somewhat
simplified all cases we knew about at the time.
> In this way, we can support multiple domains, I think.
> But I am not sure whether it is feasible, for example, are there some
> architectures/platforms had populated the top 8 bits? Do we need to request IO
> region from ioport_resource for those devices? etc...
On a 64-bit architecture, the top 32 bits of the port number are
definitely free to use for this, and 8 bits are probably sufficient.
Even on 32 bit architectures, I can't see why we'd ever need more than
16 bits worth of addressing within a domain, so using 8 bit domain
and 16 bit address leaves 8 or 40 unused bits.
Arnd
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Arnd Bergmann @ 2016-11-18 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114111111.1b753dc3@lxorguk.ukuu.org.uk>
On Monday, November 14, 2016 11:11:11 AM CET One Thousand Gnomes wrote:
> > > It's not a safe assumption for x86 at least. There are a few systems with
> > > multiple ISA busses particularly older laptops with a docking station.
> >
> > But do they have multiple ISA domains? There is no real harm in supporting
> > it, the (small) downsides I can think of are:
>
> I don't believe they x86 class ones have multiple ISA domains. But as
> I've said I don't know how the electronics in the older ThinkPad worked
> when it used two PIIX4s with some LPC or ISA stuff on each.
>
> It works in DOS and unmodified Linux so I'm pretty sure there are no
> additional domains. Likewise the various x86 schemes that route some bits
> of ISA bus off into strange places work in DOS and don't have any
> overlaps.
>
> yenta_socket handles PCI/PCMCIA bridging and routes a range of that flat
> ISA space appropriately to the card.
Right, that's what I had expected, so we still don't even
need to handle multiple ISA I/O address spaces for the
only known case of multiple ISA buses, though we may decide
to generalize the code like that anyway.
Arnd
^ permalink raw reply
* System/uncore PMUs and unit aggregation
From: Peter Zijlstra @ 2016-11-18 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117181708.GT22855@arm.com>
On Thu, Nov 17, 2016 at 06:17:08PM +0000, Will Deacon wrote:
> Hi all,
>
> We currently have support for three arm64 system PMUs in flight:
>
> [Cavium ThunderX] http://lkml.kernel.org/r/cover.1477741719.git.jglauber at cavium.com
> [Hisilicon Hip0x] http://lkml.kernel.org/r/1478151727-20250-1-git-send-email-anurup.m at huawei.com
> [Qualcomm L2] http://lkml.kernel.org/r/1477687813-11412-1-git-send-email-nleeder at codeaurora.org
>
> Each of which have to deal with multiple underlying hardware units in one
> way or another. Mark and I recently expressed a desire to expose these
> units to userspace as individual PMU instances, since this can allow:
>
> * Fine-grained control of events from userspace, when you want to see
> individual numbers as opposed to a summed total
>
> * Potentially ease migration to new SoC revisions, where the units
> are laid out slightly differently
>
> * Easier handling of cases where the units aren't quite identical
This is I think similar to the Intel Uncore situation. We expose every
single individual PMU independently. The Intel uncore is wide and varied
between parts.
Leaving the rest for Kan, who's doing the Intel uncore bits.
~ Peter
> however, this received pushback from all of the patch authors, so there's
> clearly a problem with this approach. I'm hoping we can try to resolve
> this here.
>
> Speaking to Mark earlier today, we came up with the following rough rules
> for drivers that present multiple hardware units as a single PMU:
>
> 1. If the units share some part of the programming interface (e.g. control
> registers or interrupts), then they must be handled by the same PMU.
> Otherwise, they should be treated independently as separate PMU
> instances.
>
> 2. If the units are handled by the same PMU, then care must be taken to
> handle event groups correctly. That is, if the units cannot be started
> and stopped atomically, cross-unit groups must be rejected by the
> driver. Furthermore, any cross-unit scheduling constraints must be
> honoured so that all the units targetted by a group can schedule the
> group concurrently.
>
> 3. Summing the counters across units is only permitted if the units
> can all be started and stopped atomically. Otherwise, the counters
> should be exposed individually. It's up to the driver author to
> decide what makes sense to sum.
>
> 4. Unit topology can optionally be described in sysfs (we should pick
> some standard directory naming here), and then events targetting
> specific units can have the unit identifier extracted from the topology
> encoded in some configN fields.
>
> The million dollar question is: how does that fit in with the drivers I
> mentioned at the top? Is this overly restrictive, or have we missed stuff?
>
> We certainly want to allow flexibility in the way in which the drivers
> talk to the hardware, but given that these decisions directly affect the
> user ABI, some consistent ground rules are required.
>
> For Cavium ThunderX, it's not clear whether or not the individual units
> could be expressed as separate PMUs, or whether they're caught by one of
> the rules above. The Qualcomm L2 looks like it's doing the right thing
> and we can't quite work out what the Hisilicon Hip0x topology looks like,
> since the interaction with djtag is confusing.
>
> If the driver authors (on To:) could shed some light on this, then that
> would be much appreciated!
>
> Thanks,
>
> Will
^ permalink raw reply
* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Gregory CLEMENT @ 2016-11-18 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118101248.784eff2b@free-electrons.com>
Hi Thomas,
On ven., nov. 18 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 18 Nov 2016 10:01:32 +0100, Gregory CLEMENT wrote:
>
>> >> + soc at f00100000000 {
>> >
>> > Where is this value coming from? Why does the soc node needs to have a
>>
>> It cames from the dts files.
>
> Where?
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -63,7 +63,11 @@
reg = <0x00000000 0x40000000>; /* 1 GB */
};
- soc {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ soc at f00100000000 {
ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
just here ---------^
MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
>
>> > unit address? It doesn't have a 'reg' property if I remember
>> > correctly.
>>
>> But it has a range property.
>
> And? There are multiple ranges, and you randomly took the first one for
> the unit address of the soc node?
Not randomly I followed the same rules that for the regs mentioned in
the ePAPR paragraph 2.2.1.1:
"The unit-address should match the first address specified in the reg
property of the node."
>
> You realize that the ranges property is a list of ranges, and they
> could be in any order? Why would you pick the base address of one of
> the ranges rather than any of the others?
It is the same for the regs so as explained I followed the same rules.
>
> I believe there is simply no unit address for the soc {} node. There is
> definitely one for the internal-regs {} node, but not for the soc {}
> node.
It is not the interpretation of the DTC:
"Warning (unit_address_vs_reg): Node /soc has a reg or ranges property,
but no unit name"
Gregory
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PULL] KVM/ARM updates for 4.9-rc6
From: Marc Zyngier @ 2016-11-18 9:39 UTC (permalink / raw)
To: linux-arm-kernel
Paolo, Radim,
Please find below the pull request for a couple of fixes for the
PMU emulation, courtesy of Wei. Both patches are candidates for stable.
Thanks,
M.
The following changes since commit d42c79701a3ee5c38fbbc82f98a140420bd40134:
KVM: arm/arm64: vgic: Kick VCPUs when queueing already pending IRQs (2016-11-04 17:56:56 +0000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-4.9-rc6
for you to fetch changes up to b112c84a6ff035271d41d548c10215f18443d6a6:
KVM: arm64: Fix the issues when guest PMCCFILTR is configured (2016-11-18 09:06:58 +0000)
----------------------------------------------------------------
KVM/ARM updates for v4.9-rc6
- Fix handling of the 32bit cycle counter
- Fix cycle counter filtering
----------------------------------------------------------------
Wei Huang (2):
arm64: KVM: pmu: Fix AArch32 cycle counter access
KVM: arm64: Fix the issues when guest PMCCFILTR is configured
arch/arm64/include/asm/perf_event.h | 10 +++++++++-
arch/arm64/kernel/perf_event.c | 10 +---------
arch/arm64/kvm/sys_regs.c | 10 ++++++++--
virt/kvm/arm/pmu.c | 8 +++++---
4 files changed, 23 insertions(+), 15 deletions(-)
^ permalink raw reply
* [PATCH 1/2] arm64: KVM: pmu: Fix AArch32 cycle counter access
From: Marc Zyngier @ 2016-11-18 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479461966-20136-1-git-send-email-marc.zyngier@arm.com>
From: Wei Huang <wei@redhat.com>
We're missing the handling code for the cycle counter accessed
from a 32bit guest, leading to unexpected results.
Cc: stable at vger.kernel.org # 4.6+
Signed-off-by: Wei Huang <wei@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kvm/sys_regs.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f302fdb..87e7e66 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -597,8 +597,14 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
idx = ARMV8_PMU_CYCLE_IDX;
} else {
- BUG();
+ return false;
}
+ } else if (r->CRn == 0 && r->CRm == 9) {
+ /* PMCCNTR */
+ if (pmu_access_event_counter_el0_disabled(vcpu))
+ return false;
+
+ idx = ARMV8_PMU_CYCLE_IDX;
} else if (r->CRn == 14 && (r->CRm & 12) == 8) {
/* PMEVCNTRn_EL0 */
if (pmu_access_event_counter_el0_disabled(vcpu))
@@ -606,7 +612,7 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
} else {
- BUG();
+ return false;
}
if (!pmu_counter_idx_valid(vcpu, idx))
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] KVM: arm64: Fix the issues when guest PMCCFILTR is configured
From: Marc Zyngier @ 2016-11-18 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479461966-20136-1-git-send-email-marc.zyngier@arm.com>
From: Wei Huang <wei@redhat.com>
KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.
But this function can't deals with PMCCFILTR correctly because the evtCount
bits of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event
type of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, this
function shouldn't return immediately; instead it needs to check further
if select_idx is ARMV8_PMU_CYCLE_IDX.
Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER
blindly to attr.config. Instead it ought to convert the request to the
"cpu cycle" event type (i.e. 0x11).
To support this patch and to prevent duplicated definitions, a limited
set of ARMv8 perf event types were relocated from perf_event.c to
asm/perf_event.h.
Cc: stable at vger.kernel.org # 4.6+
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Wei Huang <wei@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/perf_event.h | 10 +++++++++-
arch/arm64/kernel/perf_event.c | 10 +---------
virt/kvm/arm/pmu.c | 8 +++++---
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index 2065f46..38b6a2b 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -46,7 +46,15 @@
#define ARMV8_PMU_EVTYPE_MASK 0xc800ffff /* Mask for writable bits */
#define ARMV8_PMU_EVTYPE_EVENT 0xffff /* Mask for EVENT bits */
-#define ARMV8_PMU_EVTYPE_EVENT_SW_INCR 0 /* Software increment event */
+/*
+ * PMUv3 event types: required events
+ */
+#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
+#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
+#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
+#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
+#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
+#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
/*
* Event filters for PMUv3
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index a9310a6..57ae9d9 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -31,17 +31,9 @@
/*
* ARMv8 PMUv3 Performance Events handling code.
- * Common event types.
+ * Common event types (some are defined in asm/perf_event.h).
*/
-/* Required events. */
-#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
-#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
-#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
-#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
-#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
-#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
-
/* At least one of the following is required. */
#define ARMV8_PMUV3_PERFCTR_INST_RETIRED 0x08
#define ARMV8_PMUV3_PERFCTR_INST_SPEC 0x1B
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 6e9c40e..69ccce3 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -305,7 +305,7 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
continue;
type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
& ARMV8_PMU_EVTYPE_EVENT;
- if ((type == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+ if ((type == ARMV8_PMUV3_PERFCTR_SW_INCR)
&& (enable & BIT(i))) {
reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
reg = lower_32_bits(reg);
@@ -379,7 +379,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
eventsel = data & ARMV8_PMU_EVTYPE_EVENT;
/* Software increment event does't need to be backed by a perf event */
- if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+ if (eventsel == ARMV8_PMUV3_PERFCTR_SW_INCR &&
+ select_idx != ARMV8_PMU_CYCLE_IDX)
return;
memset(&attr, 0, sizeof(struct perf_event_attr));
@@ -391,7 +392,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
attr.exclude_kernel = data & ARMV8_PMU_EXCLUDE_EL1 ? 1 : 0;
attr.exclude_hv = 1; /* Don't count EL2 events */
attr.exclude_host = 1; /* Don't count host events */
- attr.config = eventsel;
+ attr.config = (select_idx == ARMV8_PMU_CYCLE_IDX) ?
+ ARMV8_PMUV3_PERFCTR_CPU_CYCLES : eventsel;
counter = kvm_pmu_get_counter_value(vcpu, select_idx);
/* The initial sample period (overflow count) of an event. */
--
2.1.4
^ permalink raw reply related
* [PATCH v2] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Rameshwar Prasad Sahu @ 2016-11-18 9:45 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables NCQ support for APM X-Gene SATA controller hardware v1.1
that was broken with hardware v1.0. Second thing, here we should not assume
XGENE_AHCI_V2 always in case of having valid _CID in ACPI table. I need to
remove this assumption because V1_1 also has a valid _CID for backward
compatibly with v1.
v2 changes:
1. Changed patch description
Signed-off-by: Rameshwar Prasad Sahu <rsahu@apm.com>
---
drivers/ata/ahci_xgene.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 73b19b2..8b88be9 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -87,6 +87,7 @@
enum xgene_ahci_version {
XGENE_AHCI_V1 = 1,
+ XGENE_AHCI_V1_1,
XGENE_AHCI_V2,
};
@@ -734,6 +735,7 @@ static struct scsi_host_template ahci_platform_sht = {
#ifdef CONFIG_ACPI
static const struct acpi_device_id xgene_ahci_acpi_match[] = {
{ "APMC0D0D", XGENE_AHCI_V1},
+ { "APMC0D67", XGENE_AHCI_V1_1},
{ "APMC0D32", XGENE_AHCI_V2},
{},
};
@@ -742,6 +744,7 @@ MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
static const struct of_device_id xgene_ahci_of_match[] = {
{.compatible = "apm,xgene-ahci", .data = (void *) XGENE_AHCI_V1},
+ {.compatible = "apm,xgene-ahci-v1-1", .data = (void *) XGENE_AHCI_V1_1},
{.compatible = "apm,xgene-ahci-v2", .data = (void *) XGENE_AHCI_V2},
{},
};
@@ -755,8 +758,7 @@ static int xgene_ahci_probe(struct platform_device *pdev)
struct resource *res;
const struct of_device_id *of_devid;
enum xgene_ahci_version version = XGENE_AHCI_V1;
- const struct ata_port_info *ppi[] = { &xgene_ahci_v1_port_info,
- &xgene_ahci_v2_port_info };
+ const struct ata_port_info *ppi;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
dev_warn(&pdev->dev, "%s: Error reading device info. Assume version1\n",
__func__);
version = XGENE_AHCI_V1;
- } else if (info->valid & ACPI_VALID_CID) {
- version = XGENE_AHCI_V2;
}
}
}
@@ -858,18 +858,20 @@ skip_clk_phy:
switch (version) {
case XGENE_AHCI_V1:
+ ppi = &xgene_ahci_v1_port_info;
hpriv->flags = AHCI_HFLAG_NO_NCQ;
break;
case XGENE_AHCI_V2:
+ ppi = &xgene_ahci_v2_port_info;
hpriv->flags |= AHCI_HFLAG_YES_FBS;
hpriv->irq_handler = xgene_ahci_irq_intr;
break;
default:
+ ppi = &xgene_ahci_v1_port_info;
break;
}
- rc = ahci_platform_init_host(pdev, hpriv, ppi[version - 1],
- &ahci_platform_sht);
+ rc = ahci_platform_init_host(pdev, hpriv, ppi, &ahci_platform_sht);
if (rc)
goto disable_resources;
--
1.7.1
^ permalink raw reply related
* Potential deadlock BUG in Linux 4.9 drivers/dma/coh901318.c
From: Iago Abal @ 2016-11-18 9:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
With the help of a static bug finder (EBA -
https://github.com/models-team/eba) I have found a potential deadlock
in drivers/dma/coh901318.c. This happens due to a recursive
spin_lock_irqsave on `cohc->lock'.
This bug may have been introduced by commit 84c8447c544b ("DMAENGINE:
COH 901 318 fix bytesleft").
The fix seems easy, I would personally just remove the calls to
spin_(un)lock_irqsave in lines 1805 and 1826. Function
`coh901318_config' is only called by `coh901318_alloc_chan_resources'
which already holds that lock when calling it.
If someone can confirm that all the above is correct, I will be happy
to submit a patch.
The trace is as follows:
1. Function `coh901318_alloc_chan_resources' takes the lock first in line 2165:
// see https://github.com/torvalds/linux/blob/master/drivers/dma/coh901318.c#L2165
spin_lock_irqsave(&cohc->lock, flags);
2. Immediately after it calls `coh901318_config' passing the `cohc'
struct to it.
3. The first thing `coh901318_config' does is to take the same
spinlock in line 1805:
// see https://github.com/torvalds/linux/blob/master/drivers/dma/coh901318.c#L1805
spin_lock_irqsave(&cohc->lock, flags);
Hope it helps!
-- iago
^ permalink raw reply
* [PATCH] [media] VPU: mediatek: fix dereference of pdev before checking it is null
From: Matthias Brugger @ 2016-11-18 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116191650.11486-1-colin.king@canonical.com>
On 16/11/16 20:16, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> pdev is dereferenced using platform_get_drvdata before a check to
> see if it is null, hence there could be a potential null pointer
> dereference issue. Instead, first check if pdev is null and only then
> deference pdev when initializing vpu.
>
> Found with static analysis by CoverityScan, CID 1357797
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
> drivers/media/platform/mtk-vpu/mtk_vpu.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> index c9bf58c..41f31b2 100644
> --- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
> +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> @@ -523,9 +523,9 @@ static int load_requested_vpu(struct mtk_vpu *vpu,
>
> int vpu_load_firmware(struct platform_device *pdev)
> {
> - struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> + struct mtk_vpu *vpu;
> struct device *dev = &pdev->dev;
> - struct vpu_run *run = &vpu->run;
> + struct vpu_run *run;
> const struct firmware *vpu_fw = NULL;
> int ret;
>
> @@ -533,6 +533,8 @@ int vpu_load_firmware(struct platform_device *pdev)
> dev_err(dev, "VPU platform device is invalid\n");
> return -EINVAL;
> }
> + vpu = platform_get_drvdata(pdev);
> + run = &vpu->run;
>
> mutex_lock(&vpu->vpu_mutex);
> if (vpu->fw_loaded) {
>
^ permalink raw reply
* [Resend PATCH] drm/mediatek: fix null pointer dereference
From: Matthias Brugger @ 2016-11-18 10:06 UTC (permalink / raw)
To: linux-arm-kernel
The probe function requests the interrupt before initializing
the ddp component. Which leads to a null pointer dereference at boot.
Fix this by requesting the interrput after all components got
initialized properly.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC
MT8173.")
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 019b7ca..1e78159 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -250,13 +250,6 @@ static int mtk_disp_ovl_probe(struct
platform_device *pdev)
if (irq < 0)
return irq;
- ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
- IRQF_TRIGGER_NONE, dev_name(dev), priv);
- if (ret < 0) {
- dev_err(dev, "Failed to request irq %d: %d\n", irq, ret);
- return ret;
- }
-
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_OVL);
if (comp_id < 0) {
dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
@@ -272,6 +265,13 @@ static int mtk_disp_ovl_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, priv);
+ ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
+ IRQF_TRIGGER_NONE, dev_name(dev), priv);
+ if (ret < 0) {
+ dev_err(dev, "Failed to request irq %d: %d\n", irq, ret);
+ return ret;
+ }
+
ret = component_add(dev, &mtk_disp_ovl_component_ops);
if (ret)
dev_err(dev, "Failed to add component: %d\n", ret);
--
2.10.1
^ permalink raw reply related
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-18 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114112625.GO10219@e106497-lin.cambridge.arm.com>
On Monday, November 14, 2016 11:26:25 AM CET liviu.dudau at arm.com wrote:
> On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote:
> > > Nope, that is not what it means. It means that PCI devices can see I/O
> > > addresses
> > > on the bus that start from 0. There never was any usage for non-PCI
> > > controllers
> >
> > So I am a bit confused...
> > From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
> > It seems that ISA buses operate on cpu I/O address range [0, 0xFFF].
> > I thought that was the reason why for most architectures we have
> > PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers
> > usually use [0, PCIBIOS_MIN_IO - 1] )
>
> First of all, cpu I/O addresses is an x86-ism. ARM architectures and others
> have no separate address space for I/O, it is all merged into one unified
> address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean
> that we don't care about ISA I/O because the platform does not support having
> an ISA bus (e.g.).
I think to be more specific, PCIBIOS_MIN_IO=0 would indicate that you cannot
have a PCI-to-ISA or PCI-to-LPC bridge in any PCI domain. This is different
from having an LPC master outside of PCI, as that lives in its own domain
and has a separately addressable I/O space.
> > As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO)
> > to allow special ISA controllers to use that range with special
> > accessors.
> > Having a variable threshold would make life much more difficult
> > as there would be a probe dependency between the PCI controller and
> > the special ISA one (PCI to wait for the special ISA device to be
> > probed and set the right threshold value from DT or ACPI table).
> >
> > Instead using PCIBIOS_MIN_IO is easier and should not impose much
> > constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to
> > the PCI controller for I/O tokens...
>
> What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves
> space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve
> space for your direct address I/O on top of PCIBIOS_MIN_IO.
The PCIBIOS_MIN_DIRECT_IO name still suggests having something related to
PCIBIOS_MIN_IO, but it really isn't. We are talking about multiple
concepts here that are not the same but that are somewhat related:
a) keeping PCI devices from allocating low I/O ports on the PCI bus
that would conflict with ISA devices behind a bridge of the
same bus.
b) reserving the low 0x0-0xfff range of the Linux-internal I/O
space abstraction to a particular LPC or PCI domain to make
legacy device drivers work that hardcode a particular port
number.
c) Redirecting inb/outb to call a domain-specific accessor function
rather than doing the normal MMIO window for an LPC master or
more generally any arbitrary LPC or PCI domain that has a
nonstandard I/O space.
[side note: actually if we generalized this, we could avoid
assigning an MMIO range for the I/O space on the pci-mvebu
driver, and that would help free up some other remapping
windows]
I think there is no need to change a) here, we have PCIBIOS_MIN_IO
today and even if we don't need it, there is no obvious downside.
I would also argue that we can ignore b) for the discussion of
the HiSilicon LPC driver, we just need to assign some range
of logical addresses to each domain.
That means solving c) is the important problem here, and it
shouldn't be so hard. We can do this either with a single
special domain as in the v5 patch series, or by generalizing it
so that any I/O space mapping gets looked up through the device
pointer of the bus master.
Arnd
^ permalink raw reply
* [PATCH next] arm64: remove "SMP: Total of %d processors activated." message
From: Will Deacon @ 2016-11-18 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d867f8f-c7b9-42e9-1764-6f802d6b1e96@huawei.com>
On Fri, Nov 18, 2016 at 11:37:10AM +0800, Kefeng Wang wrote:
>
>
> On 2016/11/17 22:22, Will Deacon wrote:
> > On Thu, Nov 17, 2016 at 03:32:26PM +0800, Kefeng Wang wrote:
> >> There is a common SMP boot message in generic code on all arches,
> >> kill "SMP: Total of %d processors activated." in smp_cpus_done()
> >> on arm64.
> >>
> >> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> >> ---
> >> Boot message on qemu.
> >> [ 0.375116] smp: Brought up 1 node, 8 CPUs
> >> [ 0.383749] SMP: Total of 8 processors activated.
> >>
> >> arch/arm64/kernel/smp.c | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> >> index cb87234..9db4a95 100644
> >> --- a/arch/arm64/kernel/smp.c
> >> +++ b/arch/arm64/kernel/smp.c
> >> @@ -428,7 +428,6 @@ static void __init hyp_mode_check(void)
> >>
> >> void __init smp_cpus_done(unsigned int max_cpus)
> >> {
> >> - pr_info("SMP: Total of %d processors activated.\n", num_online_cpus());
> >> setup_cpu_features();
> >> hyp_mode_check();
> >> apply_alternatives_all();
> >
> > Why? Are you proposing the same change to other architectures? Are you paid
> > per patch?
>
> The message provides no further information than the generic code, so kill it.
> Or show BogoMIPS like arm32?
Ha! No, I don't think printing the BogoMIPS is the right solution. I just
think that, if you insist on removing the harmless print, then you should
also consider doing the same thing for all the other architectures that
print the same message.
Will
^ permalink raw reply
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Ard Biesheuvel @ 2016-11-18 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116173217.GB3224@e104818-lin.cambridge.arm.com>
On 16 November 2016 at 17:32, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Nov 15, 2016 at 04:09:07PM -0800, Laura Abbott wrote:
>> On 11/15/2016 10:35 AM, Catalin Marinas wrote:
>> > I'm fine with __pa_symbol use entirely from under arch/arm64. But if you
>> > want to use __pa_symbol, I tried to change most (all?) places where
>> > necessary, together with making virt_to_phys() only deal with the kernel
>> > linear mapping. Not sure it looks cleaner, especially the
>> > __va(__pa_symbol()) cases (we could replace the latter with another
>> > macro and proper comment):
>>
>> I agree everything should be converted over, I was considering doing
>> that in a separate patch but this covers everything nicely. Are you
>> okay with me folding this in? (Few comments below)
>
> Yes. I would also like Ard to review it since he introduced the current
> __virt_to_phys() macro.
>
I think this is a clear improvement. I didn't dare to propose it at
the time, due to the fallout, but it is obviously much better to have
separate accessors than to have runtime tests to decide something that
is already known at compile time. My only concern is potential uses in
generic code: I think there may be something in the handling of
initramfs, or freeing the __init segment (I know it had 'init' in the
name :-)) that refers to the physical address of symbols, but I don't
remember exactly what it is.
Did you test it with a initramfs?
>> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> > index eac3dbb7e313..e02f45e5ee1b 100644
>> > --- a/arch/arm64/include/asm/memory.h
>> > +++ b/arch/arm64/include/asm/memory.h
>> > @@ -169,15 +169,22 @@ extern u64 kimage_voffset;
>> > */
>> > #define __virt_to_phys_nodebug(x) ({ \
>> > phys_addr_t __x = (phys_addr_t)(x); \
>> > - __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
>> > - (__x - kimage_voffset); })
>> > + VM_BUG_ON(!(__x & BIT(VA_BITS - 1))); \
>> > + ((__x & ~PAGE_OFFSET) + PHYS_OFFSET); \
>> > +})
>>
>> I do think this is easier to understand vs the ternary operator.
>> I'll add a comment detailing the use of __pa vs __pa_symbol somewhere
>> as well.
>
> Of course, a comment is welcome (I just did a quick hack to check that
> it works).
>
>> > --- a/arch/arm64/include/asm/mmu_context.h
>> > +++ b/arch/arm64/include/asm/mmu_context.h
>> > @@ -44,7 +44,7 @@ static inline void contextidr_thread_switch(struct task_struct *next)
>> > */
>> > static inline void cpu_set_reserved_ttbr0(void)
>> > {
>> > - unsigned long ttbr = virt_to_phys(empty_zero_page);
>> > + unsigned long ttbr = __pa_symbol(empty_zero_page);
>> >
>> > write_sysreg(ttbr, ttbr0_el1);
>> > isb();
>> > @@ -113,7 +113,7 @@ static inline void cpu_install_idmap(void)
>> > local_flush_tlb_all();
>> > cpu_set_idmap_tcr_t0sz();
>> >
>> > - cpu_switch_mm(idmap_pg_dir, &init_mm);
>> > + cpu_switch_mm(__va(__pa_symbol(idmap_pg_dir)), &init_mm);
>>
>> Yes, the __va(__pa_symbol(..)) idiom needs to be macroized and commented...
>
> Indeed. At the same time we should also replace the LMADDR macro in
> hibernate.c with whatever you come up with.
>
>> > diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
>> > index d55a7b09959b..81c03c74e5fe 100644
>> > --- a/arch/arm64/kernel/hibernate.c
>> > +++ b/arch/arm64/kernel/hibernate.c
>> > @@ -51,7 +51,7 @@
>> > extern int in_suspend;
>> >
>> > /* Find a symbols alias in the linear map */
>> > -#define LMADDR(x) phys_to_virt(virt_to_phys(x))
>> > +#define LMADDR(x) __va(__pa_symbol(x))
>>
>> ...Perhaps just borrowing this macro?
>
> Yes but I don't particularly like the name, especially since it goes
> into a .h file. Maybe __lm_sym_addr() or something else if you have a
> better idea.
>
>> > diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
>> > index 874c78201a2b..98dae943e496 100644
>> > --- a/arch/arm64/mm/physaddr.c
>> > +++ b/arch/arm64/mm/physaddr.c
>> > @@ -14,8 +14,8 @@ unsigned long __virt_to_phys(unsigned long x)
>> > */
>> > return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
>> > } else {
>> > - VIRTUAL_BUG_ON(x < kimage_vaddr || x >= (unsigned long)_end);
>> > - return (__x - kimage_voffset);
>> > + WARN_ON(1);
>>
>> Was the deletion of the BUG_ON here intentional? VIRTUAL_BUG_ON
>> is the check enabled by CONFIG_DEBUG_VIRTUAL vs just CONFIG_DEBUG_VM.
>> I intentionally kept CONFIG_DEBUG_VIRTUAL separate since the checks
>> are expensive.
>
> I wanted to always get a warning but fall back to __phys_addr_symbol()
> so that I can track down other uses of __virt_to_phys() on kernel
> symbols without killing the kernel. A better option would have been
> VIRTUAL_WARN_ON (or *_ONCE) but we don't have it. VM_WARN_ON, as you
> said, is independent of CONFIG_DEBUG_VIRTUAL.
>
> We could as well kill the system with VIRTUAL_BUG_ON in this case but I
> thought we should be more gentle until all the __virt_to_phys use-cases
> are sorted out.
>
> --
> Catalin
^ permalink raw reply
* [PATCH 1/2] ARM: dts: r8a7743: Move RST node before SYSC node
From: Geert Uytterhoeven @ 2016-11-18 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479464663-19054-1-git-send-email-geert+renesas@glider.be>
To preserve both alphabetical (label) and numerical ordering (unit
address).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7743.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 216cb1f37f87de9a..ca0cda28a3eb5241 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -102,17 +102,17 @@
#power-domain-cells = <0>;
};
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7743-rst";
+ reg = <0 0xe6160000 0 0x100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7743-sysc";
reg = <0 0xe6180000 0 0x200>;
#power-domain-cells = <1>;
};
- rst: reset-controller at e6160000 {
- compatible = "renesas,r8a7743-rst";
- reg = <0 0xe6160000 0 0x100>;
- };
-
dmac0: dma-controller at e6700000 {
compatible = "renesas,dmac-r8a7743",
"renesas,rcar-dmac";
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: r8a7745: Move RST node before SYSC node
From: Geert Uytterhoeven @ 2016-11-18 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479464663-19054-1-git-send-email-geert+renesas@glider.be>
To preserve both alphabetical (label) and numerical ordering (unit
address).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7745.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0b2e2f37150fdc68..0a5d7872ce289d9b 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -102,17 +102,17 @@
#power-domain-cells = <0>;
};
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7745-rst";
+ reg = <0 0xe6160000 0 0x100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7745-sysc";
reg = <0 0xe6180000 0 0x200>;
#power-domain-cells = <1>;
};
- rst: reset-controller at e6160000 {
- compatible = "renesas,r8a7745-rst";
- reg = <0 0xe6160000 0 0x100>;
- };
-
dmac0: dma-controller at e6700000 {
compatible = "renesas,dmac-r8a7745",
"renesas,rcar-dmac";
--
1.9.1
^ permalink raw reply related
* spin_lock behavior with ARM64 big.Little/HMP
From: Sudeep Holla @ 2016-11-18 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <400ab4b8b2354c5b9283f6ed657363a0@codeaurora.org>
Hi Vikram,
On 18/11/16 02:22, Vikram Mulukutla wrote:
> Hello,
>
> This isn't really a bug report, but just a description of a frequency/IPC
> dependent behavior that I'm curious if we should worry about. The behavior
> is exposed by questionable design so I'm leaning towards don't-care.
>
> Consider these threads running in parallel on two ARM64 CPUs running
> mainline
> Linux:
>
Are you seeing this behavior with the mainline kernel on any platforms
as we have a sort of workaround for this ?
> (Ordering of lines between the two columns does not indicate a sequence of
> execution. Assume flag=0 initially.)
>
> LittleARM64_CPU @ 300MHz (e.g.A53) | BigARM64_CPU @ 1.5GHz (e.g. A57)
> -------------------------------------+----------------------------------
> spin_lock_irqsave(s) | local_irq_save()
> /* critical section */
> flag = 1 | spin_lock(s)
> spin_unlock_irqrestore(s) | while (!flag) {
> | spin_unlock(s)
> | cpu_relax();
> | spin_lock(s)
> | }
> | spin_unlock(s)
> | local_irq_restore()
>
> I see a livelock occurring where the LittleCPU is never able to acquire the
> lock, and the BigCPU is stuck forever waiting on 'flag' to be set.
>
Yes we saw this issue 3 years back on TC2 which has A7(with lowest
frequency of 300MHz IIRC) and A15(with 1.2 GHz). We were observing that
inter-cluster events are missed since the two clusters are operating at
different frequencies (details below).
The hardware recommendation is that there should be glue logic between
the two clusters which captures events from one cluster and replays then
on the other if its operating at a different frequency.
Generally EVENTO from cluster 1 is connected to the EVENTI of the
cluster 2 and vice versa. The only extra logic required is the double
synchronizer in the receiving clock domain.
This issue arise in reality if the synchronizer is missing and different
CPUs hold EVENTO for different clock cycles.
However there was a different requirement to implement timer event
stream in Linux for some user-space locking and that indirectly help to
resolve the issue on TC2. That event stream feature is enabled by
default in Linux and should fix the issue and hence I asked you if you
still see that issue.
--
Regards,
Sudeep
^ permalink raw reply
* arasan,sdhci.txt "compatibility" DT binding
From: Mason @ 2016-11-18 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56B21DDB.6050708@free.fr>
On 03/02/2016 16:33, Mason wrote:
> On 03/02/2016 16:21, S?ren Brinkmann wrote:
>> On Wed, 2016-02-03 at 10:58:24 +0100, Michal Simek wrote:
>>> On 3.2.2016 09:31, Mason wrote:
>>>> On 03/02/2016 08:20, Michal Simek wrote:
>>>>
>>>>> On 3.2.2016 03:33, Shawn Lin wrote:
>>>>>> + Michal, S?ren Brinkmann
>>>>>>
>>>>>> On 2016/2/2 17:49, Mason wrote:
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt states:
>>>>>>>
>>>>>>> Required Properties:
>>>>>>> - compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or
>>>>>>> 'arasan,sdhci-4.9a' or 'arasan,sdhci-5.1'
>>>>>>>
>>>>>>> What do 8.9a, 4.9a, and 5.1 refer to?
>>>>>>>
>>>>>>
>>>>>> Good question.
>>>>>>
>>>>>> Michal told me that 8.9a and 4.9a came from Xilinx
>>>>>> databook which define their available arasan controller to be version
>>>>>> 4.9a and 8.9a.
>>>>>
>>>>> Our version is coming from here.
>>>>> http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
>>>>> page 28
>>>>>
>>>>> Datasheets from 2012 and 2010 doesn't look too recent and I expect that
>>>>> Arasan did a lot of work from that time that's why I am not surprised
>>>>> that you are not able to see that versions.
>>>>
>>>> Hello Michal,
>>>>
>>>> I'm even more confused.
>>>>
>>>> Arasan's 2010-02-19 data sheet is titled
>>>> SD3.0 / SDIO3.0 / eMMC4.4 AHB Host Controller
>>>>
>>>> Page 28 of the Xilinx data sheet mentions
>>>> SD2.0 / SDIO2.0 / MMC3.31 AHB Host Controller
>>>> Version 8.9A_apr02nd_2010
>>>>
>>>> It does not make sense that Arasan would support SD3.0 in February,
>>>> then go back to SD 2.0 in April.
>>>>
>>>> I do note eMMC4.4 vs MMC3.31 => perhaps these are two *different*
>>>> IP blocks?
>>>>
>>>> Do your data sheets come with revision history?
>>>
>>> I don't have datasheet for this IP in my hand that's why I can't check it.
>>> But I can't see any problem with it. Our zynq SoC supports SD2.0 and it
>>> was requirement at that time. Bugs can happen. Arasan fixed it and
>>> create new version.
>>> At the same time can have 3.0 versions but vendor is just decide not to
>>> use it for whatever reason.
>>>
>>> That's why timing of features and versions can upgrade any time and
>>> unfortunately bugs happen.
>>
>> We have several Arasan data sheets here. The document names are:
>> "SD2.0 / SDIO2.0 / MMC3.31 AHB Userguide" and the revisions are 9.2a,
>> 4.4a and 5.4a. I have the feeling that the document revisions have
>> been mistaken as the IP revision. I cannot find any other indicator
>> for the IP revision though. Does the IP have a way to discover its
>> revision?
>
> To summarize, it looks to me like
> 4.9a and 8.9a are documentation revision numbers for this IP:
> "SD2.0 / SDIO2.0 / MMC3.31 AHB Host Controller"
>
> and 5.1 seems to be the eMMC standard, so one of these IP:
> http://arasan.com/products/emmc51/sd3-emmc-5-1-host/
> http://arasan.com/products/emmc51/emmc-5-1-sd-4-1-host/
>
> Whereas my board is using still another IP:
> "SD3.0 / SDIO3.0 / eMMC4.4 AHB Host Controller"
>
>
> If that is correct, then I should be able to use the 8.9a
> compatible string, and perhaps my hardware will work in
> slightly degraded performance mode, from not using the
> newest protocol gizmos available.
Resurrecting this thread after a chat with Michal on IRC.
The driver now supports a few more compatible strings.
Tracing the history...
Soren/Xilinx defined "arasan,sdhci-8.9a" in e3ec3a3d11ad
They have the "SD2.0/SDIO2.0/MMC3.31 AHB Host Controller" version
(8.9a might be a document revision number, dated 2010-04-02)
Suman/APM added "arasan,sdhci-4.9a" in 308f3f8d8112
@Suman, @Rameshwar: what specific IP block does your SoC embed?
What does 4.9a refer to? The documentation revision number?
Shawn/Rockchip added "arasan,sdhci-5.1" in da795ec26e25
This seems to be for an *actual* eMMC 5.1 version
(instead of a documentation version) as mentioned in
the commit message.
Douglas added "rockchip,rk3399-sdhci-5.1"
and made several other improvements.
I have reached out to Arasan support. Hopefully they can also
help clear up the confusion, assuming they care about the
Linux driver.
Regards.
^ permalink raw reply
* [PATCH v2] ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
From: Sylwester Nawrocki @ 2016-11-18 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22757093.ejshJp9T7L@wuerfel>
On 11/18/2016 09:46 AM, Arnd Bergmann wrote:
> On Friday, November 18, 2016 9:16:58 AM CET Krzysztof Kozlowski wrote:
>> > All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
>> > 200 Hz. Unfortunately in case of multiplatform image this affects also
>> > other platforms when Exynos is enabled.
>> >
>> > This looks like an very old legacy code, dating back to initial
>> > upstreaming of S3C24xx. Probably it was required for s3c24xx timer
>> > driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
>> > unused plat-samsung/time.c").
>> >
>> > Since then, this fixed 200 Hz spread everywhere, including out-of-tree
>> > Samsung kernels (SoC vendor's and Tizen's). I believe this choice
>> > was rather an effect of coincidence instead of conscious choice.
>> >
>> > Exynos uses its own MCT or arch timer and can work with all HZ values.
>> > Older platforms use newer Samsung PWM timer driver which should handle
>> > down to 100 Hz.
>> >
>> > Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
>> > A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
>> > other values.
>> >
>> > Reported-by: Lee Jones <lee.jones@linaro.org>
>> > [Dropping 200_HZ from S3C/S5P suggested by Arnd]
>> > Reported-by: Arnd Bergmann <arnd@arndb.de>
>> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>> > Cc: Kukjin Kim <kgene@kernel.org>
>> > Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> >
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Maybe add a paragraph about the specific problem:
>
> "On s3c24xx, the PWM counter is only 16 bit wide, and with the
> typical 12MHz input clock that overflows every 5.5ms. This works
> with HZ=200 or higher but not with HZ=100 which needs a 10ms
> interval between ticks. On Later chips (S3C64xx, S5P and EXYNOS),
> the counter is 32 bits and does not have this problem.
> The new samsung_pwm_timer driver solves the problem by scaling
> the input clock by a factor of 50 on s3c24xx, which makes it
> less accurate but allows HZ=100 as well as CONFIG_NO_HZ with
> fewer wakeups".
I've tested on S3C2440 SoC based board and I didn't notice any
issues with HZ=100.
Clock frequencies look a bit different because AFAIU MPLL
clock is mostly used as a root clock. The 12 MHz oscillator clock
is used a root clock for the MPLL.
refclk: 12000 kHz
mpll: 405000 kHz
upll: 48000 kHz
fclk: 405000 kHz
hclk: 101250 kHz
pclk: 50625 kHz
So frequency of the timer block's source clock (PCLK) is 50.625 MHz.
This is further divided by 50 in the prescaler as you pointed out.
So the 16-bit is clocked with 1012500 Hz clock. I added some printks
to verify this.
Here is boot log for HZ=200: http://pastebin.com/JuWZdYwh
and HZ=100 http://pastebin.com/HnDnBfhc
samsung_clocksource_init:351 pclk: 50625000, timer clock_rate: 1012500
sched_clock: 16 bits at 1012kHz, resolution 987ns, wraps every 32362962ns
I just don't understand why the log says timer overflow is every 32.362 ms
and not twice this value (65536 * 1/1012500).
--
Thanks,
Sylwester
^ 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