* [PATCH v3] spi: atmel: Implements transfers with bounce buffer
From: Radu Pirea @ 2017-12-19 15:17 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables SPI DMA transfers for Atmel SAM9 SoCs and implements a
bounce buffer for transfers which have vmalloc allocated buffers. Those
buffers are not cache coherent even if they have been transformed into sg
lists. UBIFS is affected by this cache coherency issue.
In this patch I also reverted "spi: atmel: fix corrupted data issue on SAM9
family SoCs"(7094576ccdc3acfe1e06a1e2ab547add375baf7f).
Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
Changes v3:
-rebased on top of spi: atmel: fixed spin_lock usage inside atmel_spi_remove
-rerun checkpatch.pl and fix errors
Changes v2:
Please ignore the previous version. I messed up with file names.
drivers/spi/spi-atmel.c | 113 +++++++++++++++++++++++++++++++++++-------------
1 file changed, 84 insertions(+), 29 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 6694709..4a11fc0 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -291,6 +291,10 @@ struct atmel_spi {
struct spi_transfer *current_transfer;
int current_remaining_bytes;
int done_status;
+ dma_addr_t dma_addr_rx_bbuf;
+ dma_addr_t dma_addr_tx_bbuf;
+ void *addr_rx_bbuf;
+ void *addr_tx_bbuf;
struct completion xfer_completion;
@@ -436,6 +440,11 @@ static void atmel_spi_unlock(struct atmel_spi *as) __releases(&as->lock)
spin_unlock_irqrestore(&as->lock, as->flags);
}
+static inline bool atmel_spi_is_vmalloc_xfer(struct spi_transfer *xfer)
+{
+ return is_vmalloc_addr(xfer->tx_buf) || is_vmalloc_addr(xfer->rx_buf);
+}
+
static inline bool atmel_spi_use_dma(struct atmel_spi *as,
struct spi_transfer *xfer)
{
@@ -448,7 +457,12 @@ static bool atmel_spi_can_dma(struct spi_master *master,
{
struct atmel_spi *as = spi_master_get_devdata(master);
- return atmel_spi_use_dma(as, xfer);
+ if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5))
+ return atmel_spi_use_dma(as, xfer) &&
+ !atmel_spi_is_vmalloc_xfer(xfer);
+ else
+ return atmel_spi_use_dma(as, xfer);
+
}
static int atmel_spi_dma_slave_config(struct atmel_spi *as,
@@ -594,6 +608,11 @@ static void dma_callback(void *data)
struct spi_master *master = data;
struct atmel_spi *as = spi_master_get_devdata(master);
+ if (is_vmalloc_addr(as->current_transfer->rx_buf) &&
+ IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ memcpy(as->current_transfer->rx_buf, as->addr_rx_bbuf,
+ as->current_transfer->len);
+ }
complete(&as->xfer_completion);
}
@@ -744,17 +763,41 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
goto err_exit;
/* Send both scatterlists */
- rxdesc = dmaengine_prep_slave_sg(rxchan,
- xfer->rx_sg.sgl, xfer->rx_sg.nents,
- DMA_FROM_DEVICE,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (atmel_spi_is_vmalloc_xfer(xfer) &&
+ IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ rxdesc = dmaengine_prep_slave_single(rxchan,
+ as->dma_addr_rx_bbuf,
+ xfer->len,
+ DMA_FROM_DEVICE,
+ DMA_PREP_INTERRUPT |
+ DMA_CTRL_ACK);
+ } else {
+ rxdesc = dmaengine_prep_slave_sg(rxchan,
+ xfer->rx_sg.sgl,
+ xfer->rx_sg.nents,
+ DMA_FROM_DEVICE,
+ DMA_PREP_INTERRUPT |
+ DMA_CTRL_ACK);
+ }
if (!rxdesc)
goto err_dma;
- txdesc = dmaengine_prep_slave_sg(txchan,
- xfer->tx_sg.sgl, xfer->tx_sg.nents,
- DMA_TO_DEVICE,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (atmel_spi_is_vmalloc_xfer(xfer) &&
+ IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ memcpy(as->addr_tx_bbuf, xfer->tx_buf, xfer->len);
+ txdesc = dmaengine_prep_slave_single(txchan,
+ as->dma_addr_tx_bbuf,
+ xfer->len, DMA_TO_DEVICE,
+ DMA_PREP_INTERRUPT |
+ DMA_CTRL_ACK);
+ } else {
+ txdesc = dmaengine_prep_slave_sg(txchan,
+ xfer->tx_sg.sgl,
+ xfer->tx_sg.nents,
+ DMA_TO_DEVICE,
+ DMA_PREP_INTERRUPT |
+ DMA_CTRL_ACK);
+ }
if (!txdesc)
goto err_dma;
@@ -1426,27 +1469,7 @@ static void atmel_get_caps(struct atmel_spi *as)
as->caps.is_spi2 = version > 0x121;
as->caps.has_wdrbt = version >= 0x210;
-#ifdef CONFIG_SOC_SAM_V4_V5
- /*
- * Atmel SoCs based on ARM9 (SAM9x) cores should not use spi_map_buf()
- * since this later function tries to map buffers with dma_map_sg()
- * even if they have not been allocated inside DMA-safe areas.
- * On SoCs based on Cortex A5 (SAMA5Dx), it works anyway because for
- * those ARM cores, the data cache follows the PIPT model.
- * Also the L2 cache controller of SAMA5D2 uses the PIPT model too.
- * In case of PIPT caches, there cannot be cache aliases.
- * However on ARM9 cores, the data cache follows the VIVT model, hence
- * the cache aliases issue can occur when buffers are allocated from
- * DMA-unsafe areas, by vmalloc() for instance, where cache coherency is
- * not taken into account or at least not handled completely (cache
- * lines of aliases are not invalidated).
- * This is not a theorical issue: it was reproduced when trying to mount
- * a UBI file-system on a at91sam9g35ek board.
- */
- as->caps.has_dma_support = false;
-#else
as->caps.has_dma_support = version >= 0x212;
-#endif
as->caps.has_pdc_support = version < 0x212;
}
@@ -1592,6 +1615,30 @@ static int atmel_spi_probe(struct platform_device *pdev)
as->use_pdc = true;
}
+ if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ as->addr_rx_bbuf = dma_alloc_coherent(&pdev->dev,
+ SPI_MAX_DMA_XFER,
+ &as->dma_addr_rx_bbuf,
+ GFP_KERNEL | GFP_DMA);
+ if (!as->addr_rx_bbuf) {
+ as->use_dma = false;
+ } else {
+ as->addr_tx_bbuf = dma_alloc_coherent(&pdev->dev,
+ SPI_MAX_DMA_XFER,
+ &as->dma_addr_tx_bbuf,
+ GFP_KERNEL | GFP_DMA);
+ if (!as->addr_tx_bbuf) {
+ as->use_dma = false;
+ dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
+ as->addr_rx_bbuf,
+ as->dma_addr_rx_bbuf);
+ }
+ }
+ if (!as->use_dma)
+ dev_info(master->dev.parent,
+ " can not allocate dma coherent memory\n");
+ }
+
if (as->caps.has_dma_support && !as->use_dma)
dev_info(&pdev->dev, "Atmel SPI Controller using PIO only\n");
@@ -1664,6 +1711,14 @@ static int atmel_spi_remove(struct platform_device *pdev)
if (as->use_dma) {
atmel_spi_stop_dma(master);
atmel_spi_release_dma(master);
+ if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
+ as->addr_tx_bbuf,
+ as->dma_addr_tx_bbuf);
+ dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
+ as->addr_rx_bbuf,
+ as->dma_addr_rx_bbuf);
+ }
}
spin_lock_irq(&as->lock);
--
2.7.4
^ permalink raw reply related
* [PATCH V1 0/1] Fix kernel panic caused by device ID duplication presented to the IOMMU
From: Tomasz Nowicki @ 2017-12-19 15:13 UTC (permalink / raw)
To: linux-arm-kernel
Here is my lspci output of ThunderX2 for which I am observing kernel panic coming from
SMMUv3 driver -> arm_smmu_write_strtab_ent() -> BUG_ON(ste_live):
# lspci -vt
-[0000:00]-+-00.0-[01-1f]--+ [...]
+ [...]
\-00.0-[1e-1f]----00.0-[1f]----00.0 ASPEED Technology, Inc. ASPEED Graphics Family
ASP device -> 1f:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family
PCI-Express to PCI/PCI-X Bridge -> 1e:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge
While setting up ASP device SID in IORT dirver:
iort_iommu_configure() -> pci_for_each_dma_alias()
we need to walk up and iterate over each device which alias transaction from
downstream devices.
AST device (1f:00.0) gets BDF=0x1f00 and corresponding SID=0x1f00 from IORT.
Bridge (1e:00.0) is the first alias. Following PCI Express to PCI/PCI-X Bridge
spec: PCIe-to-PCI/X bridges alias transactions from downstream devices using
the subordinate bus number. For bridge (1e:00.0), the subordinate is equal
to 0x1f. This gives BDF=0x1f00 and SID=1f00 which is the same as downstream
device. So it is possible to have two identical SIDs. The question is what we
should do about such case. Presented patch prevents from registering the same
ID so that SMMUv3 is not complaining later on.
Tomasz Nowicki (1):
iommu: Make sure device's ID array elements are unique
drivers/iommu/iommu.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH] ARM: imx: remove unused imx3 pm definitions
From: Fabio Estevam @ 2017-12-19 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513678024-2779-1-git-send-email-martin@kaiser.cx>
On Tue, Dec 19, 2017 at 8:07 AM, Martin Kaiser <martin@kaiser.cx> wrote:
> Remove the defintion of mx3_cpu_lp_set(), this function is not
> implemented anywhere. Remove then mx3_cpu_pwr_mode enum as well,
> it was used only as parameter of mx3_cpu_lp_set().
>
> Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH V4 14/26] pch_gbe: deprecate pci_get_bus_and_slot()
From: David Miller @ 2017-12-19 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ef7d09ce-06af-ad3e-1048-3b413cc32e9b@codeaurora.org>
From: Sinan Kaya <okaya@codeaurora.org>
Date: Tue, 19 Dec 2017 07:17:41 -0500
> Then hard code the domain number as 0 while calling
> pci_get_domain_bus_and_slot() if you know for sure that this device
> will never work on a non-zero domain.
Agreed, it's so much better to be explicit about this.
^ permalink raw reply
* [PATCH] pwm: atmel-tcb: Delete an error message for a failed memory allocation in atmel_tcb_pwm_probe()
From: Nicolas Ferre @ 2017-12-19 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8274c498-1d1b-2ece-365c-98ded714a53c@users.sourceforge.net>
Hi,
On 15/12/2017 at 19:00, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 15 Dec 2017 18:55:11 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
Can you point which coccinelle script highlited this issue?
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/pwm/pwm-atmel-tcb.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
> index acd3ce8ecf3f..4fb1be246c44 100644
> --- a/drivers/pwm/pwm-atmel-tcb.c
> +++ b/drivers/pwm/pwm-atmel-tcb.c
> @@ -401,7 +401,6 @@ static int atmel_tcb_pwm_probe(struct platform_device *pdev)
> tcbpwm = devm_kzalloc(&pdev->dev, sizeof(*tcbpwm), GFP_KERNEL);
> if (tcbpwm == NULL) {
> err = -ENOMEM;
> - dev_err(&pdev->dev, "failed to allocate memory\n");
We have this in case of error:
atmel-tcb-pwm pwm: failed to allocate memory
atmel-tcb-pwm: probe of pwm failed with error -12
Which is somehow redundant I admit...
> goto err_free_tc;
> }
>
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v1] mfd: ab8500: introduce DEFINE_SHOW_ATTRIBUTE() macro
From: Andy Shevchenko @ 2017-12-19 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215105432.pm36mtles7mpvcye@dell>
On Fri, 2017-12-15 at 10:54 +0000, Lee Jones wrote:
> Linus,
>
I suppose you would like to get his attention :-)
> > This macro deduplicates a lot of similar code in the ab8500-
> > debugfs.c module.
> > Targeting to be moved to seq_file.h eventually.
> >
Linus, it would be nice to have this in three for this cycle that will
allow me to move it to seq_file.h in the next one.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v4] staging: fsl-mc: move bus driver out of staging
From: Greg KH @ 2017-12-19 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171129100844.19874-1-laurentiu.tudor@nxp.com>
On Wed, Nov 29, 2017 at 12:08:44PM +0200, laurentiu.tudor at nxp.com wrote:
> From: Stuart Yoder <stuart.yoder@nxp.com>
>
> Move the source files out of staging into their final locations:
> -include files in drivers/staging/fsl-mc/include go to include/linux/fsl
> -irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
> -source in drivers/staging/fsl-mc/bus goes to drivers/bus/fsl-mc
> -README.txt, providing and overview of DPAA goes to
> Documentation/dpaa2/overview.txt
>
> Update or delete other remaining staging files-- Makefile, Kconfig, TODO.
> Update dpaa2_eth and dpio staging drivers.
>
> Signed-off-by: Stuart Yoder <stuyoder@gmail.com>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> [Laurentiu: rebased, add dpaa2_eth and dpio #include updates]
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> Notes:
> -v4:
> - regenerated patch with renames detection disabled (Andrew Lunn)
> -v3:
> - rebased
Ok, meta-comments on the structure of the code.
You have 8 .h files that are "private" to your bus logic. That's 7 too
many, some of them have a bigger license header than actual content :)
Please consolidate into 1.
Also, the headers should be moved to SPDX format to get rid of the
boilerplate. I _think_ it's BSD/GPL, right? Hard to tell :(
Your "public" .h file does not need to go into a subdirectory, just name
it fsl-mc.h and put it in include/linux/.
One comment on the fields in your .h file, all of the user/kernel
crossing boundry structures need to use the "__" variant of types, like
"__u8" and the like. You mix and match them for some reason, you need
to be consistent.
Also, what's up with the .h files in drivers/staging/fsl-bus/include?
You didn't touch those with this movement, right? Why?
For this initial move, only move the bus "core" code out, not the other
stuff like:
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 119 +++
these should be a separate file move, right?
> drivers/staging/fsl-dpaa2/ethernet/README | 2 +-
Why does a README file for a different driver need to be touched?
> drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 2 +-
> drivers/staging/fsl-dpaa2/ethernet/dpni.c | 2 +-
> drivers/staging/fsl-mc/README.txt | 386 ---------
This file gets moved to the Documentation directory, yet it is not tied
into the documentation build process, that's not good. It doesn't need
to have a separate directory either, right?
And speaking of documentation, you have directories in sysfs, yet no
Documentation/ABI/ files describing them. Please fix that up.
that's a good start :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: Vladimir Murzin @ 2017-12-19 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219112954.GA14910@afzalpc>
Hi,
On 19/12/17 11:29, afzal mohammed wrote:
> Hi,
>
> On Tue, Dec 19, 2017 at 10:23:49AM +0000, Vladimir Murzin wrote:
>> With switch to dynamic exception base address setting, VBAR/Hivecs
>> set only for boot CPU, but secondaries stay unaware of that. That
>> might lead to weird effects when trying up to bring up secondaries.
>>
>> Fixes: ad475117d201 ("ARM: 8649/2: nommu: remove Hivecs configuration is asm")
>
> Sorry, it was my incompetence not seeing the secondary CPU's case.
>
> Was the issue observed on Cortex-R ?, and was it occuring with
> CONFIG_CPU_HIGH_VECTOR enabled or disabled ?
I caught it when was trying to setup VBAR and after code inspection I
noticed that setting of Hivecs were changed as well.
>
> Instead of,
>
>> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
>
>> +#ifndef CONFIG_MMU
>> +extern unsigned long setup_vectors_base(void);
>> +#else
>> +static inline unsigned long setup_vectors_base(void)
>> +{
>> + return 0;
>> +}
>> +#endif
>
>> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
>
>> + setup_vectors_base();
>
> how about,
>
> if (!IS_ENABLED(CONFIG_MMU))
> setup_vectors_base();
>
> That would avoid #ifdef's. Also as w/ MMU, vector base is not setup
> (always Hivecs), this would make clear that setup_vectors_base() is
> non-existent on MMU on.
Works for me, but I went with plain #ifndef.
Vladimir
>
> Thanks for the fix.
>
> afzal
>
^ permalink raw reply
* [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: Ludovic BARRE @ 2017-12-19 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1WzkVQ3591XjVQPLCqP0_zZ4ksqJqWvm7de_OnkE3oaQ@mail.gmail.com>
On 12/18/2017 09:24 PM, Arnd Bergmann wrote:
> On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
>> From: Ludovic Barre <ludovic.barre@st.com>
>>
>> This patch prepares the STM32 machine for the integration of Cortex-A
>> based microprocessor (MPU), on top of the existing Cortex-M
>> microcontroller family (MCU). Since both MCUs and MPUs are sharing
>> common hardware blocks we can keep using ARCH_STM32 flag for most of
>> them. If a hardware block is specific to one family we can use either
>> ARM_SINGLE_ARMV7M or ARCH_MULTI_V7 flag.
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>
> Looks good overall. Two more small comments:
>
>
>>
>> +if ARCH_STM32
>> +
>> config MACH_STM32F429
>> - bool "STMicrolectronics STM32F429"
>> - depends on ARCH_STM32
>> + bool "STMicroelectronics STM32F429"
>> + depends on ARM_SINGLE_ARMV7M
>> default y
>
> Instead of the explicit dependency for each board, I'd leave the surrounding
> 'if ARM_SINGLE_ARMV7M'. I think you had in v1.
As you suggest, I follow mach-at91 example.
The point is on "depends on ARM_SINGLE_ARMV7M" ?
You prefer this way:
config MACH_STM32F429
bool "STMicroelectronics STM32F429" if ARM_SINGLE_ARMV7M
default y
BR
Ludo
>
>> diff --git a/arch/arm/mach-stm32/Makefile b/arch/arm/mach-stm32/Makefile
>> index bd0b7b5..5940af1 100644
>> --- a/arch/arm/mach-stm32/Makefile
>> +++ b/arch/arm/mach-stm32/Makefile
>> @@ -1 +1 @@
>> -obj-y += board-dt.o
>> +obj-$(CONFIG_ARM_SINGLE_ARMV7M) += board-mcu-dt.o
>> diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-mcu-dt.c
>> similarity index 100%
>> rename from arch/arm/mach-stm32/board-dt.c
>> rename to arch/arm/mach-stm32/board-mcu-dt.c
>
> Why the rename? I don't expect the new machines to have any notable
> contents in a board file, if any at all, so just use one file for both.
> I see the board-dt.c file refers to armv7m_restart, we can either put
> that in an #ifdef, or find a way to make it the default for all armv7-m
> platforms that don't provide any other restart method.
>
> Arnd
>
^ permalink raw reply
* [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: Alexandre Torgue @ 2017-12-19 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1WzkVQ3591XjVQPLCqP0_zZ4ksqJqWvm7de_OnkE3oaQ@mail.gmail.com>
On 12/18/2017 09:24 PM, Arnd Bergmann wrote:
> On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
>> From: Ludovic Barre <ludovic.barre@st.com>
>>
>> This patch prepares the STM32 machine for the integration of Cortex-A
>> based microprocessor (MPU), on top of the existing Cortex-M
>> microcontroller family (MCU). Since both MCUs and MPUs are sharing
>> common hardware blocks we can keep using ARCH_STM32 flag for most of
>> them. If a hardware block is specific to one family we can use either
>> ARM_SINGLE_ARMV7M or ARCH_MULTI_V7 flag.
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>
> Looks good overall. Two more small comments:
>
>
>>
>> +if ARCH_STM32
>> +
>> config MACH_STM32F429
>> - bool "STMicrolectronics STM32F429"
>> - depends on ARCH_STM32
>> + bool "STMicroelectronics STM32F429"
>> + depends on ARM_SINGLE_ARMV7M
>> default y
>
> Instead of the explicit dependency for each board, I'd leave the surrounding
> 'if ARM_SINGLE_ARMV7M'. I think you had in v1.
>
>> diff --git a/arch/arm/mach-stm32/Makefile b/arch/arm/mach-stm32/Makefile
>> index bd0b7b5..5940af1 100644
>> --- a/arch/arm/mach-stm32/Makefile
>> +++ b/arch/arm/mach-stm32/Makefile
>> @@ -1 +1 @@
>> -obj-y += board-dt.o
>> +obj-$(CONFIG_ARM_SINGLE_ARMV7M) += board-mcu-dt.o
>> diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-mcu-dt.c
>> similarity index 100%
>> rename from arch/arm/mach-stm32/board-dt.c
>> rename to arch/arm/mach-stm32/board-mcu-dt.c
>
> Why the rename? I don't expect the new machines to have any notable
> contents in a board file, if any at all, so just use one file for both.
> I see the board-dt.c file refers to armv7m_restart, we can either put
> that in an #ifdef, or find a way to make it the default for all armv7-m
> platforms that don't provide any other restart method.
>
Currently "restart" is not functional on stm32 MCU (at least for
stm32f746, I will check on others MCU). My fear is if Ludovic made some
patches to make "armv7m_restart" the default ".restart" function for all
armv7-m platform, he will not be able to test it on stm32 MCU (as it is
not currently working). I propose to do it in 2 steps:
1-Keep as you suggest only one board-dt.c file for both (MCU and MPU)
and remove ".restart" function.
2-Investigate and send patches around ".restart" for both in an other
series.
regards
Alex
> Arnd
>
^ permalink raw reply
* [PATCH v2] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: Vladimir Murzin @ 2017-12-19 14:38 UTC (permalink / raw)
To: linux-arm-kernel
With switch to dynamic exception base address setting, VBAR/Hivecs
set only for boot CPU, but secondaries stay unaware of that. That
might lead to weird effects when trying up to bring up secondaries.
Fixes: ad475117d201 ("ARM: 8649/2: nommu: remove Hivecs configuration is asm")
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/memory.h | 1 +
arch/arm/kernel/smp.c | 3 +++
arch/arm/mm/nommu.c | 4 ++--
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 1f54e4e..4966677 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -88,6 +88,7 @@
#else /* CONFIG_MMU */
#ifndef __ASSEMBLY__
+extern unsigned long setup_vectors_base(void);
extern unsigned long vectors_base;
#define VECTORS_BASE vectors_base
#endif
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b4fbf00..2da0879 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -379,6 +379,9 @@ asmlinkage void secondary_start_kernel(void)
cpu_init();
+#ifndef CONFIG_MMU
+ setup_vectors_base();
+#endif
pr_debug("CPU%u: Booted secondary processor\n", cpu);
preempt_disable();
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 885b106..c8beaab 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -31,7 +31,7 @@ struct mpu_rgn_info mpu_rgn_info;
#ifdef CONFIG_CPU_CP15
#ifdef CONFIG_CPU_HIGH_VECTOR
-static unsigned long __init setup_vectors_base(void)
+unsigned long setup_vectors_base(void)
{
unsigned long reg = get_cr();
@@ -58,7 +58,7 @@ static inline bool security_extensions_enabled(void)
return 0;
}
-static unsigned long __init setup_vectors_base(void)
+unsigned long setup_vectors_base(void)
{
unsigned long base = 0, reg = get_cr();
--
2.0.0
^ permalink raw reply related
* [PATCH v4 1/2] DTS: GTA04: improve panel compatibility string
From: Tony Lindgren @ 2017-12-19 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e52a086f-6748-0e5e-f9b5-d4532c34d215@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [171219 10:51]:
> On 11/12/17 17:22, Tony Lindgren wrote:
> > * H. Nikolaus Schaller <hns@goldelico.com> [171201 07:44]:
> > > Official vendor string is now "tpo" and not "toppoly".
> > >
> > > Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1"
> > > so that the driver understands both.
> >
> > Tomi, so what's the plan with the dependency patch, is that for v4.16
> > or for the v4.15-rc cycle?
>
> The dependency patch for this one is queued for v4.16 (I just sent a pull
> request today). I could pick this one up (if you give an ack) if I send
> another DRM pull request, but I probably don't have anything else to send so
> most likely I won't pick this up for v4.16.
OK thanks I'll queue both of these for v4.16 then.
> The patch 2/2 in the series doesn't have dependencies and can be applied as
> a fix for 4.15, or for 4.16.
>
> Neither of these are critical, as things work fine without these patches.
OK thanks for confirming that.
Regards,
Tony
^ permalink raw reply
* [PATCH v8 8/9] KVM: arm/arm64: Avoid work when userspace iqchips are not used
From: Marc Zyngier @ 2017-12-19 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219141857.GB5380@cbox>
On 19/12/17 14:18, Christoffer Dall wrote:
> On Tue, Dec 19, 2017 at 01:55:25PM +0000, Marc Zyngier wrote:
>> On 19/12/17 13:34, Christoffer Dall wrote:
>>> On Wed, Dec 13, 2017 at 08:05:33PM +0000, Marc Zyngier wrote:
>>>> On Wed, 13 Dec 2017 10:46:01 +0000,
>>>> Christoffer Dall wrote:
>>>>>
>>>>> We currently check if the VM has a userspace irqchip on every exit from
>>>>> the VCPU, and if so, we do some work to ensure correct timer behavior.
>>>>> This is unfortunate, as we could avoid doing any work entirely, if we
>>>>> didn't have to support irqchip in userspace.
>>>>>
>>>>> Realizing the userspace irqchip on ARM is mostly a developer or hobby
>>>>> feature, and is unlikely to be used in servers or other scenarios where
>>>>> performance is a priority, we can use a refcounted static key to only
>>>>> check the irqchip configuration when we have at least one VM that uses
>>>>> an irqchip in userspace.
>>>>>
>>>>> Reviewed-by: Eric Auger <eric.auger@redhat.com>
>>>>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>>>>
>>>> On its own, this doesn't seem to be that useful. As far as I can see,
>>>> it saves us a load from the kvm structure before giving up.
>>>
>>> A load and a conditional. But what I really wanted to also avoid was
>>> the function call from the main run loop, which I neglected as well. I
>>> think I can achieve that with a static inline wrapper in the arch timer
>>> header file which first evaluates the static key and then calls into the
>>> arch timer code.
>>>
>>>
>>>> I think it
>>>> is more the cumulative effect of this load that could have an impact,
>>>> but you're only dealing with it at a single location.
>>>>
>>>> How about making this a first class helper and redefine
>>>> irqchip_in_kernel as such:
>>>>
>>>> static inline bool irqchip_in_kernel(struct kvm *kvm)
>>>> {
>>>> if (static_branch_unlikely(&userspace_irqchip_in_use) &&
>>>> unlikely(!irqchip_in_kernel(kvm)))
>>>> return true;
>>>>
>>>> return false;
>>>> }
>>>>
>>>> and move that static key to a more central location?
>>>>
>>>
>>> That's a neat idea. The only problem is that creating a new VM would
>>> then flip the static key, and then we'd have to flip it back when a vgic
>>> is created on that VM, and I don't particularly like the idea of doing
>>> this too often.
>>
>> Fair enough.
>>
>>>
>>> What I'd suggest then is to have two versions of the function:
>>> irqchip_in_kernel() which is what it is today, and then
>>> __irqchip_in_kernel() which can only be called from within the critical
>>> path of the run loop, so that we can increment the static key on
>>> kvm_vcpu_first_run_init() when we don't have a VGIC.
>>>
>>> How does that sound?
>>
>> OK, you only patch once per non-VGIC VM instead of twice per VGIC VM.
>> But you now create a distinction between what can be used at runtime and
>> what can be used at config time. The distinction is a bit annoying.
>>
>> Also, does this actually show up on the radar?
>>
>
> Honestly, I don't know for this particular version of the patch.
>
> But when I did the VHE optimization work, which was before the userspace
> irqchip support went in, getting rid of calling kvm_timer_sync_hwstate()
> and the load+conditional in there (also prior to the level mapped
> patches), was measurable, between 50 to 100 cycles.
>
> Of course, that turned out to be buggy when rebooting VMs, so I never
> actually included that in my measurements, but it left me wanting to get
> rid of this.
>
> It's a bit of a delicate balance. On the one hand, it's silly to try to
> over-optimize, but on the other hand it's exactly the cumulative effect
> of optimizing every bit that managed to get us good results on VHE.
>
> How about this: I write up the patch in the complicated version as part
> of the next version, and if you think it's too difficult to maintain, we
> can just drop it an apply the series without it?
Sounds like a good plan.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
From: Fabio Estevam @ 2017-12-19 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219134308.4plzpknvksbzhio7@valkosipuli.retiisi.org.uk>
On Tue, Dec 19, 2017 at 11:43 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
> Both seem to exist. See e.g. c3a3d1d6b8b363a02234e5564692db3647f183e6 .
This patch fixes .h files to use /* SPDX style comment, which is the
recommendation.
.c files should use // SPDX style.
^ permalink raw reply
* [PATCH] i2c/ARM: davinci: Deep refactoring of I2C recovery
From: Sekhar Nori @ 2017-12-19 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208133132.17099-1-linus.walleij@linaro.org>
On Friday 08 December 2017 07:01 PM, Linus Walleij wrote:
> Alter the DaVinci GPIO recovery fetch to use descriptors
> all the way down into the board files.
>
> Cc: arm at kernel.org
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@kernel.org>
> Cc: Keerthy <j-keerthy@ti.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> It turns out someone else was busy doing the same thing I was
> doing. Trying to carry over the useful part with this patch!
> A Tested-by or ACK from a DaVinci maintainer would be
> appreciated, also an ACK from and ARM SoC maintainer.
> The patch can be easily tested by applying on top of
> linux-next.
This patch causes I2C probe failure on DM6446 EVM.
> ---
> arch/arm/mach-davinci/board-dm355-evm.c | 15 +++++++++++++--
> arch/arm/mach-davinci/board-dm644x-evm.c | 15 +++++++++++++--
> drivers/i2c/busses/i2c-davinci.c | 21 +++++++++++----------
> include/linux/platform_data/i2c-davinci.h | 5 ++---
> 4 files changed, 39 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
> index 62e7bc3018f0..60aec5437276 100644
> --- a/arch/arm/mach-davinci/board-dm355-evm.c
> +++ b/arch/arm/mach-davinci/board-dm355-evm.c
> @@ -17,6 +17,7 @@
> #include <linux/mtd/rawnand.h>
> #include <linux/i2c.h>
> #include <linux/gpio.h>
> +#include <linux/gpio/machine.h>
> #include <linux/clk.h>
> #include <linux/videodev2.h>
> #include <media/i2c/tvp514x.h>
> @@ -108,11 +109,20 @@ static struct platform_device davinci_nand_device = {
> },
> };
>
> +static struct gpiod_lookup_table i2c_recovery_gpiod_table = {
> + .dev_id = "i2c_davinci",
> + .table = {
> + GPIO_LOOKUP("davinci_gpio.0", 15, "sda",
This should just be "davinci_gpio"
> + GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
> + GPIO_LOOKUP("davinci_gpio.0", 14, "scl",
This too
> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
> index b07c9b18d427..2efc6dbc5ac0 100644
> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> @@ -13,6 +13,7 @@
> #include <linux/dma-mapping.h>
> #include <linux/platform_device.h>
> #include <linux/gpio.h>
> +#include <linux/gpio/machine.h>
> #include <linux/i2c.h>
> #include <linux/platform_data/pcf857x.h>
> #include <linux/platform_data/at24.h>
> @@ -595,18 +596,28 @@ static struct i2c_board_info __initdata i2c_info[] = {
> },
> };
>
> +static struct gpiod_lookup_table i2c_recovery_gpiod_table = {
> + .dev_id = "i2c_davinci",
> + .table = {
> + GPIO_LOOKUP("davinci_gpio.0", 44, "sda",
> + GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
> + GPIO_LOOKUP("davinci_gpio.0", 43, "scl",
> + GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
> + },
> +};
And these too.
With that fixed, please add:
Acked-by: Sekhar Nori <nsekhar@ti.com>
I could not test the recovery itself, but the probe succeeds.
It would be nice if this can be split into platform and driver parts to
avoid any conflicts, but that does not seem straightforward.
FWIW, the patch does not clash with anything I have queued ATM.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v8 8/9] KVM: arm/arm64: Avoid work when userspace iqchips are not used
From: Christoffer Dall @ 2017-12-19 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5e24dec5-613f-c10f-4577-df3787ad9d64@arm.com>
On Tue, Dec 19, 2017 at 01:55:25PM +0000, Marc Zyngier wrote:
> On 19/12/17 13:34, Christoffer Dall wrote:
> > On Wed, Dec 13, 2017 at 08:05:33PM +0000, Marc Zyngier wrote:
> >> On Wed, 13 Dec 2017 10:46:01 +0000,
> >> Christoffer Dall wrote:
> >>>
> >>> We currently check if the VM has a userspace irqchip on every exit from
> >>> the VCPU, and if so, we do some work to ensure correct timer behavior.
> >>> This is unfortunate, as we could avoid doing any work entirely, if we
> >>> didn't have to support irqchip in userspace.
> >>>
> >>> Realizing the userspace irqchip on ARM is mostly a developer or hobby
> >>> feature, and is unlikely to be used in servers or other scenarios where
> >>> performance is a priority, we can use a refcounted static key to only
> >>> check the irqchip configuration when we have at least one VM that uses
> >>> an irqchip in userspace.
> >>>
> >>> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> >>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> >>
> >> On its own, this doesn't seem to be that useful. As far as I can see,
> >> it saves us a load from the kvm structure before giving up.
> >
> > A load and a conditional. But what I really wanted to also avoid was
> > the function call from the main run loop, which I neglected as well. I
> > think I can achieve that with a static inline wrapper in the arch timer
> > header file which first evaluates the static key and then calls into the
> > arch timer code.
> >
> >
> >> I think it
> >> is more the cumulative effect of this load that could have an impact,
> >> but you're only dealing with it at a single location.
> >>
> >> How about making this a first class helper and redefine
> >> irqchip_in_kernel as such:
> >>
> >> static inline bool irqchip_in_kernel(struct kvm *kvm)
> >> {
> >> if (static_branch_unlikely(&userspace_irqchip_in_use) &&
> >> unlikely(!irqchip_in_kernel(kvm)))
> >> return true;
> >>
> >> return false;
> >> }
> >>
> >> and move that static key to a more central location?
> >>
> >
> > That's a neat idea. The only problem is that creating a new VM would
> > then flip the static key, and then we'd have to flip it back when a vgic
> > is created on that VM, and I don't particularly like the idea of doing
> > this too often.
>
> Fair enough.
>
> >
> > What I'd suggest then is to have two versions of the function:
> > irqchip_in_kernel() which is what it is today, and then
> > __irqchip_in_kernel() which can only be called from within the critical
> > path of the run loop, so that we can increment the static key on
> > kvm_vcpu_first_run_init() when we don't have a VGIC.
> >
> > How does that sound?
>
> OK, you only patch once per non-VGIC VM instead of twice per VGIC VM.
> But you now create a distinction between what can be used at runtime and
> what can be used at config time. The distinction is a bit annoying.
>
> Also, does this actually show up on the radar?
>
Honestly, I don't know for this particular version of the patch.
But when I did the VHE optimization work, which was before the userspace
irqchip support went in, getting rid of calling kvm_timer_sync_hwstate()
and the load+conditional in there (also prior to the level mapped
patches), was measurable, between 50 to 100 cycles.
Of course, that turned out to be buggy when rebooting VMs, so I never
actually included that in my measurements, but it left me wanting to get
rid of this.
It's a bit of a delicate balance. On the one hand, it's silly to try to
over-optimize, but on the other hand it's exactly the cumulative effect
of optimizing every bit that managed to get us good results on VHE.
How about this: I write up the patch in the complicated version as part
of the next version, and if you think it's too difficult to maintain, we
can just drop it an apply the series without it?
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v8 3/9] KVM: arm/arm64: Don't cache the timer IRQ level
From: Julien Thierry @ 2017-12-19 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213104602.16383-4-christoffer.dall@linaro.org>
Hi Christoffer,
A few nits in the commit message.
On 13/12/17 10:45, Christoffer Dall wrote:
> The timer was modeled after a strict idea of modelling an interrupt line
nit: modelling (also, modeled after a strict idea of modelling?)
> level in software, meaning that only transitions in the level needed to
s/needed/need/ ?
> be reported to the VGIC. This works well for the timer, because the
> arch timer code is in complete control of the device and can track the
> transitions of the line.
>
> However, as we are about to support using the HW bit in the VGIC not
> just for the timer, but also for VFIO which cannot track transitions of
> the interrupt line, we have to decide on an interface for level
> triggered mapped interrupts to the GIC, which both the timer and VFIO
"level triggered interrupts mapped to the GIC" ?
> can use.
>
> VFIO only sees an asserting transition of the physical interrupt line,
> and tells the VGIC when that happens. That means that part of the
> interrupt flow is offloaded to the hardware.
>
> To use the same interface for VFIO devices and the timer, we therefore
> have to change the timer (we cannot change VFIO because it doesn't know
> the details of the device it is assigning to a VM).
>
> Luckily, changing the timer is simple, we just need to stop 'caching'
> the line level, but instead let the VGIC know the state of the timer
> every time there is a potential change in the line level, and when the
> line level should be asserted from the timer ISR. The VGIC can ignore
> extra notifications using its validate mechanism.
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
> ---
> virt/kvm/arm/arch_timer.c | 20 +++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 4151250ce8da..dd5aca05c500 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -99,11 +99,9 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> }
> vtimer = vcpu_vtimer(vcpu);
>
> - if (!vtimer->irq.level) {
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - if (kvm_timer_irq_can_fire(vtimer))
> - kvm_timer_update_irq(vcpu, true, vtimer);
> - }
> + vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> + if (kvm_timer_irq_can_fire(vtimer))
> + kvm_timer_update_irq(vcpu, true, vtimer);
>
> if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
> kvm_vtimer_update_mask_user(vcpu);
> @@ -324,12 +322,20 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
> + bool level;
>
> if (unlikely(!timer->enabled))
> return;
>
> - if (kvm_timer_should_fire(vtimer) != vtimer->irq.level)
> - kvm_timer_update_irq(vcpu, !vtimer->irq.level, vtimer);
> + /*
> + * The vtimer virtual interrupt is a 'mapped' interrupt, meaning part
> + * of its lifecycle is offloaded to the hardware, and we therefore may
> + * not have lowered the irq.level value before having to signal a new
> + * interrupt, but have to signal an interrupt every time the level is
> + * asserted.
> + */
> + level = kvm_timer_should_fire(vtimer);
> + kvm_timer_update_irq(vcpu, level, vtimer);
>
> if (kvm_timer_should_fire(ptimer) != ptimer->irq.level)
> kvm_timer_update_irq(vcpu, !ptimer->irq.level, ptimer);
>
--
Julien Thierry
^ permalink raw reply
* [PATCH V4 13/26] bnx2x: deprecate pci_get_bus_and_slot()
From: David Miller @ 2017-12-19 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-14-git-send-email-okaya@codeaurora.org>
From: Sinan Kaya <okaya@codeaurora.org>
Date: Tue, 19 Dec 2017 00:37:49 -0500
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
>
> Introduce bnx2x_vf_domain() function to extract the domain information
> and save it to VF specific data structure.
>
> Use the saved domain value while calling pci_get_domain_bus_and_slot().
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH V4 20/26] openprom: deprecate pci_get_bus_and_slot()
From: David Miller @ 2017-12-19 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-21-git-send-email-okaya@codeaurora.org>
From: Sinan Kaya <okaya@codeaurora.org>
Date: Tue, 19 Dec 2017 00:37:56 -0500
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
>
> Hard-coding the domain as 0 since domain information is not available.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH V4 10/26] Drivers: ide: deprecate pci_get_bus_and_slot()
From: David Miller @ 2017-12-19 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-11-git-send-email-okaya@codeaurora.org>
From: Sinan Kaya <okaya@codeaurora.org>
Date: Tue, 19 Dec 2017 00:37:46 -0500
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
>
> Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
> and extract the domain number from struct pci_dev.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH V4 14/26] pch_gbe: deprecate pci_get_bus_and_slot()
From: David Miller @ 2017-12-19 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-15-git-send-email-okaya@codeaurora.org>
From: Sinan Kaya <okaya@codeaurora.org>
Date: Tue, 19 Dec 2017 00:37:50 -0500
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
>
> Use the domain information from pdev while calling into
> pci_get_domain_bus_and_slot() function.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH v5 11/11] thermal: armada: Give meaningful names to the thermal zones
From: Miquel Raynal @ 2017-12-19 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219135719.9531-1-miquel.raynal@free-electrons.com>
After registration to the thermal core, sysfs will make one entry
per instance of the driver in /sys/class/thermal_zoneX and
/sys/class/hwmon/hwmonX, X being the index of the instance, all of them
having the type/name "armada_thermal".
Until now there was only one thermal zone per SoC but SoCs like Armada
A7K and Armada A8K have respectively two and three thermal zones (one
per AP and one per CP) and this number is subject to grow in the future.
Use dev_name() instead of the "armada_thermal" string to get a
meaningful name and be able to identify the thermal zones from
userspace.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 346a0c781057..362d2e356696 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -404,8 +404,8 @@ static int armada_thermal_probe(struct platform_device *pdev)
priv->data->init_sensor(pdev, priv);
- thermal = thermal_zone_device_register("armada_thermal", 0, 0,
- priv, &ops, NULL, 0, 0);
+ thermal = thermal_zone_device_register(dev_name(&pdev->dev), 0, 0, priv,
+ &ops, NULL, 0, 0);
if (IS_ERR(thermal)) {
dev_err(&pdev->dev,
"Failed to register thermal zone device\n");
--
2.11.0
^ permalink raw reply related
* [PATCH v5 10/11] thermal: armada: Wait sensors validity before exiting the init callback
From: Miquel Raynal @ 2017-12-19 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219135719.9531-1-miquel.raynal@free-electrons.com>
The thermal core will check for sensors validity right after the
initialization callback has returned. As the initialization routine make
a reset, the sensors are not ready immediately and the core spawns an
error in the dmesg. Avoid this annoying situation by polling on the
validity bit before exiting from these routines. This also avoid the use
of blind sleeps.
Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 1a7e24da0b9e..346a0c781057 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -23,6 +23,7 @@
#include <linux/platform_device.h>
#include <linux/of_device.h>
#include <linux/thermal.h>
+#include <linux/iopoll.h>
/* Thermal Manager Control and Status Register */
#define PMU_TDC0_SW_RST_MASK (0x1 << 1)
@@ -59,6 +60,9 @@
#define CONTROL1_EXT_TSEN_SW_RESET BIT(7)
#define CONTROL1_EXT_TSEN_HW_RESETn BIT(8)
+#define STATUS_POLL_PERIOD_US 1000
+#define STATUS_POLL_TIMEOUT_US 100000
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
@@ -155,6 +159,16 @@ static void armada375_init_sensor(struct platform_device *pdev,
msleep(50);
}
+static void armada_wait_sensor_validity(struct armada_thermal_priv *priv)
+{
+ u32 reg;
+
+ readl_relaxed_poll_timeout(priv->status, reg,
+ reg & priv->data->is_valid_bit,
+ STATUS_POLL_PERIOD_US,
+ STATUS_POLL_TIMEOUT_US);
+}
+
static void armada380_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
@@ -164,7 +178,6 @@ static void armada380_init_sensor(struct platform_device *pdev,
reg |= CONTROL1_EXT_TSEN_HW_RESETn;
reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
writel(reg, priv->control1);
- msleep(10);
/* Set Tsen Tc Trim to correct default value (errata #132698) */
if (priv->control0) {
@@ -172,8 +185,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
reg |= CONTROL0_TSEN_TC_TRIM_VAL;
writel(reg, priv->control0);
- msleep(10);
}
+
+ /* Wait the sensors to be valid or the core will warn the user */
+ armada_wait_sensor_validity(priv);
}
static void armada_ap806_init_sensor(struct platform_device *pdev,
@@ -185,7 +200,9 @@ static void armada_ap806_init_sensor(struct platform_device *pdev,
reg &= ~CONTROL0_TSEN_RESET;
reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
writel(reg, priv->control0);
- msleep(10);
+
+ /* Wait the sensors to be valid or the core will warn the user */
+ armada_wait_sensor_validity(priv);
}
static bool armada_is_valid(struct armada_thermal_priv *priv)
--
2.11.0
^ permalink raw reply related
* [PATCH v5 09/11] thermal: armada: Change sensors trim default value
From: Miquel Raynal @ 2017-12-19 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219135719.9531-1-miquel.raynal@free-electrons.com>
Errata #132698 highlights an error in the default value of Tc trim.
Set this parameter to b'011.
Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 40b57ba2f55b..1a7e24da0b9e 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -46,6 +46,10 @@
#define CONTROL0_OFFSET 0x0
#define CONTROL1_OFFSET 0x4
+/* Errata fields */
+#define CONTROL0_TSEN_TC_TRIM_MASK 0x7
+#define CONTROL0_TSEN_TC_TRIM_VAL 0x3
+
/* TSEN refers to the temperature sensors within the AP */
#define CONTROL0_TSEN_START BIT(0)
#define CONTROL0_TSEN_RESET BIT(1)
@@ -161,6 +165,15 @@ static void armada380_init_sensor(struct platform_device *pdev,
reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
writel(reg, priv->control1);
msleep(10);
+
+ /* Set Tsen Tc Trim to correct default value (errata #132698) */
+ if (priv->control0) {
+ reg = readl_relaxed(priv->control0);
+ reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
+ reg |= CONTROL0_TSEN_TC_TRIM_VAL;
+ writel(reg, priv->control0);
+ msleep(10);
+ }
}
static void armada_ap806_init_sensor(struct platform_device *pdev,
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: multi_v7_defconfig: Select PWM_RCAR as module
From: Fabrizio Castro @ 2017-12-19 13:57 UTC (permalink / raw)
To: linux-arm-kernel
Enable PWM support for R-Car and friends by default.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 61509c4..b4c36f9 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -879,6 +879,7 @@ CONFIG_PWM_ATMEL=m
CONFIG_PWM_ATMEL_HLCDC_PWM=m
CONFIG_PWM_ATMEL_TCB=m
CONFIG_PWM_FSL_FTM=m
+CONFIG_PWM_RCAR=m
CONFIG_PWM_RENESAS_TPU=y
CONFIG_PWM_ROCKCHIP=m
CONFIG_PWM_SAMSUNG=m
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox