* [PATCH 7/7] ARM: dts: NSP: Add SD/MMC support
From: Jon Mason @ 2016-12-13 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481652831-2744-1-git-send-email-jon.mason@broadcom.com>
Add SD/MMC support to the Broadcom NSP SVK and XMC.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 9 +++
arch/arm/boot/dts/bcm958525xmc.dts | 6 +-
arch/arm/boot/dts/bcm958625k.dts | 118 ++++++++++++++++++++++++-------------
3 files changed, 90 insertions(+), 43 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index ecffc16..6c58c78 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -209,6 +209,15 @@
#dma-cells = <1>;
};
+ sdio: sdhci at 21000 {
+ compatible = "brcm,sdhci-iproc-cygnus";
+ reg = <0x21000 0x100>;
+ interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
+ sdhci,auto-cmd12;
+ clocks = <&lcpll0 BCM_NSP_LCPLL0_SDIO_CLK>;
+ status = "disabled";
+ };
+
amac0: ethernet at 22000 {
compatible = "brcm,nsp-amac";
reg = <0x022000 0x1000>,
diff --git a/arch/arm/boot/dts/bcm958525xmc.dts b/arch/arm/boot/dts/bcm958525xmc.dts
index 3912269..41e7fd3 100644
--- a/arch/arm/boot/dts/bcm958525xmc.dts
+++ b/arch/arm/boot/dts/bcm958525xmc.dts
@@ -59,7 +59,7 @@
};
};
-/* XHCI and SD/MMC support needed to be complete */
+/* XHCI support needed to be complete */
&amac0 {
status = "okay";
@@ -184,6 +184,10 @@
status = "okay";
};
+&sdio {
+ status = "ok";
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm958625k.dts b/arch/arm/boot/dts/bcm958625k.dts
index 6e994f2..f8d47e5 100644
--- a/arch/arm/boot/dts/bcm958625k.dts
+++ b/arch/arm/boot/dts/bcm958625k.dts
@@ -117,58 +117,34 @@
&pinctrl {
pinctrl-names = "default";
- pinctrl-0 = <&nand_sel>;
+ pinctrl-0 = <&nand_sel>, <&gpiobs>, <&pwmc>;
+
nand_sel: nand_sel {
function = "nand";
groups = "nand_grp";
};
-};
-
-&srab {
- compatible = "brcm,bcm58625-srab", "brcm,nsp-srab";
- status = "okay";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- label = "port0";
- reg = <0>;
- };
-
- port at 1 {
- label = "port1";
- reg = <1>;
- };
-
- port at 2 {
- label = "port2";
- reg = <2>;
- };
- port at 3 {
- label = "port3";
- reg = <3>;
- };
+ gpiobs: gpiobs {
+ function = "gpio_b";
+ groups = "gpio_b_0_grp", "gpio_b_1_grp", "gpio_b_2_grp",
+ "gpio_b_3_grp";
+ };
- port at 4 {
- label = "port4";
- reg = <4>;
- };
+ pwmc: pwmc {
+ function = "pwm";
+ groups = "pwm0_grp", "pwm1_grp", "pwm2_grp", "pwm3_grp";
+ };
- port at 5 {
- ethernet = <&amac0>;
- label = "cpu";
- reg = <5>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
+ emmc_sel: emmc_sel {
+ function = "emmc";
+ groups = "emmc_grp";
};
};
+&pwm {
+ status = "okay";
+};
+
&qspi {
bspi-sel = <0>;
flash: m25p80 at 0 {
@@ -215,6 +191,64 @@
status = "okay";
};
+/*
+ * By default the sd slot is functional. For emmc to work add "<&emmc_sel>"
+ * and delete "<&nand_sel>" in "pinctrl-0" property of pinctrl node. Remove the
+ * bus-width property here and disable the nand node with status = "disabled";.
+ *
+ * Ex: pinctrl-0 = <&emmc_sel>, <&gpiobs>, <&pwmc>;
+ */
+&sdio {
+ bus-width = <4>;
+ no-1-8-v;
+ status = "ok";
+};
+
+&srab {
+ compatible = "brcm,bcm58625-srab", "brcm,nsp-srab";
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ label = "port0";
+ reg = <0>;
+ };
+
+ port at 1 {
+ label = "port1";
+ reg = <1>;
+ };
+
+ port at 2 {
+ label = "port2";
+ reg = <2>;
+ };
+
+ port at 3 {
+ label = "port3";
+ reg = <3>;
+ };
+
+ port at 4 {
+ label = "port4";
+ reg = <4>;
+ };
+
+ port at 5 {
+ ethernet = <&amac0>;
+ label = "cpu";
+ reg = <5>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+};
+
&uart0 {
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH V8 3/3] irqchip: qcom: Add IRQ combiner driver
From: Joe Perches @ 2016-12-13 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <78bfd90d47200347628f7dd98451122f@codeaurora.org>
On Tue, 2016-12-13 at 10:23 -0500, Agustin Vega-Frias wrote:
> On 2016-12-07 13:16, Marc Zyngier wrote:
> > > + }
> > > +
> > > + combiner->domain = irq_domain_create_linear(
> > > + pdev->dev.fwnode, combiner->nirqs, &domain_ops, combiner);
> >
> > On a single line, please. Do no listen to the checkpatch police that
> > will tell you otherwise. It really hurt my eyes to see this opening
> > bracket and *nothing* after that.
>
> Will do.
It seems generally preferred to have at least one argument on the
same line as the function being called.
So, here are some options:
Maximally fill the lines to 80 columns with the value being set
and function call while aligning to open parenthesis
combiner->domain = irq_domain_create_linear(pdev->dev.fwnode,
combiner->nirqs,
&domain_ops, combiner);
Use a separate line for the function call:
combiner->domain =
irq_domain_create_linear(pdev->dev.fwnode, combiner->nirqs,
&domain_ops, combiner);
Or just ignore the 80 column limit wherever you deem appropriate.
No single style is universal, use what you think best.
Anyway, long identifiers (24 chars here) make staying within the
"strongly preferred" 80 column limit produce quite silly looking
code.
^ permalink raw reply
* [RFC v2 PATCH 0/3] Fix dma_alloc_coherent() and friends for NOMMU
From: Robin Murphy @ 2016-12-13 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58500D86.4070600@arm.com>
On 13/12/16 15:02, Vladimir Murzin wrote:
> On 13/12/16 14:25, Robin Murphy wrote:
>> On 13/12/16 14:14, Vladimir Murzin wrote:
>>> On 13/12/16 14:07, Russell King - ARM Linux wrote:
>>>> On Tue, Dec 13, 2016 at 01:45:01PM +0000, Vladimir Murzin wrote:
>>>>> This patch set is trying to address the issue by providing region of
>>>>> memory suitable for consistent DMA operations. It is supposed that such
>>>>> region is marked by MPU as non-cacheable. Since we have MPU support in
>>>>> Linux for R-class only and M-class setting MPU in bootloader, proposed
>>>>> interface to advertise such memory is via "memdma=size at start" command
>>>>> line option, to avoid clashing with normal memory (which usually comes
>>>>> from dts) it'd be safer to use it together with "mem=" command line
>>>>> option. Meanwhile, I'm open to suggestions for the better way telling
>>>>> Linux of such memory.
>>>>
>>>> For those nommu systems where the MPU is not used, how do they allocate
>>>> DMA memory without setting aside a chunk of memory?
>>>>
>>>> >From what I understand of the current nommu code, it would just use
>>>> the normal page allocator for DMA memory allocation, so now requiring
>>>> everything to fit the "nommu has mpu" case seems like it's going to
>>>> break older nommu.
>>>>
>>>
>>> Probably, it'd be better if we just fallback to dma-noop operations if there
>>> is no dma region, i.e. assume that platform is coherent. We still need a way
>>> to tell user that absence of such region can be reason of broken DMA.
>>
>> As I mentioned internally, I think it would be worth trying to use CMA
>> for this, because dma_map_ops are already wired to try that first, and
>> from what I can see it seems already set up to do precisely this via a
>> "shared-dma-pool" reserved memory region (see rmem_cma_setup() in
>> drivers/base/dma-contiguous.c) - mandating that for cached v7-M systems
>> whilst letting cache-less/non-MPU systems automatically fall back to the
>> normal page allocator in its absence would seem to solve all 3 cases.
>
> Unfortunately,
>
> config DMA_CMA
> bool "DMA Contiguous Memory Allocator"
> depends on HAVE_DMA_CONTIGUOUS && CMA
> help
> ...
> config CMA
> bool "Contiguous Memory Allocator"
> depends on HAVE_MEMBLOCK && MMU
> select MIGRATION
>
> and it blows up if I remove dependecy on MMU :(
Ah yes, fair enough.
> Another option would be drivers/base/dma-coherent.c, but, IIUC, in this case
> memory is reserved per device exclusively, so I'm in doubt if tiny M-class can
> afford that...
I think as usual I managed to conflate the two - it was actually
dma_alloc_from_coherent() I had in mind when I mentioned dma_map_ops. It
does seem from 7bfa5ab6fa1b that dma-coherent *can* handle multiple
devices per region, so it wouldn't appear to be too hard to implement a
default coherent region (possibly specific to ARM_MPU) for all devices
in a similar manner to the default contiguous region. Either way I do
still think a reserved memory region in the DT is nicer and probably
more robust than the command line parameter.
Robin.
>> Other than the allocator issue, though, the rest of the refactoring does
>> look nice.
>
> Thanks for going through it!
>
> Cheers
> Vladimir
^ permalink raw reply
* [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM
From: Afzal Mohammed @ 2016-12-13 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213100226.GW14217@n2100.armlinux.org.uk>
Hi,
On Tue, Dec 13, 2016 at 10:02:26AM +0000, Russell King - ARM Linux wrote:
> On Sun, Dec 11, 2016 at 06:42:55PM +0530, Afzal Mohammed wrote:
> > bic r0, r0, #CR_V
> > #endif
> > mcr p15, 0, r0, c1, c0, 0 @ write control reg
> > +
> > +#ifdef CONFIG_REMAP_VECTORS_TO_RAM
> > + mov r3, #CONFIG_VECTORS_BASE @ read VECTORS_BASE
> > + mcr p15, 0, r3, c12, c0, 0 @ write to VBAR
> > +#endif
> > +
> Is there really any need to do this in head.S ?
Seeing the high vector configuration done here, pounced upon it :)
> I believe it's
> entirely possible to do it later - arch/arm/mm/nommu.c:paging_init().
>
> Also, if the region setup for the vectors was moved as well, it would
> then be possible to check the ID registers to determine whether this
> is supported, and make the decision where to locate the vectors base
> more dynamically.
i will look into it.
Regards
afzal
^ permalink raw reply
* [PATCH V6 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64
From: Baicar, Tyler @ 2016-12-13 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86258A5CC0A3704780874CF6004BA8A62DC9A081@lhreml502-mbs>
Hello Shiju,
Great! Thank you for testing! :)
Tyler
On 12/13/2016 4:10 AM, Shiju Jose wrote:
> Hi Tyler,
>
> We have tested V6 patch set on our platform. It worked fine.
>
> Thanks,
> Shiju
>
>> -----Original Message-----
>> From: Tyler Baicar [mailto:tbaicar at codeaurora.org]
>> Sent: 07 December 2016 21:48
>> To: christoffer.dall at linaro.org; marc.zyngier at arm.com;
>> pbonzini at redhat.com; rkrcmar at redhat.com; linux at armlinux.org.uk;
>> catalin.marinas at arm.com; will.deacon at arm.com; rjw at rjwysocki.net;
>> lenb at kernel.org; matt at codeblueprint.co.uk; robert.moore at intel.com;
>> lv.zheng at intel.com; nkaje at codeaurora.org; zjzhang at codeaurora.org;
>> mark.rutland at arm.com; james.morse at arm.com; akpm at linux-foundation.org;
>> eun.taik.lee at samsung.com; sandeepa.s.prabhu at gmail.com;
>> labbott at redhat.com; shijie.huang at arm.com; rruigrok at codeaurora.org;
>> paul.gortmaker at windriver.com; tn at semihalf.com; fu.wei at linaro.org;
>> rostedt at goodmis.org; bristot at redhat.com; linux-arm-
>> kernel at lists.infradead.org; kvmarm at lists.cs.columbia.edu;
>> kvm at vger.kernel.org; linux-kernel at vger.kernel.org; linux-
>> acpi at vger.kernel.org; linux-efi at vger.kernel.org; devel at acpica.org;
>> Suzuki.Poulose at arm.com; punit.agrawal at arm.com; astone at redhat.com;
>> harba at codeaurora.org; hanjun.guo at linaro.org; John Garry; Shiju Jose
>> Cc: Tyler Baicar
>> Subject: [PATCH V6 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on
>> ARM64
>>
>> 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 v15] acpi, apei, arm64: APEI initial support for
>> aarch64.
>> https://lkml.org/lkml/2016/12/1/312
>>
>> V6: Change HEST_TYPE_GENERIC_V2 to IS_HEST_TYPE_GENERIC_V2 for
>> readability
>> Move APEI helper defines from cper.h to ghes.h
>> Add data_len decrement back into print loop
>> Change references to ARMv8 to just ARM
>> Rewrite ARM processor context info parsing
>> Check valid bit of ARM error info field before printing it
>> Add include of linux/uuid.h in ghes.c
>>
>> 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 ARM 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 | 189
>> +++++++++++++++++++++++++++++---
>> drivers/acpi/apei/hest.c | 7 +-
>> drivers/firmware/efi/cper.c | 204
>> ++++++++++++++++++++++++++++++++---
>> drivers/ras/ras.c | 2 +
>> include/acpi/ghes.h | 27 ++++-
>> include/linux/cper.h | 53 +++++++++
>> include/ras/ras_event.h | 100 +++++++++++++++++
>> 15 files changed, 664 insertions(+), 44 deletions(-)
>>
>> --
>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
>> Technologies, Inc.
>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
>> Linux Foundation Collaborative Project.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V8 3/3] irqchip: qcom: Add IRQ combiner driver
From: Marc Zyngier @ 2016-12-13 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481653317.29291.19.camel@perches.com>
On 13/12/16 18:21, Joe Perches wrote:
> On Tue, 2016-12-13 at 10:23 -0500, Agustin Vega-Frias wrote:
>> On 2016-12-07 13:16, Marc Zyngier wrote:
>>>> + }
>>>> +
>>>> + combiner->domain = irq_domain_create_linear(
>>>> + pdev->dev.fwnode, combiner->nirqs, &domain_ops, combiner);
>>>
>>> On a single line, please. Do no listen to the checkpatch police that
>>> will tell you otherwise. It really hurt my eyes to see this opening
>>> bracket and *nothing* after that.
>>
>> Will do.
>
> It seems generally preferred to have at least one argument on the
> same line as the function being called.
>
> So, here are some options:
>
> Maximally fill the lines to 80 columns with the value being set
> and function call while aligning to open parenthesis
>
> combiner->domain = irq_domain_create_linear(pdev->dev.fwnode,
> combiner->nirqs,
> &domain_ops, combiner);
I can live with something like this.
> Use a separate line for the function call:
>
> combiner->domain =
> irq_domain_create_linear(pdev->dev.fwnode, combiner->nirqs,
> &domain_ops, combiner);
But I find this one pretty horrid.
> Or just ignore the 80 column limit wherever you deem appropriate.
Which is my usual advise. I consider the 80 column rule a good way of
limiting the complexity of code (if the nesting pushes you too far on
the right of the screen, you're doing something wrong), but not for
simple statements such as this one.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM
From: Afzal Mohammed @ 2016-12-13 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <584FC18D.2050908@arm.com>
Hi,
On Tue, Dec 13, 2016 at 09:38:21AM +0000, Vladimir Murzin wrote:
> On 11/12/16 13:12, Afzal Mohammed wrote:
> > this probably would have to be made robust so as to not cause issue on
> > other v7-A's upon trying to do !MMU (this won't affect normal MMU boot),
> > or specifically where security extensions are not enabled. Also effect
> > of hypervisor extension also need to be considered. Please let know if
> > any better ways to handle this.
> You might need to check ID_PFR1 for that.
Had been searching ARM ARM for this kind of a thing, thanks.
> > +#ifdef CONFIG_REMAP_VECTORS_TO_RAM
> > + mov r3, #CONFIG_VECTORS_BASE @ read VECTORS_BASE
> ldr r3,=CONFIG_VECTORS_BASE
>
> would be more robust. I hit this in [1]
>
> [1] https://www.spinics.net/lists/arm-kernel/msg546825.html
Russell suggested doing it in paging_init(), then probably assembly
circus can be avoided.
Regards
afzal
^ permalink raw reply
* [PATCH V7 5/8] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED
From: Sricharan @ 2016-12-13 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e6ebf88-0138-afce-d752-56b66d69772f@arm.com>
Hi Robin,
<snip..>
>>>>> return prot | IOMMU_READ | IOMMU_WRITE;
>>>>
>>>> ...and applying against -next now also needs this hunk:
>>>>
>>>> @@ -639,7 +639,7 @@ dma_addr_t iommu_dma_map_resource(struct device
>>>> *dev, phys_addr_t phys,
>>>> size_t size, enum dma_data_direction dir, unsigned long attrs)
>>>> {
>>>> return __iommu_dma_map(dev, phys, size,
>>>> - dma_direction_to_prot(dir, false) | IOMMU_MMIO);
>>>> + dma_info_to_prot(dir, false, attrs) | IOMMU_MMIO);
>>>> }
>>>>
>>>> void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>>>>
>>>> With those two issues fixed up, I've given the series (applied to
>>>> next-20161213) a spin on a SMMUv3/PL330 fast model and it still checks out.
>>>>
>>>
>>> oops, sorry that i missed this in rebase. I can repost now with this fixed,
>>> 'checks out' you mean something is not working correct ?
>>
>>No, I mean it _is_ still correct - I guess that's more of an idiom than
>>I thought :)
>>
>
>ha ok, thanks for the testing as well. I will just send a v8 with those two fixed now.
Just while checking that i have not missed anything else, realized that the
dma-mapping apis in arm as to be modified to pass the PRIVILIGED attributes
as well. While my testing path was using the iommu_map directly i was not
seeing this, but then i did a patch like below. I will just figure out another
other codebase where the master uses the dma apis, test and add it in the
V8 that i would send.
From: Sricharan R <sricharan@codeaurora.org>
Date: Tue, 13 Dec 2016 23:25:01 +0530
Subject: [PATCH V8 6/9] arm/dma-mapping: Implement DMA_ATTR_PRIVILEGED
The newly added DMA_ATTR_PRIVILEGED is useful for creating mappings that
are only accessible to privileged DMA engines. Implementing it in dma-mapping
for it to get used from the dma mappings apis.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
arch/arm/mm/dma-mapping.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ab77100..e0d9923 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1394,7 +1394,8 @@ static int __iommu_free_buffer(struct device *dev, struct page **pages,
* Create a mapping in device IO address space for specified pages
*/
static dma_addr_t
-__iommu_create_mapping(struct device *dev, struct page **pages, size_t size)
+__iommu_create_mapping(struct device *dev, struct page **pages, size_t size,
+ unsigned long attrs)
{
struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
@@ -1419,7 +1420,7 @@ static int __iommu_free_buffer(struct device *dev, struct page **pages,
len = (j - i) << PAGE_SHIFT;
ret = iommu_map(mapping->domain, iova, phys, len,
- IOMMU_READ|IOMMU_WRITE);
+ __dma_info_to_prot(DMA_BIRECTIONAL, attrs));
if (ret < 0)
goto fail;
iova += len;
@@ -1476,7 +1477,8 @@ static struct page **__iommu_get_pages(void *cpu_addr, unsigned long attrs)
}
static void *__iommu_alloc_simple(struct device *dev, size_t size, gfp_t gfp,
- dma_addr_t *handle, int coherent_flag)
+ dma_addr_t *handle, int coherent_flag,
+ unsigned long attrs)
{
struct page *page;
void *addr;
@@ -1488,7 +1490,7 @@ static void *__iommu_alloc_simple(struct device *dev, size_t size, gfp_t gfp,
if (!addr)
return NULL;
- *handle = __iommu_create_mapping(dev, &page, size);
+ *handle = __iommu_create_mapping(dev, &page, size, attrs);
if (*handle == DMA_ERROR_CODE)
goto err_mapping;
@@ -1522,7 +1524,8 @@ static void *__arm_iommu_alloc_attrs(struct device *dev, size_t size,
if (coherent_flag == COHERENT || !gfpflags_allow_blocking(gfp))
return __iommu_alloc_simple(dev, size, gfp, handle,
- coherent_flag);
+ coherent_flag,
+ attrs);
/*
* Following is a work-around (a.k.a. hack) to prevent pages
@@ -1672,10 +1675,13 @@ static int arm_iommu_get_sgtable(struct device *dev, struct sg_table *sgt,
GFP_KERNEL);
}
-static int __dma_direction_to_prot(enum dma_data_direction dir)
+static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs)
{
int prot;
+ if (attrs & DMA_ATTR_PRIVILEGED)
+ prot |= IOMMU_PRIV;
+
switch (dir) {
case DMA_BIDIRECTIONAL:
prot = IOMMU_READ | IOMMU_WRITE;
@@ -1722,7 +1728,7 @@ static int __map_sg_chunk(struct device *dev, struct scatterlist *sg,
if (!is_coherent && (attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_page_cpu_to_dev(sg_page(s), s->offset, s->length, dir);
- prot = __dma_direction_to_prot(dir);
+ prot = __dma_info_to_prot(dir, attrs);
ret = iommu_map(mapping->domain, iova, phys, len, prot);
if (ret < 0)
@@ -1930,7 +1936,7 @@ static dma_addr_t arm_coherent_iommu_map_page(struct device *dev, struct page *p
if (dma_addr == DMA_ERROR_CODE)
return dma_addr;
- prot = __dma_direction_to_prot(dir);
+ prot = __dma_info_to_prot(dir, attrs);
ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len, prot);
if (ret < 0)
@@ -2036,7 +2042,7 @@ static dma_addr_t arm_iommu_map_resource(struct device *dev,
if (dma_addr == DMA_ERROR_CODE)
return dma_addr;
- prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
+ prot = __dma_info_to_prot(dir, attrs) | IOMMU_MMIO;
ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
if (ret < 0)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Regards,
Sricharan
^ permalink raw reply related
* [PATCH] Input: imx6ul_tsc - generalize the averaging property
From: Rob Herring @ 2016-12-13 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481440003-27168-1-git-send-email-guy.shapiro@mobi-wize.com>
On Sun, Dec 11, 2016 at 09:06:43AM +0200, Guy Shapiro wrote:
> Make the avarage-samples property a general touchscreen property
> rather than imx6ul device specific.
>
> Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
> ---
> .../bindings/input/touchscreen/imx6ul_tsc.txt | 11 ++----
> .../bindings/input/touchscreen/touchscreen.txt | 3 ++
> drivers/input/touchscreen/imx6ul_tsc.c | 46 ++++++++++++++++------
> 3 files changed, 41 insertions(+), 19 deletions(-)
You can't just switch existing bindings as that breaks compatibility
with old dtbs. The kernel driver would need to support both. Just
introduce the new common property and use it for your device.
Rob
^ permalink raw reply
* [PATCH V7 5/8] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED
From: Robin Murphy @ 2016-12-13 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <005f01d25571$3f75b5f0$be6121d0$@codeaurora.org>
On 13/12/16 18:46, Sricharan wrote:
> Hi Robin,
>
> <snip..>
>
>>>>>> return prot | IOMMU_READ | IOMMU_WRITE;
>>>>>
>>>>> ...and applying against -next now also needs this hunk:
>>>>>
>>>>> @@ -639,7 +639,7 @@ dma_addr_t iommu_dma_map_resource(struct device
>>>>> *dev, phys_addr_t phys,
>>>>> size_t size, enum dma_data_direction dir, unsigned long attrs)
>>>>> {
>>>>> return __iommu_dma_map(dev, phys, size,
>>>>> - dma_direction_to_prot(dir, false) | IOMMU_MMIO);
>>>>> + dma_info_to_prot(dir, false, attrs) | IOMMU_MMIO);
>>>>> }
>>>>>
>>>>> void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>>>>>
>>>>> With those two issues fixed up, I've given the series (applied to
>>>>> next-20161213) a spin on a SMMUv3/PL330 fast model and it still checks out.
>>>>>
>>>>
>>>> oops, sorry that i missed this in rebase. I can repost now with this fixed,
>>>> 'checks out' you mean something is not working correct ?
>>>
>>> No, I mean it _is_ still correct - I guess that's more of an idiom than
>>> I thought :)
>>>
>>
>> ha ok, thanks for the testing as well. I will just send a v8 with those two fixed now.
>
> Just while checking that i have not missed anything else, realized that the
> dma-mapping apis in arm as to be modified to pass the PRIVILIGED attributes
> as well. While my testing path was using the iommu_map directly i was not
> seeing this, but then i did a patch like below. I will just figure out another
> other codebase where the master uses the dma apis, test and add it in the
> V8 that i would send.
True, adding support to 32-bit as well can't hurt, and I guess it's
equally relevant to QC's GPU use-case. I haven't considered it myself
because AArch32 is immune to the specific PL330 problem which caught me
out - that subtle corner of VMSAv8 is unique to AArch64.
> From: Sricharan R <sricharan@codeaurora.org>
> Date: Tue, 13 Dec 2016 23:25:01 +0530
> Subject: [PATCH V8 6/9] arm/dma-mapping: Implement DMA_ATTR_PRIVILEGED
>
> The newly added DMA_ATTR_PRIVILEGED is useful for creating mappings that
> are only accessible to privileged DMA engines. Implementing it in dma-mapping
> for it to get used from the dma mappings apis.
>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> ---
> arch/arm/mm/dma-mapping.c | 24 +++++++++++++++---------
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index ab77100..e0d9923 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1394,7 +1394,8 @@ static int __iommu_free_buffer(struct device *dev, struct page **pages,
> * Create a mapping in device IO address space for specified pages
> */
> static dma_addr_t
> -__iommu_create_mapping(struct device *dev, struct page **pages, size_t size)
> +__iommu_create_mapping(struct device *dev, struct page **pages, size_t size,
> + unsigned long attrs)
> {
> struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> @@ -1419,7 +1420,7 @@ static int __iommu_free_buffer(struct device *dev, struct page **pages,
>
> len = (j - i) << PAGE_SHIFT;
> ret = iommu_map(mapping->domain, iova, phys, len,
> - IOMMU_READ|IOMMU_WRITE);
> + __dma_info_to_prot(DMA_BIRECTIONAL, attrs));
> if (ret < 0)
> goto fail;
> iova += len;
> @@ -1476,7 +1477,8 @@ static struct page **__iommu_get_pages(void *cpu_addr, unsigned long attrs)
> }
>
> static void *__iommu_alloc_simple(struct device *dev, size_t size, gfp_t gfp,
> - dma_addr_t *handle, int coherent_flag)
> + dma_addr_t *handle, int coherent_flag,
> + unsigned long attrs)
> {
> struct page *page;
> void *addr;
> @@ -1488,7 +1490,7 @@ static void *__iommu_alloc_simple(struct device *dev, size_t size, gfp_t gfp,
> if (!addr)
> return NULL;
>
> - *handle = __iommu_create_mapping(dev, &page, size);
> + *handle = __iommu_create_mapping(dev, &page, size, attrs);
> if (*handle == DMA_ERROR_CODE)
> goto err_mapping;
>
> @@ -1522,7 +1524,8 @@ static void *__arm_iommu_alloc_attrs(struct device *dev, size_t size,
>
> if (coherent_flag == COHERENT || !gfpflags_allow_blocking(gfp))
> return __iommu_alloc_simple(dev, size, gfp, handle,
> - coherent_flag);
> + coherent_flag,
> + attrs);
Super-nit: unnecessary line break.
>
> /*
> * Following is a work-around (a.k.a. hack) to prevent pages
> @@ -1672,10 +1675,13 @@ static int arm_iommu_get_sgtable(struct device *dev, struct sg_table *sgt,
> GFP_KERNEL);
> }
>
> -static int __dma_direction_to_prot(enum dma_data_direction dir)
> +static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs)
> {
> int prot;
>
> + if (attrs & DMA_ATTR_PRIVILEGED)
> + prot |= IOMMU_PRIV;
> +
> switch (dir) {
> case DMA_BIDIRECTIONAL:
> prot = IOMMU_READ | IOMMU_WRITE;
> @@ -1722,7 +1728,7 @@ static int __map_sg_chunk(struct device *dev, struct scatterlist *sg,
> if (!is_coherent && (attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
> __dma_page_cpu_to_dev(sg_page(s), s->offset, s->length, dir);
>
> - prot = __dma_direction_to_prot(dir);
> + prot = __dma_info_to_prot(dir, attrs);
>
> ret = iommu_map(mapping->domain, iova, phys, len, prot);
> if (ret < 0)
> @@ -1930,7 +1936,7 @@ static dma_addr_t arm_coherent_iommu_map_page(struct device *dev, struct page *p
> if (dma_addr == DMA_ERROR_CODE)
> return dma_addr;
>
> - prot = __dma_direction_to_prot(dir);
> + prot = __dma_info_to_prot(dir, attrs);
>
> ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len, prot);
> if (ret < 0)
> @@ -2036,7 +2042,7 @@ static dma_addr_t arm_iommu_map_resource(struct device *dev,
> if (dma_addr == DMA_ERROR_CODE)
> return dma_addr;
>
> - prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
> + prot = __dma_info_to_prot(dir, attrs) | IOMMU_MMIO;
>
> ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
> if (ret < 0)
>
Looks reasonable to me. Assuming it survives testing:
Acked-by: Robin Murphy <robin.murphy@arm.com>
^ permalink raw reply
* [PATCH 4/6] ARM: dts: sun8i: add opp-v2 table for A33
From: Maxime Ripard @ 2016-12-13 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-5-icenowy@aosc.xyz>
On Tue, Dec 13, 2016 at 11:22:50PM +0800, Icenowy Zheng wrote:
> An operating point table is needed for the cpu frequency adjusting to
> work.
>
> The operating point table is converted from the common value in
> extracted script.fex from many A33 board/tablets.
>
> 1.344GHz is set as a turbo-mode operating point, as it's described as
> "extremity_freq" in the FEX file. (the "max_freq" is 1.2GHz)
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> arch/arm/boot/dts/sun8i-a33.dtsi | 38 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 504996cbee29..035c058324b8 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -46,7 +46,45 @@
> #include <dt-bindings/dma/sun4i-a10.h>
>
> / {
> + cpu0_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp at 648000000 {
> + opp-hz = /bits/ 64 <648000000>;
> + opp-microvolt = <1040000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + };
Please add new lines between the nodes.
> + opp at 816000000 {
> + opp-hz = /bits/ 64 <816000000>;
> + opp-microvolt = <1100000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + };
> + opp at 1008000000 {
> + opp-hz = /bits/ 64 <1008000000>;
> + opp-microvolt = <1200000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + };
> + opp at 1200000000 {
> + opp-hz = /bits/ 64 <1200000000>;
> + opp-microvolt = <1320000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + };
> + opp at 1344000000 {
> + opp-hz = /bits/ 64 <1344000000>;
> + opp-microvolt = <1460000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + turbo-mode;
> + };
As far as I know, this OPP is not used by Allwinner, is not usable in
any A33 board so far (both the A33-olinuxino and the SinA33 do not
allow such a voltage on their CPU regulator), and overvolting and
overclocking is something that is very risky, and might lead to
stability issues.
Please remove this OPP.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20161213/9b08b536/attachment.sig>
^ permalink raw reply
* [PATCH 5/6] ARM: dts: sun8i: set cpu-supply in reference tablet DTSI
From: Maxime Ripard @ 2016-12-13 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-6-icenowy@aosc.xyz>
On Tue, Dec 13, 2016 at 11:22:51PM +0800, Icenowy Zheng wrote:
> All reference design A33 tablets uses DCDC2 of AXP223 as the power
> supply of the Cortex-A7 cores.
>
> Set the cpu-supply in the DTSI of sun8i reference tablets.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20161213/7c630f82/attachment.sig>
^ permalink raw reply
* [PATCH] Input: imx6ul_tsc - generalize the averaging property
From: Dmitry Torokhov @ 2016-12-13 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213191050.3yrmxaubpgjh65bz@rob-hp-laptop>
On December 13, 2016 11:10:50 AM PST, Rob Herring <robh@kernel.org> wrote:
>On Sun, Dec 11, 2016 at 09:06:43AM +0200, Guy Shapiro wrote:
>> Make the avarage-samples property a general touchscreen property
>> rather than imx6ul device specific.
>>
>> Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
>> ---
>> .../bindings/input/touchscreen/imx6ul_tsc.txt | 11 ++----
>> .../bindings/input/touchscreen/touchscreen.txt | 3 ++
>> drivers/input/touchscreen/imx6ul_tsc.c | 46
>++++++++++++++++------
>> 3 files changed, 41 insertions(+), 19 deletions(-)
>
>You can't just switch existing bindings as that breaks compatibility
>with old dtbs. The kernel driver would need to support both. Just
>introduce the new common property and use it for your device.
>
The old binding is only in my tree at the moment, so I do not think there is compatibility concerns.
Are you OK with the new binding itself?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 6/6] ARM: dts: sun8i: raise the max voltage of DCDC2 in sun8i reference tablets
From: Maxime Ripard @ 2016-12-13 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-7-icenowy@aosc.xyz>
On Tue, Dec 13, 2016 at 11:22:52PM +0800, Icenowy Zheng wrote:
> The "extremity_freq" frequency described in the original FEX files uses
> a voltage of 1.46v, which is beyond the current maximum voltage value of
> DCDC2 (Cortex-A7 supply) in the sun8i reference tablet DTSI file.
>
> Raise the maximum value to 1.46v.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
> index 7ac8bb4bc95a..325ca5bd67a5 100644
> --- a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
> @@ -180,7 +180,7 @@
> ®_dcdc2 {
> regulator-always-on;
> regulator-min-microvolt = <900000>;
> - regulator-max-microvolt = <1400000>;
> + regulator-max-microvolt = <1460000>;
This is outside of the voltage range tolerated by the CPU. NAK.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20161213/b9ea0961/attachment.sig>
^ permalink raw reply
* [PATCH v6] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Ard Biesheuvel @ 2016-12-13 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213173457.GF23377@e104818-lin.cambridge.arm.com>
On 13 December 2016 at 17:34, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Dec 13, 2016 at 12:35:29PM +0000, Ard Biesheuvel wrote:
>> Currently, we allow kernel mode NEON in softirq or hardirq context by
>> stacking and unstacking a slice of the NEON register file for each call
>> to kernel_neon_begin() and kernel_neon_end(), respectively.
>>
>> Given that
>> a) a CPU typically spends most of its time in userland, during which time
>> no kernel mode NEON in process context is in progress,
>> b) a CPU spends most of its time in the kernel doing other things than
>> kernel mode NEON when it gets interrupted to perform kernel mode NEON
>> in softirq context
>>
>> the stacking and subsequent unstacking is only necessary if we are
>> interrupting a thread while it is performing kernel mode NEON in process
>> context, which means that in all other cases, we can simply preserve the
>> userland FPSIMD state once, and only restore it upon return to userland,
>> even if we are being invoked from softirq or hardirq context.
>>
>> So instead of checking whether we are running in interrupt context, keep
>> track of the level of nested kernel mode NEON calls in progress, and only
>> perform the eager stack/unstack if the level exceeds 1.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> v6:
>> - use a spinlock instead of disabling interrupts
>
> My concern with the spinlock or disabling interrupts is the latency if
> we ever get some insanely long SVE vectors.
>
Thinking about this a bit more, and trying a couple of things in code,
I think this looks like it could be a nasty problem.
The primary issue is that *any* code that handles the FP/SIMD state,
i.e., preserve it, restore it, etc, could be interrupted, and if
kernel_neon_begin()/_end() was used during that time, the top SVE end
of the registers is just blown away if we don't make the nested
save/restore SVE aware.
For instance, looking at
void fpsimd_restore_current_state(void)
{
preempt_disable();
if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
struct fpsimd_state *st = ¤t->thread.fpsimd_state;
fpsimd_load_state(st);
this_cpu_write(fpsimd_last_state, st);
st->cpu = smp_processor_id();
}
preempt_enable();
}
if fpsimd_load_state() is interrupted and the NEON is used, the
registers that were restored before the interruption will have
incorrect values if SVE is being used by userland.
On the preserve side, we can deal with this by preserving into a temp
buffer, and only store the value that was recorded when the flag was
set, i.e.,
static void safe_preserve_fpsimd_state(void)
{
union __fpsimd_percpu_state *s = this_cpu_ptr(nested_fpsimdstate);
if (in_irq()) {
/* No interruptions possible, so just proceed */
if (!test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
fpsimd_save_state(¤t->thread.fpsimd_state);
} else {
struct fpsimd_state *fp;
fp = in_interrupt() ? &s[0].full : &s[1].full;
fpsimd_save_state(fp);
if (!test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
current->thread.fpsimd_state = *fp;
}
}
which is already cumbersome if the full FP/SIMD state grows to 64 KB
However, on the restore side, I fail to see how we can tolerate
interruptions in a similar way.
--
Ard.
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-13 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5220084.l31t5oJbsy@amdc3058>
Hello Bartlomiej,
On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> cooling maps to account for new OPPs.
>
> Since new OPPs are not available on all Exynos5422/5800 boards modify
> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>
> Tested on Odroid-XU3 and XU3 Lite.
>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> Cc: Andreas Faerber <afaerber@suse.de>
> Cc: Thomas Abraham <thomas.ab@samsung.com>
> Cc: Ben Gamari <ben@smart-cactus.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> 4 files changed, 43 insertions(+), 7 deletions(-)
>
> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> @@ -118,7 +118,7 @@
> /*
> * When reaching cpu_alert3, reduce CPU
> * by 2 steps. On Exynos5422/5800 that would
> - * be: 1600 MHz and 1100 MHz.
> + * (usually) be: 1800 MHz and 1200 MHz.
> */
> map3 {
> trip = <&cpu_alert3>;
> @@ -131,16 +131,16 @@
>
> /*
> * When reaching cpu_alert4, reduce CPU
> - * further, down to 600 MHz (11 steps for big,
> - * 7 steps for LITTLE).
> + * further, down to 600 MHz (13 steps for big,
> + * 8 steps for LITTLE).
> */
> - map5 {
> + cooling_map5: map5 {
> trip = <&cpu_alert4>;
> - cooling-device = <&cpu0 3 7>;
> + cooling-device = <&cpu0 3 8>;
> };
> - map6 {
> + cooling_map6: map6 {
> trip = <&cpu_alert4>;
> - cooling-device = <&cpu4 3 11>;
> + cooling-device = <&cpu4 3 13>;
> };
> };
> };
> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> @@ -21,6 +21,23 @@
> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> };
>
> +&cluster_a15_opp_table {
> + /delete-node/opp at 2000000000;
> + /delete-node/opp at 1900000000;
> +};
> +
> +&cluster_a7_opp_table {
> + /delete-node/opp at 1400000000;
> +};
> +
I think that a comment in the DTS why these operating points aren't available
in this board will make more clear why the nodes are being deleted.
> +&cooling_map5 {
> + cooling-device = <&cpu0 3 7>;
> +};
> +
> +&cooling_map6 {
> + cooling-device = <&cpu4 3 11>;
> +};
> +
> &pwm {
> /*
> * PWM 0 -- fan
> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> @@ -146,6 +146,10 @@
> vdd-supply = <&ldo9_reg>;
> };
>
> +&cluster_a7_opp_table {
> + /delete-property/opp at 1400000000;
> +};
> +
> &cpu0 {
> cpu-supply = <&buck2_reg>;
> };
> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> @@ -24,6 +24,16 @@
> };
>
> &cluster_a15_opp_table {
> + opp at 2000000000 {
> + opp-hz = /bits/ 64 <2000000000>;
> + opp-microvolt = <1250000>;
> + clock-latency-ns = <140000>;
> + };
> + opp at 1900000000 {
> + opp-hz = /bits/ 64 <1900000000>;
> + opp-microvolt = <1250000>;
> + clock-latency-ns = <140000>;
> + };
> opp at 1700000000 {
> opp-microvolt = <1250000>;
> };
> @@ -85,6 +95,11 @@
> };
>
AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
INT rail would need to be scaled up as well since there's a maximum voltage
difference between the ARM and INT rails before the system becomes unstable:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
https://lkml.org/lkml/2014/5/2/419
The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
the maximum voltage skew is between a limit. But that never made to mainline:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
https://lkml.org/lkml/2014/4/29/28
Did that change and there's infrastructure in mainline now to cope with that?
If that's the case, I think it would be good to mention in the commit message.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v6] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Ard Biesheuvel @ 2016-12-13 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9+Rcuc3Ubbom_NrYW5sR5B9teSfhM1+zi2JKhj4GUXWQ@mail.gmail.com>
On 13 December 2016 at 19:17, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 13 December 2016 at 17:34, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> On Tue, Dec 13, 2016 at 12:35:29PM +0000, Ard Biesheuvel wrote:
>>> Currently, we allow kernel mode NEON in softirq or hardirq context by
>>> stacking and unstacking a slice of the NEON register file for each call
>>> to kernel_neon_begin() and kernel_neon_end(), respectively.
>>>
>>> Given that
>>> a) a CPU typically spends most of its time in userland, during which time
>>> no kernel mode NEON in process context is in progress,
>>> b) a CPU spends most of its time in the kernel doing other things than
>>> kernel mode NEON when it gets interrupted to perform kernel mode NEON
>>> in softirq context
>>>
>>> the stacking and subsequent unstacking is only necessary if we are
>>> interrupting a thread while it is performing kernel mode NEON in process
>>> context, which means that in all other cases, we can simply preserve the
>>> userland FPSIMD state once, and only restore it upon return to userland,
>>> even if we are being invoked from softirq or hardirq context.
>>>
>>> So instead of checking whether we are running in interrupt context, keep
>>> track of the level of nested kernel mode NEON calls in progress, and only
>>> perform the eager stack/unstack if the level exceeds 1.
>>>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> ---
>>> v6:
>>> - use a spinlock instead of disabling interrupts
>>
>> My concern with the spinlock or disabling interrupts is the latency if
>> we ever get some insanely long SVE vectors.
>>
>
> Thinking about this a bit more, and trying a couple of things in code,
> I think this looks like it could be a nasty problem.
>
> The primary issue is that *any* code that handles the FP/SIMD state,
> i.e., preserve it, restore it, etc, could be interrupted, and if
> kernel_neon_begin()/_end() was used during that time, the top SVE end
> of the registers is just blown away if we don't make the nested
> save/restore SVE aware.
>
> For instance, looking at
>
> void fpsimd_restore_current_state(void)
> {
> preempt_disable();
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> struct fpsimd_state *st = ¤t->thread.fpsimd_state;
>
> fpsimd_load_state(st);
> this_cpu_write(fpsimd_last_state, st);
> st->cpu = smp_processor_id();
> }
> preempt_enable();
> }
>
> if fpsimd_load_state() is interrupted and the NEON is used, the
> registers that were restored before the interruption will have
> incorrect values if SVE is being used by userland.
>
> On the preserve side, we can deal with this by preserving into a temp
> buffer, and only store the value that was recorded when the flag was
> set, i.e.,
>
> static void safe_preserve_fpsimd_state(void)
> {
> union __fpsimd_percpu_state *s = this_cpu_ptr(nested_fpsimdstate);
>
> if (in_irq()) {
> /* No interruptions possible, so just proceed */
> if (!test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> fpsimd_save_state(¤t->thread.fpsimd_state);
The indentation is slightly off here: the 'else' treats the !in_irq() case
> } else {
> struct fpsimd_state *fp;
>
> fp = in_interrupt() ? &s[0].full : &s[1].full;
>
> fpsimd_save_state(fp);
> if (!test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> current->thread.fpsimd_state = *fp;
> }
> }
>
> which is already cumbersome if the full FP/SIMD state grows to 64 KB
>
> However, on the restore side, I fail to see how we can tolerate
> interruptions in a similar way.
>
> --
> Ard.
^ permalink raw reply
* [GIT PULL] arm64 updates for 4.10
From: Catalin Marinas @ 2016-12-13 19:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull the arm64 updates for 4.10 below.
The patches touch the generic include/linux/thread_info.h to factor out
struct restart_block into a separate include/linux/restart_block.h file
(needed for arm64 moving thread_info off stack; acked by Andy
Lutomirski).
There is also a small refactoring touching drivers/irqchip/irq-gic-v3.c
and additional watchpoint lengths added to
include/uapi/linux/hw_breakpoint.h.
Thanks.
The following changes since commit bc33b0ca11e3df467777a4fa7639ba488c9d4911:
Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-upstream
for you to fetch changes up to 75037120e62b58c536999eb23d70cfcb6d6c0bcc:
arm64: Disable PAN on uaccess_enable() (2016-12-12 17:52:27 +0000)
----------------------------------------------------------------
arm64 updates for 4.10:
- struct thread_info moved off-stack (also touching
include/linux/thread_info.h and include/linux/restart_block.h)
- cpus_have_cap() reworked to avoid __builtin_constant_p() for static
key use (also touching drivers/irqchip/irq-gic-v3.c)
- Uprobes support (currently only for native 64-bit tasks)
- Emulation of kernel Privileged Access Never (PAN) using TTBR0_EL1
switching to a reserved page table
- CPU capacity information passing via DT or sysfs (used by the
scheduler)
- Support for systems without FP/SIMD (IOW, kernel avoids touching these
registers; there is no soft-float ABI, nor kernel emulation for
AArch64 FP/SIMD)
- Handling of hardware watchpoint with unaligned addresses, varied
lengths and offsets from base
- Use of the page table contiguous hint for kernel mappings
- Hugetlb fixes for sizes involving the contiguous hint
- Remove unnecessary I-cache invalidation in flush_cache_range()
- CNTHCTL_EL2 access fix for CPUs with VHE support (ARMv8.1)
- Boot-time checks for writable+executable kernel mappings
- Simplify asm/opcodes.h and avoid including the 32-bit ARM counterpart
and make the arm64 kernel headers self-consistent (Xen headers patch
merged separately)
- Workaround for broken .inst support in certain binutils versions
----------------------------------------------------------------
Ard Biesheuvel (3):
arm64: mm: BUG on unsupported manipulations of live kernel mappings
arm64: mm: replace 'block_mappings_allowed' with 'page_mappings_only'
arm64: mm: set the contiguous bit for kernel mappings where appropriate
Catalin Marinas (12):
arm64: Fix typo in add_default_hugepagesz() for 64K pages
arm64: Update the synchronous external abort fault description
arm64: Factor out PAN enabling/disabling into separate uaccess_* macros
arm64: Factor out TTBR0_EL1 post-update workaround into a specific asm macro
arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1
arm64: Disable TTBR0_EL1 during normal kernel execution
arm64: Handle faults caused by inadvertent user access with PAN enabled
arm64: xen: Enable user access before a privcmd hvc call
arm64: Enable CONFIG_ARM64_SW_TTBR0_PAN
arm64: Enable HIBERNATION in defconfig
arm64: Remove I-cache invalidation from flush_cache_range()
Merge Will Deacon's for-next/perf branch into for-next/core
Huang Shijie (2):
arm64: hugetlb: remove the wrong pmd check in find_num_contig()
arm64: hugetlb: fix the wrong address for several functions
Jintack (1):
arm64: head.S: Fix CNTHCTL_EL2 access on VHE system
Juri Lelli (3):
Documentation: arm: define DT cpu capacity-dmips-mhz bindings
arm64: parse cpu capacity-dmips-mhz from DT
arm64: add sysfs cpu_capacity attribute
Laura Abbott (4):
arm64: dump: Make ptdump debugfs a separate option
arm64: dump: Make the page table dumping seq_file optional
arm64: dump: Remove max_addr
arm64: dump: Add checking for writable and exectuable pages
Marc Zyngier (5):
arm64: Get rid of asm/opcodes.h
arm64: Remove reference to asm/opcodes.h
arm64: Add detection code for broken .inst support in binutils
arm64: Work around broken .inst when defective gas is detected
arm64: Disable PAN on uaccess_enable()
Mark Rutland (14):
arm64: percpu: kill off final ACCESS_ONCE() uses
thread_info: factor out restart_block
thread_info: include <current.h> for THREAD_INFO_IN_TASK
arm64: thread_info remove stale items
arm64: asm-offsets: remove unused definitions
arm64: factor out current_stack_pointer
arm64: traps: simplify die() and __die()
arm64: unexport walk_stackframe
arm64: prep stack walkers for THREAD_INFO_IN_TASK
arm64: move sp_el0 and tpidr_el1 into cpu_suspend_ctx
arm64: smp: prepare for smp_processor_id() rework
arm64: make cpu number a percpu variable
arm64: assembler: introduce ldr_this_cpu
arm64: split thread_info from task stack
Pavel Labath (1):
arm64: hw_breakpoint: Handle inexact watchpoint addresses
Pratyush Anand (11):
arm64: kprobe: protect/rename few definitions to be reused by uprobe
arm64: kgdb_step_brk_fn: ignore other's exception
arm64: Handle TRAP_TRACE for user mode as well
arm64: Handle TRAP_BRKPT for user mode as well
arm64: introduce mm context flag to keep 32 bit task information
arm64: Add uprobe support
arm64: fix error: conflicting types for 'kprobe_fault_handler'
hw_breakpoint: Allow watchpoint of length 3,5,6 and 7
arm64: Allow hw watchpoint at varied offset from base address
arm64: Allow hw watchpoint of length 3,5,6 and 7
selftests: arm64: add test for unaligned/inexact watchpoint handling
Robin Murphy (3):
arm64/kprobes: Tidy up sign-extension usage
arm64: Remove pointless WARN_ON in DMA teardown
arm64: smp: Prevent raw_smp_processor_id() recursion
Suzuki K Poulose (2):
arm64: Add hypervisor safe helper for checking constant capabilities
arm64: Support systems without FP/ASIMD
.../devicetree/bindings/arm/cpu-capacity.txt | 236 +++++++++++++++++++++
Documentation/devicetree/bindings/arm/cpus.txt | 10 +
arch/arm64/Kconfig | 12 ++
arch/arm64/Kconfig.debug | 35 ++-
arch/arm64/Makefile | 10 +-
arch/arm64/configs/defconfig | 1 +
arch/arm64/include/asm/Kbuild | 1 -
arch/arm64/include/asm/assembler.h | 48 ++++-
arch/arm64/include/asm/cacheflush.h | 7 +-
arch/arm64/include/asm/cpufeature.h | 37 +++-
arch/arm64/include/asm/current.h | 22 ++
arch/arm64/include/asm/debug-monitors.h | 3 +
arch/arm64/include/asm/efi.h | 26 ++-
arch/arm64/include/asm/elf.h | 12 +-
arch/arm64/include/asm/futex.h | 17 +-
arch/arm64/include/asm/hw_breakpoint.h | 6 +-
arch/arm64/include/asm/kernel-pgtable.h | 7 +
arch/arm64/include/asm/mmu.h | 3 +-
arch/arm64/include/asm/mmu_context.h | 53 +++--
arch/arm64/include/asm/neon.h | 3 +-
arch/arm64/include/asm/opcodes.h | 5 -
arch/arm64/include/asm/percpu.h | 18 +-
arch/arm64/include/asm/perf_event.h | 2 +
arch/arm64/include/asm/probes.h | 21 +-
arch/arm64/include/asm/ptdump.h | 22 +-
arch/arm64/include/asm/ptrace.h | 8 +
arch/arm64/include/asm/smp.h | 14 +-
arch/arm64/include/asm/stack_pointer.h | 9 +
arch/arm64/include/asm/suspend.h | 2 +-
arch/arm64/include/asm/sysreg.h | 45 +++-
arch/arm64/include/asm/thread_info.h | 40 +---
arch/arm64/include/asm/uaccess.h | 175 ++++++++++++++-
arch/arm64/include/asm/uprobes.h | 36 ++++
arch/arm64/kernel/armv8_deprecated.c | 16 +-
arch/arm64/kernel/asm-offsets.c | 13 +-
arch/arm64/kernel/cpufeature.c | 18 +-
arch/arm64/kernel/debug-monitors.c | 40 ++--
arch/arm64/kernel/efi.c | 8 +-
arch/arm64/kernel/entry.S | 110 +++++++---
arch/arm64/kernel/fpsimd.c | 14 ++
arch/arm64/kernel/head.S | 30 ++-
arch/arm64/kernel/hw_breakpoint.c | 153 +++++++++----
arch/arm64/kernel/insn.c | 1 -
arch/arm64/kernel/kgdb.c | 3 +
arch/arm64/kernel/probes/Makefile | 2 +
arch/arm64/kernel/probes/decode-insn.c | 33 +--
arch/arm64/kernel/probes/decode-insn.h | 8 +-
arch/arm64/kernel/probes/kprobes.c | 36 ++--
arch/arm64/kernel/probes/simulate-insn.c | 16 +-
arch/arm64/kernel/probes/uprobes.c | 216 +++++++++++++++++++
arch/arm64/kernel/process.c | 38 +++-
arch/arm64/kernel/ptrace.c | 7 +-
arch/arm64/kernel/return_address.c | 1 +
arch/arm64/kernel/setup.c | 9 +
arch/arm64/kernel/signal.c | 3 +
arch/arm64/kernel/sleep.S | 3 -
arch/arm64/kernel/smp.c | 14 +-
arch/arm64/kernel/stacktrace.c | 7 +-
arch/arm64/kernel/suspend.c | 6 -
arch/arm64/kernel/topology.c | 223 ++++++++++++++++++-
arch/arm64/kernel/traps.c | 28 ++-
arch/arm64/kernel/vmlinux.lds.S | 5 +
arch/arm64/kvm/handle_exit.c | 11 +
arch/arm64/kvm/hyp/hyp-entry.S | 9 +-
arch/arm64/kvm/hyp/switch.c | 5 +-
arch/arm64/lib/clear_user.S | 11 +-
arch/arm64/lib/copy_from_user.S | 11 +-
arch/arm64/lib/copy_in_user.S | 11 +-
arch/arm64/lib/copy_to_user.S | 11 +-
arch/arm64/mm/Makefile | 3 +-
arch/arm64/mm/cache.S | 6 +-
arch/arm64/mm/context.c | 7 +-
arch/arm64/mm/dma-mapping.c | 5 -
arch/arm64/mm/dump.c | 106 ++++++---
arch/arm64/mm/fault.c | 22 +-
arch/arm64/mm/flush.c | 9 +-
arch/arm64/mm/hugetlbpage.c | 22 +-
arch/arm64/mm/mmu.c | 137 ++++++++----
arch/arm64/mm/proc.S | 12 +-
arch/arm64/mm/ptdump_debugfs.c | 31 +++
arch/arm64/xen/hypercall.S | 15 ++
drivers/firmware/efi/arm-runtime.c | 4 +-
drivers/irqchip/irq-gic-v3.c | 13 +-
include/linux/restart_block.h | 51 +++++
include/linux/thread_info.h | 45 +---
include/uapi/linux/hw_breakpoint.h | 4 +
tools/include/uapi/linux/hw_breakpoint.h | 4 +
tools/testing/selftests/breakpoints/Makefile | 5 +-
.../selftests/breakpoints/breakpoint_test_arm64.c | 236 +++++++++++++++++++++
89 files changed, 2288 insertions(+), 525 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/cpu-capacity.txt
create mode 100644 arch/arm64/include/asm/current.h
delete mode 100644 arch/arm64/include/asm/opcodes.h
create mode 100644 arch/arm64/include/asm/stack_pointer.h
create mode 100644 arch/arm64/include/asm/uprobes.h
create mode 100644 arch/arm64/kernel/probes/uprobes.c
create mode 100644 arch/arm64/mm/ptdump_debugfs.c
create mode 100644 include/linux/restart_block.h
create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
--
Catalin
^ permalink raw reply
* [PATCH] Input: imx6ul_tsc - generalize the averaging property
From: Rob Herring @ 2016-12-13 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1CDAF0C6-25E1-4CE9-8F98-F07333827B98@gmail.com>
On Tue, Dec 13, 2016 at 1:14 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On December 13, 2016 11:10:50 AM PST, Rob Herring <robh@kernel.org> wrote:
>>On Sun, Dec 11, 2016 at 09:06:43AM +0200, Guy Shapiro wrote:
>>> Make the avarage-samples property a general touchscreen property
>>> rather than imx6ul device specific.
>>>
>>> Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
>>> ---
>>> .../bindings/input/touchscreen/imx6ul_tsc.txt | 11 ++----
>>> .../bindings/input/touchscreen/touchscreen.txt | 3 ++
>>> drivers/input/touchscreen/imx6ul_tsc.c | 46
>>++++++++++++++++------
>>> 3 files changed, 41 insertions(+), 19 deletions(-)
>>
>>You can't just switch existing bindings as that breaks compatibility
>>with old dtbs. The kernel driver would need to support both. Just
>>introduce the new common property and use it for your device.
>>
>
> The old binding is only in my tree at the moment, so I do not think there is compatibility concerns.
>
> Are you OK with the new binding itself?
Ah, then yes. For the binding:
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] Input: imx6ul_tsc - generalize the averaging property
From: Rob Herring @ 2016-12-13 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481440003-27168-1-git-send-email-guy.shapiro@mobi-wize.com>
On Sun, Dec 11, 2016 at 1:06 AM, Guy Shapiro <guy.shapiro@mobi-wize.com> wrote:
> Make the avarage-samples property a general touchscreen property
> rather than imx6ul device specific.
>
> Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
> ---
> .../bindings/input/touchscreen/imx6ul_tsc.txt | 11 ++----
> .../bindings/input/touchscreen/touchscreen.txt | 3 ++
> drivers/input/touchscreen/imx6ul_tsc.c | 46 ++++++++++++++++------
> 3 files changed, 41 insertions(+), 19 deletions(-)
[...]
> + switch (average_samples) {
> + case 1:
> + tsc->average_enable = false;
> + tsc->average_select = 0; /* value unused; initialize anyway */
> + break;
> + case 4:
> + tsc->average_enable = true;
> + tsc->average_select = 0;
> + break;
> + case 8:
> + tsc->average_enable = true;
> + tsc->average_select = 1;
> + break;
> + case 16:
> + tsc->average_enable = true;
> + tsc->average_select = 2;
> + break;
> + case 32:
> + tsc->average_enable = true;
> + tsc->average_select = 3;
> + break;
This could be more efficiently written as
tsc->average_select = log2(average_samples) - 2;
Then enable if >=0.
Rob
^ permalink raw reply
* [PATCH v2 2/2] crypto: mediatek - add DT bindings documentation
From: Rob Herring @ 2016-12-13 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481592676-2248-3-git-send-email-ryder.lee@mediatek.com>
On Tue, Dec 13, 2016 at 09:31:16AM +0800, Ryder Lee wrote:
> Add DT bindings documentation for the crypto driver
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> .../devicetree/bindings/crypto/mediatek-crypto.txt | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> new file mode 100644
> index 0000000..47a786e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> @@ -0,0 +1,32 @@
> +MediaTek cryptographic accelerators
> +
> +Required properties:
> +- compatible: Should be "mediatek,eip97-crypto"
> +- reg: Address and length of the register set for the device
> +- interrupts: Should contain the five crypto engines interrupts in numeric
> + order. These are global system and four descriptor rings.
> +- clocks: the clock used by the core
> +- clock-names: the names of the clock listed in the clocks property. These are
> + "ethif", "cryp"
> +- power-domains: Must contain a reference to the PM domain.
> +
> +
> +Optional properties:
> +- interrupt-parent: Should be the phandle for the interrupt controller
> + that services interrupts for this device
This is not optional. It's perhaps inherited from the parent. You can
drop it as it's implied by interrupts property.
Rob
^ permalink raw reply
* [PATCH 1/3] dt-bindings: arm: update Armada CP110 system controller binding
From: Rob Herring @ 2016-12-13 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481632880-9198-2-git-send-email-thomas.petazzoni@free-electrons.com>
On Tue, Dec 13, 2016 at 01:41:18PM +0100, Thomas Petazzoni wrote:
> It turns out that in the CP110 HW block present in Marvell Armada
> 7K/8K SoCs, gatable clock n?18 not only controls SD/MMC, but also the
> GOP block. This commit updates the Device Tree binding for this piece
> of hardware accordingly.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> .../devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 3/9] dt-bindings: stm32-dma: Fix typo regarding DMA client binding
From: Rob Herring @ 2016-12-13 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-4-git-send-email-cedric.madianga@gmail.com>
On Tue, Dec 13, 2016 at 02:40:45PM +0100, M'boumba Cedric Madianga wrote:
> Only four cells are required for dma client binding not five.
>
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
> Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
> ---
> Documentation/devicetree/bindings/dma/stm32-dma.txt | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 0/4] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Florian Fainelli @ 2016-12-13 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209233628.6642-1-f.fainelli@gmail.com>
On 12/09/2016 03:36 PM, Florian Fainelli wrote:
> This patch series builds on top of Laura's [PATCHv5 00/10] CONFIG_DEBUG_VIRTUAL
> for arm64 to add support for CONFIG_DEBUG_VIRTUAL for ARM.
>
> This was tested on a Brahma B15 platform (ARMv7 + HIGHMEM + LPAE).
>
> Note that the treewide changes would involve a huge CC list, which
> is why it has been purposely trimmed to just focusing on the DEBUG_VIRTUAL
> aspect.
Any comments on this? How would you approach merging these patches?
Thank you!
>
> Changes in v3:
>
> - fix build failures reported by Kbuild test robot
>
> Changes in v2:
>
> - Modified MTD LART driver not to create symbol conflicts with
> KERNEL_START
> - Fixed patch that defines and uses KERNEL_START/END
> - Fixed __pa_symbol()'s definition
> - Inline __pa_symbol() check wihtin the VIRTUAL_BUG_ON statement
> - Simplified check for virtual addresses
> - Added a tree-wide patch changing SMP/PM implementations to use
> __pa_symbol(), build tested against multi_v{5,7}_defconfig
>
> Thanks!
>
> Florian Fainelli (4):
> mtd: lart: Rename partition defines to be prefixed with PART_
> ARM: Define KERNEL_START and KERNEL_END
> ARM: Add support for CONFIG_DEBUG_VIRTUAL
> ARM: treewide: Replace uses of virt_to_phys with __pa_symbol
>
> arch/arm/Kconfig | 1 +
> arch/arm/boot/compressed/piggy.xzkern | Bin 0 -> 2998584 bytes
> arch/arm/common/mcpm_entry.c | 12 +++----
> arch/arm/include/asm/memory.h | 23 ++++++++++++--
> arch/arm/mach-alpine/platsmp.c | 2 +-
> arch/arm/mach-axxia/platsmp.c | 2 +-
> arch/arm/mach-bcm/bcm63xx_smp.c | 2 +-
> arch/arm/mach-bcm/platsmp-brcmstb.c | 2 +-
> arch/arm/mach-bcm/platsmp.c | 4 +--
> arch/arm/mach-berlin/platsmp.c | 2 +-
> arch/arm/mach-exynos/firmware.c | 4 +--
> arch/arm/mach-exynos/mcpm-exynos.c | 2 +-
> arch/arm/mach-exynos/platsmp.c | 4 +--
> arch/arm/mach-exynos/pm.c | 6 ++--
> arch/arm/mach-exynos/suspend.c | 6 ++--
> arch/arm/mach-hisi/platmcpm.c | 2 +-
> arch/arm/mach-hisi/platsmp.c | 6 ++--
> arch/arm/mach-imx/platsmp.c | 2 +-
> arch/arm/mach-imx/pm-imx6.c | 2 +-
> arch/arm/mach-imx/src.c | 2 +-
> arch/arm/mach-mediatek/platsmp.c | 2 +-
> arch/arm/mach-mvebu/pm.c | 2 +-
> arch/arm/mach-mvebu/pmsu.c | 2 +-
> arch/arm/mach-mvebu/system-controller.c | 2 +-
> arch/arm/mach-omap2/control.c | 8 ++---
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 8 ++---
> arch/arm/mach-omap2/omap-smp.c | 4 +--
> arch/arm/mach-prima2/platsmp.c | 2 +-
> arch/arm/mach-prima2/pm.c | 2 +-
> arch/arm/mach-pxa/palmz72.c | 2 +-
> arch/arm/mach-pxa/pxa25x.c | 2 +-
> arch/arm/mach-pxa/pxa27x.c | 2 +-
> arch/arm/mach-pxa/pxa3xx.c | 2 +-
> arch/arm/mach-realview/platsmp-dt.c | 2 +-
> arch/arm/mach-rockchip/platsmp.c | 4 +--
> arch/arm/mach-rockchip/pm.c | 2 +-
> arch/arm/mach-s3c24xx/mach-jive.c | 2 +-
> arch/arm/mach-s3c24xx/pm-s3c2410.c | 2 +-
> arch/arm/mach-s3c24xx/pm-s3c2416.c | 2 +-
> arch/arm/mach-s3c64xx/pm.c | 2 +-
> arch/arm/mach-s5pv210/pm.c | 2 +-
> arch/arm/mach-sa1100/pm.c | 2 +-
> arch/arm/mach-shmobile/platsmp-apmu.c | 6 ++--
> arch/arm/mach-shmobile/platsmp-scu.c | 4 +--
> arch/arm/mach-socfpga/platsmp.c | 4 +--
> arch/arm/mach-spear/platsmp.c | 2 +-
> arch/arm/mach-sti/platsmp.c | 2 +-
> arch/arm/mach-sunxi/platsmp.c | 4 +--
> arch/arm/mach-tango/platsmp.c | 2 +-
> arch/arm/mach-tango/pm.c | 2 +-
> arch/arm/mach-tegra/reset.c | 4 +--
> arch/arm/mach-ux500/platsmp.c | 2 +-
> arch/arm/mach-vexpress/dcscb.c | 2 +-
> arch/arm/mach-vexpress/platsmp.c | 2 +-
> arch/arm/mach-vexpress/tc2_pm.c | 4 +--
> arch/arm/mach-zx/platsmp.c | 4 +--
> arch/arm/mach-zynq/platsmp.c | 2 +-
> arch/arm/mm/Makefile | 1 +
> arch/arm/mm/init.c | 7 ++--
> arch/arm/mm/mmu.c | 6 +---
> arch/arm/mm/physaddr.c | 51 ++++++++++++++++++++++++++++++
> drivers/mtd/devices/lart.c | 24 +++++++-------
> 62 files changed, 173 insertions(+), 108 deletions(-)
> create mode 100644 arch/arm/boot/compressed/piggy.xzkern
> create mode 100644 arch/arm/mm/physaddr.c
>
--
Florian
^ permalink raw reply
* [RFC v4 00/16] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Eric Auger @ 2016-12-13 20:30 UTC (permalink / raw)
To: linux-arm-kernel
Following LPC discussions, we now report reserved regions through
iommu-group sysfs reserved_regions attribute file.
Reserved regions are populated through the IOMMU get_resv_region
callback (former get_dm_regions), now implemented by amd-iommu,
intel-iommu and arm-smmu:
- the amd-iommu reports device direct mapped regions.
- the intel-iommu reports the [0xfee00000 - 0xfeefffff] MSI window
as an IOMMU_RESV_NOMAP reserved region.
- the arm-smmu reports the MSI window (arbitrarily located at
0x8000000 and 1MB large).
Unsafe interrupt assignment is tested by enumerating all MSI irq
domains and checking they support MSI remapping. This check is done
in case we detect the iommu translates MSI (an IOMMU_RESV_MSI
window exists). Otherwise the IRQ remapping capability is checked
at IOMMU level. Obviously this is a defensive IRQ safety assessment.
Assuming there are several MSI controllers in the system and at
least one does not implement IRQ remapping, the assignment will be
considered as unsafe (even if this controller is not acessible from
the assigned devices).
The series integrates a not officially posted patch from Robin:
"iommu/dma: Allow MSI-only cookies".
Best Regards
Eric
Git: complete series available at
https://github.com/eauger/linux/tree/v4.9-reserved-v4
History:
RFCv3 -> RFCv4:
- arm-smmu driver does not register PCI host bridge windows as
reserved regions anymore
- Implement reserved region get/put callbacks also in arm-smmuv3
- take the iommu_group lock on iommu_get_group_resv_regions
- add a type field in iommu_resv_region instead of using prot
- init the region list_head in iommu_alloc_resv_region, also
add type parameter
- iommu_insert_resv_region manage overlaps and sort reserved
windows
- address IRQ safety assessment by enumerating all the MSI irq
domains and checking the MSI_REMAP flag
- update Documentation/ABI/testing/sysfs-kernel-iommu_groups
- Did not add T-b since the code has significantly changed
RFCv2 -> RFCv3:
- switch to an iommu-group sysfs API
- use new dummy allocator provided by Robin
- dummy allocator initialized by vfio-iommu-type1 after enumerating
the reserved regions
- at the moment ARM MSI base address/size is left unchanged compared
to v2
- we currently report reserved regions and not usable IOVA regions as
requested by Alex
RFC v1 -> v2:
- fix intel_add_reserved_regions
- add mutex lock/unlock in vfio_iommu_type1
Eric Auger (16):
iommu/dma: Allow MSI-only cookies
iommu: Rename iommu_dm_regions into iommu_resv_regions
iommu: Add a new type field in iommu_resv_region
iommu: iommu_alloc_resv_region
iommu: Only map direct mapped regions
iommu: iommu_get_group_resv_regions
iommu: Implement reserved_regions iommu-group sysfs file
iommu/vt-d: Implement reserved region get/put callbacks
iommu/arm-smmu: Implement reserved region get/put callbacks
iommu/arm-smmu-v3: Implement reserved region get/put callbacks
irqdomain: Add IRQ_DOMAIN_FLAG_MSI_REMAP value
irqdomain: irq_domain_check_msi_remap
irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP
vfio/type1: Allow transparent MSI IOVA allocation
vfio/type1: Check MSI remapping at irq domain level
iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP anymore
.../ABI/testing/sysfs-kernel-iommu_groups | 9 ++
drivers/iommu/amd_iommu.c | 21 +--
drivers/iommu/arm-smmu-v3.c | 30 +++-
drivers/iommu/arm-smmu.c | 30 +++-
drivers/iommu/dma-iommu.c | 116 +++++++++++++---
drivers/iommu/intel-iommu.c | 50 +++++--
drivers/iommu/iommu.c | 152 +++++++++++++++++++--
drivers/irqchip/irq-gic-v3-its.c | 1 +
drivers/vfio/vfio_iommu_type1.c | 37 ++++-
include/linux/dma-iommu.h | 7 +
include/linux/iommu.h | 46 +++++--
include/linux/irqdomain.h | 8 ++
kernel/irq/irqdomain.c | 24 ++++
13 files changed, 455 insertions(+), 76 deletions(-)
--
1.9.1
^ 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