* Re: [PATCH wn 3/4] dt-bindings: display: panel: add auo kd101n80-45na panel bindings
From: Rob Herring @ 2019-08-12 22:15 UTC (permalink / raw)
To: Jitao Shi
Cc: Mark Rutland, devicetree, David Airlie, stonea168, dri-devel,
yingjoe.chen, Sam Ravnborg, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
linux-pwm, Jitao Shi, Sascha Hauer, Pawel Moll, Ian Campbell,
Inki Dae, linux-mediatek, Andy Yan, Matthias Brugger, eddie.huang,
linux-arm-kernel, Rahul Sharma, srv_heupstream, linux-kernel,
Philipp Zabel, Sean Paul
In-Reply-To: <20190811091001.49555-4-jitao.shi@mediatek.com>
On Sun, 11 Aug 2019 17:10:00 +0800, Jitao Shi wrote:
> Add documentation for auo kd101n80-45na panel.
>
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> .../display/panel/auo,kd101n80-45na.txt | 34 +++++++++++++++++++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.txt
>
Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.
If a tag was not added on purpose, please state why and what changed.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v3 2/4] perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
From: Lubashev, Igor @ 2019-08-12 22:33 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra,
Alexey Budankov, linux-kernel@vger.kernel.org, James Morris,
Alexander Shishkin, Ingo Molnar, Namhyung Kim, Jiri Olsa,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190812201557.GF9280@kernel.org>
On Mon, August 12, 2019 at 4:16 PM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> Em Mon, Aug 12, 2019 at 05:01:34PM -0300, Arnaldo Carvalho de Melo
> escreveu:
> > Em Wed, Aug 07, 2019 at 10:44:15AM -0400, Igor Lubashev escreveu:
> > > +++ b/tools/perf/util/evsel.c
> > > @@ -279,7 +279,7 @@ struct evsel *perf_evsel__new_idx(struct
> > > perf_event_attr *attr, int idx)
> >
> > > static bool perf_event_can_profile_kernel(void)
> > > {
> > > - return geteuid() == 0 || perf_event_paranoid() == -1;
> > > + return perf_event_paranoid_check(-1);
> > > }
> >
> > While looking at your changes I think the pre-existing code is wrong,
> > i.e. the check in sys_perf_event_open(), in the kernel is:
> >
> > if (!attr.exclude_kernel) {
> > if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
> > return -EACCES;
> > }
> >
> > And:
> >
> > static inline bool perf_paranoid_kernel(void) {
> > return sysctl_perf_event_paranoid > 1; }
> >
> > So we have to change that perf_event_paranoit_check(-1) to pass 1
> > instead?
Indeed. This seems right. It was a pre-existing problem.
> > bool perf_event_paranoid_check(int max_level) {
> > return perf_cap__capable(CAP_SYS_ADMIN) ||
> > perf_event_paranoid() <= max_level; }
> >
> > Also you defined perf_cap__capable(anything) as:
> >
> > #ifdef HAVE_LIBCAP_SUPPORT
> >
> > #include <sys/capability.h>
> >
> > bool perf_cap__capable(cap_value_t cap);
> >
> > #else
> >
> > static inline bool perf_cap__capable(int cap __maybe_unused)
> > {
> > return false;
> > }
> >
> > #endif /* HAVE_LIBCAP_SUPPORT */
> >
> >
> > I think we should have:
> >
> > #else
> >
> > static inline bool perf_cap__capable(int cap __maybe_unused) {
> > return geteuid() == 0;
> > }
> >
> > #endif /* HAVE_LIBCAP_SUPPORT */
> >
> > Right?
You can have EUID==0 and not have CAP_SYS_ADMIN, though this would be rare in practice. I did not to use EUID in leu of libcap, since kernel does not do so, and therefore it seemed a bit misleading. But this is a slight matter of taste, and I do not see a problem with choosing to fall back to EUID -- the kernel will do the right thing anyway.
Now, if I were pedantic, I'd say that to use geteuid(), you need to #include <unistd.h> .
> > So I am removing the introduction of perf_cap__capable() from the
> > first patch you sent, leaving it with _only_ the feature detection
> > part, using that feature detection to do anything is then moved to a
> > separate patch, after we finish this discussion about what we should
> > fallback to when libcap-devel isn't available, i.e. we should use the
> > previous checks, etc.
>
> So, please take a look at the tmp.perf/cap branch in my git repo:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=tmp.p
> erf/cap
>
> I split the patch and made perf_cap__capable() fallback to 'return
> geteuid() == 0;' when libcap-devel isn't available, i.e. keep the checks made
> prior to your patchset.
Thank you. And thanks for updating "make_minimal".
>
> Jiri, can I keep your Acked-by?
>
> - Arnaldo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] media: dt-bindings: Add JPEG ENC device tree node document
From: Rob Herring @ 2019-08-12 22:59 UTC (permalink / raw)
To: Xia Jiang
Cc: devicetree, srv_heupstream, Rick Chang, linux-kernel, Tomasz Figa,
Matthias Brugger, linux-mediatek, Hans Verkuil, Marek Szyprowski,
linux-arm-kernel, linux-media
In-Reply-To: <20190717093034.22826-2-xia.jiang@mediatek.com>
On Wed, Jul 17, 2019 at 05:30:30PM +0800, Xia Jiang wrote:
> add JPEG ENC device tree node document
>
> Change-Id: I9f0a8aec7eced20c88acbc88d6ff179763f91246
Run checkpatch.pl. (Remove this)
> Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> ---
> .../bindings/media/mediatek-jpeg-encoder.txt | 33 +++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
> new file mode 100644
> index 000000000000..1231fedb70bc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
> @@ -0,0 +1,33 @@
> +* MediaTek JPEG Encoder
> +
> +MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs
> +
> +Required properties:
> +- compatible : must be "mediatek,mtk-jpgenc"
Needs an SoC specific compatible.
> +- reg : physical base address of the JPEG encoder registers and length of
> + memory mapped region.
> +- interrupts : interrupt number to the interrupt controller.
> +- clocks: device clocks, see
> + Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> +- clock-names: must contain "jpgenc". It is the clock of JPEG encoder.
> +- power-domains: a phandle to the power domain, see
> + Documentation/devicetree/bindings/power/power_domain.txt for details.
> +- mediatek,larb: must contain the local arbiters in the current SoCs, see
> + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> + for details.
> +- iommus: should point to the respective IOMMU block with master port as
> + argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> + for details.
> +
> +Example:
> + jpegenc: jpegenc@1500a000 {
> + compatible = "mediatek,mtk-jpgenc";
> + reg = <0 0x1500a000 0 0x1000>;
> + interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&imgsys CLK_IMG_VENC>;
> + clock-names = "jpgenc";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
> + mediatek,larb = <&larb2>;
> + iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>,
> + <&iommu MT2701_M4U_PORT_JPGENC_BSDMA>;
> + };
> --
> 2.18.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] rtc: Add Amlogic Virtual Wake RTC
From: Kevin Hilman @ 2019-08-12 23:21 UTC (permalink / raw)
To: Alexandre Belloni, Kevin Hilman
Cc: linux-rtc, linux-amlogic, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190812211337.GW3600@piout.net>
Alexandre Belloni <alexandre.belloni@bootlin.com> writes:
> On 07/08/2019 21:23:57-0700, Kevin Hilman wrote:
>> +static int meson_vrtc_probe(struct platform_device *pdev)
>> +{
>> + struct meson_vrtc_data *vrtc;
>> + struct resource *res;
>> +
>> + vrtc = devm_kzalloc(&pdev->dev, sizeof(*vrtc), GFP_KERNEL);
>> + if (!vrtc)
>> + return -ENOMEM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + vrtc->io_alarm = devm_ioremap_resource(&pdev->dev, res);
>
> You could use devm_platform_ioremap_resource.
>
>> + if (IS_ERR(vrtc->io_alarm))
>> + return PTR_ERR(vrtc->io_alarm);
>> +
>> + device_init_wakeup(&pdev->dev, 1);
>> +
>> + platform_set_drvdata(pdev, vrtc);
>> +
>> + vrtc->rtc = devm_rtc_device_register(&pdev->dev, "meson-vrtc",
>> + &meson_vrtc_ops, THIS_MODULE);
>
> Please use devm_rtc_allocate_device and rtc_register_device.
>
OK, will update both and send a v3.
Thanks for the review,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/2] rtc: add new Amlogic Virtual Wake RTC
From: Kevin Hilman @ 2019-08-12 23:28 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc
Cc: linux-amlogic, devicetree, linux-arm-kernel, Neil Armstrong
From: Kevin Hilman <khilman@baylibre.com>
Add a new driver for the virtual wake RTC on Amlogic SoCs.
The RTC is virtual from the Linux side because it's a hardware timer
managed by firmware on the secure co-processor (SCP.) The interface
is 1 register where a wakeup time (in seconds) is written. The SCP then
uses this value to program an always-on timer.
Changes since v2:
- switch to devm_platform_ioremap_resource()
- switch to devm_rtc_allocate_device() and rtc_register_device()
Changes since v1:
- add MAINTAINERS entry
- add nop ->alarm_irq_enable() (workaround for RTC core
limitation pointed out by Alexandre Belloni)
- remove unused ->read_alarm()
- fix statics
- move resume to dev_pm_ops
- add suspend hook
- don't calculate (or write) the alarm timer value until suspend time
Changes since Neil's original version
- move from do_gettimeofday() to ktime_get()
Kevin Hilman (1):
dt-bindings: rtc: new binding for Amlogic VRTC
Neil Armstrong (1):
rtc: Add Amlogic Virtual Wake RTC
.../bindings/rtc/rtc-meson-vrtc.txt | 22 +++
MAINTAINERS | 1 +
drivers/rtc/Kconfig | 11 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-meson-vrtc.c | 156 ++++++++++++++++++
5 files changed, 191 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
create mode 100644 drivers/rtc/rtc-meson-vrtc.c
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: rtc: new binding for Amlogic VRTC
From: Kevin Hilman @ 2019-08-12 23:28 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc
Cc: linux-amlogic, devicetree, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190812232850.8016-1-khilman@kernel.org>
From: Kevin Hilman <khilman@baylibre.com>
Add binding fo the new VRTC driver for Amlogic SoCs. The 64-bit
family of SoCs only has an RTC managed by firmware, and this VRTC
driver provides the simple, one-register firmware interface.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
.../bindings/rtc/rtc-meson-vrtc.txt | 22 +++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt b/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
new file mode 100644
index 000000000000..c014f54a9853
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
@@ -0,0 +1,22 @@
+* Amlogic Virtual RTC (VRTC)
+
+This is a Linux interface to an RTC managed by firmware, hence it's
+virtual from a Linux perspective. The interface is 1 register where
+an alarm time (in seconds) is to be written.
+
+Required properties:
+- compatible: should be "amlogic,meson-vrtc"
+- reg: physical address for the alarm register
+
+The alarm register is a simple scratch register shared between the
+application processors (AP) and the secure co-processor (SCP.) When
+the AP suspends, the SCP will use the value of this register to
+program an always-on timer before going sleep. When the timer expires,
+the SCP will wake up and will then wake the AP.
+
+Example:
+
+ vrtc: rtc@0a8 {
+ compatible = "amlogic,meson-vrtc";
+ reg = <0x0 0x000a8 0x0 0x4>;
+ };
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/2] rtc: Add Amlogic Virtual Wake RTC
From: Kevin Hilman @ 2019-08-12 23:28 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc
Cc: linux-amlogic, devicetree, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190812232850.8016-1-khilman@kernel.org>
From: Neil Armstrong <narmstrong@baylibre.com>
The Amlogic Meson GX SoCs uses a special register to store the
time in seconds to wakeup after a system suspend.
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.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[khilman: rebase to v5.3-rc, rework and modernization]
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
MAINTAINERS | 1 +
drivers/rtc/Kconfig | 11 +++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-meson-vrtc.c | 156 +++++++++++++++++++++++++++++++++++
4 files changed, 169 insertions(+)
create mode 100644 drivers/rtc/rtc-meson-vrtc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 783569e3c4b4..2ae83e1acb05 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1443,6 +1443,7 @@ F: arch/arm64/boot/dts/amlogic/
F: drivers/pinctrl/meson/
F: drivers/mmc/host/meson*
F: drivers/soc/amlogic/
+F: drivers/rtc/rtc-meson*
N: meson
ARM/Amlogic Meson SoC Sound Drivers
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e72f65b61176..7cd325ecc10b 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -373,6 +373,17 @@ config RTC_DRV_MAX77686
This driver can also be built as a module. If so, the module
will be called rtc-max77686.
+config RTC_DRV_MESON_VRTC
+ tristate "Amlogic Meson Virtual RTC"
+ depends on ARCH_MESON || COMPILE_TEST
+ default m if ARCH_MESON
+ help
+ If you say yes here you will get support for the
+ Virtual RTC of Amlogic SoCs.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-meson-vrtc.
+
config RTC_DRV_RK808
tristate "Rockchip RK805/RK808/RK809/RK817/RK818 RTC"
depends on MFD_RK808
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 6b09c21dc1b6..b50fd3aa81b3 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -102,6 +102,7 @@ obj-$(CONFIG_RTC_DRV_MAX8907) += rtc-max8907.o
obj-$(CONFIG_RTC_DRV_MAX8925) += rtc-max8925.o
obj-$(CONFIG_RTC_DRV_MAX8997) += rtc-max8997.o
obj-$(CONFIG_RTC_DRV_MAX8998) += rtc-max8998.o
+obj-$(CONFIG_RTC_DRV_MESON_VRTC)+= rtc-meson-vrtc.o
obj-$(CONFIG_RTC_DRV_MC13XXX) += rtc-mc13xxx.o
obj-$(CONFIG_RTC_DRV_MCP795) += rtc-mcp795.o
obj-$(CONFIG_RTC_DRV_MESON) += rtc-meson.o
diff --git a/drivers/rtc/rtc-meson-vrtc.c b/drivers/rtc/rtc-meson-vrtc.c
new file mode 100644
index 000000000000..4621a4715179
--- /dev/null
+++ b/drivers/rtc/rtc-meson-vrtc.c
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ */
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/time64.h>
+
+struct meson_vrtc_data {
+ void __iomem *io_alarm;
+ struct rtc_device *rtc;
+ unsigned long alarm_time;
+ bool enabled;
+};
+
+static int meson_vrtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct timespec64 time;
+
+ dev_dbg(dev, "%s\n", __func__);
+ ktime_get_raw_ts64(&time);
+ rtc_time64_to_tm(time.tv_sec, tm);
+
+ return 0;
+}
+
+static void meson_vrtc_set_wakeup_time(struct meson_vrtc_data *vrtc,
+ unsigned long time)
+{
+ writel_relaxed(time, vrtc->io_alarm);
+}
+
+static int meson_vrtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
+{
+ struct meson_vrtc_data *vrtc = dev_get_drvdata(dev);
+
+ dev_dbg(dev, "%s: alarm->enabled=%d\n", __func__, alarm->enabled);
+ if (alarm->enabled)
+ vrtc->alarm_time = rtc_tm_to_time64(&alarm->time);
+ else
+ vrtc->alarm_time = 0;
+
+ return 0;
+}
+
+static int meson_vrtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
+{
+ struct meson_vrtc_data *vrtc = dev_get_drvdata(dev);
+
+ vrtc->enabled = enabled;
+ return 0;
+}
+
+static const struct rtc_class_ops meson_vrtc_ops = {
+ .read_time = meson_vrtc_read_time,
+ .set_alarm = meson_vrtc_set_alarm,
+ .alarm_irq_enable = meson_vrtc_alarm_irq_enable,
+};
+
+static int meson_vrtc_probe(struct platform_device *pdev)
+{
+ struct meson_vrtc_data *vrtc;
+ int ret;
+
+ vrtc = devm_kzalloc(&pdev->dev, sizeof(*vrtc), GFP_KERNEL);
+ if (!vrtc)
+ return -ENOMEM;
+
+ vrtc->io_alarm = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(vrtc->io_alarm))
+ return PTR_ERR(vrtc->io_alarm);
+
+ device_init_wakeup(&pdev->dev, 1);
+
+ platform_set_drvdata(pdev, vrtc);
+
+ vrtc->rtc = devm_rtc_allocate_device(&pdev->dev);
+ if (IS_ERR(vrtc->rtc))
+ return PTR_ERR(vrtc->rtc);
+
+ vrtc->rtc->ops = &meson_vrtc_ops;
+ ret = rtc_register_device(vrtc->rtc);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int meson_vrtc_suspend(struct device *dev)
+{
+ struct meson_vrtc_data *vrtc = dev_get_drvdata(dev);
+
+ dev_dbg(dev, "%s\n", __func__);
+ if (vrtc->alarm_time) {
+ unsigned long local_time;
+ long alarm_secs;
+ struct timespec64 time;
+
+ ktime_get_raw_ts64(&time);
+ local_time = time.tv_sec;
+
+ dev_dbg(dev, "alarm_time = %lus, local_time=%lus\n",
+ vrtc->alarm_time, local_time);
+ alarm_secs = vrtc->alarm_time - local_time;
+ if (alarm_secs > 0) {
+ meson_vrtc_set_wakeup_time(vrtc, alarm_secs);
+ dev_dbg(dev, "system will wakeup in %lds.\n",
+ alarm_secs);
+ } else {
+ dev_err(dev, "alarm time already passed: %lds.\n",
+ alarm_secs);
+ }
+ }
+
+ return 0;
+}
+
+static int meson_vrtc_resume(struct device *dev)
+{
+ struct meson_vrtc_data *vrtc = dev_get_drvdata(dev);
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ vrtc->alarm_time = 0;
+ meson_vrtc_set_wakeup_time(vrtc, 0);
+ return 0;
+}
+#endif
+static SIMPLE_DEV_PM_OPS(meson_vrtc_pm_ops,
+ meson_vrtc_suspend, meson_vrtc_resume);
+
+static const struct of_device_id meson_vrtc_dt_match[] = {
+ { .compatible = "amlogic,meson-vrtc"},
+ {},
+};
+MODULE_DEVICE_TABLE(of, meson_vrtc_dt_match);
+
+static struct platform_driver meson_vrtc_driver = {
+ .probe = meson_vrtc_probe,
+ .driver = {
+ .name = "meson-vrtc",
+ .of_match_table = meson_vrtc_dt_match,
+ .pm = &meson_vrtc_pm_ops,
+ },
+};
+
+module_platform_driver(meson_vrtc_driver);
+
+MODULE_DESCRIPTION("Amlogic Virtual Wakeup RTC Timer driver");
+MODULE_LICENSE("GPL");
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 00/18] add thermal driver for h6
From: Frank Lee @ 2019-08-12 23:36 UTC (permalink / raw)
To: Clément Péron
Cc: Mark Rutland, devicetree, Linux PM, Maxime Ripard,
Greg Kroah-Hartman, Daniel Lezcano, Linux Kernel Mailing List,
Eduardo Valentin, Chen-Yu Tsai, Rob Herring, Jonathan.Cameron,
Mauro Carvalho Chehab, rui.zhang, David Miller, Linux ARM
In-Reply-To: <f479c162-4eac-f320-3583-b9ddbef79b1a@gmail.com>
On Mon, Aug 12, 2019 at 5:14 AM Clément Péron <peron.clem@gmail.com> wrote:
>
> Hi Yangtao,
>
> On 10/08/2019 07:28, Yangtao Li wrote:
> > This patchset add support for A64, H3, H5, H6 and R40 thermal sensor.
>
> Could you add the device-tree configuration in the same series?
> This will allow user to test it.
Ok, it will be added later.
Yangtao
>
> Thanks,
> Clément
>
> >
> > Thx to Icenowy and Vasily.
> >
> > BTY, do a cleanup in thermal makfile.
> >
> > Icenowy Zheng (3):
> > thermal: sun8i: allow to use custom temperature calculation function
> > thermal: sun8i: add support for Allwinner H5 thermal sensor
> > thermal: sun8i: add support for Allwinner R40 thermal sensor
> >
> > Vasily Khoruzhick (1):
> > thermal: sun8i: add thermal driver for A64
> >
> > Yangtao Li (14):
> > thermal: sun8i: add thermal driver for h6
> > dt-bindings: thermal: add binding document for h6 thermal controller
> > thermal: fix indentation in makefile
> > thermal: sun8i: get ths sensor number from device compatible
> > thermal: sun8i: rework for sun8i_ths_get_temp()
> > thermal: sun8i: get ths init func from device compatible
> > thermal: sun8i: rework for ths irq handler func
> > thermal: sun8i: support mod clocks
> > thermal: sun8i: rework for ths calibrate func
> > dt-bindings: thermal: add binding document for h3 thermal controller
> > thermal: sun8i: add thermal driver for h3
> > dt-bindings: thermal: add binding document for a64 thermal controller
> > dt-bindings: thermal: add binding document for h5 thermal controller
> > dt-bindings: thermal: add binding document for r40 thermal controller
> >
> > .../bindings/thermal/sun8i-thermal.yaml | 157 +++++
> > MAINTAINERS | 7 +
> > drivers/thermal/Kconfig | 14 +
> > drivers/thermal/Makefile | 9 +-
> > drivers/thermal/sun8i_thermal.c | 596 ++++++++++++++++++
> > 5 files changed, 779 insertions(+), 4 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> > create mode 100644 drivers/thermal/sun8i_thermal.c
> > ---
> > v5:
> > -add more support
> > -some trival fix
> > ---
> > 2.17.1
> >
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 02/18] dt-bindings: thermal: add binding document for h6 thermal controller
From: Frank Lee @ 2019-08-12 23:40 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Linux PM, Greg Kroah-Hartman,
Daniel Lezcano, Linux Kernel Mailing List, Eduardo Valentin,
Chen-Yu Tsai, Rob Herring, Jonathan.Cameron,
Mauro Carvalho Chehab, rui.zhang, David Miller, Linux ARM
In-Reply-To: <20190812085604.ozhl35wwm3ehlvqn@flea>
On Mon, Aug 12, 2019 at 4:56 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Sat, Aug 10, 2019 at 05:28:13AM +0000, Yangtao Li wrote:
> > This patch adds binding document for allwinner h6 thermal controller.
> >
> > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > ---
> > .../bindings/thermal/sun8i-thermal.yaml | 79 +++++++++++++++++++
> > 1 file changed, 79 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml b/Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> > new file mode 100644
> > index 000000000000..e0973199ba3c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
>
> We've used so far for the schemas the first compatible to introduce
> that controller as the filename, we should be consistent here. In that
> case that would be allwinner,sun8i-a23-ths.yaml
>
> > @@ -0,0 +1,79 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/thermal/sun8i-thermal.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Allwinner SUN8I Thermal Controller Device Tree Bindings
> > +
> > +maintainers:
> > + - Yangtao Li <tiny.windzz@gmail.com>
> > +
> > +description: |-
> > + This describes the device tree binding for the Allwinner thermal
> > + controller which measures the on-SoC temperatures.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - allwinner,sun50i-h6-ths
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + clock-names:
> > + const: bus
> > +
> > + "#thermal-sensor-cells":
> > + const: 1
> > +
> > + nvmem-cells:
>
> You need a maxItems here too
>
> > + description: ths calibrate data
>
> What about something like this:
>
> Calibration data for the thermal sensor
>
> > +
> > + nvmem-cell-names:
> > + const: calib
>
> I'm not sure we need a abbreviation here, calibration would be more
> explicit
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reset
> > + - clocks
> > + - clock-names
> > + - interrupts
> > + - "#thermal-sensor-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + ths: ths@5070400 {
> > + compatible = "allwinner,sun50i-h6-ths";
> > + reg = <0x05070400 0x100>;
> > + clocks = <&ccu CLK_BUS_THS>;
> > + clock-names = "bus";
> > + resets = <&ccu RST_BUS_THS>;
> > + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
>
> Those examples won't compile.
Emmm, I have some questions about this.
I added this information and it can be compiled.
Yours,
Yangtao
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 08/18] thermal: sun8i: support mod clocks
From: Frank Lee @ 2019-08-12 23:46 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Linux PM, Maxime Ripard,
Greg Kroah-Hartman, Daniel Lezcano, linux-kernel,
Eduardo Valentin, Chen-Yu Tsai, Rob Herring, Jonathan.Cameron,
Mauro Carvalho Chehab, rui.zhang, David S. Miller, arm-linux
In-Reply-To: <CA+E=qVfp-rProxOwX__J6jM-pZ9g_SmeuOCOgvC_5DJVQw4OGw@mail.gmail.com>
HI Vasily,
On Sat, Aug 10, 2019 at 2:17 PM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>
> On Fri, Aug 9, 2019 at 10:31 PM Yangtao Li <tiny.windzz@gmail.com> wrote:
> >
> > H3 has extra clock, so introduce something in ths_thermal_chip/ths_device
> > and adds the process of the clock.
> >
> > This is pre-work for supprt it.
> >
> > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > ---
> > drivers/thermal/sun8i_thermal.c | 17 ++++++++++++++++-
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> > index b934bc81eba7..6f4294c2aba7 100644
> > --- a/drivers/thermal/sun8i_thermal.c
> > +++ b/drivers/thermal/sun8i_thermal.c
> > @@ -54,6 +54,7 @@ struct tsensor {
> > };
> >
> > struct ths_thermal_chip {
> > + bool has_mod_clk;
> > int sensor_num;
> > int offset;
> > int scale;
> > @@ -69,6 +70,7 @@ struct ths_device {
> > struct regmap *regmap;
> > struct reset_control *reset;
> > struct clk *bus_clk;
> > + struct clk *mod_clk;
> > struct tsensor sensor[MAX_SENSOR_NUM];
> > };
> >
> > @@ -274,6 +276,12 @@ static int sun8i_ths_resource_init(struct ths_device *tmdev)
> > if (IS_ERR(tmdev->bus_clk))
> > return PTR_ERR(tmdev->bus_clk);
> >
> > + if (tmdev->chip->has_mod_clk) {
> > + tmdev->mod_clk = devm_clk_get(&pdev->dev, "mod");
> > + if (IS_ERR(tmdev->mod_clk))
> > + return PTR_ERR(tmdev->mod_clk);
> > + }
> > +
> > ret = reset_control_deassert(tmdev->reset);
> > if (ret)
> > return ret;
> > @@ -282,12 +290,18 @@ static int sun8i_ths_resource_init(struct ths_device *tmdev)
> > if (ret)
> > goto assert_reset;
> >
> > - ret = sun50i_ths_calibrate(tmdev);
> > + ret = clk_prepare_enable(tmdev->mod_clk);
>
> You have to set rate of modclk before enabling it since you can't rely
> on whatever bootloader left for you.
>
> Also I found that parameters you're using for PC_TEMP_PERIOD, ACQ0 and
> ACQ1 are too aggressive and may result in high interrupt rate to the
> point when it may stall RCU. I changed driver a bit to use params from
> Philipp Rossak's work (modclk set to 4MHz, PC_TEMP_PERIOD is 7, ACQ0
> is 255, ACQ1 is 63) and it fixed RCU stalls for me, see [1] for
> details.
Why is the RCU stall happening, is it caused by a deadlock?
Can you provide log information and your configuration?
I am a bit curious.
Thx,
Yangtao
>
> [1] https://github.com/anarsoul/linux-2.6/commit/46b8bb0fe2ccd1cd88fa9181a2ecbf79e8d513b2
>
>
> > if (ret)
> > goto bus_disable;
> >
> > + ret = sun50i_ths_calibrate(tmdev);
> > + if (ret)
> > + goto mod_disable;
> > +
> > return 0;
> >
> > +mod_disable:
> > + clk_disable_unprepare(tmdev->mod_clk);
> > bus_disable:
> > clk_disable_unprepare(tmdev->bus_clk);
> > assert_reset:
> > @@ -395,6 +409,7 @@ static int sun8i_ths_remove(struct platform_device *pdev)
> > {
> > struct ths_device *tmdev = platform_get_drvdata(pdev);
> >
> > + clk_disable_unprepare(tmdev->mod_clk);
> > clk_disable_unprepare(tmdev->bus_clk);
> > reset_control_assert(tmdev->reset);
> >
> > --
> > 2.17.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64: dts: Amlogic fixes for v5.3-rc
From: Kevin Hilman @ 2019-08-12 23:49 UTC (permalink / raw)
To: arm; +Cc: linux-amlogic, linux-arm-kernel
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-fixes
for you to fetch changes up to dc7f2cb218b5ef65ab3d455a0e62d27e44075203:
arm64: dts: amlogic: odroid-n2: keep SD card regulator always on (2019-08-05 14:06:55 -0700)
----------------------------------------------------------------
arm64: dts: Amlogic fixes for v5.3-rc
- a few small DT fixes for g12a/g12b platforms
----------------------------------------------------------------
Neil Armstrong (2):
arm64: dts: meson-g12a: add missing dwc2 phy-names
arm64: dts: meson-g12a-sei510: enable IR controller
Xavier Ruppen (1):
arm64: dts: amlogic: odroid-n2: keep SD card regulator always on
arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 1 +
arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 1 +
3 files changed, 8 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH] ARM: UNWINDER_FRAME_POINTER implementation for Clang
From: Nick Desaulniers @ 2019-08-12 23:49 UTC (permalink / raw)
To: Nathan Huckleberry
Cc: clang-built-linux, Tri Vo, Russell King, Linux ARM, LKML
In-Reply-To: <20190801231046.105022-1-nhuck@google.com>
On Thu, Aug 1, 2019 at 4:10 PM 'Nathan Huckleberry' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
>
> The stackframe setup when compiled with clang is different.
> Since the stack unwinder expects the gcc stackframe setup it
> fails to print backtraces. This patch adds support for the
> clang stackframe setup.
>
> Cc: clang-built-linux@googlegroups.com
> Suggested-by: Tri Vo <trong@google.com>
> Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Thanks for the patch! This is something definitely useful to have
implemented with Clang. Some initial thoughts below:
> ---
> arch/arm/Kconfig.debug | 4 +-
> arch/arm/Makefile | 2 +-
> arch/arm/lib/backtrace.S | 134 ++++++++++++++++++++++++++++++++++++---
> 3 files changed, 128 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 85710e078afb..92fca7463e21 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -56,7 +56,7 @@ choice
>
> config UNWINDER_FRAME_POINTER
> bool "Frame pointer unwinder"
> - depends on !THUMB2_KERNEL && !CC_IS_CLANG
> + depends on !THUMB2_KERNEL
> select ARCH_WANT_FRAME_POINTERS
> select FRAME_POINTER
> help
> @@ -1872,7 +1872,7 @@ config DEBUG_UNCOMPRESS
> When this option is set, the selected DEBUG_LL output method
> will be re-used for normal decompressor output on multiplatform
> kernels.
> -
> +
>
> config UNCOMPRESS_INCLUDE
> string
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c3624ca6c0bc..a593d9c4e18a 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -36,7 +36,7 @@ KBUILD_CFLAGS += $(call cc-option,-mno-unaligned-access)
> endif
>
> ifeq ($(CONFIG_FRAME_POINTER),y)
> -KBUILD_CFLAGS +=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
> +KBUILD_CFLAGS +=-fno-omit-frame-pointer $(call cc-option,-mapcs,) $(call cc-option,-mno-sched-prolog,)
> endif
>
> ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
> diff --git a/arch/arm/lib/backtrace.S b/arch/arm/lib/backtrace.S
> index 1d5210eb4776..fd64eec9f6ae 100644
> --- a/arch/arm/lib/backtrace.S
> +++ b/arch/arm/lib/backtrace.S
> @@ -14,10 +14,7 @@
> @ fp is 0 or stack frame
>
> #define frame r4
> -#define sv_fp r5
> -#define sv_pc r6
It looks like sv_fp and sv_pc have the same values for both GCC and
Clang, maybe they don't need to be moved here?
> #define mask r7
> -#define offset r8
So GCC has an offset while Clang has sv_lr.
>
> ENTRY(c_backtrace)
>
> @@ -25,7 +22,8 @@ ENTRY(c_backtrace)
> ret lr
> ENDPROC(c_backtrace)
> #else
> - stmfd sp!, {r4 - r8, lr} @ Save an extra register so we have a location...
> + stmfd sp!, {r4 - r8, fp, lr} @ Save an extra register
Not having a preprocessor guard here makes it seem like GCC will
always have to move the additional register, even if it's not using
it?
> + @ so we have a location..
> movs frame, r0 @ if frame pointer is zero
> beq no_frame @ we have no stack frames
>
> @@ -35,11 +33,119 @@ ENDPROC(c_backtrace)
> THUMB( orreq mask, #0x03 )
> movne mask, #0 @ mask for 32-bit
>
> -1: stmfd sp!, {pc} @ calculate offset of PC stored
> - ldr r0, [sp], #4 @ by stmfd for this CPU
> - adr r1, 1b
> - sub offset, r0, r1
>
> +#if defined(CONFIG_CC_IS_CLANG)
#ifdef CONFIG_CC_IS_CLANG
I'd only use `#if defined(foo)` if there were 2 or more things I
needed to check: `#if defined(foo) || defined(bar)`.
> +/*
> + * Clang does not store pc or sp in function prologues
> + * so we don't know exactly where the function
> + * starts.
> + * We can treat the current frame's lr as the saved pc and the
> + * preceding frame's lr as the lr, but we can't
> + * trace the most recent call.
> + * Inserting a false stack frame allows us to reference the
> + * function called last in the stacktrace.
> + * If the call instruction was a bl we can look at the callers
> + * branch instruction to calculate the saved pc.
> + * We can recover the pc in most cases, but in cases such as
> + * calling function pointers we cannot. In this
> + * case, default to using the lr. This will be
> + * some address in the function, but will not
> + * be the function start.
> + * Unfortunately due to the stack frame layout we can't dump
> + * r0 - r3, but these are less frequently saved.
> + *
> + * Stack frame layout:
> + * <larger addresses>
> + * saved lr
> + * frame => saved fp
> + * optionally saved caller registers (r4 - r10)
> + * optionally saved arguments (r0 - r3)
> + * <top of stack frame>
> + * <smaller addressses>
s/addressses/addresses/
> + *
> + * Functions start with the following code sequence:
> + * corrected pc => stmfd sp!, {..., fp, lr}
> + * add fp, sp, #x
> + * stmfd sp!, {r0 - r3} (optional)
> + */
> +#define sv_fp r5
> +#define sv_pc r6
> +#define sv_lr r8
> + add frame, sp, #20 @ switch to false frame
> +for_each_frame: tst frame, mask @ Check for address exceptions
> + bne no_frame
> +
> +1001: ldr sv_pc, [frame, #4] @ get saved 'pc'
> +1002: ldr sv_fp, [frame, #0] @ get saved fp
These two sections seem to differ between GCC and Clang only for the
offsets. Could these be made into preprocessor defines and more code
shared?
> +
> + teq sv_fp, #0 @ make sure next frame exists
> + beq no_frame
> +
> +1003: ldr sv_lr, [sv_fp, #4] @ get saved lr from next frame
> +
> + //try to find function start
Use either /* c89 comments */ or @arm assembler comments.
> + ldr r0, [sv_lr, #-4] @ get call instruction
> + ldr r3, .Ldsi+8
> + and r2, r3, r0 @ is this a bl call
> + teq r2, r3
> + bne finished_setup @ give up if it's not
> + and r0, #0xffffff @ get call offset 24-bit int
> + lsl r0, r0, #8 @ sign extend offset
> + asr r0, r0, #8
> + ldr sv_pc, [sv_fp, #4] @ get lr address
> + add sv_pc, sv_pc, #-4 @ get call instruction address
> + add sv_pc, sv_pc, #8 @ take care of prefetch
> + add sv_pc, sv_pc, r0, lsl #2 @ find function start
> + b finished_setup
Do we need an explicit branch to this label? Wouldn't we just fall
through to it?j
> +
> +finished_setup:
> +
> + bic sv_pc, sv_pc, mask @ mask PC/LR for the mode
> +
> +1004: mov r0, sv_pc
> +
> + mov r1, sv_lr
> + mov r2, frame
> + bic r1, r1, mask @ mask PC/LR for the mode
> + bl dump_backtrace_entry
> +
> +1005: ldr r1, [sv_pc, #0] @ if stmfd sp!, {..., fp, lr}
> + ldr r3, .Ldsi @ instruction exists,
> + teq r3, r1, lsr #11
> + ldr r0, [frame] @ locals are stored in
> + @ the preceding frame
> + subeq r0, r0, #4
> + bleq dump_backtrace_stm @ dump saved registers
> +
> + teq sv_fp, #0 @ zero saved fp means
> + beq no_frame @ no further frames
> +
> + cmp sv_fp, frame @ next frame must be
> + mov frame, sv_fp @ above the current frame
> + bhi for_each_frame
> +
> +1006: adr r0, .Lbad
> + mov r1, frame
> + bl printk
> +no_frame: ldmfd sp!, {r4 - r8, fp, pc}
> +ENDPROC(c_backtrace)
> + .pushsection __ex_table,"a"
> + .align 3
> + .long 1001b, 1006b
> + .long 1002b, 1006b
> + .long 1003b, 1006b
> + .long 1004b, 1006b
> + .popsection
> +
> +.Lbad: .asciz "Backtrace aborted due to bad frame pointer <%p>\n"
> + .align
Probably don't need to duplicate the above (up to ENDPROC), but the
below hunk looks compiler specific.
> +.Ldsi: .word 0xe92d4800 >> 11 @ stmfd sp!, {... fp, lr}
> + .word 0xe92d0000 >> 11 @ stmfd sp!, {}
> + .word 0x0b000000 @ bl if these bits are set
> +
> +ENDPROC(c_backtrace)
Duplicate ENDPROC?
> +
> +#else
> /*
> * Stack frame layout:
> * optionally saved caller registers (r4 - r10)
> @@ -55,6 +161,15 @@ ENDPROC(c_backtrace)
> * stmfd sp!, {r0 - r3} (optional)
> * corrected pc => stmfd sp!, {..., fp, ip, lr, pc}
> */
> +#define sv_fp r5
> +#define sv_pc r6
> +#define offset r8
> +
> +1: stmfd sp!, {pc} @ calculate offset of PC stored
> + ldr r0, [sp], #4 @ by stmfd for this CPU
> + adr r1, 1b
> + sub offset, r0, r1
> +
> for_each_frame: tst frame, mask @ Check for address exceptions
> bne no_frame
>
> @@ -98,7 +213,7 @@ for_each_frame: tst frame, mask @ Check for address exceptions
> 1006: adr r0, .Lbad
> mov r1, frame
> bl printk
> -no_frame: ldmfd sp!, {r4 - r8, pc}
> +no_frame: ldmfd sp!, {r4 - r8, fp, pc}
More work for GCC...
> ENDPROC(c_backtrace)
>
> .pushsection __ex_table,"a"
> @@ -115,3 +230,4 @@ ENDPROC(c_backtrace)
> .word 0xe92d0000 >> 11 @ stmfd sp!, {}
>
> #endif
> +#endif
It would be nice to put comments on the end of these #endif's what
condition they're terminating:
#endif /* CONFIG_CC_IS_CLANG
#endif /* !defined(CONFIG_FRAME_POINTER) || !defined(CONFIG_PRINTK) */
Maybe also the #else's above.
Will send more thoughts tomorrow/throughout the week.
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] power: reset: Add UART-based MCU poweroff DT bindings
From: Rob Herring @ 2019-08-12 23:50 UTC (permalink / raw)
To: Evgeny Kolesnikov
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, linux-pm,
Gregory Clement, Sebastian Reichel, linux-kernel, devicetree,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <cda16032dc5679a557230cbdb63702b105782b3b.1563822216.git.evgenyz@gmail.com>
On Mon, Jul 22, 2019 at 09:53:01PM +0200, Evgeny Kolesnikov wrote:
> This adds device tree bindings of the poweroff driver
> for power managing micro controller units that are connected
> to a board via the UART interface.
>
> Signed-off-by: Evgeny Kolesnikov <evgenyz@gmail.com>
> ---
> .../bindings/power/reset/uart-poweroff.txt | 38 +++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/reset/uart-poweroff.txt
>
> diff --git a/Documentation/devicetree/bindings/power/reset/uart-poweroff.txt b/Documentation/devicetree/bindings/power/reset/uart-poweroff.txt
> new file mode 100644
> index 000000000000..86d036271b51
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/uart-poweroff.txt
> @@ -0,0 +1,38 @@
> +* UART-based PM MCU power off driver
> +
> +Some devices have a microcontroller controlling the main power
> +supply. This microcontroller is connected to UART of the SoC.
> +Sending a sequence of characters tells the MCU to turn
> +the power off.
IMO, you should have a node representing the specific microcontroller.
Generic binding attempts like this generally don't work well because you
need a never ending addition of properties to deal with h/w (and f/w in
this case) differences. The properties you already have are evidence of
this.
Now, if you want a common driver, then that is a separate issue. You can
have multiple, specific bindings map to a common driver (or not, it's up
to the OS).
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 08/18] thermal: sun8i: support mod clocks
From: Vasily Khoruzhick @ 2019-08-12 23:54 UTC (permalink / raw)
To: Frank Lee
Cc: Mark Rutland, devicetree, Linux PM, Maxime Ripard,
Greg Kroah-Hartman, Daniel Lezcano, linux-kernel,
Eduardo Valentin, Chen-Yu Tsai, Rob Herring, Jonathan.Cameron,
Mauro Carvalho Chehab, rui.zhang, David S. Miller, arm-linux
In-Reply-To: <CAEExFWubLqtPZ=ZKJTCb6x2-PeYebXb3sr-t-XvtrLJTRiUU1A@mail.gmail.com>
On Mon, Aug 12, 2019 at 4:46 PM Frank Lee <tiny.windzz@gmail.com> wrote:
>
> HI Vasily,
>
> On Sat, Aug 10, 2019 at 2:17 PM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> >
> > On Fri, Aug 9, 2019 at 10:31 PM Yangtao Li <tiny.windzz@gmail.com> wrote:
> > >
> > > H3 has extra clock, so introduce something in ths_thermal_chip/ths_device
> > > and adds the process of the clock.
> > >
> > > This is pre-work for supprt it.
> > >
> > > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > > ---
> > > drivers/thermal/sun8i_thermal.c | 17 ++++++++++++++++-
> > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> > > index b934bc81eba7..6f4294c2aba7 100644
> > > --- a/drivers/thermal/sun8i_thermal.c
> > > +++ b/drivers/thermal/sun8i_thermal.c
> > > @@ -54,6 +54,7 @@ struct tsensor {
> > > };
> > >
> > > struct ths_thermal_chip {
> > > + bool has_mod_clk;
> > > int sensor_num;
> > > int offset;
> > > int scale;
> > > @@ -69,6 +70,7 @@ struct ths_device {
> > > struct regmap *regmap;
> > > struct reset_control *reset;
> > > struct clk *bus_clk;
> > > + struct clk *mod_clk;
> > > struct tsensor sensor[MAX_SENSOR_NUM];
> > > };
> > >
> > > @@ -274,6 +276,12 @@ static int sun8i_ths_resource_init(struct ths_device *tmdev)
> > > if (IS_ERR(tmdev->bus_clk))
> > > return PTR_ERR(tmdev->bus_clk);
> > >
> > > + if (tmdev->chip->has_mod_clk) {
> > > + tmdev->mod_clk = devm_clk_get(&pdev->dev, "mod");
> > > + if (IS_ERR(tmdev->mod_clk))
> > > + return PTR_ERR(tmdev->mod_clk);
> > > + }
> > > +
> > > ret = reset_control_deassert(tmdev->reset);
> > > if (ret)
> > > return ret;
> > > @@ -282,12 +290,18 @@ static int sun8i_ths_resource_init(struct ths_device *tmdev)
> > > if (ret)
> > > goto assert_reset;
> > >
> > > - ret = sun50i_ths_calibrate(tmdev);
> > > + ret = clk_prepare_enable(tmdev->mod_clk);
> >
> > You have to set rate of modclk before enabling it since you can't rely
> > on whatever bootloader left for you.
> >
> > Also I found that parameters you're using for PC_TEMP_PERIOD, ACQ0 and
> > ACQ1 are too aggressive and may result in high interrupt rate to the
> > point when it may stall RCU. I changed driver a bit to use params from
> > Philipp Rossak's work (modclk set to 4MHz, PC_TEMP_PERIOD is 7, ACQ0
> > is 255, ACQ1 is 63) and it fixed RCU stalls for me, see [1] for
> > details.
>
> Why is the RCU stall happening, is it caused by a deadlock?
> Can you provide log information and your configuration?
> I am a bit curious.
It's not deadlock, I believe it just can't handle that many interrupts
when running at lowest CPU frequency. Even with Philipp's settings
there's ~20 interrupts a second from ths. I don't remember how many
interrupts were there with your settings.
Unfortunately there's nothing interesting in backtraces, I'm using
Pine64-LTS board.
> Thx,
> Yangtao
>
> >
> > [1] https://github.com/anarsoul/linux-2.6/commit/46b8bb0fe2ccd1cd88fa9181a2ecbf79e8d513b2
> >
> >
> > > if (ret)
> > > goto bus_disable;
> > >
> > > + ret = sun50i_ths_calibrate(tmdev);
> > > + if (ret)
> > > + goto mod_disable;
> > > +
> > > return 0;
> > >
> > > +mod_disable:
> > > + clk_disable_unprepare(tmdev->mod_clk);
> > > bus_disable:
> > > clk_disable_unprepare(tmdev->bus_clk);
> > > assert_reset:
> > > @@ -395,6 +409,7 @@ static int sun8i_ths_remove(struct platform_device *pdev)
> > > {
> > > struct ths_device *tmdev = platform_get_drvdata(pdev);
> > >
> > > + clk_disable_unprepare(tmdev->mod_clk);
> > > clk_disable_unprepare(tmdev->bus_clk);
> > > reset_control_assert(tmdev->reset);
> > >
> > > --
> > > 2.17.1
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/7] drm/msm/mdp4: Drop unused GPIO include
From: Brian Masney @ 2019-08-13 0:22 UTC (permalink / raw)
To: Linus Walleij
Cc: freedreno, Maxime Ripard, linux-arm-msm, Maarten Lankhorst,
dri-devel, Rob Clark, Sean Paul, linux-arm-kernel
In-Reply-To: <20190629125933.679-1-linus.walleij@linaro.org>
On Sat, Jun 29, 2019 at 02:59:27PM +0200, Linus Walleij wrote:
> This file is not using any symbols from <linux/gpio.h> so just
> drop this include.
>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For the series:
Reviewed-by: Brian Masney <masneyb@onstation.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: devfreq: Add bindings for generic imx buses
From: Leonard Crestez @ 2019-08-13 1:32 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Artur Świgoń, Jacky Bai, Viresh Kumar,
Michael Turquette, Alexandre Bailon, Will Deacon, Abel Vesa,
Saravana Kannan, Krzysztof Kozlowski, Chanwoo Choi, MyungJoo Ham,
dl-linux-imx, devicetree@vger.kernel.org, open list:THERMAL,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Aisheng Dong, Anson Huang, Stephen Boyd, Kyungmin Park,
Sascha Hauer, Fabio Estevam, Shawn Guo, Georgi Djakov
In-Reply-To: <CAL_JsqJWpQN2oTm8Q2_Gzd0GJ+YZoc9j-zh-U1s4eGhMxDEmEA@mail.gmail.com>
On 8/12/2019 10:47 PM, Rob Herring wrote:
> On Mon, Aug 12, 2019 at 12:49 PM Leonard Crestez <leonard.crestez@nxp.com> wrote:
>> Add initial dt bindings for the interconnects inside i.MX chips.
>> Multiple external IPs are involved but SOC integration means the
>> software controllable interfaces are very similar.
>>
>> +description: |
>> + The i.MX SoC family has multiple buses for which clock frequency (and sometimes
>> + voltage) can be adjusted.
>> +
>> + Some of those buses expose register areas mentioned in the memory maps as GPV
>> + ("Global Programmers View") but not all. Access to this area might be denied for
>> + normal world.
>> +
>> + The buses are based on externally licensed IPs such as ARM NIC-301 and Arteris
>> + FlexNOC but DT bindings are specific to the integration of these bus
>> + interconnect IPs into imx SOCs.
>
> No need to use the interconnect binding?
Separate RFC: https://patchwork.kernel.org/patch/11078673/
The interconnect is represented by a separate "virtual" node which might
not be OK. There was also a recent RFC from samsung which turns devfreq
nodes into interconnect providers:
https://patchwork.kernel.org/cover/11054417/
Is that preferable?
>> +required:
>> + - compatible
>> + - clocks
>
> reg?
This is deliberately optional: for some NICs the GPV register area is
not exposed in the memory map. This is unusual but an accurate
description of the hardware.
The current driver doesn't even attempt to map registers, it only
adjusts the clock.
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/imx8mm-clock.h>
>> + noc: noc@32700000 {
>> + compatible = "fsl,imx8mm-noc", "fsl,imx8m-noc";
>
> Doesn't match the schema. (Well, it does with 'contains', but
> fsl,imx8mm-noc is not documented.)
I'm confused about how per-SOC compatible strings works with validation.
There is a rule that every SOC dtsi needs to add soc prefix to all
device nodes but of_device_id in driver code doesn't need to be updated.
Without using "contains" on the "compatible" property then all
SOC-specific compatible strings would need to be mentioned in every yaml
files. Unless I'm missing something this means updating update every
binding file for each new SOC?
I guess it can be useful because it also validates the compatible
sequence itself.
For this current example something like this seems to work:
compatible:
oneOf:
- items:
- enum:
- fsl,imx8mm-nic
- fsl,imx8mq-nic
- const: fsl,imx8m-nic
- items:
- enum:
- fsl,imx8mm-noc
- fsl,imx8mq-noc
- const: fsl,imx8m-noc
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] scsi: fas216: Mark expected switch fall-throughs
From: Martin K. Petersen @ 2019-08-13 1:54 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: linux-scsi, Martin K. Petersen, James E.J. Bottomley,
linux-kernel, Russell King, linux-arm-kernel
In-Reply-To: <20190806082902.GA11122@embeddedor>
Gustavo,
> Mark switch cases where we are expecting to fall through.
Applied to 5.4/scsi-queue. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Xiaowei Bao @ 2019-08-13 2:10 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: mark.rutland@arm.com, Roy Zang, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
kstewart@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
M.h. Lian, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, pombredanne@nexb.com,
bhelgaas@google.com, kishon@ti.com, shawnguo@kernel.org,
shawn.lin@rock-chips.com, Mingkai Hu
In-Reply-To: <20190812113543.GA25040@e121166-lin.cambridge.arm.com>
> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Sent: 2019年8月12日 19:36
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: kishon@ti.com; bhelgaas@google.com; robh+dt@kernel.org;
> mark.rutland@arm.com; shawnguo@kernel.org; Leo Li
> <leoyang.li@nxp.com>; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; kstewart@linuxfoundation.org;
> pombredanne@nexb.com; shawn.lin@rock-chips.com;
> linux-pci@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit
> property in EP driver.
>
> Caution: EXT Email
>
> On Mon, Aug 12, 2019 at 10:39:00AM +0000, Xiaowei Bao wrote:
> >
> >
> > > -----Original Message-----
> > > From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Sent: 2019年8月12日 18:12
> > > To: Xiaowei Bao <xiaowei.bao@nxp.com>; kishon@ti.com
> > > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; arnd@arndb.de;
> > > gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>;
> > > Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> > > kstewart@linuxfoundation.org; pombredanne@nexb.com;
> > > shawn.lin@rock-chips.com; linux-pci@vger.kernel.org;
> > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > > Subject: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the
> > > bar_fixed_64bit property in EP driver.
> > >
> > > Caution: EXT Email
> > >
> > > First off:
> > >
> > > Trim the CC list, you CC'ed maintainers (and mailing lists) for no
> > > reasons whatsover.
> > [Xiaowei Bao]Hi Lorenzo, I am not clear why the mail list is the CC, I use the
> command "git send-email --to", I will try to send the patch again, do I need to
> modify the version is v4 when I send this patch again?
>
> Yes you do.
>
> Wrap lines to max 80 characters. There is no need to add [Xiaowei Bao].
OK, thanks a lot.
>
> 1) Read, email etiquette
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkernel
> newbies.org%2FPatchCulture&data=02%7C01%7Cxiaowei.bao%40nxp.c
> om%7C73a3b6160aad401b72d208d71f193ae1%7C686ea1d3bc2b4c6fa92cd
> 99c5c301635%7C0%7C0%7C637012065548351226&sdata=y6xa5nMkB
> qkWz7SBFdc%2F0lcQvzI%2F9HjEyC5%2Bk0RxczI%3D&reserved=0
>
> 2) get_maintainer.pl -f drivers/pci/controller/dwc/pci-layerscape.c
>
> Compare the output to the people in CC, trim it accordingly.
>
> 3) The NXP maintainers in the MAINTAINERS file have not given a single
> comment for this patchset. Either they show up or I will remove them
> from the MAINTAINERS list.
>
> 4) Before submitting patches, talk to someone at NXP who can help you
> format them in preparation for posting, I do not have time to write
> guidelines for everyone posting on linux-pci, sorry, the information
> is out there if you care to read it.
>
> Thanks,
> Lorenzo
>
> > >
> > > Then, read this:
> > >
> > > https://lore.ke
> > >
> rnel.org%2Flinux-pci%2F20171026223701.GA25649%40bhelgaas-glaptop.roa
> > >
> m.corp.google.com%2F&data=02%7C01%7Cxiaowei.bao%40nxp.com%7
> > >
> C1c586178e23c423a0e8808d71f0d8f6f%7C686ea1d3bc2b4c6fa92cd99c5c30
> > >
> 1635%7C0%7C0%7C637012015426788575&sdata=3bx1bDFIzik8FnD0wl
> > > duAUv7wtLdD1J3hQ3xNH2xmFY%3D&reserved=0
> > >
> > > and make your patches compliant please.
> > >
> > > On Fri, Jun 28, 2019 at 09:38:25AM +0800, Xiaowei Bao wrote:
> > > > The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1
> > > > is 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware,
> > > > so set the bar_fixed_64bit with 0x14.
> > > >
> > > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > > ---
> > > > v2:
> > > > - Replace value 0x14 with a macro.
> > > > v3:
> > > > - No change.
> > > >
> > > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
> > > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > index be61d96..227c33b 100644
> > > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie
> *pci)
> > > > .linkup_notifier = false,
> > > > .msi_capable = true,
> > > > .msix_capable = false,
> > > > + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> > >
> > > I would appreciate Kishon's ACK on this.
> > >
> > > Lorenzo
> > >
> > > > };
> > > >
> > > > static const struct pci_epc_features*
> > > > --
> > > > 1.7.1
> > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] arm64: dts: ls1088a: fix gpio node
From: Hui Song @ 2019-08-13 2:04 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Mark Rutland, Linus Walleij,
Bartosz Golaszewski
Cc: devicetree, Song Hui, linux-kernel, linux-arm-kernel, linux-gpio
From: Song Hui <hui.song_1@nxp.com>
Update the nodes to include little-endian
property to be consistent with the hardware
and add ls1088a gpio specify compatible.
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 20f5ebd..d58d203 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -269,43 +269,47 @@
};
gpio0: gpio@2300000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2300000 0x0 0x10000>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
gpio1: gpio@2310000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2310000 0x0 0x10000>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
gpio2: gpio@2320000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2320000 0x0 0x10000>;
interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
gpio3: gpio@2330000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2330000 0x0 0x10000>;
interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
ifc: ifc@2240000 {
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH 2/7] dt-bindings: devfreq: Add bindings for generic imx buses
From: MyungJoo Ham @ 2019-08-13 2:25 UTC (permalink / raw)
To: Leonard Crestez, Stephen Boyd, Kyungmin Park, Rob Herring
Cc: Dong Aisheng, Artur Swigon, Abel Vesa, Saravana Kannan,
Anson Huang, linux-arm-kernel@lists.infradead.org, Viresh Kumar,
Michael Turquette, linux-pm@vger.kernel.org, linux-imx@nxp.com,
Krzysztof Kozlowski, Chanwoo Choi, Will Deacon, Alexandre Bailon,
kernel@pengutronix.de, Fabio Estevam, Mark Rutland, Shawn Guo,
Georgi Djakov, devicetree@vger.kernel.org, Jacky Bai
In-Reply-To: <97b0bff95ddb85b06ef3d2f8079faa36562a956d.1565633880.git.leonard.crestez@nxp.com>
>Add initial dt bindings for the interconnects inside i.MX chips.
>Multiple external IPs are involved but SOC integration means the
>software controllable interfaces are very similar.
>
>This is initially only for imx8mm but add an "fsl,imx8m-nic" fallback
>similar to exynos-bus.
>
>Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>---
> .../devicetree/bindings/devfreq/imx.yaml | 50 +++++++++++++++++++
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/devfreq/imx.yaml
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 3/7] PM / devfreq: Add generic imx bus driver
From: MyungJoo Ham @ 2019-08-13 2:33 UTC (permalink / raw)
To: Leonard Crestez, Stephen Boyd, Kyungmin Park, Rob Herring
Cc: Dong Aisheng, Artur Swigon, Abel Vesa, Saravana Kannan,
Anson Huang, linux-arm-kernel@lists.infradead.org, Viresh Kumar,
Michael Turquette, linux-pm@vger.kernel.org, linux-imx@nxp.com,
Krzysztof Kozlowski, Chanwoo Choi, Will Deacon, Alexandre Bailon,
kernel@pengutronix.de, Fabio Estevam, Mark Rutland, Shawn Guo,
Georgi Djakov, devicetree@vger.kernel.org, Jacky Bai
In-Reply-To: <dbdd1ae60993d5fe73ce5b446b2c7d559c981cf1.1565633880.git.leonard.crestez@nxp.com>
>Add initial support for dynamic frequency switching on pieces of the imx
>interconnect fabric.
>
>All this driver actually does is set a clk rate based on an opp table.
>
>No attempt is made to map registers or anything clever.
>
>Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>---
> drivers/devfreq/Kconfig | 12 +++
> drivers/devfreq/Makefile | 1 +
> drivers/devfreq/imx-devfreq.c | 148 ++++++++++++++++++++++++++++++++++
> 3 files changed, 161 insertions(+)
> create mode 100644 drivers/devfreq/imx-devfreq.c
>
>diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>index defe1d438710..9088a151bafe 100644
>--- a/drivers/devfreq/Kconfig
>+++ b/drivers/devfreq/Kconfig
>@@ -90,10 +90,22 @@ config ARM_EXYNOS_BUS_DEVFREQ
> Each memory bus group could contain many memoby bus block. It reads
> PPMU counters of memory controllers by using DEVFREQ-event device
> and adjusts the operating frequencies and voltages with OPP support.
> This does not yet operate with optimal voltages.
>
>+config ARM_IMX_DEVFREQ
>+ tristate "i.MX DEVFREQ Driver"
>+ depends on ARCH_MXC || COMPILE_TEST
>+ select DEVFREQ_GOV_PASSIVE
>+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
>+ select DEVFREQ_GOV_USERSPACE
>+ select PM_OPP
Hello,
I have a simple question:
Does it support ALL ARCH_MXC SoCs?
Cheers,
MyungJoo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/7] PM / devfreq: Add generic imx bus driver
From: Leonard Crestez @ 2019-08-13 3:02 UTC (permalink / raw)
To: myungjoo.ham@samsung.com, Stephen Boyd, Kyungmin Park
Cc: Mark Rutland, Artur Swigon, Jacky Bai, Viresh Kumar,
Michael Turquette, Alexandre Bailon, Will Deacon, Abel Vesa,
Saravana Kannan, Krzysztof Kozlowski, Chanwoo Choi, dl-linux-imx,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org, Rob Herring,
linux-arm-kernel@lists.infradead.org, Aisheng Dong, Anson Huang,
kernel@pengutronix.de, Fabio Estevam, Shawn Guo, Georgi Djakov
In-Reply-To: <20190813023338epcms1p307caf6727399e9f3e320b965fb95a603@epcms1p3>
On 8/13/2019 5:33 AM, MyungJoo Ham wrote:
>> Add initial support for dynamic frequency switching on pieces of the imx
>> interconnect fabric.
>>
>> All this driver actually does is set a clk rate based on an opp table.
>>
>> +config ARM_IMX_DEVFREQ
>> + tristate "i.MX DEVFREQ Driver"
>> + depends on ARCH_MXC || COMPILE_TEST
>> + select DEVFREQ_GOV_PASSIVE
>> + select DEVFREQ_GOV_SIMPLE_ONDEMAND
>> + select DEVFREQ_GOV_USERSPACE
>> + select PM_OPP
>
> Does it support ALL ARCH_MXC SoCs?
Only imx8m currently but out of tree we support bus+dram frequency
switching for ~10 imx6/7 SOCs, all other than imx7ulp.
When imx8 was upstreamed as the first 64-bit imx chip the arm64
maintainers told us to drop stuff like ARCH_FSL_IMX8MM so there is no
per-soc kconfig more specific than "ARCH_MXC".
I guess we could make it depend on (ARCH_MXC && ARM64) but the ARM64
would eventually be dropped anyway.
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv4 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Xiaowei Bao @ 2019-08-13 2:53 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, minghuan.Lian, mingkai.hu, roy.zang,
l.stach, kishon, tpiepho, leonard.crestez, andrew.smirnov,
yue.wang, hayashi.kunihiko, dwmw, jonnyc, linux-pci, linux-kernel,
linuxppc-dev, linux-arm-kernel
Cc: Xiaowei Bao
The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1
is 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware,
so set the bar_fixed_64bit with 0x14.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- Replace value 0x14 with a macro.
v3:
- No change.
v4:
- send the patch again with '--to'.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index be61d96..227c33b 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci)
.linkup_notifier = false,
.msi_capable = true,
.msix_capable = false,
+ .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
};
static const struct pci_epc_features*
--
1.7.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv4 2/2] PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
From: Xiaowei Bao @ 2019-08-13 2:53 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, minghuan.Lian, mingkai.hu, roy.zang,
l.stach, kishon, tpiepho, leonard.crestez, andrew.smirnov,
yue.wang, hayashi.kunihiko, dwmw, jonnyc, linux-pci, linux-kernel,
linuxppc-dev, linux-arm-kernel
Cc: Xiaowei Bao
In-Reply-To: <20190813025317.48290-1-xiaowei.bao@nxp.com>
Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- No change.
v3:
- modify the commit message.
v4:
- send the patch again with '--to'.
drivers/pci/controller/dwc/Kconfig | 20 ++++++++++++++++++--
drivers/pci/controller/dwc/Makefile | 3 ++-
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index a6ce1ee..a41ccf5 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -131,13 +131,29 @@ config PCI_KEYSTONE_EP
DesignWare core functions to implement the driver.
config PCI_LAYERSCAPE
- bool "Freescale Layerscape PCIe controller"
+ bool "Freescale Layerscape PCIe controller - Host mode"
depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
depends on PCI_MSI_IRQ_DOMAIN
select MFD_SYSCON
select PCIE_DW_HOST
help
- Say Y here if you want PCIe controller support on Layerscape SoCs.
+ Say Y here if you want to enable PCIe controller support on Layerscape
+ SoCs to work in Host mode.
+ This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
+ determines which PCIe controller works in EP mode and which PCIe
+ controller works in RC mode.
+
+config PCI_LAYERSCAPE_EP
+ bool "Freescale Layerscape PCIe controller - Endpoint mode"
+ depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
+ depends on PCI_ENDPOINT
+ select PCIE_DW_EP
+ help
+ Say Y here if you want to enable PCIe controller support on Layerscape
+ SoCs to work in Endpoint mode.
+ This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
+ determines which PCIe controller works in EP mode and which PCIe
+ controller works in RC mode.
config PCI_HISI
depends on OF && (ARM64 || COMPILE_TEST)
diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
index b085dfd..824fde7 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone.o
-obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o
+obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
+obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o
obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
--
1.7.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] PM / devfreq: passive: Use non-devm notifiers
From: Chanwoo Choi @ 2019-08-13 4:23 UTC (permalink / raw)
To: Leonard Crestez, MyungJoo Ham, Kyungmin Park
Cc: Artur Świgoń, Geert Uytterhoeven, Saravana Kannan,
Rafael J. Wysocki, Greg Kroah-Hartman, Bartosz Golaszewski,
linux-pm, Krzysztof Kozlowski, Lukasz Luba, Alexandre Bailon,
cpgs (cpgs@samsung.com), Bjorn Andersson, linux-arm-kernel
In-Reply-To: <38b77bb80d12aa788d4e234e399780a27dcd9e9f.1565282993.git.leonard.crestez@nxp.com>
Hi,
On 19. 8. 9. 오전 1:54, Leonard Crestez wrote:
> The devfreq passive governor registers and unregisters devfreq
> transition notifiers on DEVFREQ_GOV_START/GOV_STOP using devm wrappers.
>
> If devfreq itself is registered with devm then a warning is triggered on
> rmmod from devm_devfreq_unregister_notifier. Call stack looks like this:
>
> devm_devfreq_unregister_notifier+0x30/0x40
> devfreq_passive_event_handler+0x4c/0x88
> devfreq_remove_device.part.8+0x6c/0x9c
> devm_devfreq_dev_release+0x18/0x20
> release_nodes+0x1b0/0x220
> devres_release_all+0x78/0x84
> device_release_driver_internal+0x100/0x1c0
> driver_detach+0x4c/0x90
> bus_remove_driver+0x7c/0xd0
> driver_unregister+0x2c/0x58
> platform_driver_unregister+0x10/0x18
> imx_devfreq_platdrv_exit+0x14/0xd40 [imx_devfreq]
>
> This happens because devres_release_all will first remove all the nodes
> into a separate todo list so the nested devres_release from
> devm_devfreq_unregister_notifier won't find anything.
>
> Fix the warning by calling the non-devm APIS for frequency notification.
> Using devm wrappers is not actually useful for a governor anyway: it
> relies on the devfreq core to correctly match the GOV_START/GOV_STOP
> notifications.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>
> ---
> drivers/devfreq/governor_passive.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> The only current user of passive governor is exynos-bus; does rmmod work
> for you? Maybe I'm missing something.
>
> It also seems that no attempt is made to increase the ref count of
> the passive "parent" so in theory devices can be removed while still
> referenced. However that would be a separate issue.
>
> diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
> index 58308948b863..da485477065c 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -163,16 +163,16 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
> case DEVFREQ_GOV_START:
> if (!p_data->this)
> p_data->this = devfreq;
>
> nb->notifier_call = devfreq_passive_notifier_call;
> - ret = devm_devfreq_register_notifier(dev, parent, nb,
> + ret = devfreq_register_notifier(parent, nb,
> DEVFREQ_TRANSITION_NOTIFIER);
> break;
> case DEVFREQ_GOV_STOP:
> - devm_devfreq_unregister_notifier(dev, parent, nb,
> - DEVFREQ_TRANSITION_NOTIFIER);
> + WARN_ON(devfreq_unregister_notifier(parent, nb,
> + DEVFREQ_TRANSITION_NOTIFIER));
> break;
> default:
> break;
> }
>
>
Looks good to me. But, you have to add the following fixes tag
and send it to stable mailing list to fix the bug.
- Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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