* [PATCH v8 2/7] drm/of: Make drm_of_find_panel_or_bridge() to check graph's presence
From: Dmitry Osipenko @ 2020-06-17 22:26 UTC (permalink / raw)
To: Thierry Reding, Sam Ravnborg, Laurent Pinchart, Rob Herring,
Frank Rowand
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200617222703.17080-1-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
When graph isn't defined in a device-tree, the of_graph_get_remote_node()
prints a noisy error message, telling that port node is not found. This is
undesirable behaviour in our case because absence of a panel/bridge graph
is a valid case. Let's check the graph's presence in a device-tree before
proceeding with parsing of the graph.
Reviewed-by: Sam Ravnborg <sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/gpu/drm/drm_of.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index b50b44e76279..cbe65efdae39 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -246,6 +246,15 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
if (panel)
*panel = NULL;
+ /*
+ * of_graph_get_remote_node() produces a noisy error message if port
+ * node isn't found and the absence of the port is a legit case here,
+ * so at first we silently check whether graph presents in the
+ * device-tree node.
+ */
+ if (!of_graph_presents(np))
+ return -ENODEV;
+
remote = of_graph_get_remote_node(np, port, endpoint);
if (!remote)
return -ENODEV;
--
2.26.0
^ permalink raw reply related
* [PATCH v8 1/7] of_graph: add of_graph_presents()
From: Dmitry Osipenko @ 2020-06-17 22:26 UTC (permalink / raw)
To: Thierry Reding, Sam Ravnborg, Laurent Pinchart, Rob Herring,
Frank Rowand
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200617222703.17080-1-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
In some case, like a DRM display code for example, it's useful to silently
check whether port node exists at all in a device-tree before proceeding
with parsing of the graph.
This patch adds of_graph_presents() that returns true if given device-tree
node contains OF graph port.
Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/of/property.c | 52 +++++++++++++++++++++++++++++++++-------
include/linux/of_graph.h | 6 +++++
2 files changed, 49 insertions(+), 9 deletions(-)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 1f2086f4e7ce..b84ed6a7cf50 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -29,6 +29,48 @@
#include "of_private.h"
+/**
+ * of_graph_get_first_local_port() - get first local port node
+ * @node: pointer to a local endpoint device_node
+ *
+ * Return: First local port node associated with local endpoint node linked
+ * to @node. Use of_node_put() on it when done.
+ */
+static struct device_node *
+of_graph_get_first_local_port(const struct device_node *node)
+{
+ struct device_node *ports, *port;
+
+ ports = of_get_child_by_name(node, "ports");
+ if (ports)
+ node = ports;
+
+ port = of_get_child_by_name(node, "port");
+ of_node_put(ports);
+
+ return port;
+}
+
+/**
+ * of_graph_presents() - check graph's presence
+ * @node: pointer to a device_node checked for the graph's presence
+ *
+ * Return: True if @node has a port or ports sub-node, false otherwise.
+ */
+bool of_graph_presents(const struct device_node *node)
+{
+ struct device_node *local;
+
+ local = of_graph_get_first_local_port(node);
+ if (!local)
+ return false;
+
+ of_node_put(local);
+
+ return true;
+}
+EXPORT_SYMBOL(of_graph_presents);
+
/**
* of_property_count_elems_of_size - Count the number of elements in a property
*
@@ -608,15 +650,7 @@ struct device_node *of_graph_get_next_endpoint(const struct device_node *parent,
* parent port node.
*/
if (!prev) {
- struct device_node *node;
-
- node = of_get_child_by_name(parent, "ports");
- if (node)
- parent = node;
-
- port = of_get_child_by_name(parent, "port");
- of_node_put(node);
-
+ port = of_graph_get_first_local_port(parent);
if (!port) {
pr_err("graph: no port node found in %pOF\n", parent);
return NULL;
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 01038a6aade0..cc3028a0659d 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -38,6 +38,7 @@ struct of_endpoint {
child = of_graph_get_next_endpoint(parent, child))
#ifdef CONFIG_OF
+bool of_graph_presents(const struct device_node *node);
int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
int of_graph_get_endpoint_count(const struct device_node *np);
@@ -56,6 +57,11 @@ struct device_node *of_graph_get_remote_node(const struct device_node *node,
u32 port, u32 endpoint);
#else
+static inline bool of_graph_presents(const struct device_node *node)
+{
+ return false;
+}
+
static inline int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint)
{
--
2.26.0
^ permalink raw reply related
* [PATCH v8 0/7] Support DRM bridges on NVIDIA Tegra
From: Dmitry Osipenko @ 2020-06-17 22:26 UTC (permalink / raw)
To: Thierry Reding, Sam Ravnborg, Laurent Pinchart, Rob Herring,
Frank Rowand
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Hello,
This series adds initial support for the DRM bridges to NVIDIA Tegra DRM
driver. This is required by newer device-trees where we model the LVDS
encoder bridge properly.
Changelog:
v8: - The new of_graph_get_local_port() helper is replaced with the
of_graph_presents(), which simply checks the graph presence in a
given DT node. Thank to Laurent Pinchart for the suggestion!
- The of_graph_get_local_port() is still there, but now it isn't a public
function anymore. In the review to v7 Laurent Pinchart suggested that
the function's doc-comments and name could be improved and I implemented
these suggestions in v8.
- A day ago I discovered that devm_drm_panel_bridge_add() requires
panel to have connector type to be properly set, otherwise function
rejects panels with the incomplete description. So, I checked what
LVDS panels are used on Tegra and fixed the missing connector types
in this new patch:
drm/panel-simple: Add missing connector type for some panels
v7: - Removed the obscure unused structs (which GCC doesn't detect, but CLANG
does) in the patch "Wrap directly-connected panel into DRM bridge",
which was reported by kernel test robot for v6.
v6: - Added r-b and acks from Rob Herring and Sam Ravnborg.
- Rebased on a recent linux-next, patches now apply without fuzz.
v5: - Added new patches that make drm_of_find_panel_or_bridge() more usable
if graph isn't defined in a device-tree:
of_graph: add of_graph_get_local_port()
drm/of: Make drm_of_find_panel_or_bridge() to check graph's presence
- Updated "Support DRM bridges" patch to use drm_of_find_panel_or_bridge()
directly and added WARN_ON(output->panel || output->bridge) sanity-check.
- Added new "Wrap directly-connected panel into DRM bridge" patch, as
was suggested by Laurent Pinchart.
v4: - Following review comments that were made by Laurent Pinchart to the v3,
we now create and use the "bridge connector".
v3: - Following recommendation from Sam Ravnborg, the new bridge attachment
model is now being used, i.e. we ask bridge to *not* create a connector
using the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
- The bridge is now created only for the RGB (LVDS) output, and only
when necessary. For now we don't need bridges for HDMI or DSI outputs.
- I noticed that we're leaking OF node in the panel's error code path,
this is fixed now by the new patch "Don't leak OF node on error".
v2: - Added the new "rgb: Don't register connector if bridge is used"
patch, which hides the unused connector provided by the Tegra DRM
driver when bridge is used, since bridge provides its own connector
to us.
Dmitry Osipenko (7):
of_graph: add of_graph_presents()
drm/of: Make drm_of_find_panel_or_bridge() to check graph's presence
drm/tegra: output: Don't leak OF node on error
drm/tegra: output: Support DRM bridges
drm/tegra: output: rgb: Support LVDS encoder bridge
drm/tegra: output: rgb: Wrap directly-connected panel into DRM bridge
drm/panel-simple: Add missing connector type for some panels
drivers/gpu/drm/drm_of.c | 9 +++
drivers/gpu/drm/panel/panel-simple.c | 7 ++
drivers/gpu/drm/tegra/drm.h | 2 +
drivers/gpu/drm/tegra/output.c | 21 ++++--
drivers/gpu/drm/tegra/rgb.c | 102 ++++++++++++++-------------
drivers/of/property.c | 52 +++++++++++---
include/linux/of_graph.h | 6 ++
7 files changed, 137 insertions(+), 62 deletions(-)
--
2.26.0
^ permalink raw reply
* Re: [RFC PATCH v1 10/18] dt-bindings: tegra: Document VI and CSI port nodes
From: Rob Herring @ 2020-06-17 22:14 UTC (permalink / raw)
To: Sowjanya Komatineni
Cc: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, frankc-DDmLM1+adcrQT0dZR+AlfA,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, sakari.ailus-X3B1VOXEql0,
helen.koike-ZGY8ohtN/8qB+jHODAdFcQ, digetx-Re5JQEeQqe8AvxtiuMwx3w,
sboyd-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1591768960-31648-11-git-send-email-skomatineni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Tue, Jun 09, 2020 at 11:02:32PM -0700, Sowjanya Komatineni wrote:
> This patch documents Tegra VI and CSI port and endpoint nodes along
> with the other required properties.
>
> Signed-off-by: Sowjanya Komatineni <skomatineni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../display/tegra/nvidia,tegra20-host1x.txt | 87 ++++++++++++++++++++++
> 1 file changed, 87 insertions(+)
This is getting converted to schema by Thierry.
Rob
^ permalink raw reply
* Re: [PATCH v4 22/37] dt-bindings: host1x: Document new interconnect properties
From: Dmitry Osipenko @ 2020-06-17 21:48 UTC (permalink / raw)
To: Rob Herring
Cc: Thierry Reding, Jonathan Hunter, Georgi Djakov, Michael Turquette,
Stephen Boyd, Peter De Schrijver, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Mikko Perttunen, Artur Świgoń,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5303317a-2cb6-d7a8-361a-30867fc6eab7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
18.06.2020 00:44, Dmitry Osipenko пишет:
> 18.06.2020 00:37, Rob Herring пишет:
>> On Tue, Jun 09, 2020 at 04:13:49PM +0300, Dmitry Osipenko wrote:
>>> Most of Host1x devices have at least one memory client. These clients
>>> are directly connected to the memory controller. The new interconnect
>>> properties represent the memory client's connection to the memory
>>> controller.
>>>
>>> Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>> .../display/tegra/nvidia,tegra20-host1x.txt | 68 +++++++++++++++++++
>>> 1 file changed, 68 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
>>> index 47319214b5f6..ab4fbee7bccf 100644
>>> --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
>>> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
>>> @@ -20,6 +20,10 @@ Required properties:
>>> - reset-names: Must include the following entries:
>>> - host1x
>>>
>>> +Each host1x client module having to perform DMA through the Memory Controller
>>> +should have the interconnect endpoints set to the Memory Client and External
>>> +Memory respectively.
>>> +
>>> The host1x top-level node defines a number of children, each representing one
>>> of the following host1x client modules:
>>>
>>> @@ -36,6 +40,12 @@ of the following host1x client modules:
>>> - reset-names: Must include the following entries:
>>> - mpe
>>>
>>> + Optional properties:
>>> + - interconnects: Must contain entry for the MPE memory clients.
>>> + - interconnect-names: Must include name of the interconnect path for each
>>> + interconnect entry. Consult TRM documentation for information about
>>> + available memory clients, see MEMORY CONTROLLER section.
>>> +
>>> - vi: video input
>>>
>>> Required properties:
>>> @@ -65,6 +75,12 @@ of the following host1x client modules:
>>> - power-domains: Must include sor powergate node as csicil is in
>>> SOR partition.
>>>
>>> + Optional properties:
>>> + - interconnects: Must contain entry for the VI memory clients.
>>> + - interconnect-names: Must include name of the interconnect path for each
>>> + interconnect entry. Consult TRM documentation for information about
>>> + available memory clients, see MEMORY CONTROLLER section.
>>> +
>>> - epp: encoder pre-processor
>>>
>>> Required properties:
>>> @@ -78,6 +94,12 @@ of the following host1x client modules:
>>> - reset-names: Must include the following entries:
>>> - epp
>>>
>>> + Optional properties:
>>> + - interconnects: Must contain entry for the EPP memory clients.
>>> + - interconnect-names: Must include name of the interconnect path for each
>>> + interconnect entry. Consult TRM documentation for information about
>>> + available memory clients, see MEMORY CONTROLLER section.
>>> +
>>> - isp: image signal processor
>>>
>>> Required properties:
>>> @@ -91,6 +113,12 @@ of the following host1x client modules:
>>> - reset-names: Must include the following entries:
>>> - isp
>>>
>>> + Optional properties:
>>> + - interconnects: Must contain entry for the ISP memory clients.
>>> + - interconnect-names: Must include name of the interconnect path for each
>>> + interconnect entry. Consult TRM documentation for information about
>>> + available memory clients, see MEMORY CONTROLLER section.
>>> +
>>> - gr2d: 2D graphics engine
>>>
>>> Required properties:
>>> @@ -104,6 +132,12 @@ of the following host1x client modules:
>>> - reset-names: Must include the following entries:
>>> - 2d
>>>
>>> + Optional properties:
>>> + - interconnects: Must contain entry for the GR2D memory clients.
>>> + - interconnect-names: Must include name of the interconnect path for each
>>> + interconnect entry. Consult TRM documentation for information about
>>> + available memory clients, see MEMORY CONTROLLER section.
>>> +
>>> - gr3d: 3D graphics engine
>>>
>>> Required properties:
>>> @@ -122,6 +156,12 @@ of the following host1x client modules:
>>> - 3d
>>> - 3d2 (Only required on SoCs with two 3D clocks)
>>>
>>> + Optional properties:
>>> + - interconnects: Must contain entry for the GR3D memory clients.
>>> + - interconnect-names: Must include name of the interconnect path for each
>>> + interconnect entry. Consult TRM documentation for information about
>>> + available memory clients, see MEMORY CONTROLLER section.
>>> +
>>> - dc: display controller
>>>
>>> Required properties:
>>> @@ -149,6 +189,10 @@ of the following host1x client modules:
>>> - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
>>> - nvidia,edid: supplies a binary EDID blob
>>> - nvidia,panel: phandle of a display panel
>>> + - interconnects: Must contain entry for the DC memory clients.
>>> + - interconnect-names: Must include name of the interconnect path for each
>>> + interconnect entry. Consult TRM documentation for information about
>>> + available memory clients, see MEMORY CONTROLLER section.
>>>
>>> - hdmi: High Definition Multimedia Interface
>>>
>>> @@ -297,6 +341,12 @@ of the following host1x client modules:
>>> - reset-names: Must include the following entries:
>>> - vic
>>>
>>> + Optional properties:
>>> + - interconnects: Must contain entry for the VIC memory clients.
>>> + - interconnect-names: Must include name of the interconnect path for each
>>> + interconnect entry. Consult TRM documentation for information about
>>> + available memory clients, see MEMORY CONTROLLER section.
>>> +
>>> Example:
>>>
>>> / {
>>> @@ -410,6 +460,15 @@ Example:
>>> resets = <&tegra_car 27>;
>>> reset-names = "dc";
>>>
>>> + interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>,
>>> + <&mc TEGRA20_MC_DISPLAY0B &emc>,
>>> + <&mc TEGRA20_MC_DISPLAY0C &emc>,
>>> + <&mc TEGRA20_MC_DISPLAY1B &emc>;
>>
>> This looks odd or wrong. Each entry has 2 phandles?
>
> Each entry defines interconnect path, where MC is the start of the path
> and EMC is the end. So yes, 2 phandles for each path.
>
> Please see arm/boot/dts/qcom-msm8974.dtsi for another example [1].
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/qcom-msm8974.dtsi?h=v5.8-rc1#n1448
>
Actually, there are even better examples:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/sc7180.dtsi?h=v5.8-rc1#n1044
^ permalink raw reply
* Re: [PATCH v4 22/37] dt-bindings: host1x: Document new interconnect properties
From: Dmitry Osipenko @ 2020-06-17 21:44 UTC (permalink / raw)
To: Rob Herring
Cc: Thierry Reding, Jonathan Hunter, Georgi Djakov, Michael Turquette,
Stephen Boyd, Peter De Schrijver, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Mikko Perttunen, Artur Świgoń,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200617213726.GA2837398@bogus>
18.06.2020 00:37, Rob Herring пишет:
> On Tue, Jun 09, 2020 at 04:13:49PM +0300, Dmitry Osipenko wrote:
>> Most of Host1x devices have at least one memory client. These clients
>> are directly connected to the memory controller. The new interconnect
>> properties represent the memory client's connection to the memory
>> controller.
>>
>> Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> .../display/tegra/nvidia,tegra20-host1x.txt | 68 +++++++++++++++++++
>> 1 file changed, 68 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
>> index 47319214b5f6..ab4fbee7bccf 100644
>> --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
>> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
>> @@ -20,6 +20,10 @@ Required properties:
>> - reset-names: Must include the following entries:
>> - host1x
>>
>> +Each host1x client module having to perform DMA through the Memory Controller
>> +should have the interconnect endpoints set to the Memory Client and External
>> +Memory respectively.
>> +
>> The host1x top-level node defines a number of children, each representing one
>> of the following host1x client modules:
>>
>> @@ -36,6 +40,12 @@ of the following host1x client modules:
>> - reset-names: Must include the following entries:
>> - mpe
>>
>> + Optional properties:
>> + - interconnects: Must contain entry for the MPE memory clients.
>> + - interconnect-names: Must include name of the interconnect path for each
>> + interconnect entry. Consult TRM documentation for information about
>> + available memory clients, see MEMORY CONTROLLER section.
>> +
>> - vi: video input
>>
>> Required properties:
>> @@ -65,6 +75,12 @@ of the following host1x client modules:
>> - power-domains: Must include sor powergate node as csicil is in
>> SOR partition.
>>
>> + Optional properties:
>> + - interconnects: Must contain entry for the VI memory clients.
>> + - interconnect-names: Must include name of the interconnect path for each
>> + interconnect entry. Consult TRM documentation for information about
>> + available memory clients, see MEMORY CONTROLLER section.
>> +
>> - epp: encoder pre-processor
>>
>> Required properties:
>> @@ -78,6 +94,12 @@ of the following host1x client modules:
>> - reset-names: Must include the following entries:
>> - epp
>>
>> + Optional properties:
>> + - interconnects: Must contain entry for the EPP memory clients.
>> + - interconnect-names: Must include name of the interconnect path for each
>> + interconnect entry. Consult TRM documentation for information about
>> + available memory clients, see MEMORY CONTROLLER section.
>> +
>> - isp: image signal processor
>>
>> Required properties:
>> @@ -91,6 +113,12 @@ of the following host1x client modules:
>> - reset-names: Must include the following entries:
>> - isp
>>
>> + Optional properties:
>> + - interconnects: Must contain entry for the ISP memory clients.
>> + - interconnect-names: Must include name of the interconnect path for each
>> + interconnect entry. Consult TRM documentation for information about
>> + available memory clients, see MEMORY CONTROLLER section.
>> +
>> - gr2d: 2D graphics engine
>>
>> Required properties:
>> @@ -104,6 +132,12 @@ of the following host1x client modules:
>> - reset-names: Must include the following entries:
>> - 2d
>>
>> + Optional properties:
>> + - interconnects: Must contain entry for the GR2D memory clients.
>> + - interconnect-names: Must include name of the interconnect path for each
>> + interconnect entry. Consult TRM documentation for information about
>> + available memory clients, see MEMORY CONTROLLER section.
>> +
>> - gr3d: 3D graphics engine
>>
>> Required properties:
>> @@ -122,6 +156,12 @@ of the following host1x client modules:
>> - 3d
>> - 3d2 (Only required on SoCs with two 3D clocks)
>>
>> + Optional properties:
>> + - interconnects: Must contain entry for the GR3D memory clients.
>> + - interconnect-names: Must include name of the interconnect path for each
>> + interconnect entry. Consult TRM documentation for information about
>> + available memory clients, see MEMORY CONTROLLER section.
>> +
>> - dc: display controller
>>
>> Required properties:
>> @@ -149,6 +189,10 @@ of the following host1x client modules:
>> - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
>> - nvidia,edid: supplies a binary EDID blob
>> - nvidia,panel: phandle of a display panel
>> + - interconnects: Must contain entry for the DC memory clients.
>> + - interconnect-names: Must include name of the interconnect path for each
>> + interconnect entry. Consult TRM documentation for information about
>> + available memory clients, see MEMORY CONTROLLER section.
>>
>> - hdmi: High Definition Multimedia Interface
>>
>> @@ -297,6 +341,12 @@ of the following host1x client modules:
>> - reset-names: Must include the following entries:
>> - vic
>>
>> + Optional properties:
>> + - interconnects: Must contain entry for the VIC memory clients.
>> + - interconnect-names: Must include name of the interconnect path for each
>> + interconnect entry. Consult TRM documentation for information about
>> + available memory clients, see MEMORY CONTROLLER section.
>> +
>> Example:
>>
>> / {
>> @@ -410,6 +460,15 @@ Example:
>> resets = <&tegra_car 27>;
>> reset-names = "dc";
>>
>> + interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>,
>> + <&mc TEGRA20_MC_DISPLAY0B &emc>,
>> + <&mc TEGRA20_MC_DISPLAY0C &emc>,
>> + <&mc TEGRA20_MC_DISPLAY1B &emc>;
>
> This looks odd or wrong. Each entry has 2 phandles?
Each entry defines interconnect path, where MC is the start of the path
and EMC is the end. So yes, 2 phandles for each path.
Please see arm/boot/dts/qcom-msm8974.dtsi for another example [1].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/qcom-msm8974.dtsi?h=v5.8-rc1#n1448
^ permalink raw reply
* Re: [PATCH v4 22/37] dt-bindings: host1x: Document new interconnect properties
From: Rob Herring @ 2020-06-17 21:37 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Thierry Reding, Jonathan Hunter, Georgi Djakov, Michael Turquette,
Stephen Boyd, Peter De Schrijver, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Mikko Perttunen, Artur Świgoń,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200609131404.17523-23-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Jun 09, 2020 at 04:13:49PM +0300, Dmitry Osipenko wrote:
> Most of Host1x devices have at least one memory client. These clients
> are directly connected to the memory controller. The new interconnect
> properties represent the memory client's connection to the memory
> controller.
>
> Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../display/tegra/nvidia,tegra20-host1x.txt | 68 +++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> index 47319214b5f6..ab4fbee7bccf 100644
> --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> @@ -20,6 +20,10 @@ Required properties:
> - reset-names: Must include the following entries:
> - host1x
>
> +Each host1x client module having to perform DMA through the Memory Controller
> +should have the interconnect endpoints set to the Memory Client and External
> +Memory respectively.
> +
> The host1x top-level node defines a number of children, each representing one
> of the following host1x client modules:
>
> @@ -36,6 +40,12 @@ of the following host1x client modules:
> - reset-names: Must include the following entries:
> - mpe
>
> + Optional properties:
> + - interconnects: Must contain entry for the MPE memory clients.
> + - interconnect-names: Must include name of the interconnect path for each
> + interconnect entry. Consult TRM documentation for information about
> + available memory clients, see MEMORY CONTROLLER section.
> +
> - vi: video input
>
> Required properties:
> @@ -65,6 +75,12 @@ of the following host1x client modules:
> - power-domains: Must include sor powergate node as csicil is in
> SOR partition.
>
> + Optional properties:
> + - interconnects: Must contain entry for the VI memory clients.
> + - interconnect-names: Must include name of the interconnect path for each
> + interconnect entry. Consult TRM documentation for information about
> + available memory clients, see MEMORY CONTROLLER section.
> +
> - epp: encoder pre-processor
>
> Required properties:
> @@ -78,6 +94,12 @@ of the following host1x client modules:
> - reset-names: Must include the following entries:
> - epp
>
> + Optional properties:
> + - interconnects: Must contain entry for the EPP memory clients.
> + - interconnect-names: Must include name of the interconnect path for each
> + interconnect entry. Consult TRM documentation for information about
> + available memory clients, see MEMORY CONTROLLER section.
> +
> - isp: image signal processor
>
> Required properties:
> @@ -91,6 +113,12 @@ of the following host1x client modules:
> - reset-names: Must include the following entries:
> - isp
>
> + Optional properties:
> + - interconnects: Must contain entry for the ISP memory clients.
> + - interconnect-names: Must include name of the interconnect path for each
> + interconnect entry. Consult TRM documentation for information about
> + available memory clients, see MEMORY CONTROLLER section.
> +
> - gr2d: 2D graphics engine
>
> Required properties:
> @@ -104,6 +132,12 @@ of the following host1x client modules:
> - reset-names: Must include the following entries:
> - 2d
>
> + Optional properties:
> + - interconnects: Must contain entry for the GR2D memory clients.
> + - interconnect-names: Must include name of the interconnect path for each
> + interconnect entry. Consult TRM documentation for information about
> + available memory clients, see MEMORY CONTROLLER section.
> +
> - gr3d: 3D graphics engine
>
> Required properties:
> @@ -122,6 +156,12 @@ of the following host1x client modules:
> - 3d
> - 3d2 (Only required on SoCs with two 3D clocks)
>
> + Optional properties:
> + - interconnects: Must contain entry for the GR3D memory clients.
> + - interconnect-names: Must include name of the interconnect path for each
> + interconnect entry. Consult TRM documentation for information about
> + available memory clients, see MEMORY CONTROLLER section.
> +
> - dc: display controller
>
> Required properties:
> @@ -149,6 +189,10 @@ of the following host1x client modules:
> - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
> - nvidia,edid: supplies a binary EDID blob
> - nvidia,panel: phandle of a display panel
> + - interconnects: Must contain entry for the DC memory clients.
> + - interconnect-names: Must include name of the interconnect path for each
> + interconnect entry. Consult TRM documentation for information about
> + available memory clients, see MEMORY CONTROLLER section.
>
> - hdmi: High Definition Multimedia Interface
>
> @@ -297,6 +341,12 @@ of the following host1x client modules:
> - reset-names: Must include the following entries:
> - vic
>
> + Optional properties:
> + - interconnects: Must contain entry for the VIC memory clients.
> + - interconnect-names: Must include name of the interconnect path for each
> + interconnect entry. Consult TRM documentation for information about
> + available memory clients, see MEMORY CONTROLLER section.
> +
> Example:
>
> / {
> @@ -410,6 +460,15 @@ Example:
> resets = <&tegra_car 27>;
> reset-names = "dc";
>
> + interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>,
> + <&mc TEGRA20_MC_DISPLAY0B &emc>,
> + <&mc TEGRA20_MC_DISPLAY0C &emc>,
> + <&mc TEGRA20_MC_DISPLAY1B &emc>;
This looks odd or wrong. Each entry has 2 phandles?
> + interconnect-names = "display0a",
> + "display0b",
> + "display0c",
> + "display1b";
> +
> rgb {
> status = "disabled";
> };
> @@ -425,6 +484,15 @@ Example:
> resets = <&tegra_car 26>;
> reset-names = "dc";
>
> + interconnects = <&mc TEGRA20_MC_DISPLAY0AB &emc>,
> + <&mc TEGRA20_MC_DISPLAY0BB &emc>,
> + <&mc TEGRA20_MC_DISPLAY0CB &emc>,
> + <&mc TEGRA20_MC_DISPLAY1BB &emc>;
> + interconnect-names = "display0a",
> + "display0b",
> + "display0c",
> + "display1b";
> +
> rgb {
> status = "disabled";
> };
> --
> 2.26.0
>
^ permalink raw reply
* Re: [PATCH v6 4/4] dt-bindings: mmc: mediatek: Add document for mt6779
From: Rob Herring @ 2020-06-17 21:02 UTC (permalink / raw)
To: Chun-Hung Wu
Cc: mirq-linux-CoA6ZxLDdyEEUmgCuDUIdw, Jonathan Hunter, Al Cooper,
Adrian Hunter, Florian Fainelli,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Andy Gross,
Bjorn Andersson, Michal Simek, Thierry Reding, Chaotian Jing,
Ulf Hansson, Mark Rutland, Matthias Brugger, Linus Walleij,
Pavel Machek, Kate Stewart, Greg Kroah-Hartman,
Martin Blumenstingl
In-Reply-To: <1591665502-6573-5-git-send-email-chun-hung.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Tue, Jun 09, 2020 at 09:18:22AM +0800, Chun-Hung Wu wrote:
> Add compatible node for mt6779 mmc and HW cmdq selection
> node "mediatek,cqhci".
>
> Signed-off-by: Chun-Hung Wu <chun-hung.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mmc/mtk-sd.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 8a532f4..d4d20b9 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -12,6 +12,7 @@ Required properties:
> "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
> "mediatek,mt8183-mmc": for mmc host ip compatible with mt8183
> "mediatek,mt8516-mmc": for mmc host ip compatible with mt8516
> + "mediatek,mt6779-mmc": for mmc host ip compatible with mt6779
> "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
> "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
> "mediatek,mt7622-mmc": for MT7622 SoC
> @@ -49,6 +50,9 @@ Optional properties:
> error caused by stop clock(fifo full)
> Valid range = [0:0x7]. if not present, default value is 0.
> applied to compatible "mediatek,mt2701-mmc".
> +- mediatek,cqhci: HW cmdq selection
> + If present, hw command queue is enabled.
> + If not present, hw command queue is disabled.
'supports-cqe' does the same thing.
>
> Examples:
> mmc0: mmc@11230000 {
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH v2 5/5] drm/tegra: plane: Support 180° rotation
From: Dmitry Osipenko @ 2020-06-17 18:50 UTC (permalink / raw)
To: Emil Velikov
Cc: Thierry Reding, Thomas Zimmermann, Derek Basehore, Sam Ravnborg,
Laurent Pinchart, Sean Paul, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
Linux-Kernel@Vger. Kernel. Org, ML dri-devel
In-Reply-To: <e21404bd-49c9-039e-4aef-c4912a9c0640-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
16.06.2020 14:25, Dmitry Osipenko пишет:
> 16.06.2020 00:47, Emil Velikov пишет:
>> Hi all,
>>
>> Perhaps a silly question:
>>
>> On Mon, 15 Jun 2020 at 08:28, Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>> Combining horizontal and vertical reflections gives us 180 degrees of
>>> rotation.
>>>
>>> Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>> drivers/gpu/drm/tegra/dc.c | 13 ++++++++++++-
>>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>>> index f31bca27cde4..ddd9b88f8fce 100644
>>> --- a/drivers/gpu/drm/tegra/dc.c
>>> +++ b/drivers/gpu/drm/tegra/dc.c
>>
>>> + if (rotation & DRM_MODE_ROTATE_180) {
>>> + plane_state->reflect_x = !plane_state->reflect_x;
>>> + plane_state->reflect_y = !plane_state->reflect_y;
>>> + }
>>> +
>> As mentioned by Ville the above is already handled by
>> drm_rotation_simplify() ... although it makes me wonder:
>>
>>
>>> err = drm_plane_create_rotation_property(&plane->base,
>>> DRM_MODE_ROTATE_0,
>>> DRM_MODE_ROTATE_0 |
>>> + DRM_MODE_ROTATE_180 |
>>> DRM_MODE_REFLECT_X |
>>> DRM_MODE_REFLECT_Y);
>>
>> Would it make sense for drm_plane_create_rotation_property() itself,
>> to add DRM_MODE_ROTATE_180, when both reflections are supported?
>
> Hello Emil,
>
> That's a good point! All DRM_MODE_ROTATE_180 should be removed because
> Tegra can't do 180° + reflected-x. The DRM core takes care of 180°
> rotation when both x/y reflections are supported.
>
I just found out that I forgot to drop the WIP patches which added
transparent rotation support while was checking whether these plane
DRM_MODE_ROTATE_180 could be dropped and it's actually need to be set
for the planes, otherwise 180 rotation support is filtered out by the
atomic check.
^ permalink raw reply
* Re: [PATCH v3] drm/tegra: Add zpos property for cursor planes
From: Dmitry Osipenko @ 2020-06-17 17:14 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, Ville Syrjälä, Daniel Stone,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200617163724.GA3547875@ulmo>
17.06.2020 19:37, Thierry Reding пишет:
> On Wed, Jun 17, 2020 at 05:20:14PM +0300, Dmitry Osipenko wrote:
>> 17.06.2020 17:10, Thierry Reding пишет:
>>> On Tue, Jun 16, 2020 at 09:39:19PM +0300, Dmitry Osipenko wrote:
>>>> 16.06.2020 21:14, Thierry Reding пишет:
>>>>> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>>
>>>>> As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
>>>>> have a zpos property") a warning is emitted if there's a mix of planes
>>>>> with and without a zpos property.
>>>>>
>>>>> On Tegra, cursor planes are always composited on top of all other
>>>>> planes, which is why they never had a zpos property attached to them.
>>>>> However, since the composition order is fixed, this is trivial to
>>>>> remedy by simply attaching an immutable zpos property to them.
>>>>>
>>>>> v3: do not hardcode zpos for overlay planes used as cursor (Dmitry)
>>>>> v2: hardcode cursor plane zpos to 255 instead of 0 (Ville)
>>>>>
>>>>> Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>> ---
>>>>> drivers/gpu/drm/tegra/dc.c | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>>>>> index 83f31c6e891c..04d6848d19fc 100644
>>>>> --- a/drivers/gpu/drm/tegra/dc.c
>>>>> +++ b/drivers/gpu/drm/tegra/dc.c
>>>>> @@ -957,6 +957,7 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
>>>>> }
>>>>>
>>>>> drm_plane_helper_add(&plane->base, &tegra_cursor_plane_helper_funcs);
>>>>> + drm_plane_create_zpos_immutable_property(&plane->base, 255);
>>>>>
>>>>> return &plane->base;
>>>>> }
>>>>>
>>>>
>>>> Looks nice, thanks! Since you dropped all other zpos changes for other
>>>> planes and given that the other planes have 255 for the max zpos, what
>>>> about to set the cursor's zpos to 256?
>>>
>>> I'd prefer to have all of the planes' zpos within the same range. By
>>> default the other planes will be on the very bottom end of that range
>>> and the atomic core will normalize the zpos for all planes anyway, so
>>> the cursor plane will end up with a very small normalized zpos in the
>>> end.
>>>
>>> The zpos documentation already mentions that the behaviour is undefined
>>> if two planes have the same zpos value, so I think userspace is going to
>>> know how to set these anyway.
>>>
>>> It might be worth to do a follow-up patch that is smarter about setting
>>> the range of valid values. 0-255 is true on later chips where we
>>> actually have a proper "layer depth" register field and I wanted this to
>>> be uniform across all generations. Other drivers seem to set the upper
>>> limit on the zpos range to be equal to the number of planes available,
>>> so that there aren't potentially big gaps in the numbering. That said,
>>> since the core already normalizes the zpos for us, I don't see a big
>>> benefit in explicitly clipping the range.
>>
>> But the cursor plane doesn't use the "layer depth" register, doesn't it?
>> So the zpos over 255 shouldn't matter in this case.
>>
>> I know that DRM should normalizes the given zpos, but still it makes me
>> a bit uncomfortable knowing that there are the ranges overlap visible to
>> userspace :)
>
> Userspace has to be able to deal with this anyway because it can't make
> any assumptions about what hardware supports underneath. A cursor on a
> different platform may very well be stackable anywhere in the layout so
> it must ensure that the cursor always has the highest zpos (provided
> that that's what it wants). Immutable 255 basically just says that the
> cursor is always going to be at the top. /If/ userspace then decides to
> set some other plane's zpos = 255, then we're in the "undefined"
> behaviour case that the documentation mentions, in which case the
> behaviour on Tegra would still be sane in showing the cursor on top.
>
> So I don't think there's really an issue with the overlap.
It should work okay, but if cursor had zpos set to 256 then it would
lower the chance for userspace to create the undefined behavior situation.
^ permalink raw reply
* Re: [PATCH v2] Input: document inhibiting
From: Randy Dunlap @ 2020-06-17 16:52 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, linux-pm, linux-acpi, linux-kernel,
linux-iio, linux-arm-kernel, linux-samsung-soc, linux-input,
linux-tegra, patches, ibm-acpi-devel, platform-driver-x86
Cc: kernel, Nick Dyer, Laxman Dewangan, Peter Meerwald-Stadler,
Peter Hutterer, Fabio Estevam, Lars-Peter Clausen,
Krzysztof Kozlowski, Jonathan Hunter, Kukjin Kim, NXP Linux Team,
Sylvain Lemieux, Len Brown, Michael Hennerich, Sascha Hauer,
Henrique de Moraes Holschuh, Vladimir Zapolskiy, Hans de Goede,
Michał Mirosław, Barry Song, Dmitry Torokhov,
Rafael J . Wysocki
In-Reply-To: <20200617101822.8558-1-andrzej.p@collabora.com>
On 6/17/20 3:18 AM, Andrzej Pietrasiewicz wrote:
> Document inhibiting input devices and its relation to being
> a wakeup source.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> ---
> v1..v2:
>
> - Addressed editorial comments from Randy
> - Added a paragraph by Hans
>
> Documentation/input/input-programming.rst | 40 +++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
>
> diff --git a/Documentation/input/input-programming.rst b/Documentation/input/input-programming.rst
> index 45a4c6e05e39..7432315cc829 100644
> --- a/Documentation/input/input-programming.rst
> +++ b/Documentation/input/input-programming.rst
> @@ -164,6 +164,46 @@ disconnects. Calls to both callbacks are serialized.
> The open() callback should return a 0 in case of success or any nonzero value
> in case of failure. The close() callback (which is void) must always succeed.
>
> +Inhibiting input devices
> +~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Inhibiting a device means ignoring input events from it. As such it is about maintaining
> +relationships with input handlers - either already existing relationships, or relationships
> +to be established while the device is in inhibited state.
> +
> +If a device is inhibited, no input handler will receive events from it.
> +
> +The fact that nobody wants events from the device is exploited further, by calling device's
> +close() (if there are users) and open() (if there are users) on inhibit and uninhibit
> +operations, respectively. Indeed, the meaning of close() is to stop providing events
> +to the input core and that of open() is to start providing events to the input core.
> +
> +Calling the device's close() method on inhibit (if there are users) allows the driver
> +to save power. Either by directly powering down the device or by releasing the
> +runtime-pm reference it got in open() when the driver is using runtime-pm.
> +
> +Inhibiting and uninhibiting are orthogonal to opening and closing the device by input
> +handlers. Userspace might want to inhibit a device in anticipation before any handler is
> +positively matched against it.
> +
> +Inhibiting and uninhibiting are orthogonal to device's being a wakeup source, too. Being a
> +wakeup source plays a role when the system is sleeping, not when the system is operating.
> +How drivers should program their interaction between inhibiting, sleeping and being a wakeup
> +source is driver-specific.
> +
> +Taking the analogy with the network devices - bringing a network interface down doesn't mean
> +that it should be impossible be wake the system up on LAN through this interface. So, there
> +may be input drivers which should be considered wakeup sources even when inhibited. Actually,
> +in many I2C input devices their interrupt is declared a wakeup interrupt and its handling
> +happens in driver's core, which is not aware of input-specific inhibit (nor should it be).
> +Composite devices containing several interfaces can be inhibited on a per-interface basis and
> +e.g. inhibiting one interface shouldn't affect the device's capability of being a wakeup source.
> +
> +If a device is to be considered a wakeup source while inhibited, special care must be taken when
> +programming its suspend(), as it might need to call device's open(). Depending on what close()
> +means for the device in question, not opening() it before going to sleep might make it
> +impossible to provide any wakeup events. The device is going to sleep anyway.
> +
> Basic event types
> ~~~~~~~~~~~~~~~~~
>
>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH 5.7 000/162] 5.7.3-rc2 review
From: Greg Kroah-Hartman @ 2020-06-17 16:51 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, shuah-DgEjT+Ai2ygdnm+yROfE0A,
patches-ssFOTAMYnuFg9hUCZPvPmw,
ben.hutchings-4yDnlxn2s6sWdaTGBSpHTA,
lkft-triage-cunTk1MwBs8s++Sfvej+rw, stable-u79uwXL29TY76Z2rM5mHXA,
linux-tegra
In-Reply-To: <77015800-d0a2-38f7-e70a-e6dcbc6325f9-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Tue, Jun 16, 2020 at 09:21:09PM +0100, Jon Hunter wrote:
>
> On 16/06/2020 18:27, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.7.3 release.
> > There are 162 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu, 18 Jun 2020 17:25:43 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.3-rc2.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.7.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> All tests are passing for Tegra ...
>
> Test results for stable-v5.7:
> 11 builds: 11 pass, 0 fail
> 26 boots: 26 pass, 0 fail
> 56 tests: 56 pass, 0 fail
>
> Linux version: 5.7.3-rc2-g55b987cbccd9
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra210-p3450-0000,
> tegra30-cardhu-a04
>
Thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply
* Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
From: Thierry Reding @ 2020-06-17 16:50 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <a14c2791-83af-1cd0-1d15-0544a4bf490b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4445 bytes --]
On Wed, Jun 17, 2020 at 05:33:00PM +0300, Dmitry Osipenko wrote:
> 17.06.2020 17:24, Dmitry Osipenko пишет:
> > 17.06.2020 17:17, Thierry Reding пишет:
> >> On Wed, Jun 17, 2020 at 07:24:16AM +0300, Dmitry Osipenko wrote:
> >>> 12.06.2020 17:18, Thierry Reding пишет:
> >>> ...
> >>>> +patternProperties:
> >>>> + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
> >>>> + "^gpios(-[a-zA-Z0-9-]+)?$":
> >>>> + type: object
> >>>> + required:
> >>>> + - gpio-hog
> >>>
> >>> There are two problems here:
> >>>
> >>> 1. This naming limitation didn't exist before this patch, so it's not a
> >>> part of the conversion.
> >>>
> >>> 2. GPIO core uses the node's name for the hog's name. Hence by imposing
> >>> the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx,
> >>> which doesn't make much sense to me.
> >>>
> >>> Please explain the rationale of this change.
> >>
> >> We could probably do without this if we didn't enforce additional or
> >> unevaluated properties. Because if we don't match on a pattern here then
> >> all of those GPIO hog nodes would show up as "extra" properties and they
> >> are currently not allowed. If we do allow them, then we can drop this,
> >> but we then have no way to fail validation for whatever else somebody
> >> might want to put into these device tree nodes.
> >>
> >> That said, I think additionalProperties can be a schema in itself, so
> >> maybe there's a way to only allow additional properties if they are of
> >> type object and have a gpio-hog property. I'll look into that.
> >
> > Isn't it possible to validate the additional properties by checking what
> > properties they have?
> >
> > For example, if sub-node has a gpio-hog property then this sub-node is
> > okay, otherwise fail.
> >
>
> Ah, I haven't finished reading yours last sentence before started to
> type :) Yes, it will be nice if we could avoid the naming limitation, or
> at least change it to something like xxx-hog.
So according to the json-schema specification, both additionalProperties
and unevaluatedProperties must be a valid JSON schema, which means they
can be objects rather than just booleans. Unfortunately, dt-schema tools
don't allow these to be objects, so the below currently fails with these
tools at the moment.
I can make it work with the following patch against dt-schema.git:
--- >8 ---
diff --git a/meta-schemas/keywords.yaml b/meta-schemas/keywords.yaml
index ed543235d7e7..aa88f726ea3b 100644
--- a/meta-schemas/keywords.yaml
+++ b/meta-schemas/keywords.yaml
@@ -79,7 +79,11 @@ properties:
additionalItems:
type: boolean
additionalProperties:
- type: boolean
+ oneOf:
+ - type: object
+ allOf:
+ - $ref: "#/definitions/sub-schemas"
+ - type: boolean
allOf:
items:
$ref: "#/definitions/sub-schemas"
@@ -140,7 +144,11 @@ properties:
type: true
typeSize: true
unevaluatedProperties:
- type: boolean
+ oneOf:
+ - type: object
+ allOf:
+ - $ref: "#/definitions/sub-schemas"
+ - type: boolean
uniqueItems:
type: boolean
--- >8 ---
With that applied, I can make validation of gpio-hog nodes work without
requiring the names to change, which incidentally will allow me to drop
one of the fixup patches from the ARM/arm64 DTS series.
Here's a hunk that applies on top of this patch and makes this work.
I'll squash it in for the next version.
--- >8 ---
diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
index b2debdb0caff..3f8a9c988305 100644
--- a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
@@ -57,13 +57,6 @@ properties:
interrupt-controller:
description: Marks the device node as an interrupt controller.
-patternProperties:
- # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
- "^gpios(-[a-zA-Z0-9-]+)?$":
- type: object
- required:
- - gpio-hog
-
allOf:
- if:
properties:
@@ -90,7 +83,10 @@ required:
- "#interrupt-cells"
- interrupt-controller
-unevaluatedProperties: false
+unevaluatedProperties:
+ type: object
+ required:
+ - gpio-hog
examples:
- |
--- >8 ---
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* Re: [PATCH v3] drm/tegra: Add zpos property for cursor planes
From: Thierry Reding @ 2020-06-17 16:37 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Jon Hunter, Ville Syrjälä, Daniel Stone,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cef8e371-03a8-455e-561d-fca9d0b88309-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4089 bytes --]
On Wed, Jun 17, 2020 at 05:20:14PM +0300, Dmitry Osipenko wrote:
> 17.06.2020 17:10, Thierry Reding пишет:
> > On Tue, Jun 16, 2020 at 09:39:19PM +0300, Dmitry Osipenko wrote:
> >> 16.06.2020 21:14, Thierry Reding пишет:
> >>> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >>>
> >>> As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
> >>> have a zpos property") a warning is emitted if there's a mix of planes
> >>> with and without a zpos property.
> >>>
> >>> On Tegra, cursor planes are always composited on top of all other
> >>> planes, which is why they never had a zpos property attached to them.
> >>> However, since the composition order is fixed, this is trivial to
> >>> remedy by simply attaching an immutable zpos property to them.
> >>>
> >>> v3: do not hardcode zpos for overlay planes used as cursor (Dmitry)
> >>> v2: hardcode cursor plane zpos to 255 instead of 0 (Ville)
> >>>
> >>> Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >>> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >>> ---
> >>> drivers/gpu/drm/tegra/dc.c | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> >>> index 83f31c6e891c..04d6848d19fc 100644
> >>> --- a/drivers/gpu/drm/tegra/dc.c
> >>> +++ b/drivers/gpu/drm/tegra/dc.c
> >>> @@ -957,6 +957,7 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
> >>> }
> >>>
> >>> drm_plane_helper_add(&plane->base, &tegra_cursor_plane_helper_funcs);
> >>> + drm_plane_create_zpos_immutable_property(&plane->base, 255);
> >>>
> >>> return &plane->base;
> >>> }
> >>>
> >>
> >> Looks nice, thanks! Since you dropped all other zpos changes for other
> >> planes and given that the other planes have 255 for the max zpos, what
> >> about to set the cursor's zpos to 256?
> >
> > I'd prefer to have all of the planes' zpos within the same range. By
> > default the other planes will be on the very bottom end of that range
> > and the atomic core will normalize the zpos for all planes anyway, so
> > the cursor plane will end up with a very small normalized zpos in the
> > end.
> >
> > The zpos documentation already mentions that the behaviour is undefined
> > if two planes have the same zpos value, so I think userspace is going to
> > know how to set these anyway.
> >
> > It might be worth to do a follow-up patch that is smarter about setting
> > the range of valid values. 0-255 is true on later chips where we
> > actually have a proper "layer depth" register field and I wanted this to
> > be uniform across all generations. Other drivers seem to set the upper
> > limit on the zpos range to be equal to the number of planes available,
> > so that there aren't potentially big gaps in the numbering. That said,
> > since the core already normalizes the zpos for us, I don't see a big
> > benefit in explicitly clipping the range.
>
> But the cursor plane doesn't use the "layer depth" register, doesn't it?
> So the zpos over 255 shouldn't matter in this case.
>
> I know that DRM should normalizes the given zpos, but still it makes me
> a bit uncomfortable knowing that there are the ranges overlap visible to
> userspace :)
Userspace has to be able to deal with this anyway because it can't make
any assumptions about what hardware supports underneath. A cursor on a
different platform may very well be stackable anywhere in the layout so
it must ensure that the cursor always has the highest zpos (provided
that that's what it wants). Immutable 255 basically just says that the
cursor is always going to be at the top. /If/ userspace then decides to
set some other plane's zpos = 255, then we're in the "undefined"
behaviour case that the documentation mentions, in which case the
behaviour on Tegra would still be sane in showing the cursor on top.
So I don't think there's really an issue with the overlap.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/5] 180 degrees rotation support for NVIDIA Tegra DRM
From: Dmitry Osipenko @ 2020-06-17 16:27 UTC (permalink / raw)
To: Daniel Stone
Cc: Emil Velikov, Thierry Reding, Thomas Zimmermann, Derek Basehore,
Sam Ravnborg, Laurent Pinchart, Sean Paul,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
Linux-Kernel@Vger. Kernel. Org, ML dri-devel
In-Reply-To: <CAPj87rPwwHWtYpuZfiTMyELvr3D+UAY8CVnH3v6+Lo1-UMRRVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
17.06.2020 12:34, Daniel Stone пишет:
> Hi,
>
> On Tue, 16 Jun 2020 at 22:16, Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> The panel's orientation could be parsed by any panel driver and then
>> assigned as the connector's property in order to allow userspace/FB-core
>> to decide what to do with the rotated display. Apparently upstream
>> kernel supports only that one Samsung device which has display panel
>> mounted upside-down and it already uses the custom DT properties for
>> achieving the 180 rotation. So I don't quite see any panel drivers that
>> instantly could benefit from using the rotation property. Perhaps I can
>> add the orientation support to the panel-simple driver, but will it be
>> useful to anyone?
>
> Yes, exposing it to userspace is helpful, since Weston at least will
> parse the property and then apply the correct transform:
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/315
Hello Daniel,
Thank you very much for the pointer! I missed that Weston now uses the
panel's orientation. I gave a quick test to the recent Weston and indeed
it applies the transform in accordance to the connector's orientation
property.
^ permalink raw reply
* Re: [PATCH 09/73] ARM: tegra: gr2d is not backwards-compatible
From: Dmitry Osipenko @ 2020-06-17 16:21 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jon Hunter
In-Reply-To: <20200616135238.3001888-10-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
16.06.2020 16:51, Thierry Reding пишет:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> The instantiation of gr2d in Tegra114 is not backwards-compatible with
> the version found on earlier chips. Remove the misleading compatible
> string.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm/boot/dts/tegra114.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
> index a0ac9ea9ec9d..d583dfba688f 100644
> --- a/arch/arm/boot/dts/tegra114.dtsi
> +++ b/arch/arm/boot/dts/tegra114.dtsi
> @@ -35,7 +35,7 @@ host1x@50000000 {
> ranges = <0x54000000 0x54000000 0x01000000>;
>
> gr2d@54140000 {
> - compatible = "nvidia,tegra114-gr2d", "nvidia,tegra20-gr2d";
> + compatible = "nvidia,tegra114-gr2d";
> reg = <0x54140000 0x00040000>;
> interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&tegra_car TEGRA114_CLK_GR2D>;
>
Could you please explain what's the difference? AFAIK, the 2D HW is
identical on T20/30/114.
^ permalink raw reply
* Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
From: Dmitry Osipenko @ 2020-06-17 14:33 UTC (permalink / raw)
To: Thierry Reding, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <c0cfa39b-054c-8e88-7e5a-233c24f5d5e9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
17.06.2020 17:24, Dmitry Osipenko пишет:
> 17.06.2020 17:17, Thierry Reding пишет:
>> On Wed, Jun 17, 2020 at 07:24:16AM +0300, Dmitry Osipenko wrote:
>>> 12.06.2020 17:18, Thierry Reding пишет:
>>> ...
>>>> +patternProperties:
>>>> + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
>>>> + "^gpios(-[a-zA-Z0-9-]+)?$":
>>>> + type: object
>>>> + required:
>>>> + - gpio-hog
>>>
>>> There are two problems here:
>>>
>>> 1. This naming limitation didn't exist before this patch, so it's not a
>>> part of the conversion.
>>>
>>> 2. GPIO core uses the node's name for the hog's name. Hence by imposing
>>> the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx,
>>> which doesn't make much sense to me.
>>>
>>> Please explain the rationale of this change.
>>
>> We could probably do without this if we didn't enforce additional or
>> unevaluated properties. Because if we don't match on a pattern here then
>> all of those GPIO hog nodes would show up as "extra" properties and they
>> are currently not allowed. If we do allow them, then we can drop this,
>> but we then have no way to fail validation for whatever else somebody
>> might want to put into these device tree nodes.
>>
>> That said, I think additionalProperties can be a schema in itself, so
>> maybe there's a way to only allow additional properties if they are of
>> type object and have a gpio-hog property. I'll look into that.
>
> Isn't it possible to validate the additional properties by checking what
> properties they have?
>
> For example, if sub-node has a gpio-hog property then this sub-node is
> okay, otherwise fail.
>
Ah, I haven't finished reading yours last sentence before started to
type :) Yes, it will be nice if we could avoid the naming limitation, or
at least change it to something like xxx-hog.
^ permalink raw reply
* Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
From: Dmitry Osipenko @ 2020-06-17 14:24 UTC (permalink / raw)
To: Thierry Reding, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200617141706.GC3536291@ulmo>
17.06.2020 17:17, Thierry Reding пишет:
> On Wed, Jun 17, 2020 at 07:24:16AM +0300, Dmitry Osipenko wrote:
>> 12.06.2020 17:18, Thierry Reding пишет:
>> ...
>>> +patternProperties:
>>> + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
>>> + "^gpios(-[a-zA-Z0-9-]+)?$":
>>> + type: object
>>> + required:
>>> + - gpio-hog
>>
>> There are two problems here:
>>
>> 1. This naming limitation didn't exist before this patch, so it's not a
>> part of the conversion.
>>
>> 2. GPIO core uses the node's name for the hog's name. Hence by imposing
>> the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx,
>> which doesn't make much sense to me.
>>
>> Please explain the rationale of this change.
>
> We could probably do without this if we didn't enforce additional or
> unevaluated properties. Because if we don't match on a pattern here then
> all of those GPIO hog nodes would show up as "extra" properties and they
> are currently not allowed. If we do allow them, then we can drop this,
> but we then have no way to fail validation for whatever else somebody
> might want to put into these device tree nodes.
>
> That said, I think additionalProperties can be a schema in itself, so
> maybe there's a way to only allow additional properties if they are of
> type object and have a gpio-hog property. I'll look into that.
Isn't it possible to validate the additional properties by checking what
properties they have?
For example, if sub-node has a gpio-hog property then this sub-node is
okay, otherwise fail.
^ permalink raw reply
* Re: [PATCH 03/73] ARM: tegra: Remove simple regulators bus
From: Thierry Reding @ 2020-06-17 14:22 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <cf8eb9d4-70d5-400f-ecc8-2139c25563a9-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4863 bytes --]
On Tue, Jun 16, 2020 at 08:24:11PM +0100, Jon Hunter wrote:
>
>
> On 16/06/2020 14:51, Thierry Reding wrote:
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > The standard way to do this is to list out the regulators at the top
> > level. Adopt the standard way to fix validation.
> >
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > arch/arm/boot/dts/tegra114-dalmore.dts | 129 +++++------
> > arch/arm/boot/dts/tegra114-roth.dts | 120 +++++-----
> > arch/arm/boot/dts/tegra114-tn7.dts | 65 +++---
> > arch/arm/boot/dts/tegra124-jetson-tk1.dts | 238 +++++++++----------
> > arch/arm/boot/dts/tegra124-nyan.dtsi | 259 ++++++++++-----------
> > arch/arm/boot/dts/tegra124-venice2.dts | 265 ++++++++++------------
> > arch/arm/boot/dts/tegra20-harmony.dts | 121 +++++-----
> > arch/arm/boot/dts/tegra20-medcom-wide.dts | 66 +++---
> > arch/arm/boot/dts/tegra20-paz00.dts | 38 ++--
> > arch/arm/boot/dts/tegra20-plutux.dts | 66 +++---
> > arch/arm/boot/dts/tegra20-seaboard.dts | 125 +++++-----
> > arch/arm/boot/dts/tegra20-tamonten.dtsi | 39 +---
> > arch/arm/boot/dts/tegra20-tec.dts | 66 +++---
> > arch/arm/boot/dts/tegra20-trimslice.dts | 85 +++----
> > arch/arm/boot/dts/tegra20-ventana.dts | 85 +++----
> > arch/arm/boot/dts/tegra30-beaver.dts | 193 ++++++++--------
> > arch/arm/boot/dts/tegra30-cardhu-a02.dts | 128 +++++------
> > arch/arm/boot/dts/tegra30-cardhu-a04.dts | 149 ++++++------
> > arch/arm/boot/dts/tegra30-cardhu.dtsi | 261 ++++++++++-----------
> > 19 files changed, 1130 insertions(+), 1368 deletions(-)
>
> ...
>
> > diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
> > index 6a7a31c831c5..effdb303c7f7 100644
> > --- a/arch/arm/boot/dts/tegra124-venice2.dts
> > +++ b/arch/arm/boot/dts/tegra124-venice2.dts
> > @@ -1077,164 +1077,145 @@ power {
> >
> > panel: panel {
> > compatible = "lg,lp129qe";
> > -
> > + power-supply = <&vdd_3v3_panel>;
> > backlight = <&backlight>;
> > ddc-i2c-bus = <&dpaux>;
> > };
>
> Is this meant to be in this patch?
>
> > diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
> > index 20137fc578b1..95e6bccdb4f6 100644
> > --- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
> > +++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
> > @@ -495,40 +495,25 @@ usb-phy@c5008000 {
> > status = "okay";
> > };
> >
> > - sdhci@c8000600 {
> > + mmc@c8000600 {
> > cd-gpios = <&gpio TEGRA_GPIO(H, 2) GPIO_ACTIVE_LOW>;
> > wp-gpios = <&gpio TEGRA_GPIO(H, 3) GPIO_ACTIVE_HIGH>;
> > bus-width = <4>;
> > status = "okay";
> > };
> >
> > - clocks {
> > - compatible = "simple-bus";
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > -
> > - clk32k_in: clock@0 {
> > - compatible = "fixed-clock";
> > - reg = <0>;
> > - #clock-cells = <0>;
> > - clock-frequency = <32768>;
> > - };
> > + clk32k_in: clock@0 {
> > + compatible = "fixed-clock";
> > + clock-frequency = <32768>;
> > + #clock-cells = <0>;
> > };
>
> The above appears in to be in the wrong patch.
>
> > diff --git a/arch/arm/boot/dts/tegra30-cardhu-a02.dts b/arch/arm/boot/dts/tegra30-cardhu-a02.dts
> > index a02ec5082287..4899e05a0d9c 100644
> > --- a/arch/arm/boot/dts/tegra30-cardhu-a02.dts
> > +++ b/arch/arm/boot/dts/tegra30-cardhu-a02.dts
> > @@ -9,87 +9,75 @@ / {
> > model = "NVIDIA Tegra30 Cardhu A02 evaluation board";
> > compatible = "nvidia,cardhu-a02", "nvidia,cardhu", "nvidia,tegra30";
> >
> > - sdhci@78000400 {
> > + mmc@78000400 {
> > status = "okay";
> > power-gpios = <&gpio TEGRA_GPIO(D, 4) GPIO_ACTIVE_HIGH>;
> > bus-width = <4>;
> > keep-power-in-suspend;
> > };
>
> And here.
>
> > diff --git a/arch/arm/boot/dts/tegra30-cardhu-a04.dts b/arch/arm/boot/dts/tegra30-cardhu-a04.dts
> > index 9234988624ec..c1c0ca628af1 100644
> > --- a/arch/arm/boot/dts/tegra30-cardhu-a04.dts
> > +++ b/arch/arm/boot/dts/tegra30-cardhu-a04.dts
> > @@ -11,99 +11,86 @@ / {
> > model = "NVIDIA Tegra30 Cardhu A04 (A05, A06, A07) evaluation board";
> > compatible = "nvidia,cardhu-a04", "nvidia,cardhu", "nvidia,tegra30";
> >
> > - sdhci@78000400 {
> > + mmc@78000400 {
> > status = "okay";
> > power-gpios = <&gpio TEGRA_GPIO(D, 3) GPIO_ACTIVE_HIGH>;
> > bus-width = <4>;
> > keep-power-in-suspend;
> > };
>
> And here.
Ugh... indeed. To be honest, I'm surprised there aren't more of these
issues given the amount of rebasing that I needed to get this whole set
sorted out. I'll do some more rebasing to get these into the right
patches.
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 02/73] ARM: tegra: Remove simple clocks bus
From: Thierry Reding @ 2020-06-17 14:21 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <74f8be81-216b-b69b-4517-c90d5f7d578a-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]
On Tue, Jun 16, 2020 at 08:06:56PM +0100, Jon Hunter wrote:
>
>
> On 16/06/2020 14:51, Thierry Reding wrote:
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > The standard way to do this is to list out the clocks at the top-level.
> > Adopt the standard way to fix validation.
> >
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > arch/arm/boot/dts/tegra114-dalmore.dts | 15 ++++-----------
> > arch/arm/boot/dts/tegra114-roth.dts | 15 ++++-----------
> > arch/arm/boot/dts/tegra114-tn7.dts | 15 ++++-----------
> > arch/arm/boot/dts/tegra124-jetson-tk1.dts | 15 ++++-----------
> > arch/arm/boot/dts/tegra124-nyan.dtsi | 15 ++++-----------
> > arch/arm/boot/dts/tegra124-venice2.dts | 15 ++++-----------
> > arch/arm/boot/dts/tegra20-harmony.dts | 15 ++++-----------
> > arch/arm/boot/dts/tegra20-paz00.dts | 15 ++++-----------
> > arch/arm/boot/dts/tegra20-seaboard.dts | 15 ++++-----------
> > arch/arm/boot/dts/tegra20-trimslice.dts | 19 ++++++-------------
> > arch/arm/boot/dts/tegra20-ventana.dts | 15 ++++-----------
> > arch/arm/boot/dts/tegra30-beaver.dts | 15 ++++-----------
> > arch/arm/boot/dts/tegra30-cardhu.dtsi | 15 ++++-----------
> > 13 files changed, 54 insertions(+), 145 deletions(-)
>
> ...
>
> > diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
> > index 8debd3d3c20d..5b26482a55b7 100644
> > --- a/arch/arm/boot/dts/tegra20-trimslice.dts
> > +++ b/arch/arm/boot/dts/tegra20-trimslice.dts
> > @@ -366,30 +366,23 @@ usb-phy@c5008000 {
> > status = "okay";
> > };
> >
> > - sdhci@c8000000 {
> > + mmc@c8000000 {
> > status = "okay";
> > broken-cd;
> > bus-width = <4>;
> > };
> >
> > - sdhci@c8000600 {
> > + mmc@c8000600 {
> > status = "okay";
> > cd-gpios = <&gpio TEGRA_GPIO(P, 1) GPIO_ACTIVE_LOW>;
> > wp-gpios = <&gpio TEGRA_GPIO(P, 2) GPIO_ACTIVE_HIGH>;
> > bus-width = <4>;
> > };
>
> I think that the above belongs in patch 13/73.
Good catch!
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] [v2] dmaengine: tegra210-adma: Fix runtime PM imbalance on error
From: Vinod Koul @ 2020-06-17 14:20 UTC (permalink / raw)
To: Dinghao Liu
Cc: kjlu-OJFnDUYgAso, Laxman Dewangan, Jon Hunter, Dan Williams,
Thierry Reding, dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200522114824.8554-1-dinghao.liu-Y5EWUtBUdg4nDS1+zs4M5A@public.gmane.org>
On 22-05-20, 19:48, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
>
> Signed-off-by: Dinghao Liu <dinghao.liu-Y5EWUtBUdg4nDS1+zs4M5A@public.gmane.org>
> ---
>
> Changelog:
>
> v2: - Merge two patches that fix runtime PM imbalance in
> tegra_adma_probe() and tegra_adma_alloc_chan_resources()
> respectively.
> ---
> drivers/dma/tegra210-adma.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
> index c4ce5dfb149b..2d6e419b6eac 100644
> --- a/drivers/dma/tegra210-adma.c
> +++ b/drivers/dma/tegra210-adma.c
> @@ -658,6 +658,7 @@ static int tegra_adma_alloc_chan_resources(struct dma_chan *dc)
>
> ret = pm_runtime_get_sync(tdc2dev(tdc));
> if (ret < 0) {
> + pm_runtime_put_sync(tdc2dev(tdc));
Pls dont use _sync() here
> free_irq(tdc->irq, tdc);
> return ret;
> }
> @@ -870,7 +871,7 @@ static int tegra_adma_probe(struct platform_device *pdev)
>
> ret = pm_runtime_get_sync(&pdev->dev);
> if (ret < 0)
> - goto rpm_disable;
> + goto rpm_put;
>
> ret = tegra_adma_init(tdma);
> if (ret)
> @@ -921,7 +922,6 @@ static int tegra_adma_probe(struct platform_device *pdev)
> dma_async_device_unregister(&tdma->dma_dev);
> rpm_put:
> pm_runtime_put_sync(&pdev->dev);
> -rpm_disable:
> pm_runtime_disable(&pdev->dev);
> irq_dispose:
> while (--i >= 0)
> --
> 2.17.1
--
~Vinod
^ permalink raw reply
* Re: [PATCH v3] drm/tegra: Add zpos property for cursor planes
From: Dmitry Osipenko @ 2020-06-17 14:20 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, Ville Syrjälä, Daniel Stone,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200617141015.GB3536291@ulmo>
17.06.2020 17:10, Thierry Reding пишет:
> On Tue, Jun 16, 2020 at 09:39:19PM +0300, Dmitry Osipenko wrote:
>> 16.06.2020 21:14, Thierry Reding пишет:
>>> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>
>>> As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
>>> have a zpos property") a warning is emitted if there's a mix of planes
>>> with and without a zpos property.
>>>
>>> On Tegra, cursor planes are always composited on top of all other
>>> planes, which is why they never had a zpos property attached to them.
>>> However, since the composition order is fixed, this is trivial to
>>> remedy by simply attaching an immutable zpos property to them.
>>>
>>> v3: do not hardcode zpos for overlay planes used as cursor (Dmitry)
>>> v2: hardcode cursor plane zpos to 255 instead of 0 (Ville)
>>>
>>> Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>> ---
>>> drivers/gpu/drm/tegra/dc.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>>> index 83f31c6e891c..04d6848d19fc 100644
>>> --- a/drivers/gpu/drm/tegra/dc.c
>>> +++ b/drivers/gpu/drm/tegra/dc.c
>>> @@ -957,6 +957,7 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
>>> }
>>>
>>> drm_plane_helper_add(&plane->base, &tegra_cursor_plane_helper_funcs);
>>> + drm_plane_create_zpos_immutable_property(&plane->base, 255);
>>>
>>> return &plane->base;
>>> }
>>>
>>
>> Looks nice, thanks! Since you dropped all other zpos changes for other
>> planes and given that the other planes have 255 for the max zpos, what
>> about to set the cursor's zpos to 256?
>
> I'd prefer to have all of the planes' zpos within the same range. By
> default the other planes will be on the very bottom end of that range
> and the atomic core will normalize the zpos for all planes anyway, so
> the cursor plane will end up with a very small normalized zpos in the
> end.
>
> The zpos documentation already mentions that the behaviour is undefined
> if two planes have the same zpos value, so I think userspace is going to
> know how to set these anyway.
>
> It might be worth to do a follow-up patch that is smarter about setting
> the range of valid values. 0-255 is true on later chips where we
> actually have a proper "layer depth" register field and I wanted this to
> be uniform across all generations. Other drivers seem to set the upper
> limit on the zpos range to be equal to the number of planes available,
> so that there aren't potentially big gaps in the numbering. That said,
> since the core already normalizes the zpos for us, I don't see a big
> benefit in explicitly clipping the range.
But the cursor plane doesn't use the "layer depth" register, doesn't it?
So the zpos over 255 shouldn't matter in this case.
I know that DRM should normalizes the given zpos, but still it makes me
a bit uncomfortable knowing that there are the ranges overlap visible to
userspace :)
^ permalink raw reply
* Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
From: Thierry Reding @ 2020-06-17 14:17 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <186ceadd-317c-a7b2-d4ab-32473f857545-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]
On Wed, Jun 17, 2020 at 07:24:16AM +0300, Dmitry Osipenko wrote:
> 12.06.2020 17:18, Thierry Reding пишет:
> ...
> > +patternProperties:
> > + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
> > + "^gpios(-[a-zA-Z0-9-]+)?$":
> > + type: object
> > + required:
> > + - gpio-hog
>
> There are two problems here:
>
> 1. This naming limitation didn't exist before this patch, so it's not a
> part of the conversion.
>
> 2. GPIO core uses the node's name for the hog's name. Hence by imposing
> the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx,
> which doesn't make much sense to me.
>
> Please explain the rationale of this change.
We could probably do without this if we didn't enforce additional or
unevaluated properties. Because if we don't match on a pattern here then
all of those GPIO hog nodes would show up as "extra" properties and they
are currently not allowed. If we do allow them, then we can drop this,
but we then have no way to fail validation for whatever else somebody
might want to put into these device tree nodes.
That said, I think additionalProperties can be a schema in itself, so
maybe there's a way to only allow additional properties if they are of
type object and have a gpio-hog property. I'll look into that.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3] drm/tegra: Add zpos property for cursor planes
From: Thierry Reding @ 2020-06-17 14:10 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Jon Hunter, Ville Syrjälä, Daniel Stone,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8e45b425-b667-433e-2074-7a058329f5c2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2815 bytes --]
On Tue, Jun 16, 2020 at 09:39:19PM +0300, Dmitry Osipenko wrote:
> 16.06.2020 21:14, Thierry Reding пишет:
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
> > have a zpos property") a warning is emitted if there's a mix of planes
> > with and without a zpos property.
> >
> > On Tegra, cursor planes are always composited on top of all other
> > planes, which is why they never had a zpos property attached to them.
> > However, since the composition order is fixed, this is trivial to
> > remedy by simply attaching an immutable zpos property to them.
> >
> > v3: do not hardcode zpos for overlay planes used as cursor (Dmitry)
> > v2: hardcode cursor plane zpos to 255 instead of 0 (Ville)
> >
> > Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > drivers/gpu/drm/tegra/dc.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > index 83f31c6e891c..04d6848d19fc 100644
> > --- a/drivers/gpu/drm/tegra/dc.c
> > +++ b/drivers/gpu/drm/tegra/dc.c
> > @@ -957,6 +957,7 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
> > }
> >
> > drm_plane_helper_add(&plane->base, &tegra_cursor_plane_helper_funcs);
> > + drm_plane_create_zpos_immutable_property(&plane->base, 255);
> >
> > return &plane->base;
> > }
> >
>
> Looks nice, thanks! Since you dropped all other zpos changes for other
> planes and given that the other planes have 255 for the max zpos, what
> about to set the cursor's zpos to 256?
I'd prefer to have all of the planes' zpos within the same range. By
default the other planes will be on the very bottom end of that range
and the atomic core will normalize the zpos for all planes anyway, so
the cursor plane will end up with a very small normalized zpos in the
end.
The zpos documentation already mentions that the behaviour is undefined
if two planes have the same zpos value, so I think userspace is going to
know how to set these anyway.
It might be worth to do a follow-up patch that is smarter about setting
the range of valid values. 0-255 is true on later chips where we
actually have a proper "layer depth" register field and I wanted this to
be uniform across all generations. Other drivers seem to set the upper
limit on the zpos range to be equal to the number of planes available,
so that there aren't potentially big gaps in the numbering. That said,
since the core already normalizes the zpos for us, I don't see a big
benefit in explicitly clipping the range.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: tegra: Fix reference count leaks.
From: Mark Brown @ 2020-06-17 13:30 UTC (permalink / raw)
To: wu000273-OJFnDUYgAso@public.gmane.org, kjlu-OJFnDUYgAso
Cc: Thierry Reding, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Edward Cragg, Ben Dooks,
YueHaibing, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Jonathan Hunter,
Liam Girdwood, Takashi Iwai
In-Reply-To: <20200613204422.24484-1-wu000273-OJFnDUYgAso@public.gmane.org>
On Sat, 13 Jun 2020 15:44:19 -0500, wu000273-OJFnDUYgAso@public.gmane.org wrote:
> Calling pm_runtime_get_sync increments the counter even in case of
> failure, causing incorrect ref count if pm_runtime_put is not called in
> error handling paths. Call pm_runtime_put if pm_runtime_get_sync fails.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: tegra: Fix reference count leaks.
commit: deca195383a6085be62cb453079e03e04d618d6e
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ 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