* [PATCH -next] arm64: Kconfig: remove SMP dependence for NUMA
From: Kefeng Wang @ 2016-09-27 3:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474875410-23016-1-git-send-email-wangkefeng.wang@huawei.com>
The arm64 forces CONFIG_SMP=y with commit 4b3dc9679cf7, no need to
add SMP dependence for NUMA.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
arch/arm64/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4572f00..17c14a1d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -579,7 +579,6 @@ config HOTPLUG_CPU
# Common NUMA Features
config NUMA
bool "Numa Memory Allocation and Scheduler Support"
- depends on SMP
select ACPI_NUMA if ACPI
select OF_NUMA
help
--
1.7.12.4
^ permalink raw reply related
* [PATCH] ARM: dts: lpc32xx: add pwm-cells to base dts file
From: Vladimir Zapolskiy @ 2016-09-26 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474915641-11209-1-git-send-email-slemieux.tyco@gmail.com>
Hi Sylvain,
On 26.09.2016 21:47, Sylvain Lemieux wrote:
> From: Sylvain Lemieux <slemieux@tycoint.com>
>
> There is no need to define the "pwm-cells" in the board
> specific dts file; move the entry to the base dts file.
>
> Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
> ---
> Note:
> * This patch should be apply after
> "ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2"
> http://www.spinics.net/lists/arm-kernel/msg530277.html
> - There is no dependency between the patches.
>
> arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
> index 218d9fa..c031c94 100644
> --- a/arch/arm/boot/dts/lpc32xx.dtsi
> +++ b/arch/arm/boot/dts/lpc32xx.dtsi
> @@ -472,6 +472,7 @@
> assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
> assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
> status = "disabled";
> + #pwm-cells = <2>;
> };
>
> pwm2: pwm at 4005C004 {
> @@ -481,6 +482,7 @@
> assigned-clocks = <&clk LPC32XX_CLK_PWM2>;
> assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
> status = "disabled";
> + #pwm-cells = <2>;
> };
>
> timer3: timer at 40060000 {
>
that's something I have done locally and in a different manner, but I haven't
published it yet, please find below a draft.
First of all from multiple places in the User's Manual you can find that there
are "two single output PWM blocks" or "the LPC32x0 provides two 8-bit PWMs" etc.
In this case it does not make sense to set PWM cells to 2 (there is only one
channel), and 1 cell for frequency is good enough, and that's the proposed
change to support it:
diff --git a/drivers/pwm/pwm-lpc32xx.c b/drivers/pwm/pwm-lpc32xx.c
index a9b3cff..447ae44 100644
--- a/drivers/pwm/pwm-lpc32xx.c
+++ b/drivers/pwm/pwm-lpc32xx.c
@@ -99,6 +99,22 @@ static const struct pwm_ops lpc32xx_pwm_ops = {
.owner = THIS_MODULE,
};
+static struct pwm_device *lpc32xx_pwm_of_xlate(struct pwm_chip *pc,
+ const struct of_phandle_args *args)
+{
+ struct pwm_device *pwm;
+
+ pwm = pwm_request_from_chip(pc, 0, NULL);
+ if (IS_ERR(pwm))
+ return pwm;
+
+ pwm->args.period = args->args[0];
+
+ return pwm;
+}
+
static int lpc32xx_pwm_probe(struct platform_device *pdev)
{
struct lpc32xx_pwm_chip *lpc32xx;
@@ -123,6 +139,8 @@ static int lpc32xx_pwm_probe(struct platform_device *pdev)
lpc32xx->chip.ops = &lpc32xx_pwm_ops;
lpc32xx->chip.npwm = 1;
lpc32xx->chip.base = -1;
+ lpc32xx->chip.of_xlate = lpc32xx_pwm_of_xlate;
+ lpc32xx->chip.of_pwm_n_cells = 1;
ret = pwmchip_add(&lpc32xx->chip);
if (ret < 0) {
What is your opinion about this proposal?
If this change is applied, then lpc32xx.dtsi should contain #pwm-cells = <1>.
--
With best wishes,
Vladimir
^ permalink raw reply related
* [PATCH 4/4] ARM: sa11x0/pxa: get rid of get_clock_tick_rate
From: Russell King - ARM Linux @ 2016-09-26 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-5-git-send-email-robert.jarzmik@free.fr>
On Mon, Sep 19, 2016 at 09:12:15PM +0200, Robert Jarzmik wrote:
> The last user of this function is gone, so remove it. The clock API
> should now be used to get clock rates.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 3/4] watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
From: Russell King - ARM Linux @ 2016-09-26 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-4-git-send-email-robert.jarzmik@free.fr>
On Mon, Sep 19, 2016 at 09:12:14PM +0200, Robert Jarzmik wrote:
> The OS timer rate used for the watchdog can now be fetched from the
> standard clock API. This will remove the last user of
> get_clock_tick_rate() in both pxa and sa11x0 architectures.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 2/4] ARM: sa11x0/pxa: acquire timer rate from the clock rate
From: Russell King - ARM Linux @ 2016-09-26 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-3-git-send-email-robert.jarzmik@free.fr>
On Mon, Sep 19, 2016 at 09:12:13PM +0200, Robert Jarzmik wrote:
> As both pxa and sa1100 provide a clock to the timer, the rate can be
> inferred from the clock rather than hard encoded in a functional call.
>
> This patch changes the pxa timer to have a mandatory clock which is used
> as the timer rate.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] soc: rockchip: power-domain: Don't (incorrectly) set rk3399 up/down counts
From: Heiko Stuebner @ 2016-09-26 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1471546561-4459-1-git-send-email-dianders@chromium.org>
Am Donnerstag, 18. August 2016, 11:56:01 CEST schrieb Douglas Anderson:
> On rk3288 it was important that powerdown and powerup counts for the
> CPU/GPU in the kernel because:
> * The power on default was crazy long.
> * We couldn't rely on the firmware to set this up because really this
> wasn't the firmware's job--the kernel was the only one that really
> cared about bringing up / down CPUs and the GPU and doing suspend /
> resume (which involves bringing up / down CPUs).
>
> On newer ARM systems (like rk3399) ARM Trusted Firmware is in charge of
> bringing up and down the CPUs and it really should be in charge of
> setting all these counts right. After all ATF is in charge of suspend /
> resume and CPU up / down. Let's get out of the way and let ATF do its
> job.
>
> A few other motivations for doing this:
> * Depending on another configuration (PMU_24M_EN_CFG) these counts can
> be either in 24M or 32k cycles. Thus, though ATF isn't really so
> involved in bringing up the GPU, ATF should probably manage the counts
> for everything so it can also manage the 24M / 32k choice.
> * It turns out that (right now) 24M mode is broken on rk3399 and not
> being used. That means that the count the kernel was programming
> in (24) was not 1 us (which it seems was intended) but was actually
> .75 ms
> * On rk3399 there are actually 2 separate registers for setting CPU
> up/down time plus 1 register for GPU up/down time. The curent kernel
> code actually was putting the register for the "little" cores in the
> "CPU" slot and the register for the "big" cores in the "GPU" slot. It
> was never initting the GPU counts.
>
> Note: this change assumes that ATF will actually set these values at
> boot, as I'm proposing in <http://crosreview.com/372381>.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
applied to my drivers branch for 4.10
Thanks
Heiko
^ permalink raw reply
* [PATCH v10 0/4] ACPI: parse the SPCR table
From: Aleksey Makarov @ 2016-09-26 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <98ed1e6b-0994-4429-c085-2293b4a89edf@linaro.org>
On 09/21/2016 10:22 AM, Aleksey Makarov wrote:
>
>
> On 09/21/2016 07:38 PM, Greg Kroah-Hartman wrote:
>> On Wed, Sep 21, 2016 at 11:19:35AM -0500, Timur Tabi wrote:
>>> On Wed, Sep 21, 2016 at 5:37 AM, Greg Kroah-Hartman
>>> <gregkh@linuxfoundation.org> wrote:
>>>>
>>>> I thought you asked Rafael to take them, they are not in my queue
>>>> anymore because of that. Don't try to shop-around for maintainers
>>>> please, that's kind of rude...
>>>
>>> In Aleksey's defense, these patches have been floating around for far
>>> too long, so I can understand his frustration.
>>
>> I understand the frustration as well, cross-maintainer messy patches
>> like this are hard to get merged at times at they fall between the
>> cracks a lot.
>>
>>> But as you said, I really hope Rafael picks these up for 4.9. We need
>>> these patches for ARM server.
>>
>> I thought I saw an email saying he would do so, but it might have been
>> for some other patchset, sorry...
>
> This can be for "ACPI: ARM64: support for ACPI_TABLE_UPGRADE":
>
> https://lkml.kernel.org/r/CAJZ5v0goXsQ2umcDXU0six+QtxcKGZq7mxhgxuvXTH2iZt6YNA at mail.gmail.com
>
> As for this patchset, Rafael ACKed the ACPI part:
>
> https://lkml.kernel.org/r/CAJZ5v0hdoLTfjrD8+WxSoxM48dqbZK2KwY_h+63kHKHKgO=JFA at mail.gmail.com
>
> but I can not find any acknowledge from him that he is ready to merge the series.
> On the contrary, he expressed his doubt that he is "the right maintainer to send this to":
>
> https://lkml.kernel.org/r/CAJZ5v0gzjtFzig7nEumr83+J2dGb+OA8GNR2i45ZqznfV_hA-A at mail.gmail.com
>
> I asked the ARM64 people, they said they prefer Rafael to do that:
>
> https://lkml.kernel.org/r/20160909151758.GA11418 at arm.com
>
> I interpreted the silence from Rafael as unwillingness to pull the series
> and thought it's OK to ask you.
>
> I am sorry if this looks rude for Rafael, I did not mean that.
Hi Greg,
Can you give advise on how to deal with this situation please?
It looks like Rafael does not want to pull the patches. Some time ago he wrote:
"Honestly, I'm not sure why I'm regarded as the right maintainer to send this to.
The only patch here touching generic ACPI code is [3/5] (the [2/5] is
going in through ACPICA) and the rest is all about ARM64 AFAICS. Why
don't you send it to the ARM64 maintainers instead?"
(https://lkml.kernel.org/r/CAJZ5v0gzjtFzig7nEumr83+J2dGb+OA8GNR2i45ZqznfV_hA-A at mail.gmail.com)
ARM64 maintainer said
"The series should go via Rafael, since the bulk of the changes are
outside of arch/arm64."
(https://lkml.kernel.org/r/20160909151758.GA11418 at arm.com)
So should I continue to try to reach Rafael or ask another maintainer?
Can you pull it for 4.9?
Thank you
Aleksey Makarov
>
> Thank you
> Aleksey Makarov
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: enable arm,shared-override in the pl310
From: dinguyen at opensource.altera.com @ 2016-09-26 19:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Dinh Nguyen <dinguyen@opensource.altera.com>
Enable the bit(22) shared-override bit for the SoCFPGA family. While at it,
enable the prefetch-data and prefetch-instr settings for the Arria10.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
arch/arm/boot/dts/socfpga.dtsi | 1 +
arch/arm/boot/dts/socfpga_arria10.dtsi | 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 9f48141..28ff6e4 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -686,6 +686,7 @@
arm,data-latency = <2 1 1>;
prefetch-data = <1>;
prefetch-instr = <1>;
+ arm,shared-override;
};
mmc: dwmmc0 at ff704000 {
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi b/arch/arm/boot/dts/socfpga_arria10.dtsi
index 94000cb..16fcb9f 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -573,6 +573,9 @@
interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
cache-unified;
cache-level = <2>;
+ prefetch-data = <1>;
+ prefetch-instr = <1>;
+ arm,shared-override;
};
mmc: dwmmc0 at ff808000 {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/4] kill get_clock_tick_rate()
From: Robert Jarzmik @ 2016-09-26 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-1-git-send-email-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> Hi,
>
> This serie aims at killing get_clock_tick_rate() from pxa and sa1100 and replace
> it by clock API calls.
>
> I'd like to have this reviewed and acked afterwards at least by :
> - Russell for the mach-sa1100 and sa1100_wdt.c
> - Stephen or Michael for the clk-pxa25x.c
> - Thomas or Daniel for the clocksource part
> - Wim for sa1100_wdt.c
>
> If the review converges, I'd also like to take it through the pxa/for-next tree,
> or alternatively Russell's tree if there is a dependency I'm not seeing, for
> v4.10 cycle.
Hi Russell,
Would you have time within the next 2 weeks to give this serie a review and
maybe an Ack from the sa1100 impacted parts (that would be patches 2, 3 and 4) ?
I can also resend the serie if it's easier in your workflow.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v6 6/6] ARM: dts: imx6qdl-icore: Add FEC support
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474917937-29336-1-git-send-email-jteki@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
Add FEC support for Engicam i.CoreM6 dql modules.
Observed similar 'eth0: link is not ready' issue which was
discussed in [1] due rmii mode with external ref_clk, so added
clock node along with the properties mentioned by Shawn in [2]
FEC link log:
------------
$ ifconfig eth0 up
[ 27.905187] SMSC LAN8710/LAN8720 2188000.ethernet:00: attached PHY driver
[SMSC LAN8710/LAN8720] (mii_bus:phy_addr=2188000.ethernet:00, irq=-1)
[ 27.918982] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[1] https://patchwork.kernel.org/patch/3491061/
[2] https://patchwork.kernel.org/patch/3490511/
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- none
Changes for v5:
- new patch
arch/arm/boot/dts/imx6qdl-icore.dtsi | 37 ++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index 4e79858..972f48f 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -48,6 +48,18 @@
reg = <0x10000000 0x80000000>;
};
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rmii_clk: clock at 0 {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <25000000>; /* 25MHz for example */
+ };
+ };
+
reg_3p3v: regulator-3p3v {
compatible = "regulator-fixed";
regulator-name = "3P3V";
@@ -93,6 +105,15 @@
assigned-clock-parents = <&clks IMX6QDL_CLK_OSC>;
};
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ clocks = <&clks 117>, <&clks 117>, <&rmii_clk>;
+ phy-mode = "rmii";
+ status = "okay";
+};
+
&gpmi {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpmi_nand>;
@@ -150,6 +171,22 @@
};
&iomuxc {
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x1b0b1
+ MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+ MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_REF_CLK__GPIO1_IO23 0x1b0b0
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
+ >;
+ };
+
pinctrl_flexcan1: flexcan1grp {
fsl,pins = <
MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b020
--
2.7.4
^ permalink raw reply related
* [PATCH v6 5/6] ARM: dts: imx6qdl-icore: Add usbotg support
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474917937-29336-1-git-send-email-jteki@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
Add usbotg support for Engicam i.CoreM6 dql modules.
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- none
Changes for v5:
- none
Changes for v4:
- new patch
arch/arm/boot/dts/imx6qdl-icore.dtsi | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index ffec879..4e79858 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -65,6 +65,15 @@
regulator-boot-on;
regulator-always-on;
};
+
+ reg_usb_otg_vbus: usb_otg_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
};
&can1 {
@@ -124,6 +133,14 @@
status = "okay";
};
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ disable-over-current;
+ status = "okay";
+};
+
&usdhc1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc1>;
@@ -198,6 +215,12 @@
>;
};
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
+ >;
+ };
+
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17070
--
2.7.4
^ permalink raw reply related
* [PATCH v6 4/6] ARM: dts: imx6qdl-icore: Add usbhost support
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474917937-29336-1-git-send-email-jteki@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
Add usbhost support for Engicam i.CoreM6 dql modules.
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- none
Changes for v5:
- none
Changes for v4:
- new patch
arch/arm/boot/dts/imx6qdl-icore.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index f424cd5..ffec879 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -56,6 +56,15 @@
regulator-boot-on;
regulator-always-on;
};
+
+ reg_usb_h1_vbus: usb_h1_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
};
&can1 {
@@ -109,6 +118,12 @@
status = "okay";
};
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ disable-over-current;
+ status = "okay";
+};
+
&usdhc1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v6 3/6] ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474917937-29336-1-git-send-email-jteki@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
i.CoreM6 DualLite/Solo modules are system on module solutions manufactured
by Engicam with following characteristics:
CPU NXP i.MX6 DL, 800MHz
RAM 1GB, 32, 64 bit, DDR3-800/1066
NAND SLC,512MB
Power supply Single 5V
MAX LCD RES FULLHD
and more info at
http://www.engicam.com/en/products/embedded/som/sodimm/i-core-m6s-dl-d-q
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- none
Changes for v5:
- none
Changes for v4:
- new patch
Changes for v3:
- Use compatible as engicam,imx6-icore instead of fsl,imx6-icore
Changes for v2:
- s/oaky/okay/g
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-icore.dts | 59 ++++++++++++++++++++++++++++++++++++++
2 files changed, 60 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-icore.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 511510d..6175f44 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -333,6 +333,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-gw552x.dtb \
imx6dl-gw553x.dtb \
imx6dl-hummingboard.dtb \
+ imx6dl-icore.dtb \
imx6dl-nit6xlite.dtb \
imx6dl-nitrogen6x.dtb \
imx6dl-phytec-pbab01.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-icore.dts b/arch/arm/boot/dts/imx6dl-icore.dts
new file mode 100644
index 0000000..aec332c
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-icore.dts
@@ -0,0 +1,59 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 , 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 "imx6dl.dtsi"
+#include "imx6qdl-icore.dtsi"
+
+/ {
+ model = "Engicam i.CoreM6 DualLite/Solo Starter Kit";
+ compatible = "engicam,imx6-icore", "fsl,imx6dl";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v6 2/6] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474917937-29336-1-git-send-email-jteki@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
i.CoreM6 Quad/Dual modules are system on module solutions manufactured
by Engicam with following characteristics:
CPU NXP i.MX6 DQ, 800MHz
RAM 1GB, 32, 64 bit, DDR3-800/1066
NAND SLC,512MB
Power supply Single 5V
MAX LCD RES FULLHD
and more info at
http://www.engicam.com/en/products/embedded/som/sodimm/i-core-m6s-dl-d-q
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- none
Changes for v5:
- removed fsl,legacy-bch-geometry property from gpmi node
Changes for v4:
- new patch
Changes for v3:
- Use compatible as engicam,imx6-icore instead of fsl,imx6-icore
- Update IOMUX value for can1 and can2 nodes
- Added reg_3p3v for can1 and can2 nodes
Changes for v2:
- s/oaky/okay/g
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-icore.dts | 59 +++++++++++
arch/arm/boot/dts/imx6qdl-icore.dtsi | 196 +++++++++++++++++++++++++++++++++++
3 files changed, 256 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-icore.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-icore.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f79cac2..511510d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -374,6 +374,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-gw553x.dtb \
imx6q-h100.dtb \
imx6q-hummingboard.dtb \
+ imx6q-icore.dtb \
imx6q-icore-rqs.dtb \
imx6q-marsboard.dtb \
imx6q-nitrogen6x.dtb \
diff --git a/arch/arm/boot/dts/imx6q-icore.dts b/arch/arm/boot/dts/imx6q-icore.dts
new file mode 100644
index 0000000..025f543
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-icore.dts
@@ -0,0 +1,59 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 , 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 "imx6q.dtsi"
+#include "imx6qdl-icore.dtsi"
+
+/ {
+ model = "Engicam i.CoreM6 Quad/Dual Starter Kit";
+ compatible = "engicam,imx6-icore", "fsl,imx6q";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
new file mode 100644
index 0000000..f424cd5
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -0,0 +1,196 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 , 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.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ memory {
+ reg = <0x10000000 0x80000000>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ xceiver-supply = <®_3p3v>;
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ xceiver-supply = <®_3p3v>;
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6QDL_CLK_LVDS2_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_OSC>;
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ nand-on-flash-bbt;
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b020
+ MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x1b020
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b020
+ MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b020
+ >;
+ };
+
+ pinctrl_gpmi_nand: gpmi-nand {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
+ MX6QDL_PAD_NANDF_ALE__NAND_ALE 0xb0b1
+ MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0xb0b1
+ MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0xb000
+ MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0xb0b1
+ MX6QDL_PAD_NANDF_CS1__NAND_CE1_B 0xb0b1
+ MX6QDL_PAD_SD4_CMD__NAND_RE_B 0xb0b1
+ MX6QDL_PAD_SD4_CLK__NAND_WE_B 0xb0b1
+ MX6QDL_PAD_NANDF_D0__NAND_DATA00 0xb0b1
+ MX6QDL_PAD_NANDF_D1__NAND_DATA01 0xb0b1
+ MX6QDL_PAD_NANDF_D2__NAND_DATA02 0xb0b1
+ MX6QDL_PAD_NANDF_D3__NAND_DATA03 0xb0b1
+ MX6QDL_PAD_NANDF_D4__NAND_DATA04 0xb0b1
+ MX6QDL_PAD_NANDF_D5__NAND_DATA05 0xb0b1
+ MX6QDL_PAD_NANDF_D6__NAND_DATA06 0xb0b1
+ MX6QDL_PAD_NANDF_D7__NAND_DATA07 0xb0b1
+ MX6QDL_PAD_SD4_DAT0__NAND_DQS 0x00b1
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_EB2__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17070
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10070
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17070
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17070
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17070
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17070
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v6 1/6] of: Add vendor prefix for Engicam s.r.l company
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
From: Jagan Teki <jagan@amarulasolutions.com>
Engicam providing design services of electronic systems with
high content of technology, relying on a long experience in
electronic design.
For more info visit
http://www.engicam.com/en/
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- Added Acked-by: tag
Changes for v5:
- none
Changes for v4:
- new patch
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 3003f33..327e4c7 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -85,6 +85,7 @@ elan Elan Microelectronic Corp.
embest Shenzhen Embest Technology Co., Ltd.
emmicro EM Microelectronic
energymicro Silicon Laboratories (formerly Energy Micro AS)
+engicam Engicam S.r.l.
epcos EPCOS AG
epfl Ecole Polytechnique F?d?rale de Lausanne
epson Seiko Epson Corp.
--
2.7.4
^ permalink raw reply related
* [PATCH v6 0/6] ARM: dts: imx6q: Add Engicam i.CoreM6 dts
From: Jagan Teki @ 2016-09-26 19:23 UTC (permalink / raw)
To: linux-arm-kernel
This is series add dts support for Engicam I.Core M6 qdl modules on
top of */shawnguo/linux.git for-next.
Jagan Teki (6):
of: Add vendor prefix for Engicam s.r.l company
ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
ARM: dts: imx6qdl-icore: Add usbhost support
ARM: dts: imx6qdl-icore: Add usbotg support
ARM: dts: imx6qdl-icore: Add FEC support
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-icore.dts | 59 +++++
arch/arm/boot/dts/imx6q-icore.dts | 59 +++++
arch/arm/boot/dts/imx6qdl-icore.dtsi | 271 +++++++++++++++++++++
5 files changed, 392 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-icore.dts
create mode 100644 arch/arm/boot/dts/imx6q-icore.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-icore.dtsi
--
2.7.4
^ permalink raw reply
* [PATCH v2] ARM: dts: socfpga: Add Macnica sodia board
From: Dinh Nguyen @ 2016-09-26 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160924235945.32128-1-iwamatsu@nigauri.org>
On 09/24/2016 06:59 PM, Nobuhiro Iwamatsu wrote:
> Add support for board based on the Altera Cyclone V SoC.
> This board has the following functions:
> - 1 GiB of DRAM
> - 1 Gigabit ethernet
> - 1 SD card slot
> - 1 USB gadget port
> - QSPI NOR Flash
> - I2C EEPROMs and I2C RTC
> - DVI output
> - Audio port
>
> This commit supports without QSPI, DVI and Audio.
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> ---
> V2: move the PHY of setting to the Ethetnet PHY node level.
>
Applied. Thanks!
Dinh
^ permalink raw reply
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Stephen Boyd @ 2016-09-26 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923143513.GA29714@rob-hp-laptop>
Quoting Rob Herring (2016-09-23 07:35:13)
> On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > board to mux the D+/D- lines from the SoC between a micro usb
> > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > we need to change this mux to forward the D+/D- lines to either
> > > the port or the hub. Therefore, introduce a driver for this
> > > device that intercepts extcon USB_HOST events and logically
> > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > attached. When the cable goes away, it will logically deassert
> > > the gpio and mux the "device" lines.
> > >
> > > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > >
> > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > > Cc: <devicetree@vger.kernel.org>
> > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > ---
> > >
> > > Should I make the extcon part optional? I could see a case where there are two
> > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > software may want to mux between them at runtime. If we mandate an extcon,
> > > that won't be possible to support. Perhaps it would be better to have
> > > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > > endpoints would be useful too) so that when the controller wants to mux over
> > > a port it can do so.
>
> I've mentioned my opinion on extcon before. The first clue that it needs
> work is a Linux subsystem name is used for the binding.
>
> > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > haven't written any code around it, but the idea is to allow the binding
> > to specify how the mux is connected to upstream and downstream D+/D-
> > lines. This way, we can do some dt parsing of the endpoints and their
> > parent nodes to figure out if the mux needs to be set high or low to use
> > a device connector or a usb hub based on if the id cable is present.
> > Maybe I'm over thinking things though and we could just have a DT
> > property for that.
>
> I think the connector nodes are on the right track, but of-graph doesn't
> work here because we already have a way to describe USB buses in DT.
> Following that, would something like this work for you? The vbus-supply
> and id-gpios are just examples and may not always be there like if the
> hub controls each port's vbus directly.
My philosophical problem with this is that I don't view this usb-switch
as a usb device. It isn't addressable via the typical USB addressing
scheme. It's just a simple chip wired down on the board that muxes two
wires without considering what goes across those wires.
I would agree if this switch was a usb device itself that had a vid/pid
that we could talk to to switch the mux. But that isn't the case here.
>
> usb-controller at 1234 {
> usb-switch at 0 {
> compatible = "toshiba,tc7usb40mu";
> hub at 0 {
> compatible = "some-hub";
> port at 0 {
> compatible = "usb-A-connector"
> vbus-supply = ...;
> };
> port at 1 {
> compatible = "usb-A-connector"
> vbus-supply = ...;
> };
>
> };
> connector at 1 {
> compatible = "usb-ub-connector";
> vbus-supply = ...;
> id-gpios = <>;
> };
> };
> };
>
What do we do about a hub downstream of the mux like usb3503? If that's
on the i2c bus and we need to do some initial setup, shouldn't we put
the hub under the i2c bus (because that's the addressing scheme) instead
of under the switch and then use of-graph to describe the connections
that aren't being used for addressing? My understanding of of-graph is
pretty weak so perhaps I missed something.
^ permalink raw reply
* [PATCH] ARM: dts: lpc32xx: set pwm1 & pwm2 default clock rate
From: Sylvain Lemieux @ 2016-09-26 18:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
Probably most of NXP LPC32xx boards have 13MHz main oscillator
and therefore for HCLK PLL and ARM core clock rate default
hardware setting of 16 * 13MHz = 208MHz and the AHB bus clock
rate of 208MHz / 2 = 104MHz.
The change explicitly defines the peripheral PWM1/PWM2 default
clock output rate of 104MHz. If needed it can be redefined
in a board DTS file.
Signed-off-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
---
Note:
* There is a dependency on the following patch:
"ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2"
http://www.spinics.net/lists/arm-kernel/msg530277.html
* This patch should be apply after
"ARM: dts: lpc32xx: add pwm-cells to base dts file"
http://www.spinics.net/lists/arm-kernel/msg534050.html
- There is no dependency between the patches.
arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index c031c94..d669200 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -471,6 +471,7 @@
clocks = <&clk LPC32XX_CLK_PWM1>;
assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
+ assigned-clock-rates = <104000000>;
status = "disabled";
#pwm-cells = <2>;
};
@@ -481,6 +482,7 @@
clocks = <&clk LPC32XX_CLK_PWM2>;
assigned-clocks = <&clk LPC32XX_CLK_PWM2>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
+ assigned-clock-rates = <104000000>;
status = "disabled";
#pwm-cells = <2>;
};
--
1.8.3.1
^ permalink raw reply related
* [PATCH] ARM: dts: lpc32xx: add pwm-cells to base dts file
From: Sylvain Lemieux @ 2016-09-26 18:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
There is no need to define the "pwm-cells" in the board
specific dts file; move the entry to the base dts file.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
Note:
* This patch should be apply after
"ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2"
http://www.spinics.net/lists/arm-kernel/msg530277.html
- There is no dependency between the patches.
arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 218d9fa..c031c94 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -472,6 +472,7 @@
assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
status = "disabled";
+ #pwm-cells = <2>;
};
pwm2: pwm at 4005C004 {
@@ -481,6 +482,7 @@
assigned-clocks = <&clk LPC32XX_CLK_PWM2>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
status = "disabled";
+ #pwm-cells = <2>;
};
timer3: timer at 40060000 {
--
1.8.3.1
^ permalink raw reply related
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Stephen Boyd @ 2016-09-26 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160926032927.GA25395@b29397-desktop>
Quoting Peter Chen (2016-09-25 20:29:27)
> On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-09-16 18:16:05)
> > > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > > we need to change this mux to forward the D+/D- lines to either
> > > > > the port or the hub. Therefore, introduce a driver for this
> > > > > device that intercepts extcon USB_HOST events and logically
> > > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > > attached. When the cable goes away, it will logically deassert
> > > > > the gpio and mux the "device" lines.
> > > > >
> > > > > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > > > >
> > > > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > > > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > > > > Cc: <devicetree@vger.kernel.org>
> > > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > > > ---
> > > > >
> > > > > Should I make the extcon part optional? I could see a case where there are two
> > > > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > > > software may want to mux between them at runtime. If we mandate an extcon,
> > > > > that won't be possible to support. Perhaps it would be better to have
> > > > > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > > > > endpoints would be useful too) so that when the controller wants to mux over
> > > > > a port it can do so.
> > > >
> > > > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > > > haven't written any code around it, but the idea is to allow the binding
> > > > to specify how the mux is connected to upstream and downstream D+/D-
> > > > lines. This way, we can do some dt parsing of the endpoints and their
> > > > parent nodes to figure out if the mux needs to be set high or low to use
> > > > a device connector or a usb hub based on if the id cable is present.
> > > > Maybe I'm over thinking things though and we could just have a DT
> > > > property for that.
> > > >
> > > > soc {
> > > > usb at 78d9000 {
> > > > extcon = <&usb_id>, <&usb_id>;
> > >
> > > Why you have two same extcon phandler? From my mind, one should id,
> > > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > > vbus support, how you support vbus detection for
> > > connection/disconnection with PC for your chipidea msm patch set?
> >
> > This was already in the dts files for db410c. In the chipidea binding
> > one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> > understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> > and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> > that great on this board because we only have on gpio for this.
>
> I think extcon-usb-gpio.c needs to extend for supporting vbus event,
> otherwise, the micro-b cable's connect/disconnect will introduce
> EXTCON_USB_HOST event, if you use two <&usb_idx> for both id and
> vbus event.
>
Sorry, I'm lost now. extcon-usb-gpio.c already supports EXTCON_USB as an
event. Is the problem that we're using two of the same phandles in the
binding?
^ permalink raw reply
* [PATCH] clk: lpc32xx: fix pwm clock divider computation
From: Sylvain Lemieux @ 2016-09-26 18:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
A zero value in the PWM clock divider register
(PWM1_FREQ/PWM2_FREQ) turn off the PWM clock.
The "CLK_DIVIDER_ALLOW_ZERO" option is used for hardware that handle
the zero divider by not modifying their clock input (i.e. bypass).
See "/include/linux/clk-provider.h" for details.
Remove the CLK_DIVIDER_ALLOW_ZERO option and add support to handle
the clock rate computation of the PWM clock divider 0 value.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
Note:
* Should we include a new CLK_DIVIDER option for this case
(i.e. clock off when zero ) in "clk-provider.h"?
drivers/clk/nxp/clk-lpc32xx.c | 52 +++++++++++++++++++++++++++++++++++++++----
1 file changed, 48 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
index 34c9735..3ca3a14 100644
--- a/drivers/clk/nxp/clk-lpc32xx.c
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -959,6 +959,25 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
divider->flags);
}
+static unsigned long clk_divider_pwm_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct lpc32xx_clk_div *divider = to_lpc32xx_div(hw);
+ unsigned int val;
+
+ regmap_read(clk_regmap, divider->reg, &val);
+
+ val >>= divider->shift;
+ val &= div_mask(divider->width);
+
+ /* Handle 0 divider -> PWM clock is off. */
+ if(val == 0)
+ return 0;
+
+ return divider_recalc_rate(hw, parent_rate, val, divider->table,
+ divider->flags);
+}
+
static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
@@ -999,6 +1018,12 @@ static const struct clk_ops lpc32xx_clk_divider_ops = {
.set_rate = clk_divider_set_rate,
};
+static const struct clk_ops lpc32xx_clk_pwm_divider_ops = {
+ .recalc_rate = clk_divider_pwm_recalc_rate,
+ .round_rate = clk_divider_round_rate,
+ .set_rate = clk_divider_set_rate,
+};
+
static u8 clk_mux_get_parent(struct clk_hw *hw)
{
struct lpc32xx_clk_mux *mux = to_lpc32xx_mux(hw);
@@ -1151,6 +1176,25 @@ struct clk_hw_proto {
}, \
}
+#define LPC32XX_DEFINE_PWM_DIV(_idx, _reg, _shift, _width, _tab, _fl) \
+[CLK_PREFIX(_idx)] = { \
+ .type = CLK_DIV, \
+ { \
+ .hw0 = { \
+ .ops = &lpc32xx_clk_pwm_divider_ops, \
+ { \
+ .div = { \
+ .reg = LPC32XX_CLKPWR_ ## _reg, \
+ .shift = (_shift), \
+ .width = (_width), \
+ .table = (_tab), \
+ .flags = (_fl), \
+ }, \
+ }, \
+ }, \
+ }, \
+}
+
#define LPC32XX_DEFINE_GATE(_idx, _reg, _bit, _flags) \
[CLK_PREFIX(_idx)] = { \
.type = CLK_GATE, \
@@ -1281,14 +1325,14 @@ static struct clk_hw_proto clk_hw_proto[LPC32XX_CLK_HW_MAX] = {
LPC32XX_DEFINE_GATE(MCPWM, TIMCLK_CTRL1, 6, 0),
LPC32XX_DEFINE_MUX(PWM1_MUX, PWMCLK_CTRL, 1, 0x1, NULL, 0),
- LPC32XX_DEFINE_DIV(PWM1_DIV, PWMCLK_CTRL, 4, 4, NULL,
- CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO),
+ LPC32XX_DEFINE_PWM_DIV(PWM1_DIV, PWMCLK_CTRL, 4, 4, NULL,
+ CLK_DIVIDER_ONE_BASED),
LPC32XX_DEFINE_GATE(PWM1_GATE, PWMCLK_CTRL, 0, 0),
LPC32XX_DEFINE_COMPOSITE(PWM1, PWM1_MUX, PWM1_DIV, PWM1_GATE),
LPC32XX_DEFINE_MUX(PWM2_MUX, PWMCLK_CTRL, 3, 0x1, NULL, 0),
- LPC32XX_DEFINE_DIV(PWM2_DIV, PWMCLK_CTRL, 8, 4, NULL,
- CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO),
+ LPC32XX_DEFINE_PWM_DIV(PWM2_DIV, PWMCLK_CTRL, 8, 4, NULL,
+ CLK_DIVIDER_ONE_BASED),
LPC32XX_DEFINE_GATE(PWM2_GATE, PWMCLK_CTRL, 2, 0),
LPC32XX_DEFINE_COMPOSITE(PWM2, PWM2_MUX, PWM2_DIV, PWM2_GATE),
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.
From: Stefan Wahren @ 2016-09-26 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fa11c543-2ad3-b2ae-f816-62a1acd42911@wwwdotorg.org>
> Stephen Warren <swarren@wwwdotorg.org> hat am 26. September 2016 um 18:38
> geschrieben:
>
>
> On 09/23/2016 12:39 PM, Stefan Wahren wrote:
> > Hi Eric,
> >
> >> Eric Anholt <eric@anholt.net> hat am 19. September 2016 um 18:13
> >> geschrieben:
> >>
> >>
> >> The RPi firmware exposes all of the board's GPIO lines through
> >> property calls. Linux chooses to control most lines directly through
> >> the pinctrl driver, but for the FXL6408 GPIO expander on the Pi3, we
> >> need to access them through the firmware.
> >>
> >> Signed-off-by: Eric Anholt <eric@anholt.net>
> >> ---
> >> .../bindings/gpio/gpio-raspberrypi-firmware.txt | 22
> >> ++++++++++++++++++++++
> >> 1 file changed, 22 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> >> b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> >> new file mode 100644
> >> index 000000000000..2b635c23a6f8
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> >> @@ -0,0 +1,22 @@
> >> +Raspberry Pi power domain driver
> >> +
> >> +Required properties:
> >> +
> >> +- compatible: Should be "raspberrypi,firmware-gpio"
> >
> > i think the compatible should be more specific like
> >
> > raspberrypi,rpi3-firmware-gpio
> >
> > and all information which aren't requestable from the firmware should be
> > stored
> > in a info structure. This makes the driver easier to extend in the future by
> > adding new compatibles and their info structures.
>
> Is this actually specific to the Pi3 at all?
AFAIK only the Raspberry Pi 3 has a GPIO expander which is accessible via the
common FW. My suggestion tries to follow the basic guideline "A precise
compatible string is better than a vague one" from Device Tree for Dummies [1].
So in case the next Raspberry Pi would have a different GPIO expander with
different parameters we could add a new compatible.
But you are right the word order in "rpi3-firmware-gpio" suggests that there are
different FW which is wrong. At the end it's only a compatible string. So no
strong opinion about the naming.
[1] -
https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
> Isn't the FW the same
> across all Pis; the part that's specific to the Pi3 is whether it's
> useful to use that API?
>
> As such, I'd suggest just raspberrypi,firmware-gpio as the compatible value.
>
^ permalink raw reply
* [PATCH] dmaengine: sun6i: Add support for Allwinner A83T (sun8i) variant
From: Vinod Koul @ 2016-09-26 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79efe054-3640-45ec-9c11-3f60d497b1e0@orsmsx104.amr.corp.intel.com>
On Sun, Sep 18, 2016 at 09:59:50AM +0200, Jean-Francois Moine wrote:
> The A83T SoC has the same dma engine as the A31 (sun6i), with a reduced
> amount of endpoints and physical channels.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH v3] dmaengine: s3c24xx: Add dma_slave_map for s3c2440 devices
From: Vinod Koul @ 2016-09-26 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474570275-7238-1-git-send-email-sam.van.den.berge@telenet.be>
On Thu, Sep 22, 2016 at 08:51:15PM +0200, Sam Van Den Berge wrote:
> This patch updates the s3c24xx dma driver to be able to pass a
> dma_slave_map array via the platform data. This is needed to
> be able to use the new, simpler dmaengine API [1].
> I used the virtual DMA channels as a parameter for the dma_filter
> function. By doing that, I could reuse the existing filter function in
> drivers/dma/s3c24xx-dma.c.
>
> I have tested this on my mini2440 board with the audio driver.
> According to my observations, dma_request_slave_channel in the
> function dmaengine_pcm_new in the file
> sound/soc/soc-generic-dmaengine-pcm.c now returns a valid DMA channel
> whereas before no DMA channel was returned at that point.
>
> Entries for DMACH_XD0, DMACH_XD1 and DMACH_TIMER are missing because I
> don't realy know which driver to use for these.
Applied, thanks
--
~Vinod
^ 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