* [PATCH 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Robin Murphy @ 2016-10-17 12:05 UTC (permalink / raw)
To: linux-arm-kernel
With the new dma_{map,unmap}_resource() functions added to the DMA API
for the benefit of cases like slave DMA, add suitable implementations to
the arsenal of our generic layer. Since cache maintenance should not be
a concern, these can both be standalone versions without the need for
architecture-specific wrappers.
CC: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
Since patch 2 has a build dependency on this one, they should probably
go together through either the arm64 tree or the iommu tree, but I can't
make up my mind which one seems more appropriate...
Robin.
drivers/iommu/dma-iommu.c | 13 +++++++++++++
include/linux/dma-iommu.h | 4 ++++
2 files changed, 17 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..50acd71915db 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -624,6 +624,19 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
__iommu_dma_unmap(iommu_get_domain_for_dev(dev), sg_dma_address(sg));
}
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ return iommu_dma_map_page(dev, phys_to_page(phys), offset_in_page(phys),
+ size, dma_direction_to_prot(dir, false) | IOMMU_MMIO);
+}
+
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ __iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle);
+}
+
int iommu_dma_supported(struct device *dev, u64 mask)
{
/*
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c589062bd9..7f7e9a7e3839 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -61,6 +61,10 @@ void iommu_dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
enum dma_data_direction dir, unsigned long attrs);
void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction dir, unsigned long attrs);
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
int iommu_dma_supported(struct device *dev, u64 mask);
int iommu_dma_mapping_error(struct device *dev, dma_addr_t dma_addr);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] iommu/mediatek: Convert M4Uv1 to iommu_fwspec
From: Robin Murphy @ 2016-10-17 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0205bf6404b16bdebe8039bfc65570a2a6f9f960.1476704508.git.robin.murphy@arm.com>
Our per-device data consists of the M4U instance and firmware-provided
list of LARB IDs, which is a perfect fit for the generic iommu_fwspec
machinery. Use that directly instead of the custom archdata code - while
we can't rely on the of_xlate() mechanism to initialise things until the
32-bit ARM DMA code learns about groups and default domains, it still
results in a reasonable simplification overall.
CC: Honghui Zhang <honghui.zhang@mediatek.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu.h | 6 ---
drivers/iommu/mtk_iommu_v1.c | 95 +++++++++++++++++---------------------------
2 files changed, 36 insertions(+), 65 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 3dab13b4a211..f59609f20270 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -34,12 +34,6 @@ struct mtk_iommu_suspend_reg {
u32 int_main_control;
};
-struct mtk_iommu_client_priv {
- struct list_head client;
- unsigned int mtk_m4u_id;
- struct device *m4udev;
-};
-
struct mtk_iommu_domain;
struct mtk_iommu_data {
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index b8aeb0768483..884c80cb795e 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -204,14 +204,14 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
static void mtk_iommu_config(struct mtk_iommu_data *data,
struct device *dev, bool enable)
{
- struct mtk_iommu_client_priv *head, *cur, *next;
struct mtk_smi_larb_iommu *larb_mmu;
unsigned int larbid, portid;
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+ int i;
- head = dev->archdata.iommu;
- list_for_each_entry_safe(cur, next, &head->client, client) {
- larbid = mt2701_m4u_to_larb(cur->mtk_m4u_id);
- portid = mt2701_m4u_to_port(cur->mtk_m4u_id);
+ for (i = 0; i < fwspec->num_ids; ++i) {
+ larbid = mt2701_m4u_to_larb(fwspec->ids[i]);
+ portid = mt2701_m4u_to_port(fwspec->ids[i]);
larb_mmu = &data->smi_imu.larb_imu[larbid];
dev_dbg(dev, "%s iommu port: %d\n",
@@ -271,14 +271,12 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
struct device *dev)
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
- struct mtk_iommu_client_priv *priv = dev->archdata.iommu;
- struct mtk_iommu_data *data;
+ struct mtk_iommu_data *data = dev->iommu_fwspec->iommu_priv;
int ret;
- if (!priv)
+ if (!data)
return -ENODEV;
- data = dev_get_drvdata(priv->m4udev);
if (!data->m4u_dom) {
data->m4u_dom = dom;
ret = mtk_iommu_domain_finalise(data);
@@ -295,13 +293,11 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
static void mtk_iommu_detach_device(struct iommu_domain *domain,
struct device *dev)
{
- struct mtk_iommu_client_priv *priv = dev->archdata.iommu;
- struct mtk_iommu_data *data;
+ struct mtk_iommu_data *data = dev->iommu_fwspec->iommu_priv;
- if (!priv)
+ if (!data)
return;
- data = dev_get_drvdata(priv->m4udev);
mtk_iommu_config(data, dev, false);
}
@@ -366,6 +362,8 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
return pa;
}
+static struct iommu_ops mtk_iommu_ops;
+
/*
* MTK generation one iommu HW only support one iommu domain, and all the client
* sharing the same iova address space.
@@ -373,7 +371,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
static int mtk_iommu_create_mapping(struct device *dev,
struct of_phandle_args *args)
{
- struct mtk_iommu_client_priv *head, *priv, *next;
+ struct mtk_iommu_data *data;
struct platform_device *m4updev;
struct dma_iommu_mapping *mtk_mapping;
struct device *m4udev;
@@ -385,41 +383,37 @@ static int mtk_iommu_create_mapping(struct device *dev,
return -EINVAL;
}
- if (!dev->archdata.iommu) {
+ if (!dev->iommu_fwspec) {
+ ret = iommu_fwspec_init(dev, &args->np->fwnode, &mtk_iommu_ops);
+ if (ret)
+ return ret;
+ } else if (dev->iommu_fwspec->ops != &mtk_iommu_ops) {
+ return -EINVAL;
+ }
+
+ if (!dev->iommu_fwspec->iommu_priv) {
/* Get the m4u device */
m4updev = of_find_device_by_node(args->np);
if (WARN_ON(!m4updev))
return -EINVAL;
- head = kzalloc(sizeof(*head), GFP_KERNEL);
- if (!head)
- return -ENOMEM;
-
- dev->archdata.iommu = head;
- INIT_LIST_HEAD(&head->client);
- head->m4udev = &m4updev->dev;
- } else {
- head = dev->archdata.iommu;
+ dev->iommu_fwspec->iommu_priv = platform_get_drvdata(m4updev);
}
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- ret = -ENOMEM;
- goto err_free_mem;
- }
- priv->mtk_m4u_id = args->args[0];
- list_add_tail(&priv->client, &head->client);
+ ret = iommu_fwspec_add_ids(dev, args->args, 1);
+ if (ret)
+ return ret;
- m4udev = head->m4udev;
+ data = dev->iommu_fwspec->iommu_priv;
+ m4udev = data->dev;
mtk_mapping = m4udev->archdata.iommu;
if (!mtk_mapping) {
/* MTK iommu support 4GB iova address space. */
mtk_mapping = arm_iommu_create_mapping(&platform_bus_type,
0, 1ULL << 32);
- if (IS_ERR(mtk_mapping)) {
- ret = PTR_ERR(mtk_mapping);
- goto err_free_mem;
- }
+ if (IS_ERR(mtk_mapping))
+ return PTR_ERR(mtk_mapping);
+
m4udev->archdata.iommu = mtk_mapping;
}
@@ -432,11 +426,6 @@ static int mtk_iommu_create_mapping(struct device *dev,
err_release_mapping:
arm_iommu_release_mapping(mtk_mapping);
m4udev->archdata.iommu = NULL;
-err_free_mem:
- list_for_each_entry_safe(priv, next, &head->client, client)
- kfree(priv);
- kfree(head);
- dev->archdata.iommu = NULL;
return ret;
}
@@ -458,8 +447,8 @@ static int mtk_iommu_add_device(struct device *dev)
of_node_put(iommu_spec.np);
}
- if (!dev->archdata.iommu) /* Not a iommu client device */
- return -ENODEV;
+ if (!dev->iommu_fwspec || dev->iommu_fwspec->ops != &mtk_iommu_ops)
+ return -ENODEV; /* Not a iommu client device */
group = iommu_group_get_for_dev(dev);
if (IS_ERR(group))
@@ -471,33 +460,21 @@ static int mtk_iommu_add_device(struct device *dev)
static void mtk_iommu_remove_device(struct device *dev)
{
- struct mtk_iommu_client_priv *head, *cur, *next;
-
- head = dev->archdata.iommu;
- if (!head)
+ if (!dev->iommu_fwspec || dev->iommu_fwspec->ops != &mtk_iommu_ops)
return;
- list_for_each_entry_safe(cur, next, &head->client, client) {
- list_del(&cur->client);
- kfree(cur);
- }
- kfree(head);
- dev->archdata.iommu = NULL;
-
iommu_group_remove_device(dev);
+ iommu_fwspec_free(dev);
}
static struct iommu_group *mtk_iommu_device_group(struct device *dev)
{
- struct mtk_iommu_data *data;
- struct mtk_iommu_client_priv *priv;
+ struct mtk_iommu_data *data = dev->iommu_fwspec->iommu_priv;
- priv = dev->archdata.iommu;
- if (!priv)
+ if (!data)
return ERR_PTR(-ENODEV);
/* All the client devices are in the same m4u iommu-group */
- data = dev_get_drvdata(priv->m4udev);
if (!data->m4u_group) {
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] iommu/mediatek: Convert M4Uv2 to iommu_fwspec
From: Robin Murphy @ 2016-10-17 11:49 UTC (permalink / raw)
To: linux-arm-kernel
Our per-device data consists of the M4U instance and firmware-provided
list of LARB IDs, which is a perfect fit for the generic iommu_fwspec
machinery. Use that directly as a simpler alternative to the custom
archdata code.
CC: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
These are fairly mechanical cleanups, so I'm pretty confident, but it
still bears mentioning that they're only compile-tested as I don't have
the relevant hardware.
Robin.
drivers/iommu/mtk_iommu.c | 75 ++++++++++++-----------------------------------
1 file changed, 18 insertions(+), 57 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index b12c12d74c33..13bb57995cd3 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -195,14 +195,14 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
static void mtk_iommu_config(struct mtk_iommu_data *data,
struct device *dev, bool enable)
{
- struct mtk_iommu_client_priv *head, *cur, *next;
struct mtk_smi_larb_iommu *larb_mmu;
unsigned int larbid, portid;
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+ int i;
- head = dev->archdata.iommu;
- list_for_each_entry_safe(cur, next, &head->client, client) {
- larbid = MTK_M4U_TO_LARB(cur->mtk_m4u_id);
- portid = MTK_M4U_TO_PORT(cur->mtk_m4u_id);
+ for (i = 0; i < fwspec->num_ids; ++i) {
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[i]);
+ portid = MTK_M4U_TO_PORT(fwspec->ids[i]);
larb_mmu = &data->smi_imu.larb_imu[larbid];
dev_dbg(dev, "%s iommu port: %d\n",
@@ -282,14 +282,12 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
struct device *dev)
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
- struct mtk_iommu_client_priv *priv = dev->archdata.iommu;
- struct mtk_iommu_data *data;
+ struct mtk_iommu_data *data = dev->iommu_fwspec->iommu_priv;
int ret;
- if (!priv)
+ if (!data)
return -ENODEV;
- data = dev_get_drvdata(priv->m4udev);
if (!data->m4u_dom) {
data->m4u_dom = dom;
ret = mtk_iommu_domain_finalise(data);
@@ -310,13 +308,11 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
static void mtk_iommu_detach_device(struct iommu_domain *domain,
struct device *dev)
{
- struct mtk_iommu_client_priv *priv = dev->archdata.iommu;
- struct mtk_iommu_data *data;
+ struct mtk_iommu_data *data = dev->iommu_fwspec->iommu_priv;
- if (!priv)
+ if (!data)
return;
- data = dev_get_drvdata(priv->m4udev);
mtk_iommu_config(data, dev, false);
}
@@ -366,8 +362,8 @@ static int mtk_iommu_add_device(struct device *dev)
{
struct iommu_group *group;
- if (!dev->archdata.iommu) /* Not a iommu client device */
- return -ENODEV;
+ if (!dev->iommu_fwspec || dev->iommu_fwspec->ops != &mtk_iommu_ops)
+ return -ENODEV; /* Not a iommu client device */
group = iommu_group_get_for_dev(dev);
if (IS_ERR(group))
@@ -379,33 +375,21 @@ static int mtk_iommu_add_device(struct device *dev)
static void mtk_iommu_remove_device(struct device *dev)
{
- struct mtk_iommu_client_priv *head, *cur, *next;
-
- head = dev->archdata.iommu;
- if (!head)
+ if (!dev->iommu_fwspec || dev->iommu_fwspec->ops != &mtk_iommu_ops)
return;
- list_for_each_entry_safe(cur, next, &head->client, client) {
- list_del(&cur->client);
- kfree(cur);
- }
- kfree(head);
- dev->archdata.iommu = NULL;
-
iommu_group_remove_device(dev);
+ iommu_fwspec_free(dev);
}
static struct iommu_group *mtk_iommu_device_group(struct device *dev)
{
- struct mtk_iommu_data *data;
- struct mtk_iommu_client_priv *priv;
+ struct mtk_iommu_data *data = dev->iommu_fwspec->iommu_priv;
- priv = dev->archdata.iommu;
- if (!priv)
+ if (!data)
return ERR_PTR(-ENODEV);
/* All the client devices are in the same m4u iommu-group */
- data = dev_get_drvdata(priv->m4udev);
if (!data->m4u_group) {
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
@@ -416,7 +400,6 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
static int mtk_iommu_of_xlate(struct device *dev, struct of_phandle_args *args)
{
- struct mtk_iommu_client_priv *head, *priv, *next;
struct platform_device *m4updev;
if (args->args_count != 1) {
@@ -425,38 +408,16 @@ static int mtk_iommu_of_xlate(struct device *dev, struct of_phandle_args *args)
return -EINVAL;
}
- if (!dev->archdata.iommu) {
+ if (!dev->iommu_fwspec->iommu_priv) {
/* Get the m4u device */
m4updev = of_find_device_by_node(args->np);
if (WARN_ON(!m4updev))
return -EINVAL;
- head = kzalloc(sizeof(*head), GFP_KERNEL);
- if (!head)
- return -ENOMEM;
-
- dev->archdata.iommu = head;
- INIT_LIST_HEAD(&head->client);
- head->m4udev = &m4updev->dev;
- } else {
- head = dev->archdata.iommu;
+ dev->iommu_fwspec->iommu_priv = platform_get_drvdata(m4updev);
}
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv)
- goto err_free_mem;
-
- priv->mtk_m4u_id = args->args[0];
- list_add_tail(&priv->client, &head->client);
-
- return 0;
-
-err_free_mem:
- list_for_each_entry_safe(priv, next, &head->client, client)
- kfree(priv);
- kfree(head);
- dev->archdata.iommu = NULL;
- return -ENOMEM;
+ return iommu_fwspec_add_ids(dev, args->args, 1);
}
static struct iommu_ops mtk_iommu_ops = {
--
1.9.1
^ permalink raw reply related
* [PATCH 6/6] ARM: sun5i: chip: Add optional buses
From: Maxime Ripard @ 2016-10-17 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.92d041a0a6fe40f1c8839cabb70247445eaffdfb.1476704881.git-series.maxime.ripard@free-electrons.com>
The I2C1 and SPI2 buses are exposed on the CHIP headers, and are not
explicitly dedicated to anything.
Add them to the DTS with the muxing already set, but keep them disabled.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun5i-r8-chip.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts b/arch/arm/boot/dts/sun5i-r8-chip.dts
index 059d86865b73..c6da5ad37152 100644
--- a/arch/arm/boot/dts/sun5i-r8-chip.dts
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -56,9 +56,11 @@
aliases {
i2c0 = &i2c0;
+ i2c1 = &i2c1;
i2c2 = &i2c2;
serial0 = &uart1;
serial1 = &uart3;
+ spi0 = &spi2;
};
chosen {
@@ -126,6 +128,12 @@
#include "axp209.dtsi"
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "disabled";
+};
+
&i2c2 {
pinctrl-names = "default";
pinctrl-0 = <&i2c2_pins_a>;
@@ -257,6 +265,12 @@
status = "okay";
};
+&spi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi2_pins_a>;
+ status = "disabled";
+};
+
&tcon0 {
status = "okay";
};
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 5/6] ARM: sun5i: Add RGB 565 LCD pins
From: Maxime Ripard @ 2016-10-17 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.92d041a0a6fe40f1c8839cabb70247445eaffdfb.1476704881.git-series.maxime.ripard@free-electrons.com>
Some boards use the LCD in RGB565. Enable the pin muxing option.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun5i.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 245cee14cf1d..b4ccee8cfb02 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -574,6 +574,16 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
+ lcd_rgb565_pins: lcd_rgb565 at 0 {
+ allwinner,pins = "PD3", "PD4", "PD5", "PD6", "PD7",
+ "PD10", "PD11", "PD12", "PD13", "PD14", "PD15",
+ "PD19", "PD20", "PD21", "PD22", "PD23",
+ "PD24", "PD25", "PD26", "PD27";
+ allwinner,function = "lcd0";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
mmc0_pins_a: mmc0 at 0 {
allwinner,pins = "PF0", "PF1", "PF2", "PF3",
"PF4", "PF5";
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 4/6] ARM: sun5i: Add SPI2 pins
From: Maxime Ripard @ 2016-10-17 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.92d041a0a6fe40f1c8839cabb70247445eaffdfb.1476704881.git-series.maxime.ripard@free-electrons.com>
All the sun5i have the SPI2 pins exposed on the PE bank. Add them to the
DT.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun5i.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index e374f4fc8073..245cee14cf1d 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -591,6 +591,20 @@
allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
};
+ spi2_pins_a: spi2 at 0 {
+ allwinner,pins = "PE1", "PE2", "PE3";
+ allwinner,function = "spi2";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
+ spi2_cs0_pins_a: spi2-cs0 at 0 {
+ allwinner,pins = "PE0";
+ allwinner,function = "spi2";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
uart3_pins_a: uart3 at 0 {
allwinner,pins = "PG9", "PG10";
allwinner,function = "uart3";
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 3/6] ARM: sun5i: Rename A10s pins
From: Maxime Ripard @ 2016-10-17 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.92d041a0a6fe40f1c8839cabb70247445eaffdfb.1476704881.git-series.maxime.ripard@free-electrons.com>
The SPI2 pins on the sun5i PB bank are only available on the A10s. Rename
the A10s only bank so that it doesn't confuse people on the other SoCs
whose indexing would start at b.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 4 ++--
arch/arm/boot/dts/sun5i-a10s.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index aef91476f9ae..0684d7930d65 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -250,8 +250,8 @@
&spi2 {
pinctrl-names = "default";
- pinctrl-0 = <&spi2_pins_a>,
- <&spi2_cs0_pins_a>;
+ pinctrl-0 = <&spi2_pins_b>,
+ <&spi2_cs0_pins_b>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
index c41a2ba34dde..7aa8c7aa0153 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -243,14 +243,14 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
- spi2_pins_a: spi2 at 0 {
+ spi2_pins_b: spi2 at 1 {
allwinner,pins = "PB12", "PB13", "PB14";
allwinner,function = "spi2";
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
- spi2_cs0_pins_a: spi2_cs0 at 0 {
+ spi2_cs0_pins_b: spi2_cs0 at 1 {
allwinner,pins = "PB11";
allwinner,function = "spi2";
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 2/6] ARM: sun5i: chip: add a node for the w1 gpio controller
From: Maxime Ripard @ 2016-10-17 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.92d041a0a6fe40f1c8839cabb70247445eaffdfb.1476704881.git-series.maxime.ripard@free-electrons.com>
From: Antoine Tenart <antoine.tenart@free-electrons.com>
The CHIP uses a 1-Wire bus to discover the DIPs. Enable the bus in the DT.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
arch/arm/boot/dts/sun5i-r8-chip.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts b/arch/arm/boot/dts/sun5i-r8-chip.dts
index e616084b9495..059d86865b73 100644
--- a/arch/arm/boot/dts/sun5i-r8-chip.dts
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -81,6 +81,13 @@
pinctrl-0 = <&chip_wifi_reg_on_pin>;
reset-gpios = <&pio 2 19 GPIO_ACTIVE_LOW>; /* PC19 */
};
+
+ onewire {
+ compatible = "w1-gpio";
+ gpios = <&pio 3 2 GPIO_ACTIVE_HIGH>; /* PD2 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&chip_w1_pin>;
+ };
};
&be0 {
@@ -181,6 +188,13 @@
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
+
+ chip_w1_pin: chip_w1_pin at 0 {
+ allwinner,pins = "PD2";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+ };
};
®_dcdc2 {
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 1/6] ARM: sun5i: chip: Enable Wi-Fi SDIO chip
From: Maxime Ripard @ 2016-10-17 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.92d041a0a6fe40f1c8839cabb70247445eaffdfb.1476704881.git-series.maxime.ripard@free-electrons.com>
The WiFi chip is powered through a GPIO and two regulators in parallel.
Since that case is not supported yet, just set them as always on before we
rework the regulator framework to deal with those.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun5i-r8-chip.dts | 41 ++++++++++++++++++++++++++++++-
1 file changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts b/arch/arm/boot/dts/sun5i-r8-chip.dts
index b68a12374b35..e616084b9495 100644
--- a/arch/arm/boot/dts/sun5i-r8-chip.dts
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -74,6 +74,13 @@
default-state = "on";
};
};
+
+ mmc0_pwrseq: mmc0_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&chip_wifi_reg_on_pin>;
+ reset-gpios = <&pio 2 19 GPIO_ACTIVE_LOW>; /* PC19 */
+ };
};
&be0 {
@@ -131,10 +138,15 @@
};
};
+&mmc0_pins_a {
+ allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>;
vmmc-supply = <®_vcc3v3>;
+ mmc-pwrseq = <&mmc0_pwrseq>;
bus-width = <4>;
non-removable;
status = "okay";
@@ -156,6 +168,13 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
+ chip_wifi_reg_on_pin: chip_wifi_reg_on_pin at 0 {
+ allwinner,pins = "PC19";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
chip_id_det_pin: chip_id_det_pin at 0 {
allwinner,pins = "PG2";
allwinner,function = "gpio_in";
@@ -189,6 +208,28 @@
regulator-always-on;
};
+/*
+ * Both LDO3 and LDO4 are used in parallel to power up the WiFi/BT
+ * Chip.
+ *
+ * If those are not enabled, the SDIO part will not enumerate, and
+ * since there's no way currently to pass DT infos to an SDIO device,
+ * we cannot really do better than this ugly hack for now.
+ */
+®_ldo3 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi-1";
+ regulator-always-on;
+};
+
+®_ldo4 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi-2";
+ regulator-always-on;
+};
+
®_ldo5 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 0/6] ARM: sun5i: chip: Misc improvements
From: Maxime Ripard @ 2016-10-17 11:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is a bunch of patches I gathered for the CHIP, that enables a few
things, like the WiFi regulators (and its associated power sequence), a few
optional buses, etc.
Let me know what you think,
Maxime
Antoine Tenart (1):
ARM: sun5i: chip: add a node for the w1 gpio controller
Maxime Ripard (5):
ARM: sun5i: chip: Enable Wi-Fi SDIO chip
ARM: sun5i: Rename A10s pins
ARM: sun5i: Add SPI2 pins
ARM: sun5i: Add RGB 565 LCD pins
ARM: sun5i: chip: Add optional buses
arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 4 +-
arch/arm/boot/dts/sun5i-a10s.dtsi | 4 +-
arch/arm/boot/dts/sun5i-r8-chip.dts | 69 +++++++++++++++++-
arch/arm/boot/dts/sun5i.dtsi | 24 ++++++-
4 files changed, 97 insertions(+), 4 deletions(-)
--
git-series 0.8.10
^ permalink raw reply
* [PATCH] ARM: dts: mps2: remove skeleton.dtsi include and fix unit address warnings
From: Vladimir Murzin @ 2016-10-17 11:47 UTC (permalink / raw)
To: linux-arm-kernel
Removale of skeleton.dtsi allows us also to fix the following
warning from the dts compiler:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
by adding proper unit addresses to the memory nodes.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/boot/dts/mps2-an385.dts | 2 +-
arch/arm/boot/dts/mps2-an399.dts | 2 +-
arch/arm/boot/dts/mps2.dtsi | 4 +++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/mps2-an385.dts b/arch/arm/boot/dts/mps2-an385.dts
index 31c374d..aebbebf 100644
--- a/arch/arm/boot/dts/mps2-an385.dts
+++ b/arch/arm/boot/dts/mps2-an385.dts
@@ -59,7 +59,7 @@
stdout-path = "serial0:9600n8";
};
- memory {
+ memory at 21000000 {
device_type = "memory";
reg = <0x21000000 0x1000000>;
};
diff --git a/arch/arm/boot/dts/mps2-an399.dts b/arch/arm/boot/dts/mps2-an399.dts
index 5e7e5ca..349abf7 100644
--- a/arch/arm/boot/dts/mps2-an399.dts
+++ b/arch/arm/boot/dts/mps2-an399.dts
@@ -59,7 +59,7 @@
stdout-path = "serial0:9600n8";
};
- memory {
+ memory at 60000000 {
device_type = "memory";
reg = <0x60000000 0x1000000>;
};
diff --git a/arch/arm/boot/dts/mps2.dtsi b/arch/arm/boot/dts/mps2.dtsi
index efb8a03..2346739 100644
--- a/arch/arm/boot/dts/mps2.dtsi
+++ b/arch/arm/boot/dts/mps2.dtsi
@@ -42,10 +42,12 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include "skeleton.dtsi"
#include "armv7-m.dtsi"
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
oscclk0: clk-osc0 {
compatible = "fixed-clock";
#clock-cells = <0>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Laurent Pinchart @ 2016-10-17 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a2ffcd0-fe1d-c887-53b7-7cb5e1e61222@ti.com>
Hello,
On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
> On 17/10/16 10:12, Sekhar Nori wrote:
>> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>>> On 15/10/16 20:42, Sekhar Nori wrote:
>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>>>> b/arch/arm/boot/dts/da850.dtsi
>>>>> index f79e1b9..32908ae 100644
>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>> @@ -399,6 +420,14 @@
>>>>> <&edma0 0 1>;
>>>>> dma-names = "tx", "rx";
>>>>> };
>>>>> +
>>>>> + display: display at 213000 {
>>>>> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>>>>
>>>> This should instead be:
>>>>
>>>> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>>>>
>>>> as the closest match should appear first in the list.
>>>
>>> Actually I don't think that's correct. The LCDC on da850 is not
>>> compatible with the LCDC on AM335x. I think it should be just
>>> "ti,da850-tilcdc".
>>
>> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
>> the case, I wonder how the patch passed testing. Bartosz?
>
> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
> similar, but different.
>
> The driver gets the version number from LCDC's register, and acts based
> on that, so afaik the compatible string doesn't really affect the
> functionality (as long as it matches).
>
> But even if it works with the current driver, I don't think
> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
If the hardware provides IP revision information, how about just "ti,lcdc" ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] crygpu/drm/exynos/exynos_hdmi - Unmap region obtained by of_iomap
From: Andrzej Hajda @ 2016-10-17 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476702562-24422-1-git-send-email-arvind.yadav.cs@gmail.com>
Hi,
On 17.10.2016 13:09, Arvind Yadav wrote:
> Free memory mapping, if hdmi_probe is not successful.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Subject prefix is incorrect.
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2275efe..9b7857b 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1901,6 +1901,8 @@ err_disable_pm_runtime:
> err_hdmiphy:
> if (hdata->hdmiphy_port)
> put_device(&hdata->hdmiphy_port->dev);
> + if (hdata->regs_hdmiphy)
> + iounmap(hdata->regs_hdmiphy);
Thats OK, you can add also unmap to hdmi_remove.
Regards
Andrzej
> err_ddc:
> put_device(&hdata->ddc_adpt->dev);
>
^ permalink raw reply
* ARM64-cpuinfo: Combine six calls for sequence output into one seq_printf() call in c_show()
From: SF Markus Elfring @ 2016-10-17 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017105605.GB29095@leverpostej>
>> Some data were printed into a sequence by six separate function calls.
>> Print the same data by a single function call instead.
>
> ... why?
>
> Beyond simply having fewer function calls, is there an upside?
Will it matter to improve run time characteristics at this source code place?
> This makes it harder to see the relationship between the format strings
> and their associated data, and makes the code longer.
Do you prefer an other layout for the passed data so that the increase
of line count in my update suggestion would look differently?
Regards,
Markus
^ permalink raw reply
* [PATCH v4 2/8] scpi: Add alternative legacy structures, functions and macros
From: Sudeep Holla @ 2016-10-17 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ecdedaf0-a4a4-9881-1068-9f186f7ac6af@baylibre.com>
On 17/10/16 09:25, Neil Armstrong wrote:
> On 10/10/2016 04:36 PM, Sudeep Holla wrote:
>> Hi Neil,
>>
>> Sorry, I could not reply to your response on v3. Anyways I will review v4.
>>
>> On 05/10/16 08:33, Neil Armstrong wrote:
>>> This patch adds support for the Legacy SCPI protocol in early JUNO versions and
>>> shipped Amlogic ARMv8 based SoCs. Some Rockchip SoC are also known to use this
>>> version of protocol with extended vendor commands
>>> .
>>> In order to support the legacy SCPI protocol variant, add back the structures
>>> and macros that varies against the final specification.
>>> Then add indirection table for legacy commands.
>>> Finally Add bitmap field for channel selection since the Legacy protocol mandates to
>>> send a selected subset of the commands on the high priority channel instead of the
>>> low priority channel.
>>>
>>> The message sending path differs from the final SCPI procotocol because the
>>> Amlogic SCP firmware always reply 1 instead of a special value containing the command
>>> byte and replied rx data length.
>>> For this reason commands queuing cannot be used and we assume the reply command is
>>> the head of the rx_pending list since we ensure sequential command sending with a
>>> separate dedicated mutex.
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>> ---
>>> drivers/firmware/arm_scpi.c | 221 +++++++++++++++++++++++++++++++++++++++-----
>>> 1 file changed, 199 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
>>> index 498afa0..6244eb1 100644
>>> --- a/drivers/firmware/arm_scpi.c
>>> +++ b/drivers/firmware/arm_scpi.c
>>
>> [...]
>>
>>> @@ -307,21 +398,46 @@ static void scpi_process_cmd(struct scpi_chan *ch, u32 cmd)
>>> return;
>>> }
>>>
>>> - list_for_each_entry(t, &ch->rx_pending, node)
>>> - if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
>>> - list_del(&t->node);
>>> - match = t;
>>> - break;
>>> - }
>>> + /* Command type is not replied by the SCP Firmware in legacy Mode
>>> + * We should consider that command is the head of pending RX commands
>>> + * if the list is not empty. In TX only mode, the list would be empty.
>>> + */
>>> + if (scpi_info->is_legacy) {
>>> + match = list_first_entry(&ch->rx_pending, struct scpi_xfer,
>>> + node);
>>> + list_del(&match->node);
>>> + } else {
>>> + list_for_each_entry(t, &ch->rx_pending, node)
>>> + if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
>>> + list_del(&t->node);
>>> + match = t;
>>> + break;
>>> + }
>>> + }
>>> /* check if wait_for_completion is in progress or timed-out */
>>> if (match && !completion_done(&match->done)) {
>>> - struct scpi_shared_mem *mem = ch->rx_payload;
>>> - unsigned int len = min(match->rx_len, CMD_SIZE(cmd));
>>> + unsigned int len;
>>> +
>>> + if (scpi_info->is_legacy) {
>>> + struct legacy_scpi_shared_mem *mem = ch->rx_payload;
>>> +
>>> + /* RX Length is not replied by the lagcy Firmware */
Typo above legacy
>>> + len = match->rx_len;
>>> +
>>> + match->status = le32_to_cpu(mem->status);
>>> + memcpy_fromio(match->rx_buf, mem->payload, len);
>>
>> The above 2 seems common to both, no ?
>
> No, the shared_mem structure differs.
>
Yes I see that, I was just referring the last 2 statements.
>>
>>> + } else {
>>> + struct scpi_shared_mem *mem = ch->rx_payload;
>>> +
>>> + len = min(match->rx_len, CMD_SIZE(cmd));
>>> +
>>> + match->status = le32_to_cpu(mem->status);
>>> + memcpy_fromio(match->rx_buf, mem->payload, len);
and the above 2 can be moved out of the conditions, no ?
if (scpi_info->is_legacy) {
struct legacy_scpi_shared_mem *mem = ch->rx_payload;
len = match->rx_len;
} else {
struct scpi_shared_mem *mem = ch->rx_payload;
len = min(match->rx_len, CMD_SIZE(cmd));
}
match->status = le32_to_cpu(mem->status);
memcpy_fromio(match->rx_buf, mem->payload, len);
should work.
[...]
>>
>>> + else
>>> + cmd = le32_to_cpu(mem->command);
>>>
>>> scpi_process_cmd(ch, cmd);
>>> }
>>> @@ -343,17 +464,26 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
>>> struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
>>> struct scpi_shared_mem *mem = (struct scpi_shared_mem *)ch->tx_payload;
>>>
>>> - if (t->tx_buf)
>>> - memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
>>> + if (t->tx_buf) {
>>> + if (scpi_info->is_legacy)
>>> + memcpy_toio(ch->tx_payload, t->tx_buf, t->tx_len);
>>> + else
>>> + memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
>>> + }
>>> +
>>> if (t->rx_buf) {
>>> if (!(++ch->token))
>>> ++ch->token;
>>> ADD_SCPI_TOKEN(t->cmd, ch->token);
>>> + if (scpi_info->is_legacy)
>>> + t->slot = t->cmd;
>>
>> I thought passing token was not an issue from your previous response,
>> but you are overriding it here, why ?
>
> Indeed, I can leave it, but it's useless since it won't serve to
> distinguish multiple similar commands.
>
OK, I don't see any point in such micro optimization, so please retain it.
[...]
>>> + /* Since we cannot distinguish the original command in the
>>> + * MHU reply stat value from a Legacy SCP firmware, ensure
>>> + * sequential command sending to the firmware.
>>> + */
>>
>> OK this comment now questions the existence of this extra lock.
>> The mailbox will always send the commands in the sequential order.
>> It's only firmware that can re-order the response. Since that can't
>> happen in you case, I really don't see the need for this.
>>
>> Please explain the race you would see without this locking. Yes I
>> understand that only one command is supposed to be sent to firmware at a
>> time. Suppose you allow more callers here, all will wait on the
>> completion flags and the first in the list gets unblocked right ?
>> I am just trying to understand if there's real need for this extra
>> lock when we already have that from the list.
>
> In my current tests I have huge kernel hang when having multiple callers,
> I must find out where this issue comes from...
Yes IMO, you should understand the root cause of this issue. There may
be issue with the existing driver itself. But just adding a lock just to
avoid the hang without understanding it is wrong.
> In any case, we have an issue about the command sequencing. If we
> push a tx-only command and then right after a tx-rx command, the
> mailbox callback from the first command won't be able to distinguish
> which command is handled !
Hmm, how exactly ? I won't expect scpi_handle_remote_msg to becalled in
that case.
> In this case, the rx_pending list will not be empty, some garbage
> will be returned to the second command handler and the real data from
> the second command handling will be lost thinking it's a tx-only
> command.
>
Yes as I said why is scpi_handle_remote_msg called for tx only command.
And more over we don't have any tx only command in the driver, I am
still unable to understand the issue you are facing. Are you sure you
have tx-only command in the failure/hang case ?
>
> We have two choices here : - Also push the tx-only commands to the
> rx_pending list, and also wait for their completion
See above, I need to know details on this tx-only command. In fact, they
may not be tx-only as SCP is sending some response back, may just status.
> - Add an extra lock
>
Not this for sure.
> What is your preferred scheme ?
>
Option 1 if it legitimate case. I mean we may be misunderstanding the
definition of tx-only command.
>>> + if (scpi_info->is_legacy)
>>> + mutex_lock(&scpi_chan->legacy_lock);
>>> +
>>> ret = mbox_send_message(scpi_chan->chan, msg);
>>> if (ret < 0 || !rx_buf)
>>> goto out;
>>> @@ -421,9 +567,13 @@ static int scpi_send_message(unsigned int offset, void *tx_buf,
>>> /* first status word */
>>> ret = msg->status;
>>> out:
>>> - if (ret < 0 && rx_buf) /* remove entry from the list if timed-out */
>>> + if (ret < 0 && rx_buf)
>>> + /* remove entry from the list if timed-out */
>>> scpi_process_cmd(scpi_chan, msg->cmd);
>>>
>>> + if (scpi_info->is_legacy)
>>> + mutex_unlock(&scpi_chan->legacy_lock);
>>> +
>>> put_scpi_xfer(msg, scpi_chan);
>>> /* SCPI error codes > 0, translate them to Linux scale*/
>>> return ret > 0 ? scpi_to_linux_errno(ret) : ret;
>>
[...]
>
> I will fix the issues, but I need your advice for the locking scheme. I really want this
> to be merged and be able to go forward !
>
Yes I agree and I have no major concern with the series now except the
locking.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] usb: ehci-platform: increase EHCI_MAX_RSTS to 4
From: Masahiro Yamada @ 2016-10-17 11:11 UTC (permalink / raw)
To: linux-arm-kernel
Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
needs to handle 4 reset lines for EHCI.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/usb/host/ehci-platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 876dca4..a268d9e 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -39,7 +39,7 @@
#define DRIVER_DESC "EHCI generic platform driver"
#define EHCI_MAX_CLKS 4
-#define EHCI_MAX_RSTS 3
+#define EHCI_MAX_RSTS 4
#define hcd_to_ehci_priv(h) ((struct ehci_platform_priv *)hcd_to_ehci(h)->priv)
struct ehci_platform_priv {
--
1.9.1
^ permalink raw reply related
* [PATCH] crygpu/drm/exynos/exynos_hdmi - Unmap region obtained by of_iomap
From: Arvind Yadav @ 2016-10-17 11:09 UTC (permalink / raw)
To: linux-arm-kernel
Free memory mapping, if hdmi_probe is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2275efe..9b7857b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1901,6 +1901,8 @@ err_disable_pm_runtime:
err_hdmiphy:
if (hdata->hdmiphy_port)
put_device(&hdata->hdmiphy_port->dev);
+ if (hdata->regs_hdmiphy)
+ iounmap(hdata->regs_hdmiphy);
err_ddc:
put_device(&hdata->ddc_adpt->dev);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] iommu/arm-smmu: Work around ARM DMA configuration
From: Robin Murphy @ 2016-10-17 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5cf1acbf9c42cc99e5cc0dacb50b7a92c3bd0feb.1476702234.git.robin.murphy@arm.com>
The 32-bit ARM DMA configuration code predates the IOMMU core's default
domain functionality, and instead relies on allocating its own domains
and attaching any devices using the generic IOMMU binding to them.
Unfortunately, it does this relatively early on in the creation of the
device, before we've seen our add_device callback, which leads us to
attempt to operate on a half-configured master.
To avoid a crash, check for this situation on attach, but refuse to
play, as there's nothing we can do. This at least allows VFIO to keep
working for people who update their 32-bit DTs to the generic binding,
albeit with a few (innocuous) warnings from the DMA layer on boot.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index c841eb7a1a74..3af7f8f62d0a 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1228,6 +1228,16 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
return -ENXIO;
}
+ /*
+ * FIXME: The arch/arm DMA API code tries to attach devices to its own
+ * domains between of_xlate() and add_device() - we have no way to cope
+ * with that, so until ARM gets converted to rely on groups and default
+ * domains, just say no (but more politely than by dereferencing NULL).
+ * This should be at least a WARN_ON once that's sorted.
+ */
+ if (!fwspec->iommu_priv)
+ return -ENODEV;
+
smmu = fwspec_smmu(fwspec);
/* Ensure that the domain is finalised */
ret = arm_smmu_init_domain_context(domain, smmu);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Robin Murphy @ 2016-10-17 11:06 UTC (permalink / raw)
To: linux-arm-kernel
We now delay installing our per-bus iommu_ops until we know an SMMU has
successfully probed, as they don't serve much purpose beforehand, and
doing so also avoids fights between multiple IOMMU drivers in a single
kernel. However, the upshot of passing the return value of bus_set_iommu()
back from our probe function is that if there happens to be more than
one SMMUv3 device in a system, the second and subsequent probes will
wind up returning -EBUSY to the driver core and getting torn down again.
There are essentially 3 cases in which bus_set_iommu() returns nonzero:
1. The bus already has iommu_ops installed
2. One of the add_device callbacks from the initial notifier failed
3. Allocating or installing the notifier itself failed
The first two are down to devices other than the SMMU in question, so
shouldn't abort an otherwise-successful SMMU probe, whilst the third is
indicative of the kind of catastrophic system failure which isn't going
to get much further anyway. Consequently, there is little harm in
ignoring the return value either way.
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu-v3.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 15c01c3cd540..74fbef384deb 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
#ifdef CONFIG_PCI
pci_request_acs();
- ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
- if (ret)
- return ret;
+ bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
#endif
#ifdef CONFIG_ARM_AMBA
- ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
- if (ret)
- return ret;
+ bus_set_iommu(&amba_bustype, &arm_smmu_ops);
#endif
- return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
+ bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
+ return 0;
}
static int arm_smmu_device_remove(struct platform_device *pdev)
--
1.9.1
^ permalink raw reply related
* [PATCHv2 3/4] arm64: dump: Remove max_addr
From: Mark Rutland @ 2016-10-17 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476311522-15381-4-git-send-email-labbott@redhat.com>
On Wed, Oct 12, 2016 at 03:32:01PM -0700, Laura Abbott wrote:
>
> max_addr was added as part of struct ptdump_info but has never actually
> been used. Remove it.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> New for v2 of the series
> ---
> arch/arm64/include/asm/ptdump.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index 7c35689..8fc0957 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -30,7 +30,6 @@ struct ptdump_info {
> struct mm_struct *mm;
> const struct addr_marker *markers;
> unsigned long base_addr;
> - unsigned long max_addr;
> };
>
> void ptdump_walk_pgd(struct seq_file *s, struct ptdump_info *info);
> --
> 2.7.4
>
^ permalink raw reply
* [PATCHv2 2/4] arm64: dump: Make the page table dumping seq_file optional
From: Mark Rutland @ 2016-10-17 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476311522-15381-3-git-send-email-labbott@redhat.com>
On Wed, Oct 12, 2016 at 03:32:00PM -0700, Laura Abbott wrote:
>
> The page table dumping code always assumes it will be dumping to a
> seq_file to userspace. Future code will be taking advantage of
> the page table dumping code but will not need the seq_file. Make
> the seq_file optional for these cases.
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
Now that I'm back in the office with access to hardware, I've been able
to give this a spin. FWIW, feel free to upgrade the above to:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
^ permalink raw reply
* [PATCH] ARM64-cpuinfo: Combine six calls for sequence output into one seq_printf() call in c_show()
From: Mark Rutland @ 2016-10-17 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83d98772-8872-1b75-a9a5-5f08b8462e18@users.sourceforge.net>
On Sun, Oct 16, 2016 at 09:03:52PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 16 Oct 2016 20:48:28 +0200
>
> Some data were printed into a sequence by six separate function calls.
> Print the same data by a single function call instead.
... why?
Beyond simply having fewer function calls, is there an upside?
This makes it harder to see the relationship between the format strings
and their associated data, and makes the code longer.
Thanks,
Mark.
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> arch/arm64/kernel/cpuinfo.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index b3d5b3e..f22687d 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -148,14 +148,17 @@ static int c_show(struct seq_file *m, void *v)
> if (elf_hwcap & (1 << j))
> seq_printf(m, " %s", hwcap_str[j]);
> }
> - seq_puts(m, "\n");
> -
> - seq_printf(m, "CPU implementer\t: 0x%02x\n",
> - MIDR_IMPLEMENTOR(midr));
> - seq_printf(m, "CPU architecture: 8\n");
> - seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr));
> - seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr));
> - seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr));
> + seq_printf(m,
> + "\n"
> + "CPU implementer\t: 0x%02x\n"
> + "CPU architecture: 8\n"
> + "CPU variant\t: 0x%x\n"
> + "CPU part\t: 0x%03x\n"
> + "CPU revision\t: %d\n\n",
> + MIDR_IMPLEMENTOR(midr),
> + MIDR_VARIANT(midr),
> + MIDR_PARTNUM(midr),
> + MIDR_REVISION(midr));
> }
>
> return 0;
> --
> 2.10.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCHv2 1/4] arm64: dump: Make ptdump debugfs a separate option
From: Mark Rutland @ 2016-10-17 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476311522-15381-2-git-send-email-labbott@redhat.com>
Hi Laura,
In looking at this, I realised I was confused about ptdump_initialize()
previously, and now see why we can't decouple the debugfs registration
of the kernel page tables from the rest of the ptdump init. Sorry for
the noise on that.
Aside from one issue below, this looks good to me.
On Wed, Oct 12, 2016 at 03:31:59PM -0700, Laura Abbott wrote:
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index 07b8ed0..7c35689 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -16,9 +16,10 @@
> #ifndef __ASM_PTDUMP_H
> #define __ASM_PTDUMP_H
>
> -#ifdef CONFIG_ARM64_PTDUMP
> +#ifdef CONFIG_ARM64_PTDUMP_CORE
>
> #include <linux/mm_types.h>
> +#include <linux/seq_file.h>
>
> struct addr_marker {
> unsigned long start_address;
> @@ -32,13 +33,15 @@ struct ptdump_info {
> unsigned long max_addr;
> };
>
> -int ptdump_register(struct ptdump_info *info, const char *name);
> -
> +void ptdump_walk_pgd(struct seq_file *s, struct ptdump_info *info);
> +#ifdef CONFIG_ARM64_PTDUMP_DEBUGFS
> +int ptdump_debugfs_register(struct ptdump_info *info, const char *name);
> #else
> -static inline int ptdump_register(struct ptdump_info *info, const char *name)
> +static inline int ptdump_debugfs_register(struct ptdump_info *info,
> + const char *name)
> {
> return 0;
> }
> -#endif /* CONFIG_ARM64_PTDUMP */
> +#endif
I think you didn't mean to remove the existing endif here?
It's still needed to guard the CONFIG_ARM64_PTDUMP_CORE case, and the
new one is needed for the new #ifdef CONFIG_ARM64_PTDUMP_DEBUGFS.
Without it, I get a build error with this patch atop of v4.9-rc1 with
CONFIG_ARM64_PTDUMP_DEBUGFS selected:
[mark at leverpostej:~/src/linux]% uselinaro 15.08 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j10 -s
In file included from arch/arm64/mm/ptdump_debugfs.c:4:0:
./arch/arm64/include/asm/ptdump.h:16:0: error: unterminated #ifndef
#ifndef __ASM_PTDUMP_H
^
make[1]: *** [arch/arm64/mm/ptdump_debugfs.o] Error 1
make[1]: *** Waiting for unfinished jobs....
With that #endif restored, everything works fine. So FWIW, with that:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
[...]
> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
> index 7c75a8d..33d35e8 100644
> --- a/drivers/firmware/efi/arm-runtime.c
> +++ b/drivers/firmware/efi/arm-runtime.c
> @@ -39,7 +39,7 @@ static struct mm_struct efi_mm = {
> .mmlist = LIST_HEAD_INIT(efi_mm.mmlist),
> };
>
> -#ifdef CONFIG_ARM64_PTDUMP
> +#ifdef CONFIG_ARM64_PTDUMP_DEBUGFS
> #include <asm/ptdump.h>
>
> static struct ptdump_info efi_ptdump_info = {
> @@ -53,10 +53,9 @@ static struct ptdump_info efi_ptdump_info = {
>
> static int __init ptdump_init(void)
> {
> - return ptdump_register(&efi_ptdump_info, "efi_page_tables");
> + return ptdump_debugfs_register(&efi_ptdump_info, "efi_page_tables");
> }
> device_initcall(ptdump_init);
> -
> #endif
For the EFI changes, we'll need an ack from Ard or Matt; this should
probably be Cc'd to the linux-efi list for that.
Thanks,
Mark.
^ permalink raw reply
* master build: 2 failures 4 warnings (v4.8-11811-g35ff96d)
From: Mark Brown @ 2016-10-17 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5682869.nmeogTxQJD@wuerfel>
On Fri, Oct 14, 2016 at 10:12:04PM +0200, Arnd Bergmann wrote:
> On Friday, October 14, 2016 11:33:44 AM CEST Lee Jones wrote:
> > I'm waiting on a firm answer from Arnd and Thomas before applying
> > anything.
> I don't understand what the hardware does, so I'm not really
> able to answer this. Maybe just mark the driver as 'depends on
> BROKEN' for now?
There are a few boards using it, we should probably revert the broken
patches rather than just completely disable the driver.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/3b8b7d09/attachment-0001.sig>
^ permalink raw reply
* [PATCH] drivers: psci: Allow PSCI node to be disabled
From: Thierry Reding @ 2016-10-17 10:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Thierry Reding <treding@nvidia.com>
Allow disabling PSCI support (mostly for testing purposes) by setting
the status property to "disabled". This makes the node behave in much
the same way as proper device nodes.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/firmware/psci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 8263429e21b8..6c60a5087caf 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -630,7 +630,7 @@ int __init psci_dt_init(void)
np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
- if (!np)
+ if (!np || !of_device_is_available(np))
return -ENODEV;
init_fn = (psci_initcall_t)matched_np->data;
--
2.10.0
^ 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