[PATCH v2 16/16] ASoC: fsl_ssi: Use ssi->streams instead of reading register

Since ssi->streams is being updated along with SCR register and its SSIEN bit, it's simpler to use it instead. Signed-off-by: Nicolin Chen Tested-by: Caleb Crome --- sound/soc/fsl/fsl_ssi.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-)

[PATCH v2 15/16] ASoC: fsl_ssi: Move DT related code to a separate probe()

This patch cleans up probe() function by moving all Device Tree related code into a separate function. It allows the probe() to be Device Tree independent. This will be very useful for future integration of imx-ssi driver which has similar functionalities while exists only because it supports

[PATCH v2 14/16] ASoC: fsl_ssi: Remove cpu_dai_drv from fsl_ssi structure

The cpu_dai_drv is only used for symmetric_rates. So this patch replaces it with a synchronous boolean flag. Signed-off-by: Nicolin Chen Tested-by: Caleb Crome --- sound/soc/fsl/fsl_ssi.c | 32 1 file changed, 16

[PATCH v2 13/16] ASoC: fsl_ssi: Clean up _fsl_ssi_set_dai_fmt()

The _fsl_ssi_set_dai_fmt() is a helper function being called from fsl_ssi_set_dai_fmt() as an ASoC operation and fsl_ssi_hw_init() mainly for AC97 format initialization. This patch cleans the _fsl_ssi_set_dai_fmt() in following ways: * Removing *dev pointer in the parameters as it's included in

[PATCH v2 12/16] ASoC: fsl_ssi: Setup AC97 in fsl_ssi_hw_init()

AC97 configures most of registers earlier to start a communication with CODECs in order to successfully initialize CODEC. Currently, _fsl_ssi_set_dai_fmt() and fsl_ssi_setup_ac97() are called to get all SSI registers properly set. Since now the driver has a fsl_ssi_hw_init() to handle all

[PATCH v2 11/16] ASoC: fsl_ssi: Move one-time configurations to probe()

The probe() could handle some one-time configurations since they will not be changed once being configured. Signed-off-by: Nicolin Chen Tested-by: Caleb Crome --- sound/soc/fsl/fsl_ssi.c | 39 ++- 1 file changed, 26

[PATCH v2 10/16] ASoC: fsl_ssi: Use snd_soc_init_dma_data instead

Since there is a helper function, use it to help readability. Signed-off-by: Nicolin Chen Tested-by: Caleb Crome --- sound/soc/fsl/fsl_ssi.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c

[PATCH v2 09/16] ASoC: fsl_ssi: Set xFEN0 and xFEN1 together

It'd be safer to enable both FIFOs for TX or RX at the same time. Signed-off-by: Nicolin Chen Tested-by: Caleb Crome --- sound/soc/fsl/fsl_ssi.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c

[PATCH v2 08/16] ASoC: fsl_ssi: Clean up fsl_ssi_setup_regvals()

This patch cleans fsl_ssi_setup_regvals() by following changes: 1) Moving DBG bits to the first lines. 2) Setting SSIE, RE/TE as default and cleaning it for AC97 Signed-off-by: Nicolin Chen Tested-by: Caleb Crome --- sound/soc/fsl/fsl_ssi.c | 17

[PATCH v2 06/16] ASoC: fsl_ssi: Clean up helper functions of trigger()

The trigger() calls fsl_ssi_tx_config() and fsl_ssi_rx_config(), and both of them jump to fsl_ssi_config(). And fsl_ssi_config() later calls another fsl_ssi_rxtx_config(). However, the whole routine, especially fsl_ssi_config() function, is too complicated because of the folowing reasons: 1) It

[PATCH v2 07/16] ASoC: fsl_ssi: Add DAIFMT define for AC97

The _fsl_ssi_set_dai_fmt() bypasses an undefined format for AC97 mode. However, it's not really necessary if AC97 has its complete format defined. So this patch adds a DAIFMT macro of complete format including a clock direction and polarity. Signed-off-by: Nicolin Chen

[PATCH v2 05/16] ASoC: fsl_ssi: Clear FIFO directly in fsl_ssi_config()

The FIFO clear helper function is just one line of code now. So it could be cleaned up by removing it and calling regmap directly. Meanwhile, FIFO clear could be applied to all use cases, not confined to AC97. So this patch also moves FIFO clear in the trigger() to fsl_ssi_config() and removes

