* [PATCH v6 3/3] clk: at91: pmc: Support backup for programmable clocks
From: Stephen Boyd @ 2017-12-22 0:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165535.5126-4-romain.izard.pro@gmail.com>
On 12/11, Romain Izard wrote:
> When an AT91 programmable clock is declared in the device tree, register
> it into the Power Management Controller driver. On entering suspend mode,
> the driver saves and restores the Programmable Clock registers to support
> the backup mode for these clocks.
>
> Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.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 v6 2/3] clk: at91: pmc: Save SCSR during suspend
From: Stephen Boyd @ 2017-12-22 0:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165535.5126-3-romain.izard.pro@gmail.com>
On 12/11, Romain Izard wrote:
> The contents of the System Clock Status Register (SCSR) needs to be
> restored into the System Clock Enable Register (SCER).
>
> As the bootloader will restore some clocks by itself, the issue can be
> missed as only the USB controller, the LCD controller, the Image Sensor
> controller and the programmable clocks will be impacted.
>
> Fix the obvious typo in the suspend/resume code, as the IMR register
> does not need to be saved twice.
>
> Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.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 v6 1/3] clk: at91: pmc: Wait for clocks when resuming
From: Stephen Boyd @ 2017-12-22 0:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165535.5126-2-romain.izard.pro@gmail.com>
On 12/11, Romain Izard wrote:
> Wait for the syncronization of all clocks when resuming, not only the
> UPLL clock. Do not use regmap_read_poll_timeout, as it will call BUG()
> when interrupts are masked, which is the case in here.
>
> Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.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 v2 2/2] PCI: mediatek: Fixup class type for MT7622
From: Bjorn Helgaas @ 2017-12-22 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513839672.25872.13.camel@mhfsdcap03>
On Thu, Dec 21, 2017 at 03:01:12PM +0800, Honghui Zhang wrote:
> On Thu, 2017-12-21 at 14:41 +0800, Yong Wu wrote:
> > On Thu, 2017-12-21 at 10:11 +0800, honghui.zhang at mediatek.com wrote:
> > > From: Honghui Zhang <honghui.zhang@mediatek.com>
> > >
> > > The host bridge of MT7622 has hardware code the class code to an
> > > arbitrary, meaningless value, fix that.
> > >
> > > Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> > > ---
> > > drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> > > index 3248771..ae8d367 100644
> > > --- a/drivers/pci/host/pcie-mediatek.c
> > > +++ b/drivers/pci/host/pcie-mediatek.c
> > > @@ -1174,3 +1174,15 @@ static struct platform_driver mtk_pcie_driver = {
> > > },
> > > };
> > > builtin_platform_driver(mtk_pcie_driver);
> > > +
> > > +/* The host bridge of MT7622 advertises the wrong device class. */
> > > +static void mtk_fixup_class(struct pci_dev *dev)
> > > +{
> > > + dev->class = PCI_CLASS_BRIDGE_PCI << 8;
> > > +}
> > > +
> > > +/*
> > > + * The HW default value of vendor id and device id for mt7622 are 0x0e8d,
> > > + * 0x3258, which are arbitrary, meaningless values.
They may be arbitrary but they are certainly not meaningless.
> > What's the right vendor id and device id? is it possible to fix them
> > too?
>
> Vendor ID is managed by PCI-SIG, you may get the assigned vendor ID
> from:
> https://pci-ids.ucw.cz/read/PC?restrict=
It's true that Vendor IDs are managed by the PCI-SIG. The link above
is not managed by the PCI-SIG and is not the official list of assigned
Vendor IDs.
> The vendor ID for Mediatek Corp. should be 14c3.
> Device ID is something like vendor-defined.
> Those values are in the configuration space and are read-only defined by
> spec, it's been stored at the pci_dev, we may change the vendor and
> device values in pci_dev, but I don't think it's necessary to change
> that.
> BTW, Does anyone really cares about the vendor ID and device ID except
> the device's driver?
Yes. This is a fundamental misunderstanding of how Vendor and Device
IDs work. The *driver* really doesn't care about the IDs. The PCI
*core* cares about them because it uses the IDs to select the
appropriate driver to bind to the device.
> > > +DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
This is absolutely not OK. You cannot take over Vendor ID 0x0e8d
unless it has been assigned to you by the PCI-SIG.
To my knowledge, 0x0e8d has not been assigned to any company yet, but
the PCI-SIG could assign it to some new company X tomorrow. Company X
may then build a device with Device ID 0x3258. Now we cannot tell the
difference between the Company X device that is correctly designed and
this Mediatek device that is broken.
This quirk would improperly overwrite dev->class for the Company X
device, and we would not be able to bind the correct driver to either
device.
I am amazed that somebody could build a device that claims to be a PCI
device and get the Vendor ID wrong. That should be literally the
first thing the hardware designer does. If you have hardware in the
field that uses the wrong Vendor ID, it is definitely not
PCI-compliant.
Bjorn
^ permalink raw reply
* [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Florian Fainelli @ 2017-12-22 0:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222001407.GL10595@n2100.armlinux.org.uk>
On 12/21/2017 04:14 PM, Russell King - ARM Linux wrote:
> On Thu, Dec 21, 2017 at 11:53:47PM +0100, Linus Walleij wrote:
>> On Thu, Dec 21, 2017 at 6:32 PM, Russell King - ARM Linux
>> <linux@armlinux.org.uk> wrote:
>>
>>> What we have here is _really_ a shared interrupt between four
>>> separate devices, and we need a way to sanely describe resources
>>> shared between several device instances to pinmux. Unfortunately,
>>> it seems pinmux is designed around one device having exclusive use
>>> of a resource, which makes it hard to describe shared interrupts in
>>> DT.
>>>
>>> Given that DT should be a description of the hardware, and should be
>>> independent of the OS implementation, I'd say this is a pinmux bug,
>>> because pinmux gets in the way of describing the hardware correctly.
>>> ;)
>>
>> Hm that would be annoying. But when I look at it I think it would
>> actually work. Did you try just assigning the same pin control
>> state to all the PHY's and see what happens?
>>
>> Just set
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_mv88e1545>;
>>
>> on all of them?
>
> It was tried, DT was happy, but the kernel on boot complained because
> pinctrl objected, which caused the drivers to fail to bind:
>
> libphy: mdio: probed
> vf610-pinctrl 40048000.iomuxc: pin VF610_PAD_PTB0 already requested by !mdio-mux!mdio at 4!switch at 0!mdio:00; cannot claim for !mdio-mux!mdio at 4!switch at 0!mdio:01
> vf610-pinctrl 40048000.iomuxc: pin-22 (!mdio-mux!mdio at 4!switch at 0!mdio:01) status -22
> vf610-pinctrl 40048000.iomuxc: could not request pin 22 (VF610_PAD_PTB0) from group pinctrl-mv88e1545 on device 40048000.iomuxc
> Marvell 88E1545 !mdio-mux!mdio at 4!switch at 0!mdio:01: Error applying setting, reverse things back
> Marvell 88E1545: probe of !mdio-mux!mdio at 4!switch at 0!mdio:01 failed with error -22
> vf610-pinctrl 40048000.iomuxc: pin VF610_PAD_PTB0 already requested by !mdio-mux!mdio at 4!switch at 0!mdio:00; cannot claim for !mdio-mux!mdio at 4!switch at 0!mdio:02
> vf610-pinctrl 40048000.iomuxc: pin-22 (!mdio-mux!mdio at 4!switch at 0!mdio:02) status -22
> vf610-pinctrl 40048000.iomuxc: could not request pin 22 (VF610_PAD_PTB0) from group pinctrl-mv88e1545 on device 40048000.iomuxc
> Marvell 88E1545 !mdio-mux!mdio at 4!switch at 0!mdio:02: Error applying setting, reverse things back
> Marvell 88E1545: probe of !mdio-mux!mdio at 4!switch at 0!mdio:02 failed with error -22
>
You could also see it another way, because this is a quad PHY in a
single package, you could theoretically have a representation that
exposes a node container for the 4 PHYs, and that container node
requests the pinmux/pinctrl. Of course, this would not work with the
MDIO code which would not go one level down, and would expect the PHYs
to be at the same level as the container node...
Oh well.
--
Florian
^ permalink raw reply
* [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Russell King - ARM Linux @ 2017-12-22 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdarS+tPv5CG4bmFcPvc+=SJJcC1pbO7WSbsS5+yCuxh_Q@mail.gmail.com>
On Thu, Dec 21, 2017 at 11:53:47PM +0100, Linus Walleij wrote:
> On Thu, Dec 21, 2017 at 6:32 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
>
> > What we have here is _really_ a shared interrupt between four
> > separate devices, and we need a way to sanely describe resources
> > shared between several device instances to pinmux. Unfortunately,
> > it seems pinmux is designed around one device having exclusive use
> > of a resource, which makes it hard to describe shared interrupts in
> > DT.
> >
> > Given that DT should be a description of the hardware, and should be
> > independent of the OS implementation, I'd say this is a pinmux bug,
> > because pinmux gets in the way of describing the hardware correctly.
> > ;)
>
> Hm that would be annoying. But when I look at it I think it would
> actually work. Did you try just assigning the same pin control
> state to all the PHY's and see what happens?
>
> Just set
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_mv88e1545>;
>
> on all of them?
It was tried, DT was happy, but the kernel on boot complained because
pinctrl objected, which caused the drivers to fail to bind:
libphy: mdio: probed
vf610-pinctrl 40048000.iomuxc: pin VF610_PAD_PTB0 already requested by !mdio-mux!mdio at 4!switch at 0!mdio:00; cannot claim for !mdio-mux!mdio at 4!switch at 0!mdio:01
vf610-pinctrl 40048000.iomuxc: pin-22 (!mdio-mux!mdio at 4!switch at 0!mdio:01) status -22
vf610-pinctrl 40048000.iomuxc: could not request pin 22 (VF610_PAD_PTB0) from group pinctrl-mv88e1545 on device 40048000.iomuxc
Marvell 88E1545 !mdio-mux!mdio at 4!switch at 0!mdio:01: Error applying setting, reverse things back
Marvell 88E1545: probe of !mdio-mux!mdio at 4!switch at 0!mdio:01 failed with error -22
vf610-pinctrl 40048000.iomuxc: pin VF610_PAD_PTB0 already requested by !mdio-mux!mdio at 4!switch at 0!mdio:00; cannot claim for !mdio-mux!mdio at 4!switch at 0!mdio:02
vf610-pinctrl 40048000.iomuxc: pin-22 (!mdio-mux!mdio at 4!switch at 0!mdio:02) status -22
vf610-pinctrl 40048000.iomuxc: could not request pin 22 (VF610_PAD_PTB0) from group pinctrl-mv88e1545 on device 40048000.iomuxc
Marvell 88E1545 !mdio-mux!mdio at 4!switch at 0!mdio:02: Error applying setting, reverse things back
Marvell 88E1545: probe of !mdio-mux!mdio at 4!switch at 0!mdio:02 failed with error -22
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [GIT PULL 2/2] Broadcom drivers changes for 4.16
From: Florian Fainelli @ 2017-12-22 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222001227.30625-1-f.fainelli@gmail.com>
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.16/drivers
for you to fetch changes up to f780429adfbc222a4d8a227a2a550ba627c7338b:
soc: brcmstb: biuctrl: Move to early_initcall (2017-12-20 17:37:44 -0800)
----------------------------------------------------------------
This pull request contains Broadcom ARM/ARM64 based SoCs drivers changes for
4.16, please pull the following:
- Arnd provides an update to the Raspberry Pi firmware interface and uses time64_t to
print the time to make it more future proof
- Florian provides a set of updates to make the Broadcom STB Bus Interface Unit code
work on newer ARM64-based chips, as well as perform the correct interface tuning
for these chips to reach the expected performance
----------------------------------------------------------------
Arnd Bergmann (1):
firmware: raspberrypi: print time using time64_t
Florian Fainelli (10):
Merge tag 'bcm2835-drivers-next-2017-12-19' into drivers/next
dt-bindings: arm: Add entry for Broadcom Brahma-B53
dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation
soc: brcmstb: Make CPU credit offset more parameterized
soc: brcmstb: Correct CPU_CREDIT_REG offset for Brahma-B53 CPUs
soc: brcmstb: biuctrl: Prepare for saving/restoring other registers
soc: brcmstb: biuctrl: Wire-up new registers
soc: brcmstb: biuctrl: Fine tune B53 MCP interface settings
soc: brcmstb: Split initialization
soc: brcmstb: biuctrl: Move to early_initcall
.../devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 22 +--
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/mach-bcm/brcmstb.c | 2 -
drivers/firmware/raspberrypi.c | 2 +-
drivers/soc/bcm/brcmstb/biuctrl.c | 176 +++++++++++++++++++--
drivers/soc/bcm/brcmstb/common.c | 27 ++--
include/linux/soc/brcmstb/brcmstb.h | 6 -
7 files changed, 187 insertions(+), 49 deletions(-)
^ permalink raw reply
* [GIT PULL 1/2] Broadcom devicetree changes for 4.16
From: Florian Fainelli @ 2017-12-22 0:12 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.16/devicetree
for you to fetch changes up to ececb5639c33a6a0444bd8e1cda8bf2ef20c6a6b:
Merge tag 'bcm2835-dt-next-2017-12-19' into devicetree/next (2017-12-20 17:32:58 -0800)
----------------------------------------------------------------
This pull request contains Broadcom ARM-based SoCs Device Tree changes for
4.16, please pull the following:
- Stefan updates the BCM283x DTS to make consistent use of the existing GPIO
defines for the polarity specifier
----------------------------------------------------------------
Florian Fainelli (1):
Merge tag 'bcm2835-dt-next-2017-12-19' into devicetree/next
Stefan Wahren (1):
ARM: dts: bcm283x: Use GPIO polarity defines consistently
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 4 ++--
arch/arm/boot/dts/bcm2835-rpi-a.dts | 2 +-
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 4 ++--
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 2 +-
arch/arm/boot/dts/bcm2835-rpi-b.dts | 2 +-
arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 4 ++--
arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH] clk: imx51: uart4, uart5 gates only exist on imx50, imx53
From: Stephen Boyd @ 2017-12-22 0:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213115748.14106-1-p.zabel@pengutronix.de>
On 12/13, Philipp Zabel wrote:
> i.MX51 only has 3 UARTs and no CCGR7 register. In place of the CCGR7
> register on i.MX50/i.MX53 that contains the ipg and per clock gates
> for UARTs 4 and 5, on i.MX51 there is the CMEOR register.
>
> Without this patch, the code disabling the UART clocks would also clear
> the mod_en_ov_vpu bit in the CMEOR register, among others, which causes
> register accesses to the VPU to lock up the system.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 3/3] clk: actions: Add clock driver for Actions S900 SoC
From: Stephen Boyd @ 2017-12-21 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1509997552-29718-4-git-send-email-manivannan.sadhasivam@linaro.org>
On 11/07, Manivannan Sadhasivam wrote:
> diff --git a/drivers/clk/actions/Kconfig b/drivers/clk/actions/Kconfig
> new file mode 100644
> index 0000000..0de7a03
> --- /dev/null
> +++ b/drivers/clk/actions/Kconfig
> @@ -0,0 +1,6 @@
> +config CLK_OWL_S900
> + bool "Clock Driver for Actions S900 SoC"
Can it be a module too? Otherwise drop module.h and anything that
does to the driver.
> + depends on ARCH_ACTIONS || COMPILE_TEST
Can you try compiling this with COMPILE_TEST=y and
ARCH_ACTIONS=n? It may be that drivers/clk/Makefile needs to be
obj-y and then the owl-clk, owl-pll, owl-factor files need to be
compiled only when CONFIG_CLK_OWL_S900 is y. If there becomes
more than one actions driver, then the clk, pll, factor files
will need to be compiled with some new CLK_ACTIONS kconfig symbol
or something.
> + default ARCH_ACTIONS
> + help
> + Build the clock driver for Actions S900 SoC.
> diff --git a/drivers/clk/actions/Makefile b/drivers/clk/actions/Makefile
> new file mode 100644
> index 0000000..83bef30
> --- /dev/null
> +++ b/drivers/clk/actions/Makefile
> @@ -0,0 +1,2 @@
> +obj-y += owl-clk.o owl-pll.o owl-factor.o
> +obj-$(CONFIG_CLK_OWL_S900) += owl-s900.o
> diff --git a/drivers/clk/actions/owl-s900.c b/drivers/clk/actions/owl-s900.c
> new file mode 100644
> index 0000000..51e297f
> --- /dev/null
> +++ b/drivers/clk/actions/owl-s900.c
> @@ -0,0 +1,585 @@
> +/*
> + * Copyright (c) 2014 Actions Semi Inc.
> + * Author: David Liu <liuwei@actions-semi.com>
> + *
> + * Copyright (c) 2017 Linaro Ltd.
> + * Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This 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.
> + */
Can you move to the SPDX tags please?
> + COMP_DIV_CLK(CLK_UART3, "uart3", 0,
> + C_MUX(uart_clk_mux_p, CMU_UART3CLK, 16, 1, 0),
> + C_GATE(CMU_DEVCLKEN1, 19, 0),
> + C_DIVIDER(CMU_UART3CLK, 0, 8, NULL, CLK_DIVIDER_ROUND_CLOSEST)),
> +
> + COMP_DIV_CLK(CLK_UART4, "uart4", 0,
> + C_MUX(uart_clk_mux_p, CMU_UART4CLK, 16, 1, 0),
> + C_GATE(CMU_DEVCLKEN1, 20, 0),
> + C_DIVIDER(CMU_UART4CLK, 0, 8, NULL, CLK_DIVIDER_ROUND_CLOSEST)),
> +
> + COMP_DIV_CLK(CLK_UART5, "uart5", 0,
> + C_MUX(uart_clk_mux_p, CMU_UART5CLK, 16, 1, 0),
> + C_GATE(CMU_DEVCLKEN1, 21, 0),
> + C_DIVIDER(CMU_UART5CLK, 0, 8, NULL, CLK_DIVIDER_ROUND_CLOSEST)),
> +
> + COMP_DIV_CLK(CLK_UART6, "uart6", 0,
> + C_MUX(uart_clk_mux_p, CMU_UART6CLK, 16, 1, 0),
> + C_GATE(CMU_DEVCLKEN1, 18, 0),
> + C_DIVIDER(CMU_UART6CLK, 0, 8, NULL, CLK_DIVIDER_ROUND_CLOSEST)),
> +
> + COMP_FACTOR_CLK(CLK_VCE, "vce", 0,
> + C_MUX(vce_clk_mux_p, CMU_VCECLK, 4, 2, 0),
> + C_GATE(CMU_DEVCLKEN0, 26, 0),
> + C_FACTOR(CMU_VCECLK, 0, 3, bisp_factor_table, 0)),
> +
> + COMP_FACTOR_CLK(CLK_VDE, "vde", 0,
> + C_MUX(hde_clk_mux_p, CMU_VDECLK, 4, 2, 0),
> + C_GATE(CMU_DEVCLKEN0, 25, 0),
> + C_FACTOR(CMU_VDECLK, 0, 3, bisp_factor_table, 0)),
> +};
> +
> +static int s900_clk_probe(struct platform_device *pdev)
> +{
> + struct owl_clk_provider *ctx;
> + struct device_node *np = pdev->dev.of_node;
> + struct resource *res;
> + void __iomem *base;
> + int i;
> +
> + ctx = kzalloc(sizeof(struct owl_clk_provider) +
> + sizeof(*ctx->clk_data.hws) * CLK_NR_CLKS, GFP_KERNEL);
It would be nice to avoid this. If the structs can all be
configured properly, it should be possible to have an array of
clk_hw pointers that are registered directly with
clk_hw_register(), and then index directly into that array to
return clk_hw pointers for the clk_hw provider function.
> + if (!ctx)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + for (i = 0; i < CLK_NR_CLKS; ++i)
> + ctx->clk_data.hws[i] = ERR_PTR(-ENOENT);
> +
> + ctx->reg_base = base;
> + ctx->clk_data.num = CLK_NR_CLKS;
Hopefully CLK_NR_CLKS isn't coming from the DT header file.
> + spin_lock_init(&ctx->lock);
> +
> + /* register pll clocks */
> + owl_clk_register_pll(ctx, s900_pll_clks,
> + ARRAY_SIZE(s900_pll_clks));
> +
> + /* register divider clocks */
> + owl_clk_register_divider(ctx, s900_div_clks,
> + ARRAY_SIZE(s900_div_clks));
> +
> + /* register factor divider clocks */
> + owl_clk_register_factor(ctx, s900_factor_clks,
> + ARRAY_SIZE(s900_factor_clks));
> +
> + /* register mux clocks */
> + owl_clk_register_mux(ctx, s900_mux_clks,
> + ARRAY_SIZE(s900_mux_clks));
> +
> + /* register gate clocks */
> + owl_clk_register_gate(ctx, s900_gate_clks,
> + ARRAY_SIZE(s900_gate_clks));
> +
> + /* register composite clocks */
> + owl_clk_register_composite(ctx, s900_composite_clks,
> + ARRAY_SIZE(s900_composite_clks));
> +
> + return of_clk_add_hw_provider(np, of_clk_hw_onecell_get,
> + &ctx->clk_data);
> +
> +}
> +
> +static const struct of_device_id s900_clk_of_match[] = {
> + { .compatible = "actions,s900-cmu", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, s900_clk_of_match);
This isn't necessary? It's not a module?
> +
> +static struct platform_driver s900_clk_driver = {
> + .probe = s900_clk_probe,
> + .driver = {
> + .name = "s900-cmu",
> + .of_match_table = s900_clk_of_match,
You need to supress_bind_attrs here or implement the remove
function for this driver that would unregister all the clks and
provider.
> + },
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 0/5] clk: Add Aspeed clock driver
From: Stephen Boyd @ 2017-12-21 23:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XcQ_ZcgPK1PwEwCuWHQ_j5qS+PejRVhr2rYuH_Nn_nPLQ@mail.gmail.com>
On 12/06, Joel Stanley wrote:
> Hello clk maintainers,
>
> Has anyone had a chance to review these patches?
>
Besides the sleeping call that should be a delay it looks OK.
Send v7?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 4/5] clk: aspeed: Register gated clocks
From: Stephen Boyd @ 2017-12-21 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171128071908.12279-5-joel@jms.id.au>
On 11/28, Joel Stanley wrote:
> diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
> index 839243691b26..b5dc3e298693 100644
> --- a/drivers/clk/clk-aspeed.c
> +++ b/drivers/clk/clk-aspeed.c
> @@ -202,6 +202,107 @@ static const struct aspeed_clk_soc_data ast2400_data = {
> .calc_pll = aspeed_ast2400_calc_pll,
> };
>
> +static int aspeed_clk_enable(struct clk_hw *hw)
> +{
> + struct aspeed_clk_gate *gate = to_aspeed_clk_gate(hw);
> + unsigned long flags;
> + u32 clk = BIT(gate->clock_idx);
> + u32 rst = BIT(gate->reset_idx);
> +
> + spin_lock_irqsave(gate->lock, flags);
> +
> + if (gate->reset_idx >= 0) {
> + /* Put IP in reset */
> + regmap_update_bits(gate->map, ASPEED_RESET_CTRL, rst, rst);
> +
> + /* Delay 100us */
> + udelay(100);
> + }
> +
> + /* Enable clock */
> + regmap_update_bits(gate->map, ASPEED_CLK_STOP_CTRL, clk, 0);
> +
> + if (gate->reset_idx >= 0) {
> + /* Delay 10ms */
> + /* TODO: can we sleep here? */
> + msleep(10);
No you can't sleep here. It needs to delay because this is inside
spinlock_irqsave.
> +
> + /* Take IP out of reset */
> + regmap_update_bits(gate->map, ASPEED_RESET_CTRL, rst, 0);
> + }
> +
> + spin_unlock_irqrestore(gate->lock, flags);
> +
> + return 0;
> +}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V4 1/1] clk: bulk: add of_clk_bulk_get()
From: Stephen Boyd @ 2017-12-21 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220135330.GA30461@b29396-OptiPlex-7040>
On 12/20, Dong Aisheng wrote:
> On Fri, Sep 29, 2017 at 03:48:21PM -0700, Stephen Boyd wrote:
> > On 09/26, Dong Aisheng wrote:
> > > here to handle this for DT users without 'clock-names' specified.
>
> > > +#endif
> > >
> > > void clk_bulk_put(int num_clks, struct clk_bulk_data *clks)
> > > {
> > > diff --git a/include/linux/clk.h b/include/linux/clk.h
> > > index 12c96d9..073cb3b 100644
> > > --- a/include/linux/clk.h
> > > +++ b/include/linux/clk.h
> > > @@ -680,10 +680,18 @@ static inline void clk_bulk_disable_unprepare(int num_clks,
> > > }
> > >
> > > #if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
> > > +int __must_check of_clk_bulk_get(struct device_node *np, int num_clks,
> > > + struct clk_bulk_data *clks);
> > > struct clk *of_clk_get(struct device_node *np, int index);
> > > struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
> > > struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
> > > #else
> > > +static inline int of_clk_bulk_get(struct device_node *np, int num_clks,
> >
> > Do we need __must_check here too?
>
> Yes, you're absolutely right.
>
> of_clk_bulk_get is special as it returns error, so should add __must_check.
>
> > We should do the same for the
> > other bulk get APIs. Seems we missed that part last time.
> >
>
> Currently for !CONFIG_HAVE_CLK case, all APIs return 0.
> !CONFIG_HAVE_CLK
> clk_bulk_get return 0
> devm_clk_bulk_get return 0
> clk_bulk_enable return 0
> clk_bulk_prepare return 0
>
> Do you think we still need add __must_check for them?
Yes, we need it even when !CONFIG_HAVE_CLK because it allows us
to catch missing checking return values in the non-clk compile
configurations too. More test coverage.
>
> And for CONFIG_HAVE_CLK case, all __must_check already added.
>
> int __must_check clk_bulk_get
> int __must_check devm_clk_bulk_get
> int __must_check clk_bulk_enable
> int __must_check clk_bulk_prepare
>
> And no need for void function.
> void clk_bulk_put
> void clk_bulk_unprepare
> void clk_bulk_disable
>
> > I'll fix all these things up when applying.
> >
>
> I did not see this in latest tree.
> Suppose i should resend it with above things fixed, right?
>
I dropped it because it seems like maybe we don't need
of_clk_bulk_get(), but more like clk_get_all() or something like
that to acquire all clks for a device. It seems like it isn't DT
specific, and so we should just provide the "all" API instead of
some DT specific one that needs to know how many clks to get. I
think I sent a similar reply on some other thread and added you
to it.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2] soc: Add SoC driver for Gemini
From: Linus Walleij @ 2017-12-21 23:19 UTC (permalink / raw)
To: linux-arm-kernel
This adds an SoC driver for the Gemini. Currently there
is only one thing not fitting into any other framework,
and that is the bus arbitration setting.
All Gemini vendor trees seem to be setting this register to
exactly the same arbitration so we just add a small code
snippet to do this at subsys_init() time before any other
drivers kick in.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Add a multiplatform guard, bail out silently if we are not
running on Gemini.
ARM SoC folks: please just apply this patch directly somewhere
if you're pleased with it, it is fully idependent.
Arnd wanted some rewording of the commit message but I can't
figure out what, please entertain yourself editing it any way
you like :)
---
drivers/soc/Makefile | 1 +
drivers/soc/gemini/Makefile | 2 ++
drivers/soc/gemini/soc-gemini.c | 71 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 74 insertions(+)
create mode 100644 drivers/soc/gemini/Makefile
create mode 100644 drivers/soc/gemini/soc-gemini.c
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index deecb16e7256..342768df3530 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -9,6 +9,7 @@ obj-y += bcm/
obj-$(CONFIG_ARCH_DOVE) += dove/
obj-$(CONFIG_MACH_DOVE) += dove/
obj-y += fsl/
+obj-$(CONFIG_ARCH_GEMINI) += gemini/
obj-$(CONFIG_ARCH_MXC) += imx/
obj-$(CONFIG_SOC_XWAY) += lantiq/
obj-y += mediatek/
diff --git a/drivers/soc/gemini/Makefile b/drivers/soc/gemini/Makefile
new file mode 100644
index 000000000000..8cbd1e45db78
--- /dev/null
+++ b/drivers/soc/gemini/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y += soc-gemini.o
diff --git a/drivers/soc/gemini/soc-gemini.c b/drivers/soc/gemini/soc-gemini.c
new file mode 100644
index 000000000000..642b96c91ad6
--- /dev/null
+++ b/drivers/soc/gemini/soc-gemini.c
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ *
+ * 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.
+ *
+ */
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/of.h>
+
+#define GLOBAL_WORD_ID 0x00
+#define GEMINI_GLOBAL_ARB1_CTRL 0x2c
+#define GEMINI_ARB1_BURST_MASK GENMASK(21, 16)
+#define GEMINI_ARB1_BURST_SHIFT 16
+/* These all define the priority on the BUS2 backplane */
+#define GEMINI_ARB1_PRIO_MASK GENMASK(9, 0)
+#define GEMINI_ARB1_DMAC_HIGH_PRIO BIT(0)
+#define GEMINI_ARB1_IDE_HIGH_PRIO BIT(1)
+#define GEMINI_ARB1_RAID_HIGH_PRIO BIT(2)
+#define GEMINI_ARB1_SECURITY_HIGH_PRIO BIT(3)
+#define GEMINI_ARB1_GMAC0_HIGH_PRIO BIT(4)
+#define GEMINI_ARB1_GMAC1_HIGH_PRIO BIT(5)
+#define GEMINI_ARB1_USB0_HIGH_PRIO BIT(6)
+#define GEMINI_ARB1_USB1_HIGH_PRIO BIT(7)
+#define GEMINI_ARB1_PCI_HIGH_PRIO BIT(8)
+#define GEMINI_ARB1_TVE_HIGH_PRIO BIT(9)
+
+#define GEMINI_DEFAULT_BURST_SIZE 0x20
+#define GEMINI_DEFAULT_PRIO (GEMINI_ARB1_GMAC0_HIGH_PRIO | \
+ GEMINI_ARB1_GMAC1_HIGH_PRIO)
+
+static int __init gemini_soc_init(void)
+{
+ struct regmap *map;
+ u32 rev;
+ u32 val;
+ int ret;
+
+ /* Multiplatform guard, only proceed on Gemini */
+ if (!of_machine_is_compatible("cortina,gemini"))
+ return 0;
+
+ map = syscon_regmap_lookup_by_compatible("cortina,gemini-syscon");
+ if (IS_ERR(map))
+ return PTR_ERR(map);
+ ret = regmap_read(map, GLOBAL_WORD_ID, &rev);
+ if (ret)
+ return ret;
+
+ val = (GEMINI_DEFAULT_BURST_SIZE << GEMINI_ARB1_BURST_SHIFT) |
+ GEMINI_DEFAULT_PRIO;
+
+ /* Set up system arbitration */
+ regmap_update_bits(map,
+ GEMINI_GLOBAL_ARB1_CTRL,
+ GEMINI_ARB1_BURST_MASK | GEMINI_ARB1_PRIO_MASK,
+ val);
+
+ pr_info("Gemini SoC %04x revision %02x, set arbitration %08x\n",
+ rev >> 8, rev & 0xff, val);
+
+ return 0;
+}
+subsys_initcall(gemini_soc_init);
--
2.14.3
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series
From: Rob Herring @ 2017-12-21 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220134710.64479-5-jan.tuerk@emtrion.com>
On Wed, Dec 20, 2017 at 02:47:04PM +0100, jan.tuerk at emtrion.com wrote:
> From: Jan Tuerk <jan.tuerk@emtrion.com>
>
> This patch adds support for the emtrion GmbH emCON-MX6 modules.
> They are available with imx.6 Solo, Dual-Lite, Dual and Quad
> equipped with Memory from 512MB to 2GB (configured by U-Boot).
>
> Our default developer-Kit ships with the Avari baseboard and the
> EDT ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari).
>
> The devicetree is split into the common part providing all module
> components and the basic support for all SoC versions
> (imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant.
> Finally the support for the avari baseboard in the developer-kit
> configuration is provided by the emcon-avari dts files.
>
> Signed-off-by: Jan Tuerk <jan.tuerk@emtrion.com>
> ---
> Changes in v2:
> - Fixed typo (reg_prallel.. --> reg_parallel)
> - Removed trailing new-line
> - Fix uppercase addresses as Rob H. noted
> - Fix warning about lcd at di0 -> rename to disp0
> - Renamed some nodes regarding Rob H.
>
> Documentation/devicetree/bindings/arm/emtrion.txt | 13 +
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/imx6dl-emcon-avari.dts | 233 ++++++
> arch/arm/boot/dts/imx6dl-emcon.dtsi | 37 +
> arch/arm/boot/dts/imx6q-emcon-avari.dts | 233 ++++++
> arch/arm/boot/dts/imx6q-emcon.dtsi | 37 +
> arch/arm/boot/dts/imx6qdl-emcon.dtsi | 848 ++++++++++++++++++++++
> 7 files changed, 1403 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt
> create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
> create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
> create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
> create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
> create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi
[...]
> + captouch: touchscreen at 38 {
> + reg = <0x38>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_irq_touch2 &pinctrl_emcon_gpio4>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
> + compatible = "edt,edt-ft5406";
Put compatible as the first property.
> + wake-gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
> + wakeup-source;
> + };
> +};
[...]
> +&rgb_panel {
> + compatible = "edt,etm0700g0bdh6";
> + status = "okay";
Having compatible here is a bit strange and fragile. It's assuming 2
different panels have the same common properties.
> diff --git a/arch/arm/boot/dts/imx6q-emcon.dtsi b/arch/arm/boot/dts/imx6q-emcon.dtsi
> new file mode 100644
> index 000000000000..64fc0cd74c05
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-emcon.dtsi
> @@ -0,0 +1,37 @@
> +/*
> + * Copyright (C) 2017 emtrion GmbH
> + * Author: Jan Tuerk <jan.tuerk@emtrion.com>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
You don't need this if...
> + *
> + * SPDX-License-Identifier: GPL-2.0
You have this.
Also, the rules around this are getting a bit stricter saying the SPDX
tag should be the first line of the file using a C++ style comment.
> + *
> + */
> +
> +/ {
> + model = "emtrion SoM emCON-MX6 Dual/Quad";
> + compatible = "emtrion,emcon-mx6","fsl,imx6q";
Need a space ^
> diff --git a/arch/arm/boot/dts/imx6qdl-emcon.dtsi b/arch/arm/boot/dts/imx6qdl-emcon.dtsi
> new file mode 100644
> index 000000000000..f87d8ed6a1b1
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-emcon.dtsi
> @@ -0,0 +1,848 @@
> +/*
> + * Copyright (C) 2017 emtrion GmbH
> + * Author: Jan Tuerk <jan.tuerk@emtrion.com>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + *
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pwm/pwm.h>
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> +
> + model = "emtrion SoM emCON-MX6";
> + compatible = "emtrion,emcon-mx6","fsl,imx6q", "fsl,imx6dl";
Need a space ^
^ permalink raw reply
* [PATCH 0/3] Add DVFS support on CPU clock for Armada 37xx
From: Stephen Boyd @ 2017-12-21 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130134029.20751-1-gregory.clement@free-electrons.com>
On 11/30, Gregory CLEMENT wrote:
> Hi,
>
> This small series is needed to use DVFS on Armada 37xx. When DVFS is
> enabled the CPU clock setting is done using an other set of registers
> from the North Bridge Power Management block.
>
> The series adds the possibility to modify the CPU frequency using the
> associate load level matching the target frequency. However
> configuring the frequencies for each load is done by the cpufreq
> driver submitted in a separate series.
>
> Obviously having both series (cpufreq and clk) is needed to support
> DVFS on Armada 37xx, but there is no dependencies between the series
> (for building or at runtime).
>
Are you relying on the clk API returning an error to detect if
DVFS is present or not? Just curious why that part of the code
was there.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/3] clk: mvebu: armada-37xx-periph: add DVFS support for cpu clocks
From: Stephen Boyd @ 2017-12-21 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130134029.20751-4-gregory.clement@free-electrons.com>
On 11/30, Gregory CLEMENT wrote:
> When DVFS is enabled the CPU clock setting is done using an other set of
> registers.
>
> These Power Management registers are exposed through a syscon as they
> will also be used by other drivers such as the cpufreq.
>
> This patch add the possibility to modify the CPU frequency using the
> associate load level matching the target frequency. Then all the
> frequency switch is handle by the hardware.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
Applied to clk-next + a small fix to regmap getting to make it
shorter.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/3] clk: mvebu: armada-37xx-periph: prepare cpu clk to be used with DVFS
From: Stephen Boyd @ 2017-12-21 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130134029.20751-3-gregory.clement@free-electrons.com>
On 11/30, Gregory CLEMENT wrote:
> When DVFS will be enabled then the cpu clk will use a different set of
> register at run time. That means that we won't be able to use the common
> callback and need to use our own ones.
>
> This patch prepares this change by switching on our own set of callbacks
> without modifying the behavior of the clocks.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.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 1/3] clk: mvebu: armada-37xx-periph: cosmetic changes
From: Stephen Boyd @ 2017-12-21 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130134029.20751-2-gregory.clement@free-electrons.com>
On 11/30, Gregory CLEMENT wrote:
> This patches fixes few cosmetic issues such as alignment, blank lines
> and required space.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* linux-next: manual merge of the samsung-krzk tree with the keystone tree
From: Stephen Rothwell @ 2017-12-21 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204094558.19b80b4d@canb.auug.org.au>
Hi all,
On Mon, 4 Dec 2017 09:45:58 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the samsung-krzk tree got a conflict in:
>
> arch/arm/configs/multi_v7_defconfig
>
> between commit:
>
> f15187dcdbcd ("ARM: config: sync multi-v7 config with keystone peripherals")
>
> from the keystone tree and commit:
>
> 453c63073185 ("ARM: multi_v7_defconfig: Enable missing drivers for supported Exynos boards")
>
> from the samsung-krzk tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc arch/arm/configs/multi_v7_defconfig
> index 6f2343e259f7,833892568d31..000000000000
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@@ -558,7 -583,8 +559,9 @@@ CONFIG_VIDEO_STI_DELTA=
> CONFIG_VIDEO_RENESAS_JPU=m
> CONFIG_VIDEO_RENESAS_VSP1=m
> CONFIG_V4L_TEST_DRIVERS=y
> +CONFIG_VIDEO_VIVID=m
> + CONFIG_CEC_PLATFORM_DRIVERS=y
> + CONFIG_VIDEO_SAMSUNG_S5P_CEC=m
> # CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
> CONFIG_VIDEO_ADV7180=m
> CONFIG_VIDEO_ML86V7667=m
> @@@ -582,16 -613,12 +585,17 @@@ CONFIG_DRM_RCAR_DU=
> CONFIG_DRM_RCAR_LVDS=y
> CONFIG_DRM_SUN4I=m
> CONFIG_DRM_TEGRA=y
> +CONFIG_DRM_PANEL_SIMPLE=y
> CONFIG_DRM_PANEL_SAMSUNG_LD9040=m
> CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
> -CONFIG_DRM_PANEL_SIMPLE=y
> +CONFIG_DRM_DUMB_VGA_DAC=m
> +CONFIG_DRM_NXP_PTN3460=m
> +CONFIG_DRM_PARADE_PS8622=m
> +CONFIG_DRM_I2C_ADV7511=m
> +CONFIG_DRM_I2C_ADV7511_AUDIO=y
> + CONFIG_DRM_SII9234=m
> CONFIG_DRM_STI=m
> -CONFIG_DRM_VC4=y
> +CONFIG_DRM_VC4=m
> CONFIG_FB_ARMCLCD=y
> CONFIG_FB_EFI=y
> CONFIG_FB_WM8505=y
> @@@ -626,9 -655,10 +630,10 @@@ CONFIG_SND_SOC_SAMSUNG=
> CONFIG_SND_SOC_SAMSUNG_SMDK_WM8994=m
> CONFIG_SND_SOC_SMDK_WM8994_PCM=m
> CONFIG_SND_SOC_SNOW=m
> + CONFIG_SND_SOC_ODROID=m
> CONFIG_SND_SOC_SH4_FSI=m
> CONFIG_SND_SOC_RCAR=m
> -CONFIG_SND_SIMPLE_SCU_CARD=m
> +CONFIG_SND_SOC_STI=m
> CONFIG_SND_SUN4I_CODEC=m
> CONFIG_SND_SOC_TEGRA=m
> CONFIG_SND_SOC_TEGRA20_I2S=m
This is now a conflict between the arm-soc and keystone trees (I think).
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH V7 11/12] arm64: dts: add syscon for whale2 platform
From: Stephen Boyd @ 2017-12-21 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-12-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Some clocks on SC9860 are in the same address area with syscon
> devices, the proper syscon node will be quoted under the
> definitions of those clocks in DT.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
These last two can go via arm-soc?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 10/12] clk: sprd: add clocks support for SC9860
From: Stephen Boyd @ 2017-12-21 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-11-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This patch added the list of clocks for Spreadtrum's SC9860 SoC,
> together with clock initialization code.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.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 V7 09/12] clk: sprd: Add dt-bindings include file for SC9860
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-10-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This file defines all SC9860 clock indexes, it should be included in the
> device tree in which there's device using the clocks.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 08/12] dt-bindings: Add Spreadtrum clock binding documentation
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-9-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Introduce a new binding with its documentation for Spreadtrum clock
> sub-framework.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 07/12] clk: sprd: add adjustable pll support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-8-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Introduced a common adjustable pll clock driver for Spreadtrum SoCs.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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