* [RFC v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Zhangfei Gao @ 2016-11-25 2:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479888476-13138-2-git-send-email-zhangfei.gao@linaro.org>
On Wed, Nov 23, 2016 at 4:07 PM, Zhangfei Gao <zhangfei.gao@linaro.org> wrote:
> Add DT bindings documentation for hi3660 SoC reset controller.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> ---
> .../bindings/reset/hisilicon,hi3660-reset.txt | 51 ++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> new file mode 100644
> index 0000000..250daf2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> @@ -0,0 +1,51 @@
> +Hisilicon System Reset Controller
> +======================================
> +
> +Please also refer to reset.txt in this directory for common reset
> +controller binding usage.
> +
> +The reset controller registers are part of the system-ctl block on
> +hi3660 SoC.
> +
> +Required properties:
> +- compatible: should be
> + "hisilicon,hi3660-reset"
> +- #reset-cells: 1, see below
> +- hisi,rst-syscon: phandle of the reset's syscon.
> +- hisi,reset-bits: Contains the reset control register information
> + Should contain 2 cells for each reset exposed to
> + consumers, defined as:
> + Cell #1 : offset from the syscon register base
> + Cell #2 : bits position of the control register
> +
> +Example:
> + iomcu: iomcu at ffd7e000 {
> + compatible = "hisilicon,hi3660-iomcu", "syscon";
> + reg = <0x0 0xffd7e000 0x0 0x1000>;
> + };
> +
> + iomcu_rst: iomcu_rst_controller {
> + compatible = "hisilicon,hi3660-reset";
> + #reset-cells = <1>;
> + hisi,rst-syscon = <&iomcu>;
> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> + 0x20 0x10 /* 1: i2c1 */
> + 0x20 0x20 /* 2: i2c2 */
> + 0x20 0x8000000>; /* 3: i2c6 */
> + };
> +
> +Specifying reset lines connected to IP modules
> +==============================================
> +example:
> +
> + i2c0: i2c at ..... {
> + ...
> + resets = <&iomcu_rst 0>;
> + ...
> + };
> +
> + i2c1: i2c at ..... {
> + ...
> + resets = <&iomcu_rst 1>;
> + ...
> + };
> --
> 2.7.4
Sorry, missing cc when send-email.
Help take a look.
Thanks
^ permalink raw reply
* RPI3 doesn't boot in ARM64 mode on linux-next
From: Michael Zoran @ 2016-11-25 2:31 UTC (permalink / raw)
To: linux-arm-kernel
Last night I did a build of linux-next and I'm finding that I can no
longer get my RPI 3 to boot in arm64 mode anymore. It seems to be
hanging very early in the boot process.
I know linux-next is going through a very large number of changes now,
so does anybody know if arm64(not just the RPI 3) is just broken in
general at this point? 4.9rc6 is working fine.
I don't have a JTAG debugger, so it's a bit hard for me to debug. I've
actually been looking for a decent cheap JTAG debugger for awhile now,
so if anybody knows of one in the < $300.00 range it might be a good
self Christmas present.
^ permalink raw reply
* [PATCH v4 1/6] arm64: arch_timer: Add device tree binding for hisilicon-161601 erratum
From: Hanjun Guo @ 2016-11-25 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <624c1751-9b66-1d10-78ae-8cb4edea6109@huawei.com>
Hi John,
On 11/24/2016 08:12 PM, John Garry wrote:
> On 21/11/2016 12:49, Ding Tianhong wrote:
>> Ping....
>
> Hi,
>
> was there a cover letter for 0/6? I never saw it.
There isn't a cover letter, do we need to add it and
resend (to make thing clear)?
Thanks
Hanjun
^ permalink raw reply
* [PATCH] SCPI (pre-v1.0): fix reading sensor value
From: Martin Blumenstingl @ 2016-11-25 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCDP4PwXnUux=Wd9XJkNJef7qN3EOZm0Q8sg-B4gXqsjcA@mail.gmail.com>
On Thu, Nov 24, 2016 at 12:15 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> On Thu, Nov 24, 2016 at 11:47 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 24/11/16 00:18, Martin Blumenstingl wrote:
>>>
>>> I observed the following "strange" value when trying to read the SCPI
>>> temperature sensor on my Amlogic GXM S912 device:
>>> $ cat /sys/class/hwmon/hwmon0/temp1_input
>>> 6875990994467160116
>>>
>>> The value reported by the original kernel (Amlogic vendor kernel, after
>>> a reboot obviously) was 53C.
>>> The Amlogic SCPI driver only uses a single 32bit value to read the
>>> sensor value, instead of two. After stripping the upper 32bits from
>>> above value gives "52" as result, which is basically identical to
>>> what the vendor kernel reports.
>>
>>
>> Can you check why the upper 32-bit is not set to 0 ?
>>
>> In scpi_process_cmd, we memset extra rx_buf length by 0 and that should
>> take care. Neil had mentioned that works but now I doubt if firmware
>> returns 8 instead of 4 in the size which is wrong as it supports only
>> 32-bit.
> according to the code "RX Length is not replied by the legacy
> Firmware", so for legacy firmwares the "if (match->rx_len > len)"
> condition will never be true (because both values are always equal).
> in the sensor case we then go and copy 8 byte from mem->payload to
> match->rx_buf, but SCPI firmware only wrote 4 bytes to mem->payload.
> This means we are simply reading 4 byte (hi_val) of uninitialized
> memory - which may be all zeroes if we're lucky - but in my case I got
> "garbage" (I guess it's the second byte from the *previous* command
> which are leaking here).
>
> while writing this I see a second (more generic) approach which might
> work as well:
> scpi_chan does not hold any information about rx_payload/tx_payload
> sizes (these are calculated in scpi_probe but not stored anywhere).
> (for now, let's assume we had the rx_payload_size available)
> we could then go ahead and memset(rx_payload, 0, rx_payload_size) in
> scpi_tx_prepare or scpi_send_message.
> However, I am not sure if that would have any side-effects (for
> example on newer SCPI implementations).
I simply tried implementing this solution and I find it better than
the old one. However, I am still not sure if there are any
side-effects. maybe you can simply review v2 of this series which
implements the described approach (the result is the same as with v1:
temp1_input contains the correct value).
Regards,
Martin
^ permalink raw reply
* [PATCH v2 2/2] firmware: arm_scpi: check the payload length in scpi_send_message
From: Martin Blumenstingl @ 2016-11-25 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125005432.1205-1-martin.blumenstingl@googlemail.com>
This adds a sanity check to ensure we're not writing data beyond the
end of our rx_buf and tx_buf. Currently we are still far from reaching
this limit, so this is a non-critical fix.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/firmware/arm_scpi.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 8c183d8..78ea8c7 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -538,6 +538,11 @@ static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
scpi_info->num_chans;
scpi_chan = scpi_info->channels + chan;
+ if (tx_len > scpi_chan->max_payload_len)
+ return -EINVAL;
+ if (rx_len > scpi_chan->max_payload_len)
+ return -EINVAL;
+
msg = get_scpi_xfer(scpi_chan);
if (!msg)
return -ENOMEM;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 1/2] firmware: arm_scpi: zero RX buffer before requesting data from the mbox
From: Martin Blumenstingl @ 2016-11-25 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125005432.1205-1-martin.blumenstingl@googlemail.com>
The original code was relying on the fact that the SCPI firmware
responds with the same number of bytes (or more, all extra data would be
ignored in that case) as requested.
However, we have some pre-v1.0 SCPI firmwares which are responding with
less data for some commands (sensor_value.hi_val did not exist in the
old implementation). This means that some data from the previous
command's RX buffer was leaked into the current command (as the RX
buffer is re-used for all commands on the same channel). Clearing the
RX buffer before (re-) using it ensures we get a consistent result, even
if the SCPI firmware returns less bytes than requested.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/firmware/arm_scpi.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 70e1323..8c183d8 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -259,6 +259,7 @@ struct scpi_chan {
struct mbox_chan *chan;
void __iomem *tx_payload;
void __iomem *rx_payload;
+ resource_size_t max_payload_len;
struct list_head rx_pending;
struct list_head xfers_list;
struct scpi_xfer *xfers;
@@ -470,6 +471,20 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
if (t->rx_buf) {
if (!(++ch->token))
++ch->token;
+
+ /* clear the RX buffer as it is shared across all commands on
+ * the same channel (to make sure we're not leaking data from
+ * the previous response into the current command if the SCPI
+ * firmware writes less data than requested).
+ * This is especially important for pre-v1.0 SCPI firmwares
+ * where some fields in the responses do not exist (while they
+ * exist but are optional in newer versions). One example for
+ * this problem is sensor_value.hi_val, which would contain
+ * ("leak") the second 4 bytes of the RX buffer from the
+ * previous command.
+ */
+ memset_io(ch->rx_payload, 0, ch->max_payload_len);
+
ADD_SCPI_TOKEN(t->cmd, ch->token);
spin_lock_irqsave(&ch->rx_lock, flags);
list_add_tail(&t->node, &ch->rx_pending);
@@ -921,7 +936,9 @@ static int scpi_probe(struct platform_device *pdev)
ret = -EADDRNOTAVAIL;
goto err;
}
- pchan->tx_payload = pchan->rx_payload + (size >> 1);
+
+ pchan->max_payload_len = size / 2;
+ pchan->tx_payload = pchan->rx_payload + pchan->max_payload_len;
cl->dev = dev;
cl->rx_callback = scpi_handle_remote_msg;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 0/2] SCPI (pre-v1.0): fix reading sensor value
From: Martin Blumenstingl @ 2016-11-25 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124001845.20830-1-martin.blumenstingl@googlemail.com>
I observed the following "strange" value when trying to read the SCPI
temperature sensor on my Amlogic GXM S912 device:
$ cat /sys/class/hwmon/hwmon0/temp1_input
6875990994467160116
The value reported by the original kernel (Amlogic vendor kernel, after
a reboot obviously) was 53C.
The Amlogic SCPI driver only uses a single 32bit value to read the
sensor value, instead of two. After stripping the upper 32bits from
above value gives "52" as result, which is basically identical to
what the vendor kernel reports.
I also compared this with the value shown by u-boot (since there's
less delay between "reboot to u-boot" compared to "reboot from mainline
kernel to vendor kernel") and the temperature reported by u-boot always
matches the lower 32bits of the value from scpi-hwmon temp1_input.
Version 1 of this series introduced a separate function for reading the
sensor value on pre-v1.0 SCPI firmwares. I also tried initializing the
"buf" variable in scpi_sensor_get_value() but this didn't work (because
we request a 64bit payload from the SCPI firmware, but the firmware only
replies with a 32bit payload).
Version 2 is different as it does not require a "legacy implementation"
for scpi_sensor_get_value(). Instead the rx_buf is zeroed out before
reading the buffer from the mailbox. This works fine as well, since the
sensor_value.hi_val field was added after sensor_value.lo_val (meaning
it is backwards compatible, as long as hi_val is all zeroes on
pre-v1.0 SCPI firmwares).
A small benefit we get from this: we are now able to handle all
commands where new fields are introduced at the end of receive buffer
(which might be relevant also for future SCPI implementations - but
this is pure speculation).
I did not remove the memset(buf, 0, len) in scpi_process_cmd() because
I am not sure if there are v1.0 SCPI firmwares out there which respond
that X bytes are available in the rx_buf while it actually writes more
data (X + n where n > 0 bytes) than indicated.
Changes since v1:
- zero out the rx_buf before reading the mbox buffer (see long
description above) instead of introducing a separate legacy command
for reading the sensor value
- added patch 2/2 which validates the payload lengths (so nobody can
read or write data beyond rx_buf or tx_buf). This optional and patch
1/2 can be applied without it
Martin Blumenstingl (2):
firmware: arm_scpi: zero RX buffer before requesting data from the
mbox
firmware: arm_scpi: check the payload length in scpi_send_message
drivers/firmware/arm_scpi.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
--
2.10.2
^ permalink raw reply
* [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Martin Blumenstingl @ 2016-11-25 0:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e6ca0941-e2e3-dd93-d4d3-8fbd76b60e17@gmail.com>
On Thu, Nov 24, 2016 at 7:55 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Le 24/11/2016 ? 09:05, Martin Blumenstingl a ?crit :
>> On Thu, Nov 24, 2016 at 4:56 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
>>> On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
>>>> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
>>>> cycle TX clock delay. This seems to work fine for many boards (for
>>>> example Odroid-C2 or Amlogic's reference boards) but there are some
>>>> others where TX traffic is simply broken.
>>>> There are probably multiple reasons why it's working on some boards
>>>> while it's broken on others:
>>>> - some of Amlogic's reference boards are using a Micrel PHY
>>>> - hardware circuit design
>>>> - maybe more...
>>>>
>>>> This raises a question though:
>>>> Which device is supposed to enable the TX delay when both MAC and PHY
>>>> support it? And should we implement it for each PHY / MAC separately
>>>> or should we think about a more generic solution (currently it's not
>>>> possible to disable the TX delay generated by the RTL8211F PHY via
>>>> devicetree when using phy-mode "rgmii")?
>>>
>>> Actually you can skip the part which activate the Tx-delay on the phy
>>> by setting "phy-mode = "rgmii-id" instead of "rgmii"
>>>
>>> phy->interface will no longer be PHY_INTERFACE_MODE_RGMII
>>> but PHY_INTERFACE_MODE_RGMII_ID.
>> unfortunately this is not true for RTL8211F (I did my previous tests
>> with the same expectation in mind)!
>> the code seems to suggest that TX-delay is disabled whenever mode !=
>> PHY_INTERFACE_MODE_RGMII.
>> BUT: on my device RTL8211F_TX_DELAY is set even before
>> "phy_write(phydev, 0x11, reg);"!
>
> (Adding Sebastian (and Mans, and Andrew) since he raised the same
> question a while ago. I think I now understand a bit better what
> Sebastian was after a couple of weeks ago)
>
>>
>> Based on what I found it seems that rgmii-id, rgmii-txid and
>> rgmii-rxid are supposed to be handled by the PHY.
>
> Correct, the meaning of PHY_INTERFACE_MODE should be from the
> perspective of the PHY device:
>
> - PHY_INTERFACE_MODE_RGMII_TXID means that the PHY is responsible for
> adding a delay when the MAC transmits (TX MAC -> PHY (delay) -> wire)
> - PHY_INTERFACE_MODE_RGMII_RXID means that the PHY is responsible for
> adding a delay when the MAC receives (RX MAC <- (delay) PHY) <- wire)
and PHY_INTERFACE_MODE_RGMII_ID is basically _TXID and _RXID combined
(meaning that the PHY is responsible for the TX and RX delays)
>> That would mean that we have two problems here:
>> 1) drivers/net/phy/realtek.c:rtl8211f_config_init should check for
>> PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID and
>> enable the TX-delay in that case - otherwise explicitly disable it
>
> Agreed.
(on a side-not: it seems that the RTL8211F's TX-delay setting is
either untouched by a hardware reset via GPIO or enabled automatically
during hardware reset via GPIO)
>> 2) dwmac-meson8b.c should only use the configured TX-delay for
>> PHY_INTERFACE_MODE_RGMII
>> @Florian: could you please share your thoughts on this (who handles
>> the TX delay in which case)?
>
> This also seems reasonable to do, provided that the PHY is also properly
> configured not to add delays in both directions, and therefore assumes
> that the MAC does it.
on Amlogic Meson systems (at least on the ARM64 ones) all customer
devices with Gbit ethernet are using the RTL8211F PHY. The only
exception are some development/reference boards from Amlogic
themselves, which seem to be using a Micrel RGMII PHY.
> We have a fairly large problem with how RGMII delays are done in PHYLIB
> and Ethernet MAC drivers (or just in general), where we can't really
> intersect properly what a PHY is supporting (in terms of internal
> delays), and what the MAC supports either. One possible approach could
> be to update PHY drivers a list of PHY_INTERFACE_MODE_* that they
> support (ideally, even with normalized nanosecond delay values), and
> then intersect that with the requested phy_interface_t during
> phy_{attach,connect} time, and feed this back to the MAC with a special
> error code/callback, so we could gracefully try to choose another
> PHY_INTERFACE_MODE_* value that the MAC supports....
>
> A larger problem is that a number of drivers have been deployed, and
> Device Trees, possibly with the meaning of "phy-mode" and
> "phy-connection-type" being from the MAC perspective, and not the PHY
> perspective *sigh*, good luck auditing those.
>
> So from there, here is possibly what we could do
>
> - submit a series of patches that update the PHYLIB documentation (there
> are other things missing here) and make it clear from which entity (PHY
> or MAC) does the delay apply to, document the "intersection" problem here
sounds like a good idea, maybe we should move this to a separate thread (I guess
this is the part which is especially interesting for Sebastian, Mans
and Andrew)?
> - have you document the configured behavior for dwmac-meson8b that we
> just discussed here in v2 of this patch series
I would add something like "...using the phy-modes rgmii-id or
rgmii-txid means that the TX-delay will be added by the PHY, thus no
TX-delay should be configured for the MAC/dwmac-meson8b glue" (I'll
improve this, I just want a quick confirmation that I get your idea
right)
Thanks for the quick and helpful answer Florian!
Regards,
Martin
^ permalink raw reply
* [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3
From: megous at megous.com @ 2016-11-25 0:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Ondrej Jirman <megous@megous.com>
When adjusting PLL_CPUX on H3, the PLL is temporarily driven
too high, and the system becomes unstable (oopses or hangs).
Add a notifier to avoid this situation by temporarily switching
to a known stable 24 MHz oscillator.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Tested-by: Lutz Sammer <johns98@gmx.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 614d47c..cf266c9 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -809,6 +809,13 @@ static const struct sunxi_ccu_desc sun8i_h3_ccu_desc = {
.num_resets = ARRAY_SIZE(sun8i_h3_ccu_resets),
};
+static struct ccu_mux_nb sun8i_h3_cpu_nb = {
+ .common = &cpux_clk.common,
+ .cm = &cpux_clk.mux,
+ .delay_us = 1, /* > 8 clock cycles at 24 MHz */
+ .bypass_index = 1, /* index of 24 MHz oscillator */
+};
+
static void __init sun8i_h3_ccu_setup(struct device_node *node)
{
void __iomem *reg;
@@ -827,6 +834,9 @@ static void __init sun8i_h3_ccu_setup(struct device_node *node)
writel(val | (3 << 16), reg + SUN8I_H3_PLL_AUDIO_REG);
sunxi_ccu_probe(node, reg, &sun8i_h3_ccu_desc);
+
+ ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
+ &sun8i_h3_cpu_nb);
}
CLK_OF_DECLARE(sun8i_h3_ccu, "allwinner,sun8i-h3-ccu",
sun8i_h3_ccu_setup);
--
2.10.2
^ permalink raw reply related
* [PATCH v2] ARM: dts: imx6qdl-nitrogen6x: remove duplicate iomux entry
From: Gary Bisson @ 2016-11-24 23:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124231638.12840-1-gary.bisson@boundarydevices.com>
The NANDF_CS2 pad is also part of the wlan-vmmcgrp iomux group.
Removing is from the usdhc2grp group avoids the following error:
imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_NANDF_CS2 already requested
by regulators:regulator at 4; cannot claim for 2194000.usdhc
imx6q-pinctrl 20e0000.iomuxc: pin-187 (2194000.usdhc) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 187
(MX6Q_PAD_NANDF_CS2) from group usdhc2grp on device 20e0000.iomuxc
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
Hi all,
Changelog v1->v2:
- fix typo in patch title
Regards,
Gary
---
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index e476d01..26d0604 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -533,7 +533,6 @@
MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17071
MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17071
MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17071
- MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x000b0
>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: dts: imx6qdl-ntirogen6x: remove duplicate iomux entry
From: Gary Bisson @ 2016-11-24 23:16 UTC (permalink / raw)
To: linux-arm-kernel
The NANDF_CS2 pad is also part of the wlan-vmmcgrp iomux group.
Removing is from the usdhc2grp group avoids the following error:
imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_NANDF_CS2 already requested
by regulators:regulator at 4; cannot claim for 2194000.usdhc
imx6q-pinctrl 20e0000.iomuxc: pin-187 (2194000.usdhc) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 187
(MX6Q_PAD_NANDF_CS2) from group usdhc2grp on device 20e0000.iomuxc
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index e476d01..26d0604 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -533,7 +533,6 @@
MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17071
MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17071
MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17071
- MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x000b0
>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH] dt-bindings: document how to setup rockchip timers as clocksource
From: Alexander Kochetkov @ 2016-11-24 22:12 UTC (permalink / raw)
To: linux-arm-kernel
The patch describes how to setup rockchip timers in device tree
so they can be used as clocksource.
I'm going to implement this feature.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
.../bindings/timer/rockchip,rk-timer.txt | 35 +++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
index 7bc9691..15f8fed 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
@@ -16,7 +16,18 @@ Required properties:
- clock-names : must include the following entries:
"timer", "pclk"
-Example:
+Note:
+If device tree contain only one timer, than the timer will be intialized
+as clockevent provider. If device tree contain two timers, than first timer
+will be initialized as clockevent provider and second one as clocksource.
+
+If you want to bind specific timer as clockevent (i.e. one from alive subsystem)
+and specific timer as clocksource, you can number the timers in "aliases" node.
+
+If device tree contain only one timer and the timer is named as timer1 in
+"aliases" node, then the timer will be initialized as clocksource.
+
+Example (clockevent only):
timer: timer at ff810000 {
compatible = "rockchip,rk3288-timer";
reg = <0xff810000 0x20>;
@@ -24,3 +35,25 @@ Example:
clocks = <&xin24m>, <&cru PCLK_TIMER>;
clock-names = "timer", "pclk";
};
+
+Example (clockevent and clocksource with explicit numbering):
+ aliases {
+ timer0 = &timer6;
+ timer1 = &timer5;
+ };
+
+ timer5: timer at 20038080 {
+ compatible = "rockchip,rk3188-timer", "rockchip,rk3288-timer";
+ reg = <0x20038080 0x20>;
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TIMER5>, <&cru PCLK_TIMER0>;
+ clock-names = "timer", "pclk";
+ };
+
+ timer6: timer at 200380A0 {
+ compatible = ""rockchip,rk3188-timer", rockchip,rk3288-timer";
+ reg = <0x200380A0 0x20>;
+ interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TIMER6>, <&cru PCLK_TIMER0>;
+ clock-names = "timer", "pclk";
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCH] dt-bindings: clarify compatible field usage for rockchip timers
From: Alexander Kochetkov @ 2016-11-24 22:10 UTC (permalink / raw)
To: linux-arm-kernel
rk3036 dtsi file already use compatible field as
"rockchip,rk3036-timer", "rockchip,rk3288-timer".
The patch clearly shows how that filed should be used on other chips.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
.../bindings/timer/rockchip,rk-timer.txt | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
index a41b184..7bc9691 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
@@ -1,9 +1,15 @@
Rockchip rk timer
Required properties:
-- compatible: shall be one of:
- "rockchip,rk3288-timer" - for rk3066, rk3036, rk3188, rk322x, rk3288, rk3368
- "rockchip,rk3399-timer" - for rk3399
+- compatible: should be:
+ "rockchip,rk3036-timer", "rockchip,rk3288-timer": for Rockchip RK3036
+ "rockchip,rk3066-timer", "rockchip,rk3288-timer": for Rockchip RK3066
+ "rockchip,rk3188-timer", "rockchip,rk3288-timer": for Rockchip RK3188
+ "rockchip,rk322x-timer", "rockchip,rk3288-timer": for Rockchip RK322X
+ (please replace rk322x with exact device name and update this file)
+ "rockchip,rk3288-timer": for Rockchip RK3288
+ "rockchip,rk3368-timer", "rockchip,rk3288-timer": for Rockchip RK3368
+ "rockchip,rk3399-timer": for Rockchip RK3399
- reg: base address of the timer register starting with TIMERS CONTROL register
- interrupts: should contain the interrupts for Timer0
- clocks : must contain an entry for each entry in clock-names
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Stefan Schmidt @ 2016-11-24 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124162955.3887066-1-arnd@arndb.de>
Hello.
On 24.11.2016 17:29, Arnd Bergmann wrote:
> The camera_supply_dummy_device definition is shared between a780 and a910,
> but only provided when the first is enabled and fails to build for a
> configuration with only a910:
>
> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
>
> This moves the definition into its own section.
>
> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-pxa/ezx.c | 56 ++++++++++++++++++++++++++-----------------------
I wonder what we should do with ezx.c.
As far as I know neither Daniel nor Harald or myself are doing anything
with this devices anymore. Besides a basic compile test having an ack or
reviewed by from our side is a bit worthless. :/
I should still have some of these phones around in a box somewhere. If
there is someone with a good motivation and time to take over on this
platform we will find a way to get the person this devices.
Any takers? Robert? I guess you are already overloaded but you might
also have an interest. Worth asking :)
In the case nobody wants to pick up here what would you consider the
bets way forward? I could send a patch removing ezx platform support
from the kernel (basically ezx.c plus build support) or I can send a
patch marking it at least orphan in MAINTAINERS. Let me know what you think.
Daniel, Harald, if one of you is still interested in these and what to
pick up the work again, please speak up now. :)
regards
Stefan Schmidt
^ permalink raw reply
* [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
From: Maxime Ripard @ 2016-11-24 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64taF9x9MDYW+KUEEUUoSx0bF68QNc7uZXQoNrsozMGtg@mail.gmail.com>
On Wed, Nov 23, 2016 at 10:25:57PM +0800, Chen-Yu Tsai wrote:
> >> &r_pio {
> >> @@ -111,6 +148,11 @@
> >> pins = "PL10";
> >> function = "gpio_out";
> >> };
> >> +
> >> + wifi_pwrseq_pin_opi0: wifi_pwrseq_pin at 0 {
> >> + allwinner,pins = "PL7";
> >> + allwinner,function = "gpio_out";
> >
> > And same thing here.
>
> Might we do away with the pinmux for gpio pins tradition?
> Recent patches I've sent all omit them.
Oh, yes, that's true.
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/20161124/836dbe90/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-11-24 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a4393a37-5008-ec76-9886-05f8686dadd5@arm.com>
On Wed, Nov 23, 2016 at 09:23:49AM +0000, Andre Przywara wrote:
> Hi Maxime,
>
> On 23/11/16 07:57, Maxime Ripard wrote:
> > On Tue, Nov 22, 2016 at 12:24:20AM +0800, Icenowy Zheng wrote:
> >> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
> >>
> >> Add a device tree file for it.
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> ---
> >> Changes since v2:
> >> - Use generic pinconf binding instead of legacy allwinner pinctrl binding.
> >> - removed uart3, which is not accessible on Orange Pi Zero.
> >> - Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly include
> >> sun8i-h3.dtsi.
> >> - Removed allwinner,sun8i-h3 compatible.
> >>
> >> arch/arm/boot/dts/Makefile | 1 +
> >> arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 +++++++++++++++++++++++
> >
> > Ditto, h2-plus-orangepi-zero.
> >
> >> 2 files changed, 138 insertions(+)
> >> create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >>
> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> index 802a10d..51a1dd7 100644
> >> --- a/arch/arm/boot/dts/Makefile
> >> +++ b/arch/arm/boot/dts/Makefile
> >> @@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> >> sun8i-a33-sinlinx-sina33.dtb \
> >> sun8i-a83t-allwinner-h8homlet-v2.dtb \
> >> sun8i-a83t-cubietruck-plus.dtb \
> >> + sun8i-h2plus-orangepi-zero.dtb \
> >> sun8i-h3-bananapi-m2-plus.dtb \
> >> sun8i-h3-nanopi-neo.dtb \
> >> sun8i-h3-orangepi-2.dtb \
> >> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >> new file mode 100644
> >> index 0000000..b428e47
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >> @@ -0,0 +1,137 @@
> >> +/*
> >> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
> >> + *
> >> + * Based on sun8i-h3-orangepi-one.dts, which is:
> >> + * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
> >> + *
> >> + * This file is dual-licensed: you can use it either under the terms
> >> + * of the GPL or the X11 license, at your option. Note that this dual
> >> + * licensing only applies to this file, and not this project as a
> >> + * whole.
> >> + *
> >> + * a) This file is free software; you can redistribute it and/or
> >> + * modify it under the terms of the GNU General Public License as
> >> + * published by the Free Software Foundation; either version 2 of the
> >> + * License, or (at your option) any later version.
> >> + *
> >> + * This file 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.
> >> + *
> >> + * Or, alternatively,
> >> + *
> >> + * b) Permission is hereby granted, free of charge, to any person
> >> + * obtaining a copy of this software and associated documentation
> >> + * files (the "Software"), to deal in the Software without
> >> + * restriction, including without limitation the rights to use,
> >> + * copy, modify, merge, publish, distribute, sublicense, and/or
> >> + * sell copies of the Software, and to permit persons to whom the
> >> + * Software is furnished to do so, subject to the following
> >> + * conditions:
> >> + *
> >> + * The above copyright notice and this permission notice shall be
> >> + * included in all copies or substantial portions of the Software.
> >> + *
> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> >> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> >> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> >> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> >> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> >> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> >> + * OTHER DEALINGS IN THE SOFTWARE.
> >> + */
> >> +
> >> +/dts-v1/;
> >> +#include "sun8i-h3.dtsi"
> >> +#include "sunxi-common-regulators.dtsi"
> >> +
> >> +#include <dt-bindings/gpio/gpio.h>
> >> +#include <dt-bindings/input/input.h>
> >> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> >> +
> >> +/ {
> >> + model = "Xunlong Orange Pi Zero";
> >> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
> >> +
> >> + aliases {
> >> + serial0 = &uart0;
> >> + };
> >> +
> >> + chosen {
> >> + stdout-path = "serial0:115200n8";
> >> + };
> >> +
> >> + leds {
> >> + compatible = "gpio-leds";
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
> >> +
> >> + pwr_led {
> >> + label = "orangepi:green:pwr";
> >> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> >> + default-state = "on";
> >> + };
> >> +
> >> + status_led {
> >> + label = "orangepi:red:status";
> >> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
> >> + };
> >> + };
> >> +};
> >> +
> >> +&ehci1 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&mmc0 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
> >> + vmmc-supply = <®_vcc3v3>;
> >> + bus-width = <4>;
> >> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> >> + cd-inverted;
> >> + status = "okay";
> >> +};
> >> +
> >> +&ohci1 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&pio {
> >> + leds_opi0: led_pins at 0 {
> >> + pins = "PA17";
> >> + function = "gpio_out";
> >> + };
> >> +};
> >> +
> >> +&r_pio {
> >> + leds_r_opi0: led_pins at 0 {
> >> + pins = "PL10";
> >> + function = "gpio_out";
> >> + };
> >> +};
> >> +
> >> +&uart0 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&uart0_pins_a>;
> >> + status = "okay";
> >> +};
> >> +
> >> +&uart1 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&uart1_pins>;
> >> + status = "disabled";
> >> +};
> >> +
> >> +&uart2 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&uart2_pins>;
> >> + status = "disabled";
> >> +};
> >
> > I'm not sure you answered me on this one. Are those exposed on the
> > headers? why did you put them as disabled here?
>
> So they are on headers, though you have to solder the actual header pins
> yourself [1]. But also these are the normal pins multiplexed with GPIOs
> and other peripherals, so keeping them disabled is in line with the
> existing policy, if I got this correctly.
>
> I agree that the status="disabled" is redundant, since we have that
> exact line already in the .dtsi. But I saw it in other DTs as well, most
> prominently in the sun8i-h3-orangepi-one.dts.
>
> So I think we should remove the "status=" lines here, dtc will generate
> an identical dtb out of it. But we should keep the uart descriptions in
> to make it easier for users to see which SoC pins are used for these
> pins labeled UART[012] in the board description and schematic. Also all
> it takes to enable those is to overwrite the status property, which can
> easily be done inline (without resizing the dtb).
I'd rather have the status still in the DTS. It's true that it's
redundant, but it's also explicit. A node without any status would
give the impression that it is actually enabled, especially since a
node without a status is going to be probed.
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/20161124/39a986ab/attachment.sig>
^ permalink raw reply
* [RFC PATCH 2/5] dmaengine: allow sun6i-dma for more SoCs
From: Maxime Ripard @ 2016-11-24 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <606230fd-37f6-e1ed-adc3-72f606fa944c@arm.com>
On Thu, Nov 24, 2016 at 11:15:42AM +0000, Andre Przywara wrote:
> On 24/11/16 10:55, Maxime Ripard wrote:
> > On Thu, Nov 24, 2016 at 05:30:45PM +0800, Chen-Yu Tsai wrote:
> >> On Thu, Nov 24, 2016 at 5:16 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> >>> Hi,
> >>>
> >>> On 24/11/16 04:16, Chen-Yu Tsai wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara <andre.przywara@arm.com> wrote:
> >>>>> The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
> >>>>> have arm64 capable cores. Add the generic sunxi config symbol to allow
> >>>>> the driver to be selected by arm64 Kconfigs, which don't feature
> >>>>> SoC specific MACH_xxxx configs.
> >>>>>
> >>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >>>>> ---
> >>>>> drivers/dma/Kconfig | 2 +-
> >>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> >>>>> index af63a6b..003c284 100644
> >>>>> --- a/drivers/dma/Kconfig
> >>>>> +++ b/drivers/dma/Kconfig
> >>>>> @@ -157,7 +157,7 @@ config DMA_SUN4I
> >>>>>
> >>>>> config DMA_SUN6I
> >>>>> tristate "Allwinner A31 SoCs DMA support"
> >>>>> - depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
> >>>>> + depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || ARCH_SUNXI
> >>>>
> >>>> AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
> >>>> (And I don't have to add MACH_SUN9I later :) )
> >>>
> >>> Sure, admittedly it was just a quick hack to get things going.
> >>> Actually I don't know why we had a *depend* on those MACH_s before. I
> >>> think technically it does not depend on a certain SoC (having the
> >>> COMPILE_TEST in there hints on that). So what about:
> >>
> >> It was really because this DMA engine only comes with the later
> >> SoCs. We have dma-sun4i for the older one.
> >
> > Indeed.
> >
> >> But yes, there's no reason why you can't build it for the earlier
> >> SoC. It just doesn't get used.
> >
> > I'm still in favor of keeping the depends on. There's no point of
> > compiling something we know have zero chance of running.
> >
> > (But that would be (ARCH_SUNXI && ARM64))
>
> I am OK with that, just wondering if there is a definition of what
> "depends" really means. My impression what that it's a about code
> dependencies (requires a certain subsystem, for instance), not really if
> it's useful in a particular configuration.
My understanding is that it's a hard dependency that prevents
configuration that make no sense, ie being able to compile a driver
that has no chance of being useful in the system, or a driver missing
its framework of choice.
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/20161124/1a161529/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 2/6] iio: adc: Add support for STM32 ADC core
From: Jonathan Cameron @ 2016-11-24 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3775e118-ec41-8b09-6be3-6bde579f046d@st.com>
On 21/11/16 08:54, Fabrice Gasnier wrote:
> On 11/19/2016 01:17 PM, Jonathan Cameron wrote:
>> On 15/11/16 15:30, Fabrice Gasnier wrote:
>>> Add core driver for STMicroelectronics STM32 ADC (Analog to Digital
>>> Converter). STM32 ADC can be composed of up to 3 ADCs with shared
>>> resources like clock prescaler, common interrupt line and analog
>>> reference voltage.
>>> This core driver basically manages shared resources.
>>>
>>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
>> There is nothing in here that demands selecting a fixed regulator.
>> I've also switched the select regulator over to depends on inline with
>> other drivers in IIO that have a hard dependency on regulators.
>> Other than that which showed up during build tests, looks good to me.
>> Shout if I've broken anything with this change.
>
> Hi Jonathan, All,
>
> First many thanks.
> This is not a big deal. Only thing is: I think patch 4 of this series (on stm32_defconfig) need to be updated
> to accommodate this change. E.g. :
> +CONFIG_REGULATOR=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
>
> Shall I send a new version of this series (all patches), including your changes, with updated defconfig as well ?
> Or only updated patch on defconfig is enough ?
Just update those that haven't already been applied.
Thanks,
Jonathan
>
> Please advise,
> Fabrice
>>
>> Applied to the togreg branch of iio.git and pushed out as testing for
>> the autobuilders to play with it.
>>
>> Thanks,
>>
>> Jonathan
>>> ---
>>> drivers/iio/adc/Kconfig | 13 ++
>>> drivers/iio/adc/Makefile | 1 +
>>> drivers/iio/adc/stm32-adc-core.c | 303 +++++++++++++++++++++++++++++++++++++++
>>> drivers/iio/adc/stm32-adc-core.h | 52 +++++++
>>> 4 files changed, 369 insertions(+)
>>> create mode 100644 drivers/iio/adc/stm32-adc-core.c
>>> create mode 100644 drivers/iio/adc/stm32-adc-core.h
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index 7edcf32..ff30239 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -419,6 +419,19 @@ config ROCKCHIP_SARADC
>>> To compile this driver as a module, choose M here: the
>>> module will be called rockchip_saradc.
>>> +config STM32_ADC_CORE
>>> + tristate "STMicroelectronics STM32 adc core"
>>> + depends on ARCH_STM32 || COMPILE_TEST
>>> + depends on OF
>>> + select REGULATOR
>>> + select REGULATOR_FIXED_VOLTAGE
>>> + help
>>> + Select this option to enable the core driver for STMicroelectronics
>>> + STM32 analog-to-digital converter (ADC).
>>> +
>>> + This driver can also be built as a module. If so, the module
>>> + will be called stm32-adc-core.
>>> +
>>> config STX104
>>> tristate "Apex Embedded Systems STX104 driver"
>>> depends on X86 && ISA_BUS_API
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index 7a40c04..a1e8f44 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -41,6 +41,7 @@ obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>>> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>> obj-$(CONFIG_STX104) += stx104.o
>>> +obj-$(CONFIG_STM32_ADC_CORE) += stm32-adc-core.o
>>> obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>> obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
>>> obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
>>> diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
>>> new file mode 100644
>>> index 0000000..4214b0c
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/stm32-adc-core.c
>>> @@ -0,0 +1,303 @@
>>> +/*
>>> + * This file is part of STM32 ADC driver
>>> + *
>>> + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
>>> + * Author: Fabrice Gasnier <fabrice.gasnier@st.com>.
>>> + *
>>> + * Inspired from: fsl-imx25-tsadc
>>> + *
>>> + * License type: GPLv2
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms of the GNU General Public License 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.
>>> + *
>>> + * You should have received a copy of the GNU General Public License along with
>>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#include <linux/clk.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/irqchip/chained_irq.h>
>>> +#include <linux/irqdesc.h>
>>> +#include <linux/irqdomain.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/regulator/consumer.h>
>>> +#include <linux/slab.h>
>>> +
>>> +#include "stm32-adc-core.h"
>>> +
>>> +/* STM32F4 - common registers for all ADC instances: 1, 2 & 3 */
>>> +#define STM32F4_ADC_CSR (STM32_ADCX_COMN_OFFSET + 0x00)
>>> +#define STM32F4_ADC_CCR (STM32_ADCX_COMN_OFFSET + 0x04)
>>> +
>>> +/* STM32F4_ADC_CSR - bit fields */
>>> +#define STM32F4_EOC3 BIT(17)
>>> +#define STM32F4_EOC2 BIT(9)
>>> +#define STM32F4_EOC1 BIT(1)
>>> +
>>> +/* STM32F4_ADC_CCR - bit fields */
>>> +#define STM32F4_ADC_ADCPRE_SHIFT 16
>>> +#define STM32F4_ADC_ADCPRE_MASK GENMASK(17, 16)
>>> +
>>> +/* STM32 F4 maximum analog clock rate (from datasheet) */
>>> +#define STM32F4_ADC_MAX_CLK_RATE 36000000
>>> +
>>> +/**
>>> + * struct stm32_adc_priv - stm32 ADC core private data
>>> + * @irq: irq for ADC block
>>> + * @domain: irq domain reference
>>> + * @aclk: clock reference for the analog circuitry
>>> + * @vref: regulator reference
>>> + * @common: common data for all ADC instances
>>> + */
>>> +struct stm32_adc_priv {
>>> + int irq;
>>> + struct irq_domain *domain;
>>> + struct clk *aclk;
>>> + struct regulator *vref;
>>> + struct stm32_adc_common common;
>>> +};
>>> +
>>> +static struct stm32_adc_priv *to_stm32_adc_priv(struct stm32_adc_common *com)
>>> +{
>>> + return container_of(com, struct stm32_adc_priv, common);
>>> +}
>>> +
>>> +/* STM32F4 ADC internal common clock prescaler division ratios */
>>> +static int stm32f4_pclk_div[] = {2, 4, 6, 8};
>>> +
>>> +/**
>>> + * stm32f4_adc_clk_sel() - Select stm32f4 ADC common clock prescaler
>>> + * @priv: stm32 ADC core private data
>>> + * Select clock prescaler used for analog conversions, before using ADC.
>>> + */
>>> +static int stm32f4_adc_clk_sel(struct platform_device *pdev,
>>> + struct stm32_adc_priv *priv)
>>> +{
>>> + unsigned long rate;
>>> + u32 val;
>>> + int i;
>>> +
>>> + rate = clk_get_rate(priv->aclk);
>>> + for (i = 0; i < ARRAY_SIZE(stm32f4_pclk_div); i++) {
>>> + if ((rate / stm32f4_pclk_div[i]) <= STM32F4_ADC_MAX_CLK_RATE)
>>> + break;
>>> + }
>>> + if (i >= ARRAY_SIZE(stm32f4_pclk_div))
>>> + return -EINVAL;
>>> +
>>> + val = readl_relaxed(priv->common.base + STM32F4_ADC_CCR);
>>> + val &= ~STM32F4_ADC_ADCPRE_MASK;
>>> + val |= i << STM32F4_ADC_ADCPRE_SHIFT;
>>> + writel_relaxed(val, priv->common.base + STM32F4_ADC_CCR);
>>> +
>>> + dev_dbg(&pdev->dev, "Using analog clock source at %ld kHz\n",
>>> + rate / (stm32f4_pclk_div[i] * 1000));
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/* ADC common interrupt for all instances */
>>> +static void stm32_adc_irq_handler(struct irq_desc *desc)
>>> +{
>>> + struct stm32_adc_priv *priv = irq_desc_get_handler_data(desc);
>>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>>> + u32 status;
>>> +
>>> + chained_irq_enter(chip, desc);
>>> + status = readl_relaxed(priv->common.base + STM32F4_ADC_CSR);
>>> +
>>> + if (status & STM32F4_EOC1)
>>> + generic_handle_irq(irq_find_mapping(priv->domain, 0));
>>> +
>>> + if (status & STM32F4_EOC2)
>>> + generic_handle_irq(irq_find_mapping(priv->domain, 1));
>>> +
>>> + if (status & STM32F4_EOC3)
>>> + generic_handle_irq(irq_find_mapping(priv->domain, 2));
>>> +
>>> + chained_irq_exit(chip, desc);
>>> +};
>>> +
>>> +static int stm32_adc_domain_map(struct irq_domain *d, unsigned int irq,
>>> + irq_hw_number_t hwirq)
>>> +{
>>> + irq_set_chip_data(irq, d->host_data);
>>> + irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_level_irq);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void stm32_adc_domain_unmap(struct irq_domain *d, unsigned int irq)
>>> +{
>>> + irq_set_chip_and_handler(irq, NULL, NULL);
>>> + irq_set_chip_data(irq, NULL);
>>> +}
>>> +
>>> +static const struct irq_domain_ops stm32_adc_domain_ops = {
>>> + .map = stm32_adc_domain_map,
>>> + .unmap = stm32_adc_domain_unmap,
>>> + .xlate = irq_domain_xlate_onecell,
>>> +};
>>> +
>>> +static int stm32_adc_irq_probe(struct platform_device *pdev,
>>> + struct stm32_adc_priv *priv)
>>> +{
>>> + struct device_node *np = pdev->dev.of_node;
>>> +
>>> + priv->irq = platform_get_irq(pdev, 0);
>>> + if (priv->irq < 0) {
>>> + dev_err(&pdev->dev, "failed to get irq\n");
>>> + return priv->irq;
>>> + }
>>> +
>>> + priv->domain = irq_domain_add_simple(np, STM32_ADC_MAX_ADCS, 0,
>>> + &stm32_adc_domain_ops,
>>> + priv);
>>> + if (!priv->domain) {
>>> + dev_err(&pdev->dev, "Failed to add irq domain\n");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + irq_set_chained_handler(priv->irq, stm32_adc_irq_handler);
>>> + irq_set_handler_data(priv->irq, priv);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void stm32_adc_irq_remove(struct platform_device *pdev,
>>> + struct stm32_adc_priv *priv)
>>> +{
>>> + int hwirq;
>>> +
>>> + for (hwirq = 0; hwirq < STM32_ADC_MAX_ADCS; hwirq++)
>>> + irq_dispose_mapping(irq_find_mapping(priv->domain, hwirq));
>>> + irq_domain_remove(priv->domain);
>>> + irq_set_chained_handler(priv->irq, NULL);
>>> +}
>>> +
>>> +static int stm32_adc_probe(struct platform_device *pdev)
>>> +{
>>> + struct stm32_adc_priv *priv;
>>> + struct device_node *np = pdev->dev.of_node;
>>> + struct resource *res;
>>> + int ret;
>>> +
>>> + if (!pdev->dev.of_node)
>>> + return -ENODEV;
>>> +
>>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>>> + if (!priv)
>>> + return -ENOMEM;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + priv->common.base = devm_ioremap_resource(&pdev->dev, res);
>>> + if (IS_ERR(priv->common.base))
>>> + return PTR_ERR(priv->common.base);
>>> +
>>> + priv->vref = devm_regulator_get(&pdev->dev, "vref");
>>> + if (IS_ERR(priv->vref)) {
>>> + ret = PTR_ERR(priv->vref);
>>> + dev_err(&pdev->dev, "vref get failed, %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + ret = regulator_enable(priv->vref);
>>> + if (ret < 0) {
>>> + dev_err(&pdev->dev, "vref enable failed\n");
>>> + return ret;
>>> + }
>>> +
>>> + ret = regulator_get_voltage(priv->vref);
>>> + if (ret < 0) {
>>> + dev_err(&pdev->dev, "vref get voltage failed, %d\n", ret);
>>> + goto err_regulator_disable;
>>> + }
>>> + priv->common.vref_mv = ret / 1000;
>>> + dev_dbg(&pdev->dev, "vref+=%dmV\n", priv->common.vref_mv);
>>> +
>>> + priv->aclk = devm_clk_get(&pdev->dev, "adc");
>>> + if (IS_ERR(priv->aclk)) {
>>> + ret = PTR_ERR(priv->aclk);
>>> + dev_err(&pdev->dev, "Can't get 'adc' clock\n");
>>> + goto err_regulator_disable;
>>> + }
>>> +
>>> + ret = clk_prepare_enable(priv->aclk);
>>> + if (ret < 0) {
>>> + dev_err(&pdev->dev, "adc clk enable failed\n");
>>> + goto err_regulator_disable;
>>> + }
>>> +
>>> + ret = stm32f4_adc_clk_sel(pdev, priv);
>>> + if (ret < 0) {
>>> + dev_err(&pdev->dev, "adc clk selection failed\n");
>>> + goto err_clk_disable;
>>> + }
>>> +
>>> + ret = stm32_adc_irq_probe(pdev, priv);
>>> + if (ret < 0)
>>> + goto err_clk_disable;
>>> +
>>> + platform_set_drvdata(pdev, &priv->common);
>>> +
>>> + ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
>>> + if (ret < 0) {
>>> + dev_err(&pdev->dev, "failed to populate DT children\n");
>>> + goto err_irq_remove;
>>> + }
>>> +
>>> + return 0;
>>> +
>>> +err_irq_remove:
>>> + stm32_adc_irq_remove(pdev, priv);
>>> +
>>> +err_clk_disable:
>>> + clk_disable_unprepare(priv->aclk);
>>> +
>>> +err_regulator_disable:
>>> + regulator_disable(priv->vref);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int stm32_adc_remove(struct platform_device *pdev)
>>> +{
>>> + struct stm32_adc_common *common = platform_get_drvdata(pdev);
>>> + struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
>>> +
>>> + of_platform_depopulate(&pdev->dev);
>>> + stm32_adc_irq_remove(pdev, priv);
>>> + clk_disable_unprepare(priv->aclk);
>>> + regulator_disable(priv->vref);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static const struct of_device_id stm32_adc_of_match[] = {
>>> + { .compatible = "st,stm32f4-adc-core" },
>>> + {},
>>> +};
>>> +MODULE_DEVICE_TABLE(of, stm32_adc_of_match);
>>> +
>>> +static struct platform_driver stm32_adc_driver = {
>>> + .probe = stm32_adc_probe,
>>> + .remove = stm32_adc_remove,
>>> + .driver = {
>>> + .name = "stm32-adc-core",
>>> + .of_match_table = stm32_adc_of_match,
>>> + },
>>> +};
>>> +module_platform_driver(stm32_adc_driver);
>>> +
>>> +MODULE_AUTHOR("Fabrice Gasnier <fabrice.gasnier@st.com>");
>>> +MODULE_DESCRIPTION("STMicroelectronics STM32 ADC core driver");
>>> +MODULE_LICENSE("GPL v2");
>>> +MODULE_ALIAS("platform:stm32-adc-core");
>>> diff --git a/drivers/iio/adc/stm32-adc-core.h b/drivers/iio/adc/stm32-adc-core.h
>>> new file mode 100644
>>> index 0000000..081fa5f
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/stm32-adc-core.h
>>> @@ -0,0 +1,52 @@
>>> +/*
>>> + * This file is part of STM32 ADC driver
>>> + *
>>> + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
>>> + * Author: Fabrice Gasnier <fabrice.gasnier@st.com>.
>>> + *
>>> + * License type: GPLv2
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms of the GNU General Public License 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.
>>> + *
>>> + * You should have received a copy of the GNU General Public License along with
>>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#ifndef __STM32_ADC_H
>>> +#define __STM32_ADC_H
>>> +
>>> +/*
>>> + * STM32 - ADC global register map
>>> + * ________________________________________________________
>>> + * | Offset | Register |
>>> + * --------------------------------------------------------
>>> + * | 0x000 | Master ADC1 |
>>> + * --------------------------------------------------------
>>> + * | 0x100 | Slave ADC2 |
>>> + * --------------------------------------------------------
>>> + * | 0x200 | Slave ADC3 |
>>> + * --------------------------------------------------------
>>> + * | 0x300 | Master & Slave common regs |
>>> + * --------------------------------------------------------
>>> + */
>>> +#define STM32_ADC_MAX_ADCS 3
>>> +#define STM32_ADCX_COMN_OFFSET 0x300
>>> +
>>> +/**
>>> + * struct stm32_adc_common - stm32 ADC driver common data (for all instances)
>>> + * @base: control registers base cpu addr
>>> + * @vref_mv: vref voltage (mv)
>>> + */
>>> +struct stm32_adc_common {
>>> + void __iomem *base;
>>> + int vref_mv;
>>> +};
>>> +
>>> +#endif
>>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH renesas-next 3/3] ARM: dts: sh73a0: Use SoC-specific compat string for mmcif
From: Simon Horman @ 2016-11-24 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480018514-31718-1-git-send-email-horms+renesas@verge.net.au>
Use the SoC-specific compat string for mmcif in DT for the sh73a0 SoC.
This is in keeping with the use of compat strings for mmcif for other
Renesas ARM based SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/sh73a0.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index e1267590b575..6b01ab354e88 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -263,7 +263,7 @@
};
mmcif: mmc at e6bd0000 {
- compatible = "renesas,sh-mmcif";
+ compatible = "renesas,mmcif-sh73a0", "renesas,sh-mmcif";
reg = <0xe6bd0000 0x100>;
interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH renesas-next 2/3] ARM: dts: r8a7778: Use SoC-specific compat string for mmcif
From: Simon Horman @ 2016-11-24 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480018514-31718-1-git-send-email-horms+renesas@verge.net.au>
Use the SoC-specific compat string for mmcif in DT for the r8a7778 SoC.
This is in keeping with the use of compat strings for mmcif for other
Renesas ARM based SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7778.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index f3ffe1d31544..1e59eda8e66e 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -369,7 +369,7 @@
};
mmcif: mmc at ffe4e000 {
- compatible = "renesas,sh-mmcif";
+ compatible = "renesas,mmcif-r8a7778", "renesas,sh-mmcif";
reg = <0xffe4e000 0x100>;
interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7778_CLK_MMC>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH renesas-next 1/3] ARM: dts: r8a73a4: Use SoC-specific compat string for mmcif
From: Simon Horman @ 2016-11-24 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480018514-31718-1-git-send-email-horms+renesas@verge.net.au>
Use the SoC-specific compat string for mmcif in DT for the r8a73a4 SoC.
This is in keeping with the use of compat strings for mmcif for other
Renesas ARM based SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a73a4.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 53183ffe04c1..b138584b8800 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -440,7 +440,7 @@
};
mmcif0: mmc at ee200000 {
- compatible = "renesas,sh-mmcif";
+ compatible = "renesas,mmcif-r8a73a4", "renesas,sh-mmcif";
reg = <0 0xee200000 0 0x80>;
interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A73A4_CLK_MMCIF0>;
@@ -450,7 +450,7 @@
};
mmcif1: mmc at ee220000 {
- compatible = "renesas,sh-mmcif";
+ compatible = "renesas,mmcif-r8a73a4", "renesas,sh-mmcif";
reg = <0 0xee220000 0 0x80>;
interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A73A4_CLK_MMCIF1>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH renesas-next 0/3] ARM: dts: shmobile: Use SoC-specific compat string for mmcif
From: Simon Horman @ 2016-11-24 20:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this short series makes add of SoC-specific compat strings to the DT of
the r8a73a4, r8a7778 and sh73a0 SoCs. This is in keeping with the
rest of the Renesas ARM based SoCs with mmcif enabled in mainline.
Based on renesas-devel-20161123v2-v4.9-rc6
Documentation of these compat strings for the mmcif driver has been posted
separately as:
"[PATCH] mmc: sh_mmcif: Document r8a73a4, r8a7779 and sh73a0 DT bindings".
Simon Horman (3):
ARM: dts: r8a73a4: Use SoC-specific compat string for mmcif
ARM: dts: r8a7778: Use SoC-specific compat string for mmcif
ARM: dts: sh73a0: Use SoC-specific compat string for mmcif
arch/arm/boot/dts/r8a73a4.dtsi | 4 ++--
arch/arm/boot/dts/r8a7778.dtsi | 2 +-
arch/arm/boot/dts/sh73a0.dtsi | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Enable UEXT related nodes for Olimex A20 SOM EVB
From: Emmanuel Vadot @ 2016-11-24 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123181610.cae67ad53f5f69246d341b30@bidouilliste.com>
On Wed, 23 Nov 2016 18:16:10 +0100
Emmanuel Vadot <manu@bidouilliste.com> wrote:
> On Wed, 23 Nov 2016 09:03:50 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > On Mon, Nov 21, 2016 at 05:49:11PM +0100, Emmanuel Vadot wrote:
> > > UEXT are Universal EXTension connector from Olimex. They embed i2c, spi
> > > and uart pins along power in one connector and are found on most,
> > > if not all, Olimex boards.
> > > The Olimex A20 SOM EVB have two UEXT connector so enable the nodes found on
> > > those two connectors.
> > >
> > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> >
> > Fixed the indentation of the spi pinctrl cells, and applied.
> >
> > Please note that I'm note planning to send any new pull request, so
> > this will likely end up in 4.11.
> >
> > Thanks!
> > Maxime
> >
> > --
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
>
> Sorry about the indentation, I'll be more carefull next time.
>
> Thank you.
>
> --
> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
>
Hi Maxime,
Re-reading the patch I've seen that I've not enabled the SPI nodes, I
guess it's easier if you revert my patch and that I send a new one ?
Cheers,
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Emmanuel Vadot @ 2016-11-24 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124195517.qrq7briu3pwjnp4n@lukather>
On Thu, 24 Nov 2016 20:55:17 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> > The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> > others three only have 1.
> > Add the num-cs property to each node.
> >
> > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
>
> I don't think we have any code that uses it at the moment. What is the
> rationale behind this patch?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Hi Maxime,
If num-cs isn't present nothing prevent to start a transfer with a
non-valid CS pin, resulting in an error.
num-cs are default property especially made for this and a SPI driver
should try to get the property at probe/attach time.
Cheers,
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [PATCH] ARM: dts: sun6i: hummingbird: Enable USB OTG
From: Maxime Ripard @ 2016-11-24 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124112908.4796-1-wens@csie.org>
On Thu, Nov 24, 2016 at 07:29:08PM +0800, Chen-Yu Tsai wrote:
> The A31 Hummingbird has a mini USB OTG port, and uses GPIO pins from the
> SoC for ID pin and VBUS detection and VBUS control. The PMIC can also do
> VBUS detection and control.
>
> Here we prefer to use the PMIC's DRIVEVBUS function to control VBUS for
> USB OTG, as that is the hardware default.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
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/20161124/fb996ac4/attachment.sig>
^ 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