[PATCH v2 04/16] ASoC: fsl_ssi: Rename fsl_ssi_disable_val macro

The define of fsl_ssi_disable_val is not so clear as it mixes two steps of calculations together. And those parameter names are also a bit long to read. Since it just tries to exclude the shared bits from the regvals of current stream while the opposite stream is active, it's better to use

[PATCH v2 03/16] ASoC: fsl_ssi: Maintain a mask of active streams

Checking TE and RE bits in SCR register doesn't work for AC97 mode which enables SSIEN, TE and RE in the fsl_ssi_setup_ac97() that's called during probe(). So when running into the trigger(), it will always get the result of both TE and RE being enabled already, even if actually there is no

[PATCH v2 02/16] ASoC: fsl_ssi: Clean up set_dai_tdm_slot()

This patch replaces the register read with ssi->i2s_net for simplification. It also removes masking SSIEN from scr value since it's handled later by regmap_update_bits() to set this scr value back. Signed-off-by: Nicolin Chen Tested-by: Caleb Crome ---

[PATCH v2 00/16] ASoC: fsl_ssi: Clean up - program flow level

==Change log== v2 * Reworked the series by taking suggestions from Maciej + Added PATCH-01 to keep all ssi->i2s_net updated + Replaced bool tx with bool dir in PATCH-03 and PATCH-06 + Moved all initial register configurations from dai probe() to platform probe() so as to let AC97 CODEC

[PATCH v2 01/16] ASoC: fsl_ssi: Keep ssi->i2s_net updated

The hw_params() overwrites i2s_net settings for special cases like mono-channel support, however, it doesn't update ssi->i2s_net as set_dai_fmt() does. This patch removes the local i2s_net variable and directly updates ssi->i2s_net in the hw_params() so that the driver can simply look up the

Re: powerpc/kernel: Print actual address of regs when oopsing

On Thu, 2018-01-11 at 02:21:35 UTC, Michael Ellerman wrote: > When we oops or otherwise call show_regs() we print the address of the > regs structure. Being able to see the address is fairly useful, > firstly to verify that the regs pointer is not completely bogus, and > secondly it allows you to

Re: [01/11] powerpc/pseries: Add H_GET_CPU_CHARACTERISTICS flags & wrapper

On Mon, 2018-01-08 at 16:54:43 UTC, Michael Ellerman wrote: > From: Michael Neuling > > A new hypervisor call has been defined to communicate various > characteristics of the CPU to guests. Add definitions for the hcall > number, flags and a wrapper function. > >

Re: [v3, 1/1] powerpc/pseries: Make RAS IRQ explicitly dependent on DLPAR WQ

On Wed, 2018-01-03 at 21:12:52 UTC, Jose Ricardo Ziviani wrote: > The hotplug engine uses its own workqueue to handle IRQ requests, the > problem is that such workqueue is initialized after init_ras_IRQ, which > will cause a kernel panic if any hotplug interruption is issued in that > period of

[PATCH] powerpc/kernel: Print actual address of regs when oopsing

When we oops or otherwise call show_regs() we print the address of the regs structure. Being able to see the address is fairly useful, firstly to verify that the regs pointer is not completely bogus, and secondly it allows you to dump the regs and surrounding memory with a debugger if you have

Re: Spectre+Meltdown

On Mon, Jan 8, 2018 at 2:17 AM, Christian Zigotzky wrote: > Hi All, > > Thanks a lot for your replies. > > @NXP developers: Could you please tell us some information? We have done some investigation but it is not ready to be published yet. You can get more information

Re: [PATCH RESEND 1/1] KVM: PPC: Book3S: Add MMIO emulation for VMX instructions

On Thu, Jan 11, 2018 at 09:36:58AM +1100, Paul Mackerras wrote: > On Mon, Jan 08, 2018 at 04:29:31PM -0200, Jose Ricardo Ziviani wrote: > > This patch provides the MMIO load/store vector indexed > > X-Form emulation. > > > > Instructions implemented: lvx, stvx > > > > Signed-off-by: Jose Ricardo

Re: [PATCH] soc/fsl/guts: Add a NULL check for devm_kasprintf()

On Sun, Jan 7, 2018 at 9:06 PM, Y.b. Lu wrote: >> -Original Message- >> From: Fabio Estevam [mailto:feste...@gmail.com] >> Sent: 2018年1月6日 21:23 >> To: Leo Li >> Cc: linuxppc-dev@lists.ozlabs.org; Y.b. Lu ; Fabio >> Estevam

