* [PATCH v2 6/9] drm/sun4i: tcon: Find matching display backend by device node matching
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421083857.29636-1-wens@csie.org>
With Allwinner's Display Engine 1.0, each TCON's input is tied to a
specific display backend, and the 2 comprise what is known as a crtc
in DRM KMS land: The layer, framebuffer, and compositing functions are
provided by the backend, while the TCON provides the display timing
signals and vblank interrupts. This 1 to 1 relationship is represented
in the device tree. On some systems there is an intermediate DRC
component.
Pointers to both matching components must be provided when initializing
the crtc. As the backend is always registered before the associated
tcon, we can recursively search upwards through the of_graph to find
the matching backend.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 55 +++++++++++++++++++++++++++++++++++---
1 file changed, 51 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 52f37ef9a050..4409e7b6c74d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -472,6 +472,53 @@ struct drm_bridge *sun4i_tcon_find_bridge(struct device_node *node)
return of_drm_find_bridge(remote) ?: ERR_PTR(-EPROBE_DEFER);
}
+/*
+ * On SoCs with the old display pipeline design (Display Engine 1.0),
+ * the TCON is always tied to just one backend. Hence we can traverse
+ * the of_graph upwards to find the backend our tcon is connected to,
+ * and take its ID as our own.
+ *
+ * We can either identify backends from their compatible strings, which
+ * means maintaining a large list of them. Or, since the backend is
+ * registered and binded before the TCON, we can just go through the
+ * list of registered backends and compare the device node.
+ */
+static struct sun4i_backend *sun4i_tcon_find_backend(struct sun4i_drv *drv,
+ struct device_node *node)
+{
+ struct device_node *port, *ep, *remote;
+ struct sun4i_backend *backend;
+
+ port = of_graph_get_port_by_id(node, 0);
+ if (!port)
+ return ERR_PTR(-EINVAL);
+
+ for_each_available_child_of_node(port, ep) {
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote)
+ continue;
+
+ /* does this node match any registered backends? */
+ list_for_each_entry(backend, &drv->backend_list, list) {
+ if (remote == backend->node) {
+ of_node_put(remote);
+ of_node_put(port);
+ return backend;
+ }
+ }
+
+ /* keep looking through upstream ports */
+ backend = sun4i_tcon_find_backend(drv, remote);
+ if (!IS_ERR(backend)) {
+ of_node_put(remote);
+ of_node_put(port);
+ return backend;
+ }
+ }
+
+ return ERR_PTR(-EINVAL);
+}
+
static int sun4i_tcon_bind(struct device *dev, struct device *master,
void *data)
{
@@ -481,9 +528,11 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
struct sun4i_tcon *tcon;
int ret;
- /* Wait for a backend to be registered */
- if (list_empty(&drv->backend_list))
+ backend = sun4i_tcon_find_backend(drv, dev->of_node);
+ if (IS_ERR(backend)) {
+ dev_err(dev, "Couldn't find matching backend\n");
return -EPROBE_DEFER;
+ }
tcon = devm_kzalloc(dev, sizeof(*tcon), GFP_KERNEL);
if (!tcon)
@@ -533,8 +582,6 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
goto err_free_dotclock;
}
- backend = list_first_entry(&drv->backend_list,
- struct sun4i_backend, list);
tcon->crtc = sun4i_crtc_init(drm, backend, tcon);
if (IS_ERR(tcon->crtc)) {
dev_err(dev, "Couldn't create our CRTC\n");
--
2.11.0
^ permalink raw reply related
* [PATCH v2 5/9] drm/sun4i: backend: Save pointer to device tree node
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421083857.29636-1-wens@csie.org>
Save a pointer to the backend's underlying device tree node in its
data structure. This will be used later for downstream tcons to find
and match their respective upstream backends.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
drivers/gpu/drm/sun4i/sun4i_backend.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 0b4222312e49..e9eca057ff35 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -352,6 +352,7 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
return -ENOMEM;
dev_set_drvdata(dev, backend);
+ backend->node = dev->of_node;
backend->id = sun4i_backend_of_get_id(dev->of_node);
if (backend->id < 0)
return backend->id;
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 45b7fc110590..6327a2985fe6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -15,6 +15,7 @@
#include <linux/clk.h>
#include <linux/list.h>
+#include <linux/of.h>
#include <linux/regmap.h>
#include <linux/reset.h>
@@ -140,6 +141,7 @@
#define SUN4I_BACKEND_PIPE_OFF(p) (0x5000 + (0x400 * (p)))
struct sun4i_backend {
+ struct device_node *node;
struct regmap *regs;
struct reset_control *reset;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 4/9] drm/sun4i: backend: Fetch backend ID from device tree
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421083857.29636-1-wens@csie.org>
Some Allwinner SoCs have 2 display pipelines, as in 2 of each
components, including the frontend, backend, TCON, and any other
extras.
As the backend and TCON are always paired together and form the CRTC,
we need to know which backend or TCON we are currently probing, so we
can pair them when initializing the CRTC.
This patch figures out the backend's ID from the device tree and stores
it in the backend's data structure. It does this by looking at the "reg"
property of any remote endpoints connected to the backend's input port.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 44 +++++++++++++++++++++++++++++++++++
drivers/gpu/drm/sun4i/sun4i_backend.h | 2 ++
2 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index e17e20036aa3..0b4222312e49 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -20,6 +20,7 @@
#include <linux/component.h>
#include <linux/list.h>
+#include <linux/of_graph.h>
#include <linux/reset.h>
#include "sun4i_backend.h"
@@ -289,6 +290,45 @@ static int sun4i_backend_free_sat(struct device *dev) {
return 0;
}
+/*
+ * The display backend can take video output from the display frontend, or
+ * the display enhancement unit on the A80, as input for one it its layers.
+ * This relationship within the display pipeline is encoded in the device
+ * tree with of_graph, and we use it here to figure out which backend, if
+ * there are 2 or more, we are currently probing. The number would be in
+ * the "reg" property of the upstream output port endpoint.
+ */
+static int sun4i_backend_of_get_id(struct device_node *node)
+{
+ struct device_node *port, *ep;
+ int ret = -EINVAL;
+
+ /* input is port 0 */
+ port = of_graph_get_port_by_id(node, 0);
+ if (!port)
+ return -EINVAL;
+
+ /* try finding an upstream endpoint */
+ for_each_available_child_of_node(port, ep) {
+ struct device_node *remote;
+ u32 reg;
+
+ remote = of_parse_phandle(ep, "remote-endpoint", 0);
+ if (!remote)
+ continue;
+
+ ret = of_property_read_u32(remote, "reg", ®);
+ if (ret)
+ continue;
+
+ ret = reg;
+ }
+
+ of_node_put(port);
+
+ return ret;
+}
+
static struct regmap_config sun4i_backend_regmap_config = {
.reg_bits = 32,
.val_bits = 32,
@@ -312,6 +352,10 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
return -ENOMEM;
dev_set_drvdata(dev, backend);
+ backend->id = sun4i_backend_of_get_id(dev->of_node);
+ if (backend->id < 0)
+ return backend->id;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev, res);
if (IS_ERR(regs))
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 9c8287309c65..45b7fc110590 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -151,6 +151,8 @@ struct sun4i_backend {
struct clk *sat_clk;
struct reset_control *sat_reset;
+ int id;
+
/* Backend list management */
struct list_head list;
};
--
2.11.0
^ permalink raw reply related
* [PATCH v2 3/9] drm/sun4i: backend: Drop trailing 0 from backend in error message
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421083857.29636-1-wens@csie.org>
Now that we support multiple instances of backends, the trailing 0
implying only one backend no longer makes sense.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 95a77c6a9161..e17e20036aa3 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -320,7 +320,7 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
backend->regs = devm_regmap_init_mmio(dev, regs,
&sun4i_backend_regmap_config);
if (IS_ERR(backend->regs)) {
- dev_err(dev, "Couldn't create the backend0 regmap\n");
+ dev_err(dev, "Couldn't create the backend regmap\n");
return PTR_ERR(backend->regs);
}
--
2.11.0
^ permalink raw reply related
* [PATCH v2 2/9] drm/sun4i: Use lists to track registered display backends and TCONs
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421083857.29636-1-wens@csie.org>
To support multiple display pipelines, we need to keep track of the
multiple display backends and TCONs registered with the driver.
Switch to lists to track registered components. Components are only
appended to their respective lists if the bind process was successful.
The TCON bind function now defers if a backend was not registered.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 6 +++++-
drivers/gpu/drm/sun4i/sun4i_backend.h | 4 ++++
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
drivers/gpu/drm/sun4i/sun4i_drv.h | 4 +++-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 14 ++++++++++++--
drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
6 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index d660741ba475..95a77c6a9161 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -19,6 +19,7 @@
#include <drm/drm_plane_helper.h>
#include <linux/component.h>
+#include <linux/list.h>
#include <linux/reset.h>
#include "sun4i_backend.h"
@@ -310,7 +311,6 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
if (!backend)
return -ENOMEM;
dev_set_drvdata(dev, backend);
- drv->backend = backend;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev, res);
@@ -369,6 +369,8 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
}
}
+ list_add_tail(&backend->list, &drv->backend_list);
+
/* Reset the registers */
for (i = 0x800; i < 0x1000; i += 4)
regmap_write(backend->regs, i, 0);
@@ -400,6 +402,8 @@ static void sun4i_backend_unbind(struct device *dev, struct device *master,
{
struct sun4i_backend *backend = dev_get_drvdata(dev);
+ list_del(&backend->list);
+
if (of_device_is_compatible(dev->of_node,
"allwinner,sun8i-a33-display-backend"))
sun4i_backend_free_sat(dev);
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 83e63cc702b4..9c8287309c65 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -14,6 +14,7 @@
#define _SUN4I_BACKEND_H_
#include <linux/clk.h>
+#include <linux/list.h>
#include <linux/regmap.h>
#include <linux/reset.h>
@@ -149,6 +150,9 @@ struct sun4i_backend {
struct clk *sat_clk;
struct reset_control *sat_reset;
+
+ /* Backend list management */
+ struct list_head list;
};
void sun4i_backend_apply_color_correction(struct sun4i_backend *backend);
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 767bbadcc85d..89c51fd6e9af 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -101,6 +101,8 @@ static int sun4i_drv_bind(struct device *dev)
goto free_drm;
}
drm->dev_private = drv;
+ INIT_LIST_HEAD(&drv->backend_list);
+ INIT_LIST_HEAD(&drv->tcon_list);
ret = of_reserved_mem_device_init(dev);
if (ret && ret != -ENODEV) {
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h b/drivers/gpu/drm/sun4i/sun4i_drv.h
index 5df50126ff52..835bdb5cc0c2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.h
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
@@ -14,10 +14,12 @@
#define _SUN4I_DRV_H_
#include <linux/clk.h>
+#include <linux/list.h>
#include <linux/regmap.h>
struct sun4i_drv {
- struct sun4i_backend *backend;
+ struct list_head backend_list;
+ struct list_head tcon_list;
struct sun4i_tcon *tcon;
struct drm_fbdev_cma *fbdev;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 3ced0b1cef6e..52f37ef9a050 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -26,6 +26,7 @@
#include <linux/regmap.h>
#include <linux/reset.h>
+#include "sun4i_backend.h"
#include "sun4i_crtc.h"
#include "sun4i_dotclock.h"
#include "sun4i_drv.h"
@@ -476,14 +477,18 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
{
struct drm_device *drm = data;
struct sun4i_drv *drv = drm->dev_private;
+ struct sun4i_backend *backend;
struct sun4i_tcon *tcon;
int ret;
+ /* Wait for a backend to be registered */
+ if (list_empty(&drv->backend_list))
+ return -EPROBE_DEFER;
+
tcon = devm_kzalloc(dev, sizeof(*tcon), GFP_KERNEL);
if (!tcon)
return -ENOMEM;
dev_set_drvdata(dev, tcon);
- drv->tcon = tcon;
tcon->drm = drm;
tcon->dev = dev;
tcon->quirks = of_device_get_match_data(dev);
@@ -528,7 +533,9 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
goto err_free_dotclock;
}
- tcon->crtc = sun4i_crtc_init(drm, drv->backend, tcon);
+ backend = list_first_entry(&drv->backend_list,
+ struct sun4i_backend, list);
+ tcon->crtc = sun4i_crtc_init(drm, backend, tcon);
if (IS_ERR(tcon->crtc)) {
dev_err(dev, "Couldn't create our CRTC\n");
ret = PTR_ERR(tcon->crtc);
@@ -539,6 +546,8 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
if (ret < 0)
goto err_free_clocks;
+ list_add_tail(&tcon->list, &drv->tcon_list);
+
return 0;
err_free_dotclock:
@@ -555,6 +564,7 @@ static void sun4i_tcon_unbind(struct device *dev, struct device *master,
{
struct sun4i_tcon *tcon = dev_get_drvdata(dev);
+ list_del(&tcon->list);
sun4i_dclk_free(tcon);
sun4i_tcon_free_clocks(tcon);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index f636343a935d..1bda4d183eec 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -17,6 +17,7 @@
#include <drm/drm_crtc.h>
#include <linux/kernel.h>
+#include <linux/list.h>
#include <linux/reset.h>
#define SUN4I_TCON_GCTL_REG 0x0
@@ -172,6 +173,9 @@ struct sun4i_tcon {
/* Associated crtc */
struct sun4i_crtc *crtc;
+
+ /* TCON list management */
+ struct list_head list;
};
struct drm_bridge *sun4i_tcon_find_bridge(struct device_node *node);
--
2.11.0
^ permalink raw reply related
* [PATCH v2 1/9] dt-bindings: display: sun4i: Add component endpoint ID numbering scheme
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421083857.29636-1-wens@csie.org>
The Allwinner display pipeline contains many hardware components, some
of which can consume data from one of multiple upstream components.
The numbering scheme of these components must be encoded into the device
tree so the driver can figure out which component out of two or more of
the same type it is supposed to use or program.
This patch adds the constraint that local endpoint IDs must be the index
or number of the remote endpoint's hardware block, for all components
in the display pipeline up to the TCONs.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 57a8d0610062..7acdbf14ae1c 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -4,6 +4,16 @@ Allwinner A10 Display Pipeline
The Allwinner A10 Display pipeline is composed of several components
that are going to be documented below:
+For the input port of all components up to the TCON in the display
+pipeline, if there are multiple components, the local endpoint IDs
+must correspond to the index of the upstream block. For example, if
+the remote endpoint is Frontend 1, then the local endpoint ID must
+be 1.
+
+Conversely, for the output ports of the same group, the remote endpoint
+ID must be the index of the local hardware block. If the local backend
+is backend 1, then the remote endpoint ID must be 1.
+
TV Encoder
----------
--
2.11.0
^ permalink raw reply related
* [PATCH v2 0/9] drm/sun4i: Support multiple display pipelines
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is v2 of the series previously named "drm/sun4i: Support two
display pipelines". As the name change suggests, the driver now
supports any number of pipelines, though the hardware only has
2 or 3.
Changes since v1:
- Add component endpoint ID numbering scheme to device tree binding.
- Use lists to keep references to registered backends and tcons.
- Save pointer to device node for backends.
- Traverse the device tree of_graph starting from the tcons, going
up towards the inputs, and matching the device nodes with the
device nodes of registered backends, to find the one linked with
the tcon the search started from.
- Copy the ID for the tcon from its upstream backend, instead of
trying, and possibly failing, to figure it out from the device
tree.
- Split out hunk dropping trailing 0 from a backend error message.
Patch 1 adds the component endpoint ID numbering scheme to the
device tree binding. New in v2.
Patch 2 adds lists to track registered display backends and TCONs,
instead of just one pointer per component type. Previously added
arrays of pointers in v1.
Patch 3 drops the trailing 0 from one of the backend's bind error
messages. This was previously part of the patch "drm/sun4i: Support
two display pipelines".
Patch 4 adds a function to fetch a backend's ID from the device tree.
Unchanged.
Patch 5 adds a device node field to the backend data structure and
saves a reference to the underlying device node of the backend.
New in v2.
Patch 6 makes the tcon driver find its upstream backend by traversing
the of_graph and matching device nodes against the device nodes of
registered backends.
New in v2.
Patch 7 makes the tcon driver use the ID from its associated backend.
New in v2. This is not immediately used in this series, but will be
used in similar fashion for downstream encoders to figure out IDs and
muxing
Patch 8 adds device nodes for sun6i's second display pipeline.
Unchanged.
Patch 9 enables sun6i's tcon0 by default.
Unchanged.
With this series, the sun4i drm driver now supports registering multiple
display pipelines. However the driver does not guard against setups the
hardware does not support, such as driving 2 encoders with incompatible
dot clocks from the same source clock. Muxing of downstream encoders is
not supported either, as we have no drivers for hardware that uses them.
The WiP HDMI driver will be the first.
While this series enables the second display pipeline, there's no
usable output at the moment. For the A31, the second TCON's panel
interface uses the same pins as the Ethernet controller. However
Ethernet is used on most boards.
Regards
ChenYu
Chen-Yu Tsai (9):
dt-bindings: display: sun4i: Add component endpoint ID numbering
scheme
drm/sun4i: Use lists to track registered display backends and TCONs
drm/sun4i: backend: Drop trailing 0 from backend in error message
drm/sun4i: backend: Fetch backend ID from device tree
drm/sun4i: backend: Save pointer to device tree node
drm/sun4i: tcon: Find matching display backend by device node matching
drm/sun4i: tcon: Copy ID from associated backend
ARM: dts: sun6i: Add second display pipeline device nodes
ARM: dts: sun6i: Enable tcon0 by default
.../bindings/display/sunxi/sun4i-drm.txt | 10 ++
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 1 -
arch/arm/boot/dts/sun6i-a31.dtsi | 169 ++++++++++++++++++++-
drivers/gpu/drm/sun4i/sun4i_backend.c | 53 ++++++-
drivers/gpu/drm/sun4i/sun4i_backend.h | 8 +
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +
drivers/gpu/drm/sun4i/sun4i_drv.h | 4 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 62 +++++++-
drivers/gpu/drm/sun4i/sun4i_tcon.h | 6 +
9 files changed, 307 insertions(+), 8 deletions(-)
--
2.11.0
^ permalink raw reply
* linux-next: build failure after merge of the arm tree
From: Mason @ 2017-04-21 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421181230.05dcf937@canb.auug.org.au>
On 21/04/2017 10:12, Stephen Rothwell wrote:
> Mason wrote:
>
>> Anyway, the fix is trivial.
>>
>> The "pchans_used" field is an unsigned long array.
>> for_each_clear_bit_from() expects an unsigned long pointer,
>> not an array address.
>>
>> I'll send a patch to the drivers/dma maintainers.
>
> The fix really needs to go into the arm tree (as well?) since that is
> the tree that has the patch that causes the build to break (even if the
> actual bug was preexisting).
Hello Stephen,
Since it's a trivial patch, and since Vinod is on vacation
until Monday, I suppose Russell could push the patch through
his own tree? (Maybe after an ACK from a sunxi maintainer.)
I am currently building an allyesconfig next-20170420 kernel.
Considering the speed of this system, this will take a while.
Regards.
^ permalink raw reply
* [PATCH] dmaengine: sun4i: fix invalid argument
From: Maxime Ripard @ 2017-04-21 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <584a2c53-100b-945b-d665-cef3fa856526@free.fr>
On Fri, Apr 21, 2017 at 10:06:10AM +0200, Mason wrote:
> The "pchans_used" field is an unsigned long array.
>
> for_each_clear_bit_from() expects an unsigned long pointer,
> not an array address.
>
> $ make C=2 drivers/dma/sun4i-dma.o
> CHECK drivers/dma/sun4i-dma.c
> drivers/dma/sun4i-dma.c:241:9: warning: incorrect type in argument 1 (different base types)
> drivers/dma/sun4i-dma.c:241:9: expected unsigned long const *p
> drivers/dma/sun4i-dma.c:241:9: got unsigned long ( *<noident> )[1]
The patch looks good...
> Signed-off-by: Mason <slash.tmp@free.fr>
However this doesn't.
See https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170421/d7979951/attachment.sig>
^ permalink raw reply
* [PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers
From: icenowy at aosc.io @ 2017-04-21 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420083707.wdtrdlxpvocpzc7g@lukather>
? 2017?4?20? GMT+08:00 ??4:37:07, Maxime Ripard
<maxime.ripard@free-electrons.com> ??:
> On Tue, Apr 18, 2017 at 06:47:56PM +0800, Icenowy Zheng wrote:
>> >> + /* Get the physical address of the buffer in memory */
>> >> + gem = drm_fb_cma_get_gem_obj(fb, 0);
>> >> +
>> >> + DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
>> >> +
>> >> + /* Compute the start of the displayed memory */
>> >> + bpp = fb->format->cpp[0];
>> >> + paddr = gem->paddr + fb->offsets[0];
>> >> + paddr += (state->src_x >> 16) * bpp;
>> >> + paddr += (state->src_y >> 16) * fb->pitches[0];
>> >> +
>> >> + DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
>> >> +
>> >> + paddr_u32 = (uint32_t) paddr;
>> >
>> >How does that work on 64-bits systems ?
>>
>> The hardware is not designed to work on 64-bit systems.
>>
>> Even 64-bit A64/H5 has also 3GiB memory limit.
>
> That's a fragile assumption.
Yes, it's only the basical reason.
>
>> The address cell in mixer hardware is also only 32-bit.
>>
>> So we should just keep the force conversion here. If we then really
>> met 4GiB-capable AW SoC without changing DE2, I think we should have
>> other way to limit CMA pool inside 4GiB.
>
> The register name looks like this is only the lower 32 bits that you
> can set here, and that there is another register for the upper 32 bits
> of that address somewhere.
Maybe... but no one can verify this as their's no currently any user
which has 4GiB+ DRAM.
I think we should keep this until Allwinner really made a 4GiB-capable
hardware.
>
> In that case, please use the lower_32_bits and upper_32_bits helper,
> and don't cast it that way.
>
> If it isn't the case, you should set the DMA mask (through
> dma_set_mask) so that we only allocate memory that can be accessed by
> this device.
How to do it?
>
> Maxime
^ permalink raw reply
* linux-next: build failure after merge of the arm tree
From: Stephen Rothwell @ 2017-04-21 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9858a4ed-bdd9-bd6c-d8a4-e9e6bd539904@free.fr>
Hi Mason,
On Fri, 21 Apr 2017 09:58:58 +0200 Mason <slash.tmp@free.fr> wrote:
>
> Anyway, the fix is trivial.
>
> The "pchans_used" field is an unsigned long array.
> for_each_clear_bit_from() expects an unsigned long pointer,
> not an array address.
>
> I'll send a patch to the drivers/dma maintainers.
The fix really needs to go into the arm tree (as well?) since that is
the tree that has the patch that causes the build to break (even if the
actual bug was preexisting).
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH] dmaengine: sun4i: fix invalid argument
From: Mason @ 2017-04-21 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9858a4ed-bdd9-bd6c-d8a4-e9e6bd539904@free.fr>
The "pchans_used" field is an unsigned long array.
for_each_clear_bit_from() expects an unsigned long pointer,
not an array address.
$ make C=2 drivers/dma/sun4i-dma.o
CHECK drivers/dma/sun4i-dma.c
drivers/dma/sun4i-dma.c:241:9: warning: incorrect type in argument 1 (different base types)
drivers/dma/sun4i-dma.c:241:9: expected unsigned long const *p
drivers/dma/sun4i-dma.c:241:9: got unsigned long ( *<noident> )[1]
Signed-off-by: Mason <slash.tmp@free.fr>
---
drivers/dma/sun4i-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/sun4i-dma.c b/drivers/dma/sun4i-dma.c
index 57aa227bfadb..f4ed3f17607c 100644
--- a/drivers/dma/sun4i-dma.c
+++ b/drivers/dma/sun4i-dma.c
@@ -238,7 +238,7 @@ static struct sun4i_dma_pchan *find_and_use_pchan(struct sun4i_dma_dev *priv,
}
spin_lock_irqsave(&priv->lock, flags);
- for_each_clear_bit_from(i, &priv->pchans_used, max) {
+ for_each_clear_bit_from(i, priv->pchans_used, max) {
pchan = &pchans[i];
pchan->vchan = vchan;
set_bit(i, priv->pchans_used);
--
3.14159
^ permalink raw reply related
* [PATCH] media: mtk-vcodec: remove informative log
From: Tiffany Lin @ 2017-04-21 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419075643.0a04af21@vento.lan>
On Wed, 2017-04-19 at 07:56 -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 5 Apr 2017 19:09:59 +0800
> Tiffany Lin <tiffany.lin@mediatek.com> escreveu:
>
> > On Wed, 2017-04-05 at 18:54 +0800, Minghsiu Tsai wrote:
> > > Driver is stable. Remove DEBUG definition from driver.
> > >
> > > There are debug message in /var/log/messages if DEBUG is defined,
> > > such as:
> > > [MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
> > > [MTK_V4L2] level=0 fops_vcodec_open(),177: 16000000.vcodec decoder [0]
> > > [MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder
> > >
> > > Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> > Acked-by:Tiffany Lin <Tiffany.lin@mediatek.com>
> >
> > > ---
> > > drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > index 7d55975..1248083 100644
> > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > @@ -31,7 +31,6 @@ struct mtk_vcodec_mem {
> > > extern int mtk_v4l2_dbg_level;
> > > extern bool mtk_vcodec_dbg;
> > >
> > > -#define DEBUG 1
> > >
> > > #if defined(DEBUG)
> > >
>
> After this patch, building the Kernel with W=1 now shows warnings:
>
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 'mtk_vcodec_dec_pw_on':
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
> mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
> ^
>
> I wrote a patch fixing it, as this is really a trivial issue.
>
> Yet, after that, this one still remains:
>
>
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: In function 'mtk_vdec_pic_info_update':
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:284:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
> int ret;
> ^~~
>
>
> Shouldn't be mtk_vdec_pic_info_update() returning an error code?
>
>
> Also, IMHO, at least errors should be shown at dmesg.
>
Got it. We will upstream patch to fix warning and add dmesg when error.
best regards,
Tiffany
> Thanks,
> Mauro
^ permalink raw reply
* linux-next: build failure after merge of the arm tree
From: Mason @ 2017-04-21 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421084033.5c987e13@canb.auug.org.au>
On 21/04/2017 00:40, Stephen Rothwell wrote:
> After merging the arm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from include/linux/bitops.h:36:0,
> from include/linux/bitmap.h:7,
> from drivers/dma/sun4i-dma.c:11:
> drivers/dma/sun4i-dma.c: In function 'find_and_use_pchan':
> include/linux/bitops.h:56:34: error:
> passing argument 1 of '_find_next_zero_bit_le' from incompatible pointer type [-Werror=incompatible-pointer-types]
> for ((bit) = find_next_zero_bit((addr), (size), (bit)); \
> ^
> arch/arm/include/asm/bitops.h:200:61: note: in definition of macro 'find_next_zero_bit'
> #define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
> ^
> drivers/dma/sun4i-dma.c:241:2: note: in expansion of macro 'for_each_clear_bit_from'
> for_each_clear_bit_from(i, &priv->pchans_used, max) {
> ^
> arch/arm/include/asm/bitops.h:163:12: note:
> expected 'const long unsigned int *' but argument is of type 'long unsigned int (*)[1]'
> extern int _find_next_zero_bit_le(const unsigned long *p, int size, int offset);
> ^
> [...]
>
> Caused (or exposed) by commit
>
> c4f8ff16b46b ("ARM: 8669/1: bitops: Align prototypes to generic API")
>
> I have used the arm tree from next-20170420 for today.
Weird that I didn't catch this when I ran make allyesconfig.
https://www.spinics.net/lists/arm-kernel/msg573736.html
Anyway, the fix is trivial.
The "pchans_used" field is an unsigned long array.
for_each_clear_bit_from() expects an unsigned long pointer,
not an array address.
I'll send a patch to the drivers/dma maintainers.
$ make C=2 drivers/dma/sun4i-dma.o
CHECK drivers/dma/sun4i-dma.c
CC drivers/dma/sun4i-dma.o
Regards.
^ permalink raw reply
* [PATCH V2] scsi: mpt3sas: remove redundant wmb
From: Sreekanth Reddy @ 2017-04-21 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yq1y3uvq0c1.fsf@oracle.com>
On Thu, Apr 20, 2017 at 7:58 AM, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
> Sinan Kaya <okaya@codeaurora.org> writes:
>
>> Due to relaxed ordering requirements on multiple architectures,
>> drivers are required to use wmb/rmb/mb combinations when they need to
>> guarantee observability between the memory and the HW.
>>
>> The mpt3sas driver is already using wmb() for this purpose. However,
>> it issues a writel following wmb(). writel() function on arm/arm64
>> arhictectures have an embedded wmb() call inside.
[Sreekanth] Whether same thing applicable for SPARC & POWER
architectures. If yes then we are fine with this patch changes.
>>
>> This results in unnecessary performance loss and code duplication.
>>
>> writel already guarantees ordering for both cpu and bus. we don't need
>> additional wmb()
>
> Broadcom folks, please review!
>
> --
> Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* [PATCH] [media] mtk-vcodec: avoid warnings because of empty macros
From: Tiffany Lin @ 2017-04-21 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5bc3ebc3c6f57c2b30126f113bc35ec95c6f5b5d.1492599391.git.mchehab@s-opensource.com>
On Wed, 2017-04-19 at 07:56 -0300, Mauro Carvalho Chehab wrote:
> Remove those gcc warnings:
>
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 'mtk_vcodec_dec_pw_on':
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
> mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
> ^
>
> By adding braces.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> index 12480837ff2e..237e144c194f 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> @@ -66,15 +66,15 @@ extern bool mtk_vcodec_dbg;
>
> #else
>
> -#define mtk_v4l2_debug(level, fmt, args...)
> -#define mtk_v4l2_err(fmt, args...)
> -#define mtk_v4l2_debug_enter()
> -#define mtk_v4l2_debug_leave()
> +#define mtk_v4l2_debug(level, fmt, args...) {}
> +#define mtk_v4l2_err(fmt, args...) {}
> +#define mtk_v4l2_debug_enter() {}
> +#define mtk_v4l2_debug_leave() {}
>
> -#define mtk_vcodec_debug(h, fmt, args...)
> -#define mtk_vcodec_err(h, fmt, args...)
> -#define mtk_vcodec_debug_enter(h)
> -#define mtk_vcodec_debug_leave(h)
> +#define mtk_vcodec_debug(h, fmt, args...) {}
> +#define mtk_vcodec_err(h, fmt, args...) {}
> +#define mtk_vcodec_debug_enter(h) {}
> +#define mtk_vcodec_debug_leave(h) {}
>
> #endif
>
Acked-by: Tiffany Lin <Tiffany.lin@mediatek.com>
^ permalink raw reply
* [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init
From: Patel, Mayurkumar @ 2017-04-21 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c0c2f48f-d725-058e-a1ad-92ab4b6e7fb3@codeaurora.org>
Hi Bjorn/Kaya,
>
>On 4/17/2017 12:38 PM, Bjorn Helgaas wrote:
>>> Like you said, what do we do by default is the question. Should we opt
>>> for safe like we are doing, or try to save some power.
>> I think safety is paramount. Every user should be able to boot safely
>> without any kernel parameters. We don't want users to have a problem
>> booting and then have to search for a workaround like booting with
>> "pcie_aspm=off". Most users will never do that.
>>
>
>OK, no problem with leaving the behavior as it is.
>
>My initial approach was #2. We knew this way that user had full control
>over the ASPM policy by changing the BIOS option. Then, Mayurkumar
>complained that ASPM is not enabled following a hotplug insertion to an
>empty slot. That's when I switched to #3 as it sounded like a good thing
>to have for us.
>
>> Here's a long-term strawman proposal, see what you think:
>>
>> - Deprecate CONFIG_PCIEASPM_DEFAULT, CONFIG_PCIEASPM_POWERSAVE, etc.
>> - Default aspm_policy is POLICY_DEFAULT always.
>> - POLICY_DEFAULT means Linux doesn't touch anything: if BIOS enabled
>> ASPM, we leave it that way; we leave ASPM disabled on hot-added
>> devices.
>
I am also ok with leaving the same behavior as now.
But still following is something open I feel besides, Which may be there in your comments redundantly.
The current problem is, pcie_aspm_exit_link_state() disables the ASPM configuration even
if POLICY_DEFAULT was set.
I am seeing already following problem(or may be influence) with it. The Endpoint I have does not have
does not have "Presence detect change" mechanism. Hot plug is working with Link status events.
When link is in L1 or L1SS and if EP is powered off, no Link status change event are triggered (It might be
the expected behavior in L1 or L1SS). When next time EP is powered on there are link down and
link up events coming one after other. BIOS enables ASPM on Root port and Endpoint, but while
processing link status down, pcie_aspm_exit_link_state() clears the ASPM already which were enabled by BIOS.
If we want to follow above approach then shall we consider having something similar as following?
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 1dfa10c..bf5be6d 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -940,7 +940,8 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
parent_link = link->parent;
/* All functions are removed, so just disable ASPM for the link */
- pcie_config_aspm_link(link, 0);
+ if (aspm_policy != POLICY_DEFAULT)
+ pcie_config_aspm_link(link, 0);
list_del(&link->sibling);
list_del(&link->link);
/* Clock PM is for endpoint device */
>I can easily see people complaining the other way around. There
>could be some boot FW that doesn't know what ASPM is and this particular
>system could rely on the compile time option for enabling power options.
>Maybe, a command line option will be required for them to keep the existing
>behavior.
>
>> - Deprecate kernel boot parameters (possibly keep pcie_aspm=off for
>> debugging use).
>> - Use /sys/module/pcie_aspm/parameters/policy for run-time
>> system-wide control, including for future hot-added devices.
>> - Remove CONFIG_PCIEASPM_DEBUG and enable that code always, so we
>> have fine-grained run-time control.
>>
>
>Runtime control sounds like a better plan. We need hooks into the system
>power management policy.
>
>>> Maybe, we are missing a HPP option from the PCI spec.
>> That's an interesting idea. _HPX does have provision for manipulating
>> Link Control bits (see ACPI r5.0, sec 6.2.8.3), but I don't think very
>> many systems implement it. And there's currently no connection
>> between program_hpp_type2() and aspm.c, so I'm a little worried that
>> we might have issues if a system did implement an _HPX that sets any
>> of the ASPM bits.
>
>I looked at the spec some more. These are there to restore the register
>settings following hotplug insertion. I agree it won't play nice with ASPM
>as the control bits need to be enabled in coordination with the upstream
>device.
>
>I think the right approach is to let the userspace feed the required
>policy to the kernel like you suggested. Then, it needs to be per port
>via link_state to have the most flexibility.
>
>
>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
^ permalink raw reply related
* [PATCH v6 0/6] add support for AXP20X and AXP22X battery power supply driver
From: Maxime Ripard @ 2017-04-21 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418073421.31351-1-quentin.schulz@free-electrons.com>
On Tue, Apr 18, 2017 at 09:34:15AM +0200, Quentin Schulz wrote:
> This is a series for AXP20X and AXP22X battery power supply without the
> support for changing constant charge current from the DT. The patches for
> supporting the constant charge current from DT are ready and will be sent
> once the battery framework required to make this work has been merged.
>
> v6:
> - removed mention to fixed battery in DT-binding documentation,
>
> Quote from v4 cover letter:
>
> The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose
> information and data of the various power supplies they support such as
> ACIN, battery and VBUS. For example, they expose the current battery
> voltage, charge or discharge, as well as ACIN and VBUS current voltages
> and currents, internal PMIC temperature and ADC on 2 different GPIOs
> when in the right mode (for the AXP209 only).
>
> The ACIN power supply driver is added by this patch. The AXP20X and
> AXP22X can both read the status and the "usability" of the power supply
> but only the AXP209 will be able to tell the current current and voltage
> of the power supply by reading ADC channels. It is simply not supported
> by the AXP22X PMICs.
>
> The battery power supply driver is also added by this patch. The AXP20X
> and AXP22X share most of their behaviour but have slight variations. The
> allowed target voltages for battery charging are not the same, the
> AXP22X PMIC are able to tell if the battery percentage computed by the
> PMIC is trustworthy and they have different formulas for computing max
> current for battery power supply. The driver is able to give the current
> voltage and current of the battery (be it charging or discharging), the
> maximal and minimal voltage and maximal current allowed for the battery,
> whether the battery is present and usable and its capacity. It will get
> the battery current current and voltage by reading the ADC channels. The
> PMIC allows maximal voltages (4.36V for AXP20X and 4.22V and 4.24V for
> AXP22X) that should not be used with Lithium-based batteries and since
> this PMIC is supposed to be used with Lithium-based batteries, they have
> been disabled. The values returned by the ADC driver are multipled by
> 1000 to scale from the mV returned by the ADC to the uV expected by the
> power supply framework.
>
> This series of patch adds DT bindings for ACIN power supply, ADC and
> battery power supply drivers for AXP20X and AXP22X PMICs and their
> documentation. It also enables the supported power supplies for the
> Nextthing Co. CHIP and Sinlinx SinA33 boards.
>
> The different drivers are also added to the MFD cells of the AXP20X and
> AXP22X cells and the writeable and volatile regs updated to work with
> the newly added drivers.
>
> This series of patch is based on a previous upstreaming attempt done by
> Bruno Pr?mont few months ago. It differs in three points: the ADC
> driver does not tell the battery temperature (TS_IN) as I do not have a
> board to test it with, it does not tell the instantaneous battery power
> as it returns crazy values for me and finally no support for OCV curves
> for the battery.
>
> You can test these patches from this repo and branch:
> https://github.com/QSchulz/linux/tree/axp2xx_adc_batt_ac_v4
>
> v4:
> - added the ability to set maximum constant charge current from sysfs,
> - added a warning when setting a higher than current maximum constant charge
> current,
> - set default to minimum possible value for current and maximum constant charge
> current when no battery DT is present or invalid battery DT,
> - fixed a forgotten custom formula to compute maximum constant charge current
> for AXP22X,
> - automatically lower the current constant charge current when it is higher
> than the maximum constant charge current about to be set,
>
> v3:
> - Removed DT property for constant charge current in favor of the WIP
> battery framework as requested by Sebastian Reichel,
> - Using a simple if condition instead of a switch in the ADC driver,
> - Fixed error handling in ADC driver's probe,
> - Fixed missing call to iio_map_array_unregister in the ADC driver's
> remove,
> - Removed ADC driver's DT node and documentation,
> - Merged IIO channel mapping patches into the original ADC driver
> patch,
> - Removed `adding V-OFF to writeable reg' patch as it's already in
> writeable reg range,
>
> v2:
> - Some registers' name have been changed to better reflect their
> purpose,
> - Make VBUS power supply driver use IIO channels when AXP ADC driver is
> enabled, but fall back on previous behavior when disabled. This is made
> to avoid the ADC driver overwritting registers for VBUS power supply
> ADC when removed,
> - Removed useless adding of data registers to volatile registers,
> - Reordered IIO channels, now grouped by same part of the PMIC (e.g.
> voltage and current of the battery have the same index in different
> IIO types),
> - Added structures for specific data instead of matching on IDs,
> - Switched from DT IIO channels mapping to iio_map structures IIO
> channels mapping,
>
> Quentin
>
> Quentin Schulz (6):
> dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
> power: supply: add battery driver for AXP20X and AXP22X PMICs
> ARM: dtsi: axp209: add battery power supply subnode
> ARM: dtsi: axp22x: add battery power supply subnode
> ARM: dts: sun8i: sina33: enable battery power supply subnode
> ARM: sun5i: chip: enable battery power supply subnode
Applied the last 4 patches.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170421/90365e17/attachment.sig>
^ permalink raw reply
* [PATCH V5 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries
From: Maxime Ripard @ 2017-04-21 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2eb4a6e227f7edfb51ebf3723d5df7e652c703b4.1492685450.git.viresh.kumar@linaro.org>
On Thu, Apr 20, 2017 at 04:25:09PM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Rob Herring <robh@kernel.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170421/6158335b/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/3] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver
From: Corentin Labbe @ 2017-04-21 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419071418.18995-3-antoine.tenart@free-electrons.com>
Hello
I have some minor comment below
On Wed, Apr 19, 2017 at 09:14:17AM +0200, Antoine Tenart wrote:
> Add support for Inside Secure SafeXcel EIP197 cryptographic engine,
> which can be found on Marvell Armada 7k and 8k boards. This driver
> currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and
> hmac(sah1) algorithms.
>
> Two firmwares are needed for this engine to work. Their are mostly used
> for more advanced operations than the ones supported (as of now), but we
> still need them to pass the data to the internal cryptographic engine.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
> drivers/crypto/Kconfig | 17 +
> drivers/crypto/Makefile | 1 +
> drivers/crypto/inside-secure/Makefile | 2 +
> drivers/crypto/inside-secure/safexcel.c | 940 +++++++++++++++++++++
> drivers/crypto/inside-secure/safexcel.h | 579 +++++++++++++
> drivers/crypto/inside-secure/safexcel_cipher.c | 555 +++++++++++++
> drivers/crypto/inside-secure/safexcel_hash.c | 1060 ++++++++++++++++++++++++
> drivers/crypto/inside-secure/safexcel_ring.c | 157 ++++
> 8 files changed, 3311 insertions(+)
> create mode 100644 drivers/crypto/inside-secure/Makefile
> create mode 100644 drivers/crypto/inside-secure/safexcel.c
> create mode 100644 drivers/crypto/inside-secure/safexcel.h
> create mode 100644 drivers/crypto/inside-secure/safexcel_cipher.c
> create mode 100644 drivers/crypto/inside-secure/safexcel_hash.c
> create mode 100644 drivers/crypto/inside-secure/safexcel_ring.c
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 473d31288ad8..d12a40450858 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -619,4 +619,21 @@ config CRYPTO_DEV_BCM_SPU
> Secure Processing Unit (SPU). The SPU driver registers ablkcipher,
> ahash, and aead algorithms with the kernel cryptographic API.
>
[...]
> + /*
> + * Result Descriptor Ring prepare
> + */
This is not preferred comment format for one line
[...]
> +static int safexcel_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + struct safexcel_crypto_priv *priv;
> + int i, ret;
> +
> + priv = devm_kzalloc(dev, sizeof(struct safexcel_crypto_priv),
> + GFP_KERNEL);
sizeof(priv) is preferred as asked by checkpatch
[...]
> + ring_irq = devm_kzalloc(dev, sizeof(struct safexcel_ring_irq_data),
> + GFP_KERNEL);
same comment here
[...]
> +#define EIP197_ALG_ARC4 BIT(7)
> +#define EIP197_ALG_AES_ECB BIT(8)
> +#define EIP197_ALG_AES_CBC BIT(9)
> +#define EIP197_ALG_AES_CTR_ICM BIT(10)
> +#define EIP197_ALG_AES_OFB BIT(11)
> +#define EIP197_ALG_AES_CFB BIT(12)
> +#define EIP197_ALG_DES_ECB BIT(13)
> +#define EIP197_ALG_DES_CBC BIT(14)
> +#define EIP197_ALG_DES_OFB BIT(16)
> +#define EIP197_ALG_DES_CFB BIT(17)
> +#define EIP197_ALG_3DES_ECB BIT(18)
> +#define EIP197_ALG_3DES_CBC BIT(19)
> +#define EIP197_ALG_3DES_OFB BIT(21)
> +#define EIP197_ALG_3DES_CFB BIT(22)
> +#define EIP197_ALG_MD5 BIT(24)
> +#define EIP197_ALG_HMAC_MD5 BIT(25)
Does MD5, DES and 3DES will be added later ?
[...]
> +static const u8 sha1_zero_digest[SHA1_DIGEST_SIZE] = {
> + 0xda, 0x39, 0xa3, 0xee, 0x5e, 0x6b, 0x4b, 0x0d, 0x32, 0x55,
> + 0xbf, 0xef, 0x95, 0x60, 0x18, 0x90, 0xaf, 0xd8, 0x07, 0x09,
> +};
> +
> +static const u8 sha224_zero_digest[SHA224_DIGEST_SIZE] = {
> + 0xd1, 0x4a, 0x02, 0x8c, 0x2a, 0x3a, 0x2b, 0xc9, 0x47, 0x61,
> + 0x02, 0xbb, 0x28, 0x82, 0x34, 0xc4, 0x15, 0xa2, 0xb0, 0x1f,
> + 0x82, 0x8e, 0xa6, 0x2a, 0xc5, 0xb3, 0xe4, 0x2f
> +};
> +
> +static const u8 sha256_zero_digest[SHA256_DIGEST_SIZE] = {
> + 0xe3, 0xb0, 0xc4, 0x42, 0x98, 0xfc, 0x1c, 0x14, 0x9a, 0xfb,
> + 0xf4, 0xc8, 0x99, 0x6f, 0xb9, 0x24, 0x27, 0xae, 0x41, 0xe4,
> + 0x64, 0x9b, 0x93, 0x4c, 0xa4, 0x95, 0x99, 0x1b, 0x78, 0x52,
> + 0xb8, 0x55
> +};
Thoses structures are already defined in crypto (sha1_zero_message_hash, etc...)
You can use it since you select SHAxxx in Kconfig
[...]
> +static int safexcel_hmac_init_pad(struct ahash_request *areq,
> + unsigned int blocksize, const u8 *key,
> + unsigned int keylen, u8 *ipad, u8 *opad)
> +{
> + struct safexcel_ahash_result result;
> + struct scatterlist sg;
> + int ret, i;
> + u8 *keydup;
> +
> + if (keylen <= blocksize) {
> + memcpy(ipad, key, keylen);
> + } else {
> + keydup = kmemdup(key, keylen, GFP_KERNEL);
> + if (!keydup)
> + return -ENOMEM;
> +
> + ahash_request_set_callback(areq, CRYPTO_TFM_REQ_MAY_BACKLOG,
> + safexcel_ahash_complete, &result);
> + sg_init_one(&sg, keydup, keylen);
> + ahash_request_set_crypt(areq, &sg, ipad, keylen);
> + init_completion(&result.completion);
> +
> + ret = crypto_ahash_digest(areq);
> + if (ret == -EINPROGRESS) {
> + wait_for_completion_interruptible(&result.completion);
> + ret = result.error;
> + }
> +
> + /* Avoid leaking */
> + memset(keydup, 0, keylen);
It is safer to use memzero_explicit
> + kfree(keydup);
> +
> + if (ret)
> + return ret;
> +
> + keylen = crypto_ahash_digestsize(crypto_ahash_reqtfm(areq));
> + }
> +
> + memset(ipad + keylen, 0, blocksize - keylen);
> + memcpy(opad, ipad, blocksize);
> +
> + for (i = 0; i < blocksize; i++) {
> + ipad[i] ^= 0x36;
> + opad[i] ^= 0x5c;
What are these constant ?
[...]
> +static int safexcel_hmac_sha1_setkey(struct crypto_ahash *tfm, const u8 *key,
> + unsigned int keylen)
> +{
> + struct safexcel_ahash_ctx *ctx = crypto_tfm_ctx(crypto_ahash_tfm(tfm));
> + struct safexcel_ahash_export_state istate, ostate;
> + int ret, i;
> +
> + ret = safexcel_hmac_setkey("safexcel-sha1", key, keylen, &istate, &ostate);
Perhaps you could use the algname instead of "safexcel-sha1"
> + if (ret)
> + return ret;
> +
> + memcpy(ctx->ipad, &istate.state, SHA1_DIGEST_SIZE);
> + memcpy(ctx->opad, &ostate.state, SHA1_DIGEST_SIZE);
Perhaps you could the digest_size from alg_template
[...]
> +struct safexcel_alg_template safexcel_alg_sha256 = {
> + .type = SAFEXCEL_ALG_TYPE_AHASH,
> + .alg.ahash = {
> + .init = safexcel_sha256_init,
> + .update = safexcel_ahash_update,
> + .final = safexcel_ahash_final,
> + .finup = safexcel_ahash_finup,
> + .digest = safexcel_sha256_digest,
> + .export = safexcel_ahash_export,
> + .import = safexcel_ahash_import,
> + .halg = {
> + .digestsize = SHA256_DIGEST_SIZE,
> + .statesize = sizeof(struct safexcel_ahash_export_state),
> + .base = {
> + .cra_name = "sha256",
> + .cra_driver_name = "safexcel-sha256",
> + .cra_priority = 300,
> + .cra_flags = CRYPTO_ALG_ASYNC |
> + CRYPTO_ALG_KERN_DRIVER_ONLY,
Why do use CRYPTO_ALG_KERN_DRIVER_ONLY ?
Regards
Corentin Labbe
^ permalink raw reply
* [PATCH 2/8] [RFC] arm64: dts: renesas: Add R-Car H3 SiP (4 x 1 GiB) support
From: Geert Uytterhoeven @ 2017-04-21 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421054201.GR28868@bigcity.dyn.berto.se>
Hi Niklas,
On Fri, Apr 21, 2017 at 7:42 AM, Niklas S?derlund
<niklas.soderlund@ragnatech.se> wrote:
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
>> @@ -0,0 +1,36 @@
>> +/*
>> + * Device Tree Source for the r8j7795 SiP with 4 channels of 1 GiB RAM
>> + *
>> + * Copyright (C) 2015 Renesas Electronics Corp.
>
> 2017 right? If so same comment for patches 3 and 4.
As I just moved statements from an existing file, I retained the original
copyright information.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] PCI: imx6: fix spelling mistake: "contol" -> "control"
From: Colin King @ 2017-04-21 7:02 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
trivial fix to spelling mistake in dev_err message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/pci/dwc/pci-imx6.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
index 102edcf1e261..129717ae5022 100644
--- a/drivers/pci/dwc/pci-imx6.c
+++ b/drivers/pci/dwc/pci-imx6.c
@@ -726,13 +726,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
imx6_pcie->pciephy_reset = devm_reset_control_get(dev,
"pciephy");
if (IS_ERR(imx6_pcie->pciephy_reset)) {
- dev_err(dev, "Failed to get PCIEPHY reset contol\n");
+ dev_err(dev, "Failed to get PCIEPHY reset control\n");
return PTR_ERR(imx6_pcie->pciephy_reset);
}
imx6_pcie->apps_reset = devm_reset_control_get(dev, "apps");
if (IS_ERR(imx6_pcie->apps_reset)) {
- dev_err(dev, "Failed to get PCIE APPS reset contol\n");
+ dev_err(dev, "Failed to get PCIE APPS reset control\n");
return PTR_ERR(imx6_pcie->apps_reset);
}
break;
--
2.11.0
^ permalink raw reply related
* linux-next: manual merge of the pm tree with the arm-soc tree
From: santosh.shilimkar at oracle.com @ 2017-04-21 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3kHO1NZFJXvDwWO625aEmXoo2540FRKe+YYzoYE9NCSg@mail.gmail.com>
On 4/20/17 10:53 PM, Arnd Bergmann wrote:
> On Fri, Apr 21, 2017 at 2:54 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> Today's linux-next merge of the pm tree got a conflict in:
>>
>> include/dt-bindings/genpd/k2g.h
>>
>> between commit:
>>
>> 7cc119f29b19 ("dt-bindings: Add TI SCI PM Domains")
>>
>> from the arm-soc tree and commit:
>>
>> 45da8edd1741 ("dt-bindings: Add TI SCI PM Domains")
>>
>> from the pm tree.
>>
>> I fixed it up (I just used the pm tree version) and can carry the fix as
>> necessary. This is now fixed as far as linux-next is concerned, but any
>> non trivial conflicts should be mentioned to your upstream maintainer
>> when your tree is submitted for merging. You may also want to consider
>> cooperating with the maintainer of the conflicting tree to minimise any
>> particularly complex conflicts.
>
> Dave, Santosh,
>
> any idea what happened here? It seems that we picked up the wrong
> version of the tree, do we need to drop this from arm-soc?
>
Nope. Its because this series was in my 'next' branch for a week or
so and now it made it via arm-soc tree next as well.
I just cleaned up my next head so it linux-next next tag should have
only arm-soc copy.
Regards,
Santosh
^ permalink raw reply
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Arnd Bergmann @ 2017-04-21 5:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421105405.6a690b35@canb.auug.org.au>
On Fri, Apr 21, 2017 at 2:54 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the pm tree got a conflict in:
>
> include/dt-bindings/genpd/k2g.h
>
> between commit:
>
> 7cc119f29b19 ("dt-bindings: Add TI SCI PM Domains")
>
> from the arm-soc tree and commit:
>
> 45da8edd1741 ("dt-bindings: Add TI SCI PM Domains")
>
> from the pm tree.
>
> I fixed it up (I just used the pm tree version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Dave, Santosh,
any idea what happened here? It seems that we picked up the wrong
version of the tree, do we need to drop this from arm-soc?
Arnd
^ permalink raw reply
* [arm64] OOPS when using /proc/kcore to disassemble the kernel symbols in "perf top"
From: Tan Xiaojun @ 2017-04-21 5:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58F810F8.5080502@huawei.com>
On 2017/4/20 9:38, Tan Xiaojun wrote:
> On 2017/4/19 19:49, Mark Rutland wrote:
>> Hi,
>>
>> Ard, this sseems to be a nomap issue. Please see below.
>>
>> Xiaojun, for some reason, the first message in this thread didn't seem
>> to make it to LAKML (or to me). In future could you please Cc me for
>> emails regarding perf on arm/arm64?
>>
>
> Sorry, this is my negligence.
>
>> On Wed, Apr 19, 2017 at 09:44:56AM +0530, Pratyush Anand wrote:
>>> On Saturday 15 April 2017 02:18 PM, Tan Xiaojun wrote:
>>>> My test server is Hisilicon D03/D05 (arm64).
>>>> Kernel source code is 4.11-rc6 (up to date) and config (as an attachment in the end) is generated by defconfig.
>>>> (Old version does not seem to have this problem. Linux-4.1 is fine and other versions I have not tested yet.)
>>>
>>> I tested with mustang(ARM64) and 4.11-rc6 and could not reproduce it.
>>>
Hi,
Pratyush,
Sorry, could you test it again? Because I tested it many times and found it is not triggered every time.
And you can run "perf top -U" and try more kernel symbols to increase the probability of occurrence, or
maybe you can try Mark's way "cat /proc/kcore > /dev/null".
I would like to confirm whether this is hardware related, but I have no other arm64 boards except the
boards of Hisilicon.
>>>> When I do "perf top" and annotate a random kernel symbol (like vsnprintf or others), the system report an OOPS below:
>>>> (The probability of occurrence is very high, almost every time.)
>>>>
>>>> $ perf top
>>>>
>>>> Annotate vsnprintf ---- choose it
>>>> Zoom into perf(7066) thread
>>>> Zoom into the Kernel DSO
>>>> Browse map details
>>>> Run scripts for samples of thread [perf]
>>>> Run scripts for samples of symbol [vsnprintf]
>>>> Run scripts for all samples
>>>> Exit
>>
>> Was perf built from the same v4.11-rc6 source tree, or was this an older
>> perf binary?
>>
>
> No, I had used 4.10-rc7 or some other older perf binary.
> At first, I found this problem in kernel-4.10-rc7 + perf-4.10-rc7, and then I tested the other kernel versions.
>
> For now, I use "git bisect" and find the problem maybe between v4.5 and v4.6-rc1.
>
> I will try more and tell you the result.
>
Hi,
Mark, Ard,
I found the patch which introduced the problem.
The commit is:
commit f9040773b7bbbd9e98eb6184a263512a7cfc133f
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Tue Feb 16 13:52:40 2016 +0100
arm64: move kernel image to base of vmalloc area
This moves the module area to right before the vmalloc area, and moves
the kernel image to the base of the vmalloc area. This is an intermediate
step towards implementing KASLR, which allows the kernel image to be
located anywhere in the vmalloc area.
Since other subsystems such as hibernate may still need to refer to the
kernel text or data segments via their linears addresses, both are mapped
in the linear region as well. The linear alias of the text region is
mapped read-only/non-executable to prevent inadvertent modification or
execution.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
It can work well without this patch in Linux-4.5-rc4. And it can trigger an OOPS with this patch in Linux-4.5-rc4.
I try to revert it in v4.11-rc6, but it involves too much conflict.
So I need to understand this patch fist. Then I can known where the problem is.
Thanks.
Xiaojun.
>> With a perf tool built from v4.11-rc6, even with CAP_SYS_RAWIO, I see perf top
>> complaining that it it cannot annotate the symbol due to a lack of a vmlinux
>> file. I can't seem to convince it to use /proc/kcore.
>>
>> However, I can reproduce the issue by other means:
>>
>> # cat /proc/kcore > /dev/null
>> [ 4544.984139] Unable to handle kernel paging request at virtual address ffff804392800000
>> [ 4544.991995] pgd = ffff80096745f000
>> [ 4544.995369] [ffff804392800000] *pgd=0000000000000000
>> [ 4545.000297] Internal error: Oops: 96000005 [#1] PREEMPT SMP
>> [ 4545.005815] Modules linked in:
>> [ 4545.008843] CPU: 1 PID: 8976 Comm: cat Not tainted 4.11.0-rc6 #1
>> [ 4545.014790] Hardware name: ARM Juno development board (r1) (DT)
>> [ 4545.020653] task: ffff8009753fdb00 task.stack: ffff80097533c000
>> [ 4545.026520] PC is at __memcpy+0x100/0x180
>> [ 4545.030491] LR is at vread+0x144/0x280
>> [ 4545.034202] pc : [<ffff0000083a1000>] lr : [<ffff0000081c126c>] pstate: 20000145
>> [ 4545.041530] sp : ffff80097533fcb0
>> [ 4545.044811] x29: ffff80097533fcb0 x28: ffff800962d24000
>> [ 4545.050074] x27: 0000000000001000 x26: ffff8009753fdb00
>> [ 4545.055337] x25: ffff000008200000 x24: ffff800977801380
>> [ 4545.060600] x23: ffff8009753fdb00 x22: ffff800962d24000
>> [ 4545.065863] x21: 0000000000001000 x20: ffff000008200000
>> [ 4545.071125] x19: 0000000000001000 x18: 0000ffffefa323c0
>> [ 4545.076387] x17: 0000ffffa9c87440 x16: ffff0000081fdfd0
>> [ 4545.081649] x15: 0000ffffa9d01588 x14: 72a77346b2407be7
>> [ 4545.086911] x13: 5299400690000000 x12: b0000001f9001a79
>> [ 4545.092173] x11: 97fc098d91042260 x10: 0000000000000000
>> [ 4545.097435] x9 : 0000000000000000 x8 : 9110626091260021
>> [ 4545.102698] x7 : 0000000000001000 x6 : ffff800962d24000
>> [ 4545.107960] x5 : ffff8009778013b0 x4 : 0000000000000000
>> [ 4545.113222] x3 : 0400000000000001 x2 : 0000000000000f80
>> [ 4545.118484] x1 : ffff804392800000 x0 : ffff800962d24000
>> [ 4545.123745]
>> [ 4545.125220] Process cat (pid: 8976, stack limit = 0xffff80097533c000)
>> [ 4545.131598] Stack: (0xffff80097533fcb0 to 0xffff800975340000)
>> [ 4545.137289] fca0: ffff80097533fd30 ffff000008270f64
>> [ 4545.145049] fcc0: 000000000000e000 000000003956f000 ffff000008f950d0 ffff80097533feb8
>> [ 4545.152809] fce0: 0000000000002000 ffff8009753fdb00 ffff800962d24000 ffff000008e8d3d8
>> [ 4545.160568] fd00: 0000000000001000 ffff000008200000 0000000000001000 ffff800962d24000
>> [ 4545.168327] fd20: 0000000000001000 ffff000008e884a0 ffff80097533fdb0 ffff00000826340c
>> [ 4545.176086] fd40: ffff800976bf2800 fffffffffffffffb 000000003956d000 ffff80097533feb8
>> [ 4545.183846] fd60: 0000000060000000 0000000000000015 0000000000000124 000000000000003f
>> [ 4545.191605] fd80: ffff000008962000 ffff8009753fdb00 ffff8009753fdb00 ffff8009753fdb00
>> [ 4545.199364] fda0: 0000000300000124 0000000000002000 ffff80097533fdd0 ffff0000081fb83c
>> [ 4545.207123] fdc0: 0000000000010000 ffff80097514f900 ffff80097533fe50 ffff0000081fcb28
>> [ 4545.214883] fde0: 0000000000010000 ffff80097514f900 0000000000000000 0000000000000000
>> [ 4545.222642] fe00: ffff80097533fe30 ffff0000081fca1c ffff80097514f900 0000000000000000
>> [ 4545.230401] fe20: 000000003956d000 ffff80097533feb8 ffff80097533fe50 ffff0000081fcb04
>> [ 4545.238160] fe40: 0000000000010000 ffff80097514f900 ffff80097533fe80 ffff0000081fe014
>> [ 4545.245919] fe60: ffff80097514f900 ffff80097514f900 000000003956d000 0000000000010000
>> [ 4545.253678] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800977146000
>> [ 4545.261438] fea0: ffffffffffffffff 0000ffffa9c8745c 0000000000000124 0000000008202000
>> [ 4545.269197] fec0: 0000000000000003 000000003956d000 0000000000010000 0000000000000000
>> [ 4545.276956] fee0: 0000000000011011 0000000000000001 0000000000000011 0000000000000002
>> [ 4545.284715] ff00: 000000000000003f 1f3c201f7372686b 00000000ffffffff 0000000000000030
>> [ 4545.292474] ff20: 0000000000000038 0000000000000000 0000ffffa9bcca94 0000ffffa9d01588
>> [ 4545.300233] ff40: 0000000000000000 0000ffffa9c87440 0000ffffefa323c0 0000000000010000
>> [ 4545.307993] ff60: 000000000041a310 000000003956d000 0000000000000003 000000007fffe000
>> [ 4545.315751] ff80: 00000000004088d0 0000000000010000 0000000000000000 0000000000000000
>> [ 4545.323511] ffa0: 0000000000010000 0000ffffefa32690 0000000000404dcc 0000ffffefa32690
>> [ 4545.331270] ffc0: 0000ffffa9c8745c 0000000060000000 0000000000000003 000000000000003f
>> [ 4545.339029] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 4545.346786] Call trace:
>> [ 4545.349207] Exception stack(0xffff80097533fae0 to 0xffff80097533fc10)
>> [ 4545.355586] fae0: 0000000000001000 0001000000000000 ffff80097533fcb0 ffff0000083a1000
>> [ 4545.363345] fb00: 000000003957c000 ffff80097533fc00 0000000020000145 0000000000000025
>> [ 4545.371105] fb20: ffff800962d24000 ffff000008e8d3d8 0000000000001000 ffff8009753fdb00
>> [ 4545.378864] fb40: 0000000000000000 0000000000000002 ffff80097533fd30 ffff000008082604
>> [ 4545.386623] fb60: 0000000000001000 0001000000000000 ffff80097533fd30 ffff0000083a0a90
>> [ 4545.394382] fb80: ffff800962d24000 ffff804392800000 0000000000000f80 0400000000000001
>> [ 4545.402140] fba0: 0000000000000000 ffff8009778013b0 ffff800962d24000 0000000000001000
>> [ 4545.409899] fbc0: 9110626091260021 0000000000000000 0000000000000000 97fc098d91042260
>> [ 4545.417658] fbe0: b0000001f9001a79 5299400690000000 72a77346b2407be7 0000ffffa9d01588
>> [ 4545.425416] fc00: ffff0000081fdfd0 0000ffffa9c87440
>> [ 4545.430248] [<ffff0000083a1000>] __memcpy+0x100/0x180
>> [ 4545.435253] [<ffff000008270f64>] read_kcore+0x21c/0x3b0
>> [ 4545.440429] [<ffff00000826340c>] proc_reg_read+0x64/0x90
>> [ 4545.445691] [<ffff0000081fb83c>] __vfs_read+0x1c/0x108
>> [ 4545.450779] [<ffff0000081fcb28>] vfs_read+0x80/0x130
>> [ 4545.455696] [<ffff0000081fe014>] SyS_read+0x44/0xa0
>> [ 4545.460528] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
>> [ 4545.465790] Code: d503201f d503201f d503201f d503201f (a8c12027)
>> [ 4545.471852] ---[ end trace 4d1897f94759f461 ]---
>> [ 4545.476435] note: cat[8976] exited with preempt_count 2
>>
>> So the call flow is:
>>
>> read_core() // finds the address is vmalloc or module
>> -> vread()
>> --> aligned_vread()
>>
>> In aligned_vread(), we vmalloc_to_page() the address, and find a page.
>> We then try to kmap_atomic() that. The generic kmap_atomic() returns the
>> linear map alias of the address.
>>
>> However, it appears that the page is nomap'd memory, and the linear
>> alias doesn't exist. Thus memcpy explodes when trying to access that
>> address.
>>
>> I've verified that with:
>>
>> ----
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index 0b05762..d7f48e0 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -9,6 +9,7 @@
>> */
>>
>> #include <linux/vmalloc.h>
>> +#include <linux/memblock.h>
>> #include <linux/mm.h>
>> #include <linux/module.h>
>> #include <linux/highmem.h>
>> @@ -1978,6 +1979,8 @@ static int aligned_vread(char *buf, char *addr, unsigned long count)
>> {
>> struct page *p;
>> int copied = 0;
>> + phys_addr_t phys;
>> + bool nomap;
>>
>> while (count) {
>> unsigned long offset, length;
>> @@ -2000,6 +2003,14 @@ static int aligned_vread(char *buf, char *addr, unsigned long count)
>> * function description)
>> */
>> void *map = kmap_atomic(p);
>> +
>> + phys = page_to_phys(p);
>> + nomap = !memblock_is_map_memory(phys);
>> +
>> + pr_info("HARK: %s kmap'd %pa (%s memory) @ %p\n",
>> + __func__, &phys, (nomap ? "nomap" : "map"),
>> + map);
>> +
>> memcpy(buf, map + offset, length);
>> kunmap_atomic(map);
>> } else
>> ----
>>
>> # cat /proc/kcore > /dev/null
>>
>> ... which eventually results in:
>>
>> [ 47.360980] HARK: aligned_vread kmap'd 0x000003e290005000 (nomap memory) @ ffff83e210005000
>> [ 47.369297] Unable to handle kernel paging request at virtual address ffff83e210005000
>>
>> I'm not sure what we should do here.
>>
>> I'm not immediately sure what the nomap region is. I'm using UEFI && DT,
>> so I guess it's not ACPI tables.
>>
>> I can try to dump more info later.
>>
>> Thanks,
>> Mark.
>
> Thanks a lot.
> Xiaojun.
>
>>
>> .
>>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox