* [PATCH v7 4/7] rtc: mt6397: add compatible for mt6323
From: Frank Wunderlich @ 2019-09-10 7:04 UTC (permalink / raw)
To: linux-mediatek
Cc: linux-rtc, devicetree, Alexandre Belloni, Sean Wang,
Alessandro Zummo, linux-pm, Frank Wunderlich, Josef Friedl,
linux-kernel, Tianping Fang, Rob Herring, Sebastian Reichel,
Matthias Brugger, Mark Rutland, Eddie Huang, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190910070446.639-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
use mt6397 rtc driver also for mt6323 but with different
base/size see "mfd: mt6323: add mt6323 rtc+pwrc"
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
changes since v6: none
changes since v5: none
changes since v4: none
changes since v3: moved (was part 5)
changes since v2: splitted this from v2.3 suggested-by Alexandre Belloni
---
drivers/rtc/rtc-mt6397.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index 9370b7fc9f81..21cd9cc8b4c7 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -325,6 +325,7 @@ static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_rtc_suspend,
mt6397_rtc_resume);
static const struct of_device_id mt6397_rtc_of_match[] = {
+ { .compatible = "mediatek,mt6323-rtc", },
{ .compatible = "mediatek,mt6397-rtc", },
{ }
};
--
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 related
* [PATCH v7 0/7] implement poweroff for mt6323 / bpi-r2
From: Frank Wunderlich @ 2019-09-10 7:04 UTC (permalink / raw)
To: linux-mediatek
Cc: linux-rtc, devicetree, Alexandre Belloni, Sean Wang,
Alessandro Zummo, linux-pm, Frank Wunderlich, Josef Friedl,
linux-kernel, Tianping Fang, Rob Herring, Sebastian Reichel,
Matthias Brugger, Mark Rutland, Eddie Huang, Lee Jones,
linux-arm-kernel
mainline-driver does not support mt6323
this series makes some cleanup to mt6397-rtc-driver, adds mt6323 and
implement power-controller on it.
tested on bananapi-r2
Original Patch from Josef Friedl
changes since v6:
- rebased on 5.3-rc8
- post only 7 Patches because 6 are already applied to next
- update copyright in "move some common definitions into rtc.h"
changes since v5:
- splitted part 1 to separate changes and additions not related to pwrc
- move mfd/mt6397/core.h from v4.8 in separate patch "add mutex include"
- changed recipients (moved from To to Cc, removed committers)
changes since v4:
- relative path in part 1+2
- drop change of copyright-year in part 5
changes since v3:
- moved SOB in 2/10 and 9/10
- moved part 5 to 6 to be near driver-change
- changehistory of patches below ---
changes since v2:
- Splitted some parts and rebased on 5.3-rc2:
v2.1 dt-bindings: add powercontroller – try to make better subject
v2.2 separate rtc-mt6397.txt (suggested by Alexandre Belloni)
add missing commit-message (suggested by Matthias Brugger)
v2.3 fix alloc after IRQ (suggested by Alexandre Belloni)
new compatible (splitting suggested by Alexandre Belloni)
needed due to different rtc-base/size see #7
v2.4 simplifications (Define-res-macros)
add mt6323 rtc+pwrc
v2.5 add poweroff-driver (no change)
v2.6 MAINTAINERS (no change)
v2.7 DTS-Changes (no change)
Josef Friedl (7):
dt-bindings: rtc: mediatek: add missing mt6397 rtc
rtc: mt6397: move some common definitions into rtc.h
rtc: mt6397: improvements of rtc driver
rtc: mt6397: add compatible for mt6323
power: reset: add driver for mt6323 poweroff
MAINTAINERS: add Mediatek shutdown drivers
arm: dts: mt6323: add keys, power-controller, rtc and codec
.../devicetree/bindings/rtc/rtc-mt6397.txt | 29 +++++
MAINTAINERS | 7 ++
arch/arm/boot/dts/mt6323.dtsi | 27 +++++
drivers/power/reset/Kconfig | 10 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/mt6323-poweroff.c | 97 ++++++++++++++++
drivers/rtc/rtc-mt6397.c | 107 ++++--------------
include/linux/mfd/mt6397/rtc.h | 71 ++++++++++++
8 files changed, 263 insertions(+), 86 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
create mode 100644 drivers/power/reset/mt6323-poweroff.c
create mode 100644 include/linux/mfd/mt6397/rtc.h
--
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 v7 3/7] rtc: mt6397: improvements of rtc driver
From: Frank Wunderlich @ 2019-09-10 7:04 UTC (permalink / raw)
To: linux-mediatek
Cc: linux-rtc, devicetree, Alexandre Belloni, Sean Wang,
Alessandro Zummo, linux-pm, Frank Wunderlich, Josef Friedl,
linux-kernel, Tianping Fang, Rob Herring, Sebastian Reichel,
Matthias Brugger, Mark Rutland, Eddie Huang, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190910070446.639-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
- use regmap_read_poll_timeout to drop while-loop
- use devm-api to drop remove-callback
Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
changes since v6: none
changes since v5: none
changes since v4: none
changes since v3: none
changes since v2:
- fix allocation after irq-request
- compatible for mt6323 in separate commit => part 5
---
drivers/rtc/rtc-mt6397.c | 51 +++++++++++++++-------------------------
1 file changed, 19 insertions(+), 32 deletions(-)
diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index c08ee5edf865..9370b7fc9f81 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -4,16 +4,19 @@
* Author: Tianping.Fang <tianping.fang@mediatek.com>
*/
-#include <linux/delay.h>
-#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/mfd/mt6397/core.h>
#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/rtc.h>
#include <linux/mfd/mt6397/rtc.h>
+#include <linux/mod_devicetable.h>
static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
{
- unsigned long timeout = jiffies + HZ;
int ret;
u32 data;
@@ -21,19 +24,13 @@ static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
if (ret < 0)
return ret;
- while (1) {
- ret = regmap_read(rtc->regmap, rtc->addr_base + RTC_BBPU,
- &data);
- if (ret < 0)
- break;
- if (!(data & RTC_BBPU_CBUSY))
- break;
- if (time_after(jiffies, timeout)) {
- ret = -ETIMEDOUT;
- break;
- }
- cpu_relax();
- }
+ ret = regmap_read_poll_timeout(rtc->regmap,
+ rtc->addr_base + RTC_BBPU, data,
+ !(data & RTC_BBPU_CBUSY),
+ MTK_RTC_POLL_DELAY_US,
+ MTK_RTC_POLL_TIMEOUT);
+ if (ret < 0)
+ dev_err(rtc->dev, "failed to write WRTGE: %d\n", ret);
return ret;
}
@@ -266,19 +263,19 @@ static int mtk_rtc_probe(struct platform_device *pdev)
return rtc->irq;
rtc->regmap = mt6397_chip->regmap;
- rtc->dev = &pdev->dev;
mutex_init(&rtc->lock);
platform_set_drvdata(pdev, rtc);
- rtc->rtc_dev = devm_rtc_allocate_device(rtc->dev);
+ rtc->rtc_dev = devm_rtc_allocate_device(&pdev->dev);
if (IS_ERR(rtc->rtc_dev))
return PTR_ERR(rtc->rtc_dev);
- ret = request_threaded_irq(rtc->irq, NULL,
- mtk_rtc_irq_handler_thread,
- IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
- "mt6397-rtc", rtc);
+ ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
+ mtk_rtc_irq_handler_thread,
+ IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
+ "mt6397-rtc", rtc);
+
if (ret) {
dev_err(&pdev->dev, "Failed to request alarm IRQ: %d: %d\n",
rtc->irq, ret);
@@ -302,15 +299,6 @@ static int mtk_rtc_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_rtc_remove(struct platform_device *pdev)
-{
- struct mt6397_rtc *rtc = platform_get_drvdata(pdev);
-
- free_irq(rtc->irq, rtc);
-
- return 0;
-}
-
#ifdef CONFIG_PM_SLEEP
static int mt6397_rtc_suspend(struct device *dev)
{
@@ -349,7 +337,6 @@ static struct platform_driver mtk_rtc_driver = {
.pm = &mt6397_pm_ops,
},
.probe = mtk_rtc_probe,
- .remove = mtk_rtc_remove,
};
module_platform_driver(mtk_rtc_driver);
--
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 related
* [PATCH v7 6/7] MAINTAINERS: add Mediatek shutdown drivers
From: Frank Wunderlich @ 2019-09-10 7:04 UTC (permalink / raw)
To: linux-mediatek
Cc: linux-rtc, devicetree, Alexandre Belloni, Sean Wang,
Alessandro Zummo, linux-pm, Frank Wunderlich, Josef Friedl,
linux-kernel, Tianping Fang, Rob Herring, Sebastian Reichel,
Matthias Brugger, Mark Rutland, Eddie Huang, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190910070446.639-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
add Section in MAINTAINERS file for poweroff driver
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
changes since v6: none
changes since v5: none
changes since v4: none
changes since v3: moved SOB
changes since v2: none (=v2 part 6)
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e7a47b5210fd..46d13e845740 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10149,6 +10149,13 @@ S: Maintained
F: drivers/net/dsa/mt7530.*
F: net/dsa/tag_mtk.c
+MEDIATEK BOARD LEVEL SHUTDOWN DRIVERS
+M: Sean Wang <sean.wang@mediatek.com>
+L: linux-pm@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
+F: drivers/power/reset/mt6323-poweroff.c
+
MEDIATEK JPEG DRIVER
M: Rick Chang <rick.chang@mediatek.com>
M: Bin Liu <bin.liu@mediatek.com>
--
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 related
* [PATCH v7 7/7] arm: dts: mt6323: add keys, power-controller, rtc and codec
From: Frank Wunderlich @ 2019-09-10 7:04 UTC (permalink / raw)
To: linux-mediatek
Cc: linux-rtc, devicetree, Alexandre Belloni, Sean Wang,
Alessandro Zummo, linux-pm, Frank Wunderlich, Josef Friedl,
linux-kernel, Tianping Fang, Rob Herring, Sebastian Reichel,
Matthias Brugger, Mark Rutland, Eddie Huang, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190910070446.639-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
support poweroff and power-related keys on bpi-r2
Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v6: none
changes since v5: none
changes since v4: none
changes since v3: none
changes since v2: none (=v2 part 7)
---
arch/arm/boot/dts/mt6323.dtsi | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/mt6323.dtsi b/arch/arm/boot/dts/mt6323.dtsi
index ba397407c1dd..7fda40ab5fe8 100644
--- a/arch/arm/boot/dts/mt6323.dtsi
+++ b/arch/arm/boot/dts/mt6323.dtsi
@@ -238,5 +238,32 @@
regulator-enable-ramp-delay = <216>;
};
};
+
+ mt6323keys: mt6323keys {
+ compatible = "mediatek,mt6323-keys";
+ mediatek,long-press-mode = <1>;
+ power-off-time-sec = <0>;
+
+ power {
+ linux,keycodes = <116>;
+ wakeup-source;
+ };
+
+ home {
+ linux,keycodes = <114>;
+ };
+ };
+
+ codec: mt6397codec {
+ compatible = "mediatek,mt6397-codec";
+ };
+
+ power-controller {
+ compatible = "mediatek,mt6323-pwrc";
+ };
+
+ rtc {
+ compatible = "mediatek,mt6323-rtc";
+ };
};
};
--
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 related
* [PATCH v7 5/7] power: reset: add driver for mt6323 poweroff
From: Frank Wunderlich @ 2019-09-10 7:04 UTC (permalink / raw)
To: linux-mediatek
Cc: linux-rtc, devicetree, Alexandre Belloni, Sean Wang,
Alessandro Zummo, linux-pm, Frank Wunderlich, Josef Friedl,
linux-kernel, Tianping Fang, Rob Herring, Sebastian Reichel,
Matthias Brugger, Mark Rutland, Eddie Huang, Lee Jones,
linux-arm-kernel
In-Reply-To: <20190910070446.639-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
add poweroff driver for mt6323 and make Makefile and Kconfig-Entries
Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
changes since v6: none
changes since v5: split out mfd/mt6397/core.h
changes since v4: none
changes since v3: none
changes since v2: none (=v2 part 5)
---
drivers/power/reset/Kconfig | 10 +++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/mt6323-poweroff.c | 97 +++++++++++++++++++++++++++
3 files changed, 108 insertions(+)
create mode 100644 drivers/power/reset/mt6323-poweroff.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index a564237278ff..c721939767eb 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -140,6 +140,16 @@ config POWER_RESET_LTC2952
This driver supports an external powerdown trigger and board power
down via the LTC2952. Bindings are made in the device tree.
+config POWER_RESET_MT6323
+ bool "MediaTek MT6323 power-off driver"
+ depends on MFD_MT6397
+ help
+ The power-off driver is responsible for externally shutdown down
+ the power of a remote MediaTek SoC MT6323 is connected to through
+ controlling a tiny circuit BBPU inside MT6323 RTC.
+
+ Say Y if you have a board where MT6323 could be found.
+
config POWER_RESET_QNAP
bool "QNAP power-off driver"
depends on OF_GPIO && PLAT_ORION
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 85da3198e4e0..da37f8b851dc 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
+obj-$(CONFIG_POWER_RESET_MT6323) += mt6323-poweroff.o
obj-$(CONFIG_POWER_RESET_QCOM_PON) += qcom-pon.o
obj-$(CONFIG_POWER_RESET_OCELOT_RESET) += ocelot-reset.o
obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
diff --git a/drivers/power/reset/mt6323-poweroff.c b/drivers/power/reset/mt6323-poweroff.c
new file mode 100644
index 000000000000..1caf43d9e46d
--- /dev/null
+++ b/drivers/power/reset/mt6323-poweroff.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Power off through MediaTek PMIC
+ *
+ * Copyright (C) 2018 MediaTek Inc.
+ *
+ * Author: Sean Wang <sean.wang@mediatek.com>
+ *
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/mt6397/core.h>
+#include <linux/mfd/mt6397/rtc.h>
+
+struct mt6323_pwrc {
+ struct device *dev;
+ struct regmap *regmap;
+ u32 base;
+};
+
+static struct mt6323_pwrc *mt_pwrc;
+
+static void mt6323_do_pwroff(void)
+{
+ struct mt6323_pwrc *pwrc = mt_pwrc;
+ unsigned int val;
+ int ret;
+
+ regmap_write(pwrc->regmap, pwrc->base + RTC_BBPU, RTC_BBPU_KEY);
+ regmap_write(pwrc->regmap, pwrc->base + RTC_WRTGR, 1);
+
+ ret = regmap_read_poll_timeout(pwrc->regmap,
+ pwrc->base + RTC_BBPU, val,
+ !(val & RTC_BBPU_CBUSY),
+ MTK_RTC_POLL_DELAY_US,
+ MTK_RTC_POLL_TIMEOUT);
+ if (ret)
+ dev_err(pwrc->dev, "failed to write BBPU: %d\n", ret);
+
+ /* Wait some time until system down, otherwise, notice with a warn */
+ mdelay(1000);
+
+ WARN_ONCE(1, "Unable to power off system\n");
+}
+
+static int mt6323_pwrc_probe(struct platform_device *pdev)
+{
+ struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
+ struct mt6323_pwrc *pwrc;
+ struct resource *res;
+
+ pwrc = devm_kzalloc(&pdev->dev, sizeof(*pwrc), GFP_KERNEL);
+ if (!pwrc)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pwrc->base = res->start;
+ pwrc->regmap = mt6397_chip->regmap;
+ pwrc->dev = &pdev->dev;
+ mt_pwrc = pwrc;
+
+ pm_power_off = &mt6323_do_pwroff;
+
+ return 0;
+}
+
+static int mt6323_pwrc_remove(struct platform_device *pdev)
+{
+ if (pm_power_off == &mt6323_do_pwroff)
+ pm_power_off = NULL;
+
+ return 0;
+}
+
+static const struct of_device_id mt6323_pwrc_dt_match[] = {
+ { .compatible = "mediatek,mt6323-pwrc" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mt6323_pwrc_dt_match);
+
+static struct platform_driver mt6323_pwrc_driver = {
+ .probe = mt6323_pwrc_probe,
+ .remove = mt6323_pwrc_remove,
+ .driver = {
+ .name = "mt6323-pwrc",
+ .of_match_table = mt6323_pwrc_dt_match,
+ },
+};
+
+module_platform_driver(mt6323_pwrc_driver);
+
+MODULE_DESCRIPTION("Poweroff driver for MT6323 PMIC");
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_LICENSE("GPL v2");
--
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 related
* Re: [PATCH v2 06/14] dmaengine: ti: Add cppi5 header for UDMA
From: Grygorii Strashko @ 2019-09-10 7:06 UTC (permalink / raw)
To: Peter Ujfalusi, Vinod Koul
Cc: nm, devicetree, lokeshvutla, j-keerthy, linux-kernel, t-kristo,
tony, robh+dt, ssantosh, dmaengine, dan.j.williams,
linux-arm-kernel
In-Reply-To: <8699f999-7834-a083-2c7b-3ea909b1e011@ti.com>
On 09/09/2019 13:59, Peter Ujfalusi wrote:
>
>
> On 08/09/2019 17.25, Vinod Koul wrote:
>> On 30-07-19, 12:34, Peter Ujfalusi wrote:
>>
>>> +/**
>>> + * Descriptor header, present in all types of descriptors
>>> + */
>>> +struct cppi5_desc_hdr_t {
>>> + u32 pkt_info0; /* Packet info word 0 (n/a in Buffer desc) */
>>> + u32 pkt_info1; /* Packet info word 1 (n/a in Buffer desc) */
>>> + u32 pkt_info2; /* Packet info word 2 Buffer reclamation info */
>>> + u32 src_dst_tag; /* Packet info word 3 (n/a in Buffer desc) */
>>
>> Can we move these comments to kernel-doc style please
>
> Sure, I'll move all struct and enums.
>
>>> +/**
>>> + * cppi5_desc_get_type - get descriptor type
>>> + * @desc_hdr: packet descriptor/TR header
>>> + *
>>> + * Returns descriptor type:
>>> + * CPPI5_INFO0_DESC_TYPE_VAL_HOST
>>> + * CPPI5_INFO0_DESC_TYPE_VAL_MONO
>>> + * CPPI5_INFO0_DESC_TYPE_VAL_TR
>>> + */
>>> +static inline u32 cppi5_desc_get_type(struct cppi5_desc_hdr_t *desc_hdr)
>>> +{
>>> + WARN_ON(!desc_hdr);
>>
>> why WARN_ON and not return error!
>
> these helpers were intended to be as simple as possible.
> I can go through with all of the WARN_ONs and replace them with if()
> pr_warn() and either just return or return with 0.
>
> Would that be acceptable?
>
This should never happens in working system unless there is buggy code.
I think It can be just removed
--
Best regards,
grygorii
_______________________________________________
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 10/14] dmaengine: ti: New driver for K3 UDMA - split#3: alloc/free chan_resources
From: Grygorii Strashko @ 2019-09-10 7:25 UTC (permalink / raw)
To: Peter Ujfalusi, vkoul, robh+dt, nm, ssantosh
Cc: devicetree, lokeshvutla, j-keerthy, linux-kernel, t-kristo, tony,
dmaengine, dan.j.williams, linux-arm-kernel
In-Reply-To: <20190730093450.12664-11-peter.ujfalusi@ti.com>
On 30/07/2019 12:34, Peter Ujfalusi wrote:
> Split patch for review containing: channel rsource allocation and free
> functions.
>
> DMA driver for
> Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)
>
> The UDMA-P is intended to perform similar (but significantly upgraded) functions
> as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
> supports the transmission and reception of various packet types. The UDMA-P is
> architected to facilitate the segmentation and reassembly of SoC DMA data
> structure compliant packets to/from smaller data blocks that are natively
> compatible with the specific requirements of each connected peripheral. Multiple
> Tx and Rx channels are provided within the DMA which allow multiple segmentation
> or reassembly operations to be ongoing. The DMA controller maintains state
> information for each of the channels which allows packet segmentation and
> reassembly operations to be time division multiplexed between channels in order
> to share the underlying DMA hardware. An external DMA scheduler is used to
> control the ordering and rate at which this multiplexing occurs for Transmit
> operations. The ordering and rate of Receive operations is indirectly controlled
> by the order in which blocks are pushed into the DMA on the Rx PSI-L interface.
>
> The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
> channels. Channels in the UDMA-P can be configured to be either Packet-Based or
> Third-Party channels on a channel by channel basis.
>
> The initial driver supports:
> - MEM_TO_MEM (TR mode)
> - DEV_TO_MEM (Packet / TR mode)
> - MEM_TO_DEV (Packet / TR mode)
> - Cyclic (Packet / TR mode)
> - Metadata for descriptors
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> drivers/dma/ti/k3-udma.c | 780 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 780 insertions(+)
>
> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> index 52ccc6d46de9..0de38db03b8d 100644
> --- a/drivers/dma/ti/k3-udma.c
> +++ b/drivers/dma/ti/k3-udma.c
> @@ -1039,6 +1039,786 @@ static irqreturn_t udma_udma_irq_handler(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> +static struct udma_rflow *__udma_reserve_rflow(struct udma_dev *ud,
> + enum udma_tp_level tpl, int id)
> +{
> + DECLARE_BITMAP(tmp, K3_UDMA_MAX_RFLOWS);
> +
> + if (id >= 0) {
> + if (test_bit(id, ud->rflow_map)) {
> + dev_err(ud->dev, "rflow%d is in use\n", id);
> + return ERR_PTR(-ENOENT);
> + }
> + } else {
> + bitmap_or(tmp, ud->rflow_map, ud->rflow_map_reserved,
> + ud->rflow_cnt);
> +
> + id = find_next_zero_bit(tmp, ud->rflow_cnt, ud->rchan_cnt);
> + if (id >= ud->rflow_cnt)
> + return ERR_PTR(-ENOENT);
> + }
> +
> + set_bit(id, ud->rflow_map);
> + return &ud->rflows[id];
> +}
> +
> +#define UDMA_RESERVE_RESOURCE(res) \
> +static struct udma_##res *__udma_reserve_##res(struct udma_dev *ud, \
> + enum udma_tp_level tpl, \
> + int id) \
> +{ \
> + if (id >= 0) { \
> + if (test_bit(id, ud->res##_map)) { \
> + dev_err(ud->dev, "res##%d is in use\n", id); \
> + return ERR_PTR(-ENOENT); \
> + } \
> + } else { \
> + int start; \
> + \
> + if (tpl >= ud->match_data->tpl_levels) \
> + tpl = ud->match_data->tpl_levels - 1; \
> + \
> + start = ud->match_data->level_start_idx[tpl]; \
> + \
> + id = find_next_zero_bit(ud->res##_map, ud->res##_cnt, \
> + start); \
> + if (id == ud->res##_cnt) { \
> + return ERR_PTR(-ENOENT); \
> + } \
> + } \
> + \
> + set_bit(id, ud->res##_map); \
> + return &ud->res##s[id]; \
> +}
> +
> +UDMA_RESERVE_RESOURCE(tchan);
> +UDMA_RESERVE_RESOURCE(rchan);
Personally I'm not a fan of such a big macro, wouldn't be static functions better.
> +
> +static int udma_get_tchan(struct udma_chan *uc)
> +{
> + struct udma_dev *ud = uc->ud;
> +
> + if (uc->tchan) {
> + dev_dbg(ud->dev, "chan%d: already have tchan%d allocated\n",
> + uc->id, uc->tchan->id);
> + return 0;
> + }
> +
> + uc->tchan = __udma_reserve_tchan(ud, uc->channel_tpl, -1);
> + if (IS_ERR(uc->tchan))
> + return PTR_ERR(uc->tchan);
> +
> + return 0;
> +}
> +
[...]
> +
> +static int udma_tisci_channel_config(struct udma_chan *uc)
> +{
> + struct udma_dev *ud = uc->ud;
> + struct udma_tisci_rm *tisci_rm = &ud->tisci_rm;
> + const struct ti_sci_rm_udmap_ops *tisci_ops = tisci_rm->tisci_udmap_ops;
> + struct udma_tchan *tchan = uc->tchan;
> + struct udma_rchan *rchan = uc->rchan;
> + int ret = 0;
> +
> + if (uc->dir == DMA_MEM_TO_MEM) {
> + /* Non synchronized - mem to mem type of transfer */
> + int tc_ring = k3_ringacc_get_ring_id(tchan->tc_ring);
> + struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
> + struct ti_sci_msg_rm_udmap_rx_ch_cfg req_rx = { 0 };
> +
> + req_tx.valid_params =
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_PAUSE_ON_ERR_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_FILT_EINFO_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_FILT_PSWORDS_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CHAN_TYPE_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_SUPR_TDPKT_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_FETCH_SIZE_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CQ_QNUM_VALID;
> +
> + req_tx.nav_id = tisci_rm->tisci_dev_id;
> + req_tx.index = tchan->id;
> + req_tx.tx_pause_on_err = 0;
> + req_tx.tx_filt_einfo = 0;
> + req_tx.tx_filt_pswords = 0;
> + req_tx.tx_chan_type = TI_SCI_RM_UDMAP_CHAN_TYPE_3RDP_BCOPY_PBRR;
> + req_tx.tx_supr_tdpkt = 0;
> + req_tx.tx_fetch_size = sizeof(struct cppi5_desc_hdr_t) >> 2;
> + req_tx.txcq_qnum = tc_ring;
> +
> + ret = tisci_ops->tx_ch_cfg(tisci_rm->tisci, &req_tx);
> + if (ret) {
> + dev_err(ud->dev, "tchan%d cfg failed %d\n",
> + tchan->id, ret);
> + return ret;
> + }
> +
> + req_rx.valid_params =
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_PAUSE_ON_ERR_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_FETCH_SIZE_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CQ_QNUM_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CHAN_TYPE_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_RX_IGNORE_SHORT_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_RX_IGNORE_LONG_VALID;
> +
> + req_rx.nav_id = tisci_rm->tisci_dev_id;
> + req_rx.index = rchan->id;
> + req_rx.rx_fetch_size = sizeof(struct cppi5_desc_hdr_t) >> 2;
> + req_rx.rxcq_qnum = tc_ring;
> + req_rx.rx_pause_on_err = 0;
> + req_rx.rx_chan_type = TI_SCI_RM_UDMAP_CHAN_TYPE_3RDP_BCOPY_PBRR;
> + req_rx.rx_ignore_short = 0;
> + req_rx.rx_ignore_long = 0;Personally I'm not a fan of such a big macro.
> +
> + ret = tisci_ops->rx_ch_cfg(tisci_rm->tisci, &req_rx);
> + if (ret) {
> + dev_err(ud->dev, "rchan%d alloc failed %d\n",
> + rchan->id, ret);
> + return ret;
> + }
> + } else {
> + /* Slave transfer */
> + u32 mode, fetch_size;
> +
> + if (uc->pkt_mode) {
> + mode = TI_SCI_RM_UDMAP_CHAN_TYPE_PKT_PBRR;
> + fetch_size = cppi5_hdesc_calc_size(uc->needs_epib,
> + uc->psd_size, 0);
> + } else {
> + mode = TI_SCI_RM_UDMAP_CHAN_TYPE_3RDP_PBRR;
> + fetch_size = sizeof(struct cppi5_desc_hdr_t);
> + }
> +
> + if (uc->dir == DMA_MEM_TO_DEV) {
> + /* TX */
> + int tc_ring = k3_ringacc_get_ring_id(tchan->tc_ring);
> + struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
> +
> + req_tx.valid_params =
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_PAUSE_ON_ERR_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_FILT_EINFO_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_FILT_PSWORDS_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CHAN_TYPE_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_SUPR_TDPKT_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_FETCH_SIZE_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CQ_QNUM_VALID;
> +
> + req_tx.nav_id = tisci_rm->tisci_dev_id;
> + req_tx.index = tchan->id;
> + req_tx.tx_pause_on_err = 0;
> + req_tx.tx_filt_einfo = 0;
> + req_tx.tx_filt_pswords = 0;
> + req_tx.tx_chan_type = mode;
> + req_tx.tx_supr_tdpkt = 0;
> + req_tx.tx_fetch_size = fetch_size >> 2;
> + req_tx.txcq_qnum = tc_ring;
> +
> + ret = tisci_ops->tx_ch_cfg(tisci_rm->tisci, &req_tx);
> + if (ret) {
> + dev_err(ud->dev, "tchan%d cfg failed %d\n",
> + tchan->id, ret);
> + return ret;
> + }
> + } else {
> + /* RX */
> + int fd_ring = k3_ringacc_get_ring_id(rchan->fd_ring);
> + int rx_ring = k3_ringacc_get_ring_id(rchan->r_ring);
> + struct ti_sci_msg_rm_udmap_rx_ch_cfg req_rx = { 0 };
> + struct ti_sci_msg_rm_udmap_flow_cfg flow_req = { 0 };
> +
> + req_rx.valid_params =
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_PAUSE_ON_ERR_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_FETCH_SIZE_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CQ_QNUM_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CHAN_TYPE_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_RX_IGNORE_SHORT_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_RX_IGNORE_LONG_VALID;
> +
> + req_rx.nav_id = tisci_rm->tisci_dev_id;
> + req_rx.index = rchan->id;
> + req_rx.rx_fetch_size = fetch_size >> 2;
> + req_rx.rxcq_qnum = rx_ring;
> + req_rx.rx_pause_on_err = 0;
> + req_rx.rx_chan_type = mode;
> + req_rx.rx_ignore_short = 0;
> + req_rx.rx_ignore_long = 0;
> +
> + ret = tisci_ops->rx_ch_cfg(tisci_rm->tisci, &req_rx);
> + if (ret) {
> + dev_err(ud->dev, "rchan%d cfg failed %d\n",
> + rchan->id, ret);
> + return ret;
> + }
> +
> + flow_req.valid_params =
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_EINFO_PRESENT_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_PSINFO_PRESENT_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_ERROR_HANDLING_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_DESC_TYPE_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_DEST_QNUM_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_SRC_TAG_HI_SEL_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_SRC_TAG_LO_SEL_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_DEST_TAG_HI_SEL_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_DEST_TAG_LO_SEL_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_FDQ0_SZ0_QNUM_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_FDQ1_QNUM_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_FDQ2_QNUM_VALID |
> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_FDQ3_QNUM_VALID;
> +
> + flow_req.nav_id = tisci_rm->tisci_dev_id;
> + flow_req.flow_index = rchan->id;
> +
> + if (uc->needs_epib)
> + flow_req.rx_einfo_present = 1;
> + else
> + flow_req.rx_einfo_present = 0;
> + if (uc->psd_size)
> + flow_req.rx_psinfo_present = 1;
> + else
> + flow_req.rx_psinfo_present = 0;
> + flow_req.rx_error_handling = 1;
> + flow_req.rx_desc_type = 0;
> + flow_req.rx_dest_qnum = rx_ring;
> + flow_req.rx_src_tag_hi_sel = 2;
> + flow_req.rx_src_tag_lo_sel = 4;
> + flow_req.rx_dest_tag_hi_sel = 5;
> + flow_req.rx_dest_tag_lo_sel = 4;
> + flow_req.rx_fdq0_sz0_qnum = fd_ring;
> + flow_req.rx_fdq1_qnum = fd_ring;
> + flow_req.rx_fdq2_qnum = fd_ring;
> + flow_req.rx_fdq3_qnum = fd_ring;
> +
> + ret = tisci_ops->rx_flow_cfg(tisci_rm->tisci,
> + &flow_req);
> +
> + if (ret) {
> + dev_err(ud->dev, "flow%d config failed: %d\n",
> + rchan->id, ret);
> + return ret;
> + }
> + }
> + }
> +
> + return 0;
> +}
Could you split above big function pls?
> +
> +static int udma_alloc_chan_resources(struct dma_chan *chan)
> +{
> + struct udma_chan *uc = to_udma_chan(chan);
> + struct udma_dev *ud = to_udma_dev(chan->device);
> + const struct udma_match_data *match_data = ud->match_data;
> + struct k3_ring *irq_ring;
> + u32 irq_udma_idx;
> + int ret;
> +
> + if (uc->pkt_mode || uc->dir == DMA_MEM_TO_MEM) {
> + uc->use_dma_pool = true;
> + /* in case of MEM_TO_MEM we have maximum of two TRs */
> + if (uc->dir == DMA_MEM_TO_MEM) {
> + uc->hdesc_size = cppi5_trdesc_calc_size(
> + sizeof(struct cppi5_tr_type15_t), 2);
> + uc->pkt_mode = false;
> + }
> + }
> +
> + if (uc->use_dma_pool) {
> + uc->hdesc_pool = dma_pool_create(uc->name, ud->ddev.dev,
> + uc->hdesc_size, ud->desc_align,
> + 0);
> + if (!uc->hdesc_pool) {
> + dev_err(ud->ddev.dev,
> + "Descriptor pool allocation failed\n");
> + uc->use_dma_pool = false;
> + return -ENOMEM;
> + }
> + }
> +
> + pm_runtime_get_sync(ud->ddev.dev);
> +
> + /*
> + * Make sure that the completion is in a known state:
> + * No teardown, the channel is idle
> + */
> + reinit_completion(&uc->teardown_completed);
> + complete_all(&uc->teardown_completed);
> + uc->state = UDMA_CHAN_IS_IDLE;
> +
> + switch (uc->dir) {
> + case DMA_MEM_TO_MEM:
> + /* Non synchronized - mem to mem type of transfer */
> + dev_dbg(uc->ud->dev, "%s: chan%d as MEM-to-MEM\n", __func__,
> + uc->id);
> +
> + ret = udma_get_chan_pair(uc);
> + if (ret)
> + return ret;
> +
> + ret = udma_alloc_tx_resources(uc);
> + if (ret)
> + return ret;
> +
> + ret = udma_alloc_rx_resources(uc);
> + if (ret) {
> + udma_free_tx_resources(uc);
> + return ret;
> + }
> +
> + uc->src_thread = ud->psil_base + uc->tchan->id;
> + uc->dst_thread = (ud->psil_base + uc->rchan->id) |
> + UDMA_PSIL_DST_THREAD_ID_OFFSET;
> +
> + irq_ring = uc->tchan->tc_ring;
> + irq_udma_idx = uc->tchan->id;
> + break;
> + case DMA_MEM_TO_DEV:
> + /* Slave transfer synchronized - mem to dev (TX) trasnfer */
> + dev_dbg(uc->ud->dev, "%s: chan%d as MEM-to-DEV\n", __func__,
> + uc->id);
> +
> + ret = udma_alloc_tx_resources(uc);
> + if (ret) {
> + uc->remote_thread_id = -1;
> + return ret;
> + }
> +
> + uc->src_thread = ud->psil_base + uc->tchan->id;
> + uc->dst_thread = uc->remote_thread_id;
> + uc->dst_thread |= UDMA_PSIL_DST_THREAD_ID_OFFSET;
> +
> + irq_ring = uc->tchan->tc_ring;
> + irq_udma_idx = uc->tchan->id;
> + break;
> + case DMA_DEV_TO_MEM:
> + /* Slave transfer synchronized - dev to mem (RX) trasnfer */
> + dev_dbg(uc->ud->dev, "%s: chan%d as DEV-to-MEM\n", __func__,
> + uc->id);
> +
> + ret = udma_alloc_rx_resources(uc);
> + if (ret) {
> + uc->remote_thread_id = -1;
> + return ret;
> + }
> +
> + uc->src_thread = uc->remote_thread_id;
> + uc->dst_thread = (ud->psil_base + uc->rchan->id) |
> + UDMA_PSIL_DST_THREAD_ID_OFFSET;
> +
> + irq_ring = uc->rchan->r_ring;
> + irq_udma_idx = match_data->rchan_oes_offset + uc->rchan->id;
> + break;
> + default:
> + /* Can not happen */
> + dev_err(uc->ud->dev, "%s: chan%d invalid direction (%u)\n",
> + __func__, uc->id, uc->dir);
> + return -EINVAL;
> + }
> +
> + /* Configure channel(s), rflow via tisci */
> + ret = udma_tisci_channel_config(uc);
> + if (ret)
> + goto err_res_free;
> +
> + if (udma_is_chan_running(uc)) {
> + dev_warn(ud->dev, "chan%d: is running!\n", uc->id);
> + udma_stop(uc);
> + if (udma_is_chan_running(uc)) {
> + dev_err(ud->dev, "chan%d: won't stop!\n", uc->id);
> + goto err_res_free;
> + }
> + }
> +
> + /* PSI-L pairing */
> + ret = navss_psil_pair(ud, uc->src_thread, uc->dst_thread);
> + if (ret) {
> + dev_err(ud->dev, "PSI-L pairing failed: 0x%04x -> 0x%04x\n",
> + uc->src_thread, uc->dst_thread);
> + goto err_res_free;
> + }
> +
> + uc->psil_paired = true;
> +
> + uc->irq_num_ring = k3_ringacc_get_ring_irq_num(irq_ring);
> + if (uc->irq_num_ring <= 0) {
> + dev_err(ud->dev, "Failed to get ring irq (index: %u)\n",
> + k3_ringacc_get_ring_id(irq_ring));
> + ret = -EINVAL;
> + goto err_psi_free;
> + }
> +
> + ret = request_irq(uc->irq_num_ring, udma_ring_irq_handler,
> + IRQF_TRIGGER_HIGH, uc->name, uc);
> + if (ret) {
> + dev_err(ud->dev, "chan%d: ring irq request failed\n", uc->id);
> + goto err_irq_free;
> + }
> +
> + /* Event from UDMA (TR events) only needed for slave TR mode channels */
> + if (is_slave_direction(uc->dir) && !uc->pkt_mode) {
> + uc->irq_num_udma = ti_sci_inta_msi_get_virq(ud->dev,
> + irq_udma_idx);
> + if (uc->irq_num_udma <= 0) {
> + dev_err(ud->dev, "Failed to get udma irq (index: %u)\n",
> + irq_udma_idx);
> + free_irq(uc->irq_num_ring, uc);
> + ret = -EINVAL;
> + goto err_irq_free;
> + }
> +
> + ret = request_irq(uc->irq_num_udma, udma_udma_irq_handler, 0,
> + uc->name, uc);
> + if (ret) {
> + dev_err(ud->dev, "chan%d: UDMA irq request failed\n",
> + uc->id);
> + free_irq(uc->irq_num_ring, uc);
> + goto err_irq_free;
> + }
> + } else {
> + uc->irq_num_udma = 0;
> + }
> +
> + udma_reset_rings(uc);
> +
> + return 0;
> +
> +err_irq_free:
> + uc->irq_num_ring = 0;
> + uc->irq_num_udma = 0;
> +err_psi_free:
> + navss_psil_unpair(ud, uc->src_thread, uc->dst_thread);
> + uc->psil_paired = false;
> +err_res_free:
> + udma_free_tx_resources(uc);
> + udma_free_rx_resources(uc);
> +
> + uc->remote_thread_id = -1;
> + uc->dir = DMA_MEM_TO_MEM;
> + uc->pkt_mode = false;
> + uc->static_tr_type = 0;
> + uc->enable_acc32 = 0;
> + uc->enable_burst = 0;
> + uc->channel_tpl = 0;
> + uc->psd_size = 0;
> + uc->metadata_size = 0;
> + uc->hdesc_size = 0;
> +
> + if (uc->use_dma_pool) {
> + dma_pool_destroy(uc->hdesc_pool);
> + uc->use_dma_pool = false;
> + }
> +
> + return ret;
> +}
> +
[...]
--
Best regards,
grygorii
_______________________________________________
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 08/14] dmaengine: ti: New driver for K3 UDMA - split#1: defines, structs, io func
From: Grygorii Strashko @ 2019-09-10 7:27 UTC (permalink / raw)
To: Peter Ujfalusi, vkoul, robh+dt, nm, ssantosh
Cc: devicetree, lokeshvutla, j-keerthy, linux-kernel, t-kristo, tony,
dmaengine, dan.j.williams, linux-arm-kernel
In-Reply-To: <20190730093450.12664-9-peter.ujfalusi@ti.com>
On 30/07/2019 12:34, Peter Ujfalusi wrote:
> Split patch for review containing: defines, structs, io and low level
> functions and interrupt callbacks.
>
> DMA driver for
> Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)
>
> The UDMA-P is intended to perform similar (but significantly upgraded) functions
> as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
> supports the transmission and reception of various packet types. The UDMA-P is
> architected to facilitate the segmentation and reassembly of SoC DMA data
> structure compliant packets to/from smaller data blocks that are natively
> compatible with the specific requirements of each connected peripheral. Multiple
> Tx and Rx channels are provided within the DMA which allow multiple segmentation
> or reassembly operations to be ongoing. The DMA controller maintains state
> information for each of the channels which allows packet segmentation and
> reassembly operations to be time division multiplexed between channels in order
> to share the underlying DMA hardware. An external DMA scheduler is used to
> control the ordering and rate at which this multiplexing occurs for Transmit
> operations. The ordering and rate of Receive operations is indirectly controlled
> by the order in which blocks are pushed into the DMA on the Rx PSI-L interface.
>
> The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
> channels. Channels in the UDMA-P can be configured to be either Packet-Based or
> Third-Party channels on a channel by channel basis.
>
> The initial driver supports:
> - MEM_TO_MEM (TR mode)
> - DEV_TO_MEM (Packet / TR mode)
> - MEM_TO_DEV (Packet / TR mode)
> - Cyclic (Packet / TR mode)
> - Metadata for descriptors
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
[...]
> +
> +/* Generic register access functions */
> +static inline u32 udma_read(void __iomem *base, int reg)
> +{
> + return __raw_readl(base + reg);
> +}
> +
> +static inline void udma_write(void __iomem *base, int reg, u32 val)
> +{
> + __raw_writel(val, base + reg);
> +}
> +
> +static inline void udma_update_bits(void __iomem *base, int reg,
> + u32 mask, u32 val)
> +{
> + u32 tmp, orig;
> +
> + orig = __raw_readl(base + reg);
> + tmp = orig & ~mask;
> + tmp |= (val & mask);
> +
> + if (tmp != orig)
> + __raw_writel(tmp, base + reg);
> +}
Pls, do not use _raw APIs in drivers.
[...]
--
Best regards,
grygorii
_______________________________________________
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] arm64: fix unreachable code issue with cmpxchg
From: Will Deacon @ 2019-09-10 7:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Catalin Marinas, linux-kernel, clang-built-linux,
Andrew Murray, linux-arm-kernel
In-Reply-To: <20190909202153.144970-1-arnd@arndb.de>
On Mon, Sep 09, 2019 at 10:21:35PM +0200, Arnd Bergmann wrote:
> On arm64 build with clang, sometimes the __cmpxchg_mb is not inlined
> when CONFIG_OPTIMIZE_INLINING is set.
Hmm. Given that CONFIG_OPTIMIZE_INLINING has also been shown to break
assignment of local 'register' variables on GCC, perhaps we should just
disable that option for arm64 (at least) since we don't have any toolchains
that seem to like it very much! I'd certainly prefer that over playing
whack-a-mole with __always_inline.
Will
_______________________________________________
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] reset: uniphier-glue: Add Pro5 USB3 support
From: Philipp Zabel @ 2019-09-10 7:48 UTC (permalink / raw)
To: Kunihiko Hayashi, Rob Herring, Mark Rutland, Masahiro Yamada
Cc: devicetree, Masami Hiramatsu, linux-kernel, linux-arm-kernel,
Jassi Brar
In-Reply-To: <1568080527-1767-1-git-send-email-hayashi.kunihiko@socionext.com>
Hi Kunihiko,
On Tue, 2019-09-10 at 10:55 +0900, Kunihiko Hayashi wrote:
> Pro5 SoC has same scheme of USB3 reset as Pro4, so the data for Pro5 is
> equivalent to Pro4.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
If it is exactly the same, you could keep using the same compatible:
> ---
> Documentation/devicetree/bindings/reset/uniphier-reset.txt | 5 +++--
> drivers/reset/reset-uniphier-glue.c | 4 ++++
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> index ea00517..e320a8c 100644
> --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> @@ -130,6 +130,7 @@ this layer. These clocks and resets should be described in each property.
> Required properties:
> - compatible: Should be
> "socionext,uniphier-pro4-usb3-reset" - for Pro4 SoC USB3
> + "socionext,uniphier-pro5-usb3-reset" - for Pro5 SoC USB3
+ "socionext,uniphier-pro5-usb3-reset", "socionext,uniphier-pro4-usb3-reset" - for Pro5 SoC USB3
[...]
> diff --git a/drivers/reset/reset-uniphier-glue.c b/drivers/reset/reset-uniphier-glue.c
> index a45923f..2b188b3bb 100644
> --- a/drivers/reset/reset-uniphier-glue.c
> +++ b/drivers/reset/reset-uniphier-glue.c
> @@ -141,6 +141,10 @@ static const struct of_device_id uniphier_glue_reset_match[] = {
> .data = &uniphier_pro4_data,
> },
> {
> + .compatible = "socionext,uniphier-pro5-usb3-reset",
> + .data = &uniphier_pro4_data,
> + },
> + {
> .compatible = "socionext,uniphier-pxs2-usb3-reset",
> .data = &uniphier_pxs2_data,
> },
And this change would not be necessary.
regards
Philipp
_______________________________________________
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 10/14] dmaengine: ti: New driver for K3 UDMA - split#3: alloc/free chan_resources
From: Peter Ujfalusi @ 2019-09-10 7:53 UTC (permalink / raw)
To: Grygorii Strashko, vkoul, robh+dt, nm, ssantosh
Cc: devicetree, lokeshvutla, j-keerthy, linux-kernel, t-kristo, tony,
dmaengine, dan.j.williams, linux-arm-kernel
In-Reply-To: <9091414a-6b9f-24c2-1637-2a8c0ac78dee@ti.com>
On 10/09/2019 10.25, Grygorii Strashko wrote:
>
>
> On 30/07/2019 12:34, Peter Ujfalusi wrote:
>> Split patch for review containing: channel rsource allocation and free
>> functions.
>>
>> DMA driver for
>> Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)
>>
>> The UDMA-P is intended to perform similar (but significantly upgraded)
>> functions
>> as the packet-oriented DMA used on previous SoC devices. The UDMA-P
>> module
>> supports the transmission and reception of various packet types. The
>> UDMA-P is
>> architected to facilitate the segmentation and reassembly of SoC DMA data
>> structure compliant packets to/from smaller data blocks that are natively
>> compatible with the specific requirements of each connected
>> peripheral. Multiple
>> Tx and Rx channels are provided within the DMA which allow multiple
>> segmentation
>> or reassembly operations to be ongoing. The DMA controller maintains
>> state
>> information for each of the channels which allows packet segmentation and
>> reassembly operations to be time division multiplexed between channels
>> in order
>> to share the underlying DMA hardware. An external DMA scheduler is
>> used to
>> control the ordering and rate at which this multiplexing occurs for
>> Transmit
>> operations. The ordering and rate of Receive operations is indirectly
>> controlled
>> by the order in which blocks are pushed into the DMA on the Rx PSI-L
>> interface.
>>
>> The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
>> channels. Channels in the UDMA-P can be configured to be either
>> Packet-Based or
>> Third-Party channels on a channel by channel basis.
>>
>> The initial driver supports:
>> - MEM_TO_MEM (TR mode)
>> - DEV_TO_MEM (Packet / TR mode)
>> - MEM_TO_DEV (Packet / TR mode)
>> - Cyclic (Packet / TR mode)
>> - Metadata for descriptors
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>> drivers/dma/ti/k3-udma.c | 780 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 780 insertions(+)
>>
>> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
>> index 52ccc6d46de9..0de38db03b8d 100644
>> --- a/drivers/dma/ti/k3-udma.c
>> +++ b/drivers/dma/ti/k3-udma.c
>> @@ -1039,6 +1039,786 @@ static irqreturn_t udma_udma_irq_handler(int
>> irq, void *data)
>> return IRQ_HANDLED;
>> }
>> +static struct udma_rflow *__udma_reserve_rflow(struct udma_dev *ud,
>> + enum udma_tp_level tpl, int id)
>> +{
>> + DECLARE_BITMAP(tmp, K3_UDMA_MAX_RFLOWS);
>> +
>> + if (id >= 0) {
>> + if (test_bit(id, ud->rflow_map)) {
>> + dev_err(ud->dev, "rflow%d is in use\n", id);
>> + return ERR_PTR(-ENOENT);
>> + }
>> + } else {
>> + bitmap_or(tmp, ud->rflow_map, ud->rflow_map_reserved,
>> + ud->rflow_cnt);
>> +
>> + id = find_next_zero_bit(tmp, ud->rflow_cnt, ud->rchan_cnt);
>> + if (id >= ud->rflow_cnt)
>> + return ERR_PTR(-ENOENT);
>> + }
>> +
>> + set_bit(id, ud->rflow_map);
>> + return &ud->rflows[id];
>> +}
>> +
>> +#define UDMA_RESERVE_RESOURCE(res) \
>> +static struct udma_##res *__udma_reserve_##res(struct udma_dev *ud, \
>> + enum udma_tp_level tpl, \
>> + int id) \
>> +{ \
>> + if (id >= 0) { \
>> + if (test_bit(id, ud->res##_map)) { \
>> + dev_err(ud->dev, "res##%d is in use\n", id); \
>> + return ERR_PTR(-ENOENT); \
>> + } \
>> + } else { \
>> + int start; \
>> + \
>> + if (tpl >= ud->match_data->tpl_levels) \
>> + tpl = ud->match_data->tpl_levels - 1; \
>> + \
>> + start = ud->match_data->level_start_idx[tpl]; \
>> + \
>> + id = find_next_zero_bit(ud->res##_map, ud->res##_cnt, \
>> + start); \
>> + if (id == ud->res##_cnt) { \
>> + return ERR_PTR(-ENOENT); \
>> + } \
>> + } \
>> + \
>> + set_bit(id, ud->res##_map); \
>> + return &ud->res##s[id]; \
>> +}
>> +
>> +UDMA_RESERVE_RESOURCE(tchan);
>> +UDMA_RESERVE_RESOURCE(rchan);
>
> Personally I'm not a fan of such a big macro, wouldn't be static
> functions better.
The other option is to have two identical function with only difference
is s/tchan/rchan.
>
>> +
>> +static int udma_get_tchan(struct udma_chan *uc)
>> +{
>> + struct udma_dev *ud = uc->ud;
>> +
>> + if (uc->tchan) {
>> + dev_dbg(ud->dev, "chan%d: already have tchan%d allocated\n",
>> + uc->id, uc->tchan->id);
>> + return 0;
>> + }
>> +
>> + uc->tchan = __udma_reserve_tchan(ud, uc->channel_tpl, -1);
>> + if (IS_ERR(uc->tchan))
>> + return PTR_ERR(uc->tchan);
>> +
>> + return 0;
>> +}
>> +
>
> [...]
>
>> +
>> +static int udma_tisci_channel_config(struct udma_chan *uc)
>> +{
>> + struct udma_dev *ud = uc->ud;
>> + struct udma_tisci_rm *tisci_rm = &ud->tisci_rm;
>> + const struct ti_sci_rm_udmap_ops *tisci_ops =
>> tisci_rm->tisci_udmap_ops;
>> + struct udma_tchan *tchan = uc->tchan;
>> + struct udma_rchan *rchan = uc->rchan;
>> + int ret = 0;
>> +
>> + if (uc->dir == DMA_MEM_TO_MEM) {
>> + /* Non synchronized - mem to mem type of transfer */
>> + int tc_ring = k3_ringacc_get_ring_id(tchan->tc_ring);
>> + struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
>> + struct ti_sci_msg_rm_udmap_rx_ch_cfg req_rx = { 0 };
>> +
>> + req_tx.valid_params =
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_PAUSE_ON_ERR_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_FILT_EINFO_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_FILT_PSWORDS_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CHAN_TYPE_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_SUPR_TDPKT_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_FETCH_SIZE_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CQ_QNUM_VALID;
>> +
>> + req_tx.nav_id = tisci_rm->tisci_dev_id;
>> + req_tx.index = tchan->id;
>> + req_tx.tx_pause_on_err = 0;
>> + req_tx.tx_filt_einfo = 0;
>> + req_tx.tx_filt_pswords = 0;
>> + req_tx.tx_chan_type = TI_SCI_RM_UDMAP_CHAN_TYPE_3RDP_BCOPY_PBRR;
>> + req_tx.tx_supr_tdpkt = 0;
>> + req_tx.tx_fetch_size = sizeof(struct cppi5_desc_hdr_t) >> 2;
>> + req_tx.txcq_qnum = tc_ring;
>> +
>> + ret = tisci_ops->tx_ch_cfg(tisci_rm->tisci, &req_tx);
>> + if (ret) {
>> + dev_err(ud->dev, "tchan%d cfg failed %d\n",
>> + tchan->id, ret);
>> + return ret;
>> + }
>> +
>> + req_rx.valid_params =
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_PAUSE_ON_ERR_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_FETCH_SIZE_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CQ_QNUM_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CHAN_TYPE_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_RX_IGNORE_SHORT_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_RX_IGNORE_LONG_VALID;
>> +
>> + req_rx.nav_id = tisci_rm->tisci_dev_id;
>> + req_rx.index = rchan->id;
>> + req_rx.rx_fetch_size = sizeof(struct cppi5_desc_hdr_t) >> 2;
>> + req_rx.rxcq_qnum = tc_ring;
>> + req_rx.rx_pause_on_err = 0;
>> + req_rx.rx_chan_type = TI_SCI_RM_UDMAP_CHAN_TYPE_3RDP_BCOPY_PBRR;
>> + req_rx.rx_ignore_short = 0;
>> + req_rx.rx_ignore_long = 0;
>> +
>> + ret = tisci_ops->rx_ch_cfg(tisci_rm->tisci, &req_rx);
>> + if (ret) {
>> + dev_err(ud->dev, "rchan%d alloc failed %d\n",
>> + rchan->id, ret);
>> + return ret;
>> + }
>> + } else {
>> + /* Slave transfer */
>> + u32 mode, fetch_size;
>> +
>> + if (uc->pkt_mode) {
>> + mode = TI_SCI_RM_UDMAP_CHAN_TYPE_PKT_PBRR;
>> + fetch_size = cppi5_hdesc_calc_size(uc->needs_epib,
>> + uc->psd_size, 0);
>> + } else {
>> + mode = TI_SCI_RM_UDMAP_CHAN_TYPE_3RDP_PBRR;
>> + fetch_size = sizeof(struct cppi5_desc_hdr_t);
>> + }
>> +
>> + if (uc->dir == DMA_MEM_TO_DEV) {
>> + /* TX */
>> + int tc_ring = k3_ringacc_get_ring_id(tchan->tc_ring);
>> + struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
>> +
>> + req_tx.valid_params =
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_PAUSE_ON_ERR_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_FILT_EINFO_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_FILT_PSWORDS_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CHAN_TYPE_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_SUPR_TDPKT_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_FETCH_SIZE_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CQ_QNUM_VALID;
>> +
>> + req_tx.nav_id = tisci_rm->tisci_dev_id;
>> + req_tx.index = tchan->id;
>> + req_tx.tx_pause_on_err = 0;
>> + req_tx.tx_filt_einfo = 0;
>> + req_tx.tx_filt_pswords = 0;
>> + req_tx.tx_chan_type = mode;
>> + req_tx.tx_supr_tdpkt = 0;
>> + req_tx.tx_fetch_size = fetch_size >> 2;
>> + req_tx.txcq_qnum = tc_ring;
>> +
>> + ret = tisci_ops->tx_ch_cfg(tisci_rm->tisci, &req_tx);
>> + if (ret) {
>> + dev_err(ud->dev, "tchan%d cfg failed %d\n",
>> + tchan->id, ret);
>> + return ret;
>> + }
>> + } else {
>> + /* RX */
>> + int fd_ring = k3_ringacc_get_ring_id(rchan->fd_ring);
>> + int rx_ring = k3_ringacc_get_ring_id(rchan->r_ring);
>> + struct ti_sci_msg_rm_udmap_rx_ch_cfg req_rx = { 0 };
>> + struct ti_sci_msg_rm_udmap_flow_cfg flow_req = { 0 };
>> +
>> + req_rx.valid_params =
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_PAUSE_ON_ERR_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_FETCH_SIZE_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CQ_QNUM_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_CHAN_TYPE_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_RX_IGNORE_SHORT_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_CH_RX_IGNORE_LONG_VALID;
>> +
>> + req_rx.nav_id = tisci_rm->tisci_dev_id;
>> + req_rx.index = rchan->id;
>> + req_rx.rx_fetch_size = fetch_size >> 2;
>> + req_rx.rxcq_qnum = rx_ring;
>> + req_rx.rx_pause_on_err = 0;
>> + req_rx.rx_chan_type = mode;
>> + req_rx.rx_ignore_short = 0;
>> + req_rx.rx_ignore_long = 0;
>> +
>> + ret = tisci_ops->rx_ch_cfg(tisci_rm->tisci, &req_rx);
>> + if (ret) {
>> + dev_err(ud->dev, "rchan%d cfg failed %d\n",
>> + rchan->id, ret);
>> + return ret;
>> + }
>> +
>> + flow_req.valid_params =
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_EINFO_PRESENT_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_PSINFO_PRESENT_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_ERROR_HANDLING_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_DESC_TYPE_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_DEST_QNUM_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_SRC_TAG_HI_SEL_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_SRC_TAG_LO_SEL_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_DEST_TAG_HI_SEL_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_DEST_TAG_LO_SEL_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_FDQ0_SZ0_QNUM_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_FDQ1_QNUM_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_FDQ2_QNUM_VALID |
>> + TI_SCI_MSG_VALUE_RM_UDMAP_FLOW_FDQ3_QNUM_VALID;
>> +
>> + flow_req.nav_id = tisci_rm->tisci_dev_id;
>> + flow_req.flow_index = rchan->id;
>> +
>> + if (uc->needs_epib)
>> + flow_req.rx_einfo_present = 1;
>> + else
>> + flow_req.rx_einfo_present = 0;
>> + if (uc->psd_size)
>> + flow_req.rx_psinfo_present = 1;
>> + else
>> + flow_req.rx_psinfo_present = 0;
>> + flow_req.rx_error_handling = 1;
>> + flow_req.rx_desc_type = 0;
>> + flow_req.rx_dest_qnum = rx_ring;
>> + flow_req.rx_src_tag_hi_sel = 2;
>> + flow_req.rx_src_tag_lo_sel = 4;
>> + flow_req.rx_dest_tag_hi_sel = 5;
>> + flow_req.rx_dest_tag_lo_sel = 4;
>> + flow_req.rx_fdq0_sz0_qnum = fd_ring;
>> + flow_req.rx_fdq1_qnum = fd_ring;
>> + flow_req.rx_fdq2_qnum = fd_ring;
>> + flow_req.rx_fdq3_qnum = fd_ring;
>> +
>> + ret = tisci_ops->rx_flow_cfg(tisci_rm->tisci,
>> + &flow_req);
>> +
>> + if (ret) {
>> + dev_err(ud->dev, "flow%d config failed: %d\n",
>> + rchan->id, ret);
>> + return ret;
>> + }
>> + }
>> + }
>> +
>> + return 0;
>> +}
>
> Could you split above big function pls?
I can slit to:
udma_tisci_m2m_channel_config()
udma_tisci_tx_channel_config()
udma_tisci_rx_channel_config()
and call them from the first switch case in udma_alloc_chan_resources()
>
>> +
>> +static int udma_alloc_chan_resources(struct dma_chan *chan)
>> +{
>> + struct udma_chan *uc = to_udma_chan(chan);
>> + struct udma_dev *ud = to_udma_dev(chan->device);
>> + const struct udma_match_data *match_data = ud->match_data;
>> + struct k3_ring *irq_ring;
>> + u32 irq_udma_idx;
>> + int ret;
>> +
>> + if (uc->pkt_mode || uc->dir == DMA_MEM_TO_MEM) {
>> + uc->use_dma_pool = true;
>> + /* in case of MEM_TO_MEM we have maximum of two TRs */
>> + if (uc->dir == DMA_MEM_TO_MEM) {
>> + uc->hdesc_size = cppi5_trdesc_calc_size(
>> + sizeof(struct cppi5_tr_type15_t), 2);
>> + uc->pkt_mode = false;
>> + }
>> + }
>> +
>> + if (uc->use_dma_pool) {
>> + uc->hdesc_pool = dma_pool_create(uc->name, ud->ddev.dev,
>> + uc->hdesc_size, ud->desc_align,
>> + 0);
>> + if (!uc->hdesc_pool) {
>> + dev_err(ud->ddev.dev,
>> + "Descriptor pool allocation failed\n");
>> + uc->use_dma_pool = false;
>> + return -ENOMEM;
>> + }
>> + }
>> +
>> + pm_runtime_get_sync(ud->ddev.dev);
>> +
>> + /*
>> + * Make sure that the completion is in a known state:
>> + * No teardown, the channel is idle
>> + */
>> + reinit_completion(&uc->teardown_completed);
>> + complete_all(&uc->teardown_completed);
>> + uc->state = UDMA_CHAN_IS_IDLE;
>> +
>> + switch (uc->dir) {
>> + case DMA_MEM_TO_MEM:
>> + /* Non synchronized - mem to mem type of transfer */
>> + dev_dbg(uc->ud->dev, "%s: chan%d as MEM-to-MEM\n", __func__,
>> + uc->id);
>> +
>> + ret = udma_get_chan_pair(uc);
>> + if (ret)
>> + return ret;
>> +
>> + ret = udma_alloc_tx_resources(uc);
>> + if (ret)
>> + return ret;
>> +
>> + ret = udma_alloc_rx_resources(uc);
>> + if (ret) {
>> + udma_free_tx_resources(uc);
>> + return ret;
>> + }
>> +
>> + uc->src_thread = ud->psil_base + uc->tchan->id;
>> + uc->dst_thread = (ud->psil_base + uc->rchan->id) |
>> + UDMA_PSIL_DST_THREAD_ID_OFFSET;
>> +
>> + irq_ring = uc->tchan->tc_ring;
>> + irq_udma_idx = uc->tchan->id;
>> + break;
>> + case DMA_MEM_TO_DEV:
>> + /* Slave transfer synchronized - mem to dev (TX) trasnfer */
>> + dev_dbg(uc->ud->dev, "%s: chan%d as MEM-to-DEV\n", __func__,
>> + uc->id);
>> +
>> + ret = udma_alloc_tx_resources(uc);
>> + if (ret) {
>> + uc->remote_thread_id = -1;
>> + return ret;
>> + }
>> +
>> + uc->src_thread = ud->psil_base + uc->tchan->id;
>> + uc->dst_thread = uc->remote_thread_id;
>> + uc->dst_thread |= UDMA_PSIL_DST_THREAD_ID_OFFSET;
>> +
>> + irq_ring = uc->tchan->tc_ring;
>> + irq_udma_idx = uc->tchan->id;
>> + break;
>> + case DMA_DEV_TO_MEM:
>> + /* Slave transfer synchronized - dev to mem (RX) trasnfer */
>> + dev_dbg(uc->ud->dev, "%s: chan%d as DEV-to-MEM\n", __func__,
>> + uc->id);
>> +
>> + ret = udma_alloc_rx_resources(uc);
>> + if (ret) {
>> + uc->remote_thread_id = -1;
>> + return ret;
>> + }
>> +
>> + uc->src_thread = uc->remote_thread_id;
>> + uc->dst_thread = (ud->psil_base + uc->rchan->id) |
>> + UDMA_PSIL_DST_THREAD_ID_OFFSET;
>> +
>> + irq_ring = uc->rchan->r_ring;
>> + irq_udma_idx = match_data->rchan_oes_offset + uc->rchan->id;
>> + break;
>> + default:
>> + /* Can not happen */
>> + dev_err(uc->ud->dev, "%s: chan%d invalid direction (%u)\n",
>> + __func__, uc->id, uc->dir);
>> + return -EINVAL;
>> + }
>> +
>> + /* Configure channel(s), rflow via tisci */
>> + ret = udma_tisci_channel_config(uc);
>> + if (ret)
>> + goto err_res_free;
>> +
>> + if (udma_is_chan_running(uc)) {
>> + dev_warn(ud->dev, "chan%d: is running!\n", uc->id);
>> + udma_stop(uc);
>> + if (udma_is_chan_running(uc)) {
>> + dev_err(ud->dev, "chan%d: won't stop!\n", uc->id);
>> + goto err_res_free;
>> + }
>> + }
>> +
>> + /* PSI-L pairing */
>> + ret = navss_psil_pair(ud, uc->src_thread, uc->dst_thread);
>> + if (ret) {
>> + dev_err(ud->dev, "PSI-L pairing failed: 0x%04x -> 0x%04x\n",
>> + uc->src_thread, uc->dst_thread);
>> + goto err_res_free;
>> + }
>> +
>> + uc->psil_paired = true;
>> +
>> + uc->irq_num_ring = k3_ringacc_get_ring_irq_num(irq_ring);
>> + if (uc->irq_num_ring <= 0) {
>> + dev_err(ud->dev, "Failed to get ring irq (index: %u)\n",
>> + k3_ringacc_get_ring_id(irq_ring));
>> + ret = -EINVAL;
>> + goto err_psi_free;
>> + }
>> +
>> + ret = request_irq(uc->irq_num_ring, udma_ring_irq_handler,
>> + IRQF_TRIGGER_HIGH, uc->name, uc);
>> + if (ret) {
>> + dev_err(ud->dev, "chan%d: ring irq request failed\n", uc->id);
>> + goto err_irq_free;
>> + }
>> +
>> + /* Event from UDMA (TR events) only needed for slave TR mode
>> channels */
>> + if (is_slave_direction(uc->dir) && !uc->pkt_mode) {
>> + uc->irq_num_udma = ti_sci_inta_msi_get_virq(ud->dev,
>> + irq_udma_idx);
>> + if (uc->irq_num_udma <= 0) {
>> + dev_err(ud->dev, "Failed to get udma irq (index: %u)\n",
>> + irq_udma_idx);
>> + free_irq(uc->irq_num_ring, uc);
>> + ret = -EINVAL;
>> + goto err_irq_free;
>> + }
>> +
>> + ret = request_irq(uc->irq_num_udma, udma_udma_irq_handler, 0,
>> + uc->name, uc);
>> + if (ret) {
>> + dev_err(ud->dev, "chan%d: UDMA irq request failed\n",
>> + uc->id);
>> + free_irq(uc->irq_num_ring, uc);
>> + goto err_irq_free;
>> + }
>> + } else {
>> + uc->irq_num_udma = 0;
>> + }
>> +
>> + udma_reset_rings(uc);
>> +
>> + return 0;
>> +
>> +err_irq_free:
>> + uc->irq_num_ring = 0;
>> + uc->irq_num_udma = 0;
>> +err_psi_free:
>> + navss_psil_unpair(ud, uc->src_thread, uc->dst_thread);
>> + uc->psil_paired = false;
>> +err_res_free:
>> + udma_free_tx_resources(uc);
>> + udma_free_rx_resources(uc);
>> +
>> + uc->remote_thread_id = -1;
>> + uc->dir = DMA_MEM_TO_MEM;
>> + uc->pkt_mode = false;
>> + uc->static_tr_type = 0;
>> + uc->enable_acc32 = 0;
>> + uc->enable_burst = 0;
>> + uc->channel_tpl = 0;
>> + uc->psd_size = 0;
>> + uc->metadata_size = 0;
>> + uc->hdesc_size = 0;
>> +
>> + if (uc->use_dma_pool) {
>> + dma_pool_destroy(uc->hdesc_pool);
>> + uc->use_dma_pool = false;
>> + }
>> +
>> + return ret;
>> +}
>> +
>
> [...]
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] thermal-generic-adc: Silent error message for EPROBE_DEFER
From: Hsin-Yi Wang @ 2019-09-10 7:59 UTC (permalink / raw)
To: Eduardo Valentin, Laxman Dewangan, linux-arm-kernel
Cc: Zhang Rui, Daniel Lezcano, linux-kernel, Jonathan Cameron,
linux-pm
If devm_iio_channel_get() or devm_thermal_zone_of_sensor_register()
fail with EPROBE_DEFER, we shouldn't print an error message, as the
device will be probed again later.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
---
drivers/thermal/thermal-generic-adc.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/thermal-generic-adc.c b/drivers/thermal/thermal-generic-adc.c
index dcecf2e8dc8e..ae5743c9a894 100644
--- a/drivers/thermal/thermal-generic-adc.c
+++ b/drivers/thermal/thermal-generic-adc.c
@@ -134,7 +134,8 @@ static int gadc_thermal_probe(struct platform_device *pdev)
gti->channel = devm_iio_channel_get(&pdev->dev, "sensor-channel");
if (IS_ERR(gti->channel)) {
ret = PTR_ERR(gti->channel);
- dev_err(&pdev->dev, "IIO channel not found: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "IIO channel not found: %d\n", ret);
return ret;
}
@@ -142,8 +143,10 @@ static int gadc_thermal_probe(struct platform_device *pdev)
&gadc_thermal_ops);
if (IS_ERR(gti->tz_dev)) {
ret = PTR_ERR(gti->tz_dev);
- dev_err(&pdev->dev, "Thermal zone sensor register failed: %d\n",
- ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev,
+ "Thermal zone sensor register failed: %d\n",
+ ret);
return ret;
}
--
2.23.0.162.g0b9fbb3734-goog
_______________________________________________
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 v4 04/17] arm64: hibernate: use get_safe_page directly
From: Matthias Brugger @ 2019-09-10 8:03 UTC (permalink / raw)
To: Pavel Tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-arm-kernel, marc.zyngier,
james.morse, vladimir.murzin, bhsharma, linux-mm, mark.rutland
In-Reply-To: <20190909181221.309510-5-pasha.tatashin@soleen.com>
On 09/09/2019 20:12, Pavel Tatashin wrote:
> create_safe_exec_page() uses hibernate's allocator to create a set of page
> table to map a single page that will contain the relocation code.
>
> Remove the allocator related arguments, and use get_safe_page directly, as
> it is done in other local functions in this file to simplify function
> prototype.
>
> Removing this function pointer makes it easier to refactor the code later.
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
> ---
> arch/arm64/kernel/hibernate.c | 17 +++++++----------
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> index 227cc26720f7..47a861e0cb0c 100644
> --- a/arch/arm64/kernel/hibernate.c
> +++ b/arch/arm64/kernel/hibernate.c
> @@ -196,9 +196,7 @@ EXPORT_SYMBOL(arch_hibernation_header_restore);
> */
> static int create_safe_exec_page(void *src_start, size_t length,
> unsigned long dst_addr,
> - phys_addr_t *phys_dst_addr,
> - void *(*allocator)(gfp_t mask),
> - gfp_t mask)
> + phys_addr_t *phys_dst_addr)
> {
> int rc = 0;
> pgd_t *trans_pgd;
> @@ -206,7 +204,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
> pud_t *pudp;
> pmd_t *pmdp;
> pte_t *ptep;
> - unsigned long dst = (unsigned long)allocator(mask);
> + unsigned long dst = get_safe_page(GFP_ATOMIC);
>
> if (!dst) {
> rc = -ENOMEM;
> @@ -216,7 +214,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
> memcpy((void *)dst, src_start, length);
> __flush_icache_range(dst, dst + length);
>
> - trans_pgd = allocator(mask);
> + trans_pgd = (void *)get_safe_page(GFP_ATOMIC);
> if (!trans_pgd) {
> rc = -ENOMEM;
> goto out;
> @@ -224,7 +222,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
>
> pgdp = pgd_offset_raw(trans_pgd, dst_addr);
> if (pgd_none(READ_ONCE(*pgdp))) {
> - pudp = allocator(mask);
> + pudp = (void *)get_safe_page(GFP_ATOMIC);
> if (!pudp) {
> rc = -ENOMEM;
> goto out;
> @@ -234,7 +232,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
>
> pudp = pud_offset(pgdp, dst_addr);
> if (pud_none(READ_ONCE(*pudp))) {
> - pmdp = allocator(mask);
> + pmdp = (void *)get_safe_page(GFP_ATOMIC);
> if (!pmdp) {
> rc = -ENOMEM;
> goto out;
> @@ -244,7 +242,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
>
> pmdp = pmd_offset(pudp, dst_addr);
> if (pmd_none(READ_ONCE(*pmdp))) {
> - ptep = allocator(mask);
> + ptep = (void *)get_safe_page(GFP_ATOMIC);
> if (!ptep) {
> rc = -ENOMEM;
> goto out;
> @@ -530,8 +528,7 @@ int swsusp_arch_resume(void)
> */
> rc = create_safe_exec_page(__hibernate_exit_text_start, exit_size,
> (unsigned long)hibernate_exit,
> - &phys_hibernate_exit,
> - (void *)get_safe_page, GFP_ATOMIC);
> + &phys_hibernate_exit);
> if (rc) {
> pr_err("Failed to create safe executable page for hibernate_exit code.\n");
> goto out;
>
_______________________________________________
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] arm64: fix unreachable code issue with cmpxchg
From: Arnd Bergmann @ 2019-09-10 8:04 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Masahiro Yamada, Catalin Marinas,
linux-kernel@vger.kernel.org, clang-built-linux, Ingo Molnar,
Andrew Murray, Borislav Petkov, Linux ARM
In-Reply-To: <20190910074606.45k5m2pkztlpj4nj@willie-the-truck>
On Tue, Sep 10, 2019 at 9:46 AM Will Deacon <will@kernel.org> wrote:
>
> On Mon, Sep 09, 2019 at 10:21:35PM +0200, Arnd Bergmann wrote:
> > On arm64 build with clang, sometimes the __cmpxchg_mb is not inlined
> > when CONFIG_OPTIMIZE_INLINING is set.
>
> Hmm. Given that CONFIG_OPTIMIZE_INLINING has also been shown to break
> assignment of local 'register' variables on GCC, perhaps we should just
> disable that option for arm64 (at least) since we don't have any toolchains
> that seem to like it very much! I'd certainly prefer that over playing
> whack-a-mole with __always_inline.
Right, but I can also see good reasons to keep going:
- In theory, CONFIG_OPTIMIZE_INLINING is the right thing to do -- the compilers
also make some particularly bad decisions around inlining when each inline
turns into an __always_inline, as has been the case in Linux for a long time.
I think in most cases, we get better object code with CONFIG_OPTIMIZE_INLINING
and in the cases where this is worse, it may be better to fix the compiler.
The new "asm_inline" macro should also help with that.
- The x86 folks have apparently whacked most of the moles already, see this
commit from 2008
commit 3f9b5cc018566ad9562df0648395649aebdbc5e0
Author: Ingo Molnar <mingo@elte.hu>
Date: Fri Jul 18 16:30:05 2008 +0200
x86: re-enable OPTIMIZE_INLINING
re-enable OPTIMIZE_INLINING more widely. Jeff Dike fixed the remaining
outstanding issue in this commit:
| commit 4f81c5350b44bcc501ab6f8a089b16d064b4d2f6
| Author: Jeff Dike <jdike@addtoit.com>
| Date: Mon Jul 7 13:36:56 2008 -0400
|
| [UML] fix gcc ICEs and unresolved externs
[...]
| This patch reintroduces unit-at-a-time for gcc >= 4.0,
bringing back the
| possibility of Uli's crash. If that happens, we'll debug it.
it's still default-off and thus opt-in.
- The inlining decisions of gcc and clang are already very different, and
the bugs we are finding around that are much more common than
the difference between CONFIG_OPTIMIZE_INLINING=y/n on a
given compiler.
Arnd
_______________________________________________
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 v4 05/17] arm64: hibernate: remove gotos in create_safe_exec_page
From: Matthias Brugger @ 2019-09-10 8:21 UTC (permalink / raw)
To: Pavel Tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-arm-kernel, marc.zyngier,
james.morse, vladimir.murzin, bhsharma, linux-mm, mark.rutland
In-Reply-To: <20190909181221.309510-6-pasha.tatashin@soleen.com>
On 09/09/2019 20:12, Pavel Tatashin wrote:
> Usually, gotos are used to handle cleanup after exception, but
> in case of create_safe_exec_page there are no clean-ups. So,
> simply return the errors directly.
>
While at it, how about also cleaning up swsusp_arch_resume() which has the same
issue.
Regards,
Matthias
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> Reviewed-by: James Morse <james.morse@arm.com>
> ---
> arch/arm64/kernel/hibernate.c | 34 +++++++++++-----------------------
> 1 file changed, 11 insertions(+), 23 deletions(-)
>
> diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> index 47a861e0cb0c..7bbeb33c700d 100644
> --- a/arch/arm64/kernel/hibernate.c
> +++ b/arch/arm64/kernel/hibernate.c
> @@ -198,7 +198,6 @@ static int create_safe_exec_page(void *src_start, size_t length,
> unsigned long dst_addr,
> phys_addr_t *phys_dst_addr)
> {
> - int rc = 0;
> pgd_t *trans_pgd;
> pgd_t *pgdp;
> pud_t *pudp;
> @@ -206,47 +205,37 @@ static int create_safe_exec_page(void *src_start, size_t length,
> pte_t *ptep;
> unsigned long dst = get_safe_page(GFP_ATOMIC);
>
> - if (!dst) {
> - rc = -ENOMEM;
> - goto out;
> - }
> + if (!dst)
> + return -ENOMEM;
>
> memcpy((void *)dst, src_start, length);
> __flush_icache_range(dst, dst + length);
>
> trans_pgd = (void *)get_safe_page(GFP_ATOMIC);
> - if (!trans_pgd) {
> - rc = -ENOMEM;
> - goto out;
> - }
> + if (!trans_pgd)
> + return -ENOMEM;
>
> pgdp = pgd_offset_raw(trans_pgd, dst_addr);
> if (pgd_none(READ_ONCE(*pgdp))) {
> pudp = (void *)get_safe_page(GFP_ATOMIC);
> - if (!pudp) {
> - rc = -ENOMEM;
> - goto out;
> - }
> + if (!pudp)
> + return -ENOMEM;
> pgd_populate(&init_mm, pgdp, pudp);
> }
>
> pudp = pud_offset(pgdp, dst_addr);
> if (pud_none(READ_ONCE(*pudp))) {
> pmdp = (void *)get_safe_page(GFP_ATOMIC);
> - if (!pmdp) {
> - rc = -ENOMEM;
> - goto out;
> - }
> + if (!pmdp)
> + return -ENOMEM;
> pud_populate(&init_mm, pudp, pmdp);
> }
>
> pmdp = pmd_offset(pudp, dst_addr);
> if (pmd_none(READ_ONCE(*pmdp))) {
> ptep = (void *)get_safe_page(GFP_ATOMIC);
> - if (!ptep) {
> - rc = -ENOMEM;
> - goto out;
> - }
> + if (!ptep)
> + return -ENOMEM;
> pmd_populate_kernel(&init_mm, pmdp, ptep);
> }
>
> @@ -272,8 +261,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
>
> *phys_dst_addr = virt_to_phys((void *)dst);
>
> -out:
> - return rc;
> + return 0;
> }
>
> #define dcache_clean_range(start, end) __flush_dcache_area(start, (end - start))
>
_______________________________________________
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 v4 10/17] arm64: trans_pgd: make trans_pgd_map_page generic
From: Matthias Brugger @ 2019-09-10 8:29 UTC (permalink / raw)
To: Pavel Tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-arm-kernel, marc.zyngier,
james.morse, vladimir.murzin, bhsharma, linux-mm, mark.rutland
In-Reply-To: <20190909181221.309510-11-pasha.tatashin@soleen.com>
Bikeshedding alarm, please see below.
On 09/09/2019 20:12, Pavel Tatashin wrote:
> kexec is going to use a different allocator, so make
> trans_pgd_map_page to accept allocator as an argument, and also
> kexec is going to use a different map protection, so also pass
> it via argument.
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> ---
> arch/arm64/include/asm/trans_pgd.h | 24 ++++++++++++++++++++++--
> arch/arm64/kernel/hibernate.c | 12 +++++++++++-
> arch/arm64/mm/trans_pgd.c | 17 +++++++++++------
> 3 files changed, 44 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/include/asm/trans_pgd.h b/arch/arm64/include/asm/trans_pgd.h
> index c7b5402b7d87..53f67ec84cdc 100644
> --- a/arch/arm64/include/asm/trans_pgd.h
> +++ b/arch/arm64/include/asm/trans_pgd.h
> @@ -11,10 +11,30 @@
> #include <linux/bits.h>
> #include <asm/pgtable-types.h>
>
> +/*
> + * trans_alloc_page
> + * - Allocator that should return exactly one zeroed page, if this
> + * allocator fails, trans_pgd returns -ENOMEM error.
> + *
> + * trans_alloc_arg
> + * - Passed to trans_alloc_page as an argument
> + */
> +
> +struct trans_pgd_info {
> + void * (*trans_alloc_page)(void *arg);
> + void *trans_alloc_arg;
> +};
> +
> int trans_pgd_create_copy(pgd_t **dst_pgdp, unsigned long start,
> unsigned long end);
>
> -int trans_pgd_map_page(pgd_t *trans_pgd, void *page, unsigned long dst_addr,
> - pgprot_t pgprot);
> +/*
> + * Add map entry to trans_pgd for a base-size page at PTE level.
> + * page: page to be mapped.
> + * dst_addr: new VA address for the pages
> + * pgprot: protection for the page.
For consistency please describe all function parameters. From my experience
function parameter description is normally done in the C-file that implements
the logic. Don't ask me why.
> + */
> +int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
> + void *page, unsigned long dst_addr, pgprot_t pgprot);
>
> #endif /* _ASM_TRANS_TABLE_H */
> diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> index 94ede33bd777..9b75b680ab70 100644
> --- a/arch/arm64/kernel/hibernate.c
> +++ b/arch/arm64/kernel/hibernate.c
> @@ -179,6 +179,12 @@ int arch_hibernation_header_restore(void *addr)
> }
> EXPORT_SYMBOL(arch_hibernation_header_restore);
>
> +static void *
> +hibernate_page_alloc(void *arg)
AFAICS no new line needed here.
> +{
> + return (void *)get_safe_page((gfp_t)(unsigned long)arg);
> +}
> +
> /*
> * Copies length bytes, starting at src_start into an new page,
> * perform cache maintenance, then maps it at the specified address low
> @@ -195,6 +201,10 @@ static int create_safe_exec_page(void *src_start, size_t length,
> unsigned long dst_addr,
> phys_addr_t *phys_dst_addr)
> {
> + struct trans_pgd_info trans_info = {
> + .trans_alloc_page = hibernate_page_alloc,
> + .trans_alloc_arg = (void *)GFP_ATOMIC,
> + };
New line between end of struct and other variables.
With these changes:
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
> void *page = (void *)get_safe_page(GFP_ATOMIC);
> pgd_t *trans_pgd;
> int rc;
> @@ -209,7 +219,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
> if (!trans_pgd)
> return -ENOMEM;
>
> - rc = trans_pgd_map_page(trans_pgd, page, dst_addr,
> + rc = trans_pgd_map_page(&trans_info, trans_pgd, page, dst_addr,
> PAGE_KERNEL_EXEC);
> if (rc)
> return rc;
> diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c
> index 5ac712b92439..7521d558a0b9 100644
> --- a/arch/arm64/mm/trans_pgd.c
> +++ b/arch/arm64/mm/trans_pgd.c
> @@ -25,6 +25,11 @@
> #include <linux/mm.h>
> #include <linux/mmzone.h>
>
> +static void *trans_alloc(struct trans_pgd_info *info)
> +{
> + return info->trans_alloc_page(info->trans_alloc_arg);
> +}
> +
> static void _copy_pte(pte_t *dst_ptep, pte_t *src_ptep, unsigned long addr)
> {
> pte_t pte = READ_ONCE(*src_ptep);
> @@ -180,8 +185,8 @@ int trans_pgd_create_copy(pgd_t **dst_pgdp, unsigned long start,
> return rc;
> }
>
> -int trans_pgd_map_page(pgd_t *trans_pgd, void *page, unsigned long dst_addr,
> - pgprot_t pgprot)
> +int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
> + void *page, unsigned long dst_addr, pgprot_t pgprot)
> {
> pgd_t *pgdp;
> pud_t *pudp;
> @@ -190,7 +195,7 @@ int trans_pgd_map_page(pgd_t *trans_pgd, void *page, unsigned long dst_addr,
>
> pgdp = pgd_offset_raw(trans_pgd, dst_addr);
> if (pgd_none(READ_ONCE(*pgdp))) {
> - pudp = (void *)get_safe_page(GFP_ATOMIC);
> + pudp = trans_alloc(info);
> if (!pudp)
> return -ENOMEM;
> pgd_populate(&init_mm, pgdp, pudp);
> @@ -198,7 +203,7 @@ int trans_pgd_map_page(pgd_t *trans_pgd, void *page, unsigned long dst_addr,
>
> pudp = pud_offset(pgdp, dst_addr);
> if (pud_none(READ_ONCE(*pudp))) {
> - pmdp = (void *)get_safe_page(GFP_ATOMIC);
> + pmdp = trans_alloc(info);
> if (!pmdp)
> return -ENOMEM;
> pud_populate(&init_mm, pudp, pmdp);
> @@ -206,14 +211,14 @@ int trans_pgd_map_page(pgd_t *trans_pgd, void *page, unsigned long dst_addr,
>
> pmdp = pmd_offset(pudp, dst_addr);
> if (pmd_none(READ_ONCE(*pmdp))) {
> - ptep = (void *)get_safe_page(GFP_ATOMIC);
> + ptep = trans_alloc(info);
> if (!ptep)
> return -ENOMEM;
> pmd_populate_kernel(&init_mm, pmdp, ptep);
> }
>
> ptep = pte_offset_kernel(pmdp, dst_addr);
> - set_pte(ptep, pfn_pte(virt_to_pfn(page), PAGE_KERNEL_EXEC));
> + set_pte(ptep, pfn_pte(virt_to_pfn(page), pgprot));
>
> return 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: [RFC PATCH 1/2] dt-bindings: pwm: Convert PWM bindings to json-schema
From: Rob Herring @ 2019-09-10 8:33 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, Linux PWM List, linux-samsung-soc, Maciej Falkowski,
devicetree, linux-kernel@vger.kernel.org, Thierry Reding,
Linux LED Subsystem, linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190909183436.9045-1-krzk@kernel.org>
On Mon, Sep 9, 2019 at 7:35 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Convert generic PWM bindings to DT schema format using json-schema. The
> consumer bindings are split to separate file.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> .../devicetree/bindings/clock/pwm-clock.txt | 2 +-
> .../bindings/display/bridge/ti,sn65dsi86.txt | 2 +-
> .../devicetree/bindings/display/ssd1307fb.txt | 2 +-
> .../bindings/leds/backlight/pwm-backlight.txt | 2 +-
> .../devicetree/bindings/leds/leds-pwm.txt | 2 +-
> .../devicetree/bindings/mfd/max77693.txt | 2 +-
> .../bindings/pwm/atmel-hlcdc-pwm.txt | 2 +-
> .../devicetree/bindings/pwm/atmel-pwm.txt | 2 +-
> .../devicetree/bindings/pwm/atmel-tcb-pwm.txt | 2 +-
> .../bindings/pwm/brcm,bcm7038-pwm.txt | 2 +-
> .../bindings/pwm/brcm,iproc-pwm.txt | 2 +-
> .../devicetree/bindings/pwm/brcm,kona-pwm.txt | 2 +-
> .../devicetree/bindings/pwm/img-pwm.txt | 2 +-
> .../devicetree/bindings/pwm/imx-pwm.txt | 2 +-
> .../devicetree/bindings/pwm/imx-tpm-pwm.txt | 2 +-
> .../bindings/pwm/lpc1850-sct-pwm.txt | 2 +-
> .../devicetree/bindings/pwm/mxs-pwm.txt | 2 +-
> .../bindings/pwm/nvidia,tegra20-pwm.txt | 2 +-
> .../bindings/pwm/nxp,pca9685-pwm.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-bcm2835.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-berlin.txt | 2 +-
> .../bindings/pwm/pwm-consumers.yaml | 76 +++++++++++++++++++
> .../devicetree/bindings/pwm/pwm-fsl-ftm.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-hibvt.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-lp3943.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-mediatek.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-meson.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 2 +-
> .../bindings/pwm/pwm-omap-dmtimer.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-rockchip.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-sifive.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-stm32-lp.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-stm32.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-tiecap.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-tiehrpwm.txt | 2 +-
> .../devicetree/bindings/pwm/pwm-zx.txt | 2 +-
> Documentation/devicetree/bindings/pwm/pwm.txt | 69 -----------------
> .../devicetree/bindings/pwm/pwm.yaml | 30 ++++++++
> .../bindings/pwm/renesas,pwm-rcar.txt | 2 +-
> .../bindings/pwm/renesas,tpu-pwm.txt | 4 +-
> .../devicetree/bindings/pwm/spear-pwm.txt | 2 +-
> .../devicetree/bindings/pwm/st,stmpe-pwm.txt | 2 +-
> .../devicetree/bindings/pwm/ti,twl-pwm.txt | 2 +-
> .../devicetree/bindings/pwm/ti,twl-pwmled.txt | 2 +-
> .../devicetree/bindings/pwm/vt8500-pwm.txt | 2 +-
> .../bindings/regulator/pwm-regulator.txt | 2 +-
> .../devicetree/bindings/timer/ingenic,tcu.txt | 2 +-
We've been leaving the .txt file with a reference to the schema file
to avoid doing all the updates. But as you've done it already, that's
good.
> 47 files changed, 151 insertions(+), 114 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-consumers.yaml
> delete mode 100644 Documentation/devicetree/bindings/pwm/pwm.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm.yaml
[...]
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-consumers.yaml b/Documentation/devicetree/bindings/pwm/pwm-consumers.yaml
> new file mode 100644
> index 000000000000..39c844fe6338
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-consumers.yaml
We already have a PWM consumer schema in dt-schema repository. It
doesn't have the descriptions because we need permission to relicense.
My aim is to have all common schema in the dt-schema repo, but we have
a mixture because of needing to relicense.
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/pwm-consumers.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Specifying PWM information for devices
> +
> +maintainers:
> + - Thierry Reding <thierry.reding@gmail.com>
> +
> +description: |
> + PWM properties should be named "pwms". The exact meaning of each pwms
> + property must be documented in the device tree binding for each device.
> + An optional property "pwm-names" may contain a list of strings to label
> + each of the PWM devices listed in the "pwms" property. If no "pwm-names"
> + property is given, the name of the user node will be used as fallback.
> +
> + Drivers for devices that use more than a single PWM device can use the
> + "pwm-names" property to map the name of the PWM device requested by the
> + pwm_get() call to an index into the list given by the "pwms" property.
> +
> +properties:
> + pwms:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + description: |
> + Phandle to PWM controller node and pwm-specifier (controller specific).
> + pwm-specifier typically encodes the chip-relative PWM number and the PWM
> + period in nanoseconds.
> + Optionally, the pwm-specifier can encode a number of flags (defined in
> + <dt-bindings/pwm/pwm.h>) in a third cell:
> + - PWM_POLARITY_INVERTED: invert the PWM signal polarity
> +
> + pwm-names:
> + $ref: /schemas/types.yaml#/definitions/string-array
> + description:
> + A list of strings to label each of the PWM devices listed in the "pwms"
> + property. If no "pwm-names" property is given, the name of the user node
> + will be used as fallback.
> +
> +required:
> + - pwms
Doing this means every consumer has to include this file where as I do
'select: true' some every occurrence of these properties is checked.
We're generally only including other schema on the provider side.
> +
> +dependencies:
> + pwm-names: [ pwms ]
> +
> +examples:
> + - |
> + // The following example could be used to describe a PWM-based
> + // backlight device:
> +
> + pwm: pwm {
> + #pwm-cells = <2>;
> + };
> +
> + bl: backlight {
> + pwms = <&pwm 0 5000000>;
> + pwm-names = "backlight";
> + };
> +
> + // Note that in the example above, specifying the "pwm-names" is redundant
> + // because the name "backlight" would be used as fallback anyway.
> +
> + - |
> + // Example with optional PWM specifier for inverse polarity
> +
> + #include <dt-bindings/pwm/pwm.h>
> +
> + pwm2: pwm {
> + #pwm-cells = <3>;
> + };
> +
> + backlight {
> + pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
> + pwm-names = "backlight";
> + };
> diff --git a/Documentation/devicetree/bindings/pwm/pwm.yaml b/Documentation/devicetree/bindings/pwm/pwm.yaml
> new file mode 100644
> index 000000000000..5d8029f11ccc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm.yaml
> @@ -0,0 +1,30 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/pwm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PWM controllers (providers)
> +
> +maintainers:
> + - Thierry Reding <thierry.reding@gmail.com>
> +
> +properties:
> + $nodename:
> + pattern: "^pwm(@.*)?$"
Copy the pattern for spi. We allow for 'pwm-[0-9]' for cases like GPIO PWMs.
> +
> + "#pwm-cells":
> + $ref: /schemas/types.yaml#/definitions/uint32
You don't actually need to define the type as we already have for '#.*-cells'
> + description:
> + Number of cells in a PWM specifier.
> +
> +required:
> + - "#pwm-cells"
> +
> +examples:
> + - |
> + pwm: pwm@7000a000 {
> + compatible = "nvidia,tegra20-pwm";
> + reg = <0x7000a000 0x100>;
> + #pwm-cells = <2>;
> + };
_______________________________________________
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: imx7-mipi-csis: make array 'registers' static const, makes object smaller
From: Rui Miguel Silva @ 2019-09-10 8:43 UTC (permalink / raw)
To: Colin King
Cc: devel, Greg Kroah-Hartman, Sascha Hauer, kernel-janitors,
linux-kernel, Philipp Zabel, Steve Longerbeam,
Mauro Carvalho Chehab, Shawn Guo, linux-arm-kernel, linux-media
In-Reply-To: <20190906150823.30859-1-colin.king@canonical.com>
Hi Colin,
Thanks for the patch.
On Fri 06 Sep 2019 at 16:08, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Don't populate the array 'registers' on the stack but instead make it
> static const. Makes the object code smaller by 10 bytes.
>
>
> Before:
> text data bss dec hex filename
> 20138 5196 128 25462 6376 staging/media/imx/imx7-mipi-csis.o
>
> After:
> text data bss dec hex filename
> 20032 5292 128 25452 636c staging/media/imx/imx7-mipi-csis.o
>
> (gcc version 9.2.1, amd64)
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Looks very good to me.
Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com>
Cheers,
Rui
> ---
> drivers/staging/media/imx/imx7-mipi-csis.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
> index 73d8354e618c..f8a97b7e2535 100644
> --- a/drivers/staging/media/imx/imx7-mipi-csis.c
> +++ b/drivers/staging/media/imx/imx7-mipi-csis.c
> @@ -293,7 +293,7 @@ static int mipi_csis_dump_regs(struct csi_state *state)
> struct device *dev = &state->pdev->dev;
> unsigned int i;
> u32 cfg;
> - struct {
> + static const struct {
> u32 offset;
> const char * const name;
> } registers[] = {
_______________________________________________
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 1/2] dt-bindings: pwm: Convert PWM bindings to json-schema
From: Krzysztof Kozlowski @ 2019-09-10 8:43 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Linux PWM List, linux-samsung-soc, Maciej Falkowski,
devicetree, linux-kernel@vger.kernel.org, Thierry Reding,
Linux LED Subsystem, linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqJpZ-64Y7p1w5ctMwbjdftQPLjeh3XRHkBeS6tfYY0a+A@mail.gmail.com>
On Tue, 10 Sep 2019 at 10:33, Rob Herring <robh+dt@kernel.org> wrote:
>
> On Mon, Sep 9, 2019 at 7:35 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > Convert generic PWM bindings to DT schema format using json-schema. The
> > consumer bindings are split to separate file.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > ---
> > .../devicetree/bindings/clock/pwm-clock.txt | 2 +-
> > .../bindings/display/bridge/ti,sn65dsi86.txt | 2 +-
> > .../devicetree/bindings/display/ssd1307fb.txt | 2 +-
> > .../bindings/leds/backlight/pwm-backlight.txt | 2 +-
> > .../devicetree/bindings/leds/leds-pwm.txt | 2 +-
> > .../devicetree/bindings/mfd/max77693.txt | 2 +-
> > .../bindings/pwm/atmel-hlcdc-pwm.txt | 2 +-
> > .../devicetree/bindings/pwm/atmel-pwm.txt | 2 +-
> > .../devicetree/bindings/pwm/atmel-tcb-pwm.txt | 2 +-
> > .../bindings/pwm/brcm,bcm7038-pwm.txt | 2 +-
> > .../bindings/pwm/brcm,iproc-pwm.txt | 2 +-
> > .../devicetree/bindings/pwm/brcm,kona-pwm.txt | 2 +-
> > .../devicetree/bindings/pwm/img-pwm.txt | 2 +-
> > .../devicetree/bindings/pwm/imx-pwm.txt | 2 +-
> > .../devicetree/bindings/pwm/imx-tpm-pwm.txt | 2 +-
> > .../bindings/pwm/lpc1850-sct-pwm.txt | 2 +-
> > .../devicetree/bindings/pwm/mxs-pwm.txt | 2 +-
> > .../bindings/pwm/nvidia,tegra20-pwm.txt | 2 +-
> > .../bindings/pwm/nxp,pca9685-pwm.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-bcm2835.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-berlin.txt | 2 +-
> > .../bindings/pwm/pwm-consumers.yaml | 76 +++++++++++++++++++
> > .../devicetree/bindings/pwm/pwm-fsl-ftm.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-hibvt.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-lp3943.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-mediatek.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-meson.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 2 +-
> > .../bindings/pwm/pwm-omap-dmtimer.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-rockchip.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-sifive.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-stm32-lp.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-stm32.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-tiecap.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-tiehrpwm.txt | 2 +-
> > .../devicetree/bindings/pwm/pwm-zx.txt | 2 +-
> > Documentation/devicetree/bindings/pwm/pwm.txt | 69 -----------------
> > .../devicetree/bindings/pwm/pwm.yaml | 30 ++++++++
> > .../bindings/pwm/renesas,pwm-rcar.txt | 2 +-
> > .../bindings/pwm/renesas,tpu-pwm.txt | 4 +-
> > .../devicetree/bindings/pwm/spear-pwm.txt | 2 +-
> > .../devicetree/bindings/pwm/st,stmpe-pwm.txt | 2 +-
> > .../devicetree/bindings/pwm/ti,twl-pwm.txt | 2 +-
> > .../devicetree/bindings/pwm/ti,twl-pwmled.txt | 2 +-
> > .../devicetree/bindings/pwm/vt8500-pwm.txt | 2 +-
> > .../bindings/regulator/pwm-regulator.txt | 2 +-
> > .../devicetree/bindings/timer/ingenic,tcu.txt | 2 +-
>
> We've been leaving the .txt file with a reference to the schema file
> to avoid doing all the updates. But as you've done it already, that's
> good.
>
> > 47 files changed, 151 insertions(+), 114 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-consumers.yaml
> > delete mode 100644 Documentation/devicetree/bindings/pwm/pwm.txt
> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm.yaml
>
> [...]
>
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-consumers.yaml b/Documentation/devicetree/bindings/pwm/pwm-consumers.yaml
> > new file mode 100644
> > index 000000000000..39c844fe6338
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-consumers.yaml
>
> We already have a PWM consumer schema in dt-schema repository. It
> doesn't have the descriptions because we need permission to relicense.
> My aim is to have all common schema in the dt-schema repo, but we have
> a mixture because of needing to relicense.
I forgot to check it. In such case the pwm-consumers here do not offer
much more, except some description and examples. I guess it can be
just dropped then?
> > @@ -0,0 +1,76 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pwm/pwm-consumers.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Specifying PWM information for devices
> > +
> > +maintainers:
> > + - Thierry Reding <thierry.reding@gmail.com>
> > +
> > +description: |
> > + PWM properties should be named "pwms". The exact meaning of each pwms
> > + property must be documented in the device tree binding for each device.
> > + An optional property "pwm-names" may contain a list of strings to label
> > + each of the PWM devices listed in the "pwms" property. If no "pwm-names"
> > + property is given, the name of the user node will be used as fallback.
> > +
> > + Drivers for devices that use more than a single PWM device can use the
> > + "pwm-names" property to map the name of the PWM device requested by the
> > + pwm_get() call to an index into the list given by the "pwms" property.
> > +
> > +properties:
> > + pwms:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > + description: |
> > + Phandle to PWM controller node and pwm-specifier (controller specific).
> > + pwm-specifier typically encodes the chip-relative PWM number and the PWM
> > + period in nanoseconds.
> > + Optionally, the pwm-specifier can encode a number of flags (defined in
> > + <dt-bindings/pwm/pwm.h>) in a third cell:
> > + - PWM_POLARITY_INVERTED: invert the PWM signal polarity
> > +
> > + pwm-names:
> > + $ref: /schemas/types.yaml#/definitions/string-array
> > + description:
> > + A list of strings to label each of the PWM devices listed in the "pwms"
> > + property. If no "pwm-names" property is given, the name of the user node
> > + will be used as fallback.
> > +
> > +required:
> > + - pwms
>
> Doing this means every consumer has to include this file where as I do
> 'select: true' some every occurrence of these properties is checked.
> We're generally only including other schema on the provider side.
>
> > +
> > +dependencies:
> > + pwm-names: [ pwms ]
> > +
> > +examples:
> > + - |
> > + // The following example could be used to describe a PWM-based
> > + // backlight device:
> > +
> > + pwm: pwm {
> > + #pwm-cells = <2>;
> > + };
> > +
> > + bl: backlight {
> > + pwms = <&pwm 0 5000000>;
> > + pwm-names = "backlight";
> > + };
> > +
> > + // Note that in the example above, specifying the "pwm-names" is redundant
> > + // because the name "backlight" would be used as fallback anyway.
> > +
> > + - |
> > + // Example with optional PWM specifier for inverse polarity
> > +
> > + #include <dt-bindings/pwm/pwm.h>
> > +
> > + pwm2: pwm {
> > + #pwm-cells = <3>;
> > + };
> > +
> > + backlight {
> > + pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
> > + pwm-names = "backlight";
> > + };
>
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm.yaml b/Documentation/devicetree/bindings/pwm/pwm.yaml
> > new file mode 100644
> > index 000000000000..5d8029f11ccc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/pwm.yaml
> > @@ -0,0 +1,30 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pwm/pwm.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: PWM controllers (providers)
> > +
> > +maintainers:
> > + - Thierry Reding <thierry.reding@gmail.com>
> > +
> > +properties:
> > + $nodename:
> > + pattern: "^pwm(@.*)?$"
>
> Copy the pattern for spi. We allow for 'pwm-[0-9]' for cases like GPIO PWMs.
Sure
>
> > +
> > + "#pwm-cells":
> > + $ref: /schemas/types.yaml#/definitions/uint32
>
> You don't actually need to define the type as we already have for '#.*-cells'
OK.
Best regards,
Krzysztof
_______________________________________________
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 0/4] gpio: API boundary cleanups
From: Bartosz Golaszewski @ 2019-09-10 8:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-devicetree, Linus Walleij, LKML, linux-gpio, Rob Herring,
Frank Rowand, arm-soc
In-Reply-To: <20190906084539.21838-1-geert+renesas@glider.be>
pt., 6 wrz 2019 o 10:45 Geert Uytterhoeven <geert+renesas@glider.be> napisał(a):
>
> Hi Linus, Bartosz,
>
> This patch series contains various API boundary cleanups for gpiolib:
> - The first two patches make two functions private,
> - The last two patches switch the remaining gpiolib exported functions
> from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL().
>
> After this there is only a single GPIO driver function exported with
> EXPORT_SYMBOL();
>
> drivers/gpio/gpio-htc-egpio.c:EXPORT_SYMBOL(htc_egpio_get_wakeup_irq);
>
> I believe this symbol was never used upstream, and may be a relic of the
> original out-of-tree code the htc-egpio was based on. I don't know if
> there (still) exist out-of-tree users of the symbol.
>
> Thanks for your comments!
All looks good to me. Are you fine with this being picked up after the
v5.4 merge window?
Bart
>
> Geert Uytterhoeven (4):
> gpio: of: Make of_get_named_gpiod_flags() private
> gpio: of: Make of_gpio_simple_xlate() private
> gpio: of: Switch to EXPORT_SYMBOL_GPL()
> gpio: devres: Switch to EXPORT_SYMBOL_GPL()
>
> drivers/gpio/gpiolib-devres.c | 28 ++++++++++++++--------------
> drivers/gpio/gpiolib-of.c | 16 ++++++++--------
> drivers/gpio/gpiolib-of.h | 7 -------
> include/linux/of_gpio.h | 11 -----------
> 4 files changed, 22 insertions(+), 40 deletions(-)
>
> --
> 2.17.1
>
> 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
* [PATCH] aarch64/mm: speedup memory initialisation
From: Hubert Ralf @ 2019-09-10 8:59 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org; +Cc: Hubert Ralf
On ARM64 memmap_init_zone is used during bootmem_init, which iterates over
all pages in the memory starting at the lowest address until the highest
address is reached. On arm64 this ends up in searching a memmory region
containing for each single page between lowest and highest available
physicall address.
Having a sparse memory system there may be some big holes in the
memory map. For each page in this holes a lookup is done, which is
implemented as a binary search on the available memory blocks.
Adding a memmap_init for aarch64 to do the init only for the available
memory areas reduces the time needed for initialising memory on startup.
On a Renesas R-CAR M3 based system with a total hole of 20GB bootmem_init
execution time is reduced from 378ms to 84ms.
Signed-off-by: Ralf Hubert <ralf.hubert@preh.de>
---
arch/arm64/include/asm/pgtable.h | 7 +++++++
arch/arm64/mm/init.c | 24 ++++++++++++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e09760ece844..8c6eefc08b0b 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -298,6 +298,13 @@ static inline int pte_same(pte_t pte_a, pte_t pte_b)
return (lhs == rhs);
}
+#ifdef CONFIG_SPARSEMEM
+/* arch mem_map init routine is needed due to holes in a memmap */
+# define __HAVE_ARCH_MEMMAP_INIT
+ void memmap_init(unsigned long size, int nid, unsigned long zone,
+ unsigned long start_pfn);
+#endif /* CONFIG_SPARSEMEM */
+
/*
* Huge pte definitions.
*/
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3c795278def..206b28310872 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -250,6 +250,30 @@ int pfn_valid(unsigned long pfn)
}
EXPORT_SYMBOL(pfn_valid);
+#ifdef CONFIG_SPARSEMEM
+void __meminit
+memmap_init(unsigned long size, int nid, unsigned long zone,
+ unsigned long start_pfn)
+{
+ struct memblock_region *reg;
+
+ for_each_memblock(memory, reg) {
+ unsigned long start = memblock_region_memory_base_pfn(reg);
+ unsigned long end = memblock_region_memory_end_pfn(reg);
+
+ if (start < start_pfn)
+ start = start_pfn;
+ if (end > start_pfn + size)
+ end = start_pfn + size;
+
+ if (start < end) {
+ memmap_init_zone(end - start, nid, zone, start,
+ MEMMAP_EARLY, NULL);
+ }
+ }
+}
+#endif /* CONFIG_SPARSEMEM */
+
static phys_addr_t memory_limit = PHYS_ADDR_MAX;
/*
--
2.23.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 0/4] gpio: API boundary cleanups
From: Geert Uytterhoeven @ 2019-09-10 8:59 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-devicetree, Geert Uytterhoeven, Linus Walleij, LKML,
linux-gpio, Rob Herring, Frank Rowand, arm-soc
In-Reply-To: <CAMpxmJVrQ92+ULRrzyN52LwEcdPTuK7OZssZjUcRPRSTBQ=fwg@mail.gmail.com>
Hi Bartosz,
On Tue, Sep 10, 2019 at 10:51 AM Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> pt., 6 wrz 2019 o 10:45 Geert Uytterhoeven <geert+renesas@glider.be> napisał(a):
> > This patch series contains various API boundary cleanups for gpiolib:
> > - The first two patches make two functions private,
> > - The last two patches switch the remaining gpiolib exported functions
> > from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL().
> >
> > After this there is only a single GPIO driver function exported with
> > EXPORT_SYMBOL();
> >
> > drivers/gpio/gpio-htc-egpio.c:EXPORT_SYMBOL(htc_egpio_get_wakeup_irq);
> >
> > I believe this symbol was never used upstream, and may be a relic of the
> > original out-of-tree code the htc-egpio was based on. I don't know if
> > there (still) exist out-of-tree users of the symbol.
> >
> > Thanks for your comments!
>
> All looks good to me. Are you fine with this being picked up after the
> v5.4 merge window?
Sure, whatever suits you best.
Thanks!
> > Geert Uytterhoeven (4):
> > gpio: of: Make of_get_named_gpiod_flags() private
> > gpio: of: Make of_gpio_simple_xlate() private
> > gpio: of: Switch to EXPORT_SYMBOL_GPL()
> > gpio: devres: Switch to EXPORT_SYMBOL_GPL()
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 v4 04/17] arm64: hibernate: use get_safe_page directly
From: Pavel Tatashin @ 2019-09-10 9:10 UTC (permalink / raw)
To: Matthias Brugger
Cc: Sasha Levin, Mark Rutland, Vladimir Murzin, Jonathan Corbet,
Marc Zyngier, Catalin Marinas, Bhupesh Sharma, kexec mailing list,
LKML, James Morris, linux-mm, James Morse, Eric W. Biederman,
will, Linux ARM
In-Reply-To: <e2ceb43a-d7bf-e0c6-c3ea-b83c95ba880d@suse.com>
> On 09/09/2019 20:12, Pavel Tatashin wrote:
> > create_safe_exec_page() uses hibernate's allocator to create a set of page
> > table to map a single page that will contain the relocation code.
> >
> > Remove the allocator related arguments, and use get_safe_page directly, as
> > it is done in other local functions in this file to simplify function
> > prototype.
> >
> > Removing this function pointer makes it easier to refactor the code later.
> >
> > Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
>
> Reviewed-by: Matthias Brugger <mbrugger@suse.com>
>
Thank you
_______________________________________________
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 6/6] arm64: dts: khadas-vim3: add commented support for PCIe
From: Marc Zyngier @ 2019-09-10 9:12 UTC (permalink / raw)
To: Neil Armstrong
Cc: lorenzo.pieralisi, khilman, linux-kernel, kishon, repk, linux-pci,
bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <2c25e8b5-191f-96c9-8989-23959a7b1c4e@baylibre.com>
On Mon, 09 Sep 2019 18:50:42 +0100,
Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Hi Marc,
>
> Le 09/09/2019 à 18:37, Marc Zyngier a écrit :
> > On Sun, 08 Sep 2019 14:42:58 +0100,
> > Neil Armstrong <narmstrong@baylibre.com> wrote:
> >>
> >> The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> >> lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> >> an USB3.0 Type A connector and a M.2 Key M slot.
> >> The PHY driving these differential lines is shared between
> >> the USB3.0 controller and the PCIe Controller, thus only
> >> a single controller can use it.
> >>
> >> The needed DT configuration when the MCU is configured to mux
> >> the PCIe/USB3.0 differential lines to the M.2 Key M slot is
> >> added commented and may uncommented to disable USB3.0 from the
> >> USB Complex and enable the PCIe controller.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >> .../amlogic/meson-g12b-a311d-khadas-vim3.dts | 22 +++++++++++++++++++
> >> .../amlogic/meson-g12b-s922x-khadas-vim3.dts | 22 +++++++++++++++++++
> >> .../boot/dts/amlogic/meson-khadas-vim3.dtsi | 4 ++++
> >> .../dts/amlogic/meson-sm1-khadas-vim3l.dts | 22 +++++++++++++++++++
> >> 4 files changed, 70 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> index 3a6a1e0c1e32..0577b1435cbb 100644
> >> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> @@ -14,3 +14,25 @@
> >> / {
> >> compatible = "khadas,vim3", "amlogic,a311d", "amlogic,g12b";
> >> };
> >> +
> >> +/*
> >> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> >> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> >> + * an USB3.0 Type A connector and a M.2 Key M slot.
> >> + * The PHY driving these differential lines is shared between
> >> + * the USB3.0 controller and the PCIe Controller, thus only
> >> + * a single controller can use it.
> >> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
> >> + * to the M.2 Key M slot, uncomment the following block to disable
> >> + * USB3.0 from the USB Complex and enable the PCIe controller.
> >> + */
> >> +/*
> >> +&pcie {
> >> + status = "okay";
> >> +};
> >> +
> >> +&usb {
> >> + phys = <&usb2_phy0>, <&usb2_phy1>;
> >> + phy-names = "usb2-phy0", "usb2-phy1";
> >> +};
> >> + */
> >
> > Although you can't do much more than this here, I'd expect firmware on
> > the machine to provide the DT that matches its configuration. Is it
> > the way it actually works? Or is the user actually expected to edit
> > this file?
>
> It's the plan when initial VIM3 support will be merged in u-boot mainline,
> and the MCU driver will be added aswell :
> https://patchwork.ozlabs.org/cover/1156618/
> A custom board support altering the DT will be added when this patchset
> is merged upstream.
>
> But since these are separate projects, leaving this as commented is ugly,
> but necessary.
I agree with the unfortunate necessity. However, could you please have
a comment here, indicating that the user isn't expected to change this
on their own, but instead rely on the firmware/bootloader to do it
accordingly?
Thanks,
M.
--
Jazz is not dead, it just smells funny.
_______________________________________________
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