Re: [PATCH RESEND 1/1] KVM: PPC: Book3S: Add MMIO emulation for VMX instructions

On Mon, Jan 08, 2018 at 04:29:31PM -0200, Jose Ricardo Ziviani wrote: > This patch provides the MMIO load/store vector indexed > X-Form emulation. > > Instructions implemented: lvx, stvx > > Signed-off-by: Jose Ricardo Ziviani What testing has been done of this

Re: [PATCH] PCI: Add #defines for Completion Timeout Disable feature

On Fri, Dec 15, 2017 at 04:57:11PM -0600, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > Add #defines for the Completion Timeout Disable feature and use them. No > functional change intended. > > Signed-off-by: Bjorn Helgaas Applied with Michael's

DPAA Ethernet traffice troubles with Linux kernel

Hi linux devs, Like mentioned in this thread https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-January/167630.html i also experience the exact same issues. I am also trying to find out why the network traffic is not flowing the way it should (out for example ). My linux knowledge is very

Re: [PATCH 10/13] ocxl: Add Makefile and Kconfig

Le 10/01/2018 à 00:21, Michael Ellerman a écrit : Would also be great to add something describing the relationship to CAPI and cxl. Otherwise people will be confused about whether they need this one or the other one or both. OK, I'll add something. Fred

