* [PATCH v2 0/7] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11
From: Herbert Xu @ 2017-01-12 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484152915-26517-1-git-send-email-ard.biesheuvel@linaro.org>
On Wed, Jan 11, 2017 at 04:41:48PM +0000, Ard Biesheuvel wrote:
> This adds ARM and arm64 implementations of ChaCha20, scalar AES and SIMD
> AES (using bit slicing). The SIMD algorithms in this series take advantage
> of the new skcipher walksize attribute to iterate over the input in the most
> efficient manner possible.
>
> Patch #1 adds a NEON implementation of ChaCha20 for ARM.
>
> Patch #2 adds a NEON implementation of ChaCha20 for arm64.
>
> Patch #3 modifies the existing NEON and ARMv8 Crypto Extensions implementations
> of AES-CTR to be available as a synchronous skcipher as well. This is intended
> for the mac80211 code, which uses synchronous encapsulations of ctr(aes)
> [ccm, gcm] in softirq context, during which arm64 supports use of SIMD code.
>
> Patch #4 adds a scalar implementation of AES for arm64, using the key schedule
> generation routines and lookup tables of the generic code in crypto/aes_generic.
>
> Patch #5 does the same for ARM, replacing existing scalar code that originated
> in the OpenSSL project, and contains redundant key schedule generation routines
> and lookup tables (and is slightly slower on modern cores)
>
> Patch #6 replaces the ARM bit sliced NEON code with a new implementation that
> has a number of advantages over the original code (which also originated in the
> OpenSSL project.) The performance should be identical.
>
> Patch #7 adds a port of the ARM bit-sliced AES code to arm64, in ECB, CBC, CTR
> and XTS modes.
>
> Due to the size of patch #7, it may be difficult to apply these patches from
> patchwork, so I pushed them here as well:
It seems to have made it.
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] ASoC: sun4i-spdif: Add support for the H3 SoC
From: codekipper at gmail.com @ 2017-01-12 16:45 UTC (permalink / raw)
To: linux-arm-kernel
From: Marcus Cooper <codekipper@gmail.com>
The H3 SoC uses the same SPDIF block as found in earlier SoCs, but its
TXFIFO is mapped to another address.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
sound/soc/sunxi/sun4i-spdif.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
index fec62ee1fc72..c03cd07a9b19 100644
--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -103,6 +103,8 @@
#define SUN4I_SPDIF_ISTA_RXOSTA BIT(1)
#define SUN4I_SPDIF_ISTA_RXASTA BIT(0)
+#define SUN8I_SPDIF_TXFIFO (0x20)
+
#define SUN4I_SPDIF_TXCNT (0x24)
#define SUN4I_SPDIF_RXCNT (0x28)
@@ -417,6 +419,11 @@ static const struct sun4i_spdif_quirks sun6i_a31_spdif_quirks = {
.has_reset = true,
};
+static const struct sun4i_spdif_quirks sun8i_h3_spdif_quirks = {
+ .reg_dac_txdata = SUN8I_SPDIF_TXFIFO,
+ .has_reset = true,
+};
+
static const struct of_device_id sun4i_spdif_of_match[] = {
{
.compatible = "allwinner,sun4i-a10-spdif",
@@ -426,6 +433,10 @@ static const struct of_device_id sun4i_spdif_of_match[] = {
.compatible = "allwinner,sun6i-a31-spdif",
.data = &sun6i_a31_spdif_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-h3-spdif",
+ .data = &sun8i_h3_spdif_quirks,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun4i_spdif_of_match);
--
2.11.0
^ permalink raw reply related
* [PATCH v2 0/7] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11
From: Ard Biesheuvel @ 2017-01-12 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112164504.GD20313@gondor.apana.org.au>
On 12 January 2017 at 16:45, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Jan 11, 2017 at 04:41:48PM +0000, Ard Biesheuvel wrote:
>> This adds ARM and arm64 implementations of ChaCha20, scalar AES and SIMD
>> AES (using bit slicing). The SIMD algorithms in this series take advantage
>> of the new skcipher walksize attribute to iterate over the input in the most
>> efficient manner possible.
>>
>> Patch #1 adds a NEON implementation of ChaCha20 for ARM.
>>
>> Patch #2 adds a NEON implementation of ChaCha20 for arm64.
>>
>> Patch #3 modifies the existing NEON and ARMv8 Crypto Extensions implementations
>> of AES-CTR to be available as a synchronous skcipher as well. This is intended
>> for the mac80211 code, which uses synchronous encapsulations of ctr(aes)
>> [ccm, gcm] in softirq context, during which arm64 supports use of SIMD code.
>>
>> Patch #4 adds a scalar implementation of AES for arm64, using the key schedule
>> generation routines and lookup tables of the generic code in crypto/aes_generic.
>>
>> Patch #5 does the same for ARM, replacing existing scalar code that originated
>> in the OpenSSL project, and contains redundant key schedule generation routines
>> and lookup tables (and is slightly slower on modern cores)
>>
>> Patch #6 replaces the ARM bit sliced NEON code with a new implementation that
>> has a number of advantages over the original code (which also originated in the
>> OpenSSL project.) The performance should be identical.
>>
>> Patch #7 adds a port of the ARM bit-sliced AES code to arm64, in ECB, CBC, CTR
>> and XTS modes.
>>
>> Due to the size of patch #7, it may be difficult to apply these patches from
>> patchwork, so I pushed them here as well:
>
> It seems to have made it.
>
> All applied. Thanks.
Actually, patch #6 was the huge one not #7, and I don't see it in your tree yet.
https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/commit/?h=crypto-arm-v4.11&id=cbf03b255f7c
The order does not matter, though, so could you please put it on top? Thanks.
--
Ard.
^ permalink raw reply
* [PATCH v3 2/3] arm64: dts: juno: fix CoreSight support for Juno r1/r2 variants
From: Mathieu Poirier @ 2017-01-12 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484234410-7670-3-git-send-email-sudeep.holla@arm.com>
On 12 January 2017 at 08:20, Sudeep Holla <sudeep.holla@arm.com> wrote:
> From: Mike Leach <mike.leach@linaro.org>
>
> The CoreSight support added for Juno is valid for only Juno r0.
> The Juno r1 and r2 variants have additional components and alternative
> connection routes between trace source and sinks.
>
> This patch builds on top of the existing r0 support and extends it to
> Juno r1/r2 variants.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> [sudeep.holla at arm.com: minor changelog update and reorganising the common
> coresight components back into juno-base.dtsi to avoid duplication]
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 102 ++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/arm/juno-r1.dts | 9 +++
> arch/arm64/boot/dts/arm/juno-r2.dts | 9 +++
> 3 files changed, 120 insertions(+)
> create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>
> diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
> new file mode 100644
> index 000000000000..89fcef366ff9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
> @@ -0,0 +1,102 @@
> + csys1_funnel at 20130000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x20130000 0 0x1000>;
> +
> + clocks = <&soc_smc50mhz>;
> + clock-names = "apb_pclk";
> + power-domains = <&scpi_devpd 0>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* input port */
> + port at 0 {
> + reg = <0>;
> + csys1_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&etf1_in_port>;
> + };
> + };
> +
> + /* output port */
> + port at 1 {
> + reg = <0>;
> + csys1_funnel_in_port0: endpoint {
> + slave-mode;
> + };
> + };
The comments related to the input and output port are reversed.
> +
> + };
> + };
> +
> + etf1 at 20140000 {
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0 0x20140000 0 0x1000>;
> +
> + clocks = <&soc_smc50mhz>;
> + clock-names = "apb_pclk";
> + power-domains = <&scpi_devpd 0>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* input port */
> + port at 0 {
> + reg = <0>;
> + etf1_in_port: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&csys1_funnel_out_port>;
> + };
> + };
> +
> + /* output port */
> + port at 1 {
> + reg = <0>;
> + etf1_out_port: endpoint {
> + remote-endpoint =
> + <&csys2_funnel_in_port1>;
> + };
> + };
> + };
> + };
> +
> + csys2_funnel at 20150000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x20150000 0 0x1000>;
> +
> + clocks = <&soc_smc50mhz>;
> + clock-names = "apb_pclk";
> + power-domains = <&scpi_devpd 0>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* output port */
> + port at 0 {
> + reg = <0>;
> + csys2_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&replicator_in_port0>;
> + };
> + };
> +
> + /* input ports */
> + port at 1 {
> + reg = <0>;
> + csys2_funnel_in_port0: endpoint {
> + slave-mode;
> + remote-endpoint = <&etf0_out_port>;
> + };
> + };
> +
> + port at 2 {
> + reg = <1>;
> + csys2_funnel_in_port1: endpoint {
> + slave-mode;
> + remote-endpoint = <&etf1_out_port>;
> + };
> + };
> +
> + };
> + };
> diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> index eec37feee8fc..d4b85d9d343e 100644
> --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> @@ -178,6 +178,7 @@
> };
>
> #include "juno-base.dtsi"
> + #include "juno-cs-r1r2.dtsi"
> };
>
> &memtimer {
> @@ -227,3 +228,11 @@
> &gpu1_thermal_zone {
> status = "okay";
> };
> +
> +&etf0_out_port {
> + remote-endpoint = <&csys2_funnel_in_port0>;
> +};
> +
> +&replicator_in_port0 {
> + remote-endpoint = <&csys2_funnel_out_port>;
> +};
> diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
> index 28f40ec44090..14b29517065c 100644
> --- a/arch/arm64/boot/dts/arm/juno-r2.dts
> +++ b/arch/arm64/boot/dts/arm/juno-r2.dts
> @@ -178,6 +178,7 @@
> };
>
> #include "juno-base.dtsi"
> + #include "juno-cs-r1r2.dtsi"
> };
>
> &memtimer {
> @@ -227,3 +228,11 @@
> &gpu1_thermal_zone {
> status = "okay";
> };
> +
> +&etf0_out_port {
> + remote-endpoint = <&csys2_funnel_in_port0>;
> +};
> +
> +&replicator_in_port0 {
> + remote-endpoint = <&csys2_funnel_out_port>;
> +};
> --
> 2.7.4
>
> _______________________________________________
> CoreSight mailing list
> CoreSight at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 4/5] ARM: dts: sunxi: add dtsi file for V3s SoC
From: Maxime Ripard @ 2017-01-12 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111065638.uW1SQ7Kq@smtp3m.mail.yandex.net>
On Wed, Jan 11, 2017 at 11:56:32AM +0800, Icenowy Zheng wrote:
>
> 2017?1?11? 02:21? Maxime Ripard <maxime.ripard@free-electrons.com>???
> >
> > On Tue, Jan 03, 2017 at 11:16:28PM +0800, Icenowy Zheng wrote:
> > > + uart0_pins_a: uart0 at 0 {
> > > + pins = "PB8", "PB9";
> > > + function = "uart0";
> > > + bias-pull-up;
> >
> > Why do you need a pullup here?
>
> I think TX needs one, but RX do not need.
That's (at best) board specific. So it belongs in the DTS if it's
truely needed.
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/20170112/f8f7e9e4/attachment-0001.sig>
^ permalink raw reply
* [RFC 01/13] KVM: arm/arm64: Add vITS save/restore API documentation
From: Marc Zyngier @ 2017-01-12 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484236613-24633-2-git-send-email-eric.auger@redhat.com>
Hi Eric,
On 12/01/17 15:56, Eric Auger wrote:
> Add description for how to access vITS registers and how to flush/restore
> vITS tables into/from memory
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
> Documentation/virtual/kvm/devices/arm-vgic-its.txt | 70 ++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> index 6081a5b..bd74613 100644
> --- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> +++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> @@ -36,3 +36,73 @@ Groups:
> -ENXIO: ITS not properly configured as required prior to setting
> this attribute
> -ENOMEM: Memory shortage when allocating ITS internal data
> +
> + KVM_DEV_ARM_VGIC_GRP_ITS_REGS
> + Attributes:
> + The attr field of kvm_device_attr encodes the offset of the
> + ITS register, relative to the ITS control frame base address
> + (ITS_base).
> +
> + kvm_device_attr.addr points to a __u64 value whatever the width
> + of the addressed register (32/64 bits).
> +
> + Writes to read-only registers are ignored by the kernel except
> + for a single register, GITS_READR. Normally this register is RO
> + but it needs to be restored otherwise commands in the queue will
> + be re-executed after CWRITER setting.
> +
> + For other registers, Getting or setting a register has the same
> + effect as reading/writing the register on real hardware.
> + Errors:
> + -ENXIO: Offset does not correspond to any supported register
> + -EFAULT: Invalid user pointer for attr->addr
> + -EINVAL: Offset is not 64-bit aligned
> +
> + KVM_DEV_ARM_VGIC_GRP_ITS_TABLES
> + Attributes
> + The attr field of kvm_device_attr is not used.
> +
> + request the flush-save/restore of the ITS tables, namely
> + the device table, the collection table, all the ITT tables,
> + the LPI pending tables. On save, the tables are flushed
> + into guest memory at the location provisionned by the guest
provisioned
> + in GITS_BASER (device and collection tables), on MAPD command
> + (ITT_addr), GICR_PENDBASERs (pending tables).
> +
> + This means the GIC should be restored before the ITS and all
> + ITS registers but the GITS_CTRL must be restored before
> + restoring the ITS tables.
> +
> + Note the LPI configuration table is read-only for the
> + in-kernel ITS and its save/restore goes through the standard
> + RAM save/restore.
> +
> + The layout of the tables in guest memory defines an ABI.
> + The entries are laid out in memory as follows;
> +
> + Device Table Entry (DTE) layout: entry size = 16 bytes
> +
> + bits: | 63 ... 32 | 31 ... 6 | 5 | 4 ... 0 |
> + values: | DeviceID | Resv | V | Size |
> +
> + bits: | 63 ... 44 | 43 ... 0 |
> + values: | Resv | ITT_addr |
While I appreciate this layout represents the absolute maximum an ITS
could implement, I'm a bit concerned about the amount of memory we may
end-up requiring here. All the ITSs implementations I know of seem to
get away with 8 bytes per entry. Maybe I'm just too worried.
Also, please mention that ITT_addr is actually ITT_addr[51:8], as we're
guaranteed to have an ITT that is 256 byte aligned.
> +
> + Collection Table Entry (CTE) layout: entry size = 8 bytes
> +
> + bits: | 63| 62 .. 52 | 51 ... 16 | 15 ... 0 |
> + values: | V | RES0 | RDBase | ICID |
> +
> + Interrupt Translation Table Entry (ITTE) layout: entry size = 16 bytes
The actual name is Interrupt Translation Entry (ITE). I have a patch
renaming this all over the vgic-its.c file...
> +
> + bits: | 63 ... 32 | 31 ... 17 | 16 | 15 ... 0 |
> + values: | DeviceID | RES0 | V | ICID |
> +
> + bits: | 63 ... 32 | 31 ... 0 |
> + values: | pINTID | EventID |
Same concern here. 32bit DevID, EventID and INTID seem a bit over the
top. But maybe we shouldn't be concerned about memory... ;-)
> +
> + LPI Pending Table layout:
> +
> + As specified in the ARM Generic Interrupt Controller Architecture
> + Specification GIC Architecture version 3.0 and version 4. The first
> + 1kB contains only zeros.
>
You definitely want to relax this. An ITS implementation is allowed (and
actually encouraged) to maintain a coarse map in the first kB, and use
this to quickly scan the table, which would be very useful on restore.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH v4 0/5] ARM: Fix dma_alloc_coherent() and friends for NOMMU
From: Vladimir Murzin @ 2017-01-12 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks6abvJV1RJtZhD1ixrnVhC5V3PL1+7DdwB+_tVg+vTkaw@mail.gmail.com>
On 12/01/17 10:55, Benjamin Gaignard wrote:
> 2017-01-12 11:35 GMT+01:00 Benjamin Gaignard <benjamin.gaignard@linaro.org>:
>> 2017-01-11 15:34 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>> On 11/01/17 13:17, Benjamin Gaignard wrote:
>>>> 2017-01-10 15:18 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>>> Hi,
>>>>>
>>>>> It seem that addition of cache support for M-class cpus uncovered
>>>>> latent bug in DMA usage. NOMMU memory model has been treated as being
>>>>> always consistent; however, for R/M classes of cpu memory can be
>>>>> covered by MPU which in turn might configure RAM as Normal
>>>>> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
>>>>> friends, since data can stuck in caches now or be buffered.
>>>>>
>>>>> 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. Robin suggested to
>>>>> advertise such memory as reserved shared-dma-pool, rather then using
>>>>> homebrew command line option, and extend dma-coherent to provide
>>>>> default DMA area in the similar way as it is done for CMA (PATCH
>>>>> 2/5). It allows us to offload all bookkeeping on generic coherent DMA
>>>>> framework, and it is seems that it might be reused by other
>>>>> architectures like c6x and blackfin.
>>>>>
>>>>> Dedicated DMA region is required for cases other than:
>>>>> - MMU/MPU is off
>>>>> - cpu is v7m w/o cache support
>>>>> - device is coherent
>>>>>
>>>>> In case one of the above conditions is true dma operations are forced
>>>>> to be coherent and wired with dma_noop_ops.
>>>>>
>>>>> To make life easier NOMMU dma operations are kept in separate
>>>>> compilation unit.
>>>>>
>>>>> Since the issue was reported in the same time as Benjamin sent his
>>>>> patch [1] to allow mmap for NOMMU, his case is also addressed in this
>>>>> series (PATCH 1/5 and PATCH 3/5).
>>>>>
>>>>> Thanks!
>>>>
>>>> I have tested this v4 on my setup (stm32f4, no cache, no MPU) and unfortunately
>>>> it doesn't work with my drm/kms driver.
>>>
>>> I guess the same is for fbmem, but would be better to have confirmation since
>>> amba-clcd I use has not been ported to drm/kms (yet), so I can't test.
>>>
>>>> I haven't any errors but nothing is displayed unlike what I have when
>>>> using current dma-mapping
>>>> code.
>>>> I guess the issue is coming from dma-noop where __get_free_pages() is
>>>> used instead of alloc_pages()
>>>> in dma-mapping.
>>>
>>> Unless I've missed something bellow is a call stack for both
>>>
>>> #1
>>> __alloc_simple_buffer
>>> __dma_alloc_buffer
>>> alloc_pages
>>> split_page
>>> __dma_clear_buffer
>>> memset
>>> page_address
>>>
>>> #2
>>> __get_free_pages
>>> alloc_pages
>>> page_address
>>>
>>> So the difference is that nommu case in dma-mapping.c memzeros memory, handles
>>> DMA_ATTR_NO_KERNEL_MAPPING and does optimisation of memory usage.
>>>
>>> Is something from above critical for your driver?
>>
>> I have removed all the diff (split_page, __dma_clear_buffer, memset)
>> from #1 and it is still working.
>> DMA_ATTR_NO_KERNEL_MAPPING flag is not set when allocating the buffer.
>>
>> I have investigated more and found that dma-noop doesn't take care of
>> "dma-ranges" property which is set in DT.
>> I believed that is the root cause of my problem with your patches.
>
> After testing changing virt_to_phys to virt_to_dma in dma-noop.c fix the issue
> modetest and fbdemo are now still functional.
>
Thanks for narrowing it down! I did not noticed that stm32f4 remap its memory,
so dma-ranges property is in use.
It looks like virt_to_dma is ARM specific, so I probably have to discard idea
of reusing dma-noop-ops and switch logic into dma-mapping-nommu.c based on
is_device_dma_coherent(dev) check.
Meanwhile, I'm quite puzzled on how such memory remaping should work together
with reserved memory. It seem it doesn't account dma-ranges while reserving
memory (it is too early) nor while allocating/mapping/etc.
Cheers
Vladimir
>>
>> Benjamin
>>
>>>
>>>>
>>>> Since my hardware doesn't have cache or MPU (and so use dma-noop) I
>>>> haven't reserved specific memory region.
>>>> Buffer addresses and vma parameters look correct... What could I have
>>>> miss here ?
>>>
>>> No ideas, sorry...
>>>
>>> Cheers
>>> Vladimir
>>>
>>>>
>>>> Benjamin
>>>>
>>>>>
>>>>> [1] http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
>>>>>
>>>>> Vladimir Murzin (5):
>>>>> dma: Add simple dma_noop_mmap
>>>>> drivers: dma-coherent: Introduce default DMA pool
>>>>> ARM: NOMMU: Introduce dma operations for noMMU
>>>>> ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
>>>>> ARM: dma-mapping: Remove traces of NOMMU code
>>>>>
>>>>> .../bindings/reserved-memory/reserved-memory.txt | 3 +
>>>>> arch/arm/include/asm/dma-mapping.h | 3 +-
>>>>> arch/arm/mm/Kconfig | 2 +-
>>>>> arch/arm/mm/Makefile | 5 +-
>>>>> arch/arm/mm/dma-mapping-nommu.c | 252 +++++++++++++++++++++
>>>>> arch/arm/mm/dma-mapping.c | 26 +--
>>>>> drivers/base/dma-coherent.c | 59 ++++-
>>>>> lib/dma-noop.c | 21 ++
>>>>> 8 files changed, 335 insertions(+), 36 deletions(-)
>>>>> create mode 100644 arch/arm/mm/dma-mapping-nommu.c
>>>>>
>>>>> --
>>>>> 2.0.0
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Benjamin Gaignard
>>
>> Graphic Study Group
>>
>> Linaro.org ? Open source software for ARM SoCs
>>
>> Follow Linaro: Facebook | Twitter | Blog
>
>
>
^ permalink raw reply
* [kvm-unit-tests PATCH 1/6] libcflat: add PRI(dux)32 format types
From: Andrew Jones @ 2017-01-12 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4286b719-ff75-d2cd-68b5-cb9d9bb89553@redhat.com>
On Thu, Jan 12, 2017 at 01:29:24PM +0100, Paolo Bonzini wrote:
>
>
> On 11/01/2017 17:28, Alex Benn?e wrote:
> > So we can have portable formatting of uint32_t types. However there is
> > a catch. Different compilers can use legally subtly different types
> > though so we need to probe the compiler defined intdef.h first.
>
> Interesting, what platform has long uint32_t? I thought the issue was
> whether 64-bit is long or "long long".
>
> Paolo
>
> > Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> > ---
> > Makefile | 1 +
> > configure | 13 +++++++++++++
> > lib/libcflat.h | 9 +++++++++
> > 3 files changed, 23 insertions(+)
> >
> > diff --git a/Makefile b/Makefile
> > index a32333b..9822d9a 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -55,6 +55,7 @@ CFLAGS += $(fomit_frame_pointer)
> > CFLAGS += $(fno_stack_protector)
> > CFLAGS += $(fno_stack_protector_all)
> > CFLAGS += $(wno_frame_address)
> > +CFLAGS += $(if $(U32_LONG_FMT),-D__U32_LONG_FMT__,)
> >
> > CXXFLAGS += $(CFLAGS)
> >
> > diff --git a/configure b/configure
> > index 995c8fa..127868c 100755
> > --- a/configure
> > +++ b/configure
> > @@ -109,6 +109,18 @@ if [ -f $testdir/run ]; then
> > ln -fs $testdir/run $testdir-run
> > fi
> >
> > +# check if uint32_t needs a long format modifier
> > +cat << EOF > lib_test.c
> > +#include <inttypes.h>
> > +EOF
> > +
> > +$cross_prefix$cc lib_test.c -E | grep "typedef" | grep "long" | grep "uint32_t" &> /dev/null
This won't work with cross compilers that don't have inttypes.h in their
path (like mine). How about something like
cat << EOF > lib_test.c
__UINT32_TYPE__
EOF
u32_long="`aarch64-linux-gnu-gcc lib_test.c -E | awk '/unsigned/ && $2 == "long"'`"
Although I feel there should be a compiler macro way to do this without
a need for configure/makefile trickery at all...
Thanks,
drew
> > +exit=$?
> > +if [ $exit -eq 0 ]; then
> > + u32_long=true
> > +fi
> > +rm -f lib_test.c
> > +
> > # check for dependent 32 bit libraries
> > if [ "$arch" != "arm" ]; then
> > cat << EOF > lib_test.c
> > @@ -155,4 +167,5 @@ TEST_DIR=$testdir
> > FIRMWARE=$firmware
> > ENDIAN=$endian
> > PRETTY_PRINT_STACKS=$pretty_print_stacks
> > +U32_LONG_FMT=$u32_long
> > EOF
> > diff --git a/lib/libcflat.h b/lib/libcflat.h
> > index 380395f..e80fc50 100644
> > --- a/lib/libcflat.h
> > +++ b/lib/libcflat.h
> > @@ -58,12 +58,21 @@ typedef _Bool bool;
> > #define true 1
> >
> > #if __SIZEOF_LONG__ == 8
> > +# define __PRI32_PREFIX
> > # define __PRI64_PREFIX "l"
> > # define __PRIPTR_PREFIX "l"
> > #else
> > +#if defined(__U32_LONG_FMT__)
> > +# define __PRI32_PREFIX "l"
> > +#else
> > +# define __PRI32_PREFIX
> > +#endif
> > # define __PRI64_PREFIX "ll"
> > # define __PRIPTR_PREFIX
> > #endif
> > +#define PRId32 __PRI32_PREFIX "d"
> > +#define PRIu32 __PRI32_PREFIX "u"
> > +#define PRIx32 __PRI32_PREFIX "x"
> > #define PRId64 __PRI64_PREFIX "d"
> > #define PRIu64 __PRI64_PREFIX "u"
> > #define PRIx64 __PRI64_PREFIX "x"
> >
> --
> 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 v3 3/5] arm64: Create and use __tlbi_dsb() macros
From: Will Deacon @ 2017-01-12 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111144118.17062-3-cov@codeaurora.org>
Hi Christopher,
On Wed, Jan 11, 2017 at 09:41:16AM -0500, Christopher Covington wrote:
> This refactoring will allow an errata workaround that repeats tlbi dsb
> sequences to only change one location. This is not intended to change the
> generated assembly and comparison of before and after preprocessor output
> of arch/arm64/mm/mmu.c and vmlinux objdump shows no functional changes.
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> ---
> arch/arm64/include/asm/tlbflush.h | 104 +++++++++++++++++++++++++-------------
> 1 file changed, 69 insertions(+), 35 deletions(-)
>
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index deab523..f28813c 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -25,22 +25,69 @@
> #include <asm/cputype.h>
>
> /*
> - * Raw TLBI operations.
> + * Raw TLBI, DSB operations
> *
> - * Where necessary, use the __tlbi() macro to avoid asm()
> - * boilerplate. Drivers and most kernel code should use the TLB
> - * management routines in preference to the macro below.
> + * Where necessary, use __tlbi_*dsb() macros to avoid asm() boilerplate.
> + * Drivers and most kernel code should use the TLB management routines in
> + * preference to the macros below.
> *
> - * The macro can be used as __tlbi(op) or __tlbi(op, arg), depending
> - * on whether a particular TLBI operation takes an argument or
> - * not. The macros handles invoking the asm with or without the
> - * register argument as appropriate.
> + * The __tlbi_dsb() macro handles invoking the asm without any register
> + * argument, with a single register argument, and with start (included)
> + * and end (excluded) range of register arguments. For example:
> + *
> + * __tlbi_dsb(op, attr)
> + *
> + * tlbi op
> + * dsb attr
> + *
> + * __tlbi_dsb(op, attr, addr)
> + *
> + * mov %[addr], =addr
> + * tlbi op, %[addr]
> + * dsb attr
> + *
> + * __tlbi_range_dsb(op, attr, start, end)
> + *
> + * mov %[arg], =start
> + * mov %[end], =end
> + * for:
> + * tlbi op, %[addr]
> + * add %[addr], %[addr], #(1 << (PAGE_SHIFT - 12))
> + * cmp %[addr], %[end]
> + * b.ne for
> + * dsb attr
> */
> -#define __TLBI_0(op, arg) asm ("tlbi " #op)
> -#define __TLBI_1(op, arg) asm ("tlbi " #op ", %0" : : "r" (arg))
> -#define __TLBI_N(op, arg, n, ...) __TLBI_##n(op, arg)
>
> -#define __tlbi(op, ...) __TLBI_N(op, ##__VA_ARGS__, 1, 0)
> +#define __TLBI_FOR_0(ig0, ig1, ig2)
> +#define __TLBI_INSTR_0(op, ig1, ig2) "tlbi " #op
> +#define __TLBI_IO_0(ig0, ig1, ig2) : :
> +
> +#define __TLBI_FOR_1(ig0, ig1, ig2)
> +#define __TLBI_INSTR_1(op, ig0, ig1) "tlbi " #op ", %0"
> +#define __TLBI_IO_1(ig0, arg, ig1) : : "r" (arg)
> +
> +#define __TLBI_FOR_2(ig0, start, ig1) unsigned long addr; \
> + for (addr = start; addr < end; \
> + addr += 1 << (PAGE_SHIFT - 12))
> +#define __TLBI_INSTR_2(op, ig0, ig1) "tlbi " #op ", %0"
> +#define __TLBI_IO_2(ig0, ig1, ig2) : : "r" (addr)
> +
> +#define __TLBI_FOR_N(op, a1, a2, n, ...) __TLBI_FOR_##n(op, a1, a2)
> +#define __TLBI_INSTR_N(op, a1, a2, n, ...) __TLBI_INSTR_##n(op, a1, a2)
> +#define __TLBI_IO_N(op, a1, a2, n, ...) __TLBI_IO_##n(op, a1, a2)
> +
> +#define __TLBI_FOR(op, ...) __TLBI_FOR_N(op, ##__VA_ARGS__, 2, 1, 0)
> +#define __TLBI_INSTR(op, ...) __TLBI_INSTR_N(op, ##__VA_ARGS__, 2, 1, 0)
> +#define __TLBI_IO(op, ...) __TLBI_IO_N(op, ##__VA_ARGS__, 2, 1, 0)
> +
> +#define __tlbi_asm_dsb(as, op, attr, ...) do { \
> + __TLBI_FOR(op, ##__VA_ARGS__) \
> + asm (__TLBI_INSTR(op, ##__VA_ARGS__) \
> + __TLBI_IO(op, ##__VA_ARGS__)); \
> + asm volatile ( as "\ndsb " #attr "\n" \
> + : : : "memory"); } while (0)
> +
> +#define __tlbi_dsb(...) __tlbi_asm_dsb("", ##__VA_ARGS__)
I can't deny that this is cool, but ultimately it's completely unreadable.
What I was thinking you'd do would be make __tlbi expand to:
tlbi
dsb
tlbi
dsb
for Falkor, and:
tlbi
nop
nop
nop
for everybody else.
Wouldn't that localise this change sufficiently that you wouldn't need
to change all the callers and encode the looping in your cpp macros?
I realise you get an extra dsb in some places with that change, but I'd
like to see numbers for the impact of that on top of the workaround. If
it's an issue, then an alternative sequence would be:
tlbi
dsb
tlbi
and you'd rely on the existing dsb to complete that.
Having said that, I don't understand how your current loop code works
when the workaround is applied. AFAICT, you end up emitting something
like:
dsb ishst
for i in 0 to n
tlbi va+i
dsb
tlbi va+n
dsb
which looks wrong to me. Am I misreading something here?
Will
^ permalink raw reply
* [GIT PULL] STi DT update for v4.11 round 1
From: Patrice Chotard @ 2017-01-12 16:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof
PLease consider this first round of STi dts update for v4.11 :
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git tags/sti-dt-for-v4.11
for you to fetch changes up to 2016ead446b98c42dffd9b6c03ce813e5cb3b810:
ARM: dts: STiH407-family: Supply Mailbox properties to delta RProc (2017-01-12 17:23:39 +0100)
----------------------------------------------------------------
STi dts update:
Enable High Quality Video Data Plane (HQVDP) DT entry
Add DELTA V4L2 video decoder DT entry
Disable unused fdma instances
Fix sti-display-subsystem wrong clock parent's value
Cleanup and update DT entries related to remoteproc
----------------------------------------------------------------
Hugues Fruchet (1):
ARM: dts: STiH410: add DELTA dt node
Patrice Chotard (10):
ARM: dts: STiH410-B2120: enable sti-hda at board level
ARM: dts: STiH410: add hqvdp node
ARM: dts: STiH407-family: disable fdma1 and fdma2
ARM: dts: STiH410-family: fix wrong parent clock frequency
ARM: dts: STiH407-family: update gp0_reserved memory region
ARM: dts: STiH407-family: remove audio remoteproc node
ARM: dts: STiH407-family: remove gp1 remoteproc node
ARM: dts: STiH407-family: update dmu remoteproc node
ARM: dts: STiH407-family: Supply mailbox properties to GP0 RProc
ARM: dts: STiH407-family: Supply Mailbox properties to delta RProc
arch/arm/boot/dts/stih407-family.dtsi | 58 ++++++++++-------------------------
arch/arm/boot/dts/stih410-b2120.dts | 6 ++++
arch/arm/boot/dts/stih410.dtsi | 24 ++++++++++++++-
3 files changed, 45 insertions(+), 43 deletions(-)
^ permalink raw reply
* [RFC PATCH v4 0/5] ARM: Fix dma_alloc_coherent() and friends for NOMMU
From: Robin Murphy @ 2017-01-12 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1908ef72-beb0-1855-3c49-d5a37f014c17@arm.com>
On 12/01/17 16:52, Vladimir Murzin wrote:
> On 12/01/17 10:55, Benjamin Gaignard wrote:
>> 2017-01-12 11:35 GMT+01:00 Benjamin Gaignard <benjamin.gaignard@linaro.org>:
>>> 2017-01-11 15:34 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>> On 11/01/17 13:17, Benjamin Gaignard wrote:
>>>>> 2017-01-10 15:18 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>>>> Hi,
>>>>>>
>>>>>> It seem that addition of cache support for M-class cpus uncovered
>>>>>> latent bug in DMA usage. NOMMU memory model has been treated as being
>>>>>> always consistent; however, for R/M classes of cpu memory can be
>>>>>> covered by MPU which in turn might configure RAM as Normal
>>>>>> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
>>>>>> friends, since data can stuck in caches now or be buffered.
>>>>>>
>>>>>> 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. Robin suggested to
>>>>>> advertise such memory as reserved shared-dma-pool, rather then using
>>>>>> homebrew command line option, and extend dma-coherent to provide
>>>>>> default DMA area in the similar way as it is done for CMA (PATCH
>>>>>> 2/5). It allows us to offload all bookkeeping on generic coherent DMA
>>>>>> framework, and it is seems that it might be reused by other
>>>>>> architectures like c6x and blackfin.
>>>>>>
>>>>>> Dedicated DMA region is required for cases other than:
>>>>>> - MMU/MPU is off
>>>>>> - cpu is v7m w/o cache support
>>>>>> - device is coherent
>>>>>>
>>>>>> In case one of the above conditions is true dma operations are forced
>>>>>> to be coherent and wired with dma_noop_ops.
>>>>>>
>>>>>> To make life easier NOMMU dma operations are kept in separate
>>>>>> compilation unit.
>>>>>>
>>>>>> Since the issue was reported in the same time as Benjamin sent his
>>>>>> patch [1] to allow mmap for NOMMU, his case is also addressed in this
>>>>>> series (PATCH 1/5 and PATCH 3/5).
>>>>>>
>>>>>> Thanks!
>>>>>
>>>>> I have tested this v4 on my setup (stm32f4, no cache, no MPU) and unfortunately
>>>>> it doesn't work with my drm/kms driver.
>>>>
>>>> I guess the same is for fbmem, but would be better to have confirmation since
>>>> amba-clcd I use has not been ported to drm/kms (yet), so I can't test.
>>>>
>>>>> I haven't any errors but nothing is displayed unlike what I have when
>>>>> using current dma-mapping
>>>>> code.
>>>>> I guess the issue is coming from dma-noop where __get_free_pages() is
>>>>> used instead of alloc_pages()
>>>>> in dma-mapping.
>>>>
>>>> Unless I've missed something bellow is a call stack for both
>>>>
>>>> #1
>>>> __alloc_simple_buffer
>>>> __dma_alloc_buffer
>>>> alloc_pages
>>>> split_page
>>>> __dma_clear_buffer
>>>> memset
>>>> page_address
>>>>
>>>> #2
>>>> __get_free_pages
>>>> alloc_pages
>>>> page_address
>>>>
>>>> So the difference is that nommu case in dma-mapping.c memzeros memory, handles
>>>> DMA_ATTR_NO_KERNEL_MAPPING and does optimisation of memory usage.
>>>>
>>>> Is something from above critical for your driver?
>>>
>>> I have removed all the diff (split_page, __dma_clear_buffer, memset)
>>> from #1 and it is still working.
>>> DMA_ATTR_NO_KERNEL_MAPPING flag is not set when allocating the buffer.
>>>
>>> I have investigated more and found that dma-noop doesn't take care of
>>> "dma-ranges" property which is set in DT.
>>> I believed that is the root cause of my problem with your patches.
>>
>> After testing changing virt_to_phys to virt_to_dma in dma-noop.c fix the issue
>> modetest and fbdemo are now still functional.
>>
>
> Thanks for narrowing it down! I did not noticed that stm32f4 remap its memory,
> so dma-ranges property is in use.
>
> It looks like virt_to_dma is ARM specific, so I probably have to discard idea
> of reusing dma-noop-ops and switch logic into dma-mapping-nommu.c based on
> is_device_dma_coherent(dev) check.
dma_pfn_offset is a member of struct device, so it should be OK for
dma_noop_ops to also make reference to it (and assume it's zero if not
explicitly set).
> Meanwhile, I'm quite puzzled on how such memory remaping should work together
> with reserved memory. It seem it doesn't account dma-ranges while reserving
> memory (it is too early) nor while allocating/mapping/etc.
The reserved memory is described in terms of CPU physical addresses, so
a device offset shouldn't matter from that perspective. It only comes
into play at the point you generate the dma_addr_t to hand off to the
device - only then do you need to transform the CPU physical address of
the allocated/mapped page into the device's view of that page (i.e.
subtract the offset).
Robin.
>
> Cheers
> Vladimir
>
>>>
>>> Benjamin
>>>
>>>>
>>>>>
>>>>> Since my hardware doesn't have cache or MPU (and so use dma-noop) I
>>>>> haven't reserved specific memory region.
>>>>> Buffer addresses and vma parameters look correct... What could I have
>>>>> miss here ?
>>>>
>>>> No ideas, sorry...
>>>>
>>>> Cheers
>>>> Vladimir
>>>>
>>>>>
>>>>> Benjamin
>>>>>
>>>>>>
>>>>>> [1] http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
>>>>>>
>>>>>> Vladimir Murzin (5):
>>>>>> dma: Add simple dma_noop_mmap
>>>>>> drivers: dma-coherent: Introduce default DMA pool
>>>>>> ARM: NOMMU: Introduce dma operations for noMMU
>>>>>> ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
>>>>>> ARM: dma-mapping: Remove traces of NOMMU code
>>>>>>
>>>>>> .../bindings/reserved-memory/reserved-memory.txt | 3 +
>>>>>> arch/arm/include/asm/dma-mapping.h | 3 +-
>>>>>> arch/arm/mm/Kconfig | 2 +-
>>>>>> arch/arm/mm/Makefile | 5 +-
>>>>>> arch/arm/mm/dma-mapping-nommu.c | 252 +++++++++++++++++++++
>>>>>> arch/arm/mm/dma-mapping.c | 26 +--
>>>>>> drivers/base/dma-coherent.c | 59 ++++-
>>>>>> lib/dma-noop.c | 21 ++
>>>>>> 8 files changed, 335 insertions(+), 36 deletions(-)
>>>>>> create mode 100644 arch/arm/mm/dma-mapping-nommu.c
>>>>>>
>>>>>> --
>>>>>> 2.0.0
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Benjamin Gaignard
>>>
>>> Graphic Study Group
>>>
>>> Linaro.org ? Open source software for ARM SoCs
>>>
>>> Follow Linaro: Facebook | Twitter | Blog
>>
>>
>>
>
^ permalink raw reply
* [kvm-unit-tests PATCH 3/6] docs: move README to README.md and symlink
From: Andrew Jones @ 2017-01-12 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-4-alex.bennee@linaro.org>
On Wed, Jan 11, 2017 at 04:28:38PM +0000, Alex Benn?e wrote:
> This allows a slightly nicer formatting of the text when displayed on
> some repository hosts. We keep a symlink from README for the
> old-school purists.
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> README | 69 +----------------------------------------------------
> README.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 82 insertions(+), 68 deletions(-)
> mode change 100644 => 120000 README
> create mode 100644 README.md
Please use 'format-patch -M' to create patches when renaming files.
I'm not sure I care about having a .md version or not, but only
one README* file in the root dir would be my preference, i.e. if we
want a .md version, then let's just have that, i.e no symlink.
Thanks,
drew
^ permalink raw reply
* [RFC 07/13] KVM: arm64: ITS: Change entry_size and indirect bit in BASER
From: Marc Zyngier @ 2017-01-12 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484236613-24633-8-git-send-email-eric.auger@redhat.com>
On 12/01/17 15:56, Eric Auger wrote:
> Change the device table entry_size to 16 bytes instead of 8.
> We also Store the device and collection device in the its
> struct.
>
> The patch also clears the indirect bit for the device BASER.
> The indirect bit is set as read-only.
Err... Why? We *really* want to continue supporting indirect tables, as
this is a massive memory saver for the guest.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> TODO: investigate support of 2 level tables, ie. enabling
> Indirect = 1. Support of 2 level tables is implementation
> defined.
Clearly, that's a regression. What exactly is the issue that decided you
to disable it?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC 06/13] KVM: arm64: ITS: Expose ITT_Entry_Size in GITS_TYPER
From: Andre Przywara @ 2017-01-12 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484236613-24633-7-git-send-email-eric.auger@redhat.com>
Hi Eric,
On 12/01/17 15:56, Eric Auger wrote:
> An ITT_Entry_Size of 2x8Bytes is reported to the guest
> to provision for ITTE state storage.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
> include/linux/irqchip/arm-gic-v3.h | 1 +
> virt/kvm/arm/vgic/vgic-its.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
> index 170e00a..8cfd81bc 100644
> --- a/include/linux/irqchip/arm-gic-v3.h
> +++ b/include/linux/irqchip/arm-gic-v3.h
> @@ -233,6 +233,7 @@
> #define GITS_CTLR_QUIESCENT (1U << 31)
>
> #define GITS_TYPER_PLPIS (1UL << 0)
> +#define GITS_TYPER_ITT_ENTRY_SIZE_SHIFT 4
> #define GITS_TYPER_IDBITS_SHIFT 8
> #define GITS_TYPER_DEVBITS_SHIFT 13
> #define GITS_TYPER_DEVBITS(r) ((((r) >> GITS_TYPER_DEVBITS_SHIFT) & 0x1f) + 1)
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index e174220..96378b8 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -33,6 +33,8 @@
> #include "vgic.h"
> #include "vgic-mmio.h"
>
> +#define ITTE_SIZE 16
> +
> /*
> * Creates a new (reference to a) struct vgic_irq for a given LPI.
> * If this LPI is already mapped on another ITS, we increase its refcount
> @@ -399,6 +401,7 @@ static unsigned long vgic_mmio_read_its_typer(struct kvm *kvm,
> */
> reg |= 0x0f << GITS_TYPER_DEVBITS_SHIFT;
> reg |= 0x0f << GITS_TYPER_IDBITS_SHIFT;
> + reg |= ITTE_SIZE << GITS_TYPER_ITT_ENTRY_SIZE_SHIFT;
The field is defined as the "... number of bytes per translation table
entry, minus one.". So it should be: (ITTE_SIZE - 1) << ...
Cheers,
Andre.
>
> return extract_bytes(reg, addr & 7, len);
> }
>
^ permalink raw reply
* [PATCH v3 0/3] arm64: dts: juno: CoreSight support updates
From: Mathieu Poirier @ 2017-01-12 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484234410-7670-1-git-send-email-sudeep.holla@arm.com>
On 12 January 2017 at 08:20, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Hi Mike,
>
> I just did some refactoring to reduced thge churn and duplication.
> Can you check if this work for you ? I could not give it much testing.
>
> Regards,
> Sudeep
>
> --->8
> Juno r1/r2 boards have different CoreSight infrastructure outside the
> CPU clusters. This patchset adds the additional coreSight components to
> separate .dtsi files to support these differences.
>
> v1->v2:
> - moved the addition of the STM component into a separate patch
>
> v2->v3:
> - moved the back the common coreSight components back into
> juno-base.dtsi
>
>
> Mike Leach (2):
> arm64: dts: juno: fix CoreSight support for Juno r1/r2 variants
> arm64: dts: juno: add missing CoreSight STM component
>
> Sudeep Holla (1):
> arm64: dts: juno: refactor CoreSight support on Juno r0
>
> arch/arm64/boot/dts/arm/juno-base.dtsi | 31 ++++++---
> arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 102 ++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/arm/juno-r1.dts | 13 ++++
> arch/arm64/boot/dts/arm/juno-r2.dts | 13 ++++
> arch/arm64/boot/dts/arm/juno.dts | 24 +++++++
> 5 files changed, 175 insertions(+), 8 deletions(-)
> create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
For the set:
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org> (On R0 only)
>
> --
> 2.7.4
>
> _______________________________________________
> CoreSight mailing list
> CoreSight at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight
^ permalink raw reply
* [kvm-unit-tests PATCH 4/6] docs: mention checkpatch in the README
From: Andrew Jones @ 2017-01-12 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <322298cd-aefa-e945-d3f4-1237767a06ef@redhat.com>
On Thu, Jan 12, 2017 at 01:29:52PM +0100, Paolo Bonzini wrote:
>
>
> On 11/01/2017 17:28, Alex Benn?e wrote:
> > Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> > ---
> > README.md | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/README.md b/README.md
> > index 5027b62..9462824 100644
> > --- a/README.md
> > +++ b/README.md
> > @@ -79,3 +79,4 @@ You can add the following to .git/config to do this automatically for you:
> > [format]
> > subjectprefix = kvm-unit-tests PATCH
> >
> > +Please run the kernel's ./scripts/checkpatch.pl on new patches
>
> Does it really work well on kvm-unit-tests?
I use it on new code (liberally ignoring stuff I don't think
is worth conforming to), but there's no chance it'll work on
old files (many lib files and pretty much all x86 files). So
we can't really enforce for x86 developers, as we prefer
consistency over kernel style. That said, I think mentioning
in the README that new files could use it (at least for guidance)
is a good idea.
Thanks,
drew
^ permalink raw reply
* [kvm-unit-tests PATCH 4/6] docs: mention checkpatch in the README
From: Andrew Jones @ 2017-01-12 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lgug318o.fsf@linaro.org>
On Thu, Jan 12, 2017 at 12:35:03PM +0000, Alex Benn?e wrote:
>
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
> > On 11/01/2017 17:28, Alex Benn?e wrote:
> >> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> >> ---
> >> README.md | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/README.md b/README.md
> >> index 5027b62..9462824 100644
> >> --- a/README.md
> >> +++ b/README.md
> >> @@ -79,3 +79,4 @@ You can add the following to .git/config to do this automatically for you:
> >> [format]
> >> subjectprefix = kvm-unit-tests PATCH
> >>
> >> +Please run the kernel's ./scripts/checkpatch.pl on new patches
s/patches/files
All patches should be new :-)
drew
> >
> > Does it really work well on kvm-unit-tests?
>
> Well I keep getting pulled up on kernel coding style on my reviews so if
> we mean it we should enforce it.
>
> --
> Alex Benn?e
> --
> 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
* [linux-sunxi][PATCH] ARM: dts: sun8i-h3: Add dts for the Beelink X2 STB
From: codekipper at gmail.com @ 2017-01-12 17:11 UTC (permalink / raw)
To: linux-arm-kernel
From: Marcus Cooper <codekipper@gmail.com>
The Beelink X2 is an STB based on the Allwinner H3 SoC with a uSD slot,
2 USB ports( 1 * USB-2 Host, 1 USB OTG), a 10/100M ethernet port using the
SoC's integrated PHY, Wifi via a RTL8189ETV sdio wifi chip, HDMI, an IR
receiver, 1 LEDs and an optical S/PDIF connector.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 187 ++++++++++++++++++++++++++++++
2 files changed, 188 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 78a94b747059..75960b1468a4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -857,6 +857,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
+ sun8i-h3-beelink-x2.dtb \
sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
new file mode 100644
index 000000000000..bc5aed52cb1d
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
@@ -0,0 +1,187 @@
+/*
+ * Copyright (C) 2017 Marcus Cooper <codekipper@gmail.com>
+ *
+ * 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 file 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 file 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 "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Beelink X2";
+ compatible = "roofull,beelink-x2", "allwinner,sun8i-h3";
+
+ aliases {
+ serial0 = &uart0;
+ /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+ ethernet1 = &rtl8189ftv;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwr_led_x2>;
+
+ pwr_led {
+ label = "beelink-x2:red:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
+ default-state = "on";
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sw_r_x2>;
+
+ sw4 {
+ label = "power";
+ linux,code = <BTN_0>;
+ gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_en_x2>;
+ reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7 */
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&ir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_pins_a>;
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ cd-inverted;
+ status = "okay";
+};
+
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ /*
+ * Explicitly define the sdio device, so that we can add an ethernet
+ * alias for it (which e.g. makes u-boot set a mac-address).
+ */
+ rtl8189ftv: sdio_wifi at 1 {
+ reg = <1>;
+ };
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_8bit_pins>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <8>;
+ non-removable;
+ cap-mmc-hw-reset;
+ status = "okay";
+};
+
+&mmc2_8bit_pins {
+ /* Increase drive strength for DDR modes */
+ drive-strength = <40>;
+ /* eMMC is missing pull-ups */
+ bias-pull-up;
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&r_pio {
+ pwr_led_x2: led_pins at 0 {
+ pins = "PL10";
+ function = "gpio_out";
+ };
+
+ sw_r_x2: key_pins at 0 {
+ pins = "PL3";
+ function = "gpio_in";
+ };
+
+ wifi_en_x2: wifi_en_pin {
+ pins = "PL7";
+ function = "gpio_out";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+ status = "okay";
+};
+
+&usbphy {
+ /* USB VBUS is on as long as VCC-IO is on */
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* [linux-sunxi] Re: [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Maxime Ripard @ 2017-01-12 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111065524.tILSH8cS@smtp1p.mail.yandex.net>
Hi,
On Wed, Jan 11, 2017 at 11:55:16AM +0800, Icenowy Zheng wrote:
>
> 2017?1?11? 02:10? Maxime Ripard <maxime.ripard@free-electrons.com>???
> >
> > On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
> > > V3s has a similar but cut-down CCU to H3.
> > >
> > > Add support for it.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >
> > It looks like there's nothing different but the clocks that you
> > register with the H3, please just use the H3 driver.
>
> USB gate part is different, and many things have gone.
As far as I can see, you're only adding a few clocks, and removing a
bunch. This is definitely something that can be dealt with by simply
registering a slightly different set of clocks, like we're doing on
sun5i.
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/20170112/32eeed87/attachment.sig>
^ permalink raw reply
* [kvm-unit-tests PATCH 5/6] docs: mention modifying env vars in README
From: Andrew Jones @ 2017-01-12 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-6-alex.bennee@linaro.org>
On Wed, Jan 11, 2017 at 04:28:40PM +0000, Alex Benn?e wrote:
> I had started adding a series of flags to control the run-time
> behaviour of the tests but it was pointed out env vars can already do
> that. Mention them in the README so others can find out to.
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> README.md | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/README.md b/README.md
> index 9462824..fa3a445 100644
> --- a/README.md
> +++ b/README.md
> @@ -47,6 +47,14 @@ environment variable:
>
> QEMU=/tmp/qemu/x86_64-softmmu/qemu-system-x86_64 ./x86-run ./x86/msr.flat
>
> +To force the acceleration mode:
> +
> + ACCEL=tcg ./run_tests.sh
> +
> +To extend or disable the timeouts:
> +
> + TIMEOUT=0 ./run_tests.sh
> +
This is a nice addition to the README, but please add more detail.
To force the use of TCG:
ACCEL=tcg ./run_tests.sh
To force failure when KVM is not present:
ACCEL=kvm ./run_tests.sh
To modify the timeout:
TIMEOUT=$DURATION ./run_tests.sh # man timeout(1) for duration format
TIMEOUT=0 ./run_tests.sh # disable the timeout
or something like that...
thanks,
drew
> # Contributing
>
> ## Directory structure
> --
> 2.11.0
>
> --
> 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
* [RFC PATCH v4 0/5] ARM: Fix dma_alloc_coherent() and friends for NOMMU
From: Vladimir Murzin @ 2017-01-12 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c9bb8baa-ae3d-27cd-8c9f-2d77e1f5c62b@arm.com>
On 12/01/17 17:04, Robin Murphy wrote:
> On 12/01/17 16:52, Vladimir Murzin wrote:
>> On 12/01/17 10:55, Benjamin Gaignard wrote:
>>> 2017-01-12 11:35 GMT+01:00 Benjamin Gaignard <benjamin.gaignard@linaro.org>:
>>>> 2017-01-11 15:34 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>>> On 11/01/17 13:17, Benjamin Gaignard wrote:
>>>>>> 2017-01-10 15:18 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>>>>> Hi,
>>>>>>>
>>>>>>> It seem that addition of cache support for M-class cpus uncovered
>>>>>>> latent bug in DMA usage. NOMMU memory model has been treated as being
>>>>>>> always consistent; however, for R/M classes of cpu memory can be
>>>>>>> covered by MPU which in turn might configure RAM as Normal
>>>>>>> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
>>>>>>> friends, since data can stuck in caches now or be buffered.
>>>>>>>
>>>>>>> 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. Robin suggested to
>>>>>>> advertise such memory as reserved shared-dma-pool, rather then using
>>>>>>> homebrew command line option, and extend dma-coherent to provide
>>>>>>> default DMA area in the similar way as it is done for CMA (PATCH
>>>>>>> 2/5). It allows us to offload all bookkeeping on generic coherent DMA
>>>>>>> framework, and it is seems that it might be reused by other
>>>>>>> architectures like c6x and blackfin.
>>>>>>>
>>>>>>> Dedicated DMA region is required for cases other than:
>>>>>>> - MMU/MPU is off
>>>>>>> - cpu is v7m w/o cache support
>>>>>>> - device is coherent
>>>>>>>
>>>>>>> In case one of the above conditions is true dma operations are forced
>>>>>>> to be coherent and wired with dma_noop_ops.
>>>>>>>
>>>>>>> To make life easier NOMMU dma operations are kept in separate
>>>>>>> compilation unit.
>>>>>>>
>>>>>>> Since the issue was reported in the same time as Benjamin sent his
>>>>>>> patch [1] to allow mmap for NOMMU, his case is also addressed in this
>>>>>>> series (PATCH 1/5 and PATCH 3/5).
>>>>>>>
>>>>>>> Thanks!
>>>>>>
>>>>>> I have tested this v4 on my setup (stm32f4, no cache, no MPU) and unfortunately
>>>>>> it doesn't work with my drm/kms driver.
>>>>>
>>>>> I guess the same is for fbmem, but would be better to have confirmation since
>>>>> amba-clcd I use has not been ported to drm/kms (yet), so I can't test.
>>>>>
>>>>>> I haven't any errors but nothing is displayed unlike what I have when
>>>>>> using current dma-mapping
>>>>>> code.
>>>>>> I guess the issue is coming from dma-noop where __get_free_pages() is
>>>>>> used instead of alloc_pages()
>>>>>> in dma-mapping.
>>>>>
>>>>> Unless I've missed something bellow is a call stack for both
>>>>>
>>>>> #1
>>>>> __alloc_simple_buffer
>>>>> __dma_alloc_buffer
>>>>> alloc_pages
>>>>> split_page
>>>>> __dma_clear_buffer
>>>>> memset
>>>>> page_address
>>>>>
>>>>> #2
>>>>> __get_free_pages
>>>>> alloc_pages
>>>>> page_address
>>>>>
>>>>> So the difference is that nommu case in dma-mapping.c memzeros memory, handles
>>>>> DMA_ATTR_NO_KERNEL_MAPPING and does optimisation of memory usage.
>>>>>
>>>>> Is something from above critical for your driver?
>>>>
>>>> I have removed all the diff (split_page, __dma_clear_buffer, memset)
>>>> from #1 and it is still working.
>>>> DMA_ATTR_NO_KERNEL_MAPPING flag is not set when allocating the buffer.
>>>>
>>>> I have investigated more and found that dma-noop doesn't take care of
>>>> "dma-ranges" property which is set in DT.
>>>> I believed that is the root cause of my problem with your patches.
>>>
>>> After testing changing virt_to_phys to virt_to_dma in dma-noop.c fix the issue
>>> modetest and fbdemo are now still functional.
>>>
>>
>> Thanks for narrowing it down! I did not noticed that stm32f4 remap its memory,
>> so dma-ranges property is in use.
>>
>> It looks like virt_to_dma is ARM specific, so I probably have to discard idea
>> of reusing dma-noop-ops and switch logic into dma-mapping-nommu.c based on
>> is_device_dma_coherent(dev) check.
>
> dma_pfn_offset is a member of struct device, so it should be OK for
> dma_noop_ops to also make reference to it (and assume it's zero if not
> explicitly set).
>
>> Meanwhile, I'm quite puzzled on how such memory remaping should work together
>> with reserved memory. It seem it doesn't account dma-ranges while reserving
>> memory (it is too early) nor while allocating/mapping/etc.
>
> The reserved memory is described in terms of CPU physical addresses, so
> a device offset shouldn't matter from that perspective. It only comes
> into play at the point you generate the dma_addr_t to hand off to the
> device - only then do you need to transform the CPU physical address of
> the allocated/mapped page into the device's view of that page (i.e.
> subtract the offset).
Thanks for explanation! So dma-coherent.c should be modified, right? I see
that some architectures provide phys_to_dma/dma_to_phys helpers primary for
swiotlb, is it safe to reuse them given that default implementation is
provided? Nothing under Documentation explains how they supposed to be used,
sorry if asking stupid question.
Cheers
Vladimir
>
> Robin.
>
>>
>> Cheers
>> Vladimir
>>
>>>>
>>>> Benjamin
>>>>
>>>>>
>>>>>>
>>>>>> Since my hardware doesn't have cache or MPU (and so use dma-noop) I
>>>>>> haven't reserved specific memory region.
>>>>>> Buffer addresses and vma parameters look correct... What could I have
>>>>>> miss here ?
>>>>>
>>>>> No ideas, sorry...
>>>>>
>>>>> Cheers
>>>>> Vladimir
>>>>>
>>>>>>
>>>>>> Benjamin
>>>>>>
>>>>>>>
>>>>>>> [1] http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
>>>>>>>
>>>>>>> Vladimir Murzin (5):
>>>>>>> dma: Add simple dma_noop_mmap
>>>>>>> drivers: dma-coherent: Introduce default DMA pool
>>>>>>> ARM: NOMMU: Introduce dma operations for noMMU
>>>>>>> ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
>>>>>>> ARM: dma-mapping: Remove traces of NOMMU code
>>>>>>>
>>>>>>> .../bindings/reserved-memory/reserved-memory.txt | 3 +
>>>>>>> arch/arm/include/asm/dma-mapping.h | 3 +-
>>>>>>> arch/arm/mm/Kconfig | 2 +-
>>>>>>> arch/arm/mm/Makefile | 5 +-
>>>>>>> arch/arm/mm/dma-mapping-nommu.c | 252 +++++++++++++++++++++
>>>>>>> arch/arm/mm/dma-mapping.c | 26 +--
>>>>>>> drivers/base/dma-coherent.c | 59 ++++-
>>>>>>> lib/dma-noop.c | 21 ++
>>>>>>> 8 files changed, 335 insertions(+), 36 deletions(-)
>>>>>>> create mode 100644 arch/arm/mm/dma-mapping-nommu.c
>>>>>>>
>>>>>>> --
>>>>>>> 2.0.0
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Benjamin Gaignard
>>>>
>>>> Graphic Study Group
>>>>
>>>> Linaro.org ? Open source software for ARM SoCs
>>>>
>>>> Follow Linaro: Facebook | Twitter | Blog
>>>
>>>
>>>
>>
>
>
^ permalink raw reply
* [PATCH 1/5] arm: sunxi: add support for V3s SoC
From: Maxime Ripard @ 2017-01-12 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2706391484163632@web1g.yandex.ru>
1;4601;0c
On Thu, Jan 12, 2017 at 03:40:32AM +0800, Icenowy Zheng wrote:
>
>
> 11.01.2017, 02:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > On Tue, Jan 03, 2017 at 11:16:25PM +0800, Icenowy Zheng wrote:
> >> ?Allwinner V3s is a low-end single-core Cortex-A7 SoC, with 64MB
> >> ?integrated DRAM, and several peripherals.
> >>
> >> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> ?---
> >> ??Documentation/arm/sunxi/README | 4 ++++
> >> ??arch/arm/mach-sunxi/sunxi.c | 1 +
> >> ??2 files changed, 5 insertions(+)
> >>
> >> ?diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> >> ?index cd0243302bc1..91ec8f2055be 100644
> >> ?--- a/Documentation/arm/sunxi/README
> >> ?+++ b/Documentation/arm/sunxi/README
> >> ?@@ -67,6 +67,10 @@ SunXi family
> >> ??????????+ Datasheet
> >> ????????????http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
> >>
> >> ?+ - Allwinner V3s (sun8i)
> >> ?+ + Datasheet
> >> ?+ https://www.goprawn.com/forum/allwinner-cams/783-allwinner-v3s-soc-datasheet
> >> ?+
> >
> > Please don't put random links in there, but at least something that we
> > know will be there in a couple of weeks/monthes/years
>
> Is http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf acceptable?
It's much better, yes.
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/20170112/acac9672/attachment.sig>
^ permalink raw reply
* [kvm-unit-tests PATCH 1/6] libcflat: add PRI(dux)32 format types
From: Alex Bennée @ 2017-01-12 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112165629.nbczamlqlpsqaauh@hawk.localdomain>
Andrew Jones <drjones@redhat.com> writes:
> On Thu, Jan 12, 2017 at 01:29:24PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 11/01/2017 17:28, Alex Benn?e wrote:
>> > So we can have portable formatting of uint32_t types. However there is
>> > a catch. Different compilers can use legally subtly different types
>> > though so we need to probe the compiler defined intdef.h first.
>>
>> Interesting, what platform has long uint32_t? I thought the issue was
>> whether 64-bit is long or "long long".
>>
>> Paolo
>>
>> > Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>> > ---
>> > Makefile | 1 +
>> > configure | 13 +++++++++++++
>> > lib/libcflat.h | 9 +++++++++
>> > 3 files changed, 23 insertions(+)
>> >
>> > diff --git a/Makefile b/Makefile
>> > index a32333b..9822d9a 100644
>> > --- a/Makefile
>> > +++ b/Makefile
>> > @@ -55,6 +55,7 @@ CFLAGS += $(fomit_frame_pointer)
>> > CFLAGS += $(fno_stack_protector)
>> > CFLAGS += $(fno_stack_protector_all)
>> > CFLAGS += $(wno_frame_address)
>> > +CFLAGS += $(if $(U32_LONG_FMT),-D__U32_LONG_FMT__,)
>> >
>> > CXXFLAGS += $(CFLAGS)
>> >
>> > diff --git a/configure b/configure
>> > index 995c8fa..127868c 100755
>> > --- a/configure
>> > +++ b/configure
>> > @@ -109,6 +109,18 @@ if [ -f $testdir/run ]; then
>> > ln -fs $testdir/run $testdir-run
>> > fi
>> >
>> > +# check if uint32_t needs a long format modifier
>> > +cat << EOF > lib_test.c
>> > +#include <inttypes.h>
>> > +EOF
>> > +
>> > +$cross_prefix$cc lib_test.c -E | grep "typedef" | grep "long" | grep "uint32_t" &> /dev/null
>
> This won't work with cross compilers that don't have inttypes.h in their
> path (like mine). How about something like
Hmm good point, in my case inttypes.h came from the libnewlib-dev package.
>
> cat << EOF > lib_test.c
> __UINT32_TYPE__
> EOF
> u32_long="`aarch64-linux-gnu-gcc lib_test.c -E | awk '/unsigned/ && $2 == "long"'`"
Hmm it is not clear from the docs if this is a GCCism. If it is do we
care? Also the docs do say:
"Some of these macros may not be defined on particular systems if GCC does not provide a stdint.h header on those systems. "
> Although I feel there should be a compiler macro way to do this without
> a need for configure/makefile trickery at all...
I did ask our toolchain bods. They started going on about potential
solutions using _Generic but I fear that might be worse in this case!
>
> Thanks,
> drew
>
>
>> > +exit=$?
>> > +if [ $exit -eq 0 ]; then
>> > + u32_long=true
>> > +fi
>> > +rm -f lib_test.c
>> > +
>> > # check for dependent 32 bit libraries
>> > if [ "$arch" != "arm" ]; then
>> > cat << EOF > lib_test.c
>> > @@ -155,4 +167,5 @@ TEST_DIR=$testdir
>> > FIRMWARE=$firmware
>> > ENDIAN=$endian
>> > PRETTY_PRINT_STACKS=$pretty_print_stacks
>> > +U32_LONG_FMT=$u32_long
>> > EOF
>> > diff --git a/lib/libcflat.h b/lib/libcflat.h
>> > index 380395f..e80fc50 100644
>> > --- a/lib/libcflat.h
>> > +++ b/lib/libcflat.h
>> > @@ -58,12 +58,21 @@ typedef _Bool bool;
>> > #define true 1
>> >
>> > #if __SIZEOF_LONG__ == 8
>> > +# define __PRI32_PREFIX
>> > # define __PRI64_PREFIX "l"
>> > # define __PRIPTR_PREFIX "l"
>> > #else
>> > +#if defined(__U32_LONG_FMT__)
>> > +# define __PRI32_PREFIX "l"
>> > +#else
>> > +# define __PRI32_PREFIX
>> > +#endif
>> > # define __PRI64_PREFIX "ll"
>> > # define __PRIPTR_PREFIX
>> > #endif
>> > +#define PRId32 __PRI32_PREFIX "d"
>> > +#define PRIu32 __PRI32_PREFIX "u"
>> > +#define PRIx32 __PRI32_PREFIX "x"
>> > #define PRId64 __PRI64_PREFIX "d"
>> > #define PRIu64 __PRI64_PREFIX "u"
>> > #define PRIx64 __PRI64_PREFIX "x"
>> >
>> --
>> 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
--
Alex Benn?e
^ permalink raw reply
* [PATCH v3 2/3] arm64: dts: juno: fix CoreSight support for Juno r1/r2 variants
From: Sudeep Holla @ 2017-01-12 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkymGdrM8z-ZWan0Fn+Ymq97oHAJtW3G0YdUAxpWSf+aaw@mail.gmail.com>
On 12/01/17 16:51, Mathieu Poirier wrote:
> On 12 January 2017 at 08:20, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> From: Mike Leach <mike.leach@linaro.org>
>>
>> The CoreSight support added for Juno is valid for only Juno r0.
>> The Juno r1 and r2 variants have additional components and alternative
>> connection routes between trace source and sinks.
>>
>> This patch builds on top of the existing r0 support and extends it to
>> Juno r1/r2 variants.
>>
>> Signed-off-by: Mike Leach <mike.leach@linaro.org>
>> [sudeep.holla at arm.com: minor changelog update and reorganising the common
>> coresight components back into juno-base.dtsi to avoid duplication]
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 102 ++++++++++++++++++++++++++++++
>> arch/arm64/boot/dts/arm/juno-r1.dts | 9 +++
>> arch/arm64/boot/dts/arm/juno-r2.dts | 9 +++
>> 3 files changed, 120 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>> new file mode 100644
>> index 000000000000..89fcef366ff9
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>> @@ -0,0 +1,102 @@
>> + csys1_funnel at 20130000 {
>> + compatible = "arm,coresight-funnel", "arm,primecell";
>> + reg = <0 0x20130000 0 0x1000>;
>> +
>> + clocks = <&soc_smc50mhz>;
>> + clock-names = "apb_pclk";
>> + power-domains = <&scpi_devpd 0>;
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + /* input port */
>> + port at 0 {
>> + reg = <0>;
>> + csys1_funnel_out_port: endpoint {
>> + remote-endpoint =
>> + <&etf1_in_port>;
>> + };
>> + };
>> +
>> + /* output port */
>> + port at 1 {
>> + reg = <0>;
>> + csys1_funnel_in_port0: endpoint {
>> + slave-mode;
>> + };
>> + };
>
> The comments related to the input and output port are reversed.
>
Fixed locally.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v3 0/3] arm64: dts: juno: CoreSight support updates
From: Sudeep Holla @ 2017-01-12 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkxm-6eBsURrN_pO1833QNfVL4Li98P48C6ktsytyyagdg@mail.gmail.com>
On 12/01/17 17:08, Mathieu Poirier wrote:
> On 12 January 2017 at 08:20, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> Hi Mike,
>>
>> I just did some refactoring to reduced thge churn and duplication.
>> Can you check if this work for you ? I could not give it much testing.
>>
>> Regards,
>> Sudeep
>>
>> --->8
>> Juno r1/r2 boards have different CoreSight infrastructure outside the
>> CPU clusters. This patchset adds the additional coreSight components to
>> separate .dtsi files to support these differences.
>>
>> v1->v2:
>> - moved the addition of the STM component into a separate patch
>>
>> v2->v3:
>> - moved the back the common coreSight components back into
>> juno-base.dtsi
>>
>>
>> Mike Leach (2):
>> arm64: dts: juno: fix CoreSight support for Juno r1/r2 variants
>> arm64: dts: juno: add missing CoreSight STM component
>>
>> Sudeep Holla (1):
>> arm64: dts: juno: refactor CoreSight support on Juno r0
>>
>> arch/arm64/boot/dts/arm/juno-base.dtsi | 31 ++++++---
>> arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 102 ++++++++++++++++++++++++++++++
>> arch/arm64/boot/dts/arm/juno-r1.dts | 13 ++++
>> arch/arm64/boot/dts/arm/juno-r2.dts | 13 ++++
>> arch/arm64/boot/dts/arm/juno.dts | 24 +++++++
>> 5 files changed, 175 insertions(+), 8 deletions(-)
>> create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>
> For the set:
>
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org> (On R0 only)
>
Thanks for reviewing and testing.
--
Regards,
Sudeep
^ 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