* Re: [PATCH v3] PCI: aardvark: Don't rely on jiffies while holding spinlock
From: Thomas Petazzoni @ 2019-09-27 9:45 UTC (permalink / raw)
To: Remi Pommarel
Cc: Bjorn Helgaas, linux-pci, Lorenzo Pieralisi, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190927085502.1758-1-repk@triplefau.lt>
On Fri, 27 Sep 2019 10:55:02 +0200
Remi Pommarel <repk@triplefau.lt> wrote:
> advk_pcie_wait_pio() can be called while holding a spinlock (from
> pci_bus_read_config_dword()), then depends on jiffies in order to
> timeout while polling on PIO state registers. In the case the PIO
> transaction failed, the timeout will never happen and will also cause
> the cpu to stall.
>
> This decrements a variable and wait instead of using jiffies.
>
> Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Thanks!
Thomas
--
Thomas Petazzoni, CTO, 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] media: ov5695: Add suport for registering sensor-related
From: Andy Shevchenko @ 2019-09-27 9:45 UTC (permalink / raw)
To: Dongchun Zhu
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, shengnan.wang,
tfiga, louis.kuo, sj.huang, robh+dt, linux-mediatek, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20190927071824.18675-1-dongchun.zhu@mediatek.com>
On Fri, Sep 27, 2019 at 03:18:23PM +0800, Dongchun Zhu wrote:
> Hello,
>
> This series modifies the interface of async register V4L2 sub-device invoked in probe function for OV5695 CMOS sensor.
> The Omnivision OV5695 image sensor would be used in camera features on CrOS application.
> 5.0 Mega Pixel MIPI Camera Mdoule also supports auto-focus control (AFC) with embedded AF VCM Driver.
>
> Here we use v4l2_async_register_subdev_sensor_common() instead of v4l2_async_register_subdev()
> to register a sensor sub-device to the asynchronous sub-device framework and parse set up
> common sensor-related devices, such as actuator.
>
> This function is just like v4l2_async_register_subdev() with the exception that calling it will also parse
> firmware interfaces for remote references using v4l2_async_notifier_parse_fwnode_sensor_common()
> and registers the async sub-devices.
>
> After applying this change, we can see the VCM move when changing the scene.
When you derive Cc list, set some threshold to the get_maintainer.pl, like
scripts/get_maintainer.pl --git --git-min-percent=67
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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 08/11] of: Factor out #{addr,size}-cells parsing
From: Geert Uytterhoeven @ 2019-09-27 9:27 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Arnd Bergmann, Frank Rowand, linux-pci,
Linux Kernel Mailing List, Marek Vasut, Lorenzo Pieralisi,
Linux ARM, Simon Horman, Robin Murphy, Nicolas Saenz Julienne,
Stefan Wahren
In-Reply-To: <20190927002455.13169-9-robh@kernel.org>
On Fri, Sep 27, 2019 at 2:25 AM Rob Herring <robh@kernel.org> wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> In some cases such as PCI host controllers, we may have a "parent bus"
> which is an OF leaf node, but still need to correctly parse ranges from
> the point of view of that bus. For that, factor out variants of the
> "#addr-cells" and "#size-cells" parsers which do not assume they have a
> device node and thus immediately traverse upwards before reading the
> relevant property.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> [robh: don't make of_bus_n_{addr,size}_cells() public]
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] firmware: imx: Skip return value check for some special SCU firmware APIs
From: Anson Huang @ 2019-09-27 9:27 UTC (permalink / raw)
To: Marco Felsch
Cc: Aisheng Dong, shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
Leonard Crestez, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190927090609.fyxdekkzrco7memt@pengutronix.de>
Hi, Marco
> On 19-09-27 01:20, Anson Huang wrote:
> > Hi, Leonard
> >
> > > On 2019-09-26 1:06 PM, Marco Felsch wrote:
> > > > On 19-09-26 08:03, Anson Huang wrote:
> > > >>> On 19-09-25 18:07, Anson Huang wrote:
> > > >>>> The SCU firmware does NOT always have return value stored in
> > > >>>> message header's function element even the API has response
> > > >>>> data, those special APIs are defined as void function in SCU
> > > >>>> firmware, so they should be treated as return success always.
> > > >>>>
> > > >>>> +static const struct imx_sc_rpc_msg whitelist[] = {
> > > >>>> + { .svc = IMX_SC_RPC_SVC_MISC, .func =
> > > >>> IMX_SC_MISC_FUNC_UNIQUE_ID },
> > > >>>> + { .svc = IMX_SC_RPC_SVC_MISC, .func =
> > > >>>> +IMX_SC_MISC_FUNC_GET_BUTTON_STATUS }, };
> > > >>>
> > > >>> Is this going to be extended in the near future? I see some
> > > >>> upcoming problems here if someone uses a different
> > > >>> scu-fw<->kernel combination as nxp would suggest.
> > > >>
> > > >> Could be, but I checked the current APIs, ONLY these 2 will be
> > > >> used in Linux kernel, so I ONLY add these 2 APIs for now.
> > > >
> > > > Okay.
> > > >
> > > >> However, after rethink, maybe we should add another imx_sc_rpc
> > > >> API for those special APIs? To avoid checking it for all the APIs
> > > >> called which
> > > may impact some performance.
> > > >> Still under discussion, if you have better idea, please advise, thanks!
> > >
> > > My suggestion is to refactor the code and add a new API for the this
> > > "no error value" convention. Internally they can call a common
> > > function with flags.
> >
> > If I understand your point correctly, that means the loop check of
> > whether the API is with "no error value" for every API still NOT be
> > skipped, it is just refactoring the code, right?
>
> How makes this things easier?
I think it is just for making a better SW layer.
>
> > > > Adding a special api shouldn't be the right fix. Imagine if
> > > > someone (not a nxp-developer) wants to add a new driver. How could
> > > > he be expected to know which api he should use. The better
> > > > abbroach would be to fix the scu-fw instead of adding quirks..
> >
> > Yes, fixing SCU FW is the best solution, but we have talked to SCU FW
> > owner, the SCU FW released has been finalized, so the API
> > implementation can NOT be changed, but they will pay attention to this
> > issue for new added APIs later. That means the number of APIs having this
> issue a very limited.
>
> This means those APIs which already have this bug will not be fixed?
> IMHO this sounds a bit weird since this is a changeable peace of code ;)
We can't say it is a bug, the SCU FW owner design it in this way, there are
some void function in SCU FW API, and once there is response data from SCU,
that means the API call is successful, and void function does NOT have a return
value for caller.
So it is just current SCU IPC driver in kernel NOT 100% matching SCU FW, those
void function has such return value issue.
Anson.
_______________________________________________
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 5/5] arm64: vdso32: Remove jump label config option in Makefile
From: Catalin Marinas @ 2019-09-27 9:27 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: ard.biesheuvel, ndesaulniers, linux-kernel, tglx, will,
linux-arm-kernel
In-Reply-To: <20190926214342.34608-6-vincenzo.frascino@arm.com>
On Thu, Sep 26, 2019 at 10:43:42PM +0100, Vincenzo Frascino wrote:
> The jump labels are not used in vdso32 since it is not possible to run
> runtime patching on them.
>
> Remove the configuration option from the Makefile.
>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/4] WIP: dt-bindings: medaitek: mt8183: add property "resets" && "reset-names"
From: Jiaxin Yu @ 2019-09-27 9:26 UTC (permalink / raw)
To: broonie, mark.rutland, robh+dt, linux, wim
Cc: alsa-devel, yong.liang, lgirdwood, jiaxin.yu, perex, tzungbi,
linux-mediatek, eason.yen, linux-arm-kernel
In-Reply-To: <1569576417-20663-1-git-send-email-jiaxin.yu@mediatek.com>
This patch add property "resets" && "reset-names" in examples so that we can
use reset controller to reset audio domain regs.
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com>
---
Documentation/devicetree/bindings/sound/mt8183-afe-pcm.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/mt8183-afe-pcm.txt b/Documentation/devicetree/bindings/sound/mt8183-afe-pcm.txt
index 396ba38619f6..1f1cba4152ce 100644
--- a/Documentation/devicetree/bindings/sound/mt8183-afe-pcm.txt
+++ b/Documentation/devicetree/bindings/sound/mt8183-afe-pcm.txt
@@ -4,6 +4,10 @@ Required properties:
- compatible = "mediatek,mt68183-audio";
- reg: register location and size
- interrupts: should contain AFE interrupt
+- resets: Must contain an entry for each entry in reset-names
+ See ../reset/reset.txt for details.
+- reset-names: should have these reset names:
+ "audiosys";
- power-domains: should define the power domain
- clocks: Must contain an entry for each entry in clock-names
- clock-names: should have these clock names:
@@ -20,6 +24,8 @@ Example:
compatible = "mediatek,mt8183-audio";
reg = <0 0x11220000 0 0x1000>;
interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_LOW>;
+ resets = <&watchdog MT8183_TOPRGU_AUDIO_SW_RST>;
+ reset-names = "audiosys";
power-domains = <&scpsys MT8183_POWER_DOMAIN_AUDIO>;
clocks = <&infrasys CLK_INFRA_AUDIO>,
<&infrasys CLK_INFRA_AUDIO_26M_BCLK>,
--
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 related
* [PATCH 2/4] WIP: watchdog: mtk_wdt: mt8183: Add reset controller
From: Jiaxin Yu @ 2019-09-27 9:26 UTC (permalink / raw)
To: broonie, mark.rutland, robh+dt, linux, wim
Cc: alsa-devel, yong.liang, lgirdwood, jiaxin.yu, perex, tzungbi,
linux-mediatek, eason.yen, linux-arm-kernel
In-Reply-To: <1569576417-20663-1-git-send-email-jiaxin.yu@mediatek.com>
From: "yong.liang" <yong.liang@mediatek.com>
Provide assert/deassert/reset API in watchdog driver.
Register reset controller for toprgu device in watchdog probe.
Signed-off-by: yong.liang <yong.liang@mediatek.com>
---
drivers/watchdog/Kconfig | 1 +
drivers/watchdog/mtk_wdt.c | 110 ++++++++++++++++++++++++++++++++++++-
2 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2e07caab9db2..629249fe5305 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -717,6 +717,7 @@ config MEDIATEK_WATCHDOG
tristate "Mediatek SoCs watchdog support"
depends on ARCH_MEDIATEK || COMPILE_TEST
select WATCHDOG_CORE
+ select RESET_CONTROLLER
help
Say Y here to include support for the watchdog timer
in Mediatek SoCs.
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 9c3d0033260d..660fb0e48d8e 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -20,6 +20,10 @@
#include <linux/types.h>
#include <linux/watchdog.h>
#include <linux/delay.h>
+#include <linux/reset-controller.h>
+#include <linux/slab.h>
+#include <linux/reset.h>
+#include <linux/of_device.h>
#define WDT_MAX_TIMEOUT 31
#define WDT_MIN_TIMEOUT 1
@@ -44,17 +48,113 @@
#define WDT_SWRST 0x14
#define WDT_SWRST_KEY 0x1209
+#define WDT_SWSYSRST 0x18U
+#define WDT_SWSYS_RST_KEY 0x88000000
+
#define DRV_NAME "mtk-wdt"
#define DRV_VERSION "1.0"
static bool nowayout = WATCHDOG_NOWAYOUT;
static unsigned int timeout;
+struct toprgu_reset {
+ spinlock_t lock; /* Protects reset_controller access */
+ void __iomem *toprgu_swrst_base;
+ int regofs;
+ struct reset_controller_dev rcdev;
+};
+
struct mtk_wdt_dev {
struct watchdog_device wdt_dev;
void __iomem *wdt_base;
+ struct toprgu_reset reset_controller;
+ const struct mtk_wdt_compatible *dev_comp;
+};
+
+struct mtk_wdt_compatible {
+ int sw_rst_num;
+};
+
+static int toprgu_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ unsigned int tmp;
+ unsigned long flags;
+ struct toprgu_reset *data = container_of(rcdev,
+ struct toprgu_reset, rcdev);
+
+ spin_lock_irqsave(&data->lock, flags);
+
+ tmp = __raw_readl(data->toprgu_swrst_base + data->regofs);
+ tmp |= BIT(id);
+ tmp |= WDT_SWSYS_RST_KEY;
+ writel(tmp, data->toprgu_swrst_base + data->regofs);
+
+ spin_unlock_irqrestore(&data->lock, flags);
+
+ return 0;
+}
+
+static int toprgu_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ unsigned int tmp;
+ unsigned long flags;
+ struct toprgu_reset *data = container_of(rcdev,
+ struct toprgu_reset, rcdev);
+
+ spin_lock_irqsave(&data->lock, flags);
+
+ tmp = __raw_readl(data->toprgu_swrst_base + data->regofs);
+ tmp &= ~BIT(id);
+ tmp |= WDT_SWSYS_RST_KEY;
+ writel(tmp, data->toprgu_swrst_base + data->regofs);
+
+ spin_unlock_irqrestore(&data->lock, flags);
+
+ return 0;
+}
+
+static int toprgu_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ int ret;
+
+ ret = toprgu_reset_assert(rcdev, id);
+ if (ret)
+ return ret;
+
+ return toprgu_reset_deassert(rcdev, id);
+}
+
+static struct reset_control_ops toprgu_reset_ops = {
+ .assert = toprgu_reset_assert,
+ .deassert = toprgu_reset_deassert,
+ .reset = toprgu_reset,
};
+static void toprgu_register_reset_controller(struct platform_device *pdev,
+ int regofs)
+{
+ int ret;
+ struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
+
+ spin_lock_init(&mtk_wdt->reset_controller.lock);
+
+ mtk_wdt->dev_comp = of_device_get_match_data(&pdev->dev);
+ mtk_wdt->reset_controller.toprgu_swrst_base = mtk_wdt->wdt_base;
+ mtk_wdt->reset_controller.regofs = regofs;
+ mtk_wdt->reset_controller.rcdev.owner = THIS_MODULE;
+ mtk_wdt->reset_controller.rcdev.nr_resets =
+ mtk_wdt->dev_comp->sw_rst_num;
+ mtk_wdt->reset_controller.rcdev.ops = &toprgu_reset_ops;
+ mtk_wdt->reset_controller.rcdev.of_node = pdev->dev.of_node;
+ ret = reset_controller_register(&mtk_wdt->reset_controller.rcdev);
+ if (ret != 0)
+ dev_err(&pdev->dev,
+ "couldn't register wdt reset controller: %d\n", ret);
+}
+
static int mtk_wdt_restart(struct watchdog_device *wdt_dev,
unsigned long action, void *data)
{
@@ -187,9 +287,12 @@ static int mtk_wdt_probe(struct platform_device *pdev)
if (unlikely(err))
return err;
- dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d)\n",
+ dev_info(&pdev->dev, "Watchdog enabled (timeout=%d sec, nowayout=%d)\n",
mtk_wdt->wdt_dev.timeout, nowayout);
+ mtk_wdt->dev_comp = of_device_get_match_data(&pdev->dev);
+ if (mtk_wdt->dev_comp)
+ toprgu_register_reset_controller(pdev, WDT_SWSYSRST);
return 0;
}
@@ -217,7 +320,12 @@ static int mtk_wdt_resume(struct device *dev)
}
#endif
+static const struct mtk_wdt_compatible mt8183_compat = {
+ .sw_rst_num = 18,
+};
+
static const struct of_device_id mtk_wdt_dt_ids[] = {
+ { .compatible = "mediatek,mt8183-wdt", .data = &mt8183_compat },
{ .compatible = "mediatek,mt6589-wdt" },
{ /* sentinel */ }
};
--
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 related
* [PATCH 1/4] WIP: dt-bindings: mediatek: mt8183: Add #reset-cells
From: Jiaxin Yu @ 2019-09-27 9:26 UTC (permalink / raw)
To: broonie, mark.rutland, robh+dt, linux, wim
Cc: alsa-devel, yong.liang, yong.liang, lgirdwood, jiaxin.yu, perex,
tzungbi, linux-mediatek, eason.yen, linux-arm-kernel
In-Reply-To: <1569576417-20663-1-git-send-email-jiaxin.yu@mediatek.com>
From: "yong.liang" <yong.liang@mediatek.corp-partner.google.com>
Add #reset-cells property and update example.
Signed-off-by: yong.liang <yong.liang@mediatek.com>
---
.../devicetree/bindings/watchdog/mtk-wdt.txt | 9 ++++++---
.../dt-bindings/reset-controller/mt8183-resets.h | 13 +++++++++++++
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
index 3ee625d0812f..ecb9ff784832 100644
--- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
@@ -16,11 +16,14 @@ Required properties:
Optional properties:
- timeout-sec: contains the watchdog timeout in seconds.
+- #reset-cells: Should be 1.
Example:
-wdt: watchdog@10000000 {
- compatible = "mediatek,mt6589-wdt";
- reg = <0x10000000 0x18>;
+watchdog: watchdog@10007000 {
+ compatible = "mediatek,mt8183-wdt",
+ "mediatek,mt6589-wdt";
+ reg = <0 0x10007000 0 0x100>;
timeout-sec = <10>;
+ #reset-cells = <1>;
};
diff --git a/include/dt-bindings/reset-controller/mt8183-resets.h b/include/dt-bindings/reset-controller/mt8183-resets.h
index 8804e34ebdd4..47dadcf3fd24 100644
--- a/include/dt-bindings/reset-controller/mt8183-resets.h
+++ b/include/dt-bindings/reset-controller/mt8183-resets.h
@@ -78,4 +78,17 @@
#define MT8183_INFRACFG_AO_I2C7_SW_RST 126
#define MT8183_INFRACFG_AO_I2C8_SW_RST 127
+#define MT8183_TOPRGU_MM_SW_RST 1
+#define MT8183_TOPRGU_MFG_SW_RST 2
+#define MT8183_TOPRGU_VENC_SW_RST 3
+#define MT8183_TOPRGU_VDEC_SW_RST 4
+#define MT8183_TOPRGU_IMG_SW_RST 5
+#define MT8183_TOPRGU_MD_SW_RST 7
+#define MT8183_TOPRGU_CONN_SW_RST 9
+#define MT8183_TOPRGU_CONN_MCU_SW_RST 12
+#define MT8183_TOPRGU_IPU0_SW_RST 14
+#define MT8183_TOPRGU_IPU1_SW_RST 15
+#define MT8183_TOPRGU_AUDIO_SW_RST 17
+#define MT8183_TOPRGU_CAMSYS_SW_RST 18
+
#endif /* _DT_BINDINGS_RESET_CONTROLLER_MT8183 */
--
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 related
* [PATCH 4/4] WIP: ASoC: mt8183: fix audio playback slowly after playback during bootup
From: Jiaxin Yu @ 2019-09-27 9:26 UTC (permalink / raw)
To: broonie, mark.rutland, robh+dt, linux, wim
Cc: alsa-devel, yong.liang, lgirdwood, jiaxin.yu, perex, tzungbi,
linux-mediatek, eason.yen, linux-arm-kernel
In-Reply-To: <1569576417-20663-1-git-send-email-jiaxin.yu@mediatek.com>
Before regmap_reinit_cache we must reset audio regs as default values.
So we use reset controller unit(toprgu) to reset audio hw.
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com>
---
sound/soc/mediatek/mt8183/mt8183-afe-pcm.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/sound/soc/mediatek/mt8183/mt8183-afe-pcm.c b/sound/soc/mediatek/mt8183/mt8183-afe-pcm.c
index 4a31106d3471..721632386a50 100644
--- a/sound/soc/mediatek/mt8183/mt8183-afe-pcm.c
+++ b/sound/soc/mediatek/mt8183/mt8183-afe-pcm.c
@@ -11,6 +11,7 @@
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/pm_runtime.h>
+#include <linux/reset.h>
#include "mt8183-afe-common.h"
#include "mt8183-afe-clk.h"
@@ -1089,6 +1090,7 @@ static int mt8183_afe_pcm_dev_probe(struct platform_device *pdev)
struct mtk_base_afe *afe;
struct mt8183_afe_private *afe_priv;
struct device *dev;
+ struct reset_control *rstc;
int i, irq_id, ret;
afe = devm_kzalloc(&pdev->dev, sizeof(*afe), GFP_KERNEL);
@@ -1126,6 +1128,19 @@ static int mt8183_afe_pcm_dev_probe(struct platform_device *pdev)
return ret;
}
+ rstc = devm_reset_control_get(dev, "audiosys");
+ if (IS_ERR(rstc)) {
+ ret = PTR_ERR(rstc);
+ dev_err(dev, "could not get audiosys reset:%d\n", ret);
+ return ret;
+ }
+
+ ret = reset_control_reset(rstc);
+ if (ret) {
+ dev_err(dev, "failed to trigger audio reset:%d\n", ret);
+ return ret;
+ }
+
/* enable clock for regcache get default value from hw */
afe_priv->pm_runtime_bypass_reg_ctl = true;
pm_runtime_get_sync(&pdev->dev);
--
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 related
* [PATCH 0/4] ASoC: mt8183: fix audio playback slowly after playback
From: Jiaxin Yu @ 2019-09-27 9:26 UTC (permalink / raw)
To: broonie, mark.rutland, robh+dt, linux, wim
Cc: alsa-devel, yong.liang, lgirdwood, jiaxin.yu, perex, tzungbi,
linux-mediatek, eason.yen, linux-arm-kernel
This series patches add reset controller for MT8183, and audio will use it in
machine driver during bootup, they depend on the following patch:
1. this series add support reset-controller in infra
[v5,2/2] clk: reset: Modify reset-controller driver
*** BLURB HERE ***
Jiaxin Yu (2):
WIP: dt-bindings: medaitek: mt8183: add property "resets" &&
"reset-names"
WIP: ASoC: mt8183: fix audio playback slowly after playback during
bootup
yong.liang (2):
WIP: dt-bindings: mediatek: mt8183: Add #reset-cells
WIP: watchdog: mtk_wdt: mt8183: Add reset controller
.../bindings/sound/mt8183-afe-pcm.txt | 6 +
.../devicetree/bindings/watchdog/mtk-wdt.txt | 9 +-
drivers/watchdog/Kconfig | 1 +
drivers/watchdog/mtk_wdt.c | 110 +++++++++++++++++-
.../reset-controller/mt8183-resets.h | 13 +++
sound/soc/mediatek/mt8183/mt8183-afe-pcm.c | 15 +++
6 files changed, 150 insertions(+), 4 deletions(-)
--
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 v3 3/5] arm64: vdso32: Fix compilation warning
From: Catalin Marinas @ 2019-09-27 9:26 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: ard.biesheuvel, ndesaulniers, linux-kernel, tglx, will,
linux-arm-kernel
In-Reply-To: <20190926214342.34608-4-vincenzo.frascino@arm.com>
On Thu, Sep 26, 2019 at 10:43:40PM +0100, Vincenzo Frascino wrote:
> Note: This fix is meant to be temporary, a more comprehensive solution
> based on the refactoring of the generic headers will be provided with a
> future patch set. At that point it will be possible to revert this patch.
With this note, I'm fine with the patch.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.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 v3 2/5] arm64: vdso32: Detect binutils support for dmb ishld
From: Catalin Marinas @ 2019-09-27 9:25 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: ard.biesheuvel, ndesaulniers, linux-kernel, tglx, will,
linux-arm-kernel
In-Reply-To: <20190926214342.34608-3-vincenzo.frascino@arm.com>
On Thu, Sep 26, 2019 at 10:43:39PM +0100, Vincenzo Frascino wrote:
> As reported by Will Deacon, older versions of binutils that do not
> support certain types of memory barriers can cause build failure of the
> vdso32 library.
>
> Add a compilation time mechanism that detects if binutils supports those
> instructions and configure the kernel accordingly.
>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.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 v3 1/5] arm64: vdso32: Introduce COMPAT_CC_IS_GCC
From: Catalin Marinas @ 2019-09-27 9:24 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: ard.biesheuvel, ndesaulniers, linux-kernel, tglx, will,
linux-arm-kernel
In-Reply-To: <20190926214342.34608-2-vincenzo.frascino@arm.com>
On Thu, Sep 26, 2019 at 10:43:38PM +0100, Vincenzo Frascino wrote:
> Address the problem removing CONFIG_CROSS_COMPILE_COMPAT_VDSO and moving
And this config does need to go in a subsequent patch.
> the detection of the correct compiler into Kconfig via COMPAT_CC_IS_GCC.
Nitpick: it's COMPATCC_IS_ARM_GCC now.
> As a consequence of this it is not possible anymore to set the compat
> cross compiler from menuconfig but it requires to be exported via
> command line.
>
> E.g.:
>
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
> CROSS_COMPILE_COMPAT=arm-linux-gnueabihf
Another nitpick, add a '-' at the end of 'gnueabihf'.
Otherwise:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.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 06/11] of/address: Introduce of_get_next_dma_parent() helper
From: Geert Uytterhoeven @ 2019-09-27 9:24 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Arnd Bergmann, Frank Rowand, linux-pci,
Linux Kernel Mailing List, Marek Vasut, Lorenzo Pieralisi,
Linux ARM, Simon Horman, Geert Uytterhoeven, Robin Murphy,
Nicolas Saenz Julienne, Stefan Wahren
In-Reply-To: <20190927002455.13169-7-robh@kernel.org>
On Fri, Sep 27, 2019 at 2:25 AM Rob Herring <robh@kernel.org> wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> Add of_get_next_dma_parent() helper which is similar to
> __of_get_dma_parent(), but can be used in iterators and decrements the
> ref count on the prior parent.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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 v4 3/5] psci: Add hvc call service for ptp_kvm.
From: Sergei Shtylyov @ 2019-09-27 9:20 UTC (permalink / raw)
To: Jianyong Wu, netdev, yangbo.lu, john.stultz, tglx, pbonzini,
sean.j.christopherson, maz, richardcochran, Mark.Rutland,
Will.Deacon, suzuki.poulose
Cc: justin.he, kvm, Steve.Capper, linux-kernel, Kaly.Xin, nd, kvmarm,
linux-arm-kernel
In-Reply-To: <20190926114212.5322-4-jianyong.wu@arm.com>
Hello!
On 26.09.2019 14:42, Jianyong Wu wrote:
> This patch is the base of ptp_kvm for arm64.
> ptp_kvm modules will call hvc to get this service.
> The service offers real time and counter cycle of host for guest.
>
> Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
> ---
> include/linux/arm-smccc.h | 12 ++++++++++++
> virt/kvm/arm/psci.c | 18 ++++++++++++++++++
> 2 files changed, 30 insertions(+)
[...]
> diff --git a/virt/kvm/arm/psci.c b/virt/kvm/arm/psci.c
> index 0debf49bf259..3f30fc42a5ca 100644
> --- a/virt/kvm/arm/psci.c
> +++ b/virt/kvm/arm/psci.c
[...]
> @@ -431,6 +433,22 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> break;
> + /*
> + * This will used for virtual ptp kvm clock. three
^ be? ^ T
[...]
MBR, Sergei
_______________________________________________
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/3] memory: samsung: exynos5422-dmc: Add support for interrupt from performance counters
From: Krzysztof Kozlowski @ 2019-09-27 9:19 UTC (permalink / raw)
To: Lukasz Luba
Cc: mark.rutland, devicetree, willy.mh.wolff.ml, linux-samsung-soc,
b.zolnierkie, linux-pm, linux-kernel, robh+dt, cw00.choi,
kyungmin.park, kgene, myungjoo.ham, s.nawrocki, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190925161813.21117-4-l.luba@partner.samsung.com>
On Wed, Sep 25, 2019 at 06:18:13PM +0200, Lukasz Luba wrote:
> Introduce a new interrupt driven mechanism for managing speed of the
> memory controller. The interrupts are generated due to performance
> counters overflow. The performance counters might track memory reads,
> writes, transfers, page misses, etc. In the basic algorithm tracking
> read transfers and calculating memory pressure should be enough to
> skip polling mode in devfreq.
>
> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> ---
> drivers/memory/samsung/exynos5422-dmc.c | 297 ++++++++++++++++++++++--
> 1 file changed, 272 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/memory/samsung/exynos5422-dmc.c b/drivers/memory/samsung/exynos5422-dmc.c
> index 0fe5f2186139..86e1844b97ef 100644
> --- a/drivers/memory/samsung/exynos5422-dmc.c
> +++ b/drivers/memory/samsung/exynos5422-dmc.c
> @@ -8,6 +8,7 @@
> #include <linux/devfreq.h>
> #include <linux/devfreq-event.h>
> #include <linux/device.h>
> +#include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/mfd/syscon.h>
> #include <linux/module.h>
> @@ -35,6 +36,29 @@
> #define USE_BPLL_TIMINGS (0)
> #define EXYNOS5_AREF_NORMAL (0x2e)
>
> +#define DREX_PPCCLKCON (0x0130)
> +#define DREX_PEREV2CONFIG (0x013c)
> +#define DREX_PMNC_PPC (0xE000)
> +#define DREX_CNTENS_PPC (0xE010)
> +#define DREX_CNTENC_PPC (0xE020)
> +#define DREX_INTENS_PPC (0xE030)
> +#define DREX_INTENC_PPC (0xE040)
> +#define DREX_FLAG_PPC (0xE050)
> +#define DREX_PMCNT2_PPC (0xE130)
> +
> +#define CC_RESET BIT(2)
> +#define PPC_COUNTER_RESET BIT(1)
> +#define PPC_ENABLE BIT(0)
> +#define PEREV_CLK_EN BIT(0)
> +#define PERF_CNT2 BIT(2)
> +#define PERF_CCNT BIT(31)
Describe to which registers these bitfields are applicable.
> +
> +#define READ_TRANSFER_CH0 (0x6d)
> +#define READ_TRANSFER_CH1 (0x6f)
The same. Otherwise they all look like some generic constants which is
not true.
> +
> +#define PERF_COUNTER_START_VALUE 0xff000000
> +#define PERF_EVENT_UP_DOWN_THRESHOLD 900000000ULL
> +
> /**
> * struct dmc_opp_table - Operating level desciption
> *
> @@ -85,6 +109,9 @@ struct exynos5_dmc {
> struct clk *mout_mx_mspll_ccore_phy;
> struct devfreq_event_dev **counter;
> int num_counters;
> + u64 last_overflow_ts[2];
> + unsigned long load, total;
One member per line. This decreases readability.
> + bool in_irq_mode;
> };
>
> #define TIMING_FIELD(t_name, t_bit_beg, t_bit_end) \
> @@ -653,6 +680,167 @@ static int exynos5_counters_get(struct exynos5_dmc *dmc,
> return 0;
> }
>
> +/**
> + * exynos5_dmc_start_perf_events() - Setup and start performance event counters
> + * @dmc: device for which the counters are going to be checked
> + * @beg_value: initial value for the counter
> + *
> + * Function which enables needed counters, interrupts and sets initial values
> + * then starts the counters.
> + */
> +static void exynos5_dmc_start_perf_events(struct exynos5_dmc *dmc,
> + u32 beg_value)
> +{
> + /* Enable interrupts for counter 2 */
> + writel(PERF_CNT2, dmc->base_drexi0 + DREX_INTENS_PPC);
> + writel(PERF_CNT2, dmc->base_drexi1 + DREX_INTENS_PPC);
Blank line.
> + /* Enable counter 2 and CCNT */
> + writel(PERF_CNT2 | PERF_CCNT, dmc->base_drexi0 + DREX_CNTENS_PPC);
> + writel(PERF_CNT2 | PERF_CCNT, dmc->base_drexi1 + DREX_CNTENS_PPC);
Blank line.
> + /* Clear overflow flag for all counters */
> + writel(PERF_CNT2 | PERF_CCNT, dmc->base_drexi0 + DREX_FLAG_PPC);
> + writel(PERF_CNT2 | PERF_CCNT, dmc->base_drexi1 + DREX_FLAG_PPC);
Blank line.
> + /* Reset all counters */
> + writel(CC_RESET | PPC_COUNTER_RESET, dmc->base_drexi0 + DREX_PMNC_PPC);
> + writel(CC_RESET | PPC_COUNTER_RESET, dmc->base_drexi1 + DREX_PMNC_PPC);
Blank line.
> + /*
> + * Set start value for the counters, the number of samples that
> + * will be gathered is calculated as: 0xffffffff - beg_value
> + */
> + writel(beg_value, dmc->base_drexi0 + DREX_PMCNT2_PPC);
> + writel(beg_value, dmc->base_drexi1 + DREX_PMCNT2_PPC);
Blank line.
> + /* Start all counters */
> + writel(PPC_ENABLE, dmc->base_drexi0 + DREX_PMNC_PPC);
> + writel(PPC_ENABLE, dmc->base_drexi1 + DREX_PMNC_PPC);
> +}
> +
> +/**
> + * exynos5_dmc_perf_events_calc() - Calculate utilization
> + * @dmc: device for which the counters are going to be checked
> + * @diff_ts: time between last interrupt and current one
> + *
> + * Function which calculates needed utilization for the devfreq governor.
> + * It prepares values for 'busy_time' and 'total_time' based on elapsed time
> + * between interrupts, which approximates utilization.
> + */
> +static void exynos5_dmc_perf_events_calc(struct exynos5_dmc *dmc, u64 diff_ts)
> +{
> + /*
> + * This is a simple algorithm for managing traffic on DMC.
> + * When there is almost no load the counters overflow every 4s,
> + * no mater the DMC frequency.
> + * The high load might be approximated using linear function.
> + * Knowing that, simple calculation can provide 'busy_time' and
> + * 'total_time' to the devfreq governor which picks up target
> + * frequency.
> + * We want a fast ramp up and slow decay in frequency change function.
> + */
> + if (diff_ts < PERF_EVENT_UP_DOWN_THRESHOLD) {
> + /*
> + * Set higher utilization for the simple_ondemand governor.
> + * The governor should increase the frequency of the DMC.
> + */
> + dmc->load = 70;
> + dmc->total = 100;
> + } else {
> + /*
> + * Set low utilization for the simple_ondemand governor.
> + * The governor should decrease the frequency of the DMC.
> + */
> + dmc->load = 35;
> + dmc->total = 100;
> + }
> +
> + dev_dbg(dmc->dev, "diff_ts=%llu\n", diff_ts);
> +}
> +
> +/**
> + * exynos5_dmc_perf_events_check() - Checks the status of the counters
> + * @dmc: device for which the counters are going to be checked
> + *
> + * Function which is called from threaded IRQ to check the counters state
> + * and to call approximation for the needed utilization.
> + */
> +static void exynos5_dmc_perf_events_check(struct exynos5_dmc *dmc)
> +{
> + u32 val;
> + u64 diff_ts, ts;
> +
> + ts = ktime_get_ns();
> +
> + /* Stop all counters */
> + writel(0, dmc->base_drexi0 + DREX_PMNC_PPC);
> + writel(0, dmc->base_drexi1 + DREX_PMNC_PPC);
> +
> + /* Check the source in interrupt flag registers (which channel) */
> + val = readl(dmc->base_drexi0 + DREX_FLAG_PPC);
> + if (val) {
> + diff_ts = ts - dmc->last_overflow_ts[0];
> + dmc->last_overflow_ts[0] = ts;
> + dev_dbg(dmc->dev, "drex0 0xE050 val= 0x%08x\n", val);
> + } else {
> + val = readl(dmc->base_drexi1 + DREX_FLAG_PPC);
> + diff_ts = ts - dmc->last_overflow_ts[1];
> + dmc->last_overflow_ts[1] = ts;
> + dev_dbg(dmc->dev, "drex1 0xE050 val= 0x%08x\n", val);
> + }
> +
> + exynos5_dmc_perf_events_calc(dmc, diff_ts);
> +
> + exynos5_dmc_start_perf_events(dmc, PERF_COUNTER_START_VALUE);
> +}
> +
> +/**
> + * exynos5_dmc_enable_perf_events() - Enable performance events
> + * @dmc: device for which the counters are going to be checked
> + *
> + * Function which is setup needed environment and enables counters.
> + */
> +static void exynos5_dmc_enable_perf_events(struct exynos5_dmc *dmc)
> +{
> + u64 ts;
> +
> + /* Enable Performance Event Clock */
> + writel(PEREV_CLK_EN, dmc->base_drexi0 + DREX_PPCCLKCON);
> + writel(PEREV_CLK_EN, dmc->base_drexi1 + DREX_PPCCLKCON);
> +
> + /* Select read transfers as performance event2 */
> + writel(READ_TRANSFER_CH0, dmc->base_drexi0 + DREX_PEREV2CONFIG);
> + writel(READ_TRANSFER_CH1, dmc->base_drexi1 + DREX_PEREV2CONFIG);
> +
> + dmc->in_irq_mode = 1;
Move this outside, to the probe. Logically it belongs there.
> +
> + ts = ktime_get_ns();
> + dmc->last_overflow_ts[0] = ts;
> + dmc->last_overflow_ts[1] = ts;
> +
> + /* Devfreq shouldn't be faster than initialization, play safe though. */
> + dmc->load = 99;
> + dmc->total = 100;
> +}
> +
> +/**
> + * exynos5_dmc_disable_perf_events() - Disable performance events
> + * @dmc: device for which the counters are going to be checked
> + *
> + * Function which stops, disables performance event counters and interrupts.
> + */
> +static void exynos5_dmc_disable_perf_events(struct exynos5_dmc *dmc)
> +{
> + /* Stop all counters */
> + writel(0, dmc->base_drexi0 + DREX_PMNC_PPC);
> + writel(0, dmc->base_drexi1 + DREX_PMNC_PPC);
Blank line here and later.
> + /* Disable interrupts for counter 2 */
> + writel(PERF_CNT2, dmc->base_drexi0 + DREX_INTENC_PPC);
> + writel(PERF_CNT2, dmc->base_drexi1 + DREX_INTENC_PPC);
> + /* Disable counter 2 and CCNT */
> + writel(PERF_CNT2 | PERF_CCNT, dmc->base_drexi0 + DREX_CNTENC_PPC);
> + writel(PERF_CNT2 | PERF_CCNT, dmc->base_drexi1 + DREX_CNTENC_PPC);
> + /* Clear overflow flag for all counters */
> + writel(PERF_CNT2 | PERF_CCNT, dmc->base_drexi0 + DREX_FLAG_PPC);
> + writel(PERF_CNT2 | PERF_CCNT, dmc->base_drexi1 + DREX_FLAG_PPC);
> +}
> +
> /**
> * exynos5_dmc_get_status() - Read current DMC performance statistics.
> * @dev: device for which the statistics are requested
> @@ -669,18 +857,24 @@ static int exynos5_dmc_get_status(struct device *dev,
> unsigned long load, total;
> int ret;
>
> - ret = exynos5_counters_get(dmc, &load, &total);
> - if (ret < 0)
> - return -EINVAL;
> + if (dmc->in_irq_mode) {
> + stat->current_frequency = dmc->curr_rate;
> + stat->busy_time = dmc->load;
> + stat->total_time = dmc->total;
> + } else {
> + ret = exynos5_counters_get(dmc, &load, &total);
> + if (ret < 0)
> + return -EINVAL;
>
> - /* To protect from overflow in calculation ratios, divide by 1024 */
> - stat->busy_time = load >> 10;
> - stat->total_time = total >> 10;
> + /* To protect from overflow, divide by 1024 */
> + stat->busy_time = load >> 10;
> + stat->total_time = total >> 10;
>
> - ret = exynos5_counters_set_event(dmc);
> - if (ret < 0) {
> - dev_err(dev, "could not set event counter\n");
> - return ret;
> + ret = exynos5_counters_set_event(dmc);
> + if (ret < 0) {
> + dev_err(dev, "could not set event counter\n");
> + return ret;
> + }
> }
>
> return 0;
> @@ -712,7 +906,6 @@ static int exynos5_dmc_get_cur_freq(struct device *dev, unsigned long *freq)
> * It provides to the devfreq framework needed functions and polling period.
> */
> static struct devfreq_dev_profile exynos5_dmc_df_profile = {
> - .polling_ms = 500,
> .target = exynos5_dmc_target,
> .get_dev_status = exynos5_dmc_get_status,
> .get_cur_freq = exynos5_dmc_get_cur_freq,
> @@ -1108,6 +1301,26 @@ static inline int exynos5_dmc_set_pause_on_switching(struct exynos5_dmc *dmc)
> return 0;
> }
>
> +static irqreturn_t dmc_irq_thread(int irq, void *priv)
> +{
> + int res;
> + struct exynos5_dmc *dmc = priv;
> +
> + dev_dbg(dmc->dev, "irq thread handler\n");
Skip a debug in thread handler for memory. It can pollute your log (I
guess depending on workload).
> +
> + mutex_lock(&dmc->df->lock);
> +
> + exynos5_dmc_perf_events_check(dmc);
> +
> + res = update_devfreq(dmc->df);
> + if (res)
> + dev_err(dmc->dev, "devfreq failed with %d\n", res);
dev_warn()
> +
> + mutex_unlock(&dmc->df->lock);
> +
> + return IRQ_HANDLED;
> +}
> +
> /**
> * exynos5_dmc_probe() - Probe function for the DMC driver
> * @pdev: platform device for which the driver is going to be initialized
> @@ -1125,6 +1338,7 @@ static int exynos5_dmc_probe(struct platform_device *pdev)
> struct device_node *np = dev->of_node;
> struct exynos5_dmc *dmc;
> struct resource *res;
> + int irq;
>
> dmc = devm_kzalloc(dev, sizeof(*dmc), GFP_KERNEL);
> if (!dmc)
> @@ -1172,24 +1386,48 @@ static int exynos5_dmc_probe(struct platform_device *pdev)
> goto remove_clocks;
> }
>
> - ret = exynos5_performance_counters_init(dmc);
> - if (ret) {
> - dev_warn(dev, "couldn't probe performance counters\n");
> - goto remove_clocks;
> - }
> -
> ret = exynos5_dmc_set_pause_on_switching(dmc);
> if (ret) {
> dev_warn(dev, "couldn't get access to PAUSE register\n");
> goto err_devfreq_add;
This is wrong now, I think.
> }
>
> - /*
> - * Setup default thresholds for the devfreq governor.
> - * The values are chosen based on experiments.
> - */
> - dmc->gov_data.upthreshold = 30;
> - dmc->gov_data.downdifferential = 5;
> + /* There is two modes in which the driver works: polling or IRQ */
> + irq = platform_get_irq(pdev, 0);
You need to document it in bindings.
> + if (irq < 0) {
> + ret = exynos5_performance_counters_init(dmc);
> + if (ret) {
> + dev_warn(dev, "couldn't probe performance counters\n");
> + goto remove_clocks;
Weird, previous error jump goes to err_devfreq_add. This goes to error
label which is narrower (less to cleanup).
Best regards,
Krzysztof
> + }
> +
> + /*
> + * Setup default thresholds for the devfreq governor.
> + * The values are chosen based on experiments.
> + */
> + dmc->gov_data.upthreshold = 30;
> + dmc->gov_data.downdifferential = 5;
> +
> + exynos5_dmc_df_profile.polling_ms = 500;
> + } else {
> + ret = devm_request_threaded_irq(dev, irq, NULL,
> + dmc_irq_thread, IRQF_ONESHOT,
> + dev_name(dev), dmc);
> + if (ret) {
> + dev_err(dev, "couldn't grab IRQ\n");
> + goto remove_clocks;
> + }
> +
> + /*
> + * Setup default thresholds for the devfreq governor.
> + * The values are chosen based on experiments.
> + */
> + dmc->gov_data.upthreshold = 55;
> + dmc->gov_data.downdifferential = 5;
> +
> + exynos5_dmc_enable_perf_events(dmc);
> + }
> +
>
> dmc->df = devm_devfreq_add_device(dev, &exynos5_dmc_df_profile,
> DEVFREQ_GOV_SIMPLE_ONDEMAND,
> @@ -1200,12 +1438,18 @@ static int exynos5_dmc_probe(struct platform_device *pdev)
> goto err_devfreq_add;
> }
>
> + if (dmc->in_irq_mode)
> + exynos5_dmc_start_perf_events(dmc, PERF_COUNTER_START_VALUE);
> +
> dev_info(dev, "DMC initialized\n");
>
> return 0;
>
> err_devfreq_add:
> - exynos5_counters_disable_edev(dmc);
> + if (dmc->in_irq_mode)
> + exynos5_dmc_disable_perf_events(dmc);
> + else
> + exynos5_counters_disable_edev(dmc);
> remove_clocks:
> clk_disable_unprepare(dmc->mout_bpll);
> clk_disable_unprepare(dmc->fout_bpll);
> @@ -1225,7 +1469,10 @@ static int exynos5_dmc_remove(struct platform_device *pdev)
> {
> struct exynos5_dmc *dmc = dev_get_drvdata(&pdev->dev);
>
> - exynos5_counters_disable_edev(dmc);
> + if (dmc->in_irq_mode)
> + exynos5_dmc_disable_perf_events(dmc);
> + else
> + exynos5_counters_disable_edev(dmc);
>
> clk_disable_unprepare(dmc->mout_bpll);
> clk_disable_unprepare(dmc->fout_bpll);
> --
> 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 2/3] dt-bindings: arm: fsl: add compatible string for Kobo Clara HD
From: Marco Felsch @ 2019-09-27 9:19 UTC (permalink / raw)
To: Andreas Kemnade
Cc: mark.rutland, marex, devicetree, andrew.smirnov, shawnguo,
s.hauer, angus, linux-kernel, j.neuschaefer, robh+dt, linux-imx,
kernel, manivannan.sadhasivam, Discussions about the Letux Kernel,
festevam, linux-arm-kernel
In-Reply-To: <20190927061423.17278-3-andreas@kemnade.info>
Hi Andreas,
On 19-09-27 08:14, Andreas Kemnade wrote:
> This adds a compatible string fro the Kobo Clara HD eBook reader.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
Just a nitpick, this should be patch number 1.
Regards,
Marco
> Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 7294ac36f4c0..afa3bfeca0c0 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -148,6 +148,7 @@ properties:
> items:
> - enum:
> - fsl,imx6sll-evk
> + - kobo,clarahd
> - const: fsl,imx6sll
>
> - description: i.MX6SX based Boards
> --
> 2.20.1
>
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
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 02/11] of: Make of_dma_get_range() private
From: Geert Uytterhoeven @ 2019-09-27 9:18 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Arnd Bergmann, Frank Rowand, linux-pci,
Linux Kernel Mailing List, Marek Vasut, Lorenzo Pieralisi,
Oza Pawandeep, Linux ARM, Simon Horman, Geert Uytterhoeven,
Robin Murphy, Nicolas Saenz Julienne, Stefan Wahren
In-Reply-To: <20190927002455.13169-3-robh@kernel.org>
On Fri, Sep 27, 2019 at 2:25 AM Rob Herring <robh@kernel.org> wrote:
> of_dma_get_range() is only used within the DT core code, so remove the
> export and move the header declaration to the private header.
>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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 01/11] of: Remove unused of_find_matching_node_by_address()
From: Geert Uytterhoeven @ 2019-09-27 9:17 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Arnd Bergmann, Frank Rowand, linux-pci,
Linux Kernel Mailing List, Marek Vasut, Lorenzo Pieralisi,
Oza Pawandeep, Linux ARM, Simon Horman, Geert Uytterhoeven,
Robin Murphy, Nicolas Saenz Julienne, Stefan Wahren
In-Reply-To: <20190927002455.13169-2-robh@kernel.org>
On Fri, Sep 27, 2019 at 2:25 AM Rob Herring <robh@kernel.org> wrote:
> of_find_matching_node_by_address() is unused, so remove it.
>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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 03/11] of: address: Report of_dma_get_range() errors meaningfully
From: Geert Uytterhoeven @ 2019-09-27 9:15 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Arnd Bergmann, Frank Rowand, linux-pci,
Linux Kernel Mailing List, Marek Vasut, Lorenzo Pieralisi,
Oza Pawandeep, Linux ARM, Simon Horman, Geert Uytterhoeven,
Robin Murphy, Nicolas Saenz Julienne, Stefan Wahren
In-Reply-To: <20190927002455.13169-4-robh@kernel.org>
On Fri, Sep 27, 2019 at 2:25 AM Rob Herring <robh@kernel.org> wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> If we failed to translate a DMA address, at least show the offending
> address rather than the uninitialised contents of the destination
> argument.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> drivers/of/address.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8e354d12fb04..53d2656c2269 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -955,8 +955,8 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
> dmaaddr = of_read_number(ranges, naddr);
> *paddr = of_translate_dma_address(np, ranges);
> if (*paddr == OF_BAD_ADDR) {
> - pr_err("translation of DMA address(%pad) to CPU address failed node(%pOF)\n",
Yeah, the %pad was wrong on 32-bit without CONFIG_PHYS_ADDR_T_64BIT.
> - dma_addr, np);
> + pr_err("translation of DMA address(%llx) to CPU address failed node(%pOF)\n",
> + dmaaddr, np);
> ret = -EINVAL;
> goto out;
> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] firmware: imx: Skip return value check for some special SCU firmware APIs
From: Marco Felsch @ 2019-09-27 9:06 UTC (permalink / raw)
To: Anson Huang
Cc: Aisheng Dong, shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
Leonard Crestez, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB3PR0402MB391675F9BF6FCA315B124BEBF5810@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Hi Anson, Leonard,
On 19-09-27 01:20, Anson Huang wrote:
> Hi, Leonard
>
> > On 2019-09-26 1:06 PM, Marco Felsch wrote:
> > > On 19-09-26 08:03, Anson Huang wrote:
> > >>> On 19-09-25 18:07, Anson Huang wrote:
> > >>>> The SCU firmware does NOT always have return value stored in
> > >>>> message header's function element even the API has response data,
> > >>>> those special APIs are defined as void function in SCU firmware, so
> > >>>> they should be treated as return success always.
> > >>>>
> > >>>> +static const struct imx_sc_rpc_msg whitelist[] = {
> > >>>> + { .svc = IMX_SC_RPC_SVC_MISC, .func =
> > >>> IMX_SC_MISC_FUNC_UNIQUE_ID },
> > >>>> + { .svc = IMX_SC_RPC_SVC_MISC, .func =
> > >>>> +IMX_SC_MISC_FUNC_GET_BUTTON_STATUS }, };
> > >>>
> > >>> Is this going to be extended in the near future? I see some upcoming
> > >>> problems here if someone uses a different scu-fw<->kernel
> > >>> combination as nxp would suggest.
> > >>
> > >> Could be, but I checked the current APIs, ONLY these 2 will be used
> > >> in Linux kernel, so I ONLY add these 2 APIs for now.
> > >
> > > Okay.
> > >
> > >> However, after rethink, maybe we should add another imx_sc_rpc API
> > >> for those special APIs? To avoid checking it for all the APIs called which
> > may impact some performance.
> > >> Still under discussion, if you have better idea, please advise, thanks!
> >
> > My suggestion is to refactor the code and add a new API for the this "no
> > error value" convention. Internally they can call a common function with
> > flags.
>
> If I understand your point correctly, that means the loop check of whether the API
> is with "no error value" for every API still NOT be skipped, it is just refactoring the code,
> right?
How makes this things easier?
> > > Adding a special api shouldn't be the right fix. Imagine if someone
> > > (not a nxp-developer) wants to add a new driver. How could he be
> > > expected to know which api he should use. The better abbroach would be
> > > to fix the scu-fw instead of adding quirks..
>
> Yes, fixing SCU FW is the best solution, but we have talked to SCU FW owner, the SCU
> FW released has been finalized, so the API implementation can NOT be changed, but
> they will pay attention to this issue for new added APIs later. That means the number
> of APIs having this issue a very limited.
This means those APIs which already have this bug will not be fixed?
IMHO this sounds a bit weird since this is a changeable peace of code ;)
> > Right now developers who want to make SCFW calls in upstream need to
> > define the message struct in their driver based on protocol documentation.
> > This includes:
> >
> > * Binary layout of the message (a packed struct)
> > * If the message has a response (already a bool flag)
> > * If an error code is returned (this patch adds support for it)
Why should I specify if a error code is returned?
Regards,
Marco
> > Since callers are already exposed to the binary protocol exposing them to
> > minor quirks of the calling convention also seems reasonable. Having the
> > low-level IPC code peek at message IDs seems like a hack; this belong at a
> > slightly higher level.
>
> A little confused, so what you suggested is to add make the imx_scu_call_rpc()
> becomes the "slightly higher level" API, then in this API, check the message IDs
> to decide whether to return error value, then calls a new API which will have
> the low-level IPC code, the this new API will have a flag passed from imx_scu_call_rpc()
> function, am I right?
>
> Anson
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
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 5/5] arm64: Enable and document ARM errata 1319367 and 1319537
From: Catalin Marinas @ 2019-09-27 9:03 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, kvm, Suzuki K Poulose, James Morse, Julien Thierry,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190925111941.88103-6-maz@kernel.org>
On Wed, Sep 25, 2019 at 12:19:41PM +0100, Marc Zyngier wrote:
> Now that everything is in place, let's get the ball rolling
> by allowing the corresponding config option to be selected.
> Also add the required information to silicon_arrata.rst.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.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 1/5] arm64: Add ARM64_WORKAROUND_1319367 for all A57 and A72 versions
From: Catalin Marinas @ 2019-09-27 9:03 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, kvm, Suzuki K Poulose, James Morse, Julien Thierry,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190925111941.88103-2-maz@kernel.org>
On Wed, Sep 25, 2019 at 12:19:37PM +0100, Marc Zyngier wrote:
> Rework the EL2 vector hardening that is only selected for A57 and A72
> so that the table can also be used for ARM64_WORKAROUND_1319367.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
--
Catalin
_______________________________________________
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/3] ARM: dts: exynos: Add interrupt to DMC controller in Exynos5422
From: Krzysztof Kozlowski @ 2019-09-27 8:53 UTC (permalink / raw)
To: Lukasz Luba
Cc: mark.rutland, devicetree, willy.mh.wolff.ml, linux-samsung-soc,
b.zolnierkie, linux-pm, linux-kernel, robh+dt, cw00.choi,
kyungmin.park, kgene, myungjoo.ham, s.nawrocki, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190925161813.21117-2-l.luba@partner.samsung.com>
On Wed, Sep 25, 2019 at 06:18:11PM +0200, Lukasz Luba wrote:
> Add interrupt to Dynamic Memory Controller in Exynos5422 and Odroid
> XU3-family boards. It will be used instead of devfreq polling mode
> governor. The interrupt is connected to performance counters private
> for DMC, which might track utilisation of the memory channels.
>
> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index ac49373baae7..72738e620d11 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -240,6 +240,8 @@
> dmc: memory-controller@10c20000 {
> compatible = "samsung,exynos5422-dmc";
> reg = <0x10c20000 0x100>, <0x10c30000 0x100>;
> + interrupt-parent = <&combiner>;
> + interrupts = <16 0>;
You register DMC for DREX0 and DREX1 but take only DREX0 interrupt. Why
skipping second?
Best regards,
Krzysztof
> clocks = <&clock CLK_FOUT_SPLL>,
> <&clock CLK_MOUT_SCLK_SPLL>,
> <&clock CLK_FF_DOUT_SPLL2>,
> --
> 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
* [PATCH] ARM: dts: stm32: Enable high resolution timer
From: Benjamin Gaignard @ 2019-09-27 8:48 UTC (permalink / raw)
To: alexandre.torgue, robh+dt, mark.rutland
Cc: Benjamin Gaignard, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel
Adding always-on makes arm arch_timer claim to be an high resolution timer.
That is possible because power mode won't stop clocking the timer.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
arch/arm/boot/dts/stm32mp157c.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index 9b11654a0a39..74f64745d60d 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -50,6 +50,7 @@
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
interrupt-parent = <&intc>;
+ always-on;
};
clocks {
--
2.15.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
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