* [PATCH 2/2] MAINTAINERS: Add myself as co-maintainer to fpga mgr framework.
From: Greg Kroah-Hartman @ 2016-11-22 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <47eb36a7-ee48-53bd-fbdc-15225c3147ec@xilinx.com>
On Tue, Nov 22, 2016 at 08:48:57AM +0100, Michal Simek wrote:
> On 22.11.2016 03:29, atull wrote:
> > On Mon, 21 Nov 2016, Moritz Fischer wrote:
> >
> >> Add myself as co-maintainer to fpga mgr framework.
> >>
> >> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> >> Cc: Alan Tull <atull@opensource.altera.com>
> >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> Cc: linux-kernel at vger.kernel.org
> >> Cc: linux-fpga at vger.kernel.org
> >> ---
> >> Hi all,
> >>
> >> Lately we've fallen behind a bit on reviewing patches lately.
> >
> > Hi Moritz,
> >
> > drivers/fpga has been in the upstream kernel a year now. Most of that
> > time, traffic has been very slow. Recently we had more traffic while
> > I was travelling and moving to a new office, both cases leaving me
> > with bad network connectivity. Things will probably return to normal.
> > I appreciate your passion and all your effort reviewing stuff. I
> > don't see a need for two maintainers at this point.
>
> TBH. I think it is not a bad option. I do normally have backup person
> for all repos I do maintain. It doesn't mean that second maintainer does
> something but it has all accesses to repos you maintain.
> It means if something really happens to you (hopefully not) than this
> person can continue in this work without any delay which is not a bad
> thing.
> It is really just about talking to each other what that second person
> will do - probably just review patches as is done now. You can also
> learn from each other.
> I would like to be involved more in this but unfortunately I don't have
> enough time to do it properly.
>
> Regarding maintaining this repo. It is just standard process. Apply
> sensible things, well described and test it. And then send pull request
> to Greg based on signed tags and you are done.
> Greg should told you what should be the base which you should use for
> pull request. Someone is taking patches based on rc1 tag, someone is
> rebasing it on the final tag.
Greg doesn't care what base you use, as long as you don't rebase
patches. What subsystem does that? I need to go yell at someone...
And I take patches just as easily, what ever works best for the
subsystem.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2] clk: qoriq: added ls1012a clock configuration
From: yuantian.tang at nxp.com @ 2016-11-22 8:14 UTC (permalink / raw)
To: linux-arm-kernel
From: Tang Yuantian <Yuantian.Tang@nxp.com>
Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
v2:
- remove commit message as it is duplicated to title
drivers/clk/clk-qoriq.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 1bece0f..65c21d7 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -202,6 +202,14 @@ static const struct clockgen_muxinfo ls1021a_cmux = {
}
};
+static const struct clockgen_muxinfo ls1012a_cmux = {
+ {
+ [0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
+ {},
+ [2] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
+ }
+};
+
static const struct clockgen_muxinfo t1040_cmux = {
{
[0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
@@ -482,6 +490,16 @@ static const struct clockgen_chipinfo chipinfo[] = {
.pll_mask = 0x03,
},
{
+ .compat = "fsl,ls1012a-clockgen",
+ .cmux_groups = {
+ &ls1012a_cmux
+ },
+ .cmux_to_group = {
+ 0, -1
+ },
+ .pll_mask = 0x03,
+ },
+ {
.compat = "fsl,ls1043a-clockgen",
.init_periph = t2080_init_periph,
.cmux_groups = {
@@ -1282,6 +1300,7 @@ static void __init clockgen_init(struct device_node *np)
CLK_OF_DECLARE(qoriq_clockgen_1, "fsl,qoriq-clockgen-1.0", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_2, "fsl,qoriq-clockgen-2.0", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1021a, "fsl,ls1021a-clockgen", clockgen_init);
+CLK_OF_DECLARE(qoriq_clockgen_ls1012a, "fsl,ls1012a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1043a, "fsl,ls1043a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls2080a, "fsl,ls2080a-clockgen", clockgen_init);
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH] clk: qoriq: added ls1012a clock configuration
From: Y.T. Tang @ 2016-11-22 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479279262.21746.40.camel@buserror.net>
Hi Scott,
> -----Original Message-----
> From: Scott Wood [mailto:oss at buserror.net]
> Sent: Wednesday, November 16, 2016 2:54 PM
> To: Y.T. Tang <yuantian.tang@nxp.com>; mturquette at baylibre.com
> Cc: sboyd at codeaurora.org; linux-kernel at vger.kernel.org; Scott Wood
> <scott.wood@nxp.com>; linux-clk at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH] clk: qoriq: added ls1012a clock configuration
>
> On Wed, 2016-11-16 at 13:58 +0800, yuantian.tang at nxp.com wrote:
> > From: Tang Yuantian <Yuantian.Tang@nxp.com>
> >
> > Added ls1012a clock configuation information.
>
> Do we really need the same line in the changelog twice?
>
> >
> > Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
> > ---
> > ?drivers/clk/clk-qoriq.c | 19 +++++++++++++++++++
> > ?1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c index
> > 1bece0f..563d874 100644
> > --- a/drivers/clk/clk-qoriq.c
> > +++ b/drivers/clk/clk-qoriq.c
> > @@ -202,6 +202,14 @@ static const struct clockgen_muxinfo ls1021a_cmux
> = {
> > ? }
> > ?};
> >
> > +static const struct clockgen_muxinfo ls1012a_cmux = {
> > + {
> > + [0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
> > + {},
> > + [2] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
> > + }
> > +};
> > +
>
> Based on the "ls1021a_cmux" in the context it looks like this patch is
> intended to apply on top
> of?https://patchwork.kernel.org/patch/8923541/?but I don't see any mention
> of that.
>
I saw this patch had been merged already.
Regards,
Yuantian
> > ?static const struct clockgen_muxinfo t1040_cmux = {
> > ? {
> > ? [0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 }, @@ -482,6
> +490,16 @@
> > static const struct clockgen_chipinfo chipinfo[] = {
> > ? .pll_mask = 0x03,
> > ? },
> > ? {
> > + .compat = "fsl,ls1012a-clockgen",
> > + .cmux_groups = {
> > + &ls1012a_cmux
> > + },
> > + .cmux_to_group = {
> > + 0, -1
> > + },
> > + .pll_mask = 0x03,
> > + },
> > + {
> > ? .compat = "fsl,ls1043a-clockgen",
> > ? .init_periph = t2080_init_periph,
> > ? .cmux_groups = {
> > @@ -1284,6 +1302,7 @@ CLK_OF_DECLARE(qoriq_clockgen_2,
> > "fsl,qoriq-clockgen- 2.0", clockgen_init);
> > ?CLK_OF_DECLARE(qoriq_clockgen_ls1021a, "fsl,ls1021a-clockgen",
> > clockgen_init);
> > ?CLK_OF_DECLARE(qoriq_clockgen_ls1043a, "fsl,ls1043a-clockgen",
> > clockgen_init);
> > ?CLK_OF_DECLARE(qoriq_clockgen_ls2080a, "fsl,ls2080a-clockgen",
> > clockgen_init);
> > +CLK_OF_DECLARE(qoriq_clockgen_ls1012a, "fsl,ls1012a-clockgen",
> > clockgen_init);
>
> Please keep these lists of chips sorted (or as close as you can in the case of
> the cmux structs which already have some sorting issues).
>
> -Scott
^ permalink raw reply
* [PATCH 2/2] MAINTAINERS: Add myself as co-maintainer to fpga mgr framework.
From: Michal Simek @ 2016-11-22 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122080713.GB22441@kroah.com>
On 22.11.2016 09:07, Greg Kroah-Hartman wrote:
> On Tue, Nov 22, 2016 at 08:48:57AM +0100, Michal Simek wrote:
>> On 22.11.2016 03:29, atull wrote:
>>> On Mon, 21 Nov 2016, Moritz Fischer wrote:
>>>
>>>> Add myself as co-maintainer to fpga mgr framework.
>>>>
>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>> Cc: Alan Tull <atull@opensource.altera.com>
>>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>> Cc: linux-kernel at vger.kernel.org
>>>> Cc: linux-fpga at vger.kernel.org
>>>> ---
>>>> Hi all,
>>>>
>>>> Lately we've fallen behind a bit on reviewing patches lately.
>>>
>>> Hi Moritz,
>>>
>>> drivers/fpga has been in the upstream kernel a year now. Most of that
>>> time, traffic has been very slow. Recently we had more traffic while
>>> I was travelling and moving to a new office, both cases leaving me
>>> with bad network connectivity. Things will probably return to normal.
>>> I appreciate your passion and all your effort reviewing stuff. I
>>> don't see a need for two maintainers at this point.
>>
>> TBH. I think it is not a bad option. I do normally have backup person
>> for all repos I do maintain. It doesn't mean that second maintainer does
>> something but it has all accesses to repos you maintain.
>> It means if something really happens to you (hopefully not) than this
>> person can continue in this work without any delay which is not a bad
>> thing.
>> It is really just about talking to each other what that second person
>> will do - probably just review patches as is done now. You can also
>> learn from each other.
>> I would like to be involved more in this but unfortunately I don't have
>> enough time to do it properly.
>>
>> Regarding maintaining this repo. It is just standard process. Apply
>> sensible things, well described and test it. And then send pull request
>> to Greg based on signed tags and you are done.
>> Greg should told you what should be the base which you should use for
>> pull request. Someone is taking patches based on rc1 tag, someone is
>> rebasing it on the final tag.
>
> Greg doesn't care what base you use, as long as you don't rebase
> patches. What subsystem does that? I need to go yell at someone...
:-) Not sure if there is any subsystem which use this.
And for my microblaze tree I do normally base patches on the top of
rc7/8 or final tag but that's done mostly because I collect patches at
that time. But IIRC when I started with this someone mentioned that for
small number of patches this is fine.
Thanks,
Michal
^ permalink raw reply
* Synopsys Ethernet QoS Driver
From: Ozgur Karatas @ 2016-11-22 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <937252db-9538-2cf6-c8fa-82b558531c51@st.com>
Hello all,
I think, ethtool and mdio don't work because the tool's not support to "QoS", right?
Maybe, need a new API. I'm looking for dwceqos code but "tc" tools is very idea.
I hope to be me always helpful.
Regards,
Ozgur
21.11.2016, 16:38, "Giuseppe CAVALLARO" <peppe.cavallaro@st.com>:
> Hello Joao
>
> On 11/21/2016 2:48 PM, Joao Pinto wrote:
>> ?Synopsys QoS IP is a separated hardware component, so it should be reusable by
>> ?all implementations using it and so have its own "core driver" and platform +
>> ?pci glue drivers. This is necessary for example in hardware validation, where
>> ?you prototype an IP and instantiate its drivers and test it.
>>
>> ?Was there a strong reason to integrate QoS features directly in stmmac and not
>> ?in synopsys/dwc_eth_qos.*?
>
> We decided to enhance the stmmac on supporting the QoS for several
> reasons; for example the common APIs that the driver already exposed and
> actually suitable for other SYNP chips. Then, PTP, EEE,
> S/RGMII, MMC could be shared among different chips with a minimal
> effort. This meant a lot of code already ready.
>
> For sure, the net-core, Ethtool, mdio parts were reused. Same for the
> glue logic files.
> For the latter, this helped to easily bring-up new platforms also
> because the stmmac uses the HW cap register to auto-configure many
> parts of the MAC core, DMA and modules. This helped many users, AFAIK.
>
> For validation purpose, this is my experience, the stmmac helped
> a lot because people used the same code to validate different HW
> and it was easy to switch to a platform to another one in order to
> verify / check if the support was ok or if a regression was introduced.
> This is important for complex supports like PTP or EEE.
>
> Hoping this can help.
>
> Do not hesitate to contact me for further details
>
> peppe
^ permalink raw reply
* linux-next: manual merge of the clk tree with the arm-soc tree
From: Stephen Rothwell @ 2016-11-22 8:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the clk tree got conflicts in:
arch/arm/boot/dts/r8a7779.dtsi
arch/arm/boot/dts/r8a7790.dtsi
arch/arm/boot/dts/r8a7791.dtsi
arch/arm/boot/dts/r8a7792.dtsi
arch/arm/boot/dts/r8a7793.dtsi
arch/arm/boot/dts/r8a7794.dtsi
arch/arm/mach-shmobile/setup-rcar-gen2.c
arch/arm64/boot/dts/renesas/r8a7795.dtsi
arch/arm64/boot/dts/renesas/r8a7796.dtsi
drivers/soc/renesas/Makefile
between various commits from the arm-soc tree and commits from the
clk tree.
It was just too much at this time of day, so please talk to each other
and figure out how to fix these up. I have used the clk tree from
next-20161117 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH 1/6] reset: hisilicon: add reset core
From: Arnd Bergmann @ 2016-11-22 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479800961-6249-2-git-send-email-zhangfei.gao@linaro.org>
On Tuesday, November 22, 2016 3:49:16 PM CET Zhangfei Gao wrote:
> @@ -1,8 +1,8 @@
> obj-y += core.o
> -obj-y += hisilicon/
> obj-$(CONFIG_ARCH_STI) += sti/
> obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
> obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
> +obj-$(CONFIG_ARCH_HISI) += hisilicon/
> obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
> obj-$(CONFIG_RESET_MESON) += reset-meson.o
> obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
Please leave the obj-y line, otherwise the COMPILE_TEST variant won't work.
Arnd
^ permalink raw reply
* [PATCH] ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation
From: Linus Walleij @ 2016-11-22 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152047.3336967-1-arnd@arndb.de>
On Wed, Nov 16, 2016 at 4:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> This function clearly never worked and always returns true,
> as pointed out by gcc-7:
>
> arch/arm/mach-ux500/pm.c: In function 'prcmu_is_cpu_in_wfi':
> arch/arm/mach-ux500/pm.c:137:212: error: ?: using integer constants in boolean context, the expression will always evaluate to 'true' [-Werror=int-in-bool-context]
>
> With the added braces, the condition actually makes sense.
>
> Fixes: 34fe6f107eab ("mfd : Check if the other db8500 core is in WFI")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Will you apply it directly to ARM SoC or should I queue it and
send it with a pull request?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/6] dt-bindings: change hi6220-reset.txt according to reset-hi6220.c
From: Arnd Bergmann @ 2016-11-22 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479800961-6249-5-git-send-email-zhangfei.gao@linaro.org>
On Tuesday, November 22, 2016 3:49:19 PM CET Zhangfei Gao wrote:
> Required properties:
> - compatible: should be one of the following:
> - - "hisilicon,hi6220-sysctrl", "syscon" : For peripheral reset controller.
> - - "hisilicon,hi6220-mediactrl", "syscon" : For media reset controller.
> -- reg: should be register base and length as documented in the
> - datasheet
> + - "hisilicon,hi6220-reset-sysctrl" : For peripheral reset controller.
> + - "hisilicon,hi6220-reset-mediactrl" : For media reset controller.
> +- hisi,rst-syscon: phandle of the reset's syscon.
> - #reset-cells: 1, see below
>
Please keep the old strings around for compatibility.
Arnd
^ permalink raw reply
* [PATCH 5/6] reset: hisilicon: Use new driver reset-hi6222
From: Arnd Bergmann @ 2016-11-22 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479800961-6249-6-git-send-email-zhangfei.gao@linaro.org>
On Tuesday, November 22, 2016 3:49:20 PM CET Zhangfei Gao wrote:
>
> -#define PERIPH_RSTDIS0_MMC0 0x000
> -#define PERIPH_RSTDIS0_MMC1 0x001
> -#define PERIPH_RSTDIS0_MMC2 0x002
> -#define PERIPH_RSTDIS0_NANDC 0x003
> -#define PERIPH_RSTDIS0_USBOTG_BUS 0x004
> -#define PERIPH_RSTDIS0_POR_PICOPHY 0x005
> -#define PERIPH_RSTDIS0_USBOTG 0x006
> -#define PERIPH_RSTDIS0_USBOTG_32K 0x007
> -#define PERIPH_RSTDIS1_HIFI 0x100
> -#define PERIPH_RSTDIS1_DIGACODEC 0x105
> +/* reset in sysctrl */
> +#define PERIPH_RSTDIS0_MMC0 0
> +#define PERIPH_RSTDIS0_MMC1 1
> +#define PERIPH_RSTDIS0_MMC2 2
> +#define PERIPH_RSTDIS0_NANDC 3
> +#define PERIPH_RSTDIS0_USBOTG_BUS 4
> +#define PERIPH_RSTDIS0_POR_PICOPHY 5
> +#define PERIPH_RSTDIS0_USBOTG 6
> +#define PERIPH_RSTDIS0_USBOTG_32K 7
> +#define PERIPH_RSTDIS1_HIFI 8
You can't redefined the binding here, this is part of the ABI.
You can however add new numbers as long as the old ones keep
working.
Arnd
^ permalink raw reply
* [PATCH 3/6] reset: hisilicon: add reset-hi3660
From: Arnd Bergmann @ 2016-11-22 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479800961-6249-4-git-send-email-zhangfei.gao@linaro.org>
On Tuesday, November 22, 2016 3:49:18 PM CET Zhangfei Gao wrote:
>
> +static const struct hisi_reset_channel_data hi3660_iomcu_rst[] = {
> + [HI3660_RST_I2C0] = HISI_RST_SEP(0x20, 3),
> + [HI3660_RST_I2C1] = HISI_RST_SEP(0x20, 4),
> + [HI3660_RST_I2C2] = HISI_RST_SEP(0x20, 5),
> + [HI3660_RST_I2C6] = HISI_RST_SEP(0x20, 27),
> +};
> +
> +static struct hisi_reset_controller_data hi3660_iomcu_controller = {
> + .nr_channels = ARRAY_SIZE(hi3660_iomcu_rst),
> + .channels = hi3660_iomcu_rst,
> +};
> +
> +static const struct hisi_reset_channel_data hi3660_crgctrl_rst[] = {
> + [HI3660_RST_I2C3] = HISI_RST_SEP(0x78, 7),
> + [HI3660_RST_I2C4] = HISI_RST_SEP(0x78, 27),
> + [HI3660_RST_I2C7] = HISI_RST_SEP(0x60, 14),
> + [HI3660_RST_SD] = HISI_RST_SEP(0x90, 18),
> + [HI3660_RST_SDIO] = HISI_RST_SEP(0x90, 20),
> + [HI3660_RST_UFS] = HISI_RST_SEP(0x84, 12),
> + [HI3660_RST_UFS_ASSERT] = HISI_RST_SEP(0x84, 7),
> + [HI3660_RST_PCIE_SYS] = HISI_RST_SEP(0x84, 26),
> + [HI3660_RST_PCIE_PHY] = HISI_RST_SEP(0x84, 27),
> + [HI3660_RST_PCIE_BUS] = HISI_RST_SEP(0x84, 31),
> + [HI3660_RST_USB3OTG_PHY] = HISI_RST_SEP(0x90, 3),
> + [HI3660_RST_USB3OTG] = HISI_RST_SEP(0x90, 5),
> + [HI3660_RST_USB3OTG_32K] = HISI_RST_SEP(0x90, 6),
> + [HI3660_RST_USB3OTG_AHB] = HISI_RST_SEP(0x90, 7),
> + [HI3660_RST_USB3OTG_MUX] = HISI_RST_SEP(0x90, 8),
> +};
I think you can avoid the trap of the ABI incompatibility if
you just define those as in the binding as tuples, using #reset-cells=2.
In particular for the first set, it seems really silly to redefine
the numbers when there is just a simple integer number.
Arnd
^ permalink raw reply
* [PATCH] pinctrl: stm32: use builtin_platform_driver
From: Linus Walleij @ 2016-11-22 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <910c70b66426b79a3c045d17c9fea8dbf80b6ceb.1479457288.git.geliangtang@gmail.com>
On Fri, Nov 18, 2016 at 3:12 PM, Geliang Tang <geliangtang@gmail.com> wrote:
> Use builtin_platform_driver() helper to simplify the code.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation
From: Arnd Bergmann @ 2016-11-22 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb1RdDCjT3ChiJdF8WZHp-Sb1un1tvSOh3uShZn2DaZ-Q@mail.gmail.com>
On Tuesday, November 22, 2016 9:47:20 AM CET Linus Walleij wrote:
> On Wed, Nov 16, 2016 at 4:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > This function clearly never worked and always returns true,
> > as pointed out by gcc-7:
> >
> > arch/arm/mach-ux500/pm.c: In function 'prcmu_is_cpu_in_wfi':
> > arch/arm/mach-ux500/pm.c:137:212: error: ?: using integer constants in boolean context, the expression will always evaluate to 'true' [-Werror=int-in-bool-context]
> >
> > With the added braces, the condition actually makes sense.
> >
> > Fixes: 34fe6f107eab ("mfd : Check if the other db8500 core is in WFI")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Will you apply it directly to ARM SoC or should I queue it and
> send it with a pull request?
I'd prefer you to queue and track it, thanks,
Arnd
^ permalink raw reply
* [PATCH v3] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Wenyou.Yang at microchip.com @ 2016-11-22 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121140248.utlir6krokjeeobi@piout.net>
> -----Original Message-----
> From: Alexandre Belloni [mailto:alexandre.belloni at free-electrons.com]
> Sent: 2016?11?21? 22:03
> To: Wenyou Yang - A41535 <Wenyou.Yang@microchip.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>; Russell King
> <linux@arm.linux.org.uk>; Rob Herring <robh+dt@kernel.org>; Pawel Moll
> <pawel.moll@arm.com>; Mark Rutland <mark.rutland@arm.com>; Ian Campbell
> <ijc+devicetree@hellion.org.uk>; Kumar Gala <galak@codeaurora.org>; linux-
> kernel at vger.kernel.org; Wenyou Yang - A41535
> <Wenyou.Yang@microchip.com>; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v3] ARM: at91/dt: add dts file for sama5d36ek CMP board
>
> Hi,
>
> I fixed it up this time but please use the proper subject prefix next time (ARM: dts:
> at91:).
Thank you.
I keep it in mind.
>
> On 21/11/2016 at 13:14:42 +0800, Wenyou Yang wrote :
> > The sama5d36ek CMP board is the variant of sama5d3xek board.
> > It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and some
> > power rail. Its main purpose is used to measure the power consumption.
> > The difference of the sama5d36ek CMP dts from sama5d36ek dts is listed
> > as below.
> > 1. The USB host nodes are removed, that is, the USB host is disabled.
> > 2. The gpio_keys node is added to wake up from the sleep.
> > 3. The LCD isn't supported due to the pins for LCD are conflicted
> > with gpio_keys.
> > 4. The adc0 node support the pinctrl sleep state to fix the over
> > consumption on VDDANA.
> >
> > As said in errata, "When the USB host ports are used in high speed
> > mode (EHCI), it is not possible to suspend the ports if no device is
> > attached on each port. This leads to increased power consumption even
> > if the system is in a low power mode." That is why the the USB host is
> > disabled.
> >
> > Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> > ---
> >
> > Changes in v3:
> > - Use a dual license scheme for DT files.
> > - Use the proper model name and the compatible string to reflect
> > the nature of this new "CMP" board.
> > - Change name of wakeup property to "wakeup-source".
> > - Remove unnecessary comments.
> > - Remove bootargs.
> >
> > Changes in v2:
> > - Add the pinctrl sleep state for adc0 node to fix the over
> > consumption on VDDANA.
> > - Improve the commit log.
> >
> > arch/arm/boot/dts/sama5d36ek_cmp.dts | 87 ++++++++++
> > arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 201 +++++++++++++++++++++++
> > arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 301
> > ++++++++++++++++++++++++++++++++++
> > 3 files changed, 589 insertions(+)
> > create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
> > create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> > create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> >
> Applied, thanks.
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Best Regards,
Wenyou Yang
^ permalink raw reply
* [PATCH] pinctrl: mediatek: use builtin_platform_driver
From: Linus Walleij @ 2016-11-22 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <70fcc58b7e9219a9fbe3695df927041b8234dd08.1479457060.git.geliangtang@gmail.com>
On Fri, Nov 18, 2016 at 3:12 PM, Geliang Tang <geliangtang@gmail.com> wrote:
> Use builtin_platform_driver() helper to simplify the code.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Patch applied with Hongzhou's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/6] reset: hisilicon: add reset core
From: zhangfei @ 2016-11-22 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3993565.nedzUBZcVS@wuerfel>
Hi, Arnd
On 2016?11?22? 16:45, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 3:49:16 PM CET Zhangfei Gao wrote:
>> @@ -1,8 +1,8 @@
>> obj-y += core.o
>> -obj-y += hisilicon/
>> obj-$(CONFIG_ARCH_STI) += sti/
>> obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
>> obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
>> +obj-$(CONFIG_ARCH_HISI) += hisilicon/
>> obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
>> obj-$(CONFIG_RESET_MESON) += reset-meson.o
>> obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
> Please leave the obj-y line, otherwise the COMPILE_TEST variant won't work.
COMPILE_TEST is added in drivers/reset/hisilicon/Kconfig
like
config COMMON_RESET_HI3660
tristate "Hi3660 Reset Driver"
depends on ARCH_HISI || COMPILE_TEST
The reason not using "obj-y" here is that reset.c will be compiled unconditionally.
drivers/reset/hisilicon/Makefile
obj-y += reset.o
Thanks
^ permalink raw reply
* [RFC PATCH 00/11] Allow NOMMU for MULTIPLATFORM
From: Vladimir Murzin @ 2016-11-22 9:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
With transition to MULTIPLATFORM we lost capability to build NOMMU
configurations. Maybe not a big deal, but there is still interest in
building NOMMU configuration apart from M-class cores. Basically, I'm
talking about R-class cores which shares a lot with A-class except
MMU; there was little interest to run A-class with MMU disabled (or
1:1 MMU mapping) as well. By now it is not even possible to build
such configurations without extra patches on top. Another aspect is
that some portion of NOMMU code have been (build) untested for a
while. All these makes it even harder to involve more people in using
NOMMU and build community around that.
This series is trying to make it possible to build NOMMU
configurations. It is done in PATCH 11/11 which allows to select
ARCH_MULTIPLATFORM even for NOMMU. This is controlled with EXPERT
config option. All patches prior 11/11 is an attempt to fix build
failures for NOMMU case. I don't claim they are 100% correct, so I'm
open to suggestion how they can be done in a better way.
Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>
Vladimir Murzin (11):
ARM: NOMMU: define stubs for fixup
ARM: ep93xx: select ARM_PATCH_PHYS_VIRT for MMU builds only
ARM: omap: do not select HIGHMEM explicitly
PCI: tegra: limit to MMU build only
ARM: move arm_heavy_mb to MMU/noMMU neutral place
ARM: tlbflush: drop dependency on CONFIG_SMP
ARM: sleep: allow it to be build for R-class
ARM: NOMMU: define debug_ll_io_ini
ARM: NOMMU: define SECTION_xxx macros
ARM: NOMMU: define __arm_ioremap_exec and pci_ioremap functions
ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
arch/arm/Kconfig | 8 ++++----
arch/arm/include/asm/fixmap.h | 6 ++++++
arch/arm/include/asm/mach/map.h | 2 ++
arch/arm/include/asm/pgtable-nommu.h | 5 +++++
arch/arm/include/asm/tlbflush.h | 2 +-
arch/arm/kernel/sleep.S | 4 ----
arch/arm/mach-omap2/Kconfig | 1 -
arch/arm/mm/flush.c | 15 ---------------
arch/arm/mm/iomap.c | 17 +++++++++++++++++
arch/arm/mm/nommu.c | 35 ++++++++++++++++++++++++++++++++++
drivers/pci/host/Kconfig | 2 +-
11 files changed, 71 insertions(+), 26 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [RFC PATCH 01/11] ARM: NOMMU: define stubs for fixup
From: Vladimir Murzin @ 2016-11-22 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479806768-39911-1-git-send-email-vladimir.murzin@arm.com>
When build for NOMMU following errors show ups:
arch/arm/kernel/patch.c: In function 'patch_map':
arch/arm/kernel/patch.c:39:2: error: implicit declaration of function 'set_fixmap' [-Werror=implicit-function-declaration]
set_fixmap(fixmap, page_to_phys(page));
^
arch/arm/kernel/patch.c:41:2: error: implicit declaration of function '__fix_to_virt' [-Werror=implicit-function-declaration]
return (void *) (__fix_to_virt(fixmap) + (uintaddr & ~PAGE_MASK));
^
arch/arm/kernel/patch.c: In function 'patch_unmap':
arch/arm/kernel/patch.c:47:2: error: implicit declaration of function 'clear_fixmap' [-Werror=implicit-function-declaration]
clear_fixmap(fixmap);
^
cc1: some warnings being treated as errors
Fixup does not make much sense in NOMMU configurations, so provide
stub definitions.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/fixmap.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
index 5c17d2d..0bfc2e3 100644
--- a/arch/arm/include/asm/fixmap.h
+++ b/arch/arm/include/asm/fixmap.h
@@ -59,6 +59,12 @@ enum fixed_addresses {
#else
+#define set_fixmap(idx, phys)
+#define clear_fixmap(idx)
+
+#define __fix_to_virt(x) (x)
+#define __virt_to_fix(x) (x)
+
static inline void early_fixmap_init(void) { }
#endif
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 02/11] ARM: ep93xx: select ARM_PATCH_PHYS_VIRT for MMU builds only
From: Vladimir Murzin @ 2016-11-22 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479806768-39911-1-git-send-email-vladimir.murzin@arm.com>
Building in NOMMU configurations lead to the following splat:
warning: (ARCH_INTEGRATOR && ARCH_MULTIPLATFORM && ARCH_EP93XX) selects ARM_PATCH_PHYS_VIRT which has unmet direct dependencies (!XIP_KERNEL && MMU)
Make sure ARM_PATCH_PHYS_VIRT is selected for MMU builds only.
Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529f..49e0f01 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -380,7 +380,7 @@ config ARCH_EP93XX
bool "EP93xx-based"
select ARCH_HAS_HOLES_MEMORYMODEL
select ARM_AMBA
- select ARM_PATCH_PHYS_VIRT
+ select ARM_PATCH_PHYS_VIRT if MMU
select ARM_VIC
select AUTO_ZRELADDR
select CLKDEV_LOOKUP
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 03/11] ARM: omap: do not select HIGHMEM explicitly
From: Vladimir Murzin @ 2016-11-22 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479806768-39911-1-git-send-email-vladimir.murzin@arm.com>
Explicit selection of HIGHMEM breaks NOMMU builds. It seems that
HIGHMEM is user selectable option, so probably it would be better to
let user to make a decision on this options or, at least, move it to
defconfig.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/mach-omap2/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a9afeeb..4e3fb69 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -120,7 +120,6 @@ config ARCH_OMAP2PLUS_TYPICAL
bool "Typical OMAP configuration"
default y
select AEABI
- select HIGHMEM
select I2C
select I2C_OMAP
select MENELAUS if ARCH_OMAP2
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 04/11] PCI: tegra: limit to MMU build only
From: Vladimir Murzin @ 2016-11-22 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479806768-39911-1-git-send-email-vladimir.murzin@arm.com>
This driver uses functionality which available for MMU build only,
thus add dependency on MMU.
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
drivers/pci/host/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d7e7c0a..836fa02 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -69,7 +69,7 @@ config PCI_IMX6
config PCI_TEGRA
bool "NVIDIA Tegra PCIe controller"
- depends on ARCH_TEGRA && !ARM64
+ depends on ARCH_TEGRA && !ARM64 && MMU
help
Say Y here if you want support for the PCIe host controller found
on NVIDIA Tegra SoCs.
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 05/11] ARM: move arm_heavy_mb to MMU/noMMU neutral place
From: Vladimir Murzin @ 2016-11-22 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479806768-39911-1-git-send-email-vladimir.murzin@arm.com>
So it can be referenced from both camps.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/mm/flush.c | 15 ---------------
arch/arm/mm/iomap.c | 17 +++++++++++++++++
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
index 3cced84..0c73969 100644
--- a/arch/arm/mm/flush.c
+++ b/arch/arm/mm/flush.c
@@ -21,21 +21,6 @@
#include "mm.h"
-#ifdef CONFIG_ARM_HEAVY_MB
-void (*soc_mb)(void);
-
-void arm_heavy_mb(void)
-{
-#ifdef CONFIG_OUTER_CACHE_SYNC
- if (outer_cache.sync)
- outer_cache.sync();
-#endif
- if (soc_mb)
- soc_mb();
-}
-EXPORT_SYMBOL(arm_heavy_mb);
-#endif
-
#ifdef CONFIG_CPU_CACHE_VIPT
static void flush_pfn_alias(unsigned long pfn, unsigned long vaddr)
diff --git a/arch/arm/mm/iomap.c b/arch/arm/mm/iomap.c
index 4614208..1b601db 100644
--- a/arch/arm/mm/iomap.c
+++ b/arch/arm/mm/iomap.c
@@ -9,6 +9,8 @@
#include <linux/ioport.h>
#include <linux/io.h>
+#include <asm/outercache.h>
+
unsigned long vga_base;
EXPORT_SYMBOL(vga_base);
@@ -40,3 +42,18 @@ void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
}
EXPORT_SYMBOL(pci_iounmap);
#endif
+
+#ifdef CONFIG_ARM_HEAVY_MB
+void (*soc_mb)(void);
+
+void arm_heavy_mb(void)
+{
+#ifdef CONFIG_OUTER_CACHE_SYNC
+ if (outer_cache.sync)
+ outer_cache.sync();
+#endif
+ if (soc_mb)
+ soc_mb();
+}
+EXPORT_SYMBOL(arm_heavy_mb);
+#endif
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 06/11] ARM: tlbflush: drop dependency on CONFIG_SMP
From: Vladimir Murzin @ 2016-11-22 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479806768-39911-1-git-send-email-vladimir.murzin@arm.com>
It can be referenced in UP case as well.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/tlbflush.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index def9e57..d9a6e2e 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -641,7 +641,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
#endif
-#elif defined(CONFIG_SMP) /* !CONFIG_MMU */
+#else /* !CONFIG_MMU */
#ifndef __ASSEMBLY__
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 07/11] ARM: sleep: allow it to be build for R-class
From: Vladimir Murzin @ 2016-11-22 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479806768-39911-1-git-send-email-vladimir.murzin@arm.com>
Dependency on MMU is quite strict and prevent R-class from being built -
relax this condition and guard against M-class only
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/Kconfig | 2 +-
arch/arm/kernel/sleep.S | 4 ----
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 49e0f01..f9ff570 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2179,7 +2179,7 @@ config ARCH_SUSPEND_POSSIBLE
def_bool y
config ARM_CPU_SUSPEND
- def_bool PM_SLEEP || BL_SWITCHER || ARM_PSCI_FW
+ def_bool (PM_SLEEP || BL_SWITCHER || ARM_PSCI_FW) && !CPU_V7M
depends on ARCH_SUSPEND_POSSIBLE
config ARCH_HIBERNATION_POSSIBLE
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 0f6c100..0e7fddf 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -119,14 +119,12 @@ ENDPROC(cpu_resume_after_mmu)
.text
.align
-#ifdef CONFIG_MMU
.arm
ENTRY(cpu_resume_arm)
THUMB( badr r9, 1f ) @ Kernel is entered in ARM.
THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
THUMB( .thumb ) @ switch to Thumb now.
THUMB(1: )
-#endif
ENTRY(cpu_resume)
ARM_BE8(setend be) @ ensure we are in BE mode
@@ -160,9 +158,7 @@ THUMB( mov sp, r2 )
THUMB( bx r3 )
ENDPROC(cpu_resume)
-#ifdef CONFIG_MMU
ENDPROC(cpu_resume_arm)
-#endif
.align 2
_sleep_save_sp:
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 08/11] ARM: NOMMU: define debug_ll_io_ini
From: Vladimir Murzin @ 2016-11-22 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479806768-39911-1-git-send-email-vladimir.murzin@arm.com>
We do not need to do anything in debug_ll_io_init in case of NOMMU.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/mach/map.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 9b7c328..6b86b9c 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -62,6 +62,8 @@ extern int ioremap_page(unsigned long virt, unsigned long phys,
#else
#define iotable_init(map,num) do { } while (0)
#define vm_reserve_area_early(a,s,c) do { } while (0)
+#define debug_ll_io_init() do { } while (0)
+
#endif
#endif
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox