* [PATCH 1/9] dt-bindings: ti-sysc: Update binding for timers and capabilities
From: Tony Lindgren @ 2017-12-21 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220181051.eoftsww6463hyak3@rob-hp-laptop>
* Rob Herring <robh@kernel.org> [171220 18:13]:
> On Sat, Dec 16, 2017 at 11:22:22AM -0800, Tony Lindgren wrote:
> > I was planning to have "ti,sysc-delay-us" only in the driver, but
> > the same IP needs it set on dm814x while not on omap4 for OTG
> > for example. I could add SoC specific quirks to the driver
> > for that one if you prefer that instead?
>
> No, I don't have a preference.
OK
> > > Are the bits you've defined all of them or there's more?
> >
> > That's it, with this binding I've allocated the data from dts
> > for the tests I've done. So that should allow us to replace the
> > static data to start with as seen with the following command:
> >
> > $ git grep -A10 "struct omap_hwmod_class_sysconfig" \
> > arch/arm/*hwmod*data*.c
> > ...
> >
> > So that's to configure a big pile of different module
> > configurations we currently have as can be seen with:
> >
> > $ git grep "struct omap_hwmod_class_sysconfig" \
> > arch/arm/*hwmod*data*.c | wc -l
> > 194
> >
> > I'm sure there's still few duplicates there though..
>
> Okay, then I guess I'm okay with this.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
OK thanks for the review.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: dts: aspeed-g4: Correct VUART IRQ number
From: Arnd Bergmann @ 2017-12-21 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c68ec45-a0d8-f601-08e3-c21db0b8f925@kaod.org>
On Mon, Dec 18, 2017 at 10:00 AM, C?dric Le Goater <clg@kaod.org> wrote:
> On 12/15/2017 06:33 AM, Joel Stanley wrote:
>> This should have always been 8.
>>
>> Fixes: db4d6d9d80fa ("ARM: dts: aspeed: Correctly order UART nodes")
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>
> Reviewed-by: C?dric Le Goater <clg@kaod.org>
>
>> ---
>> ARM maintainers, please include this fix for 4.15
Applied to fixes, thanks!
Arnd
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Maxime Ripard @ 2017-12-21 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACNAnaE9GiVTXD-TV1xXyBJKtTGKpdA6n0REk6a=qm218EgHbg@mail.gmail.com>
Hi,
On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote:
> On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi Kyle,
> >
> > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91 at ksu.edu wrote:
> >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> >> thermal calibration data, add node to describe it.
> >>
> >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> >> supported in an external driver for FreeBSD.
> >>
> >> Signed-off-by: Kyle Evans <kevans91@ksu.edu>
> >
> > The patch looks fine in itself, but we've had a number of issues with
> > the register layout (and access patterns) in the past, so I'd rather
> > have something that works in Linux too if possible.
>
> I have a patch that I think should make it work fine on Linux [1], but
> I'm afraid I have little to no capability to test it myself and so I
> did not add it as well.
>
> I do know that the rootkey is offset 0x200 into the given space [2],
> as is the case with the H3, and that the readout quirk is not needed.
> I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the
> H3, but I do know that thermal data can be found at 0x34 and 0x38 in
> this space.
Then maybe we should leave it aside until someone takes some time on
the A83t. The good news is that the binding itself looks fine, so as
far as FreeBSD goes, there shouldn't be anything preventing you from
using it I guess.
Chen-Yu, what do you think?
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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171221/7c003c1c/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: defconfig: enable CONFIG_UNIPHIER_EFUSE
From: Arnd Bergmann @ 2017-12-21 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNATznT8Es7gRVKO+xVCp7QLCRDo+gBbaW87cQpLSPSEiVw@mail.gmail.com>
On Mon, Dec 11, 2017 at 5:16 PM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> FW: Arnd and Olof,
>
>
> This patch looks trivial enough.
>
> The reason for not-apply is
> probably because this patch was sent to Catalin and Will
> without Arnd and Olof even CC'ed.
>
>
>
> Arnd, Olof,
> Please consider to apply it.
>
> This one:
> https://patchwork.kernel.org/patch/10084055/
>
Applied to next/soc with your
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Thanks for forwarding it to me.
Arnd
^ permalink raw reply
* [GIT PULL] omap-gpmc changes for v4.16 merge (immutable for mtd)
From: Arnd Bergmann @ 2017-12-21 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b55511ad-6d23-0356-f2d3-8e2b7c6d1ffb@ti.com>
On Mon, Dec 11, 2017 at 3:16 PM, Roger Quadros <rogerq@ti.com> wrote:
> Hi Arnd/Olof,
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://github.com/rogerq/linux.git tags/gpmc-omap-for-v4.16-immutable
>
> for you to fetch changes up to c18a7ac3398d0cef29749f9568666db8321aa4c9:
>
> memory: omap-gpmc: Make 'bank-width' property optional (2017-12-01 15:37:49 +0200)
>
> ----------------------------------------------------------------
> OMAP-GPMC: driver updates for v4.16
> * Error out only if both 'bank-width' and 'gpmc,device-width' DT properties are missing.
Pulled into next/drivers, thanks!
Arnd
^ permalink raw reply
* [PATCH v2] ARM: dts: imx51-babbage: Fix the 26MHz clock modelling
From: Fabio Estevam @ 2017-12-21 15:23 UTC (permalink / raw)
To: linux-arm-kernel
On imx51-babbage there is a 26MHz oscillator that is gated by GPIO3_1.
The output of this clock feeds audio codec clock and USB PHY clocks,
which are gated by GPIO4_26 and GPIO2_1 respectively.
Fix the clock representation by properly using gpio-gate-clock.
The clock nodes can be moved out of the 'clocks' node.
Based on a commit from Lucas Stach for imx51-zii-rdu1 board.
This also fixes the following build warning with W=1:
arch/arm/boot/dts/imx51-babbage.dtb: Warning (unit_address_vs_reg): Node /clocks/codec_clock has a reg or ranges property, but no unit name
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v1:
- Use hyphen rather than underscore in node name, and all
lowercase for node name (Shawn)
arch/arm/boot/dts/imx51-babbage.dts | 67 +++++++++++++++++++++++++++----------
1 file changed, 50 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
index c432de778850..4ac5ab614a7f 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -25,18 +25,41 @@
reg = <0x90000000 0x20000000>;
};
- clocks {
- ckih1 {
- clock-frequency = <22579200>;
- };
+ ckih1 {
+ clock-frequency = <22579200>;
+ };
- clk_26M: codec_clock {
- compatible = "fixed-clock";
- reg=<0>;
- #clock-cells = <0>;
- clock-frequency = <26000000>;
- gpios = <&gpio4 26 GPIO_ACTIVE_LOW>;
- };
+ clk_osc: clk-osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+
+ clk_osc_gate: clk-osc-gate {
+ compatible = "gpio-gate-clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_clk26mhz_osc>;
+ clocks = <&clk_osc>;
+ #clock-cells = <0>;
+ enable-gpios = <&gpio3 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ clk_audio: clk-audio {
+ compatible = "gpio-gate-clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_clk26mhz_audio>;
+ clocks = <&clk_osc_gate>;
+ #clock-cells = <0>;
+ enable-gpios = <&gpio4 26 GPIO_ACTIVE_LOW>;
+ };
+
+ clk_usb: clk-usb {
+ compatible = "gpio-gate-clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_clk26mhz_usb>;
+ clocks = <&clk_osc_gate>;
+ #clock-cells = <0>;
+ enable-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
};
display1: disp1 {
@@ -162,7 +185,7 @@
usbh1phy: usbh1phy at 0 {
compatible = "usb-nop-xceiv";
reg = <0>;
- clocks = <&clks IMX5_CLK_DUMMY>;
+ clocks = <&clk_usb>;
clock-names = "main_clk";
reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
vcc-supply = <&vusb_reg>;
@@ -345,10 +368,8 @@
sgtl5000: codec at a {
compatible = "fsl,sgtl5000";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_clkcodec>;
reg = <0x0a>;
- clocks = <&clk_26M>;
+ clocks = <&clk_audio>;
VDDA-supply = <&vdig_reg>;
VDDIO-supply = <&vvideo_reg>;
};
@@ -441,9 +462,21 @@
>;
};
- pinctrl_clkcodec: clkcodecgrp {
+ pinctrl_clk26mhz_audio: clk26mhzaudiocgrp {
+ fsl,pins = <
+ MX51_PAD_CSPI1_RDY__GPIO4_26 0x85
+ >;
+ };
+
+ pinctrl_clk26mhz_osc: clk26mhzoscgrp {
+ fsl,pins = <
+ MX51_PAD_DI1_PIN12__GPIO3_1 0x85
+ >;
+ };
+
+ pinctrl_clk26mhz_usb: clk26mhzusbgrp {
fsl,pins = <
- MX51_PAD_CSPI1_RDY__GPIO4_26 0x80000000
+ MX51_PAD_EIM_D17__GPIO2_1 0x85
>;
};
--
2.14.1
^ permalink raw reply related
* [PATCH v2] MAINTAINERS: Add self as extended maintainer for a slew of files
From: Arnd Bergmann @ 2017-12-21 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221115638.7850-1-linus.walleij@linaro.org>
On Thu, Dec 21, 2017 at 12:56 PM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> Take over sole maintenance of Nomadik, U300 and Ux500. Since all are
> Device Tree converted and using standard format drivers this is not
> burdensome. Alessandro is not working on this platform any more.
> Let's use one single git tree for all of them and combine the
> MAINTAINERS entries into one.
>
> Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
> Acked-by: Alessandro Rubini <rubini@unipv.it>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Applied to next/soc, thanks!
Arnd
^ permalink raw reply
* [PATCH 1/2] ARM: sun8i: v3s: add EHCI/OHCI0 device nodes
From: Maxime Ripard @ 2017-12-21 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221150537.20304-2-icenowy@aosc.io>
On Thu, Dec 21, 2017 at 11:05:36PM +0800, Icenowy Zheng wrote:
> The USB PHY 0 on V3s SoC can also be routed to a pair of EHCI/OHCI
> controllers.
>
> Add the device nodes for the controllers.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index 443b083c6adc..cc315dc742d2 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -264,6 +264,25 @@
> #phy-cells = <1>;
> };
>
> + ehci0: usb at 01c1a000 {
And you should also drop the leading zero on your two nodes
unit-address.
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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171221/67cbc973/attachment-0001.sig>
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Updates for v4.16
From: Arnd Bergmann @ 2017-12-21 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1512553442.git.horms+renesas@verge.net.au>
On Wed, Dec 6, 2017 at 11:21 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC updates for v4.16.
>
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v4.16
>
> for you to fetch changes up to 90f0d2b344313a8a4c366ef60d0df33008d2be84:
>
> soc: renesas: Identify R-Car M3-W ES1.1 (2017-11-27 11:40:57 +0100)
>
> ----------------------------------------------------------------
> Renesas ARM Based SoC Updates for v4.16
>
> * Identify R-Car M3-W ES1.1
>
> Geert Uytterhoeven says "The Product Register of R-Car M3-W ES1.1
> incorrectly identifies the SoC revision as ES2.0. Add a workaround to
> fix this."
>
> It is my understanding that this is likely to be forwards-compatibile.
>\
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.16
From: Arnd Bergmann @ 2017-12-21 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1512640145.git.horms+renesas@verge.net.au>
On Thu, Dec 7, 2017 at 10:53 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
>
> ----------------------------------------------------------------
> Renesas ARM64 Based SoC DT Updates for v4.16
>
> * Use r8a77970 (V3M) CPG core clock and SYSC power domain macros
>
> These may be used in place of numeric constants now that they
> are present in Linus's tree.
>
> * Add r8a77970 (V3M) Starter Kit board support
>
> This includes basic support to bring up the board with a serial
> console and EtherAVB support
>
> * Add IPMMU nodes and connections to on-chip devices
> on r8a7795 (H3), r8a7796 (M3-W), r8a77970 (V3M) and r8a77995 (D3) SoCs
>
> Simon Horman says "With these patches applied a white list enabled IPMMU
> driver may be used to check silicon revision and then enable IPMMU in the
> known working cases."
>
> * Enable DMA for SCIF2 on r8a77995 (D2) SoC
>
> * Increase the number of GPIO bank 1 ports to 29 on r8a7795 (H3) SoC
>
> This adds support for the GP-1-28 port pin of the r8a7795 (H3) ES2.0 SoC
>
> * Add support for CAN to r8a77995 (D3) SoC
>
> Ulrich Hecht says "This is a by-the-datasheet implementation, with the
> datasheet missing some bits, namely the pin map. I filled in the gaps...
> by deducing the information from pin numbers already in the PFC driver,
> so careful scrutiny is advised."
>
> * Add support for SDHI to r8a77995 (D3) SoC
>
> * Add SoC name to file header of r8a7795 (H3) and r8a7796 (M3-W)
> Salvator-X and Salvator-XS board files
>
> Geert Uytterhoeven says "With the proliferation of Salvator-X and
> Salvator-XS boards carrying different R-Car Gen3 SoCs variants, several
> DTS files ended up having the same file headers.
>
> Add the SoC names to the file headers to avoid confusion."
>
> * Add device note for ROHM BD9571MWV PMIC to
> r8a7795 (H3) and r8a7796 (M3-W) Salvator-X and Salvator-XS boards.
>
> Geert Uytterhoeven says "This was based on the example in the DT binding
> documentation, but using IRQ0 instead of a GPIO interrupt, as that
> matches the schematics, and because INTC-EX is a simpler block."
>
> * Enable USB2.0 channel 0 on r8a77970 (V3M) ULCB Kingfisher board
>
> Vladimir Barinov says "The dedicated USB0_PWEN pin is used to control
> CN13 VBUS source from U43 power supply. MAX3355 can also provide VBUS,
> hence it should be disabled via OTG_OFFVBUSn node coming from gpio
> expander TCA9539. Set MAX3355 enabled using OTG_EXTLPn node to be able
> to read OTG ID of CN13."
>
> * Add support for r8a7795 (M3-W) Salvator-XS board
>
> Geert Uytterhoeven says "This patch series adds support for the version
> of the Salvator-XS development board equipped with an R-Car M3-W SiP.
>
> The DT was based on work for the Salvator-X and -XS boards with M3-W
> resp. H3 SiPs."
>
> * Add watchdog timer support to r8a77970 (V3M) eagle board
>
> Geert Uytterhoven says "This allows to use the watchdog timer to reset
> the board, until PSCI is enhanced to include such functionality."
>
> * Use Use R-Car SDHI Gen3 fallback on r8a7795 (H3) and r8a7796 (M3-W) SoCs
>
> * Set driver type for MMC on r8a7795 (H3) and r8a7796 (M3-W) Salvator-X and
> Salvator-XS boards.
>
> Wolfram Sang says "These boards are known to have eMMC issues with the
> default driver type. Specify a working one."
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH 0/2] Add EHCI/OHCI nodes for V3s and Lichee Pi Zero
From: Maxime Ripard @ 2017-12-21 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221150537.20304-1-icenowy@aosc.io>
On Thu, Dec 21, 2017 at 11:05:35PM +0800, Icenowy Zheng wrote:
> As the PHY dual-route property is added to 4.15-rc, the EHCI/OHCI nodes
> are now necessary.
>
> Please apply these patches to 4.15, Thanks!
There's no reason to have it merged in 4.15. It's not a regression,
so 4.15 should work just as 4.14 worked, right?
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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171221/214d2041/attachment.sig>
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC DT Updates for v4.16
From: Arnd Bergmann @ 2017-12-21 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1512555546.git.horms+renesas@verge.net.au>
On Wed, Dec 6, 2017 at 11:22 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC DT updates for v4.16.
>
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v4.16
>
> for you to fetch changes up to 7f32eddb81ecc06131a643babe2d0f961fbd7f08:
>
> ARM: dts: alt: Convert to named i2c-gpio bindings (2017-12-04 09:34:53 +0100)
>
> ----------------------------------------------------------------
> Renesas ARM Based SoC DT Updates for v4.16
>
> * Convert to named i2c-gpio bindings
>
> Geert Uytterhoeven says "Commits 7d29f509d2cfd807 ("dt-bindings: i2c:
> i2c-gpio: Add support for named gpios") and 05c74778858d7d99 ("i2c: gpio:
> Add support for named gpios in DT") introduced named i2c-gpio DT
> bindings, and deprecated the more error-prone unnamed variant.
>
> This patch series switches all Renesas boards to the new bindings, and
> adds the missing GPIO_OPEN_DRAIN I/O flags, which were implicitly
> assumed before..."
>
> ... Note that after this series is applied, the i2c-gpio buses are no
> longer detected when booting new DTBs on old (v4.14 and older) kernels,
> which should not be an issue. Booting old DTBs on new kernels is not
> affected."
>
> * Update DTS for CMT DT binding rework
>
> Geert Uytterhoeven says "This patch series updates the CMT device nodes
> in the various Renesas DTS files sh_cmt clocksource driver for the recent
> DT binding rework that was merged in v4.14-rc1 and v4.15-rc1..."
>
> * Add SMP support to r8a7794 (R-Car E2) SoC
>
> Sergei Shtylyov says "Add the device tree node for the Advanced Power
> Management Unit (APMU). Use the "enable-method" prop to point out that
> the APMU should be used for the SMP support."
>
> * Correct primary compatible value for eeprom
> on r7s72100 (RZ/A1H) genmai and r8a7791 (R-Car M2-W) koelsh boards
>
> Geert Uytterhoeven says "The Renesas part numbers of the two-wire serial
> interface EEPROMs do not follow the 24Cxx pattern, but the R1EX24xxx
> pattern.
>
> Hence change the primary compatible values to the appropriate variant of
> "renesas,r1ex24xxx", like is already done on Gose.""
>
> * Move cec_clock to root node on r8a7791 (R-Car M2-W) koelsh board
> r8a7791 (R-Car M2-W) koelsh board
>
> * Use R-Car SDHI and Ether Gen1 and 2 fallback compat strings
>
> Use recently posted R-Car SDHI and Ether Gen 1 and 2 fallback
> compat strings in the DT of Renesas ARM based SoCs.
>
> * Add IIC cores to dtsi of r8a7745 (RZ/G1E) SoC
>
> * Rework DT architecture for r8a7745 (RZ/G1E) iW-RainboW-G22D development
> platform and add serial support.
>
> Fabrizio Castro says "... define a new DT architecture for the
> iW-RainboW-G22D SODIMM Development Platform to include the configuration
> with the HDMI daughter board and to define the serial interfaces."
>
> * Add USB function support to
> r8a7745 (RZ/G1E) iW-RainboW-G22D development platform
>
> * Add PCIEC and ttySC3 support to r8a7743 (RZ/G1M) iW-RainboW-G20M-Qseven SoM
>
> * Add VIN support to r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs
>
> * Add CAN and HDMI support to r8a7743 (RZ/G1M) iW-RainboW-G20D-Qseven and
> r8a7745 (RZ/G1E) iW-RainboW-G22D development platforms
Pulled into next/dt, thanks for the detailed description!
Arnd
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Kyle Evans @ 2017-12-21 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221145512.llxvzkcrjpquhczi@flea.lan>
On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Kyle,
>
> On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91 at ksu.edu wrote:
>> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
>> thermal calibration data, add node to describe it.
>>
>> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
>> supported in an external driver for FreeBSD.
>>
>> Signed-off-by: Kyle Evans <kevans91@ksu.edu>
>
> The patch looks fine in itself, but we've had a number of issues with
> the register layout (and access patterns) in the past, so I'd rather
> have something that works in Linux too if possible.
Hello!
I have a patch that I think should make it work fine on Linux [1], but
I'm afraid I have little to no capability to test it myself and so I
did not add it as well.
I do know that the rootkey is offset 0x200 into the given space [2],
as is the case with the H3, and that the readout quirk is not needed.
I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the
H3, but I do know that thermal data can be found at 0x34 and 0x38 in
this space.
[1] https://people.freebsd.org/~kevans/sunxi-sid.diff
[2] https://svnweb.freebsd.org/base/head/sys/arm/allwinner/aw_sid.c?view=markup#l56
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
From: Vladimir Zapolskiy @ 2017-12-21 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513869539-18803-1-git-send-email-vladimir_zapolskiy@mentor.com>
From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Fixes: 253ed045a34d ("arm64: dts: renesas: Extract common ULCB board support")
Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi b/arch/arm64/boot/dts/renesas/ulcb.dtsi
index be91016e0b48..3e7a6b94e9f8 100644
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -145,7 +145,6 @@
&avb {
pinctrl-0 = <&avb_pins>;
pinctrl-names = "default";
- renesas,no-ether-link;
phy-handle = <&phy0>;
status = "okay";
--
2.8.1
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property
From: Vladimir Zapolskiy @ 2017-12-21 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513869539-18803-1-git-send-email-vladimir_zapolskiy@mentor.com>
From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Fixes: d25e8ff0d5aa ("arm64: dts: renesas: Extract common Salvator-X board support")
Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 4e800e933944..c3095bd575d7 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -255,7 +255,6 @@
&avb {
pinctrl-0 = <&avb_pins>;
pinctrl-names = "default";
- renesas,no-ether-link;
phy-handle = <&phy0>;
status = "okay";
--
2.8.1
^ permalink raw reply related
* [PATCH v2 0/2] arm64: dts: renesas: Remove renesas, no-ether-link property
From: Vladimir Zapolskiy @ 2017-12-21 15:18 UTC (permalink / raw)
To: linux-arm-kernel
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the change is also a safety improvement because it
removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Note that DTS files for V3M Starter Kit, Draak and Eagle boards
contain the same property, the files are untouched due to unavailable
schematics to verify if the fix applies to these boards as well.
Changes from v1 to v2:
* per a request from Simon added Fixes tags to both changes,
the specified commits generalize Salvator-X and ULCB dtsi files
and the fixes should be applicable without a conflict, however
similar but virtually different fixes can be spread into Salvator-X
and ULCB board DTS files of older kernel revisions as well.
Bogdan Mirea (2):
arm64: dts: renesas: salvator-x: Remove renesas,no-ether-link property
arm64: dts: renesas: ulcb: Remove renesas,no-ether-link property
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 -
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
2 files changed, 2 deletions(-)
--
2.8.1
^ permalink raw reply
* [PATCH 1/3] ARM: dts: am335x-boneblue: fix wl1835 IRQ pin
From: Tony Lindgren @ 2017-12-21 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219223242.21386-1-robertcnelson@gmail.com>
* Robert Nelson <robertcnelson@gmail.com> [171219 14:35]:
> Use the correct IRQ gpio pin on the BeagleBone Blue to allow the
> wl1835 wireless module to actually work.
Thanks applying all three into omap-for-v4.16/dt.
Tony
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC DT Bindings Updates for v4.16
From: Arnd Bergmann @ 2017-12-21 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1512553735.git.horms+renesas@verge.net.au>
On Wed, Dec 6, 2017 at 11:21 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC DT bindings updates for v4.16.
>
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-bindings-for-v4.16
>
> for you to fetch changes up to eebd0732136fd293c8f15a435978c1c34cd7f32f:
>
> arm64: renesas: document V3MSK board bindings (2017-11-29 09:18:24 +0100)
>
> ----------------------------------------------------------------
> Renesas ARM Based SoC DT Bindings Updates for v4.16
>
> * Document V3MSK board bindings
>
> These are the bindings for the R-Car V3M Starter Kit
>
> * Document M3-W-based Salvator-XS board bingigns
>
> Geert Uytterhoeven says "The Renesas Salvator-XS (Salvator-X 2nd version)
> development board can be equipped with either an R-Car H3 ES2.0 or M3-W
> ES1.x SiP, which are pin-compatible."
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH v2 0/4] arm64: defconfig: enable additional led triggers
From: Arnd Bergmann @ 2017-12-21 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHLCerN4sYpU7PJG7JLhAy644s3jz9KD_myKWfOoOkEResPu-Q@mail.gmail.com>
On Wed, Dec 6, 2017 at 9:57 AM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
> (Adding Arnd)
>
> Now that the merge window rush has abated, can you please apply this
> trivial series?
>
> On Mon, Nov 6, 2017 at 12:38 PM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>> This patchset enables the kernel panic and disk-activity trigger for LEDs
>> and then enables the panic trigger for three 96Boards - DB410c, Hikey and
>> Hikey960.
>>
>> DB410c and Hikey panic behaviour has been tested by triggering a panic
>> through /proc/sysrq-trigger, while Hikey960 is only compile-tested.
I applied all four now, but it would have been easier for me if you had either
sent them to the platform maintainers, or to arm at kernel.org.
Arnd
^ permalink raw reply
* [PATCH 1/2] ARM: sun8i: v3s: add EHCI/OHCI0 device nodes
From: Maxime Ripard @ 2017-12-21 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221150537.20304-2-icenowy@aosc.io>
Hi,
On Thu, Dec 21, 2017 at 11:05:36PM +0800, Icenowy Zheng wrote:
> The USB PHY 0 on V3s SoC can also be routed to a pair of EHCI/OHCI
> controllers.
>
> Add the device nodes for the controllers.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index 443b083c6adc..cc315dc742d2 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -264,6 +264,25 @@
> #phy-cells = <1>;
> };
>
> + ehci0: usb at 01c1a000 {
> + compatible = "allwinner,sun8i-v3s-ehci", "generic-ehci";
> + reg = <0x01c1a000 0x100>;
> + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>;
> + resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
Why are you taking the OHCI clocks and resets in the OHCI node..
> + status = "disabled";
> + };
> +
> + ohci0: usb at 01c1a400 {
> + compatible = "allwinner,sun8i-v3s-ohci", "generic-ohci";
> + reg = <0x01c1a400 0x100>;
> + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>,
> + <&ccu CLK_USB_OHCI0>;
> + resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
... And the EHCI clocks and resets in the OHCI node?
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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171221/96d46b00/attachment.sig>
^ permalink raw reply
* [PATCH 1/8] ARM: dts: dra7: Add vbb-supply to cpu and additional voltages
From: Tony Lindgren @ 2017-12-21 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513697066-27732-2-git-send-email-d-gerlach@ti.com>
* Dave Gerlach <d-gerlach@ti.com> [171219 15:27]:
> Add a vbb-supply phandle to the cpus node and also add an additional
> triplet of voltages for each OPP in the operating-points-v2 table to
> make use of the multi regulator support in the OPP core and provide the
> vbb regulator for use by the ti-opp-supply driver.
Sounds like these depend on the ti-opp-supply being available first?
Regards,
Tony
^ permalink raw reply
* [PATCH 0/7] ARM: dts: dra7: Enable x2 lane mode support
From: Tony Lindgren @ 2017-12-21 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
* Kishon Vijay Abraham I <kishon@ti.com> [171219 01:34]:
> Add properties to enable PCIe x2 lane mode since all dra7
> based SoCs support x2 lane mode.
>
> However only dra76-evm has a slot which can support x2 lane
> cards. Hence only enable x2 lane mode in dra76-evm.
> (am571x-idk can support x2 lane mode but that makes usb port
> not functional so not including the patch to enable
> x2 mode in am571x-idk)
>
> Also included in this series is patch to enable PCIe configs
> (both host and device) in omap2plus_defconfig and
> multi_v7_defconfig
>
> In order to get x2 mode working [1] is required.
>
> However by keeping the older compatible, this series won't
> break functionality if this series is merged before [1]
OK applying into omap-for-v4.16/dt and omap-for-v4.16/defconfig.
Thanks,
Tony
^ permalink raw reply
* [PATCH] ARM: make ARCH_S3C24XX select USE_OF and clean-up boot/dts/Makefile
From: Arnd Bergmann @ 2017-12-21 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1511749163-11057-1-git-send-email-yamada.masahiro@socionext.com>
On Mon, Nov 27, 2017 at 3:19 AM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> ARCH_S3C24XX is a very exceptional platform that some DT files in
> arch/arm/boot/dts/, but does not select USE_OF.
>
> All the other platforms with DT files correctly select USE_OF
> directly or indirectly (Most of them are either ARCH_MULTIPLATFORM
> or ARM_SINGLE_ARMV7M).
>
> With ARCH_S3C24XX fixed, "ifeq ($(CONFIG_OF),y)" in DT Makefile
> can be deleted.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied to next/dt, thanks!
Arnd
^ permalink raw reply
* [RESEND PATCH 4/4] ARM: dts: socfpga: Add generic compatible string for I2C EEPROM
From: Arnd Bergmann @ 2017-12-21 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171124162750.18756-4-javierm@redhat.com>
On Fri, Nov 24, 2017 at 5:27 PM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Applied, thanks!
Arnd
^ permalink raw reply
* [RESEND PATCH 3/4] ARM: dts: lpc18xx: Add generic compatible string for I2C EEPROM
From: Arnd Bergmann @ 2017-12-21 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171124162750.18756-3-javierm@redhat.com>
On Fri, Nov 24, 2017 at 5:27 PM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Applied, thanks
Arnd
^ 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