* [PATCH] clk: qoriq: add ls1046a support
From: Stephen Boyd @ 2016-11-02 0:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473220110-22159-1-git-send-email-shh.xie@gmail.com>
On 09/07, shh.xie at gmail.com wrote:
> From: Mingkai Hu <mingkai.hu@nxp.com>
>
> Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
Would have been nice to have some blurb here about the chip being
supported, but ok.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: qoriq: add ls1046a support
From: Stephen Boyd @ 2016-11-02 0:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473220110-22159-1-git-send-email-shh.xie@gmail.com>
On 09/07, shh.xie at gmail.com wrote:
> From: Mingkai Hu <mingkai.hu@nxp.com>
>
> Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: stm32f4: don't assume 48MHz clock is derived from primary PLL
From: Stephen Boyd @ 2016-11-02 0:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN8YU5MFX0cwUv34fAL3PSaRQNhgPZFO3PiXBdE+fVeLgGJ8ZQ@mail.gmail.com>
On 09/12, Andrea Merello wrote:
> On Fri, Sep 9, 2016 at 11:57 AM, Alexandre Torgue
> <alexandre.torgue@st.com> wrote:
> > Hi Andrea,
> >
> > On 09/08/2016 09:01 AM, Andrea Merello wrote:
> >>
> >> This driver just look at the PLLs configurations set by the
> >> bootloader, but it assumes the 48MHz clock is derived from the primary
> >> PLL; however using PLLSAI is another option for generating the 48MHz
> >> clock.
> >>
> >> This patch make the driver to check for this, and eventually adjust the
> >> clock tree accordingly
> >
> >
> > Another patch-set is ongoing concerning RTC clock for stm32f4. It is
> > developed by Gabriel Fernandez (I add him directly in this reply).
> > Can you check with him how he plans to manage this RTC clock in order to
> > have something similar / coherent for SAI clocks, 48MHz ....
> >
> > Concerning this patch,
> > When I look at the clock tree I see that 48 MHz is only provided by pll
> > named "PLL". So If you use PLL SAI to provide a clock at 48 MHz, you
> > actually use SAI_A or SAI_B clock. I'm right ?
>
> No, SAI_A and SAI_B are two other clocks output, that comes from
> PLLSAI through other divisors and muxes; here I simply look at if the
> bootloader selected the "PLL48CLK" output of the SAI PLL instead of
> the "PLL48CLK" of the primary PLL.
>
> > I think we need to have something more configurable. Each special clock (SAI
> > / RTC /LCd ...) have to be configurable and each "parents" (PLL / PLLI2S /
> > PLLSAI) should be described at least in the driver.
>
> Yes, there are probably other possible clock configurations that the
> driver does not recognize yet; I just added this one because I found
> it useful in real-world scenario (USB/SDcard working and core running
> at the max speed at the same time).
>
> >
> > Gabriel,
> >
> > Can you send a draft of your patch-set for RTC clock to Andrea, in order to
> > discuss about this topic.
> >
> > Thanks
I know this is a couple months old, but the RTC patches have been
applied. Please resend this patch rebased onto clk-next and
restart this discussion if this is still important.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 1/1] clk: mvebu: migrate CP110 system controller to clk_hw API and registration
From: Stephen Boyd @ 2016-11-02 0:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474789673-3837-2-git-send-email-mw@semihalf.com>
On 09/25, Marcin Wojtas wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in Armada
> CP110 system controller driver. This commit introduces new
> API and registration for all clocks in CP110 HW blocks.
>
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: nxp: clk-lpc18xx-ccu: Unmap region obtained by of_iomap
From: Stephen Boyd @ 2016-11-02 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474367987-15808-1-git-send-email-arvind.yadav.cs@gmail.com>
On 09/20, Arvind Yadav wrote:
> From: Arvind Yadav <arvind.yadav.cs@gmail.com>
>
> Free memory mapping, if lpc18xx_ccu_init is not successful.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: lpc32xx: add a quirk for PWM and MS clock dividers
From: Stephen Boyd @ 2016-11-02 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475803015-4067-1-git-send-email-vz@mleia.com>
On 10/07, Vladimir Zapolskiy wrote:
> In common clock framework CLK_DIVIDER_ONE_BASED or'ed with
> CLK_DIVIDER_ALLOW_ZERO flags indicates that
> 1) a divider clock may be set to zero value,
> 2) divider's zero value is interpreted as a non-divided clock.
>
> On the LPC32xx platform clock dividers of PWM and memory card clocks
> comply with the first condition, but zero value means a gated clock,
> thus it may happen that the divider value is not updated when
> the clock is enabled and the clock remains gated.
>
> The change adds one-shot quirks, which check for zero value of divider
> on initialization and set it to a non-zero value, therefore in runtime
> a gate clock will work as expected.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: qoriq: Don't allow CPU clocks higher than starting value
From: Stephen Boyd @ 2016-11-02 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476729743-15563-1-git-send-email-oss@buserror.net>
On 10/17, Scott Wood wrote:
> The boot-time frequency of a CPU is considered its rated maximum, as we
> have no other source of such information. However, this was previously
> only used for chips with 80% restrictions on secondary PLLs. This
> usually wasn't a problem because most chips/configs boot with a divider
> of /1, with other dividers being used only for dynamic frequency
> reduction. However, at least one config (LS1021A at less than 1 GHz)
> uses a different divider for top speed. This was causing cpufreq to set
> a frequency beyond the chip's rated speed.
>
> This is fixed by applying a 100%-of-initial-speed limit to all CPU PLLs,
> similar to the existing 80% limit that only applied to some.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> Cc: stable at vger.kernel.org
> ---
All silence, so I applied to clk-fixes because presumably this is
some sort of badness we need to fix quickly.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/3] clk: imx: clk-imx6ul: add clk support for imx6ull
From: Stephen Boyd @ 2016-11-02 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477969343-19887-4-git-send-email-peter.chen@nxp.com>
On 11/01, Peter Chen wrote:
> clks[IMX6UL_CLK_USDHC1] = imx_clk_gate2("usdhc1", "usdhc1_podf", base + 0x80, 2);
> clks[IMX6UL_CLK_USDHC2] = imx_clk_gate2("usdhc2", "usdhc2_podf", base + 0x80, 4);
> - clks[IMX6UL_CLK_SIM1] = imx_clk_gate2("sim1", "sim_sel", base + 0x80, 6);
> - clks[IMX6UL_CLK_SIM2] = imx_clk_gate2("sim2", "sim_sel", base + 0x80, 8);
> + if (clk_on_imx6ul()) {
> + clks[IMX6UL_CLK_SIM1] = imx_clk_gate2("sim1", "sim_sel", base + 0x80, 6);
> + clks[IMX6UL_CLK_SIM2] = imx_clk_gate2("sim2", "sim_sel", base + 0x80, 8);
> + }
> clks[IMX6UL_CLK_EIM] = imx_clk_gate2("eim", "eim_slow_podf", base + 0x80, 10);
> clks[IMX6UL_CLK_PWM8] = imx_clk_gate2("pwm8", "perclk", base + 0x80, 16);
> clks[IMX6UL_CLK_UART8_IPG] = imx_clk_gate2("uart8_ipg", "ipg", base + 0x80, 14);
> @@ -430,6 +478,7 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
> clk_set_rate(clks[IMX6UL_CLK_ENET_REF], 50000000);
> clk_set_rate(clks[IMX6UL_CLK_ENET2_REF], 50000000);
> clk_set_rate(clks[IMX6UL_CLK_CSI], 24000000);
> + clk_set_rate(clks[IMX6UL_CLK_PLL3_PFD2], 320000000);
Can you use assigned clock rates for this instead?
>
> /* keep all the clks on just for bringup */
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Stephen Boyd @ 2016-11-02 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CLMtyZStgDzdiSHo9s8BhXyiapWqDx1L_TmMpH13043g@mail.gmail.com>
On 10/28, Fabio Estevam wrote:
> On Fri, Oct 28, 2016 at 4:13 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>
> > The clk-fixes branch is for patches that fix problems in code
> > merged during the merge window as well as small one-liners and
> > things that are causing great pain for people on the latest
> > release. Given that this fixes a regression in v4.8 and we're
> > trying to stabilize v4.9 it looked like it could wait until
> > v4.10.
>
> The regression affects 4.8 and 4.9.
>
> > So is there something going on here where the pain is too much to
> > wait for the next merge window? If so the commit text should
>
> Yes, people reported HDMI issues because of this bug:
> https://www.spinics.net/lists/arm-kernel/msg535304.html
>
> > mention something about what's causing that pain. Perhaps by
> > referencing the commit that merged outside of clk tree that
> > caused problems.
>
> This patch clearly states that the problem is caused by ba7f4f557eb6
> ("clk: imx: correct AV PLL rate formula").
That commit isn't outside of clk tree :(
>
> Since this is a regression, I don't understand why we need to wait
> until 4.10 to get it applied.
Because we're stabilizing the 4.9-rc series and not the 4.8-rc
series and the assumption is people tested code no 4.8 before it
was released. But in cases where that doesn't happen and the bugs
cause problems with testing the latest rc series we just apply
the patch. It sounds like in this case that happened, so I'll
move this patch over to fixes.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] ARM: socfpga: updates for socfpga_defconfig
From: Alan Tull @ 2016-11-01 23:54 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables the following in the
socfpga_defconfig:
+CONFIG_OF_OVERLAY=y
Enable support for Device Tree Overlays
+CONFIG_FPGA_REGION=y
Enable device tree overlay support for FPGA
programming
+CONFIG_FPGA_MGR_SOCFPGA_A10=y
Enable partial reconfiguration for Altera
Arria 10 FPGA
+CONFIG_FPGA_BRIDGE=y
Enable the FPGA Bridges framework
+CONFIG_SOCFPGA_FPGA_BRIDGE=y
Enable support for SoCFPGA hardware
bridges
+CONFIG_ALTERA_FREEZE_BRIDGE=y
Enable support for the Altera Soft IP
Freeze bridges
Signed-off-by: Alan Tull <atull@opensource.altera.com>
---
arch/arm/configs/socfpga_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
index f5b9bc5..18d3ec1 100644
--- a/arch/arm/configs/socfpga_defconfig
+++ b/arch/arm/configs/socfpga_defconfig
@@ -54,6 +54,7 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_SPI_NOR=y
CONFIG_SPI_CADENCE_QUADSPI=y
+CONFIG_OF_OVERLAY=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=2
CONFIG_BLK_DEV_RAM_SIZE=8192
@@ -105,7 +106,12 @@ CONFIG_DMADEVICES=y
CONFIG_PL330_DMA=y
CONFIG_DMATEST=m
CONFIG_FPGA=y
+CONFIG_FPGA_REGION=y
CONFIG_FPGA_MGR_SOCFPGA=y
+CONFIG_FPGA_MGR_SOCFPGA_A10=y
+CONFIG_FPGA_BRIDGE=y
+CONFIG_SOCFPGA_FPGA_BRIDGE=y
+CONFIG_ALTERA_FREEZE_BRIDGE=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
--
1.9.1
^ permalink raw reply related
* [PATCH] ARM: dts: imx6: Add imx-weim parameters to dtsi's
From: Joshua Clayton @ 2016-11-01 23:51 UTC (permalink / raw)
To: linux-arm-kernel
imx-weim should always set address-cells to 2,
and size_cells to 1.
On imx6, fsl,weim-cs-gpr will always be &gpr
Set these common parameters in the dtsi file,
rather than in a downstream dts.
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
arch/arm/boot/dts/imx6q-evi.dts | 3 ---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 2 --
arch/arm/boot/dts/imx6qdl.dtsi | 3 +++
arch/arm/boot/dts/imx6sl.dtsi | 3 +++
arch/arm/boot/dts/imx6sx.dtsi | 3 +++
5 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index bd0b85c..a88cbd8 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -241,10 +241,7 @@
};
&weim {
- #address-cells = <2>;
- #size-cells = <1>;
ranges = <0 0 0x08000000 0x08000000>;
- fsl,weim-cs-gpr = <&gpr>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_weimfpga &pinctrl_weimcs>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 8006467..52390ba 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -613,8 +613,6 @@
&weim {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_weim_nor &pinctrl_weim_cs0>;
- #address-cells = <2>;
- #size-cells = <1>;
ranges = <0 0 0x08000000 0x08000000>;
status = "disabled"; /* pin conflict with SPI NOR */
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 1bbd36f..d7bed1f 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1092,10 +1092,13 @@
};
weim: weim at 021b8000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
compatible = "fsl,imx6q-weim";
reg = <0x021b8000 0x4000>;
interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_EIM_SLOW>;
+ fsl,weim-cs-gpr = <&gpr>;
};
ocotp: ocotp at 021bc000 {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 02378db..c2b28c0 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -893,8 +893,11 @@
};
weim: weim at 021b8000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
reg = <0x021b8000 0x4000>;
interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
+ fsl,weim-cs-gpr = <&gpr>;
};
ocotp: ocotp at 021bc000 {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 9526c38..78eb023 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -968,10 +968,13 @@
};
weim: weim at 021b8000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
compatible = "fsl,imx6sx-weim", "fsl,imx6q-weim";
reg = <0x021b8000 0x4000>;
interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_EIM_SLOW>;
+ fsl,weim-cs-gpr = <&gpr>;
};
ocotp: ocotp at 021bc000 {
--
2.7.4
^ permalink raw reply related
* [PATCH] clk: rockchip: optimize the configuration for 800MHz and 1GHz on RK3399
From: Heiko Stuebner @ 2016-11-01 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477970526-26388-1-git-send-email-zhengxing@rock-chips.com>
Am Dienstag, 1. November 2016, 11:22:06 CET schrieb Xing Zheng:
> Usually, the 800MHz and 1GHz are supplied for CPLL and NPLL in the RK3399.
> But dues to the carelessly copying from RK3036 when the RK3399 bringing up,
> the refdiv == 6, it will increase the lock time, and it is not an optimal
> configuration.
>
> Please let's fix them for the lock time and jitter are lower:
> 800 MHz:
> - FVCO == 2.4 GHz, revdiv == 1.
> 1 GHz:
> - FVCO == 3 GHz, revdiv == 1.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
applied to my clk-branch for 4.10
Thanks
Heiko
^ permalink raw reply
* [PATCH v3] ARM: dts: Add gyro and accel to APQ8060 Dragonboard
From: Bjorn Andersson @ 2016-11-01 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbipgysCjQDgvBhex7SewVaV379gL-wsZuHCY4Mz1p-aw@mail.gmail.com>
On Tue 01 Nov 04:31 PDT 2016, Linus Walleij wrote:
> On Mon, Oct 31, 2016 at 11:20 PM, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
>
> >> + interrupt-parent = <&pm8058_gpio>;
> >> + interrupts = <208 IRQ_TYPE_EDGE_FALLING>;
> >
> > To remove the need of resetting the interrupt-parent in each child you
> > can use the following form:
> >
> > interrupts-extended = <&pm8058_gpio 208 IRQ_TYPE_EDGE_FALLING>;
> >
> > But, if we correct the ssbi gpio driver then this would no longer be
> > interrupt 208 in this parent, right?. I believe that if you say
> > <&pmicintc 208 IRQ_TYPE_EDGE_FALLING> instead, which should work even
> > after we correct the gpio translation.
>
> Yes. It should be fixed everywhere but is not related to this
> patch. But I can do a two-patch series first fixing this and then
> adding the gyro+accelerometer on top referencing the MFD
> pmicintc as parent.
>
Sorry, I'm not sure I'm following.
What I tried to say was that before the correction of the GPIO block's
window this particular IRQ would be #208 in &pmicintc and #208 in
&pm8058_gpio. After the correction of the window the IRQ is #208 in
&pmicintc and #17 in &pm8058_gpio.
As such, using #208 from &pmicintc would make this work through the
correction of the GPIO driver. Perhaps I'm wrong about this?
Either way, it's no big deal. I'm fine with either path.
> > (Which probably means we need to get that redesigned, before we
> > introduce to many of these)
>
> What needs to happen is for the SSBI and SPMI GPIO to use a
> hierarchical irqdomain so their GPIO local line offset and hwirq
> are the same. Then we can reference the GPIO IRQ lines directly
> in a correct manner.
>
Right. Do you have any example of drivers getting this right? I did take
a quick look but didn't find one.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v8 1/3] ARM: dts: da850: Add cfgchip syscon node
From: David Lechner @ 2016-11-01 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b3617c00-1f1d-5ab8-23e9-a96307a53558@ti.com>
On 11/01/2016 04:53 AM, Sekhar Nori wrote:
> Hi David,
>
> On Tuesday 01 November 2016 02:17 AM, David Lechner wrote:
>> Add a syscon node for the SoC CFGCHIPn registers. It includes a child node
>> for the USB PHY that is part of this range of registers.
>>
>> Also have to add OF_DEV_AUXDATA() entry so that clock lookup will work for
>> the the USB PHY driver.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> For future, please do not combine device-tree addition and other C code into a
> single patch. I have applied this patch while splitting it into two as
> attached.
>
Sorry. I should know that by now. :-/
Thank you for fixing it for me.
^ permalink raw reply
* [PATCH v6 09/16] drivers: acpi: iort: add support for ARM SMMU platform devices creation
From: Graeme Gregory @ 2016-11-01 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028155007.GA19523@red-moon>
On Fri, Oct 28, 2016 at 04:50:07PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Oct 18, 2016 at 05:04:07PM +0100, Lorenzo Pieralisi wrote:
> > In ARM ACPI systems, IOMMU components are specified through static
> > IORT table entries. In order to create platform devices for the
> > corresponding ARM SMMU components, IORT kernel code should be made
> > able to parse IORT table entries and create platform devices
> > dynamically.
> >
> > This patch adds the generic IORT infrastructure required to create
> > platform devices for ARM SMMUs.
> >
> > ARM SMMU versions have different resources requirement therefore this
> > patch also introduces an IORT specific structure (ie iort_iommu_config)
> > that contains hooks (to be defined when the corresponding ARM SMMU
> > driver support is added to the kernel) to be used to define the
> > platform devices names, init the IOMMUs, count their resources and
> > finally initialize them.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Hanjun Guo <hanjun.guo@linaro.org>
> > Cc: Tomasz Nowicki <tn@semihalf.com>
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > ---
> > drivers/acpi/arm64/iort.c | 151 ++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 151 insertions(+)
> >
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 1433de3..2eda2f5 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -19,9 +19,11 @@
> > #define pr_fmt(fmt) "ACPI: IORT: " fmt
> >
> > #include <linux/acpi_iort.h>
> > +#include <linux/iommu.h>
> > #include <linux/kernel.h>
> > #include <linux/list.h>
> > #include <linux/pci.h>
> > +#include <linux/platform_device.h>
> > #include <linux/slab.h>
> >
> > struct iort_its_msi_chip {
> > @@ -457,6 +459,153 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
> > return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
> > }
> >
> > +struct iort_iommu_config {
> > + const char *name;
> > + int (*iommu_init)(struct acpi_iort_node *node);
> > + bool (*iommu_is_coherent)(struct acpi_iort_node *node);
> > + int (*iommu_count_resources)(struct acpi_iort_node *node);
> > + void (*iommu_init_resources)(struct resource *res,
> > + struct acpi_iort_node *node);
> > +};
> > +
> > +static __init
> > +const struct iort_iommu_config *iort_get_iommu_cfg(struct acpi_iort_node *node)
> > +{
> > + return NULL;
> > +}
> > +
> > +/**
> > + * iort_add_smmu_platform_device() - Allocate a platform device for SMMU
> > + * @node: Pointer to SMMU ACPI IORT node
> > + *
> > + * Returns: 0 on success, <0 failure
> > + */
> > +static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)
> > +{
> > + struct fwnode_handle *fwnode;
> > + struct platform_device *pdev;
> > + struct resource *r;
> > + enum dev_dma_attr attr;
> > + int ret, count;
> > + const struct iort_iommu_config *ops = iort_get_iommu_cfg(node);
> > +
> > + if (!ops)
> > + return -ENODEV;
> > +
> > + pdev = platform_device_alloc(ops->name, PLATFORM_DEVID_AUTO);
> > + if (!pdev)
> > + return PTR_ERR(pdev);
> > +
> > + count = ops->iommu_count_resources(node);
> > +
> > + r = kcalloc(count, sizeof(*r), GFP_KERNEL);
> > + if (!r) {
> > + ret = -ENOMEM;
> > + goto dev_put;
> > + }
> > +
> > + ops->iommu_init_resources(r, node);
> > +
> > + ret = platform_device_add_resources(pdev, r, count);
> > + /*
> > + * Resources are duplicated in platform_device_add_resources,
> > + * free their allocated memory
> > + */
> > + kfree(r);
> > +
> > + if (ret)
> > + goto dev_put;
> > +
> > + /*
> > + * Add a copy of IORT node pointer to platform_data to
> > + * be used to retrieve IORT data information.
> > + */
> > + ret = platform_device_add_data(pdev, &node, sizeof(node));
> > + if (ret)
> > + goto dev_put;
> > +
> > + /*
> > + * We expect the dma masks to be equivalent for
> > + * all SMMUs set-ups
> > + */
> > + pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> > +
> > + fwnode = iort_get_fwnode(node);
> > +
> > + if (!fwnode) {
> > + ret = -ENODEV;
> > + goto dev_put;
> > + }
> > +
> > + pdev->dev.fwnode = fwnode;
> > +
> > + attr = ops->iommu_is_coherent(node) ?
> > + DEV_DMA_COHERENT : DEV_DMA_NON_COHERENT;
> > +
> > + /* Configure DMA for the page table walker */
> > + acpi_dma_configure(&pdev->dev, attr);
> > +
> > + ret = platform_device_add(pdev);
> > + if (ret)
> > + goto dma_deconfigure;
> > +
> > + return 0;
> > +
> > +dma_deconfigure:
> > + acpi_dma_deconfigure(&pdev->dev);
> > +dev_put:
> > + platform_device_put(pdev);
> > +
> > + return ret;
> > +}
> > +
> > +static void __init iort_init_platform_devices(void)
> > +{
> > + struct acpi_iort_node *iort_node, *iort_end;
> > + struct acpi_table_iort *iort;
> > + struct fwnode_handle *fwnode;
> > + int i, ret;
> > +
> > + /*
> > + * iort_table and iort both point to the start of IORT table, but
> > + * have different struct types
> > + */
> > + iort = (struct acpi_table_iort *)iort_table;
> > +
> > + /* Get the first IORT node */
> > + iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort,
> > + iort->node_offset);
> > + iort_end = ACPI_ADD_PTR(struct acpi_iort_node, iort,
> > + iort_table->length);
> > +
> > + for (i = 0; i < iort->node_count; i++) {
> > + if (iort_node >= iort_end) {
> > + pr_err("iort node pointer overflows, bad table\n");
> > + return;
> > + }
> > +
> > + if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
> > + (iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
> > +
> > + fwnode = acpi_alloc_fwnode_static();
> > + if (!fwnode)
> > + return;
> > +
> > + iort_set_fwnode(iort_node, fwnode);
> > +
> > + ret = iort_add_smmu_platform_device(iort_node);
> > + if (ret) {
> > + iort_delete_fwnode(iort_node);
> > + acpi_free_fwnode_static(fwnode);
> > + return;
> > + }
> > + }
> > +
> > + iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> > + iort_node->length);
> > + }
> > +}
> > +
> > void __init acpi_iort_init(void)
> > {
> > acpi_status status;
> > @@ -468,5 +617,7 @@ void __init acpi_iort_init(void)
> > return;
> > }
> >
>
> Slipped through the cracks while rebasing v6, I should add code that
> returns if no IORT table found here to prevent calling:
>
> iort_init_platform_devices()
>
> I will update the next version, it is just a heads-up for testers,
> I can push an updated/fixed branch if needed.
>
I could do with the updated branch.
Thanks
Graeme
^ permalink raw reply
* [PATCHv2] ARM: dts: socfpga: add specific compatible strings for boards
From: Olof Johansson @ 2016-11-01 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101205652.26384-1-dinguyen@kernel.org>
On Tue, Nov 01, 2016 at 03:56:52PM -0500, Dinh Nguyen wrote:
> Add a more specific board compatible entry for all of the SOCFPGA
> Cyclone 5 based boards.
>
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
> ---
> v2: remove extra space and add a comma between compatible entries
> ---
> arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts | 2 +-
> arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 2 +-
> arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 2 +-
> arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 2 +-
> arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> index afea364..5ecd2ef 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> @@ -18,7 +18,7 @@
>
> / {
> model = "Terasic DE-0(Atlas)";
> - compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> + compatible = "terasic,de0-atlas", "altr,socfpga-cyclone5", "altr,socfpga";
>
> chosen {
> bootargs = "earlyprintk";
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
> index 424523b..e5a98e5 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
> @@ -19,7 +19,7 @@
>
> / {
> model = "Aries/DENX MCV EVK";
> - compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> + compatible = "denx,mcvevk", "altr,socfpga-cyclone5", "altr,socfpga";
>
> aliases {
> ethernet0 = &gmac0;
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
> index 15e43f4..b0577c1 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
> @@ -19,7 +19,7 @@
>
> / {
> model = "Altera SOCFPGA Cyclone V SoC Development Kit";
> - compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> + compatible = "altr,socdk", "altr,socfpga-cyclone5", "altr,socfpga";
This looks a little too generic, what if there's another dk with another
SoC down the road?
> chosen {
> bootargs = "earlyprintk";
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> index 02e22f5..c5623a7 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> @@ -19,7 +19,7 @@
>
> / {
> model = "Terasic SoCkit";
> - compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> + compatible = "terasic,sockit", "altr,socfpga-cyclone5", "altr,socfpga";
Same thing here, this seems a bit on the generic side.
-Olof
^ permalink raw reply
* [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding
From: Andrew Lunn @ 2016-11-01 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f56145b6-adb6-186b-0b75-45a9f3a6c58e@broadcom.com>
> If set, indicates the PHY will swap the TX/RX lanes to compensate
> for the board being designed with the lanes swapped.
Thanks, much better.
Andrew
^ permalink raw reply
* [PATCH v4 6/7] net: ethernet: bgmac: add NS2 support
From: Jon Mason @ 2016-11-01 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <711f4964-e655-4007-9804-f45bd47fed73@broadcom.com>
On Tue, Nov 01, 2016 at 01:34:30PM -0700, Scott Branden wrote:
> One change in this patch
>
> On 16-11-01 01:04 PM, Jon Mason wrote:
> >Add support for the variant of amac hardware present in the Broadcom
> >Northstar2 based SoCs. Northstar2 requires an additional register to be
> >configured with the port speed/duplexity (NICPM). This can be added to
> >the link callback to hide it from the instances that do not use this.
> >Also, clearing of the pending interrupts on init is required due to
> >observed issues on some platforms.
> >
> >Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> >---
> > drivers/net/ethernet/broadcom/bgmac-platform.c | 56 +++++++++++++++++++++++++-
> > drivers/net/ethernet/broadcom/bgmac.c | 3 ++
> > drivers/net/ethernet/broadcom/bgmac.h | 1 +
> > 3 files changed, 58 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
> >index aed5dc5..f6d48c7 100644
> >--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
> >+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
> >@@ -14,12 +14,21 @@
> > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >
> > #include <linux/bcma/bcma.h>
> >+#include <linux/brcmphy.h>
> > #include <linux/etherdevice.h>
> > #include <linux/of_address.h>
> > #include <linux/of_mdio.h>
> > #include <linux/of_net.h>
> > #include "bgmac.h"
> >
> >+#define NICPM_IOMUX_CTRL 0x00000008
> >+
> >+#define NICPM_IOMUX_CTRL_INIT_VAL 0x3196e000
> >+#define NICPM_IOMUX_CTRL_SPD_SHIFT 10
> >+#define NICPM_IOMUX_CTRL_SPD_10M 0
> >+#define NICPM_IOMUX_CTRL_SPD_100M 1
> >+#define NICPM_IOMUX_CTRL_SPD_1000M 2
> >+
> > static u32 platform_bgmac_read(struct bgmac *bgmac, u16 offset)
> > {
> > return readl(bgmac->plat.base + offset);
> >@@ -87,12 +96,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
> > WARN_ON(1);
> > }
> >
> >+static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> >+{
> >+ struct bgmac *bgmac = netdev_priv(net_dev);
> >+ u32 val;
> >+
> >+ if (!bgmac->plat.nicpm_base)
> >+ return;
> >+
> >+ val = NICPM_IOMUX_CTRL_INIT_VAL;
> >+ switch (bgmac->net_dev->phydev->speed) {
> >+ default:
> >+ pr_err("Unsupported speed. Defaulting to 1000Mb\n");
> This should be dev_err
It should probably be netdev_err (and there are a few instances below
that should probably be changed to netdev_err as well).
Thanks,
Jon
> >+ case SPEED_1000:
> >+ val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> >+ break;
> >+ case SPEED_100:
> >+ val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> >+ break;
> >+ case SPEED_10:
> >+ val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> >+ break;
> >+ }
> >+
> >+ writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> >+
> >+ bgmac_adjust_link(bgmac->net_dev);
> >+}
> >+
> > static int platform_phy_connect(struct bgmac *bgmac)
> > {
> > struct phy_device *phy_dev;
> >
> >- phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> >- bgmac_adjust_link);
> >+ if (bgmac->plat.nicpm_base)
> >+ phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> >+ bgmac->dev->of_node,
> >+ bgmac_nicpm_speed_set);
> >+ else
> >+ phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> >+ bgmac->dev->of_node,
> >+ bgmac_adjust_link);
> > if (!phy_dev) {
> > dev_err(bgmac->dev, "Phy connect failed\n");
> > return -ENODEV;
> >@@ -182,6 +225,14 @@ static int bgmac_probe(struct platform_device *pdev)
> > if (IS_ERR(bgmac->plat.idm_base))
> > return PTR_ERR(bgmac->plat.idm_base);
> >
> >+ regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> >+ if (regs) {
> >+ bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> >+ regs);
> >+ if (IS_ERR(bgmac->plat.nicpm_base))
> >+ return PTR_ERR(bgmac->plat.nicpm_base);
> >+ }
> >+
> > bgmac->read = platform_bgmac_read;
> > bgmac->write = platform_bgmac_write;
> > bgmac->idm_read = platform_bgmac_idm_read;
> >@@ -213,6 +264,7 @@ static int bgmac_remove(struct platform_device *pdev)
> > static const struct of_device_id bgmac_of_enet_match[] = {
> > {.compatible = "brcm,amac",},
> > {.compatible = "brcm,nsp-amac",},
> >+ {.compatible = "brcm,ns2-amac",},
> > {},
> > };
> >
> >diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> >index 4584958..a805cc8 100644
> >--- a/drivers/net/ethernet/broadcom/bgmac.c
> >+++ b/drivers/net/ethernet/broadcom/bgmac.c
> >@@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> > /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> > static void bgmac_chip_init(struct bgmac *bgmac)
> > {
> >+ /* Clear any erroneously pending interrupts */
> >+ bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> >+
> > /* 1 interrupt per received frame */
> > bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
> >
> >diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
> >index ea52ac3..b1820ea 100644
> >--- a/drivers/net/ethernet/broadcom/bgmac.h
> >+++ b/drivers/net/ethernet/broadcom/bgmac.h
> >@@ -463,6 +463,7 @@ struct bgmac {
> > struct {
> > void *base;
> > void *idm_base;
> >+ void *nicpm_base;
> > } plat;
> > struct {
> > struct bcma_device *core;
> >
^ permalink raw reply
* [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding
From: Scott Branden @ 2016-11-01 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101205913.GA27191@broadcom.com>
On 16-11-01 01:59 PM, Jon Mason wrote:
> On Tue, Nov 01, 2016 at 09:48:26PM +0100, Andrew Lunn wrote:
>>> +- enet-phy-lane-swap: If set, indicates the PHY device requires swapping the
>>> + TX/RX lanes to function properly.
>>
>> Is 'requires' the right word here? The PHY performs the actual swap of
>> the Tx/Rx lanes.
>
> What I'm trying to say here is that without the lane swapping, the PHY
> will not function properly. Thus, those PHYs require this parameter
> to work. I am open to suggestions to reword the sentence to make it
> clearer.
If set, indicates the PHY will swap the TX/RX lanes to compensate for
the board being designed with the lanes swapped.
>
> Thanks,
> Jon
>
>>
>> Andrew
^ permalink raw reply
* [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding
From: Jon Mason @ 2016-11-01 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101204826.GA21010@lunn.ch>
On Tue, Nov 01, 2016 at 09:48:26PM +0100, Andrew Lunn wrote:
> > +- enet-phy-lane-swap: If set, indicates the PHY device requires swapping the
> > + TX/RX lanes to function properly.
>
> Is 'requires' the right word here? The PHY performs the actual swap of
> the Tx/Rx lanes.
What I'm trying to say here is that without the lane swapping, the PHY
will not function properly. Thus, those PHYs require this parameter
to work. I am open to suggestions to reword the sentence to make it
clearer.
Thanks,
Jon
>
> Andrew
^ permalink raw reply
* [PATCHv2] ARM: dts: socfpga: add specific compatible strings for boards
From: Dinh Nguyen @ 2016-11-01 20:56 UTC (permalink / raw)
To: linux-arm-kernel
Add a more specific board compatible entry for all of the SOCFPGA
Cyclone 5 based boards.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
v2: remove extra space and add a comma between compatible entries
---
arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
index afea364..5ecd2ef 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
@@ -18,7 +18,7 @@
/ {
model = "Terasic DE-0(Atlas)";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "terasic,de0-atlas", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
index 424523b..e5a98e5 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
@@ -19,7 +19,7 @@
/ {
model = "Aries/DENX MCV EVK";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "denx,mcvevk", "altr,socfpga-cyclone5", "altr,socfpga";
aliases {
ethernet0 = &gmac0;
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
index 15e43f4..b0577c1 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
@@ -19,7 +19,7 @@
/ {
model = "Altera SOCFPGA Cyclone V SoC Development Kit";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "altr,socdk", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
index 02e22f5..c5623a7 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
@@ -19,7 +19,7 @@
/ {
model = "Terasic SoCkit";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "terasic,sockit", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
index 9aaf413..5b7e3c2 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
@@ -21,7 +21,7 @@
/ {
model = "Altera SOCFPGA Cyclone V SoC Macnica Sodia board";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "macnica,sodia", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
index b844473..363ee62 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
@@ -51,7 +51,7 @@
/ {
model = "samtec VIN|ING FPGA";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "samtec,vining", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "console=ttyS0,115200";
--
2.8.3
^ permalink raw reply related
* [PATCH v2 2/3] irqchip: mtk-cirq: Add mediatek mtk-cirq implement
From: Marc Zyngier @ 2016-11-01 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478001122-8664-3-git-send-email-youlin.pei@mediatek.com>
On Tue, Nov 01 2016 at 11:52:01 AM, Youlin Pei <youlin.pei@mediatek.com> wrote:
> In Mediatek SOCs, the CIRQ is a low power interrupt controller
> designed to works outside MCUSYS which comprises with Cortex-Ax
> cores,CCI and GIC.
>
> The CIRQ controller is integrated in between MCUSYS( include
> Cortex-Ax, CCI and GIC ) and interrupt sources as the second
> level interrupt controller. The external interrupts which outside
> MCUSYS will feed through CIRQ then bypass to GIC. CIRQ can monitors
> all edge trigger interupts. When an edge interrupt is triggered,
> CIRQ can record the status and generate a pulse signal to GIC when
> flush command executed.
>
> When system enters sleep mode, MCUSYS will be turned off to improve
> power consumption, also GIC is power down. The edge trigger interrupts
> will be lost in this scenario without CIRQ.
>
> This commit provides the CIRQ irqchip implement.
>
> Signed-off-by: Youlin Pei <youlin.pei@mediatek.com>
> ---
> drivers/irqchip/Makefile | 2 +-
> drivers/irqchip/irq-mtk-cirq.c | 262 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 263 insertions(+), 1 deletion(-)
> create mode 100644 drivers/irqchip/irq-mtk-cirq.c
>
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index e4dbfc8..8f33580 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -60,7 +60,7 @@ obj-$(CONFIG_BCM7120_L2_IRQ) += irq-bcm7120-l2.o
> obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
> obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
> obj-$(CONFIG_MIPS_GIC) += irq-mips-gic.o
> -obj-$(CONFIG_ARCH_MEDIATEK) += irq-mtk-sysirq.o
> +obj-$(CONFIG_ARCH_MEDIATEK) += irq-mtk-sysirq.o irq-mtk-cirq.o
> obj-$(CONFIG_ARCH_DIGICOLOR) += irq-digicolor.o
> obj-$(CONFIG_RENESAS_H8300H_INTC) += irq-renesas-h8300h.o
> obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
> diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c
> new file mode 100644
> index 0000000..fc43ef3
> --- /dev/null
> +++ b/drivers/irqchip/irq-mtk-cirq.c
> @@ -0,0 +1,262 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: Youlin.Pei <youlin.pei@mediatek.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/irq.h>
> +#include <linux/irqchip.h>
> +#include <linux/irqdomain.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +#include <linux/syscore_ops.h>
> +
> +#define CIRQ_ACK 0x40
> +#define CIRQ_MASK_SET 0xc0
> +#define CIRQ_MASK_CLR 0x100
> +#define CIRQ_SENS_SET 0x180
> +#define CIRQ_SENS_CLR 0x1c0
> +#define CIRQ_POL_SET 0x240
> +#define CIRQ_POL_CLR 0x280
> +#define CIRQ_CONTROL 0x300
> +
> +#define CIRQ_EN 0x1
> +#define CIRQ_EDGE 0x2
> +#define CIRQ_FLUSH 0x4
> +
> +#define CIRQ_IRQ_NUM 0x200
> +
> +struct mtk_cirq_chip_data {
> + void __iomem *base;
> + unsigned int ext_irq_start;
> +};
> +
> +static struct mtk_cirq_chip_data *cirq_data;
Are you guaranteed that you'll only ever have a single CIRQ in any
system?
> +
> +static void mtk_cirq_write_mask(struct irq_data *data, unsigned int offset)
> +{
> + struct mtk_cirq_chip_data *chip_data = data->chip_data;
> + unsigned int cirq_num = data->hwirq;
> + u32 mask = 1 << (cirq_num % 32);
> +
> + writel(mask, chip_data->base + offset + (cirq_num / 32) * 4);
Why can't you use the relaxed accessors?
> +}
> +
> +static void mtk_cirq_mask(struct irq_data *data)
> +{
> + mtk_cirq_write_mask(data, CIRQ_MASK_SET);
> + irq_chip_mask_parent(data);
> +}
> +
> +static void mtk_cirq_unmask(struct irq_data *data)
> +{
> + mtk_cirq_write_mask(data, CIRQ_MASK_CLR);
> + irq_chip_unmask_parent(data);
> +}
> +
> +static void mtk_cirq_eoi(struct irq_data *data)
> +{
> + mtk_cirq_write_mask(data, CIRQ_ACK);
EOI and ACK have very different semantics. What is this write actually
doing? Also, you're now doing an additional MMIO write on each interrupt
EOI, doubling its cost. Do you really need to do actually signal the HW
that we've EOIed an interrupt? I would have hoped that you'd be able to
put it in "bypass" mode as long as you're not suspending...
> + irq_chip_eoi_parent(data);
> +}
> +
> +static int mtk_cirq_set_type(struct irq_data *data, unsigned int type)
> +{
> + int ret;
> +
> + switch (type & IRQ_TYPE_SENSE_MASK) {
> + case IRQ_TYPE_EDGE_FALLING:
> + mtk_cirq_write_mask(data, CIRQ_POL_CLR);
> + mtk_cirq_write_mask(data, CIRQ_SENS_CLR);
> + break;
> + case IRQ_TYPE_EDGE_RISING:
> + mtk_cirq_write_mask(data, CIRQ_POL_SET);
> + mtk_cirq_write_mask(data, CIRQ_SENS_CLR);
> + break;
> + case IRQ_TYPE_LEVEL_LOW:
> + mtk_cirq_write_mask(data, CIRQ_POL_CLR);
> + mtk_cirq_write_mask(data, CIRQ_SENS_SET);
> + break;
> + case IRQ_TYPE_LEVEL_HIGH:
> + mtk_cirq_write_mask(data, CIRQ_POL_SET);
> + mtk_cirq_write_mask(data, CIRQ_SENS_SET);
> + break;
> + default:
> + break;
> + }
> +
> + data = data->parent_data;
> + ret = data->chip->irq_set_type(data, type);
> + return ret;
> +}
> +
> +static struct irq_chip mtk_cirq_chip = {
> + .name = "MT_CIRQ",
> + .irq_mask = mtk_cirq_mask,
> + .irq_unmask = mtk_cirq_unmask,
> + .irq_eoi = mtk_cirq_eoi,
> + .irq_set_type = mtk_cirq_set_type,
> + .irq_retrigger = irq_chip_retrigger_hierarchy,
> +#ifdef CONFIG_SMP
> + .irq_set_affinity = irq_chip_set_affinity_parent,
> +#endif
> +};
> +
> +static int mtk_cirq_domain_translate(struct irq_domain *d,
> + struct irq_fwspec *fwspec,
> + unsigned long *hwirq,
> + unsigned int *type)
> +{
> + if (is_of_node(fwspec->fwnode)) {
> + if (fwspec->param_count != 3)
> + return -EINVAL;
> +
> + /* No PPI should point to this domain */
> + if (fwspec->param[0] != 0)
> + return -EINVAL;
> +
> + /* cirq support irq number check */
> + if (fwspec->param[1] < cirq_data->ext_irq_start)
> + return -EINVAL;
> +
> + *hwirq = fwspec->param[1] - cirq_data->ext_irq_start;
What if the result is > CIRQ_IRQ_NUM?
> + *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int mtk_cirq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> + unsigned int nr_irqs, void *arg)
> +{
> + int i;
> + irq_hw_number_t hwirq;
> + struct irq_fwspec *fwspec = arg;
> + struct irq_fwspec parent_fwspec = *fwspec;
> +
> + if (fwspec->param_count != 3)
> + return -EINVAL;
> +
> + /* cirq doesn't support PPI */
> + if (fwspec->param[0])
> + return -EINVAL;
> +
> + if (fwspec->param[1] < cirq_data->ext_irq_start)
> + return -EINVAL;
> +
> + hwirq = fwspec->param[1] - cirq_data->ext_irq_start;
All this is a pure copy of mtk_cirq_domain_translate(). Please use it.
> + for (i = 0; i < nr_irqs; i++)
> + irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> + &mtk_cirq_chip,
> + domain->host_data);
This is a bit silly. This loop only exists for the benefit of MSI
support, which we're not dealing with here. So please stick a
if (WARN_ON(nr_irqs != 1))
return -EINVAL;
and drop the loop.
> +
> + parent_fwspec.fwnode = domain->parent->fwnode;
> + return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs,
> + &parent_fwspec);
> +}
> +
> +static const struct irq_domain_ops cirq_domain_ops = {
> + .translate = mtk_cirq_domain_translate,
> + .alloc = mtk_cirq_domain_alloc,
> + .free = irq_domain_free_irqs_common,
> +};
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int mtk_cirq_suspend(void)
> +{
> + u32 value;
> +
> + /* set edge_only mode, record edge-triggerd interrupts */
> + /* enable cirq */
> + value = readl_relaxed(cirq_data->base + CIRQ_CONTROL);
> + value |= (CIRQ_EDGE | CIRQ_EN);
> + writel(value, cirq_data->base + CIRQ_CONTROL);
You're mixing relaxed and non-relaxed accessors. Why?
> + return 0;
> +}
> +
> +static void mtk_cirq_resume(void)
> +{
> + u32 value;
> +
> + /* flush recored interrupts, will send signals to parent controller */
> + value = readl_relaxed(cirq_data->base + CIRQ_CONTROL);
> + writel(value | CIRQ_FLUSH, cirq_data->base + CIRQ_CONTROL);
Same remark.
> +
> + /* disable cirq */
> + value = readl_relaxed(cirq_data->base + CIRQ_CONTROL);
> + value &= ~(CIRQ_EDGE | CIRQ_EN);
> + writel(value, cirq_data->base + CIRQ_CONTROL);
So from this, I infer that CIRQ is not enabled when the kernel is
running (not suspended). It really makes me wonder why you need to do
anything in the EOI callback.
> +}
> +
> +static struct syscore_ops mtk_cirq_syscore_ops = {
> + .suspend = mtk_cirq_suspend,
> + .resume = mtk_cirq_resume,
> +};
> +
> +static void mtk_cirq_syscore_init(void)
> +{
> + register_syscore_ops(&mtk_cirq_syscore_ops);
> +}
> +#else
> +static inline void mtk_cirq_syscore_init(void) {}
> +#endif
> +
> +static int __init mtk_cirq_of_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + struct irq_domain *domain, *domain_parent;
> + int ret;
> +
> + domain_parent = irq_find_host(parent);
> + if (!domain_parent) {
> + pr_err("mtk_cirq: interrupt-parent not found\n");
> + return -EINVAL;
> + }
> +
> + cirq_data = kzalloc(sizeof(*cirq_data), GFP_KERNEL);
> + if (!cirq_data)
> + return -ENOMEM;
> +
> + cirq_data->base = of_iomap(node, 0);
> + if (!cirq_data->base) {
> + pr_err("mtk_cirq: unable to map cirq register\n");
> + ret = -ENXIO;
> + goto out_free;
> + }
> +
> + ret = of_property_read_u32(node, "mediatek,ext-irq-start",
> + &cirq_data->ext_irq_start);
> + if (ret)
> + goto out_unmap;
> +
> + domain = irq_domain_add_hierarchy(domain_parent, 0, CIRQ_IRQ_NUM, node,
> + &cirq_domain_ops, cirq_data);
So you support at most 512 interrupts, and yet the GIC supports up to
987 SPIs. What happens for interrupt lines that out of the CIRQ range?
Maybe having an explicit range in DT would be a good thing. That also
brings back the question of having a single CIRQ in the system...
> + if (!domain) {
> + ret = -ENOMEM;
> + goto out_unmap;
> + }
> +
> + mtk_cirq_syscore_init();
> +
> + return 0;
> +
> +out_unmap:
> + iounmap(cirq_data->base);
> +out_free:
> + kfree(cirq_data);
> + return ret;
> +}
> +
> +IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init);
Thanks,
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply
* [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding
From: Andrew Lunn @ 2016-11-01 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478030682-27012-3-git-send-email-jon.mason@broadcom.com>
> +- enet-phy-lane-swap: If set, indicates the PHY device requires swapping the
> + TX/RX lanes to function properly.
Is 'requires' the right word here? The PHY performs the actual swap of
the Tx/Rx lanes.
Andrew
^ permalink raw reply
* [PATCH v4 6/7] net: ethernet: bgmac: add NS2 support
From: Scott Branden @ 2016-11-01 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478030682-27012-7-git-send-email-jon.mason@broadcom.com>
One change in this patch
On 16-11-01 01:04 PM, Jon Mason wrote:
> Add support for the variant of amac hardware present in the Broadcom
> Northstar2 based SoCs. Northstar2 requires an additional register to be
> configured with the port speed/duplexity (NICPM). This can be added to
> the link callback to hide it from the instances that do not use this.
> Also, clearing of the pending interrupts on init is required due to
> observed issues on some platforms.
>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/bgmac-platform.c | 56 +++++++++++++++++++++++++-
> drivers/net/ethernet/broadcom/bgmac.c | 3 ++
> drivers/net/ethernet/broadcom/bgmac.h | 1 +
> 3 files changed, 58 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
> index aed5dc5..f6d48c7 100644
> --- a/drivers/net/ethernet/broadcom/bgmac-platform.c
> +++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
> @@ -14,12 +14,21 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include <linux/bcma/bcma.h>
> +#include <linux/brcmphy.h>
> #include <linux/etherdevice.h>
> #include <linux/of_address.h>
> #include <linux/of_mdio.h>
> #include <linux/of_net.h>
> #include "bgmac.h"
>
> +#define NICPM_IOMUX_CTRL 0x00000008
> +
> +#define NICPM_IOMUX_CTRL_INIT_VAL 0x3196e000
> +#define NICPM_IOMUX_CTRL_SPD_SHIFT 10
> +#define NICPM_IOMUX_CTRL_SPD_10M 0
> +#define NICPM_IOMUX_CTRL_SPD_100M 1
> +#define NICPM_IOMUX_CTRL_SPD_1000M 2
> +
> static u32 platform_bgmac_read(struct bgmac *bgmac, u16 offset)
> {
> return readl(bgmac->plat.base + offset);
> @@ -87,12 +96,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
> WARN_ON(1);
> }
>
> +static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> +{
> + struct bgmac *bgmac = netdev_priv(net_dev);
> + u32 val;
> +
> + if (!bgmac->plat.nicpm_base)
> + return;
> +
> + val = NICPM_IOMUX_CTRL_INIT_VAL;
> + switch (bgmac->net_dev->phydev->speed) {
> + default:
> + pr_err("Unsupported speed. Defaulting to 1000Mb\n");
This should be dev_err
> + case SPEED_1000:
> + val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_100:
> + val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_10:
> + val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + }
> +
> + writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> +
> + bgmac_adjust_link(bgmac->net_dev);
> +}
> +
> static int platform_phy_connect(struct bgmac *bgmac)
> {
> struct phy_device *phy_dev;
>
> - phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> - bgmac_adjust_link);
> + if (bgmac->plat.nicpm_base)
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_nicpm_speed_set);
> + else
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_adjust_link);
> if (!phy_dev) {
> dev_err(bgmac->dev, "Phy connect failed\n");
> return -ENODEV;
> @@ -182,6 +225,14 @@ static int bgmac_probe(struct platform_device *pdev)
> if (IS_ERR(bgmac->plat.idm_base))
> return PTR_ERR(bgmac->plat.idm_base);
>
> + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> + if (regs) {
> + bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> + regs);
> + if (IS_ERR(bgmac->plat.nicpm_base))
> + return PTR_ERR(bgmac->plat.nicpm_base);
> + }
> +
> bgmac->read = platform_bgmac_read;
> bgmac->write = platform_bgmac_write;
> bgmac->idm_read = platform_bgmac_idm_read;
> @@ -213,6 +264,7 @@ static int bgmac_remove(struct platform_device *pdev)
> static const struct of_device_id bgmac_of_enet_match[] = {
> {.compatible = "brcm,amac",},
> {.compatible = "brcm,nsp-amac",},
> + {.compatible = "brcm,ns2-amac",},
> {},
> };
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> index 4584958..a805cc8 100644
> --- a/drivers/net/ethernet/broadcom/bgmac.c
> +++ b/drivers/net/ethernet/broadcom/bgmac.c
> @@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> static void bgmac_chip_init(struct bgmac *bgmac)
> {
> + /* Clear any erroneously pending interrupts */
> + bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> +
> /* 1 interrupt per received frame */
> bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
> index ea52ac3..b1820ea 100644
> --- a/drivers/net/ethernet/broadcom/bgmac.h
> +++ b/drivers/net/ethernet/broadcom/bgmac.h
> @@ -463,6 +463,7 @@ struct bgmac {
> struct {
> void *base;
> void *idm_base;
> + void *nicpm_base;
> } plat;
> struct {
> struct bcma_device *core;
>
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: add specific compatible strings for boards
From: Dinh Nguyen @ 2016-11-01 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6ebcc3e9-37b7-7c27-a111-9fc663d07864@mentor.com>
Hi Vladimir,
On 11/01/2016 03:10 PM, Vladimir Zapolskiy wrote:
> Hi Dinh,
>
> On 11/01/2016 05:38 PM, Dinh Nguyen wrote:
>> Add a more specific board compatible entry for all of the SOCFPGA
>> Cyclone 5 based boards.
>>
>> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
>> ---
>> arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts | 2 +-
>> arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
>> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 2 +-
>> arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 2 +-
>> arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 2 +-
>> arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 2 +-
>> 6 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
>> b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
>> index afea364..5ecd2ef 100644
>> --- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
>> +++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
>> @@ -18,7 +18,7 @@
>>
>> / {
>> model = "Terasic DE-0(Atlas)";
>> - compatible = "altr,socfpga-cyclone5", "altr,socfpga";
>> + compatible = "terasic,de0-atlas", "altr,socfpga-cyclone5",
>> "altr,socfpga";
>>
>> chosen {
>> bootargs = "earlyprintk";
>> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
>> b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
>> index 424523b..668d77c 100644
>> --- a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
>> +++ b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
>> @@ -19,7 +19,7 @@
>>
>> / {
>> model = "Aries/DENX MCV EVK";
>> - compatible = "altr,socfpga-cyclone5", "altr,socfpga";
>> + compatible = "denx, mcvevk", "altr,socfpga-cyclone5",
>> "altr,socfpga";
>
> Redundant space ^
OK
>
>>
>> aliases {
>> ethernet0 = &gmac0;
>> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
>> b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
>> index 15e43f4..b0577c1 100644
>> --- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
>> +++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
>> @@ -19,7 +19,7 @@
>>
>> / {
>> model = "Altera SOCFPGA Cyclone V SoC Development Kit";
>> - compatible = "altr,socfpga-cyclone5", "altr,socfpga";
>> + compatible = "altr,socdk", "altr,socfpga-cyclone5", "altr,socfpga";
>>
>> chosen {
>> bootargs = "earlyprintk";
>> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
>> b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
>> index 02e22f5..c5623a7 100644
>> --- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
>> +++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
>> @@ -19,7 +19,7 @@
>>
>> / {
>> model = "Terasic SoCkit";
>> - compatible = "altr,socfpga-cyclone5", "altr,socfpga";
>> + compatible = "terasic,sockit", "altr,socfpga-cyclone5",
>> "altr,socfpga";
>>
>> chosen {
>> bootargs = "earlyprintk";
>> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
>> b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
>> index 9aaf413..992ae49 100644
>> --- a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
>> +++ b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
>> @@ -21,7 +21,7 @@
>>
>> / {
>> model = "Altera SOCFPGA Cyclone V SoC Macnica Sodia board";
>> - compatible = "altr,socfpga-cyclone5", "altr,socfpga";
>> + compatible = "macnica, sodia", "altr,socfpga-cyclone5",
>> "altr,socfpga";
>
> Redundant space ^
Ok,
>
> If it is not yet done, you may consider to add Macnica to
> Documentation/devicetree/bindings/vendor-prefixes.txt
>
Yes, I have sent separate patches to add the vendor prefixes.
>>
>> chosen {
>> bootargs = "earlyprintk";
>> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
>> b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
>> index b844473..78b187e 100644
>> --- a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
>> +++ b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
>> @@ -51,7 +51,7 @@
>>
>> / {
>> model = "samtec VIN|ING FPGA";
>> - compatible = "altr,socfpga-cyclone5", "altr,socfpga";
>> + compatible = "samtec,vining". "altr,socfpga-cyclone5",
>> "altr,socfpga";
>
> Comma is expected here ^
Ok,
>
> Probably Terasic and Samtec are also not in the vendor-prefixes.txt list,
> usually checkpatch complains about it.
Yes, I have sent patches for the vendor prefixes. Thanks for reviewing.
Dinh
^ 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