* [kvm-unit-tests PATCH v10 3/3] arm: pmu: Add CPI checking
From: Andrew Jones @ 2016-11-22 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5263e77a-b987-c955-c328-040a11543c94@redhat.com>
On Mon, Nov 21, 2016 at 04:49:20PM -0600, Wei Huang wrote:
>
>
> On 11/21/2016 03:40 PM, Christopher Covington wrote:
> > Hi Wei,
> >
> > On 11/21/2016 03:24 PM, Wei Huang wrote:
> >> From: Christopher Covington <cov@codeaurora.org>
> >
> > I really appreciate your work on these patches. If for any or all of these
> > you have more lines added/modified than me (or using any other better
> > metric), please make sure to change the author to be you with
> > `git commit --amend --reset-author` or equivalent.
>
> Sure, I will if needed. Regarding your comments below, I will fix the
> patch series after Drew's comments, if any.
>
> >
> >> Calculate the numbers of cycles per instruction (CPI) implied by ARM
> >> PMU cycle counter values. The code includes a strict checking facility
> >> intended for the -icount option in TCG mode in the configuration file.
> >>
> >> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> >> Signed-off-by: Wei Huang <wei@redhat.com>
> >> ---
> >> arm/pmu.c | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
> >> arm/unittests.cfg | 14 +++++++
> >> 2 files changed, 132 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arm/pmu.c b/arm/pmu.c
> >> index 176b070..129ef1e 100644
> >> --- a/arm/pmu.c
> >> +++ b/arm/pmu.c
> >> @@ -104,6 +104,25 @@ static inline uint32_t id_dfr0_read(void)
> >> asm volatile("mrc p15, 0, %0, c0, c1, 2" : "=r" (val));
> >> return val;
> >> }
> >> +
> >> +/*
> >> + * Extra instructions inserted by the compiler would be difficult to compensate
> >> + * for, so hand assemble everything between, and including, the PMCR accesses
> >> + * to start and stop counting. Total cycles = isb + mcr + 2*loop = 2 + 2*loop.
> ^^^^^^^^^^^^
> I will change the comment above to "Total instrs".
>
> >> + */
> >> +static inline void precise_cycles_loop(int loop, uint32_t pmcr)
> >
> > Nit: I would call this precise_instrs_loop. How many cycles it takes is
> > IMPLEMENTATION DEFINED.
>
> You are right. The cycle indeed depends on the design. Will fix.
>
> >
> >> +{
> >> + asm volatile(
> >> + " mcr p15, 0, %[pmcr], c9, c12, 0\n"
> >> + " isb\n"
> >> + "1: subs %[loop], %[loop], #1\n"
> >> + " bgt 1b\n"
> >
> > Is there any chance we might need an isb here, to prevent the stop from happening
> > before or during the loop? Where ISBs are required, the Linux best practice is to
>
> In theory, I think this can happen when mcr is executed before all loop
> instructions completed, causing pmccntr_read() to miss some cycles. But
> QEMU TCG mode doesn't support out-order-execution. So the test
> condition, "cpi > 0 && cycles != i * cpi", will never be TRUE. Because
> cpi==0 in KVM, this same test condition won't be TRUE under KVM mode either.
>
> > diligently comment why they are needed. Perhaps it would be a good habit to
> > carry over into kvm-unit-tests.
>
> Agreed. Most isb() instructions were added following CP15 writes (not
> all CP15 writes, but at limited locations). We tried to follow what
> Linux kernel does in perf_event.c. If you feel that any isb() place
> needs special comment, I will be more than happy to add it.
>
> <snip>
No new comments from me. Thanks guys for catching the need to update the
comments.
drew
^ permalink raw reply
* [PATCH 3/3] ARM: davinci: hawk: use gpio descriptor for card detect
From: Axel Haslam @ 2016-11-22 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51a13cb8-082c-c6c8-c1a1-c39de252d022@ti.com>
On Tue, Nov 22, 2016 at 11:26 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Monday 21 November 2016 09:45 PM, Axel Haslam wrote:
>> Currently the mmc driver is polling the gpio to know if the
>> card was removed.
>>
>> By using a gpio descriptor instead of the platform callbacks, the
>> driver will be able to register the gpio with the mmc core with API's
>> designed for this purpose.
>>
>> This has the advantage that an irq will be registered,
>> and polling is no longer needed. Also, platform callbacks can be removed.
>>
>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>
> This patch looks good, provided it is not based of 1/3 and 2/3. There
> are other boards in mach-davinci using the card detect and wp callbacks.
> And some like board-dm365-evm.c have those pins routed through a CPLD.
> So I guess there is more work to be done before platform callbacks can
> completely be removed from MMC/SD driver. But the closer we get, the
> better it is :)
>
Yes, i saw the platform using CPLD for the pins. that might be tricky to remove.
we can flag the mmc "broken card detect" which would force polling on the pin.
im not sure if it is feasible to move the cpld pin handling to a
driver.. (maybe a
gpio driver?)
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Hans Verkuil @ 2016-11-22 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479784905.8964.15.camel@mtksdaap41>
On 22/11/16 04:21, Rick Chang wrote:
> Hi Hans,
>
> On Mon, 2016-11-21 at 15:51 +0100, Hans Verkuil wrote:
>> On 17/11/16 04:38, Rick Chang wrote:
>>> Signed-off-by: Rick Chang <rick.chang@mediatek.com>
>>> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
>>> ---
>>> This patch depends on:
>>> CCF "Add clock support for Mediatek MT2701"[1]
>>> iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
>>>
>>> [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
>>> [2] https://patchwork.kernel.org/patch/9164013/
>>
>> I assume that 1 & 2 will appear in 4.10? So this patch needs to go in
>> after the
>> other two are merged in 4.10?
>>
>> Regards,
>>
>> Hans
>
> [1] will appear in 4.10, but [2] will appear latter than 4.10.So this
> patch needs to go in after [1] & [2] will be merged in 4.11.
So what should I do? Merge the driver for 4.11 and wait with this patch
until [2] is merged in 4.11? Does that sound reasonable?
Regards,
Hans
^ permalink raw reply
* [kvm-unit-tests PATCH v10 2/3] arm: pmu: Check cycle count increases
From: Andrew Jones @ 2016-11-22 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479759895-10042-3-git-send-email-wei@redhat.com>
On Mon, Nov 21, 2016 at 02:24:54PM -0600, Wei Huang wrote:
> From: Christopher Covington <cov@codeaurora.org>
>
> Ensure that reads of the PMCCNTR_EL0 are monotonically increasing,
> even for the smallest delta of two subsequent reads.
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> Signed-off-by: Wei Huang <wei@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
> ---
> arm/pmu.c | 156 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 156 insertions(+)
>
> diff --git a/arm/pmu.c b/arm/pmu.c
> index 9d9c53b..176b070 100644
> --- a/arm/pmu.c
> +++ b/arm/pmu.c
> @@ -15,6 +15,9 @@
> #include "libcflat.h"
> #include "asm/barrier.h"
>
> +#define PMU_PMCR_E (1 << 0)
> +#define PMU_PMCR_C (1 << 2)
> +#define PMU_PMCR_LC (1 << 6)
> #define PMU_PMCR_N_SHIFT 11
> #define PMU_PMCR_N_MASK 0x1f
> #define PMU_PMCR_ID_SHIFT 16
> @@ -22,6 +25,14 @@
> #define PMU_PMCR_IMP_SHIFT 24
> #define PMU_PMCR_IMP_MASK 0xff
>
> +#define ID_DFR0_PERFMON_SHIFT 24
> +#define ID_DFR0_PERFMON_MASK 0xf
> +
> +#define PMU_CYCLE_IDX 31
> +
> +#define NR_SAMPLES 10
> +
> +static unsigned int pmu_version;
> #if defined(__arm__)
> static inline uint32_t pmcr_read(void)
> {
> @@ -30,6 +41,69 @@ static inline uint32_t pmcr_read(void)
> asm volatile("mrc p15, 0, %0, c9, c12, 0" : "=r" (ret));
> return ret;
> }
> +
> +static inline void pmcr_write(uint32_t value)
> +{
> + asm volatile("mcr p15, 0, %0, c9, c12, 0" : : "r" (value));
> + isb();
> +}
> +
> +static inline void pmselr_write(uint32_t value)
> +{
> + asm volatile("mcr p15, 0, %0, c9, c12, 5" : : "r" (value));
> + isb();
> +}
> +
> +static inline void pmxevtyper_write(uint32_t value)
> +{
> + asm volatile("mcr p15, 0, %0, c9, c13, 1" : : "r" (value));
> +}
> +
> +static inline uint64_t pmccntr_read(void)
> +{
> + uint32_t lo, hi = 0;
> +
> + if (pmu_version == 0x3)
> + asm volatile("mrrc p15, 0, %0, %1, c9" : "=r" (lo), "=r" (hi));
> + else
> + asm volatile("mrc p15, 0, %0, c9, c13, 0" : "=r" (lo));
> +
> + return ((uint64_t)hi << 32) | lo;
> +}
> +
> +static inline void pmccntr_write(uint64_t value)
> +{
> + uint32_t lo, hi;
> +
> + lo = value & 0xffffffff;
> + hi = (value >> 32) & 0xffffffff;
> +
> + if (pmu_version == 0x3)
> + asm volatile("mcrr p15, 0, %0, %1, c9" : : "r" (lo), "r" (hi));
> + else
> + asm volatile("mcr p15, 0, %0, c9, c13, 0" : : "r" (lo));
> +}
> +
> +static inline void pmcntenset_write(uint32_t value)
> +{
> + asm volatile("mcr p15, 0, %0, c9, c12, 1" : : "r" (value));
> +}
> +
> +/* PMCCFILTR is an obsolete name for PMXEVTYPER31 in ARMv7 */
> +static inline void pmccfiltr_write(uint32_t value)
> +{
> + pmselr_write(PMU_CYCLE_IDX);
> + pmxevtyper_write(value);
> + isb();
> +}
> +
> +static inline uint32_t id_dfr0_read(void)
> +{
> + uint32_t val;
> +
> + asm volatile("mrc p15, 0, %0, c0, c1, 2" : "=r" (val));
> + return val;
> +}
> #elif defined(__aarch64__)
> static inline uint32_t pmcr_read(void)
> {
> @@ -38,6 +112,44 @@ static inline uint32_t pmcr_read(void)
> asm volatile("mrs %0, pmcr_el0" : "=r" (ret));
> return ret;
> }
> +
> +static inline void pmcr_write(uint32_t value)
> +{
> + asm volatile("msr pmcr_el0, %0" : : "r" (value));
> + isb();
> +}
> +
> +static inline uint64_t pmccntr_read(void)
> +{
> + uint64_t cycles;
> +
> + asm volatile("mrs %0, pmccntr_el0" : "=r" (cycles));
> + return cycles;
> +}
> +
> +static inline void pmccntr_write(uint64_t value)
> +{
> + asm volatile("msr pmccntr_el0, %0" : : "r" (value));
> +}
> +
> +static inline void pmcntenset_write(uint32_t value)
> +{
> + asm volatile("msr pmcntenset_el0, %0" : : "r" (value));
> +}
> +
> +static inline void pmccfiltr_write(uint32_t value)
> +{
> + asm volatile("msr pmccfiltr_el0, %0" : : "r" (value));
> + isb();
> +}
> +
> +static inline uint32_t id_dfr0_read(void)
> +{
> + uint32_t id;
> +
> + asm volatile("mrs %0, id_dfr0_el1" : "=r" (id));
> + return id;
> +}
> #endif
>
> /*
> @@ -64,11 +176,55 @@ static bool check_pmcr(void)
> return ((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) != 0;
> }
>
> +/*
> + * Ensure that the cycle counter progresses between back-to-back reads.
> + */
> +static bool check_cycles_increase(void)
> +{
> + bool success = true;
> +
> + /* init before event access, this test only cares about cycle count */
> + pmcntenset_write(1 << PMU_CYCLE_IDX);
> + pmccfiltr_write(0); /* count cycles in EL0, EL1, but not EL2 */
> + pmccntr_write(0);
> +
> + pmcr_write(pmcr_read() | PMU_PMCR_LC | PMU_PMCR_C | PMU_PMCR_E);
> +
> + for (int i = 0; i < NR_SAMPLES; i++) {
> + uint64_t a, b;
> +
> + a = pmccntr_read();
> + b = pmccntr_read();
> +
> + if (a >= b) {
> + printf("Read %"PRId64" then %"PRId64".\n", a, b);
> + success = false;
> + break;
> + }
> + }
> +
> + pmcr_write(pmcr_read() & ~PMU_PMCR_E);
> +
> + return success;
> +}
> +
> +void pmu_init(void)
> +{
> + uint32_t dfr0;
> +
> + /* probe pmu version */
> + dfr0 = id_dfr0_read();
> + pmu_version = (dfr0 >> ID_DFR0_PERFMON_SHIFT) & ID_DFR0_PERFMON_MASK;
> + printf("PMU version: %d\n", pmu_version);
> +}
> +
> int main(void)
> {
> report_prefix_push("pmu");
>
> + pmu_init();
> report("Control register", check_pmcr());
> + report("Monotonically increasing cycle count", check_cycles_increase());
>
> return report_summary();
> }
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/3] of: base: add support to get machine compatible string
From: Sekhar Nori @ 2016-11-22 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dd85c5f9-0899-7da3-ab58-730107bfb02c@arm.com>
On Tuesday 22 November 2016 04:36 PM, Sudeep Holla wrote:
>
>
> On 22/11/16 10:57, Bartosz Golaszewski wrote:
>> 2016-11-22 11:53 GMT+01:00 Sudeep Holla <sudeep.holla@arm.com>:
>>>
>>>
>>> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>>>>
>>>> Add a function allowing to retrieve the compatible string of the root
>>>> node of the device tree.
>>>>
>>>
>>> Rob has queued [1] and it's in -next today. You can reuse that if you
>>> are planning to target this for v4.11 or just use open coding in your
>>> driver for v4.10 and target this move for v4.11 to avoid cross tree
>>> dependencies as I already mentioned in your previous thread.
>>
>> Rob's patch checks the model first - I'm not sure this is the behavior
>> we want here as Sekhar suggested we print the machine compatible.
>
> IIUC, you are replacing of_flat_dt_get_machine_name and
> of_machine_get_model_name does exactly same. So I don't see any point in
> adding this new function and it's just used for logging purpose.
> Also Sekhar just gave example by using just compatible adding that
> function in the driver itself.
>
> As Arnd suggested me[1], you should for v4.10 fix it in the driver
> itself to avoid the cross tree dependencies at this point similar to [2]
+1. Bartosz, can you please fix it in the driver for v4.10. If there is
an API available, we can move to it for v4.11
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 16/18] arm64: dts: h3ulcb: rename SDHI0 pins
From: Vladimir Barinov @ 2016-11-22 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4fbb71f-2a4d-2239-faa9-c017c74e1d79@cogentembedded.com>
Hi Sergei,
On 22.11.2016 14:40, Sergei Shtylyov wrote:
> On 11/22/2016 2:22 PM, Vladimir Barinov wrote:
>
>>>> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>>>>
>>>> This changes SDHI0 pin names for H3ULCB board
>>>>
>>>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>>>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>>>> ---
>>>> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 8 ++++----
>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>>>> b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>>>> index 8d0ac076d8e2..6ffb0517421a 100644
>>>> --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>>>> +++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>>>> @@ -163,13 +163,13 @@
>>>> function = "avb";
>>>> };
>>>>
>>>> - sdhi0_pins_3v3: sd0_3v3 {
>>>> + sdhi0_pins: sd0 {
>>>> groups = "sdhi0_data4", "sdhi0_ctrl";
>>>> function = "sdhi0";
>>>> power-source = <3300>;
>>>> };
>>>>
>>>> - sdhi0_pins_1v8: sd0_1v8 {
>>>> + sdhi0_pins_uhs: sd0 {
>>>
>>> I'm afraid the following will just override the props of the node
>>> above
>>> which is not what we ant.
>> Thank you for pointing to this.
>>
>> This is my typo.
>> I will rework the patch to have different node names.
>
> The patch had been already merged by Simon and was posted a s apart
> of a pull request (if I don't mistake), so I guess an incremental
> patch needed now...
Thanks for clarification.
I will make incremental patch.
Regards,
Vladimir
>
>> Regards,
>> Vladimir
>
> MBR, Sergei
>
^ permalink raw reply
* [PATCH] ARM: dts: da850-lcdk: fix mmc card detect polarity
From: Sekhar Nori @ 2016-11-22 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121154155.16985-1-ahaslam@baylibre.com>
On Monday 21 November 2016 09:11 PM, Axel Haslam wrote:
> The polarity of the card detect pin is inverted.
>
> Change it to reflect the right polarity for the board
> which is ACTIVE_LOW.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Applied to v4.10/dt
Thanks,
Sekhar
^ permalink raw reply
* [RFC PATCH 09/11] ARM: NOMMU: define SECTION_xxx macros
From: Russell King - ARM Linux @ 2016-11-22 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58343121.4030906@arm.com>
On Tue, Nov 22, 2016 at 11:50:57AM +0000, Vladimir Murzin wrote:
> On 22/11/16 10:07, Russell King - ARM Linux wrote:
> > On Tue, Nov 22, 2016 at 09:26:06AM +0000, Vladimir Murzin wrote:
> >> Pickup defines from pgtable-2level.h to make NOMMU build happy.
> >
> > This needs more detail.
> >
>
> It comes from
>
> CC arch/arm/kernel/setup.o
> arch/arm/kernel/setup.c: In function 'reserve_crashkernel':
> arch/arm/kernel/setup.c:1001:25: error: 'SECTION_SIZE' undeclared (first use in this function)
> crash_size, SECTION_SIZE);
> ^
> arch/arm/kernel/setup.c:1001:25: note: each undeclared identifier is reported only once for each function it appears in
> make[1]: *** [arch/arm/kernel/setup.o] Error 1
> make: *** [arch/arm/kernel] Error 2
Hmm, I decided not to use CRASH_ALIGN there because I didn't want to
break anyone's existing setup unnecessarily, however arguably it
should be CRASH_ALIGN to ensure that the new kernel is properly
positioned.
I wonder if we can get away with changing that, rather than
unnecessarily introducing these otherwise meaningless definitions
for R-class.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RFC PATCH 09/11] ARM: NOMMU: define SECTION_xxx macros
From: Vladimir Murzin @ 2016-11-22 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122100713.GW1041@n2100.armlinux.org.uk>
On 22/11/16 10:07, Russell King - ARM Linux wrote:
> On Tue, Nov 22, 2016 at 09:26:06AM +0000, Vladimir Murzin wrote:
>> Pickup defines from pgtable-2level.h to make NOMMU build happy.
>
> This needs more detail.
>
It comes from
CC arch/arm/kernel/setup.o
arch/arm/kernel/setup.c: In function 'reserve_crashkernel':
arch/arm/kernel/setup.c:1001:25: error: 'SECTION_SIZE' undeclared (first use in this function)
crash_size, SECTION_SIZE);
^
arch/arm/kernel/setup.c:1001:25: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [arch/arm/kernel/setup.o] Error 1
make: *** [arch/arm/kernel] Error 2
Cheers
Vladimir
>>
>> Cc: Russell King <linux@armlinux.org.uk>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>> ---
>> arch/arm/include/asm/pgtable-nommu.h | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/pgtable-nommu.h b/arch/arm/include/asm/pgtable-nommu.h
>> index add094d..9115801 100644
>> --- a/arch/arm/include/asm/pgtable-nommu.h
>> +++ b/arch/arm/include/asm/pgtable-nommu.h
>> @@ -35,6 +35,11 @@
>>
>> #define PGDIR_SIZE (1UL << PGDIR_SHIFT)
>> #define PGDIR_MASK (~(PGDIR_SIZE-1))
>> +
>> +#define SECTION_SHIFT 20
>> +#define SECTION_SIZE (1UL << SECTION_SHIFT)
>> +#define SECTION_MASK (~(SECTION_SIZE-1))
>> +
>> /* FIXME */
>>
>> #define PAGE_NONE __pgprot(0)
>> --
>> 1.7.9.5
>>
>
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxl: Add support for Nexbox A95X
From: Neil Armstrong @ 2016-11-22 11:41 UTC (permalink / raw)
To: linux-arm-kernel
The Nexbox A95X exists with a Meson GXBB (S905) Soc or a Meson GXL SoC (S905X).
Add the S905X variant which uses the internal PHY instead of an external PHY.
---
Documentation/devicetree/bindings/arm/amlogic.txt | 1 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 205 +++++++++++++++++++++
3 files changed, 207 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
index 6ef7c52..9b2b41a 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -45,4 +45,5 @@ Board compatible values:
- "amlogic,p231" (Meson gxl s905d)
- "amlogic,q200" (Meson gxm s912)
- "amlogic,q201" (Meson gxm s912)
+ - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
- "nexbox,a1" (Meson gxm s912)
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 2fbb8e3..0d7bfbf 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-vega-s95-telos.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-p212.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p230.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p231.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
new file mode 100644
index 0000000..e99101a
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -0,0 +1,205 @@
+/*
+ * Copyright (c) 2016 Andreas F?rber
+ * Copyright (c) 2016 BayLibre, Inc.
+ * Author: Neil Armstrong <narmstrong@kernel.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "meson-gxl-s905x.dtsi"
+
+/ {
+ compatible = "nexbox,a95x", "amlogic,s905x", "amlogic,meson-gxl";
+ model = "NEXBOX A95X (S905X)";
+
+ aliases {
+ serial0 = &uart_AO;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x80000000>;
+ };
+
+ vddio_card: gpio-regulator {
+ compatible = "regulator-gpio";
+
+ regulator-name = "VDDIO_CARD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+
+ /* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
+ states = <1800000 0
+ 3300000 1>;
+ };
+
+ vddio_boot: regulator-vddio_boot {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_BOOT";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vddao_3v3: regulator-vddao_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcc_3v3: regulator-vcc_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
+ };
+
+ wifi32k: wifi32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
+};
+
+&uart_AO {
+ status = "okay";
+ pinctrl-0 = <&uart_ao_a_pins>;
+ pinctrl-names = "default";
+};
+
+ðmac {
+ status = "okay";
+ phy-mode = "rmii";
+ phy-handle = <&internal_phy>;
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_input_ao_pins>;
+ pinctrl-names = "default";
+};
+
+/* Wireless SDIO Module */
+&sd_emmc_a {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <100000000>;
+
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&sdio_pwrseq>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_boot>;
+};
+
+/* SD card */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-names = "default";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <100000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_card>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>;
+ pinctrl-names = "default";
+
+ bus-width = <8>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&vddio_boot>;
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&clkc CLKID_FCLK_DIV4>;
+ clock-names = "clkin0";
+};
--
2.7.0
^ permalink raw reply related
* [PATCH 16/18] arm64: dts: h3ulcb: rename SDHI0 pins
From: Sergei Shtylyov @ 2016-11-22 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f4f57fbc-313c-669f-94c7-073747a20a82@cogentembedded.com>
On 11/22/2016 2:22 PM, Vladimir Barinov wrote:
>>> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>>>
>>> This changes SDHI0 pin names for H3ULCB board
>>>
>>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>>> ---
>>> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>>> b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>>> index 8d0ac076d8e2..6ffb0517421a 100644
>>> --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>>> +++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>>> @@ -163,13 +163,13 @@
>>> function = "avb";
>>> };
>>>
>>> - sdhi0_pins_3v3: sd0_3v3 {
>>> + sdhi0_pins: sd0 {
>>> groups = "sdhi0_data4", "sdhi0_ctrl";
>>> function = "sdhi0";
>>> power-source = <3300>;
>>> };
>>>
>>> - sdhi0_pins_1v8: sd0_1v8 {
>>> + sdhi0_pins_uhs: sd0 {
>>
>> I'm afraid the following will just override the props of the node above
>> which is not what we ant.
> Thank you for pointing to this.
>
> This is my typo.
> I will rework the patch to have different node names.
The patch had been already merged by Simon and was posted a s apart of a
pull request (if I don't mistake), so I guess an incremental patch needed now...
> Regards,
> Vladimir
MBR, Sergei
^ permalink raw reply
* [PATCH v3] clkdev: Detect errors in clk_hw_register_clkdev() for mass registration
From: Geert Uytterhoeven @ 2016-11-22 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdW8V2v7na1c4B=w2qzN=qVF0QUA3fcqaUXdTEVB20JREg@mail.gmail.com>
On Mon, Oct 31, 2016 at 10:31 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Oct 31, 2016 at 10:22 AM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
>> On Fri, Oct 21, 2016 at 09:02:38AM +0200, Geert Uytterhoeven wrote:
>>> Unlike clk_register_clkdev(), clk_hw_register_clkdev() doesn't check for
>>> passed error objects from a previous registration call. Hence the caller
>>> of clk_hw_register_*() has to check for errors before calling
>>> clk_hw_register_clkdev*().
>>>
>>> Make clk_hw_register_clkdev() more similar to clk_register_clkdev() by
>>> adding this error check, removing the burden from callers that do mass
>>> registration.
>>>
>>> Fixes: e4f1b49bda6d6aa2 ("clkdev: Add clk_hw based registration APIs")
>>> Fixes: 944b9a41e004534f ("clk: ls1x: Migrate to clk_hw based OF and registration APIs")
>>> Fixes: 44ce9a9ae977736f ("MIPS: TXx9: Convert to Common Clock Framework")
>>> Fixes: f48d947a162dfa9d ("clk: clps711x: Migrate to clk_hw based OF and registration APIs")
>>> Fixes: b4626a7f489238a5 ("CLK: Add Loongson1C clock support")
>>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>
>> Please put this in the patch system, thanks.
>
> Done. I hope it went through, the "new" README predates git-send-email.
Still no evidence of the patch having arrived...
Tried the web interface instead, patch is now 8631/1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [RFC PATCH 04/11] PCI: tegra: limit to MMU build only
From: Thierry Reding @ 2016-11-22 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28079479.jInxCWkYlm@wuerfel>
On Tue, Nov 22, 2016 at 10:54:01AM +0100, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 9:40:39 AM CET Vladimir Murzin wrote:
> > On 22/11/16 09:31, Arnd Bergmann wrote:
> > > On Tuesday, November 22, 2016 9:26:01 AM CET Vladimir Murzin wrote:
> > >> This driver uses functionality which available for MMU build only,
> > >> thus add dependency on MMU.
> > >>
> > >> Cc: Thierry Reding <thierry.reding@gmail.com>
> > >> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> > >>
> > >
> > > Can you be more specific about what requires the MMU here?
> > >
> > > Is it the I/O space remapping or something else?
> >
> > Yes it comes from I/O space remapping.
> >
> > The fill error log:
> >
> > CC drivers/pci/host/pci-tegra.o
> > In file included from ./arch/arm/include/asm/page.h:22:0,
> > from ./arch/arm/include/asm/thread_info.h:17,
> > from ./include/linux/thread_info.h:58,
> > from ./include/asm-generic/current.h:4,
> > from ./arch/arm/include/generated/asm/current.h:1,
> > from ./include/linux/mutex.h:13,
> > from ./include/linux/notifier.h:13,
> > from ./include/linux/clk.h:17,
> > from drivers/pci/host/pci-tegra.c:29:
> > drivers/pci/host/pci-tegra.c: In function 'tegra_pcie_bus_alloc':
> > drivers/pci/host/pci-tegra.c:388:27: error: 'L_PTE_PRESENT' undeclared (first use in this function)
> > pgprot_t prot = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
>
>
> That is not the I/O space, that is the config space.
>
> Not sure what a better alternative would be, but the manual selection
> of page flags makes the driver non-portable and dependent on architecture
> specifics that it really shouldn't have to worry about.
>
> In common PCI code, we use pgprot_device(PAGE_KERNEL)) at some point,
> and that sounds like the right thing to do, but ARM doesn't provide
> an override for it and the fallback is pgprot_noncached(), which is
> probably wrong here.
Actually I think pgprot_noncached() is correct. Very early on we used to
map this using ioremap() and I remember that working. I also just tested
the pci-tegra driver with pgprot_device(PAGE_KERNEL) instead of the ARM-
specific flags and it seems to work well.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161122/220bb54b/attachment-0001.sig>
^ permalink raw reply
* [PATCH 16/18] arm64: dts: h3ulcb: rename SDHI0 pins
From: Vladimir Barinov @ 2016-11-22 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <45a251f6-ee0c-5eba-ffd1-3f61a1e7ccc7@cogentembedded.com>
Hi Sergei,
On 21.11.2016 16:13, Sergei Shtylyov wrote:
> Hello.
>
> On 11/21/2016 03:05 PM, Simon Horman wrote:
>
>> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>>
>> This changes SDHI0 pin names for H3ULCB board
>>
>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>> ---
>> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>> b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>> index 8d0ac076d8e2..6ffb0517421a 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
>> @@ -163,13 +163,13 @@
>> function = "avb";
>> };
>>
>> - sdhi0_pins_3v3: sd0_3v3 {
>> + sdhi0_pins: sd0 {
>> groups = "sdhi0_data4", "sdhi0_ctrl";
>> function = "sdhi0";
>> power-source = <3300>;
>> };
>>
>> - sdhi0_pins_1v8: sd0_1v8 {
>> + sdhi0_pins_uhs: sd0 {
>
> I'm afraid the following will just override the props of the node
> above which is not what we ant.
Thank you for pointing to this.
This is my typo.
I will rework the patch to have different node names.
Regards,
Vladimir
>
>> groups = "sdhi0_data4", "sdhi0_ctrl";
>> function = "sdhi0";
>> power-source = <1800>;
> [...]
>
> MBR, Sergei
>
^ permalink raw reply
* [PATCH V5 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64
From: John Garry @ 2016-11-22 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479767763-27532-1-git-send-email-tbaicar@codeaurora.org>
+
We'll try and test this on our platform.
Cheers,
John
On 21/11/2016 22:35, Tyler Baicar wrote:
> When a memory error, CPU error, PCIe error, or other type of hardware error
> that's covered by RAS occurs, firmware should populate the shared GHES memory
> location with the proper GHES structures to notify the OS of the error.
> For example, platforms that implement firmware first handling may implement
> separate GHES sources for corrected errors and uncorrected errors. If the
> error is an uncorrectable error, then the firmware will notify the OS
> immediately since the error needs to be handled ASAP. The OS will then be able
> to take the appropriate action needed such as offlining a page. If the error
> is a corrected error, then the firmware will not interrupt the OS immediately.
> Instead, the OS will see and report the error the next time it's GHES timer
> expires. The kernel will first parse the GHES structures and report the errors
> through the kernel logs and then notify the user space through RAS trace
> events. This allows user space applications such as RAS Daemon to see the
> errors and report them however the user desires. This patchset extends the
> kernel functionality for RAS errors based on updates in the UEFI 2.6 and
> ACPI 6.1 specifications.
>
> An example flow from firmware to user space could be:
>
> +---------------+
> +-------->| |
> | | GHES polling |--+
> +-------------+ | source | | +---------------+ +------------+
> | | +---------------+ | | Kernel GHES | | |
> | Firmware | +-->| CPER AER and |-->| RAS trace |
> | | +---------------+ | | EDAC drivers | | event |
> +-------------+ | | | +---------------+ +------------+
> | | GHES sci |--+
> +-------->| source |
> +---------------+
>
> Add support for Generic Hardware Error Source (GHES) v2, which introduces the
> capability for the OS to acknowledge the consumption of the error record
> generated by the Reliability, Availability and Serviceability (RAS) controller.
> This eliminates potential race conditions between the OS and the RAS controller.
>
> Add support for the timestamp field added to the Generic Error Data Entry v3,
> allowing the OS to log the time that the error is generated by the firmware,
> rather than the time the error is consumed. This improves the correctness of
> event sequences when analyzing error logs. The timestamp is added in
> ACPI 6.1, reference Table 18-343 Generic Error Data Entry.
>
> Add support for ARMv8 Common Platform Error Record (CPER) per UEFI 2.6
> specification. ARMv8 specific processor error information is reported as part of
> the CPER records. This provides more detail on for processor error logs. This
> can help describe ARMv8 cache, tlb, and bus errors.
>
> Synchronous External Abort (SEA) represents a specific processor error condition
> in ARM systems. A handler is added to recognize SEA errors, and a notifier is
> added to parse and report the errors before the process is killed. Refer to
> section N.2.1.1 in the Common Platform Error Record appendix of the UEFI 2.6
> specification.
>
> Currently the kernel ignores CPER records that are unrecognized.
> On the other hand, UEFI spec allows for non-standard (eg. vendor
> proprietary) error section type in CPER (Common Platform Error Record),
> as defined in section N2.3 of UEFI version 2.5. Therefore, user
> is not able to see hardware error data of non-standard section.
>
> If section Type field of Generic Error Data Entry is unrecognized,
> prints out the raw data in dmesg buffer, and also adds a tracepoint
> for reporting such hardware errors.
>
> Currently even if an error status block's severity is fatal, the kernel
> does not honor the severity level and panic. With the firmware first
> model, the platform could inform the OS about a fatal hardware error
> through the non-NMI GHES notification type. The OS should panic when a
> hardware error record is received with this severity.
>
> Add support to handle SEAs that occur while a KVM guest kernel is
> running. Currently these are unsupported by the guest abort handling.
>
> Depends on: [PATCH v14] acpi, apei, arm64: APEI initial support for aarch64.
> https://lkml.org/lkml/2016/8/10/231
>
> V5: Fix GHES goto logic for error conditions
> Change ghes_do_read_ack to ghes_ack_error
> Make sure data version check is >= 3
> Use CPER helper functions in print functions
> Make handle_guest_sea() dummy function static for arm
> Add arm to subject line for KVM patch
>
> V4: Add bit offset left shift to read_ack_write value
> Make HEST generic and generic_v2 structures a union in the ghes structure
> Move gdata v3 helper functions into ghes.h to avoid duplication
> Reorder the timestamp print and avoid memcpy
> Add helper functions for gdata size checking
> Rename the SEA functions
> Add helper function for GHES panics
> Set fru_id to NULL UUID at variable declaration
> Limit ARM trace event parameters to the needed structures
> Reorder the ARM trace event variables to save space
> Add comment for why we don't pass SEAs to the guest when it aborts
> Move ARM trace event call into GHES driver instead of CPER
>
> V3: Fix unmapped address to the read_ack_register in ghes.c
> Add helper function to get the proper payload based on generic data entry
> version
> Move timestamp print to avoid changing function calls in cper.c
> Remove patch "arm64: exception: handle instruction abort at current EL"
> since the el1_ia handler is already added in 4.8
> Add EFI and ARM64 dependencies for HAVE_ACPI_APEI_SEA
> Add a new trace event for ARM type errors
> Add support to handle KVM guest SEAs
>
> V2: Add PSCI state print for the ARMv8 error type.
> Separate timestamp year into year and century using BCD format.
> Rebase on top of ACPICA 20160318 release and remove header file changes
> in include/acpi/actbl1.h.
> Add panic OS with fatal error status block patch.
> Add processing of unrecognized CPER error section patches with updates
> from previous comments. Original patches: https://lkml.org/lkml/2015/9/8/646
>
> V1: https://lkml.org/lkml/2016/2/5/544
>
> Jonathan (Zhixiong) Zhang (1):
> acpi: apei: panic OS with fatal error status block
>
> Tyler Baicar (9):
> acpi: apei: read ack upon ghes record consumption
> ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
> efi: parse ARMv8 processor error
> arm64: exception: handle Synchronous External Abort
> acpi: apei: handle SEA notification type for ARMv8
> efi: print unrecognized CPER section
> ras: acpi / apei: generate trace event for unrecognized CPER section
> trace, ras: add ARM processor error trace event
> arm/arm64: KVM: add guest SEA support
>
> arch/arm/include/asm/kvm_arm.h | 1 +
> arch/arm/include/asm/system_misc.h | 5 +
> arch/arm/kvm/mmu.c | 18 ++-
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/kvm_arm.h | 1 +
> arch/arm64/include/asm/system_misc.h | 15 +++
> arch/arm64/mm/fault.c | 71 ++++++++++--
> drivers/acpi/apei/Kconfig | 14 +++
> drivers/acpi/apei/ghes.c | 188 ++++++++++++++++++++++++++++---
> drivers/acpi/apei/hest.c | 7 +-
> drivers/firmware/efi/cper.c | 210 ++++++++++++++++++++++++++++++++---
> drivers/ras/ras.c | 2 +
> include/acpi/ghes.h | 15 ++-
> include/linux/cper.h | 84 ++++++++++++++
> include/ras/ras_event.h | 100 +++++++++++++++++
> 15 files changed, 688 insertions(+), 44 deletions(-)
>
^ permalink raw reply
* commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build
From: Arnd Bergmann @ 2016-11-22 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120172248.GW1041@n2100.armlinux.org.uk>
On Sunday, November 20, 2016 5:22:48 PM CET Russell King - ARM Linux wrote:
> - not touching:
> arch/arm/lib/csumpartialcopy.S
> arch/arm/lib/csumpartialcopygeneric.S
> arch/arm/lib/csumpartialcopyuser.S
>
> other than that, it's doing the same thing.
>
> I think Arnd's changes to the csumpartial code are unnecessary, and
> yours is, although larger, puts the asm/export.h include in the right
> place. So please drop yours into the patch system so we can move
> forward fixing some of the problems created during the last merge
> window.
Right, the csumpartialcopy*.S changes are no longer needed after
commit cc6acc11cad1 ("kbuild: be more careful about matching
preprocessed asm ___EXPORT_SYMBOL") solves the problem more
generally.
I've submitted a new version of my patch, now just adding the
one header file that is needed to get MODVERSIONS back working,
plus the second patch for mmiocpy/mmioset to partially revert
Al's original change.
Arnd
^ permalink raw reply
* [PATCH 1/3] of: base: add support to get machine compatible string
From: Sudeep Holla @ 2016-11-22 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJU=wR4mdQr5tpNSv8POirtWXR=_s7D_Q_H=Cuy=W=-Jtw@mail.gmail.com>
On 22/11/16 10:57, Bartosz Golaszewski wrote:
> 2016-11-22 11:53 GMT+01:00 Sudeep Holla <sudeep.holla@arm.com>:
>>
>>
>> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>>>
>>> Add a function allowing to retrieve the compatible string of the root
>>> node of the device tree.
>>>
>>
>> Rob has queued [1] and it's in -next today. You can reuse that if you
>> are planning to target this for v4.11 or just use open coding in your
>> driver for v4.10 and target this move for v4.11 to avoid cross tree
>> dependencies as I already mentioned in your previous thread.
>
> Rob's patch checks the model first - I'm not sure this is the behavior
> we want here as Sekhar suggested we print the machine compatible.
IIUC, you are replacing of_flat_dt_get_machine_name and
of_machine_get_model_name does exactly same. So I don't see any point in
adding this new function and it's just used for logging purpose.
Also Sekhar just gave example by using just compatible adding that
function in the driver itself.
As Arnd suggested me[1], you should for v4.10 fix it in the driver
itself to avoid the cross tree dependencies at this point similar to [2]
--
Regards,
Sudeep
[1]
https://www.mail-archive.com/linuxppc-dev at lists.ozlabs.org/msg111428.html
[2] http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1274502.html
^ permalink raw reply
* [PATCH 2/2] ARM: move mmiocpy/mmioset exports to io.c
From: Arnd Bergmann @ 2016-11-22 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122110557.1533467-1-arnd@arndb.de>
The prototypes for mmioset/mmiocpy are intentionally hidden
inside of inline functions, which breaks the EXPORT_SYMBOL
statements when symbol versioning is enabled.
This moves the two exports from the files that implement the
code into the kernel/io.c file, adding another local declaration
there.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/kernel/io.c | 7 +++++++
arch/arm/lib/memcpy.S | 1 -
arch/arm/lib/memset.S | 1 -
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/io.c b/arch/arm/kernel/io.c
index eedefe050022..c74746997626 100644
--- a/arch/arm/kernel/io.c
+++ b/arch/arm/kernel/io.c
@@ -82,3 +82,10 @@ void _memset_io(volatile void __iomem *dst, int c, size_t count)
}
}
EXPORT_SYMBOL(_memset_io);
+
+/* can't export them from memcpy.S/memset.S because of hidden declaration */
+void mmioset(void __iomem *addr, unsigned int c, size_t n);
+EXPORT_SYMBOL(mmioset);
+
+void mmiocpy(void *dest, const void __iomem *src, size_t n);
+EXPORT_SYMBOL(mmiocpy);
diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index 1be5b6ddf37c..1f822fc52400 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -70,4 +70,3 @@ ENTRY(memcpy)
ENDPROC(memcpy)
ENDPROC(mmiocpy)
EXPORT_SYMBOL(memcpy)
-EXPORT_SYMBOL(mmiocpy)
diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S
index 7b72044cba62..6f075ca09abc 100644
--- a/arch/arm/lib/memset.S
+++ b/arch/arm/lib/memset.S
@@ -137,4 +137,3 @@ UNWIND( .fnend )
ENDPROC(memset)
ENDPROC(mmioset)
EXPORT_SYMBOL(memset)
-EXPORT_SYMBOL(mmioset)
--
2.9.0
^ permalink raw reply related
* [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
From: Arnd Bergmann @ 2016-11-22 11:05 UTC (permalink / raw)
To: linux-arm-kernel
This adds an asm/asm-prototypes.h header for ARM to fix the broken symbol
versioning for symbols exported from assembler files.
I couldn't find the correct prototypes for the compiler builtins,
so I went with the fake 'void f(void)' prototypes that we had
before, restoring the state before they were moved.
Originally I assumed that the problem was just a harmless warning
in unusual configurations, but as Uwe found, we actually need this
to load most modules when symbol versioning is enabled, as it is
in many distro kernels.
Cc: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
Fixes: 4dd1837d7589 ("arm: move exports to definitions")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Compared to the earlier version, I dropped the changes to the
csumpartial files, which now get handled correctly by Kbuild
even when the export comes from a macro, and I also dropped the
changes to the bitops files, which were already fixed in a
patch from Nico.
The patch applies cleanly on top of the rmk/fixes tree but has
no effect there, as it also needs 4efca4ed05cb ("kbuild: modversions
for EXPORT_SYMBOL() for asm") and cc6acc11cad1 ("kbuild: be more
careful about matching preprocessed asm ___EXPORT_SYMBOL").
With the combination of rmk/fixes, torvalds/master and these two
patches, symbol versioning works again on ARM. As it is still
broken on almost all other architectures (powerpc is fixed,
x86 has a patch), I wonder if we should make CONFIG_MODVERSIONS
as broken for everything else.
---
arch/arm/include/asm/asm-prototypes.h | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
create mode 100644 arch/arm/include/asm/asm-prototypes.h
diff --git a/arch/arm/include/asm/asm-prototypes.h b/arch/arm/include/asm/asm-prototypes.h
new file mode 100644
index 000000000000..04e5616a7b15
--- /dev/null
+++ b/arch/arm/include/asm/asm-prototypes.h
@@ -0,0 +1,34 @@
+#include <linux/arm-smccc.h>
+#include <linux/bitops.h>
+#include <linux/ftrace.h>
+#include <linux/io.h>
+#include <linux/platform_data/asoc-imx-ssi.h>
+#include <linux/string.h>
+#include <linux/uaccess.h>
+
+#include <asm/checksum.h>
+#include <asm/div64.h>
+#include <asm/memory.h>
+
+extern void __aeabi_idivmod(void);
+extern void __aeabi_idiv(void);
+extern void __aeabi_lasr(void);
+extern void __aeabi_llsl(void);
+extern void __aeabi_llsr(void);
+extern void __aeabi_lmul(void);
+extern void __aeabi_uidivmod(void);
+extern void __aeabi_uidiv(void);
+extern void __aeabi_ulcmp(void);
+
+extern void __ashldi3(void);
+extern void __ashrdi3(void);
+extern void __bswapdi2(void);
+extern void __bswapsi2(void);
+extern void __divsi3(void);
+extern void __do_div64(void);
+extern void __lshrdi3(void);
+extern void __modsi3(void);
+extern void __muldi3(void);
+extern void __ucmpdi2(void);
+extern void __udivsi3(void);
+extern void __umodsi3(void);
--
2.9.0
^ permalink raw reply related
* [PATCH 8/9] mtd: nand: mxc: implement onfi get/set features
From: Boris Brezillon @ 2016-11-22 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122105253.tzz2hvzhkse7telr@pengutronix.de>
On Tue, 22 Nov 2016 11:52:53 +0100
Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Hi Boris,
>
> On Mon, Nov 21, 2016 at 02:56:43PM +0100, Boris Brezillon wrote:
> > Hi Sascha,
> >
> > On Thu, 15 Sep 2016 10:32:52 +0200
> > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >
> > > To be able to support different ONFI timing modes we have to implement
> > > the onfi_set_features and onfi_get_features. Tested on an i.MX25 SoC.
> > >
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > ---
> > > drivers/mtd/nand/mxc_nand.c | 53 +++++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 53 insertions(+)
> > >
> > > diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> > > index 5173fad..1db8299 100644
> > > --- a/drivers/mtd/nand/mxc_nand.c
> > > +++ b/drivers/mtd/nand/mxc_nand.c
> > > @@ -1239,6 +1239,57 @@ static void mxc_nand_command(struct mtd_info *mtd, unsigned command,
> > > }
> > > }
> > >
> > > +static int mxc_nand_onfi_set_features(struct mtd_info *mtd, struct nand_chip *chip,
> > > + int addr, uint8_t *subfeature_param)
> > > +{
> > > + struct nand_chip *nand_chip = mtd_to_nand(mtd);
> > > + struct mxc_nand_host *host = nand_get_controller_data(nand_chip);
> > > + int i;
> > > +
> > > + if (!chip->onfi_version ||
> > > + !(le16_to_cpu(chip->onfi_params.opt_cmd)
> > > + & ONFI_OPT_CMD_SET_GET_FEATURES))
> > > + return -EINVAL;
> > > +
> > > + host->buf_start = 0;
> > > +
> > > + for (i = 0; i < ONFI_SUBFEATURE_PARAM_LEN; ++i)
> > > + chip->write_byte(mtd, subfeature_param[i]);
> > > +
> > > + memcpy32_toio(host->main_area0, host->data_buf, mtd->writesize);
> > > + host->devtype_data->send_cmd(host, NAND_CMD_SET_FEATURES, false);
> > > + mxc_do_addr_cycle(mtd, addr, -1);
> > > + host->devtype_data->send_page(mtd, NFC_INPUT);
> >
> > I've been working with an mx27 board embedding a NAND device lately,
> > and had a closer look at the NAND controller IP.
> > With this IP, you're not able to send only 4 bytes of data, and I'm
> > sure sure what you're doing here (sending a full page of data) works
> > for a SET_FEATURE command.
> >
> > Do you have a way to test it (my NAND is not ONFI compliant)? By test
> > it, I mean, set a timing mode using SET_FEATURE and check if the new
> > mode has been applied using GET_FEATURE.
>
> I have an i.MX27 board with ONFI flash, but this one does not have the
> ONFI_OPT_CMD_SET_GET_FEATURES bit set, so I can't test it there.
> However, I can confirm that it works on an i.MX25. With the attached
> patch applied on vanilla v4.9-rc5 I get:
>
> GET FEATURES. chip->onfi_timing_mode_default: 4
> timing before: 0x00
> timing after: 0x04
Okay, cool. I guess most NANDs are more tolerant than what's strictly
required in the ONFI spec.
Thanks for testing.
Boris
^ permalink raw reply
* [PATCH 1/3] of: base: add support to get machine compatible string
From: Bartosz Golaszewski @ 2016-11-22 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJU=wR4mdQr5tpNSv8POirtWXR=_s7D_Q_H=Cuy=W=-Jtw@mail.gmail.com>
2016-11-22 11:57 GMT+01:00 Bartosz Golaszewski <bgolaszewski@baylibre.com>:
> 2016-11-22 11:53 GMT+01:00 Sudeep Holla <sudeep.holla@arm.com>:
>>
>>
>> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>>>
>>> Add a function allowing to retrieve the compatible string of the root
>>> node of the device tree.
>>>
>>
>> Rob has queued [1] and it's in -next today. You can reuse that if you
>> are planning to target this for v4.11 or just use open coding in your
>> driver for v4.10 and target this move for v4.11 to avoid cross tree
>> dependencies as I already mentioned in your previous thread.
>>
>> --
>> Regards,
>> Sudeep
>>
>> [1] http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1274549.html
>
> Rob's patch checks the model first - I'm not sure this is the behavior
> we want here as Sekhar suggested we print the machine compatible.
>
I meant your patch of course.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH 1/3] of: base: add support to get machine compatible string
From: Bartosz Golaszewski @ 2016-11-22 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5ce9fb9f-459a-562b-2e9f-85d35f9ec035@arm.com>
2016-11-22 11:53 GMT+01:00 Sudeep Holla <sudeep.holla@arm.com>:
>
>
> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>>
>> Add a function allowing to retrieve the compatible string of the root
>> node of the device tree.
>>
>
> Rob has queued [1] and it's in -next today. You can reuse that if you
> are planning to target this for v4.11 or just use open coding in your
> driver for v4.10 and target this move for v4.11 to avoid cross tree
> dependencies as I already mentioned in your previous thread.
>
> --
> Regards,
> Sudeep
>
> [1] http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1274549.html
Rob's patch checks the model first - I'm not sure this is the behavior
we want here as Sekhar suggested we print the machine compatible.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH v2] mfd: twl-core: make driver DT only
From: Nicolae Rosia @ 2016-11-22 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122104510.iujd5revibqgbldl@tarshish>
Hi,
On Tue, Nov 22, 2016 at 12:45 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Nicolae,
>
>
> Can struct twl4030_platform_data declaration be removed now from
> include/linux/i2c/twl.h?
>
> baruch
>
Yes, I have the patches ready and plan on doing that in the next cycle.
I have been sending multiple patches to convert twl related drivers to
DT only and I don't want to create merge conflicts on twl.h
Thanks,
Nicolae
^ permalink raw reply
* [PATCH 1/3] of: base: add support to get machine compatible string
From: Sudeep Holla @ 2016-11-22 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479811311-3080-2-git-send-email-bgolaszewski@baylibre.com>
On 22/11/16 10:41, Bartosz Golaszewski wrote:
> Add a function allowing to retrieve the compatible string of the root
> node of the device tree.
>
Rob has queued [1] and it's in -next today. You can reuse that if you
are planning to target this for v4.11 or just use open coding in your
driver for v4.10 and target this move for v4.11 to avoid cross tree
dependencies as I already mentioned in your previous thread.
--
Regards,
Sudeep
[1] http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1274549.html
^ permalink raw reply
* [PATCH 8/9] mtd: nand: mxc: implement onfi get/set features
From: Sascha Hauer @ 2016-11-22 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121145643.7804e28f@bbrezillon>
Hi Boris,
On Mon, Nov 21, 2016 at 02:56:43PM +0100, Boris Brezillon wrote:
> Hi Sascha,
>
> On Thu, 15 Sep 2016 10:32:52 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> > To be able to support different ONFI timing modes we have to implement
> > the onfi_set_features and onfi_get_features. Tested on an i.MX25 SoC.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > drivers/mtd/nand/mxc_nand.c | 53 +++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 53 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> > index 5173fad..1db8299 100644
> > --- a/drivers/mtd/nand/mxc_nand.c
> > +++ b/drivers/mtd/nand/mxc_nand.c
> > @@ -1239,6 +1239,57 @@ static void mxc_nand_command(struct mtd_info *mtd, unsigned command,
> > }
> > }
> >
> > +static int mxc_nand_onfi_set_features(struct mtd_info *mtd, struct nand_chip *chip,
> > + int addr, uint8_t *subfeature_param)
> > +{
> > + struct nand_chip *nand_chip = mtd_to_nand(mtd);
> > + struct mxc_nand_host *host = nand_get_controller_data(nand_chip);
> > + int i;
> > +
> > + if (!chip->onfi_version ||
> > + !(le16_to_cpu(chip->onfi_params.opt_cmd)
> > + & ONFI_OPT_CMD_SET_GET_FEATURES))
> > + return -EINVAL;
> > +
> > + host->buf_start = 0;
> > +
> > + for (i = 0; i < ONFI_SUBFEATURE_PARAM_LEN; ++i)
> > + chip->write_byte(mtd, subfeature_param[i]);
> > +
> > + memcpy32_toio(host->main_area0, host->data_buf, mtd->writesize);
> > + host->devtype_data->send_cmd(host, NAND_CMD_SET_FEATURES, false);
> > + mxc_do_addr_cycle(mtd, addr, -1);
> > + host->devtype_data->send_page(mtd, NFC_INPUT);
>
> I've been working with an mx27 board embedding a NAND device lately,
> and had a closer look at the NAND controller IP.
> With this IP, you're not able to send only 4 bytes of data, and I'm
> sure sure what you're doing here (sending a full page of data) works
> for a SET_FEATURE command.
>
> Do you have a way to test it (my NAND is not ONFI compliant)? By test
> it, I mean, set a timing mode using SET_FEATURE and check if the new
> mode has been applied using GET_FEATURE.
I have an i.MX27 board with ONFI flash, but this one does not have the
ONFI_OPT_CMD_SET_GET_FEATURES bit set, so I can't test it there.
However, I can confirm that it works on an i.MX25. With the attached
patch applied on vanilla v4.9-rc5 I get:
GET FEATURES. chip->onfi_timing_mode_default: 4
timing before: 0x00
timing after: 0x04
Sascha
-------------------------8<-------------------------------
>From 38e45851a796ba47e25c72ebc58e358c70e18275 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Tue, 22 Nov 2016 11:48:36 +0100
Subject: [PATCH] wip
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/mtd/nand/nand_base.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 3bde96a..5b5be2b 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1017,12 +1017,24 @@ static int nand_setup_data_interface(struct nand_chip *chip)
u8 tmode_param[ONFI_SUBFEATURE_PARAM_LEN] = {
chip->onfi_timing_mode_default,
};
+ u8 rmode_param[ONFI_SUBFEATURE_PARAM_LEN] = {};
+
+ printk("GET FEATURES. chip->onfi_timing_mode_default: %d\n", chip->onfi_timing_mode_default);
+ ret = chip->onfi_get_features(mtd, chip, ONFI_FEATURE_ADDR_TIMING_MODE, rmode_param);
+ if (ret)
+ goto err;
+ printk("timing before: 0x%02x\n", rmode_param[0]);
ret = chip->onfi_set_features(mtd, chip,
ONFI_FEATURE_ADDR_TIMING_MODE,
tmode_param);
if (ret)
goto err;
+
+ ret = chip->onfi_get_features(mtd, chip, ONFI_FEATURE_ADDR_TIMING_MODE, rmode_param);
+ if (ret)
+ goto err;
+ printk("timing after: 0x%02x\n", rmode_param[0]);
}
ret = chip->setup_data_interface(mtd, chip->data_interface, false);
--
2.10.2
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox