Re: [PATCH] drm/amd/powerplay: work around enum conversion warnings
Hi Arnd,
On Mon, Jul 08, 2019 at 03:57:06PM +0200, Arnd Bergmann wrote:
> A couple of calls to smu_get_current_clk_freq() and smu_force_clk_levels()
> pass constants of the wrong type, leading to warnings with clang-8:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:995:39: error: implicit
> conversion from enumeration type 'PPCLK_e' to different enumeration type
> 'enum smu_clk_type' [-Werror,-Wenum-conversion]
> ret = smu_get_current_clk_freq(smu, PPCLK_SOCCLK, &now);
> ~~^~~
> drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:775:82: note:
> expanded from macro 'smu_get_current_clk_freq'
> ((smu)->funcs->get_current_clk_freq?
> (smu)->funcs->get_current_clk_freq((smu), (clk_id), (value)) : 0)
>
> I could not figure out what the purpose is of mixing the types
> like this and if it is written like this intentionally.
> Assuming this is all correct, adding an explict case is an
> easy way to shut up the warnings.
>
> Fixes: bc0fcffd36ba ("drm/amd/powerplay: Unify smu handle task function (v2)")
> Fixes: 096761014227 ("drm/amd/powerplay: support sysfs to get socclk, fclk,
> dcefclk")
> Signed-off-by: Arnd Bergmann
I sent a series last week for all of the clang warnings that were added
in this driver recently.
https://lore.kernel.org/lkml/20190704055217.45860-1-natechancel...@gmail.com/
I think it is safe to use the CLK enums from the expected type (from
what I could see from going down the code flow rabbit hole).
https://lore.kernel.org/lkml/20190704055217.45860-4-natechancel...@gmail.com/
https://lore.kernel.org/lkml/20190704055217.45860-7-natechancel...@gmail.com/
Cheers,
Nathan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/14] drm/drv: Replace devm_add_action() followed by failure action with devm_add_action_or_reset()
devm_add_action_or_reset() is introduced as a helper function which internally calls devm_add_action(). If devm_add_action() fails then it will execute the action mentioned and return the error code. This reduce source code size (avoid writing the action twice) and reduce the likelyhood of bugs. Signed-off-by: Fuqian Huang --- drivers/gpu/drm/drm_drv.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 862621494a93..dd004ebbb5fd 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -760,9 +760,7 @@ int devm_drm_dev_init(struct device *parent, if (ret) return ret; - ret = devm_add_action(parent, devm_drm_dev_init_release, dev); - if (ret) - devm_drm_dev_init_release(dev); + ret = devm_add_action_or_reset(parent, devm_drm_dev_init_release, dev); return ret; } -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4, 13/33] drm/mediatek: add mmsys private data for ddp path config
From: Yongqiang Niu
This patch add mmsys private data for ddp path config
all these register offset and value will be different in future SOC
add these define into mmsys private data
u32 ovl0_mout_en;
u32 rdma0_sout_sel_in;
u32 rdma0_sout_color0;
u32 rdma1_sout_sel_in;
u32 rdma1_sout_dpi0;
u32 rdma1_sout_dsi0;
u32 dpi0_sel_in;
u32 dpi0_sel_in_rdma1;
u32 dsi0_sel_in;
u32 dsi0_sel_in_rdma1;
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 89 -
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 5 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 ++
5 files changed, 79 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index e520b56..5eac376 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -49,6 +49,7 @@ struct mtk_drm_crtc {
boolpending_planes;
void __iomem*config_regs;
+ const struct mtk_mmsys_reg_data *mmsys_reg_data;
struct mtk_disp_mutex *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
@@ -270,6 +271,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
DRM_DEBUG_DRIVER("mediatek_ddp_ddp_path_setup\n");
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
+mtk_crtc->mmsys_reg_data,
mtk_crtc->ddp_comp[i]->id,
mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_add_comp(mtk_crtc->mutex,
@@ -318,6 +320,7 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
mtk_disp_mutex_disable(mtk_crtc->mutex);
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
+ mtk_crtc->mmsys_reg_data,
mtk_crtc->ddp_comp[i]->id,
mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_remove_comp(mtk_crtc->mutex,
@@ -549,6 +552,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
return -ENOMEM;
mtk_crtc->config_regs = priv->config_regs;
+ mtk_crtc->mmsys_reg_data = priv->data->reg_data;
mtk_crtc->ddp_comp_nr = path_len;
mtk_crtc->ddp_comp = devm_kmalloc_array(dev, mtk_crtc->ddp_comp_nr,
sizeof(*mtk_crtc->ddp_comp),
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 47b3e35..7819fd31 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -175,6 +175,19 @@ struct mtk_ddp {
const struct mtk_ddp_data *data;
};
+struct mtk_mmsys_reg_data {
+ u32 ovl0_mout_en;
+ u32 rdma0_sout_sel_in;
+ u32 rdma0_sout_color0;
+ u32 rdma1_sout_sel_in;
+ u32 rdma1_sout_dpi0;
+ u32 rdma1_sout_dsi0;
+ u32 dpi0_sel_in;
+ u32 dpi0_sel_in_rdma1;
+ u32 dsi0_sel_in;
+ u32 dsi0_sel_in_rdma1;
+};
+
static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
[DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
@@ -253,17 +266,34 @@ struct mtk_ddp {
.mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
};
-static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
+const struct mtk_mmsys_reg_data mt2701_mmsys_reg_data = {
+ .ovl0_mout_en = DISP_REG_CONFIG_DISP_OVL_MOUT_EN,
+ .dsi0_sel_in = DISP_REG_CONFIG_DSI_SEL,
+ .dsi0_sel_in_rdma1 = DSI_SEL_IN_RDMA,
+};
+
+const struct mtk_mmsys_reg_data mt8173_mmsys_reg_data = {
+ .ovl0_mout_en = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN,
+ .rdma1_sout_sel_in = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN,
+ .rdma1_sout_dpi0 = RDMA1_SOUT_DPI0,
+ .dpi0_sel_in = DISP_REG_CONFIG_DPI_SEL_IN,
+ .dpi0_sel_in_rdma1 = DPI0_SEL_IN_RDMA1,
+ .dsi0_sel_in = DISP_REG_CONFIG_DSIE_SEL_IN,
+ .dsi0_sel_in_rdma1 = DSI0_SEL_IN_RDMA1,
+};
+
+static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
+ enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next,
unsigned int *addr)
{
unsigned int value;
if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
- *addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
+ *addr = data->ovl0_mout_en;
[PATCH 06/14] drm/i2c: tda9950: Replace devm_add_action() followed by failure action with devm_add_action_or_reset()
devm_add_action_or_reset() is introduced as a helper function which internally calls devm_add_action(). If devm_add_action() fails then it will execute the action mentioned and return the error code. This reduce source code size (avoid writing the action twice) and reduce the likelyhood of bugs. Signed-off-by: Fuqian Huang --- drivers/gpu/drm/i2c/tda9950.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c index 8039fc0d83db..042f6487e6fb 100644 --- a/drivers/gpu/drm/i2c/tda9950.c +++ b/drivers/gpu/drm/i2c/tda9950.c @@ -361,9 +361,7 @@ static int tda9950_devm_glue_init(struct device *dev, struct tda9950_glue *glue) return ret; } - ret = devm_add_action(dev, tda9950_devm_glue_exit, glue); - if (ret) - tda9950_devm_glue_exit(glue); + ret = devm_add_action_or_reset(dev, tda9950_devm_glue_exit, glue); return ret; } -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings
Brian
On 6/30/19 7:28 PM, Brian Dodge wrote:
The vendor-prefixes.txt file properly refers to ArcticSand
as arctic but the driver bindings improperly abbreviated the
prefix to arc. This was a mistake in the original patch. This
patch adds "arctic" and retains "arc" (deprecated) bindings
Signed-off-by: Brian Dodge
---
.../bindings/leds/backlight/arcxcnn_bl.txt | 31 +++---
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
index 230abde..4d98394 100644
--- a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
@@ -1,8 +1,13 @@
-Binding for ArcticSand arc2c0608 LED driver
+Binding for ArcticSand arc family LED drivers
Required properties:
-- compatible: should be "arc,arc2c0608"
-- reg: slave address
+- compatible: one of
+ "arctic,arc1c0608"
+ "arctic,arc2c0608"
+ "arctic,arc3c0845"
+ "arc,arc2c0608" (deprecated)
+
+- reg: slave address
Optional properties:
- default-brightness: brightness value on boot, value from: 0-4095
@@ -11,19 +16,25 @@ Optional properties:
- led-sources:List of enabled channels from 0 to 5.
See Documentation/devicetree/bindings/leds/common.txt
-- arc,led-config-0: setting for register ILED_CONFIG_0
-- arc,led-config-1:setting for register ILED_CONFIG_1
-- arc,dim-freq:PWM mode frequence setting (bits [3:0] used)
-- arc,comp-config: setting for register CONFIG_COMP
-- arc,filter-config: setting for register FILTER_CONFIG
-- arc,trim-config: setting for register IMAXTUNE
+- arctic,led-config-0: setting for register ILED_CONFIG_0
+- arctic,led-config-1: setting for register ILED_CONFIG_1
+- arctic,dim-freq: PWM mode frequence setting (bits [3:0] used)
+- arctic,comp-config: setting for register CONFIG_COMP
+- arctic,filter-config:setting for register FILTER_CONFIG
+- arctic,trim-config: setting for register IMAXTUNE
+- arc,led-config-0:setting for register ILED_CONFIG_0 (deprecated)
+- arc,led-config-1:setting for register ILED_CONFIG_1 (deprecated)
+- arc,dim-freq:PWM mode frequence setting (bits [3:0] used)
(deprecated)
+- arc,comp-config: setting for register CONFIG_COMP (deprecated)
+- arc,filter-config: setting for register FILTER_CONFIG (deprecated)
+- arc,trim-config: setting for register IMAXTUNE (deprecated)
Note: Optional properties not specified will default to values in IC EPROM
Example:
arc2c0608@30 {
- compatible = "arc,arc2c0608";
+ compatible = "arctic,arc2c0608";
reg = <0x30>;
default-brightness = <500>;
label = "lcd-backlight";
Reviewed-by: Dan Murphy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: hmm_range_fault related fixes and legacy API removal v2
On Mon, Jul 08, 2019 at 10:30:55AM -0700, Ralph Campbell wrote: > > On 7/4/19 9:42 AM, Jason Gunthorpe wrote: > > On Wed, Jul 03, 2019 at 03:02:08PM -0700, Christoph Hellwig wrote: > > > Hi Jérôme, Ben and Jason, > > > > > > below is a series against the hmm tree which fixes up the mmap_sem > > > locking in nouveau and while at it also removes leftover legacy HMM APIs > > > only used by nouveau. > > > > > > Changes since v1: > > > - don't return the valid state from hmm_range_unregister > > > - additional nouveau cleanups > > > > Ralph, since most of this is nouveau could you contribute a > > Tested-by? Thanks > > > > Jason > > > > I can test things fairly easily but with all the different patches, > conflicts, and personal git trees, can you specify the git tree > and branch with everything applied that you want me to test? This series will be pushed to the next cycle, so if you test v5.3-rc1 + this series you'd get the right coverage. Thanks, Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: hmm_range_fault related fixes and legacy API removal v2
On 7/4/19 9:42 AM, Jason Gunthorpe wrote: On Wed, Jul 03, 2019 at 03:02:08PM -0700, Christoph Hellwig wrote: Hi Jérôme, Ben and Jason, below is a series against the hmm tree which fixes up the mmap_sem locking in nouveau and while at it also removes leftover legacy HMM APIs only used by nouveau. Changes since v1: - don't return the valid state from hmm_range_unregister - additional nouveau cleanups Ralph, since most of this is nouveau could you contribute a Tested-by? Thanks Jason I can test things fairly easily but with all the different patches, conflicts, and personal git trees, can you specify the git tree and branch with everything applied that you want me to test? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4, 26/33] drm/mediatek: add connection from OVL0 to OVL_2L0
From: Yongqiang Niu
This patch add connection from OVL0 to OVL_2L0
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index a9d3e27..fe4a458 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -145,6 +145,8 @@
#define DPI_SEL_IN_BLS 0x0
#define DSI_SEL_IN_RDMA0x1
+#define OVL0_MOUT_EN_OVL0_2L BIT(4)
+
struct mtk_disp_mutex {
int id;
bool claimed;
@@ -310,6 +312,9 @@ static unsigned int mtk_ddp_mout_en(const struct
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD1_MOUT_EN_RDMA1;
+ } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0) {
+ *addr = data->ovl0_mout_en;
+ value = OVL0_MOUT_EN_OVL0_2L;
} else {
value = 0;
}
--
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] backlight: arcxcnn: add "arctic" vendor prefix
Brian
On 6/30/19 7:28 PM, Brian Dodge wrote:
The original patch adding this driver and DT bindings improperly
used "arc" as the vendor-prefix. This adds "arctic" which is the
proper prefix and retains "arc" to allow existing users of the
"arc" prefix to update to new kernels. There is at least one
(Samsung Chromebook Plus)
Signed-off-by: Brian Dodge
Acked-by: Daniel Thompson
---
drivers/video/backlight/arcxcnn_bl.c | 41 +++-
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/arcxcnn_bl.c
b/drivers/video/backlight/arcxcnn_bl.c
index 7b1c0a0..a419554 100644
--- a/drivers/video/backlight/arcxcnn_bl.c
+++ b/drivers/video/backlight/arcxcnn_bl.c
@@ -1,9 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
+ * Backlight driver for pSemi (formerly ArcticSand) ARC_X_C_0N_0N Devices
*
- * Copyright 2016 ArcticSand, Inc.
- * Author : Brian Dodge
I know you are the original author from ArcticSand but did pSemi
actually own the copyright in 2016?
I don't think this is a big issue just wondering if we should retain the
ArcticSand copyright as well.
Probably a question for your legal department.
Otherwise
Reviewed-by: Dan Murphy
+ * Copyright 2016-2019 pSemi, Inc.
+ * Author : Brian Dodge
*/
#include
@@ -191,27 +191,46 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
if (ret == 0)
lp->pdata->initial_brightness = prog_val;
- ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+ ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val);
+ if (ret)
+ ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+
if (ret == 0)
lp->pdata->led_config_0 = (u8)prog_val;
- ret = of_property_read_u32(node, "arc,led-config-1", &prog_val);
+ ret = of_property_read_u32(node, "arctic,led-config-1", &prog_val);
+ if (ret)
+ ret = of_property_read_u32(node, "arc,led-config-1", &prog_val);
+
if (ret == 0)
lp->pdata->led_config_1 = (u8)prog_val;
- ret = of_property_read_u32(node, "arc,dim-freq", &prog_val);
+ ret = of_property_read_u32(node, "arctic,dim-freq", &prog_val);
+ if (ret)
+ ret = of_property_read_u32(node, "arc,dim-freq", &prog_val);
+
if (ret == 0)
lp->pdata->dim_freq = (u8)prog_val;
- ret = of_property_read_u32(node, "arc,comp-config", &prog_val);
+ ret = of_property_read_u32(node, "arctic,comp-config", &prog_val);
+ if (ret)
+ ret = of_property_read_u32(node, "arc,comp-config", &prog_val);
+
if (ret == 0)
lp->pdata->comp_config = (u8)prog_val;
- ret = of_property_read_u32(node, "arc,filter-config", &prog_val);
+ ret = of_property_read_u32(node, "arctic,filter-config", &prog_val);
+ if (ret)
+ ret = of_property_read_u32(node,
+ "arc,filter-config", &prog_val);
+
if (ret == 0)
lp->pdata->filter_config = (u8)prog_val;
- ret = of_property_read_u32(node, "arc,trim-config", &prog_val);
+ ret = of_property_read_u32(node, "arctic,trim-config", &prog_val);
+ if (ret)
+ ret = of_property_read_u32(node, "arc,trim-config", &prog_val);
+
if (ret == 0)
lp->pdata->trim_config = (u8)prog_val;
@@ -381,6 +400,8 @@ static int arcxcnn_remove(struct i2c_client *cl)
}
static const struct of_device_id arcxcnn_dt_ids[] = {
+ { .compatible = "arctic,arc2c0608" },
+ /* here to remain compatible with an older binding, do not use */
{ .compatible = "arc,arc2c0608" },
{ }
};
@@ -404,5 +425,5 @@ static struct i2c_driver arcxcnn_driver = {
module_i2c_driver(arcxcnn_driver);
MODULE_LICENSE("GPL v2");
-MODULE_AUTHOR("Brian Dodge ");
+MODULE_AUTHOR("Brian Dodge ");
MODULE_DESCRIPTION("ARCXCNN Backlight driver");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4, 14/33] drm/mediatek: move rdma sout from mtk_ddp_mout_en into mtk_ddp_sout_sel
From: Yongqiang Niu
This patch move rdma sout from mtk_ddp_mout_en into mtk_ddp_sout_sel
rdma only has single output, but no multi output,
all these rdma->dsi/dpi usecase should move to mtk_ddp_sout_sel
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 90 +-
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 7819fd31..c57e7ab 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -310,51 +310,6 @@ static unsigned int mtk_ddp_mout_en(const struct
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD1_MOUT_EN_RDMA1;
- } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
- value = RDMA0_SOUT_DPI0;
- } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
- value = RDMA0_SOUT_DPI1;
- } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
- value = RDMA0_SOUT_DSI1;
- } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
- value = RDMA0_SOUT_DSI2;
- } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
- value = RDMA0_SOUT_DSI3;
- } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
- value = RDMA1_SOUT_DSI1;
- } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
- value = RDMA1_SOUT_DSI2;
- } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
- value = RDMA1_SOUT_DSI3;
- } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
- *addr = data->rdma1_sout_sel_in;
- value = data->rdma1_sout_dpi0;
- } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
- value = RDMA1_SOUT_DPI1;
- } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
- *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
- value = RDMA2_SOUT_DPI0;
- } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
- value = RDMA2_SOUT_DPI1;
- } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
- value = RDMA2_SOUT_DSI1;
- } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
- *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
- value = RDMA2_SOUT_DSI2;
- } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
- *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
- value = RDMA2_SOUT_DSI3;
} else {
value = 0;
}
@@ -434,6 +389,51 @@ static unsigned int mtk_ddp_sout_sel(const struct
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
*addr = DISP_REG_CONFIG_OUT_SEL;
value = BLS_TO_DPI_RDMA1_TO_DSI;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DPI0;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DPI1;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DSI1;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DSI2;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DSI3;
+ } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
+ value = RDMA1_SOUT_DSI1;
+ } else if (cur == DDP_COMPONENT_RDMA1 && n
Re: [PATCH 2/2] backlight: arcxcnn: add "arctic" vendor prefix
Thanks. pSemi purchased ArcticSand a few years ago so they are the same
legal entity. I will ask them if they want to retain the original copyright
notice
On Mon, Jul 8, 2019, 2:05 PM Dan Murphy wrote:
> Brian
>
> On 6/30/19 7:28 PM, Brian Dodge wrote:
> > The original patch adding this driver and DT bindings improperly
> > used "arc" as the vendor-prefix. This adds "arctic" which is the
> > proper prefix and retains "arc" to allow existing users of the
> > "arc" prefix to update to new kernels. There is at least one
> > (Samsung Chromebook Plus)
> >
> > Signed-off-by: Brian Dodge
> > Acked-by: Daniel Thompson
> > ---
> > drivers/video/backlight/arcxcnn_bl.c | 41
> +++-
> > 1 file changed, 31 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/video/backlight/arcxcnn_bl.c
> b/drivers/video/backlight/arcxcnn_bl.c
> > index 7b1c0a0..a419554 100644
> > --- a/drivers/video/backlight/arcxcnn_bl.c
> > +++ b/drivers/video/backlight/arcxcnn_bl.c
> > @@ -1,9 +1,9 @@
> > // SPDX-License-Identifier: GPL-2.0-only
> > /*
> > - * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
> > + * Backlight driver for pSemi (formerly ArcticSand) ARC_X_C_0N_0N
> Devices
> >*
> > - * Copyright 2016 ArcticSand, Inc.
> > - * Author : Brian Dodge
>
> I know you are the original author from ArcticSand but did pSemi
> actually own the copyright in 2016?
>
> I don't think this is a big issue just wondering if we should retain the
> ArcticSand copyright as well.
>
> Probably a question for your legal department.
>
> Otherwise
>
> Reviewed-by: Dan Murphy
>
> > + * Copyright 2016-2019 pSemi, Inc.
> > + * Author : Brian Dodge
> >*/
> >
> > #include
> > @@ -191,27 +191,46 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
> > if (ret == 0)
> > lp->pdata->initial_brightness = prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node, "arc,led-config-0",
> &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->led_config_0 = (u8)prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,led-config-1", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,led-config-1", &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node, "arc,led-config-1",
> &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->led_config_1 = (u8)prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,dim-freq", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,dim-freq", &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node, "arc,dim-freq",
> &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->dim_freq = (u8)prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,comp-config", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,comp-config", &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node, "arc,comp-config",
> &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->comp_config = (u8)prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,filter-config", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,filter-config",
> &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node,
> > + "arc,filter-config", &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->filter_config = (u8)prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,trim-config", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,trim-config", &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node, "arc,trim-config",
> &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->trim_config = (u8)prog_val;
> >
> > @@ -381,6 +400,8 @@ static int arcxcnn_remove(struct i2c_client *cl)
> > }
> >
> > static const struct of_device_id arcxcnn_dt_ids[] = {
> > + { .compatible = "arctic,arc2c0608" },
> > + /* here to remain compatible with an older binding, do not use */
> > { .compatible = "arc,arc2c0608" },
> > { }
> > };
> > @@ -404,5 +425,5 @@ static struct i2c_driver arcxcnn_driver = {
> > module_i2c_driver(arcxcnn_driver);
> >
> > MODULE_LICENSE("GPL v2");
> > -MODULE_AUTHOR("Brian Dodge ");
> > +MODULE_AUTHOR("Brian Dodge ");
> > MODULE_DESCRIPTION("ARCXCNN Backlight driver");
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/amdgpu: adopt to hmm_range_register API change
On Mon, Jul 08, 2019 at 09:30:20AM +1000, Stephen Rothwell wrote: > Hi all, > > On Wed, 3 Jul 2019 17:09:16 -0400 Alex Deucher wrote: > > > > On Wed, Jul 3, 2019 at 5:03 PM Kuehling, Felix > > wrote: > > > > > > On 2019-07-03 10:10 a.m., Jason Gunthorpe wrote: > > > > On Wed, Jul 03, 2019 at 01:55:08AM +, Kuehling, Felix wrote: > > > >> From: Philip Yang > > > >> > > > >> In order to pass mirror instead of mm to hmm_range_register, we need > > > >> pass bo instead of ttm to amdgpu_ttm_tt_get_user_pages because mirror > > > >> is part of amdgpu_mn structure, which is accessible from bo. > > > >> > > > >> Signed-off-by: Philip Yang > > > >> Reviewed-by: Felix Kuehling > > > >> Signed-off-by: Felix Kuehling > > > >> CC: Stephen Rothwell > > > >> CC: Jason Gunthorpe > > > >> CC: Dave Airlie > > > >> CC: Alex Deucher > > > >> drivers/gpu/drm/Kconfig | 1 - > > > >> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 ++--- > > > >> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- > > > >> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 +-- > > > >> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 8 > > > >> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h | 5 + > > > >> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 12 ++-- > > > >> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 5 +++-- > > > >> 8 files changed, 30 insertions(+), 11 deletions(-) > > > > This is too big to use as a conflict resolution, what you could do is > > > > apply the majority of the patch on top of your tree as-is (ie keep > > > > using the old hmm_range_register), then the conflict resolution for > > > > the updated AMD GPU tree can be a simple one line change: > > > > > > > > - hmm_range_register(range, mm, start, > > > > + hmm_range_register(range, mirror, start, > > > > start + ttm->num_pages * PAGE_SIZE, > > > > PAGE_SHIFT); > > > > > > > > Which is trivial for everone to deal with, and solves the problem. > > > > > > Good idea. > > With the changes added to the amdgpu tree over the weekend, I will > apply the following merge fix patch to the hmm merge today: > > From: Philip Yang > Sibject: drm/amdgpu: adopt to hmm_range_register API change > > Signed-off-by: Stephen Rothwell > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -783,7 +783,7 @@ int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, > struct page **pages) > 0 : range->flags[HMM_PFN_WRITE]; > range->pfn_flags_mask = 0; > range->pfns = pfns; > - hmm_range_register(range, mm, start, > + hmm_range_register(range, mirror, start, > start + ttm->num_pages * PAGE_SIZE, PAGE_SHIFT); > > retry: > > And someone just needs to make sure Linus is aware of this needed merge fix. Great, thanks everyone Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/agp: Remove unused function drm_agp_bind_pages
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_agpsupport.c | 43
include/drm/drm_agpsupport.h | 14 -
2 files changed, 57 deletions(-)
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 117b8ee98243..8b4e7b1d82e4 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -465,46 +465,3 @@ void drm_legacy_agp_clear(struct drm_device *dev)
dev->agp->acquired = 0;
dev->agp->enabled = 0;
}
-
-/**
- * Binds a collection of pages into AGP memory at the given offset, returning
- * the AGP memory structure containing them.
- *
- * No reference is held on the pages during this time -- it is up to the
- * caller to handle that.
- */
-struct agp_memory *
-drm_agp_bind_pages(struct drm_device *dev,
- struct page **pages,
- unsigned long num_pages,
- uint32_t gtt_offset,
- u32 type)
-{
- struct agp_memory *mem;
- int ret, i;
-
- DRM_DEBUG("\n");
-
- mem = agp_allocate_memory(dev->agp->bridge, num_pages,
- type);
- if (mem == NULL) {
- DRM_ERROR("Failed to allocate memory for %ld pages\n",
- num_pages);
- return NULL;
- }
-
- for (i = 0; i < num_pages; i++)
- mem->pages[i] = pages[i];
- mem->page_count = num_pages;
-
- mem->is_flushed = true;
- ret = agp_bind_memory(mem, gtt_offset / PAGE_SIZE);
- if (ret != 0) {
- DRM_ERROR("Failed to bind AGP memory: %d\n", ret);
- agp_free_memory(mem);
- return NULL;
- }
-
- return mem;
-}
-EXPORT_SYMBOL(drm_agp_bind_pages);
diff --git a/include/drm/drm_agpsupport.h b/include/drm/drm_agpsupport.h
index b05e462276d5..664e120b93e6 100644
--- a/include/drm/drm_agpsupport.h
+++ b/include/drm/drm_agpsupport.h
@@ -31,11 +31,6 @@ struct drm_agp_head {
void drm_free_agp(struct agp_memory * handle, int pages);
int drm_bind_agp(struct agp_memory * handle, unsigned int start);
int drm_unbind_agp(struct agp_memory * handle);
-struct agp_memory *drm_agp_bind_pages(struct drm_device *dev,
- struct page **pages,
- unsigned long num_pages,
- uint32_t gtt_offset,
- uint32_t type);
struct drm_agp_head *drm_agp_init(struct drm_device *dev);
void drm_legacy_agp_clear(struct drm_device *dev);
@@ -80,15 +75,6 @@ static inline int drm_unbind_agp(struct agp_memory * handle)
return -ENODEV;
}
-static inline struct agp_memory *drm_agp_bind_pages(struct drm_device *dev,
- struct page **pages,
- unsigned long num_pages,
- uint32_t gtt_offset,
- uint32_t type)
-{
- return NULL;
-}
-
static inline struct drm_agp_head *drm_agp_init(struct drm_device *dev)
{
return NULL;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [1/2] drm/amd/powerplay: smu_v11_0: fix uninitialized variable use
On Mon, Jul 08, 2019 at 04:07:58PM +0200, Arnd Bergmann wrote:
> A mistake in the error handling caused an uninitialized
> variable to be used:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:1102:10: error: variable
> 'freq' is used uninitialized whenever '?:' condition is false
> [-Werror,-Wsometimes-uninitialized]
> ret = smu_get_current_clk_freq_by_table(smu, clk_id, &freq);
>^
> drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:880:3: note:
> expanded from macro 'smu_get_current_clk_freq_by_table'
> ((smu)->ppt_funcs->get_current_clk_freq_by_table ?
> (smu)->ppt_funcs->get_current_clk_freq_by_table((smu), (clk_type), (value)) :
> 0)
> ^~~
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:1114:2: note:
> uninitialized use occurs here
> freq *= 100;
> ^~~~
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:1102:10: note: remove the
> '?:' if its condition is always true
> ret = smu_get_current_clk_freq_by_table(smu, clk_id, &freq);
>^
> drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:880:3: note:
> expanded from macro 'smu_get_current_clk_freq_by_table'
> ((smu)->ppt_funcs->get_current_clk_freq_by_table ?
> (smu)->ppt_funcs->get_current_clk_freq_by_table((smu), (clk_type), (value)) :
> 0)
> ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:1095:15: note: initialize
> the variable 'freq' to silence this warning
> uint32_t freq;
> ^
> = 0
>
> Bail out of smu_v11_0_get_current_clk_freq() before we get there.
>
> Fixes: e36182490dec ("drm/amd/powerplay: fix dpm freq unit error (10KHz ->
> Mhz)")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> index c3f9714e9047..bd89a13b6679 100644
> --- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> +++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> @@ -1099,9 +1099,11 @@ static int smu_v11_0_get_current_clk_freq(struct
> smu_context *smu,
> return -EINVAL;
>
> /* if don't has GetDpmClockFreq Message, try get current clock by
> SmuMetrics_t */
> - if (smu_msg_get_index(smu, SMU_MSG_GetDpmClockFreq) == 0)
> + if (smu_msg_get_index(smu, SMU_MSG_GetDpmClockFreq) == 0) {
> ret = smu_get_current_clk_freq_by_table(smu, clk_id, &freq);
> - else {
> + if (ret)
> + return ret;
I am kind of surprised that this fixes the warning. If I am interpreting
the warning correctly, it is complaining that the member
get_current_clk_freq_by_table could be NULL and not be called to
initialize freq and that entire statement will become 0. If that is the
case, it seems like this added error handling won't fix that problem,
right?
Cheers,
Nathan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4, 25/33] drm/mediatek: add clock property check before get it
From: Yongqiang Niu
This patch add clock property check before get it
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index c57e7ab..a9d3e27 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -668,10 +668,12 @@ static int mtk_ddp_probe(struct platform_device *pdev)
for (i = 0; i < 10; i++)
ddp->mutex[i].id = i;
- ddp->clk = devm_clk_get(dev, NULL);
- if (IS_ERR(ddp->clk)) {
- dev_err(dev, "Failed to get clock\n");
- return PTR_ERR(ddp->clk);
+ if (of_find_property(dev->of_node, "clocks", &i)) {
+ ddp->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(ddp->clk)) {
+ dev_err(dev, "Failed to get clock\n");
+ return PTR_ERR(ddp->clk);
+ }
}
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix reporting of size of created GEM object
Quoting Janusz Krzysztofik (2019-07-09 07:58:00)
> Commit e163484afa8d ("drm/i915: Update size upon return from
> GEM_CREATE") (re)introduced reporting of actual size of created GEM
> objects, possibly rounded up on object alignment. Unfortunately, its
> implementation resulted in a possible use-after-free bug. The bug has
> been fixed by commit 929eec99f5fd ("drm/i915: Avoid use-after-free in
> reporting create.size") at the cost of possibly incorrect value being
> reported as actual object size.
>
> Safely restore correct reporting by capturing actual size of created
> GEM object before a reference to the object is put.
>
> Fixes: 929eec99f5fd ("drm/i915: Avoid use-after-free in reporting
> create.size")
This doesn't do anything.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111087] SteamOS boots to black screen
https://bugs.freedesktop.org/show_bug.cgi?id=111087 --- Comment #15 from Michel Dänzer --- "Server terminated successfully" means Xorg doesn't crash, indicating the problem is on the client side. You should probably get in touch with SteamOS folks about how to get diagnostics on that. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #84 from Wilko Bartels --- (In reply to Wilko Bartels from comment #83) > (In reply to Jaap Buurman from comment #81) > > issue seems to be using a setup that requires higher engine clocks in idle > > AFAIK. Either high refresh displays, or in my case, multiple monitors. Could > > this be part of the issue that seems to trigger this bug? I might be > > grasping at straws here, but I have had this problem for as long as I have > > this Vega64 (bought at launch), while it is 100% stable under Windows 10 in > > the same setup. > > This might be true. I was running i3 with xrandr set to 144hz when the > freeze scenario began (somewhat last mont, did not "game" much before). Than > switched to icewm to test and issue was gone. Later when i configured icewm > to also have proper xrandr setting issue comes back. I didnt know that could > be related. Will test this tonight. nevermind. it crashed on 60hz as well (once) yesterday -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/14] drm/sti: Try to fix up the tvout possible clones
Le lun. 8 juil. 2019 à 18:21, Ville Syrjala a écrit : > > From: Ville Syrjälä > > The current possible_clones setup doesn't look sensible. I'm assuming > the 0 and 1 are supposed to refer to the indexes of the hdmi and hda > encoders? So it kinda looks like we want hda+hdmi cloning, but then > dvo also claims to be cloneable with hdmi, but hdmi won't recipricate. > > Benjamin tells me all encoders should be cloneable with each other, > so let's fix up the masks to indicate that. > Applied on drm-misc-next, Thanks, Benjamin > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Acked-by: Benjamin Gaignard > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/sti/sti_tvout.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c > index 42f4c264a783..aba79c172512 100644 > --- a/drivers/gpu/drm/sti/sti_tvout.c > +++ b/drivers/gpu/drm/sti/sti_tvout.c > @@ -672,7 +672,6 @@ sti_tvout_create_dvo_encoder(struct drm_device *dev, > drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 0; > > drm_encoder_init(dev, drm_encoder, > &sti_tvout_encoder_funcs, DRM_MODE_ENCODER_LVDS, > @@ -725,7 +724,6 @@ static struct drm_encoder > *sti_tvout_create_hda_encoder(struct drm_device *dev, > drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 0; > > drm_encoder_init(dev, drm_encoder, > &sti_tvout_encoder_funcs, DRM_MODE_ENCODER_DAC, NULL); > @@ -774,7 +772,6 @@ static struct drm_encoder > *sti_tvout_create_hdmi_encoder(struct drm_device *dev, > drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 1; > > drm_encoder_init(dev, drm_encoder, > &sti_tvout_encoder_funcs, DRM_MODE_ENCODER_TMDS, > NULL); > @@ -790,6 +787,13 @@ static void sti_tvout_create_encoders(struct drm_device > *dev, > tvout->hdmi = sti_tvout_create_hdmi_encoder(dev, tvout); > tvout->hda = sti_tvout_create_hda_encoder(dev, tvout); > tvout->dvo = sti_tvout_create_dvo_encoder(dev, tvout); > + > + tvout->hdmi->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > + tvout->hda->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > + tvout->dvo->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > } > > static void sti_tvout_destroy_encoders(struct sti_tvout *tvout) > -- > 2.21.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/14] drm/sti: Remove pointless casts
Le lun. 8 juil. 2019 à 18:21, Ville Syrjala a écrit : > > From: Ville Syrjälä > > There's no point in the cast for accessing the base class. Just > take the address of the struct instead. Applied on drm-misc-next, Thanks, Benjamin > > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Acked-by: Benjamin Gaignard > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/sti/sti_tvout.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c > index e1b3c8cb7287..42f4c264a783 100644 > --- a/drivers/gpu/drm/sti/sti_tvout.c > +++ b/drivers/gpu/drm/sti/sti_tvout.c > @@ -669,7 +669,7 @@ sti_tvout_create_dvo_encoder(struct drm_device *dev, > > encoder->tvout = tvout; > > - drm_encoder = (struct drm_encoder *)encoder; > + drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > drm_encoder->possible_clones = 1 << 0; > @@ -722,7 +722,7 @@ static struct drm_encoder > *sti_tvout_create_hda_encoder(struct drm_device *dev, > > encoder->tvout = tvout; > > - drm_encoder = (struct drm_encoder *) encoder; > + drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > drm_encoder->possible_clones = 1 << 0; > @@ -771,7 +771,7 @@ static struct drm_encoder > *sti_tvout_create_hdmi_encoder(struct drm_device *dev, > > encoder->tvout = tvout; > > - drm_encoder = (struct drm_encoder *) encoder; > + drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > drm_encoder->possible_clones = 1 << 1; > -- > 2.21.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/komeda: Add new product "D32" support
This series enables new product "D32" support James Qian Wang (Arm Technology China) (2): drm/komeda: Update the chip identify drm/komeda: Enable new product D32 support .../drm/arm/display/include/malidp_product.h | 3 +- .../arm/display/komeda/d71/d71_component.c| 2 +- .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 70 +-- .../gpu/drm/arm/display/komeda/d71/d71_regs.h | 13 .../gpu/drm/arm/display/komeda/komeda_dev.c | 62 .../gpu/drm/arm/display/komeda/komeda_dev.h | 14 +--- .../gpu/drm/arm/display/komeda/komeda_drv.c | 10 +-- 7 files changed, 104 insertions(+), 70 deletions(-) -- 2.20.1
[PATCH 1/2] drm/komeda: Update the chip identify
1. Drop komeda-CORE product id comparison and put it into the d71_identify
2. Update pipeline node DT-binding:
*. Skip the needless pipeline DT node.
*. Return fail if the essential pipeline DT node was missing.
With these changes, for one family chips no need to change the DT.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 27 ++--
.../gpu/drm/arm/display/komeda/komeda_dev.c | 62 ++-
.../gpu/drm/arm/display/komeda/komeda_dev.h | 14 +
.../gpu/drm/arm/display/komeda/komeda_drv.c | 9 +--
4 files changed, 60 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index 7e7c9e935eaf..e383a781c9e9 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -578,10 +578,27 @@ static const struct komeda_dev_funcs d71_chip_funcs = {
const struct komeda_dev_funcs *
d71_identify(u32 __iomem *reg_base, struct komeda_chip_info *chip)
{
- chip->arch_id = malidp_read32(reg_base, GLB_ARCH_ID);
- chip->core_id = malidp_read32(reg_base, GLB_CORE_ID);
- chip->core_info = malidp_read32(reg_base, GLB_CORE_INFO);
- chip->bus_width = D71_BUS_WIDTH_16_BYTES;
+ const struct komeda_dev_funcs *funcs;
+ u32 product_id;
- return &d71_chip_funcs;
+ chip->core_id = malidp_read32(reg_base, GLB_CORE_ID);
+
+ product_id = MALIDP_CORE_ID_PRODUCT_ID(chip->core_id);
+
+ switch (product_id) {
+ case MALIDP_D71_PRODUCT_ID:
+ funcs = &d71_chip_funcs;
+ break;
+ default:
+ funcs = NULL;
+ DRM_ERROR("Unsupported product: 0x%x\n", product_id);
+ }
+
+ if (funcs) {
+ chip->arch_id = malidp_read32(reg_base, GLB_ARCH_ID);
+ chip->core_info = malidp_read32(reg_base, GLB_CORE_INFO);
+ chip->bus_width = D71_BUS_WIDTH_16_BYTES;
+ }
+
+ return funcs;
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 2aee735a683f..dd4a0ba1c37d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -125,23 +125,16 @@ static int to_color_format(const char *str)
return format;
}
-static int komeda_parse_pipe_dt(struct komeda_dev *mdev, struct device_node
*np)
+static int komeda_parse_pipe_dt(struct komeda_pipeline *pipe)
{
- struct komeda_pipeline *pipe;
+ struct device_node *np = pipe->of_node;
struct clk *clk;
- u32 pipe_id;
- int ret = 0, color_format;
+ u32 color_format;
const char *str;
- ret = of_property_read_u32(np, "reg", &pipe_id);
- if (ret != 0 || pipe_id >= mdev->n_pipelines)
- return -EINVAL;
-
- pipe = mdev->pipelines[pipe_id];
-
clk = of_clk_get_by_name(np, "pxclk");
if (IS_ERR(clk)) {
- DRM_ERROR("get pxclk for pipeline %d failed!\n", pipe_id);
+ DRM_ERROR("get pxclk for pipeline %d failed!\n", pipe->id);
return PTR_ERR(clk);
}
pipe->pxlclk = clk;
@@ -163,7 +156,6 @@ static int komeda_parse_pipe_dt(struct komeda_dev *mdev,
struct device_node *np)
of_graph_get_port_by_id(np, KOMEDA_OF_PORT_OUTPUT);
pipe->dual_link = pipe->of_output_links[0] && pipe->of_output_links[1];
- pipe->of_node = np;
return 0;
}
@@ -172,7 +164,9 @@ static int komeda_parse_dt(struct device *dev, struct
komeda_dev *mdev)
{
struct platform_device *pdev = to_platform_device(dev);
struct device_node *child, *np = dev->of_node;
- int ret;
+ struct komeda_pipeline *pipe;
+ u32 pipe_id = U32_MAX;
+ int ret = -1;
mdev->irq = platform_get_irq(pdev, 0);
if (mdev->irq < 0) {
@@ -181,32 +175,46 @@ static int komeda_parse_dt(struct device *dev, struct
komeda_dev *mdev)
}
for_each_available_child_of_node(np, child) {
- if (of_node_cmp(child->name, "pipeline") == 0) {
- ret = komeda_parse_pipe_dt(mdev, child);
- if (ret) {
- DRM_ERROR("parse pipeline dt error!\n");
+ if (of_node_name_eq(child, "pipeline")) {
+ ret = of_property_read_u32(child, "reg", &pipe_id);
+ if (pipe_id >= mdev->n_pipelines) {
+ DRM_WARN("Skip the redandunt DT node:
pipeline-%u.\n",
+pipe_id);
of_node_put(child);
- break;
+ continue;
}
+ mdev->pipelines[pipe_id]->of_node = child;
+ }
+ }
+
+ for
[PATCH 2/2] drm/komeda: Enable new product D32 support
D32 is simple version of D71, the difference is:
- Only has one pipeline
- Drop the periph block and merge it to GCU
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/include/malidp_product.h | 3 +-
.../arm/display/komeda/d71/d71_component.c| 2 +-
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 43 ---
.../gpu/drm/arm/display/komeda/d71/d71_regs.h | 13 ++
.../gpu/drm/arm/display/komeda/komeda_drv.c | 1 +
5 files changed, 44 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/include/malidp_product.h
b/drivers/gpu/drm/arm/display/include/malidp_product.h
index 1053b11352eb..16a8a2c22c42 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_product.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_product.h
@@ -18,7 +18,8 @@
#define MALIDP_CORE_ID_STATUS(__core_id) (((__u32)(__core_id)) & 0xFF)
/* Mali-display product IDs */
-#define MALIDP_D71_PRODUCT_ID 0x0071
+#define MALIDP_D71_PRODUCT_ID 0x0071
+#define MALIDP_D32_PRODUCT_ID 0x0032
union komeda_config_id {
struct {
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index a68954bb594a..593f8b7e9bb6 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -1178,7 +1178,7 @@ static int d71_timing_ctrlr_init(struct d71_dev *d71,
ctrlr = to_ctrlr(c);
- ctrlr->supports_dual_link = true;
+ ctrlr->supports_dual_link = d71->supports_dual_link;
ctrlr->supports_vrr = true;
set_range(&ctrlr->vfp_range, 0, 0x3FF);
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index e383a781c9e9..8f7c44a0b916 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -371,23 +371,33 @@ static int d71_enum_resources(struct komeda_dev *mdev)
goto err_cleanup;
}
- /* probe PERIPH */
+ /* Only the legacy HW has the periph block, the newer merges the periph
+* into GCU
+*/
value = malidp_read32(d71->periph_addr, BLK_BLOCK_INFO);
- if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH) {
- DRM_ERROR("access blk periph but got blk: %d.\n",
- BLOCK_INFO_BLK_TYPE(value));
- err = -EINVAL;
- goto err_cleanup;
+ if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH)
+ d71->periph_addr = NULL;
+
+ if (d71->periph_addr) {
+ /* probe PERIPHERAL in legacy HW */
+ value = malidp_read32(d71->periph_addr,
PERIPH_CONFIGURATION_ID);
+
+ d71->max_line_size = value & PERIPH_MAX_LINE_SIZE ? 4096 :
2048;
+ d71->max_vsize = 4096;
+ d71->num_rich_layers= value & PERIPH_NUM_RICH_LAYERS ? 2 :
1;
+ d71->supports_dual_link = !!(value & PERIPH_SPLIT_EN);
+ d71->integrates_tbu = !!(value & PERIPH_TBU_EN);
+ } else {
+ value = malidp_read32(d71->gcu_addr, GCU_CONFIGURATION_ID0);
+ d71->max_line_size = GCU_MAX_LINE_SIZE(value);
+ d71->max_vsize = GCU_MAX_NUM_LINES(value);
+
+ value = malidp_read32(d71->gcu_addr, GCU_CONFIGURATION_ID1);
+ d71->num_rich_layers= GCU_NUM_RICH_LAYERS(value);
+ d71->supports_dual_link = GCU_DISPLAY_SPLIT_EN(value);
+ d71->integrates_tbu = GCU_DISPLAY_TBU_EN(value);
}
- value = malidp_read32(d71->periph_addr, PERIPH_CONFIGURATION_ID);
-
- d71->max_line_size = value & PERIPH_MAX_LINE_SIZE ? 4096 : 2048;
- d71->max_vsize = 4096;
- d71->num_rich_layers= value & PERIPH_NUM_RICH_LAYERS ? 2 : 1;
- d71->supports_dual_link = value & PERIPH_SPLIT_EN ? true : false;
- d71->integrates_tbu = value & PERIPH_TBU_EN ? true : false;
-
for (i = 0; i < d71->num_pipelines; i++) {
pipe = komeda_pipeline_add(mdev, sizeof(struct d71_pipeline),
&d71_pipeline_funcs);
@@ -399,7 +409,7 @@ static int d71_enum_resources(struct komeda_dev *mdev)
}
/* loop the register blks and probe */
- i = 2; /* exclude GCU and PERIPH */
+ i = 1; /* exclude GCU */
offset = D71_BLOCK_SIZE; /* skip GCU */
while (i < d71->num_blocks) {
blk_base = mdev->reg_base + (offset >> 2);
@@ -409,9 +419,9 @@ static int d71_enum_resources(struct komeda_dev *mdev)
err = d71_probe_block(d71, &blk, blk_base);
if (err)
goto err_cleanup;
- i++;
}
+ i++;
offset += D71_BLOCK_SIZE;
}
@@ -5
Re: [PATCH 1/5] drm/komeda: Remove clock ratio property
On Fri, Jul 05, 2019 at 02:10:02PM +0200, Daniel Vetter wrote:
> Properties are uapi like anything else, with all the usual rules
> regarding review, testcases, open source userspace ... Furthermore
> driver-private kms properties are highly discouraged, over the past
> few years we've realized we need to make a serious effort at better
> standardizing this stuff.
>
> >From the discussion with Liviu the solution for these here needs
> multiple pieces:
>
> - For being able to reliably read the memory clock we need a DT
> property, plus maybe DT override snippets to fix it if it's wrong.
>
> - For exposing plane limitations to userspace there's TEST_ONLY. There
> is a bit a gap in telling userspace better that scaling doesn't work
> due to limits (atm a good strategy is to retry again without scaling
> when adding a plane didn't work the first time around). But that
> needs a more generic solution, not exposing something extremely
> komeda specific.
>
> - If this is needed by validation tools, you can still expose it in
> debugfs. We have an entire nice infrastructure for debug printing of
> kms objects already, see the various atomic_print_state callbacks
> and infrastructure around them.
>
> Fixes: 1f7f9ab7900e ("drm/komeda: Add engine clock requirement check for the
> downscaling")
> Cc: Lowry Li (Arm Technology China)
> Cc: James Qian Wang (Arm Technology China)
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: Brian Starkey
> Signed-off-by: Daniel Vetter
Hi Daniel:
Thank you for the patch!
Reviewed-by: James Qian Wang (Arm Technology China)
> ---
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 39 ---
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 --
> 2 files changed, 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 3f222f464eb2..e852dc27f1b8 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -454,24 +454,6 @@ static void komeda_crtc_vblank_disable(struct drm_crtc
> *crtc)
> mdev->funcs->on_off_vblank(mdev, kcrtc->master->id, false);
> }
>
> -static int
> -komeda_crtc_atomic_get_property(struct drm_crtc *crtc,
> - const struct drm_crtc_state *state,
> - struct drm_property *property, uint64_t *val)
> -{
> - struct komeda_crtc *kcrtc = to_kcrtc(crtc);
> - struct komeda_crtc_state *kcrtc_st = to_kcrtc_st(state);
> -
> - if (property == kcrtc->clock_ratio_property) {
> - *val = kcrtc_st->clock_ratio;
> - } else {
> - DRM_DEBUG_DRIVER("Unknown property %s\n", property->name);
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
> static const struct drm_crtc_funcs komeda_crtc_funcs = {
> .gamma_set = drm_atomic_helper_legacy_gamma_set,
> .destroy= drm_crtc_cleanup,
> @@ -482,7 +464,6 @@ static const struct drm_crtc_funcs komeda_crtc_funcs = {
> .atomic_destroy_state = komeda_crtc_atomic_destroy_state,
> .enable_vblank = komeda_crtc_vblank_enable,
> .disable_vblank = komeda_crtc_vblank_disable,
> - .atomic_get_property= komeda_crtc_atomic_get_property,
> };
>
> int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> @@ -518,22 +499,6 @@ int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> return 0;
> }
>
> -static int komeda_crtc_create_clock_ratio_property(struct komeda_crtc *kcrtc)
> -{
> - struct drm_crtc *crtc = &kcrtc->base;
> - struct drm_property *prop;
> -
> - prop = drm_property_create_range(crtc->dev, DRM_MODE_PROP_ATOMIC,
> - "CLOCK_RATIO", 0, U64_MAX);
> - if (!prop)
> - return -ENOMEM;
> -
> - drm_object_attach_property(&crtc->base, prop, 0);
> - kcrtc->clock_ratio_property = prop;
> -
> - return 0;
> -}
> -
> static int komeda_crtc_create_slave_planes_property(struct komeda_crtc
> *kcrtc)
> {
> struct drm_crtc *crtc = &kcrtc->base;
> @@ -590,10 +555,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>
> crtc->port = kcrtc->master->of_output_port;
>
> - err = komeda_crtc_create_clock_ratio_property(kcrtc);
> - if (err)
> - return err;
> -
> err = komeda_crtc_create_slave_planes_property(kcrtc);
> if (err)
> return err;
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> index 219fa3f0c336..2775f34bf4ab 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> @@ -95,9 +95,6 @@ struct komeda_crtc {
> /** @disable_done: this flip_done is for tracing the disable */
> struct completion *disable_done;
>
> - /** @clock_ratio_property: property for ratio o
Re: [PATCH 2/5] drm/komeda: remove slave_planes property
On Fri, Jul 05, 2019 at 02:10:03PM +0200, Daniel Vetter wrote:
> Properties are uapi like anything else, with all the usual rules
> regarding review, testcases, open source userspace ... Furthermore
> driver-private kms properties are highly discouraged, over the past
> few years we've realized we need to make a serious effort at better
> standardizing this stuff.
>
> Again this probably needs multiple pieces to solve this properly:
>
> - To make plane configuration less surprising to userspace you
> propably need to virtualize planes, and reorder which logical plane
> you map to which physical one dynamically. Instead of exposing a
> komeda-specific limitation to userspace and expecting them to dtrt.
> I think msm and rcar-du do that already (and others), if you need
> people to chat with or example code.
>
> - If this is needed for validation, again ->atomic_print_state and the
> infrastructure around that is your friend.
>
> Fixes: 3b9dfa4ef28c ("drm/komeda: Add slave pipeline support")
> Cc: Lowry Li (Arm Technology China)
> Cc: James Qian Wang (Arm Technology China)
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: Brian Starkey
> Signed-off-by: Daniel Vetter
Hi Daniel:
Thank you for the patch!
Reviewed-by: James Qian Wang (Arm Technology China)
> ---
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 24 ---
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 ---
> 2 files changed, 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index e852dc27f1b8..f4400788ab94 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -499,26 +499,6 @@ int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> return 0;
> }
>
> -static int komeda_crtc_create_slave_planes_property(struct komeda_crtc
> *kcrtc)
> -{
> - struct drm_crtc *crtc = &kcrtc->base;
> - struct drm_property *prop;
> -
> - if (kcrtc->slave_planes == 0)
> - return 0;
> -
> - prop = drm_property_create_range(crtc->dev, DRM_MODE_PROP_IMMUTABLE,
> - "slave_planes", 0, U32_MAX);
> - if (!prop)
> - return -ENOMEM;
> -
> - drm_object_attach_property(&crtc->base, prop, kcrtc->slave_planes);
> -
> - kcrtc->slave_planes_property = prop;
> -
> - return 0;
> -}
> -
> static struct drm_plane *
> get_crtc_primary(struct komeda_kms_dev *kms, struct komeda_crtc *crtc)
> {
> @@ -555,10 +535,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>
> crtc->port = kcrtc->master->of_output_port;
>
> - err = komeda_crtc_create_slave_planes_property(kcrtc);
> - if (err)
> - return err;
> -
> return err;
> }
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> index 2775f34bf4ab..c545cb963d40 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> @@ -94,9 +94,6 @@ struct komeda_crtc {
>
> /** @disable_done: this flip_done is for tracing the disable */
> struct completion *disable_done;
> -
> - /** @slave_planes_property: property for slaves of the planes */
> - struct drm_property *slave_planes_property;
> };
>
> /**
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/komeda: remove img_enhancement property
On Fri, Jul 05, 2019 at 02:10:04PM +0200, Daniel Vetter wrote:
> Properties are uapi like anything else, with all the usual rules
> regarding review, testcases, open source userspace ... Furthermore
> driver-private kms properties are highly discouraged, over the past
> few years we've realized we need to make a serious effort at better
> standardizing this stuff.
>
> Again this probably needs multiple pieces to solve this properly:
>
> - Instead of expecting userspace to compute this (and duplicating
> modeset code), the kernel driver should compute when it's possible
> to enable this better up/downscale mode (assuming I understood
> Liviu correctly on what this does) automatically.
>
> - If this is needed for validation then you want a debugfs file to
> force this one way or the other, or alternatively use
> ->atomic_print_state to dump such hidden driver-private state.
> Depends upon how you do your validation ofc.
>
> Fixes: 42b6f118f6d1 ("drm/komeda: Add image enhancement support")
> Cc: Lowry Li (Arm Technology China)
> Cc: James Qian Wang (Arm Technology China)
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: Brian Starkey
> Signed-off-by: Daniel Vetter
Hi Daniel:
Thank you for the patch!
Reviewed-by: James Qian Wang (Arm Technology China)
> ---
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 2 --
> .../gpu/drm/arm/display/komeda/komeda_plane.c | 19 ++-
> 2 files changed, 2 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> index c545cb963d40..fb2adc233760 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> @@ -34,8 +34,6 @@ struct komeda_plane {
>*/
> struct komeda_layer *layer;
>
> - /** @prop_img_enhancement: for on/off image enhancement */
> - struct drm_property *prop_img_enhancement;
> /** @prop_layer_split: for on/off layer_split */
> struct drm_property *prop_layer_split;
> };
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> index 04b122f28fb6..23db38650a46 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> @@ -197,9 +197,7 @@ komeda_plane_atomic_get_property(struct drm_plane *plane,
> struct komeda_plane *kplane = to_kplane(plane);
> struct komeda_plane_state *st = to_kplane_st(state);
>
> - if (property == kplane->prop_img_enhancement)
> - *val = st->img_enhancement;
> - else if (property == kplane->prop_layer_split)
> + if (property == kplane->prop_layer_split)
> *val = st->layer_split;
> else
> return -EINVAL;
> @@ -216,9 +214,7 @@ komeda_plane_atomic_set_property(struct drm_plane *plane,
> struct komeda_plane *kplane = to_kplane(plane);
> struct komeda_plane_state *st = to_kplane_st(state);
>
> - if (property == kplane->prop_img_enhancement)
> - st->img_enhancement = !!val;
> - else if (property == kplane->prop_layer_split)
> + if (property == kplane->prop_layer_split)
> st->layer_split = !!val;
> else
> return -EINVAL;
> @@ -258,17 +254,6 @@ komeda_plane_create_layer_properties(struct komeda_plane
> *kplane,
> struct drm_plane *plane = &kplane->base;
> struct drm_property *prop = NULL;
>
> - /* property: layer image_enhancement */
> - if (layer->base.supported_outputs & KOMEDA_PIPELINE_SCALERS) {
> - prop = drm_property_create_bool(drm, DRM_MODE_PROP_ATOMIC,
> - "img_enhancement");
> - if (!prop)
> - return -ENOMEM;
> -
> - drm_object_attach_property(&plane->base, prop, 0);
> - kplane->prop_img_enhancement = prop;
> - }
> -
> /* property: layer split */
> if (layer->right) {
> prop = drm_property_create_bool(drm, DRM_MODE_PROP_ATOMIC,
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/komeda: Remove layer_split property
On Fri, Jul 05, 2019 at 02:10:05PM +0200, Daniel Vetter wrote:
> Properties are uapi like anything else, with all the usual rules
> regarding review, testcases, open source userspace ... Furthermore
> driver-private kms properties are highly discouraged, over the past
> few years we've realized we need to make a serious effort at better
> standardizing this stuff.
>
> Again this probably needs multiple pieces to solve this properly:
>
> - Instead of expecting userspace to compute this (and duplicating
> modeset code), the kernel driver should compute when it's necessary
> to enable layer_split mode to make a configuration possible. I.e. in
> komeda_plane_atomic_check() first try komeda_build_layer_data_flow()
> and if that fails, try komeda_build_layer_split_data_flow(), and set
> dflow.en_split accordingly. Assuming I understand somewhat correctly
> what this does.
>
> - If this is needed for validation then you want a debugfs file to
> force this one way or the other, or alternatively use
> ->atomic_print_state to dump such hidden driver-private state.
> Depends upon how you do your validation ofc.
>
> Fixes: a407a6509393 ("drm/komeda: Add layer split support")
> Cc: Lowry Li (Arm Technology China)
> Cc: James Qian Wang (Arm Technology China)
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: Brian Starkey
> Signed-off-by: Daniel Vetter
Hi Daniel:
Thank you for the patch!
Reviewed-by: James Qian Wang (Arm Technology China)
> ---
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 -
> .../gpu/drm/arm/display/komeda/komeda_plane.c | 61 ---
> 2 files changed, 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> index fb2adc233760..0c006576a25c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> @@ -33,9 +33,6 @@ struct komeda_plane {
>* Layers with same capabilities.
>*/
> struct komeda_layer *layer;
> -
> - /** @prop_layer_split: for on/off layer_split */
> - struct drm_property *prop_layer_split;
> };
>
> /**
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> index 23db38650a46..5bb8553cc117 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> @@ -188,40 +188,6 @@ komeda_plane_atomic_destroy_state(struct drm_plane
> *plane,
> kfree(to_kplane_st(state));
> }
>
> -static int
> -komeda_plane_atomic_get_property(struct drm_plane *plane,
> - const struct drm_plane_state *state,
> - struct drm_property *property,
> - uint64_t *val)
> -{
> - struct komeda_plane *kplane = to_kplane(plane);
> - struct komeda_plane_state *st = to_kplane_st(state);
> -
> - if (property == kplane->prop_layer_split)
> - *val = st->layer_split;
> - else
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> -static int
> -komeda_plane_atomic_set_property(struct drm_plane *plane,
> - struct drm_plane_state *state,
> - struct drm_property *property,
> - uint64_t val)
> -{
> - struct komeda_plane *kplane = to_kplane(plane);
> - struct komeda_plane_state *st = to_kplane_st(state);
> -
> - if (property == kplane->prop_layer_split)
> - st->layer_split = !!val;
> - else
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> static bool
> komeda_plane_format_mod_supported(struct drm_plane *plane,
> u32 format, u64 modifier)
> @@ -241,32 +207,9 @@ static const struct drm_plane_funcs komeda_plane_funcs =
> {
> .reset = komeda_plane_reset,
> .atomic_duplicate_state = komeda_plane_atomic_duplicate_state,
> .atomic_destroy_state = komeda_plane_atomic_destroy_state,
> - .atomic_get_property= komeda_plane_atomic_get_property,
> - .atomic_set_property= komeda_plane_atomic_set_property,
> .format_mod_supported = komeda_plane_format_mod_supported,
> };
>
> -static int
> -komeda_plane_create_layer_properties(struct komeda_plane *kplane,
> - struct komeda_layer *layer)
> -{
> - struct drm_device *drm = kplane->base.dev;
> - struct drm_plane *plane = &kplane->base;
> - struct drm_property *prop = NULL;
> -
> - /* property: layer split */
> - if (layer->right) {
> - prop = drm_property_create_bool(drm, DRM_MODE_PROP_ATOMIC,
> - "layer_split");
> - if (!prop)
> - return -ENOMEM;
> - kplane->prop_layer_split = prop;
> - drm_object_attach_property(&plane->base, prop, 0);
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > > > Maybe instead of edp-connector one would introduce integrator's specific > > > connector, for example with compatible "olimex,teres-edp-connector" > > > which should follow edp abstract connector rules? This will be at least > > > consistent with below presentation[1] - eDP requirements depends on > > > integrator. Then if olimex has standard way of dealing with panels > > > present in olimex/teres platforms the driver would then create > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > > Anyway it still looks fishy for me :), maybe because I am not > > > familiarized with details of these platforms. > > > > That makes sense yes > > Actually, it makes no sense at all. Current implementation for anx6345 > driver works fine as is with any panel specified assuming panel delays > are long enough for connected panel. It just doesn't use panel timings > from the driver. Creating a platform driver for connector itself looks > redundant since it can't be reused, it doesn't describe actual > hardware and it's just defeats purpose of DT by introducing > board-specific code. I'm not sure where you got the idea that the purpose of DT is to not have any board-specific code. It's perfectly fine to have some, that's even why there's a compatible assigned to each and every board. What the DT is about is allowing us to have a generic behaviour that we can detect: we can have a given behaviour for a given board, and a separate one for another one, and this will be evaluated at runtime. This is *exactly* what this is about: we can have a compatible that sets a given, more specific, behaviour (olimex,teres-edp-connector) while saying that this is compatible with the generic behaviour (edp-connector). That way, any OS will know what quirk to apply if needed, and if not that it can use the generic behaviour. And we could create a generic driver, for the generic behaviour if needed. > There's another issue: if we introduce edp-connector we'll have to > specify power up delays somewhere (in dts? or in platform driver?), so > edp-connector doesn't really solve the issue of multiple panels with > same motherboard. And that's what that compatible is about :) > I'd say DT overlays should be preferred solution here, not another > connector binding. Overlays are a way to apply a device tree dynamically. It's orthogonal to the binding. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard 写到: >On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: >> > > Maybe instead of edp-connector one would introduce integrator's >specific >> > > connector, for example with compatible >"olimex,teres-edp-connector" >> > > which should follow edp abstract connector rules? This will be at >least >> > > consistent with below presentation[1] - eDP requirements depends >on >> > > integrator. Then if olimex has standard way of dealing with >panels >> > > present in olimex/teres platforms the driver would then create >> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I >guess. >> > > Anyway it still looks fishy for me :), maybe because I am not >> > > familiarized with details of these platforms. >> > >> > That makes sense yes >> >> Actually, it makes no sense at all. Current implementation for >anx6345 >> driver works fine as is with any panel specified assuming panel >delays >> are long enough for connected panel. It just doesn't use panel >timings >> from the driver. Creating a platform driver for connector itself >looks >> redundant since it can't be reused, it doesn't describe actual >> hardware and it's just defeats purpose of DT by introducing >> board-specific code. > >I'm not sure where you got the idea that the purpose of DT is to not >have any board-specific code. > >It's perfectly fine to have some, that's even why there's a compatible >assigned to each and every board. > >What the DT is about is allowing us to have a generic behaviour that >we can detect: we can have a given behaviour for a given board, and a >separate one for another one, and this will be evaluated at runtime. > >This is *exactly* what this is about: we can have a compatible that >sets a given, more specific, behaviour (olimex,teres-edp-connector) >while saying that this is compatible with the generic behaviour >(edp-connector). That way, any OS will know what quirk to apply if >needed, and if not that it can use the generic behaviour. > >And we could create a generic driver, for the generic behaviour if >needed. > >> There's another issue: if we introduce edp-connector we'll have to >> specify power up delays somewhere (in dts? or in platform driver?), >so >> edp-connector doesn't really solve the issue of multiple panels with >> same motherboard. > >And that's what that compatible is about :) Maybe we can introduce a connector w/o any driver just like hdmi-connector? > >> I'd say DT overlays should be preferred solution here, not another >> connector binding. > >Overlays are a way to apply a device tree dynamically. It's orthogonal >to the binding. > >Maxime > >-- >Maxime Ripard, Bootlin >Embedded Linux and Kernel engineering >https://bootlin.com -- 使用 K-9 Mail 发送自我的Android设备。
Re: [PATCH v2 4/4] backlight: add led-backlight driver
On Mon, Jul 08, 2019 at 12:27:00PM +0200, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds a led-backlight driver (led_bl), which is similar to
> pwm_bl except the driver uses a LED class driver to adjust the
> brightness in the HW. Multiple LEDs can be used for a single backlight.
>
> Signed-off-by: Tomi Valkeinen
> Signed-off-by: Jean-Jacques Hiblot
> ---
> drivers/video/backlight/Kconfig | 7 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/led_bl.c | 235 +++
> 3 files changed, 243 insertions(+)
> create mode 100644 drivers/video/backlight/led_bl.c
> diff --git a/drivers/video/backlight/led_bl.c
> b/drivers/video/backlight/led_bl.c
> new file mode 100644
> index ..7644277cfdbb
> --- /dev/null
> +++ b/drivers/video/backlight/led_bl.c
> @@ -0,0 +1,235 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2015-2019 Texas Instruments Incorporated -
> http://www.ti.com/
> + * Author: Tomi Valkeinen
> + *
> + * Based on pwm_bl.c
> + */
> +
> +#include
> +#include
Header should no longer be needed.
> +static int led_bl_probe(struct platform_device *pdev)
> +{
> + struct backlight_properties props;
> + struct led_bl_data *priv;
> + int ret;
> + int i;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> +
> + priv->dev = &pdev->dev;
> +
> + ret = led_bl_parse_dt(&pdev->dev, priv);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to parse DT data\n");
> + return ret;
> + }
> + priv->leds = devm_kzalloc(&pdev->dev,
> + sizeof(struct led_classdev *) * priv->nb_leds,
> + GFP_KERNEL);
> + if (!priv->leds)
> + return -ENOMEM;
> +
> + for (i = 0; i < priv->nb_leds; i++) {
> + priv->leds[i] = devm_led_get(&pdev->dev, i);
> + if (IS_ERR(priv->leds[i]))
> + return PTR_ERR(priv->leds[i]);
> + }
> +
> + memset(&props, 0, sizeof(struct backlight_properties));
> + props.type = BACKLIGHT_RAW;
> + props.max_brightness = priv->max_brightness;
> + priv->bl_dev = backlight_device_register(dev_name(&pdev->dev),
> + &pdev->dev, priv, &led_bl_ops, &props);
> + if (IS_ERR(priv->bl_dev)) {
> + dev_err(&pdev->dev, "failed to register backlight\n");
> + ret = PTR_ERR(priv->bl_dev);
> + goto err;
goto is pointless for a pure-devm function.
> + }
> +
> + priv->bl_dev->props.brightness = priv->default_brightness;
> + backlight_update_status(priv->bl_dev);
This will light up the backlight during backlight probe.
Can you take a look at pwm_backlight_initial_power_state() and decide
how much of it applies to an LED based backlight (the phandle stuff
certainly does).
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] backlight: rave-sp: don't touch initial state and register with correct device
On Mon, Jul 08, 2019 at 02:41:29PM +0200, Lucas Stach wrote: > This way the backlight can be referenced through its device node and > enabling/disabling can be managed through the panel driver. > > Signed-off-by: Lucas Stach Reviewed-by: Daniel Thompson > --- > drivers/video/backlight/rave-sp-backlight.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/backlight/rave-sp-backlight.c > b/drivers/video/backlight/rave-sp-backlight.c > index 462f14a1b19d..05b5f003a3d1 100644 > --- a/drivers/video/backlight/rave-sp-backlight.c > +++ b/drivers/video/backlight/rave-sp-backlight.c > @@ -48,14 +48,20 @@ static int rave_sp_backlight_probe(struct platform_device > *pdev) > struct device *dev = &pdev->dev; > struct backlight_device *bd; > > - bd = devm_backlight_device_register(dev, pdev->name, dev->parent, > + bd = devm_backlight_device_register(dev, pdev->name, dev, > dev_get_drvdata(dev->parent), > &rave_sp_backlight_ops, > &rave_sp_backlight_props); > if (IS_ERR(bd)) > return PTR_ERR(bd); > > - backlight_update_status(bd); > + /* > + * If there is a phandle pointing to the device node we can > + * assume that another device will manage the status changes. > + * If not we make sure the backlight is in a consistent state. > + */ > + if (!dev->of_node->phandle) > + backlight_update_status(bd); > > return 0; > } > -- > 2.20.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110702] segfault in radeonsi HEVC hardware decoding with yuv420p10le
https://bugs.freedesktop.org/show_bug.cgi?id=110702 Juan A. Suarez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Juan A. Suarez --- And the fix is also included in Mesa 19.1.2 release. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110783] Mesa 19.1 rc crashing MPV with VAAPI
https://bugs.freedesktop.org/show_bug.cgi?id=110783 --- Comment #20 from Juan A. Suarez --- The fix has landed in 19.1.2 release. Can you try it again? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110944] [Bisected] Blender 2.8 crashes when closing certain windows
https://bugs.freedesktop.org/show_bug.cgi?id=110944 Juan A. Suarez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Juan A. Suarez --- The patch has been released also with Mesa 19.1.2. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/client: remove the exporting of drm_client_close
Den 04.07.2019 16.07, skrev Emil Velikov: > On Thu, 4 Jul 2019 at 08:27, Denis Efremov wrote: >> >> The function drm_client_close is declared as static and marked as >> EXPORT_SYMBOL. It's a bit confusing for an internal function to be >> exported. The area of visibility for such function is its .c file >> and all other modules. Other *.c files of the same module can't use it, >> despite all other modules can. Relying on the fact that this is the >> internal function and it's not a crucial part of the API, the patch >> removes the EXPORT_SYMBOL marking of drm_client_close. >> >> Signed-off-by: Denis Efremov > > Nice one: > Reviewed-by: Emil Velikov Thanks, applied. Noralf.
Re: [PATCH V3 4/5] drm/vkms: Compute CRC without change input data
On Tue, 2019-06-25 at 22:38 -0300, Rodrigo Siqueira wrote:
> The compute_crc() function is responsible for calculating the
> framebuffer CRC value; due to the XRGB format, this function has to
> ignore the alpha channel during the CRC computation. Therefore,
> compute_crc() set zero to the alpha channel directly in the input
> framebuffer, which is not a problem since this function receives a
> copy
> of the original buffer. However, if we want to use this function in a
> context without a buffer copy, it will change the initial value. This
> patch makes compute_crc() calculate the CRC value without modifying
> the
> input framebuffer.
>
> Signed-off-by: Rodrigo Siqueira
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 31 +-
> --
> 1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 51a270514219..8126aa0f968f 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -6,33 +6,40 @@
> #include
> #include
>
> +static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
> + const struct vkms_composer *composer)
> +{
> + int src_offset = composer->offset + (y * composer->pitch)
> + + (x * composer->cpp);
> +
> + return *(u32 *)&buffer[src_offset];
> +}
> +
> /**
> * compute_crc - Compute CRC value on output frame
> *
> - * @vaddr_out: address to final framebuffer
> + * @vaddr: address to final framebuffer
> * @composer: framebuffer's metadata
> *
> * returns CRC value computed using crc32 on the visible portion of
> * the final framebuffer at vaddr_out
> */
> -static uint32_t compute_crc(void *vaddr_out, struct vkms_composer
> *composer)
> +static uint32_t compute_crc(const u8 *vaddr,
> + const struct vkms_composer *composer)
> {
> - int i, j, src_offset;
> + int x, y;
> int x_src = composer->src.x1 >> 16;
> int y_src = composer->src.y1 >> 16;
> int h_src = drm_rect_height(&composer->src) >> 16;
> int w_src = drm_rect_width(&composer->src) >> 16;
> - u32 crc = 0;
> + u32 crc = 0, pixel = 0;
>
> - for (i = y_src; i < y_src + h_src; ++i) {
> - for (j = x_src; j < x_src + w_src; ++j) {
> - src_offset = composer->offset
> - + (i * composer->pitch)
> - + (j * composer->cpp);
> + for (y = y_src; y < y_src + h_src; ++y) {
> + for (x = x_src; x < x_src + w_src; ++x) {
> /* XRGB format ignores Alpha channel */
> - memset(vaddr_out + src_offset + 24, 0, 8);
Hi Rodgrigo,
Do I understand correctly, that previous version with memset was
actually zeroing out the whole fb, except first 24 bytes? On the first
iteration bytes 24..32 would be zeroed, on the second 25..33, etc.
Should we add more CRC tests to IGT, so we can catch such mistakes? For
example, compute CRC, than augment random pixel and assert that CRC
changed.
Oleg
> - crc = crc32_le(crc, vaddr_out + src_offset,
> -sizeof(u32));
> + pixel = get_pixel_from_buffer(x, y, vaddr,
> composer);
> + bitmap_clear((void *)&pixel, 0, 8);
> + crc = crc32_le(crc, (void *)&pixel,
> sizeof(u32));
> }
> }
>
smime.p7s
Description: S/MIME cryptographic signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] ASoC: hdmi-codec: Add an op to set callback function for plug event
On 2019-07-05 06:26, Cheng-Yi Chiang wrote:
+static void hdmi_codec_jack_report(struct hdmi_codec_priv *hcp,
+ unsigned int jack_status)
+{
+ if (!hcp->jack)
+ return;
+
+ if (jack_status != hcp->jack_status) {
+ snd_soc_jack_report(hcp->jack, jack_status, SND_JACK_LINEOUT);
+ hcp->jack_status = jack_status;
+ }
+}
Single "if" statement instead? The first "if" does not even cover all
cases - if the secondary check fails, you'll "return;" too.
+/**
+ * hdmi_codec_set_jack_detect - register HDMI plugged callback
+ * @component: the hdmi-codec instance
+ * @jack: ASoC jack to report (dis)connection events on
+ */
+int hdmi_codec_set_jack_detect(struct snd_soc_component *component,
+ struct snd_soc_jack *jack)
+{
+ struct hdmi_codec_priv *hcp = snd_soc_component_get_drvdata(component);
+ int ret;
+
+ if (hcp->hcd.ops->hook_plugged_cb) {
+ hcp->jack = jack;
+ ret = hcp->hcd.ops->hook_plugged_cb(component->dev->parent,
+ hcp->hcd.data,
+ plugged_cb);
+ if (ret) {
+ hcp->jack = NULL;
+ return ret;
+ }
+ return 0;
+ }
+ return -EOPNOTSUPP;
+}
+EXPORT_SYMBOL_GPL(hdmi_codec_set_jack_detect);
int ret = -EOPNOTSUPP;
(...)
return ret;
In consequence, you can reduce the number of "return(s)" and also remove
the redundant parenthesis for the if-statement used to set jack to NULL.
Czarek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] ASoC: hdmi-codec: Add an op to set callback function for plug event
On Tue, Jul 9, 2019 at 7:47 PM Cezary Rojewski
wrote:
>
> On 2019-07-05 06:26, Cheng-Yi Chiang wrote:
> > +static void hdmi_codec_jack_report(struct hdmi_codec_priv *hcp,
> > +unsigned int jack_status)
> > +{
> > + if (!hcp->jack)
> > + return;
> > +
> > + if (jack_status != hcp->jack_status) {
> > + snd_soc_jack_report(hcp->jack, jack_status, SND_JACK_LINEOUT);
> > + hcp->jack_status = jack_status;
> > + }
> > +}
>
> Single "if" statement instead? The first "if" does not even cover all
> cases - if the secondary check fails, you'll "return;" too.
>
ACK.
I will fix in v2.
> > +/**
> > + * hdmi_codec_set_jack_detect - register HDMI plugged callback
> > + * @component: the hdmi-codec instance
> > + * @jack: ASoC jack to report (dis)connection events on
> > + */
> > +int hdmi_codec_set_jack_detect(struct snd_soc_component *component,
> > +struct snd_soc_jack *jack)
> > +{
> > + struct hdmi_codec_priv *hcp =
> > snd_soc_component_get_drvdata(component);
> > + int ret;
> > +
> > + if (hcp->hcd.ops->hook_plugged_cb) {
> > + hcp->jack = jack;
> > + ret = hcp->hcd.ops->hook_plugged_cb(component->dev->parent,
> > + hcp->hcd.data,
> > + plugged_cb);
> > + if (ret) {
> > + hcp->jack = NULL;
> > + return ret;
> > + }
> > + return 0;
> > + }
> > + return -EOPNOTSUPP;
> > +}
> > +EXPORT_SYMBOL_GPL(hdmi_codec_set_jack_detect);
>
> int ret = -EOPNOTSUPP;
> (...)
>
> return ret;
>
> In consequence, you can reduce the number of "return(s)" and also remove
> the redundant parenthesis for the if-statement used to set jack to NULL.
>
> Czarek
ACK
will fix in v2.
Thanks a lot for the review!
Re: [PATCH 1/4] ASoC: hdmi-codec: Add an op to set callback function for plug event
On Mon, Jul 8, 2019 at 1:03 PM Cheng-yi Chiang wrote: > > On Fri, Jul 5, 2019 at 8:12 PM Mark Brown wrote: > > > > On Fri, Jul 05, 2019 at 03:08:37PM +0800, Tzung-Bi Shih wrote: > > > On Fri, Jul 5, 2019 at 12:26 PM Cheng-Yi Chiang > > > wrote: > > > > > > +typedef void (*hdmi_codec_plugged_cb)(struct platform_device *dev, > > > > + bool plugged); > > > > + > > > > > The callback prototype is "weird" by struct platform_device. Is it > > > possible to having snd_soc_component instead of platform_device? > > > > Or if it's got to be a device why not just a generic device so > > we're not tied to a particular bus here? > > My intention was to invoke the call in dw-hdmi.c like this: > > hdmi->plugged_cb(hdmi->audio, >result == connector_status_connected); > > Here hdmi->audio is a platform_device. > I think dw-hdmi can not get snd_soc_component easily. > I can use a generic device here so the ops is more general. > The calling will be like > hdmi->plugged_cb(&hdmi->audio->dev, >result == connector_status_connected); > I will update this in v2. > Thanks! I have thought about this a bit more. And I think the more proper interface is to pass in a generic struct device* for codec. This way, the user of hdmi-codec driver on the DRM side is not limited to the relation chain of audio platform device -> codec platform device, which is just a special case in dw-hdmi driver. As long as DRM side can get hdmi-codec device pointer through drv_data, it can use this callback. Hope this makes the interface more generic.
Re: [PATCH v5 05/12] drm/modes: Rewrite the command line parser
Hi, On Fri, Jul 05, 2019 at 07:54:47PM +0300, Dmitry Osipenko wrote: > 17.06.2019 17:51, Maxime Ripard пишет: > > From: Maxime Ripard > > > > Rewrite the command line parser in order to get away from the state machine > > parsing the video mode lines. > > > > Hopefully, this will allow to extend it more easily to support named modes > > and / or properties set directly on the command line. > > > > Reviewed-by: Noralf Trønnes > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/drm_modes.c | 325 +++-- > > 1 file changed, 210 insertions(+), 115 deletions(-) > > I have a Tegra device that uses a stock android bootloader which > passes "video=tegrafb" in the kernels cmdline. That wasn't a problem > before this patch, but now Tegra DRM driver fails to probe because > the mode is 0x0:0 and hence framebuffer allocation fails. Is it a > legit regression that should be fixed in upstream? Thierry indeed reported that issue, but the discussion pretty much stalled since then. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] v4l: Add definitions for missing 16-bit RGB4444 formats
Hi Laurent,
On 3/28/19 8:07 AM, Laurent Pinchart wrote:
> The V4L2 API is missing the 16-bit RGB formats for the RGBA, RGBX,
> ABGR, XBGR, BGRA and BGRX component orders. Add them, using the same
> 4CCs as DRM.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../media/uapi/v4l/pixfmt-packed-rgb.rst | 138 ++
> include/uapi/linux/videodev2.h| 6 +
> 2 files changed, 144 insertions(+)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 4e5222726719..df9fa78a6ab7 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -514,6 +514,12 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_RGB444 v4l2_fourcc('R', '4', '4', '4') /* 16
> */
> #define V4L2_PIX_FMT_ARGB444 v4l2_fourcc('A', 'R', '1', '2') /* 16
> */
> #define V4L2_PIX_FMT_XRGB444 v4l2_fourcc('X', 'R', '1', '2') /* 16
> */
> +#define V4L2_PIX_FMT_RGBA444 v4l2_fourcc('R', 'A', '1', '2') /* 16
> */
> +#define V4L2_PIX_FMT_RGBX444 v4l2_fourcc('R', 'X', '1', '2') /* 16
> */
> +#define V4L2_PIX_FMT_ABGR444 v4l2_fourcc('A', 'B', '1', '2') /* 16
> */
> +#define V4L2_PIX_FMT_XBGR444 v4l2_fourcc('X', 'B', '1', '2') /* 16
> */
> +#define V4L2_PIX_FMT_BGRA444 v4l2_fourcc('B', 'A', '1', '2') /* 16
> */
Hmm, 'BA12' clashes with V4L2_PIX_FMT_SGRBG12 which has the same fourcc.
That fourcc makes no sense for V4L2_PIX_FMT_SGRBG12 and I suspect it was
a mistake, but it's been in use since 2014.
I think V4L2_PIX_FMT_BGRA444 should get a different fourcc and be backported to
5.2.
Can you address this issue?
Regards,
Hans
> +#define V4L2_PIX_FMT_BGRX444 v4l2_fourcc('B', 'X', '1', '2') /* 16
> */
> #define V4L2_PIX_FMT_RGB555 v4l2_fourcc('R', 'G', 'B', 'O') /* 16
> RGB-5-5-5 */
> #define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16
> ARGB-1-5-5-5 */
> #define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16
> XRGB-1-5-5-5 */
>
Re: [PATCH] drm/amdgpu: Fix build without CONFIG_HMM_MIRROR
On Tue, Jul 9, 2019 at 8:55 AM YueHaibing wrote:
>
> If CONFIG_HMM_MIRROR is not set, building may fails:
>
> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu.h:72:0,
> from drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:40:
> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h:69:20: error: field mirror has
> incomplete type
> struct hmm_mirror mirror;
>
> Fixes: 7590f6d211ec ("drm/amdgpu: Prepare for hmm_range_register API change")
> Signed-off-by: YueHaibing
I already applied a similar patch from Arnd.
Thanks,
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
> index 281fd9f..b14f175 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
> @@ -65,8 +65,10 @@ struct amdgpu_mn {
> struct rw_semaphore lock;
> struct rb_root_cached objects;
>
> +#if defined(CONFIG_HMM_MIRROR)
> /* HMM mirror */
> struct hmm_mirror mirror;
> +#endif
> };
>
> #if defined(CONFIG_HMM_MIRROR)
> --
> 2.7.4
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/19] arm64: renesas: Update 'vsps' property
Hi Jacopo,
On 08/07/2019 04:11, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Sat, Jul 06, 2019 at 04:07:30PM +0200, Jacopo Mondi wrote:
>> Update the 'vsps' property in the R-Car Gen3 SoC device tree files to
>> match what's in in the documentation example.
>>
>> Signed-off-by: Jacopo Mondi
>
> Reviewed-by: Laurent Pinchart
+1 from me too. This certainly improves readability/clarity IMO.
Reviewed-by: Kieran Bingham
>
>> ---
>> arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 2 +-
>> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
>> arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
>> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 +-
>> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 +-
>> 5 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
>> index 3f86db199dbf..e643f9d3c102 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
>> @@ -1807,7 +1807,7 @@
>> clocks = <&cpg CPG_MOD 724>,
>> <&cpg CPG_MOD 723>;
>> clock-names = "du.0", "du.1";
>> -vsps = <&vspd0 0 &vspd1 0>;
>> +vsps = <&vspd0 0>, <&vspd1 0>;
>> status = "disabled";
>>
>> ports {
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> index 097538cc4b1f..432f4036a8a8 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> @@ -3098,7 +3098,7 @@
>> <&cpg CPG_MOD 722>,
>> <&cpg CPG_MOD 721>;
>> clock-names = "du.0", "du.1", "du.2", "du.3";
>> -vsps = <&vspd0 0 &vspd1 0 &vspd2 0 &vspd0 1>;
>> +vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
>> status = "disabled";
>>
>> ports {
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> index 2554b1742dbf..b701aeb4f438 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> @@ -2456,7 +2456,7 @@
>> clock-names = "du.0", "du.1", "du.3";
>> status = "disabled";
>>
>> -vsps = <&vspd0 0 &vspd1 0 &vspd0 1>;
>> +vsps = <&vspd0 0>, <&vspd1 0>, <&vspd0 1>;
>>
>> ports {
>> #address-cells = <1>;
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
>> index 56cb566ffa09..79db5441b7e7 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
>> @@ -1764,7 +1764,7 @@
>> clocks = <&cpg CPG_MOD 724>,
>> <&cpg CPG_MOD 723>;
>> clock-names = "du.0", "du.1";
>> -vsps = <&vspd0 0 &vspd1 0>;
>> +vsps = <&vspd0 0>, <&vspd1 0>;
>> status = "disabled";
>>
>> ports {
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> index 5bf3af246e14..49a11b4f55bd 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> @@ -1001,7 +1001,7 @@
>> clocks = <&cpg CPG_MOD 724>,
>> <&cpg CPG_MOD 723>;
>> clock-names = "du.0", "du.1";
>> -vsps = <&vspd0 0 &vspd1 0>;
>> +vsps = <&vspd0 0>, <&vspd1 0>;
>> status = "disabled";
>>
>> ports {
>
[GIT PULL] fbdev changes for v5.3
Hi Linus,
Please pull fbdev changes for v5.3. They are:
- removal of fbdev notifier usage for fbcon
- COMPILE_TEST support for more fb drivers
- removal of no longer needed fbdev mxsfb driver
- minor fixes/cleanups for other fb drivers
Please see the signed tag description for details.
Test merge revealed a small merge conflict with SPDX changes, the
resolution is trivial (drivers/video/fbdev/omap2/omapfb/dss/rfbi.c
should be deleted).
Also there is a conflict with media tree (pull request for media
tree has been posted a bit earlier today by Mauro), a fix for it
has been carried in linux-next tree by Stephen:
diff --cc drivers/media/pci/ivtv/ivtvfb.c
index 800b3654cac5,299ff032f528..
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@@ -1251,16 -1246,7 +1251,12 @@@ static int ivtvfb_callback_cleanup(stru
struct osd_info *oi = itv->osd_info;
if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
+ itv->streams[IVTV_DEC_STREAM_TYPE_YUV].vdev.device_caps &=
+ ~V4L2_CAP_VIDEO_OUTPUT_OVERLAY;
+ itv->streams[IVTV_DEC_STREAM_TYPE_MPG].vdev.device_caps &=
+ ~V4L2_CAP_VIDEO_OUTPUT_OVERLAY;
+ itv->v4l2_cap &= ~V4L2_CAP_VIDEO_OUTPUT_OVERLAY;
- if (unregister_framebuffer(&itv->osd_info->ivtvfb_info)) {
- IVTVFB_WARN("Framebuffer %d is in use, cannot unload\n",
- itv->instance);
- return 0;
- }
+ unregister_framebuffer(&itv->osd_info->ivtvfb_info);
IVTVFB_INFO("Unregister framebuffer %d\n", itv->instance);
itv->ivtvfb_restore = NULL;
ivtvfb_blank(FB_BLANK_VSYNC_SUSPEND, &oi->ivtvfb_info);
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:
Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)
are available in the git repository at:
https://github.com/bzolnier/linux.git tags/fbdev-v5.3
for you to fetch changes up to 732146a3f1dc78ebb0d3c4b1f4dc6ea33cc2c58f:
video: fbdev: imxfb: fix a typo in imxfb_probe() (2019-07-05 17:42:13 +0200)
fbdev changes for v5.3:
- remove fbdev notifier usage for fbcon (as prep work to clean up the fbcon
locking), add locking checks in vt/console code and make assorted cleanups
in fbdev and backlight code (Daniel Vetter)
- add COMPILE_TEST support to atmel_lcdfb, da8xx-fb, gbefb, imxfb, pvr2fb and
pxa168fb drivers (me)
- fix DMA API abuse in au1200fb and jz4740_fb drivers (Christoph Hellwig)
- add check for new BGRT status field rotation bits in efifb driver (Hans de
Goede)
- mark expected switch fall-throughs in s3c-fb driver (Gustavo A. R. Silva)
- remove fbdev mxsfb driver in favour of the drm version (Fabio Estevam)
- remove broken rfbi code from omap2fb driver (me)
- misc fixes (Arnd Bergmann, Shobhit Kukreti, Wei Yongjun, me)
- misc cleanups (Gustavo A. R. Silva, Colin Ian King, me)
Arnd Bergmann (1):
video: fbdev: pvr2fb: fix link error for pvr2fb_pci_exit
Bartlomiej Zolnierkiewicz (21):
Merge tag 'v5.2-rc1' of https://git.kernel.org/.../torvalds/linux into
fbdev-for-next
video: fbdev: atafb: remove superfluous function prototypes
video: fbdev: atmel_lcdfb: add COMPILE_TEST support
video: fbdev: imxfb: add COMPILE_TEST support
video: fbdev: pxa168fb: add COMPILE_TEST support
video: fbdev: gbefb: add COMPILE_TEST support
video: fbdev: da8xx-fb: add COMPILE_TEST support
video: fbdev: cyber2000fb: remove superfluous CONFIG_PCI ifdef
video: fbdev: pvr2fb: remove function prototypes
video: fbdev: pvr2fb: add COMPILE_TEST support
Merge tag 'topic/remove-fbcon-notifiers-2019-06-14-1' of
git://anongit.freedesktop.org/drm/drm-misc into fbdev-for-next
Merge branch 'topic/remove-fbcon-notifiers' of
git://anongit.freedesktop.org/drm/drm-misc into fbdev-for-next
video: fbdev: pvr2fb: fix build warning when compiling as module
video: fbdev: imxfb: fix sparse warnings about using incorrect types
video: fbdev: s3c-fb: add COMPILE_TEST support
video: fbdev: omap2: remove rfbi
Merge tag 'topic/remove-fbcon-notifiers-2019-06-26' of
git://anongit.freedesktop.org/drm/drm-misc into fbdev-for-next
video: fbdev: s3c-fb: return -ENOMEM on framebuffer_alloc() failure
video: fbdev: intelfb: return -ENOMEM on framebuffer_alloc() failure
video: fbdev: don't print error message on framebuffer_alloc() failure
video: fbdev: s3c-fb: fix sparse warnings about using incorrect types
Christoph Hellwig (2):
au1200fb: fix DMA API abuse
jz4740_fb: fix DMA API abuse
Colin Ian King (1):
video: fbdev: atm
[Bug 110783] Mesa 19.1 rc crashing MPV with VAAPI
https://bugs.freedesktop.org/show_bug.cgi?id=110783 --- Comment #21 from ITwrx --- @juan sure, but i'll probably wait long enough for arch to package the new version. Thanks for letting me know. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/60] drm/edid: Add flag to drm_display_info to identify HDMI sinks
On 07.07.2019 20:07, Laurent Pinchart wrote:
> The drm_display_info structure contains many fields related to HDMI
> sinks, but none that identifies if a sink compliant with CEA-861 (EDID)
> shall be treated as an HDMI sink or a DVI sink. Add such a flag, and
> populate it according to section 8.3.3 ("DVI/HDMI Device
> Discrimination") of the HDMI v1.3 specification.
>
> Signed-off-by: Laurent Pinchart
It looks like it can replace drm_detect_hdmi_monitor usage in most cases.
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/drm_edid.c | 3 +++
> include/drm/drm_connector.h | 5 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 82a4ceed3fcf..d2e7a5334c3f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4559,6 +4559,8 @@ drm_parse_hdmi_vsdb_video(struct drm_connector
> *connector, const u8 *db)
> struct drm_display_info *info = &connector->display_info;
> u8 len = cea_db_payload_len(db);
>
> + info->is_hdmi = true;
> +
> if (len >= 6)
> info->dvi_dual = db[6] & 1;
> if (len >= 7)
> @@ -4627,6 +4629,7 @@ drm_reset_display_info(struct drm_connector *connector)
> info->cea_rev = 0;
> info->max_tmds_clock = 0;
> info->dvi_dual = false;
> + info->is_hdmi = false;
> info->has_hdmi_infoframe = false;
> info->rgb_quant_range_selectable = false;
> memset(&info->hdmi, 0, sizeof(info->hdmi));
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ca745d9feaf5..e80ca0d149e5 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -426,6 +426,11 @@ struct drm_display_info {
>*/
> bool dvi_dual;
>
> + /**
> + * @is_hdmi: True if the sink is an HDMI device.
> + */
> + bool is_hdmi;
> +
> /**
>* @has_hdmi_infoframe: Does the sink support the HDMI infoframe?
>*/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/60] video: hdmi: Change return type of hdmi_avi_infoframe_init() to void
On 07.07.2019 20:07, Laurent Pinchart wrote: > The hdmi_avi_infoframe_init() never needs to return an error, change its > return type to void. > > Signed-off-by: Laurent Pinchart Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 05/12] drm/modes: Rewrite the command line parser
On 09/07/2019 13:52, Dmitry Osipenko wrote: > 09.07.2019 15:45, Maxime Ripard пишет: >> Hi, >> >> On Fri, Jul 05, 2019 at 07:54:47PM +0300, Dmitry Osipenko wrote: >>> 17.06.2019 17:51, Maxime Ripard пишет: From: Maxime Ripard Rewrite the command line parser in order to get away from the state machine parsing the video mode lines. Hopefully, this will allow to extend it more easily to support named modes and / or properties set directly on the command line. Reviewed-by: Noralf Trønnes Signed-off-by: Maxime Ripard --- drivers/gpu/drm/drm_modes.c | 325 +++-- 1 file changed, 210 insertions(+), 115 deletions(-) >>> >>> I have a Tegra device that uses a stock android bootloader which >>> passes "video=tegrafb" in the kernels cmdline. That wasn't a problem >>> before this patch, but now Tegra DRM driver fails to probe because >>> the mode is 0x0:0 and hence framebuffer allocation fails. Is it a >>> legit regression that should be fixed in upstream? >> >> Thierry indeed reported that issue, but the discussion pretty much >> stalled since then. Yes Thierry is currently out and hence has not responded. I had been planning to look at this this week and responded. > Sorry, this doesn't answer my question. Where it was reported? Same thread [0]. Dmitry, are you able to respond to Maxime's response to Thierry? Cheers Jon [0] https://patchwork.kernel.org/patch/10999393/ -- nvpublic ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/6] drm: Add Content protection type property
On Mon, 8 Jul 2019 14:42:29 +0530
Ramalingam C wrote:
> On 2019-07-08 at 12:59:59 +0300, Pekka Paalanen wrote:
> > On Mon, 8 Jul 2019 12:52:17 +0300
> > Pekka Paalanen wrote:
> >
> > > On Fri, 5 Jul 2019 06:16:37 +0530
> > > Ramalingam C wrote:
> > >
> > > > This patch adds a DRM ENUM property to the selected connectors.
> > > > This property is used for mentioning the protected content's type
> > > > from userspace to kernel HDCP authentication.
> > > >
> > > > Type of the stream is decided by the protected content providers.
> > > > Type 0 content can be rendered on any HDCP protected display wires.
> > > > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> > > >
> > > > So when a userspace sets this property to Type 1 and starts the HDCP
> > > > enable, kernel will honour it only if HDCP2.2 authentication is through
> > > > for type 1. Else HDCP enable will be failed.
> > > >
> > > > Need ACK for this new conenctor property from userspace consumer.
> > > >
> > > > v2:
> > > > cp_content_type is replaced with content_protection_type [daniel]
> > > > check at atomic_set_property is removed [Maarten]
> > > > v3:
> > > > %s/content_protection_type/hdcp_content_type [Pekka]
> > > > v4:
> > > > property is created for the first requested connector and then reused.
> > > > [Danvet]
> > > > v5:
> > > > kernel doc nits addressed [Daniel]
> > > > Rebased as part of patch reordering.
> > > > v6:
> > > > Kernel docs are modified [pekka]
> > > >
> > > > Signed-off-by: Ramalingam C
> > > > Reviewed-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> > > > drivers/gpu/drm/drm_connector.c | 22 ++
> > > > drivers/gpu/drm/drm_hdcp.c| 36 ++-
> > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++-
> > > > include/drm/drm_connector.h | 7 +
> > > > include/drm/drm_hdcp.h| 2 +-
> > > > include/drm/drm_mode_config.h | 6
> > > > include/uapi/drm/drm_mode.h | 4 +++
> > > > 8 files changed, 82 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > index abe38bdf85ae..19ae119f1a5d 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > @@ -747,6 +747,8 @@ static int drm_atomic_connector_set_property(struct
> > > > drm_connector *connector,
> > > > return -EINVAL;
> > > > }
> > > > state->content_protection = val;
> > > > + } else if (property == config->hdcp_content_type_property) {
> > > > + state->hdcp_content_type = val;
> > > > } else if (property == connector->colorspace_property) {
> > > > state->colorspace = val;
> > > > } else if (property == config->writeback_fb_id_property) {
> > > > @@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct
> > > > drm_connector *connector,
> > > > state->hdr_output_metadata->base.id : 0;
> > > > } else if (property == config->content_protection_property) {
> > > > *val = state->content_protection;
> > > > + } else if (property == config->hdcp_content_type_property) {
> > > > + *val = state->hdcp_content_type;
> > > > } else if (property == config->writeback_fb_id_property) {
> > > > /* Writeback framebuffer is one-shot, write and forget
> > > > */
> > > > *val = 0;
> > > > diff --git a/drivers/gpu/drm/drm_connector.c
> > > > b/drivers/gpu/drm/drm_connector.c
> > > > index 068d4b05f1be..17aef88c03a6 100644
> > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > @@ -951,6 +951,28 @@ static const struct drm_prop_enum_list
> > > > hdmi_colorspaces[] = {
> > > > * the value transitions from ENABLED to DESIRED. This signifies
> > > > the link
> > > > * is no longer protected and userspace should take appropriate
> > > > action
> > > > * (whatever that might be).
> > > > + * HDCP Content Type:
> > > > + * This property is used by the userspace to configure the kernel
> > > > with
> > > > + * to be displayed stream's content type. Content Type of a stream
> > > > is
> > > > + * decided by the owner of the stream, as "HDCP Type0" or "HDCP
> > > > Type1".
> > > > + *
> > > > + * The value of the property can be one the below:
> > > > + * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
> > > > + * HDCP Type0 streams can be transmitted on a link which is
> > > > + * encrypted with HDCP 1.4 or higher versions of HDCP(i.e
> > > > HDCP2.2
> > > > + * and more).
> > > > + * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1
> > > > + * HDCP Type1 streams can
Re: [PATCH v5 05/12] drm/modes: Rewrite the command line parser
On 09/07/2019 14:26, Jon Hunter wrote: > > On 09/07/2019 13:52, Dmitry Osipenko wrote: >> 09.07.2019 15:45, Maxime Ripard пишет: >>> Hi, >>> >>> On Fri, Jul 05, 2019 at 07:54:47PM +0300, Dmitry Osipenko wrote: 17.06.2019 17:51, Maxime Ripard пишет: > From: Maxime Ripard > > Rewrite the command line parser in order to get away from the state > machine > parsing the video mode lines. > > Hopefully, this will allow to extend it more easily to support named modes > and / or properties set directly on the command line. > > Reviewed-by: Noralf Trønnes > Signed-off-by: Maxime Ripard > --- > drivers/gpu/drm/drm_modes.c | 325 +++-- > 1 file changed, 210 insertions(+), 115 deletions(-) I have a Tegra device that uses a stock android bootloader which passes "video=tegrafb" in the kernels cmdline. That wasn't a problem before this patch, but now Tegra DRM driver fails to probe because the mode is 0x0:0 and hence framebuffer allocation fails. Is it a legit regression that should be fixed in upstream? >>> >>> Thierry indeed reported that issue, but the discussion pretty much >>> stalled since then. > > Yes Thierry is currently out and hence has not responded. I had been > planning to look at this this week and responded. > >> Sorry, this doesn't answer my question. Where it was reported? > > Same thread [0]. Correction, it was on patch 6/12 and not this one. Jon -- nvpublic ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/60] drm/bridge: dumb-vga-dac: Rename internal symbols to simple-bridge
On 07.07.2019 20:07, Laurent Pinchart wrote:
> The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA
> DACs that don't require configuration. Other non-VGA bridges fall in a
> similar category, and would benefit from a common driver. Prepare for
> this by renaming the internal symbols from dumb-vga-dac to
> simple-bridge.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 149 +-
> 1 file changed, 75 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index d32885b906ae..d46e461ae039 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -16,7 +16,7 @@
> #include
> #include
>
> -struct dumb_vga {
> +struct simple_bridge {
> struct drm_bridge bridge;
> struct drm_connectorconnector;
>
> @@ -24,28 +24,28 @@ struct dumb_vga {
> struct regulator*vdd;
> };
>
> -static inline struct dumb_vga *
> -drm_bridge_to_dumb_vga(struct drm_bridge *bridge)
> +static inline struct simple_bridge *
> +drm_bridge_to_simple_bridge(struct drm_bridge *bridge)
> {
> - return container_of(bridge, struct dumb_vga, bridge);
> + return container_of(bridge, struct simple_bridge, bridge);
> }
>
> -static inline struct dumb_vga *
> -drm_connector_to_dumb_vga(struct drm_connector *connector)
> +static inline struct simple_bridge *
> +drm_connector_to_simple_bridge(struct drm_connector *connector)
> {
> - return container_of(connector, struct dumb_vga, connector);
> + return container_of(connector, struct simple_bridge, connector);
> }
>
> -static int dumb_vga_get_modes(struct drm_connector *connector)
> +static int simple_bridge_get_modes(struct drm_connector *connector)
> {
> - struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> + struct simple_bridge *sbridge =
> drm_connector_to_simple_bridge(connector);
> struct edid *edid;
> int ret;
>
> - if (IS_ERR(vga->ddc))
> + if (IS_ERR(sbridge->ddc))
> goto fallback;
>
> - edid = drm_get_edid(connector, vga->ddc);
> + edid = drm_get_edid(connector, sbridge->ddc);
> if (!edid) {
> DRM_INFO("EDID readout failed, falling back to standard
> modes\n");
> goto fallback;
> @@ -69,14 +69,14 @@ static int dumb_vga_get_modes(struct drm_connector
> *connector)
> return ret;
> }
>
> -static const struct drm_connector_helper_funcs dumb_vga_con_helper_funcs = {
> - .get_modes = dumb_vga_get_modes,
> +static const struct drm_connector_helper_funcs
> simple_bridge_con_helper_funcs = {
> + .get_modes = simple_bridge_get_modes,
> };
>
> static enum drm_connector_status
> -dumb_vga_connector_detect(struct drm_connector *connector, bool force)
> +simple_bridge_connector_detect(struct drm_connector *connector, bool force)
> {
> - struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> + struct simple_bridge *sbridge =
> drm_connector_to_simple_bridge(connector);
>
> /*
>* Even if we have an I2C bus, we can't assume that the cable
> @@ -84,14 +84,14 @@ dumb_vga_connector_detect(struct drm_connector
> *connector, bool force)
>* wire the DDC pins, or the I2C bus might not be working at
>* all.
>*/
> - if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
> + if (!IS_ERR(sbridge->ddc) && drm_probe_ddc(sbridge->ddc))
> return connector_status_connected;
>
> return connector_status_unknown;
> }
>
> -static const struct drm_connector_funcs dumb_vga_con_funcs = {
> - .detect = dumb_vga_connector_detect,
> +static const struct drm_connector_funcs simple_bridge_con_funcs = {
> + .detect = simple_bridge_connector_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .destroy= drm_connector_cleanup,
> .reset = drm_atomic_helper_connector_reset,
> @@ -99,9 +99,9 @@ static const struct drm_connector_funcs dumb_vga_con_funcs
> = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static int dumb_vga_attach(struct drm_bridge *bridge)
> +static int simple_bridge_attach(struct drm_bridge *bridge)
> {
> - struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> + struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
> int ret;
>
> if (!bridge->encoder) {
> @@ -109,48 +109,49 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
> return -ENODEV;
> }
>
> - drm_connector_helper_add(&vga->connector,
> - &dumb_vga_con_helper_funcs);
> - ret = drm_connector_init(bridge->dev, &vga->connector,
> - &dumb_vga_con_funcs, DR
Re: [PATCH 04/60] drm/bridge: dumb-vga-dac: Rename driver to simple-bridge
On 07.07.2019 20:18, Laurent Pinchart wrote:
> The dumb-vga-dac driver can support simple DRM bridges without being
> limited to VGA DACs. Rename it to simple-bridge.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> arch/arm/configs/davinci_all_defconfig | 2 +-
> arch/arm/configs/integrator_defconfig| 2 +-
> arch/arm/configs/multi_v7_defconfig | 2 +-
> arch/arm/configs/shmobile_defconfig | 2 +-
> arch/arm/configs/sunxi_defconfig | 2 +-
> arch/arm/configs/versatile_defconfig | 2 +-
> drivers/gpu/drm/bridge/Kconfig | 16
> drivers/gpu/drm/bridge/Makefile | 2 +-
> .../bridge/{dumb-vga-dac.c => simple-bridge.c} | 2 +-
> 9 files changed, 16 insertions(+), 16 deletions(-)
> rename drivers/gpu/drm/bridge/{dumb-vga-dac.c => simple-bridge.c} (99%)
>
> diff --git a/arch/arm/configs/davinci_all_defconfig
> b/arch/arm/configs/davinci_all_defconfig
> index 4a8cad4d3707..f422d34a4e4e 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -154,7 +154,7 @@ CONFIG_VIDEO_TVP514X=m
> CONFIG_VIDEO_ADV7343=m
> CONFIG_DRM=m
> CONFIG_DRM_TILCDC=m
> -CONFIG_DRM_DUMB_VGA_DAC=m
> +CONFIG_DRM_SIMPLE_BRIDGE=m
> CONFIG_DRM_TINYDRM=m
> CONFIG_TINYDRM_ST7586=m
> CONFIG_FB=y
> diff --git a/arch/arm/configs/integrator_defconfig
> b/arch/arm/configs/integrator_defconfig
> index 747550c7af2f..4d265a689655 100644
> --- a/arch/arm/configs/integrator_defconfig
> +++ b/arch/arm/configs/integrator_defconfig
> @@ -55,7 +55,7 @@ CONFIG_SMC91X=y
> # CONFIG_KEYBOARD_ATKBD is not set
> # CONFIG_SERIO_SERPORT is not set
> CONFIG_DRM=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_DRM_PL111=y
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_FB_MATROX=y
> diff --git a/arch/arm/configs/multi_v7_defconfig
> b/arch/arm/configs/multi_v7_defconfig
> index 6b748f214eae..634e029a5736 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -643,11 +643,11 @@ CONFIG_DRM_PANEL_ORISETECH_OTM8009A=m
> CONFIG_DRM_PANEL_RAYDIUM_RM68200=m
> CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03=m
> CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
> -CONFIG_DRM_DUMB_VGA_DAC=m
> CONFIG_DRM_NXP_PTN3460=m
> CONFIG_DRM_PARADE_PS8622=m
> CONFIG_DRM_SII902X=m
> CONFIG_DRM_SII9234=m
> +CONFIG_DRM_SIMPLE_BRIDGE=m
> CONFIG_DRM_TOSHIBA_TC358764=m
> CONFIG_DRM_I2C_ADV7511=m
> CONFIG_DRM_I2C_ADV7511_AUDIO=y
> diff --git a/arch/arm/configs/shmobile_defconfig
> b/arch/arm/configs/shmobile_defconfig
> index eb02ba9ec6e6..771074e399fb 100644
> --- a/arch/arm/configs/shmobile_defconfig
> +++ b/arch/arm/configs/shmobile_defconfig
> @@ -125,8 +125,8 @@ CONFIG_VIDEO_ADV7604=y
> CONFIG_VIDEO_ML86V7667=y
> CONFIG_DRM=y
> CONFIG_DRM_RCAR_DU=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> CONFIG_DRM_SII902X=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_DRM_I2C_ADV7511=y
> CONFIG_DRM_I2C_ADV7511_AUDIO=y
> CONFIG_FB_SH_MOBILE_LCDC=y
> diff --git a/arch/arm/configs/sunxi_defconfig
> b/arch/arm/configs/sunxi_defconfig
> index df433abfcb02..19cccae84a19 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -99,7 +99,7 @@ CONFIG_RC_DEVICES=y
> CONFIG_IR_SUNXI=y
> CONFIG_DRM=y
> CONFIG_DRM_SUN4I=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_FB_SIMPLE=y
> CONFIG_SOUND=y
> CONFIG_SND=y
> diff --git a/arch/arm/configs/versatile_defconfig
> b/arch/arm/configs/versatile_defconfig
> index 5282324c7cef..afc44c99e7f9 100644
> --- a/arch/arm/configs/versatile_defconfig
> +++ b/arch/arm/configs/versatile_defconfig
> @@ -59,7 +59,7 @@ CONFIG_GPIO_PL061=y
> CONFIG_DRM=y
> CONFIG_DRM_PANEL_ARM_VERSATILE=y
> CONFIG_DRM_PANEL_SIMPLE=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_DRM_PL111=y
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_BACKLIGHT_LCD_SUPPORT=y
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index ee777469293a..a78392e2dbb9 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -37,14 +37,6 @@ config DRM_CDNS_DSI
> Support Cadence DPI to DSI bridge. This is an internal
> bridge and is meant to be directly embedded in a SoC.
>
> -config DRM_DUMB_VGA_DAC
> - tristate "Dumb VGA DAC Bridge support"
> - depends on OF
> - select DRM_KMS_HELPER
> - help
> - Support for non-programmable RGB to VGA DAC bridges, such as ADI
> - ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> -
> config DRM_LVDS_ENCODER
> tristate "Transparent parallel to LVDS encoder support"
> depends on OF
> @@ -108,6 +100,14 @@ config DRM_SII9234
> It is an I2C driver, that detects connection of MHL bridge
> and starts encapsulation of HDMI signal.
>
> +config DRM_SIMPLE_BRIDGE
> + tristate "Simple DRM bridge
Re: [PATCH] drm/vkms: prime import support
Hi Oleg,
First of all, thank you for your patch and for working in this issue.
A few comments inline.
On Thu, Jul 4, 2019 at 5:54 AM Oleg Vasilev wrote:
>
> Bring dmabuf sharing through implementing prime_import_sg_table callback.
> This will help to validate userspace conformance in prime configurations
> without using any actual hardware (e.g. in the cloud).
>
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Signed-off-by: Oleg Vasilev
> ---
> drivers/gpu/drm/vkms/vkms_drv.c | 6 +
> drivers/gpu/drm/vkms/vkms_drv.h | 9 +++
> drivers/gpu/drm/vkms/vkms_gem.c | 46 +
> 3 files changed, 61 insertions(+)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index cc53ef88a331..b71c16d9ca09 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -10,6 +10,7 @@
> */
>
> #include
> +#include
Maybe I missed something, but I think you don't need to add this
include here since you already included it on vkms_gem.
> #include
> #include
> #include
> @@ -96,6 +97,8 @@ static struct drm_driver vkms_driver = {
> .gem_vm_ops = &vkms_gem_vm_ops,
> .gem_free_object_unlocked = vkms_gem_free_object,
> .get_vblank_timestamp = vkms_get_vblank_timestamp,
> + .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> + .gem_prime_import_sg_table = vkms_prime_import_sg_table,
>
> .name = DRIVER_NAME,
> .desc = DRIVER_DESC,
> @@ -147,6 +150,9 @@ static int __init vkms_init(void)
>
> ret = drm_dev_init(&vkms_device->drm, &vkms_driver,
>&vkms_device->platform->dev);
> +
> + dma_coerce_mask_and_coherent(vkms_device->drm.dev,
> +DMA_BIT_MASK(64));
How about capture the return value from dma_coerce_mask_and_coherent()
and warn the user if something wrong happened? Something like:
ret = dma_coerce_mask_and_coherent(..);
if (ret)
DRM_WARN("Failed to set dma mask");
Additionally, I would like to suggest you move this code above
drm_dev_init() since there's a return validation of ret in the below
if.
> if (ret)
> goto out_unregister;
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 12b4db7ac641..fb15101c8f3e 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -126,6 +126,9 @@ struct drm_gem_object *vkms_gem_create(struct drm_device
> *dev,
>u32 *handle,
>u64 size);
>
> +struct vkms_gem_object *vkms_gem_create_private(struct drm_device *dev,
> + u64 size);
> +
> vm_fault_t vkms_gem_fault(struct vm_fault *vmf);
>
> int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
> @@ -137,6 +140,12 @@ int vkms_gem_vmap(struct drm_gem_object *obj);
>
> void vkms_gem_vunmap(struct drm_gem_object *obj);
>
> +/* Prime */
> +struct drm_gem_object *
> +vkms_prime_import_sg_table(struct drm_device *dev,
> + struct dma_buf_attachment *attach,
> + struct sg_table *sg);
> +
> /* CRC Support */
> const char *const *vkms_get_crc_sources(struct drm_crtc *crtc,
> size_t *count);
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index 69048e73377d..a1b837460f63 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -1,5 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> +#include
> #include
>
> #include "vkms_drv.h"
> @@ -117,6 +118,25 @@ struct drm_gem_object *vkms_gem_create(struct drm_device
> *dev,
> return &obj->gem;
> }
>
> +struct vkms_gem_object *vkms_gem_create_private(struct drm_device *dev,
> + u64 size)
> +{
I did not fully get the idea behind this function in this patch, and
it looks like this function is never invoked. Am I right or I missed
something?
> + struct vkms_gem_object *obj;
> +
> + obj = kzalloc(sizeof(*obj), GFP_KERNEL);
> +
> + if (!obj)
> + return ERR_PTR(-ENOMEM);
> +
> + size = roundup(size, PAGE_SIZE);
> +
> + drm_gem_private_object_init(dev, &obj->gem, size);
Please, correct if I'm wrong, I'm trying to understand where this
function should be placed and when it is invoked. If I correctly
understood, you want to use this function for creating a separate gem
object to be used as a private area to be shared with another device,
am I right? If I am right, I'm wondering if we could reuse or update
some of the functions available in the vkms_gem. If I am wrong, I'm
wondering if we may have synchronization problems for handling
multiples mutex for accessing pages. Could you help me here?
> +
> + mu
[PATCH -next] drm/komeda: remove set but not used variable 'old'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/arm/display/komeda/komeda_plane.c:
In function komeda_plane_atomic_duplicate_state:
drivers/gpu/drm/arm/display/komeda/komeda_plane.c:161:35:
warning: variable old set but not used [-Wunused-but-set-variable
It is not used since commit 990dee3aa456 ("drm/komeda:
Computing image enhancer internally")
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index c095af1..c1381ac 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -158,8 +158,6 @@ static void komeda_plane_reset(struct drm_plane *plane)
static struct drm_plane_state *
komeda_plane_atomic_duplicate_state(struct drm_plane *plane)
{
- struct komeda_plane_state *new, *old;
-
if (WARN_ON(!plane->state))
return NULL;
@@ -169,8 +167,6 @@ komeda_plane_atomic_duplicate_state(struct drm_plane *plane)
__drm_atomic_helper_plane_duplicate_state(plane, &new->base);
- old = to_kplane_st(plane->state);
-
return &new->base;
}
--
2.7.4
Re: [PATCH 05/60] drm/bridge: simple-bridge: Add support for non-VGA bridges
On 07.07.2019 20:18, Laurent Pinchart wrote:
> Create a new simple_bridge_info structure that stores information about
> the bridge model, and store the bridge timings in there, along with the
> connector type. Use that new structure for of_device_id data. This
> enables support for non-VGA bridges.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 41 ++
> 1 file changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index da5479bd5878..bff240cf283d 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -16,10 +16,17 @@
> #include
> #include
>
> +struct simple_bridge_info {
> + const struct drm_bridge_timings *timings;
> + unsigned int type;
> +};
> +
> struct simple_bridge {
> struct drm_bridge bridge;
> struct drm_connectorconnector;
>
> + const struct simple_bridge_info *info;
> +
> struct i2c_adapter *ddc;
> struct regulator*vdd;
> };
> @@ -113,7 +120,7 @@ static int simple_bridge_attach(struct drm_bridge *bridge)
>&simple_bridge_con_helper_funcs);
> ret = drm_connector_init(bridge->dev, &sbridge->connector,
>&simple_bridge_con_funcs,
> - DRM_MODE_CONNECTOR_VGA);
> + sbridge->info->type);
> if (ret) {
> DRM_ERROR("Failed to initialize connector\n");
> return ret;
> @@ -182,6 +189,8 @@ static int simple_bridge_probe(struct platform_device
> *pdev)
> return -ENOMEM;
> platform_set_drvdata(pdev, sbridge);
>
> + sbridge->info = of_device_get_match_data(&pdev->dev);
> +
> sbridge->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
> if (IS_ERR(sbridge->vdd)) {
> int ret = PTR_ERR(sbridge->vdd);
> @@ -204,7 +213,7 @@ static int simple_bridge_probe(struct platform_device
> *pdev)
>
> sbridge->bridge.funcs = &simple_bridge_bridge_funcs;
> sbridge->bridge.of_node = pdev->dev.of_node;
> - sbridge->bridge.timings = of_device_get_match_data(&pdev->dev);
> + sbridge->bridge.timings = sbridge->info->timings;
>
> drm_bridge_add(&sbridge->bridge);
>
> @@ -264,19 +273,27 @@ static const struct drm_bridge_timings
> ti_ths8135_bridge_timings = {
> static const struct of_device_id simple_bridge_match[] = {
> {
> .compatible = "dumb-vga-dac",
> - .data = NULL,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
> .compatible = "adi,adv7123",
> - .data = &default_bridge_timings,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .timings = &default_bridge_timings,
> + .type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
> .compatible = "ti,ths8135",
> - .data = &ti_ths8135_bridge_timings,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .timings = &ti_ths8135_bridge_timings,
> + .type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
> .compatible = "ti,ths8134",
> - .data = &ti_ths8134_bridge_timings,
> + .data = &(const struct simple_bridge_info) {
> + .timings = &ti_ths8134_bridge_timings,
> + .type = DRM_MODE_CONNECTOR_VGA,
> + },
> },
> {},
> };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Tue, Jul 09, 2019 at 04:58:35PM +0800, Icenowy Zheng wrote: > > > 于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard 写到: > >On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > >> > > Maybe instead of edp-connector one would introduce integrator's > >specific > >> > > connector, for example with compatible > >"olimex,teres-edp-connector" > >> > > which should follow edp abstract connector rules? This will be at > >least > >> > > consistent with below presentation[1] - eDP requirements depends > >on > >> > > integrator. Then if olimex has standard way of dealing with > >panels > >> > > present in olimex/teres platforms the driver would then create > >> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I > >guess. > >> > > Anyway it still looks fishy for me :), maybe because I am not > >> > > familiarized with details of these platforms. > >> > > >> > That makes sense yes > >> > >> Actually, it makes no sense at all. Current implementation for > >anx6345 > >> driver works fine as is with any panel specified assuming panel > >delays > >> are long enough for connected panel. It just doesn't use panel > >timings > >> from the driver. Creating a platform driver for connector itself > >looks > >> redundant since it can't be reused, it doesn't describe actual > >> hardware and it's just defeats purpose of DT by introducing > >> board-specific code. > > > >I'm not sure where you got the idea that the purpose of DT is to not > >have any board-specific code. > > > >It's perfectly fine to have some, that's even why there's a compatible > >assigned to each and every board. > > > >What the DT is about is allowing us to have a generic behaviour that > >we can detect: we can have a given behaviour for a given board, and a > >separate one for another one, and this will be evaluated at runtime. > > > >This is *exactly* what this is about: we can have a compatible that > >sets a given, more specific, behaviour (olimex,teres-edp-connector) > >while saying that this is compatible with the generic behaviour > >(edp-connector). That way, any OS will know what quirk to apply if > >needed, and if not that it can use the generic behaviour. > > > >And we could create a generic driver, for the generic behaviour if > >needed. > > > >> There's another issue: if we introduce edp-connector we'll have to > >> specify power up delays somewhere (in dts? or in platform driver?), > >so > >> edp-connector doesn't really solve the issue of multiple panels with > >> same motherboard. > > > >And that's what that compatible is about :) > > Maybe we can introduce a connector w/o any driver just like hdmi-connector? Ironically, a driver for it has been sent yesterday :) But yeah, we can definitely do that too. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #40 from Wilko Bartels --- Since i experience the same issue since june (didnt game much) i want to share my system info. I am on Ryzen 2600X, Vega 56 Pulse, Strix B450. Using Arch 5.1. Tested every Windowmanager i know , tested also 60Hz and 144Hz. The crashes are totally random. I only play Dota 2. Last friday i played like 6 games in a row without a single issue. The day after i crashed like 7 times per game. Always have to press reset on my PC. Is it know that hits issue related to a kernel or mesa update? I mean it wasnt always like this no? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/6] drm: Add Content protection type property
On Mon, 8 Jul 2019 16:51:11 +0530
Ramalingam C wrote:
> This patch adds a DRM ENUM property to the selected connectors.
> This property is used for mentioning the protected content's type
> from userspace to kernel HDCP authentication.
>
> Type of the stream is decided by the protected content providers.
> Type 0 content can be rendered on any HDCP protected display wires.
> But Type 1 content can be rendered only on HDCP2.2 protected paths.
>
> So when a userspace sets this property to Type 1 and starts the HDCP
> enable, kernel will honour it only if HDCP2.2 authentication is through
> for type 1. Else HDCP enable will be failed.
>
> Need ACK for this new conenctor property from userspace consumer.
>
> v2:
> cp_content_type is replaced with content_protection_type [daniel]
> check at atomic_set_property is removed [Maarten]
> v3:
> %s/content_protection_type/hdcp_content_type [Pekka]
> v4:
> property is created for the first requested connector and then reused.
> [Danvet]
> v5:
> kernel doc nits addressed [Daniel]
> Rebased as part of patch reordering.
> v6:
> Kernel docs are modified [pekka]
> v7:
> More details in Kernel docs. [pekka]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> drivers/gpu/drm/drm_connector.c | 39 +++
> drivers/gpu/drm/drm_hdcp.c| 36 -
> drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++-
> include/drm/drm_connector.h | 7
> include/drm/drm_hdcp.h| 2 +-
> include/drm/drm_mode_config.h | 6
> include/uapi/drm/drm_mode.h | 4 +++
> 8 files changed, 99 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index abe38bdf85ae..19ae119f1a5d 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -747,6 +747,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> return -EINVAL;
> }
> state->content_protection = val;
> + } else if (property == config->hdcp_content_type_property) {
> + state->hdcp_content_type = val;
> } else if (property == connector->colorspace_property) {
> state->colorspace = val;
> } else if (property == config->writeback_fb_id_property) {
> @@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> state->hdr_output_metadata->base.id : 0;
> } else if (property == config->content_protection_property) {
> *val = state->content_protection;
> + } else if (property == config->hdcp_content_type_property) {
> + *val = state->hdcp_content_type;
> } else if (property == config->writeback_fb_id_property) {
> /* Writeback framebuffer is one-shot, write and forget */
> *val = 0;
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 068d4b05f1be..732f6645643d 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -952,6 +952,45 @@ static const struct drm_prop_enum_list
> hdmi_colorspaces[] = {
> * is no longer protected and userspace should take appropriate action
> * (whatever that might be).
> *
> + * HDCP Content Type:
> + * This Enum property is used by the userspace to declare the content type
> + * of the display stream, to kernel. Here display stream stands for any
> + * display content that userspace intended to render with HDCP encryption.
Hi,
I'd suggest s/render with/display through/.
As a gfx dev, rendering is something quite different to me.
> + *
> + * Content Type of a stream is decided by the owner of the stream, as
> + * "HDCP Type0" or "HDCP Type1".
> + *
> + * The value of the property can be one the below:
*one of the below
> + * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
> + * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1
> + *
> + * When kernel starts the HDCP authentication upon the "DESIRED" state of
> + * the "Content Protection", it refers the "HDCP Content Type" property
> + * state. And perform the HDCP authentication with the display sink for
> + * the content type mentioned by "HDCP Content Type".
How about:
When kernel starts the HDCP authentication (see "Content Protection"
for details), it uses the content type in "HDCP Content Type"
for performing the HDCP authentication with the display sink.
> + *
> + * Stream classified as HDCP Type0 can be transmitted on a link which is
> + * encrypted with HDCP 1.4 or higher versions of HDCP(i.e HDCP2.2
> + * and more).
This is where I get confused, see my earlier email from today on the
previous revision of this patch series. Is it necessary to talk a
Re: [PATCH 06/60] drm/bridge: simple-bridge: Add support for enable GPIO
On 07.07.2019 20:18, Laurent Pinchart wrote:
> If an enable GPIO is declared in the firmware, assert it when enabling
> the bridge and deassert it when disabling it.
>
> Signed-off-by: Laurent Pinchart
Hmm, simple becomes less simple. I guess we will end-up with sth similar
to panel-simple. And then we can merge both :)
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index bff240cf283d..a7edf3c39627 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -6,6 +6,7 @@
> * Maxime Ripard
> */
>
> +#include
> #include
> #include
> #include
> @@ -29,6 +30,7 @@ struct simple_bridge {
>
> struct i2c_adapter *ddc;
> struct regulator*vdd;
> + struct gpio_desc*enable;
> };
>
> static inline struct simple_bridge *
> @@ -135,19 +137,23 @@ static int simple_bridge_attach(struct drm_bridge
> *bridge)
> static void simple_bridge_enable(struct drm_bridge *bridge)
> {
> struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
> - int ret = 0;
> + int ret;
>
> - if (sbridge->vdd)
> + if (sbridge->vdd) {
> ret = regulator_enable(sbridge->vdd);
> + if (ret)
> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + }
>
> - if (ret)
> - DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + gpiod_set_value_cansleep(sbridge->enable, 1);
> }
>
> static void simple_bridge_disable(struct drm_bridge *bridge)
> {
> struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
>
> + gpiod_set_value_cansleep(sbridge->enable, 0);
> +
> if (sbridge->vdd)
> regulator_disable(sbridge->vdd);
> }
> @@ -200,6 +206,14 @@ static int simple_bridge_probe(struct platform_device
> *pdev)
> dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
> }
>
> + sbridge->enable = devm_gpiod_get_optional(&pdev->dev, "enable",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(sbridge->enable)) {
> + if (PTR_ERR(sbridge->enable) != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Unable to retrieve enable GPIO\n");
> + return PTR_ERR(sbridge->enable);
> + }
> +
> sbridge->ddc = simple_bridge_retrieve_ddc(&pdev->dev);
> if (IS_ERR(sbridge->ddc)) {
> if (PTR_ERR(sbridge->ddc) == -ENODEV) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/60] drm/bridge: simple-bridge: Add support for the TI OP362
On 07.07.2019 20:18, Laurent Pinchart wrote:
> The TI OP362 is an analog video amplifier controlled through a GPIO. Add
> support for it to the simple-bridge driver.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index a7edf3c39627..7495b9bef865 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -296,6 +296,11 @@ static const struct of_device_id simple_bridge_match[] =
> {
> .timings = &default_bridge_timings,
> .type = DRM_MODE_CONNECTOR_VGA,
> },
> + }, {
> + .compatible = "ti,opa362",
> + .data = &(const struct simple_bridge_info) {
> + .type = DRM_MODE_CONNECTOR_Composite,
> + },
> }, {
> .compatible = "ti,ths8135",
> .data = &(const struct simple_bridge_info) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 4/6] drm/hdcp: update content protection property with uevent
On Mon, 8 Jul 2019 16:51:14 +0530
Ramalingam C wrote:
> drm function is defined and exported to update a connector's
> content protection property state and to generate a uevent along
> with it.
>
> Need ACK for the uevent from userspace consumer.
>
> v2:
> Update only when state is different from old one.
> v3:
> KDoc is added [Daniel]
> v4:
> KDoc is extended bit more [pekka]
> v5:
> Uevent usage is documented at kdoc of "Content Protection" also
> [pekka]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_connector.c | 17 +
> drivers/gpu/drm/drm_hdcp.c | 34 +
> include/drm/drm_hdcp.h | 2 ++
> 3 files changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 732f6645643d..6de906ef10b3 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -947,10 +947,19 @@ static const struct drm_prop_enum_list
> hdmi_colorspaces[] = {
> * - If the state is DESIRED, kernel should attempt to re-authenticate the
> * link whenever possible. This includes across disable/enable, dpms,
> * hotplug, downstream device changes, link status failures, etc..
> - * - Userspace is responsible for polling the property to determine when
> - * the value transitions from ENABLED to DESIRED. This signifies the link
> - * is no longer protected and userspace should take appropriate action
> - * (whatever that might be).
> + * - Kernel sends uevent with the connector id and property id through
> + * @drm_hdcp_update_content_protection, upon below kernel triggered
> + * scenarios:
> + * DESIRED -> ENABLED (authentication success)
> + * ENABLED -> DESIRED (termination of authentication)
> + * - Please note no uevents for userspace triggered property state changes,
> + * which can't fail such as
> + * DESIRED/ENABLED -> UNDESIRED
> + * UNDESIRED -> DESIRED
> + * - Userspace is responsible for polling the property or listen to uevents
> + * to determine when the value transitions from ENABLED to DESIRED.
> + * This signifies the link is no longer protected and userspace should
> + * take appropriate action (whatever that might be).
Yes!
This doc is exactly what I hoped to see. Good job.
This is also exactly how
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 deals
with this in userspace. That MR still has some open issues, but I think
nothing related to the uevent.
Thanks,
pq
> *
> * HDCP Content Type:
> * This Enum property is used by the userspace to declare the content type
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> index ce235fd1c844..77433ee3d652 100644
> --- a/drivers/gpu/drm/drm_hdcp.c
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -374,6 +374,10 @@ DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
> *
> * The content protection will be set to
> &drm_connector_state.content_protection
> *
> + * When kernel triggered content protection state change like
> DESIRED->ENABLED
> + * and ENABLED->DESIRED, will use drm_hdcp_update_content_protection() to
> update
> + * the content protection state of a connector.
> + *
> * Returns:
> * Zero on success, negative errno on failure.
> */
> @@ -414,3 +418,33 @@ int drm_connector_attach_content_protection_property(
> return 0;
> }
> EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
> +
> +/**
> + * drm_hdcp_update_content_protection - Updates the content protection state
> + * of a connector
> + *
> + * @connector: drm_connector on which content protection state needs an
> update
> + * @val: New state of the content protection property
> + *
> + * This function can be used by display drivers, to update the kernel
> triggered
> + * content protection state changes of a drm_connector such as
> DESIRED->ENABLED
> + * and ENABLED->DESIRED. No uevent for DESIRED->UNDESIRED or
> ENABLED->UNDESIRED,
> + * as userspace is triggering such state change and kernel performs it
> without
> + * fail.This function update the new state of the property into the
> connector's
> + * state and generate an uevent to notify the userspace.
> + */
> +void drm_hdcp_update_content_protection(struct drm_connector *connector,
> + u64 val)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_connector_state *state = connector->state;
> +
> + WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
> + if (state->content_protection == val)
> + return;
> +
> + state->content_protection = val;
> + drm_sysfs_connector_status_event(connector,
> + dev->mode_config.content_protection_property);
> +}
> +EXPORT_SYMBOL(drm_hdcp_update_content_protection);
> diff --git a/include/drm/
Re: [PATCH v2 1/9] dt-bindings: display: Add TCON LCD compatible for R40
On Fri, 14 Jun 2019 22:13:16 +0530, Jagan Teki wrote: > Like TCON TV0, TV1 allwinner R40 has TCON LCD0, LCD1 which > are managed via TCON TOP. > > Add tcon lcd compatible R40, the same compatible can handle > TCON LCD0, LCD1. > > Signed-off-by: Jagan Teki > Acked-by: Chen-Yu Tsai > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/9] dt-bindings: sun6i-dsi: Add R40 MIPI-DSI compatible (w/ A64 fallback)
On Fri, 14 Jun 2019 22:13:21 +0530, Jagan Teki wrote: > The MIPI DSI controller on Allwinner R40 is similar on > the one on A64 like doesn't associate any DSI_SCLK gating. > > So, add R40 compatible and append A64 compatible as fallback. > > Signed-off-by: Jagan Teki > --- > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring
[PATCH v1] drm/modes: Skip invalid cmdline mode
The named mode could be invalid and then cmdline parser misses to validate
mode's dimensions, happily adding 0x0 mode as a valid mode. One case where
this happens is NVIDIA Tegra devices that are using downstream bootloader
which adds "video=tegrafb" to the kernel's cmdline and thus upstream Tegra
DRM driver fails to probe because of the invalid mode.
Fixes: 3aeeb13d8996 ("drm/modes: Support modes names on the command line")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_client_modeset.c | 3 ++-
drivers/gpu/drm/drm_modes.c | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index e95fceac8f8b..56d36779d213 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -180,7 +180,8 @@ drm_connector_pick_cmdline_mode(struct drm_connector
*connector)
create_mode:
mode = drm_mode_create_from_cmdline_mode(connector->dev, cmdline_mode);
- list_add(&mode->head, &connector->modes);
+ if (mode)
+ list_add(&mode->head, &connector->modes);
return mode;
}
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 910561d4f071..74a5739df506 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -158,6 +158,9 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device
*dev, int hdisplay,
int interlace;
u64 tmp;
+ if (!hdisplay || !vdisplay)
+ return NULL;
+
/* allocate the drm_display_mode structure. If failure, we will
* return directly
*/
@@ -392,6 +395,9 @@ drm_gtf_mode_complex(struct drm_device *dev, int hdisplay,
int vdisplay,
int hsync, hfront_porch, vodd_front_porch_lines;
unsigned int tmp1, tmp2;
+ if (!hdisplay || !vdisplay)
+ return NULL;
+
drm_mode = drm_mode_create(dev);
if (!drm_mode)
return NULL;
--
2.22.0
Re: [PATCH v7 16/18] MAINTAINERS: add entry for KUnit the unit testing framework
On 7/9/19 12:30 AM, Brendan Higgins wrote: Add myself as maintainer of KUnit, the Linux kernel's unit testing framework. Signed-off-by: Brendan Higgins Reviewed-by: Greg Kroah-Hartman Reviewed-by: Logan Gunthorpe --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 677ef41cb012c..48d04d180a988 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8599,6 +8599,17 @@ S: Maintained F:tools/testing/selftests/ F:Documentation/dev-tools/kselftest* +KERNEL UNIT TESTING FRAMEWORK (KUnit) +M: Brendan Higgins +L: linux-kselft...@vger.kernel.org +L: kunit-...@googlegroups.com +W: https://google.github.io/kunit-docs/third_party/kernel/docs/ +S: Maintained +F: Documentation/dev-tools/kunit/ +F: include/kunit/ +F: kunit/ +F: tools/testing/kunit/ + KERNEL USERMODE HELPER M:Luis Chamberlain L:linux-ker...@vger.kernel.org Thanks Brendan. I am good with this. I can take KUnit patches through kselftest with your Ack. thanks, -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 12/33] drm/vkms: drop use of drmP.h
On Sun, Jun 30, 2019 at 3:19 AM Sam Ravnborg wrote:
>
> Drop use of the deprecated drmP.h header.
> Replace it with the necessary includes in the individual .c files.
> The header files was self-contained, and extra includes were not added
> there.
>
> Signed-off-by: Sam Ravnborg
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Cc: David Airlie
Hi Sam,
Thanks for you patch, it LGTM.
Reviewed-by: Rodrigo Siqueira
> ---
> The list of cc: was too large to add all recipients to the cover letter.
> Please find cover letter here:
> https://lists.freedesktop.org/archives/dri-devel/2019-June/thread.html
> Search for "drm: drop use of drmp.h in drm-misc"
>
> Sam
>
> drivers/gpu/drm/vkms/vkms_crc.c | 5 -
> drivers/gpu/drm/vkms/vkms_crtc.c | 4 +++-
> drivers/gpu/drm/vkms/vkms_drv.c | 11 +--
> drivers/gpu/drm/vkms/vkms_drv.h | 4 ++--
> drivers/gpu/drm/vkms/vkms_gem.c | 1 +
> drivers/gpu/drm/vkms/vkms_plane.c | 6 --
> 6 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index 30b048b67a32..2037e5669fcf 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -1,10 +1,13 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> -#include "vkms_drv.h"
> #include
> +
> #include
> #include
> #include
> +#include
> +
> +#include "vkms_drv.h"
>
> /**
> * compute_crc - Compute CRC value on output frame
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 7e2a081f3764..8e9cc35c16d3 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -1,9 +1,11 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> -#include "vkms_drv.h"
> #include
> #include
> #include
> +#include
> +
> +#include "vkms_drv.h"
>
> static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
> {
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index cc53ef88a331..0a236160b235 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -10,12 +10,19 @@
> */
>
> #include
> -#include
> +#include
> +
> #include
> #include
> -#include
> +#include
> #include
> +#include
> +#include
> +#include
> +#include
> #include
> +#include
> +
> #include "vkms_drv.h"
>
> #define DRIVER_NAME"vkms"
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 12b4db7ac641..0a4ba8b57e11 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -3,11 +3,11 @@
> #ifndef _VKMS_DRV_H_
> #define _VKMS_DRV_H_
>
> -#include
> +#include
> +
> #include
> #include
> #include
> -#include
>
> #define XRES_MIN20
> #define YRES_MIN20
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index 69048e73377d..6489bfe0a149 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> #include
> +#include
>
> #include "vkms_drv.h"
>
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 0fceb6258422..3a610b4060c1 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -1,10 +1,12 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> -#include "vkms_drv.h"
> -#include
> #include
> #include
> +#include
> #include
> +#include
> +
> +#include "vkms_drv.h"
>
> static const u32 vkms_formats[] = {
> DRM_FORMAT_XRGB,
> --
> 2.20.1
>
--
Rodrigo Siqueira
https://siqueira.tech
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] gpu/drm_memory: fix a few warnings
The opening comment mark "/**" is reserved for kernel-doc comments, so it will generate a warning with "make W=1". drivers/gpu/drm/drm_memory.c:2: warning: Cannot understand * \file drm_memory.c Also, silence a checkpatch warning by adding a license identfiter where it indicates the MIT license further down in the source file. WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 Fix it by adding the MIT SPDX identifier without touching the boilerplate language. Suggested-by: Thomas Gleixner Signed-off-by: Qian Cai --- v3: Keep the boilerplate language. v2: Remove the redundant description of the license. drivers/gpu/drm/drm_memory.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c index 132fef8ff1b6..683042c8ee2c 100644 --- a/drivers/gpu/drm/drm_memory.c +++ b/drivers/gpu/drm/drm_memory.c @@ -1,4 +1,5 @@ -/** +// SPDX-License-Identifier: MIT +/* * \file drm_memory.c * Memory management wrappers for DRM * -- 1.8.3.1
[PATCH] drm/atmel-hlcdc: set layer REP bit to enable replication logic
This bit enables replication logic to expand an RGB color less than 24
bits, to 24 bits, which is used internally for all formats. Otherwise,
the least significant bits are always set to zero and the color may not
be what is expected.
Signed-off-by: Joshua Henderson
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index eb7c4cf..6f6cf61 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -389,7 +389,7 @@ atmel_hlcdc_plane_update_general_settings(struct
atmel_hlcdc_plane *plane,
atmel_hlcdc_layer_write_cfg(&plane->layer, ATMEL_HLCDC_LAYER_DMA_CFG,
cfg);
- cfg = ATMEL_HLCDC_LAYER_DMA;
+ cfg = ATMEL_HLCDC_LAYER_DMA | ATMEL_HLCDC_LAYER_REP;
if (plane->base.type != DRM_PLANE_TYPE_PRIMARY) {
cfg |= ATMEL_HLCDC_LAYER_OVR | ATMEL_HLCDC_LAYER_ITER2BL |
--
2.7.4
Re: [PATCH v2 7/9] dt-bindings: sun6i-dsi: Add R40 DPHY compatible (w/ A31 fallback)
On Fri, 14 Jun 2019 22:13:22 +0530, Jagan Teki wrote: > The MIPI DSI PHY controller on Allwinner R40 is similar > on the one on A31. > > Add R40 compatible and append A31 compatible as fallback. > > Signed-off-by: Jagan Teki > --- > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 17/28] drivers: Introduce bus_find_device_by_of_node() helper
On Fri, 14 Jun 2019 18:54:12 +0100, Suzuki K Poulose wrote: > Add a wrapper to bus_find_device() to search for a device > by the of_node pointer, reusing the generic match function. > Also convert the existing users to make use of the new helper. > > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: dri-devel@lists.freedesktop.org > Cc: David Airlie > Cc: Daniel Vetter > Cc: devicet...@vger.kernel.org > Cc: Florian Fainelli > Cc: Frank Rowand > Cc: Heiko Stuebner > Cc: Liam Girdwood > Cc: linux-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-...@vger.kernel.org > Cc: Mathieu Poirier > Cc: Rob Herring > Cc: Srinivas Kandagatla > Cc: Takashi Iwai > Cc: Wolfram Sang > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Signed-off-by: Suzuki K Poulose > --- > drivers/gpu/drm/drm_mipi_dsi.c | 7 +-- > drivers/hwtracing/coresight/of_coresight.c | 11 ++- > drivers/i2c/i2c-core-of.c | 7 +-- > drivers/nvmem/core.c | 7 +-- > drivers/of/of_mdio.c | 8 +--- > drivers/of/platform.c | 7 +-- > drivers/spi/spi.c | 9 ++--- > include/linux/device.h | 12 > sound/soc/rockchip/rk3399_gru_sound.c | 9 ++--- > 9 files changed, 23 insertions(+), 54 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH] drm/atmel-hlcdc: set layer REP bit to enable replication logic
On 09/07/2019 at 17:35, Joshua Henderson wrote:
> This bit enables replication logic to expand an RGB color less than 24
> bits, to 24 bits, which is used internally for all formats. Otherwise,
> the least significant bits are always set to zero and the color may not
> be what is expected.
>
> Signed-off-by: Joshua Henderson
Acked-by: Nicolas Ferre
Here is patchwork entry:
https://patchwork.kernel.org/patch/11037167/
Thanks, best regards,
Nicolas
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index eb7c4cf..6f6cf61 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -389,7 +389,7 @@ atmel_hlcdc_plane_update_general_settings(struct
> atmel_hlcdc_plane *plane,
> atmel_hlcdc_layer_write_cfg(&plane->layer, ATMEL_HLCDC_LAYER_DMA_CFG,
> cfg);
>
> - cfg = ATMEL_HLCDC_LAYER_DMA;
> + cfg = ATMEL_HLCDC_LAYER_DMA | ATMEL_HLCDC_LAYER_REP;
>
> if (plane->base.type != DRM_PLANE_TYPE_PRIMARY) {
> cfg |= ATMEL_HLCDC_LAYER_OVR | ATMEL_HLCDC_LAYER_ITER2BL |
>
--
Nicolas Ferre
Re: [PATCH v1] drm/tegra: Fix gpiod_get_from_of_node() regression
On 05/07/2019 16:11, Dmitry Osipenko wrote:
> That function now returns ERR_PTR instead of NULL if "hpd-gpio" is not
> present in device-tree. The offending patch missed to adapt the Tegra's
> DRM driver for the API change.
>
> Fixes: 025bf37725f1 ("gpio: Fix return value mismatch of function
> gpiod_get_from_of_node()")
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/output.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> index 274cb955e2e1..471d33809cd4 100644
> --- a/drivers/gpu/drm/tegra/output.c
> +++ b/drivers/gpu/drm/tegra/output.c
> @@ -126,8 +126,12 @@ int tegra_output_probe(struct tegra_output *output)
> "nvidia,hpd-gpio", 0,
> GPIOD_IN,
> "HDMI hotplug detect");
> - if (IS_ERR(output->hpd_gpio))
> - return PTR_ERR(output->hpd_gpio);
> + if (IS_ERR(output->hpd_gpio)) {
> + if (PTR_ERR(output->hpd_gpio) == -ENOENT)
> + output->hpd_gpio = NULL;
> + else
> + return PTR_ERR(output->hpd_gpio);
> + }
>
> if (output->hpd_gpio) {
> err = gpiod_to_irq(output->hpd_gpio);
>
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
Re: [PATCH] drm/amd/display: avoid 64-bit division
Hi Arnd!
Thanks for bisecting this issue.
I wonder whether you are going to commit your patch or planning to update it
and it's still in your work queue. We have one of our 32-bit builds failing
because of this issue, so that I would like either to fix it or wait to your
fix if it has chances to go upstream today.
Sincerely,
Slava Abramov
From: amd-gfx on behalf of Arnd
Bergmann
Sent: Monday, July 8, 2019 9:52:08 AM
To: Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander; Koenig, Christian;
Zhou, David(ChunMing); David Airlie; Daniel Vetter
Cc: Liu, Charlene; Park, Chris; Arnd Bergmann; Cheng, Tony; Francis, David;
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Cornij, Nikola;
Laktyushkin, Dmytro; dri-devel@lists.freedesktop.org; Lei, Jun; Lakha,
Bhawanpreet; Koo, Anthony
Subject: [PATCH] drm/amd/display: avoid 64-bit division
On 32-bit architectures, dividing a 64-bit integer in the kernel
leads to a link error:
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Change the two recently introduced instances to a multiply+shift
operation that is also much cheaper on 32-bit architectures.
We can do that here, since both of them are really 32-bit numbers
that change a few percent.
Fixes: bedbbe6af4be ("drm/amd/display: Move link functions from dc to dc_link")
Fixes: f18bc4e53ad6 ("drm/amd/display: update calculated bounding box logic for
NV")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index c17db5c144aa..8dbf759eba45 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3072,8 +3072,8 @@ uint32_t dc_link_bandwidth_kbps(
* but the difference is minimal and is in a safe direction,
* which all works well around potential ambiguity of DP 1.4a
spec.
*/
- long long fec_link_bw_kbps = link_bw_kbps * 970LL;
- link_bw_kbps = (uint32_t)(fec_link_bw_kbps / 1000LL);
+ link_bw_kbps = mul_u64_u32_shr(BIT_ULL(32) * 970LL / 1000,
+ link_bw_kbps, 32);
}
#endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index b35327bafbc5..70ac8a95d2db 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -2657,7 +2657,7 @@ static void update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_
calculated_states[i].dram_speed_mts = uclk_states[i] * 16 /
1000;
// FCLK:UCLK ratio is 1.08
- min_fclk_required_by_uclk = ((unsigned long
long)uclk_states[i]) * 1080 / 100;
+ min_fclk_required_by_uclk = mul_u64_u32_shr(BIT_ULL(32) * 1080
/ 100, uclk_states[i], 32);
calculated_states[i].fabricclk_mhz =
(min_fclk_required_by_uclk < min_dcfclk) ?
min_dcfclk : min_fclk_required_by_uclk;
--
2.20.0
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: avoid 64-bit division
I'll just apply Arnd's patch. If the display team wants to adjust it later to
clarify the operation, they should go ahead as a follow up patch.
Thanks,
Alex
From: Abramov, Slava
Sent: Tuesday, July 9, 2019 12:31 PM
To: Arnd Bergmann; Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander;
Koenig, Christian; Zhou, David(ChunMing); David Airlie; Daniel Vetter
Cc: Liu, Charlene; Park, Chris; Cheng, Tony; Francis, David;
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Cornij, Nikola;
Laktyushkin, Dmytro; dri-devel@lists.freedesktop.org; Lei, Jun; Lakha,
Bhawanpreet; Koo, Anthony
Subject: Re: [PATCH] drm/amd/display: avoid 64-bit division
Hi Arnd!
Thanks for bisecting this issue.
I wonder whether you are going to commit your patch or planning to update it
and it's still in your work queue. We have one of our 32-bit builds failing
because of this issue, so that I would like either to fix it or wait to your
fix if it has chances to go upstream today.
Sincerely,
Slava Abramov
From: amd-gfx on behalf of Arnd
Bergmann
Sent: Monday, July 8, 2019 9:52:08 AM
To: Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander; Koenig, Christian;
Zhou, David(ChunMing); David Airlie; Daniel Vetter
Cc: Liu, Charlene; Park, Chris; Arnd Bergmann; Cheng, Tony; Francis, David;
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Cornij, Nikola;
Laktyushkin, Dmytro; dri-devel@lists.freedesktop.org; Lei, Jun; Lakha,
Bhawanpreet; Koo, Anthony
Subject: [PATCH] drm/amd/display: avoid 64-bit division
On 32-bit architectures, dividing a 64-bit integer in the kernel
leads to a link error:
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Change the two recently introduced instances to a multiply+shift
operation that is also much cheaper on 32-bit architectures.
We can do that here, since both of them are really 32-bit numbers
that change a few percent.
Fixes: bedbbe6af4be ("drm/amd/display: Move link functions from dc to dc_link")
Fixes: f18bc4e53ad6 ("drm/amd/display: update calculated bounding box logic for
NV")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index c17db5c144aa..8dbf759eba45 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3072,8 +3072,8 @@ uint32_t dc_link_bandwidth_kbps(
* but the difference is minimal and is in a safe direction,
* which all works well around potential ambiguity of DP 1.4a
spec.
*/
- long long fec_link_bw_kbps = link_bw_kbps * 970LL;
- link_bw_kbps = (uint32_t)(fec_link_bw_kbps / 1000LL);
+ link_bw_kbps = mul_u64_u32_shr(BIT_ULL(32) * 970LL / 1000,
+ link_bw_kbps, 32);
}
#endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index b35327bafbc5..70ac8a95d2db 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -2657,7 +2657,7 @@ static void update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_
calculated_states[i].dram_speed_mts = uclk_states[i] * 16 /
1000;
// FCLK:UCLK ratio is 1.08
- min_fclk_required_by_uclk = ((unsigned long
long)uclk_states[i]) * 1080 / 100;
+ min_fclk_required_by_uclk = mul_u64_u32_shr(BIT_ULL(32) * 1080
/ 100, uclk_states[i], 32);
calculated_states[i].fabricclk_mhz =
(min_fclk_required_by_uclk < min_dcfclk) ?
min_dcfclk : min_fclk_required_by_uclk;
--
2.20.0
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] dt-bindings: display: ssd1307fb: Add initialization properties
On Tue, 18 Jun 2019 10:41:10 +0300, Marko Kohtala wrote: > Document new bindings for adapting ssd1307fb driver to new displays. > > Signed-off-by: Marko Kohtala > --- > .../devicetree/bindings/display/ssd1307fb.txt | 10 ++ > 1 file changed, 10 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 01/22] docs: Documentation/*.txt: rename all ReST files to *.rst
On Tue, Jun 18, 2019 at 06:05:25PM -0300, Mauro Carvalho Chehab wrote:
> Those files are actually at ReST format. Ok, currently, they
> don't belong to any place yet at the organized book series,
> but we don't want patches to break them as ReST files. So,
> rename them and add a :orphan: in order to shut up warning
> messages like those:
>
> ...
> Documentation/svga.rst: WARNING: document isn't included in any toctree
> Documentation/switchtec.rst: WARNING: document isn't included in any
> toctree
> ...
>
> Later patches will move them to a better place and remove the
> :orphan: markup.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> I had to remove the long list of maintainers got by
> getpatch.pl, as it was too long. I opted to keep only the
> mailing lists.
>
> Documentation/ABI/removed/sysfs-class-rfkill | 2 +-
> Documentation/ABI/stable/sysfs-class-rfkill | 2 +-
> Documentation/ABI/stable/sysfs-devices-node | 2 +-
> Documentation/ABI/testing/procfs-diskstats| 2 +-
> Documentation/ABI/testing/sysfs-block | 2 +-
> .../ABI/testing/sysfs-class-switchtec | 2 +-
> .../ABI/testing/sysfs-devices-system-cpu | 4 +-
> .../{DMA-API-HOWTO.txt => DMA-API-HOWTO.rst} | 2 +
> Documentation/{DMA-API.txt => DMA-API.rst}| 8 ++-
> .../{DMA-ISA-LPC.txt => DMA-ISA-LPC.rst} | 4 +-
> ...{DMA-attributes.txt => DMA-attributes.rst} | 2 +
> Documentation/{IPMI.txt => IPMI.rst} | 2 +
> .../{IRQ-affinity.txt => IRQ-affinity.rst}| 2 +
> .../{IRQ-domain.txt => IRQ-domain.rst}| 2 +
> Documentation/{IRQ.txt => IRQ.rst}| 2 +
> .../{Intel-IOMMU.txt => Intel-IOMMU.rst} | 2 +
> Documentation/PCI/pci.rst | 8 +--
> Documentation/{SAK.txt => SAK.rst}| 3 +-
> Documentation/{SM501.txt => SM501.rst}| 2 +
> Documentation/admin-guide/hw-vuln/l1tf.rst| 2 +-
> .../admin-guide/kernel-parameters.txt | 4 +-
> .../{atomic_bitops.txt => atomic_bitops.rst} | 3 +-
> Documentation/block/biodoc.txt| 2 +-
> .../{bt8xxgpio.txt => bt8xxgpio.rst} | 3 +-
> Documentation/{btmrvl.txt => btmrvl.rst} | 2 +
> ...-mapping.txt => bus-virt-phys-mapping.rst} | 54 +-
> ...g-warn-once.txt => clearing-warn-once.rst} | 2 +
> Documentation/{cpu-load.txt => cpu-load.rst} | 2 +
> .../{cputopology.txt => cputopology.rst} | 2 +
> Documentation/{crc32.txt => crc32.rst}| 2 +
> Documentation/{dcdbas.txt => dcdbas.rst} | 2 +
> ...ging-modules.txt => debugging-modules.rst} | 2 +
> ...hci1394.txt => debugging-via-ohci1394.rst} | 2 +
> Documentation/{dell_rbu.txt => dell_rbu.rst} | 3 +-
> Documentation/device-mapper/statistics.rst| 4 +-
> .../devicetree/bindings/phy/phy-bindings.txt | 2 +-
Acked-by: Rob Herring
> Documentation/{digsig.txt => digsig.rst} | 2 +
> Documentation/driver-api/usb/dma.rst | 6 +-
> Documentation/driver-model/device.rst | 2 +-
> Documentation/{efi-stub.txt => efi-stub.rst} | 2 +
> Documentation/{eisa.txt => eisa.rst} | 2 +
> Documentation/fb/vesafb.rst | 2 +-
> Documentation/filesystems/sysfs.txt | 2 +-
> ...ex-requeue-pi.txt => futex-requeue-pi.rst} | 2 +
> .../{gcc-plugins.txt => gcc-plugins.rst} | 2 +
> Documentation/gpu/drm-mm.rst | 2 +-
> Documentation/{highuid.txt => highuid.rst}| 4 +-
> .../{hw_random.txt => hw_random.rst} | 2 +
> .../{hwspinlock.txt => hwspinlock.rst}| 2 +
> Documentation/ia64/irq-redir.rst | 2 +-
> .../{intel_txt.txt => intel_txt.rst} | 2 +
> .../{io-mapping.txt => io-mapping.rst}| 2 +
> .../{io_ordering.txt => io_ordering.rst} | 2 +
> Documentation/{iostats.txt => iostats.rst}| 2 +
> ...flags-tracing.txt => irqflags-tracing.rst} | 3 +-
> Documentation/{isa.txt => isa.rst}| 2 +
> Documentation/{isapnp.txt => isapnp.rst} | 2 +
> ...hreads.txt => kernel-per-CPU-kthreads.rst} | 4 +-
> Documentation/{kobject.txt => kobject.rst}| 6 +-
> Documentation/{kprobes.txt => kprobes.rst}| 3 +-
> Documentation/{kref.txt => kref.rst} | 2 +
> Documentation/laptops/thinkpad-acpi.rst | 6 +-
> Documentation/{ldm.txt => ldm.rst}| 5 +-
> Documentation/locking/rt-mutex.rst| 2 +-
> ...kup-watchdogs.txt => lockup-watchdogs.rst} | 2 +
> Documentation/{lsm.txt => lsm.rst}| 2 +
> Documentation/{lzo.txt => lzo.rst}| 2 +
> Documentation/{mailbox.txt => mailbox.rst}| 2 +
> Documentation/memory-barriers.txt | 6 +-
> ...hameleon-bus.txt => men-chameleon-bus.rst} | 2 +
> Documentation/networking/scaling.rst | 4 +-
> .../{nommu-mmap.txt => nommu-mmap.rst}| 2 +
> Documentation/{ntb.txt => ntb.rst}| 2 +
> Documentation/{numastat.txt => numast
Re: [PATCH v7 16/18] MAINTAINERS: add entry for KUnit the unit testing framework
On Tue, Jul 9, 2019 at 7:53 AM shuah wrote: > > On 7/9/19 12:30 AM, Brendan Higgins wrote: > > Add myself as maintainer of KUnit, the Linux kernel's unit testing > > framework. > > > > Signed-off-by: Brendan Higgins > > Reviewed-by: Greg Kroah-Hartman > > Reviewed-by: Logan Gunthorpe > > --- > > MAINTAINERS | 11 +++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 677ef41cb012c..48d04d180a988 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -8599,6 +8599,17 @@ S: Maintained > > F: tools/testing/selftests/ > > F: Documentation/dev-tools/kselftest* > > > > +KERNEL UNIT TESTING FRAMEWORK (KUnit) > > +M: Brendan Higgins > > +L: linux-kselft...@vger.kernel.org > > +L: kunit-...@googlegroups.com > > +W: https://google.github.io/kunit-docs/third_party/kernel/docs/ > > +S: Maintained > > +F: Documentation/dev-tools/kunit/ > > +F: include/kunit/ > > +F: kunit/ > > +F: tools/testing/kunit/ > > + > > KERNEL USERMODE HELPER > > M: Luis Chamberlain > > L: linux-ker...@vger.kernel.org > > > > Thanks Brendan. > > I am good with this. I can take KUnit patches through kselftest > with your Ack. My acknowledgement? Sure! I thought we already agreed to that. Also, do we need an ack from Masahiro or Michal for the Kbuild patch [PATCH v7 06/18]? And an ack from Josh or Peter for the objtool patch [PATCH v7 08/18]? Greg and Logan gave me a Reviewed-by for the Kbuild patch, so maybe that's fine, but I don't have any reviews or acks for the objtool patch. Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] fbdev changes for v5.3
The pull request you sent on Tue, 9 Jul 2019 15:10:33 +0200: > https://github.com/bzolnier/linux.git tags/fbdev-v5.3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2d41ef5432b76ae90dc0db93026f1d981f874ec4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #41 from Sylvain BERTRAND --- Guys, I am getting freezes on tahiti xt/fx9590 recently... But I am not logging a bug yet because I think the reason is summer heat. Try to game with an opened computer case with a big fan blowing into it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
Guys, I am getting freezes on tahiti xt/fx9590 recently... But I am not logging a bug yet because I think the reason is summer heat. Try to game with an opened computer case with a big fan blowing into it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/amd/display: Use proper enum conversion functions
On Thu, Jul 4, 2019 at 7:52 AM Nathan Chancellor
wrote:
>
> clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:336:8:
> warning: implicit conversion from enumeration type 'enum smu_clk_type'
> to different enumeration type 'enum amd_pp_clock_type'
> [-Wenum-conversion]
> dc_to_smu_clock_type(clk_type),
> ^~~
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:421:14:
> warning: implicit conversion from enumeration type 'enum
> amd_pp_clock_type' to different enumeration type 'enum smu_clk_type'
> [-Wenum-conversion]
> dc_to_pp_clock_type(clk_type),
> ^~
>
> There are functions to properly convert between all of these types, use
> them so there are no longer any warnings.
I had a different solution for this one as well. The difference is that your
patch keeps the types and assumes that the functions do the right thing
(i.e. the warning was correct), while my version assumes that the code
works correctly, but the types are wrong (a false positive warning).
One of the two patches is correct, the other one is broken, but I have
no idea which one.
Arnd
From 61316b80c852d103bb61e1ce9904002414600125 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Mon, 8 Jul 2019 17:44:05 +0200
Subject: [PATCH] drm/amd/powerplay: fix one more incorrect enum conversion
Similar to a previous patch, this one converts the type from a
function argument of a different enum type:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:336:8:
error: implicit conversion from enumeration type 'enum smu_clk_type'
to different enumeration type 'enum amd_pp_clock_type'
[-Werror,-Wenum-conversion]
dc_to_smu_clock_type(clk_type),
^~~
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:868:77: note:
expanded from macro 'smu_get_clock_by_type'
((smu)->funcs->get_clock_by_type ?
(smu)->funcs->get_clock_by_type((smu), (type), (clocks)) : 0)
~
^~~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:421:14:
error: implicit conversion from enumeration type 'enum
amd_pp_clock_type' to different enumeration type 'enum smu_clk_type'
[-Werror,-Wenum-conversion]
dc_to_pp_clock_type(clk_type),
^~
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:872:111:
note: expanded from macro 'smu_get_clock_by_type_with_latency'
Add another type cast.
Fixes: e5e4e22391c2 ("drm/amd/powerplay: add interface to get clock by
type with latency for display (v2)")
Signed-off-by: Arnd Bergmann
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
index eac09bfe3be2..88e3f8456b1c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
@@ -333,7 +333,7 @@ bool dm_pp_get_clock_levels_by_type(
}
} else if (adev->smu.funcs && adev->smu.funcs->get_clock_by_type) {
if (smu_get_clock_by_type(&adev->smu,
- dc_to_smu_clock_type(clk_type),
+ (enum
amd_pp_clock_type)dc_to_smu_clock_type(clk_type),
&pp_clks)) {
get_default_clock_levels(clk_type, dc_clks);
return true;
@@ -418,7 +418,7 @@ bool dm_pp_get_clock_levels_by_type_with_latency(
return false;
} else if (adev->smu.ppt_funcs &&
adev->smu.ppt_funcs->get_clock_by_type_with_latency) {
if (smu_get_clock_by_type_with_latency(&adev->smu,
-
dc_to_pp_clock_type(clk_type),
+ (enum
smu_clk_type)dc_to_pp_clock_type(clk_type),
&pp_clks))
return false;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109524] "Invalid glsl version in shading_language_version()" when trying to run directX games using wine
https://bugs.freedesktop.org/show_bug.cgi?id=109524 --- Comment #12 from BabylonAS --- On Debian Testing I still have Mesa 18.3.6; so do I have to build Mesa from source code in order to get the patch? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/4] backlight: Expose brightness curve type through sysfs
Backlight brightness curves can have different shapes. The two main types are linear and non-linear curves. The human eye doesn't perceive linearly increasing/decreasing brightness as linear (see also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED linearly to human eye"), hence many backlights use non-linear (often logarithmic) brightness curves. The type of curve is currently opaque to userspace, so userspace often relies on more or less reliable heuristics (like the number of brightness levels) to decide whether to treat a backlight device as linear or non-linear. Export the type of the brightness curve via a new sysfs attribute. Matthias Kaehlcke (4): MAINTAINERS: Add entry for stable backlight sysfs ABI documentation backlight: Expose brightness curve type through sysfs backlight: pwm_bl: Set scale type for CIE 1931 curves backlight: pwm_bl: Set scale type for brightness curves specified in the DT .../ABI/testing/sysfs-class-backlight | 26 ++ MAINTAINERS | 2 ++ drivers/video/backlight/backlight.c | 19 ++ drivers/video/backlight/pwm_bl.c | 35 ++- include/linux/backlight.h | 8 + 5 files changed, 89 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-class-backlight -- 2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT
Check if a brightness curve specified in the device tree is linear or
not and set the corresponding property accordingly. This makes the
scale type available to userspace via the 'scale' sysfs attribute.
To determine if a curve is linear it is compared to a interpolated linear
curve between min and max brightness. The curve is considered linear if
no value deviates more than +/-5% of ${brightness_range} from their
interpolated value.
Signed-off-by: Matthias Kaehlcke
Acked-by: Daniel Thompson
---
Changes in v3:
- none
Changes in v2:
- use 128 (power of two) instead of 100 as factor for the slope
- add comment about max quantization error
- added Daniel's 'Acked-by' tag
---
drivers/video/backlight/pwm_bl.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 7c6dfc4a601d..fef98beb8b7e 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -404,6 +404,31 @@ int pwm_backlight_brightness_default(struct device *dev,
}
#endif
+static bool pwm_backlight_is_linear(struct platform_pwm_backlight_data *data)
+{
+ unsigned int nlevels = data->max_brightness + 1;
+ unsigned int min_val = data->levels[0];
+ unsigned int max_val = data->levels[nlevels - 1];
+ /*
+* Multiplying by 128 means that even in pathological cases such
+* as (max_val - min_val) == nlevels the error at max_val is less
+* than 1%.
+*/
+ unsigned int slope = (128 * (max_val - min_val)) / nlevels;
+ unsigned int margin = (max_val - min_val) / 20; /* 5% */
+ int i;
+
+ for (i = 1; i < nlevels; i++) {
+ unsigned int linear_value = min_val + ((i * slope) / 128);
+ unsigned int delta = abs(linear_value - data->levels[i]);
+
+ if (delta > margin)
+ return false;
+ }
+
+ return true;
+}
+
static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb)
{
struct device_node *node = pb->dev->of_node;
@@ -567,6 +592,11 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
pb->levels = data->levels;
}
+
+ if (pwm_backlight_is_linear(data))
+ props.scale = BACKLIGHT_SCALE_LINEAR;
+ else
+ props.scale = BACKLIGHT_SCALE_NON_LINEAR;
} else if (!data->max_brightness) {
/*
* If no brightness levels are provided and max_brightness is
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 2/4] backlight: Expose brightness curve type through sysfs
Backlight brightness curves can have different shapes. The two main
types are linear and non-linear curves. The human eye doesn't
perceive linearly increasing/decreasing brightness as linear (see
also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED
linearly to human eye"), hence many backlights use non-linear (often
logarithmic) brightness curves. The type of curve currently is opaque
to userspace, so userspace often uses more or less reliable heuristics
(like the number of brightness levels) to decide whether to treat a
backlight device as linear or non-linear.
Export the type of the brightness curve via the new sysfs attribute
'scale'. The value of the attribute can be 'linear', 'non-linear' or
'unknown'. For devices that don't provide information about the scale
of their brightness curve the value of the 'scale' attribute is 'unknown'.
Signed-off-by: Matthias Kaehlcke
---
Feel free to suggest improvements in the documentation :)
Changes in v3:
- removed composite strings, only keep 'linear', 'non-linear' and
'unknown'
- updated sysfs attribute documentation
- updated commit message
Changes in v2:
- changed order of brightness scale enums, explicitly make 'unknown' zero
- minor update of commit message
- deleted excess blank line after 'backlight_scale_types'
- s/curves/curve/ in sysfs doc
---
.../ABI/testing/sysfs-class-backlight | 26 +++
MAINTAINERS | 1 +
drivers/video/backlight/backlight.c | 19 ++
include/linux/backlight.h | 8 ++
4 files changed, 54 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-backlight
diff --git a/Documentation/ABI/testing/sysfs-class-backlight
b/Documentation/ABI/testing/sysfs-class-backlight
new file mode 100644
index ..3ab175a3f5cb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight
@@ -0,0 +1,26 @@
+What: /sys/class/backlight//scale
+Date: July 2019
+KernelVersion: 5.4
+Contact: Daniel Thompson
+Description:
+ Description of the scale of the brightness curve.
+
+ The human eye senses brightness approximately logarithmically,
+ hence linear changes in brightness are perceived as being
+ non-linear. To achieve a linear perception of brightness changes
+ controls like sliders need to apply a logarithmic mapping for
+ backlights with a linear brightness curve.
+
+ Possible values of the attribute are:
+
+ unknown
+ The scale of the brightness curve is unknown.
+
+ linear
+ The brightness changes linearly with each step. Brightness
+ controls should apply a logarithmic mapping for a linear
+ perception.
+
+ non-linear
+ The brightness changes non-linearly with each step. Brightness
+ controls should use a linear mapping for a linear perception.
diff --git a/MAINTAINERS b/MAINTAINERS
index d51e74340870..c46812510ba5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2858,6 +2858,7 @@ F:include/linux/backlight.h
F: include/linux/pwm_backlight.h
F: Documentation/devicetree/bindings/leds/backlight
F: Documentation/ABI/stable/sysfs-class-backlight
+F: Documentation/ABI/testing/sysfs-class-backlight
BATMAN ADVANCED
M: Marek Lindner
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 1ef8b6fd62ac..277abc76c83a 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -32,6 +32,12 @@ static const char *const backlight_types[] = {
[BACKLIGHT_FIRMWARE] = "firmware",
};
+static const char *const backlight_scale_types[] = {
+ [BACKLIGHT_SCALE_UNKNOWN] = "unknown",
+ [BACKLIGHT_SCALE_LINEAR]= "linear",
+ [BACKLIGHT_SCALE_NON_LINEAR]= "non-linear",
+};
+
#if defined(CONFIG_FB) || (defined(CONFIG_FB_MODULE) && \
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
/* This callback gets called when something important happens inside a
@@ -246,6 +252,18 @@ static ssize_t actual_brightness_show(struct device *dev,
}
static DEVICE_ATTR_RO(actual_brightness);
+static ssize_t scale_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct backlight_device *bd = to_backlight_device(dev);
+
+ if (WARN_ON(bd->props.scale > BACKLIGHT_SCALE_NON_LINEAR))
+ return sprintf(buf, "unknown\n");
+
+ return sprintf(buf, "%s\n", backlight_scale_types[bd->props.scale]);
+}
+static DEVICE_ATTR_RO(scale);
+
static struct class *backlight_class;
#ifdef CONFIG_PM_SLEEP
@@ -292,6 +310,7 @@ static struct attribute *bl_device_attrs[] = {
&dev_attr_brightness.attr,
&dev_attr_actual_brightness.attr,
&dev_attr_max_
[PATCH v3 1/4] MAINTAINERS: Add entry for stable backlight sysfs ABI documentation
Add an entry for the stable backlight sysfs ABI to the MAINTAINERS file. Signed-off-by: Matthias Kaehlcke Acked-by: Daniel Thompson --- Changes in v3: - none Changes in v2: - added Daniel's 'Acked-by' tag --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 57f496cff999..d51e74340870 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2857,6 +2857,7 @@ F:drivers/video/backlight/ F: include/linux/backlight.h F: include/linux/pwm_backlight.h F: Documentation/devicetree/bindings/leds/backlight +F: Documentation/ABI/stable/sysfs-class-backlight BATMAN ADVANCED M: Marek Lindner -- 2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 3/4] backlight: pwm_bl: Set scale type for CIE 1931 curves
For backlight curves calculated with the CIE 1931 algorithm set
the brightness scale type to non-linear. This makes the scale type
available to userspace via the 'scale' sysfs attribute.
Signed-off-by: Matthias Kaehlcke
Tested-by: Enric Balletbo i Serra
Acked-by: Daniel Thompson
---
Changes in v3:
- mark scale as non-linear instead of using the CIE1931 type which
has been removed
- updated commit message
Changes in v2:
- added Enric's 'Tested-by' tag
- added Daniel's 'Acked-by' tag
---
drivers/video/backlight/pwm_bl.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index fb45f866b923..7c6dfc4a601d 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -553,6 +553,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
goto err_alloc;
}
+ memset(&props, 0, sizeof(struct backlight_properties));
+
if (data->levels) {
/*
* For the DT case, only when brightness levels is defined
@@ -591,6 +593,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->levels = data->levels;
}
+
+ props.scale = BACKLIGHT_SCALE_NON_LINEAR;
} else {
/*
* That only happens for the non-DT case, where platform data
@@ -601,7 +605,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
- memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = data->max_brightness;
bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, pb,
--
2.22.0.410.gd8fdbe21b5-goog
Re: [PATCH 00/10] Enable MST Aux devices (v2)
Hi Lyude, sorry - just realized I forgot to CC you on this series! Let me know if I should resend them. Adding some additional reviewers as well. Thanks, Leo On 2019-07-04 3:05 p.m., sunpeng...@amd.com wrote: > From: Leo Li > > Hi all, > > Here's the second revision of patches to enable mst aux devices. > > v2 fixes an aux device unregistration issue during driver unload. See > patch 2/10 for details. Consequently, drivers supporting mst are > modified to use the new mst connector late register and early unregister > helpers. > > Thanks, > Leo > > Leo Li (9): > drm/dp: Use non-cyclic idr > drm/sysfs: Add mstpath attribute to connector devices > drm/nouveau: Use connector kdev as aux device parent > drm/bridge/analogix-anx78xx: Use connector kdev as aux device parent > drm/amd/display: Use connector kdev as aux device parent > drm/i915: Implement MST Aux device registration > drm/nouveau/kms/nv50: Implement MST Aux device registration > drm/radeon: Implement MST Aux device registration > drm/amd/display: Implement MST Aux device registration > > Ville Syrjälä (1): > drm/dp_mst: Enable registration of AUX devices for MST ports > > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 26 +++- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 22 +-- > drivers/gpu/drm/drm_dp_aux_dev.c | 19 ++- > drivers/gpu/drm/drm_dp_mst_topology.c | 137 -- > drivers/gpu/drm/drm_sysfs.c | 23 +++ > drivers/gpu/drm/i915/display/intel_dp_mst.c | 29 +++- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 20 +++ > drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +- > drivers/gpu/drm/radeon/radeon_dp_mst.c| 22 +++ > include/drm/drm_dp_helper.h | 4 + > include/drm/drm_dp_mst_helper.h | 11 ++ > 11 files changed, 285 insertions(+), 30 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/33] drm: drop use of drmp.h in drm-misc
Hi all. On Sun, Jun 30, 2019 at 08:18:49AM +0200, Sam Ravnborg wrote: > This patch set removes a far share of the remaining uses of drmP.h. > Common for all patches are that the respective files are maintained > in drm-misc. > All patches are independent except [PATCH 32] drm/ast, > [PATCH 31] drm/bochs and [PATCH 33] drm/hisilicon. > They need the fix to drm_vram_mm_helper.h [PATCH 30]. > > Patches have all been build tested with various configs and various > architectures. > There are likely introduced a few build issues that randconfig > build will reveal, but for all configs I have used the build was OK. > > This patchset does not conclude the quest to kill all uses > of drmP.h, but it is a major step towards the goal. > > Please review/ack. > I plan to apply the patches to drm-misc, but feel free > to do it yourself. On holiday this week, will process patches next week. Plan to apply reviewed patches to drm-misc-next and hope to have almost all of it ready for 5.3. Final removal of drmP.h will be after 5.3 due to dependencies with other trees. This is how I see it outlined now, plans may change as reality strikes. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: avoid 64-bit division
On Tue, Jul 9, 2019 at 6:40 PM Deucher, Alexander wrote: > > I'll just apply Arnd's patch. If the display team wants to adjust it later > to clarify the > operation, they should go ahead as a follow up patch. Thanks! > From: Abramov, Slava > Sent: Tuesday, July 9, 2019 12:31 PM > > Thanks for bisecting this issue. > > > > I wonder whether you are going to commit your patch or planning to update > > it and it's > > still in your work queue. We have one of our 32-bit builds failing because > > of this > > issue, so that I would like either to fix it or wait to your fix if it has > > chances to go > > upstream today. I was going to update the patch, but had not gotten to that yet. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/6] drm: Add Content protection type property
On 2019-07-09 at 17:31:10 +0300, Pekka Paalanen wrote:
> On Mon, 8 Jul 2019 16:51:11 +0530
> Ramalingam C wrote:
>
> > This patch adds a DRM ENUM property to the selected connectors.
> > This property is used for mentioning the protected content's type
> > from userspace to kernel HDCP authentication.
> >
> > Type of the stream is decided by the protected content providers.
> > Type 0 content can be rendered on any HDCP protected display wires.
> > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> >
> > So when a userspace sets this property to Type 1 and starts the HDCP
> > enable, kernel will honour it only if HDCP2.2 authentication is through
> > for type 1. Else HDCP enable will be failed.
> >
> > Need ACK for this new conenctor property from userspace consumer.
> >
> > v2:
> > cp_content_type is replaced with content_protection_type [daniel]
> > check at atomic_set_property is removed [Maarten]
> > v3:
> > %s/content_protection_type/hdcp_content_type [Pekka]
> > v4:
> > property is created for the first requested connector and then reused.
> > [Danvet]
> > v5:
> > kernel doc nits addressed [Daniel]
> > Rebased as part of patch reordering.
> > v6:
> > Kernel docs are modified [pekka]
> > v7:
> > More details in Kernel docs. [pekka]
> >
> > Signed-off-by: Ramalingam C
> > Reviewed-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> > drivers/gpu/drm/drm_connector.c | 39 +++
> > drivers/gpu/drm/drm_hdcp.c| 36 -
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++-
> > include/drm/drm_connector.h | 7
> > include/drm/drm_hdcp.h| 2 +-
> > include/drm/drm_mode_config.h | 6
> > include/uapi/drm/drm_mode.h | 4 +++
> > 8 files changed, 99 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index abe38bdf85ae..19ae119f1a5d 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -747,6 +747,8 @@ static int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> > return -EINVAL;
> > }
> > state->content_protection = val;
> > + } else if (property == config->hdcp_content_type_property) {
> > + state->hdcp_content_type = val;
> > } else if (property == connector->colorspace_property) {
> > state->colorspace = val;
> > } else if (property == config->writeback_fb_id_property) {
> > @@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct drm_connector
> > *connector,
> > state->hdr_output_metadata->base.id : 0;
> > } else if (property == config->content_protection_property) {
> > *val = state->content_protection;
> > + } else if (property == config->hdcp_content_type_property) {
> > + *val = state->hdcp_content_type;
> > } else if (property == config->writeback_fb_id_property) {
> > /* Writeback framebuffer is one-shot, write and forget */
> > *val = 0;
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 068d4b05f1be..732f6645643d 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -952,6 +952,45 @@ static const struct drm_prop_enum_list
> > hdmi_colorspaces[] = {
> > * is no longer protected and userspace should take appropriate action
> > * (whatever that might be).
> > *
> > + * HDCP Content Type:
> > + * This Enum property is used by the userspace to declare the content type
> > + * of the display stream, to kernel. Here display stream stands for any
> > + * display content that userspace intended to render with HDCP encryption.
>
> Hi,
>
> I'd suggest s/render with/display through/.
>
> As a gfx dev, rendering is something quite different to me.
Ok.
>
> > + *
> > + * Content Type of a stream is decided by the owner of the stream, as
> > + * "HDCP Type0" or "HDCP Type1".
> > + *
> > + * The value of the property can be one the below:
>
> *one of the below
Sure.
>
> > + * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
> > + * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1
> > + *
> > + * When kernel starts the HDCP authentication upon the "DESIRED" state of
> > + * the "Content Protection", it refers the "HDCP Content Type" property
> > + * state. And perform the HDCP authentication with the display sink for
> > + * the content type mentioned by "HDCP Content Type".
>
> How about:
>
> When kernel starts the HDCP authentication (see "Content Protection"
> for details), it uses the content type in "HDCP Content Type"
> for performing the HDCP authentication with the display sink.
less confusing :) Thanks.
>
> > + *
> > + * Stream classified as HDCP Type0 can be
Re: [PATCH v8 1/6] drm: Add Content protection type property
On 2019-07-09 at 16:26:31 +0300, Pekka Paalanen wrote:
> On Mon, 8 Jul 2019 14:42:29 +0530
> Ramalingam C wrote:
>
> > On 2019-07-08 at 12:59:59 +0300, Pekka Paalanen wrote:
> > > On Mon, 8 Jul 2019 12:52:17 +0300
> > > Pekka Paalanen wrote:
> > >
> > > > On Fri, 5 Jul 2019 06:16:37 +0530
> > > > Ramalingam C wrote:
> > > >
> > > > > This patch adds a DRM ENUM property to the selected connectors.
> > > > > This property is used for mentioning the protected content's type
> > > > > from userspace to kernel HDCP authentication.
> > > > >
> > > > > Type of the stream is decided by the protected content providers.
> > > > > Type 0 content can be rendered on any HDCP protected display wires.
> > > > > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> > > > >
> > > > > So when a userspace sets this property to Type 1 and starts the HDCP
> > > > > enable, kernel will honour it only if HDCP2.2 authentication is
> > > > > through
> > > > > for type 1. Else HDCP enable will be failed.
> > > > >
> > > > > Need ACK for this new conenctor property from userspace consumer.
> > > > >
> > > > > v2:
> > > > > cp_content_type is replaced with content_protection_type [daniel]
> > > > > check at atomic_set_property is removed [Maarten]
> > > > > v3:
> > > > > %s/content_protection_type/hdcp_content_type [Pekka]
> > > > > v4:
> > > > > property is created for the first requested connector and then
> > > > > reused.
> > > > > [Danvet]
> > > > > v5:
> > > > > kernel doc nits addressed [Daniel]
> > > > > Rebased as part of patch reordering.
> > > > > v6:
> > > > > Kernel docs are modified [pekka]
> > > > >
> > > > > Signed-off-by: Ramalingam C
> > > > > Reviewed-by: Daniel Vetter
> > > > > ---
> > > > > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> > > > > drivers/gpu/drm/drm_connector.c | 22 ++
> > > > > drivers/gpu/drm/drm_hdcp.c| 36
> > > > > ++-
> > > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++-
> > > > > include/drm/drm_connector.h | 7 +
> > > > > include/drm/drm_hdcp.h| 2 +-
> > > > > include/drm/drm_mode_config.h | 6
> > > > > include/uapi/drm/drm_mode.h | 4 +++
> > > > > 8 files changed, 82 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > index abe38bdf85ae..19ae119f1a5d 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > @@ -747,6 +747,8 @@ static int
> > > > > drm_atomic_connector_set_property(struct drm_connector *connector,
> > > > > return -EINVAL;
> > > > > }
> > > > > state->content_protection = val;
> > > > > + } else if (property == config->hdcp_content_type_property) {
> > > > > + state->hdcp_content_type = val;
> > > > > } else if (property == connector->colorspace_property) {
> > > > > state->colorspace = val;
> > > > > } else if (property == config->writeback_fb_id_property) {
> > > > > @@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct
> > > > > drm_connector *connector,
> > > > > state->hdr_output_metadata->base.id : 0;
> > > > > } else if (property == config->content_protection_property) {
> > > > > *val = state->content_protection;
> > > > > + } else if (property == config->hdcp_content_type_property) {
> > > > > + *val = state->hdcp_content_type;
> > > > > } else if (property == config->writeback_fb_id_property) {
> > > > > /* Writeback framebuffer is one-shot, write and forget
> > > > > */
> > > > > *val = 0;
> > > > > diff --git a/drivers/gpu/drm/drm_connector.c
> > > > > b/drivers/gpu/drm/drm_connector.c
> > > > > index 068d4b05f1be..17aef88c03a6 100644
> > > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > > @@ -951,6 +951,28 @@ static const struct drm_prop_enum_list
> > > > > hdmi_colorspaces[] = {
> > > > > * the value transitions from ENABLED to DESIRED. This signifies
> > > > > the link
> > > > > * is no longer protected and userspace should take appropriate
> > > > > action
> > > > > * (whatever that might be).
> > > > > + * HDCP Content Type:
> > > > > + * This property is used by the userspace to configure the kernel
> > > > > with
> > > > > + * to be displayed stream's content type. Content Type of a stream
> > > > > is
> > > > > + * decided by the owner of the stream, as "HDCP Type0" or "HDCP
> > > > > Type1".
> > > > > + *
> > > > > + * The value of the property can be one the below:
> > > > > + * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
> > > > > + * HDCP Type0 streams can be transmitted on a link which is
> > > >
Re: [PATCH 5/7] ASoC: rockchip: rockchip-max98090: Add node for HDMI
On Mon, Jun 03, 2019 at 12:32:49PM +0800, Cheng-Yi Chiang wrote:
> Let user specify HDMI node so machine driver can use it to let codec
> driver register callback on correct hdmi-notifier.
>
> Signed-off-by: Cheng-Yi Chiang
> ---
> Documentation/devicetree/bindings/sound/rockchip-max98090.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
> b/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
> index a805aa99ad75..dae57c14864e 100644
> --- a/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
> +++ b/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
> @@ -7,6 +7,7 @@ Required properties:
>connected to the CODEC
> - rockchip,audio-codec: The phandle of the MAX98090 audio codec
> - rockchip,headset-codec: The phandle of Ext chip for jack detection
> +- rockchip,hdmi: The phandle of HDMI node for HDMI jack detection
>
> Example:
>
> @@ -16,4 +17,5 @@ sound {
> rockchip,i2s-controller = <&i2s>;
> rockchip,audio-codec = <&max98090>;
> rockchip,headset-codec = <&headsetcodec>;
> + rockchip,hdmi= <&hdmi>;
space^
With that,
Acked-by: Rob Herring
> };
> --
> 2.22.0.rc1.257.g3120a18244-goog
>
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard wrote: > > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > > > > Maybe instead of edp-connector one would introduce integrator's specific > > > > connector, for example with compatible "olimex,teres-edp-connector" > > > > which should follow edp abstract connector rules? This will be at least > > > > consistent with below presentation[1] - eDP requirements depends on > > > > integrator. Then if olimex has standard way of dealing with panels > > > > present in olimex/teres platforms the driver would then create > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > > > Anyway it still looks fishy for me :), maybe because I am not > > > > familiarized with details of these platforms. > > > > > > That makes sense yes > > > > Actually, it makes no sense at all. Current implementation for anx6345 > > driver works fine as is with any panel specified assuming panel delays > > are long enough for connected panel. It just doesn't use panel timings > > from the driver. Creating a platform driver for connector itself looks > > redundant since it can't be reused, it doesn't describe actual > > hardware and it's just defeats purpose of DT by introducing > > board-specific code. > > I'm not sure where you got the idea that the purpose of DT is to not > have any board-specific code. I believe DT was an attempt to move to declarative approach for describing hardware. Yes, we have different compatibles for different devices but they're specific to particular device rather than particular board. Device interconnection is described in DT along with some properties rather than in board-specific C-file. Introducing board-specific compatible for a connector isn't looking right to me. > It's perfectly fine to have some, that's even why there's a compatible > assigned to each and every board. > > What the DT is about is allowing us to have a generic behaviour that > we can detect: we can have a given behaviour for a given board, and a > separate one for another one, and this will be evaluated at runtime. > > This is *exactly* what this is about: we can have a compatible that > sets a given, more specific, behaviour (olimex,teres-edp-connector) > while saying that this is compatible with the generic behaviour > (edp-connector). That way, any OS will know what quirk to apply if > needed, and if not that it can use the generic behaviour. > > And we could create a generic driver, for the generic behaviour if > needed. > > > There's another issue: if we introduce edp-connector we'll have to > > specify power up delays somewhere (in dts? or in platform driver?), so > > edp-connector doesn't really solve the issue of multiple panels with > > same motherboard. > > And that's what that compatible is about :) Sorry, I fail to see how it would be different from using existing panels infrastructure and different panels compatibles. I think Rob's idea was to introduce generic edp-connector. If we can't make it generic then let's use panel infrastructure. > > I'd say DT overlays should be preferred solution here, not another > > connector binding. > > Overlays are a way to apply a device tree dynamically. It's orthogonal > to the binding. It isn't orthogonal to original problem though. > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/tegra: Fix gpiod_get_from_of_node() regression
09.07.2019 19:27, Jon Hunter пишет:
>
> On 05/07/2019 16:11, Dmitry Osipenko wrote:
>> That function now returns ERR_PTR instead of NULL if "hpd-gpio" is not
>> present in device-tree. The offending patch missed to adapt the Tegra's
>> DRM driver for the API change.
>>
>> Fixes: 025bf37725f1 ("gpio: Fix return value mismatch of function
>> gpiod_get_from_of_node()")
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/gpu/drm/tegra/output.c | 8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
>> index 274cb955e2e1..471d33809cd4 100644
>> --- a/drivers/gpu/drm/tegra/output.c
>> +++ b/drivers/gpu/drm/tegra/output.c
>> @@ -126,8 +126,12 @@ int tegra_output_probe(struct tegra_output *output)
>> "nvidia,hpd-gpio", 0,
>> GPIOD_IN,
>> "HDMI hotplug detect");
>> -if (IS_ERR(output->hpd_gpio))
>> -return PTR_ERR(output->hpd_gpio);
>> +if (IS_ERR(output->hpd_gpio)) {
>> +if (PTR_ERR(output->hpd_gpio) == -ENOENT)
>> +output->hpd_gpio = NULL;
>> +else
>> +return PTR_ERR(output->hpd_gpio);
>> +}
>>
>> if (output->hpd_gpio) {
>> err = gpiod_to_irq(output->hpd_gpio);
>>
>
> Acked-by: Jon Hunter
Thanks!
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #85 from dwagner --- (In reply to Wilko Bartels from comment #84) > nevermind. it crashed on 60hz as well (once) yesterday It sure does. This bug is now about two years old, during which amdgpu has never been stable, got worse, and every contemporary kernel, whether "official" ones or ones compiled from git heads of development trees has this very problem, which I can reproduce within minutes. I've given up hoping for a fix. I'll buy an Intel Xe GPU as soon as it hits the shelves. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dt-bindings: display: rockchip: document VOP gamma LUT address
On Fri, 21 Jun 2019 18:13:44 -0300, Ezequiel Garcia wrote: > Add the register specifier description for an > optional gamma LUT address. > > Signed-off-by: Ezequiel Garcia > --- > Changes from v1: > * Drop reg-names, suggested by Doug. > --- > .../devicetree/bindings/display/rockchip/rockchip-vop.txt | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
[PATCH v6 0/4] Panel rotation patches
This adds the plumbing for reading panel rotation from the devicetree and sets up adding a panel property for the panel orientation on Mediatek SoCs when a rotation is present. v6 changes: -added enum declaration to drm_panel.h header v5 changes: -rebased v4 changes: -fixed some changes made to the i915 driver -clarified comments on of orientation helper v3 changes: -changed from attach/detach callbacks to directly setting fixed panel values in drm_panel_attach -removed update to Documentation -added separate function for quirked panel orientation property init v2 changes: fixed build errors in i915 Derek Basehore (4): drm/panel: Add helper for reading DT rotation drm/panel: set display info in panel attach drm/connector: Split out orientation quirk detection drm/mtk: add panel orientation property drivers/gpu/drm/drm_connector.c| 45 ++- drivers/gpu/drm/drm_panel.c| 70 ++ drivers/gpu/drm/i915/intel_dp.c| 4 +- drivers/gpu/drm/i915/vlv_dsi.c | 5 +-- drivers/gpu/drm/mediatek/mtk_dsi.c | 8 include/drm/drm_connector.h| 2 + include/drm/drm_panel.h| 21 + 7 files changed, 138 insertions(+), 17 deletions(-) -- 2.22.0.410.gd8fdbe21b5-goog
[PATCH v6 3/4] drm/connector: Split out orientation quirk detection
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_connector.c | 45 ++---
drivers/gpu/drm/i915/display/intel_dp.c | 4 +--
drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
include/drm/drm_connector.h | 2 ++
4 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3f2cf7eae9c..52777d647494 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1892,31 +1892,23 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
* drm_connector_init_panel_orientation_property -
* initialize the connecters panel_orientation property
* @connector: connector for which to init the panel-orientation property.
- * @width: width in pixels of the panel, used for panel quirk detection
- * @height: height in pixels of the panel, used for panel quirk detection
*
* This function should only be called for built-in panels, after setting
* connector->display_info.panel_orientation first (if known).
*
- * This function will check for platform specific (e.g. DMI based) quirks
- * overriding display_info.panel_orientation first, then if panel_orientation
- * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
- * "panel orientation" property to the connector.
+ * This function will check if the panel_orientation is not
+ * DRM_MODE_PANEL_ORIENTATION_UNKNOWN. If not, it will attach the "panel
+ * orientation" property to the connector.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_init_panel_orientation_property(
- struct drm_connector *connector, int width, int height)
+ struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct drm_display_info *info = &connector->display_info;
struct drm_property *prop;
- int orientation_quirk;
-
- orientation_quirk = drm_get_panel_orientation_quirk(width, height);
- if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
- info->panel_orientation = orientation_quirk;
if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
return 0;
@@ -1939,6 +1931,35 @@ int drm_connector_init_panel_orientation_property(
}
EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+/**
+ * drm_connector_init_panel_orientation_property_quirk -
+ * initialize the connecters panel_orientation property with a quirk
+ * override
+ * @connector: connector for which to init the panel-orientation property.
+ * @width: width in pixels of the panel, used for panel quirk detection
+ * @height: height in pixels of the panel, used for panel quirk detection
+ *
+ * This function will check for platform specific (e.g. DMI based) quirks
+ * overriding display_info.panel_orientation first, then if panel_orientation
+ * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
+ * "panel orientation" property to the connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property_quirk(
+ struct drm_connector *connector, int width, int height)
+{
+ int orientation_quirk;
+
+ orientation_quirk = drm_get_panel_orientation_quirk(width, height);
+ if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
+ connector->display_info.panel_orientation = orientation_quirk;
+
+ return drm_connector_init_panel_orientation_property(connector);
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property_quirk);
+
int drm_connector_set_obj_prop(struct drm_mode_object *obj,
struct drm_property *property,
uint64_t value)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8f7188d71d08..45b637419085 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7068,8 +7068,8 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
intel_panel_setup_backlight(connector, pipe);
if (fixed_mode)
- drm_connector_init_panel_orientation_property(
- connector, fixed_mode->hdisplay, fixed_mode->vdisplay);
+ drm_connector_init_panel_orientation_property_quirk(connector,
+ fixed_mode->hdisplay, fixed_mode->vdisplay);
return true;
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index e272d826210a..dd7fa806f95c 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -166
[PATCH v6 2/4] drm/panel: set display info in panel attach
Devicetree systems can set panel orientation via a panel binding, but
there's no way, as is, to propagate this setting to the connector,
where the property need to be added.
To address this, this patch sets orientation, as well as other fixed
values for the panel, in the drm_panel_attach function. These values
are stored from probe in the drm_panel struct.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 28
include/drm/drm_panel.h | 14 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 169bab54d52d..ca01095470a9 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -104,11 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
*/
int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
{
+ struct drm_display_info *info;
+
if (panel->connector)
return -EBUSY;
panel->connector = connector;
panel->drm = connector->dev;
+ info = &connector->display_info;
+ info->width_mm = panel->width_mm;
+ info->height_mm = panel->height_mm;
+ info->bpc = panel->bpc;
+ info->panel_orientation = panel->orientation;
+ info->bus_flags = panel->bus_flags;
+ if (panel->bus_formats)
+ drm_display_info_set_bus_formats(&connector->display_info,
+panel->bus_formats,
+panel->num_bus_formats);
return 0;
}
@@ -128,6 +140,22 @@ EXPORT_SYMBOL(drm_panel_attach);
*/
int drm_panel_detach(struct drm_panel *panel)
{
+ struct drm_display_info *info;
+
+ if (!panel->connector)
+ goto out;
+
+ info = &panel->connector->display_info;
+ info->width_mm = 0;
+ info->height_mm = 0;
+ info->bpc = 0;
+ info->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+ info->bus_flags = 0;
+ kfree(info->bus_formats);
+ info->bus_formats = NULL;
+ info->num_bus_formats = 0;
+
+out:
panel->connector = NULL;
panel->drm = NULL;
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index a18c59f136ab..1760c11e0298 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -39,6 +39,8 @@ enum drm_panel_orientation;
* struct drm_panel_funcs - perform operations on a given panel
* @disable: disable panel (turn off back light, etc.)
* @unprepare: turn off panel
+ * @detach: detach panel->connector (clear internal state, etc.)
+ * @attach: attach panel->connector (update internal state, etc.)
* @prepare: turn on panel and perform set up
* @enable: enable panel (turn on back light, etc.)
* @get_modes: add modes to the connector that the panel is attached to and
@@ -95,6 +97,18 @@ struct drm_panel {
const struct drm_panel_funcs *funcs;
+ /*
+* panel information to be set in the connector when the panel is
+* attached.
+*/
+ unsigned int width_mm;
+ unsigned int height_mm;
+ unsigned int bpc;
+ int orientation;
+ const u32 *bus_formats;
+ unsigned int num_bus_formats;
+ u32 bus_flags;
+
struct list_head list;
};
--
2.22.0.410.gd8fdbe21b5-goog
