[PATCH 01/12] dt-bindings: display: Convert ingenic,lcd.txt to YAML
Convert the ingenic,lcd.txt to a new ingenic,lcd.yaml file.
In the process, the new ingenic,jz4780-lcd compatible string has been
added.
Signed-off-by: Paul Cercueil
---
Notes:
This patch comes from a different patchset so it's effectively a V2.
Changes were:
- lcd_pclk and lcd clocks are in the correct order now,
- Add 'port' and 'ports' properties, and document the valid ports.
.../bindings/display/ingenic,lcd.txt | 45 ---
.../bindings/display/ingenic,lcd.yaml | 126 ++
2 files changed, 126 insertions(+), 45 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.txt
create mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.yaml
diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.txt
b/Documentation/devicetree/bindings/display/ingenic,lcd.txt
deleted file mode 100644
index 01e3261defb6..
--- a/Documentation/devicetree/bindings/display/ingenic,lcd.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-Ingenic JZ47xx LCD driver
-
-Required properties:
-- compatible: one of:
- * ingenic,jz4740-lcd
- * ingenic,jz4725b-lcd
- * ingenic,jz4770-lcd
-- reg: LCD registers location and length
-- clocks: LCD pixclock and device clock specifiers.
- The device clock is only required on the JZ4740.
-- clock-names: "lcd_pclk" and "lcd"
-- interrupts: Specifies the interrupt line the LCD controller is connected to.
-
-Example:
-
-panel {
- compatible = "sharp,ls020b1dd01d";
-
- backlight = <>;
- power-supply = <>;
-
- port {
- panel_input: endpoint {
- remote-endpoint = <_output>;
- };
- };
-};
-
-
-lcd: lcd-controller@1305 {
- compatible = "ingenic,jz4725b-lcd";
- reg = <0x1305 0x1000>;
-
- interrupt-parent = <>;
- interrupts = <31>;
-
- clocks = < JZ4725B_CLK_LCD>;
- clock-names = "lcd";
-
- port {
- panel_output: endpoint {
- remote-endpoint = <_input>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
new file mode 100644
index ..d56db1802fad
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ingenic,lcd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ingenic SoCs LCD controller devicetree bindings
+
+maintainers:
+ - Paul Cercueil
+
+properties:
+ $nodename:
+pattern: "^lcd-controller@[0-9a-f]+$"
+
+ compatible:
+enum:
+ - ingenic,jz4740-lcd
+ - ingenic,jz4725b-lcd
+ - ingenic,jz4770-lcd
+ - ingenic,jz4780-lcd
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Pixel clock
+ - description: Module clock
+minItems: 1
+
+ clock-names:
+items:
+ - const: lcd_pclk
+ - const: lcd
+minItems: 1
+
+ port:
+description: OF graph bindings (specified in bindings/graph.txt).
+
+ ports:
+description: OF graph bindings (specified in bindings/graph.txt).
+type: object
+properties:
+ port@0:
+type: object
+description: DPI output, to interface with TFT panels.
+
+ port@8:
+type: object
+description: Link to the Image Processing Unit (IPU).
+ (See ingenic,ipu.yaml).
+
+required:
+ - port@0
+
+required:
+- compatible
+- reg
+- interrupts
+- clocks
+- clock-names
+
+if:
+ properties:
+compatible:
+ contains:
+enum:
+ - ingenic,jz4740-lcd
+ - ingenic,jz4780-lcd
+then:
+ properties:
+clocks:
+ minItems: 2
+clock-names:
+ minItems: 2
+else:
+ properties:
+clocks:
+ maxItems: 1
+clock-names:
+ maxItems: 1
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+lcd-controller@1305 {
+ compatible = "ingenic,jz4740-lcd";
+ reg = <0x1305 0x1000>;
+
+ interrupt-parent = <>;
+ interrupts = <30>;
+
+ clocks = < JZ4740_CLK_LCD_PCLK>, < JZ4740_CLK_LCD>;
+ clock-names = "lcd_pclk", "lcd";
+
+ port {
+endpoint {
+ remote-endpoint = <_input>;
+};
+ };
+};
+
+ - |
+#include
+lcd-controller@1305 {
+ compatible = "ingenic,jz4725b-lcd";
+ reg = <0x1305 0x1000>;
+
+ interrupt-parent = <>;
+ interrupts = <31>;
+
+ clocks = < JZ4725B_CLK_LCD>;
+ clock-names = "lcd_pclk";
+
+ port {
+endpoint {
+ remote-endpoint = <_input>;
+};
+ };
+};
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[PATCH 06/12] gpu/drm: Ingenic: Fix incorrect assumption about plane->index
plane->index is NOT the index of the color plane in a YUV frame.
Actually, a YUV frame is represented by a single drm_plane, even though
it contains three Y, U, V planes.
Cc: sta...@vger.kernel.org # v5.3
Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs")
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 97244462599b..3207105755c9 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -386,7 +386,7 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
width = state->src_w >> 16;
height = state->src_h >> 16;
- cpp = state->fb->format->cpp[plane->index];
+ cpp = state->fb->format->cpp[0];
priv->dma_hwdesc->addr = addr;
priv->dma_hwdesc->cmd = width * height * cpp / 4;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/12] gpu/drm: Ingenic: Add support for the IPU
Add support for the Image Processing Unit (IPU) found in all Ingenic
SoCs.
The IPU can upscale and downscale a source frame of arbitrary size
ranging from 4x4 to 4096x4096 on newer SoCs, with bicubic filtering
on newer SoCs, bilinear filtering on older SoCs. Nearest-neighbour can
also be obtained with proper coefficients.
Starting from the JZ4725B, the IPU supports a mode where its output is
sent directly to the CRTC, without having to be written to RAM first.
This makes it possible to use the IPU as a DRM plane on the compatible
SoCs, and have it convert and scale anything the userspace asks for to
what's available for the display.
Regarding pixel formats, older SoCs support packed YUV 4:2:2 and various
planar YUV formats. Newer SoCs also support RGB.
The CRTC can toggle between the primary plane and the IPU, but cannot
display both at the same time. The IPU plane is then a primary plane
itself.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/Kconfig | 11 +
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-drm.c | 67 +-
drivers/gpu/drm/ingenic/ingenic-drm.h | 9 +
drivers/gpu/drm/ingenic/ingenic-ipu.c | 861 ++
drivers/gpu/drm/ingenic/ingenic-ipu.h | 110
6 files changed, 1048 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-ipu.c
create mode 100644 drivers/gpu/drm/ingenic/ingenic-ipu.h
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index d82c3d37ec9c..80e10527d404 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -14,3 +14,14 @@ config DRM_INGENIC
Choose this option for DRM support for the Ingenic SoCs.
If M is selected the module will be called ingenic-drm.
+
+if DRM_INGENIC
+
+config DRM_INGENIC_IPU
+ tristate "IPU support for Ingenic SoCs"
+ help
+ Choose this option to enable support for the IPU found in Ingenic
SoCs.
+
+ If M is selected the module will be called ingenic-ipu.
+
+endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index 11cac42ce0bb..df156194fbe5 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
+obj-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index b53db3ee001f..ad1cec4f2a4d 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -50,7 +50,7 @@ struct jz_soc_info {
struct ingenic_drm {
struct drm_device drm;
- struct drm_plane f0, f1;
+ struct drm_plane f0, f1, *ipu_plane;
struct drm_crtc crtc;
struct drm_encoder encoder;
@@ -186,13 +186,16 @@ static void ingenic_drm_crtc_update_timings(struct
ingenic_drm *priv,
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16,
JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16);
+
+ regmap_write(priv->map, JZ_REG_LCD_IPUR, JZ_LCD_IPUR_IPUREN |
+(ht * vpe / 3) << JZ_LCD_IPUR_IPUR_LSB);
}
static int ingenic_drm_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
- struct drm_plane_state *f1_state, *f0_state;
+ struct drm_plane_state *f1_state, *f0_state, *ipu_state;
long rate;
if (!drm_atomic_crtc_needs_modeset(state))
@@ -213,14 +216,41 @@ static int ingenic_drm_crtc_atomic_check(struct drm_crtc
*crtc,
f0_state = drm_atomic_get_plane_state(state->state,
>f0);
+ if (priv->ipu_plane)
+ ipu_state = drm_atomic_get_plane_state(state->state,
+ priv->ipu_plane);
+
+ /* IPU and F1 planes cannot be enabled at the same time. */
+ if (priv->ipu_plane && f1_state->fb && ipu_state->fb) {
+ dev_dbg(priv->dev, "Cannot enable both F1 and IPU\n");
+ return -EINVAL;
+ }
+
/* If all the planes are disabled, we won't get a VBLANK IRQ */
- if (!f1_state->fb && !f0_state->fb)
+ if (!f1_state->fb && !f0_state->fb &&
+ !(priv->ipu_plane && ipu_state->fb))
state->no_vblank = true;
}
return 0;
}
+static void ingenic_drm_crtc_atomic_begin(struct drm_crtc *crtc,
+ struct drm_crtc_state *oldstate)
+{
+ struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
+ u32 ctrl = 0;
+
+ if (priv->soc_info->has_osd &&
+ drm_atomic_crtc_needs_modeset(crtc->state)) {
+
[PATCH 04/12] gpu/drm: ingenic: Fix bogus crtc_atomic_check callback
The code was comparing the SoC's maximum height with the mode's width,
and vice-versa. D'oh.
Cc: sta...@vger.kernel.org # v5.6
Fixes: a7c909b7c037 ("gpu/drm: ingenic: Check for display size in CRTC atomic
check")
Signed-off-by: Paul Cercueil
---
Notes:
This patch was previously sent standalone.
I marked it as superseded in patchwork.
Nothing has been changed here.
drivers/gpu/drm/ingenic/ingenic-drm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 632d72177123..0c472382a08b 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -330,8 +330,8 @@ static int ingenic_drm_crtc_atomic_check(struct drm_crtc
*crtc,
if (!drm_atomic_crtc_needs_modeset(state))
return 0;
- if (state->mode.hdisplay > priv->soc_info->max_height ||
- state->mode.vdisplay > priv->soc_info->max_width)
+ if (state->mode.hdisplay > priv->soc_info->max_width ||
+ state->mode.vdisplay > priv->soc_info->max_height)
return -EINVAL;
rate = clk_round_rate(priv->pix_clk,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/12] gpu/drm: Ingenic: Support multiple panels/bridges
Support multiple panels or bridges connected to the same DPI output of
the SoC. This setup can be found for instance on the GCW Zero, where the
same DPI output interfaces the internal 320x240 TFT panel, and the ITE
IT6610 HDMI chip.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 74 ---
1 file changed, 43 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index ad1cec4f2a4d..091e3d3c9027 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -52,7 +52,6 @@ struct ingenic_drm {
struct drm_device drm;
struct drm_plane f0, f1, *ipu_plane;
struct drm_crtc crtc;
- struct drm_encoder encoder;
struct device *dev;
struct regmap *map;
@@ -106,12 +105,6 @@ static inline struct ingenic_drm *drm_crtc_get_priv(struct
drm_crtc *crtc)
return container_of(crtc, struct ingenic_drm, crtc);
}
-static inline struct ingenic_drm *
-drm_encoder_get_priv(struct drm_encoder *encoder)
-{
- return container_of(encoder, struct ingenic_drm, encoder);
-}
-
static void ingenic_drm_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -456,7 +449,7 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
struct drm_crtc_state
*crtc_state,
struct drm_connector_state
*conn_state)
{
- struct ingenic_drm *priv = drm_encoder_get_priv(encoder);
+ struct ingenic_drm *priv = drm_device_get_priv(encoder->dev);
struct drm_display_mode *mode = _state->adjusted_mode;
struct drm_connector *conn = conn_state->connector;
struct drm_display_info *info = >display_info;
@@ -670,9 +663,11 @@ static int ingenic_drm_bind(struct device *dev)
struct clk *parent_clk;
struct drm_bridge *bridge;
struct drm_panel *panel;
+ struct drm_encoder *encoder;
struct drm_device *drm;
void __iomem *base;
long parent_rate;
+ unsigned int i, clone_mask = 0;
int ret, irq;
soc_info = of_device_get_match_data(dev);
@@ -744,17 +739,6 @@ static int ingenic_drm_bind(struct device *dev)
return PTR_ERR(priv->pix_clk);
}
- ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, , );
- if (ret) {
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "Failed to get panel handle");
- return ret;
- }
-
- if (panel)
- bridge = devm_drm_panel_bridge_add_typed(dev, panel,
-
DRM_MODE_CONNECTOR_DPI);
-
priv->dma_hwdesc[0] = dma_alloc_coherent(dev,
sizeof(*priv->dma_hwdesc[0]),
>dma_hwdesc_phys[0],
@@ -821,22 +805,50 @@ static int ingenic_drm_bind(struct device *dev)
}
}
- priv->encoder.possible_crtcs = 1;
+ for (i = 0; ; i++) {
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 0, i,
+ , );
+ if (ret) {
+ if (ret == -ENODEV)
+ break; /* we're done */
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get bridge handle\n");
+ return ret;
+ }
- drm_encoder_helper_add(>encoder,
- _drm_encoder_helper_funcs);
+ if (panel)
+ bridge = devm_drm_panel_bridge_add_typed(dev, panel,
+
DRM_MODE_CONNECTOR_DPI);
- ret = drm_simple_encoder_init(drm, >encoder,
- DRM_MODE_ENCODER_DPI);
- if (ret) {
- dev_err(dev, "Failed to init encoder: %i", ret);
- return ret;
+ encoder = devm_kzalloc(dev, sizeof(*encoder), GFP_KERNEL);
+ if (!encoder)
+ return -ENOMEM;
+
+ encoder->possible_crtcs = 1;
+
+ drm_encoder_helper_add(encoder,
+ _drm_encoder_helper_funcs);
+
+ ret = drm_simple_encoder_init(drm, encoder,
+ DRM_MODE_ENCODER_DPI);
+ if (ret) {
+ dev_err(dev, "Failed to init encoder: %d\n", ret);
+ return ret;
+ }
+
+ ret = drm_bridge_attach(encoder, bridge, NULL, 0);
+ if (ret) {
+ dev_err(dev, "Unable to attach bridge");
+ return ret;
+ }
[PATCH 03/12] component: Support binding with no matches
Support binding the master even though no components have been
registered.
This permits to support cases where components are optional.
Signed-off-by: Paul Cercueil
---
drivers/base/component.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index e97704104784..a9de7ee1677f 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -100,7 +100,7 @@ static int component_devices_show(struct seq_file *s, void
*data)
seq_printf(s, "%-40s %20s\n", "device name", "status");
seq_puts(s,
"-\n");
- for (i = 0; i < match->num; i++) {
+ for (i = 0; !!match && i < match->num; i++) {
struct component *component = match->compare[i].component;
seq_printf(s, "%-40s %20s\n",
@@ -184,6 +184,11 @@ static int find_components(struct master *master)
size_t i;
int ret = 0;
+ if (!match) {
+ dev_dbg(master->dev, "No components\n");
+ return 0;
+ }
+
/*
* Scan the array of match functions and attach
* any components which are found to this master.
@@ -218,10 +223,12 @@ static void remove_component(struct master *master,
struct component *c)
{
size_t i;
- /* Detach the component from this master. */
- for (i = 0; i < master->match->num; i++)
- if (master->match->compare[i].component == c)
- master->match->compare[i].component = NULL;
+ if (master->match) {
+ /* Detach the component from this master. */
+ for (i = 0; i < master->match->num; i++)
+ if (master->match->compare[i].component == c)
+ master->match->compare[i].component = NULL;
+ }
}
/*
@@ -470,10 +477,12 @@ int component_master_add_with_match(struct device *dev,
struct master *master;
int ret;
- /* Reallocate the match array for its true size */
- ret = component_match_realloc(dev, match, match->num);
- if (ret)
- return ret;
+ if (match) {
+ /* Reallocate the match array for its true size */
+ ret = component_match_realloc(dev, match, match->num);
+ if (ret)
+ return ret;
+ }
master = kzalloc(sizeof(*master), GFP_KERNEL);
if (!master)
@@ -557,6 +566,10 @@ void component_unbind_all(struct device *master_dev, void
*data)
if (!master)
return;
+ /* No match, nothing to unbind */
+ if (!master->match)
+ return;
+
/* Unbind components in reverse order */
for (i = master->match->num; i--; )
if (!master->match->compare[i].duplicate) {
@@ -640,6 +653,10 @@ int component_bind_all(struct device *master_dev, void
*data)
if (!master)
return -EINVAL;
+ /* No match, nothing to bind */
+ if (!master->match)
+ return 0;
+
/* Bind components in match order */
for (i = 0; i < master->match->num; i++)
if (!master->match->compare[i].duplicate) {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/12] gpu/drm: Ingenic: Fix opaque pointer casted to wrong type
The opaque pointer passed to the IRQ handler is a pointer to the
drm_device, not a pointer to our ingenic_drm structure.
It still worked, because our ingenic_drm structure contains the
drm_device as its first field, so the pointer received had the same
value, but this was not semantically correct.
Cc: sta...@vger.kernel.org # v5.3
Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs")
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 0c472382a08b..97244462599b 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -476,7 +476,7 @@ static int ingenic_drm_encoder_atomic_check(struct
drm_encoder *encoder,
static irqreturn_t ingenic_drm_irq_handler(int irq, void *arg)
{
- struct ingenic_drm *priv = arg;
+ struct ingenic_drm *priv = drm_device_get_priv(arg);
unsigned int state;
regmap_read(priv->map, JZ_REG_LCD_STATE, );
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/12] gpu/drm: ingenic: Set DMA descriptor chain address in probe
The address of the DMA descriptor never changes. It can therefore be set
in the probe function.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 3207105755c9..e43318938e9e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -358,8 +358,6 @@ static void ingenic_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
ingenic_drm_crtc_update_ctrl(priv, finfo);
clk_set_rate(priv->pix_clk, state->adjusted_mode.clock * 1000);
-
- regmap_write(priv->map, JZ_REG_LCD_DA0, priv->dma_hwdesc->next);
}
if (event) {
@@ -768,6 +766,9 @@ static int ingenic_drm_probe(struct platform_device *pdev)
}
}
+ /* Set address of our DMA descriptor chain */
+ regmap_write(priv->map, JZ_REG_LCD_DA0, priv->dma_hwdesc_phys);
+
ret = drm_dev_register(drm, 0);
if (ret) {
dev_err(dev, "Failed to register DRM driver");
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/12] gpu/drm: Ingenic: Add support for OSD mode
All Ingenic SoCs starting from the JZ4725B support OSD mode.
In this mode, two separate planes can be used. They can have different
positions and sizes, and one can be overlayed on top of the other.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 275 +-
drivers/gpu/drm/ingenic/ingenic-drm.h | 35
2 files changed, 258 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 92c63d1303f9..f139af5b7a40 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -43,12 +43,13 @@ struct ingenic_dma_hwdesc {
struct jz_soc_info {
bool needs_dev_clk;
+ bool has_osd;
unsigned int max_width, max_height;
};
struct ingenic_drm {
struct drm_device drm;
- struct drm_plane primary;
+ struct drm_plane f0, f1;
struct drm_crtc crtc;
struct drm_encoder encoder;
@@ -57,8 +58,8 @@ struct ingenic_drm {
struct clk *lcd_clk, *pix_clk;
const struct jz_soc_info *soc_info;
- struct ingenic_dma_hwdesc *dma_hwdesc;
- dma_addr_t dma_hwdesc_phys;
+ struct ingenic_dma_hwdesc *dma_hwdesc[2];
+ dma_addr_t dma_hwdesc_phys[2];
bool panel_is_sharp;
};
@@ -90,7 +91,7 @@ static const struct regmap_config ingenic_drm_regmap_config =
{
.val_bits = 32,
.reg_stride = 4,
- .max_register = JZ_REG_LCD_CMD1,
+ .max_register = JZ_REG_LCD_SIZE1,
.writeable_reg = ingenic_drm_writeable_reg,
};
@@ -110,11 +111,6 @@ drm_encoder_get_priv(struct drm_encoder *encoder)
return container_of(encoder, struct ingenic_drm, encoder);
}
-static inline struct ingenic_drm *drm_plane_get_priv(struct drm_plane *plane)
-{
- return container_of(plane, struct ingenic_drm, primary);
-}
-
static void ingenic_drm_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -185,34 +181,17 @@ static void ingenic_drm_crtc_update_timings(struct
ingenic_drm *priv,
regmap_write(priv->map, JZ_REG_LCD_SPL, hpe << 16 | (hpe + 1));
regmap_write(priv->map, JZ_REG_LCD_REV, mode->htotal << 16);
}
-}
-
-static void ingenic_drm_crtc_update_ctrl(struct ingenic_drm *priv,
-const struct drm_format_info *finfo)
-{
- unsigned int ctrl = JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16;
-
- switch (finfo->format) {
- case DRM_FORMAT_XRGB1555:
- ctrl |= JZ_LCD_CTRL_RGB555;
- /* fall-through */
- case DRM_FORMAT_RGB565:
- ctrl |= JZ_LCD_CTRL_BPP_15_16;
- break;
- case DRM_FORMAT_XRGB:
- ctrl |= JZ_LCD_CTRL_BPP_18_24;
- break;
- }
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
- JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16 |
- JZ_LCD_CTRL_BPP_MASK, ctrl);
+ JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16,
+ JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16);
}
static int ingenic_drm_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
+ struct drm_plane_state *f1_state, *f0_state;
long rate;
if (!drm_atomic_crtc_needs_modeset(state))
@@ -227,6 +206,17 @@ static int ingenic_drm_crtc_atomic_check(struct drm_crtc
*crtc,
if (rate < 0)
return rate;
+ if (priv->soc_info->has_osd) {
+ f1_state = drm_atomic_get_plane_state(state->state,
+ >f1);
+ f0_state = drm_atomic_get_plane_state(state->state,
+ >f0);
+
+ /* If all the planes are disabled, we won't get a VBLANK IRQ */
+ if (!f1_state->fb && !f0_state->fb)
+ state->no_vblank = true;
+ }
+
return 0;
}
@@ -236,14 +226,9 @@ static void ingenic_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
struct drm_crtc_state *state = crtc->state;
struct drm_pending_vblank_event *event = state->event;
- struct drm_framebuffer *drm_fb = crtc->primary->state->fb;
- const struct drm_format_info *finfo;
if (drm_atomic_crtc_needs_modeset(state)) {
- finfo = drm_format_info(drm_fb->format->format);
-
ingenic_drm_crtc_update_timings(priv, >mode);
- ingenic_drm_crtc_update_ctrl(priv, finfo);
clk_set_rate(priv->pix_clk, state->adjusted_mode.clock * 1000);
}
@@ -260,12 +245,149 @@ static void ingenic_drm_crtc_atomic_flush(struct
drm_crtc *crtc,
}
}
[PATCH 10/12] gpu/drm: Ingenic: Register driver as component master
Register the ingenic-drm driver as a component master.
This will later allow to plug optional components to the driver, for
instance to add support for the IPU, or the SLCD module.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 61 +--
1 file changed, 57 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index f139af5b7a40..b53db3ee001f 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -6,6 +6,7 @@
#include "ingenic-drm.h"
+#include
#include
#include
#include
@@ -613,10 +614,17 @@ static void ingenic_drm_free_dma_hwdesc(void *d)
priv->dma_hwdesc[1], priv->dma_hwdesc_phys[1]);
}
-static int ingenic_drm_probe(struct platform_device *pdev)
+static void ingenic_drm_unbind_all(void *d)
{
+ struct ingenic_drm *priv = d;
+
+ component_unbind_all(priv->dev, >drm);
+}
+
+static int ingenic_drm_bind(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
const struct jz_soc_info *soc_info;
- struct device *dev = >dev;
struct ingenic_drm *priv;
struct clk *parent_clk;
struct drm_bridge *bridge;
@@ -653,6 +661,17 @@ static int ingenic_drm_probe(struct platform_device *pdev)
drm->mode_config.max_height = 4095;
drm->mode_config.funcs = _drm_mode_config_funcs;
+ ret = component_bind_all(dev, drm);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to bind components: %i", ret);
+ return ret;
+ }
+
+ ret = devm_add_action_or_reset(dev, ingenic_drm_unbind_all, priv);
+ if (ret)
+ return ret;
+
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base)) {
dev_err(dev, "Failed to get memory resource");
@@ -843,9 +862,14 @@ static int ingenic_drm_probe(struct platform_device *pdev)
return ret;
}
-static int ingenic_drm_remove(struct platform_device *pdev)
+static int compare_of(struct device *dev, void *data)
+{
+ return dev->of_node == data;
+}
+
+static void ingenic_drm_unbind(struct device *dev)
{
- struct ingenic_drm *priv = platform_get_drvdata(pdev);
+ struct ingenic_drm *priv = dev_get_drvdata(dev);
if (priv->lcd_clk)
clk_disable_unprepare(priv->lcd_clk);
@@ -853,6 +877,35 @@ static int ingenic_drm_remove(struct platform_device *pdev)
drm_dev_unregister(>drm);
drm_atomic_helper_shutdown(>drm);
+}
+
+static const struct component_master_ops ingenic_master_ops = {
+ .bind = ingenic_drm_bind,
+ .unbind = ingenic_drm_unbind,
+};
+
+static int ingenic_drm_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct component_match *match = NULL;
+ struct device_node *np;
+ unsigned int i;
+
+ /* Probe components at port address 8 and upwards */
+ for (i = 8; ; i++) {
+ np = of_graph_get_remote_node(dev->of_node, i, 0);
+ if (!np)
+ break;
+
+ drm_of_component_match_add(dev, , compare_of, np);
+ }
+
+ return component_master_add_with_match(dev, _master_ops, match);
+}
+
+static int ingenic_drm_remove(struct platform_device *pdev)
+{
+ component_master_del(>dev, _master_ops);
return 0;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/12] dt-bindings: display: Add ingenic,ipu.yaml
Add documentation of the Device Tree bindings for the Image Processing
Unit (IPU) found in most Ingenic SoCs.
Signed-off-by: Paul Cercueil
---
.../bindings/display/ingenic,ipu.yaml | 65 +++
1 file changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/ingenic,ipu.yaml
diff --git a/Documentation/devicetree/bindings/display/ingenic,ipu.yaml
b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml
new file mode 100644
index ..22fe02ca866d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ingenic,ipu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ingenic SoCs Image Processing Unit (IPU) devicetree bindings
+
+maintainers:
+ - Paul Cercueil
+
+properties:
+ compatible:
+oneOf:
+ - enum:
+- ingenic,jz4725b-ipu
+- ingenic,jz4760-ipu
+ - items:
+- ingenic,jz4770-ipu
+- ingenic,jz4760-ipu
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: ipu
+
+patternProperties:
+ "^ports?$":
+description: OF graph bindings (specified in bindings/graph.txt).
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+ipu@1308 {
+ compatible = "ingenic,jz4770-ipu", "ingenic,jz4760-ipu";
+ reg = <0x1308 0x800>;
+
+ interrupt-parent = <>;
+ interrupts = <29>;
+
+ clocks = < JZ4770_CLK_IPU>;
+ clock-names = "ipu";
+
+ port {
+ipu_ep: endpoint {
+ remote-endpoint = <_ep>;
+};
+ };
+};
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] drm/tegra: gr3d: Assert reset before power-gating
Tegra TRM documentation states that hardware should be in a default state
when power partition is turned off, i.e. reset should be asserted. This
patch adds the missing reset assertions.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gr3d.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index c0a528be0369..b0b8154e8104 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -381,10 +381,12 @@ static int gr3d_remove(struct platform_device *pdev)
}
if (gr3d->clk_secondary) {
+ reset_control_assert(gr3d->rst_secondary);
tegra_powergate_power_off(TEGRA_POWERGATE_3D1);
clk_disable_unprepare(gr3d->clk_secondary);
}
+ reset_control_assert(gr3d->rst);
tegra_powergate_power_off(TEGRA_POWERGATE_3D);
clk_disable_unprepare(gr3d->clk);
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/12] gpu/drm: Ingenic: Move register definitions to ingenic-drm.h
Move the register definitions to ingenic-drm.h, to keep ingenic-drm.c tidy. Signed-off-by: Paul Cercueil --- drivers/gpu/drm/ingenic/ingenic-drm.c | 116 +-- drivers/gpu/drm/ingenic/ingenic-drm.h | 127 ++ 2 files changed, 129 insertions(+), 114 deletions(-) create mode 100644 drivers/gpu/drm/ingenic/ingenic-drm.h diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c b/drivers/gpu/drm/ingenic/ingenic-drm.c index e43318938e9e..92c63d1303f9 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c @@ -4,6 +4,8 @@ // // Copyright (C) 2019, Paul Cercueil +#include "ingenic-drm.h" + #include #include #include @@ -32,120 +34,6 @@ #include #include -#define JZ_REG_LCD_CFG 0x00 -#define JZ_REG_LCD_VSYNC 0x04 -#define JZ_REG_LCD_HSYNC 0x08 -#define JZ_REG_LCD_VAT 0x0C -#define JZ_REG_LCD_DAH 0x10 -#define JZ_REG_LCD_DAV 0x14 -#define JZ_REG_LCD_PS 0x18 -#define JZ_REG_LCD_CLS 0x1C -#define JZ_REG_LCD_SPL 0x20 -#define JZ_REG_LCD_REV 0x24 -#define JZ_REG_LCD_CTRL0x30 -#define JZ_REG_LCD_STATE 0x34 -#define JZ_REG_LCD_IID 0x38 -#define JZ_REG_LCD_DA0 0x40 -#define JZ_REG_LCD_SA0 0x44 -#define JZ_REG_LCD_FID00x48 -#define JZ_REG_LCD_CMD00x4C -#define JZ_REG_LCD_DA1 0x50 -#define JZ_REG_LCD_SA1 0x54 -#define JZ_REG_LCD_FID10x58 -#define JZ_REG_LCD_CMD10x5C - -#define JZ_LCD_CFG_SLCDBIT(31) -#define JZ_LCD_CFG_PS_DISABLE BIT(23) -#define JZ_LCD_CFG_CLS_DISABLE BIT(22) -#define JZ_LCD_CFG_SPL_DISABLE BIT(21) -#define JZ_LCD_CFG_REV_DISABLE BIT(20) -#define JZ_LCD_CFG_HSYNCM BIT(19) -#define JZ_LCD_CFG_PCLKM BIT(18) -#define JZ_LCD_CFG_INV BIT(17) -#define JZ_LCD_CFG_SYNC_DIRBIT(16) -#define JZ_LCD_CFG_PS_POLARITY BIT(15) -#define JZ_LCD_CFG_CLS_POLARITYBIT(14) -#define JZ_LCD_CFG_SPL_POLARITYBIT(13) -#define JZ_LCD_CFG_REV_POLARITYBIT(12) -#define JZ_LCD_CFG_HSYNC_ACTIVE_LOWBIT(11) -#define JZ_LCD_CFG_PCLK_FALLING_EDGE BIT(10) -#define JZ_LCD_CFG_DE_ACTIVE_LOW BIT(9) -#define JZ_LCD_CFG_VSYNC_ACTIVE_LOWBIT(8) -#define JZ_LCD_CFG_18_BIT BIT(7) -#define JZ_LCD_CFG_PDW (BIT(5) | BIT(4)) - -#define JZ_LCD_CFG_MODE_GENERIC_16BIT 0 -#define JZ_LCD_CFG_MODE_GENERIC_18BIT BIT(7) -#define JZ_LCD_CFG_MODE_GENERIC_24BIT BIT(6) - -#define JZ_LCD_CFG_MODE_SPECIAL_TFT_1 1 -#define JZ_LCD_CFG_MODE_SPECIAL_TFT_2 2 -#define JZ_LCD_CFG_MODE_SPECIAL_TFT_3 3 - -#define JZ_LCD_CFG_MODE_TV_OUT_P 4 -#define JZ_LCD_CFG_MODE_TV_OUT_I 6 - -#define JZ_LCD_CFG_MODE_SINGLE_COLOR_STN 8 -#define JZ_LCD_CFG_MODE_SINGLE_MONOCHROME_STN 9 -#define JZ_LCD_CFG_MODE_DUAL_COLOR_STN 10 -#define JZ_LCD_CFG_MODE_DUAL_MONOCHROME_STN11 - -#define JZ_LCD_CFG_MODE_8BIT_SERIAL12 -#define JZ_LCD_CFG_MODE_LCM13 - -#define JZ_LCD_VSYNC_VPS_OFFSET16 -#define JZ_LCD_VSYNC_VPE_OFFSET0 - -#define JZ_LCD_HSYNC_HPS_OFFSET16 -#define JZ_LCD_HSYNC_HPE_OFFSET0 - -#define JZ_LCD_VAT_HT_OFFSET 16 -#define JZ_LCD_VAT_VT_OFFSET 0 - -#define JZ_LCD_DAH_HDS_OFFSET 16 -#define JZ_LCD_DAH_HDE_OFFSET 0 - -#define JZ_LCD_DAV_VDS_OFFSET 16 -#define JZ_LCD_DAV_VDE_OFFSET 0 - -#define JZ_LCD_CTRL_BURST_4(0x0 << 28) -#define JZ_LCD_CTRL_BURST_8(0x1 << 28) -#define JZ_LCD_CTRL_BURST_16 (0x2 << 28) -#define JZ_LCD_CTRL_RGB555 BIT(27) -#define JZ_LCD_CTRL_OFUP BIT(26) -#define JZ_LCD_CTRL_FRC_GRAYSCALE_16 (0x0 << 24) -#define JZ_LCD_CTRL_FRC_GRAYSCALE_4(0x1 << 24) -#define JZ_LCD_CTRL_FRC_GRAYSCALE_2(0x2 << 24) -#define JZ_LCD_CTRL_PDD_MASK (0xff << 16) -#define JZ_LCD_CTRL_EOF_IRQBIT(13) -#define JZ_LCD_CTRL_SOF_IRQBIT(12) -#define JZ_LCD_CTRL_OFU_IRQBIT(11) -#define
[PATCH v2] drm/exynos: dsi: Remove bridge node reference in error handling path in probe function
'exynos_dsi_parse_dt()' takes a reference to 'dsi->in_bridge_node'.
This must be released in the error handling path.
In order to do that, add an error handling path and move the
'exynos_dsi_parse_dt()' call from the beginning to the end of the probe
function to ease the error handling path.
This function only sets some variables which are used only in the
'transfer' function.
The call chain is:
.transfer
--> exynos_dsi_host_transfer
--> exynos_dsi_init
--> exynos_dsi_enable_clock (use burst_clk_rate and esc_clk_rate)
--> exynos_dsi_set_pll (use pll_clk_rate)
While at it, also handle cases where 'component_add()' fails.
This patch is similar to commit 70505c2ef94b ("drm/exynos: dsi: Remove bridge
node reference in removal")
which fixed the issue in the remove function.
Signed-off-by: Christophe JAILLET
---
A Fixes tag could be required, but I've not been able to figure out which
one to use.
v2: move around 'exynos_dsi_parse_dt' instead of adding many gotos
handle component_add failures
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 902938d2568f..a9d24402fabf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1759,10 +1759,6 @@ static int exynos_dsi_probe(struct platform_device *pdev)
dsi->dev = dev;
dsi->driver_data = of_device_get_match_data(dev);
- ret = exynos_dsi_parse_dt(dsi);
- if (ret)
- return ret;
-
dsi->supplies[0].supply = "vddcore";
dsi->supplies[1].supply = "vddio";
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
@@ -1823,11 +1819,25 @@ static int exynos_dsi_probe(struct platform_device
*pdev)
return ret;
}
+ ret = exynos_dsi_parse_dt(dsi);
+ if (ret)
+ return ret;
+
platform_set_drvdata(pdev, >encoder);
pm_runtime_enable(dev);
- return component_add(dev, _dsi_component_ops);
+ ret = component_add(dev, _dsi_component_ops);
+ if (ret)
+ goto err_disable_runtime;
+
+ return 0;
+
+err_disable_runtime:
+ pm_runtime_disable(dev);
+ of_node_put(dsi->in_bridge_node);
+
+ return ret;
}
static int exynos_dsi_remove(struct platform_device *pdev)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.6 33/50] drm/amdgpu: bump version for invalidate L2 before SDMA IBs
On Thu, May 07, 2020 at 06:11:17PM +0200, Michel Dänzer wrote:
On 2020-05-07 4:27 p.m., Sasha Levin wrote:
From: Marek Olšák
[ Upstream commit 9017a4897a20658f010bebea825262963c10afa6 ]
This fixes GPU hangs due to cache coherency issues.
Bump the driver version. Split out from the original patch.
Signed-off-by: Marek Olšák
Reviewed-by: Christian König
Tested-by: Pierre-Eric Pelloux-Prayer
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 42f4febe24c6d..8d45a2b662aeb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -85,9 +85,10 @@
* - 3.34.0 - Non-DC can flip correctly between buffers with different pitches
* - 3.35.0 - Add drm_amdgpu_info_device::tcc_disabled_mask
* - 3.36.0 - Allow reading more status registers on si/cik
+ * - 3.37.0 - L2 is invalidated before SDMA IBs, needed for correctness
*/
#define KMS_DRIVER_MAJOR 3
-#define KMS_DRIVER_MINOR 36
+#define KMS_DRIVER_MINOR 37
#define KMS_DRIVER_PATCHLEVEL 0
int amdgpu_vram_limit = 0;
This requires the parent commit fdf83646c0542ecfb9adc4db8f741a1f43dca058
"drm/amdgpu: invalidate L2 before SDMA IBs (v2)". KMS_DRIVER_MINOR is
bumped to signal to userspace the fix in that commit is present.
I've grabbed the commit you've pointed out as well as ce73516d42c9
("drm/amdgpu: simplify padding calculations (v2)") to make the backport
apply cleanly, thank you!
--
Thanks,
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm: Help unconfuse gcc, avoid accidental impossible unsigned comparisons
drivers/gpu/drm/drm_client_modeset.c: In function ‘drm_client_firmware_config’:
./include/linux/bits.h:26:28: warning: comparison of unsigned expression < 0 is
always false [-Wtype-limits]
__builtin_constant_p((l) > (h)), (l) > (h), 0)))
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_client_modeset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 7443114bd713..6e9530df0737 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -563,7 +563,7 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
- unsigned int count = min_t(unsigned int, connector_count,
BITS_PER_LONG);
+ const int count = min_t(unsigned int, connector_count, BITS_PER_LONG);
unsigned long conn_configured, conn_seq, mask;
struct drm_device *dev = client->dev;
int i, j;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm: Describe dp_rev for drm_dp_set_phy_test_pattern
drivers/gpu/drm/drm_dp_helper.c:1598: warning: Function parameter or member 'dp_rev' not described in 'drm_dp_set_phy_test_pattern' Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_dp_helper.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 43e57632b00a..532b07118542 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1590,6 +1590,7 @@ EXPORT_SYMBOL(drm_dp_get_phy_test_pattern); * drm_dp_set_phy_test_pattern() - set the pattern to the sink. * @aux: DisplayPort AUX channel * @data: DP phy compliance test parameters. + * @dp_rev: DP revision to use for compliance testing * * Returns 0 on success or a negative error code on failure. */ -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: Include internal header for managed function declarations
drivers/gpu/drm/drm_managed.c:61:6: warning: symbol 'drm_managed_release' was
not declared. Should it be static?
CC drivers/gpu/drm/drm_managed.o
drivers/gpu/drm/drm_managed.c:61:6: warning: no previous prototype for
‘drm_managed_release’ [-Wmissing-prototypes]
void drm_managed_release(struct drm_device *dev)
Fixes: c6603c740e0e ("drm: add managed resources tied to drm_device")
Signed-off-by: Chris Wilson
Cc: Sam Ravnborg
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_managed.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
index 9cebfe370a65..1e1356560c2e 100644
--- a/drivers/gpu/drm/drm_managed.c
+++ b/drivers/gpu/drm/drm_managed.c
@@ -14,6 +14,8 @@
#include
#include
+#include "drm_internal.h"
+
/**
* DOC: managed resources
*
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm: Match drm_dp_send_clear_payload_id_table definition to declaration
drivers/gpu/drm/drm_dp_mst_topology.c:2898:6: warning: symbol
'drm_dp_send_clear_payload_id_table' was not declared. Should it be static?
drivers/gpu/drm/drm_dp_mst_topology.c:5451:37: warning: missing braces around
initializer
drivers/gpu/drm/drm_dp_mst_topology.c:5451:37: warning: missing braces around
initializer
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 70455e304a26..1bdf3cfeeebb 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2895,8 +2895,9 @@ static int drm_dp_send_link_address(struct
drm_dp_mst_topology_mgr *mgr,
return ret < 0 ? ret : changed;
}
-void drm_dp_send_clear_payload_id_table(struct drm_dp_mst_topology_mgr *mgr,
- struct drm_dp_mst_branch *mstb)
+static void
+drm_dp_send_clear_payload_id_table(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb)
{
struct drm_dp_sideband_msg_tx *txmsg;
int ret;
@@ -5448,7 +5449,7 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
drm_dp_mst_port *port)
{
struct drm_dp_mst_port *immediate_upstream_port;
struct drm_dp_mst_port *fec_port;
- struct drm_dp_desc desc = { 0 };
+ struct drm_dp_desc desc = {};
u8 endpoint_fec;
u8 endpoint_dsc;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 13/13] soc: mediatek: cmdq: add set event function
On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> Add set event function in cmdq helper functions to set specific event.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 15 +++
> include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
> include/linux/soc/mediatek/mtk-cmdq.h| 9 +
> 3 files changed, 25 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index ec5637d43254..3294c9285994 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -327,6 +327,21 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> }
> EXPORT_SYMBOL(cmdq_pkt_clear_event);
>
> +int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event)
> +{
> + struct cmdq_instruction inst = { {0} };
> +
> + if (event >= CMDQ_MAX_EVENT)
> + return -EINVAL;
> +
> + inst.op = CMDQ_CODE_WFE;
> + inst.value = CMDQ_WFE_UPDATE | CMDQ_WFE_UPDATE_VALUE;
> + inst.event = event;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_set_event);
> +
> int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value)
> {
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 42d2a30e6a70..ba2d811183a9 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -17,6 +17,7 @@
> #define CMDQ_JUMP_PASS CMDQ_INST_SIZE
>
> #define CMDQ_WFE_UPDATE BIT(31)
> +#define CMDQ_WFE_UPDATE_VALUEBIT(16)
> #define CMDQ_WFE_WAITBIT(15)
> #define CMDQ_WFE_WAIT_VALUE 0x1
>
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index d63749440697..ca70296ae120 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -168,6 +168,15 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool
> clear);
> */
> int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
>
> +/**
> + * cmdq_pkt_set_event() - append set event command to the CMDQ packet
> + * @pkt: the CMDQ packet
> + * @event: the desired event to be set
Can we add the events and their code, so that later on, when a consumer calls
cmdq_pkt_set_event() we don't have any magic values that are hard to understand?
Regards,
Matthias
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event);
> +
> /**
> * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
> *execute an instruction that wait for a specified
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 12/13] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> Add clear parameter to let client decide if
> event should be clear to 0 after GCE receive it.
>
> Signed-off-by: Dennis YC Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
> drivers/soc/mediatek/mtk-cmdq-helper.c | 5 +++--
> include/linux/mailbox/mtk-cmdq-mailbox.h | 3 +--
> include/linux/soc/mediatek/mtk-cmdq.h| 5 +++--
> 4 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 7daaabc26eb1..a065b3a412cf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -488,7 +488,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
> *mtk_crtc)
> if (mtk_crtc->cmdq_client) {
> cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> - cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> + cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
> mtk_crtc_ddp_config(crtc, cmdq_handle);
> cmdq_pkt_finalize(cmdq_handle);
> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
This should be an independent patch
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index bb5be20fc70a..ec5637d43254 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -296,15 +296,16 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16
> high_addr_reg_idx,
> }
> EXPORT_SYMBOL(cmdq_pkt_write_s_value);
>
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
> {
> struct cmdq_instruction inst = { {0} };
> + u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
>
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
>
> inst.op = CMDQ_CODE_WFE;
> - inst.value = CMDQ_WFE_OPTION;
> + inst.value = CMDQ_WFE_OPTION | clear_option;
> inst.event = event;
>
> return cmdq_pkt_append_command(pkt, inst);
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 3f6bc0dfd5da..42d2a30e6a70 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -27,8 +27,7 @@
> * bit 16-27: update value
> * bit 31: 1 - update, 0 - no update
> */
> -#define CMDQ_WFE_OPTION (CMDQ_WFE_UPDATE |
> CMDQ_WFE_WAIT | \
> - CMDQ_WFE_WAIT_VALUE)
> +#define CMDQ_WFE_OPTION (CMDQ_WFE_WAIT |
> CMDQ_WFE_WAIT_VALUE)
>
> /** cmdq event maximum */
> #define CMDQ_MAX_EVENT 0x3ff
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 1a6c56f3bec1..d63749440697 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -152,11 +152,12 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16
> high_addr_reg_idx,
> /**
> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> * @pkt: the CMDQ packet
> - * @event: the desired event type to "wait and CLEAR"
> + * @event: the desired event type to wait
> + * @clear: clear event or not after event arrive
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
>
> /**
> * cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 10/13] soc: mediatek: cmdq: export finalize function
On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> Export finalize function to client which helps append eoc and jump
> command to pkt. Let client decide call finalize or not.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
> drivers/soc/mediatek/mtk-cmdq-helper.c | 7 ++-
> include/linux/soc/mediatek/mtk-cmdq.h | 8
> 3 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 0dfcd1787e65..7daaabc26eb1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
> *mtk_crtc)
> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> mtk_crtc_ddp_config(crtc, cmdq_handle);
> + cmdq_pkt_finalize(cmdq_handle);
> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> }
> #endif
This should be a independent patch.
Other then that patch looks good.
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index a9ebbabb7439..59bc1164b411 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -372,7 +372,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx,
> u32 value)
> }
> EXPORT_SYMBOL(cmdq_pkt_assign);
>
> -static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> {
> struct cmdq_instruction inst = { {0} };
> int err;
> @@ -392,6 +392,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>
> return err;
> }
> +EXPORT_SYMBOL(cmdq_pkt_finalize);
>
> static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
> {
> @@ -426,10 +427,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt,
> cmdq_async_flush_cb cb,
> unsigned long flags = 0;
> struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
>
> - err = cmdq_pkt_finalize(pkt);
> - if (err < 0)
> - return err;
> -
> pkt->cb.cb = cb;
> pkt->cb.data = data;
> pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index fec292aac83c..99e77155f967 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -213,6 +213,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
> */
> int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
>
> +/**
> + * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
> + * @pkt: the CMDQ packet
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
> +
> /**
> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> * packet and call back at the end of done packet
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 09/13] soc: mediatek: cmdq: add write_s value function
On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> add write_s function in cmdq helper functions which
> writes a constant value to address with large dma
> access support.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 26 ++
> include/linux/soc/mediatek/mtk-cmdq.h | 14 ++
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 03c129230cd7..a9ebbabb7439 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -269,6 +269,32 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16
> high_addr_reg_idx,
> }
> EXPORT_SYMBOL(cmdq_pkt_write_s);
>
> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> +u16 addr_low, u32 value, u32 mask)
> +{
> + struct cmdq_instruction inst = { {0} };
> + int err;
> +
> + if (mask != U32_MAX) {
> + inst.op = CMDQ_CODE_MASK;
> + inst.mask = ~mask;
> + err = cmdq_pkt_append_command(pkt, inst);
> + if (err < 0)
> + return err;
> +
> + inst.op = CMDQ_CODE_WRITE_S_MASK;
> + } else {
> + inst.op = CMDQ_CODE_WRITE_S;
> + }
> +
> + inst.sop = high_addr_reg_idx;
Writing u16 value in a 5 bit wide variable?
> + inst.offset = addr_low;
> + inst.value = value;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_write_s_value);
> +
> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> {
> struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 01b4184af310..fec292aac83c 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -135,6 +135,20 @@ int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16
> high_addr_reg_idx, u16 addr_low,
> int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>u16 addr_low, u16 src_reg_idx, u32 mask);
>
> +/**
> + * cmdq_pkt_write_s_value() - append write_s command with mask to the CMDQ
> + * packet which write value to a physical address
> + * @pkt: the CMDQ packet
> + * @high_addr_reg_idx: internal regisger ID which contains high
> address of pa
register
> + * @addr_low:low address of pa
> + * @value: the specified target value
> + * @mask:the specified target mask
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> +u16 addr_low, u32 value, u32 mask);
> +
> /**
> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> * @pkt: the CMDQ packet
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/13] soc: mediatek: cmdq: add write_s function
On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> add write_s function in cmdq helper functions which
> writes value contains in internal register to address
> with large dma access support.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 34 +++-
> include/linux/mailbox/mtk-cmdq-mailbox.h | 2 ++
> include/linux/soc/mediatek/mtk-cmdq.h| 20 ++
> 3 files changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 33153d17c9d9..90f1ff2b4b00 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -18,6 +18,10 @@ struct cmdq_instruction {
> union {
> u32 value;
> u32 mask;
> + struct {
> + u16 arg_c;
> + u16 src_reg;
> + };
> };
> union {
> u16 offset;
> @@ -29,7 +33,7 @@ struct cmdq_instruction {
> struct {
> u8 sop:5;
> u8 arg_c_t:1;
> - u8 arg_b_t:1;
> + u8 src_t:1;
fixing patch 6/13 please. seems the struct should be added in this patch.
> u8 dst_t:1;
> };
> };
> @@ -222,6 +226,34 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> }
> EXPORT_SYMBOL(cmdq_pkt_write_mask);
>
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> + u16 addr_low, u16 src_reg_idx, u32 mask)
> +{
> + struct cmdq_instruction inst = { {0} };
> + int err;
> +
> + if (mask != U32_MAX) {
> + inst.op = CMDQ_CODE_MASK;
> + inst.mask = ~mask;
> + err = cmdq_pkt_append_command(pkt, inst);
> + if (err < 0)
> + return err;
> +
> + inst.mask = 0;
> + inst.op = CMDQ_CODE_WRITE_S_MASK;
> + } else {
> + inst.op = CMDQ_CODE_WRITE_S;
> + }
> +
> + inst.src_t = CMDQ_REG_TYPE;
Not defined.
Please make sure that every patch compiles on it's own and does not add a
regression. This is very helpful if we have to bisect the kernel in the future.
> + inst.sop = high_addr_reg_idx;
> + inst.offset = addr_low;
> + inst.src_reg = src_reg_idx;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_write_s);
> +
> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> {
> struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 121c3bb6d3de..8ef87e1bd03b 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -59,6 +59,8 @@ enum cmdq_code {
> CMDQ_CODE_JUMP = 0x10,
> CMDQ_CODE_WFE = 0x20,
> CMDQ_CODE_EOC = 0x40,
> + CMDQ_CODE_WRITE_S = 0x90,
> + CMDQ_CODE_WRITE_S_MASK = 0x91,
> CMDQ_CODE_LOGIC = 0xa0,
> };
>
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 83340211e1d3..c72d826d8934 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -12,6 +12,8 @@
> #include
>
> #define CMDQ_NO_TIMEOUT 0xu
> +#define CMDQ_ADDR_HIGH(addr) ((u32)(((addr) >> 16) & GENMASK(31, 0)))
> +#define CMDQ_ADDR_LOW(addr) ((u16)(addr) | BIT(1))
>
> struct cmdq_pkt;
>
> @@ -102,6 +104,24 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16
> offset, u32 value);
> int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value, u32 mask);
>
> +/**
> + * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
> + * @pkt: the CMDQ packet
> + * @high_addr_reg_idx: internal regisger ID which contains high
> address of pa
s/regisger/register
> + * @addr_low:low address of pa
> + * @src_reg_idx: the CMDQ internal register ID which cache source value
> + * @mask:the specified target address mask, use U32_MAX if no need
> + *
> + * Return: 0 for success; else the error code is returned
> + *
> + * Support write value to physical address without subsys. Use
> CMDQ_ADDR_HIGH()
> + * to get high addrees and call cmdq_pkt_assign() to assign value into
> internal
s/addrees/address
> + * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low
> parameterwhen
s/parameterwhen/parameter when
> + * call to this function.
> + */
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> + u16 addr_low, u16 src_reg_idx, u32 mask);
> +
In general I wonder if we shouldn't provide two functions, one that writes a
mask and on for the else case.
Regards,
Matthias
> /**
> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> * @pkt:
Re: [PATCH v5 06/13] soc: mediatek: cmdq: add assign function
On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> Add assign function in cmdq helper which assign constant value into
> internal register by index.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 24 +++-
> include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
> include/linux/soc/mediatek/mtk-cmdq.h| 14 ++
> 3 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 98f23ba3ba47..33153d17c9d9 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -12,6 +12,7 @@
> #define CMDQ_WRITE_ENABLE_MASK BIT(0)
> #define CMDQ_POLL_ENABLE_MASKBIT(0)
> #define CMDQ_EOC_IRQ_EN BIT(0)
> +#define CMDQ_REG_TYPE1
>
> struct cmdq_instruction {
> union {
> @@ -21,8 +22,17 @@ struct cmdq_instruction {
> union {
> u16 offset;
> u16 event;
> + u16 reg_dst;
> + };
> + union {
> + u8 subsys;
> + struct {
> + u8 sop:5;
> + u8 arg_c_t:1;
> + u8 arg_b_t:1;
> + u8 dst_t:1;
> + };
This union seems without context in this patch. Please drop.
Regards,
Matthias
> };
> - u8 subsys;
> u8 op;
> };
>
> @@ -277,6 +287,18 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
> }
> EXPORT_SYMBOL(cmdq_pkt_poll_mask);
>
> +int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
> +{
> + struct cmdq_instruction inst = { {0} };
> +
> + inst.op = CMDQ_CODE_LOGIC;
> + inst.dst_t = CMDQ_REG_TYPE;
> + inst.reg_dst = reg_idx;
> + inst.value = value;
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_assign);
> +
> static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> {
> struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index dfe5b2eb85cc..121c3bb6d3de 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -59,6 +59,7 @@ enum cmdq_code {
> CMDQ_CODE_JUMP = 0x10,
> CMDQ_CODE_WFE = 0x20,
> CMDQ_CODE_EOC = 0x40,
> + CMDQ_CODE_LOGIC = 0xa0,
> };
>
> enum cmdq_cb_status {
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index a74c1d5acdf3..83340211e1d3 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -152,6 +152,20 @@ int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> */
> int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value, u32 mask);
> +
> +/**
> + * cmdq_pkt_assign() - Append logic assign command to the CMDQ packet, ask
> GCE
> + * to execute an instruction that set a constant value into
> + * internal register and use as value, mask or address in
> + * read/write instruction.
> + * @pkt: the CMDQ packet
> + * @reg_idx: the CMDQ internal register ID
> + * @value: the specified value
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
> +
> /**
> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> * packet and call back at the end of done packet
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 05/13] soc: mediatek: cmdq: return send msg error code
On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> Return error code to client if send message fail,
> so that client has chance to error handling.
>
> Signed-off-by: Dennis YC Hsieh
> Fixes: 576f1b4bc802 ("soc: mediatek: Add Mediatek CMDQ helper")
> Reviewed-by: CK Hu
Queued for v5.7-fixes
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 2e1bc513569b..98f23ba3ba47 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -351,7 +351,9 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt,
> cmdq_async_flush_cb cb,
> spin_unlock_irqrestore(>lock, flags);
> }
>
> - mbox_send_message(client->chan, pkt);
> + err = mbox_send_message(client->chan, pkt);
> + if (err < 0)
> + return err;
> /* We can send next packet immediately, so just call txdone. */
> mbox_client_txdone(client->chan, 0);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)
On Friday 15. May 2020 09.43.54 Neil Armstrong wrote: > > On 15/05/2020 00:04, Paul Boddie wrote: > > > > WARNING: CPU: 1 PID: 396 at drivers/gpu/drm/drm_atomic_helper.c:1457 > > drm_atomic_helper_wait_for_vblanks+0x1ec/0x25c > > [CRTC:32:crtc-0] vblank wait timed out > > This means the CRTC didn't start, usually because the Pixel clock didn't go > through the pipeline to the pixel generator, thus not generating > vblank/vsync interrupts. > > You may check if there is not muxes to select the clock source/pixel > destination. I have taken a look at the clocks to see what they get initialised to. Here are the details of the LCD controller clocks from this experiment as reported by /sys/kernel/debug/clk/clk_summary: lcd 1104800 tve1104800 vpll 222 88800 hdmi 11026909090 lcd1pixclk 000 88800 lcd0pixclk 1109866 >From the 3.18 vendor kernel: lcd 114800 tve114800 vpll 22 88800 hdmi 1126909090 lcd1pixclk 00 88800 lcd0pixclk 11 11100 (The 3.18 output lacks the "protect count" value.) Here, the only obvious difference is a slower pixel clock in the experimental system: 98.7MHz versus 111MHz. [...] > Perfect, EDID reading works fine. We're fairly confident about this now, at least. ;-) For the record, the Synopsys peripheral's own I2C support seems far preferable to Ingenic's own I2C peripherals and was a nice discovery amongst the bridge driver's capabilities. [...] > > Attempting to set a mode using... > > > > modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02 > > > > ...yields the following: > > > > failed to set mode: Permission denied > > setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32 > > This is weird, the command line is ok, is it the same for all modes ? Yes. Permission denied for all that I have tried. [...] > >>> But if you have "Input not supported" on your monitor, this means you > >>> have TMDS going out on your hardware, which is good, this means all the > >>> power/reset/system clocks are ok. > >>> This could mean you have a timing/clock issue, please check if something > >>> is not done on the pixel clock before going to the dw-hdmi block. > > Replying to your previous email concerning the bus formats, yeah should > probably look at the bus format configured, because if you have a DDR bus > format, the clock will be half and thus won't work. I can easily imagine that I am missing something with regard to bus formats and flags. However, I reviewed differences between drivers and found a few more things that are not done in the ingenic-drm driver, mostly because they won't be needed by other SoCs or aren't even supported by them. Some of these things are not so easy to explain, but maybe they sound familiar to someone. The 3.18 kernel driver sets up two DMA descriptors, rather than the usual one that would be sufficient, and it enables 8-word descriptors that seem to use on-screen display functionality in their additional 4 words. The programming manual doesn't say anything obvious about this, but it did make me wonder whether this extra functionality might need to be enabled in order to activate the HDMI output. All it seems to do is to make a foreground layer equivalent to the size of the framebuffer. (With the above noted, the 3.18 kernel doesn't obviously activate the on- screen display support using the "OSD configure" register, although the vendor 3.0.8 kernel does, alongside much else.) There are some registers used that are probably not available on other SoCs in the family. An RGB control register sets up RGB output and odd/even line formats. A "priority level threshold configure" register seems to be used for some kind of bus arbitration. Again, I can imagine that the pipeline to the HDMI peripheral may need a specific configuration, but I haven't found an explanation yet. I have tried to introduce these extra measures in a fairly sensible way to the ingenic-drm driver, but no further progress has been made so far. Thanks once again for comments and suggestions! Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 03/13] mailbox: cmdq: support mt6779 gce platform definition
On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> Add gce v4 hardware support with different thread number and shift.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
Reviewed-by: Matthias Brugger
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 4dbee9258127..9994ac9426d6 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -572,10 +572,12 @@ static const struct dev_pm_ops cmdq_pm_ops = {
>
> static const struct gce_plat gce_plat_v2 = {.thread_nr = 16};
> static const struct gce_plat gce_plat_v3 = {.thread_nr = 24};
> +static const struct gce_plat gce_plat_v4 = {.thread_nr = 24, .shift = 3};
>
> static const struct of_device_id cmdq_of_ids[] = {
> {.compatible = "mediatek,mt8173-gce", .data = (void *)_plat_v2},
> {.compatible = "mediatek,mt8183-gce", .data = (void *)_plat_v3},
> + {.compatible = "mediatek,mt6779-gce", .data = (void *)_plat_v4},
> {}
> };
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 37/38] drm/xen: remove _unlocked suffix in drm_object_put_unlocked
On 5/15/20 12:51 PM, Emil Velikov wrote:
> From: Emil Velikov
>
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
>
> Just drop the suffix. It makes the API cleaner.
>
> Done via the following script:
>
> __from=drm_gem_object_put_unlocked
> __to=drm_gem_object_put
> for __file in $(git grep --name-only $__from); do
>sed -i "s/$__from/$__to/g" $__file;
> done
>
> Cc: Oleksandr Andrushchenko
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
> Acked-by: Sam Ravnborg
Acked-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/xen_drm_front.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
> b/drivers/gpu/drm/xen/xen_drm_front.c
> index 1fd458e877ca..3e660fb111b3 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> @@ -419,7 +419,7 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
> goto fail_handle;
>
> /* Drop reference from allocate - handle holds it now */
> - drm_gem_object_put_unlocked(obj);
> + drm_gem_object_put(obj);
> return 0;
>
> fail_handle:
> @@ -427,7 +427,7 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
> xen_drm_front_dbuf_to_cookie(obj));
> fail_backend:
> /* drop reference from allocate */
> - drm_gem_object_put_unlocked(obj);
> + drm_gem_object_put(obj);
> fail:
> DRM_ERROR("Failed to create dumb buffer: %d\n", ret);
> return ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月15日 週五 上午1:35寫道：
>
> Hi again,
>
> On 14/5/20 19:12, Enric Balletbo i Serra wrote:
> > Hi Chun-Kuang,
> >
> > On 14/5/20 18:44, Chun-Kuang Hu wrote:
> >> Hi, Enric:
> >>
> >> Enric Balletbo i Serra 於 2020年5月14日 週四
> >> 下午11:42寫道：
> >>>
> >>> Hi Chun-Kuang,
> >>>
> >>> On 14/5/20 16:28, Chun-Kuang Hu wrote:
> Hi, Enric:
>
> Enric Balletbo Serra 於 2020年5月14日 週四 上午12:41寫道：
> >
> > Hi Chun-Kuang,
> >
> > Missatge de Enric Balletbo i Serra del
> > dia dv., 1 de maig 2020 a les 17:25:
> >>
> >> Use the drm_bridge_connector helper to create a connector for pipelines
> >> that use drm_bridge. This allows splitting connector operations across
> >> multiple bridges when necessary, instead of having the last bridge in
> >> the chain creating the connector and handling all connector operations
> >> internally.
> >>
> >> Signed-off-by: Enric Balletbo i Serra
> >> Acked-by: Sam Ravnborg
> >
> > A gentle ping on this, I think that this one is the only one that
> > still needs a review in the series.
>
> This is what I reply in patch v3:
>
> >>>
> >>> Sorry for missing this.
> >>>
> I think the panel is wrapped into next_bridge here,
>
> >>>
> >>> Yes, you can have for example:
> >>>
> >>> 1. drm_bridge (mtk_dsi) -> drm_bridge (ps8640 - dsi-to-edp) ->
> >>> drm_panel_bridge
> >>> (edp panel)
> >>>
> >>> or a
> >>>
> >>> 2. drm_bridge (mtk_dsi)-> drm_panel_bridge (dsi panel)
> >>>
> >>> The _first_ one is my use case
> >>>
> if (panel) {
> >>>
> >>> This handles the second case, where you attach a dsi panel.
> >>>
> dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
>
> so the next_bridge is a panel_bridge, in its attach function
> panel_bridge_attach(),
> according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
> it would create connector and attach connector to panel.
>
> I'm not sure this flag would exist or not, but for both case, it's
> strange.
> If exist, you create connector in this patch but no where to attach
> connector to panel.
> >>>
> >>> Yes, in fact, this is transitional patch needed, as once I converted
> >>> mtk_dpi,
> >>> mtk_dsi and mtk_hdmi to the new drm_bridge API the
> >>> drm_bridge_connector_init()
> >>> will be done in mtk_drm_drv. We will need to call
> >>> drm_bridge_connector_init for
> >>> dpi and dsi pipes and remove that call from mtk_dsi and mtk_dpi drivers.
> >>> The
> >>> graphic controller driver should create connectors and CRTCs, as example
> >>> you can
> >>> take a look at drivers/gpu/drm/omapdrm/omap_drv.c
> >>>
> >>
> >> I have such question because I've reviewed omap's driver. In omap's
> >> driver, after it call drm_bridge_connector_init(), it does this:
> >>
> >> if (pipe->output->panel) {
> >> ret = drm_panel_attach(pipe->output->panel,
> >> pipe->connector);
> >> if (ret < 0)
> >> return ret;
> >> }
> >>
> >> In this patch, you does not do this.
> >>
> >
> > I see, so yes, I am probably missing call drm_panel_attach in case there is
> > a
> > direct panel attached. Thanks for pointing it.
> >
> > I'll send a new version adding the drm_panel_attach call.
> >
>
> Wait, shouldn't panel be attached on the call of mtk_dsi_bridge_attach as
> next_bridge points to a bridge or a panel?
>
> static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
> enum drm_bridge_attach_flags flags)
> {
> struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> /* Attach the panel or bridge to the dsi bridge */
> return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
> >bridge, flags);
> }
>
> Or I am continuing misunderstanding all this?
>
My point is: when do you attach panel to a connector?
In this patch,
ret = drm_bridge_attach(>encoder, >bridge, NULL,
DRM_BRIDGE_ATTACH_NO_CONNECTOR);
it would call into mtk_dsi_bridge_attach() with
DRM_BRIDGE_ATTACH_NO_CONNECTOR, and call into panel_bridge_attach()
with DRM_BRIDGE_ATTACH_NO_CONNECTOR.
If you does not pass DRM_BRIDGE_ATTACH_NO_CONNECTOR into
panel_bridge_attach(), it would create a connector and attach panel to
that connector.
And you pass DRM_BRIDGE_ATTACH_NO_CONNECTOR into
panel_bridge_attach(), so I thiink you need to create connector and
attach panel to that connector by yourself (this is what omap does).
Regards,
Chun-Kuang.
> If not exist, the next_brige would create one connector and this brige
> would create another connector.
>
> I think in your case, mtk_dsi does not directly connect to a panel, so
> >>>
> >>> Exactly
> >>>
> I need a exact explain. Or someone could test this on a
> directly-connect-panel platform.
> >>>
> >>> I don't think I am breaking this use case but AFAICS there is no users in
> >>> mainline that
Re: [PATCH v7 01/12] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
Hi Tony, > Am 03.05.2020 um 17:01 schrieb Tony Lindgren : > > * Paul Cercueil [200503 14:19]: >> You have a new SoC with a SGX, and you only need to enable one clock to get >> it to work. So you create a devicetree node which receives only one clock. >> >> Turns out, that the bootloader was enabling the other 3 clocks, and since >> the last release, it doesn't anymore. You're left with having to support a >> broken devicetree. >> >> That's the kind of problem that can be easily avoided by enforcing the >> number of clocks that have to be provided. > > The number of clocks depends on how it's wired for the SoC. > > On omaps, there's are no controls for additinoal SGX clocks. Sure some > of the clocks may be routed to multple places internally by the wrapper > module. But we have no control over that. > > If we wanted to specify just the "fck" clock on omaps, then we can > do it with something like this: > > allOf: > - if: >properites: > compatible: >enum: > - "ti,omap4-sgx544-112" > - "ti,omap5-sgx544-116" > - "ti,dra7-sgx544-116" >then: > properties: >clocks: > minItems: 1 > maxItems: 1 > >clock-names: > const: fck > >required: > - clocks > - clock-names will add to v8 of this series as a separate patch on top of the general one. This should make it easier to have a focussed discussion and revert/bisect if something goes wrong. BR and thanks, Nikolaus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 01/12] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
> Am 05.05.2020 um 17:53 schrieb Rob Herring : > > On Fri, Apr 24, 2020 at 10:34:04PM +0200, H. Nikolaus Schaller wrote: >> The Imagination PVR/SGX GPU is part of several SoC from >> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo, >> Allwinner A83 and others. >> >> With this binding, we describe how the SGX processor is >> interfaced to the SoC (registers and interrupt). >> >> The interface also consists of clocks, reset, power but >> information from data sheets is vague and some SoC integrators >> (TI) deciced to use a PRCM wrapper (ti,sysc) which does >> all clock, reset and power-management through registers >> outside of the sgx register block. >> >> Therefore all these properties are optional. >> >> Tested by make dt_binding_check >> >> Signed-off-by: H. Nikolaus Schaller >> --- >> .../devicetree/bindings/gpu/img,pvrsgx.yaml | 150 ++ >> 1 file changed, 150 insertions(+) >> +oneOf: >> + - description: SGX530-121 based SoC >> +items: >> + - enum: >> +- ti,omap3-sgx530-121 # BeagleBoard A/B/C, OpenPandora 600MHz >> and similar > > Should be indented 2 more here and elsewhere where you have a list > under a list. added for patch v8 series. BR and thanks, Nikolaus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Mark check_shadow_context_ppgtt as maybe unused
When CONFIG_DRM_I915_DEBUG_GEM is not set, clang warns:
drivers/gpu/drm/i915/gvt/scheduler.c:884:1: warning: function
'check_shadow_context_ppgtt' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
check_shadow_context_ppgtt(struct execlist_ring_context *c, struct
intel_vgpu_mm *m)
^
1 warning generated.
This warning is similar to -Wunused-function but rather than warning
that the function is completely unused, it warns that it is used in some
expression within the file but that expression will be evaluated to a
constant or be optimized away in the final assembly, essentially making
it appeared used but really isn't. Usually, this happens when a function
or variable is only used in sizeof, where it will appear to be used but
will be evaluated at compile time and not be required to be emitted.
In this case, the function is only used in GEM_BUG_ON, which is defined
as BUILD_BUG_ON_INVALID, which intentionally follows this pattern. To
fix this warning, add __maybe_unused to make it clear that this is
intentional depending on the configuration.
Fixes: bec3df930fbd ("drm/i915/gvt: Support PPGTT table load command")
Link: https://github.com/ClangBuiltLinux/linux/issues/1027
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f776c92de8d7..0fb1df71c637 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -880,7 +880,7 @@ static void update_guest_pdps(struct intel_vgpu *vgpu,
gpa + i * 8, [7 - i], 4);
}
-static bool
+static __maybe_unused bool
check_shadow_context_ppgtt(struct execlist_ring_context *c, struct
intel_vgpu_mm *m)
{
if (m->ppgtt_mm.root_entry_type == GTT_TYPE_PPGTT_ROOT_L4_ENTRY) {
base-commit: bdecf38f228bcca73b31ada98b5b7ba1215eb9c9
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linux-stm32] [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
On 5/15/20 11:24 AM, dillon min wrote:
> Hi Benjamin,
>
> thanks for reply.
>
> On Fri, May 15, 2020 at 4:31 PM Benjamin GAIGNARD
> wrote:
>>
>>
>> On 5/14/20 3:07 PM, dillon min wrote:
>>> Hi Alexandre,
>>>
>>> On Thu, May 14, 2020 at 8:53 PM Alexandre Torgue
>>> wrote:
On 5/14/20 10:24 AM, Linus Walleij wrote:
> On Tue, May 12, 2020 at 9:04 AM wrote:
>
>> From: dillon min
>>
>> Enable the ltdc & ili9341 on stm32429-disco board.
>>
>> Signed-off-by: dillon min
> This mostly looks good but...
>
>> + {
>> + status = "okay";
>> + pinctrl-0 = <_pins>;
>> + pinctrl-names = "default";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + cs-gpios = < 2 GPIO_ACTIVE_LOW>;
>> + dmas = < 3 2 0x400 0x0>,
>> + < 4 2 0x400 0x0>;
>> + dma-names = "rx", "tx";
> These DMA assignments seem to be SoC things and should
> rather be in the DTS(I) file where is defined, right?
> stm32f429.dtsi I suppose?
I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
doesn't want to use it, we use the "delete-property".
>>> Yes, will move to Soc dtsi in next submits.
>>>
>>> i'm working on write a v4l2-m2m driver for dma2d of stm32 to support
>>> pixel conversion
>>> alpha blending between foreground and background graphics.
>>>
>>> as you know, some soc's engineer trying to add this function to drm system.
>>>
>>> do you know st's planning about soc's hardware accelerator driver on
>>> stm32mp?
>>> such as chrom-art, will add to drm subsystem via ioctl to access, or to
>>> v4l2,
>> On stm32mp we do not plan to use chrom-art in drm or v4l2 because it
>> does fit
>> with userland way of working. We use the GPU to do conversion, scaling,
>> blending
>> and composition in only one go.
>> As explain here [1] DRM subsytem it isn't a solution and v4l2-m2m isn't
>> used in any
>> mainline compositors like Weston or android surfaceflinger.
>>
>> Benjamin
>>
> After check stm32mp's datasheets, they don't have chrom-art ip inside. sorry
> for
> didn't check it yet.
>
> for stm32h7 series with chrom-art, jpeg hardware accelerator inside.
> does st has plan to
> setup a driver to support it ? i prefer v4l2-m2m should be easier to
> implement it.
> co work with dcmi, fbdev.
ST doesn't plan to create a driver for chrom-art because nothing in
mainline
userland could use it.
Benjamin
>
> thanks.
>
> best regards.
>
> Dillon
>> [1]
>> https://www.phoronix.com/scan.php?page=news_item=Linux-DRM-No-2D-Accel-API
>>> thanks.
>>>
> It is likely the same no matter which device is using spi5.
>
> Yours,
> Linus Walleij
>
>>> ___
>>> Linux-stm32 mailing list
>>> linux-st...@st-md-mailman.stormreply.com
>>> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources
> > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
> > + vgdev->has_resource_assign_uuid = true;
> > + }
>
>
> Just a question: this relies on DMA bufs so I assume it is
> not really assumed to work when DMA API is bypassed, right?
> Rather than worry what does it mean, how about just
> disabling this feature without PLATFORM_DMA for now?
By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? Virtio-gpu
depends on DRM, which selects that feature. So I think DMA bufs should
always be available when virtio-gpu is present.
-David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 20/91] clk: bcm: rpi: Discover the firmware clocks
Hi Nicolas,
On Mon, May 04, 2020 at 02:05:47PM +0200, Nicolas Saenz Julienne wrote:
> Hi Maxime, as always, thanks for the series!
> Some extra context, and comments below.
>
> On Fri, 2020-04-24 at 17:34 +0200, Maxime Ripard wrote:
> > The RaspberryPi4 firmware actually exposes more clocks than are currently
> > handled by the driver and we will need to change some of them directly
> > based on the pixel rate for the display related clocks, or the load for the
> > GPU.
> >
> > This rate change can have a number of side-effects, including adjusting the
> > various PLL voltages or the PLL parents. The firmware will also update
> > those clocks by itself for example if the SoC runs too hot.
>
> To complete this:
>
> RPi4's firmware implements DVFS. Clock frequency and SoC voltage are
> correlated, if you can determine all clocks are running below a maximum then
> it
> should be safe to lower the voltage. Currently, firmware actively monitors
> arm,
> core, h264, v3d, isp and hevc to determine what voltage can be reduced to, and
> if arm increases any of those clocks behind the firmware's back, when it has a
> lowered voltage, a crash is highly likely.
>
> As pointed out to me by RPi foundation engineers hsm/pixel aren't currently
> being monitored, as driving a high resolution display also requires a high
> core
> clock, which already sets an acceptable min voltage threshold. But that might
> change if needed.
>
> Ultimately, from the DVFS, the safe way to change clocks from arm would be to
> always use the firmware interface, which we're far from doing right now. On
> the
> other hand, AFAIK not all clocks have a firmware counterpart.
>
> Note that we could also have a word with the RPi foundation and see if
> disabling DVFS is possible (AFAIK it's not an option right now). Although I
> personally prefer to support this upstream, aside from the obvious benefits to
> battery powered use cases, not consuming power unnecessarily is always big
> plus.
>
> > In order to make Linux play as nice as possible with those constraints, it
> > makes sense to rely on the firmware clocks as much as possible.
>
> As I comment above, not as simple as it seems. I suggest, for now, we only
> register the clocks we're going to use and that are likely to be affected by
> DVFS. hsm being a contender here.
>
> As we'd be settling on a hybrid solution here, which isn't ideal to say the
> least, I'd like to gather some opinions on whether pushing towards a fully
> firmware based solution is something you'd like to see.
Thanks for the summary above, I'll try to adjust that commit log to reflect
this. As for my opinion, I don't really think that an hybrid approach is
practical, since that would leave us with weird interactions between the
firmware (and possibly multiple versinos of it) and the linux driver, and this
would be pretty hard to maintain in the long run.
That leaves us either the MMIO-based driver or the firmware-based one, and here
with what you said above, at the moment, the firmware based one is a clear
winner.
> > Fortunately,t he firmware has an interface to discover the clocks it
> > exposes.
>
> nit: wrongly placed space
>
> > Let's use it to discover, register the clocks in the clocks framework and
> > then expose them through the device tree for consumers to use them.
> >
> > Cc: Michael Turquette
> > Cc: Stephen Boyd
> > Cc: linux-...@vger.kernel.org
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/clk/bcm/clk-raspberrypi.c | 104 +++---
>
> [...]
>
> > +static struct clk_hw *raspberrypi_clk_register(struct raspberrypi_clk *rpi,
> > + unsigned int parent,
> > + unsigned int id)
> > +{
> > + struct raspberrypi_clk_data *data;
> > + struct clk_init_data init = {};
> > + int ret;
> > +
> > + if (id == RPI_FIRMWARE_ARM_CLK_ID) {
> > + struct clk_hw *hw;
> > +
> > + hw = raspberrypi_register_pllb(rpi);
> > + if (IS_ERR(hw)) {
> > + dev_err(rpi->dev, "Failed to initialize pllb, %ld\n",
> > + PTR_ERR(hw));
> > + return hw;
> > + }
> > +
> > + return raspberrypi_register_pllb_arm(rpi);
> > + }
>
> We shouldn't create a special case for pllb. My suggestion here is that we
> revert the commit that removed pllb from the mmio driver, in order to maintain
> a nice view of the clock tree, and register this as a regular fw-clk.
>
> The only user to this is RPi's the cpufreq driver, which shouldn't mind the
> change as long as you maintain the clk lookup creation.
Ok, I'll change that.
> On that topic, now that the clocks are available in DT we could even move
> raspberrypi-cpufreq's registration there. But that's out of the scope of this
> series.
>
> > +
> > + data = devm_kzalloc(rpi->dev, sizeof(*data), GFP_KERNEL);
> > + if (!data)
> > + return
Re: [PATCH] drm/etnaviv: fix perfmon domain interation
Hi Christian,
Le ven. 15 mai 2020 à 12:09, Christian Gmeiner
a écrit :
Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
:
The GC860 has one GPU device which has a 2d and 3d core. In this
case
we want to expose perfmon information for both cores.
The driver has one array which contains all possible perfmon domains
with some meta data - doms_meta. Here we can see that for the GC860
two elements of that array are relevant:
doms_3d: is at index 0 in the doms_meta array with 8 perfmon
domains
doms_2d: is at index 1 in the doms_meta array with 1 perfmon
domain
The userspace driver wants to get a list of all perfmon domains and
their perfmon signals. This is done by iterating over all domains
and
their signals. If the userspace driver wants to access the domain
with
id 8 the kernel driver fails and returns invalid data from doms_3d
with
and invalid offset.
This results in:
Unable to handle kernel paging request at virtual address
On such a device it is not possible to use the userspace driver at
all.
The fix for this off-by-one error is quite simple.
Reported-by: Paul Cercueil
Tested-by: Paul Cercueil
Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query
infrastructure")
Cc: sta...@vger.kernel.org
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index e6795bafcbb9..35f7171e779a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -453,7 +453,7 @@ static const struct etnaviv_pm_domain
*pm_domain(const struct etnaviv_gpu *gpu,
if (!(gpu->identity.features & meta->feature))
continue;
- if (meta->nr_domains < (index - offset)) {
+ if ((meta->nr_domains - 1) < (index - offset)) {
offset += meta->nr_domains;
continue;
}
--
2.26.2
ping
I'll merge it tomorrow if there's no further feedback.
-Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linux-stm32] [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
Hi Benjamin,
thanks for reply.
On Fri, May 15, 2020 at 4:31 PM Benjamin GAIGNARD
wrote:
>
>
>
> On 5/14/20 3:07 PM, dillon min wrote:
> > Hi Alexandre,
> >
> > On Thu, May 14, 2020 at 8:53 PM Alexandre Torgue
> > wrote:
> >>
> >>
> >> On 5/14/20 10:24 AM, Linus Walleij wrote:
> >>> On Tue, May 12, 2020 at 9:04 AM wrote:
> >>>
> From: dillon min
>
> Enable the ltdc & ili9341 on stm32429-disco board.
>
> Signed-off-by: dillon min
> >>> This mostly looks good but...
> >>>
> + {
> + status = "okay";
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cs-gpios = < 2 GPIO_ACTIVE_LOW>;
> + dmas = < 3 2 0x400 0x0>,
> + < 4 2 0x400 0x0>;
> + dma-names = "rx", "tx";
> >>> These DMA assignments seem to be SoC things and should
> >>> rather be in the DTS(I) file where is defined, right?
> >>> stm32f429.dtsi I suppose?
> >> I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
> >> doesn't want to use it, we use the "delete-property".
> > Yes, will move to Soc dtsi in next submits.
> >
> > i'm working on write a v4l2-m2m driver for dma2d of stm32 to support
> > pixel conversion
> > alpha blending between foreground and background graphics.
> >
> > as you know, some soc's engineer trying to add this function to drm system.
> >
> > do you know st's planning about soc's hardware accelerator driver on
> > stm32mp?
> > such as chrom-art, will add to drm subsystem via ioctl to access, or to
> > v4l2,
> On stm32mp we do not plan to use chrom-art in drm or v4l2 because it
> does fit
> with userland way of working. We use the GPU to do conversion, scaling,
> blending
> and composition in only one go.
> As explain here [1] DRM subsytem it isn't a solution and v4l2-m2m isn't
> used in any
> mainline compositors like Weston or android surfaceflinger.
>
> Benjamin
>
After check stm32mp's datasheets, they don't have chrom-art ip inside. sorry for
didn't check it yet.
for stm32h7 series with chrom-art, jpeg hardware accelerator inside.
does st has plan to
setup a driver to support it ? i prefer v4l2-m2m should be easier to
implement it.
co work with dcmi, fbdev.
thanks.
best regards.
Dillon
> [1]
> https://www.phoronix.com/scan.php?page=news_item=Linux-DRM-No-2D-Accel-API
> >
> > thanks.
> >
> >>> It is likely the same no matter which device is using spi5.
> >>>
> >>> Yours,
> >>> Linus Walleij
> >>>
> > ___
> > Linux-stm32 mailing list
> > linux-st...@st-md-mailman.stormreply.com
> > https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep
On 2020-05-14 21:47, Doug Anderson wrote: Hi, On Fri, May 1, 2020 at 6:31 AM Kalyan Thota wrote: "The PM core always increments the runtime usage counter before calling the ->suspend() callback and decrements it after calling the ->resume() callback" DPU and DSI are managed as runtime devices. When suspend is triggered, PM core adds a refcount on all the devices and calls device suspend, since usage count is already incremented, runtime suspend was not getting called and it kept the clocks on which resulted in target not entering into XO shutdown. Add changes to force suspend on runtime devices during pm sleep. Changes in v1: - Remove unnecessary checks in the function _dpu_kms_disable_dpu (Rob Clark). Changes in v2: - Avoid using suspend_late to reset the usagecount as suspend_late might not be called during suspend call failures (Doug). Changes in v3: - Use force suspend instead of managing device usage_count via runtime put and get API's to trigger callbacks (Doug). Changes in v4: - Check the return values of pm_runtime_force_suspend and pm_runtime_force_resume API's and pass appropriately (Doug). Changes in v5: Can you please put the version number properly in your subject? It's really hard to tell one version of your patch from another. - With v4 patch, test cycle has uncovered issues in device resume. On bubs: cmd tx failures were seen as SW is sending panel off commands when the dsi resources are turned off. Upon suspend, DRM driver will issue a NULL composition to the dpu, followed by turning off all the HW blocks. v5 changes will serialize the NULL commit and resource unwinding by handling them under PM prepare and PM complete phases there by ensuring that clks are on when panel off commands are being processed. I'm still most definitely not an expert in how all the DRM pieces all hook up together, but the solution you have in this patch seems wrong to me. As far as I can tell the "prepare" state isn't supposed to be actually doing the suspend work and here that's exactly what you're doing. I think you should find a different solution to ensure ordering is correct. -Doug Hi, Prepare and Complete are callbacks defined as part of Sleep and Resume sequence Entering PM SUSPEND the phases are : prepare --> suspend --> suspend_late --> suspend_noirq. While leaving PM SUSPEND the phases are: resume_noirq --> resume_early --> resume --> complete. The reason to push drm suspend handling to PM prepare phase is that parent here will trigger a modeset to turn off the timing and subsequently the panel. the child devices should not turn of their clocks before parent unwinds the composition. Hence they are serialized as per the sequence mentioned above. A similar approach is taken by other driver that use drm framework. In this driver, the device registers for prepare and complete callbacks to handle drm_suspend and drm_resume. https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/exynos/exynos_drm_drv.c#L163 Kalyan ___ Freedreno mailing list freedr...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linux-stm32] [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
Hi Benjamin,
got it, thanks a lot.
best regards
Dillon
On Fri, May 15, 2020 at 5:34 PM Benjamin GAIGNARD
wrote:
>
>
>
> On 5/15/20 11:24 AM, dillon min wrote:
> > Hi Benjamin,
> >
> > thanks for reply.
> >
> > On Fri, May 15, 2020 at 4:31 PM Benjamin GAIGNARD
> > wrote:
> >>
> >>
> >> On 5/14/20 3:07 PM, dillon min wrote:
> >>> Hi Alexandre,
> >>>
> >>> On Thu, May 14, 2020 at 8:53 PM Alexandre Torgue
> >>> wrote:
>
> On 5/14/20 10:24 AM, Linus Walleij wrote:
> > On Tue, May 12, 2020 at 9:04 AM wrote:
> >
> >> From: dillon min
> >>
> >> Enable the ltdc & ili9341 on stm32429-disco board.
> >>
> >> Signed-off-by: dillon min
> > This mostly looks good but...
> >
> >> + {
> >> + status = "okay";
> >> + pinctrl-0 = <_pins>;
> >> + pinctrl-names = "default";
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + cs-gpios = < 2 GPIO_ACTIVE_LOW>;
> >> + dmas = < 3 2 0x400 0x0>,
> >> + < 4 2 0x400 0x0>;
> >> + dma-names = "rx", "tx";
> > These DMA assignments seem to be SoC things and should
> > rather be in the DTS(I) file where is defined, right?
> > stm32f429.dtsi I suppose?
> I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
> doesn't want to use it, we use the "delete-property".
> >>> Yes, will move to Soc dtsi in next submits.
> >>>
> >>> i'm working on write a v4l2-m2m driver for dma2d of stm32 to support
> >>> pixel conversion
> >>> alpha blending between foreground and background graphics.
> >>>
> >>> as you know, some soc's engineer trying to add this function to drm
> >>> system.
> >>>
> >>> do you know st's planning about soc's hardware accelerator driver on
> >>> stm32mp?
> >>> such as chrom-art, will add to drm subsystem via ioctl to access, or to
> >>> v4l2,
> >> On stm32mp we do not plan to use chrom-art in drm or v4l2 because it
> >> does fit
> >> with userland way of working. We use the GPU to do conversion, scaling,
> >> blending
> >> and composition in only one go.
> >> As explain here [1] DRM subsytem it isn't a solution and v4l2-m2m isn't
> >> used in any
> >> mainline compositors like Weston or android surfaceflinger.
> >>
> >> Benjamin
> >>
> > After check stm32mp's datasheets, they don't have chrom-art ip inside.
> > sorry for
> > didn't check it yet.
> >
> > for stm32h7 series with chrom-art, jpeg hardware accelerator inside.
> > does st has plan to
> > setup a driver to support it ? i prefer v4l2-m2m should be easier to
> > implement it.
> > co work with dcmi, fbdev.
> ST doesn't plan to create a driver for chrom-art because nothing in
> mainline
> userland could use it.
>
> Benjamin
> >
> > thanks.
> >
> > best regards.
> >
> > Dillon
> >> [1]
> >> https://www.phoronix.com/scan.php?page=news_item=Linux-DRM-No-2D-Accel-API
> >>> thanks.
> >>>
> > It is likely the same no matter which device is using spi5.
> >
> > Yours,
> > Linus Walleij
> >
> >>> ___
> >>> Linux-stm32 mailing list
> >>> linux-st...@st-md-mailman.stormreply.com
> >>> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linux-stm32] [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
On 5/14/20 3:07 PM, dillon min wrote:
> Hi Alexandre,
>
> On Thu, May 14, 2020 at 8:53 PM Alexandre Torgue
> wrote:
>>
>>
>> On 5/14/20 10:24 AM, Linus Walleij wrote:
>>> On Tue, May 12, 2020 at 9:04 AM wrote:
>>>
From: dillon min
Enable the ltdc & ili9341 on stm32429-disco board.
Signed-off-by: dillon min
>>> This mostly looks good but...
>>>
+ {
+ status = "okay";
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cs-gpios = < 2 GPIO_ACTIVE_LOW>;
+ dmas = < 3 2 0x400 0x0>,
+ < 4 2 0x400 0x0>;
+ dma-names = "rx", "tx";
>>> These DMA assignments seem to be SoC things and should
>>> rather be in the DTS(I) file where is defined, right?
>>> stm32f429.dtsi I suppose?
>> I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
>> doesn't want to use it, we use the "delete-property".
> Yes, will move to Soc dtsi in next submits.
>
> i'm working on write a v4l2-m2m driver for dma2d of stm32 to support
> pixel conversion
> alpha blending between foreground and background graphics.
>
> as you know, some soc's engineer trying to add this function to drm system.
>
> do you know st's planning about soc's hardware accelerator driver on stm32mp?
> such as chrom-art, will add to drm subsystem via ioctl to access, or to v4l2,
On stm32mp we do not plan to use chrom-art in drm or v4l2 because it
does fit
with userland way of working. We use the GPU to do conversion, scaling,
blending
and composition in only one go.
As explain here [1] DRM subsytem it isn't a solution and v4l2-m2m isn't
used in any
mainline compositors like Weston or android surfaceflinger.
Benjamin
[1]
https://www.phoronix.com/scan.php?page=news_item=Linux-DRM-No-2D-Accel-API
>
> thanks.
>
>>> It is likely the same no matter which device is using spi5.
>>>
>>> Yours,
>>> Linus Walleij
>>>
> ___
> Linux-stm32 mailing list
> linux-st...@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 01/12] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
Hi Paul & Paul, > Am 03.05.2020 um 18:41 schrieb H. Nikolaus Schaller : > > Hi Paul and Paul, > >> Am 03.05.2020 um 16:18 schrieb Paul Cercueil : >> >> >> >> Le dim. 3 mai 2020 à 15:31, H. Nikolaus Schaller a >> écrit : >>> Hi Paul, Am 03.05.2020 um 14:52 schrieb Paul Cercueil : >> It's possible to forbid the presence of the 'clocks' property on some >> implementations, and require it on others. > To be precise we have to specify the exact number of clocks (between 0 > and 4) for every architecture. > This also contradicts my dream to get rid of the architecture specific > components in the long run. My dream (because I can't tell how it can be > done) is that we can one day develop something which just needs > compatible = img,530 or imp,540 or img,544. Then we can't make the number > clocks depend on the implementation any more. As we said before, the number of clocks is a property of the GPU and *not* its integration into the SoC. >>> Well, it is a not very well documented property of the GPU. We have no data >>> sheet of the standalone GPU. Only several SoC data sheets which give some >>> indications. >> >> Maybe we can nicely ask them? > > There is some (old) answer here: > > https://github.com/MIPS/CI20_linux/blob/ci20-v3.18/arch/mips/boot/dts/jz4780.dtsi#L63 > >> I expect Paul Burton to have some contacts at ImgTec. Asking for a doc would >> be too much, but maybe they can help a bit with the DT bindings. > > Good idea! It is definitively worth to try. Therefore I have moved him from > CC: to To: Do we already have an idea if we can get into contact and get help from ImgTec for this topic or if we have to live with what we have? BR and thanks, Nikolaus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/5] clk: stm32: Fix stm32f429 ltdc driver loading hang in clk set rate. keep ltdc clk running after kernel startup
Hi Stephen,
thanks for reviewing.
On Fri, May 15, 2020 at 5:02 AM Stephen Boyd wrote:
>
> Quoting dillon.min...@gmail.com (2020-05-12 00:03:36)
> > From: dillon min
> >
> > as store stm32f4_rcc_register_pll return to the wrong offset of clks,
>
> Use () on functions, i.e. stm32f4_rcc_register_pll().
ok
>
> > so ltdc gate clk is null. need change clks[PLL_VCO_SAI] to clks[PLL_SAI]
>
> And quote variables like 'clks[PLL_VCO_SAI]'
ok
>
> >
> > add CLK_IGNORE_UNUSED for ltdc to make sure clk not be freed by
> > clk_disable_unused
>
> clk_disable_unused() doesn't free anything. Why does ltdc not need to be
> turned off if it isn't used? Is it critical to system operation? Should
> it be marked with the critical clk flag then? The CLK_IGNORE_UNUSED flag
> is almost always wrong to use.
Yes, you are right. thanks. CLK_IGNORE_UNUSED just hide the root
cause. after deeper debugging.
i need to drop the last changes , they are not the root cause.
post diff and analyse here first, i will resubmit clk's changes in
next patchset with gyro and ili9341.
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -129,8 +129,6 @@ static const struct stm32f4_gate_data
stm32f429_gates[] __initconst = {
{ STM32F4_RCC_APB2ENR, 20, "spi5", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
- { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div",
- CLK_IGNORE_UNUSED },
};
static const struct stm32f4_gate_data stm32f469_gates[] __initconst = {
@@ -558,13 +556,13 @@ static const struct clk_div_table post_divr_table[] = {
#define MAX_POST_DIV 3
static const struct stm32f4_pll_post_div_data post_div_data[MAX_POST_DIV] = {
- { CLK_I2SQ_PDIV, PLL_I2S, "plli2s-q-div", "plli2s-q",
+ { CLK_I2SQ_PDIV, PLL_VCO_I2S, "plli2s-q-div", "plli2s-q",
CLK_SET_RATE_PARENT, STM32F4_RCC_DCKCFGR, 0, 5, 0, NULL},
- { CLK_SAIQ_PDIV, PLL_SAI, "pllsai-q-div", "pllsai-q",
+ { CLK_SAIQ_PDIV, PLL_VCO_SAI, "pllsai-q-div", "pllsai-q",
CLK_SET_RATE_PARENT, STM32F4_RCC_DCKCFGR, 8, 5, 0, NULL },
- { NO_IDX, PLL_SAI, "pllsai-r-div", "pllsai-r", CLK_SET_RATE_PARENT,
+ { NO_IDX, PLL_VCO_SAI, "pllsai-r-div", "pllsai-r", CLK_SET_RATE_PARENT,
STM32F4_RCC_DCKCFGR, 16, 2, 0, post_divr_table },
};
@@ -1758,7 +1756,7 @@ static void __init stm32f4_rcc_init(struct
device_node *np)
clks[PLL_VCO_I2S] = stm32f4_rcc_register_pll("vco_in",
>pll_data[1], _clk_lock);
- clks[PLL_SAI] = stm32f4_rcc_register_pll("vco_in",
+ clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll("vco_in",
>pll_data[2], _clk_lock);
for (n = 0; n < MAX_POST_DIV; n++) {
issue 1: ili9341 hang in clk set rate, the root cause should be
PLL_VCO_SAI, PLL_SAI mismatch
for 'clks[]'
1, first at stm32f4_rcc_init() ,
clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll("vco_in",
>pll_data[2], _clk_lock);
the clk_hw from stm32f4_rcc_register_pll() is store to 'clks[7]', defined in
'include/dt-bindings/clock/stm32fx-clock.h'
2, next
hw = clk_register_pll_div(post_div->name,
post_div->parent,
post_div->flag,
base + post_div->offset,
post_div->shift,
post_div->width,
post_div->flag_div,
post_div->div_table,
clks[post_div->pll_num],
_clk_lock);
the 'clks[post_div->pll_num]', the pll_num is PLL_SAI, the value is 2,
defined at
enum {
PLL,
PLL_I2S,
PLL_SAI,
};
'post_div_data[]'
so 7 != 2 offset of 'clks[]', input the wrong 'clks[]' to
clk_register_pll_div. cause to_clk_gate result is null,
crashed in ltdc driver's loading.
issue 2: clk_disable_unused() turn off ltdc clock.
1, ltdc clk is defined in 'stm32f429_gates[]', register to clk core,
but there is no user to use it.
ltdc driver use dts binding name "lcd", connect to CLK_LCD, then
aux clk 'lcd-tft '
2, as no one use 'stm32f429_gates[]' s ltdc clock , so the
enable_count is zero, after kernel startup
it's been turn off by clk_disable_unused() is fine.
my chages for this is remove the ltdc from 'stm32f429_gates[]'
but this modification still need 'clk-stm32f4.c''s maintainer to check
if there is side effect.
>
> >
> > Signed-off-by: dillon min
> > ---
> > drivers/clk/clk-stm32f4.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> > index 18117ce..0ba73de 100644
> > --- a/drivers/clk/clk-stm32f4.c
> > +++ b/drivers/clk/clk-stm32f4.c
> > @@ -129,7 +129,8 @@ static const struct stm32f4_gate_data stm32f429_gates[]
>
Re: [PATCH 0/3] Convert mtk-dpi to drm_bridge API
Hi, Enric: Chun-Kuang Hu 於 2020年5月10日 週日 上午9:24寫道： > > Hi, Enric: > > Enric Balletbo i Serra 於 2020年5月4日 週一 > 下午10:14寫道： > > > > The mtk-dpi driver still uses the drm_encoder API which is now somehow > > deprecated. We started to move all the Mediatek drivers to the drm_bridge > > API, > > like we did for the mtk-dsi driver [1], this is another small step to be > > able to > > fully convert the DRM Mediatek drivers to the drm_bridge API. A dummy > > drm_encoder is maintained in the mtk-dpi driver but the end goal is move > > all the > > dummy drm_encoder (mtk-dsi, mtk-dpi, etc) to the main mtk_drm_drv driver. > > For this series, applied to mediatek-drm-next [1], thanks. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next > I remove this series from mediatek-drm-next because drm bridge driver need ack of drm bridge maintainer. Regards, Chun-Kuang. > Regards, > Chun-Kuang. > > > > > Best regards, > > Enric > > > > [1] https://lore.kernel.org/patchwork/project/lkml/list/?series=441559 > > > > Enric Balletbo i Serra (3): > > drm/mediatek: mtk_dpi: Rename bridge to next_bridge > > drm/mediatek: mtk_dpi: Convert to bridge driver > > drm/mediatek: mtk_dpi: Use simple encoder > > > > drivers/gpu/drm/mediatek/mtk_dpi.c | 84 ++ > > 1 file changed, 39 insertions(+), 45 deletions(-) > > > > -- > > 2.26.2 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
