[PATCH 2/3] drm/msm/43xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
---
Build-tested only.
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 715436cb3996..2ae072b4e79d 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -658,6 +658,8 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct icc_path *ocmem_icc_path;
struct icc_path *icc_path;
int ret;
@@ -684,6 +686,25 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
if (ret)
goto fail;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
adreno_gpu->registers = adreno_is_a405(adreno_gpu) ? a405_registers :
a4xx_registers;
--
2.34.1
[PATCH 3/3] drm/msm/a5xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
---
Build-tested only.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index a99310b68793..b4c1720ba89c 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1744,6 +1744,7 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct a5xx_gpu *a5xx_gpu = NULL;
struct adreno_gpu *adreno_gpu;
struct msm_gpu *gpu;
@@ -1770,6 +1771,23 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
nr_rings = 4;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info)
+ return ERR_PTR(-EINVAL);
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
if (adreno_cmp_rev(ADRENO_REV(5, 1, 0, ANY_ID), config->rev))
nr_rings = 1;
--
2.34.1
[PATCH v2 1/4] drm/msm/a2xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions:
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/msm/adreno/adreno_gpu.h:171
a2xx_gpu_init+0x138/0x184
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-rc7-next-20230620 #993
Pass the GPU revision information to avoid run-time warning.
Tested on a imx53-qsb board.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Make it part of a single patch series.
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index c67089a7ebc1..4e1218462a23 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -520,6 +520,8 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
int ret;
if (!pdev) {
@@ -540,6 +542,23 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
gpu->perfcntrs = perfcntrs;
gpu->num_perfcntrs = ARRAY_SIZE(perfcntrs);
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info)
+ return ERR_PTR(-EINVAL);
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
if (adreno_is_a20x(adreno_gpu))
adreno_gpu->registers = a200_registers;
else if (adreno_is_a225(adreno_gpu))
--
2.34.1
[PATCH v2 3/4] drm/msm/a4xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
---
Build-tested only.
Changes since v1:
- None
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 715436cb3996..2ae072b4e79d 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -658,6 +658,8 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct icc_path *ocmem_icc_path;
struct icc_path *icc_path;
int ret;
@@ -684,6 +686,25 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
if (ret)
goto fail;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
adreno_gpu->registers = adreno_is_a405(adreno_gpu) ? a405_registers :
a4xx_registers;
--
2.34.1
[PATCH v2 2/4] drm/msm/a3xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
---
Build-tested only.
Changes since v1:
- None
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c86b377f6f0d..fc23810d7684 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -530,6 +530,8 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct icc_path *ocmem_icc_path;
struct icc_path *icc_path;
int ret;
@@ -558,6 +560,25 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
if (ret)
goto fail;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
/* if needed, allocate gmem: */
if (adreno_is_a330(adreno_gpu)) {
ret = adreno_gpu_ocmem_init(&adreno_gpu->base.pdev->dev,
--
2.34.1
[PATCH v2 4/4] drm/msm/a5xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
---
Build-tested only.
Changes since v1:
- None
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index a99310b68793..b4c1720ba89c 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1744,6 +1744,7 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct a5xx_gpu *a5xx_gpu = NULL;
struct adreno_gpu *adreno_gpu;
struct msm_gpu *gpu;
@@ -1770,6 +1771,23 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
nr_rings = 4;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info)
+ return ERR_PTR(-EINVAL);
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
if (adreno_cmp_rev(ADRENO_REV(5, 1, 0, ANY_ID), config->rev))
nr_rings = 1;
--
2.34.1
Re: [PATCH 1/3] drm/msm/a3xx: Pass the revision information
On 20/06/2023 14:40, Dmitry Baryshkov wrote:
This looks like a boilerplate being added to all aYxx drivers (and
then these fields are also set in adreno_gpu_init()). Can we remove
duplication somehow?
Sorry, I missed this comment prior to sending v2.
Maybe a simpler fix for a2xx_gpu would be:
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -540,6 +540,10 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device
*dev)
gpu->perfcntrs = perfcntrs;
gpu->num_perfcntrs = ARRAY_SIZE(perfcntrs);
+ ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
+ if (ret)
+ goto fail;
+
if (adreno_is_a20x(adreno_gpu))
adreno_gpu->registers = a200_registers;
else if (adreno_is_a225(adreno_gpu))
@@ -547,10 +551,6 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device
*dev)
else
adreno_gpu->registers = a220_registers;
- ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
- if (ret)
- goto fail;
-
if (!gpu->aspace) {
dev_err(dev->dev, "No memory protection without MMU\n");
if (!allow_vram_carveout) {
What do you think?
a3xx and a4xx call adreno_gpu_init() prior to adreno_is_xxx() so they
don't have issues.
[PATCH v3] drm/msm/a2xx: Call adreno_gpu_init() earlier
From: Fabio Estevam
The adreno_is_a20x() and adreno_is_a225() functions rely on the
GPU revision, but such information is retrieved inside adreno_gpu_init(),
which is called afterwards.
Fix this problem by caling adreno_gpu_init() earlier, so that
the GPU information revision is available when adreno_is_a20x()
and adreno_is_a225() run.
Tested on a imx53-qsb board.
Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx")
Signed-off-by: Fabio Estevam
---
Hi,
This error has been exposed by a recent commit in linux-next:
cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified before being set")
, but the error has been present since the very first a2xx commit.
Changes since v2:
- Call adreno_gpu_init() earlier.
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index c67089a7ebc1..ad4570d60abf 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -540,6 +540,10 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
gpu->perfcntrs = perfcntrs;
gpu->num_perfcntrs = ARRAY_SIZE(perfcntrs);
+ ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
+ if (ret)
+ goto fail;
+
if (adreno_is_a20x(adreno_gpu))
adreno_gpu->registers = a200_registers;
else if (adreno_is_a225(adreno_gpu))
@@ -547,10 +551,6 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
else
adreno_gpu->registers = a220_registers;
- ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
- if (ret)
- goto fail;
-
if (!gpu->aspace) {
dev_err(dev->dev, "No memory protection without MMU\n");
if (!allow_vram_carveout) {
--
2.34.1
[PATCH v3 1/2] dt-bindings: samsung,mipi-dsim: Add 'lane-polarities'
From: Fabio Estevam The Samsung DSIM IP block allows the inversion of the clock and data lanes. Add an optional property called 'lane-polarities' that describes the polarities of the MIPI DSI clock and data lanes. This property is useful for properly describing the hardware when the board designer decided to switch the polarities of the MIPI DSI clock and/or data lanes. Signed-off-by: Fabio Estevam --- Changes since v2: - Use video-interfaces.yaml (Rob). .../display/bridge/samsung,mipi-dsim.yaml | 29 +++ 1 file changed, 29 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml index e841659e20cd..dad6d06fbdd9 100644 --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -105,6 +105,35 @@ properties: DSI output port node to the panel or the next bridge in the chain. +properties: + endpoint: +$ref: /schemas/media/video-interfaces.yaml# +unevaluatedProperties: false + +properties: + data-lanes: +oneOf: + - minItems: 1 +maxItems: 4 +uniqueItems: true +items: + enum: [ 1, 2, 3, 4 ] +description: + See ../../media/video-interfaces.yaml for details. + + lane-polarities: +minItems: 1 +maxItems: 5 +items: + enum: [ 0, 1 ] +description: + See ../../media/video-interfaces.yaml for details. + The Samsung MIPI DSI IP requires that all the data lanes have + the same polarity. + +dependencies: + lane-polarities: [data-lanes] + required: - clock-names - clocks -- 2.34.1
[PATCH v3 2/2] drm: bridge: samsung-dsim: Implement support for clock/data polarity swap
From: Marek Vasut
Implement support for DSI clock and data lane DN/DP polarity swap by
means of decoding 'lane-polarities' DT property. The controller does
support DN/DP swap of clock lane and all data lanes, the controller
does not support polarity swap of individual data lane bundles, add
a check which verifies all data lanes have the same polarity.
This has been validated on an imx8mm board that actually has the MIPI DSI
clock lanes inverted.
Signed-off-by: Marek Vasut
Signed-off-by: Fabio Estevam
Reviewed-by: Jagan Teki
---
Changes since v2:
- None
drivers/gpu/drm/bridge/samsung-dsim.c | 27 ++-
include/drm/bridge/samsung-dsim.h | 2 ++
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index e0a402a85787..5791148e2da2 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -183,6 +183,8 @@
#define DSIM_AFC_CTL(x)(((x) & 0x7) << 5)
/* DSIM_PLLCTRL */
+#define DSIM_PLL_DPDNSWAP_CLK (1 << 25)
+#define DSIM_PLL_DPDNSWAP_DAT (1 << 24)
#define DSIM_FREQ_BAND(x) ((x) << 24)
#define DSIM_PLL_ENBIT(23)
#define DSIM_PLL_P(x, offset) ((x) << (offset))
@@ -622,6 +624,11 @@ static unsigned long samsung_dsim_set_pll(struct
samsung_dsim *dsi,
reg |= DSIM_FREQ_BAND(band);
}
+ if (dsi->swap_dn_dp_clk)
+ reg |= DSIM_PLL_DPDNSWAP_CLK;
+ if (dsi->swap_dn_dp_data)
+ reg |= DSIM_PLL_DPDNSWAP_DAT;
+
samsung_dsim_write(dsi, DSIM_PLLCTRL_REG, reg);
timeout = 1000;
@@ -1696,7 +1703,9 @@ static int samsung_dsim_parse_dt(struct samsung_dsim *dsi)
{
struct device *dev = dsi->dev;
struct device_node *node = dev->of_node;
- int ret;
+ u32 lane_polarities[5] = { 0 };
+ struct device_node *endpoint;
+ int i, nr_lanes, ret;
ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
&dsi->pll_clk_rate);
@@ -1713,6 +1722,22 @@ static int samsung_dsim_parse_dt(struct samsung_dsim
*dsi)
if (ret < 0)
return ret;
+ endpoint = of_graph_get_endpoint_by_regs(node, 1, -1);
+ nr_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
+ if (nr_lanes > 0 && nr_lanes <= 4) {
+ /* Polarity 0 is clock lane, 1..4 are data lanes. */
+ of_property_read_u32_array(endpoint, "lane-polarities",
+ lane_polarities, nr_lanes + 1);
+ for (i = 1; i <= nr_lanes; i++) {
+ if (lane_polarities[1] != lane_polarities[i])
+ DRM_DEV_ERROR(dsi->dev, "Data lanes polarities
do not match");
+ }
+ if (lane_polarities[0])
+ dsi->swap_dn_dp_clk = true;
+ if (lane_polarities[1])
+ dsi->swap_dn_dp_data = true;
+ }
+
return 0;
}
diff --git a/include/drm/bridge/samsung-dsim.h
b/include/drm/bridge/samsung-dsim.h
index ba5484de2b30..6a37d1e079bf 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -95,6 +95,8 @@ struct samsung_dsim {
u32 mode_flags;
u32 format;
+ bool swap_dn_dp_clk;
+ bool swap_dn_dp_data;
int state;
struct drm_property *brightness;
struct completion completed;
--
2.34.1
[PATCH v4 1/2] dt-bindings: samsung,mipi-dsim: Add 'lane-polarities'
From: Fabio Estevam The Samsung DSIM IP block allows the inversion of the clock and data lanes. Add an optional property called 'lane-polarities' that describes the polarities of the MIPI DSI clock and data lanes. This property is useful for properly describing the hardware when the board designer decided to switch the polarities of the MIPI DSI clock and/or data lanes. Signed-off-by: Fabio Estevam --- Changes since v3: - Dropped oneOf, no need for it. (Krzysztof) - Dropped description as it is obvious. (Krzysztof) - Dropped items, as it is already in video-interfaces. (Krzysztof) - Dropped "See ../../media/video-interfaces.yaml". (Krzysztof) .../display/bridge/samsung,mipi-dsim.yaml | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml index e841659e20cd..9f61ebdfefa8 100644 --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -105,6 +105,29 @@ properties: DSI output port node to the panel or the next bridge in the chain. +properties: + endpoint: +$ref: /schemas/media/video-interfaces.yaml# +unevaluatedProperties: false + +properties: + data-lanes: +minItems: 1 +maxItems: 4 +uniqueItems: true +items: + enum: [ 1, 2, 3, 4 ] + + lane-polarities: +minItems: 1 +maxItems: 5 +description: + The Samsung MIPI DSI IP requires that all the data lanes have + the same polarity. + +dependencies: + lane-polarities: [data-lanes] + required: - clock-names - clocks -- 2.34.1
[PATCH v4 2/2] drm: bridge: samsung-dsim: Implement support for clock/data polarity swap
From: Marek Vasut
Implement support for DSI clock and data lane DN/DP polarity swap by
means of decoding 'lane-polarities' DT property. The controller does
support DN/DP swap of clock lane and all data lanes, the controller
does not support polarity swap of individual data lane bundles, add
a check which verifies all data lanes have the same polarity.
This has been validated on an imx8mm board that actually has the MIPI DSI
clock lanes inverted.
Signed-off-by: Marek Vasut
Signed-off-by: Fabio Estevam
Reviewed-by: Jagan Teki
---
Changes since v3:
- None
drivers/gpu/drm/bridge/samsung-dsim.c | 27 ++-
include/drm/bridge/samsung-dsim.h | 2 ++
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index e0a402a85787..5791148e2da2 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -183,6 +183,8 @@
#define DSIM_AFC_CTL(x)(((x) & 0x7) << 5)
/* DSIM_PLLCTRL */
+#define DSIM_PLL_DPDNSWAP_CLK (1 << 25)
+#define DSIM_PLL_DPDNSWAP_DAT (1 << 24)
#define DSIM_FREQ_BAND(x) ((x) << 24)
#define DSIM_PLL_ENBIT(23)
#define DSIM_PLL_P(x, offset) ((x) << (offset))
@@ -622,6 +624,11 @@ static unsigned long samsung_dsim_set_pll(struct
samsung_dsim *dsi,
reg |= DSIM_FREQ_BAND(band);
}
+ if (dsi->swap_dn_dp_clk)
+ reg |= DSIM_PLL_DPDNSWAP_CLK;
+ if (dsi->swap_dn_dp_data)
+ reg |= DSIM_PLL_DPDNSWAP_DAT;
+
samsung_dsim_write(dsi, DSIM_PLLCTRL_REG, reg);
timeout = 1000;
@@ -1696,7 +1703,9 @@ static int samsung_dsim_parse_dt(struct samsung_dsim *dsi)
{
struct device *dev = dsi->dev;
struct device_node *node = dev->of_node;
- int ret;
+ u32 lane_polarities[5] = { 0 };
+ struct device_node *endpoint;
+ int i, nr_lanes, ret;
ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
&dsi->pll_clk_rate);
@@ -1713,6 +1722,22 @@ static int samsung_dsim_parse_dt(struct samsung_dsim
*dsi)
if (ret < 0)
return ret;
+ endpoint = of_graph_get_endpoint_by_regs(node, 1, -1);
+ nr_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
+ if (nr_lanes > 0 && nr_lanes <= 4) {
+ /* Polarity 0 is clock lane, 1..4 are data lanes. */
+ of_property_read_u32_array(endpoint, "lane-polarities",
+ lane_polarities, nr_lanes + 1);
+ for (i = 1; i <= nr_lanes; i++) {
+ if (lane_polarities[1] != lane_polarities[i])
+ DRM_DEV_ERROR(dsi->dev, "Data lanes polarities
do not match");
+ }
+ if (lane_polarities[0])
+ dsi->swap_dn_dp_clk = true;
+ if (lane_polarities[1])
+ dsi->swap_dn_dp_data = true;
+ }
+
return 0;
}
diff --git a/include/drm/bridge/samsung-dsim.h
b/include/drm/bridge/samsung-dsim.h
index ba5484de2b30..6a37d1e079bf 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -95,6 +95,8 @@ struct samsung_dsim {
u32 mode_flags;
u32 format;
+ bool swap_dn_dp_clk;
+ bool swap_dn_dp_data;
int state;
struct drm_property *brightness;
struct completion completed;
--
2.34.1
Re: [PATCH v2 2/2] drm/bridge: ti-sn65dsi83: Fix enable/disable flow to meet spec
On Thu, May 4, 2023 at 6:12 AM Alexander Stein wrote: > > Am Mittwoch, 3. Mai 2023, 18:33:07 CEST schrieb Frieder Schrempf: > > From: Frieder Schrempf > > > > The datasheet describes the following initialization flow including > > minimum delay times between each step: > > > > 1. DSI data lanes need to be in LP-11 and the clock lane in HS mode > > 2. toggle EN signal > > 3. initialize registers > > 4. enable PLL > > 5. soft reset > > 6. enable DSI stream > > 7. check error status register > > > > To meet this requirement we need to make sure the host bridge's > > pre_enable() is called first by using the pre_enable_prev_first > > flag. > > > > Furthermore we need to split enable() into pre_enable() which covers > > steps 2-5 from above and enable() which covers step 7 and is called > > after the host bridge's enable(). > > > > Signed-off-by: Frieder Schrempf > > Tested-by: Alexander Stein #TQMa8MxML/MBa8Mx Should this have a Fixes tag so that it could be backported to stable kernels?
Re: [PATCH V7 0/6] drm: bridge: samsung-dsim: Support variable clocking
Hi Adam, On Thu, May 18, 2023 at 8:06 PM Adam Ford wrote: > > This series fixes the blanking pack size and the PMS calculation. It then > adds support to allows the DSIM to dynamically DPHY clocks, and support > non-burst mode while allowing the removal of the hard-coded clock values > for the PLL for imx8m mini/nano/plus, and it allows the removal of the > burst-clock device tree entry when burst-mode isn't supported by connected > devices like an HDMI brige. In that event, the HS clock is set to the > value requested by the bridge chip. > > This has been tested on both an i.MX8M Nano and i.MX8M Plus, and should > work on i.MX8M Mini as well. Marek Szyprowski has tested it on various > Exynos boards. > > Adam Ford (5): > drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp] > drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically > drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY > drm: bridge: samsung-dsim: Dynamically configure DPHY timing > drm: bridge: samsung-dsim: Support non-burst mode > > Lucas Stach (1): > drm: bridge: samsung-dsim: fix blanking packet size calculation > > drivers/gpu/drm/bridge/Kconfig| 1 + > drivers/gpu/drm/bridge/samsung-dsim.c | 142 +- > include/drm/bridge/samsung-dsim.h | 4 + > 3 files changed, 124 insertions(+), 23 deletions(-) > > V7: Move messages indicating the optional device tree items are going > to be automatically read elsewhere was move to dev_dbg instead of > dev_info. Cleaned up some of the comments to be a bit more clear. > Eliminated a double variable assignement accidentally introduced > in V6 when some of the items were moved from patch 6 to patch 5. It seems you missed addressing one previous comment from Lucas: "Same as with the earlier patch, this needs to be documented in the DT binding by moving "samsung,burst-clock-frequency" to be a optional property."
Re: [PATCH v4 1/2] dt-bindings: samsung, mipi-dsim: Add 'lane-polarities'
Hi Neil, On Sun, May 14, 2023 at 9:29 AM Krzysztof Kozlowski wrote: > > On 14/05/2023 13:46, Fabio Estevam wrote: > > From: Fabio Estevam > > > > The Samsung DSIM IP block allows the inversion of the clock and > > data lanes. > > > > Add an optional property called 'lane-polarities' that describes the > > polarities of the MIPI DSI clock and data lanes. > > > Reviewed-by: Krzysztof Kozlowski Could you please apply this series? Thanks
Re: [PATCH V7 0/6] drm: bridge: samsung-dsim: Support variable clocking
Hi Adam, On Tue, May 23, 2023 at 8:49 PM Adam Ford wrote: > Inki, > > I haven't heard back from you on whether or not you want the bindings > patch to be included with me resending the series as V7 or if you're > OK with a single, stand-alone patch. > Will you let me know? I have the patch standing by waiting for > instructions. If you're not the right person to ask, please let me > know who the right person is. Neil has also been collecting samsung-dsim patches. Maybe he can clarify.
Re: [PATCH v2] drm: bridge: samsung-dsim: Fix waiting for empty cmd transfer FIFO on older Exynos
On Fri, Jul 21, 2023 at 8:28 AM Marek Szyprowski
wrote:
>
> Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
> doesn't report empty level of packer header FIFO. In case of those SoCs,
> use the old way of waiting for empty command tranfsfer FIFO, removed
> recently by commit 14806c641582 ("Drain command transfer FIFO before
> transfer").
>
> Fixes: 14806c641582 ("Drain command transfer FIFO before transfer")
Nitpick: the Subject of the commit log is not complete.
Fixes: 14806c641582 ("drm: bridge: samsung-dsim: Drain command
transfer FIFO before transfer")
> Signed-off-by: Marek Szyprowski
> ---
> v2:
> - added additional delay when workaround is used as suggested by Marek Vasut
>
> v1:
> https://lore.kernel.org/all/20230718131859.3114135-1-m.szyprow...@samsung.com/
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 18 --
> include/drm/bridge/samsung-dsim.h | 1 +
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 9b7a00bafeaa..d06401de637c 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -412,6 +412,7 @@ static const struct samsung_dsim_driver_data
> exynos3_dsi_driver_data = {
> .m_min = 41,
> .m_max = 125,
> .min_freq = 500,
> + .has_broken_fifoctrl_emptyhdr = 1,
> };
>
> static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
> @@ -428,6 +429,7 @@ static const struct samsung_dsim_driver_data
> exynos4_dsi_driver_data = {
> .m_min = 41,
> .m_max = 125,
> .min_freq = 500,
> + .has_broken_fifoctrl_emptyhdr = 1,
> };
>
> static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
> @@ -1009,8 +1011,20 @@ static int samsung_dsim_wait_for_hdr_fifo(struct
> samsung_dsim *dsi)
> do {
> u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
>
> - if (reg & DSIM_SFR_HEADER_EMPTY)
> - return 0;
> + if (!dsi->driver_data->has_broken_fifoctrl_emptyhdr) {
> + if (reg & DSIM_SFR_HEADER_EMPTY)
> + return 0;
> + } else {
> + if (!(reg & DSIM_SFR_HEADER_FULL)) {
> + /*
> +* Wait a little bit, so the pending data can
> +* actually leave the FIFO to avoid overflow.
> +*/
> + if (!cond_resched())
> + usleep_range(950, 1050);
> + return 0;
> + }
> + }
>
> if (!cond_resched())
> usleep_range(950, 1050);
> diff --git a/include/drm/bridge/samsung-dsim.h
> b/include/drm/bridge/samsung-dsim.h
> index 05100e91ecb9..18017b3e5d9e 100644
> --- a/include/drm/bridge/samsung-dsim.h
> +++ b/include/drm/bridge/samsung-dsim.h
> @@ -62,6 +62,7 @@ struct samsung_dsim_driver_data {
> const unsigned int *reg_values;
> u16 m_min;
> u16 m_max;
> + unsigned int has_broken_fifoctrl_emptyhdr;
> };
>
> struct samsung_dsim_host_ops {
> --
> 2.34.1
>
Re: [PATCH v3] drm/msm/a2xx: Call adreno_gpu_init() earlier
Hi Rob,
A gentle ping.
On Thu, Jun 22, 2023 at 3:37 PM Dmitry Baryshkov
wrote:
>
> On 21/06/2023 02:23, Fabio Estevam wrote:
> > From: Fabio Estevam
> >
> > The adreno_is_a20x() and adreno_is_a225() functions rely on the
> > GPU revision, but such information is retrieved inside adreno_gpu_init(),
> > which is called afterwards.
> >
> > Fix this problem by caling adreno_gpu_init() earlier, so that
> > the GPU information revision is available when adreno_is_a20x()
> > and adreno_is_a225() run.
> >
> > Tested on a imx53-qsb board.
> >
> > Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx")
> > Signed-off-by: Fabio Estevam
> > ---
> > Hi,
> >
> > This error has been exposed by a recent commit in linux-next:
> >
> > cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified before being
> > set")
> >
> > , but the error has been present since the very first a2xx commit.
> >
> > Changes since v2:
> > - Call adreno_gpu_init() earlier.
>
> Reviewed-by: Dmitry Baryshkov
>
>
> >
> > drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
>
>
> --
> With best wishes
> Dmitry
>
Re: [PATCH V2] dt-bindings: bridge: samsung-dsim: Make some flags optional
On Sun, May 28, 2023 at 10:27 AM Adam Ford wrote: > > In the event a device is connected to the samsung-dsim > controller that doesn't support the burst-clock, the > driver is able to get the requested pixel clock from the > attached device or bridge. In these instances, the > samsung,burst-clock-frequency isn't needed, so remove > it from the required list. > > The pll-clock frequency can be set by the device tree entry > for samsung,pll-clock-frequency, but in some cases, the > pll-clock may have the same clock rate as sclk_mipi clock. > If they are equal, this flag is not needed since the driver > will use the sclk_mipi rate as a fallback. > > Signed-off-by: Adam Ford > Reviewed-by: Conor Dooley > --- > V2: Split from driver series. Re-word updates for burst > and pll-clock frequency. Reviewed-by: Fabio Estevam
[PATCH] dt-bindings: samsung,mipi-dsim: Use port-base reference
From: Fabio Estevam
Use port-base reference for port@0 and port@1.
This fixes the following schema warning:
imx8mm-evk.dtb: dsi@32e1: ports:port@1:endpoint: Unevaluated properties are
not allowed ('data-lanes' was unexpected)
>From schema:
>Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
Fixes: 1f0d40d88f7a ("dt-bindings: bridge: Convert Samsung MIPI DSIM bridge to
yaml")
Signed-off-by: Fabio Estevam
---
.../devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
index 9f61ebdfefa8..51879030dd6d 100644
--- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
@@ -93,14 +93,14 @@ properties:
properties:
port@0:
-$ref: /schemas/graph.yaml#/properties/port
+$ref: /schemas/graph.yaml#/$defs/port-base
description:
Input port node to receive pixel data from the
display controller. Exactly one endpoint must be
specified.
port@1:
-$ref: /schemas/graph.yaml#/properties/port
+$ref: /schemas/graph.yaml#/$defs/port-base
description:
DSI output port node to the panel or the next bridge
in the chain.
--
2.34.1
Re: [PATCH] dt-bindings: samsung,mipi-dsim: Use port-base reference
On 31/05/2023 15:56, Krzysztof Kozlowski wrote: This would have sense if you kept original intention, so additionalProperties: false Without it - you just break bindings to hide warning. I am not sure I understood your suggestion. Is this what you mean? diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml index 06b6c44d4641..033404669b11 100644 --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -96,14 +96,14 @@ properties: properties: port@0: -$ref: /schemas/graph.yaml#/properties/port +$ref: /schemas/graph.yaml#/$defs/port-base description: Input port node to receive pixel data from the display controller. Exactly one endpoint must be specified. port@1: -$ref: /schemas/graph.yaml#/properties/port +$ref: /schemas/graph.yaml#/$defs/port-base description: DSI output port node to the panel or the next bridge in the chain. @@ -230,8 +230,7 @@ allOf: - vddio-supply - samsung,phy-type -additionalProperties: - type: object +additionalProperties: false examples: - | --
[PATCH v2] dt-bindings: samsung,mipi-dsim: Use port-base reference
From: Fabio Estevam
Use port-base reference for port@1.
This fixes the following schema warning:
imx8mp-dhcom-pdk3.dtb: dsi@32e6: ports:port@1:endpoint: Unevaluated
properties are not allowed ('data-lanes' was unexpected)
>From schema:
>Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
Fixes: 1f0d40d88f7a ("dt-bindings: bridge: Convert Samsung MIPI DSIM bridge to
yaml")
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Only changed port@1.
- Used Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml as
reference. (Thanks Marek for the suggestion!)
To reproduce the original problem against linux-next 20230531:
- Enable the mipi_dsi node on imx8mp-dhcom-som.dtsi
&mipi_dsi {
samsung,burst-clock-frequency = <16000>;
samsung,esc-clock-frequency = <1000>;
+ status = "okay";
ports {
port@1 {
$ make CHECK_DTBS=y DT_SCHEMA_FILES=samsung,mipi-dsim.yaml
freescale/imx8mp-dhcom-pdk3.dtb
UPD include/config/kernel.release
LINTDocumentation/devicetree/bindings
CHKDT Documentation/devicetree/bindings/processed-schema.json
SCHEMA Documentation/devicetree/bindings/processed-schema.json
DTC_CHK arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dtb
arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dtb: dsi@32e6:
ports:port@1:endpoint: Unevaluated properties are not allowed ('data-lanes' was
unexpected)
>From schema:
>Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
.../devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
index 06b6c44d4641..4ed7a799ba26 100644
--- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
@@ -103,7 +103,8 @@ properties:
specified.
port@1:
-$ref: /schemas/graph.yaml#/properties/port
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
description:
DSI output port node to the panel or the next bridge
in the chain.
--
2.34.1
Re: [PATCH v3] drm/msm/a2xx: Call adreno_gpu_init() earlier
Hi Rob,
Any comments, please?
On Mon, Jul 24, 2023 at 5:28 PM Fabio Estevam wrote:
>
> Hi Rob,
>
> A gentle ping.
>
> On Thu, Jun 22, 2023 at 3:37 PM Dmitry Baryshkov
> wrote:
> >
> > On 21/06/2023 02:23, Fabio Estevam wrote:
> > > From: Fabio Estevam
> > >
> > > The adreno_is_a20x() and adreno_is_a225() functions rely on the
> > > GPU revision, but such information is retrieved inside adreno_gpu_init(),
> > > which is called afterwards.
> > >
> > > Fix this problem by caling adreno_gpu_init() earlier, so that
> > > the GPU information revision is available when adreno_is_a20x()
> > > and adreno_is_a225() run.
> > >
> > > Tested on a imx53-qsb board.
> > >
> > > Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx")
> > > Signed-off-by: Fabio Estevam
> > > ---
> > > Hi,
> > >
> > > This error has been exposed by a recent commit in linux-next:
> > >
> > > cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified before being
> > > set")
> > >
> > > , but the error has been present since the very first a2xx commit.
> > >
> > > Changes since v2:
> > > - Call adreno_gpu_init() earlier.
> >
> > Reviewed-by: Dmitry Baryshkov
> >
> >
> > >
> > > drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 8
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> >
> > --
> > With best wishes
> > Dmitry
> >
Re: [PATCH v2] drm: bridge: samsung-dsim: Fix init during host transfer
Hi Tim, On Thu, Aug 17, 2023 at 5:53 PM Tim Harvey wrote: > Frieder, > > Sorry for the delay. Yes this resolves the regression I ran into. I > tested it on top of v6.5-rc6 on a gw72xx-0x with a DFROBOT DRF0678 7in > 800x480 (Raspberry Pi) display which has the Toshiba TC358762 > compatible DSI to DBI bridge. > > Let's please get this into v6.5 as soon as possible. Care to provide your Tested-by tag?
Re: [PATCH 0/7] ADV7511 driver enhancements
Hi Biju, On Sun, Aug 13, 2023 at 3:05 PM Biju Das wrote: > > This patch series aims to improve ADV7511 driver by adding > feature bits and data instead of comparing enum adv7511_type for > various hardware differences between ADV7511, ADV7533 and ADV7535. > > This patch series tested with[1] on RZ/G2L SMARC EVK which embeds > ADV7535. I have successfully tested this series on a imx8mm-evk, which has an ADV7535: Tested-by: Fabio Estevam
Re: [PATCH] drm: adv7511: Fix low refresh rate register for ADV7533/5
On Wed, May 17, 2023 at 4:08 AM Alexandru Ardelean wrote: > > From: Bogdan Togorean > > For ADV7533 and ADV7535 low refresh rate is selected using > bits [3:2] of 0x4a main register. > So depending on ADV model write 0xfb or 0x4a register. > > Signed-off-by: Bogdan Togorean > Signed-off-by: Alexandru Ardelean Should this contain a Fixes tag so that it could be backported to stable kernels?
[PATCH] README: Fix typos and grammar
Signed-off-by: Fabio Estevam --- README | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README b/README index 603a1c1..15b3064 100644 --- a/README +++ b/README @@ -1,7 +1,7 @@ libdrm - userspace library for drm This is libdrm, a userspace library for accessing the DRM, direct -rendering manager, on Linux, BSD and other operating systes that +rendering manager, on Linux, BSD and other operating systems that support the ioctl interface. The library provides wrapper functions for the ioctls to avoid exposing the kernel interface directly, and for chipsets with drm memory manager, support for tracking relocations @@ -15,7 +15,7 @@ with an older kernel. Compiling - -libdrm is a standard autotools packages and follows the normal +libdrm is a standard autotools package and follows the normal configure, build and install steps. The first step is to configure the package, which is done by running the configure shell script: @@ -37,5 +37,5 @@ and once make finishes successfully, install the package using make install -If you are install into a system location, you will need to be root to -perform the install step. +If you are installing into a system location, you will need to be root +to perform the install step. -- 2.7.4
Etnaviv driver does bind with 4.9-rc1
Hi, With kernel 4.8.2 the following messages are seen on a mx6q: root at imx6qsabresd:~# dmesg | grep etnaviv [2.378176] etnaviv gpu-subsystem: bound 134000.gpu (ops gpu_ops) [2.384352] etnaviv gpu-subsystem: bound 13.gpu (ops gpu_ops) [2.390542] etnaviv gpu-subsystem: bound 2204000.gpu (ops gpu_ops) [2.396745] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 [2.448947] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108 [2.51] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 [2.506119] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 However, with 4.9-rc1 none of these log messages appear: root at imx6qsabresd:~# dmesg | grep etnaviv root at imx6qsabresd:~# For some reason etnaviv_gpu_bind() is never getting called. I haven't debugged this yet. If anyone has some ideas, please let me know. Thanks, Fabio Estevam
Etnaviv driver does bind with 4.9-rc1
Hi Lucas, On Mon, Oct 17, 2016 at 1:12 PM, Lucas Stach wrote: > This is the same issue you already fixed yourself in patch "ARM: imx: > gpc: Initialize all power domains" ;) Oh, you are right :-) I wasn't even using etnaviv when I created such patch. Just applied it against 4.9-rc1 and it does allow etnaviv to probe with 4.9-rc1. Thanks!
Re: DVI output on i.MX51 EVP board not working?
Hi Wladimir, On Fri, Mar 31, 2017 at 2:36 AM, Wladimir J. van der Laan wrote: > - Went as far back as kernel v4.0, even to v3.12 or so (commit 493a863, "ARM: > dts: imx51-babbage: Make DVI and WVGA panel functional"). No difference. So > nothing to > bisect, unfortunately. It was a long time I worked on this commit and it worked well for me on an old DVI monitor. I will try to locate such monitor in the office next week and try it again. Regards, Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DVI output on i.MX51 EVP board not working?
On Sat, Apr 1, 2017 at 6:40 PM, Fabio Estevam wrote: > Hi Wladimir, > > On Fri, Mar 31, 2017 at 2:36 AM, Wladimir J. van der Laan > wrote: > >> - Went as far back as kernel v4.0, even to v3.12 or so (commit 493a863, "ARM: >> dts: imx51-babbage: Make DVI and WVGA panel functional"). No difference. >> So nothing to >> bisect, unfortunately. > > It was a long time I worked on this commit and it worked well for me > on an old DVI monitor. > > I will try to locate such monitor in the office next week and try it again. Finally had a chance to test it and I can see both U-Boot logo and kernel penguin correctly on my monitor. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DVI output on i.MX51 EVP board not working?
On Wed, Apr 5, 2017 at 10:05 AM, Wladimir J. van der Laan wrote: > Ok, thanks for testing. > > To be clear: was this result with v3.x, or with mainline? I tested with 4.11-rc5 and the kernel is driving the DVI monitor correctly. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
Thierry/Rob, On Tue, Feb 7, 2017 at 10:48 PM, Fabio Estevam wrote: > On Tue, Feb 7, 2017 at 9:36 PM, Rob Herring wrote: > >> Except I have no way of knowing whether: a) you omitted a supply >> because you don't (yet) care, b) the panel has a single supply and you >> are using power-supply or c) the panel has multiple supplies and your >> binding is wrong. >> >> I can only eliminate A if you list the supplies. Just need something >> like "power-supply : see simple-panel.txt". I've still got to go read >> the panel spec if I really want to check the binding. > > Just checked the panel datasheet at > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf and it lists two > supplies: > DVDD (Digital power supply) and AVDD (Analog power supply). > > Our dts was just providing a single 'power-supply' which referred to a > GPIO enabled regulator that drives DVDD. > > So it seems we missed to pass AVDD (not software controlled in our > case, but we need to describe it in dts anyway). > > Does this mean we cannot use simple-panel for this particular panel > and we should add a separate driver for it? Please confirm if we need to create a separate driver for this panel, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mxsfb_crtc: Print bus_format in hexadecimal
From: Fabio Estevam Media bus formats are represented in hexadecimal format in include/uapi/linux/media-bus-format.h, so it is better to print the error message using the bus_format variable in hexadecimal. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c index 1144e0c..893f9f0 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c @@ -109,7 +109,7 @@ static void mxsfb_set_bus_fmt(struct mxsfb_drm_private *mxsfb) reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_24BIT); break; default: - dev_err(drm->dev, "Unknown media bus format %d\n", bus_format); + dev_err(drm->dev, "Unknown media bus format 0x%x\n", bus_format); break; } writel(reg, mxsfb->base + LCDC_CTRL); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Warning at drivers/gpu/drm/drm_atomic_helper.c
Hi Lucas, On Wed, Jan 25, 2017 at 8:43 AM, Lucas Stach wrote: > This only fixes the issue, as with this change we never attach fences to > the plane state. I've looked into this issue a bit and if I'm not > mistaken, this should still be reproducible with 4.10-rc. Correct? I could not reproduce this kernel warning with 4.10-rc, as it does not use imx_drm_atomic_commit() anymore. The problem happens with 4.9.x stable, which uses imx_drm_atomic_commit(). Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Warning at drivers/gpu/drm/drm_atomic_helper.c
On Wed, Jan 25, 2017 at 9:30 AM, Lucas Stach wrote: > Kernel 4.10 just moves the fence attach to the plane state. It has > nothing to do with the used commit function. The issue going away if you > change that on kernel 4.9 is a red herring. > > In any case, can you try the attached patch? It's against 4.10, if you > want to test it on 4.9 you need to replace dma_fence_put(), with > fence_put(). Just tested it on 4.9 (using fence_put()) and I can still get the warning sometimes: http://pastebin.com/p6acMLcY ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix the .fault functions
Commit 25d3db7600b87a4 ("mm, fs: reduce fault, page_mkwrite, and
pfn_mkwrite to take only vmf") causes the following build failure with
arm allmodconfig:
drivers/gpu/drm/armada/armada_gem.c:38:11: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
drivers/gpu/drm/etnaviv/etnaviv_drv.c:474:11: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
drivers/gpu/drm/etnaviv/etnaviv_gem.c:178:5: error: conflicting types for
'etnaviv_gem_fault'
drivers/gpu/drm/omapdrm/omap_drv.c:787:11: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
drivers/gpu/drm/omapdrm/omap_gem.c:531:5: error: conflicting types for
'omap_gem_fault'
Fix the conversion in some drm drivers.
Signed-off-by: Fabio Estevam
---
This build failure is from linux-next 20170125.
drivers/gpu/drm/armada/armada_gem.c | 3 ++-
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 2 +-
drivers/gpu/drm/omapdrm/omap_drv.h| 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index a293c8b..1ec0419 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -14,8 +14,9 @@
#include
#include "armada_ioctlP.h"
-static int armada_gem_vm_fault(struct vm_area_struct *vma, struct vm_fault
*vmf)
+static int armada_gem_vm_fault(struct vm_fault *vmf)
{
+ struct vm_area_struct *vma = vmf->vma;
struct armada_gem_object *obj = drm_to_armada_gem(vma->vm_private_data);
unsigned long pfn = obj->phys_addr >> PAGE_SHIFT;
int ret;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index c255eda..e41f386 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -73,7 +73,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
struct drm_file *file);
int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-int etnaviv_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
+int etnaviv_gem_fault(struct vm_fault *vmf);
int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64 *offset);
struct sg_table *etnaviv_gem_prime_get_sg_table(struct drm_gem_object *obj);
void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 7d9dd54..7a8f4bf 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -204,7 +204,7 @@ int omap_gem_dumb_create(struct drm_file *file, struct
drm_device *dev,
int omap_gem_mmap(struct file *filp, struct vm_area_struct *vma);
int omap_gem_mmap_obj(struct drm_gem_object *obj,
struct vm_area_struct *vma);
-int omap_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
+int omap_gem_fault(struct vm_fault *vmf);
int omap_gem_op_start(struct drm_gem_object *obj, enum omap_gem_op op);
int omap_gem_op_finish(struct drm_gem_object *obj, enum omap_gem_op op);
int omap_gem_op_sync(struct drm_gem_object *obj, enum omap_gem_op op);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: clear out fence when duplicating state
Hi Lucas, On Fri, Jan 27, 2017 at 8:33 AM, Lucas Stach wrote: > The fence needs to be cleared out, otherwise the following commit > might wait on a stale fence from the previous commit. This was fixed > as a side effect of 9626014258a5 (drm/fence: add in-fences support) > in kernel 4.10. > > As this commit introduces new functionality and as such can not be > applied to stable, this patch is the minimal fix for the kernel 4.9 > stable series. > > Signed-off-by: Lucas Stach Excellent: this fixes the kernel warning on 4.9.x. I can now stop kmscube several times without getting any kernel warning: Tested-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.
On Wed, Feb 1, 2017 at 2:04 PM, Breno Matheus Lima
wrote:
> Hi,
>
> I'm trying to use the Seiko 43WVF1G panel (Datasheet link:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS driver
> on
> the i.MX6SX SabreSD. Applying the patch below removes the old
> timing configuration on the dtsi and adds it to the panel-simple.c
> I can get the display working, but the image is out of place. Another point
> to
> note is that it's necessary to set the reg_lcd_3v3 to regulator-always-on
> otherwise the gpio3 27 does not get enabled.
>
> The main two problems that I'm having at the moment are:
>
> - Gpio3 27 is not being set by the driver, function
> panel_simple_prepare(struct drm_panel *panel) is not being called.
With the change below the regulator can be properly turned on:
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -103,12 +103,16 @@ static void mxsfb_pipe_enable(struct
drm_simple_display_pipe *pipe,
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
mxsfb_crtc_enable(mxsfb);
+ drm_panel_prepare(mxsfb->panel);
+ drm_panel_enable(mxsfb->panel);
}
static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ drm_panel_disable(mxsfb->panel);
+ drm_panel_unprepare(mxsfb->panel);
mxsfb_crtc_disable(mxsfb);
}
Marek, not sure if this is the correct place to call drm_panel_prepare/enable.
Any comments, please?
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mxsfb: Implement drm_panel handling
Currently when the 'power-supply' regulator is passed via device tree
it does not actually work since drm_panel_prepare()/drm_panel_enable()
are never called.
Quoting Thierry Reding: "It should really call drm_panel_prepare() and
drm_panel_enable() while switching on the display pipeline and
drm_panel_disable(), followed by drm_panel_unprepare() while switching
off the display pipeline."
So do as suggested, so that the 'power-supply' regulator can be functional.
Reported-by: Breno Lima
Suggested-by: Thierry Reding
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 955441f..766538f8 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -102,14 +102,18 @@ static void mxsfb_pipe_enable(struct
drm_simple_display_pipe *pipe,
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ drm_panel_prepare(mxsfb->panel);
mxsfb_crtc_enable(mxsfb);
+ drm_panel_enable(mxsfb->panel);
}
static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ drm_panel_disable(mxsfb->panel);
mxsfb_crtc_disable(mxsfb);
+ drm_panel_unprepare(mxsfb->panel);
}
static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.
On Wed, Feb 1, 2017 at 2:04 PM, Breno Matheus Lima wrote: > - The image is displaced even when using the same timing values in > the datasheet. Managed to fix this framebuffer displacement problem. Will submit a patch soon. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
Hi Thierry, On Thu, Feb 2, 2017 at 6:18 PM, Thierry Reding wrote: > Shawn, Fabio, anyone want to give this a Tested-by? I take it that this, > in combination with Fabio's patch to fix the displacement would make the > SabreSD display work properly? Yes, that is correct. It also needs the other patch I sent yesterday that allows the power-supply regulator to work. I was able to test it on a imx6sx-sdb board, so: Tested-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement
From: Fabio Estevam Currently the framebuffer content is displayed with incorrect offsets in both the vertical and horizontal directions. The fbdev version of the driver does not show this problem. Breno Lima dumped the eLCDIF controller registers on both the drm and fbdev drivers and noticed that the VDCTRL3 register is configured incorrectly in the drm driver. The fbdev driver calculates the vertical and horizontal wait counts of the VDCTRL3 register by doing: back porch + sync length. Looking at the horizontal and vertical timing diagram from include/drm/drm_modes.h this value corresponds to: crtc_[hv]total - crtc_[hv]sync_start So fix the VDCTRL3 register setting accordingly so that the eLCDIF controller can properly show the framebuffer content in the correct position. Reported-by: Breno Lima Signed-off-by: Fabio Estevam --- drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c index e10a4ed..b56f86c 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c @@ -184,8 +184,8 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb) VDCTRL2_SET_HSYNC_PERIOD(m->crtc_htotal), mxsfb->base + LCDC_VDCTRL2); - writel(SET_HOR_WAIT_CNT(m->crtc_hblank_end - m->crtc_hsync_end) | - SET_VERT_WAIT_CNT(m->crtc_vblank_end - m->crtc_vsync_end), + writel(SET_HOR_WAIT_CNT(m->crtc_htotal - m->crtc_hsync_start) | + SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start), mxsfb->base + LCDC_VDCTRL3); writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay), -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional
Hi Philipp,
On Tue, Jan 3, 2017 at 5:11 PM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
> regulator_set_voltage()") exposes the following probe issue:
>
> 63ff.tve supply dac not found, using dummy regulator
> imx-drm display-subsystem: failed to bind 63ff.tve (ops imx_tve_ops): -22
>
> When the 'dac' regulator is not passed in the device tree,
> devm_regulator_get() will return NULL and when regulator_set_voltage()
> is called it returns an error.
>
> Fix the issue by making the 'dac' regulator optional.
>
> Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
> regulator_set_voltage()")
> Cc: # 4.8+
> Signed-off-by: Fabio Estevam
Any comments, please?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge
On Sun, Feb 5, 2017 at 8:25 PM, Rob Herring wrote: > Did the bridge driver probe? This function just checks lists of > registered panels and bridges. The tda998x_probe() returns success, but tda998x_bind() is never called. I am trying to understand what needs to be done in drivers/gpu/drm/mxsfb/ so that it can bind the tda998x driver. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge
Hi Rob,
On Sat, Feb 4, 2017 at 1:36 AM, Rob Herring wrote:
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_out.c
> b/drivers/gpu/drm/mxsfb/mxsfb_out.c
> index fa8d17399407..f7d729aa09bd 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_out.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_out.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -82,20 +83,15 @@ static const struct drm_connector_funcs
> mxsfb_panel_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static int mxsfb_attach_endpoint(struct drm_device *drm,
> -const struct of_endpoint *ep)
> +int mxsfb_create_output(struct drm_device *drm)
> {
> struct mxsfb_drm_private *mxsfb = drm->dev_private;
> - struct device_node *np;
> struct drm_panel *panel;
> - int ret = -EPROBE_DEFER;
> -
> - np = of_graph_get_remote_port_parent(ep->local_node);
> - panel = of_drm_find_panel(np);
> - of_node_put(np);
> + int ret;
>
> - if (!panel)
> - return -EPROBE_DEFER;
> + ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, &panel,
> NULL);
> + if (ret)
> + return ret;
I fixed some build issues of this series and I am trying to use it
with the mxsfb drm driver.
I would like to add bridge support for this driver, so that I can use
the TDA19988 HDMI bridge on a imx6sx-udoo-neo-full board.
My dts looks like this:
--- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
@@ -185,6 +185,41 @@
};
};
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ clock-frequency = <10>;
+ status = "okay";
+
+ hdmi-transmitter@70 {
+ compatible = "nxp,tda998x";
+ reg = <0x70>;
+ pinctrl-0 = <&pinctrl_hdmi>;
+ pinctrl-names = "default";
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&clks IMX6SX_CLK_CKO2>;
+
+ port {
+ tda998x_input: endpoint {
+ remote-endpoint = <&lcdif1_output>;
+ };
+ };
+ };
+};
+
+&lcdif1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd>;
+ status = "okay";
+
+ port {
+ lcdif1_output: endpoint {
+ remote-endpoint = <&tda998x_input>;
+ };
+ };
+};
and I changed it to:
ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, &panel, &bridge);
,but drm_of_find_panel_or_bridge() always returns -EPROBE_DEFER.
Shouldn't it be able to find the bridge chip in this case? Any ideas
of what it is missing?
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge
On Sun, Feb 5, 2017 at 10:01 PM, Fabio Estevam wrote: > > The tda998x_probe() returns success, but tda998x_bind() is never called. > > I am trying to understand what needs to be done in > drivers/gpu/drm/mxsfb/ so that it can bind the tda998x driver. Looks like that converting to component style and adding component_bind_all() does the trick: [1.323772] tda998x 2-0070: found TDA19988 [1.342381] mxsfb 222.lcdif: bound 2-0070 (ops tda998x_ops) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional
Hi Philipp, On Tue, Feb 7, 2017 at 2:45 PM, Philipp Zabel wrote: > I've applied this to the fixes branch, since the current device trees > don't have the regulator set. I have sent a patch providing the dac-supply regulator for imx53-qsb: https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=for-next&id=042f6d98261d8edc225237acaeb627aeadbf54ad > Is this really optional, though? It would be better to add the correct > dac-supply to the device trees. The other TVE user is imx53-mba53.dts, but as I don't have its schematics I am not able to provide the regulator for it. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
Hi Rob, On Tue, Feb 7, 2017 at 4:49 PM, Rob Herring wrote: > No power supply(ies) for this panel? power-supply is mentioned in simple-panel.txt. >> +This binding is compatible with the simple-panel binding, which is specified >> +in simple-panel.txt in this directory. and this doc refers to simple-panel.txt. Isn't that enough? Seems like a common pattern for the other simple panel binding doc. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
On Tue, Feb 7, 2017 at 9:36 PM, Rob Herring wrote: > Except I have no way of knowing whether: a) you omitted a supply > because you don't (yet) care, b) the panel has a single supply and you > are using power-supply or c) the panel has multiple supplies and your > binding is wrong. > > I can only eliminate A if you list the supplies. Just need something > like "power-supply : see simple-panel.txt". I've still got to go read > the panel spec if I really want to check the binding. Just checked the panel datasheet at http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf and it lists two supplies: DVDD (Digital power supply) and AVDD (Analog power supply). Our dts was just providing a single 'power-supply' which referred to a GPIO enabled regulator that drives DVDD. So it seems we missed to pass AVDD (not software controlled in our case, but we need to describe it in dts anyway). Does this mean we cannot use simple-panel for this particular panel and we should add a separate driver for it? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional
On Wed, Feb 8, 2017 at 7:52 AM, Philipp Zabel wrote: > Good point, I suppose what the driver should really do is warn if the > voltage not set correctly? Yes, I can do as suggested. Will prepare a patch. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/imx: imx-tve: Do not set the regulator voltage
Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()") exposes the following probe issue:
63ff.tve supply dac not found, using dummy regulator
imx-drm display-subsystem: failed to bind 63ff.tve (ops imx_tve_ops): -22
When the 'dac-supply' is not passed in the device tree a dummy regulator is
used and setting its voltage is not allowed.
To fix this issue, do not set the dac-supply voltage inside the driver
and let its voltage be specified in the device tree.
Print a warning if the the 'dac-supply' voltage has a value different
from 2.75V.
Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()")
Cc: # 4.8+
Suggested-by: Lucas Stach
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/imx/imx-tve.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 8f8aa4a..f20a3e0 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -98,6 +98,8 @@
/* TVE_TST_MODE_REG */
#define TVE_TVDAC_TEST_MODE_MASK (0x7 << 0)
+#define IMX_TVE_DAC_VOLTAGE275
+
enum {
TVE_MODE_TVOUT,
TVE_MODE_VGA,
@@ -616,9 +618,9 @@ static int imx_tve_bind(struct device *dev, struct device
*master, void *data)
tve->dac_reg = devm_regulator_get(dev, "dac");
if (!IS_ERR(tve->dac_reg)) {
- ret = regulator_set_voltage(tve->dac_reg, 275, 275);
- if (ret)
- return ret;
+ if (regulator_get_voltage(tve->dac_reg) != IMX_TVE_DAC_VOLTAGE)
+ dev_warn(dev, "dac voltage is %d uV instead of %d uV\n",
+ret, IMX_TVE_DAC_VOLTAGE);
ret = regulator_enable(tve->dac_reg);
if (ret)
return ret;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/imx: imx-tve: Do not set the regulator voltage
Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()") exposes the following probe issue:
63ff.tve supply dac not found, using dummy regulator
imx-drm display-subsystem: failed to bind 63ff.tve (ops imx_tve_ops): -22
When the 'dac-supply' is not passed in the device tree a dummy regulator is
used and setting its voltage is not allowed.
To fix this issue, do not set the dac-supply voltage inside the driver
and let its voltage be specified in the device tree.
Print a warning if the the 'dac-supply' voltage has a value different
from 2.75V.
Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()")
Cc: # 4.8+
Suggested-by: Lucas Stach
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Fix the warning message. When a 'dac-supply' node is not passed we cannot
print the regulator_get_voltage() value.
drivers/gpu/drm/imx/imx-tve.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 8f8aa4a..4826bb7 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -98,6 +98,8 @@
/* TVE_TST_MODE_REG */
#define TVE_TVDAC_TEST_MODE_MASK (0x7 << 0)
+#define IMX_TVE_DAC_VOLTAGE275
+
enum {
TVE_MODE_TVOUT,
TVE_MODE_VGA,
@@ -616,9 +618,8 @@ static int imx_tve_bind(struct device *dev, struct device
*master, void *data)
tve->dac_reg = devm_regulator_get(dev, "dac");
if (!IS_ERR(tve->dac_reg)) {
- ret = regulator_set_voltage(tve->dac_reg, 275, 275);
- if (ret)
- return ret;
+ if (regulator_get_voltage(tve->dac_reg) != IMX_TVE_DAC_VOLTAGE)
+ dev_warn(dev, "dac voltage is not %d uV\n",
IMX_TVE_DAC_VOLTAGE);
ret = regulator_enable(tve->dac_reg);
if (ret)
return ret;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: imxdrm issue on Hummingboard with LVDS enabled
Hi Russell, On Sun, Feb 12, 2017 at 11:18 AM, Russell King - ARM Linux wrote: > Hi, > > Here's another issue with imxdrm. I got this while trying to reproduce > Dan's problem by enabling the lvds output using the patch below > originally from Fabio, but updated a bit. This doesn't occur if I leave > LVDS disabled. > > The taint is due to the IMX capture modules from Steve, who chose to put > his code in drivers/staging/media rather than drivers/media. However, > the last module to make the capture stuff active (imx-csi) which interfaces > the drivers/gpu/ipu-v3 code with the capture code has not been loaded. > > [ cut here ] > WARNING: CPU: 1 PID: 1049 at > /home/rmk/git/linux-rmk/drivers/gpu/drm/drm_atomic_helper.c:1149 > drm_atomic_helper_wait_for_vblanks+0x218/0x224 > [CRTC:29] vblank wait timed out I am getting the same warning when trying to add HDMI support on imx6sx-udoo-neo board via TDA19988: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. tda998x 2-0070: Falling back to first CRTC random: fast init done tda998x 2-0070: found TDA19988 mxsfb 222.lcdif: bound 2-0070 (ops tda998x_ops) [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. [ cut here ] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1149 drm_atomic_helper_wait_for_vblanks+00 [CRTC:26] vblank wait timed out Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc7-00034-g2217172 #155 Hardware name: Freescale i.MX6 SoloX (Device Tree) Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r7: r6:6013 r5: r4:c0e29258 [] (show_stack) from [] (dump_stack+0xb4/0xe8) [] (dump_stack) from [] (__warn+0xd8/0x104) r9:c04d63ac r8:047d r7:0009 r6:c0c1f2b4 r5: r4:ef05f8c8 [] (__warn) from [] (warn_slowpath_fmt+0x3c/0x44) r9:ef35 r8:ef037028 r7: r6:ef3bd600 r5:ef3d2c00 r4:c0c1f3d0 [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks+0x230/0x240) r3:001a r2:c0c1f3d0 r4: [] (drm_atomic_helper_wait_for_vblanks) from [] (drm_atomic_helper_commit_tail+0x50) r10:0001 r9:ef3cd100 r8:ef350484 r7:ef35 r6: r5:ef35 r4:ef3d2c00 I haven't had a chance to debug this yet. If anyone makes any progress, please keep me on Cc. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/fsl-dcu: Remove unneeded NULL check
devm_ioremap_resource() performs NULL check for the 'res' argument,
so remove the unneeded check.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 0b0d1cb..812a211 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -336,11 +336,6 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
fsl_dev->soc = id->data;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "could not get memory IO resource\n");
- return -ENODEV;
- }
-
base = devm_ioremap_resource(dev, res);
if (IS_ERR(base)) {
ret = PTR_ERR(base);
--
2.7.4
[PATCH 2/2] drm/fsl-dcu: Propagate the real error code
In case of platform_get_irq() failure, let's propagate the real
error code, instead of a 'fake' one.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 812a211..143e639 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -345,7 +345,7 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
fsl_dev->irq = platform_get_irq(pdev, 0);
if (fsl_dev->irq < 0) {
dev_err(dev, "failed to get irq\n");
- return -ENXIO;
+ return fsl_dev->irq;
}
fsl_dev->regmap = devm_regmap_init_mmio(dev, base,
--
2.7.4
Question regarding clocks in the DW-HDMI DT bindings
Hi Laurent, On Thu, Nov 24, 2016 at 7:16 PM, Laurent Pinchart wrote: > Hi Andy, > > As the author of the DW-HDMI DT bindings this question is addressed to you, > but information from anyone is more than welcome. > > The DT bindings specify two clocks named "iahb" and "isfr" but don't describe > them. While I assume that the "isfr" clock corresponds to the "isfrclk" input > signal of the DW HDMI, there is no "iahb" clock described in the IP core > datasheet. i.MX6Q has a DW-HDMI IP block. The names in the devicetree binding matches the ones listed at the i.MX6Q Reference Manual - Table 33-1. HDMI Clocks Regards, Fabio Estevam
Question regarding clocks in the DW-HDMI DT bindings
On Thu, Nov 24, 2016 at 8:16 PM, Vladimir Zapolskiy wrote: > correct, for your convenience the table is copied below: > > Clock name | Clock Root | Description > ---++--- > iahbclk | ahb_clk_root | Bus clock > icecclk | ckil_sync_clk_root | CEC low-frequency clock (32kHZ) > ihclk| ahb_clk_root | Module clock > isfrclk | video_27m_clk_root | Internal SFR clock (video clock 27MHz) > > Here AHB stands for ARM Advanced High-performance Bus. > > By the way while we're discussing DW HDMI bindings specific to iMX, > I would recommend to remove utterly hackish and iMX only "gpr" > property from the example in bindings/display/bridge/dw_hdmi.txt Yes, the "gpr" property is i.MX specific and it is described in Documentation/devicetree/bindings/display/imx/hdmi.txt, so we can remove it from dw_hdmi.txt. Will send a patch removing it. Thanks
[PATCH] drm: dw_hdmi: Remove non-standard "gpr" property
From: Fabio Estevam The "gpr" property is i.MX specific and is documented at Documentation/devicetree/bindings/display/imx/hdmi.txt, so remove such non-standard property from the common binding doc. Suggested-by: Vladimir Zapolskiy Signed-off-by: Fabio Estevam --- Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt index 5e9a84d..684eb10 100644 --- a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt +++ b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt @@ -29,7 +29,6 @@ Example: compatible = "fsl,imx6q-hdmi"; reg = <0x0012 0x9000>; interrupts = <0 115 0x04>; - gpr = <&gpr>; clocks = <&clks 123>, <&clks 124>; clock-names = "iahb", "isfr"; ddc-i2c-bus = <&i2c2>; -- 2.7.4
Question regarding clocks in the DW-HDMI DT bindings
Hi Vladimir,
On Thu, Nov 24, 2016 at 8:16 PM, Vladimir Zapolskiy
wrote:
> By the way while we're discussing DW HDMI bindings specific to iMX,
> I would recommend to remove utterly hackish and iMX only "gpr"
> property from the example in bindings/display/bridge/dw_hdmi.txt
What if we get rid of the "gpr" property completely?
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -99,9 +99,8 @@ static const struct dw_hdmi_phy_config imx_phy_config[] = {
static int dw_hdmi_imx_parse_dt(struct imx_hdmi *hdmi)
{
- struct device_node *np = hdmi->dev->of_node;
+ hdmi->regmap =
syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
- hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "gpr");
if (IS_ERR(hdmi->regmap)) {
dev_err(hdmi->dev, "Unable to get gpr\n");
return PTR_ERR(hdmi->regmap);
Then we can remove the gpr from the device tree files.
Question regarding clocks in the DW-HDMI DT bindings
Hi Laurent, On Thu, Nov 24, 2016 at 9:26 PM, Laurent Pinchart wrote: > Another question I have about the bus clock (CC'ing the devicetree mailing > list as well as the clock maintainers) is whether it should be made optional. > The clock is obviously mandatory from a hardware point of view (given that APB > is a synchronous bus and thus requires a clock), but in some SoCs > (specifically for the Renesas SoCs) that clock is always on and can't be > controlled. We already omit bus clocks in DT for most IP cores when the clock > can never be controlled (and we also omit a bunch of other clocks that we > don't even know exist), so it could make sense to make the clock optional. > Otherwise there would be runtime overhead trying to handle a clock that can't > be controlled. What if you register the clock as a "dummy" clock instead?
Question regarding clocks in the DW-HDMI DT bindings
Hi Vladimir, On Fri, Nov 25, 2016 at 11:00 AM, Vladimir Zapolskiy wrote: > according to the DTSI files in the vanilla kernel DW HDMI IP is found > only on iMX6Q/D and iMX6DL/iMX6S SoCs (but please double check it), > so this approach should work ideally. After thinking more about this I think we can not get rid of "gpr". If we have a new i.MX SoC that is not compatible with "fsl,imx6q-iomuxc-gpr" then the lookup will fail. > I see that the same has already been done in PCIe and SATA drivers, > but please consider to send a similar change against iMX LDB driver The i.MX LDB driver is also used on imx53, so we cannot search for "fsl,imx6q-iomuxc-gpr" compatible, as it will fail on imx53. So it seems we need to keep the "gpr" property in this case.
Question regarding clocks in the DW-HDMI DT bindings
On Fri, Nov 25, 2016 at 1:22 PM, Laurent Pinchart wrote: >> I got the clock name from I.MX6Q TRM, I also checked the name again >> with Rockchip IC design team now, hope to get some new information soon. > > Thank you. While at it, could you ask them which version of the DW HDMI IP > used in the SoC ? DW HDMI IP used in Rockchip is: dwhdmi-rockchip ff98.hdmi: Detected HDMI controller 0x20:0xa:0xa0:0xc1 as shown at https://storage.kernelci.org/mainline/v4.9-rc6-157-g16ae16c6e561/arm-multi_v7_defconfig/lab-collabora/boot-rk3288-rock2-square_rootfs:nfs.html DW HDMI IP used on mx6q is: dwhdmi-imx 12.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1
Re: [PATCH] drm/panel: Add driver for Seiko 43WVF1G panel
Thierry/Rob, On Mon, May 8, 2017 at 10:54 AM, Fabio Estevam wrote: > On Tue, Apr 25, 2017 at 1:18 PM, Marco Franchi wrote: >> Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) >> TFT with Touch-Panel. >> >> Datasheet available at: >> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf >> >> Seiko 43WVF1G panel has two power supplies: AVDD and DVDD and they >> require a specific power on/down sequence. >> For this reason the simple panel driver cannot be used to drive this >> panel, so create a new one heavily based on simple panel. >> >> Based on initial patch submission from Breno Lima. >> >> Signed-off-by: Marco Franchi > > Works fine on a imx6sx-sdb board: > > Tested-by: Fabio Estevam Does this look good for you? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller
Hi Marek, On Mon, Jun 5, 2017 at 9:08 AM, Marek Vasut wrote: > I'm currently on vacation, try one more time and if it doesn't work out > (which means this trivial list is not really working?), I'll send a PR > sometime mid-month. Tried your suggestion, but it did not work. Could you please consider sending Dave Airlie a pull request with this patch? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: Add driver for Seiko 43WVF1G panel
Hi Rob,
On Wed, Jun 14, 2017 at 2:49 PM, Thierry Reding
wrote:
> On Tue, Apr 25, 2017 at 01:18:35PM -0300, Marco Franchi wrote:
>> Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
>> TFT with Touch-Panel.
>>
>> Datasheet available at:
>> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
>>
>> Seiko 43WVF1G panel has two power supplies: AVDD and DVDD and they
>> require a specific power on/down sequence.
>> For this reason the simple panel driver cannot be used to drive this
>> panel, so create a new one heavily based on simple panel.
>>
>> Based on initial patch submission from Breno Lima.
>>
>> Signed-off-by: Marco Franchi
>> ---
>> .../bindings/display/panel/seiko,43wvf1g.txt | 23 ++
>> drivers/gpu/drm/panel/Kconfig | 9 +
>> drivers/gpu/drm/panel/Makefile | 1 +
>> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c| 372
>> +
>> 4 files changed, 405 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt
>> create mode 100644 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt
>> b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt
>> new file mode 100644
>> index 000..cd1eeda
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt
>> @@ -0,0 +1,23 @@
>> +Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel
>> +
>> +Required properties:
>> +- compatible: should be "sii,43wvf1g".
>> +- "DVDD-supply": 3v3 digital regulator.
>> +- "AVDD-supply": 5v analog regulator.
>
> I don't think we should be using all-uppercase for supply names. So the
> above should be "dvdd-supply" and "avdd-supply". No need to resend only
> for that change, I can fix it up when applying.
>
> Rob, can I have your Acked-by with the above change?
Any comment, please? It would be nice if we can get this into 4.13, if possible.
>
> Just two minor comments below.
>
>> diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
>> b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
> [...]
>> +struct seiko_panel_desc {
>> + const struct drm_display_mode *modes;
>> + unsigned int num_modes;
>> + const struct display_timing *timings;
>> + unsigned int num_timings;
>> +
>> + unsigned int bpc;
>> +
>> + /**
>> + * @width: width (in millimeters) of the panel's active display area
>> + * @height: height (in millimeters) of the panel's active display area
>> + */
>> + struct {
>> + unsigned int width;
>> + unsigned int height;
>> + } size;
>> +
>> + u32 bus_format;
>> + u32 bus_flags;
>> +};
>
> It's somewhat unfortunate how this has to duplicate a lot of the
> panel-simple driver just because it uses two regulators. However, with
> some of the work going on to make panel-simple code more reusable this
> might improve in the future. For now I think this doesn't hurt.
>
>> +struct seiko_panel {
>> + struct drm_panel base;
>> + bool prepared;
>> + bool enabled;
>> + const struct seiko_panel_desc *desc;
>> + struct backlight_device *backlight;
>> + struct regulator *DVDD;
>> + struct regulator *AVDD;
>> +};
>
> Same as for the binding: we don't use all-uppercase names for variables,
> so I'll fix those up to be lowercase when applying.
>
> Thierry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: Add driver for Seiko 43WVF1G panel
Rob, On Wed, Jun 14, 2017 at 2:49 PM, Thierry Reding wrote: >> +Required properties: >> +- compatible: should be "sii,43wvf1g". >> +- "DVDD-supply": 3v3 digital regulator. >> +- "AVDD-supply": 5v analog regulator. > > I don't think we should be using all-uppercase for supply names. So the > above should be "dvdd-supply" and "avdd-supply". No need to resend only > for that change, I can fix it up when applying. > > Rob, can I have your Acked-by with the above change? Any comments? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: simple: Skip error message on deferred probe
From: Fabio Estevam
When enable_gpio is provided via an I2C or SPI expander, it may not be
available when panel-simple probes leading to the following error:
panel-simple panel: failed to request GPIO: -517
As this error message is not very useful to the end user, skip printing
it in the case of deferred probe.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/panel/panel-simple.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 474fa75..9469c4d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -315,7 +315,8 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
GPIOD_OUT_LOW);
if (IS_ERR(panel->enable_gpio)) {
err = PTR_ERR(panel->enable_gpio);
- dev_err(dev, "failed to request GPIO: %d\n", err);
+ if (err != -EPROBE_DEFER)
+ dev_err(dev, "failed to request GPIO: %d\n", err);
return err;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/bridge: ti-tfp410: support hpd via gpio
Hi Christopher, On Mon, Mar 6, 2017 at 6:40 PM, wrote: > From: Christopher Spinrath > > On some boards the hpd pin of a hdmi connector is wired up to a gpio > pin. Since in the DRM world the tfp410 driver is responsible for > handling the connector, add support for hpd gpios in this very driver. > > Signed-off-by: Christopher Spinrath > --- > drivers/gpu/drm/bridge/ti-tfp410.c | 72 > -- It would be nice to add 'hpd-gpios' property in the binding doc as well: Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: mxsfb_crtc: Reset the eLCDIF controller
According to the eLCDIF initialization steps listed in the MX6SX
Reference Manual the eLCDIF block reset is mandatory.
Without performing the eLCDIF reset the display shows garbage content
when the kernel boots.
In earlier tests this issue has not been observed because the bootloader
was previously showing a splash screen and the bootloader display driver
does properly implement the eLCDIF reset.
Add the eLCDIF reset to the driver, so that it can operate correctly
independently of the bootloader.
Tested on a imx6sx-sdb board.
Cc:
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Use readl_poll_timeout() - Marek
- Remove unneeded comments
Marek,
As to your other suggestion, we cannot put mxsfb_reset_block() inside
the probe function.
According to the Reference Manual the reset step is after the clock
is enabled and prior to setting the pixel format, so the current
location is the correct one.
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 43 ++
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 1144e0c..69a9baf 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -35,6 +35,13 @@
#include "mxsfb_drv.h"
#include "mxsfb_regs.h"
+#define MXS_SET_ADDR 0x4
+#define MXS_CLR_ADDR 0x8
+#define MODULE_CLKGATE BIT(30)
+#define MODULE_SFTRST BIT(31)
+/* 1 second delay should be plenty of time for block reset */
+#define RESET_TIMEOUT 100
+
static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val)
{
return (val & mxsfb->devdata->hs_wdth_mask) <<
@@ -159,6 +166,37 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
clk_disable_unprepare(mxsfb->clk_disp_axi);
}
+/*
+ * Clear the bit and poll it cleared. This is usually called with
+ * a reset address and mask being either SFTRST(bit 31) or CLKGATE
+ * (bit 30).
+ */
+static int clear_poll_bit(void __iomem *addr, u32 mask)
+{
+ u32 reg;
+
+ writel(mask, addr + MXS_CLR_ADDR);
+ udelay(1);
+ return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
+}
+
+static int mxsfb_reset_block(void __iomem *reset_addr)
+{
+ int ret;
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ return clear_poll_bit(reset_addr, MODULE_CLKGATE);
+}
+
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
{
struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
@@ -173,6 +211,11 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
*/
mxsfb_enable_axi_clk(mxsfb);
+ /* Mandatory eLCDIF reset as per the Reference Manual */
+ err = mxsfb_reset_block(mxsfb->base);
+ if (err)
+ return;
+
/* Clear the FIFOs */
writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mxsfb_crtc: Reset the eLCDIF controller
According to the eLCDIF initialization steps listed in the MX6SX
Reference Manual the eLCDIF block reset is mandatory.
Without performing the eLCDIF reset the display shows garbage content
when the kernel boots.
In earlier tests this issue has not been observed because the bootloader
was previously showing a splash screen and the bootloader display driver
does properly implement the eLCDIF reset.
Add the eLCDIF reset to the driver, so that it can operate correctly
independently of the bootloader.
Tested on a imx6sx-sdb board.
Cc:
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 53 ++
1 file changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 1144e0c..47e0941 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -35,6 +35,13 @@
#include "mxsfb_drv.h"
#include "mxsfb_regs.h"
+#define MXS_SET_ADDR 0x4
+#define MXS_CLR_ADDR 0x8
+#define MODULE_CLKGATE BIT(30)
+#define MODULE_SFTRST BIT(31)
+/* 1 second delay should be plenty of time for block reset. */
+#define RESET_MAX_TIMEOUT 100
+
static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val)
{
return (val & mxsfb->devdata->hs_wdth_mask) <<
@@ -159,6 +166,48 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
clk_disable_unprepare(mxsfb->clk_disp_axi);
}
+/*
+ * Clear the bit and poll it cleared. This is usually called with
+ * a reset address and mask being either SFTRST(bit 31) or CLKGATE
+ * (bit 30).
+ */
+static int clear_poll_bit(void __iomem *addr, u32 mask)
+{
+ unsigned int timeout = RESET_MAX_TIMEOUT;
+
+ /* clear the bit */
+ writel(mask, addr + MXS_CLR_ADDR);
+
+ udelay(1);
+
+ /* poll the bit becoming clear */
+ while ((readl(addr) & mask) && --timeout)
+ ;
+
+ return !timeout;
+}
+
+static int mxsfb_reset_block(void __iomem *reset_addr)
+{
+ int ret;
+
+ /* clear and poll SFTRST */
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ /* clear CLKGATE */
+ writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
+
+ /* clear and poll SFTRST */
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ /* clear and poll CLKGATE */
+ return clear_poll_bit(reset_addr, MODULE_CLKGATE);
+}
+
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
{
struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
@@ -173,6 +222,10 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
*/
mxsfb_enable_axi_clk(mxsfb);
+ err = mxsfb_reset_block(mxsfb->base);
+ if (err)
+ return;
+
/* Clear the FIFOs */
writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller
According to the eLCDIF initialization steps listed in the MX6SX
Reference Manual the eLCDIF block reset is mandatory.
Without performing the eLCDIF reset the display shows garbage content
when the kernel boots.
In earlier tests this issue has not been observed because the bootloader
was previously showing a splash screen and the bootloader display driver
does properly implement the eLCDIF reset.
Add the eLCDIF reset to the driver, so that it can operate correctly
independently of the bootloader.
Tested on a imx6sx-sdb board.
Cc:
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Remove unneeded udelay(1) - Marek
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 1144e0c..0abe776 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -35,6 +35,13 @@
#include "mxsfb_drv.h"
#include "mxsfb_regs.h"
+#define MXS_SET_ADDR 0x4
+#define MXS_CLR_ADDR 0x8
+#define MODULE_CLKGATE BIT(30)
+#define MODULE_SFTRST BIT(31)
+/* 1 second delay should be plenty of time for block reset */
+#define RESET_TIMEOUT 100
+
static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val)
{
return (val & mxsfb->devdata->hs_wdth_mask) <<
@@ -159,6 +166,36 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
clk_disable_unprepare(mxsfb->clk_disp_axi);
}
+/*
+ * Clear the bit and poll it cleared. This is usually called with
+ * a reset address and mask being either SFTRST(bit 31) or CLKGATE
+ * (bit 30).
+ */
+static int clear_poll_bit(void __iomem *addr, u32 mask)
+{
+ u32 reg;
+
+ writel(mask, addr + MXS_CLR_ADDR);
+ return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
+}
+
+static int mxsfb_reset_block(void __iomem *reset_addr)
+{
+ int ret;
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ return clear_poll_bit(reset_addr, MODULE_CLKGATE);
+}
+
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
{
struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
@@ -173,6 +210,11 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
*/
mxsfb_enable_axi_clk(mxsfb);
+ /* Mandatory eLCDIF reset as per the Reference Manual */
+ err = mxsfb_reset_block(mxsfb->base);
+ if (err)
+ return;
+
/* Clear the FIFOs */
writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: Add driver for Seiko 43WVF1G panel
On Tue, Apr 25, 2017 at 1:18 PM, Marco Franchi wrote: > Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) > TFT with Touch-Panel. > > Datasheet available at: > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf > > Seiko 43WVF1G panel has two power supplies: AVDD and DVDD and they > require a specific power on/down sequence. > For this reason the simple panel driver cannot be used to drive this > panel, so create a new one heavily based on simple panel. > > Based on initial patch submission from Breno Lima. > > Signed-off-by: Marco Franchi Works fine on a imx6sx-sdb board: Tested-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller
Hi Marek, On Fri, May 5, 2017 at 3:01 PM, Fabio Estevam wrote: > According to the eLCDIF initialization steps listed in the MX6SX > Reference Manual the eLCDIF block reset is mandatory. > > Without performing the eLCDIF reset the display shows garbage content > when the kernel boots. > > In earlier tests this issue has not been observed because the bootloader > was previously showing a splash screen and the bootloader display driver > does properly implement the eLCDIF reset. > > Add the eLCDIF reset to the driver, so that it can operate correctly > independently of the bootloader. > > Tested on a imx6sx-sdb board. > > Cc: > Signed-off-by: Fabio Estevam > --- > Changes since v2: > > - Remove unneeded udelay(1) - Marek Any comments about v3? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller
Hi Marek, On Mon, May 22, 2017 at 11:20 AM, Marek Vasut wrote: > IMO it's OK. > > Reviewed-by: Marek Vasut Thanks for the feedback. Do you plan to send Dave a pull request so that this one can reach 4.12-rc? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] drm: mxsfb_crtc: Reset the eLCDIF controller
From: Fabio Estevam
According to the eLCDIF initialization steps listed in the MX6SX
Reference Manual the eLCDIF block reset is mandatory.
Without performing the eLCDIF reset the display shows garbage content
when the kernel boots.
In earlier tests this issue has not been observed because the bootloader
was previously showing a splash screen and the bootloader display driver
does properly implement the eLCDIF reset.
Add the eLCDIF reset to the driver, so that it can operate correctly
independently of the bootloader.
Tested on a imx6sx-sdb board.
Cc: #4.11.x
Signed-off-by: Fabio Estevam
Reviewed-by: Marek Vasut
---
Daniel,
Marek suggested that this goes via drm-misc.
Thanks
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 1144e0c..0abe776 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -35,6 +35,13 @@
#include "mxsfb_drv.h"
#include "mxsfb_regs.h"
+#define MXS_SET_ADDR 0x4
+#define MXS_CLR_ADDR 0x8
+#define MODULE_CLKGATE BIT(30)
+#define MODULE_SFTRST BIT(31)
+/* 1 second delay should be plenty of time for block reset */
+#define RESET_TIMEOUT 100
+
static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val)
{
return (val & mxsfb->devdata->hs_wdth_mask) <<
@@ -159,6 +166,36 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
clk_disable_unprepare(mxsfb->clk_disp_axi);
}
+/*
+ * Clear the bit and poll it cleared. This is usually called with
+ * a reset address and mask being either SFTRST(bit 31) or CLKGATE
+ * (bit 30).
+ */
+static int clear_poll_bit(void __iomem *addr, u32 mask)
+{
+ u32 reg;
+
+ writel(mask, addr + MXS_CLR_ADDR);
+ return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
+}
+
+static int mxsfb_reset_block(void __iomem *reset_addr)
+{
+ int ret;
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ return clear_poll_bit(reset_addr, MODULE_CLKGATE);
+}
+
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
{
struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
@@ -173,6 +210,11 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
*/
mxsfb_enable_axi_clk(mxsfb);
+ /* Mandatory eLCDIF reset as per the Reference Manual */
+ err = mxsfb_reset_block(mxsfb->base);
+ if (err)
+ return;
+
/* Clear the FIFOs */
writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] drm: mxsfb_crtc: Reset the eLCDIF controller
On Mon, May 22, 2017 at 5:53 PM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> According to the eLCDIF initialization steps listed in the MX6SX
> Reference Manual the eLCDIF block reset is mandatory.
>
> Without performing the eLCDIF reset the display shows garbage content
> when the kernel boots.
>
> In earlier tests this issue has not been observed because the bootloader
> was previously showing a splash screen and the bootloader display driver
> does properly implement the eLCDIF reset.
>
> Add the eLCDIF reset to the driver, so that it can operate correctly
> independently of the bootloader.
>
> Tested on a imx6sx-sdb board.
>
> Cc: #4.11.x
> Signed-off-by: Fabio Estevam
> Reviewed-by: Marek Vasut
> ---
> Daniel,
>
> Marek suggested that this goes via drm-misc.
Sean/Jani/Daniel,
Any chance this could go via drm-misc?
Without this change the mxsfb driver is unusable on some platforms.
Thanks
>
> Thanks
>
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42
> ++
> 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index 1144e0c..0abe776 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -35,6 +35,13 @@
> #include "mxsfb_drv.h"
> #include "mxsfb_regs.h"
>
> +#define MXS_SET_ADDR 0x4
> +#define MXS_CLR_ADDR 0x8
> +#define MODULE_CLKGATE BIT(30)
> +#define MODULE_SFTRST BIT(31)
> +/* 1 second delay should be plenty of time for block reset */
> +#define RESET_TIMEOUT 100
> +
> static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val)
> {
> return (val & mxsfb->devdata->hs_wdth_mask) <<
> @@ -159,6 +166,36 @@ static void mxsfb_disable_controller(struct
> mxsfb_drm_private *mxsfb)
> clk_disable_unprepare(mxsfb->clk_disp_axi);
> }
>
> +/*
> + * Clear the bit and poll it cleared. This is usually called with
> + * a reset address and mask being either SFTRST(bit 31) or CLKGATE
> + * (bit 30).
> + */
> +static int clear_poll_bit(void __iomem *addr, u32 mask)
> +{
> + u32 reg;
> +
> + writel(mask, addr + MXS_CLR_ADDR);
> + return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
> +}
> +
> +static int mxsfb_reset_block(void __iomem *reset_addr)
> +{
> + int ret;
> +
> + ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
> + if (ret)
> + return ret;
> +
> + writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
> +
> + ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
> + if (ret)
> + return ret;
> +
> + return clear_poll_bit(reset_addr, MODULE_CLKGATE);
> +}
> +
> static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
> {
> struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
> @@ -173,6 +210,11 @@ static void mxsfb_crtc_mode_set_nofb(struct
> mxsfb_drm_private *mxsfb)
> */
> mxsfb_enable_axi_clk(mxsfb);
>
> + /* Mandatory eLCDIF reset as per the Reference Manual */
> + err = mxsfb_reset_block(mxsfb->base);
> + if (err)
> + return;
> +
> /* Clear the FIFOs */
> writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
>
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller
Hi Marek, On Mon, May 22, 2017 at 5:33 PM, Marek Vasut wrote: >> Do you plan to send Dave a pull request so that this one can reach 4.12-rc? > > You could probably get it in via drm-misc ? I tried it, but no response so far. Care to send Dave a pull request so that this one can get into 4.12-rc? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] drm: mxsfb_crtc: Reset the eLCDIF controller
From: Fabio Estevam
According to the eLCDIF initialization steps listed in the MX6SX
Reference Manual the eLCDIF block reset is mandatory.
Without performing the eLCDIF reset the display shows garbage content
when the kernel boots.
In earlier tests this issue has not been observed because the bootloader
was previously showing a splash screen and the bootloader display driver
does properly implement the eLCDIF reset.
Add the eLCDIF reset to the driver, so that it can operate correctly
independently of the bootloader.
Tested on a imx6sx-sdb board.
Cc: #4.11.x
Signed-off-by: Fabio Estevam
Reviewed-by: Marek Vasut
---
Dear drm-misc maintainers,
Marek suggested that this goes via drm-misc.
Thanks
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 1144e0c..0abe776 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -35,6 +35,13 @@
#include "mxsfb_drv.h"
#include "mxsfb_regs.h"
+#define MXS_SET_ADDR 0x4
+#define MXS_CLR_ADDR 0x8
+#define MODULE_CLKGATE BIT(30)
+#define MODULE_SFTRST BIT(31)
+/* 1 second delay should be plenty of time for block reset */
+#define RESET_TIMEOUT 100
+
static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val)
{
return (val & mxsfb->devdata->hs_wdth_mask) <<
@@ -159,6 +166,36 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
clk_disable_unprepare(mxsfb->clk_disp_axi);
}
+/*
+ * Clear the bit and poll it cleared. This is usually called with
+ * a reset address and mask being either SFTRST(bit 31) or CLKGATE
+ * (bit 30).
+ */
+static int clear_poll_bit(void __iomem *addr, u32 mask)
+{
+ u32 reg;
+
+ writel(mask, addr + MXS_CLR_ADDR);
+ return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
+}
+
+static int mxsfb_reset_block(void __iomem *reset_addr)
+{
+ int ret;
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ return clear_poll_bit(reset_addr, MODULE_CLKGATE);
+}
+
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
{
struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
@@ -173,6 +210,11 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
*/
mxsfb_enable_axi_clk(mxsfb);
+ /* Mandatory eLCDIF reset as per the Reference Manual */
+ err = mxsfb_reset_block(mxsfb->base);
+ if (err)
+ return;
+
/* Clear the FIFOs */
writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/4] IPUv3 prep for i.MX5/6 v4l2 staging drivers, v4
Hi Philipp, On Thu, Aug 25, 2016 at 11:17 AM, Tim Harvey wrote: > Philipp, > > Have you had a chance to review this last series of Steve's submitted > last week? We are down to 4 patches in gpu/ipu-v3 needed in order to > get his IMX5/6 capture driver into staging and the sooner we do that > the sooner we can get more testing and additional support/features for > it. Do these patches look good to you? It would be nice to get them into 4.9 if possible. Thanks
[PATCH RESEND] drm/fsl-dcu: disable clock on error path
From: Fabio Estevam
In fsl_dcu_drm_pm_resume() we should disable the previously enabled
clock (fsl_dev->clk) when enabling fsl_dev->pix_clk fails.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 7882387..76ae558 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -270,7 +270,7 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
ret = clk_prepare_enable(fsl_dev->pix_clk);
if (ret < 0) {
dev_err(dev, "failed to enable pix clk\n");
- return ret;
+ goto disable_dcu_clk;
}
fsl_dcu_drm_init_planes(fsl_dev->drm);
@@ -284,6 +284,10 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
enable_irq(fsl_dev->irq);
return 0;
+
+disable_dcu_clk:
+ clk_disable_unprepare(fsl_dev->clk);
+ return ret;
}
#endif
--
1.9.1
[RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite
On Mon, Sep 19, 2016 at 4:02 PM, Randy Li wrote:
> + vcc_sys_lcd: sys-lcd {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_5v";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
Is this really active high? If so, you should add the
'enable-active-high' property.
[PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional
From: Fabio Estevam
Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()") exposes the following probe issue:
63ff.tve supply dac not found, using dummy regulator
imx-drm display-subsystem: failed to bind 63ff.tve (ops imx_tve_ops): -22
When the 'dac' regulator is not passed in the device tree,
devm_regulator_get() will return NULL and when regulator_set_voltage()
is called it returns an error.
Fix the issue by making the 'dac' regulator optional.
Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()")
Cc: # 4.8+
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/imx/imx-tve.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 3b602ee..cec0e12 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -619,7 +619,7 @@ static int imx_tve_bind(struct device *dev, struct device
*master, void *data)
return ret;
}
- tve->dac_reg = devm_regulator_get(dev, "dac");
+ tve->dac_reg = devm_regulator_get_optional(dev, "dac");
if (!IS_ERR(tve->dac_reg)) {
ret = regulator_set_voltage(tve->dac_reg, 275, 275);
if (ret)
--
2.7.4
[PATCH] drm/imx: imx-tve: Remove unused variable
'ret' is never used in tve_enable/tve_disable(), so just
remove it.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/imx/imx-tve.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 3b602ee..8f8aa4a 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -150,13 +150,11 @@ __releases(&tve->lock)
static void tve_enable(struct imx_tve *tve)
{
- int ret;
-
if (!tve->enabled) {
tve->enabled = true;
clk_prepare_enable(tve->clk);
- ret = regmap_update_bits(tve->regmap, TVE_COM_CONF_REG,
-TVE_EN, TVE_EN);
+ regmap_update_bits(tve->regmap, TVE_COM_CONF_REG,
+ TVE_EN, TVE_EN);
}
/* clear interrupt status register */
@@ -174,12 +172,9 @@ static void tve_enable(struct imx_tve *tve)
static void tve_disable(struct imx_tve *tve)
{
- int ret;
-
if (tve->enabled) {
tve->enabled = false;
- ret = regmap_update_bits(tve->regmap, TVE_COM_CONF_REG,
-TVE_EN, 0);
+ regmap_update_bits(tve->regmap, TVE_COM_CONF_REG, TVE_EN, 0);
clk_disable_unprepare(tve->clk);
}
}
--
2.7.4
[PATCH] README: Fix grammar
Fix two grammar issues: - "standard autotools packages ---> "standard autotools package" - "If you are install" ---> "If you are installing" Signed-off-by: Fabio Estevam --- README | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README b/README index 7eeae38..26cab9d 100644 --- a/README +++ b/README @@ -15,7 +15,7 @@ with an older kernel. Compiling - -libdrm is a standard autotools packages and follows the normal +libdrm is a standard autotools package and follows the normal configure, build and install steps. The first step is to configure the package, which is done by running the configure shell script: @@ -37,5 +37,5 @@ and once make finishes successfully, install the package using make install -If you are install into a system location, you will need to be root to -perform the install step. +If you are installing into a system location, you will need to be root +to perform the install step. -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Warning at drivers/gpu/drm/drm_atomic_helper.c
Hi, Stopping kmscube application on mx6q through CTRL + C sometimes leads to the following kernel warning: ^C[ 3939.785516] [ cut here ] [ 3939.790313] WARNING: CPU: 1 PID: 67 at drivers/gpu/drm/drm_atomic_helper.c:1032 drm_atomic_helper_wait_for_fences+0xe4/0x104 [ 3939.801626] Modules linked in: [ 3939.804762] CPU: 1 PID: 67 Comm: kworker/1:1 Tainted: GW 4.9.4 #1 [ 3939.812094] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 3939.818666] Workqueue: events drm_mode_rmfb_work_fn [ 3939.823584] Backtrace: [ 3939.826100] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 3939.833689] r7:ee8aa000 r6:6013 r5: r4:c0e25cac [ 3939.839367] [] (show_stack) from [] (dump_stack+0xb4/0xe8) [ 3939.846604] [] (dump_stack) from [] (__warn+0xd8/0x104) [ 3939.853578] r10:ee577b80 r9:c04c9f3c r8:0408 r7:0009 r6:c0c3c438 r5: [ 3939.861414] r4: r3: [ 3939.865001] [] (__warn) from [] (warn_slowpath_null+0x28/0x30) [ 3939.872581] r9: r8: r7:0001 r6:ee577b80 r5: r4:ef101800 [ 3939.880340] [] (warn_slowpath_null) from [] (drm_atomic_helper_wait_for_fences+0xe4/0x104) [ 3939.890356] [] (drm_atomic_helper_wait_for_fences) from [] (drm_atomic_helper_commit+0x8c/0xe8) [ 3939.900802] r9: r8:ee8b1c8c r7:ee8b1800 r6: r5: r4:ee577b80 [ 3939.908562] [] (drm_atomic_helper_commit) from [] (imx_drm_atomic_commit+0x1fc/0x340) [ 3939.918137] r7:ee8aec18 r6: r5:ee577b80 r4:0006 [ 3939.923813] [] (imx_drm_atomic_commit) from [] (drm_atomic_commit+0x54/0x60) [ 3939.932609] r10:0001 r9: r8:ee8b1c8c r7:ee8aec18 r6:ee8b1800 r5:ee577b80 [ 3939.940444] r4: [ 3939.942994] [] (drm_atomic_commit) from [] (drm_atomic_helper_set_config+0x80/0xa4) [ 3939.952395] r7:ee8aec18 r6:ee8abe2c r5: r4:ee577b80 [ 3939.958068] [] (drm_atomic_helper_set_config) from [] (drm_mode_set_config_internal+0x6c/0xfc) [ 3939.968424] r7:ee8b1800 r6:ee8b1c80 r5:ee8aec18 r4: [ 3939.974095] [] (drm_mode_set_config_internal) from [] (drm_crtc_force_disable+0x38/0x40) [ 3939.983930] r7:ee8b1800 r6:ee8b1c80 r5:ee4869c0 r4:ee8aec18 [ 3939.989603] [] (drm_crtc_force_disable) from [] (drm_framebuffer_remove+0xc8/0x104) [ 3939.999011] [] (drm_framebuffer_remove) from [] (drm_mode_rmfb_work_fn+0x40/0x50) [ 3940.008240] r9: r8:ee8abeb0 r7:ef7b4e00 r6:ef7b1800 r5:ee4d5d58 r4:ee4d5d38 [ 3940.016008] [] (drm_mode_rmfb_work_fn) from [] (process_one_work+0x198/0x4e0) [ 3940.024888] r5:ef0f4180 r4:ee4d5d38 [ 3940.028478] [] (process_one_work) from [] (worker_thread+0x34/0x57c) [ 3940.036579] r10:ef0f4180 r9:ef7b1800 r8:c0e04900 r7:ef7b1834 r6:0008 r5:ef0f4198 [ 3940.044414] r4:ef7b1800 [ 3940.046964] [] (worker_thread) from [] (kthread+0xdc/0xf8) [ 3940.054196] r10: r9: r8: r7:c01402a4 r6:ef0f4180 r5:ef0f7000 [ 3940.062031] r4: [ 3940.064581] [] (kthread) from [] (ret_from_fork+0x14/0x24) [ 3940.071813] r7: r6: r5:c0146894 r4:ef0f7000 [ 3940.077578] ---[ end trace a2c0d89dc638cc35 ]--- Any ideas on how to fix it? Thanks, Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Warning at drivers/gpu/drm/drm_atomic_helper.c
On Sat, Jan 21, 2017 at 2:40 PM, Fabio Estevam wrote: > Hi, > > Stopping kmscube application on mx6q through CTRL + C sometimes leads > to the following kernel warning: > > ^C[ 3939.785516] [ cut here ] > [ 3939.790313] WARNING: CPU: 1 PID: 67 at > drivers/gpu/drm/drm_atomic_helper.c:1032 > drm_atomic_helper_wait_for_fences+0xe4/0x104 > [ 3939.801626] Modules linked in: > [ 3939.804762] CPU: 1 PID: 67 Comm: kworker/1:1 Tainted: GW >4.9.4 #1 Just tested 4.9.5 and the kernel warning is gone. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Warning at drivers/gpu/drm/drm_atomic_helper.c
On Sun, Jan 22, 2017 at 12:26 PM, Fabio Estevam wrote:
> On Sat, Jan 21, 2017 at 2:40 PM, Fabio Estevam wrote:
>> Hi,
>>
>> Stopping kmscube application on mx6q through CTRL + C sometimes leads
>> to the following kernel warning:
>>
>> ^C[ 3939.785516] [ cut here ]
>> [ 3939.790313] WARNING: CPU: 1 PID: 67 at
>> drivers/gpu/drm/drm_atomic_helper.c:1032
>> drm_atomic_helper_wait_for_fences+0xe4/0x104
>> [ 3939.801626] Modules linked in:
>> [ 3939.804762] CPU: 1 PID: 67 Comm: kworker/1:1 Tainted: GW
>>4.9.4 #1
>
> Just tested 4.9.5 and the kernel warning is gone.
Actually 4.9.5 shows the same warning.
If I change .atomic_commit like in 782ea2a493ba90800 ("drm/imx: Switch
to drm_fb_cma_prepare_fb() helper") from 4.10-rc1
- .atomic_commit = imx_drm_atomic_commit,
+ .atomic_commit = drm_atomic_helper_commit,
it fixes the problem.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Warning at drivers/gpu/drm/drm_atomic_helper.c
On Mon, Jan 23, 2017 at 1:15 AM, Marek Vasut wrote:
> IMHO this will no longer handle the fences correctly and you'll see
> rendering artifacts sometimes.
Ok, for 4.9.x stable we cannot apply your 782ea2a493ba90800 ("drm/imx: Switch
to drm_fb_cma_prepare_fb() helper") as it depends on many things that
only show up on 4.10-rc1, so we need to provide a different fix for
4.9.x.
What I did not figure out so far is why are we getting sometimes the
WARN_ON(!plane_state->fb); inside drm_atomic_helper_wait_for_fences()?
The way to reproduce this issue on 4.9.x:
1. Start kmscube
2. Stop kmscube with CTRL + C
Repeate this sequence several times (10 to 20 times) and the
WARN_ON(!plane_state->fb) will trigger about 20% of the times.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Revert "drm/imx: Remove of_node assignment from ipuv3-crtc driver probe"
Commit 407c9eba789767 ("drm/imx: Remove of_node assignment from ipuv3-crtc
driver probe") causes the IPU to be non-functional, so better to
revert it to avoid such regression.
This reverts commit 407c9eba789767feb68b42eb2d65db68584e06c0.
Cc: # 4.4.x
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index dee8e8b..006753d 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -520,6 +520,28 @@ err_put_resources:
return ret;
}
+static struct device_node *ipu_drm_get_port_by_id(struct device_node *parent,
+ int port_id)
+{
+ struct device_node *port;
+ int id, ret;
+
+ port = of_get_child_by_name(parent, "port");
+ while (port) {
+ ret = of_property_read_u32(port, "reg", &id);
+ if (!ret && id == port_id)
+ return port;
+
+ do {
+ port = of_get_next_child(parent, port);
+ if (!port)
+ return NULL;
+ } while (of_node_cmp(port->name, "port"));
+ }
+
+ return NULL;
+}
+
static int ipu_drm_bind(struct device *dev, struct device *master, void *data)
{
struct ipu_client_platformdata *pdata = dev->platform_data;
@@ -562,11 +584,23 @@ static const struct component_ops ipu_crtc_ops = {
static int ipu_drm_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
+ struct ipu_client_platformdata *pdata = dev->platform_data;
int ret;
if (!dev->platform_data)
return -EINVAL;
+ if (!dev->of_node) {
+ /* Associate crtc device with the corresponding DI port node */
+ dev->of_node = ipu_drm_get_port_by_id(dev->parent->of_node,
+ pdata->di + 2);
+ if (!dev->of_node) {
+ dev_err(dev, "missing port@%d node in %s\n",
+ pdata->di + 2, dev->parent->of_node->full_name);
+ return -ENODEV;
+ }
+ }
+
ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
if (ret)
return ret;
--
1.9.1
[PATCH] Revert "drm/imx: Remove of_node assignment from ipuv3-crtc driver probe"
Hi Philipp, On Wed, May 18, 2016 at 5:38 AM, Philipp Zabel wrote: > Could you also test https://patchwork.kernel.org/patch/9081661/ ? With this patch applied I still do not get HDMI working on a mx6q sabresd board. Thanks
[PATCH v2] drm/imx: Match imx-ipuv3-crtc components using device node in platform data
On Wed, May 18, 2016 at 9:56 AM, Philipp Zabel
wrote:
> The component master driver imx-drm-core matches component devices using
> their of_node. Since commit 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc
> module autoloading"), the imx-ipuv3-crtc dev->of_node is not set during
> probing. Before that, of_node was set and caused an of: modalias to be
> used instead of the platform: modalias, which broke module autoloading.
>
> On the other hand, if dev->of_node is not set yet when the imx-ipuv3-crtc
> probe function calls component_add, component matching in imx-drm-core
> fails. While dev->of_node will be set once the next component tries to
> bring up the component master, imx-drm-core component binding will never
> succeed if one of the crtc devices is probed last.
>
> Add of_node to the component platform data and match against the
> pdata->of_node instead of dev->of_node in imx-drm-core to work around
> this problem.
>
> Cc: # 4.4.x
> Fixes: 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
> Signed-off-by: Philipp Zabel
Thanks, Philipp. With this patch HDMI is functional again:
Tested-by: Fabio Estevam
[PATCH] gpu: ipu-v3: display support on the aristainetos2 board broken
Hi Heiko,
On Fri, May 20, 2016 at 8:15 AM, Heiko Schocher wrote:
> commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
> breaks the aristainetos2 board with the "lg,lg4573" panel.
>
> This reverts the above commit.
>
> Signed-off-by: Heiko Schocher
>
> ---
> Any hint, how to bring back the display on the aristainetos2
> board without reverting this commit would be appreciated.
Philipp sent the following patch that fixes the issue:
http://www.spinics.net/lists/dri-devel/msg107524.html
[PATCH 2/5] arm/dts/imx6q-b850v3: Configure IPU assignment order
On Mon, May 30, 2016 at 1:39 PM, Peter Senna Tschudin wrote: > Configure the IPU assignment order to assign one IPU per external > display. A single IPU can drive multiple external displays but there are > resolution restrictions. After this patch the GPU is capalbe of driving two I think you meant "the IPU is capable"
[PATCH 5/5] arm/dts/imx6q-b850v3: Use GE B850v3 LVDS/DP++ Bridge
On Mon, May 30, 2016 at 1:39 PM, Peter Senna Tschudin
wrote:
> +&mux2_i2c2 {
> + status = "okay";
> + clock-frequency = <10>;
> +
> + b850v3_lvds_dp_bridge {
> + compatible = "ge,b850v3_lvds_dp";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <0x73>;
You use 'reg = <0x73>' here, but no @73.
[alsa-devel] [PATCH 0/9] dw-hdmi audio support
On Tue, Jan 5, 2016 at 1:40 PM, Jean-Michel Hautbois wrote: > What is the status of this series ? > I would like to use audio output in HDMI on my i.MX6 board, but I > don't know if you have some pending WIP on this ? This series is in mainline since 4.4-rc1.
[PATCH] etnaviv: etnaviv_drv: Remove owner assignment from platform_driver
This platform_driver does not need to set an owner as it will be
populated by the driver core.
Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 5c89ebb..e885898 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -668,7 +668,6 @@ static struct platform_driver etnaviv_platform_driver = {
.probe = etnaviv_pdev_probe,
.remove = etnaviv_pdev_remove,
.driver = {
- .owner = THIS_MODULE,
.name = "etnaviv",
.of_match_table = dt_match,
},
--
1.9.1
[PATCH v11 2/4] PM / Domains: add setter for dev.pm_domain
On Thu, Jan 7, 2016 at 12:47 PM, Tomeu Vizoso wrote: > On 10 November 2015 at 10:33, Daniel Kurtz wrote: > [snip] >> >> The problem appears to be that: >> * On boot, platform_drv_probe() calls dev_pm_domain_attach() before >> drv->probe(); thus, it calls dev_pm_domain_attach() while the device >> is unbound. >> >> * However, for a platform_device, the reboot path calls >> device_shutdown(), but not __device_release_driver(): >> device_shutdown() >> dev->driver->shutdown => platform_drv_shutdown() >> dev_pm_domain_detach() >>dev->pm_domain->detach() => genpd_dev_pm_detach() >> pm_genpd_remove_device() >> dev_pm_domain_set(dev, NULL); >> >> So, for a platform_device in a genpd power domain with .shutdown >> installed, platform_drv_shutdown() calls dev_pm_domain_detach() while >> the device is still bound, which triggers the WARN(). > > Hi Rafael, Alan and Ulf, > > do you have any suggestion about this? I don't really understand why > the device is detached from the domain on shutdown. I am running linux-next and this commit causes the same problem for me on a mx6 after running a 'reboot' command: Requesting system reboot [ 15.058782] [ cut here ] [ 15.063459] WARNING: CPU: 3 PID: 1122 at drivers/base/power/common.c:150 dev_pm_domain_set+0x4c/0x58() [ 15.072838] PM domains can only be changed for unbound devices [ 15.078735] Modules linked in: [ 15.081849] CPU: 3 PID: 1122 Comm: init Not tainted 4.4.0-rc8-next-20160111-dirty #207 [ 15.089826] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 15.096375] Backtrace: [ 15.098941] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 15.106532] r6:0096 r5: r4: r3: [ 15.112390] [] (show_stack) from [] (dump_stack+0x88/0xa4) [ 15.119708] [] (dump_stack) from [] (warn_slowpath_common+0x80/0xbc) [ 15.127860] r5:c03da810 r4:ee63bd68 [ 15.131533] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x38/0x40) [ 15.140292] r8:eea01db0 r7:c0b0f87c r6:eea01d80 r5: r4:ef181410 [ 15.147165] [] (warn_slowpath_fmt) from [] (dev_pm_domain_set+0x4c/0x58) [ 15.155661] r3:c0b0f7f0 r2:c09e82dc [ 15.159373] [] (dev_pm_domain_set) from [] (genpd_free_dev_data+0x20/0x50) [ 15.168065] r5:ef1814a0 r4:ef181410 [ 15.171737] [] (genpd_free_dev_data) from [] (pm_genpd_remove_device+0xb4/0xe0) [ 15.180842] r6:ef181410 r5:eea01d80 r4:c0b0f7f0 r3: [ 15.186644] [] (pm_genpd_remove_device) from [] (genpd_dev_pm_detach+0x30/0xac) [ 15.195743] r8:c0b0f7f0 r7:c1379734 r6:0001 r5:c0b209c4 r4:ef181410 r3: [ 15.203694] [] (genpd_dev_pm_detach) from [] (dev_pm_domain_detach+0x28/0x2c) [ 15.212621] r10:ef181444 r8:c0b6f560 r7:c1379734 r6:ef181410 r5:ef173c10 r4:ef181410 [ 15.220683] [] (dev_pm_domain_detach) from [] (platform_drv_shutdown+0x34/0x38) [ 15.229817] [] (platform_drv_shutdown) from [] (device_shutdown+0x3c/0x194) [ 15.238579] r4:ef18141c r3:c03d3e6c [ 15.242259] [] (device_shutdown) from [] (kernel_restart_prepare+0x34/0x40) [ 15.251021] r10: r8:c0010044 r7: r6:c0b120cc r5:4321fedc r4: [ 15.259065] [] (kernel_restart_prepare) from [] (kernel_restart+0x14/0x58) [ 15.267760] [] (kernel_restart) from [] (SyS_reboot+0x18c/0x1e4) [ 15.275526] r4:01234567 r3:01234567 [ 15.279242] [] (SyS_reboot) from [] (ret_fast_syscall+0x0/0x1c) [ 15.286920] r7:0058 r6: r5: r4: [ 15.292754] ---[ end trace 3b419d3cbb367a11 ]---
[PATCH v11 2/4] PM / Domains: add setter for dev.pm_domain
On Mon, Jan 11, 2016 at 12:45 PM, Rafael J. Wysocki wrote: > OK, so does the appended patch help? Yes, thanks. I do not see the warnings after 'reboot' with your patch applied: Tested-by: Fabio Estevam
[PATCH] dt-bindings: display: sun8i-mixer: Remove duplicated 'iommus'
Commit 13871279ff5c ("arm64: dts: allwinner: h6: Fix Cedrus IOMMU usage")
introduced a double instance of 'iommus' causing the following build
error with 'make dt_binding_check':
found duplicate key "iommus" with value "{}" (original value: "{}")
in "", line 45, column 3
Remove the double occurrence to fix this problem.
Fixes: 13871279ff5c ("arm64: dts: allwinner: h6: Fix Cedrus IOMMU usage")
Signed-off-by: Fabio Estevam
---
.../bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml | 3 ---
1 file changed, 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
index c2fbf0b06d32..c040eef56518 100644
---
a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
+++
b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
@@ -42,9 +42,6 @@ properties:
resets:
maxItems: 1
- iommus:
-maxItems: 1
-
ports:
type: object
description: |
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