Re: [PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops

On 10/01/18 15:35, Christoph Hellwig wrote: On Wed, Jan 10, 2018 at 12:16:15PM +, Robin Murphy wrote: On 10/01/18 08:09, Christoph Hellwig wrote: To properly reject too small DMA masks based on the addressability of the bounce buffer. I reckon this is self-evident enough that it should

Re: [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32

On 10/01/18 15:55, Christoph Hellwig wrote: On Wed, Jan 10, 2018 at 04:55:17PM +0100, Christoph Hellwig wrote: On Wed, Jan 10, 2018 at 12:58:14PM +, Robin Murphy wrote: On 10/01/18 08:09, Christoph Hellwig wrote: arm64 uses ZONE_DMA for allocations below 32-bits. These days we name the

Re: [PATCH 10/22] swiotlb: refactor coherent buffer allocation

On 10/01/18 15:46, Christoph Hellwig wrote: On Wed, Jan 10, 2018 at 12:22:18PM +, Robin Murphy wrote: + if (phys_addr == SWIOTLB_MAP_ERROR) + goto out_warn; -/* Confirm address can be DMA'd by device */ - if (dev_addr + size - 1 > dma_mask) {

Re: [PATCH 31/33] dma-direct: reject too small dma masks

On 10/01/18 15:32, Christoph Hellwig wrote: On Wed, Jan 10, 2018 at 11:49:34AM +, Robin Murphy wrote: +#ifdef CONFIG_ZONE_DMA + if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS)) + return 0; +#else + /* +* Because 32-bit DMA masks are so common we expect every

Re: [PATCH 27/33] dma-direct: use node local allocations for coherent memory

On 10/01/18 15:30, Christoph Hellwig wrote: On Wed, Jan 10, 2018 at 12:06:22PM +, Robin Murphy wrote: On 10/01/18 08:00, Christoph Hellwig wrote: To preserve the x86 behavior. And combined with patch 10/22 of the SWIOTLB refactoring, this means SWIOTLB allocations will also end up

DPAA Ethernet problems with mainstream Linux kernels

Hello all @ linuxppc-dev, I have been working with a team of people maintaining PowerPC Linux for the new AmigaONE X5000/20 (a Freescale p5020 SoC based machine). We are trying to determine why the submitted Data Path Acceleration Architecture (DPAA) Ethernet Driver is not fully functional with

Re: [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32

On Wed, Jan 10, 2018 at 04:55:17PM +0100, Christoph Hellwig wrote: > On Wed, Jan 10, 2018 at 12:58:14PM +, Robin Murphy wrote: > > On 10/01/18 08:09, Christoph Hellwig wrote: > >> arm64 uses ZONE_DMA for allocations below 32-bits. These days we > >> name the zone for that ZONE_DMA32, which

Re: [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32

On Wed, Jan 10, 2018 at 12:58:14PM +, Robin Murphy wrote: > On 10/01/18 08:09, Christoph Hellwig wrote: >> arm64 uses ZONE_DMA for allocations below 32-bits. These days we >> name the zone for that ZONE_DMA32, which will allow to use the >> dma-direct and generic swiotlb code as-is, so rename

[PATCH v7 for 4.16 03/11] powerpc: membarrier: Skip memory barrier in switch_mm()

Allow PowerPC to skip the full memory barrier in switch_mm(), and only issue the barrier when scheduling into a task belonging to a process that has registered to use expedited private. Threads targeting the same VM but which belong to different thread groups is a tricky case. It has a few

Re: [PATCH 10/22] swiotlb: refactor coherent buffer allocation

On Wed, Jan 10, 2018 at 12:22:18PM +, Robin Murphy wrote: >> +if (phys_addr == SWIOTLB_MAP_ERROR) >> +goto out_warn; >> - /* Confirm address can be DMA'd by device */ >> -if (dev_addr + size - 1 > dma_mask) { >> -printk("hwdev DMA mask

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

On Wed, Jan 10, 2018 at 03:31:08PM +, Robin Murphy wrote: > Yes indeed, modulo Vladimir's comments - it does seem prudent to fix the > obvious off-by-ones as we touch them. I've wanted to do something like this > for ages, but never got around to it myself. I've fixed these now in a

Re: [PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops

On Wed, Jan 10, 2018 at 12:16:15PM +, Robin Murphy wrote: > On 10/01/18 08:09, Christoph Hellwig wrote: >> To properly reject too small DMA masks based on the addressability of the >> bounce buffer. > > I reckon this is self-evident enough that it should simply be squashed into > the previous

Re: [PATCH 31/33] dma-direct: reject too small dma masks

On Wed, Jan 10, 2018 at 11:49:34AM +, Robin Murphy wrote: >> +#ifdef CONFIG_ZONE_DMA >> +if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS)) >> +return 0; >> +#else >> +/* >> + * Because 32-bit DMA masks are so common we expect every architecture >> + * to be able to

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

On 10/01/18 15:26, Christoph Hellwig wrote: On Wed, Jan 10, 2018 at 02:56:01PM +, Robin Murphy wrote: I took a look at these, and it seems their phys_to_dma() usage is doing the thing which we subsequently formalised as dma_map_resource(). I've had a crack at a quick patch to update the

Re: [PATCH 27/33] dma-direct: use node local allocations for coherent memory

On Wed, Jan 10, 2018 at 12:06:22PM +, Robin Murphy wrote: > On 10/01/18 08:00, Christoph Hellwig wrote: >> To preserve the x86 behavior. > > And combined with patch 10/22 of the SWIOTLB refactoring, this means > SWIOTLB allocations will also end up NUMA-aware, right? Great, that's what > we

Re: [PATCH 20/33] dma-mapping: clear harmful GFP_* flags in common code

On Wed, Jan 10, 2018 at 11:59:30AM +, Robin Murphy wrote: > Just a note that if we're all happy to enshrine the "allocations are always > zeroed" behaviour in the API (I am too, for the record), we should remember > to follow up once the dust settles to update the docs and I guess just >

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

On Wed, Jan 10, 2018 at 02:56:01PM +, Robin Murphy wrote: > I took a look at these, and it seems their phys_to_dma() usage is doing the > thing which we subsequently formalised as dma_map_resource(). I've had a > crack at a quick patch to update the CESA driver; qcom_nandc looks slightly >

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

On Wed, Jan 10, 2018 at 09:31:45AM +, Vladimir Murzin wrote: > I know it is copy, but it seems it has off by one error and it should be > > return addr + size - 1 <= *dev->dma_mask; I've added a new patch to fix the mips dma_capable() definition, thanks.

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

On 10/01/18 08:00, Christoph Hellwig wrote: phys_to_dma, dma_to_phys and dma_capable are helpers published by architecture code for use of swiotlb and xen-swiotlb only. Drivers are not supposed to use these directly, but use the DMA API instead. Move these to a new asm/dma-direct.h helper,

[PATCH] powerpc/xmon: Don't print hashed pointers in paca dump

Remember when the biggest problem we had to worry about was hashed pointers, those were the days. These were missed in my earlier patch because they don't match "%p", but the macro is hiding a "%p", so these all end up being hashed, which is not what we want in xmon. Convert them to "%px".

Re: [PATCH V6] cxl: Add support for ASB_Notify on POWER9

Hi Christophe, Couple of comments about file.c, the rest of the patch looks ok to me. @@ -193,6 +194,7 @@ static long afu_ioctl_start_work(struct cxl_context *ctx, amr = work.amr & mfspr(SPRN_UAMOR); ctx->mmio_err_ff = !!(work.flags & CXL_START_WORK_ERR_FF); +

[PATCH] powerpc/xmon: Add RFI flush related fields to paca dump

Signed-off-by: Michael Ellerman --- arch/powerpc/xmon/xmon.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c index cab24f549e7c..b3bb5beec54a 100644 --- a/arch/powerpc/xmon/xmon.c +++ b/arch/powerpc/xmon/xmon.c @@

Re: [PATCH 22/22] arm64: use swiotlb_alloc and swiotlb_free

On 10/01/18 08:09, Christoph Hellwig wrote: The generic swiotlb_alloc and swiotlb_free routines already take care of CMA allocations and adding GFP_DMA32 where needed, so use them instead of the arm specific helpers. It took a while to satisfy myself that the GFP_DMA(32) handling ends up

Re: [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32

On 10/01/18 08:09, Christoph Hellwig wrote: arm64 uses ZONE_DMA for allocations below 32-bits. These days we name the zone for that ZONE_DMA32, which will allow to use the dma-direct and generic swiotlb code as-is, so rename it. I do wonder if we could also "upgrade" GFP_DMA to GFP_DMA32

Re: consolidate swiotlb dma_map implementations

Acked-by: Christian König for the whole series. Regards, Christian. Am 10.01.2018 um 09:09 schrieb Christoph Hellwig: A lot of architectures have essentially identical dma_map_ops implementations to use swiotlb. This series adds new generic swiotlb_alloc/free

Re: [PATCH 10/22] swiotlb: refactor coherent buffer allocation

On 10/01/18 08:09, Christoph Hellwig wrote: Factor out a new swiotlb_alloc_buffer helper that allocates DMA coherent memory from the swiotlb bounce buffer. This allows to simplify the swiotlb_alloc implemenation that uses dma_direct_alloc to try to allocate a reachable buffer first.

Re: [PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops

On 10/01/18 08:09, Christoph Hellwig wrote: To properly reject too small DMA masks based on the addressability of the bounce buffer. I reckon this is self-evident enough that it should simply be squashed into the previous patch. Robin. Signed-off-by: Christoph Hellwig ---

Re: [PATCH 02/22] arm64: rename swiotlb_dma_ops

On 10/01/18 08:09, Christoph Hellwig wrote: We'll need that name for a generic implementation soon. Reviewed-by: Robin Murphy Signed-off-by: Christoph Hellwig --- arch/arm64/mm/dma-mapping.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH 27/33] dma-direct: use node local allocations for coherent memory

On 10/01/18 08:00, Christoph Hellwig wrote: To preserve the x86 behavior. And combined with patch 10/22 of the SWIOTLB refactoring, this means SWIOTLB allocations will also end up NUMA-aware, right? Great, that's what we want on arm64 too :) Reviewed-by: Robin Murphy

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

On Wednesday, January 10, 2018 9:55:45 AM CET Gautham R Shenoy wrote: > Hi Rafael, > > On Wed, Jan 03, 2018 at 11:47:58PM +1100, Balbir Singh wrote: > > On Wed, Jan 3, 2018 at 11:07 PM, Rafael J. Wysocki > > wrote: > > > On Monday, December 18, 2017 9:38:20 AM CET Gautham R

Re: [PATCH 20/33] dma-mapping: clear harmful GFP_* flags in common code

On 10/01/18 08:00, Christoph Hellwig wrote: [...] diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 9f28b2fa329e..88bcb1a8211d 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -518,6 +518,13 @@ static inline void *dma_alloc_attrs(struct

Re: [PATCH 31/33] dma-direct: reject too small dma masks

On 10/01/18 08:00, Christoph Hellwig wrote: Signed-off-by: Christoph Hellwig --- include/linux/dma-direct.h | 1 + lib/dma-direct.c | 19 +++ 2 files changed, 20 insertions(+) diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h index

Re: [PATCH 10/33] arm64: don't override dma_max_pfn

On 10/01/18 08:00, Christoph Hellwig wrote: The generic version now takes dma_pfn_offset into account, so there is no more need for an architecture override. Reviewed-by: Robin Murphy Signed-off-by: Christoph Hellwig ---

Re: [PATCH 09/33] dma-mapping: take dma_pfn_offset into account in dma_max_pfn

On 10/01/18 08:00, Christoph Hellwig wrote: This makes sure the generic version can be used with architectures / devices that have a DMA offset in the direct mapping. Reviewed-by: Robin Murphy Signed-off-by: Christoph Hellwig ---

[PATCH] powerpc : Fix sleeping-in-atomic section warning triggered by /proc/cpuinfo

Commit cd77b5ce208c ("Fix the frequency read by /proc/cpuinfo") to fix /proc/cpuinfo on POWERNV triggered a sleeping-in-atomic section warning. This was because the place where we cpufreq_get (which takes an rwsem) from show_cpuinfo is in a preempt_disabled. However, the preempt_disable() in

Re: [v3 PATCH 0/3] powernv-cpufreq: Multiple pstate related fixes.

On 13-12-17, 12:27, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > This is a third version of the patch to fix pstate related issues in > the powernv-cpufreq driver. Acked-by: Viresh Kumar -- viresh

Re: [PATCH 29/33] dma-direct: retry allocations using GFP_DMA for small masks

On 10/01/18 08:00, Christoph Hellwig wrote: > If an attempt to allocate memory succeeded, but isn't inside the > supported DMA mask, retry the allocation with GFP_DMA set as a > last resort. > > Based on the x86 code, but an off by one error in what is now > dma_coherent_ok has been fixed vs the

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

On 10/01/18 08:00, Christoph Hellwig wrote: > index 9110988b92a1..f00833acb626 100644 > --- a/arch/mips/include/asm/mach-cavium-octeon/dma-coherence.h > +++ b/arch/mips/include/asm/mach-cavium-octeon/dma-coherence.h > @@ -61,6 +61,14 @@ static inline void plat_post_dma_flush(struct device *dev) >

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

Hi Rafael, On Wed, Jan 03, 2018 at 11:47:58PM +1100, Balbir Singh wrote: > On Wed, Jan 3, 2018 at 11:07 PM, Rafael J. Wysocki wrote: > > On Monday, December 18, 2017 9:38:20 AM CET Gautham R Shenoy wrote: > >> Hi Balbir, > >> > >> On Sun, Dec 17, 2017 at 02:15:25PM +1100,

[PATCH 22/22] arm64: use swiotlb_alloc and swiotlb_free

The generic swiotlb_alloc and swiotlb_free routines already take care of CMA allocations and adding GFP_DMA32 where needed, so use them instead of the arm specific helpers. Signed-off-by: Christoph Hellwig --- arch/arm64/Kconfig | 1 + arch/arm64/mm/dma-mapping.c | 46

[PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32

arm64 uses ZONE_DMA for allocations below 32-bits. These days we name the zone for that ZONE_DMA32, which will allow to use the dma-direct and generic swiotlb code as-is, so rename it. Signed-off-by: Christoph Hellwig --- arch/arm64/Kconfig | 2 +-

[PATCH 20/22] mips: use swiotlb_{alloc,free}

These already include the GFP_DMA/GFP_DMA32 usage, and will use CMA memory if enabled, thus avoiding the GFP_NORETRY hack. Signed-off-by: Christoph Hellwig --- arch/mips/cavium-octeon/Kconfig | 1 + arch/mips/cavium-octeon/dma-octeon.c | 26

[PATCH 19/22] mips/netlogic: remove swiotlb support

nlm_swiotlb_dma_ops is unused code, so the whole swiotlb support is dead. If it gets resurrected at some point it should use the generic swiotlb_dma_ops instead. Signed-off-by: Christoph Hellwig --- arch/mips/include/asm/netlogic/common.h | 3 -- arch/mips/netlogic/Kconfig

[PATCH 18/22] tile: use generic swiotlb_ops

These are identical to the tile ops, and would also support CMA if enabled on tile. Signed-off-by: Christoph Hellwig --- arch/tile/Kconfig | 1 + arch/tile/kernel/pci-dma.c | 36 +++- 2 files changed, 4 insertions(+), 33 deletions(-) diff

[PATCH 17/22] tile: replace ZONE_DMA with ZONE_DMA32

tile uses ZONE_DMA for allocations below 32-bits. These days we name the zone for that ZONE_DMA32, which will allow to use the dma-direct and generic swiotlb code as-is, so rename it. Signed-off-by: Christoph Hellwig --- arch/tile/Kconfig | 2 +-

[PATCH 16/22] unicore32: use generic swiotlb_ops

These are identical to the unicore32 ops, and would also support CMA if enabled on unicore32. Signed-off-by: Christoph Hellwig --- arch/unicore32/include/asm/dma-mapping.h | 9 +- arch/unicore32/mm/Kconfig| 1 + arch/unicore32/mm/Makefile | 2 --

[PATCH 15/22] ia64: remove an ifdef around the content of pci-dma.c

The file is only compiled if CONFIG_INTEL_IOMMU is set to start with. Signed-off-by: Christoph Hellwig --- arch/ia64/kernel/pci-dma.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c index 35e0cad33b7d..b5df084c0af4

[PATCH 14/22] ia64: clean up swiotlb support

Move the few remaining bits of swiotlb glue towards their callers, and remove the pointless on ia64 swiotlb variable. Signed-off-by: Christoph Hellwig --- arch/ia64/include/asm/dma-mapping.h | 1 - arch/ia64/include/asm/swiotlb.h | 18 --

[PATCH 13/22] ia64: use generic swiotlb_ops

These are identical to the ia64 ops, and would also support CMA if enabled on ia64. Signed-off-by: Christoph Hellwig --- arch/ia64/Kconfig| 5 + arch/ia64/hp/common/hwsw_iommu.c | 4 ++-- arch/ia64/hp/common/sba_iommu.c | 6 +++---

[PATCH 12/22] ia64: replace ZONE_DMA with ZONE_DMA32

ia64 uses ZONE_DMA for allocations below 32-bits. These days we name the zone for that ZONE_DMA32, which will allow to use the dma-direct and generic swiotlb code as-is, so rename it. Signed-off-by: Christoph Hellwig --- arch/ia64/Kconfig | 2 +-

[PATCH 11/22] swiotlb: remove various exports

All these symbols are only used by arch dma_ops implementations or xen-swiotlb. None of which can be modular. Signed-off-by: Christoph Hellwig --- lib/swiotlb.c | 13 - 1 file changed, 13 deletions(-) diff --git a/lib/swiotlb.c b/lib/swiotlb.c index

[PATCH 10/22] swiotlb: refactor coherent buffer allocation

Factor out a new swiotlb_alloc_buffer helper that allocates DMA coherent memory from the swiotlb bounce buffer. This allows to simplify the swiotlb_alloc implemenation that uses dma_direct_alloc to try to allocate a reachable buffer first. Signed-off-by: Christoph Hellwig ---

[PATCH 09/22] swiotlb: refactor coherent buffer freeing

Factor out a new swiotlb_free_buffer helper that checks if an address is allocated from the swiotlb bounce buffer, and if yes frees it. This allows to simplify the swiotlb_free implemenation that uses dma_direct_free to free the non-bounce buffer allocations. Signed-off-by: Christoph Hellwig

[PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops

To properly reject too small DMA masks based on the addressability of the bounce buffer. Signed-off-by: Christoph Hellwig --- lib/swiotlb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/swiotlb.c b/lib/swiotlb.c index 0fae2f45c3c0..539fd1099ba9 100644 --- a/lib/swiotlb.c

[PATCH 07/22] swiotlb: add common swiotlb_map_ops

Currently all architectures that want to use swiotlb have to implement their own dma_map_ops instances. Provide a generic one based on the x86 implementation which first calls into dma_direct to try a full blown direct mapping implementation (including e.g. CMA) before falling back allocating

[PATCH 06/22] swiotlb: rename swiotlb_free to swiotlb_exit

Signed-off-by: Christoph Hellwig --- arch/powerpc/kernel/dma-swiotlb.c | 2 +- arch/x86/kernel/pci-swiotlb.c | 2 +- include/linux/swiotlb.h | 4 ++-- lib/swiotlb.c | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH 05/22] x86: rename swiotlb_dma_ops

We'll need that name for a generic implementation soon. Signed-off-by: Christoph Hellwig --- arch/x86/kernel/pci-swiotlb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c index

[PATCH 04/22] powerpc: rename swiotlb_dma_ops

We'll need that name for a generic implementation soon. Signed-off-by: Christoph Hellwig --- arch/powerpc/include/asm/swiotlb.h | 2 +- arch/powerpc/kernel/dma-swiotlb.c | 4 ++-- arch/powerpc/kernel/dma.c | 2 +- arch/powerpc/sysdev/fsl_pci.c | 2 +- 4 files

[PATCH 03/22] ia64: rename swiotlb_dma_ops

We'll need that name for a generic implementation soon. Signed-off-by: Christoph Hellwig --- arch/ia64/hp/common/hwsw_iommu.c | 4 ++-- arch/ia64/hp/common/sba_iommu.c | 6 +++--- arch/ia64/kernel/pci-swiotlb.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff

[PATCH 02/22] arm64: rename swiotlb_dma_ops

We'll need that name for a generic implementation soon. Signed-off-by: Christoph Hellwig --- arch/arm64/mm/dma-mapping.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c index

[PATCH 01/22] swiotlb: suppress warning when __GFP_NOWARN is set

From: Christian König TTM tries to allocate coherent memory in chunks of 2MB first to improve TLB efficiency and falls back to allocating 4K pages if that fails. Suppress the warning when the 2MB allocations fails since there is a valid fall back path.

consolidate swiotlb dma_map implementations

A lot of architectures have essentially identical dma_map_ops implementations to use swiotlb. This series adds new generic swiotlb_alloc/free helpers that take the attrs argument exposed in dma_map_ops, and which do an enhanced direct allocation modelled after x86 and reused from the dma-direct

[PATCH 33/33] h8300: use dma-direct

Replace the bare-bones h8300 direct dma mapping implementation with the fully featured generic dma-direct one. Signed-off-by: Christoph Hellwig --- arch/h8300/Kconfig | 1 + arch/h8300/include/asm/Kbuild| 1 + arch/h8300/include/asm/dma-mapping.h | 12

[PATCH 32/33] cris: use dma-direct

cris currently has an incomplete direct mapping dma_map_ops implementation is PCI support is enabled. Replace it with the fully feature generic dma-direct implementation. Signed-off-by: Christoph Hellwig Acked-by: Jesper Nilsson --- arch/cris/Kconfig

[PATCH 31/33] dma-direct: reject too small dma masks

Signed-off-by: Christoph Hellwig --- include/linux/dma-direct.h | 1 + lib/dma-direct.c | 19 +++ 2 files changed, 20 insertions(+) diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h index 4788bf0bf683..bcdb1a3e4b1f 100644 ---

[PATCH 30/33] dma-direct: make dma_direct_{alloc, free} available to other implementations

So that they don't need to indirect through the operation vector. Signed-off-by: Christoph Hellwig Reviewed-by: Vladimir Murzin --- arch/arm/mm/dma-mapping-nommu.c | 9 +++-- include/linux/dma-direct.h | 5 + lib/dma-direct.c|

[PATCH 29/33] dma-direct: retry allocations using GFP_DMA for small masks

If an attempt to allocate memory succeeded, but isn't inside the supported DMA mask, retry the allocation with GFP_DMA set as a last resort. Based on the x86 code, but an off by one error in what is now dma_coherent_ok has been fixed vs the x86 code. Signed-off-by: Christoph Hellwig

[PATCH 28/33] dma-direct: add support for allocation from ZONE_DMA and ZONE_DMA32

This allows to dip into zones for lower memory if they are available. If one of the zones is not available the corresponding GFP_* flag will evaluate to 0 so they won't change anything. We provide an arch tunable for those architectures that do not use GFP_DMA for the lowest 24-bits, given that

[PATCH 27/33] dma-direct: use node local allocations for coherent memory

To preserve the x86 behavior. Signed-off-by: Christoph Hellwig --- lib/dma-direct.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/dma-direct.c b/lib/dma-direct.c index a9ae98be7af3..f04a424f91fa 100644 --- a/lib/dma-direct.c +++ b/lib/dma-direct.c @@ -38,7

[PATCH 25/33] dma-direct: add dma address sanity checks

Roughly based on the x86 pci-nommu implementation. Signed-off-by: Christoph Hellwig --- lib/dma-direct.c | 31 ++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/lib/dma-direct.c b/lib/dma-direct.c index 12ea9653781b..32fd4d9e4c47 100644

[PATCH 26/33] dma-direct: add support for CMA allocation

Try the CMA allocator for coherent allocations if supported. Roughly modelled after the x86 code. Signed-off-by: Christoph Hellwig --- lib/dma-direct.c | 24 ++-- 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/lib/dma-direct.c b/lib/dma-direct.c

[PATCH 24/33] dma-direct: use phys_to_dma

This means it uses whatever linear remapping scheme that the architecture provides is used in the generic dma_direct ops. Signed-off-by: Christoph Hellwig Reviewed-by: Vladimir Murzin --- lib/dma-direct.c | 18 +++--- 1 file changed, 7

  1   2   >