* [PATCH 4/8] soc: ti: omap-prm: add support for denying idle for reset clockdomain
From: Tero Kristo @ 2019-08-07 7:48 UTC (permalink / raw)
To: ssantosh, linux-arm-kernel, linux-omap, robh+dt; +Cc: tony, devicetree
In-Reply-To: <1565164139-21886-1-git-send-email-t-kristo@ti.com>
TI SoCs hardware reset signals require the parent clockdomain to be
in force wakeup mode while de-asserting the reset, otherwise it may
never complete. To support this, add pdata hooks to control the
clockdomain directly.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/soc/ti/omap_prm.c | 32 ++++++++++++++++++++++++++++----
include/linux/platform_data/ti-prm.h | 21 +++++++++++++++++++++
2 files changed, 49 insertions(+), 4 deletions(-)
create mode 100644 include/linux/platform_data/ti-prm.h
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index d412af3..870515e3 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -16,6 +16,8 @@
#include <linux/reset-controller.h>
#include <linux/delay.h>
+#include <linux/platform_data/ti-prm.h>
+
struct omap_rst_map {
s8 rst;
s8 st;
@@ -24,6 +26,7 @@ struct omap_rst_map {
struct omap_prm_data {
u32 base;
const char *name;
+ const char *clkdm_name;
u16 pwstctrl;
u16 pwstst;
u16 rstctl;
@@ -40,6 +43,8 @@ struct omap_prm {
struct omap_reset_data {
struct reset_controller_dev rcdev;
struct omap_prm *prm;
+ struct clockdomain *clkdm;
+ struct device *dev;
};
#define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
@@ -108,6 +113,8 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
int st_bit = id;
bool has_rstst;
int timeout = 0;
+ struct ti_prm_platform_data *pdata = dev_get_platdata(reset->dev);
+ int ret = 0;
/* check the current status to avoid de-asserting the line twice */
v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
@@ -125,13 +132,16 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
}
+ if (pdata->clkdm_deny_idle && reset->clkdm)
+ pdata->clkdm_deny_idle(reset->clkdm);
+
/* de-assert the reset control line */
v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
v &= ~(1 << id);
writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
if (!has_rstst)
- return 0;
+ goto exit;
/* wait for the status to be set */
while (1) {
@@ -140,13 +150,19 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
if (v)
break;
timeout++;
- if (timeout > OMAP_RESET_MAX_WAIT)
- return -EBUSY;
+ if (timeout > OMAP_RESET_MAX_WAIT) {
+ ret = -EBUSY;
+ goto exit;
+ }
udelay(1);
}
- return 0;
+exit:
+ if (pdata->clkdm_allow_idle && reset->clkdm)
+ pdata->clkdm_allow_idle(reset->clkdm);
+
+ return ret;
}
static const struct reset_control_ops omap_reset_ops = {
@@ -159,6 +175,8 @@ static int omap_prm_reset_probe(struct platform_device *pdev,
struct omap_prm *prm)
{
struct omap_reset_data *reset;
+ struct ti_prm_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ char buf[32];
/*
* Check if we have resets. If either rstctl or rstst is
@@ -177,9 +195,15 @@ static int omap_prm_reset_probe(struct platform_device *pdev,
reset->rcdev.ops = &omap_reset_ops;
reset->rcdev.of_node = pdev->dev.of_node;
reset->rcdev.nr_resets = OMAP_MAX_RESETS;
+ reset->dev = &pdev->dev;
reset->prm = prm;
+ sprintf(buf, "%s_clkdm", prm->data->clkdm_name ? prm->data->clkdm_name :
+ prm->data->name);
+
+ reset->clkdm = pdata->clkdm_lookup(buf);
+
return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
}
diff --git a/include/linux/platform_data/ti-prm.h b/include/linux/platform_data/ti-prm.h
new file mode 100644
index 0000000..28154c3
--- /dev/null
+++ b/include/linux/platform_data/ti-prm.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * TI PRM (Power & Reset Manager) platform data
+ *
+ * Copyright (C) 2019 Texas Instruments, Inc.
+ *
+ * Tero Kristo <t-kristo@ti.com>
+ */
+
+#ifndef _LINUX_PLATFORM_DATA_TI_PRM_H
+#define _LINUX_PLATFORM_DATA_TI_PRM_H
+
+struct clockdomain;
+
+struct ti_prm_platform_data {
+ void (*clkdm_deny_idle)(struct clockdomain *clkdm);
+ void (*clkdm_allow_idle)(struct clockdomain *clkdm);
+ struct clockdomain * (*clkdm_lookup)(const char *name);
+};
+
+#endif /* _LINUX_PLATFORM_DATA_TI_PRM_H */
--
1.9.1
--
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 related
* [PATCH 0/8] soc: ti: Add OMAP PRM driver
From: Tero Kristo @ 2019-08-07 7:48 UTC (permalink / raw)
To: ssantosh, linux-arm-kernel, linux-omap, robh+dt; +Cc: tony, devicetree
Hi,
This series adds OMAP PRM driver which initially supports only reset
handling. Later on, power domain support can be added to this to get
rid of the current OMAP power domain handling code which resides
under the mach-omap2 platform directory. Initially, reset data is
added for AM3, OMAP4 and DRA7 SoCs.
I've been testing the reset handling logic with OMAP remoteproc
driver which has been converted to use generic reset framework. This
part is a work in progress, so will be posting patches from that part
later on.
-Tero
--
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 2/8] soc: ti: add initial PRM driver with reset control support
From: Tero Kristo @ 2019-08-07 7:48 UTC (permalink / raw)
To: ssantosh, linux-arm-kernel, linux-omap, robh+dt; +Cc: tony, devicetree
In-Reply-To: <1565164139-21886-1-git-send-email-t-kristo@ti.com>
Add initial PRM (Power and Reset Management) driver for TI OMAP class
SoCs. Initially this driver only supports reset control, but can be
extended to support rest of the functionality, like powerdomain
control, PRCM irq support etc.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/omap_prm.c | 216 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 218 insertions(+)
create mode 100644 drivers/soc/ti/omap_prm.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fdb6743..42ad063 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -109,6 +109,7 @@ config ARCH_OMAP2PLUS
select TI_SYSC
select OMAP_IRQCHIP
select CLKSRC_TI_32K
+ select RESET_CONTROLLER
help
Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index b3868d3..788b5cd 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
obj-$(CONFIG_AMX3_PM) += pm33xx.o
+obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_prm.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
new file mode 100644
index 0000000..7c89eb8
--- /dev/null
+++ b/drivers/soc/ti/omap_prm.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * OMAP2+ PRM driver
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Tero Kristo <t-kristo@ti.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/delay.h>
+
+struct omap_rst_map {
+ s8 rst;
+ s8 st;
+};
+
+struct omap_prm_data {
+ u32 base;
+ const char *name;
+ u16 pwstctrl;
+ u16 pwstst;
+ u16 rstctl;
+ u16 rstst;
+ struct omap_rst_map *rstmap;
+ u8 flags;
+};
+
+struct omap_prm {
+ const struct omap_prm_data *data;
+ void __iomem *base;
+};
+
+struct omap_reset_data {
+ struct reset_controller_dev rcdev;
+ struct omap_prm *prm;
+};
+
+#define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
+
+#define OMAP_MAX_RESETS 8
+#define OMAP_RESET_MAX_WAIT 10000
+
+#define OMAP_PRM_NO_RSTST BIT(0)
+
+static const struct of_device_id omap_prm_id_table[] = {
+ { },
+};
+
+static int omap_reset_status(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct omap_reset_data *reset = to_omap_reset_data(rcdev);
+ u32 v;
+
+ v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
+ v &= 1 << id;
+ v >>= id;
+
+ return v;
+}
+
+static int omap_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct omap_reset_data *reset = to_omap_reset_data(rcdev);
+ u32 v;
+
+ /* assert the reset control line */
+ v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
+ v |= 1 << id;
+ writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
+
+ return 0;
+}
+
+static int omap_reset_get_st_bit(struct omap_reset_data *reset,
+ unsigned long id)
+{
+ struct omap_rst_map *map = reset->prm->data->rstmap;
+
+ while (map && map->rst >= 0) {
+ if (map->rst == id)
+ return map->st;
+
+ map++;
+ }
+
+ return id;
+}
+
+/*
+ * Note that status will not change until clocks are on, and clocks cannot be
+ * enabled until reset is deasserted. Consumer drivers must check status
+ * separately after enabling clocks.
+ */
+static int omap_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct omap_reset_data *reset = to_omap_reset_data(rcdev);
+ u32 v;
+ int st_bit = id;
+ bool has_rstst;
+
+ /* check the current status to avoid de-asserting the line twice */
+ v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
+ if (!(v & BIT(id)))
+ return -EEXIST;
+
+ has_rstst = !(reset->prm->data->flags & OMAP_PRM_NO_RSTST);
+
+ if (has_rstst) {
+ st_bit = omap_reset_get_st_bit(reset, id);
+
+ /* Clear the reset status by writing 1 to the status bit */
+ v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
+ v |= 1 << st_bit;
+ writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
+ }
+
+ /* de-assert the reset control line */
+ v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
+ v &= ~(1 << id);
+ writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
+
+ return 0;
+}
+
+static const struct reset_control_ops omap_reset_ops = {
+ .assert = omap_reset_assert,
+ .deassert = omap_reset_deassert,
+ .status = omap_reset_status,
+};
+
+static int omap_prm_reset_probe(struct platform_device *pdev,
+ struct omap_prm *prm)
+{
+ struct omap_reset_data *reset;
+
+ /*
+ * Check if we have resets. If either rstctl or rstst is
+ * non-zero, we have reset registers in place. Additionally
+ * the flag OMAP_PRM_NO_RSTST implies that we have resets.
+ */
+ if (!prm->data->rstctl && !prm->data->rstst &&
+ !(prm->data->flags & OMAP_PRM_NO_RSTST))
+ return 0;
+
+ reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
+ if (!reset)
+ return -ENOMEM;
+
+ reset->rcdev.owner = THIS_MODULE;
+ reset->rcdev.ops = &omap_reset_ops;
+ reset->rcdev.of_node = pdev->dev.of_node;
+ reset->rcdev.nr_resets = OMAP_MAX_RESETS;
+
+ reset->prm = prm;
+
+ return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
+}
+
+static int omap_prm_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ const struct omap_prm_data *data;
+ struct omap_prm *prm;
+ const struct of_device_id *match;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+
+ match = of_match_device(omap_prm_id_table, &pdev->dev);
+ if (!match)
+ return -ENOTSUPP;
+
+ prm = devm_kzalloc(&pdev->dev, sizeof(*prm), GFP_KERNEL);
+ if (!prm)
+ return -ENOMEM;
+
+ data = match->data;
+
+ while (data->base != res->start) {
+ if (!data->base)
+ return -EINVAL;
+ data++;
+ }
+
+ prm->data = data;
+
+ prm->base = devm_ioremap_resource(&pdev->dev, res);
+ if (!prm->base)
+ return -ENOMEM;
+
+ return omap_prm_reset_probe(pdev, prm);
+}
+
+static struct platform_driver omap_prm_driver = {
+ .probe = omap_prm_probe,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = omap_prm_id_table,
+ },
+};
+builtin_platform_driver(omap_prm_driver);
+
+MODULE_ALIAS("platform:prm");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("omap2+ prm driver");
--
1.9.1
--
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 related
* [PATCH 3/8] soc: ti: omap-prm: poll for reset complete during de-assert
From: Tero Kristo @ 2019-08-07 7:48 UTC (permalink / raw)
To: ssantosh, linux-arm-kernel, linux-omap, robh+dt; +Cc: tony, devicetree
In-Reply-To: <1565164139-21886-1-git-send-email-t-kristo@ti.com>
Poll for reset completion status during de-assertion of reset, otherwise
the IP in question might be accessed before it has left reset properly.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/soc/ti/omap_prm.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index 7c89eb8..d412af3 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -107,6 +107,7 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
u32 v;
int st_bit = id;
bool has_rstst;
+ int timeout = 0;
/* check the current status to avoid de-asserting the line twice */
v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
@@ -129,6 +130,22 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
v &= ~(1 << id);
writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
+ if (!has_rstst)
+ return 0;
+
+ /* wait for the status to be set */
+ while (1) {
+ v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
+ v &= 1 << st_bit;
+ if (v)
+ break;
+ timeout++;
+ if (timeout > OMAP_RESET_MAX_WAIT)
+ return -EBUSY;
+
+ udelay(1);
+ }
+
return 0;
}
--
1.9.1
--
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 related
* [PATCH 1/8] dt-bindings: omap: add new binding for PRM instances
From: Tero Kristo @ 2019-08-07 7:48 UTC (permalink / raw)
To: ssantosh, linux-arm-kernel, linux-omap, robh+dt; +Cc: tony, devicetree
In-Reply-To: <1565164139-21886-1-git-send-email-t-kristo@ti.com>
Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
of these will act as a power domain controller and potentially as a reset
provider.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
.../devicetree/bindings/arm/omap/prm-inst.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
new file mode 100644
index 0000000..e0ae87b
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
@@ -0,0 +1,24 @@
+OMAP PRM instance bindings
+
+Power and Reset Manager is an IP block on OMAP family of devices which
+handle the power domains and their current state, and provide reset
+handling for the domains and/or separate IP blocks under the power domain
+hierarchy.
+
+Required properties:
+- compatible: Must be one of:
+ "ti,am3-prm-inst"
+ "ti,am4-prm-inst"
+ "ti,omap4-prm-inst"
+ "ti,omap5-prm-inst"
+ "ti,dra7-prm-inst"
+- reg: Contains PRM instance register address range
+ (base address and length)
+
+Example:
+
+prm_dsp2: prm@1b00 {
+ compatible = "ti,dra7-prm-inst";
+ reg = <0x1b00 0x40>;
+ #reset-cells = <1>;
+};
--
1.9.1
--
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 related
* Re: [PATCH v3 11/41] media/v4l2-core/mm: convert put_page() to put_user_page*()
From: Sakari Ailus @ 2019-08-07 7:20 UTC (permalink / raw)
To: john.hubbard
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Ira Weiny, Dan Williams, devel, rds-devel,
linux-rdma, x86, amd-gfx, Christoph Hellwig, Jason Gunthorpe,
Hans Verkuil, xen-devel, devel, linux-media, Kees Cook,
John Hubbard, intel-gfx, linux-block, Jérôme Glisse,
linux-rpi-kernel, ceph-devel, Mauro Carvalho Chehab,
linux-arm-kernel, linux-nfs, netdev, LKML, Souptick Joarder,
linux-xfs, linux-crypto, linux-fsdevel, Andrew Morton,
Robin Murphy
In-Reply-To: <20190807013340.9706-12-jhubbard@nvidia.com>
On Tue, Aug 06, 2019 at 06:33:10PM -0700, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Hans Verkuil <hans.verkuil@cisco.com>
> Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Souptick Joarder <jrdr.linux@gmail.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: linux-media@vger.kernel.org
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
--
Sakari Ailus
sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: add touchkey nodes for midas
From: Paul Kocialkowski @ 2019-08-07 7:09 UTC (permalink / raw)
To: Denis 'GNUtoo' Carikli
Cc: Mark Rutland, Simon Shields, Rob Herring, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20190806165749.29468-1-GNUtoo@cyberdimension.org>
[-- Attachment #1.1: Type: text/plain, Size: 3914 bytes --]
Hi,
On Tue 06 Aug 19, 18:57, Denis 'GNUtoo' Carikli wrote:
> From: Simon Shields <simon@lineageos.org>
>
> this patch adds the fixed VTOUCH_3.3V regulator and configures
> the touchkey node + i2c-gpio node.
Thanks for the patch, see some comments below.
> Signed-off-by: Simon Shields <simon@lineageos.org>
> GNUtoo@cyberdimension.org: Fixed keycodes.
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
> ---
> arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi | 4 +++
> arch/arm/boot/dts/exynos4412-midas.dtsi | 29 +++++++++++++++++++++
> arch/arm/boot/dts/exynos4412-n710x.dts | 4 +++
> 3 files changed, 37 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> index ce87d2ff27aa..e71f103ab940 100644
> --- a/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> @@ -166,5 +166,9 @@
> &s5c73m3 {
> standby-gpios = <&gpm0 1 GPIO_ACTIVE_LOW>; /* ISP_STANDBY */
> vdda-supply = <&ldo17_reg>;
> +};
> +
> +&touchkey_reg {
> + gpio = <&gpm0 0 GPIO_ACTIVE_HIGH>;
> status = "okay";
It looks like status = "okay" was initially found on the s5c73m3 node. With this
change, it's no longer the case so the camera node will remain disabled.
So you probably need to duplicate status = "okay", so that it's both on
touchkey_reg and s5c73m3.
> };
> diff --git a/arch/arm/boot/dts/exynos4412-midas.dtsi b/arch/arm/boot/dts/exynos4412-midas.dtsi
> index 83be3a797411..797e8de40580 100644
> --- a/arch/arm/boot/dts/exynos4412-midas.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-midas.dtsi
> @@ -13,6 +13,7 @@
> #include "exynos4412.dtsi"
> #include "exynos4412-ppmu-common.dtsi"
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/clock/maxim,max77686.h>
> #include <dt-bindings/pinctrl/samsung.h>
> @@ -92,6 +93,15 @@
> enable-active-high;
> };
>
> + touchkey_reg: voltage-regulator-4 {
> + compatible = "regulator-fixed";
> + regulator-name = "VTOUCH_3.3V";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + enable-active-high;
> + status = "disabled";
> + };
> +
> gpio-keys {
> compatible = "gpio-keys";
> pinctrl-names = "default";
> @@ -197,6 +207,25 @@
> };
> };
>
> + i2c_touchkey: i2c-gpio-4 {
Any reason why this node is not marked as disabled here although the regulator
it depends on is?
> + compatible = "i2c-gpio";
> + sda-gpios = <&gpl0 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + scl-gpios = <&gpl0 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + i2c-gpio,delay-us = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + touchkey@20 {
> + compatible = "cypress,midas-touchkey";
> + reg = <0x20>;
> + vdd-supply = <&touchkey_reg>;
> + vcc-supply = <&ldo5_reg>;
> + interrupt-parent = <&gpj0>;
> + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> + linux,keycodes = <KEY_BACK KEY_MENU>;
> + };
> + };
> +
> i2c-mhl {
> compatible = "i2c-gpio";
> gpios = <&gpf0 4 GPIO_ACTIVE_HIGH>, <&gpf0 6 GPIO_ACTIVE_HIGH>;
> diff --git a/arch/arm/boot/dts/exynos4412-n710x.dts b/arch/arm/boot/dts/exynos4412-n710x.dts
> index fe2bfd76cc4e..6acb19d2bae2 100644
> --- a/arch/arm/boot/dts/exynos4412-n710x.dts
> +++ b/arch/arm/boot/dts/exynos4412-n710x.dts
> @@ -71,5 +71,9 @@
> &s5c73m3 {
> standby-gpios = <&gpm0 6 GPIO_ACTIVE_LOW>; /* ISP_STANDBY */
> vdda-supply = <&cam_vdda_reg>;
> +};
> +
> +&touchkey_reg {
> + gpio = <&gpm0 5 GPIO_ACTIVE_HIGH>;
> status = "okay";
And ditto about duplicating status.
Cheers,
Paul
> };
> --
> 2.22.0
>
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] drm/amdgpu: replace readq/writeq with atomic64 operations
From: Christoph Hellwig @ 2019-08-07 7:08 UTC (permalink / raw)
To: Tao Zhou
Cc: linux-arm-kernel, kernel-build-reports, amd-gfx, broonie,
linux-next, alexander.deucher, akpm, christian.koenig, dennis.li,
hawking.zhang
In-Reply-To: <20190807025640.682-1-tao.zhou1@amd.com>
On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote:
> readq/writeq are not supported on all architectures
NAK. You must not use atomic_* on __iomem (MMIO) memory.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] drm: add cache support for arm64
From: Christoph Hellwig @ 2019-08-07 6:25 UTC (permalink / raw)
To: Rob Clark
Cc: Sean Paul, Maxime Ripard, Catalin Marinas, Maarten Lankhorst,
LKML, dri-devel, David Airlie, Rob Clark, linux-arm-kernel,
Daniel Vetter, Greg Kroah-Hartman, Thomas Gleixner, Will Deacon,
Christoph Hellwig, Allison Randal
In-Reply-To: <CAJs_Fx6uztwDy2PqRy3Tc9p12k8r_ovS2tAcsMV6HqnAp=Ggug@mail.gmail.com>
On Tue, Aug 06, 2019 at 09:23:51AM -0700, Rob Clark wrote:
> On Tue, Aug 6, 2019 at 8:50 AM Christoph Hellwig <hch@lst.de> wrote:
> >
> > On Tue, Aug 06, 2019 at 07:11:41AM -0700, Rob Clark wrote:
> > > Agreed that drm_cflush_* isn't a great API. In this particular case
> > > (IIUC), I need wb+inv so that there aren't dirty cache lines that drop
> > > out to memory later, and so that I don't get a cache hit on
> > > uncached/wc mmap'ing.
> >
> > So what is the use case here? Allocate pages using the page allocator
> > (or CMA for that matter), and then mmaping them to userspace and never
> > touching them again from the kernel?
>
> Currently, it is pages coming from tmpfs. Ideally we want pages that
> are swappable when unpinned.
tmpfs is basically a (complicated) frontend for alloc pages as far
as page allocation is concerned.
> CPU mappings are *mostly* just mapping to userspace. There are a few
> exceptions that are vmap'd (fbcon, and ringbuffer).
And those use the same backend?
> (Eventually I'd like to support pages passed in from userspace.. but
> that is down the road.)
Eww. Please talk to the iommu list before starting on that.
> > > Tying it in w/ iommu seems a bit weird to me.. but maybe that is just
> > > me, I'm certainly willing to consider proposals or to try things and
> > > see how they work out.
> >
> > This was just my through as the fit seems easy. But maybe you'll
> > need to explain your use case(s) a bit more so that we can figure out
> > what a good high level API is.
>
> Tying it to iommu_map/unmap would be awkward, as we could need to
> setup cpu mmap before it ends up mapped to iommu. And the plan to
> support per-process pagetables involved creating an iommu_domain per
> userspace gl context.. some buffers would end up mapped into multiple
> contexts/iommu_domains.
>
> If the cache operation was detached from iommu_map/unmap, then it
> would seem weird to be part of the iommu API.
>
> I guess I'm not entirely sure what you had in mind, but this is why
> iommu seemed to me like a bad fit.
So back to the question, I'd like to understand your use case (and
maybe hear from the other drm folks if that is common):
- you allocate pages from shmem (why shmem, btw? if this is done by
other drm drivers how do they guarantee addressability without an
iommu?)
- then the memory is either mapped to userspace or vmapped (or even
both, althrough the lack of aliasing you mentioned would speak
against it) as writecombine (aka arm v6+ normal uncached). Does
the mapping live on until the memory is freed?
- as you mention swapping - how do you guarantee there are no
aliases in the kernel direct mapping after the page has been swapped
in?
- then the memory is potentially mapped to the iommu. Is it using
a long-living mapping, or does get unmapped/remapped repeatedly?
_______________________________________________
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] arm64: dts: allwinner: a64: Enable eMMC on A64-OLinuXino
From: Chen-Yu Tsai @ 2019-08-07 6:18 UTC (permalink / raw)
To: Martin Ayotte; +Cc: Maxime Ripard, Sunil Mohan Adapa, linux-arm-kernel
In-Reply-To: <AD4CCAA0C22145CFB1E662CF924CB239@GirolesWin7>
On Tue, Aug 6, 2019 at 8:49 PM Martin Ayotte <martinayotte@gmail.com> wrote:
>
> Just to let you know : typo in my email still there...
Duh. Fixed it now.
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4&id=8d3071f3e85894be35a1b35bcf6fdef970c81018
> -----Message d'origine-----
> De : Chen-Yu Tsai [mailto:wens@csie.org]
> Envoyé : Tuesday, August 06, 2019 2:25 AM
> À : Martin Ayotte
> Cc : Sunil Mohan Adapa; Maxime Ripard; linux-arm-kernel
> Objet : Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on
> A64-OLinuXino
>
> On Mon, Aug 5, 2019 at 8:58 PM Martin Ayotte <martinayotte@gmail.com> wrote:
> >
> > Fine for me too.
> >
> > Thanks .
> >
> > -----Message d'origine-----
> > De : Sunil Mohan Adapa [mailto:sunil@medhas.org]
> > Envoyé : Monday, August 05, 2019 1:25 AM
> > À : Chen-Yu Tsai
> > Cc : Maxime Ripard; Martin Ayotte; linux-arm-kernel
> > Objet : Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on
> > A64-OLinuXino
> >
> > On 04/08/19 8:33 pm, Chen-Yu Tsai wrote:
> > > On Fri, Aug 2, 2019 at 2:47 AM Sunil Mohan Adapa <sunil@medhas.org>
> wrote:
> > >>
> > >> On 01/08/19 6:49 am, Martin Ayotte wrote:
> > >>> If my SOB could help here, I don't mind since I've done the commit
> > >>> more than a year ago for Armbian ...
> > >>>
> > >>> Signed-off-by: Martin Ayotte <martinayotte@gmai.com>
> > >>> Tested-by: Martin Ayotte <martinayotte@gmai.com>
> > >> gmai.com is likely a typo.
> > >>
> > >>> On Wed, Jul 31, 2019 at 10:42 PM Chen-Yu Tsai <wens@csie.org
> > >>>
> > >>>> Thanks. The patch looks good overall. The authorship is a little
> > >>>> confusing though. If it was initially done by Martin (CC-ed), then
> > >>>> he should be the author, and we should get his Signed-off-by if
> > >>>> possible.
> > >>
> > >> Martin is indeed the original author of the patch. Thank you for
> > reviewing.
> > >
> > > I'd like to apply this patch with Martin as the author, if that's OK
> with
> > you
> > > both?
> >
> > That is completely okay with me.
>
> Applied for 5.4.
>
> I reordered the tags so they make more sense:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=su
> nxi/dt-for-5.4&id=0834887732df5af41b59b2e4d530fc1f5478965f
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] MIPS: remove support for DMA_ATTR_WRITE_COMBINE
From: Christoph Hellwig @ 2019-08-07 6:16 UTC (permalink / raw)
To: iommu
Cc: Shawn Anastasio, Will Deacon, Michael Ellerman, linuxppc-dev,
linux-kernel, Russell King, linux-mips, Paul Burton,
Catalin Marinas, James Hogan, Robin Murphy, linux-arm-kernel
In-Reply-To: <20190807061602.31217-1-hch@lst.de>
Mips uses the KSEG1 kernel memory segment to map dma coherent
allocations for non-coherent devices as uncacheable, and does not have
any kind of special support for DMA_ATTR_WRITE_COMBINE in the allocation
path. Thus supporting DMA_ATTR_WRITE_COMBINE in dma_mmap_attrs will
lead to multiple mappings with different caching attributes.
Fixes: 8c172467be36 ("MIPS: Add implementation of dma_map_ops.mmap()")
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/mips/Kconfig | 1 -
arch/mips/mm/dma-noncoherent.c | 8 --------
2 files changed, 9 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d50fafd7bf3a..86e6760ef0d0 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1119,7 +1119,6 @@ config DMA_PERDEV_COHERENT
config DMA_NONCOHERENT
bool
- select ARCH_HAS_DMA_MMAP_PGPROT
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_HAS_UNCACHED_SEGMENT
select NEED_DMA_MAP_STATE
diff --git a/arch/mips/mm/dma-noncoherent.c b/arch/mips/mm/dma-noncoherent.c
index ed56c6fa7be2..1d4d57dd9acf 100644
--- a/arch/mips/mm/dma-noncoherent.c
+++ b/arch/mips/mm/dma-noncoherent.c
@@ -65,14 +65,6 @@ long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
return page_to_pfn(virt_to_page(cached_kernel_address(cpu_addr)));
}
-pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
- unsigned long attrs)
-{
- if (attrs & DMA_ATTR_WRITE_COMBINE)
- return pgprot_writecombine(prot);
- return pgprot_noncached(prot);
-}
-
static inline void dma_sync_virt(void *addr, size_t size,
enum dma_data_direction dir)
{
--
2.20.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 1/2] dma-mapping: fix page attributes for dma_mmap_*
From: Christoph Hellwig @ 2019-08-07 6:16 UTC (permalink / raw)
To: iommu
Cc: Gavin Li, Shawn Anastasio, Will Deacon, Michael Ellerman,
linuxppc-dev, linux-kernel, Russell King, linux-mips, Paul Burton,
Catalin Marinas, James Hogan, Robin Murphy, linux-arm-kernel
In-Reply-To: <20190807061602.31217-1-hch@lst.de>
All the way back to introducing dma_common_mmap we've defaulted to mark
the pages as uncached. But this is wrong for DMA coherent devices.
Later on DMA_ATTR_WRITE_COMBINE also got incorrect treatment as that
flag is only treated special on the alloc side for non-coherent devices.
Introduce a new dma_pgprot helper that deals with the check for coherent
devices so that only the remapping cases ever reach arch_dma_mmap_pgprot
and we thus ensure no aliasing of page attributes happens, which makes
the powerpc version of arch_dma_mmap_pgprot obsolete and simplifies the
remaining ones.
Note that this means arch_dma_mmap_pgprot is a bit misnamed now, but
we'll phase it out soon.
Fixes: 64ccc9c033c6 ("common: dma-mapping: add support for generic dma_mmap_* calls")
Reported-by: Shawn Anastasio <shawn@anastas.io>
Reported-by: Gavin Li <git@thegavinli.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com> # arm64
---
arch/arm/mm/dma-mapping.c | 4 +---
arch/arm64/mm/dma-mapping.c | 4 +---
arch/powerpc/Kconfig | 1 -
arch/powerpc/kernel/dma-common.c | 17 -----------------
drivers/iommu/dma-iommu.c | 6 +++---
include/linux/dma-noncoherent.h | 13 +++++++++----
kernel/dma/mapping.c | 17 ++++++++++++++++-
kernel/dma/remap.c | 2 +-
8 files changed, 31 insertions(+), 33 deletions(-)
delete mode 100644 arch/powerpc/kernel/dma-common.c
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6774b03aa405..d42557ee69c2 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2405,9 +2405,7 @@ long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
unsigned long attrs)
{
- if (!dev_is_dma_coherent(dev))
- return __get_dma_pgprot(attrs, prot);
- return prot;
+ return __get_dma_pgprot(attrs, prot);
}
void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 1d3f0b5a9940..bd2b039f43a6 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -14,9 +14,7 @@
pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
unsigned long attrs)
{
- if (!dev_is_dma_coherent(dev) || (attrs & DMA_ATTR_WRITE_COMBINE))
- return pgprot_writecombine(prot);
- return prot;
+ return pgprot_writecombine(prot);
}
void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr,
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 77f6ebf97113..d8dcd8820369 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -121,7 +121,6 @@ config PPC
select ARCH_32BIT_OFF_T if PPC32
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
- select ARCH_HAS_DMA_MMAP_PGPROT
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/powerpc/kernel/dma-common.c b/arch/powerpc/kernel/dma-common.c
deleted file mode 100644
index dc7ef6b17b69..000000000000
--- a/arch/powerpc/kernel/dma-common.c
+++ /dev/null
@@ -1,17 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * Contains common dma routines for all powerpc platforms.
- *
- * Copyright (C) 2019 Shawn Anastasio.
- */
-
-#include <linux/mm.h>
-#include <linux/dma-noncoherent.h>
-
-pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
- unsigned long attrs)
-{
- if (!dev_is_dma_coherent(dev))
- return pgprot_noncached(prot);
- return prot;
-}
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index a7f9c3edbcb2..0015fe610b23 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -574,7 +574,7 @@ static void *iommu_dma_alloc_remap(struct device *dev, size_t size,
struct iova_domain *iovad = &cookie->iovad;
bool coherent = dev_is_dma_coherent(dev);
int ioprot = dma_info_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
- pgprot_t prot = arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs);
+ pgprot_t prot = dma_pgprot(dev, PAGE_KERNEL, attrs);
unsigned int count, min_size, alloc_sizes = domain->pgsize_bitmap;
struct page **pages;
struct sg_table sgt;
@@ -975,7 +975,7 @@ static void *iommu_dma_alloc_pages(struct device *dev, size_t size,
return NULL;
if (IS_ENABLED(CONFIG_DMA_REMAP) && (!coherent || PageHighMem(page))) {
- pgprot_t prot = arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs);
+ pgprot_t prot = dma_pgprot(dev, PAGE_KERNEL, attrs);
cpu_addr = dma_common_contiguous_remap(page, alloc_size,
VM_USERMAP, prot, __builtin_return_address(0));
@@ -1035,7 +1035,7 @@ static int iommu_dma_mmap(struct device *dev, struct vm_area_struct *vma,
unsigned long pfn, off = vma->vm_pgoff;
int ret;
- vma->vm_page_prot = arch_dma_mmap_pgprot(dev, vma->vm_page_prot, attrs);
+ vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, &ret))
return ret;
diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
index 3813211a9aad..0bff3d7fac92 100644
--- a/include/linux/dma-noncoherent.h
+++ b/include/linux/dma-noncoherent.h
@@ -42,13 +42,18 @@ void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_addr, unsigned long attrs);
long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
dma_addr_t dma_addr);
-
-#ifdef CONFIG_ARCH_HAS_DMA_MMAP_PGPROT
pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
unsigned long attrs);
+
+#ifdef CONFIG_MMU
+pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs);
#else
-# define arch_dma_mmap_pgprot(dev, prot, attrs) pgprot_noncached(prot)
-#endif
+static inline pgprot_t dma_pgprot(struct device *dev, pgprot_t prot,
+ unsigned long attrs)
+{
+ return prot; /* no protection bits supported without page tables */
+}
+#endif /* CONFIG_MMU */
#ifdef CONFIG_DMA_NONCOHERENT_CACHE_SYNC
void arch_dma_cache_sync(struct device *dev, void *vaddr, size_t size,
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index b945239621d8..51d9657e0a8f 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -150,6 +150,21 @@ int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt,
}
EXPORT_SYMBOL(dma_get_sgtable_attrs);
+/*
+ * Return the page attributes used for mapping dma_alloc_* memory, either in
+ * kernel space if remapping is needed, or to userspace through dma_mmap_*.
+ */
+pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs)
+{
+ if (dev_is_dma_coherent(dev) ||
+ (IS_ENABLED(CONFIG_DMA_NONCOHERENT_CACHE_SYNC) &&
+ (attrs & DMA_ATTR_NON_CONSISTENT)))
+ return prot;
+ if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_MMAP_PGPROT))
+ return arch_dma_mmap_pgprot(dev, prot, attrs);
+ return pgprot_noncached(prot);
+}
+
/*
* Create userspace mapping for the DMA-coherent memory.
*/
@@ -164,7 +179,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
unsigned long pfn;
int ret = -ENXIO;
- vma->vm_page_prot = arch_dma_mmap_pgprot(dev, vma->vm_page_prot, attrs);
+ vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, &ret))
return ret;
diff --git a/kernel/dma/remap.c b/kernel/dma/remap.c
index a594aec07882..ffe78f0b2fe4 100644
--- a/kernel/dma/remap.c
+++ b/kernel/dma/remap.c
@@ -218,7 +218,7 @@ void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
/* create a coherent mapping */
ret = dma_common_contiguous_remap(page, size, VM_USERMAP,
- arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs),
+ dma_pgprot(dev, PAGE_KERNEL, attrs),
__builtin_return_address(0));
if (!ret) {
__dma_direct_free_pages(dev, size, page);
--
2.20.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
* fix default dma_mmap_* pgprot v3
From: Christoph Hellwig @ 2019-08-07 6:16 UTC (permalink / raw)
To: iommu
Cc: Shawn Anastasio, Will Deacon, Michael Ellerman, linuxppc-dev,
linux-kernel, Russell King, linux-mips, Paul Burton,
Catalin Marinas, James Hogan, Robin Murphy, linux-arm-kernel
Hi all,
As Shawn pointed out we've had issues with the dma mmap pgprots ever
since the dma_common_mmap helper was added beyong the initial
architectures - we default to uncached mappings, but for devices that
are DMA coherent, or if the DMA_ATTR_NON_CONSISTENT is set (and
supported) this can lead to aliasing of cache attributes. This patch
fixes that. My explanation of why this hasn't been much of an issue
is that the dma_mmap_ helpers aren't used widely and mostly just in
architecture specific drivers.
Changes since v2:
- fix m68knommu compile by inlining dma_prprot helper and providing
a stub for !CONFIG_MMU
- fix various typos in the commit messages
Changes since v1:
- fix handling of DMA_ATTR_NON_CONSISTENT where it is a no-op
(which is most architectures)
- remove DMA_ATTR_WRITE_COMBINE on mips, as it seem dangerous as-is
_______________________________________________
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] dma-mapping: fix page attributes for dma_mmap_*
From: Christoph Hellwig @ 2019-08-07 6:14 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Shawn Anastasio, Catalin Marinas, linuxppc-dev, Robin Murphy,
linux-kernel, iommu, Michael Ellerman, Will Deacon,
Christoph Hellwig, linux-arm-kernel
In-Reply-To: <20190806164503.GD1330@shell.armlinux.org.uk>
On Tue, Aug 06, 2019 at 05:45:03PM +0100, Russell King - ARM Linux admin wrote:
> We could have used a different approach, making all IO writes contain
> a "drain write buffer" instruction, and map DMA memory as "buffered",
> but as there were no Linux barriers defined to order memory accesses
> to DMA memory (so, for example, ring buffers can be updated in the
> correct order) back in those days, using the uncached/unbuffered mode
> was the sanest and most reliable solution.
Absolutely makes sense so far.
> > > The other really weird things is that in arm32
> > > pgprot_dmacoherent incudes the L_PTE_XN bit, which from my understanding
> > > is the no-execture bit, but pgprot_writecombine does not. This seems to
> > > not very unintentional. So minus that the whole DMA_ATTR_WRITE_COMBІNE
> > > seems to be about flagging old arm specific drivers as having the proper
> > > barriers in places and otherwise is a no-op.
> >
> > I think it only matters for Armv7 CPUs, but yes, we should probably be
> > setting L_PTE_XN for both of these memory types.
>
> Conventionally, pgprot_writecombine() has only been used to change
> the memory type and not the permissions. Since writecombine memory
> is still capable of being executed, I don't see any reason to set XN
> for it.
>
> If the user wishes to mmap() using PROT_READ|PROT_EXEC, then is there
> really a reason for writecombine to set XN overriding the user?
>
> That said, pgprot_writecombine() is mostly used for framebuffers, which
> arguably shouldn't be executable anyway - but who'd want to mmap() the
> framebuffer with PROT_EXEC?
Well, I was mostly taking about DMA_ATTR_WRITE_COMBINE, which really
should include the NX bit even if pgprot_writecombine doesn't, right?
> > > - make DMA_ATTR_WRITE_COMBINE a no-op and schedule it for removal,
> > > thus removing the last instances of arch_dma_mmap_pgprot
> >
> > All sounds good to me, although I suppose 32-bit Arm platforms without
> > CONFIG_ARM_DMA_MEM_BUFFERABLE may run into issues if DMA_ATTR_WRITE_COMBINE
> > disappears. Only one way to find out...
>
> Looking at the results of grep, I think only OMAP2+ and Exynos may be
> affected.
As you mentioned later we also have the dma_alloc_wc wrapper, and a
single instance of dma_alloc_writecombine.
Exynos looks like purely ARM v7 from Kconfig, so it shouldn't even be
affected.
> However, removing writecombine support from the DMA API is going to
> have a huge impact for framebuffers on earlier ARMs - that's where we
> do expect framebuffers to be mapped "uncached/buffered" for performance
> reasons and not "uncached/unbuffered". It's quite literally the
> difference between console scrolling being usable and totally unusable.
>
> Given what I've said above, switching to using buffered mode for normal
> DMA mappings is data-corrupting risky - as in your filesystem could get
> fried. I don't think we should play fast and loose with people's data
> by randomly changing that "because we'd like to", and I don't see that
> screwing the console is really an option either.
Oh well. If we can't make dma_alloc_wc generally safe I fear we'll
have to keep it, but maybe literally limit it to the pre ARM v6
platforms. While pretty much all callers seems platform specific,
there actually are a decent number that can only work on ARM v7 or
arm64.
_______________________________________________
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] ARM: dts: sun8i: a83t: Enable HDMI output on Cubietruck Plus
From: Chen-Yu Tsai @ 2019-08-07 6:06 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: devicetree, linux-arm-kernel, Maxime Ripard, linux-kernel
In-Reply-To: <20190728145944.4091-1-wens@kernel.org>
On Sun, Jul 28, 2019 at 10:59 PM Chen-Yu Tsai <wens@kernel.org> wrote:
>
> From: Chen-Yu Tsai <wens@csie.org>
>
> The Cubietruck Plus has an HDMI connector tied to the HDMI output of the
> SoC.
>
> Enables display output via HDMI on the Cubietruck Plus. The connector
> device node is named "hdmi-connector" as there is also a display port
> connector, which is tied to the MIPI DSI output of the SoC through a
> MIPI-DSI-to-DP bridge. This part is not supported yet.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied for 5.4.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dma-mapping: fix page attributes for dma_mmap_*
From: Christoph Hellwig @ 2019-08-07 6:04 UTC (permalink / raw)
To: Shawn Anastasio
Cc: Gavin Li, linux-kernel, Michael Ellerman, linuxppc-dev,
Russell King, linux-mips, iommu, Paul Burton, Catalin Marinas,
James Hogan, Will Deacon, Christoph Hellwig, linux-arm-kernel,
Robin Murphy
In-Reply-To: <7df95ffb-6df3-b118-284c-ee32cad81199@anastas.io>
On Tue, Aug 06, 2019 at 09:39:06PM +0200, Shawn Anastasio wrote:
>> -#ifdef CONFIG_ARCH_HAS_DMA_MMAP_PGPROT
>> pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
>> unsigned long attrs);
>> -#else
>> -# define arch_dma_mmap_pgprot(dev, prot, attrs) pgprot_noncached(prot)
>> -#endif
>
> Nit, but maybe the prototype should still be ifdef'd here? It at least
> could prevent a reader from incorrectly thinking that the function is
> always present.
Actually it is typical modern Linux style to just provide a prototype
and then use "if (IS_ENABLED(CONFIG_FOO))" to guard the call(s) to it.
>
> Also, like Will mentioned earlier, the function name isn't entirely
> accurate anymore. I second the suggestion of using something like
> arch_dma_noncoherent_pgprot().
As mentioned I plan to remove arch_dma_mmap_pgprot for 5.4, so I'd
rather avoid churn for the short period of time.
> As for your idea of defining
> pgprot_dmacoherent for all architectures as
>
> #ifndef pgprot_dmacoherent
> #define pgprot_dmacoherent pgprot_noncached
> #endif
>
> I think that the name here is kind of misleading too, since this
> definition will only be used when there is no support for proper
> DMA coherency.
Do you have a suggestion for a better name? I'm pretty bad at naming,
so just reusing the arm name seemed like a good way to avoid having
to make naming decisions myself.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 4/4] drm/mediatek: control dpi pins dpi or gpio mode in on or off
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190807060257.57007-1-jitao.shi@mediatek.com>
Pull dpi pins low when dpi has nothing to display. Aovid leakage
current from some dpi pins (Hsync Vsync DE ... ).
Some chips have dpi pins, but there are some chip don't have pins.
So this function is controlled by device tree.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 39 +++++++++++++++++++++++++++++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 4f2700cbfdb7..83fb0d753f72 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -9,10 +9,12 @@
#include <drm/drm_of.h>
#include <linux/kernel.h>
#include <linux/component.h>
-#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_gpio.h>
#include <linux/of_graph.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/platform_device.h>
#include <linux/interrupt.h>
#include <linux/types.h>
#include <linux/clk.h>
@@ -71,8 +73,12 @@ struct mtk_dpi {
enum mtk_dpi_out_yc_map yc_map;
enum mtk_dpi_out_bit_num bit_num;
enum mtk_dpi_out_channel_swap channel_swap;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pins_gpio;
+ struct pinctrl_state *pins_dpi;
int refcount;
bool dual_edge;
+ bool dpi_pin_ctrl;
};
static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
@@ -384,6 +390,9 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi)
if (--dpi->refcount != 0)
return;
+ if (dpi->dpi_pin_ctrl)
+ pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
+
mtk_dpi_disable(dpi);
clk_disable_unprepare(dpi->pixel_clk);
clk_disable_unprepare(dpi->engine_clk);
@@ -408,6 +417,9 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi)
goto err_pixel;
}
+ if (dpi->dpi_pin_ctrl)
+ pinctrl_select_state(dpi->pinctrl, dpi->pins_dpi);
+
mtk_dpi_enable(dpi);
return 0;
@@ -713,6 +725,31 @@ static int mtk_dpi_probe(struct platform_device *pdev)
dpi->dev = dev;
dpi->conf = (struct mtk_dpi_conf *)of_device_get_match_data(dev);
dpi->dual_edge = of_property_read_bool(dev->of_node, "dpi_dual_edge");
+ dpi->dpi_pin_ctrl = of_property_read_bool(dev->of_node,
+ "dpi_pin_mode_swap");
+
+ if (dpi->dpi_pin_ctrl) {
+ dpi->pinctrl = devm_pinctrl_get(&pdev->dev);
+ if (IS_ERR(dpi->pinctrl)) {
+ dev_err(&pdev->dev, "Cannot find pinctrl!\n");
+ return PTR_ERR(dpi->pinctrl);
+ }
+
+ dpi->pins_gpio = pinctrl_lookup_state(dpi->pinctrl,
+ "gpiomode");
+ if (IS_ERR(dpi->pins_gpio)) {
+ dev_err(&pdev->dev, "Cannot find pinctrl gpiomode!\n");
+ return PTR_ERR(dpi->pins_gpio);
+ }
+
+ pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
+
+ dpi->pins_dpi = pinctrl_lookup_state(dpi->pinctrl, "dpimode");
+ if (IS_ERR(dpi->pins_dpi)) {
+ dev_err(&pdev->dev, "Cannot find pinctrl dpimode!\n");
+ return PTR_ERR(dpi->pins_dpi);
+ }
+ }
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dpi->regs = devm_ioremap_resource(dev, mem);
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 1/4] dt-bindings: display: mediatek: update dpi supported chips
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190807060257.57007-1-jitao.shi@mediatek.com>
Add decriptions about supported chips, including MT2701 & MT8173 &
mt8183
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
.../bindings/display/mediatek/mediatek,dpi.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
index b6a7e7397b8b..cd6a1469c8b7 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
@@ -7,6 +7,7 @@ output bus.
Required properties:
- compatible: "mediatek,<chip>-dpi"
+ the supported chips are mt2701 , mt8173 and mt8183.
- reg: Physical base address and length of the controller's registers
- interrupts: The interrupt signal from the function block.
- clocks: device clocks
@@ -16,6 +17,11 @@ Required properties:
Documentation/devicetree/bindings/graph.txt. This port should be connected
to the input port of an attached HDMI or LVDS encoder chip.
+Optional properties:
+- dpi_pin_mode_swap: Swap the pin mode between dpi mode and gpio mode.
+- pinctrl-names: Contain "gpiomode" and "dpimode".
+- dpi_dual_edge: Control the RGB 24bit data on 12 pins or 24 pins.
+
Example:
dpi0: dpi@1401d000 {
@@ -26,6 +32,11 @@ dpi0: dpi@1401d000 {
<&mmsys CLK_MM_DPI_ENGINE>,
<&apmixedsys CLK_APMIXED_TVDPLL>;
clock-names = "pixel", "engine", "pll";
+ dpi_dual_edge;
+ dpi_pin_mode_swap;
+ pinctrl-names = "gpiomode", "dpimode";
+ pinctrl-0 = <&dpi_pin_gpio>;
+ pinctrl-1 = <&dpi_pin_func>;
port {
dpi0_out: endpoint {
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/4] drm/mediatek: dpi dual edge support
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190807060257.57007-1-jitao.shi@mediatek.com>
DPI sample the data both rising and falling edge.
It can reduce half data io pins.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index bacd989cc9aa..743230864ba0 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -72,6 +72,7 @@ struct mtk_dpi {
enum mtk_dpi_out_bit_num bit_num;
enum mtk_dpi_out_channel_swap channel_swap;
int refcount;
+ bool dual_edge;
};
static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
@@ -345,6 +346,13 @@ static void mtk_dpi_config_disable_edge(struct mtk_dpi *dpi)
mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
}
+static void mtk_dpi_enable_dual_edge(struct mtk_dpi *dpi)
+{
+ mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
+ DDR_EN | DDR_4PHASE);
+ mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, EDGE_SEL, EDGE_SEL);
+}
+
static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
enum mtk_dpi_out_color_format format)
{
@@ -436,7 +444,8 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
pll_rate = clk_get_rate(dpi->tvd_clk);
vm.pixelclock = pll_rate / factor;
- clk_set_rate(dpi->pixel_clk, vm.pixelclock);
+ clk_set_rate(dpi->pixel_clk,
+ vm.pixelclock * (dpi->dual_edge ? 2 : 1));
vm.pixelclock = clk_get_rate(dpi->pixel_clk);
dev_dbg(dpi->dev, "Got PLL %lu Hz, pixel clock %lu Hz\n",
@@ -501,6 +510,8 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
mtk_dpi_config_color_format(dpi, dpi->color_format);
mtk_dpi_config_2n_h_fre(dpi);
mtk_dpi_config_disable_edge(dpi);
+ if (dpi->dual_edge)
+ mtk_dpi_enable_dual_edge(dpi);
mtk_dpi_sw_reset(dpi, false);
return 0;
@@ -686,6 +697,7 @@ static int mtk_dpi_probe(struct platform_device *pdev)
dpi->dev = dev;
dpi->conf = (struct mtk_dpi_conf *)of_device_get_match_data(dev);
+ dpi->dual_edge = of_property_read_bool(dev->of_node, "dpi_dual_edge");
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dpi->regs = devm_ioremap_resource(dev, mem);
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 0/4] add mt8183 dpi driver
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
Changes since v4:
- move pin mode control and dual edge control to deveice tree.
- update dt-bindings document for pin mode swap and dual edge control.
Changes since v3:
- add dpi pin mode control when dpi on or off.
- update dpi dual edge comment.
Changes since v2:
- update dt-bindings document for mt8183 dpi.
- separate dual edge modfication as independent patch.
Jitao Shi (4):
dt-bindings: display: mediatek: update dpi supported chips
drm/mediatek: dpi dual edge support
drm/mediatek: add mt8183 dpi clock factor
drm/mediatek: control dpi pins dpi or gpio mode in on or off
.../display/mediatek/mediatek,dpi.txt | 11 +++
drivers/gpu/drm/mediatek/mtk_dpi.c | 71 ++++++++++++++++++-
2 files changed, 80 insertions(+), 2 deletions(-)
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 3/4] drm/mediatek: add mt8183 dpi clock factor
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190807060257.57007-1-jitao.shi@mediatek.com>
The factor depends on the divider of DPI in MT8183, therefore,
we should fix this factor to the right and new one.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 743230864ba0..4f2700cbfdb7 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -672,6 +672,16 @@ static unsigned int mt2701_calculate_factor(int clock)
return 1;
}
+static unsigned int mt8183_calculate_factor(int clock)
+{
+ if (clock <= 27000)
+ return 8;
+ else if (clock <= 167000)
+ return 4;
+ else
+ return 2;
+}
+
static const struct mtk_dpi_conf mt8173_conf = {
.cal_factor = mt8173_calculate_factor,
.reg_h_fre_con = 0xe0,
@@ -683,6 +693,11 @@ static const struct mtk_dpi_conf mt2701_conf = {
.edge_sel_en = true,
};
+static const struct mtk_dpi_conf mt8183_conf = {
+ .cal_factor = mt8183_calculate_factor,
+ .reg_h_fre_con = 0xe0,
+};
+
static int mtk_dpi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -779,6 +794,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
{ .compatible = "mediatek,mt8173-dpi",
.data = &mt8173_conf,
},
+ { .compatible = "mediatek,mt8183-dpi",
+ .data = &mt8183_conf,
+ },
{ },
};
--
2.21.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 v2] net: mdio-octeon: Fix Kconfig warnings and build errors
From: Nathan Chancellor @ 2019-08-07 5:10 UTC (permalink / raw)
To: David Miller
Cc: devel, andrew, f.fainelli, lkp, kernel-build-reports, gregkh,
rdunlap, willy, broonie, linux-next, netdev, linux-arm-kernel,
hkallweit1
In-Reply-To: <20190806.141133.1365654857955536268.davem@davemloft.net>
On Tue, Aug 06, 2019 at 02:11:33PM -0700, David Miller wrote:
> From: Nathan Chancellor <natechancellor@gmail.com>
> Date: Fri, 2 Aug 2019 23:01:56 -0700
>
> > After commit 171a9bae68c7 ("staging/octeon: Allow test build on
> > !MIPS"), the following combination of configs cause a few Kconfig
> > warnings and build errors (distilled from arm allyesconfig and Randy's
> > randconfig builds):
> >
> > CONFIG_NETDEVICES=y
> > CONFIG_STAGING=y
> > CONFIG_COMPILE_TEST=y
> >
> > and CONFIG_OCTEON_ETHERNET as either a module or built-in.
> >
> > WARNING: unmet direct dependencies detected for MDIO_OCTEON
> > Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
> > && 64BIT [=n] && HAS_IOMEM [=y] && OF_MDIO [=n]
> > Selected by [y]:
> > - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC ||
> > COMPILE_TEST [=y]) && NETDEVICES [=y]
> >
> > In file included from ../drivers/net/phy/mdio-octeon.c:14:
> > ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> > function ‘writeq’; did you mean ‘writel’?
> > [-Werror=implicit-function-declaration]
> > 111 | #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
> > | ^~~~~~
> >
> > CONFIG_64BIT is not strictly necessary if the proper readq/writeq
> > definitions are included from io-64-nonatomic-lo-hi.h.
> >
> > CONFIG_OF_MDIO is not needed when CONFIG_COMPILE_TEST is enabled because
> > of commit f9dc9ac51610 ("of/mdio: Add dummy functions in of_mdio.h.").
> >
> > Fixes: 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS")
> > Reported-by: kbuild test robot <lkp@intel.com>
> > Reported-by: Mark Brown <broonie@kernel.org>
> > Reported-by: Randy Dunlap <rdunlap@infradead.org>
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Applied to net-next.
>
> Please make it clear what tree your changes are targetting in the future,
> thank you.
Sorry for the confusion, I'll do my best to add a patch suffix in the
future.
Thank you for picking this up!
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: mm: add missing PTE_SPECIAL in pte_mkdevmap on arm64
From: Jia He @ 2019-08-07 4:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse
Cc: Jia He, Anshuman Khandual, Christoffer Dall, linux-kernel,
Jun Yao, Qian Cai, Punit Agrawal, Thomas Gleixner, Robin Murphy,
Alex Van Brunt, linux-arm-kernel
Without this patch, the MAP_SYNC test case will cause a print_bad_pte
warning on arm64 as follows:
[ 25.542693] BUG: Bad page map in process mapdax333
pte:2e8000448800f53 pmd:41ff5f003
[ 25.546360] page:ffff7e0010220000 refcount:1 mapcount:-1
mapping:ffff8003e29c7440 index:0x0
[ 25.550281] ext4_dax_aops
[ 25.550282] name:"__aaabbbcccddd__"
[ 25.551553] flags: 0x3ffff0000001002(referenced|reserved)
[ 25.555802] raw: 03ffff0000001002 ffff8003dfffa908 0000000000000000
ffff8003e29c7440
[ 25.559446] raw: 0000000000000000 0000000000000000 00000001fffffffe
0000000000000000
[ 25.563075] page dumped because: bad pte
[ 25.564938] addr:0000ffffbe05b000 vm_flags:208000fb
anon_vma:0000000000000000 mapping:ffff8003e29c7440 index:0
[ 25.574272] file:__aaabbbcccddd__ fault:ext4_dax_fault
mmmmap:ext4_file_mmap readpage:0x0
[ 25.578799] CPU: 1 PID: 1180 Comm: mapdax333 Not tainted 5.2.0+ #21
[ 25.581702] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0
02/06/2015
[ 25.585624] Call trace:
[ 25.587008] dump_backtrace+0x0/0x178
[ 25.588799] show_stack+0x24/0x30
[ 25.590328] dump_stack+0xa8/0xcc
[ 25.591901] print_bad_pte+0x18c/0x218
[ 25.593628] unmap_page_range+0x778/0xc00
[ 25.595506] unmap_single_vma+0x94/0xe8
[ 25.597304] unmap_vmas+0x90/0x108
[ 25.598901] unmap_region+0xc0/0x128
[ 25.600566] __do_munmap+0x284/0x3f0
[ 25.602245] __vm_munmap+0x78/0xe0
[ 25.603820] __arm64_sys_munmap+0x34/0x48
[ 25.605709] el0_svc_common.constprop.0+0x78/0x168
[ 25.607956] el0_svc_handler+0x34/0x90
[ 25.609698] el0_svc+0x8/0xc
[ 25.611103] Disabling lock debugging due to kernel taint
[ 25.613573] BUG: Bad page state in process mapdax333 pfn:448800
[ 25.616359] page:ffff7e0010220000 refcount:0 mapcount:-1
mapping:ffff8003e29c7440 index:0x1
[ 25.620236] ext4_dax_aops
[ 25.620237] name:"__aaabbbcccddd__"
[ 25.621495] flags: 0x3ffff0000000000()
[ 25.624912] raw: 03ffff0000000000 dead000000000100 dead000000000200
ffff8003e29c7440
[ 25.628502] raw: 0000000000000001 0000000000000000 00000000fffffffe
0000000000000000
[ 25.632097] page dumped because: non-NULL mapping
[...]
[ 25.656567] CPU: 1 PID: 1180 Comm: mapdax333 Tainted: G B
5.2.0+ #21
[ 25.660131] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0
02/06/2015
[ 25.663324] Call trace:
[ 25.664466] dump_backtrace+0x0/0x178
[ 25.666163] show_stack+0x24/0x30
[ 25.667721] dump_stack+0xa8/0xcc
[ 25.669270] bad_page+0xf0/0x150
[ 25.670772] free_pages_check_bad+0x84/0xa0
[ 25.672724] free_pcppages_bulk+0x45c/0x708
[ 25.674675] free_unref_page_commit+0xcc/0x100
[ 25.676751] free_unref_page_list+0x13c/0x200
[ 25.678801] release_pages+0x350/0x420
[ 25.680539] free_pages_and_swap_cache+0xf8/0x128
[ 25.682738] tlb_flush_mmu+0x164/0x2b0
[ 25.684485] unmap_page_range+0x648/0xc00
[ 25.686349] unmap_single_vma+0x94/0xe8
[ 25.688131] unmap_vmas+0x90/0x108
[ 25.689739] unmap_region+0xc0/0x128
[ 25.691392] __do_munmap+0x284/0x3f0
[ 25.693079] __vm_munmap+0x78/0xe0
[ 25.694658] __arm64_sys_munmap+0x34/0x48
[ 25.696530] el0_svc_common.constprop.0+0x78/0x168
[ 25.698772] el0_svc_handler+0x34/0x90
[ 25.700512] el0_svc+0x8/0xc
The root cause is in _vm_normal_page, without the PTE_SPECIAL bit,
the return value will be incorrectly set to pfn_to_page(pfn) instead
of NULL. Besides, this patch also rewrite the pmd_mkdevmap to avoid
setting PTE_SPECIAL for pmd
The MAP_SYNC test case is as follows(Provided by Yibo Cai)
$#include <stdio.h>
$#include <string.h>
$#include <unistd.h>
$#include <sys/file.h>
$#include <sys/mman.h>
$#ifndef MAP_SYNC
$#define MAP_SYNC 0x80000
$#endif
/* mount -o dax /dev/pmem0 /mnt */
$#define F "/mnt/__aaabbbcccddd__"
int main(void)
{
int fd;
char buf[4096];
void *addr;
if ((fd = open(F, O_CREAT|O_TRUNC|O_RDWR, 0644)) < 0) {
perror("open1");
return 1;
}
if (write(fd, buf, 4096) != 4096) {
perror("lseek");
return 1;
}
addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_SYNC,
fd, 0);
if (addr == MAP_FAILED) {
perror("mmap");
printf("did you mount with '-o dax'?\n");
return 1;
}
memset(addr, 0x55, 4096);
if (munmap(addr, 4096) == -1) {
perror("munmap");
return 1;
}
close(fd);
return 0;
}
Fixes: 73b20c84d42d ("arm64: mm: implement pte_devmap support")
Reported-by: Yibo Cai <Yibo.Cai@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Acked-by: Robin Murphy <Robin.Murphy@arm.com>
---
arch/arm64/include/asm/pgtable.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 5fdcfe237338..e09760ece844 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -209,7 +209,7 @@ static inline pmd_t pmd_mkcont(pmd_t pmd)
static inline pte_t pte_mkdevmap(pte_t pte)
{
- return set_pte_bit(pte, __pgprot(PTE_DEVMAP));
+ return set_pte_bit(pte, __pgprot(PTE_DEVMAP | PTE_SPECIAL));
}
static inline void set_pte(pte_t *ptep, pte_t pte)
@@ -396,7 +396,10 @@ static inline int pmd_protnone(pmd_t pmd)
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
#define pmd_devmap(pmd) pte_devmap(pmd_pte(pmd))
#endif
-#define pmd_mkdevmap(pmd) pte_pmd(pte_mkdevmap(pmd_pte(pmd)))
+static inline pmd_t pmd_mkdevmap(pmd_t pmd)
+{
+ return pte_pmd(set_pte_bit(pmd_pte(pmd), __pgprot(PTE_DEVMAP)));
+}
#define __pmd_to_phys(pmd) __pte_to_phys(pmd_pte(pmd))
#define __phys_to_pmd_val(phys) __phys_to_pte_val(phys)
--
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 nvmem v2 2/2] dt-bindings: fsl: scu: add new compatible string for ocotp
From: fugang.duan @ 2019-08-07 4:03 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: mark.rutland, robh, festevam, fugang.duan, devicetree, gregkh,
s.hauer, linux-kernel, kernel, shawnguo, linux-arm-kernel
In-Reply-To: <20190807040320.1760-1-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
Add new compatible string "fsl,imx8qm-scu-ocotp" into binding
doc for i.MX8 SCU OCOTP driver.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index a575e42..c149fad 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -136,7 +136,9 @@ Required properties:
OCOTP bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
-- compatible: Should be "fsl,imx8qxp-scu-ocotp"
+- compatible: Should be one of:
+ "fsl,imx8qm-scu-ocotp",
+ "fsl,imx8qxp-scu-ocotp".
- #address-cells: Must be 1. Contains byte index
- #size-cells: Must be 1. Contains byte length
--
2.7.4
_______________________________________________
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 nvmem v2 1/2] nvmem: imx: add i.MX8QM platform support
From: fugang.duan @ 2019-08-07 4:03 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: mark.rutland, robh, festevam, fugang.duan, devicetree, gregkh,
s.hauer, linux-kernel, kernel, shawnguo, linux-arm-kernel
In-Reply-To: <20190807040320.1760-1-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
i.MX8QM efuse table has some difference with i.MX8QXP platform,
so add i.MX8QM platform support.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
drivers/nvmem/imx-ocotp-scu.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
index be2f5f0..0d78ab4 100644
--- a/drivers/nvmem/imx-ocotp-scu.c
+++ b/drivers/nvmem/imx-ocotp-scu.c
@@ -16,6 +16,7 @@
enum ocotp_devtype {
IMX8QXP,
+ IMX8QM,
};
struct ocotp_devtype_data {
@@ -39,6 +40,11 @@ static struct ocotp_devtype_data imx8qxp_data = {
.nregs = 800,
};
+static struct ocotp_devtype_data imx8qm_data = {
+ .devtype = IMX8QM,
+ .nregs = 800,
+};
+
static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
u32 *val)
{
@@ -118,6 +124,7 @@ static struct nvmem_config imx_scu_ocotp_nvmem_config = {
static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx8qxp-scu-ocotp", (void *)&imx8qxp_data },
+ { .compatible = "fsl,imx8qm-scu-ocotp", (void *)&imx8qm_data },
{ },
};
MODULE_DEVICE_TABLE(of, imx_scu_ocotp_dt_ids);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox