* [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
* [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 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 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
* [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: 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
* [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] 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 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 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: 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 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 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 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 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 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 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
* [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 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
* [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: PrasannaKumar Muralidharan @ 2016-12-13 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213141059.GB10647@Red>
> 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.
Regards,
PrasannaKumar
^ permalink raw reply
* [PATCH V8 3/3] irqchip: qcom: Add IRQ combiner driver
From: Agustin Vega-Frias @ 2016-12-13 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b009635d-8a10-5e22-4438-0019d79d01d3@arm.com>
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.
>
>> +static int combiner_irq_translate(struct irq_domain *d, struct
>> irq_fwspec *fws,
>> + unsigned long *hwirq, unsigned int *type)
>> +{
>> + if (is_acpi_node(fws->fwnode)) {
>> + if (fws->param_count != 2)
>> + return -EINVAL;
>> +
>> + *hwirq = fws->param[0];
>> + *type = fws->param[1];
>
> Given that you're only handling level interrupts, shouldn't you abort
> if
> detecting an edge interrupt?
I'll add the check.
>
>> + return 0;
>> + }
>> +
>> + return -EINVAL;
>> +}
>> +#endif
>> +
>> +static const struct irq_domain_ops domain_ops = {
>> + .map = combiner_irq_map,
>> + .unmap = combiner_irq_unmap,
>> +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
>> + .translate = combiner_irq_translate
>> +#endif
>> +};
>> +
>> +/*
>> + * Device probing
>> + */
>> +
>> +#ifdef CONFIG_ACPI
>> +
>> +static acpi_status count_registers_cb(struct acpi_resource *ares,
>> void *context)
>> +{
>> + int *count = context;
>> +
>> + if (ares->type == ACPI_RESOURCE_TYPE_GENERIC_REGISTER)
>> + ++(*count);
>> + return AE_OK;
>> +}
>> +
>> +static int count_registers(struct platform_device *pdev)
>> +{
>> + struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
>> + acpi_status status;
>> + int count = 0;
>> +
>> + if (!acpi_has_method(adev->handle, METHOD_NAME__CRS))
>> + return -EINVAL;
>> +
>> + status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
>> + count_registers_cb, &count);
>> + if (ACPI_FAILURE(status))
>> + return -EINVAL;
>> + return count;
>> +}
>> +
>> +struct get_registers_context {
>> + struct device *dev;
>> + struct combiner *combiner;
>> + int err;
>> +};
>> +
>> +static acpi_status get_registers_cb(struct acpi_resource *ares, void
>> *context)
>> +{
>> + struct get_registers_context *ctx = context;
>> + struct acpi_resource_generic_register *reg;
>> + phys_addr_t paddr;
>> + void __iomem *vaddr;
>> +
>> + if (ares->type != ACPI_RESOURCE_TYPE_GENERIC_REGISTER)
>> + return AE_OK;
>> +
>> + reg = &ares->data.generic_reg;
>> + paddr = reg->address;
>> + if ((reg->space_id != ACPI_SPACE_MEM) ||
>> + (reg->bit_offset != 0) ||
>> + (reg->bit_width > REG_SIZE)) {
>> + dev_err(ctx->dev, "Bad register resource @%pa\n", &paddr);
>> + ctx->err = -EINVAL;
>> + return AE_ERROR;
>> + }
>> +
>> + vaddr = devm_ioremap(ctx->dev, reg->address, REG_SIZE);
>> + if (IS_ERR(vaddr)) {
>> + dev_err(ctx->dev, "Can't map register @%pa\n", &paddr);
>> + ctx->err = PTR_ERR(vaddr);
>> + return AE_ERROR;
>> + }
>> +
>> + ctx->combiner->regs[ctx->combiner->nregs].addr = vaddr;
>> + ctx->combiner->nirqs += reg->bit_width;
>> + ctx->combiner->nregs++;
>> + return AE_OK;
>> +}
>> +
>> +static int get_registers(struct platform_device *pdev, struct
>> combiner *comb)
>> +{
>> + struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
>> + acpi_status status;
>> + struct get_registers_context ctx;
>> +
>> + if (!acpi_has_method(adev->handle, METHOD_NAME__CRS))
>> + return -EINVAL;
>> +
>> + ctx.dev = &pdev->dev;
>> + ctx.combiner = comb;
>> + ctx.err = 0;
>> +
>> + status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
>> + get_registers_cb, &ctx);
>> + if (ACPI_FAILURE(status))
>> + return ctx.err;
>> + return 0;
>> +}
>> +
>> +#else /* !CONFIG_ACPI */
>> +
>> +static int count_registers(struct platform_device *pdev)
>> +{
>> + return -EINVAL;
>> +}
>> +
>> +static int get_registers(struct platform_device *pdev, struct
>> combiner *comb)
>> +{
>> + return -EINVAL;
>> +}
>
> So this driver is obviously ACPI only. Can't you just get rid of these,
> of the #ifdef CONFIG_ACPI, and simply make it depend on ACPI?
Good point, will do.
>
>> +
>> +#endif
>> +
>> +static int __init combiner_probe(struct platform_device *pdev)
>> +{
>> + struct combiner *combiner;
>> + size_t alloc_sz;
>> + u32 nregs;
>> + int err;
>> +
>> + nregs = count_registers(pdev);
>> + if (nregs <= 0) {
>> + dev_err(&pdev->dev, "Error reading register resources\n");
>> + return -EINVAL;
>> + }
>> +
>> + alloc_sz = sizeof(*combiner) + sizeof(struct combiner_reg) * nregs;
>> + combiner = devm_kzalloc(&pdev->dev, alloc_sz, GFP_KERNEL);
>> + if (!combiner)
>> + return -ENOMEM;
>> +
>> + err = get_registers(pdev, combiner);
>> + if (err < 0)
>> + return err;
>> +
>> + combiner->parent_irq = platform_get_irq(pdev, 0);
>> + if (combiner->parent_irq <= 0) {
>> + dev_err(&pdev->dev, "Error getting IRQ resource\n");
>> + return -EINVAL;
>
> Can you ever get in a situation where it'd be more sensible to return
> -EPROBE_DEFER? I'm thinking of a case where you'd have this irq chip
> cascaded into another one, which is not present yet?
Not in the current architecture, but I agree it would accommodate other
use cases. I will change it to return -EPROBE_DEFER.
>
>> + }
>> +
>> + combiner->domain = irq_domain_create_linear(
>> + pdev->dev.fwnode, combiner->nirqs, &domain_ops, combiner);
>
> On a single line, please. Do no listen to the checkpatch police that
> will tell you otherwise. It really hurt my eyes to see this opening
> bracket and *nothing* after that.
Will do.
>
>> + if (!combiner->domain)
>> + /* Errors printed by irq_domain_create_linear */
>> + return -ENODEV;
>> +
>> + irq_set_chained_handler_and_data(combiner->parent_irq,
>> + combiner_handle_irq, combiner);
>> + combiner->irq_chip.irq_mask = combiner_irq_chip_mask_irq;
>> + combiner->irq_chip.irq_unmask = combiner_irq_chip_unmask_irq;
>> + combiner->irq_chip.name = pdev->name;
>
> Arghh. Please don't do that. Once you've called irq_set_chained_*, the
> interrupt is live, and can be requested. Unlikely, but still. In
> general, feeding uninitialized data to a function is pretty bad.
>
> Also, do you really need to show pdev->name in /proc/cpuinfo? Just make
> the irq_chip structure static, outside of combiner, and have "QCOM80B1"
> (or something of your liking) as the name once and for all.
I'll look at this.
Thanks for the detailed feedback.
Agustin.
>
>> +
>> + dev_info(&pdev->dev, "Initialized with [p=%d,n=%d,r=%p]\n",
>> + combiner->parent_irq, combiner->nirqs, combiner->regs[0].addr);
>> + return 0;
>> +}
>> +
>> +static const struct acpi_device_id qcom_irq_combiner_acpi_match[] = {
>> + { "QCOM80B1", },
>> + { }
>> +};
>> +
>> +static struct platform_driver qcom_irq_combiner_probe = {
>> + .driver = {
>> + .name = "qcom-irq-combiner",
>> + .owner = THIS_MODULE,
>> + .acpi_match_table = ACPI_PTR(qcom_irq_combiner_acpi_match),
>> + },
>> + .probe = combiner_probe,
>> +};
>> +
>> +static int __init register_qcom_irq_combiner(void)
>> +{
>> + return platform_driver_register(&qcom_irq_combiner_probe);
>> +}
>> +device_initcall(register_qcom_irq_combiner);
>>
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 6/6] ARM: dts: sun8i: raise the max voltage of DCDC2 in sun8i reference tablets
From: Icenowy Zheng @ 2016-12-13 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-1-icenowy@aosc.xyz>
The "extremity_freq" frequency described in the original FEX files uses
a voltage of 1.46v, which is beyond the current maximum voltage value of
DCDC2 (Cortex-A7 supply) in the sun8i reference tablet DTSI file.
Raise the maximum value to 1.46v.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
index 7ac8bb4bc95a..325ca5bd67a5 100644
--- a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
@@ -180,7 +180,7 @@
®_dcdc2 {
regulator-always-on;
regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <1400000>;
+ regulator-max-microvolt = <1460000>;
regulator-name = "vdd-sys";
};
--
2.11.0
^ permalink raw reply related
* [PATCH 5/6] ARM: dts: sun8i: set cpu-supply in reference tablet DTSI
From: Icenowy Zheng @ 2016-12-13 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-1-icenowy@aosc.xyz>
All reference design A33 tablets uses DCDC2 of AXP223 as the power
supply of the Cortex-A7 cores.
Set the cpu-supply in the DTSI of sun8i reference tablets.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
index 08cd00143635..7ac8bb4bc95a 100644
--- a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
@@ -213,6 +213,10 @@
regulator-name = "vcc-rtc";
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&r_uart {
pinctrl-names = "default";
pinctrl-0 = <&r_uart_pins_a>;
--
2.11.0
^ permalink raw reply related
* [PATCH 4/6] ARM: dts: sun8i: add opp-v2 table for A33
From: Icenowy Zheng @ 2016-12-13 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-1-icenowy@aosc.xyz>
An operating point table is needed for the cpu frequency adjusting to
work.
The operating point table is converted from the common value in
extracted script.fex from many A33 board/tablets.
1.344GHz is set as a turbo-mode operating point, as it's described as
"extremity_freq" in the FEX file. (the "max_freq" is 1.2GHz)
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-a33.dtsi | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 504996cbee29..035c058324b8 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -46,7 +46,45 @@
#include <dt-bindings/dma/sun4i-a10.h>
/ {
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 648000000 {
+ opp-hz = /bits/ 64 <648000000>;
+ opp-microvolt = <1040000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+ opp at 816000000 {
+ opp-hz = /bits/ 64 <816000000>;
+ opp-microvolt = <1100000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+ opp at 1008000000 {
+ opp-hz = /bits/ 64 <1008000000>;
+ opp-microvolt = <1200000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+ opp at 1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt = <1320000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+ opp at 1344000000 {
+ opp-hz = /bits/ 64 <1344000000>;
+ opp-microvolt = <1460000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ turbo-mode;
+ };
+ };
+
cpus {
+ cpu0: cpu at 0 {
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
+ operating-points-v2 = <&cpu0_opp_table>;
+ };
+
cpu at 2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox