* [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode
From: Hongzhou Yang @ 2016-12-01 0:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <42f5df18-2edd-08f2-a833-9c92ac85e87c@gmail.com>
On Wed, 2016-11-23 at 19:32 +0100, Matthias Brugger wrote:
> Hi Hongzhou,
>
> On 12/05/16 04:55, Hongzhou Yang wrote:
> > On Wed, 2016-05-11 at 19:09 -0700, Hongzhou Yang wrote:
> >> On Thu, 2016-05-12 at 09:41 +0800, chunfeng yun wrote:
> >>> Hi,
> >>>
> >>> On Wed, 2016-05-11 at 11:32 -0700, Hongzhou Yang wrote:
> >>>> On Wed, 2016-05-11 at 13:56 +0200, Linus Walleij wrote:
> >>>>> On Tue, May 10, 2016 at 10:23 AM, Chunfeng Yun
> >>>>> <chunfeng.yun@mediatek.com> wrote:
> >>>>>
> >>>>>> the default mode of GPIO16 pin is gpio, when set EINT16 to
> >>>>>> IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be
> >>>>>> fixed when set its default mode as usb iddig.
> >>>>>>
> >>>>>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> >>>>>
> >>>>
> >>>> Chunfeng, GPIO16 can be used as EINT16 mode, but the pinmux should be 0.
> >>>> If you want to set its default mode to iddig, you should set it in dts.
> >>>>
> >>> I set it in DTS, but it didn't work, because when usb driver requested
> >>> IRQ, pinmux was switched back to default mode set by
> >>> MTK_EINT_FUNCTION().
> >>>
> >>
> >> After confirmed, there are something wrong with data sheet and pinmux
> >> table, and GPIO16 can only receive interrupt by mode 1. So
> >>
> >> Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
> >>
> >
> > Linus,
> >
> > We find there are some other pins still have the same problem, so please
> > hold on it. Sorry for so much noise.
> >
>
> Did you made any progress on this? I didn't see any patch on the mailing
> list.
>
> Regards,
> Matthias
Hi Matthias,
Sorry for the late reply.
I have double confirmed with HW designer, other special EINTs are
built-in and they are using internal signal, they are not triggered
by GPIO, only GPIO16 should set to mode 1.
And, Chunfeng already re-sent this patch.
Thank you very much.
Yours,
Hongzhou
^ permalink raw reply
* [RESEND PATCH] pinctrl: mt8173: set GPIO16 to usb iddig mode
From: Hongzhou Yang @ 2016-12-01 0:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480472491-4644-1-git-send-email-chunfeng.yun@mediatek.com>
On Wed, 2016-11-30 at 10:21 +0800, Chunfeng Yun wrote:
> the default mode of GPIO16 pin is gpio, when set EINT16 to
> IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be
> fixed when set its default mode as usb iddig.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h b/drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h
> index 13e5b68..9b018fd 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h
> @@ -201,7 +201,7 @@
> MTK_PIN(
> PINCTRL_PIN(16, "IDDIG"),
> NULL, "mt8173",
> - MTK_EINT_FUNCTION(0, 16),
> + MTK_EINT_FUNCTION(1, 16),
> MTK_FUNCTION(0, "GPIO16"),
> MTK_FUNCTION(1, "IDDIG"),
> MTK_FUNCTION(2, "CMFLASH"),
Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
Thanks,
Hongzhou
^ permalink raw reply
* [resend V2:PATCH 0/2] add reset-hi3660
From: Zhangfei Gao @ 2016-12-01 0:48 UTC (permalink / raw)
To: linux-arm-kernel
Considering Arnd and Philipp suggestions,
move reset register to dts as table instead of dts header in case of ABI issue
Zhangfei Gao (2):
dt-bindings: Document the hi3660 reset bindings
reset: hisilicon: add reset-hi3660
.../bindings/reset/hisilicon,hi3660-reset.txt | 51 ++++++++
drivers/reset/hisilicon/Kconfig | 7 +
drivers/reset/hisilicon/Makefile | 1 +
drivers/reset/hisilicon/reset-hi3660.c | 144 +++++++++++++++++++++
4 files changed, 203 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
create mode 100644 drivers/reset/hisilicon/reset-hi3660.c
--
2.7.4
^ permalink raw reply
* [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Zhangfei Gao @ 2016-12-01 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480553321-17400-1-git-send-email-zhangfei.gao@linaro.org>
Add DT bindings documentation for hi3660 SoC reset controller.
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
---
.../bindings/reset/hisilicon,hi3660-reset.txt | 51 ++++++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
new file mode 100644
index 0000000..250daf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
@@ -0,0 +1,51 @@
+Hisilicon System Reset Controller
+======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller registers are part of the system-ctl block on
+hi3660 SoC.
+
+Required properties:
+- compatible: should be
+ "hisilicon,hi3660-reset"
+- #reset-cells: 1, see below
+- hisi,rst-syscon: phandle of the reset's syscon.
+- hisi,reset-bits: Contains the reset control register information
+ Should contain 2 cells for each reset exposed to
+ consumers, defined as:
+ Cell #1 : offset from the syscon register base
+ Cell #2 : bits position of the control register
+
+Example:
+ iomcu: iomcu at ffd7e000 {
+ compatible = "hisilicon,hi3660-iomcu", "syscon";
+ reg = <0x0 0xffd7e000 0x0 0x1000>;
+ };
+
+ iomcu_rst: iomcu_rst_controller {
+ compatible = "hisilicon,hi3660-reset";
+ #reset-cells = <1>;
+ hisi,rst-syscon = <&iomcu>;
+ hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
+ 0x20 0x10 /* 1: i2c1 */
+ 0x20 0x20 /* 2: i2c2 */
+ 0x20 0x8000000>; /* 3: i2c6 */
+ };
+
+Specifying reset lines connected to IP modules
+==============================================
+example:
+
+ i2c0: i2c at ..... {
+ ...
+ resets = <&iomcu_rst 0>;
+ ...
+ };
+
+ i2c1: i2c at ..... {
+ ...
+ resets = <&iomcu_rst 1>;
+ ...
+ };
--
2.7.4
^ permalink raw reply related
* [resend V2: PATCH 2/2] reset: hisilicon: add reset-hi3660
From: Zhangfei Gao @ 2016-12-01 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480553321-17400-1-git-send-email-zhangfei.gao@linaro.org>
Add hi3660 reset driver
Reset offset & bits should be listed in dts
Like:
iomcu_rst: iomcu_rst_controller {
compatible = "hisilicon,hi3660-reset";
#reset-cells = <1>;
hisi,rst-syscon = <&iomcu>;
hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
0x20 0x10 /* 1: i2c1 */
0x20 0x20 /* 2: i2c2 */
0x20 0x8000000>; /* 3: i2c6 */
};
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
---
drivers/reset/hisilicon/Kconfig | 7 ++
drivers/reset/hisilicon/Makefile | 1 +
drivers/reset/hisilicon/reset-hi3660.c | 144 +++++++++++++++++++++++++++++++++
3 files changed, 152 insertions(+)
create mode 100644 drivers/reset/hisilicon/reset-hi3660.c
diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig
index 1ff8b0c..10134dc 100644
--- a/drivers/reset/hisilicon/Kconfig
+++ b/drivers/reset/hisilicon/Kconfig
@@ -1,3 +1,10 @@
+config COMMON_RESET_HI3660
+ tristate "Hi3660 Reset Driver"
+ depends on ARCH_HISI || COMPILE_TEST
+ default ARCH_HISI
+ help
+ Build the Hisilicon Hi3660 reset driver.
+
config COMMON_RESET_HI6220
tristate "Hi6220 Reset Driver"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/reset/hisilicon/Makefile b/drivers/reset/hisilicon/Makefile
index c932f86..ab8a7bf 100644
--- a/drivers/reset/hisilicon/Makefile
+++ b/drivers/reset/hisilicon/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_COMMON_RESET_HI6220) += hi6220_reset.o
+obj-$(CONFIG_COMMON_RESET_HI3660) += reset-hi3660.o
diff --git a/drivers/reset/hisilicon/reset-hi3660.c b/drivers/reset/hisilicon/reset-hi3660.c
new file mode 100644
index 0000000..3307252
--- /dev/null
+++ b/drivers/reset/hisilicon/reset-hi3660.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) 2016-2017 Linaro Ltd.
+ * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
+ *
+ * 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.
+ */
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+struct hi3660_reset_data {
+ unsigned int off;
+ unsigned int bits;
+};
+
+struct hi3660_reset_controller {
+ struct reset_controller_dev rst;
+ struct regmap *map;
+ const struct hi3660_reset_data *datas;
+};
+
+#define to_hi3660_reset_controller(_rst) \
+ container_of(_rst, struct hi3660_reset_controller, rst)
+
+static int hi3660_reset_program_hw(struct reset_controller_dev *rcdev,
+ unsigned long idx, bool assert)
+{
+ struct hi3660_reset_controller *rc = to_hi3660_reset_controller(rcdev);
+ const struct hi3660_reset_data *d;
+
+ if (idx >= rcdev->nr_resets)
+ return -EINVAL;
+
+ d = &rc->datas[idx];
+
+ if (assert)
+ return regmap_write(rc->map, d->off, d->bits);
+ else
+ return regmap_write(rc->map, d->off + 4, d->bits);
+}
+
+static int hi3660_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ return hi3660_reset_program_hw(rcdev, idx, true);
+}
+
+static int hi3660_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ return hi3660_reset_program_hw(rcdev, idx, false);
+}
+
+static int hi3660_reset_dev(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ int err;
+
+ err = hi3660_reset_assert(rcdev, idx);
+ if (err)
+ return err;
+
+ return hi3660_reset_deassert(rcdev, idx);
+}
+
+static struct reset_control_ops hi3660_reset_ops = {
+ .reset = hi3660_reset_dev,
+ .assert = hi3660_reset_assert,
+ .deassert = hi3660_reset_deassert,
+};
+
+static int hi3660_reset_probe(struct platform_device *pdev)
+{
+ struct hi3660_reset_controller *rc;
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct hi3660_reset_data *datas;
+ const __be32 *list;
+ int size, nr, i;
+
+ rc = devm_kzalloc(dev, sizeof(*rc), GFP_KERNEL);
+ if (!rc)
+ return -ENOMEM;
+
+ rc->map = syscon_regmap_lookup_by_phandle(np, "hisi,rst-syscon");
+ if (IS_ERR(rc->map)) {
+ dev_err(dev, "failed to get hi3660,rst-syscon\n");
+ return PTR_ERR(rc->map);
+ }
+
+ list = of_get_property(np, "hisi,reset-bits", &size);
+ if (!list || (size / sizeof(*list)) % 2 != 0) {
+ dev_err(dev, "invalid DT reset description\n");
+ return -EINVAL;
+ }
+
+ nr = (size / sizeof(*list)) / 2;
+ datas = devm_kzalloc(dev, nr * sizeof(*datas), GFP_KERNEL);
+ if (!datas)
+ return -ENOMEM;
+
+ for (i = 0; i < nr; i++) {
+ datas[i].off = be32_to_cpup(list++);
+ datas[i].bits = be32_to_cpup(list++);
+ }
+
+ rc->rst.ops = &hi3660_reset_ops,
+ rc->rst.of_node = np;
+ rc->rst.nr_resets = nr;
+ rc->datas = datas;
+
+ return reset_controller_register(&rc->rst);
+}
+
+static const struct of_device_id hi3660_reset_match[] = {
+ { .compatible = "hisilicon,hi3660-reset", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, hi3660_reset_match);
+
+static struct platform_driver hi3660_reset_driver = {
+ .probe = hi3660_reset_probe,
+ .driver = {
+ .name = "hi3660-reset",
+ .of_match_table = hi3660_reset_match,
+ },
+};
+
+static int __init hi3660_reset_init(void)
+{
+ return platform_driver_register(&hi3660_reset_driver);
+}
+arch_initcall(hi3660_reset_init);
+
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:hi3660-reset");
+MODULE_DESCRIPTION("HiSilicon Hi3660 Reset Driver");
--
2.7.4
^ permalink raw reply related
* [rtc-linux] Re: [RFC PATCH 2/3] rtc: Add Amlogic Virtual Wake RTC
From: Alexandre Belloni @ 2016-12-01 0:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103153647.GD25852@remoulade>
On 03/11/2016 at 15:36:48 +0000, Mark Rutland wrote :
> > In order to be able to reuse the RTC wakealarm feature, this
> > driver implements a fake RTC device which uses the system time
> > to deduce a suspend delay.
>
> This sounds like an always-on oneshot timer device, not an RTC.
>
> > +static int meson_vrtc_read_time(struct device *dev, struct rtc_time *tm)
> > +{
> > + unsigned long local_time;
> > + struct timeval time;
> > +
> > + do_gettimeofday(&time);
> > + local_time = time.tv_sec - (sys_tz.tz_minuteswest * 60);
> > + rtc_time_to_tm(local_time, tm);
> > +
> > + return 0;
> > +}
>
> ... if this were a timer, you wouldn't need this hack.
>
The main issue I think is that the clockevents are not able to wakeup a
platform so it doesn't really fit as a timer inside the kernel.
I think it may be fine to handle that in the RTC subsystem for now.
The same issue can be seen with the flextimer on LS1021A:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/365597.html
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Sinan Kaya @ 2016-12-01 1:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201002812.GB9409@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn,
On 11/30/2016 7:28 PM, Bjorn Helgaas wrote:
> Actually, that raises a question for qualcomm and hisi: in the DT
> model, we use non-ECAM config accessors in the driver, but in the ACPI
> model, we use ECAM accessors. It seems like the accessors should be
> the same regardless of whether we discover the bridge via DT or ACPI.
For servers, we are only setting up the PCIe controller in ECAM mode in FW.
If somebody wants to use DT with QCOM Server (unsupported but possible),
they need to use pci-host-ecam-generic driver.
Here is an example:
pcie3 {
compatible = "pci-host-ecam-generic";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
bus-range = <0x0 0xff>;
linux,pci-domain = <3>;
// CPU_PHYSICAL(2) SIZE(2)
reg = <0xC00 0x00000000 0x0 0x10000000>;
...
}
I think you are referring to this driver here.
obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
This driver is only in use by the mobile products.
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v10 10/13] drm/mediatek: add dsi ulp mode control
From: CK Hu @ 2016-12-01 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480070076-6196-11-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> modify dsi enter ultra low power mode method
>
This looks like a power-saving patch. I think without this, MT2701 could
still work correctly. The commit message is too simple, please describe
why this patch is related to MT2701. If it is not related to MT2701,
move this patch out of MT2701 series and send it independently.
Regards,
CK
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index d03a0f1..01df829 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -289,7 +289,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
> {
> mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
> - mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
> + mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, LC_ULPM_EN);
> }
>
> static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
> @@ -302,7 +302,7 @@ static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
> static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
> {
> mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
> - mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
> + mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, LD0_ULPM_EN);
> }
>
> static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the arm-soc tree
From: Stephen Rothwell @ 2016-12-01 1:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
arch/arm64/boot/dts/broadcom/ns2.dtsi
between commit:
e79249143f46 ("arm64: dts: Add Broadcom Northstar2 device tree entries for PDC driver.")
from the arm-soc tree and commit:
dddc3c9d7d02 ("arm64: dts: NS2: add AMAC ethernet support")
from the net-next 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.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/boot/dts/broadcom/ns2.dtsi
index 863503d78f57,773ed593da4d..000000000000
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@@ -197,42 -191,18 +197,54 @@@
#include "ns2-clock.dtsi"
+ pdc0: iproc-pdc0 at 612c0000 {
+ compatible = "brcm,iproc-pdc-mbox";
+ reg = <0x612c0000 0x445>; /* PDC FS0 regs */
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ brcm,rx-status-len = <32>;
+ brcm,use-bcm-hdr;
+ };
+
+ pdc1: iproc-pdc1 at 612e0000 {
+ compatible = "brcm,iproc-pdc-mbox";
+ reg = <0x612e0000 0x445>; /* PDC FS1 regs */
+ interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ brcm,rx-status-len = <32>;
+ brcm,use-bcm-hdr;
+ };
+
+ pdc2: iproc-pdc2 at 61300000 {
+ compatible = "brcm,iproc-pdc-mbox";
+ reg = <0x61300000 0x445>; /* PDC FS2 regs */
+ interrupts = <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ brcm,rx-status-len = <32>;
+ brcm,use-bcm-hdr;
+ };
+
+ pdc3: iproc-pdc3 at 61320000 {
+ compatible = "brcm,iproc-pdc-mbox";
+ reg = <0x61320000 0x445>; /* PDC FS3 regs */
+ interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ brcm,rx-status-len = <32>;
+ brcm,use-bcm-hdr;
+ };
+
+ enet: ethernet at 61000000 {
+ compatible = "brcm,ns2-amac";
+ reg = <0x61000000 0x1000>,
+ <0x61090000 0x1000>,
+ <0x61030000 0x100>;
+ reg-names = "amac_base", "idm_base", "nicpm_base";
+ interrupts = <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>;
+ phy-handle = <&gphy0>;
+ phy-mode = "rgmii";
+ status = "disabled";
+ };
+
dma0: dma at 61360000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x61360000 0x1000>;
^ permalink raw reply
* [alsa-devel] [PATCH v2] clkdev: add devm_of_clk_get()
From: Kuninori Morimoto @ 2016-12-01 1:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874m2pbwsn.wl%kuninori.morimoto.gx@renesas.com>
Hi Stephen, again
Can I confirm ??
Was I misunderstanding ??
> I understand your point, but I think devm_get_clk_from_child()
> needs new DT setings, and it can't keep compatibility, or
> it makes driver complex.
> I think it is nice to have. but, I want to keep current style.
> Thus, I will try to use current of_clk_get() as-is, and
> call clk_free() somehow in this driver.
------ Pattern1 -----------
sound_soc {
clocks = <&xxx>, <&xxx>;
clock-names = "cpu", "codec";
...
cpu { /* of_cpu_node */
...
};
codec { /* of_codec_node */
...
};
};
----------------------------
Do you mean, this case we can use
devm_get_clk_from_child(dev, of_cpu_node, "cpu");
devm_get_clk_from_child(dev, of_codec_node, "codec");
------ Pattern2 -----------
sound_soc {
...
cpu { /* of_cpu_node */
clocks = <&xxx>;
...
};
codec { /* of_codec_node */
clocks = <&xxx>;
...
};
};
----------------------------
And, this case, we can use
devm_get_clk_from_child(dev, of_cpu_node, NULL);
devm_get_clk_from_child(dev, of_codec_node, NULL);
If so, I can use it without DT change.
^ permalink raw reply
* [PATCH v2] arm64: dts: zx: add zx296718's topcrm node
From: Jun Nie @ 2016-12-01 1:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480499418-13905-1-git-send-email-baoyou.xie@linaro.org>
2016-11-30 17:50 GMT+08:00 Baoyou Xie <baoyou.xie@linaro.org>:
> Enable topcrm clock node for zx296718, which is used for
> CPU's frequency change.
Please reference other device tree patches title to add a simple title
with category information. Such as
arm64: dts: uniphier: change MIO node to SD control node
>
> Furthermore, this patch adds the CPU clock phandle in CPU's node
> and uses operating-points-v2 to register operating points.
>
> So it can be used by cpufreq-dt driver.
Detail comment should provide more information to support title. So
topcrm and cpu freq changes shall be split into two patches.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> arch/arm64/boot/dts/zte/zx296718.dtsi | 43 +++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
> index 6b239a3..992158a 100644
> --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> @@ -44,6 +44,7 @@
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/clock/zx296718-clock.h>
>
> / {
> compatible = "zte,zx296718";
> @@ -81,6 +82,8 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x0>;
> enable-method = "psci";
> + clocks = <&topcrm A53_GATE>;
> + operating-points-v2 = <&cluster0_opp>;
> };
>
> cpu1: cpu at 1 {
> @@ -88,6 +91,7 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x1>;
> enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
> };
>
> cpu2: cpu at 2 {
> @@ -95,6 +99,7 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x2>;
> enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
> };
>
> cpu3: cpu at 3 {
> @@ -102,6 +107,38 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x3>;
> enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
> + };
> + };
> +
> + cluster0_opp: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp at 500000000 {
> + opp-hz = /bits/ 64 <500000000>;
> + opp-microvolt = <857000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 648000000 {
> + opp-hz = /bits/ 64 <648000000>;
> + opp-microvolt = <857000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 800000000 {
> + opp-hz = /bits/ 64 <800000000>;
> + opp-microvolt = <882000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1000000000 {
> + opp-hz = /bits/ 64 <1000000000>;
> + opp-microvolt = <892000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1188000000 {
> + opp-hz = /bits/ 64 <1188000000>;
> + opp-microvolt = <1009000>;
> + clock-latency-ns = <500000>;
> };
I see 1600m and 1800m for a53 clock source in clk driver. Aren't they
supported by product chip?
> };
>
> @@ -279,6 +316,12 @@
> dma-requests = <32>;
> };
>
> + topcrm: clock-controller at 1461000 {
> + compatible = "zte,zx296718-topcrm";
> + reg = <0x01461000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
Top clock nodes patch is just merged into linux-next. You can prepare
your patch based on it.
https://www.spinics.net/lists/arm-kernel/msg535883.html
> sysctrl: sysctrl at 1463000 {
> compatible = "zte,zx296718-sysctrl", "syscon";
> reg = <0x1463000 0x1000>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v4] clkdev: add devm_of_clk_get()
From: Kuninori Morimoto @ 2016-12-01 1:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129212600.GH6095@codeaurora.org>
Hi Stephen
> > Current Linux has of_clk_get(), but doesn't have devm_of_clk_get().
> > This patch adds it. It is implemeted in clk-devres.c to share
> > devm_clk_release().
>
> Please add an explanation of why we want this sort of API. The
> example you gave for audio sound card is useful. We're not going
> to remember 5 months from now why we did something, so we should
> put that here instead of digging through mailing list archives.
OK, will do
> > +struct clk *devm_of_clk_get(struct device *dev,
> > + struct device_node *np, int index)
>
> Please call this devm_get_clk_from_child() instead. Also, replace
> the index argument with a string called con_id. Then call
> of_clk_get_by_name() instead of of_clk_get().
I guess we want to have _of_ on function name ?
devm_get_clk_from_child() ?
devm_of_get_clk_from_child ?
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Icenowy Zheng @ 2016-12-01 2:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130205233.mwfqlfuqg4cefink@lukather>
01.12.2016, 04:52, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Wed, Nov 30, 2016 at 09:41:26PM +0100, Jernej ?krabec wrote:
>> ?> > > > The only
>> ?> > > > code left from you is for DE2. HDMI stuff is basically copied from
>> ?> > > > Rockhip
>> ?> > > > driver (including EDID reading), TCON code is now reverted to the same
>> ?> > > > as
>> ?> > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
>> ?> > > > code
>> ?> > > > and compare it.
>> ?> > >
>> ?> > > So is the TCON of DE 2.0 identical to the original TCON?
>> ?> > >
>> ?> > > If so, we should reuse sun4i-tcon ...
>> ?> >
>> ?> > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
>> ?> > one for TV. However, register offsets are same as before, so I guess
>> ?> > driver reusage make sense. I think that there are few additional
>> ?> > registers, but they can be ignored for simplefb.
>> ?>
>> ?> The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
>> ?> clock and I/O area.
>> ?>
>>
>> ?True, H3 user manual can be misleading sometimes. But this doesn't change the
>> ?fact that TCON0 has same register offsets with same meaning.
>
> Then yes, we should definitely share the drivers too. So, in the end,
> the only thing that is actually new is the display-engine?
And HDMI PHY on H3 ;-)
In my opinion, we should just put sun8i-de2-drm related code into drivers/gpu/drm/sun4i/ .
(Or rename the directory to sunxi)
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough
From: Dennis Chen @ 2016-12-01 2:15 UTC (permalink / raw)
To: linux-arm-kernel
The __pci_enable_msi_range() should return -ENOSPC instead of -EINVAL
when the device doesn't have enough vectors as required, just as the
MSI-X vector allocator does in __pci_enable_msix_range(). Otherwise,
some drivers depending on that return value will probably fallback to
the legacy interrupt directly, for example, in commit 17a51f12cfbd2814
("ahci: only try to use multi-MSI mode if there is more than 1 port"), the
ahci driver will fallback to single MSI mode only when the return value
is -ENOSPC in case of required vectors is not enough, else the driver will
use legacy interrupt which has been observed on a x86 box with 6-port SATA
controller.
With this patch, when a MSI-capable device doesn't have enough MSI
vectors as requested, it will fallback to single MSI mode while not
legacy interrupt.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Tom Long Nguyen <tom.l.nguyen@intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: linux-ide at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
drivers/pci/msi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index ad70507..da37113 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1084,7 +1084,7 @@ static int __pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec,
if (nvec < 0)
return nvec;
if (nvec < minvec)
- return -EINVAL;
+ return -ENOSPC;
if (nvec > maxvec)
nvec = maxvec;
--
2.7.4
^ permalink raw reply related
* [PATCHv4 07/10] kexec: Switch to __pa_symbol
From: Dave Young @ 2016-12-01 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-8-git-send-email-labbott@redhat.com>
Hi, Laura
On 11/29/16 at 10:55am, Laura Abbott wrote:
>
> __pa_symbol is the correct api to get the physical address of kernel
> symbols. Switch to it to allow for better debug checking.
>
I assume __pa_symbol is faster than __pa, but it still need some testing
on all arches which support kexec.
But seems long long ago there is a commit e3ebadd95cb in the commit log
I see below from:
"we should deprecate __pa_symbol(), and preferably __pa() too - and
just use "virt_to_phys()" instead, which is is more readable and has
nicer semantics."
But maybe in modern code __pa_symbol is prefered I may miss background.
virt_to_phys still sounds more readable now for me though.
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> Found during review of the kernel. Untested.
> ---
> kernel/kexec_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 5616755..e1b625e 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1397,7 +1397,7 @@ void __weak arch_crash_save_vmcoreinfo(void)
>
> phys_addr_t __weak paddr_vmcoreinfo_note(void)
> {
> - return __pa((unsigned long)(char *)&vmcoreinfo_note);
> + return __pa_symbol((unsigned long)(char *)&vmcoreinfo_note);
> }
>
> static int __init crash_save_vmcoreinfo_init(void)
> --
> 2.7.4
>
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Thanks
Dave
^ permalink raw reply
* [PATCHv4 07/10] kexec: Switch to __pa_symbol
From: Eric W. Biederman @ 2016-12-01 3:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201024103.GA32438@dhcp-128-65.nay.redhat.com>
Dave Young <dyoung@redhat.com> writes:
> Hi, Laura
> On 11/29/16 at 10:55am, Laura Abbott wrote:
>>
>> __pa_symbol is the correct api to get the physical address of kernel
>> symbols. Switch to it to allow for better debug checking.
>>
>
> I assume __pa_symbol is faster than __pa, but it still need some testing
> on all arches which support kexec.
>
> But seems long long ago there is a commit e3ebadd95cb in the commit log
> I see below from:
> "we should deprecate __pa_symbol(), and preferably __pa() too - and
> just use "virt_to_phys()" instead, which is is more readable and has
> nicer semantics."
>
> But maybe in modern code __pa_symbol is prefered I may miss background.
> virt_to_phys still sounds more readable now for me though.
There has been a lot of history with the various definitions.
__pa_symbol used to be x86 specific.
Now what we have is that __pa_symbol is just __pa(RELOC_HIDE(x));
Now arguably that whole reloc hide thing should happen by architectures
having a non-inline version of __pa as was done in the commit you
mention. But at this point there appears to be nothing wrong with
changing a __pa to a __pa_symbol it might make things a tad more
reliable depending on the implementation of __pa.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Eric
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> Found during review of the kernel. Untested.
>> ---
>> kernel/kexec_core.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index 5616755..e1b625e 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -1397,7 +1397,7 @@ void __weak arch_crash_save_vmcoreinfo(void)
>>
>> phys_addr_t __weak paddr_vmcoreinfo_note(void)
>> {
>> - return __pa((unsigned long)(char *)&vmcoreinfo_note);
>> + return __pa_symbol((unsigned long)(char *)&vmcoreinfo_note);
>> }
>>
>> static int __init crash_save_vmcoreinfo_init(void)
>> --
>> 2.7.4
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>
> Thanks
> Dave
^ permalink raw reply
* [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Bjorn Helgaas @ 2016-12-01 3:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19e244f2-22f9-be94-0929-a9d96844b801@codeaurora.org>
On Wed, Nov 30, 2016 at 08:00:12PM -0500, Sinan Kaya wrote:
> Hi Bjorn,
>
> On 11/30/2016 7:28 PM, Bjorn Helgaas wrote:
> > Actually, that raises a question for qualcomm and hisi: in the DT
> > model, we use non-ECAM config accessors in the driver, but in the ACPI
> > model, we use ECAM accessors. It seems like the accessors should be
> > the same regardless of whether we discover the bridge via DT or ACPI.
>
> For servers, we are only setting up the PCIe controller in ECAM mode in FW.
> If somebody wants to use DT with QCOM Server (unsupported but possible),
> they need to use pci-host-ecam-generic driver.
>
> Here is an example:
>
> pcie3 {
> compatible = "pci-host-ecam-generic";
> device_type = "pci";
> #address-cells = <3>;
> #size-cells = <2>;
> bus-range = <0x0 0xff>;
> linux,pci-domain = <3>;
>
> // CPU_PHYSICAL(2) SIZE(2)
> reg = <0xC00 0x00000000 0x0 0x10000000>;
> ...
> }
>
> I think you are referring to this driver here.
>
> obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
>
> This driver is only in use by the mobile products.
https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=2bb62a60711e
says it's for the Qualcomm QDF2432. Is pcie-qcom for that same
device, or is it for something different?
I assume it's probably different because pci-host-ecam-generic uses
the standard ECAM accessors (pci_generic_ecam_ops), while the quirk
requires non-standard ones (pci_32b_ops).
If these are two different controllers, that's fine. If it's the same
controller in both cases, the controller should be configured the same
way (either by FW or by the DT driver) and we should use the same
accessors.
If you have to use different accessors for the same controller, you
would need some explanation for the difference because it's a
maintenance headache to operate a device in different modes depending
on the environment or which driver you're using.
Bjorn
^ permalink raw reply
* [Linaro-acpi] [PATCH v14] acpi, apei, arm64: APEI initial support for aarch64.
From: Fu Wei @ 2016-12-01 4:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1470834168-1780-1-git-send-email-fu.wei@linaro.org>
Hi Borislav, Rafael,
any comment or suggestion for this patch?
I wonder if there is anything I need to improve for it?
Or will it be accepted ?
Great thanks for your attention.
On 10 August 2016 at 21:02, <fu.wei@linaro.org> wrote:
> From: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>
> This patch provides APEI arch-specific bits for aarch64
>
> Meanwhile,
> (1)move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
> a generic place.
> (2)select HAVE_ACPI_APEI when EFI and ACPI is set on ARM64,
> because arch_apei_get_mem_attribute is using efi_mem_attributes on ARM64.
>
> [Fu Wei: improve && upstream]
>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Tested-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> Signed-off-by: Fu Wei <fu.wei@linaro.org>
> Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
> Acked-by: Will Deacon <will.deacon@arm.com>
> ---
> This patchset has been tested on the following platforms:
> (1)ARM Foundation v8 model
>
> Changelog:
> v14:https://lkml.org/lkml/2016/8/10/
> Delete hest_ia32_init().
> Fix a comment typo for acpi_disable_cmcff.
> Rebase to 4.8.0-rc1-ge6c4d92
>
> v13:https://lkml.org/lkml/2016/8/10/
> Fix a comment problem(add a "end").
> Add a comment for the definition of acpi_disable_cmcff.
> Rebase to 4.8.0-rc1-g372734a
>
> v12:https://lkml.org/lkml/2016/7/29/97
> Fix a comment problem(redundant "with").
> Rebase to 4.7.0-g680eee2.
>
> v11:https://lkml.org/lkml/2016/7/27/427
> Rebase to v4.7-0e06f5c0.
>
> v10:https://lkml.org/lkml/2016/4/14
> Fix the Alphabetical order problem in arch/arm64/Kconfig.
>
> v9: https://lkml.org/lkml/2016/4/5/522
> Improve the comment for arch_apei_flush_tlb_one.
> Using select "HAVE_ACPI_APEI if (ACPI && EFI)" to fix the EFI dependence
> problem.
>
> v8: https://lkml.org/lkml/2016/3/29/132
> Fix a "undefined reference" bug by selecting EFI when ACPI_APEI is set
> on ARM64.
>
> v7: https://lkml.org/lkml/2016/3/17/183
> Add comment for arch_apei_flush_tlb_one in arch/arm64/include/asm/acpi.h.
>
> v6: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006644.html
> Move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
> a generic place.
> Delete HAVE_ACPI_APEI_HEST_IA32.
>
> v5: https://lkml.org/lkml/2015/12/10/131
> Add "HAVE_ACPI_APEI_HEST_IA32" instead of
> "#if defined(__i386__) || defined(__x86_64__)".
>
> v4: https://lkml.org/lkml/2015/12/8/188
> Rebase to latest kernel version(4.4-rc4).
> Move arch_apei_flush_tlb_one into header file as a inline function
> Add a new subfunction "hest_ia_init" for "acpi_disable_cmcff".
>
> v3: https://lkml.org/lkml/2015/12/3/521
> Remove "acpi_disable_cmcff" from arm64 code,
> and wrap it in hest.c by "#if defined(__i386__) || defined(__x86_64__)"
>
> v2: https://lkml.org/lkml/2015/12/2/432
> Rebase to latest kernel version(4.4-rc3).
> Move arch_apei_flush_tlb_one() to arch/arm64/kernel/acpi.c
>
> v1: https://lkml.org/lkml/2015/8/14/199
> Move arch_apei_flush_tlb_one() to arch/arm64/include/asm/apci.h.
> Delete arch/arm64/kernel/apei.c.
> Add "#ifdef CONFIG_ACPI_APEI" for "acpi_disable_cmcff".
>
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/acpi.h | 22 +++++++++++++++++++++-
> arch/x86/kernel/acpi/apei.c | 3 ---
> drivers/acpi/apei/hest.c | 13 ++++++++++---
> 4 files changed, 32 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index bc3f00f..385cf13 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -51,6 +51,7 @@ config ARM64
> select GENERIC_TIME_VSYSCALL
> select HANDLE_DOMAIN_IRQ
> select HARDIRQS_SW_RESEND
> + select HAVE_ACPI_APEI if (ACPI && EFI)
> select HAVE_ALIGNED_STRUCT_PAGE if SLUB
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_BITREVERSE
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 5420cb0..f435967 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -17,6 +17,7 @@
>
> #include <asm/cputype.h>
> #include <asm/smp_plat.h>
> +#include <asm/tlbflush.h>
>
> /* Macros for consistency checks of the GICC subtable of MADT */
> #define ACPI_MADT_GICC_LENGTH \
> @@ -110,8 +111,27 @@ static inline const char *acpi_get_enable_method(int cpu)
> }
>
> #ifdef CONFIG_ACPI_APEI
> +/*
> + * acpi_disable_cmcff is used in drivers/acpi/apei/hest.c for disabling
> + * IA-32 Architecture Corrected Machine Check (CMC) Firmware-First mode by
> + * boot parameter(acpi=nocmcff). But we don't have this IA-32 specific
> + * feature on ARM64, this definition is only for compatibility.
> + */
> +#define acpi_disable_cmcff 1
> pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
> -#endif
> +
> +/*
> + * Despite its name, this function must still broadcast the TLB
> + * invalidation in order to ensure other CPUs don't end up with junk
> + * entries as a result of speculation. Unusually, its also called in
> + * IRQ context (ghes_iounmap_irq) so if we ever need to use IPIs for
> + * TLB broadcasting, then we're in trouble here.
> + */
> +static inline void arch_apei_flush_tlb_one(unsigned long addr)
> +{
> + flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> +}
> +#endif /* CONFIG_ACPI_APEI */
>
> #ifdef CONFIG_ACPI_NUMA
> int arm64_acpi_numa_init(void);
> diff --git a/arch/x86/kernel/acpi/apei.c b/arch/x86/kernel/acpi/apei.c
> index c280df6..ea3046e 100644
> --- a/arch/x86/kernel/acpi/apei.c
> +++ b/arch/x86/kernel/acpi/apei.c
> @@ -24,9 +24,6 @@ int arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr, void *data)
> struct acpi_hest_ia_corrected *cmc;
> struct acpi_hest_ia_error_bank *mc_bank;
>
> - if (hest_hdr->type != ACPI_HEST_TYPE_IA32_CORRECTED_CHECK)
> - return 0;
> -
> cmc = (struct acpi_hest_ia_corrected *)hest_hdr;
> if (!cmc->enabled)
> return 0;
> diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
> index 20b3fcf..8f2a98e 100644
> --- a/drivers/acpi/apei/hest.c
> +++ b/drivers/acpi/apei/hest.c
> @@ -123,7 +123,13 @@ EXPORT_SYMBOL_GPL(apei_hest_parse);
> */
> static int __init hest_parse_cmc(struct acpi_hest_header *hest_hdr, void *data)
> {
> - return arch_apei_enable_cmcff(hest_hdr, data);
> + if (hest_hdr->type != ACPI_HEST_TYPE_IA32_CORRECTED_CHECK)
> + return 0;
> +
> + if (!acpi_disable_cmcff)
> + return !arch_apei_enable_cmcff(hest_hdr, data);
> +
> + return 0;
> }
>
> struct ghes_arr {
> @@ -232,8 +238,9 @@ void __init acpi_hest_init(void)
> goto err;
> }
>
> - if (!acpi_disable_cmcff)
> - apei_hest_parse(hest_parse_cmc, NULL);
> + rc = apei_hest_parse(hest_parse_cmc, NULL);
> + if (rc)
> + goto err;
>
> if (!ghes_disable) {
> rc = apei_hest_parse(hest_parse_ghes_count, &ghes_count);
> --
> 2.5.5
>
> _______________________________________________
> Linaro-acpi mailing list
> Linaro-acpi at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-acpi
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* arasan,sdhci.txt "compatibility" DT binding
From: Shawn Lin @ 2016-12-01 4:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <583C50E7.6030400@free.fr>
On 2016/11/28 23:44, Mason wrote:
> Hello,
>
> @Shawn Lin, could you take a look below and tell me exactly
> which IP core(s) Rockchip is using in its SoCs?
>
From the Host Controller version register (0xfe)
bit[7:0]: 0x2 : specification version number is 3.00
bit[15:8]: 0x10: Vendor version number is 1.0
Command Queueing version register (0x200)
bit[11:8]: 0x5 eMMC Major version number
bit[7:4]: 0x1 eMMC manor version number
bit[3:0]: 0x0 eMMC version suffix
User guide "eMMC 5.1/SD3.0/SDIO3.0 Host Controller"
Revision number: 1.14
Released on Dec. 2014
> Based on the feedback I received, here is an updated list of
> compatible strings and controller versions dealt with by the
> drivers/mmc/host/sdhci-of-arasan.c code.
>
>
> Xilinx Zynq:
> "SD2.0 / SDIO2.0 / MMC3.31 AHB Host Controller"
> "arasan,sdhci-8.9a"
> NB: 8.9a is the documentation revision (dated 2011-10-19)
> subsequent tweaks labeled 9.0a, 9.1a, 9.2a
>
> Xilinx ZynqMP:
> "SD3.0 / SDIO3.0 / eMMC4.51 AHB Host Controller"
> "arasan,sdhci-8.9a"
> NB: using the same compatible string as Zynq
>
> Sigma SMP87xx
> "SD3.0 / SDIO3.0 / eMMC4.4 AHB Host Controller"
> no compatible string yet, platform-specific init required
>
> APM:
> "SD3.0 / SDIO3.0 / eMMC4.41 AHB Host Controller"
> "arasan,sdhci-4.9a"
> NB: 4.9a appears to be the documentation revision
> no functional diff with "arasan,sdhci-8.9a"
>
> Rockchip
> Exact IP unknown, waiting for Shawn's answer
> "arasan,sdhci-5.1"
> NB: 5.1 appears to refer to the eMMC standard supported
>
>
> On a final note, there are many variations of the Arasan IP.
> I've tracked down at least the following:
>
> SD_2.0_SDIO_2.0__MMC_3.31_AHB_Host_Controller.pdf
> SD_3.0_SDIO_3.0_eMMC_4.41_OCP_Host_Controller.pdf
> SD_3.0_SDIO_3.0_eMMC_4.4__AHB_Host_Controller.pdf
> SD_3.0_SDIO_3.0_eMMC_4.51_Host_Controller.pdf
> SD_3.0_SDIO_3.0_eMMC_4.5__Host_Controller.pdf
> SD_4.1_SDIO_4.1_eMMC_4.51_Host_Controller.pdf
> SD_4.1_SDIO_4.1_eMMC_5.1__Host_Controller.pdf
>
> It seems to me the compatible string should specify
> the SD/SDIO version AND the eMMC version, since it
> seems many combinations are allowed, e.g. eMMC 4.51
> has two possible SD versions.
>
> What do you think?
>
> Regards.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Sinan Kaya @ 2016-12-01 4:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201034817.GA19681@bhelgaas-glaptop.roam.corp.google.com>
On 11/30/2016 10:48 PM, Bjorn Helgaas wrote:
> On Wed, Nov 30, 2016 at 08:00:12PM -0500, Sinan Kaya wrote:
>> Hi Bjorn,
>>
>> On 11/30/2016 7:28 PM, Bjorn Helgaas wrote:
>>> Actually, that raises a question for qualcomm and hisi: in the DT
>>> model, we use non-ECAM config accessors in the driver, but in the ACPI
>>> model, we use ECAM accessors. It seems like the accessors should be
>>> the same regardless of whether we discover the bridge via DT or ACPI.
>>
>> For servers, we are only setting up the PCIe controller in ECAM mode in FW.
>> If somebody wants to use DT with QCOM Server (unsupported but possible),
>> they need to use pci-host-ecam-generic driver.
>>
>> Here is an example:
>>
>> pcie3 {
>> compatible = "pci-host-ecam-generic";
>> device_type = "pci";
>> #address-cells = <3>;
>> #size-cells = <2>;
>> bus-range = <0x0 0xff>;
>> linux,pci-domain = <3>;
>>
>> // CPU_PHYSICAL(2) SIZE(2)
>> reg = <0xC00 0x00000000 0x0 0x10000000>;
>> ...
>> }
>>
>> I think you are referring to this driver here.
>>
>> obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
>>
>> This driver is only in use by the mobile products.
>
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=2bb62a60711e
> says it's for the Qualcomm QDF2432. Is pcie-qcom for that same
> device, or is it for something different?
They are different controllers.
Qualcomm QDF2432 only supports ECAM mode only and is designed for
ACPI based server products by the Data Center division.
If somebody really needs device tree for QDF2432 server chip even though
we don't officially support it, generic host driver with ECAM mode
is the way to go.
Even there, we need a small patch to pci_generic_ecam_ops as follows due
to quirky HW. Generic host driver won't work out of the box.
struct pci_ecam_ops pci_generic_ecam_ops = {
.bus_shift = 20,
.pci_ops = {
.map_bus = pci_ecam_map_bus,
- .read = pci_generic_config_read,
+ .read = pci_generic_config_read32,
- .write = pci_generic_config_write,
+ .write = pci_generic_config_write32,
}
};
This is essentially what pci_32b_ops is. Since device-tree is not officially
supported, we didn't bother making changes to the generic host bridge driver.
https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=2bb62a60711e
is the only thing needed for QDF2432.
>
> I assume it's probably different because pci-host-ecam-generic uses
> the standard ECAM accessors (pci_generic_ecam_ops), while the quirk
> requires non-standard ones (pci_32b_ops).
>
> If these are two different controllers, that's fine. If it's the same
> controller in both cases, the controller should be configured the same
> way (either by FW or by the DT driver) and we should use the same
> accessors.
>
> If you have to use different accessors for the same controller, you
> would need some explanation for the difference because it's a
> maintenance headache to operate a device in different modes depending
> on the environment or which driver you're using.
>
> Bjorn
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCHv4 07/10] kexec: Switch to __pa_symbol
From: Dave Young @ 2016-12-01 4:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87polc7357.fsf@xmission.com>
On 11/30/16 at 09:13pm, Eric W. Biederman wrote:
> Dave Young <dyoung@redhat.com> writes:
>
> > Hi, Laura
> > On 11/29/16 at 10:55am, Laura Abbott wrote:
> >>
> >> __pa_symbol is the correct api to get the physical address of kernel
> >> symbols. Switch to it to allow for better debug checking.
> >>
> >
> > I assume __pa_symbol is faster than __pa, but it still need some testing
> > on all arches which support kexec.
> >
> > But seems long long ago there is a commit e3ebadd95cb in the commit log
> > I see below from:
> > "we should deprecate __pa_symbol(), and preferably __pa() too - and
> > just use "virt_to_phys()" instead, which is is more readable and has
> > nicer semantics."
> >
> > But maybe in modern code __pa_symbol is prefered I may miss background.
> > virt_to_phys still sounds more readable now for me though.
>
> There has been a lot of history with the various definitions.
> __pa_symbol used to be x86 specific.
>
> Now what we have is that __pa_symbol is just __pa(RELOC_HIDE(x));
>
> Now arguably that whole reloc hide thing should happen by architectures
> having a non-inline version of __pa as was done in the commit you
> mention. But at this point there appears to be nothing wrong with
> changing a __pa to a __pa_symbol it might make things a tad more
> reliable depending on the implementation of __pa.
Then it is safe and reasonable, thanks for the clarification.
>
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
>
> Eric
>
> >> Signed-off-by: Laura Abbott <labbott@redhat.com>
> >> ---
> >> Found during review of the kernel. Untested.
> >> ---
> >> kernel/kexec_core.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> >> index 5616755..e1b625e 100644
> >> --- a/kernel/kexec_core.c
> >> +++ b/kernel/kexec_core.c
> >> @@ -1397,7 +1397,7 @@ void __weak arch_crash_save_vmcoreinfo(void)
> >>
> >> phys_addr_t __weak paddr_vmcoreinfo_note(void)
> >> {
> >> - return __pa((unsigned long)(char *)&vmcoreinfo_note);
> >> + return __pa_symbol((unsigned long)(char *)&vmcoreinfo_note);
> >> }
> >>
> >> static int __init crash_save_vmcoreinfo_init(void)
> >> --
> >> 2.7.4
> >>
> >>
> >> _______________________________________________
> >> kexec mailing list
> >> kexec at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/kexec
> >
> > Thanks
> > Dave
^ permalink raw reply
* [PATCH] Platform: Exynos4-is: Clean up file handle in open() error path.
From: Shailendra Verma @ 2016-12-01 4:40 UTC (permalink / raw)
To: linux-arm-kernel
The File handle is not yet added in the vfd list.So no need to call
v4l2_fh_del(&ctx->fh) if it fails to create control.
Signed-off-by: Shailendra Verma <shailendra.v@samsung.com>
---
drivers/media/platform/exynos4-is/fimc-m2m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-m2m.c b/drivers/media/platform/exynos4-is/fimc-m2m.c
index 6028e4f..d8724fe 100644
--- a/drivers/media/platform/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/exynos4-is/fimc-m2m.c
@@ -663,8 +663,8 @@ static int fimc_m2m_open(struct file *file)
v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
error_c:
fimc_ctrls_delete(ctx);
-error_fh:
v4l2_fh_del(&ctx->fh);
+error_fh:
v4l2_fh_exit(&ctx->fh);
kfree(ctx);
unlock:
--
1.7.9.5
^ permalink raw reply related
* [PATCH] Platform: Exynos-gsc: Clean up file handle in open() error path.
From: Shailendra Verma @ 2016-12-01 4:42 UTC (permalink / raw)
To: linux-arm-kernel
The File handle is not yet added in the vfd list.So no need to call
v4l2_fh_del(&ctx->fh) if it fails to create control.
Signed-off-by: Shailendra Verma <shailendra.v@samsung.com>
---
drivers/media/platform/exynos-gsc/gsc-m2m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 9f03b79..5ea97c1 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -664,8 +664,8 @@ static int gsc_m2m_open(struct file *file)
error_ctrls:
gsc_ctrls_delete(ctx);
-error_fh:
v4l2_fh_del(&ctx->fh);
+error_fh:
v4l2_fh_exit(&ctx->fh);
kfree(ctx);
unlock:
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 0/2] Support for Axentia TSE-850
From: Peter Rosin @ 2016-12-01 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5198068.r9o6jcztHW@wuerfel>
On 2016-11-30 23:25, Arnd Bergmann wrote:
> On Wednesday, November 30, 2016 1:48:20 PM CET Peter Rosin wrote:
>> Hi!
>>
>> changes v2 -> v3
>> - document the new compatible strings prefixed with "axentia,".
>>
>> changes v1 -> v2
>> - squash the fixup into the correct patch, sorry for the noise.
>>
>> After finally having all essintial drivers upstreamed (the
>> last ones are currently in -next) I would like to have the
>> dts and the defconfig also upstreamed.
>>
>> Cheers,
>> Peter
>>
>> Peter Rosin (2):
>> ARM: dts: add devicetree for the Axentia TSE-850
>> ARM: tse850_defconfig: add Axentia TSE-850
>>
>> Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
>> MAINTAINERS | 8 +
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/axentia-linea.dtsi | 53 +++++
>> arch/arm/boot/dts/axentia-tse850-3.dts | 276 ++++++++++++++++++++++
>> arch/arm/configs/tse850_defconfig | 223 +++++++++++++++++
>> 6 files changed, 580 insertions(+)
>
> Hi Peter,
>
> I'm a bit confused. Are these just boards using the sama5d31 SoC,
> or something else?
No no, it's just what it seems, a cpu module with a sama5d31 and a
board using it (a couple more boards using the cpu module coming
later). I just didn't know about the naming conventions.
> Normally, dts files are picked up by the SoC platform maintainers
> and named with a prefix for that soc.
I was starting to wonder about the deafening silence, now I know
the reason...
> Also, we don't normally add a defconfig file for a specific
> machine, just add the options you want to sama5_defconfig
> and multi_v7_defconfig, and send all patches to the
> at91 maitainers.
I'll make some changes, thank you very much for the pointers!
Cheers,
Peter
^ permalink raw reply
* [PATCH v10 0/8] arm/arm64: vgic: Implement API for vGICv3 live migration
From: vijay.kilari at gmail.com @ 2016-12-01 7:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
This patchset adds API for saving and restoring
of VGICv3 registers to support live migration with new vgic feature.
This API definition is as per version of VGICv3 specification
Documentation/virtual/kvm/devices/arm-vgic-v3.txt
The patch 3 & 4 are picked from the Pavel's previous implementation.
http://www.spinics.net/lists/kvm/msg122040.html
NOTE: Only compilation tested for AArch32. No hardware to test.
v9 => v10:
- Dropped support for AArch32 mode.
- Fixed line level update
- Updated documentation
- Moved vgic-sys-reg-v3.c to arch/arm64/kvm/ and
added vgic-v3-coproc.c to arch/arm/kvm for AArch32
- Fixed nits
v8 => v9:
- Rebased to kvmarm/next branch
- Introduce support for save and restore of CPU interface
registers for AArch32 mode (9,10 and 11 patches).
Only compilation tested.
- Fixed vmcr.ctlr format
- Updated error code for invalid CPU REG value in Documentation
- Updated commit messages and added comments required
- Queued IRQ when irq_line is set.
- Compatibility check on ICC_CTLR_EL1.SEIS and A3V
v7 => v8:
- Rebased to 4.9-rc3
- Fixed wrong parameter to VGIC_TO_MPIDR
v6 => v7:
- Rename all patches heading from vgic-new to vgic
- Moved caching of priority and ID bits from vgic global struct
to vgic_cpu struct.
v5 => v6:
- Collated all register definitions to single patch (4)
- Introduce macro to convert userspace MPIDR format to MPIDR reg format
- Check on ICC_CTLR_EL1.CBPR value is made while accessing ICC_BPR1_EL1
- Cached ich_vtr_el2 and guests priority and ID bits
- Check on number of priority and ID bits when ICC_CTRL_EL1 write is made
- Check is made on SRE bit for ICC_SRE_EL1 write
v4 => v5:
- ICC_CTLR_EL1 access is updated to reflect HW values
- Updated ICC reg access mask and shift macros
- Introduced patch 4 for VMCR changes
- Other minor fixes.
v3 => v4:
- Rebased to latest code base
- Moved vgic_uaccess() from vgic-mmio-v2.c to vgic-mmio.c
- Dropped macro REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED_UACCESS
- Dropped LE conversion for userspace access
- Introduced vgic_uaccess_write_pending() for ISPENDR write
- Change macro KVM_DEV_ARM_VGIC_V3_CPUID_MASK to KVM_DEV_ARM_VGIC_V3_MIDR_MASK
- Refactored some code as common code.
- Changed handing of ICC_* registers
- Allowed ICC_SRE_EL1 read by userspace
- Fixed KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_* macros
v2 => v3:
- Implemented separate API for ISPENDR and ICPENDR to
read soft_pending instead of pending for level triggerred interrupts
- Implemented ioctl KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO to access line level
- Rebased on top of Christoffer's patch set
http://www.spinics.net/lists/kvm/msg136840.html
NOTE: GICD_STATUSR and GICR_STATUSR are implemented as RAZ/WI.
v1 => v2:
- The init sequence change patch is no more required.
Fixed in patch 2 by using static vgic_io_dev regions structure instead
of using dynamic allocation pointer.
- Updated commit message of patch 4.
- Dropped usage of union to manage 32-bit and 64-bit access in patch 1.
Used local variable for 32-bit access.
- Updated macro __ARM64_SYS_REG and ARM64_SYS_REG in
arch/arm64/include/uapi/asm/kvm.h as per qemu requirements.
Vijaya Kumar K (8):
arm/arm64: vgic: Implement support for userspace access
arm/arm64: vgic: Add distributor and redistributor access
arm/arm64: vgic: Introduce find_reg_by_id()
irqchip/gic-v3: Add missing system register definitions
arm/arm64: vgic: Introduce VENG0 and VENG1 fields to vmcr struct
arm/arm64: vgic: Implement VGICv3 CPU interface access
arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
arm/arm64: Documentation: Update arm-vgic-v3.txt
Documentation/virtual/kvm/devices/arm-vgic-v3.txt | 9 +-
arch/arm/include/uapi/asm/kvm.h | 13 +
arch/arm/kvm/Makefile | 4 +-
arch/arm/kvm/vgic-v3-coproc.c | 35 +++
arch/arm64/include/uapi/asm/kvm.h | 13 +
arch/arm64/kvm/Makefile | 3 +-
arch/arm64/kvm/sys_regs.c | 22 +-
arch/arm64/kvm/sys_regs.h | 4 +
arch/arm64/kvm/vgic-sys-reg-v3.c | 338 ++++++++++++++++++++++
include/kvm/arm_vgic.h | 9 +
include/linux/irqchip/arm-gic-v3.h | 45 ++-
virt/kvm/arm/vgic/vgic-kvm-device.c | 215 +++++++++++++-
virt/kvm/arm/vgic/vgic-mmio-v2.c | 57 +---
virt/kvm/arm/vgic/vgic-mmio-v3.c | 204 +++++++++++--
virt/kvm/arm/vgic/vgic-mmio.c | 162 ++++++++++-
virt/kvm/arm/vgic/vgic-mmio.h | 28 ++
virt/kvm/arm/vgic/vgic-v3.c | 28 +-
virt/kvm/arm/vgic/vgic.h | 60 +++-
18 files changed, 1144 insertions(+), 105 deletions(-)
create mode 100644 arch/arm/kvm/vgic-v3-coproc.c
create mode 100644 arch/arm64/kvm/vgic-sys-reg-v3.c
--
1.9.1
^ 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