* [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
* [PATCH v5 08/11] thermal: armada: Update Kconfig and module description
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>
Update Armada thermal driver Kconfig entry as well as the driver's
MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
eg. Armada 7K and Armada 8K.
Use the generic term "Marvell EBU Armada SoCs" instead of listing all
the supported SoCs everywhere (excepted in the Kconfig description,
where it is useful to have a list).
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/Kconfig | 4 ++--
drivers/thermal/armada_thermal.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 315ae2926e20..b6adc54b96f1 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -301,13 +301,13 @@ config DB8500_THERMAL
thermal zone if trip points reached.
config ARMADA_THERMAL
- tristate "Armada 370/XP thermal management"
+ tristate "Marvell EBU Armada SoCs thermal management"
depends on ARCH_MVEBU || COMPILE_TEST
depends on HAS_IOMEM
depends on OF
help
Enable this option if you want to have support for thermal management
- controller present in Armada 370 and Armada XP SoC.
+ controller present in Marvell EBU Armada SoCs (370,375,XP,38x,7K,8K).
config DA9062_THERMAL
tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 3785b5248bf5..40b57ba2f55b 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -1,5 +1,5 @@
/*
- * Marvell Armada 370/XP thermal sensor driver
+ * Marvell EBU Armada SoCs thermal sensor driver
*
* Copyright (C) 2013 Marvell
*
@@ -409,5 +409,5 @@ static struct platform_driver armada_thermal_driver = {
module_platform_driver(armada_thermal_driver);
MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia@free-electrons.com>");
-MODULE_DESCRIPTION("Armada 370/XP thermal driver");
+MODULE_DESCRIPTION("Marvell EBU Armada SoCs thermal driver");
MODULE_LICENSE("GPL v2");
--
2.11.0
^ permalink raw reply related
* [PATCH v5 07/11] thermal: armada: Add support for Armada CP110
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>
From: Baruch Siach <baruch@tkos.co.il>
The CP110 component is integrated in the Armada 8k and 7k lines of
processors.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[<miquel.raynal@free-electrons.com>: renamed the register pointers as
well as some definitions related to the new register names and
simplified the init sequence for Armada 380]
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 33 ++++++++++++++++++++++++++-------
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index c7dcac39cbf9..3785b5248bf5 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -37,7 +37,6 @@
#define A375_UNIT_CONTROL_MASK 0x7
#define A375_READOUT_INVERT BIT(15)
#define A375_HW_RESETn BIT(8)
-#define A380_HW_RESET BIT(8)
/* Legacy bindings */
#define LEGACY_CONTROL_MEM_LEN 0x4
@@ -52,6 +51,10 @@
#define CONTROL0_TSEN_RESET BIT(1)
#define CONTROL0_TSEN_ENABLE BIT(2)
+/* EXT_TSEN refers to the external temperature sensors, out of the AP */
+#define CONTROL1_EXT_TSEN_SW_RESET BIT(7)
+#define CONTROL1_EXT_TSEN_HW_RESETn BIT(8)
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
@@ -153,12 +156,11 @@ static void armada380_init_sensor(struct platform_device *pdev,
{
u32 reg = readl_relaxed(priv->control1);
- /* Reset hardware once */
- if (!(reg & A380_HW_RESET)) {
- reg |= A380_HW_RESET;
- writel(reg, priv->control1);
- msleep(10);
- }
+ /* Disable the HW/SW reset */
+ reg |= CONTROL1_EXT_TSEN_HW_RESETn;
+ reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
+ writel(reg, priv->control1);
+ msleep(10);
}
static void armada_ap806_init_sensor(struct platform_device *pdev,
@@ -279,6 +281,19 @@ static const struct armada_thermal_data armada_ap806_data = {
.needs_control0 = true,
};
+static const struct armada_thermal_data armada_cp110_data = {
+ .is_valid = armada_is_valid,
+ .init_sensor = armada380_init_sensor,
+ .is_valid_bit = BIT(10),
+ .temp_shift = 0,
+ .temp_mask = 0x3ff,
+ .coef_b = 1172499100ULL,
+ .coef_m = 2000096ULL,
+ .coef_div = 4201,
+ .inverted = true,
+ .needs_control0 = true,
+};
+
static const struct of_device_id armada_thermal_id_table[] = {
{
.compatible = "marvell,armadaxp-thermal",
@@ -301,6 +316,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
.data = &armada_ap806_data,
},
{
+ .compatible = "marvell,armada-cp110-thermal",
+ .data = &armada_cp110_data,
+ },
+ {
/* sentinel */
},
};
--
2.11.0
^ permalink raw reply related
* [PATCH v5 06/11] thermal: armada: Add support for Armada AP806
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>
From: Baruch Siach <baruch@tkos.co.il>
The AP806 component is integrated in the Armada 8K and 7K lines of
processors.
The thermal sensor sample field on the status register is a signed
value. Extend armada_get_temp() and the driver structure to handle
signed values.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[<miquel.raynal@free-electrons.com>: Changes when applying over the
previous patches, including the register names changes, also switched
the coefficients values to s64 instead of unsigned long to deal with
negative values and used do_div instead of the traditionnal '/']
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 74 ++++++++++++++++++++++++++++++++--------
1 file changed, 59 insertions(+), 15 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index ceebabf45c53..c7dcac39cbf9 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -47,6 +47,11 @@
#define CONTROL0_OFFSET 0x0
#define CONTROL1_OFFSET 0x4
+/* TSEN refers to the temperature sensors within the AP */
+#define CONTROL0_TSEN_START BIT(0)
+#define CONTROL0_TSEN_RESET BIT(1)
+#define CONTROL0_TSEN_ENABLE BIT(2)
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
@@ -66,10 +71,11 @@ struct armada_thermal_data {
bool (*is_valid)(struct armada_thermal_priv *);
/* Formula coeficients: temp = (b - m * reg) / div */
- unsigned long coef_b;
- unsigned long coef_m;
- unsigned long coef_div;
+ s64 coef_b;
+ s64 coef_m;
+ u32 coef_div;
bool inverted;
+ bool signed_sample;
/* Register shift and mask to access the sensor temperature */
unsigned int temp_shift;
@@ -155,6 +161,18 @@ static void armada380_init_sensor(struct platform_device *pdev,
}
}
+static void armada_ap806_init_sensor(struct platform_device *pdev,
+ struct armada_thermal_priv *priv)
+{
+ u32 reg;
+
+ reg = readl_relaxed(priv->control0);
+ reg &= ~CONTROL0_TSEN_RESET;
+ reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
+ writel(reg, priv->control0);
+ msleep(10);
+}
+
static bool armada_is_valid(struct armada_thermal_priv *priv)
{
u32 reg = readl_relaxed(priv->status);
@@ -166,8 +184,8 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
int *temp)
{
struct armada_thermal_priv *priv = thermal->devdata;
- unsigned long reg;
- unsigned long m, b, div;
+ u32 reg, div;
+ s64 sample, b, m;
/* Valid check */
if (priv->data->is_valid && !priv->data->is_valid(priv)) {
@@ -178,6 +196,11 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
reg = readl_relaxed(priv->status);
reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
+ if (priv->data->signed_sample)
+ /* The most significant bit is the sign bit */
+ sample = sign_extend32(reg, fls(priv->data->temp_mask) - 1);
+ else
+ sample = reg;
/* Get formula coeficients */
b = priv->data->coef_b;
@@ -185,9 +208,12 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
div = priv->data->coef_div;
if (priv->data->inverted)
- *temp = ((m * reg) - b) / div;
+ *temp = (m * sample) - b;
else
- *temp = (b - (m * reg)) / div;
+ *temp = b - (m * sample);
+
+ do_div(*temp, div);
+
return 0;
}
@@ -199,8 +225,8 @@ static const struct armada_thermal_data armadaxp_data = {
.init_sensor = armadaxp_init_sensor,
.temp_shift = 10,
.temp_mask = 0x1ff,
- .coef_b = 3153000000UL,
- .coef_m = 10000000UL,
+ .coef_b = 3153000000ULL,
+ .coef_m = 10000000ULL,
.coef_div = 13825,
};
@@ -210,8 +236,8 @@ static const struct armada_thermal_data armada370_data = {
.is_valid_bit = BIT(9),
.temp_shift = 10,
.temp_mask = 0x1ff,
- .coef_b = 3153000000UL,
- .coef_m = 10000000UL,
+ .coef_b = 3153000000ULL,
+ .coef_m = 10000000ULL,
.coef_div = 13825,
};
@@ -221,8 +247,8 @@ static const struct armada_thermal_data armada375_data = {
.is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x1ff,
- .coef_b = 3171900000UL,
- .coef_m = 10000000UL,
+ .coef_b = 3171900000ULL,
+ .coef_m = 10000000ULL,
.coef_div = 13616,
.needs_control0 = true,
};
@@ -233,12 +259,26 @@ static const struct armada_thermal_data armada380_data = {
.is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x3ff,
- .coef_b = 1172499100UL,
- .coef_m = 2000096UL,
+ .coef_b = 1172499100ULL,
+ .coef_m = 2000096ULL,
.coef_div = 4201,
.inverted = true,
};
+static const struct armada_thermal_data armada_ap806_data = {
+ .is_valid = armada_is_valid,
+ .init_sensor = armada_ap806_init_sensor,
+ .is_valid_bit = BIT(16),
+ .temp_shift = 0,
+ .temp_mask = 0x3ff,
+ .coef_b = -150000LL,
+ .coef_m = 423ULL,
+ .coef_div = 1,
+ .inverted = true,
+ .signed_sample = true,
+ .needs_control0 = true,
+};
+
static const struct of_device_id armada_thermal_id_table[] = {
{
.compatible = "marvell,armadaxp-thermal",
@@ -257,6 +297,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
.data = &armada380_data,
},
{
+ .compatible = "marvell,armada-ap806-thermal",
+ .data = &armada_ap806_data,
+ },
+ {
/* sentinel */
},
};
--
2.11.0
^ permalink raw reply related
* [PATCH v5 05/11] thermal: armada: Use real status register name
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>
Three 32-bit registers are used to drive the thermal IP: control0,
control1 and status. The two control registers share the same name both
in the documentation and in the code, while the latter is referred as
"sensor" in the code. Rename this pointer to be called "status" in order
to be aligned with the documentation.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index d58376eba6d9..ceebabf45c53 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -51,7 +51,7 @@ struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
struct armada_thermal_priv {
- void __iomem *sensor;
+ void __iomem *status;
void __iomem *control0;
void __iomem *control1;
struct armada_thermal_data *data;
@@ -99,9 +99,9 @@ static void armadaxp_init_sensor(struct platform_device *pdev,
writel(reg, priv->control1);
/* Enable the sensor */
- reg = readl_relaxed(priv->sensor);
+ reg = readl_relaxed(priv->status);
reg &= ~PMU_TM_DISABLE_MASK;
- writel(reg, priv->sensor);
+ writel(reg, priv->status);
}
static void armada370_init_sensor(struct platform_device *pdev,
@@ -157,7 +157,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
static bool armada_is_valid(struct armada_thermal_priv *priv)
{
- u32 reg = readl_relaxed(priv->sensor);
+ u32 reg = readl_relaxed(priv->status);
return reg & priv->data->is_valid_bit;
}
@@ -176,7 +176,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
return -EIO;
}
- reg = readl_relaxed(priv->sensor);
+ reg = readl_relaxed(priv->status);
reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
/* Get formula coeficients */
@@ -279,9 +279,9 @@ static int armada_thermal_probe(struct platform_device *pdev)
return -ENOMEM;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->sensor = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(priv->sensor))
- return PTR_ERR(priv->sensor);
+ priv->status = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->status))
+ return PTR_ERR(priv->status);
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
control = devm_ioremap_resource(&pdev->dev, res);
--
2.11.0
^ permalink raw reply related
* [PATCH v5 04/11] thermal: armada: Clarify control registers accesses
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>
Bindings were incomplete for a long time by only exposing one of the two
available control registers. To ease the migration to the full bindings
(already in use for the Armada 375 SoC), rename the pointers for
clarification. This way, it will only be needed to add another pointer
to access the other control register when the time comes.
This avoids dangerous situations where the offset 0 of the control
area can be either one register or the other depending on the bindings
used. After this change, device trees of other SoCs could be migrated to
the "full" bindings if they may benefit from features from the
unaccessible register, without any change in the driver.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 76 ++++++++++++++++++++++++++++------------
1 file changed, 54 insertions(+), 22 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index f350d7efd35a..d58376eba6d9 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -39,12 +39,21 @@
#define A375_HW_RESETn BIT(8)
#define A380_HW_RESET BIT(8)
+/* Legacy bindings */
+#define LEGACY_CONTROL_MEM_LEN 0x4
+
+/* Current bindings with the 2 control registers under the same memory area */
+#define LEGACY_CONTROL1_OFFSET 0x0
+#define CONTROL0_OFFSET 0x0
+#define CONTROL1_OFFSET 0x4
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
struct armada_thermal_priv {
void __iomem *sensor;
- void __iomem *control;
+ void __iomem *control0;
+ void __iomem *control1;
struct armada_thermal_data *data;
};
@@ -66,27 +75,28 @@ struct armada_thermal_data {
unsigned int temp_shift;
unsigned int temp_mask;
u32 is_valid_bit;
+ bool needs_control0;
};
static void armadaxp_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg;
+ u32 reg;
- reg = readl_relaxed(priv->control);
+ reg = readl_relaxed(priv->control1);
reg |= PMU_TDC0_OTF_CAL_MASK;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Reference calibration value */
reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Reset the sensor */
- reg = readl_relaxed(priv->control);
- writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
+ reg = readl_relaxed(priv->control1);
+ writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Enable the sensor */
reg = readl_relaxed(priv->sensor);
@@ -97,19 +107,19 @@ static void armadaxp_init_sensor(struct platform_device *pdev,
static void armada370_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg;
+ u32 reg;
- reg = readl_relaxed(priv->control);
+ reg = readl_relaxed(priv->control1);
reg |= PMU_TDC0_OTF_CAL_MASK;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Reference calibration value */
reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
- writel(reg, priv->control);
+ writel(reg, priv->control1);
reg &= ~PMU_TDC0_START_CAL_MASK;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
msleep(10);
}
@@ -117,30 +127,30 @@ static void armada370_init_sensor(struct platform_device *pdev,
static void armada375_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg;
+ u32 reg;
- reg = readl(priv->control + 4);
+ reg = readl(priv->control1);
reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
reg &= ~A375_READOUT_INVERT;
reg &= ~A375_HW_RESETn;
- writel(reg, priv->control + 4);
+ writel(reg, priv->control1);
msleep(20);
reg |= A375_HW_RESETn;
- writel(reg, priv->control + 4);
+ writel(reg, priv->control1);
msleep(50);
}
static void armada380_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg = readl_relaxed(priv->control);
+ u32 reg = readl_relaxed(priv->control1);
/* Reset hardware once */
if (!(reg & A380_HW_RESET)) {
reg |= A380_HW_RESET;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
msleep(10);
}
}
@@ -214,6 +224,7 @@ static const struct armada_thermal_data armada375_data = {
.coef_b = 3171900000UL,
.coef_m = 10000000UL,
.coef_div = 13616,
+ .needs_control0 = true,
};
static const struct armada_thermal_data armada380_data = {
@@ -253,6 +264,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
static int armada_thermal_probe(struct platform_device *pdev)
{
+ void __iomem *control = NULL;
struct thermal_zone_device *thermal;
const struct of_device_id *match;
struct armada_thermal_priv *priv;
@@ -272,11 +284,31 @@ static int armada_thermal_probe(struct platform_device *pdev)
return PTR_ERR(priv->sensor);
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- priv->control = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(priv->control))
- return PTR_ERR(priv->control);
+ control = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(control))
+ return PTR_ERR(control);
priv->data = (struct armada_thermal_data *)match->data;
+
+ /*
+ * Legacy DT bindings only described "control1" register (also referred
+ * as "control MSB" on old documentation). New bindings cover
+ * "control0/control LSB" and "control1/control MSB" registers within
+ * the same resource, which is then of size 8 instead of 4.
+ */
+ if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
+ /* ->control0 unavailable in this configuration */
+ if (priv->data->needs_control0) {
+ dev_err(&pdev->dev, "No access to control0 register\n");
+ return -EINVAL;
+ }
+
+ priv->control1 = control + LEGACY_CONTROL1_OFFSET;
+ } else {
+ priv->control0 = control + CONTROL0_OFFSET;
+ priv->control1 = control + CONTROL1_OFFSET;
+ }
+
priv->data->init_sensor(pdev, priv);
thermal = thermal_zone_device_register("armada_thermal", 0, 0,
--
2.11.0
^ permalink raw reply related
* [PATCH v5 03/11] thermal: armada: Simplify the check of the validity bit
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>
All Armada SoCs use one bit to declare if the sensor values are valid.
This bit moves across the versions of the IP.
The method until then was to do both a shift and compare with an useless
flag of "0x1". It is clearer and quicker to directly save the value that
must be ANDed instead of the bit position and do a single bitwise AND
operation.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 6c4af2622d4f..f350d7efd35a 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -24,8 +24,6 @@
#include <linux/of_device.h>
#include <linux/thermal.h>
-#define THERMAL_VALID_MASK 0x1
-
/* Thermal Manager Control and Status Register */
#define PMU_TDC0_SW_RST_MASK (0x1 << 1)
#define PMU_TM_DISABLE_OFFS 0
@@ -67,7 +65,7 @@ struct armada_thermal_data {
/* Register shift and mask to access the sensor temperature */
unsigned int temp_shift;
unsigned int temp_mask;
- unsigned int is_valid_shift;
+ u32 is_valid_bit;
};
static void armadaxp_init_sensor(struct platform_device *pdev,
@@ -149,9 +147,9 @@ static void armada380_init_sensor(struct platform_device *pdev,
static bool armada_is_valid(struct armada_thermal_priv *priv)
{
- unsigned long reg = readl_relaxed(priv->sensor);
+ u32 reg = readl_relaxed(priv->sensor);
- return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
+ return reg & priv->data->is_valid_bit;
}
static int armada_get_temp(struct thermal_zone_device *thermal,
@@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
static const struct armada_thermal_data armada370_data = {
.is_valid = armada_is_valid,
.init_sensor = armada370_init_sensor,
- .is_valid_shift = 9,
+ .is_valid_bit = BIT(9),
.temp_shift = 10,
.temp_mask = 0x1ff,
.coef_b = 3153000000UL,
@@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
static const struct armada_thermal_data armada375_data = {
.is_valid = armada_is_valid,
.init_sensor = armada375_init_sensor,
- .is_valid_shift = 10,
+ .is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x1ff,
.coef_b = 3171900000UL,
@@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
static const struct armada_thermal_data armada380_data = {
.is_valid = armada_is_valid,
.init_sensor = armada380_init_sensor,
- .is_valid_shift = 10,
+ .is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x3ff,
.coef_b = 1172499100UL,
--
2.11.0
^ permalink raw reply related
* [PATCH v5 02/11] thermal: armada: Use msleep for long delays
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>
From: Baruch Siach <baruch@tkos.co.il>
Use msleep for long (> 10ms) delays, instead of the busy waiting mdelay.
All delays are called from the probe routine, where scheduling is
allowed.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 706d74798cbe..6c4af2622d4f 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -113,7 +113,7 @@ static void armada370_init_sensor(struct platform_device *pdev,
reg &= ~PMU_TDC0_START_CAL_MASK;
writel(reg, priv->control);
- mdelay(10);
+ msleep(10);
}
static void armada375_init_sensor(struct platform_device *pdev,
@@ -127,11 +127,11 @@ static void armada375_init_sensor(struct platform_device *pdev,
reg &= ~A375_HW_RESETn;
writel(reg, priv->control + 4);
- mdelay(20);
+ msleep(20);
reg |= A375_HW_RESETn;
writel(reg, priv->control + 4);
- mdelay(50);
+ msleep(50);
}
static void armada380_init_sensor(struct platform_device *pdev,
@@ -143,7 +143,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
if (!(reg & A380_HW_RESET)) {
reg |= A380_HW_RESET;
writel(reg, priv->control);
- mdelay(10);
+ msleep(10);
}
}
--
2.11.0
^ permalink raw reply related
* [PATCH v5 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
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>
From: Baruch Siach <baruch@tkos.co.il>
Add compatible strings for AP806 and CP110 that are part of the Armada
8k/7k line of SoCs.
Add a note on the differences in the size of the control area in
different bindings. This is an existing difference between the Armada
375 binding and the other boards already supported. The new AP806 and
CP110 bindings are similar to the existing Armada 375 in this regard.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[<miquel.raynal@free-electrons.com>: reword, additional details]
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
.../devicetree/bindings/thermal/armada-thermal.txt | 37 +++++++++++++++-------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
index 24aacf8948c5..e0d013a2e66d 100644
--- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -2,22 +2,35 @@
Required properties:
-- compatible: Should be set to one of the following:
- marvell,armada370-thermal
- marvell,armada375-thermal
- marvell,armada380-thermal
- marvell,armadaxp-thermal
+- compatible: Should be set to one of the following:
+ * marvell,armada370-thermal
+ * marvell,armada375-thermal
+ * marvell,armada380-thermal
+ * marvell,armadaxp-thermal
+ * marvell,armada-ap806-thermal
+ * marvell,armada-cp110-thermal
-- reg: Device's register space.
- Two entries are expected, see the examples below.
- The first one is required for the sensor register;
- the second one is required for the control register
- to be used for sensor initialization (a.k.a. calibration).
+- reg: Device's register space.
+ Two entries are expected, see the examples below. The first one points
+ to the status register (4B). The second one points to the control
+ registers (8B).
+ Note: The compatibles marvell,armada370-thermal,
+ marvell,armada380-thermal, and marvell,armadaxp-thermal must point to
+ "control MSB/control 1", with size of 4 (deprecated binding), or point
+ to "control LSB/control 0" with size of 8 (current binding). All other
+ compatibles must point to "control LSB/control 0" with size of 8.
-Example:
+Examples:
+ /* Legacy bindings */
thermal at d0018300 {
compatible = "marvell,armada370-thermal";
- reg = <0xd0018300 0x4
+ reg = <0xd0018300 0x4
0xd0018304 0x4>;
};
+
+ ap_thermal: thermal at 6f8084 {
+ compatible = "marvell,armada-ap806-thermal";
+ reg = <0x6f808C 0x4>,
+ <0x6f8084 0x8>;
+ };
--
2.11.0
^ permalink raw reply related
* [PATCH v5 00/11] Armada thermal: improvements and A7K/A8K SoCs support
From: Miquel Raynal @ 2017-12-19 13:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series takes over Baruch's series by integrating his patches about
supporting thermal on Armada 7K and 8K SoCs within a larger series with
several improvements on the armada_thermal.c driver.
For now, Armada 380 and CP110 compatibles share the same initialization
routine but this will probably change in the near future when adding
support for overheat interrupts.
DT bindings documentation is updated to match existing code.
Armada AP806 and CP110 DT are also updated with thermal nodes and have
already been accepted (thus absent in this series).
Thank you,
Miqu?l
Changes since v4:
- Added Gregory's Reviewed-by tags
- Rephrased the paragraph in the documentation explaining what
compatible supports.
- Enumerated the compatibles supporting only the new bindings.
- Required the Armada 375 SoC compatible string to be used with
new bindings.
Baruch Siach (4):
dt-bindings: thermal: Describe Armada AP806 and CP110
thermal: armada: Use msleep for long delays
thermal: armada: Add support for Armada AP806
thermal: armada: Add support for Armada CP110
Miquel Raynal (7):
thermal: armada: Simplify the check of the validity bit
thermal: armada: Clarify control registers accesses
thermal: armada: Use real status register name
thermal: armada: Update Kconfig and module description
thermal: armada: Change sensors trim default value
thermal: armada: Wait sensors validity before exiting the init
callback
thermal: armada: Give meaningful names to the thermal zones
.../devicetree/bindings/thermal/armada-thermal.txt | 37 ++-
drivers/thermal/Kconfig | 4 +-
drivers/thermal/armada_thermal.c | 253 +++++++++++++++------
3 files changed, 215 insertions(+), 79 deletions(-)
--
2.11.0
^ 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