* [PATCH V8 3/3] irqchip: qcom: Add IRQ combiner driver
From: Marc Zyngier @ 2016-12-13 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <78bfd90d47200347628f7dd98451122f@codeaurora.org>
On 13/12/16 15:23, Agustin Vega-Frias wrote:
> On 2016-12-07 13:16, Marc Zyngier wrote:
>> Hi Agustin,
>>
>> On 29/11/16 22:57, Agustin Vega-Frias wrote:
>>> Driver for interrupt combiners in the Top-level Control and Status
>>> Registers (TCSR) hardware block in Qualcomm Technologies chips.
>>>
>>> An interrupt combiner in this block combines a set of interrupts by
>>> OR'ing the individual interrupt signals into a summary interrupt
>>> signal routed to a parent interrupt controller, and provides read-
>>> only, 32-bit registers to query the status of individual interrupts.
>>> The status bit for IRQ n is bit (n % 32) within register (n / 32)
>>> of the given combiner. Thus, each combiner can be described as a set
>>> of register offsets and the number of IRQs managed.
>>>
>>> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
>>> ---
>>> drivers/irqchip/Kconfig | 8 +
>>> drivers/irqchip/Makefile | 1 +
>>> drivers/irqchip/qcom-irq-combiner.c | 337
>>> ++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 346 insertions(+)
>>> create mode 100644 drivers/irqchip/qcom-irq-combiner.c
>>>
>>> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
>>> index bc0af33..610f902 100644
>>> --- a/drivers/irqchip/Kconfig
>>> +++ b/drivers/irqchip/Kconfig
>>> @@ -279,3 +279,11 @@ config EZNPS_GIC
>>> config STM32_EXTI
>>> bool
>>> select IRQ_DOMAIN
>>> +
>>> +config QCOM_IRQ_COMBINER
>>> + bool "QCOM IRQ combiner support"
>>> + depends on ARCH_QCOM
>>> + select IRQ_DOMAIN
>>> + help
>>> + Say yes here to add support for the IRQ combiner devices embedded
>>> + in Qualcomm Technologies chips.
>>> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
>>> index e4dbfc8..1818a0b 100644
>>> --- a/drivers/irqchip/Makefile
>>> +++ b/drivers/irqchip/Makefile
>>> @@ -74,3 +74,4 @@ obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
>>> obj-$(CONFIG_EZNPS_GIC) += irq-eznps.o
>>> obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o
>>> obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
>>> +obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o
>>> diff --git a/drivers/irqchip/qcom-irq-combiner.c
>>> b/drivers/irqchip/qcom-irq-combiner.c
>>> new file mode 100644
>>> index 0000000..fc25251
>>> --- /dev/null
>>> +++ b/drivers/irqchip/qcom-irq-combiner.c
>>> @@ -0,0 +1,337 @@
>>> +/* Copyright (c) 2015-2016, The Linux Foundation. All rights
>>> reserved.
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify
>>> + * it under the terms of the GNU General Public License version 2 and
>>> + * only version 2 as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +/*
>>> + * Driver for interrupt combiners in the Top-level Control and Status
>>> + * Registers (TCSR) hardware block in Qualcomm Technologies chips.
>>> + * An interrupt combiner in this block combines a set of interrupts
>>> by
>>> + * OR'ing the individual interrupt signals into a summary interrupt
>>> + * signal routed to a parent interrupt controller, and provides read-
>>> + * only, 32-bit registers to query the status of individual
>>> interrupts.
>>> + * The status bit for IRQ n is bit (n % 32) within register (n / 32)
>>> + * of the given combiner. Thus, each combiner can be described as a
>>> set
>>> + * of register offsets and the number of IRQs managed.
>>> + */
>>> +
>>> +#include <linux/acpi.h>
>>> +#include <linux/irqchip/chained_irq.h>
>>> +#include <linux/irqdomain.h>
>>> +#include <linux/platform_device.h>
>>> +
>>> +#define REG_SIZE 32
>>> +
>>> +struct combiner_reg {
>>> + void __iomem *addr;
>>> + unsigned long mask;
>>> +};
>>> +
>>> +struct combiner {
>>> + struct irq_chip irq_chip;
>>> + struct irq_domain *domain;
>>> + int parent_irq;
>>> + u32 nirqs;
>>> + u32 nregs;
>>> + struct combiner_reg regs[0];
>>> +};
>>> +
>>> +static inline u32 irq_register(int irq)
>>> +{
>>> + return irq / REG_SIZE;
>>> +}
>>> +
>>> +static inline u32 irq_bit(int irq)
>>> +{
>>> + return irq % REG_SIZE;
>>> +
>>> +}
>>> +
>>> +static inline int irq_nr(u32 reg, u32 bit)
>>> +{
>>> + return reg * REG_SIZE + bit;
>>> +}
>>> +
>>> +/*
>>> + * Handler for the cascaded IRQ.
>>> + */
>>> +static void combiner_handle_irq(struct irq_desc *desc)
>>> +{
>>> + struct combiner *combiner = irq_desc_get_handler_data(desc);
>>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>>> + u32 reg;
>>> +
>>> + chained_irq_enter(chip, desc);
>>> +
>>> + for (reg = 0; reg < combiner->nregs; reg++) {
>>> + int virq;
>>> + int hwirq;
>>> + u32 bit;
>>> + u32 status;
>>> +
>>> + if (combiner->regs[reg].mask == 0)
>>> + continue;
>>> +
>>> + status = readl_relaxed(combiner->regs[reg].addr);
>>> + status &= combiner->regs[reg].mask;
>>> +
>>> + while (status) {
>>> + bit = __ffs(status);
>>> + status &= ~(1 << bit);
>>> + hwirq = irq_nr(reg, bit);
>>> + virq = irq_find_mapping(combiner->domain, hwirq);
>>> + if (virq >= 0)
>>> + generic_handle_irq(virq);
>>> +
>>> + }
>>> + }
>>> +
>>> + chained_irq_exit(chip, desc);
>>> +}
>>> +
>>> +/*
>>> + * irqchip callbacks
>>> + */
>>> +
>>> +static void combiner_irq_chip_mask_irq(struct irq_data *data)
>>> +{
>>> + struct combiner *combiner = irq_data_get_irq_chip_data(data);
>>> + struct combiner_reg *reg = combiner->regs +
>>> irq_register(data->hwirq);
>>> +
>>> + clear_bit(irq_bit(data->hwirq), ®->mask);
>>> +}
>>> +
>>> +static void combiner_irq_chip_unmask_irq(struct irq_data *data)
>>> +{
>>> + struct combiner *combiner = irq_data_get_irq_chip_data(data);
>>> + struct combiner_reg *reg = combiner->regs +
>>> irq_register(data->hwirq);
>>> +
>>> + set_bit(irq_bit(data->hwirq), ®->mask);
>>> +}
>>> +
>>> +/*
>>> + * irq_domain_ops callbacks
>>> + */
>>> +
>>> +static int combiner_irq_map(struct irq_domain *domain, unsigned int
>>> irq,
>>> + irq_hw_number_t hwirq)
>>> +{
>>> + struct combiner *combiner = domain->host_data;
>>> +
>>> + if (hwirq >= combiner->nirqs)
>>> + return -EINVAL;
>>> +
>>> + irq_set_chip_and_handler(irq, &combiner->irq_chip,
>>> handle_level_irq);
>>> + irq_set_chip_data(irq, combiner);
>>> + irq_set_parent(irq, combiner->parent_irq);
>>
>> Do you really need this irq_set_parent? This only makes sense if you're
>> resending edge interrupts, and you seem to be level only.
>
> OK, I'll take a look.
>
>>
>>> + irq_set_noprobe(irq);
>>> + return 0;
>>> +}
>>> +
>>> +static void combiner_irq_unmap(struct irq_domain *domain, unsigned
>>> int irq)
>>> +{
>>> + irq_set_chip_and_handler(irq, NULL, NULL);
>>> + irq_set_chip_data(irq, NULL);
>>> + irq_set_parent(irq, -1);
>>
>> All of this should probably be replaced with a call to
>> irq_domain_reset_irq_data().
>
> Will do.
>
>>
>>> +}
>>> +
>>> +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
>>
>> Is there any case where this is not valid?
>
> What do you mean? Are you asking why is this under a preprocessor
> conditional? If so I did it to be on the safe side since translate
> in struct irq_domain_ops under that conditional.
Since this code can only work when CONFIG_IRQ_DOMAIN_HIERARCHY is
selected, you might as well make the KConfig entry select (or depend on
- I'm always confused about which one should be used when) this
configuration symbol, and make the code more readable.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-12-13 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANc+2y5zegViTsPnuWZwWLUwdRk+ac6upaWOjH7iRFL_zEBxGg@mail.gmail.com>
On Tue, Dec 13, 2016 at 08:53:54PM +0530, PrasannaKumar Muralidharan wrote:
> > What do you think about those two solutions ?
>
> I prefer the second solution's idea of using two files (/dev/hwrng and
> /dev/hwprng). Upon having a quick glance it looks like (based on
> current_rng == prng check) that your current implementation allows
> only one rng device to be in use at a time. It would be better to have
> both usable at the same time. So applications that need pseudo random
> data at high speed can use /dev/prng while applications that require
> true random number can use /dev/rng. Please feel free to correct if my
> understanding of the code is incorrect. Along with this change I think
> changing the algif_rng to use this code if this solution is going to
> be used.
>
No, there could be both device at the same time.
^ permalink raw reply
* [PATCHv4 00/15] clk: ti: add support for hwmod clocks
From: Tony Lindgren @ 2016-12-13 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4b016883-e7c9-94d8-d964-3c8dfee6ee13@ti.com>
* Tero Kristo <t-kristo@ti.com> [161213 00:31]:
> On 13/12/16 06:40, Michael Turquette wrote:
> > Quoting Tony Lindgren (2016-12-12 17:31:34)
> > > * Stephen Boyd <sboyd@codeaurora.org> [161212 16:49]:
> > > > I spent a bunch of time looking at this again today. From a DT
> > > > perspective we don't want to have clocks or clockdomains nodes
> > > > below the cm1/cm2/prm dt nodes. That's getting to the point of
> > > > describing individual elements of a device that should be
> > > > described in the driver instead of DT.
> > >
> > > I agree we don't need separate clocks and clockdomain nodes.. But
> > > I think you're missing something here though. The clockdomains in
> > > this case are separate devices on the interconnect, not individual
> > > elements within a device. The outputs of a clockdomain are individual
> > > elements of a clockdomain and can be just described as indexed
> > > outputs of the clockdomain.
> >
> > Is the goal to describe this hardware topology in DT? Is that right
> > thing to do? I think it's cool to have this modeled *somehow* in Linux,
> > but I'm not sure DT is the right place to model the interconnect and
> > every device hanging off of it.
Well struct device is what we should use, the DT nodes pretty much
map with that :)
> > I don't want to put words in Stephen's mouth, but I think the issue over
> > whether clockdomains are CCF clock providers or some genpd thing is
> > probably less important to him than the fact that the DT bindings are
> > super detailed to inner workings of the SoC.
>
> Ok, so your preference would be to reduce the data under DT, and the ideal
> approach would be a single prcm node. I think we still need to keep the prm
> / cm1 / cm2 as separate nodes, as they are pretty individual from hardware
> point of view, provide quite different features, and they reside in some
> cases in quite different address spaces also. Anyway, here's what I gather
> we should probably have in DT:
>
> - reset provider
> * example: resets = <&prm OMAP4_IVA2_RESET>;
> * only from 'prm' node
>
> - genpd provider (for the hwmods, clockdomains, powerdomains, voltage
> domains)
> * examples: power-domains = <&cm2 OMAP4_DSS_CORE_MOD>;
> power-domains = <&cm2 OMAP4_DSS_CLKDM>;
> power-domains = <&prm OMAP4_DSS_PWRDM>;
> power-domains = <&prm OMAP4_CORE_VOLTDM>;
> * from all 'prm', 'cm1' and 'cm2' nodes, though 'prm' would be the only
> one providing _CLKDM, _PWRDM, _VOLTDM genpds.
>
> - clock provider (for anything that requires clocks)
> * example: clocks = <&cm1 OMAP4_DPLL_MPU_CK>;
> * from all 'prm', 'cm1' and 'cm2' nodes
Makes sense to me in general.
For the clkctrl clocks, here's what I'd like to see. The driver should be
just a regular device driver along the lines we did with the ADPLL as in
Documentation/devicetree/bindings/clock/ti/adpll.txt.
For the binding, something like the following should work as a minimal
example, this follows what we have in the hardware:
&prm {
...
/* See "CD_WKUP Clock Domain" in 4430 TRM page 393 */
wkup_cm: clock at 1800 {
compatible = "ti,clkctrl";
reg = <0x1800 0x100>;
#clock-cells = <1>;
clocks = <&wkup_l4_iclk2 &wkup_32k_fclk
&32k_fclk &gp1_fclk>;
clock-output-names =
"sysctrl_padconf_wkup",
"badgap",
"sysctrl_general_wkup",
"gpio1",
"keyboard",
"sar_ram",
"32ktimer",
"gptimer1";
};
...
/* See "CD_EMU Clock Domain" in 4430 TRM page 424 */
emu_cm: clock at 1a00 {
compatible = "ti,clkctrl";
reg = <0x1a00 0x100>;
#clock-cells = <1>;
clocks = <&emu_sys_clk &core_dpll_emu_clk>;
clock-output-names = "debug";
};
...
};
So the device tree nodes could be minimal as above and the rest can
be taken care of by the driver. We may need separate compatible strings
for the various instances, not sure about that.
Note that the clkctrl hardware manages multiple clocks for each
interconnect target module. AFAIK we don't need to care about that from
the consumer device driver point of view as it can't separately manage
functional and interface clock.
We need few clockctrl clocks early for system timers, but those can
be registered earlier in the driver.
Then some clkctrl clocks have optional aux clocks. I think those can
be just be regular child clocks of the module clocks.
> This would eventually cause an ABI breakage for the clock handles, if we
> transfer the existing clocks to this format, and remove the existing clock
> handles from DT. Otherwise, I think we could just transition the existing
> hwmod data to this new format only, and add the clockdomain / powerdomain /
> voltagedomain support a bit later.
Let's not break anything while doing this.. And let's not mess with the
hwmod except where it helps moving that into regular device drivers.
If necessary we can maybe first register the new clock instances, then
register the old clocks if new clock is not found?
Regards,
Tony
^ permalink raw reply
* [PATCH v9 2/3] mfd: Kconfig: MFD_SUN4I_GPADC depends on !TOUCHSCREN_SUN4I_GPADC
From: Maxime Ripard @ 2016-12-13 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213143332.24988-3-quentin.schulz@free-electrons.com>
On Tue, Dec 13, 2016 at 03:33:31PM +0100, Quentin Schulz wrote:
> MFD_SUN4I_GPADC and TOUCHSCREEN_SUN4I are incompatible (both are drivers
> for Allwinner SoCs' ADC). This makes sure TOUCHSCREEN_SUN4I isn't
> enabled while MFD_SUN4I_GPADC is enabled.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161213/eee851ba/attachment-0001.sig>
^ permalink raw reply
* [PATCH v9 3/3] iio: adc: add support for Allwinner SoCs ADC
From: Maxime Ripard @ 2016-12-13 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213143332.24988-4-quentin.schulz@free-electrons.com>
On Tue, Dec 13, 2016 at 03:33:32PM +0100, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a touchscreen
> controller and a thermal sensor. This patch adds the ADC driver which is
> based on the MFD for the same SoCs ADC.
>
> This also registers the thermal adc channel in the iio map array so
> iio_hwmon could use it without modifying the Device Tree. This registers
> the driver in the thermal framework.
>
> The thermal sensor requires the IP to be in touchscreen mode to return
> correct values. Therefore, if the user is continuously reading the ADC
> channel(s), the thermal framework in which the thermal sensor is
> registered will switch the IP in touchscreen mode to get a temperature
> value and requires a delay of 100ms (because of the mode switching),
> then the ADC will switch back to ADC mode and requires also a delay of
> 100ms. If the ADC readings are critical to user and the SoC temperature
> is not, this driver is capable of not registering the thermal sensor in
> the thermal framework and thus, "quicken" the ADC readings.
>
> This driver probes on three different platform_device_id to take into
> account slight differences (registers bit and temperature computation)
> between Allwinner SoCs ADCs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
I already gave my Acked-by apparently, but I'll say it again :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161213/fc278b98/attachment.sig>
^ permalink raw reply
* [PATCH v9 1/3] ARM: sunxi_defconfig: Add CONFIG_THERMAL_OF
From: Maxime Ripard @ 2016-12-13 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213143332.24988-2-quentin.schulz@free-electrons.com>
On Tue, Dec 13, 2016 at 03:33:30PM +0100, Quentin Schulz wrote:
> This enables CONFIG_THERMAL_OF by default for sunxi_defconfig. It is
> required to get Allwinner SoCs' temperature from the GPADC driver.
>
> The Allwinner SoCs all have an ADC that can also act as a touchscreen
> controller and a thermal sensor. The first four channels can be used
> either for the ADC or the touchscreen and the fifth channel is used for
> the thermal sensor.
>
> The thermal sensor requires the IP to be in touchscreen mode to return
> correct values. Therefore, if the user is continuously reading the ADC
> channel(s), the thermal framework in which the thermal sensor is
> registered will switch the IP in touchscreen mode to get a temperature
> value and requires a delay of 100ms (because of the mode switching),
> then the ADC will switch back to ADC mode and requires also a delay of
> 100ms. If the ADC readings are critical to user and the SoC temperature
> is not, the GPADC driver is capable of not registering the thermal
> sensor in the thermal framework and thus, "quicken" the ADC readings. In
> most use cases, the SoC temperature is more critical (for cpu throttling
> for example or activating cooling devices) than ADC readings, thus it is
> now enabled by default.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161213/cb630690/attachment.sig>
^ permalink raw reply
* [PATCH v6] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Dave Martin @ 2016-12-13 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_9QSkoxYb8=ECn4ar4LXpojtuNgpoLe+0-hA4n-8PhNQ@mail.gmail.com>
On Tue, Dec 13, 2016 at 02:17:14PM +0000, Ard Biesheuvel wrote:
> On 13 December 2016 at 13:49, Dave Martin <Dave.Martin@arm.com> wrote:
> > On Tue, Dec 13, 2016 at 12:35:29PM +0000, Ard Biesheuvel wrote:
> >> Currently, we allow kernel mode NEON in softirq or hardirq context by
> >> stacking and unstacking a slice of the NEON register file for each call
> >> to kernel_neon_begin() and kernel_neon_end(), respectively.
> >>
> >> Given that
> >> a) a CPU typically spends most of its time in userland, during which time
> >> no kernel mode NEON in process context is in progress,
> >> b) a CPU spends most of its time in the kernel doing other things than
> >> kernel mode NEON when it gets interrupted to perform kernel mode NEON
> >> in softirq context
> >>
> >> the stacking and subsequent unstacking is only necessary if we are
> >> interrupting a thread while it is performing kernel mode NEON in process
> >> context, which means that in all other cases, we can simply preserve the
> >> userland FPSIMD state once, and only restore it upon return to userland,
> >> even if we are being invoked from softirq or hardirq context.
> >>
> >> So instead of checking whether we are running in interrupt context, keep
> >> track of the level of nested kernel mode NEON calls in progress, and only
> >> perform the eager stack/unstack if the level exceeds 1.
> >
> > Hang on ... we could be in the middle of fpsimd_save_state() for other
> > reasons, say on the context switch path. Wouldn't we need to take the
> > lock for those too?
> >
>
> Yes. Saving the state should never be interrupted, and now that I
> think of it, this is an issue for your original patch as well: even if
> you always preserve the state first in kernel_neon_begin(), any
> occurrence of fpsimd_save_state() could be interrupted by a
> kernel_neon_begin()/_end() pair, after which the SVE state is nuked
> anyway (regardless of whether a patch like this one is applied) So I
> think we do need the lock in all cases where the FP/SIMD is copied to
> memory and the flag set.
Yes, that's true. I didn't really trust my hack that much yet (for
development I was typically just putting a BUG_ON() on
kernel_neon_begin() to make sure it's not being called...)
> > Also, a spinlock can't protect a critical section from code running on
> > the same CPU... wouldn't it just deadlock in that case?
> >
>
> That is why I use spin_trylock(). But I realise now that the patch is
> incorrect: the nesting level needs to be incremented first, or the
Ah, I missed the significance of that.
> interrupter will still clobber the context while it is being
> preserved.
Hmmm, yes.
> > I still tend to prefer v4 -- there we do a redundant double-save only if
> > one kernel_neon_begin() interrupts the actual task context save.
> >
>
> I think we're not at the bottom of this rabbit hole yet:-)
Seemingly not...
I think it's better to ignore SVE to begin with and focus on what
changes are desirable for the NEON case by itself. That's likely to
give cleaner code which can then be extended for SVE as appropriate.
For SVE, the basic change is that if task state saving isn't finished,
then we need to save (partial) SVE state in a nested
kernel_neon_begin(), not just NEON state. I'm hoping we can detect
this case as TIF_SVE && !TIF_FOREIGN_FPSTATE, if we defer setting
TIF_FOREIGN_FPSTATE until after the task state save is complete ...
unless there's some other reason this won't work.
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/6] clk: sunxi-ng: fix PLL_CPUX adjusting on A33
From: Maxime Ripard @ 2016-12-13 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-2-icenowy@aosc.xyz>
On Tue, Dec 13, 2016 at 11:22:47PM +0800, Icenowy Zheng wrote:
> When adjusting PLL_CPUX on A33, the PLL is temporarily driven too high,
> and the system hangs.
>
> Add a notifier to avoid this situation by temporarily switching to a
> known stable 24 MHz oscillator.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161213/583d3807/attachment.sig>
^ permalink raw reply
* [PATCH 2/6] clk: sunxi-ng: set the parent rate when adjustin CPUX clock on A33
From: Maxime Ripard @ 2016-12-13 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-3-icenowy@aosc.xyz>
On Tue, Dec 13, 2016 at 11:22:48PM +0800, Icenowy Zheng wrote:
> The CPUX clock on A33, which is for the Cortex-A7 cores, is designed to
> be changeable by changing the rate of PLL_CPUX.
>
> Add CLK_SET_RATE_PARENT flag to this clock.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161213/67097aa8/attachment.sig>
^ permalink raw reply
* [PATCH 3/6] ARM: dts: sun8i: add a cpu0 label to cpu@0 node on A23/33
From: Maxime Ripard @ 2016-12-13 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-4-icenowy@aosc.xyz>
On Tue, Dec 13, 2016 at 11:22:49PM +0800, Icenowy Zheng wrote:
> A "cpu0" label is needed on cpu at 0 for cpufreq-dt to work.
>
> Add such a label, in order to prepare for cpufreq support of A23/33.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161213/41eadf1e/attachment-0001.sig>
^ permalink raw reply
* [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings
From: Rob Herring @ 2016-12-13 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213111137.GW3625@dell.home>
On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Mon, 12 Dec 2016, Rob Herring wrote:
>
>> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
>> > Define bindings for pwm-stm32
>> >
>> > version 6:
>> > - change st,breakinput parameter format to make it usuable on stm32f7 too.
>> >
>> > version 2:
>> > - use parameters instead of compatible of handle the hardware configuration
>> >
>> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> > ---
>> > .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
>> > 1 file changed, 33 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> > new file mode 100644
>> > index 0000000..866f222
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> > @@ -0,0 +1,33 @@
>> > +STMicroelectronics STM32 Timers PWM bindings
>> > +
>> > +Must be a sub-node of an STM32 Timers device tree node.
>> > +See ../mfd/stm32-timers.txt for details about the parent node.
>> > +
>> > +Required parameters:
>> > +- compatible: Must be "st,stm32-pwm".
>> > +- pinctrl-names: Set to "default".
>> > +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
>> > + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
>> > +
>> > +Optional parameters:
>> > +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
>> > + "index" indicates on which break input the configuration should be applied.
>> > + "level" gives the active level (0=low or 1=high) for this configuration.
>> > + "filter" gives the filtering value to be applied.
>> > +
>> > +Example:
>> > + timers at 40010000 {
>>
>> timer at ...
>
> No, it should be timers.
Read the spec. "timer" is a generic node name. "timers" is not. How
many is not relevant.
> The 's' is intentional, since this parent (MFD) device houses 3
> different types of timers. The "timer" node is a child of this one.
^ permalink raw reply
* [PATCH 3/6] ARM: dts: sun8i: add a cpu0 label to cpu@0 node on A23/33
From: Sudeep Holla @ 2016-12-13 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-4-icenowy@aosc.xyz>
On 13/12/16 15:22, Icenowy Zheng wrote:
> A "cpu0" label is needed on cpu at 0 for cpufreq-dt to work.
>
IIUC any label should be fine and I don't see anything in the driver
looking for such label name. All I see is it looks for cpu0 regulator
for *legacy* DTs
> Add such a label, in order to prepare for cpufreq support of A23/33.
>
You need this as you add the same label in the following patches. The
commit message sounds like cpufreq-dt search for that label by name.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx
From: Richard Genoud @ 2016-12-13 16:27 UTC (permalink / raw)
To: linux-arm-kernel
If we don't disable the transmitter in atmel_stop_tx, the DMA buffer
continues to send data until it is emptied.
This cause problems with the flow control (CTS is asserted and data are
still sent).
So, disabling the transmitter in atmel_stop_tx is a sane thing to do.
Tested on at91sam9g35-cm(DMA)
Tested for regressions on sama5d2-xplained(Fifo) and at91sam9g20ek(PDC)
Cc: <stable@vger.kernel.org> (beware, this won't apply before 4.3)
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
---
drivers/tty/serial/atmel_serial.c | 11 +++++++++++
1 file changed, 11 insertions(+)
NB: this is not for the 4.10 merge window, I'm just sending it now to
have some comments if someone is againts it.
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 168b10cad47b..f9d42de5ab2d 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -481,6 +481,14 @@ static void atmel_stop_tx(struct uart_port *port)
/* disable PDC transmit */
atmel_uart_writel(port, ATMEL_PDC_PTCR, ATMEL_PDC_TXTDIS);
}
+
+ /*
+ * Disable the transmitter.
+ * This is mandatory when DMA is used, otherwise the DMA buffer
+ * is fully transmitted.
+ */
+ atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXDIS);
+
/* Disable interrupts */
atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
@@ -513,6 +521,9 @@ static void atmel_start_tx(struct uart_port *port)
/* Enable interrupts */
atmel_uart_writel(port, ATMEL_US_IER, atmel_port->tx_done_mask);
+
+ /* re-enable the transmitter */
+ atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN);
}
/*
^ permalink raw reply related
* [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings
From: Benjamin Gaignard @ 2016-12-13 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqL8pJSFb8LbABAYJOQ0URaMpyupbFryk_mS2ToN1kStdA@mail.gmail.com>
2016-12-13 16:57 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> On Mon, 12 Dec 2016, Rob Herring wrote:
>>
>>> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
>>> > Define bindings for pwm-stm32
>>> >
>>> > version 6:
>>> > - change st,breakinput parameter format to make it usuable on stm32f7 too.
>>> >
>>> > version 2:
>>> > - use parameters instead of compatible of handle the hardware configuration
>>> >
>>> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>> > ---
>>> > .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
>>> > 1 file changed, 33 insertions(+)
>>> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>> >
>>> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>> > new file mode 100644
>>> > index 0000000..866f222
>>> > --- /dev/null
>>> > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>> > @@ -0,0 +1,33 @@
>>> > +STMicroelectronics STM32 Timers PWM bindings
>>> > +
>>> > +Must be a sub-node of an STM32 Timers device tree node.
>>> > +See ../mfd/stm32-timers.txt for details about the parent node.
>>> > +
>>> > +Required parameters:
>>> > +- compatible: Must be "st,stm32-pwm".
>>> > +- pinctrl-names: Set to "default".
>>> > +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
>>> > + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
>>> > +
>>> > +Optional parameters:
>>> > +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
>>> > + "index" indicates on which break input the configuration should be applied.
>>> > + "level" gives the active level (0=low or 1=high) for this configuration.
>>> > + "filter" gives the filtering value to be applied.
>>> > +
>>> > +Example:
>>> > + timers at 40010000 {
>>>
>>> timer at ...
>>
>> No, it should be timers.
>
> Read the spec. "timer" is a generic node name. "timers" is not. How
> many is not relevant.
"timer" is already used in stm32 DT for clocksource node... It is also why
I use "timers" for this.
>
>> The 's' is intentional, since this parent (MFD) device houses 3
>> different types of timers. The "timer" node is a child of this one.
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 3/6] ARM: dts: sun8i: add a cpu0 label to cpu@0 node on A23/33
From: Chen-Yu Tsai @ 2016-12-13 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <139af71f-390a-4023-8f82-71dd80212518@arm.com>
On Wed, Dec 14, 2016 at 12:09 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 13/12/16 15:22, Icenowy Zheng wrote:
>> A "cpu0" label is needed on cpu at 0 for cpufreq-dt to work.
>>
>
> IIUC any label should be fine and I don't see anything in the driver
> looking for such label name. All I see is it looks for cpu0 regulator
> for *legacy* DTs
>
>> Add such a label, in order to prepare for cpufreq support of A23/33.
>>
>
> You need this as you add the same label in the following patches. The
> commit message sounds like cpufreq-dt search for that label by name.
I think a more proper explanation would be:
The cpu's supply regulator is specified at the board level, hence we
need to add a label to it to reference it without replicating the whole
tree structure.
ChenYu
^ permalink raw reply
* [linux-sunxi] sunxi-ng clocks: leaving certain clocks alone?
From: Chen-Yu Tsai @ 2016-12-13 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213150813.uq6megq24nmaircc@lukather>
On Tue, Dec 13, 2016 at 11:08 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Mon, Dec 12, 2016 at 12:16:07PM +0000, Andre Przywara wrote:
>> Hi Chen-Yu,
>>
>> thanks for the answer!
>>
>> On 12/12/16 04:41, Chen-Yu Tsai wrote:
>> > On Mon, Dec 12, 2016 at 7:54 AM, Andr? Przywara <andre.przywara@arm.com> wrote:
>> >> Hi,
>> >>
>> >> I was observing that the new sunxi-ng clock code apparently explicitly
>> >> turns off _all_ clocks that are not used or needed. I find this rather
>> >> unfortunate, as I wanted to use the THS temperature sensor from ARM
>> >> Trusted Firmware to implement emergency shutdown or DVFS throttling.
>> >> That works until the clock framework finds the clock (as enumerated in
>> >> ccu-sun50i-a64.c) and obviously explicitly clears bit 31 in the THS mod
>> >> clock register and bit 8 in the respective clock gate register.
>> >> Turning them manually back on via /dev/mem or removing the THS clock
>> >> from the sunxi-ng driver fixes this for me.
>> >>
>> >> This was not happening with the old Allwinner clocks, since the kernel
>> >> wouldn't even know about it if there was no driver and the clock wasn't
>> >> mentioned in the DT.
>> >>
>> >> Now with sunxi-ng even though the THS clock is not actually referenced
>> >> or used in the DT, the kernel turns it off. I would expect that upon
>> >> entering the kernel all unneeded clocks are turned off anyway, so there
>> >> is no need to mess with clocks that have no user, but are enumerated in
>> >> the ccu driver.
>> >
>> > I can't say that's absolutely true (wink).
>> >
>> >>
>> >> I wonder if this kills simplefb as well, for instance, since I believe
>> >> that U-Boot needs to turn on certain clocks and relies on them staying up.
>> >
>> > The simplefb bindings takes clocks and regulators expressly for the
>> > purpose of keeping them enabled.
>>
>> Right, I should have checked this before ...
>>
>> >>
>> >> So my questions:
>> >> 1) Is this expected behaviour?
>> >
>> > Yes.
>> >
>> >> 2) If yes, should it really be?
>> >> 3) If yes, shouldn't there be way to explicitly tell Linux to leave that
>> >> clock alone, preferably via DT? Although the sunxi-ng clocks take
>> >> control over the whole CCU unit, I wonder if it should really mess with
>> >> clocks there are not referenced in the DT.
>> >
>> > As it owns the whole CCU unit, why not? And how would it know if some
>> > clock is referenced or not, unless going through the whole device tree?
>>
>> I was hoping that it just provides clocks to any users (drivers) and
>> wouldn't bother with tinkering with every clock unless explicitly being
>> asked for (by a driver being pointed to a specific clock through DT).
>> So it would need to iterate through anything - neither the whole DT nor
>> it's own list of clocks.
>>
>> > Furthermore, nothing prevents another device driver from referencing
>> > said clock and turning it off when it's not in use. Think THS driver
>> > with runtime PM.
>>
>> I am totally OK with that: Any potential Linux THS driver can take over,
>> if the DT references this device and the clock.
>> My point is that atm there is no such driver and so the clocks framework
>> shouldn't turn that clock off.
>
> You could turn that exact argument the other way though. If there's no
> user in the system, why should we waste power and leave it enabled?
>
>> > Are you also mapping the THS to secure only? Otherwise nothing would
>> > prevent Linux from also claiming it.
>>
>> Unfortunately the THS is always unsecure. And even if it could be
>> switched, after a recent IRC discussion I came to believe that those
>> secure peripherals features only works when the secure boot feature is
>> used, which requires to blow an efuse and thus is not easily doable on
>> most boards and also irreversible.
>> Also I am not sure whether this security feature actually extends to the
>> mod clocks and the bus reset and clock gates bits.
>>
>> But I was relying on that Linux doesn't touch hardware that's not
>> referenced in the DT, so if firmware uses the THS, any Linux THS node
>> would need to go - or the other way around: if there is a Linux THS
>> node, firmware backs off.
>
> It's not just about node though, but also based on the kernel
> configuration. If the kernel didn't have a THS driver compiled (or not
> loaded), then if you want to implement such a behaviour, you should
> also keep the THS driver in the firmware.
>
>> >> Maybe there is some way to reference those clocks via some dummy driver
>> >> or DT node to avoid this behaviour? Is there any prior art in this respect?
>> >
>> > If you want a clock to not be disabled by anyone, adding CLK_IS_CRITICAL
>> > to its flags is the proper option. This is done in the clk driver though.
>>
>> Yes, I was thinking about that, but it indeed sounds like a hack to
>> follow this.
>
> You also have the option to add a clock-critical property.
This is not supported by the clk core though. Rather, the clk core just
provides the helper function of_clk_detect_critical() to set the flag.
We don't support it either. Furthermore, the function's comment says:
Do not use this function. It exists only for legacy Device Tree
bindings, such as the one-clock-per-node style that are outdated.
Those bindings typically put all clock data into .dts and the Linux
driver has no clock data, thus making it impossible to set this flag
correctly from the driver. Only those drivers may call
of_clk_detect_critical from their setup functions.
ChenYu
>
> Keep in mind that just preventing it from shutting down at boot gives
> no warranty that the clock will remain enabled. Other clocks in the
> same sub-tree might do a reparenting or a disable that would lead to
> that clock being modified or disabled too as a side effect.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH 3/6] ARM: dts: sun8i: add a cpu0 label to cpu@0 node on A23/33
From: Sudeep Holla @ 2016-12-13 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65=Sh-WMEVk0Db48sgUcV6d7-wF_Yh0yJAHANMkGUzFwQ@mail.gmail.com>
On 13/12/16 16:31, Chen-Yu Tsai wrote:
> On Wed, Dec 14, 2016 at 12:09 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 13/12/16 15:22, Icenowy Zheng wrote:
>>> A "cpu0" label is needed on cpu at 0 for cpufreq-dt to work.
>>>
>>
>> IIUC any label should be fine and I don't see anything in the driver
>> looking for such label name. All I see is it looks for cpu0 regulator
>> for *legacy* DTs
>>
>>> Add such a label, in order to prepare for cpufreq support of A23/33.
>>>
>>
>> You need this as you add the same label in the following patches. The
>> commit message sounds like cpufreq-dt search for that label by name.
>
> I think a more proper explanation would be:
>
> The cpu's supply regulator is specified at the board level, hence we
> need to add a label to it to reference it without replicating the whole
> tree structure.
Thanks for clarifying, was confused based on the commit log.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot
From: Mark Brown @ 2016-12-13 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209112018.GL3625@dell.home>
On Fri, Dec 09, 2016 at 11:20:18AM +0000, Lee Jones wrote:
> Is the following valid/necessary?
> On Wed, 23 Nov 2016, Chen-Yu Tsai wrote:
> > The AXP806 supports either master/standalone or slave mode.
> > Slave mode allows sharing the serial bus, even with multiple
> > AXP806 which all have the same hardware address.
> > This is done with extra "serial interface address extension",
> > or AXP806_BUS_ADDR_EXT, and "register address extension", or
> > AXP806_REG_ADDR_EXT, registers. The former is read-only, with
> > 1 bit customizable at the factory, and 1 bit depending on the
I don't really know anything about the details of this chip, sorry.
> > This patch sets AXP806_REG_ADDR_EXT to 0x10, which is what we
> > know to be the proper value for a standard AXP806 in slave mode.
> > Afterwards it will reinitialize the regmap cache, to purge any
> > invalid stale values.
If the chip has been reset then you'd want to reset the cache too. I've
no idea if that's needed here or not though, it depends what happens to
the global state of the chip when this reconfiguration happens.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161213/18150a5a/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-13 16:52 UTC (permalink / raw)
To: linux-arm-kernel
Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
(for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
cooling maps to account for new OPPs.
Since new OPPs are not available on all Exynos5422/5800 boards modify
dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
Tested on Odroid-XU3 and XU3 Lite.
Cc: Doug Anderson <dianders@chromium.org>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Ben Gamari <ben@smart-cactus.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
4 files changed, 43 insertions(+), 7 deletions(-)
Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
===================================================================
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
@@ -118,7 +118,7 @@
/*
* When reaching cpu_alert3, reduce CPU
* by 2 steps. On Exynos5422/5800 that would
- * be: 1600 MHz and 1100 MHz.
+ * (usually) be: 1800 MHz and 1200 MHz.
*/
map3 {
trip = <&cpu_alert3>;
@@ -131,16 +131,16 @@
/*
* When reaching cpu_alert4, reduce CPU
- * further, down to 600 MHz (11 steps for big,
- * 7 steps for LITTLE).
+ * further, down to 600 MHz (13 steps for big,
+ * 8 steps for LITTLE).
*/
- map5 {
+ cooling_map5: map5 {
trip = <&cpu_alert4>;
- cooling-device = <&cpu0 3 7>;
+ cooling-device = <&cpu0 3 8>;
};
- map6 {
+ cooling_map6: map6 {
trip = <&cpu_alert4>;
- cooling-device = <&cpu4 3 11>;
+ cooling-device = <&cpu4 3 13>;
};
};
};
Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
===================================================================
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
@@ -21,6 +21,23 @@
compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
};
+&cluster_a15_opp_table {
+ /delete-node/opp at 2000000000;
+ /delete-node/opp at 1900000000;
+};
+
+&cluster_a7_opp_table {
+ /delete-node/opp at 1400000000;
+};
+
+&cooling_map5 {
+ cooling-device = <&cpu0 3 7>;
+};
+
+&cooling_map6 {
+ cooling-device = <&cpu4 3 11>;
+};
+
&pwm {
/*
* PWM 0 -- fan
Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
===================================================================
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
@@ -146,6 +146,10 @@
vdd-supply = <&ldo9_reg>;
};
+&cluster_a7_opp_table {
+ /delete-property/opp at 1400000000;
+};
+
&cpu0 {
cpu-supply = <&buck2_reg>;
};
Index: b/arch/arm/boot/dts/exynos5800.dtsi
===================================================================
--- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
@@ -24,6 +24,16 @@
};
&cluster_a15_opp_table {
+ opp at 2000000000 {
+ opp-hz = /bits/ 64 <2000000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
+ opp at 1900000000 {
+ opp-hz = /bits/ 64 <1900000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
opp at 1700000000 {
opp-microvolt = <1250000>;
};
@@ -85,6 +95,11 @@
};
&cluster_a7_opp_table {
+ opp_a7_14: opp at 1400000000 {
+ opp-hz = /bits/ 64 <1400000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
opp at 1300000000 {
opp-microvolt = <1250000>;
};
^ permalink raw reply
* [PATCH] net: mvpp2: fix dma unmapping of TX buffers for fragments
From: Thomas Petazzoni @ 2016-12-13 16:53 UTC (permalink / raw)
To: linux-arm-kernel
Since commit 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX
buffers unmapping"), we are not correctly DMA unmapping TX buffers for
fragments.
Indeed, the mvpp2_txq_inc_put() function only stores in the
txq_cpu->tx_buffs[] array the physical address of the buffer to be
DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
skb_headlen(skb) to get the size to be unmapped. Both of this works fine
for TX descriptors that are associated directly to a SKB, but not the
ones that are used for fragments, with a NULL pointer as skb:
- We have a NULL physical address when calling DMA unmap
- skb_headlen(skb) crashes because skb is NULL
This causes random crashes when fragments are used.
To solve this problem, this commit:
- Stores the physical address of the buffer to be unmapped
unconditionally, regardless of whether it is tied to a SKB or not.
- Adds a txq_cpu->tx_data_size[] array to store the size of the DMA
buffer to be unmapped upon TX completion.
Fixes: 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
Reported-by: Raphael G <raphael.glon@corp.ovh.com>
Cc: Raphael G <raphael.glon@corp.ovh.com>
Cc: stable at vger.kernel.org
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 1026c45..d168b13 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -791,6 +791,8 @@ struct mvpp2_txq_pcpu {
/* Array of transmitted buffers' physical addresses */
dma_addr_t *tx_buffs;
+ size_t *tx_data_size;
+
/* Index of last TX DMA descriptor that was inserted */
int txq_put_index;
@@ -980,9 +982,10 @@ static void mvpp2_txq_inc_put(struct mvpp2_txq_pcpu *txq_pcpu,
struct mvpp2_tx_desc *tx_desc)
{
txq_pcpu->tx_skb[txq_pcpu->txq_put_index] = skb;
- if (skb)
- txq_pcpu->tx_buffs[txq_pcpu->txq_put_index] =
- tx_desc->buf_phys_addr;
+ txq_pcpu->tx_data_size[txq_pcpu->txq_put_index] =
+ tx_desc->data_size;
+ txq_pcpu->tx_buffs[txq_pcpu->txq_put_index] =
+ tx_desc->buf_phys_addr;
txq_pcpu->txq_put_index++;
if (txq_pcpu->txq_put_index == txq_pcpu->size)
txq_pcpu->txq_put_index = 0;
@@ -4404,11 +4407,13 @@ static void mvpp2_txq_bufs_free(struct mvpp2_port *port,
dma_addr_t buf_phys_addr =
txq_pcpu->tx_buffs[txq_pcpu->txq_get_index];
struct sk_buff *skb = txq_pcpu->tx_skb[txq_pcpu->txq_get_index];
+ size_t data_size =
+ txq_pcpu->tx_data_size[txq_pcpu->txq_get_index];
mvpp2_txq_inc_get(txq_pcpu);
dma_unmap_single(port->dev->dev.parent, buf_phys_addr,
- skb_headlen(skb), DMA_TO_DEVICE);
+ data_size, DMA_TO_DEVICE);
if (!skb)
continue;
dev_kfree_skb_any(skb);
@@ -4662,6 +4667,11 @@ static int mvpp2_txq_init(struct mvpp2_port *port,
if (!txq_pcpu->tx_buffs)
goto error;
+ txq_pcpu->tx_data_size = kmalloc(txq_pcpu->size *
+ sizeof(size_t), GFP_KERNEL);
+ if (!txq_pcpu->tx_data_size)
+ goto error;
+
txq_pcpu->count = 0;
txq_pcpu->reserved_num = 0;
txq_pcpu->txq_put_index = 0;
@@ -4675,6 +4685,7 @@ static int mvpp2_txq_init(struct mvpp2_port *port,
txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
kfree(txq_pcpu->tx_skb);
kfree(txq_pcpu->tx_buffs);
+ kfree(txq_pcpu->tx_data_size);
}
dma_free_coherent(port->dev->dev.parent,
@@ -4695,6 +4706,7 @@ static void mvpp2_txq_deinit(struct mvpp2_port *port,
txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
kfree(txq_pcpu->tx_skb);
kfree(txq_pcpu->tx_buffs);
+ kfree(txq_pcpu->tx_data_size);
}
if (txq->descs)
--
2.7.4
^ permalink raw reply related
* double free issue, mvpp2 driver, armada375 modules
From: Thomas Petazzoni @ 2016-12-13 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57272206.6070703@corp.ovh.com>
Hello,
On Mon, 2 May 2016 11:46:46 +0200, Raphael G wrote:
> enclosed the kernel panic we obtain after boot with a slightly patched
> upstream kernel (4.5.2).
>
> (as well as the patchset applied to the upstream kernel, so that you can
> know which code we are talking about. Too bad we cannot use the upstream
> kernel but we had no choice about this + we're no experts so we rely on
> provided patches, adapted to our bootloader and hardware for this)
>
> Reproduce:
> boot on kernel on an armada375 module, connect to it, launch a top in
> commandline
>
> As seen with Marcin Wojtas, reverting commit
> e864b4c7b184bde36fa6a02bb3190983d2f796f9 fixes this issue.
>
> Reporting upstream so that you can decide what should be done next
Thanks for your report. I have finally submitted a fix for this issue.
You can find it at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473989.html
If you have the time to test it and report back, it would be very
useful.
Thanks a lot!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: add cmpxchg64 helper for ARMv7-M
From: Russell King - ARM Linux @ 2016-12-13 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161210123234.GA5468@salvia>
On Sat, Dec 10, 2016 at 01:32:34PM +0100, Pablo Neira Ayuso wrote:
> Hi Arnd,
>
> On Sat, Dec 10, 2016 at 11:36:34AM +0100, Arnd Bergmann wrote:
> > A change to the netfilter code in net-next introduced the first caller of
> > cmpxchg64 that can get built on ARMv7-M, leading to an error from the
> > assembler that points out the lack of 64-bit atomics on this architecture:
> >
> > /tmp/ccMe7djj.s: Assembler messages:
> > /tmp/ccMe7djj.s:367: Error: selected processor does not support `ldrexd r0,r1,[lr]' in Thumb mode
> > /tmp/ccMe7djj.s:371: Error: selected processor does not support `strexd ip,r2,r3,[lr]' in Thumb mode
> > /tmp/ccMe7djj.s:389: Error: selected processor does not support `ldrexd r8,r9,[r7]' in Thumb mode
> > /tmp/ccMe7djj.s:393: Error: selected processor does not support `strexd lr,r0,r1,[r7]' in Thumb mode
> > scripts/Makefile.build:299: recipe for target 'net/netfilter/nft_counter.o' failed
> >
> > This makes ARMv7-M use the same emulation from asm-generic/cmpxchg-local.h
> > that we use on architectures earlier than ARMv6K, to fix the build. The
> > 32-bit atomics are available on ARMv7-M and we keep using them there.
> > This ARM specific change is probably something we should do regardless
> > of the netfilter code.
> >
> > However, looking at the new nft_counter_reset() function in nft_counter.c,
> > this looks incorrect to me not just on ARMv7-M but also on other
> > architectures, with at least the following possible race:
>
> Right, Eric Dumazet already spotted this problem. I'm preparing a
> patch that doesn't require cmpxchg64(). Will keep you on Cc. Thanks.
Please keep me on the Cc as well so I know what's happening, thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] net: mvpp2: fix dma unmapping of TX buffers for fragments
From: Marcin Wojtas @ 2016-12-13 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481647995-7213-1-git-send-email-thomas.petazzoni@free-electrons.com>
Hi Thomas,
Reviewed-by: Marcin Wojtas <mw@semihalf.com>
Best regards,
Marcin
2016-12-13 17:53 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Since commit 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX
> buffers unmapping"), we are not correctly DMA unmapping TX buffers for
> fragments.
>
> Indeed, the mvpp2_txq_inc_put() function only stores in the
> txq_cpu->tx_buffs[] array the physical address of the buffer to be
> DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
> skb_headlen(skb) to get the size to be unmapped. Both of this works fine
> for TX descriptors that are associated directly to a SKB, but not the
> ones that are used for fragments, with a NULL pointer as skb:
>
> - We have a NULL physical address when calling DMA unmap
> - skb_headlen(skb) crashes because skb is NULL
>
> This causes random crashes when fragments are used.
>
> To solve this problem, this commit:
>
> - Stores the physical address of the buffer to be unmapped
> unconditionally, regardless of whether it is tied to a SKB or not.
>
> - Adds a txq_cpu->tx_data_size[] array to store the size of the DMA
> buffer to be unmapped upon TX completion.
>
> Fixes: 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
> Reported-by: Raphael G <raphael.glon@corp.ovh.com>
> Cc: Raphael G <raphael.glon@corp.ovh.com>
> Cc: stable at vger.kernel.org
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> drivers/net/ethernet/marvell/mvpp2.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
> index 1026c45..d168b13 100644
> --- a/drivers/net/ethernet/marvell/mvpp2.c
> +++ b/drivers/net/ethernet/marvell/mvpp2.c
> @@ -791,6 +791,8 @@ struct mvpp2_txq_pcpu {
> /* Array of transmitted buffers' physical addresses */
> dma_addr_t *tx_buffs;
>
> + size_t *tx_data_size;
> +
> /* Index of last TX DMA descriptor that was inserted */
> int txq_put_index;
>
> @@ -980,9 +982,10 @@ static void mvpp2_txq_inc_put(struct mvpp2_txq_pcpu *txq_pcpu,
> struct mvpp2_tx_desc *tx_desc)
> {
> txq_pcpu->tx_skb[txq_pcpu->txq_put_index] = skb;
> - if (skb)
> - txq_pcpu->tx_buffs[txq_pcpu->txq_put_index] =
> - tx_desc->buf_phys_addr;
> + txq_pcpu->tx_data_size[txq_pcpu->txq_put_index] =
> + tx_desc->data_size;
> + txq_pcpu->tx_buffs[txq_pcpu->txq_put_index] =
> + tx_desc->buf_phys_addr;
> txq_pcpu->txq_put_index++;
> if (txq_pcpu->txq_put_index == txq_pcpu->size)
> txq_pcpu->txq_put_index = 0;
> @@ -4404,11 +4407,13 @@ static void mvpp2_txq_bufs_free(struct mvpp2_port *port,
> dma_addr_t buf_phys_addr =
> txq_pcpu->tx_buffs[txq_pcpu->txq_get_index];
> struct sk_buff *skb = txq_pcpu->tx_skb[txq_pcpu->txq_get_index];
> + size_t data_size =
> + txq_pcpu->tx_data_size[txq_pcpu->txq_get_index];
>
> mvpp2_txq_inc_get(txq_pcpu);
>
> dma_unmap_single(port->dev->dev.parent, buf_phys_addr,
> - skb_headlen(skb), DMA_TO_DEVICE);
> + data_size, DMA_TO_DEVICE);
> if (!skb)
> continue;
> dev_kfree_skb_any(skb);
> @@ -4662,6 +4667,11 @@ static int mvpp2_txq_init(struct mvpp2_port *port,
> if (!txq_pcpu->tx_buffs)
> goto error;
>
> + txq_pcpu->tx_data_size = kmalloc(txq_pcpu->size *
> + sizeof(size_t), GFP_KERNEL);
> + if (!txq_pcpu->tx_data_size)
> + goto error;
> +
> txq_pcpu->count = 0;
> txq_pcpu->reserved_num = 0;
> txq_pcpu->txq_put_index = 0;
> @@ -4675,6 +4685,7 @@ static int mvpp2_txq_init(struct mvpp2_port *port,
> txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
> kfree(txq_pcpu->tx_skb);
> kfree(txq_pcpu->tx_buffs);
> + kfree(txq_pcpu->tx_data_size);
> }
>
> dma_free_coherent(port->dev->dev.parent,
> @@ -4695,6 +4706,7 @@ static void mvpp2_txq_deinit(struct mvpp2_port *port,
> txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
> kfree(txq_pcpu->tx_skb);
> kfree(txq_pcpu->tx_buffs);
> + kfree(txq_pcpu->tx_data_size);
> }
>
> if (txq->descs)
> --
> 2.7.4
>
^ permalink raw reply
* [RFC v3 PATCH 00/25] Allow NOMMU for MULTIPLATFORM
From: Russell King - ARM Linux @ 2016-12-13 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211070104.GB3035@afzalpc>
On Sun, Dec 11, 2016 at 12:31:04PM +0530, Afzal Mohammed wrote:
> And in buildroot,
> couldn't see Cortex R option in menuconfig, and selecting Cortex-A's
> excludes flat binary target & presents only with ELF.
That's something which has changed in the kernel - you can now build
for MMUful platforms, and run flat binaries. See commit d782e426b835
("ARM: 8594/1: enable binfmt_flat on systems with an MMU").
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings
From: Rob Herring @ 2016-12-13 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks6CQsOA0w82yiTaCw04e7gRwNx1mfeHanE3MDjkuX-gjg@mail.gmail.com>
On Tue, Dec 13, 2016 at 10:28 AM, Benjamin Gaignard
<benjamin.gaignard@linaro.org> wrote:
> 2016-12-13 16:57 GMT+01:00 Rob Herring <robh@kernel.org>:
>> On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
>>> On Mon, 12 Dec 2016, Rob Herring wrote:
>>>
>>>> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
>>>> > Define bindings for pwm-stm32
>>>> >
>>>> > version 6:
>>>> > - change st,breakinput parameter format to make it usuable on stm32f7 too.
>>>> >
>>>> > version 2:
>>>> > - use parameters instead of compatible of handle the hardware configuration
>>>> >
>>>> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>> > ---
>>>> > .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
>>>> > 1 file changed, 33 insertions(+)
>>>> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>>> >
>>>> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>>> > new file mode 100644
>>>> > index 0000000..866f222
>>>> > --- /dev/null
>>>> > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>>> > @@ -0,0 +1,33 @@
>>>> > +STMicroelectronics STM32 Timers PWM bindings
>>>> > +
>>>> > +Must be a sub-node of an STM32 Timers device tree node.
>>>> > +See ../mfd/stm32-timers.txt for details about the parent node.
>>>> > +
>>>> > +Required parameters:
>>>> > +- compatible: Must be "st,stm32-pwm".
>>>> > +- pinctrl-names: Set to "default".
>>>> > +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
>>>> > + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
>>>> > +
>>>> > +Optional parameters:
>>>> > +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
>>>> > + "index" indicates on which break input the configuration should be applied.
>>>> > + "level" gives the active level (0=low or 1=high) for this configuration.
>>>> > + "filter" gives the filtering value to be applied.
>>>> > +
>>>> > +Example:
>>>> > + timers at 40010000 {
>>>>
>>>> timer at ...
>>>
>>> No, it should be timers.
>>
>> Read the spec. "timer" is a generic node name. "timers" is not. How
>> many is not relevant.
>
> "timer" is already used in stm32 DT for clocksource node... It is also why
> I use "timers" for this.
That doesn't matter. They are at different levels in the hierarchy.
Rob
^ 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