* [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
* [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Maxime Ripard @ 2017-01-12 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2714901484163893@web1g.yandex.ru>
On Thu, Jan 12, 2017 at 03:44:53AM +0800, Icenowy Zheng wrote:
>
>
> 12.01.2017, 03:40, "Icenowy Zheng" <icenowy@aosc.xyz>:
> > 11.01.2017, 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.
> >
> > Nope.
> >
> > It has a different PLL (PLL_ISP) at different address, and some
> > different muxes.
>
> Forgot to mention the missing of PLL_DE and related misses.
Those are not conflicting, it's just a slightly different set of
clocks.
So there's really nothing undoable.
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/c54bf580/attachment.sig>
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: limit use of 2-level stream tables
From: Will Deacon @ 2017-01-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484077633-18376-1-git-send-email-nwatters@codeaurora.org>
On Tue, Jan 10, 2017 at 02:47:13PM -0500, Nate Watterson wrote:
> In the current arm-smmu-v3 driver, all smmus that support 2-level
> stream tables are being forced to use them. This is suboptimal for
> smmus that support fewer stream id bits than would fill in a single
> second level table. This patch limits the use of 2-level tables to
> smmus that both support the feature and whose first level table can
> possibly contain more than a single entry.
>
> Signed-off-by: Nate Watterson <nwatters@codeaurora.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 21 ++++++++++-----------
> 1 file changed, 10 insertions(+), 11 deletions(-)
Thanks Nate, I'll queue this for 4.11. Sorry for messing you about before.
Will
^ permalink raw reply
* [PATCH] ASoC: sun4i-spdif: Add support for the H3 SoC
From: Maxime Ripard @ 2017-01-12 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112164516.15877-1-codekipper@gmail.com>
On Thu, Jan 12, 2017 at 05:45:16PM +0100, codekipper at gmail.com wrote:
> 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>
You should also document the new compatible.
Once this is done, you have my:
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
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/6de91701/attachment.sig>
^ permalink raw reply
* [linux-sunxi][PATCH] ARM: dts: sun8i-h3: Add dts for the Beelink X2 STB
From: Maxime Ripard @ 2017-01-12 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112171135.7822-1-codekipper@gmail.com>
Hi,
On Thu, Jan 12, 2017 at 06:11:35PM +0100, codekipper at gmail.com wrote:
> 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>;
Please drop all the pinctrl nodes for the GPIOs. They're useless, and
will be harmful when we'll switch to a stricter pinctrl driver.
> +
> + 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>;
Should that be BTN_0 then if the label is that one?
> + 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>;
Have you actually tested that it was needed?
> + /* eMMC is missing pull-ups */
> + bias-pull-up;
This is already enabled in the DTSI.
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/d4f5d1b3/attachment-0001.sig>
^ permalink raw reply
* [kvm-unit-tests PATCH 6/6] run_tests: allow passing of options to QEMU
From: Andrew Jones @ 2017-01-12 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-7-alex.bennee@linaro.org>
On Wed, Jan 11, 2017 at 04:28:41PM +0000, Alex Benn?e wrote:
> This allows additional options to be passed to QEMU. It follows the
> convention of passing parameters after a -- to the child process. In
> my case I'm using it to toggle MTTCG on an off:
>
> ./run_tests.sh -- --accel tcg,thread=multi
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>
> ---
> v1
> - changes from -o to --
> - fixed whitespace damage
> ---
> README.md | 6 ++++++
> run_tests.sh | 13 +++++++++++--
> scripts/functions.bash | 7 ++++---
> 3 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/README.md b/README.md
> index fa3a445..1bd6dcb 100644
> --- a/README.md
> +++ b/README.md
> @@ -55,6 +55,12 @@ To extend or disable the timeouts:
>
> TIMEOUT=0 ./run_tests.sh
>
> +Any arguments past the end-of-arguments marker (--) is passed on down
> +to the QEMU invocation. This can of course be combined with the other
> +modifiers:
> +
> + ACCEL=tcg ./run_tests.sh -v -- --accel tcg,thread=multi
> +
> # Contributing
>
> ## Directory structure
> diff --git a/run_tests.sh b/run_tests.sh
> index 254129d..3270fba 100755
> --- a/run_tests.sh
> +++ b/run_tests.sh
> @@ -13,7 +13,7 @@ function usage()
> {
> cat <<EOF
>
> -Usage: $0 [-g group] [-h] [-v]
> +Usage: $0 [-g group] [-h] [-v] [-- QEMU options]
>
> -g: Only execute tests in the given group
> -h: Output this help text
> @@ -22,6 +22,8 @@ Usage: $0 [-g group] [-h] [-v]
> Set the environment variable QEMU=/path/to/qemu-system-ARCH to
> specify the appropriate qemu binary for ARCH-run.
>
> +All options specified after -- are passed on to QEMU.
> +
> EOF
> }
>
> @@ -29,6 +31,7 @@ RUNTIME_arch_run="./$TEST_DIR/run"
> source scripts/runtime.bash
>
> while getopts "g:hv" opt; do
> +
stray blank line added?
> case $opt in
> g)
> only_group=$OPTARG
> @@ -46,6 +49,12 @@ while getopts "g:hv" opt; do
> esac
> done
>
> +# Any options left for QEMU?
> +shift $((OPTIND-1))
> +if [ "$#" -gt 0 ]; then
> + extra_opts="$@"
> +fi
We can unconditionally do the extra_opts="$@", extra_opts will just
be null in the case there aren't more args, like it was before.
> +
> RUNTIME_log_stderr () { cat >> test.log; }
> RUNTIME_log_stdout () {
> if [ "$PRETTY_PRINT_STACKS" = "yes" ]; then
> @@ -59,4 +68,4 @@ RUNTIME_log_stdout () {
> config=$TEST_DIR/unittests.cfg
> rm -f test.log
> printf "BUILD_HEAD=$(cat build-head)\n\n" > test.log
> -for_each_unittest $config run
> +for_each_unittest $config run "$extra_opts"
> diff --git a/scripts/functions.bash b/scripts/functions.bash
> index ee9143c..60fbc6a 100644
> --- a/scripts/functions.bash
> +++ b/scripts/functions.bash
> @@ -3,10 +3,11 @@ function for_each_unittest()
> {
> local unittests="$1"
> local cmd="$2"
> + local extra_opts=$3
> local testname
> local smp
> local kernel
> - local opts
> + local opts=$extra_opts
> local groups
> local arch
> local check
> @@ -21,7 +22,7 @@ function for_each_unittest()
> testname=${BASH_REMATCH[1]}
> smp=1
> kernel=""
> - opts=""
> + opts=$extra_opts
> groups=""
> arch=""
> check=""
> @@ -32,7 +33,7 @@ function for_each_unittest()
> elif [[ $line =~ ^smp\ *=\ *(.*)$ ]]; then
> smp=${BASH_REMATCH[1]}
> elif [[ $line =~ ^extra_params\ *=\ *(.*)$ ]]; then
> - opts=${BASH_REMATCH[1]}
> + opts="$opts ${BASH_REMATCH[1]}"
How do QEMU opts work with respect to precedence? If the later
opts override the earlier (I think they do), then we should put
opts after rematch here, because the user explicitly added those
options to the command line, and therefore probably prefers them.
> elif [[ $line =~ ^groups\ *=\ *(.*)$ ]]; then
> groups=${BASH_REMATCH[1]}
> elif [[ $line =~ ^arch\ *=\ *(.*)$ ]]; then
> --
> 2.11.0
>
Thanks for this patch! I'm looking forward to making use of it for
testing Peter's EL2 series with/without "-machine virtualization=on"
drew
^ permalink raw reply
* [PATCH] ASoC: sunxi: Add bindings for sun8i to SPDIF
From: codekipper at gmail.com @ 2017-01-12 17:33 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 the
transmit fifo is at a different address.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
index 0230c4d20506..fe0a65e6d629 100644
--- a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
+++ b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
@@ -10,6 +10,7 @@ Required properties:
- compatible : should be one of the following:
- "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
- "allwinner,sun6i-a31-spdif": for the Allwinner A31 SoC
+ - "allwinner,sun8i-h3-spdif": for the Allwinner H3 SoC
- reg : Offset and length of the register set for the device.
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox