* [GIT PULL] ARM: mvebu: dt64 for v4.18 (#1)
From: Gregory CLEMENT @ 2018-05-18 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for dt64 for mvebu for v4.18.
Gregory
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.18-1
for you to fetch changes up to bd473ecda24c6214868d58500c4d7569f6597946:
arm64: dts: marvell: armada-37xx: mark the gpio controllers as irq controller (2018-05-18 18:35:16 +0200)
----------------------------------------------------------------
mvebu dt64 for 4.18 (part 1)
- Allow using Armada 3700 gpio controller as interrupt one too
- Describe SPI flash on the EspressoBin
- Mark ahci as dma-coherent for Armada 7K/8K
- Add 10G interface support Armada 7K/8K based boards (including MacBin)
----------------------------------------------------------------
Antoine Tenart (3):
arm64: dts: marvell: mcbin: enable the fourth network interface
arm64: dts: marvell: 8040-db: describe the 10G interfaces as fixed-link
arm64: dts: marvell: 7040-db: describe the 10G interface as fixed-link
Ellie Reeves (1):
arm64: dts: armada-3720-espressobin: wire up spi flash
Mark Kettenis (1):
arm64: dts: marvell: mark CP110 ahci as dma-coherent
Russell King (1):
arm64: dts: marvell: mcbin: add 10G SFP support
Uwe Kleine-K?nig (1):
arm64: dts: marvell: armada-37xx: mark the gpio controllers as irq controller
.../boot/dts/marvell/armada-3720-espressobin.dts | 27 +++++++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 6 ++
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 5 ++
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 10 ++++
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 70 ++++++++++++++++++++++
arch/arm64/boot/dts/marvell/armada-cp110.dtsi | 1 +
6 files changed, 119 insertions(+)
^ permalink raw reply
* [PATCH 2/2] pwm: stm32: initialize raw local variables
From: Randy Dunlap @ 2018-05-18 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526657044-14879-3-git-send-email-fabrice.gasnier@st.com>
On 05/18/2018 08:24 AM, Fabrice Gasnier wrote:
> This removes build warning when COMPILE_TEST=y and MFD_STM32_TIMERS=n
> in drivers/pwm/pwm-stm32.c. In function 'stm32_pwm_capture' 'raw_prd' and
> 'raw_dty' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> drivers/pwm/pwm-stm32.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
> index 60bfc07..09383c6 100644
> --- a/drivers/pwm/pwm-stm32.c
> +++ b/drivers/pwm/pwm-stm32.c
> @@ -170,7 +170,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct pwm_device *pwm,
> unsigned long long prd, div, dty;
> unsigned long rate;
> unsigned int psc = 0, icpsc, scale;
> - u32 raw_prd, raw_dty;
> + u32 raw_prd = 0, raw_dty = 0;
> int ret = 0;
>
> mutex_lock(&priv->lock);
>
--
~Randy
^ permalink raw reply
* [PATCH 1/2] mfd: stm32-timers: fix pwm-stm32 linker issue with COMPILE_TEST
From: Randy Dunlap @ 2018-05-18 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526657044-14879-2-git-send-email-fabrice.gasnier@st.com>
On 05/18/2018 08:24 AM, Fabrice Gasnier wrote:
> This is seen when COMPILE_TEST=y and MFD_STM32_TIMERS=n.
> drivers/pwm/pwm-stm32.o: In function 'stm32_pwm_raw_capture':
> pwm-stm32.c:... undefined reference to 'stm32_timers_dma_burst_read'
> Fixes: 0c6609805b63 ("mfd: stm32-timers: Add support for DMAs")
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> include/linux/mfd/stm32-timers.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
> index 9da1d7e..067d146 100644
> --- a/include/linux/mfd/stm32-timers.h
> +++ b/include/linux/mfd/stm32-timers.h
> @@ -124,8 +124,20 @@ struct stm32_timers {
> struct stm32_timers_dma dma; /* Only to be used by the parent */
> };
>
> +#if IS_REACHABLE(CONFIG_MFD_STM32_TIMERS)
> int stm32_timers_dma_burst_read(struct device *dev, u32 *buf,
> enum stm32_timers_dmas id, u32 reg,
> unsigned int num_reg, unsigned int bursts,
> unsigned long tmo_ms);
> +#else
> +static inline int stm32_timers_dma_burst_read(struct device *dev, u32 *buf,
> + enum stm32_timers_dmas id,
> + u32 reg,
> + unsigned int num_reg,
> + unsigned int bursts,
> + unsigned long tmo_ms)
> +{
> + return -ENODEV;
> +}
> +#endif
> #endif
>
--
~Randy
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Sami Tolvanen @ 2018-05-18 17:02 UTC (permalink / raw)
To: linux-arm-kernel
Starting with LLVM r308050, clang generates a jump table with EL1
virtual addresses in __init_stage2_translation, which results in a
kernel panic when booting at EL2:
Kernel panic - not syncing: HYP panic:
PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
VCPU:000804fc20001221
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc7-dirty #3
Hardware name: ARM Juno development board (r1) (DT)
Call trace:
[<ffff000008088ea4>] dump_backtrace+0x0/0x34c
[<ffff000008089208>] show_stack+0x18/0x20
[<ffff0000089c73ec>] dump_stack+0xc4/0xfc
[<ffff0000080c8e1c>] panic+0x138/0x2b4
[<ffff0000080c8ce4>] panic+0x0/0x2b4
SMP: stopping secondary CPUs
SMP: failed to stop secondary CPUs 0-3,5
Kernel Offset: disabled
CPU features: 0x002086
Memory Limit: none
---[ end Kernel panic - not syncing: HYP panic:
PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
VCPU:000804fc20001221
This change adds -fno-jump-tables to arm64/hyp to work around the
bug.
Suggested-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
arch/arm64/kvm/hyp/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
index 4313f74753332..745b3255e7832 100644
--- a/arch/arm64/kvm/hyp/Makefile
+++ b/arch/arm64/kvm/hyp/Makefile
@@ -5,6 +5,10 @@
ccflags-y += -fno-stack-protector -DDISABLE_BRANCH_PROFILING
+ifeq ($(cc-name),clang)
+ccflags-y += -fno-jump-tables
+endif
+
KVM=../../../../virt/kvm
obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v3-sr.o
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH] arm64: dts: specify 1.8V EMMC capabilities for bcm958742k
From: Florian Fainelli @ 2018-05-18 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526656880-8795-1-git-send-email-scott.branden@broadcom.com>
On Fri, 18 May 2018 08:21:20 -0700, Scott Branden <scott.branden@broadcom.com> wrote:
> Specify 1.8V EMMC capabilities for bcm958742k board to indicate support
> for UHS mode.
>
> Fixes: d4b4aba6be8a ("arm64: dts: Initial DTS files for Broadcom Stingray SOC")
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
Applied to devicetree-arm64/fixes, thanks!
--
Florian
^ permalink raw reply
* dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)
From: Vineet Gupta @ 2018-05-18 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bad125dff49f6e49c895e818c9d1abb346a46e8e.camel@synopsys.com>
On 05/18/2018 06:11 AM, Alexey Brodkin wrote:
> void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr,
> size_t size, enum dma_data_direction dir)
> {
> + if (dir != DMA_TO_DEVICE){
> + dump_stack();
> + printk(" *** %s@%d: DMA direction is %s instead of %s\n",
> + __func__, __LINE__, dir_to_str(dir), dir_to_str(DMA_TO_DEVICE));
> + }
> +
> return _dma_cache_sync(dev, paddr, size, dir);
> }
>
> void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr,
> size_t size, enum dma_data_direction dir)
> {
> + if (dir != DMA_FROM_DEVICE) {
> + dump_stack();
> + printk(" *** %s@%d: DMA direction is %s instead of %s\n",
> + __func__, __LINE__, dir_to_str(dir), dir_to_str(DMA_FROM_DEVICE));
> + }
> +
> return _dma_cache_sync(dev, paddr, size, dir);
> }
...
> In case of MMC/DW_MCI (AKA DesignWare MobileStorage controller) that's an execution flow:
> 1) __dw_mci_start_request()
> 2) dw_mci_pre_dma_transfer()
> 3) dma_map_sg(..., mmc_get_dma_dir(data))
>
> Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : DMA_FROM_DEVICE".
> I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have DMA_TO_DEVICE which
> is quite OK for passing to dma_noncoherent_sync_sg_for_device() but in case of reading we'll have
> DMA_FROM_DEVICE which we'll pass to dma_noncoherent_sync_sg_for_device() in dma_noncoherent_map_sg().
>
> I'd say this is not entirely correct because IMHO arch_sync_dma_for_cpu() is supposed to only be used
> in case of DMA_FROM_DEVICE and arch_sync_dma_for_device() only in case of DMA_TO_DEVICE.
So roughly 10 years ago, some kernel rookie name Vineet Gupta, asked the exact
same question :-)
http://kernelnewbies.kernelnewbies.narkive.com/aGW1QcDv/query-about-dma-sync-for-cpu-and-direction-to-device
I never understood the need for this direction. And if memory serves me right, at
that time I was seeing twice the amount of cache flushing !
> But the real fix of my problem is:
> ---------------------------------------->8------------------------------------
> --- a/lib/dma-noncoherent.c
> +++ b/lib/dma-noncoherent.c
> @@ -35,7 +35,7 @@ static dma_addr_t dma_noncoherent_map_page(struct device *dev, struct page *page
>
> addr = dma_direct_map_page(dev, page, offset, size, dir, attrs);
> if (!dma_mapping_error(dev, addr) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
> - arch_sync_dma_for_device(dev, page_to_phys(page), size, dir);
> + arch_sync_dma_for_device(dev, page_to_phys(page) + offset, size, dir);
> return addr;
> }
> ---------------------------------------->8------------------------------------
>
> You seem to lost an offset in the page so if we happen to have a buffer not aligned to
> a page boundary then we were obviously corrupting data outside our data :)
Neat !
^ permalink raw reply
* [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation
From: Vineet Gupta @ 2018-05-18 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518132731.GA31125@lst.de>
On 05/18/2018 06:23 AM, hch at lst.de wrote:
> Fri, May 18, 2018 at 01:03:46PM +0000, Alexey Brodkin wrote:
>> Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : DMA_FROM_DEVICE".
>> I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have DMA_TO_DEVICE which
>> is quite OK for passing to dma_noncoherent_sync_sg_for_device() but in case of reading we'll have
>> DMA_FROM_DEVICE which we'll pass to dma_noncoherent_sync_sg_for_device() in dma_noncoherent_map_sg().
>>
>> I'd say this is not entirely correct because IMHO arch_sync_dma_for_cpu() is supposed to only be used
>> in case of DMA_FROM_DEVICE and arch_sync_dma_for_device() only in case of DMA_TO_DEVICE.
> arc overrides the dir paramter of the dma_sync_single_for_device/
> dma_sync_single_for_cpu calls. My patches dropped that, and I have
> restored that, and audit for the other architectures is pending.
Right, for now lets retain that and do a sweeping audit of @direction - to me it
seems extraneous (as it did 10 years ago), but I'm not an expert in this are so
perhaps it is needed for some device / arches and it would be good to understand
that finally.
> That being said the existing arc code still looks rather odd as it
> didn't do the same thing for the scatterlist versions of the calls.
> I've thrown in a few patches into my new tree to make the sg versions
> make the normal calls, and to clean up the area a bit.
Not calling names or anything here, but it doesn't exist for sg variants, because
I didn't write that code :-)
It was introduced by your commi:
2016-01-20 052c96dbe33b arc: convert to dma_map_ops
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Marc Zyngier @ 2018-05-18 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518170202.11458-1-samitolvanen@google.com>
On 18/05/18 18:02, Sami Tolvanen wrote:
> Starting with LLVM r308050, clang generates a jump table with EL1
> virtual addresses in __init_stage2_translation, which results in a
> kernel panic when booting at EL2:
>
> Kernel panic - not syncing: HYP panic:
> PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
> FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
> VCPU:000804fc20001221
>
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc7-dirty #3
> Hardware name: ARM Juno development board (r1) (DT)
> Call trace:
> [<ffff000008088ea4>] dump_backtrace+0x0/0x34c
> [<ffff000008089208>] show_stack+0x18/0x20
> [<ffff0000089c73ec>] dump_stack+0xc4/0xfc
> [<ffff0000080c8e1c>] panic+0x138/0x2b4
> [<ffff0000080c8ce4>] panic+0x0/0x2b4
> SMP: stopping secondary CPUs
> SMP: failed to stop secondary CPUs 0-3,5
> Kernel Offset: disabled
> CPU features: 0x002086
> Memory Limit: none
> ---[ end Kernel panic - not syncing: HYP panic:
> PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
> FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
> VCPU:000804fc20001221
>
> This change adds -fno-jump-tables to arm64/hyp to work around the
> bug.
>
> Suggested-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
> arch/arm64/kvm/hyp/Makefile | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
> index 4313f74753332..745b3255e7832 100644
> --- a/arch/arm64/kvm/hyp/Makefile
> +++ b/arch/arm64/kvm/hyp/Makefile
> @@ -5,6 +5,10 @@
>
> ccflags-y += -fno-stack-protector -DDISABLE_BRANCH_PROFILING
>
> +ifeq ($(cc-name),clang)
> +ccflags-y += -fno-jump-tables
> +endif
> +
> KVM=../../../../virt/kvm
>
> obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v3-sr.o
>
I'm going to ask the question I've asked before when this patch cropped
up (must be the 4th time now):
Is it guaranteed that this is the only case where LLVM/clang is going to
generate absolute addresses instead of using relative addressing?
So far, nobody has answered that question. If you assure me that this is
the case, I'll take that patch. Otherwise, we're just playing
whack-a-mole, as with the profiling stuff.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 0/5]
From: Stefan Wahren @ 2018-05-18 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <278cb8b1-d567-2067-2dde-980596821c9c@arm.com>
> Marc Zyngier <marc.zyngier@arm.com> hat am 18. Mai 2018 um 18:41 geschrieben:
>
>
> [/me beats himself for not writing a subject line...]
>
> On 18/05/18 17:29, Vince Weaver wrote:
> > On Fri, 18 May 2018, Marc Zyngier wrote:
> >
> >> There is also the case of people natively running 32bit kernels on
> >> 64bit HW and trying to upstream unspeakable hacks, hoping that the
> >> stars will align and that they'll win the lottery (see [1]).
> >
> > I've tested these patches on a Raspberry Pi 3B running a 32-bit upstream
> > (4.17-rc5-git) kernel and they work.
> >
> > [ 0.472906] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
> >
> > I only needed to add this to the devicetree
> >
> > arm-pmu {
> > compatible = "arm,cortex-a53-pmu";
> > interrupt-parent = <&local_intc>;
> > interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
> > };
>
> That's definitely the sensible thing to have on such hardware. Why isn't
> it in the upstream DT already, irrespective of the state of the kernel
> support?
I remember that Vince point out the absence. He asked about how to implement it and i wasn't sure about it. At this time we hadn't IRQ polarity support. So we wanted to get this puzzle piece before. In march i put it on my TODO list, but then RPI 3 B+ support had higher prio to get into 4.18.
In general we have the problem that most of the users take the downstream kernel and don't know about the differences. Luckily more distributions switch to the upstream kernel, which increases the feedback.
>
> > Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Thanks again
Stefan
>
> Thanks a lot for testing.
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Nick Desaulniers @ 2018-05-18 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <05d14ac7-0feb-63a3-e7ef-b8ca1ae2fd1d@arm.com>
On Fri, May 18, 2018 at 10:30 AM Marc Zyngier <marc.zyngier@arm.com> wrote:
> I'm going to ask the question I've asked before when this patch cropped
> up (must be the 4th time now):
> Is it guaranteed that this is the only case where LLVM/clang is going to
> generate absolute addresses instead of using relative addressing?
It seems like if there's requirements that only relative addressing be
used, then the compiler should be told explicitly about this restriction,
no?
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Nick Desaulniers @ 2018-05-18 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKwvOdm1kYedukCq=g74AvqJHp6KC03oNoouQy2nkvfo4idoEw@mail.gmail.com>
+ Andrey (who reported testing this patch in
https://github.com/ClangBuiltLinux/linux/issues/11)
On Fri, May 18, 2018 at 10:40 AM Nick Desaulniers <ndesaulniers@google.com>
wrote:
> On Fri, May 18, 2018 at 10:30 AM Marc Zyngier <marc.zyngier@arm.com>
wrote:
> > I'm going to ask the question I've asked before when this patch cropped
> > up (must be the 4th time now):
> > Is it guaranteed that this is the only case where LLVM/clang is going to
> > generate absolute addresses instead of using relative addressing?
> It seems like if there's requirements that only relative addressing be
> used, then the compiler should be told explicitly about this restriction,
> no?
> --
> Thanks,
> ~Nick Desaulniers
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Marc Zyngier @ 2018-05-18 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKwvOdm1kYedukCq=g74AvqJHp6KC03oNoouQy2nkvfo4idoEw@mail.gmail.com>
On 18/05/18 18:40, Nick Desaulniers wrote:
> On Fri, May 18, 2018 at 10:30 AM Marc Zyngier <marc.zyngier@arm.com> wrote:
>> I'm going to ask the question I've asked before when this patch cropped
>> up (must be the 4th time now):
>
>> Is it guaranteed that this is the only case where LLVM/clang is going to
>> generate absolute addresses instead of using relative addressing?
>
> It seems like if there's requirements that only relative addressing be
> used, then the compiler should be told explicitly about this restriction,
> no?
Certainly. What's the rune?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)
From: Russell King - ARM Linux @ 2018-05-18 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5ac5b1e3-9b96-9c7c-4dfe-f65be45ec179@synopsys.com>
On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote:
> I never understood the need for this direction. And if memory serves me
> right, at that time I was seeing twice the amount of cache flushing !
It's necessary. Take a moment to think carefully about this:
dma_map_single(, dir)
dma_sync_single_for_cpu(, dir)
dma_sync_single_for_device(, dir)
dma_unmap_single(, dir)
In the case of a DMA-incoherent architecture, the operations done at each
stage depend on the direction argument:
map for_cpu for_device unmap
TO_DEV writeback none writeback none
TO_CPU invalidate invalidate* invalidate invalidate*
BIDIR writeback invalidate writeback invalidate
* - only necessary if the CPU speculatively prefetches.
The multiple invalidations for the TO_CPU case handles different
conditions that can result in data corruption, and for some CPUs, all
four are necessary.
This is what is implemented for 32-bit ARM, depending on the CPU
capabilities, as we have DMA incoherent devices and we have CPUs that
speculatively prefetch data, and so may load data into the caches while
DMA is in operation.
Things get more interesting if the implementation behind the DMA API has
to copy data between the buffer supplied to the mapping and some DMA
accessible buffer:
map for_cpu for_device unmap
TO_DEV copy to dma none copy to dma none
TO_CPU none copy to cpu none copy to cpu
BIDIR copy to dma copy to cpu copy to dma copy to cpu
So, in both cases, the value of the direction argument defines what you
need to do in each call.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Nick Desaulniers @ 2018-05-18 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8c7be44f-086d-65e3-9969-8182261ce82f@arm.com>
+ Andrey
On Fri, May 18, 2018 at 10:45 AM Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 18/05/18 18:40, Nick Desaulniers wrote:
> > On Fri, May 18, 2018 at 10:30 AM Marc Zyngier <marc.zyngier@arm.com>
wrote:
> >> I'm going to ask the question I've asked before when this patch cropped
> >> up (must be the 4th time now):
The previous threads for context:
https://patchwork.kernel.org/patch/10060381/
https://lkml.org/lkml/2018/3/16/434
> >> Is it guaranteed that this is the only case where LLVM/clang is going
to
> >> generate absolute addresses instead of using relative addressing?
> >
> > It seems like if there's requirements that only relative addressing be
> > used, then the compiler should be told explicitly about this
restriction,
> > no?
> Certainly. What's the rune?
It seems like -fno-jump-tables covers all known issues and unblocks people
from doing further work. It sounds like you'd like some kind of stronger
guarantee? Wont those cases still "crop up" as far as needing to annotate
either the code, or build scripts?
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH V6] ARM: dts: da850-evm: Enable LCD and Backlight
From: Adam Ford @ 2018-05-18 18:02 UTC (permalink / raw)
To: linux-arm-kernel
When using the board files the LCD works, but not with the DT.
This adds enables the original da850-evm to work with the same
LCD in device tree mode.
The EVM has a gpio for the regulator and a PWM for dimming the
backlight. The LCD and the vpif display pins are mutually
exclusive, so if using the LCD, do not load the vpif driver.
Signed-off-by: Adam Ford <aford173@gmail.com>
---
V6: Fix some whitespace and comment formatting. Rename backlight_reg to
backlight_lcd
V5: Resync against v4.18/dt
V4: Move the backlight to PWM, so the driver can control the regulator allowing the
regulator to power down and enabling the ability to change the brightness of the
backlight
V3: Fix errant GPIO, label GPIO pins, and rename the regulator to be more explict to
backlight which better matches the schematic. Updated the description to explain
that it cannot be used at the same time as the vpif driver.
V2: Add regulator and GPIO enable pins. Remove PWM backlight and replace with GPIO
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 0e82bb988fde..3e760e23d88c 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -27,6 +27,60 @@
spi0 = &spi1;
};
+ backlight: backlight-pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ecap2_pins>;
+ power-supply = <&backlight_reg>;
+ compatible = "pwm-backlight";
+ pwms = <&ecap2 0 50000 0>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 99>;
+ default-brightness-level = <7>;
+ };
+
+ panel {
+ compatible = "ti,tilcdc,panel";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+ /*
+ * The vpif and the LCD are mutually exclusive.
+ * To enable VPIF, change the status below to 'disabled' then
+ * then change the status of the vpif below to 'okay'
+ */
+ status = "okay";
+ enable-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>; /* lcd_panel_pwr */
+
+ panel-info {
+ ac-bias = <255>;
+ ac-bias-intrpt = <0>;
+ dma-burst-sz = <16>;
+ bpp = <16>;
+ fdd = <0x80>;
+ sync-edge = <0>;
+ sync-ctrl = <1>;
+ raster-order = <0>;
+ fifo-th = <0>;
+ };
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 480x272 {
+ clock-frequency = <9000000>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <3>;
+ hback-porch = <2>;
+ hsync-len = <42>;
+ vback-porch = <3>;
+ vfront-porch = <4>;
+ vsync-len = <11>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+ };
+ };
+
vbat: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vbat";
@@ -35,6 +89,15 @@
regulator-boot-on;
};
+ backlight_lcd: backlight-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_backlight_pwr";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio 47 GPIO_ACTIVE_HIGH>; /* lcd_backlight_pwr */
+ enable-active-high;
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,name = "DA850/OMAP-L138 EVM";
@@ -63,6 +126,10 @@
};
};
+&ecap2 {
+ status = "okay";
+};
+
&pmx_core {
status = "okay";
@@ -109,6 +176,10 @@
status = "okay";
};
+&lcdc {
+ status = "okay";
+};
+
&i2c0 {
status = "okay";
clock-frequency = <100000>;
@@ -336,5 +407,10 @@
&vpif {
pinctrl-names = "default";
pinctrl-0 = <&vpif_capture_pins>, <&vpif_display_pins>;
- status = "okay";
+ /*
+ * The vpif and the LCD are mutually exclusive.
+ * To enable VPIF, disable the ti,tilcdc,panel then
+ * changed the status below to 'okay'
+ */
+ status = "disabled";
};
--
2.17.0
^ permalink raw reply related
* [PATCH v2 07/40] iommu: Add a page fault handler
From: Jacob Pan @ 2018-05-18 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511190641.23008-8-jean-philippe.brucker@arm.com>
On Fri, 11 May 2018 20:06:08 +0100
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> wrote:
> Some systems allow devices to handle I/O Page Faults in the core mm.
> For example systems implementing the PCI PRI extension or Arm SMMU
> stall model. Infrastructure for reporting these recoverable page
> faults was recently added to the IOMMU core for SVA virtualisation.
> Add a page fault handler for host SVA.
>
> IOMMU driver can now instantiate several fault workqueues and link
> them to IOPF-capable devices. Drivers can choose between a single
> global workqueue, one per IOMMU device, one per low-level fault
> queue, one per domain, etc.
>
> When it receives a fault event, supposedly in an IRQ handler, the
> IOMMU driver reports the fault using iommu_report_device_fault(),
> which calls the registered handler. The page fault handler then calls
> the mm fault handler, and reports either success or failure with
> iommu_page_response(). When the handler succeeded, the IOMMU retries
> the access.
>
> The iopf_param pointer could be embedded into iommu_fault_param. But
> putting iopf_param into the iommu_param structure allows us not to
> care about ordering between calls to iopf_queue_add_device() and
> iommu_register_device_fault_handler().
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
>
> ---
> v1->v2: multiple queues registered by IOMMU driver
> ---
> drivers/iommu/Kconfig | 4 +
> drivers/iommu/Makefile | 1 +
> drivers/iommu/io-pgfault.c | 363
> +++++++++++++++++++++++++++++++++++++ include/linux/iommu.h |
> 58 ++++++ 4 files changed, 426 insertions(+)
> create mode 100644 drivers/iommu/io-pgfault.c
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 38434899e283..09f13a7c4b60 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -79,6 +79,10 @@ config IOMMU_SVA
> select IOMMU_API
> select MMU_NOTIFIER
>
> +config IOMMU_PAGE_FAULT
> + bool
> + select IOMMU_API
> +
> config FSL_PAMU
> bool "Freescale IOMMU support"
> depends on PCI
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 1dbcc89ebe4c..4b744e399a1b 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_IOMMU_API) += iommu-traces.o
> obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
> obj-$(CONFIG_IOMMU_DMA) += dma-iommu.o
> obj-$(CONFIG_IOMMU_SVA) += iommu-sva.o
> +obj-$(CONFIG_IOMMU_PAGE_FAULT) += io-pgfault.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE_ARMV7S) += io-pgtable-arm-v7s.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
> diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
> new file mode 100644
> index 000000000000..321c00dd3a3d
> --- /dev/null
> +++ b/drivers/iommu/io-pgfault.c
> @@ -0,0 +1,363 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Handle device page faults
> + *
> + * Copyright (C) 2018 ARM Ltd.
> + */
> +
> +#include <linux/iommu.h>
> +#include <linux/list.h>
> +#include <linux/slab.h>
> +#include <linux/workqueue.h>
> +
> +/**
> + * struct iopf_queue - IO Page Fault queue
> + * @wq: the fault workqueue
> + * @flush: low-level flush callback
> + * @flush_arg: flush() argument
> + * @refs: references to this structure taken by producers
> + */
> +struct iopf_queue {
> + struct workqueue_struct *wq;
> + iopf_queue_flush_t flush;
> + void *flush_arg;
> + refcount_t refs;
> +};
> +
> +/**
> + * struct iopf_device_param - IO Page Fault data attached to a device
> + * @queue: IOPF queue
> + * @partial: faults that are part of a Page Request Group for which
> the last
> + * request hasn't been submitted yet.
> + */
> +struct iopf_device_param {
> + struct iopf_queue *queue;
> + struct list_head partial;
> +};
> +
> +struct iopf_context {
> + struct device *dev;
> + struct iommu_fault_event evt;
> + struct list_head head;
> +};
> +
> +struct iopf_group {
> + struct iopf_context last_fault;
> + struct list_head faults;
> + struct work_struct work;
> +};
> +
All the page requests in the group should belong to the same device,
perhaps struct device tracking should be in iopf_group instead of
iopf_context?
> +static int iopf_complete(struct device *dev, struct
> iommu_fault_event *evt,
> + enum page_response_code status)
> +{
> + struct page_response_msg resp = {
> + .addr = evt->addr,
> + .pasid = evt->pasid,
> + .pasid_present = evt->pasid_valid,
> + .page_req_group_id = evt->page_req_group_id,
> + .private_data = evt->iommu_private,
> + .resp_code = status,
> + };
> +
> + return iommu_page_response(dev, &resp);
> +}
> +
> +static enum page_response_code
> +iopf_handle_single(struct iopf_context *fault)
> +{
> + /* TODO */
> + return -ENODEV;
> +}
> +
> +static void iopf_handle_group(struct work_struct *work)
> +{
> + struct iopf_group *group;
> + struct iopf_context *fault, *next;
> + enum page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
> +
> + group = container_of(work, struct iopf_group, work);
> +
> + list_for_each_entry_safe(fault, next, &group->faults, head) {
> + struct iommu_fault_event *evt = &fault->evt;
> + /*
> + * Errors are sticky: don't handle subsequent faults
> in the
> + * group if there is an error.
> + */
There might be performance benefit for certain device to continue in
spite of error in that the ATS retry may have less fault. Perhaps a
policy decision for later enhancement.
> + if (status == IOMMU_PAGE_RESP_SUCCESS)
> + status = iopf_handle_single(fault);
> +
> + if (!evt->last_req)
> + kfree(fault);
> + }
> +
> + iopf_complete(group->last_fault.dev, &group->last_fault.evt,
> status);
> + kfree(group);
> +}
> +
> +/**
> + * iommu_queue_iopf - IO Page Fault handler
> + * @evt: fault event
> + * @cookie: struct device, passed to
> iommu_register_device_fault_handler.
> + *
> + * Add a fault to the device workqueue, to be handled by mm.
> + */
> +int iommu_queue_iopf(struct iommu_fault_event *evt, void *cookie)
> +{
> + struct iopf_group *group;
> + struct iopf_context *fault, *next;
> + struct iopf_device_param *iopf_param;
> +
> + struct device *dev = cookie;
> + struct iommu_param *param = dev->iommu_param;
> +
> + if (WARN_ON(!mutex_is_locked(¶m->lock)))
> + return -EINVAL;
> +
> + if (evt->type != IOMMU_FAULT_PAGE_REQ)
> + /* Not a recoverable page fault */
> + return IOMMU_PAGE_RESP_CONTINUE;
> +
> + /*
> + * As long as we're holding param->lock, the queue can't be
> unlinked
> + * from the device and therefore cannot disappear.
> + */
> + iopf_param = param->iopf_param;
> + if (!iopf_param)
> + return -ENODEV;
> +
> + if (!evt->last_req) {
> + fault = kzalloc(sizeof(*fault), GFP_KERNEL);
> + if (!fault)
> + return -ENOMEM;
> +
> + fault->evt = *evt;
> + fault->dev = dev;
> +
> + /* Non-last request of a group. Postpone until the
> last one */
> + list_add(&fault->head, &iopf_param->partial);
> +
> + return IOMMU_PAGE_RESP_HANDLED;
> + }
> +
> + group = kzalloc(sizeof(*group), GFP_KERNEL);
> + if (!group)
> + return -ENOMEM;
> +
> + group->last_fault.evt = *evt;
> + group->last_fault.dev = dev;
> + INIT_LIST_HEAD(&group->faults);
> + list_add(&group->last_fault.head, &group->faults);
> + INIT_WORK(&group->work, iopf_handle_group);
> +
> + /* See if we have partial faults for this group */
> + list_for_each_entry_safe(fault, next, &iopf_param->partial,
> head) {
> + if (fault->evt.page_req_group_id ==
> evt->page_req_group_id)
If all 9 bit group index are used, there can be lots of PRGs. For
future enhancement, maybe we can have per group partial list ready to
go when LPIG comes in? I will be less searching.
> + /* Insert *before* the last fault */
> + list_move(&fault->head, &group->faults);
> + }
> +
If you already sorted the group list with last fault at the end, why do
you need a separate entry to track the last fault?
> + queue_work(iopf_param->queue->wq, &group->work);
> +
> + /* Postpone the fault completion */
> + return IOMMU_PAGE_RESP_HANDLED;
> +}
> +EXPORT_SYMBOL_GPL(iommu_queue_iopf);
> +
> +/**
> + * iopf_queue_flush_dev - Ensure that all queued faults have been
> processed
> + * @dev: the endpoint whose faults need to be flushed.
> + *
> + * Users must call this function when releasing a PASID, to ensure
> that all
> + * pending faults for this PASID have been handled, and won't hit
> the address
> + * space of the next process that uses this PASID.
> + *
> + * Return 0 on success.
> + */
> +int iopf_queue_flush_dev(struct device *dev)
> +{
> + int ret = 0;
> + struct iopf_queue *queue;
> + struct iommu_param *param = dev->iommu_param;
> +
> + if (!param)
> + return -ENODEV;
> +
> + /*
> + * It is incredibly easy to find ourselves in a deadlock
> situation if
> + * we're not careful, because we're taking the opposite path
> as
> + * iommu_queue_iopf:
> + *
> + * iopf_queue_flush_dev() | PRI queue handler
> + * lock(mutex) | iommu_queue_iopf()
> + * queue->flush() | lock(mutex)
> + * wait PRI queue empty |
> + *
> + * So we can't hold the device param lock while flushing. We
> don't have
> + * to, because the queue or the device won't disappear until
> all flush
> + * are finished.
> + */
> + mutex_lock(¶m->lock);
> + if (param->iopf_param) {
> + queue = param->iopf_param->queue;
> + } else {
> + ret = -ENODEV;
> + }
> + mutex_unlock(¶m->lock);
> + if (ret)
> + return ret;
> +
> + queue->flush(queue->flush_arg, dev);
> +
> + /*
> + * No need to clear the partial list. All PRGs containing
> the PASID that
> + * needs to be decommissioned are whole (the device driver
> made sure of
> + * it before this function was called). They have been
> submitted to the
> + * queue by the above flush().
> + */
So you are saying device driver need to make sure LPIG PRQ is submitted
in the flush call above such that partial list is cleared? what if
there are device failures where device needs to reset (either whole
function level or PASID level), should there still be a need to clear
the partial list for all associated PASID/group?
> + flush_workqueue(queue->wq);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_flush_dev);
> +
> +/**
> + * iopf_queue_add_device - Add producer to the fault queue
> + * @queue: IOPF queue
> + * @dev: device to add
> + */
> +int iopf_queue_add_device(struct iopf_queue *queue, struct device
> *dev) +{
> + int ret = -EINVAL;
> + struct iopf_device_param *iopf_param;
> + struct iommu_param *param = dev->iommu_param;
> +
> + if (!param)
> + return -ENODEV;
> +
> + iopf_param = kzalloc(sizeof(*iopf_param), GFP_KERNEL);
> + if (!iopf_param)
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(&iopf_param->partial);
> + iopf_param->queue = queue;
> +
> + mutex_lock(¶m->lock);
> + if (!param->iopf_param) {
> + refcount_inc(&queue->refs);
> + param->iopf_param = iopf_param;
> + ret = 0;
> + }
> + mutex_unlock(¶m->lock);
> +
> + if (ret)
> + kfree(iopf_param);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_add_device);
> +
> +/**
> + * iopf_queue_remove_device - Remove producer from fault queue
> + * @dev: device to remove
> + *
> + * Caller makes sure that no more fault is reported for this device,
> and no more
> + * flush is scheduled for this device.
> + *
> + * Note: safe to call unconditionally on a cleanup path, even if the
> device
> + * isn't registered to any IOPF queue.
> + *
> + * Return 0 if the device was attached to the IOPF queue
> + */
> +int iopf_queue_remove_device(struct device *dev)
> +{
> + struct iopf_context *fault, *next;
> + struct iopf_device_param *iopf_param;
> + struct iommu_param *param = dev->iommu_param;
> +
> + if (!param)
> + return -EINVAL;
> +
> + mutex_lock(¶m->lock);
> + iopf_param = param->iopf_param;
> + if (iopf_param) {
> + refcount_dec(&iopf_param->queue->refs);
> + param->iopf_param = NULL;
> + }
> + mutex_unlock(¶m->lock);
> + if (!iopf_param)
> + return -EINVAL;
> +
> + list_for_each_entry_safe(fault, next, &iopf_param->partial,
> head)
> + kfree(fault);
> +
> + /*
> + * No more flush is scheduled, and the caller removed all
> bonds from
> + * this device. unbind() waited until any concurrent
> mm_exit() finished,
> + * therefore there is no flush() running anymore and we can
> free the
> + * param.
> + */
> + kfree(iopf_param);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_remove_device);
> +
> +/**
> + * iopf_queue_alloc - Allocate and initialize a fault queue
> + * @name: a unique string identifying the queue (for workqueue)
> + * @flush: a callback that flushes the low-level queue
> + * @cookie: driver-private data passed to the flush callback
> + *
> + * The callback is called before the workqueue is flushed. The IOMMU
> driver must
> + * commit all faults that are pending in its low-level queues at the
> time of the
> + * call, into the IOPF queue (with iommu_report_device_fault). The
> callback
> + * takes a device pointer as argument, hinting what endpoint is
> causing the
> + * flush. When the device is NULL, all faults should be committed.
> + */
> +struct iopf_queue *
> +iopf_queue_alloc(const char *name, iopf_queue_flush_t flush, void
> *cookie) +{
> + struct iopf_queue *queue;
> +
> + queue = kzalloc(sizeof(*queue), GFP_KERNEL);
> + if (!queue)
> + return NULL;
> +
> + /*
> + * The WQ is unordered because the low-level handler
> enqueues faults by
> + * group. PRI requests within a group have to be ordered,
> but once
> + * that's dealt with, the high-level function can handle
> groups out of
> + * order.
> + */
> + queue->wq = alloc_workqueue("iopf_queue/%s", WQ_UNBOUND, 0,
> name);
> + if (!queue->wq) {
> + kfree(queue);
> + return NULL;
> + }
> +
> + queue->flush = flush;
> + queue->flush_arg = cookie;
> + refcount_set(&queue->refs, 1);
> +
> + return queue;
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_alloc);
> +
> +/**
> + * iopf_queue_free - Free IOPF queue
> + * @queue: queue to free
> + *
> + * Counterpart to iopf_queue_alloc(). Caller must make sure that all
> producers
> + * have been removed.
> + */
> +void iopf_queue_free(struct iopf_queue *queue)
> +{
> +
> + /* Caller should have removed all producers first */
> + if (WARN_ON(!refcount_dec_and_test(&queue->refs)))
> + return;
> +
> + destroy_workqueue(queue->wq);
> + kfree(queue);
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_free);
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index faf3390ce89d..fad3a60e1c14 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -461,11 +461,20 @@ struct iommu_fault_param {
> void *data;
> };
>
> +/**
> + * iopf_queue_flush_t - Flush low-level page fault queue
> + *
> + * Report all faults currently pending in the low-level page fault
> queue
> + */
> +struct iopf_queue;
> +typedef int (*iopf_queue_flush_t)(void *cookie, struct device *dev);
> +
> /**
> * struct iommu_param - collection of per-device IOMMU data
> *
> * @fault_param: IOMMU detected device fault reporting data
> * @sva_param: SVA parameters
> + * @iopf_param: I/O Page Fault queue and data
> *
> * TODO: migrate other per device data pointers under
> iommu_dev_data, e.g.
> * struct iommu_group *iommu_group;
> @@ -475,6 +484,7 @@ struct iommu_param {
> struct mutex lock;
> struct iommu_fault_param *fault_param;
> struct iommu_sva_param *sva_param;
> + struct iopf_device_param *iopf_param;
> };
>
> int iommu_device_register(struct iommu_device *iommu);
> @@ -874,6 +884,12 @@ static inline int
> iommu_report_device_fault(struct device *dev, struct iommu_fau return
> 0; }
>
> +static inline int iommu_page_response(struct device *dev,
> + struct page_response_msg *msg)
> +{
> + return -ENODEV;
> +}
> +
> static inline int iommu_group_id(struct iommu_group *group)
> {
> return -ENODEV;
> @@ -1038,4 +1054,46 @@ static inline struct mm_struct
> *iommu_sva_find(int pasid) }
> #endif /* CONFIG_IOMMU_SVA */
>
> +#ifdef CONFIG_IOMMU_PAGE_FAULT
> +extern int iommu_queue_iopf(struct iommu_fault_event *evt, void
> *cookie); +
> +extern int iopf_queue_add_device(struct iopf_queue *queue, struct
> device *dev); +extern int iopf_queue_remove_device(struct device
> *dev); +extern int iopf_queue_flush_dev(struct device *dev);
> +extern struct iopf_queue *
> +iopf_queue_alloc(const char *name, iopf_queue_flush_t flush, void
> *cookie); +extern void iopf_queue_free(struct iopf_queue *queue);
> +#else /* CONFIG_IOMMU_PAGE_FAULT */
> +static inline int iommu_queue_iopf(struct iommu_fault_event *evt,
> void *cookie) +{
> + return -ENODEV;
> +}
> +
> +static inline int iopf_queue_add_device(struct iopf_queue *queue,
> + struct device *dev)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int iopf_queue_remove_device(struct device *dev)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int iopf_queue_flush_dev(struct device *dev)
> +{
> + return -ENODEV;
> +}
> +
> +static inline struct iopf_queue *
> +iopf_queue_alloc(const char *name, iopf_queue_flush_t flush, void
> *cookie) +{
> + return NULL;
> +}
> +
> +static inline void iopf_queue_free(struct iopf_queue *queue)
> +{
> +}
> +#endif /* CONFIG_IOMMU_PAGE_FAULT */
> +
> #endif /* __LINUX_IOMMU_H */
^ permalink raw reply
* [PATCH V2] ARM: davinci_all_defconfig: set CONFIG_BACKLIGHT_PWM=m
From: Adam Ford @ 2018-05-18 18:09 UTC (permalink / raw)
To: linux-arm-kernel
The da850-evm came with an LCD with a backlight tied to a pwm. This
enables CONFIG_BACKLIGHT_PWM as a module so the PWM backlight can be
used to maintain brightness control of the backlight.
Signed-off-by: Adam Ford <aford173@gmail.com>
---
V2: Only enable CONFIG_BACKLIGHT_PWM and do not re-sync with savedefconfig
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index c302a04e8cbc..48d23956d898 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -153,6 +153,7 @@ CONFIG_TINYDRM_ST7586=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DA8XX=y
+CONFIG_BACKLIGHT_PWM=m
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
CONFIG_SOUND=m
--
2.17.0
^ permalink raw reply related
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Marc Zyngier @ 2018-05-18 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKwvOd=XZqg5=mkXZb-cxq3i_AGoJGAbmF=Fwc7Q98oi0tbN9g@mail.gmail.com>
On 18/05/18 18:56, Nick Desaulniers wrote:
> + Andrey
>
> On Fri, May 18, 2018 at 10:45 AM Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 18/05/18 18:40, Nick Desaulniers wrote:
>>> On Fri, May 18, 2018 at 10:30 AM Marc Zyngier <marc.zyngier@arm.com>
> wrote:
>>>> I'm going to ask the question I've asked before when this patch cropped
>>>> up (must be the 4th time now):
>
> The previous threads for context:
> https://patchwork.kernel.org/patch/10060381/
> https://lkml.org/lkml/2018/3/16/434
>
>>>> Is it guaranteed that this is the only case where LLVM/clang is going
> to
>>>> generate absolute addresses instead of using relative addressing?
>>>
>>> It seems like if there's requirements that only relative addressing be
>>> used, then the compiler should be told explicitly about this
> restriction,
>>> no?
>
>> Certainly. What's the rune?
>
> It seems like -fno-jump-tables covers all known issues and unblocks people
> from doing further work. It sounds like you'd like some kind of stronger
> guarantee? Wont those cases still "crop up" as far as needing to annotate
> either the code, or build scripts?
What I'd really like is to apply that patch knowing that:
- you have checked that with a released version of the compiler, you
don't observe any absolute address in any of the objects that are going
to be executed at EL2 on a mainline kernel,
- you have successfully run guests with a mainline kernel,
- it works for a reasonable set of common kernel configurations
(defconfig and some of the most useful debug options),
- I can reproduce your findings with the same released compiler.
Is that the case? I don't think any of the above is completely outlandish.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* AArch64 memory
From: Robin Murphy @ 2018-05-18 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU2kK1rF-ozLSyV-ctY=ySfkkzqMoFiFgSk724mXJ_Wa-w@mail.gmail.com>
On 18/05/18 17:43, Tim Harvey wrote:
[...]
>>> My second question has to do with CMA and coherent_pool. I have
>>> understood CMA as being a chunk of physical memory carved out by the
>>> kernel for allocations from dma_alloc_coherent by drivers that need
>>> chunks of contiguous memory for DMA buffers. I believe that before CMA
>>> was introduced we had to do this by defining memory holes. I'm not
>>> understanding the difference between CMA and the coherent pool. I've
>>> noticed that if CONFIG_DMA_CMA=y then the coherent pool allocates from
>>> CMA. Is there some disadvantage of CONFIG_DMA_CMA=y other than if
>>> defined you need to make sure your CMA is larger than coherent_pool?
>>> What drivers/calls use coherent_pool vs cma?
>>
>>
>> coherent_pool is a special thing which exists for the sake of
>> non-hardware-coherent devices - normally for those we satisfy DMA-coherent
>> allocations by setting up a non-cacheable remap of the allocated buffer -
>> see dma_common_contiguous_remap(). However, drivers may call
>> dma_alloc_coherent(..., GFP_ATOMIC) from interrupt handlers, at which point
>> we can't call get_vm_area() to remap on demand, since that might sleep, so
>> we reserve a pool pre-mapped as non-cacheable to satisfy such atomic
>> allocations from. I'm not sure why its user-visible name is "coherent pool"
>> rather than the more descriptive "atomic pool" which it's named internally,
>> but there's probably some history there. If you're lucky enough not to have
>> any non-coherent DMA masters then you can safely ignore the whole thing;
>> otherwise it's still generally rare that it should need adjusting.
>
> is there an easy way to tell if I have non-coherent DMA masters? The
> Cavium SDK uses a kernel cmdline param of coherent_pool=16M so I'm
> guessing something in the CN80XX/CN81XX (BGX NIC's or CPT perhaps)
> need atomic pool mem.
AFAIK the big-boy CN88xx is fully coherent everywhere, but whether the
peripherals and interconnect in the littler Octeon TX variants are
different I have no idea. If the contents of your dts-newport repo on
GitHub are the right thing to be looking at, then you do have the
"dma-coherent" property on the PCI nodes, which should cover everything
beneath (I'd expect that in reality the SMMU may actually be coherent as
well, but fortunately that's irrelevant here). Thus everything which
matters *should* be being picked up as coherent already, and if not it
would be a Linux problem. I can't imagine what the SDK is up to there,
but 16MB of coherent pool does sound like something being done wrong,
like incorrectly compensating for bad firmware failing to describe the
hardware properly in the first place.
>> CMA is, as you surmise, a much more general thing for providing large
>> physically-contiguous areas, which the arch code correspondingly uses to get
>> DMA-contiguous buffers. Unless all your DMA masters are behind IOMMUs (such
>> that we can make any motley collection of pages look DMA-contiguous), you
>> probably don't want to turn it off. None of these details should be relevant
>> as far as drivers are concerned, since from their viewpoint it's all
>> abstracted behind dma_alloc_coherent().
>>
>
> I don't want to turn off CONFIG_CMA but I'm still not clear if I
> should turn off CONFIG_DMA_CMA. I noticed the Cavium SDK 4.9 kernel
> has CONFIG_CMA=y but does not enable CONFIG_DMA_CMA which I believe
> means that the atomic pool does not pull its chunks from the CMA pool.
I wouldn't think there's much good reason to turn DMA_CMA off either,
even if nothing actually needs huge DMA buffers. Where the atomic pool
comes from shouldn't really matter, as it's a very early one-off
allocation. To speculate wildly I suppose there *might* possibly be some
performance difference between cma_alloc() and falling back to the
regular page allocator - if that were the case it ought to be measurable
by profiling something which calls dma_alloc_coherent() in process
context a lot, under both configurations. Even then I'd imagine it's
something that would matter most on the 2-socket 96-core systems, and
not so much on the diddy ones.
Robin.
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Nick Desaulniers @ 2018-05-18 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3fd89842-86cd-ee01-0c2c-5438dd2d5f2a@arm.com>
On Fri, May 18, 2018 at 11:13 AM Marc Zyngier <marc.zyngier@arm.com> wrote:
> What I'd really like is to apply that patch knowing that:
> - you have checked that with a released version of the compiler, you
> don't observe any absolute address in any of the objects that are going
> to be executed at EL2 on a mainline kernel,
To verify, we should disassemble objects from arch/arm64/kvm/hyp/*.o and
make sure we don't see absolute addresses? I can work with Sami to get a
sense of what the before and after of this patch looks like in disassembly,
then verify those changes are pervasive.
> - you have successfully run guests with a mainline kernel,
I believe Andrey has already done this. If he can verify (maybe during
working hours next week), then maybe we can add his Tested-by to this
patches commit message?
> - it works for a reasonable set of common kernel configurations
> (defconfig and some of the most useful debug options),
It's easy for us to test our kernel configs for Android, ChromeOS, and
defconfig. I'd be curious to know the shortlist of "most useful debug
options" just to be a better kernel developer, personally.
> - I can reproduce your findings with the same released compiler.
Lets wait for Andrey to confirm his test setup. On the Android side, I
think you should be able to get by with a released version, but I'd be
curious to hear from Andrey.
> Is that the case? I don't think any of the above is completely outlandish.
These are all reasonable. Thanks for the feedback.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
From: Scott Branden @ 2018-05-18 18:34 UTC (permalink / raw)
To: linux-arm-kernel
Move remaining sata configuration to stingray-sata.dtsi and enable
ports based on NUM_SATA defined.
Now, all that needs to be done is define NUM_SATA per board.
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
.../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 --------------------
.../boot/dts/broadcom/stingray/bcm958742k.dts | 2 +
.../boot/dts/broadcom/stingray/bcm958742t.dts | 2 +
.../boot/dts/broadcom/stingray/stingray-sata.dtsi | 68 ++++++++++++++++++++++
4 files changed, 72 insertions(+), 64 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index 8862ec9..cacc25e 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -72,70 +72,6 @@
<0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
};
-&sata0 {
- status = "okay";
-};
-
-&sata_phy0{
- status = "okay";
-};
-
-&sata1 {
- status = "okay";
-};
-
-&sata_phy1{
- status = "okay";
-};
-
-&sata2 {
- status = "okay";
-};
-
-&sata_phy2{
- status = "okay";
-};
-
-&sata3 {
- status = "okay";
-};
-
-&sata_phy3{
- status = "okay";
-};
-
-&sata4 {
- status = "okay";
-};
-
-&sata_phy4{
- status = "okay";
-};
-
-&sata5 {
- status = "okay";
-};
-
-&sata_phy5{
- status = "okay";
-};
-
-&sata6 {
- status = "okay";
-};
-
-&sata_phy6{
- status = "okay";
-};
-
-&sata7 {
- status = "okay";
-};
-
-&sata_phy7{
- status = "okay";
-};
-
&mdio_mux_iproc {
mdio at 10 {
gphy0: eth-phy at 10 {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
index 77efa28..a515346 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
@@ -32,6 +32,8 @@
/dts-v1/;
+#define NUM_SATA 8
+
#include "bcm958742-base.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
index 5084b03..6a4d19e 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
@@ -32,6 +32,8 @@
/dts-v1/;
+#define NUM_SATA 8
+
#include "bcm958742-base.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
index 8c68e0c..7f6d176 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
@@ -43,7 +43,11 @@
interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 0)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata0_port0: sata-port at 0 {
reg = <0>;
@@ -58,7 +62,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 0)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata0_phy0: sata-phy at 0 {
reg = <0>;
@@ -73,7 +81,11 @@
interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 1)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata1_port0: sata-port at 0 {
reg = <0>;
@@ -88,7 +100,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 1)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata1_phy0: sata-phy at 0 {
reg = <0>;
@@ -103,7 +119,11 @@
interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 2)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata2_port0: sata-port at 0 {
reg = <0>;
@@ -118,7 +138,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 2)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata2_phy0: sata-phy at 0 {
reg = <0>;
@@ -133,7 +157,11 @@
interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 3)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata3_port0: sata-port at 0 {
reg = <0>;
@@ -148,7 +176,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 3)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata3_phy0: sata-phy at 0 {
reg = <0>;
@@ -163,7 +195,11 @@
interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 4)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata4_port0: sata-port at 0 {
reg = <0>;
@@ -178,7 +214,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 4)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata4_phy0: sata-phy at 0 {
reg = <0>;
@@ -193,7 +233,11 @@
interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 5)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata5_port0: sata-port at 0 {
reg = <0>;
@@ -208,7 +252,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 5)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata5_phy0: sata-phy at 0 {
reg = <0>;
@@ -223,7 +271,11 @@
interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 6)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata6_port0: sata-port at 0 {
reg = <0>;
@@ -238,7 +290,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 6)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata6_phy0: sata-phy at 0 {
reg = <0>;
@@ -253,7 +309,11 @@
interrupts = <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 7)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata7_port0: sata-port at 0 {
reg = <0>;
@@ -268,11 +328,19 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 7)
+ status = "okay";
+#else
status = "disabled";
+#endif
sata7_phy0: sata-phy at 0 {
reg = <0>;
#phy-cells = <0>;
};
};
+
+#if (NUM_SATA > 8)
+#error "NUM_SATA > 8"
+#endif
};
--
2.5.0
^ permalink raw reply related
* [PATCH] locking/atomics: Simplify the op definitions in atomic.h some more
From: Palmer Dabbelt @ 2018-05-18 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180506145726.y4jxhvfolzvbuft5@gmail.com>
On Sun, 06 May 2018 07:57:27 PDT (-0700), mingo at kernel.org wrote:
>
> * Andrea Parri <andrea.parri@amarulasolutions.com> wrote:
>
>> Hi Ingo,
>>
>> > From 5affbf7e91901143f84f1b2ca64f4afe70e210fd Mon Sep 17 00:00:00 2001
>> > From: Ingo Molnar <mingo@kernel.org>
>> > Date: Sat, 5 May 2018 10:23:23 +0200
>> > Subject: [PATCH] locking/atomics: Simplify the op definitions in atomic.h some more
>> >
>> > Before:
>> >
>> > #ifndef atomic_fetch_dec_relaxed
>> > # ifndef atomic_fetch_dec
>> > # define atomic_fetch_dec(v) atomic_fetch_sub(1, (v))
>> > # define atomic_fetch_dec_relaxed(v) atomic_fetch_sub_relaxed(1, (v))
>> > # define atomic_fetch_dec_acquire(v) atomic_fetch_sub_acquire(1, (v))
>> > # define atomic_fetch_dec_release(v) atomic_fetch_sub_release(1, (v))
>> > # else
>> > # define atomic_fetch_dec_relaxed atomic_fetch_dec
>> > # define atomic_fetch_dec_acquire atomic_fetch_dec
>> > # define atomic_fetch_dec_release atomic_fetch_dec
>> > # endif
>> > #else
>> > # ifndef atomic_fetch_dec_acquire
>> > # define atomic_fetch_dec_acquire(...) __atomic_op_acquire(atomic_fetch_dec, __VA_ARGS__)
>> > # endif
>> > # ifndef atomic_fetch_dec_release
>> > # define atomic_fetch_dec_release(...) __atomic_op_release(atomic_fetch_dec, __VA_ARGS__)
>> > # endif
>> > # ifndef atomic_fetch_dec
>> > # define atomic_fetch_dec(...) __atomic_op_fence(atomic_fetch_dec, __VA_ARGS__)
>> > # endif
>> > #endif
>> >
>> > After:
>> >
>> > #ifndef atomic_fetch_dec_relaxed
>> > # ifndef atomic_fetch_dec
>> > # define atomic_fetch_dec(v) atomic_fetch_sub(1, (v))
>> > # define atomic_fetch_dec_relaxed(v) atomic_fetch_sub_relaxed(1, (v))
>> > # define atomic_fetch_dec_acquire(v) atomic_fetch_sub_acquire(1, (v))
>> > # define atomic_fetch_dec_release(v) atomic_fetch_sub_release(1, (v))
>> > # else
>> > # define atomic_fetch_dec_relaxed atomic_fetch_dec
>> > # define atomic_fetch_dec_acquire atomic_fetch_dec
>> > # define atomic_fetch_dec_release atomic_fetch_dec
>> > # endif
>> > #else
>> > # ifndef atomic_fetch_dec
>> > # define atomic_fetch_dec(...) __atomic_op_fence(atomic_fetch_dec, __VA_ARGS__)
>> > # define atomic_fetch_dec_acquire(...) __atomic_op_acquire(atomic_fetch_dec, __VA_ARGS__)
>> > # define atomic_fetch_dec_release(...) __atomic_op_release(atomic_fetch_dec, __VA_ARGS__)
>> > # endif
>> > #endif
>> >
>> > The idea is that because we already group these APIs by certain defines
>> > such as atomic_fetch_dec_relaxed and atomic_fetch_dec in the primary
>> > branches - we can do the same in the secondary branch as well.
>> >
>> > ( Also remove some unnecessarily duplicate comments, as the API
>> > group defines are now pretty much self-documenting. )
>> >
>> > No change in functionality.
>> >
>> > Cc: Peter Zijlstra <peterz@infradead.org>
>> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
>> > Cc: Andrew Morton <akpm@linux-foundation.org>
>> > Cc: Thomas Gleixner <tglx@linutronix.de>
>> > Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>> > Cc: Will Deacon <will.deacon@arm.com>
>> > Cc: linux-kernel at vger.kernel.org
>> > Signed-off-by: Ingo Molnar <mingo@kernel.org>
>>
>> This breaks compilation on RISC-V. (For some of its atomics, the arch
>> currently defines the _relaxed and the full variants and it relies on
>> the generic definitions for the _acquire and the _release variants.)
>
> I don't have cross-compilation for RISC-V, which is a relatively new arch.
> (Is there any RISC-V set of cross-compilation tools on kernel.org somewhere?)
Arnd added RISC-V to the cross compiler list a month or two ago when he updated
them all. I use the "make.cross" script from the Intel test robot, which will
fetch the cross compilers for you. It looks like I made a Git Hub pull request
to update the script for RISC-V, it fetches from kernel.org
https://github.com/palmer-dabbelt/lkp-tests/blob/e14f4236ccd0572f4b87ffd480fecefee412dedc/sbin/make.cross
http://cdn.kernel.org/pub/tools/crosstool/files/bin/
http://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_riscv64-linux.tar.gz
> Could you please send a patch that defines those variants against Linus's tree,
> like the PowerPC patch that does something similar:
>
> 0476a632cb3a: locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs
>
> ?
>
> ... and I'll integrate it into the proper place to make it all bisectable, etc.
Sorry, I got buried in email again. Did this get merged, or is there a current
version of the patch set I should look at?
^ permalink raw reply
* AArch64 memory
From: Tim Harvey @ 2018-05-18 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bb3353c7-1ef1-403a-cbf0-7e311e55c276@arm.com>
On Fri, May 18, 2018 at 11:15 AM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 18/05/18 17:43, Tim Harvey wrote:
> [...]
>
>>>> My second question has to do with CMA and coherent_pool. I have
>>>> understood CMA as being a chunk of physical memory carved out by the
>>>> kernel for allocations from dma_alloc_coherent by drivers that need
>>>> chunks of contiguous memory for DMA buffers. I believe that before CMA
>>>> was introduced we had to do this by defining memory holes. I'm not
>>>> understanding the difference between CMA and the coherent pool. I've
>>>> noticed that if CONFIG_DMA_CMA=y then the coherent pool allocates from
>>>> CMA. Is there some disadvantage of CONFIG_DMA_CMA=y other than if
>>>> defined you need to make sure your CMA is larger than coherent_pool?
>>>> What drivers/calls use coherent_pool vs cma?
>>>
>>>
>>>
>>> coherent_pool is a special thing which exists for the sake of
>>> non-hardware-coherent devices - normally for those we satisfy
>>> DMA-coherent
>>> allocations by setting up a non-cacheable remap of the allocated buffer -
>>> see dma_common_contiguous_remap(). However, drivers may call
>>> dma_alloc_coherent(..., GFP_ATOMIC) from interrupt handlers, at which
>>> point
>>> we can't call get_vm_area() to remap on demand, since that might sleep,
>>> so
>>> we reserve a pool pre-mapped as non-cacheable to satisfy such atomic
>>> allocations from. I'm not sure why its user-visible name is "coherent
>>> pool"
>>> rather than the more descriptive "atomic pool" which it's named
>>> internally,
>>> but there's probably some history there. If you're lucky enough not to
>>> have
>>> any non-coherent DMA masters then you can safely ignore the whole thing;
>>> otherwise it's still generally rare that it should need adjusting.
>>
>>
>> is there an easy way to tell if I have non-coherent DMA masters? The
>> Cavium SDK uses a kernel cmdline param of coherent_pool=16M so I'm
>> guessing something in the CN80XX/CN81XX (BGX NIC's or CPT perhaps)
>> need atomic pool mem.
>
>
> AFAIK the big-boy CN88xx is fully coherent everywhere, but whether the
> peripherals and interconnect in the littler Octeon TX variants are different
> I have no idea. If the contents of your dts-newport repo on GitHub are the
> right thing to be looking at, then you do have the "dma-coherent" property
> on the PCI nodes, which should cover everything beneath (I'd expect that in
> reality the SMMU may actually be coherent as well, but fortunately that's
> irrelevant here). Thus everything which matters *should* be being picked up
> as coherent already, and if not it would be a Linux problem. I can't imagine
> what the SDK is up to there, but 16MB of coherent pool does sound like
> something being done wrong, like incorrectly compensating for bad firmware
> failing to describe the hardware properly in the first place.
Yes https://github.com/Gateworks/dts-newport/ is the board that I'm
working with :)
Ok, I think I understand now that the dma-coherent property on the PCI
host controller is saying that all allocations by PCI device drivers
will come from the atomic pool defined by coherent_pool=.
Why does coherent_pool=16M seem wrong to you?
>
>>> CMA is, as you surmise, a much more general thing for providing large
>>> physically-contiguous areas, which the arch code correspondingly uses to
>>> get
>>> DMA-contiguous buffers. Unless all your DMA masters are behind IOMMUs
>>> (such
>>> that we can make any motley collection of pages look DMA-contiguous), you
>>> probably don't want to turn it off. None of these details should be
>>> relevant
>>> as far as drivers are concerned, since from their viewpoint it's all
>>> abstracted behind dma_alloc_coherent().
>>>
>>
>> I don't want to turn off CONFIG_CMA but I'm still not clear if I
>> should turn off CONFIG_DMA_CMA. I noticed the Cavium SDK 4.9 kernel
>> has CONFIG_CMA=y but does not enable CONFIG_DMA_CMA which I believe
>> means that the atomic pool does not pull its chunks from the CMA pool.
>
>
> I wouldn't think there's much good reason to turn DMA_CMA off either, even
> if nothing actually needs huge DMA buffers. Where the atomic pool comes from
> shouldn't really matter, as it's a very early one-off allocation. To
> speculate wildly I suppose there *might* possibly be some performance
> difference between cma_alloc() and falling back to the regular page
> allocator - if that were the case it ought to be measurable by profiling
> something which calls dma_alloc_coherent() in process context a lot, under
> both configurations. Even then I'd imagine it's something that would matter
> most on the 2-socket 96-core systems, and not so much on the diddy ones.
>
If you enable DMA_CMA then you have to make sure to size CMA large
enough to handle coherent_pool (and any additional CMA you will need).
I made the mistake of setting CONFIG_CMA_SIZE_MBYTES=16 then passing
in a coherent_pool=64M which causes the coherent pool DMA allocation
to fail and I'm not clear if that even has an impact on the system. It
seems to me that the kernel should perhaps catch the case where CMA <
dma_coherent when CONFIG_CMA_DMA=y and either warn about that
condition or set cma to coherent_pool to resolve it.
Tim
^ permalink raw reply
* [PATCH 0/2] Add R8A77980/V3HSK GEther support
From: Sergei Shtylyov @ 2018-05-18 19:37 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180518-v4.17-rc5' tag plus the R8A77980 SMP support patch.
I'm adding the device tree support for mounting the NFS root on the R8A77980-
based V3H Starter Kit board. The 'sh_eth' driver patches adding R8A77980
GEther support patches needed for these 2 patches to work have been posted
and are close to be merged...
[1/2] arm64: dts: renesas: r8a77980: add GEther support
[2/2] arm64: dts: renesas: v3hsk: add GEther support
WBR, Sergei
^ permalink raw reply
* [PATCH 1/2] arm64: dts: renesas: r8a77980: add GEther support
From: Sergei Shtylyov @ 2018-05-18 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a4230699-e46f-0782-e3b1-22d58b9033c8@cogentembedded.com>
Define the generic R8A77980 part of the GEther device node.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -417,6 +417,17 @@
dma-channels = <16>;
};
+ gether: ethernet at e7400000 {
+ compatible = "renesas,gether-r8a77980";
+ reg = <0 0xe7400000 0 0x1000>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 813>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
mmc0: mmc at ee140000 {
compatible = "renesas,sdhi-r8a77980",
"renesas,rcar-gen3-sdhi";
^ 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