[PULL] topic/mei-hdcp

[Daniel Vetter]

Hi all,

topic/mei-hdcp-2019-02-19:
Prep patches + headers for the mei-hdcp/i915 component interfaces

Also contains the prep work in the component helpers plus adjustements
for the snd-hda/i915 component interface.

Plus one small static inline in the drm_hdcp.h header that both i915
and mei_hdcp will need.

Joonas, please pull into drm-intel-next-queued so I can apply the i915
hdcp patches.

Greg/Arnd, I think there's two options to get the mei-hdcp patches landed
into drivers-misc:
- You pull this topic pull and then apply the mei-hdcp patches on top in
  char-misc-next.
- I also pull in char-misc-next to get at 32ea33a04484 ("mei: bus: export
  to_mei_cl_device for mei client devices drivers") and then apply all the
  mei-hdcp stuff into a new topic branch.

I think 2nd option would be better, allows us to integration test easier,
and we'll have a topic branch in case we need a fixup spanning mei-hdcp
and i915. Also would allow me to start merging the patches, since I think
it's too late for 5.1.

Cheers, Daniel

The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:

  Linux 5.0-rc5 (2019-02-03 13:48:04 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/topic/mei-hdcp-2019-02-19

for you to fetch changes up to 35c0272502cca0a1b461d310c23aac94a503983d:

  drm/audio: declaration of struct device (2019-02-18 20:19:28 +0100)


Prep patches + headers for the mei-hdcp/i915 component interfaces

Also contains the prep work in the component helpers plus adjustements
for the snd-hda/i915 component interface.

Plus one small static inline in the drm_hdcp.h header that both i915
and mei_hdcp will need.


Daniel Vetter (3):
  component: Add documentation
  components: multiple components for a device
  i915/snd_hdac: I915 subcomponent for the snd_hdac

Ramalingam C (5):
  drm/i915: enum port definition is moved into i915_drm.h
  drm/i915: header for i915 - MEI_HDCP interface
  drm/i915: MEI interface definition
  drm: helper functions for hdcp2 seq_num to from u32
  drm/audio: declaration of struct device

 Documentation/driver-api/component.rst   |  17 +++
 Documentation/driver-api/device_link.rst |   3 +
 Documentation/driver-api/index.rst   |   1 +
 drivers/base/component.c | 206 +--
 drivers/gpu/drm/i915/intel_audio.c   |   4 +-
 drivers/gpu/drm/i915/intel_display.h |  16 +--
 include/drm/drm_audio_component.h|   1 +
 include/drm/drm_hdcp.h   |  18 +++
 include/drm/i915_component.h |   5 +
 include/drm/i915_drm.h   |  15 +++
 include/drm/i915_mei_hdcp_interface.h| 149 ++
 include/linux/component.h|  76 
 include/sound/hda_component.h|   5 +-
 sound/hda/hdac_component.c   |   4 +-
 sound/hda/hdac_i915.c|   6 +-
 15 files changed, 493 insertions(+), 33 deletions(-)
 create mode 100644 Documentation/driver-api/component.rst
 create mode 100644 include/drm/i915_mei_hdcp_interface.h

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108711] [apitrace] GPU hangs in some opengl 1.x applications on RAVEN

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108711

--- Comment #4 from mittorn  ---
Still can reproduce on opensource drivers, but no crash on amdgpu-pro-18.50
Also i managed to recover system after gpu crash on "modesetting" xorg driver
and ignoring recover errors. GPU seems to ignore all commands after
"successful" recovery, but it is possible to suspend system. After entering
suspend gpu completely restarting and becomes useful again (except you need
restart all userspace that used gpu). Maybe it is only possible to implement
gpu recovery by entering whole system to suspend (because it is not possible to
shutdown power on APU)

-- 
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 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109206

--- Comment #12 from Adrian Garay  ---
(In reply to matrix8967 from comment #11)
> This is the exact same issue I had and the above solution for removing
> /lib/firmware/amdgpu/raven_dmcu.bin worked for me. 
> 
> For Ubuntu Users on 4.20 you'll need to also run 
> 
> sudo update-initramfs -u
> 
> to update the bootimage. Thanks Chris.

Removing this file and updating my initramfs allows my 2500u HP x360 to
actually boot to the desktop.  Unfortunately, the moment you try to load any
game or even the Steam client, the laptop will hard lock.

The desktop is otherwise functional.

-- 
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: [v2 1/1] drm/mediatek: add mt8183 dpi support

[CK Hu]

Hi, Jitao:

On Tue, 2019-02-19 at 11:06 +0800, Jitao Shi wrote:
> MT8183 samples on rising and falling edge. It can reduce half data
> io.
> MT8173 also has those registers. But the hw function is removed.
> So MT8173 doesn't support DPI dual edge sample and can't use the
> same setting to mt8183.
> 
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_dpi.c | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 62a9d47df948..610c23334047 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -117,6 +117,7 @@ struct mtk_dpi_conf {
>   unsigned int (*cal_factor)(int clock);
>   u32 reg_h_fre_con;
>   bool edge_sel_en;
> + bool dual_edge;
>  };
>  
>  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
> @@ -353,6 +354,13 @@ static void mtk_dpi_config_disable_edge(struct mtk_dpi 
> *dpi)
>   mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
>  }
>  
> +static void mtk_dpi_enable_dual_edge(struct mtk_dpi *dpi)
> +{
> + mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
> +  DDR_EN | DDR_4PHASE);
> + mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, EDGE_SEL, EDGE_SEL);
> +}

I would like to move dual edge function to an independent patch. Maybe
some other SoC need dual edge function but it's not mt8183 so it could
cherry-pick the dual edge part only.

> +
>  static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
>   enum mtk_dpi_out_color_format format)
>  {
> @@ -509,6 +517,8 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>   mtk_dpi_config_color_format(dpi, dpi->color_format);
>   mtk_dpi_config_2n_h_fre(dpi);
>   mtk_dpi_config_disable_edge(dpi);
> + if (dpi->conf->dual_edge)
> + mtk_dpi_enable_dual_edge(dpi);
>   mtk_dpi_sw_reset(dpi, false);
>  
>   return 0;
> @@ -671,6 +681,16 @@ static unsigned int mt2701_calculate_factor(int clock)
>   return 2;
>  }
>  
> +static unsigned int mt8183_calculate_factor(int clock)
> +{
> + if (clock <= 27000)
> + return 8;
> + else if (clock <= 167000)
> + return 4;
> + else
> + return 2;
> +}
> +
>  static const struct mtk_dpi_conf mt8173_conf = {
>   .cal_factor = mt8173_calculate_factor,
>   .reg_h_fre_con = 0xe0,
> @@ -682,6 +702,12 @@ static const struct mtk_dpi_conf mt2701_conf = {
>   .edge_sel_en = true,
>  };
>  
> +static const struct mtk_dpi_conf mt8183_conf = {
> + .cal_factor = mt8183_calculate_factor,
> + .reg_h_fre_con = 0xe0,
> + .dual_edge = true,
> +};
> +
>  static int mtk_dpi_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
> @@ -777,6 +803,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
>   { .compatible = "mediatek,mt8173-dpi",
> .data = &mt8173_conf,
>   },
> + { .compatible = "mediatek,mt8183-dpi",

I could not find "mediatek,mt8183-dpi" in binding document, please add
it.

Regards,
CK

> +   .data = &mt8183_conf,
> + },
>   { },
>  };
>  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108711] [apitrace] GPU hangs in some opengl 1.x applications on RAVEN

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108711

Timothy Arceri  changed:

   What|Removed |Added

Summary|GPU crash in some opengl|[apitrace] GPU hangs in
   |1.x applications on vega|some opengl 1.x
   |gpu |applications on RAVEN

-- 
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 108711] GPU crash in some opengl 1.x applications on vega gpu

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108711

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #3 from Timothy Arceri  ---
Ok, I was able to produce a hang when testing on my RAVEN laptop, seems like
this is a RAVEN specific issue. I could only test with the 4.19 kernel as my
laptop would not boot with 4.20.

-- 
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

[v2 1/1] drm/mediatek: add mt8183 dpi support

[Jitao Shi]

MT8183 samples on rising and falling edge. It can reduce half data
io.
MT8173 also has those registers. But the hw function is removed.
So MT8173 doesn't support DPI dual edge sample and can't use the
same setting to mt8183.

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 62a9d47df948..610c23334047 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -117,6 +117,7 @@ struct mtk_dpi_conf {
unsigned int (*cal_factor)(int clock);
u32 reg_h_fre_con;
bool edge_sel_en;
+   bool dual_edge;
 };
 
 static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -353,6 +354,13 @@ static void mtk_dpi_config_disable_edge(struct mtk_dpi 
*dpi)
mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
 }
 
+static void mtk_dpi_enable_dual_edge(struct mtk_dpi *dpi)
+{
+   mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
+DDR_EN | DDR_4PHASE);
+   mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, EDGE_SEL, EDGE_SEL);
+}
+
 static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
enum mtk_dpi_out_color_format format)
 {
@@ -509,6 +517,8 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
mtk_dpi_config_color_format(dpi, dpi->color_format);
mtk_dpi_config_2n_h_fre(dpi);
mtk_dpi_config_disable_edge(dpi);
+   if (dpi->conf->dual_edge)
+   mtk_dpi_enable_dual_edge(dpi);
mtk_dpi_sw_reset(dpi, false);
 
return 0;
@@ -671,6 +681,16 @@ static unsigned int mt2701_calculate_factor(int clock)
return 2;
 }
 
+static unsigned int mt8183_calculate_factor(int clock)
+{
+   if (clock <= 27000)
+   return 8;
+   else if (clock <= 167000)
+   return 4;
+   else
+   return 2;
+}
+
 static const struct mtk_dpi_conf mt8173_conf = {
.cal_factor = mt8173_calculate_factor,
.reg_h_fre_con = 0xe0,
@@ -682,6 +702,12 @@ static const struct mtk_dpi_conf mt2701_conf = {
.edge_sel_en = true,
 };
 
+static const struct mtk_dpi_conf mt8183_conf = {
+   .cal_factor = mt8183_calculate_factor,
+   .reg_h_fre_con = 0xe0,
+   .dual_edge = true,
+};
+
 static int mtk_dpi_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
@@ -777,6 +803,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
{ .compatible = "mediatek,mt8173-dpi",
  .data = &mt8173_conf,
},
+   { .compatible = "mediatek,mt8183-dpi",
+ .data = &mt8183_conf,
+   },
{ },
 };
 
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/mediatek: add mt8183 dpi support

[CK Hu]

Hi, Jitao:

On Tue, 2019-02-19 at 09:53 +0800, Jitao Shi wrote:
> On Fri, 2019-02-15 at 00:13 +0800, CK Hu wrote:
> > Hi, Jitao:
> > 
> > On Mon, 2019-02-11 at 12:50 +0800, Jitao Shi wrote:
> > > MT8183 sample on rising and falling edge. It can reduce half data io.
> > > 
> > > Signed-off-by: Jitao Shi 
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_dpi.c | 29 +
> > >  1 file changed, 29 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> > > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > index 62a9d47df948..610c23334047 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > @@ -117,6 +117,7 @@ struct mtk_dpi_conf {
> > >   unsigned int (*cal_factor)(int clock);
> > >   u32 reg_h_fre_con;
> > >   bool edge_sel_en;
> > > + bool dual_edge;
> > >  };
> > >  
> > >  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 
> > > mask)
> > > @@ -353,6 +354,13 @@ static void mtk_dpi_config_disable_edge(struct 
> > > mtk_dpi *dpi)
> > >   mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
> > >  }
> > >  
> > > +static void mtk_dpi_enable_dual_edge(struct mtk_dpi *dpi)
> > > +{
> > > + mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
> > > +  DDR_EN | DDR_4PHASE);
> > > + mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, EDGE_SEL, EDGE_SEL);
> > > +}
> > 
> > All these register exist in MT8173, if you do the same setting in
> > MT8173, could it also sample on rising edge and falling edge?
> > 
> > Regards,
> > CK
> 
> Hi CK,
> 
> MT8173 has those registers. But the hw function is removed.
> So MT8173 doesn't support DPI dual edge sample.

OK, please add this information in commit message.

Regards,
CK

> 
> Best Regards
> Jitao
> 
> > 
> > > +
> > >  static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
> > >   enum mtk_dpi_out_color_format format)
> > >  {
> > > @@ -509,6 +517,8 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi 
> > > *dpi,
> > >   mtk_dpi_config_color_format(dpi, dpi->color_format);
> > >   mtk_dpi_config_2n_h_fre(dpi);
> > >   mtk_dpi_config_disable_edge(dpi);
> > > + if (dpi->conf->dual_edge)
> > > + mtk_dpi_enable_dual_edge(dpi);
> > >   mtk_dpi_sw_reset(dpi, false);
> > >  
> > >   return 0;
> > > @@ -671,6 +681,16 @@ static unsigned int mt2701_calculate_factor(int 
> > > clock)
> > >   return 2;
> > >  }
> > >  
> > > +static unsigned int mt8183_calculate_factor(int clock)
> > > +{
> > > + if (clock <= 27000)
> > > + return 8;
> > > + else if (clock <= 167000)
> > > + return 4;
> > > + else
> > > + return 2;
> > > +}
> > > +
> > >  static const struct mtk_dpi_conf mt8173_conf = {
> > >   .cal_factor = mt8173_calculate_factor,
> > >   .reg_h_fre_con = 0xe0,
> > > @@ -682,6 +702,12 @@ static const struct mtk_dpi_conf mt2701_conf = {
> > >   .edge_sel_en = true,
> > >  };
> > >  
> > > +static const struct mtk_dpi_conf mt8183_conf = {
> > > + .cal_factor = mt8183_calculate_factor,
> > > + .reg_h_fre_con = 0xe0,
> > > + .dual_edge = true,
> > > +};
> > > +
> > >  static int mtk_dpi_probe(struct platform_device *pdev)
> > >  {
> > >   struct device *dev = &pdev->dev;
> > > @@ -777,6 +803,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
> > >   { .compatible = "mediatek,mt8173-dpi",
> > > .data = &mt8173_conf,
> > >   },
> > > + { .compatible = "mediatek,mt8183-dpi",
> > > +   .data = &mt8183_conf,
> > > + },
> > >   { },
> > >  };
> > >  
> > 
> > 
> 
> 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH libdrm] tests/amdgpu: add dispatch test

[Zhang, Hawking]

Although the shader is simple enough, please work with CQE to test it on all 
gfx9 ASICs before push it.

The patch is Reviewed-by: Hawking Zhang 

Regards,
Hawking
-Original Message-
From: amd-gfx  On Behalf Of Cui, Flora
Sent: 2019年2月18日 12:56
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Cui, Flora 
Subject: [PATCH libdrm] tests/amdgpu: add dispatch test

From: Flora Cui 

Change-Id: I6f5dfa4379cb21c41c68757fae0105527a03e54f
Signed-off-by: Flora Cui 
---
 tests/amdgpu/basic_tests.c | 175 -
 1 file changed, 173 insertions(+), 2 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c index 
d79859a..649c5a4 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -49,6 +49,7 @@ static void amdgpu_userptr_test(void);  static void 
amdgpu_semaphore_test(void);  static void amdgpu_sync_dependency_test(void);
 static void amdgpu_bo_eviction_test(void);
+static void amdgpu_memset_dispatch_test(void);
 static void amdgpu_direct_gma_test(void);
 
 static void amdgpu_command_submission_write_linear_helper(unsigned ip_type); 
@@ -71,6 +72,7 @@ CU_TestInfo basic_tests[] = {
{ "Command submission Test (SDMA)", amdgpu_command_submission_sdma },
{ "SW semaphore Test",  amdgpu_semaphore_test },
{ "Sync dependency Test",  amdgpu_sync_dependency_test },
+   { "Memset dispatch Test",  amdgpu_memset_dispatch_test },
{ "Direct GMA", amdgpu_direct_gma_test },
CU_TEST_INFO_NULL,
 };
@@ -119,6 +121,7 @@ CU_TestInfo basic_tests[] = {
 #define PACKET3(op, n) ((PACKET_TYPE3 << 30) | \
 (((op) & 0xFF) << 8) | \
 ((n) & 0x3FFF) << 16)
+#define PACKET3_COMPUTE(op, n) PACKET3(op, n) | (1 << 1)
 
 /* Packet 3 types */
 #definePACKET3_NOP 0x10
@@ -247,8 +250,8 @@ CU_TestInfo basic_tests[] = {
 #definePACKET3_SET_SH_REG_START
0x2c00
 
 #definePACKET3_DISPATCH_DIRECT 0x15
-
-
+#define PACKET3_EVENT_WRITE0x46
+#define PACKET3_ACQUIRE_MEM0x58
 /* gfx 8 */
 #define mmCOMPUTE_PGM_LO   
 0x2e0c
 #define mmCOMPUTE_PGM_RSRC1
 0x2e12
@@ -1945,6 +1948,174 @@ static void amdgpu_sync_dependency_test(void)
free(ibs_request.dependencies);
 }
 
+static const uint32_t bufferclear_cs_shader_gfx9[] = {
+0xD1FD, 0x04010C08, 0x7E020204, 0x7E040205,
+0x7E060206, 0x7E080207, 0xE01C2000, 0x8100,
+0xBF81
+};
+static const uint32_t bufferclear_cs_shader_registers_gfx9[][2] = {
+   {0x2e12, 0x000C0041},   //{ mmCOMPUTE_PGM_RSRC1,  0x000C0041 },
+   {0x2e13, 0x0090},   //{ mmCOMPUTE_PGM_RSRC2,  0x0090 },
+   {0x2e07, 0x0040},   //{ mmCOMPUTE_NUM_THREAD_X, 0x0040 },
+   {0x2e08, 0x0001},   //{ mmCOMPUTE_NUM_THREAD_Y, 0x0001 },
+   {0x2e09, 0x0001},   //{ mmCOMPUTE_NUM_THREAD_Z, 0x0001 }
+};
+static void amdgpu_memset_dispatch_gfx_test_gfx9()
+{
+   amdgpu_context_handle context_handle;
+   amdgpu_bo_handle bo_dst, bo_shader, resources[2];
+   volatile unsigned char *ptr_dst;
+   void *ptr_shader;
+   uint64_t mc_address_dst, mc_address_shader;
+   amdgpu_va_handle va_dst, va_shader;
+   int i, j, r;
+   uint32_t *ptr;
+   int bo_dst_size = 16384;
+   struct amdgpu_cs_request ibs_request;
+   struct amdgpu_cs_ib_info ib_info;
+
+   ptr = calloc(256, sizeof(*ptr));
+   CU_ASSERT_NOT_EQUAL(ptr, NULL);
+   memset(ptr, 0, 256);
+
+   r = amdgpu_cs_ctx_create(device_handle, &context_handle);
+   CU_ASSERT_EQUAL(r, 0);
+
+   r = amdgpu_bo_alloc_and_map(device_handle, 4096, 4096,
+   AMDGPU_GEM_DOMAIN_VRAM, 0,
+   &bo_shader, &ptr_shader,
+   &mc_address_shader, &va_shader);
+   CU_ASSERT_EQUAL(r, 0);
+
+   r = amdgpu_bo_alloc_and_map(device_handle, bo_dst_size, 4096,
+   AMDGPU_GEM_DOMAIN_VRAM, 0,
+   &bo_dst, &ptr_dst,
+   &mc_address_dst, &va_dst);
+   CU_ASSERT_EQUAL(r, 0);
+
+   memcpy(ptr_shader, bufferclear_cs_shader_gfx9, 
+sizeof(bufferclear_cs_shader_gfx9));
+
+   i = 0;
+   ptr[i++] = PACKET3(PKT3_CONTEXT_CONTROL, 1);
+   ptr[i++] = 0x8000;
+   ptr[i++] = 0x8000;
+
+   /* Issue commands to set default compute state. */
+   /* clear mmCOMPUTE_START_Z - mmCOMPUTE_START_X */
+   ptr[i++] = PACKET3_COMPUTE(PKT3_SET_SH_REG, 3);
+   ptr[i++] = 0x204;
+   ptr[i++] = 0;
+   ptr[i++] = 0;
+   p

Re: [PATCH] drm/mediatek: add mt8183 dpi support

[Jitao Shi]

On Fri, 2019-02-15 at 00:13 +0800, CK Hu wrote:
> Hi, Jitao:
> 
> On Mon, 2019-02-11 at 12:50 +0800, Jitao Shi wrote:
> > MT8183 sample on rising and falling edge. It can reduce half data io.
> > 
> > Signed-off-by: Jitao Shi 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dpi.c | 29 +
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index 62a9d47df948..610c23334047 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -117,6 +117,7 @@ struct mtk_dpi_conf {
> > unsigned int (*cal_factor)(int clock);
> > u32 reg_h_fre_con;
> > bool edge_sel_en;
> > +   bool dual_edge;
> >  };
> >  
> >  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 
> > mask)
> > @@ -353,6 +354,13 @@ static void mtk_dpi_config_disable_edge(struct mtk_dpi 
> > *dpi)
> > mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
> >  }
> >  
> > +static void mtk_dpi_enable_dual_edge(struct mtk_dpi *dpi)
> > +{
> > +   mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
> > +DDR_EN | DDR_4PHASE);
> > +   mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, EDGE_SEL, EDGE_SEL);
> > +}
> 
> All these register exist in MT8173, if you do the same setting in
> MT8173, could it also sample on rising edge and falling edge?
> 
> Regards,
> CK

Hi CK,

MT8173 has those registers. But the hw function is removed.
So MT8173 doesn't support DPI dual edge sample.

Best Regards
Jitao

> 
> > +
> >  static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
> > enum mtk_dpi_out_color_format format)
> >  {
> > @@ -509,6 +517,8 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> > mtk_dpi_config_color_format(dpi, dpi->color_format);
> > mtk_dpi_config_2n_h_fre(dpi);
> > mtk_dpi_config_disable_edge(dpi);
> > +   if (dpi->conf->dual_edge)
> > +   mtk_dpi_enable_dual_edge(dpi);
> > mtk_dpi_sw_reset(dpi, false);
> >  
> > return 0;
> > @@ -671,6 +681,16 @@ static unsigned int mt2701_calculate_factor(int clock)
> > return 2;
> >  }
> >  
> > +static unsigned int mt8183_calculate_factor(int clock)
> > +{
> > +   if (clock <= 27000)
> > +   return 8;
> > +   else if (clock <= 167000)
> > +   return 4;
> > +   else
> > +   return 2;
> > +}
> > +
> >  static const struct mtk_dpi_conf mt8173_conf = {
> > .cal_factor = mt8173_calculate_factor,
> > .reg_h_fre_con = 0xe0,
> > @@ -682,6 +702,12 @@ static const struct mtk_dpi_conf mt2701_conf = {
> > .edge_sel_en = true,
> >  };
> >  
> > +static const struct mtk_dpi_conf mt8183_conf = {
> > +   .cal_factor = mt8183_calculate_factor,
> > +   .reg_h_fre_con = 0xe0,
> > +   .dual_edge = true,
> > +};
> > +
> >  static int mtk_dpi_probe(struct platform_device *pdev)
> >  {
> > struct device *dev = &pdev->dev;
> > @@ -777,6 +803,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
> > { .compatible = "mediatek,mt8173-dpi",
> >   .data = &mt8173_conf,
> > },
> > +   { .compatible = "mediatek,mt8183-dpi",
> > + .data = &mt8183_conf,
> > +   },
> > { },
> >  };
> >  
> 
> 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105251

--- Comment #65 from zzyx...@gmail.com ---
I've just tested the vega_crasher on the latest kernel from the
linux-amd-staging-drm-next-git package (archlinux) and it didn't crash.

% uname -a
Linux erebor 5.0.0-rc1-amd-staging-drm-next-git-b8cd95e15410+ #1 SMP PREEMPT
Sat Feb 16 02:30:22 PST 2019 x86_64 GNU/Linux

That said, I'm still experiencing random crashes. I'll try and and get a debug
dump next time it happens, but it looks a lot like what is described on this
thread:
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1049483-amd-devs-error-ring-gfx-timeout

-- 
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 v4 7/7] media: vsp1: Provide a writeback video device

[Laurent Pinchart]

Hi Kieran,

On Sun, Feb 17, 2019 at 08:06:32PM +, Kieran Bingham wrote:
> On 17/02/2019 02:48, Laurent Pinchart wrote:
> > From: Kieran Bingham 
> > 
> > When the VSP1 is used in an active display pipeline, the output of the
> > WPF can supply the LIF entity directly and simultaneously write to
> > memory.
> > 
> > Support this functionality in the VSP1 driver through a V4L2 video
> > device node connected to the WPF.
> > 
> > The writeback video node support RGB formats only due to the WPF
> > outputting RGB to the LIF. The pixel format can otherwise be configured
> > freely.
> > 
> > The resolution of the captured frames are set by the display mode. A
> > different resolution can be selected on the video node, in which case
> > cropping or composing will be performed.
> > 
> > Signed-off-by: Kieran Bingham 
> > Signed-off-by: Laurent Pinchart 
> 
> For your changes,
> 
> With the documentation updated for vsp1_dl_body_write_patch(),
> 
> Reviewed-by: Kieran Bingham 
> 
> > ---
> > Changes since v3:
> > 
> > - Infer has_writeback from the number of LIFs and the generation
> > - Remove vsp1_video::is_writeback
> > - Describe writeback video nodes as 'writeback'
> > - Add mechanism to patch active display lists
> > - Handle writeback format restrictions
> > - Don't wait for next page flip before completing writeback buffer
> 
> This is a nice addition.

Thank you. It was the hard part :)

> > - Periods at the end of sentences.
> 
> You also fix writeback for the bitrot that the previous sets had now
> that we have partition handling.
> 
> Interestingly my local implementation for this bitrot was just to
> allocate a table for a single partition. I like your implementation
> better :)

Thank you.

> > Changes since v2:
> >  - Rebased to v4.12-rc1
> > 
> > Changes since RFC
> >  - Fix checkpatch.pl warnings
> >  - Adapt to use a single source pad for the Writeback and LIF
> >  - Use WPF properties to determine when to create links instead of VSP
> >  - Remove incorrect vsp1_video_verify_format() changes
> >  - Spelling and grammar fixes
> > ---
> >  drivers/media/platform/vsp1/vsp1_dl.c|  83 +
> >  drivers/media/platform/vsp1/vsp1_dl.h|   4 +
> >  drivers/media/platform/vsp1/vsp1_drm.c   |  14 ++-
> >  drivers/media/platform/vsp1/vsp1_drv.c   |  17 ++-
> >  drivers/media/platform/vsp1/vsp1_pipe.c  |   5 +
> >  drivers/media/platform/vsp1/vsp1_pipe.h  |   6 +
> >  drivers/media/platform/vsp1/vsp1_rwpf.h  |   2 +
> >  drivers/media/platform/vsp1/vsp1_video.c | 150 +--
> >  drivers/media/platform/vsp1/vsp1_video.h |   6 +
> >  drivers/media/platform/vsp1/vsp1_wpf.c   |  49 ++--
> >  10 files changed, 318 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
> > b/drivers/media/platform/vsp1/vsp1_dl.c
> > index 886b3a69d329..591544382946 100644
> > --- a/drivers/media/platform/vsp1/vsp1_dl.c
> > +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> > @@ -115,6 +115,12 @@ struct vsp1_dl_body {
> >  
> > unsigned int num_entries;
> > unsigned int max_entries;
> > +
> > +   unsigned int num_patches;
> > +   struct {
> > +   struct vsp1_dl_entry *entry;
> > +   u32 data;
> > +   } patches[2];
> 
> What's the significance of [2] ?
> Perhaps it will be clear what two entry's support patching later...
> 
> Ok - yes - it's to patch both the Writeback enable and the display start
> enable.

Yes, we only need two registers. This is a bit of a hack, I'd like to
come up with a better API, but making it generic will be unneedingly
costly.

> >  };
> >  
> >  /**
> > @@ -361,6 +367,7 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
> > return;
> >  
> > dlb->num_entries = 0;
> > +   dlb->num_patches = 0;
> >  
> > spin_lock_irqsave(&dlb->pool->lock, flags);
> > list_add_tail(&dlb->free, &dlb->pool->free);
> > @@ -388,6 +395,37 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 
> > reg, u32 data)
> > dlb->num_entries++;
> >  }
> >  
> > +/**
> > + * vsp1_dl_body_write - Write a register to a display list body
> 
> s/_write/_write_patch/

Oops. I forgot to update the documentation :-/

> "Store an update to an existing register for handling at display-start
> interrupt"? (or as you see fit)

The function writes a register and stores the update. I'll fix the
documentation.

/**
 * vsp1_dl_body_write_patch - Write a register to a display list body with an
 *  update for the next vblank
 * @dlb: The body
 * @reg: The register address
 * @data: The register value
 * @patch: The register value for the next vblank
 *
 * Display lists in continuous mode are re-used by the hardware for successive
 * frames until a new display list is committed. Changing the VSP configuration
 * normally requires creating and committing a new display list. This function
 * offers an alternative race-free way by writing a @value to the @register in
 * the display list body, along with an updated @patch value to

[PATCH v2 3/3] drm/panel: simple: Add support for VXT VL050-8048NT-C01 panel

[Fabio Estevam]

Add support for the VXT VL050-8048NT-C01 800x480 panel to the
panel-simple driver. 

This panel is used on some boards manufactured by TechNexion, such as
imx7d-pico.

Reviewed-by: Otavio Salvador 
Reviewed-by: Sam Ravnborg 
Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Pass .flags and .bus_flags (Sam)

 drivers/gpu/drm/panel/panel-simple.c | 29 
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9c69e739a524..737cbf3aee11 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2434,6 +2434,32 @@ static const struct panel_desc urt_umsh_8596md_parallel 
= {
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
 };
 
+static const struct drm_display_mode vl050_8048nt_c01_mode = {
+   .clock = 3,
+   .hdisplay = 800,
+   .hsync_start = 800 + 210,
+   .hsync_end = 800 + 210 + 20,
+   .htotal = 800 + 210 + 20 + 46,
+   .vdisplay =  480,
+   .vsync_start = 480 + 22,
+   .vsync_end = 480 + 22 + 10,
+   .vtotal = 480 + 22 + 10 + 23,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc vl050_8048nt_c01 = {
+   .modes = &vl050_8048nt_c01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 120,
+   .height = 76,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
 static const struct drm_display_mode winstar_wf35ltiacd_mode = {
.clock = 6410,
.hdisplay = 320,
@@ -2751,6 +2777,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "urt,umsh-8596md-20t",
.data = &urt_umsh_8596md_parallel,
+   }, {
+   .compatible = "vxt,vl050-8048nt-c01",
+   .data = &vl050_8048nt_c01,
}, {
.compatible = "winstar,wf35ltiacd",
.data = &winstar_wf35ltiacd,
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/3] dt-bindings: Add VXT VL050-8048NT-C01 panel bindings

[Fabio Estevam]

The VXT VL050-8048NT-C01 is a TFT LCD panel with a 800x480 resolution
connected via 24 width parallel interface.

Reviewed-by: Otavio Salvador 
Reviewed-by: Rob Herring 
---
Changes since v1:
- None

 .../bindings/display/panel/vl050_8048nt_c01.txt  | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt 
b/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt
new file mode 100644
index ..b42bf06bbd99
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt
@@ -0,0 +1,12 @@
+VXT 800x480 color TFT LCD panel
+
+Required properties:
+- compatible: should be "vxt,vl050-8048nt-c01"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+- enable-gpios: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/3] dt-bindings: Add vendor prefix for VXT Ltd

[Fabio Estevam]

VXT Ltd is a manufacturer of projected capacitive touch panel
and display solutions: http://www.vxt.com.tw/

Reviewed-by: Otavio Salvador 
Reviewed-by: Rob Herring 
Signed-off-by: Fabio Estevam 
---
Changes since v1:
- None

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 389508584f48..096ad1857692 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -427,6 +427,7 @@ vivante Vivante Corporation
 vocore VoCore Studio
 voipac Voipac Technologies s.r.o.
 votVision Optical Technology Co., Ltd.
+vxtVXT Ltd
 wd Western Digital Corp.
 wetek  WeTek Electronics, limited.
 wexler Wexler
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 5/7] media: vsp1: Refactor vsp1_video_complete_buffer() for later reuse

[Laurent Pinchart]

Hi Kieran,

On Sun, Feb 17, 2019 at 08:35:25PM +, Kieran Bingham wrote:
> On 17/02/2019 02:48, Laurent Pinchart wrote:
> > The vsp1_video_complete_buffer() function completes the current buffer
> > and returns a pointer to the next buffer. Split the code that completes
> > the buffer to a separate function for later reuse, and rename
> > vsp1_video_complete_buffer() to vsp1_video_complete_next_buffer().
> > 
> > Signed-off-by: Laurent Pinchart 
> 
> This looks good to me - except perhaps the documentation /might/ need
> some refresh. With or without updates there, the code changes look good
> to me:
> 
> Reviewed-by: Kieran Bingham 
> 
> > ---
> >  drivers/media/platform/vsp1/vsp1_video.c | 35 ++--
> >  1 file changed, 20 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
> > b/drivers/media/platform/vsp1/vsp1_video.c
> > index 328d686189be..cfbab16c4820 100644
> > --- a/drivers/media/platform/vsp1/vsp1_video.c
> > +++ b/drivers/media/platform/vsp1/vsp1_video.c
> > @@ -300,8 +300,22 @@ static int vsp1_video_pipeline_setup_partitions(struct 
> > vsp1_pipeline *pipe)
> >   * Pipeline Management
> >   */
> >  
> > +static void vsp1_video_complete_buffer(struct vsp1_video *video,
> > +  struct vsp1_vb2_buffer *buffer)
> > +{
> > +   struct vsp1_pipeline *pipe = video->rwpf->entity.pipe;
> > +   unsigned int i;
> > +
> > +   buffer->buf.sequence = pipe->sequence;
> > +   buffer->buf.vb2_buf.timestamp = ktime_get_ns();
> > +   for (i = 0; i < buffer->buf.vb2_buf.num_planes; ++i)
> > +   vb2_set_plane_payload(&buffer->buf.vb2_buf, i,
> > + vb2_plane_size(&buffer->buf.vb2_buf, i));
> > +   vb2_buffer_done(&buffer->buf.vb2_buf, VB2_BUF_STATE_DONE);
> > +}
> > +
> >  /*
> > - * vsp1_video_complete_buffer - Complete the current buffer
> > + * vsp1_video_complete_next_buffer - Complete the current buffer
> 
> Should the brief be updated?
> It looks quite odd to call the function "complete next buffer" but with
> a brief saying "complete the current buffer".
> 
> Technically it's still correct, but it's more like
> "Complete the current buffer and return the next buffer"
> or such.

Good point. I'll update the brief to that.

> >   * @video: the video node
> >   *
> >   * This function completes the current buffer by filling its sequence 
> > number,
> 
> Is this still accurate enough to keep the text as is ?

It's still true, isn't it ?

> > @@ -310,13 +324,11 @@ static int 
> > vsp1_video_pipeline_setup_partitions(struct vsp1_pipeline *pipe)
> >   * Return the next queued buffer or NULL if the queue is empty.
> >   */
> >  static struct vsp1_vb2_buffer *
> > -vsp1_video_complete_buffer(struct vsp1_video *video)
> > +vsp1_video_complete_next_buffer(struct vsp1_video *video)
> >  {
> > -   struct vsp1_pipeline *pipe = video->rwpf->entity.pipe;
> > -   struct vsp1_vb2_buffer *next = NULL;
> > +   struct vsp1_vb2_buffer *next;
> > struct vsp1_vb2_buffer *done;
> > unsigned long flags;
> > -   unsigned int i;
> >  
> > spin_lock_irqsave(&video->irqlock, flags);
> >  
> > @@ -327,21 +339,14 @@ vsp1_video_complete_buffer(struct vsp1_video *video)
> >  
> > done = list_first_entry(&video->irqqueue,
> > struct vsp1_vb2_buffer, queue);
> > -
> > list_del(&done->queue);
> >  
> > -   if (!list_empty(&video->irqqueue))
> > -   next = list_first_entry(&video->irqqueue,
> > +   next = list_first_entry_or_null(&video->irqqueue,
> 
> That's a nice way to save a line.
> 
> > struct vsp1_vb2_buffer, queue);
> >  
> > spin_unlock_irqrestore(&video->irqlock, flags);
> >  
> > -   done->buf.sequence = pipe->sequence;
> > -   done->buf.vb2_buf.timestamp = ktime_get_ns();
> > -   for (i = 0; i < done->buf.vb2_buf.num_planes; ++i)
> > -   vb2_set_plane_payload(&done->buf.vb2_buf, i,
> > - vb2_plane_size(&done->buf.vb2_buf, i));
> > -   vb2_buffer_done(&done->buf.vb2_buf, VB2_BUF_STATE_DONE);
> > +   vsp1_video_complete_buffer(video, done);
> >  
> > return next;
> >  }
> > @@ -352,7 +357,7 @@ static void vsp1_video_frame_end(struct vsp1_pipeline 
> > *pipe,
> > struct vsp1_video *video = rwpf->video;
> > struct vsp1_vb2_buffer *buf;
> >  
> > -   buf = vsp1_video_complete_buffer(video);
> > +   buf = vsp1_video_complete_next_buffer(video);
> > if (buf == NULL)
> > return;
> >  

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108711] GPU crash in some opengl 1.x applications on vega gpu

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108711

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Timothy Arceri  ---
(In reply to mittorn from comment #1)
> Re-uploaded traces here
> http://mittorn.the-swank.pp.ua/xash64.1.trace.xz
> http://mittorn.the-swank.pp.ua/xash64.trace.xz

I can't get these to crash. Tested with Mesa 19.1-devel on Radeon RX Vega
(VEGA10, DRM 3.27.0, 4.20.8-200.fc29.x86_64, LLVM 9.0.0-devel).

Is this still and issue for you? Are you able to get a stack trace from the
crash?

-- 
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 v4 2/7] media: vsp1: wpf: Fix partition configuration for display pipelines

[Laurent Pinchart]

Hi Kieran,

On Sun, Feb 17, 2019 at 08:16:27PM +, Kieran Bingham wrote:
> On 17/02/2019 02:48, Laurent Pinchart wrote:
> > The WPF accesses partition configuration from pipe->partition in the
> > partition configuration that is not used for display pipelines.
> 
> That sentence is hard to read...

Indeed. I'll rewrite it.

> > Writeback support will require full configuration of the WPF while not
> > providing a valid pipe->partition. Rework the configuration code to fall
> > back to the full image width in that case, as is already done for the
> > part of the configuration currently relevant for display pipelines.
> > 
> 
> Ah yes - this is probably a better route than allocating a table for a
> single partition (which is what I had locally).
> 
> 
> > Signed-off-by: Laurent Pinchart 
> 
> I like that this change also simplifies the flip/rotate handling code to
> make that easier to read.
> 
> Reviewed-by: Kieran Bingham 
> 
> > ---
> >  drivers/media/platform/vsp1/vsp1_wpf.c | 16 +---
> >  1 file changed, 9 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
> > b/drivers/media/platform/vsp1/vsp1_wpf.c
> > index 32bb207b2007..a07c5944b598 100644
> > --- a/drivers/media/platform/vsp1/vsp1_wpf.c
> > +++ b/drivers/media/platform/vsp1/vsp1_wpf.c
> > @@ -362,6 +362,7 @@ static void wpf_configure_partition(struct vsp1_entity 
> > *entity,
> > const struct vsp1_format_info *fmtinfo = wpf->fmtinfo;
> > unsigned int width;
> > unsigned int height;
> > +   unsigned int left;
> > unsigned int offset;
> > unsigned int flip;
> > unsigned int i;
> > @@ -371,13 +372,16 @@ static void wpf_configure_partition(struct 
> > vsp1_entity *entity,
> >  RWPF_PAD_SINK);
> > width = sink_format->width;
> > height = sink_format->height;
> > +   left = 0;
> >  
> > /*
> >  * Cropping. The partition algorithm can split the image into
> >  * multiple slices.
> >  */
> > -   if (pipe->partitions > 1)
> > +   if (pipe->partitions > 1) {
> > width = pipe->partition->wpf.width;
> > +   left = pipe->partition->wpf.left;
> > +   }
> >  
> > vsp1_wpf_write(wpf, dlb, VI6_WPF_HSZCLIP, VI6_WPF_SZCLIP_EN |
> >(0 << VI6_WPF_SZCLIP_OFST_SHIFT) |
> > @@ -408,13 +412,11 @@ static void wpf_configure_partition(struct 
> > vsp1_entity *entity,
> > flip = wpf->flip.active;
> >  
> > if (flip & BIT(WPF_CTRL_HFLIP) && !wpf->flip.rotate)
> > -   offset = format->width - pipe->partition->wpf.left
> > -   - pipe->partition->wpf.width;
> > +   offset = format->width - left - width;
> > else if (flip & BIT(WPF_CTRL_VFLIP) && wpf->flip.rotate)
> > -   offset = format->height - pipe->partition->wpf.left
> > -   - pipe->partition->wpf.width;
> > +   offset = format->height - left - width;
> > else
> > -   offset = pipe->partition->wpf.left;
> > +   offset = left;
> 
> This hunk looks a lot simpler :)
> 
> 
> >  
> > for (i = 0; i < format->num_planes; ++i) {
> > unsigned int hsub = i > 0 ? fmtinfo->hsub : 1;
> > @@ -436,7 +438,7 @@ static void wpf_configure_partition(struct vsp1_entity 
> > *entity,
> >  * image height.
> >  */
> > if (wpf->flip.rotate)
> > -   height = pipe->partition->wpf.width;
> > +   height = width;
> > else
> > height = format->height;
> >  
> > 
> 
> -- 
> Regards
> --
> Kieran

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/7] VSP1: Display writeback support

[Laurent Pinchart]

Hi Brian,

On Mon, Feb 18, 2019 at 12:22:58PM +, Brian Starkey wrote:
> On Sun, Feb 17, 2019 at 04:48:45AM +0200, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series implements display writeback support for the R-Car
> > Gen3 platforms in the VSP1 driver.
> > 
> > DRM/KMS provides a writeback API through a special type of writeback
> > connectors. This series takes a different approach by exposing writeback
> > as a V4L2 device. While there is nothing fundamentally wrong with
> > writeback connectors, display for R-Car Gen3 platforms relies on the
> > VSP1 driver behind the scene, which already implements V4L2 support.
> > Enabling writeback through V4L2 is thus significantly easier in this
> > case.
> 
> How does this look to an application? (I'm entirely ignorant about
> R-Car). They are interacting with the DRM device, and then need to
> open and configure a v4l2 device to get the writeback? Can the process
> which isn't controlling the DRM device independently capture the
> screen output?

It can. The V4L2 capture device is independently controlled, and doesn't
affect the DRM/KMS device. The only dependency is that the V4L2 device
will only provide frames on atomic commit, a blocking VIDIOC_DQBUF or a
select()/poll() call will block until the atomic commit.

> I didn't see any major complication to implementing this as a
> writeback connector. If you want/need to use the vb2_queue, couldn't
> you just do that entirely from within the kernel?

In theory yes, in practice possibly, but with a higher complexity. I
didn't go for V4L2 to avoid writeback connectors, but because the
infrastructure was there already in the VSP driver.

> Honestly (predictably?), to me it seems like a bad idea to introduce a
> second, non-compatible interface for display writeback. Any
> application interested in display writeback (e.g. compositors) will
> need to implement both in order to support all HW. drm_hwcomposer
> already supports writeback via DRM writeback connectors.
> 
> While I can see the advantages of having writeback exposed via v4l2
> for streaming use-cases, I think it would be better to have it done in
> such a way that it works for all writeback connectors, rather than
> being VSP1-specific. That would allow any application to choose
> whichever method is most appropriate for their use-case, without
> limiting themselves to a subset of hardware.

I get your point. There's no much use arguing, as I believe you're right
:-) I'll give this another shot using writeback connectors.

> > The writeback pixel format is restricted to RGB, due to the VSP1
> > outputting RGB to the display and lacking a separate colour space
> > conversion unit for writeback. The resolution can be freely picked by
> > will result in cropping or composing, not scaling.
> > 
> > Writeback requests are queued to the hardware on page flip (atomic
> > flush), and complete at the next vblank. This means that a queued
> > writeback buffer will not be processed until the next page flip, but
> > once it starts being written to by the VSP, it will complete at the next
> > vblank regardless of whether another page flip occurs at that time.
> 
> This sounds the same as mali-dp, and so fits directly with the
> semantics of writeback connectors.
> 
> > The code is based on a merge of the media master branch, the drm-next
> > branch and the R-Car DT next branch. For convenience patches can be
> > found at
> > 
> > git://linuxtv.org/pinchartl/media.git v4l2/vsp1/writeback
> > 
> > Kieran Bingham (2):
> >   Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
> >   media: vsp1: Provide a writeback video device
> > 
> > Laurent Pinchart (5):
> >   media: vsp1: wpf: Fix partition configuration for display pipelines
> >   media: vsp1: Replace leftover occurrence of fragment with body
> >   media: vsp1: Fix addresses of display-related registers for VSP-DL
> >   media: vsp1: Refactor vsp1_video_complete_buffer() for later reuse
> >   media: vsp1: Replace the display list internal flag with a flags field
> > 
> >  drivers/media/platform/vsp1/vsp1_dl.c| 118 --
> >  drivers/media/platform/vsp1/vsp1_dl.h|   6 +-
> >  drivers/media/platform/vsp1/vsp1_drm.c   |  24 ++-
> >  drivers/media/platform/vsp1/vsp1_drv.c   |  17 +-
> >  drivers/media/platform/vsp1/vsp1_pipe.c  |   5 +
> >  drivers/media/platform/vsp1/vsp1_pipe.h  |   6 +
> >  drivers/media/platform/vsp1/vsp1_regs.h  |   6 +-
> >  drivers/media/platform/vsp1/vsp1_rwpf.h  |   2 +
> >  drivers/media/platform/vsp1/vsp1_video.c | 198 +++
> >  drivers/media/platform/vsp1/vsp1_video.h |   6 +
> >  drivers/media/platform/vsp1/vsp1_wpf.c   |  65 ++--
> >  11 files changed, 378 insertions(+), 75 deletions(-)

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu/powerplay/polaris10_smumgr: Mark expected switch fall-through

[Gustavo A. R. Silva]

On 2/18/19 4:40 PM, Alex Deucher wrote:
> On Fri, Feb 15, 2019 at 1:50 PM Gustavo A. R. Silva
>  wrote:
>>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> This patch is part of the ongoing efforts to enable
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva 
>> ---
>>  drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c 
>> b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
>> index 52abca065764..92de1bbb2e33 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
>> @@ -2330,6 +2330,7 @@ static uint32_t polaris10_get_offsetof(uint32_t type, 
>> uint32_t member)
>> case DRAM_LOG_BUFF_SIZE:
>> return offsetof(SMU74_SoftRegisters, 
>> DRAM_LOG_BUFF_SIZE);
>> }
>> +   /* fall through */
> 
> These should be breaks, although I don't think we ever currently hit
> this case.  I've sent out a patch to fix it and applied the rest of
> the radeon and amdgpu patches.  Thanks!
> 

Awesome!

Thanks, Alex.

--
Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu/powerplay/polaris10_smumgr: Mark expected switch fall-through

[Alex Deucher]

On Fri, Feb 15, 2019 at 1:50 PM Gustavo A. R. Silva
 wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> index 52abca065764..92de1bbb2e33 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> @@ -2330,6 +2330,7 @@ static uint32_t polaris10_get_offsetof(uint32_t type, 
> uint32_t member)
> case DRAM_LOG_BUFF_SIZE:
> return offsetof(SMU74_SoftRegisters, 
> DRAM_LOG_BUFF_SIZE);
> }
> +   /* fall through */

These should be breaks, although I don't think we ever currently hit
this case.  I've sent out a patch to fix it and applied the rest of
the radeon and amdgpu patches.  Thanks!

Alex

> case SMU_Discrete_DpmTable:
> switch (member) {
> case UvdBootLevel:
> --
> 2.20.1
>
> ___
> 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

[Bug 202537] amdgpu/DC failed to reserve new abo buffer before flip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=202537

--- Comment #21 from Bernd Steinhauser (li...@bernd-steinhauser.de) ---
Created attachment 281201
  --> https://bugzilla.kernel.org/attachment.cgi?id=281201&action=edit
kmemleak output with 4.19.0-rc1 5d35ed4832da

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 202537] amdgpu/DC failed to reserve new abo buffer before flip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=202537

--- Comment #20 from Bernd Steinhauser (li...@bernd-steinhauser.de) ---
(In reply to Christian König from comment #17)
> We completely disabled the feature added in "5d35ed4832d" for upstreaming
> later on.
> 
> Can you guys please test amd-staging-drm-next as well and check if the
> problem occurs there as well. If not then please bisect what fixed it.
Would've been nice to point me to the corresponding repo as well.
Don't worry, I've figured it out, but still would've been nice.
In any case, current HEAD of amd-staging-drm-next looks good to me, I can't
reproduce the memleaks with that one.

I'll try to find the fix, but that'll take me 2-3 days.

(In reply to Paul Menzel from comment #18)
> Bernd, if you have time, it’d be great, if you listed the commits here,
> which you needed to apply on top to fix the other regressions.
Most importantly 9d27e39d309c93025ae6aa97236af15bef2a5f1f, which says it's for
Carrizo, but it seems to affect my Kaveri as well, which wouldn't be surprising
since the two are related.
But on your Ryzen(?) system, this one might not be necessary.
I also applied 03651735fbded39f608163718f816ab9cf14fba7 on top for a wider
range of commits after 972a21f94631642d6714bb2a1983b7b15a77526d since otherwise
the system would freeze very quickly.
But even with that one applied the mentioned id above is very unstable and I
have only about 1min or so to do my tests.
Still that was enough time to do the tests at least twice and show that there
is the same flood of memory leaks with pretty much the same function sequences.

(In reply to Christian König from comment #19)
> 
> Commit 5d35ed4832d is a bug fix for bulk moves, which is a feature which
> should be completely disabled in 4.20. So your bisecting is most likely
> incorrect.
> 
Well, as I said, I'm not 100% sure, because I had to apply two patches to be
even able to test.
But I've repeated my tests with those two versions earlier on and came to the
same result.
b995795bf09b6bb7847a2a9fc8e6b5b4ab0ce20c does show exactly 6 memleaks to me and
those are the 2 acpi ones I mentioned above and 4 showing hid function
sequences, but nothing with drm or similar.
One commit later (5d35ed4832d) with the same two patches applied it's a
different story and I get 60 or more memleaks listed, which you have to admit
look an awful lot similar to what I've posted for 5.0-rc1 above (I'll upload
the log in a minute).
Now that could be pure coincidence, but I would be surprised if it was.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/evergreen_cs: fix missing break in switch statement

[Alex Deucher]

On Fri, Feb 15, 2019 at 5:40 PM Gustavo A. R. Silva
 wrote:
>
> Add missing break statement in order to prevent the code from falling
> through to case CB_TARGET_MASK.
>
> This bug was found thanks to the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Fixes: dd220a00e8bd ("drm/radeon/kms: add support for streamout v7")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 
> ---
> NOTE: Notice that this code has been out there since 2012. So, it
> would be helpful if someone can double-check this.

Applied.  thanks!

Alex

>
>  drivers/gpu/drm/radeon/evergreen_cs.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index f471537c852f..1e14c6921454 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -1299,6 +1299,7 @@ static int evergreen_cs_handle_reg(struct 
> radeon_cs_parser *p, u32 reg, u32 idx)
> return -EINVAL;
> }
> ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
> +   break;
> case CB_TARGET_MASK:
> track->cb_target_mask = radeon_get_ib_value(p, idx);
> track->cb_dirty = true;
> --
> 2.20.1
>
> ___
> 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] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

[Bjorn Helgaas]

On Mon, Feb 18, 2019 at 3:14 PM Sasha Levin  wrote:
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.20.8, v4.19.21, v4.14.99, 
> v4.9.156, v4.4.174, v3.18.134.
>
> v4.20.8: Build OK!
> v4.19.21: Failed to apply! Possible dependencies:
> 01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
>
> v4.14.99: Failed to apply! Possible dependencies:
> 01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
> 06dc4ee54e30 ("PCI: Disable MSI for Freescale Layerscape PCIe RC mode")
> 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
> 8948ca1a12c9 ("vga_switcheroo: Deduplicate power state tracking")
> ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")
>
> v4.9.156: Failed to apply! Possible dependencies:
> 01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
> 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
> 3e13676862f9 ("thunderbolt: Add support for DMA configuration based 
> mailbox")
> 46cd4b75cd0e ("efi: Add device path parser")
> 58c5475aba67 ("x86/efi: Retrieve and assign Apple device properties")
> 630b3aff8a51 ("treewide: Consolidate Apple DMI checks")
> 81a54b5e1986 ("thunderbolt: Let the connection manager handle all 
> notifications")
> 8948ca1a12c9 ("vga_switcheroo: Deduplicate power state tracking")
> 9d3cce0b6136 ("thunderbolt: Introduce thunderbolt bus and connection 
> manager")
> ac6c44de503e ("thunderbolt: Expose get_route() to other files")
> ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")
> bfe778ac4982 ("thunderbolt: Convert switch to a device")
> c9cc3aaa0281 ("thunderbolt: Use Device ROM retrieved from EFI")
> da2da04b8d44 ("thunderbolt: Rework capability handling")
> f67cf491175a ("thunderbolt: Add support for Internal Connection Manager 
> (ICM)")
> fa6d513aefe4 ("drivers:gpu: vga :vga_switcheroo.c : Fixed some coding 
> style issues")
>
> v4.4.174: Failed to apply! Possible dependencies:
> 01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
> 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
> 14d2000182ed ("drm/radeon: Defer probe if gmux is present but its driver 
> isn't")
> 156d7d4120e1 ("vga_switcheroo: Add handler flags infrastructure")
> 3a848662c751 ("vga_switcheroo: Prettify documentation")
> 412c8f7de011 ("drm/radeon: Return -EPROBE_DEFER when amdkfd not loaded")
> 704ab614ec12 ("drm/i915: Defer probe if gmux is present but its driver 
> isn't")
> 8948ca1a12c9 ("vga_switcheroo: Deduplicate power state tracking")
> 989561de9b51 ("PM / Domains: add setter for dev.pm_domain")
> 98b3a3402eb6 ("drm/nouveau: Defer probe if gmux is present but its driver 
> isn't")
> a345918d6ee6 ("vga_switcheroo: Support deferred probing of audio clients")
> ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")
> b00e5334ab1b ("vga_switcheroo: Add helper for deferred probing")
> b5f88dd1d6ef ("Revert "ACPI / LPSS: allow to use specific PM domain 
> during ->probe()"")
> c1e1655bb892 ("apple-gmux: Assign apple_gmux_data before registering")
> c68f4528a2e9 ("drm/amdkfd: Track when module's init is complete")
> fa6d513aefe4 ("drivers:gpu: vga :vga_switcheroo.c : Fixed some coding 
> style issues")
>
> v3.18.134: Failed to apply! Possible dependencies:
> 01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
> 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
> 083dba02947d ("drm/nouveau/device: recognise GM204")
> 2f4a58e852d1 ("drm/nouveau/subdev: always upcast through 
> nouveau_subdev()/nouveau_engine()")
> 4766ec53945f ("drm/nouveau/bios: add parsing of BIT M(v2) +0x03 table")
> 50e216d6e7c3 ("drm/nouveau/bios: add parsing of pmu image tables")
> 5444204036b2 ("drm/nouveau: switch to new-style timer macros")
> 7bb6d4428d3d ("drm/nouveau: move the (far too many...) different s/r 
> paths to the same place")
> 8d5e3af15c79 ("drm/nouveau/device: Add support for GK208B, resolves bug 
> 86935")
> 8d85e06b5e04 ("drm/nouveau/bios: add pci data structure parsing")
> 989aa5b76ad2 ("drm/nouveau/nvif: namespace of nvkm accessors (no binary 
> change)")
> a01ca78c8f11 ("drm/nouveau/nvif: simplify and tidy library interfaces")
> ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")
> ad4a36263535 ("drm/nouveau/bios: split out shadow methods")
> b71a1344ec20 ("drm/nouveau/bios: add NPDE parsing")
> ba6e34e61271 ("drm/gm204/devinit: initial implementation")
> be83cd4ef9a2 ("drm/nouveau: finalise nvkm namespace switch (no binary 
> change)")
> c39f472e9f14 ("drm/nouveau: remove symlinks, move core/ to nvkm/ (no c

[Bug 109667] r5 m330 hung if dpm enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109667

--- Comment #4 from Slava  ---
Created attachment 143402
  --> https://bugs.freedesktop.org/attachment.cgi?id=143402&action=edit
Xorg.log

-- 
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 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #28 from nmr  ---
I get that it's triggered by Mesa, but don't you think it's a bug itself that
user-space can hang the kernel? I can't even switch virtual consoles when it
hangs. 

I'm currently running Linux waldorf 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1
(2019-01-17) x86_64 GNU/Linux

I'll report back when I upgrade to 4.20

-- 
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 109667] r5 m330 hung if dpm enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109667

--- Comment #3 from Slava  ---
uh, lst dmesg get litle bit early, after few seconds there appeared such
strings

[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled
seq=431052, emitted seq=431053
amdgpu :01:00.0: GPU reset begin!

-- 
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 109667] r5 m330 hung if dpm enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109667

--- Comment #2 from Slava  ---
Created attachment 143398
  --> https://bugs.freedesktop.org/attachment.cgi?id=143398&action=edit
actualy after gpu reset dmesg get overflowed, so it is dmesg before reset

-- 
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 202533] DVI Monitors blank in 4.20-6 kernel

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=202533

--- Comment #8 from acollie...@gmail.com ---
Thanks for your patience. Figured out the error. For whatever reason, there was
a blacklist file in /etc/modprobe.d/ that was blacklisting the nouveau drivers.
4.20 recognized the blacklist while 4.19 did not. 

Thanks for your direction!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all

The bot has tested the following trees: v4.20.8, v4.19.21, v4.14.99, v4.9.156, 
v4.4.174, v3.18.134.

v4.20.8: Build OK!
v4.19.21: Failed to apply! Possible dependencies:
01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")

v4.14.99: Failed to apply! Possible dependencies:
01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
06dc4ee54e30 ("PCI: Disable MSI for Freescale Layerscape PCIe RC mode")
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
8948ca1a12c9 ("vga_switcheroo: Deduplicate power state tracking")
ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")

v4.9.156: Failed to apply! Possible dependencies:
01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
3e13676862f9 ("thunderbolt: Add support for DMA configuration based 
mailbox")
46cd4b75cd0e ("efi: Add device path parser")
58c5475aba67 ("x86/efi: Retrieve and assign Apple device properties")
630b3aff8a51 ("treewide: Consolidate Apple DMI checks")
81a54b5e1986 ("thunderbolt: Let the connection manager handle all 
notifications")
8948ca1a12c9 ("vga_switcheroo: Deduplicate power state tracking")
9d3cce0b6136 ("thunderbolt: Introduce thunderbolt bus and connection 
manager")
ac6c44de503e ("thunderbolt: Expose get_route() to other files")
ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")
bfe778ac4982 ("thunderbolt: Convert switch to a device")
c9cc3aaa0281 ("thunderbolt: Use Device ROM retrieved from EFI")
da2da04b8d44 ("thunderbolt: Rework capability handling")
f67cf491175a ("thunderbolt: Add support for Internal Connection Manager 
(ICM)")
fa6d513aefe4 ("drivers:gpu: vga :vga_switcheroo.c : Fixed some coding style 
issues")

v4.4.174: Failed to apply! Possible dependencies:
01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
14d2000182ed ("drm/radeon: Defer probe if gmux is present but its driver 
isn't")
156d7d4120e1 ("vga_switcheroo: Add handler flags infrastructure")
3a848662c751 ("vga_switcheroo: Prettify documentation")
412c8f7de011 ("drm/radeon: Return -EPROBE_DEFER when amdkfd not loaded")
704ab614ec12 ("drm/i915: Defer probe if gmux is present but its driver 
isn't")
8948ca1a12c9 ("vga_switcheroo: Deduplicate power state tracking")
989561de9b51 ("PM / Domains: add setter for dev.pm_domain")
98b3a3402eb6 ("drm/nouveau: Defer probe if gmux is present but its driver 
isn't")
a345918d6ee6 ("vga_switcheroo: Support deferred probing of audio clients")
ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")
b00e5334ab1b ("vga_switcheroo: Add helper for deferred probing")
b5f88dd1d6ef ("Revert "ACPI / LPSS: allow to use specific PM domain during 
->probe()"")
c1e1655bb892 ("apple-gmux: Assign apple_gmux_data before registering")
c68f4528a2e9 ("drm/amdkfd: Track when module's init is complete")
fa6d513aefe4 ("drivers:gpu: vga :vga_switcheroo.c : Fixed some coding style 
issues")

v3.18.134: Failed to apply! Possible dependencies:
01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
083dba02947d ("drm/nouveau/device: recognise GM204")
2f4a58e852d1 ("drm/nouveau/subdev: always upcast through 
nouveau_subdev()/nouveau_engine()")
4766ec53945f ("drm/nouveau/bios: add parsing of BIT M(v2) +0x03 table")
50e216d6e7c3 ("drm/nouveau/bios: add parsing of pmu image tables")
5444204036b2 ("drm/nouveau: switch to new-style timer macros")
7bb6d4428d3d ("drm/nouveau: move the (far too many...) different s/r paths 
to the same place")
8d5e3af15c79 ("drm/nouveau/device: Add support for GK208B, resolves bug 
86935")
8d85e06b5e04 ("drm/nouveau/bios: add pci data structure parsing")
989aa5b76ad2 ("drm/nouveau/nvif: namespace of nvkm accessors (no binary 
change)")
a01ca78c8f11 ("drm/nouveau/nvif: simplify and tidy library interfaces")
ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")
ad4a36263535 ("drm/nouveau/bios: split out shadow methods")
b71a1344ec20 ("drm/nouveau/bios: add NPDE parsing")
ba6e34e61271 ("drm/gm204/devinit: initial implementation")
be83cd4ef9a2 ("drm/nouveau: finalise nvkm namespace switch (no binary 
change)")
c39f472e9f14 ("drm/nouveau: remove symlinks, move core/ to nvkm/ (no code 
changes)")
cb8bb9cedb60 ("drm/nouveau/tmr: cosmetic changes")
d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
f3867f439fd6 ("drm/nouveau/clk: rename from clock (no binary change)")
f8a8546194d7 ("drm/nouveau

Re: [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all

The bot has tested the following trees: v4.20.8, v4.19.21, v4.14.99, v4.9.156, 
v4.4.174, v3.18.134.

v4.20.8: Build OK!
v4.19.21: Failed to apply! Possible dependencies:
01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")

v4.14.99: Failed to apply! Possible dependencies:
01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
06dc4ee54e30 ("PCI: Disable MSI for Freescale Layerscape PCIe RC mode")
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
8948ca1a12c9 ("vga_switcheroo: Deduplicate power state tracking")
ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")

v4.9.156: Failed to apply! Possible dependencies:
01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
3e13676862f9 ("thunderbolt: Add support for DMA configuration based 
mailbox")
46cd4b75cd0e ("efi: Add device path parser")
58c5475aba67 ("x86/efi: Retrieve and assign Apple device properties")
630b3aff8a51 ("treewide: Consolidate Apple DMI checks")
81a54b5e1986 ("thunderbolt: Let the connection manager handle all 
notifications")
8948ca1a12c9 ("vga_switcheroo: Deduplicate power state tracking")
9d3cce0b6136 ("thunderbolt: Introduce thunderbolt bus and connection 
manager")
ac6c44de503e ("thunderbolt: Expose get_route() to other files")
ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")
bfe778ac4982 ("thunderbolt: Convert switch to a device")
c9cc3aaa0281 ("thunderbolt: Use Device ROM retrieved from EFI")
da2da04b8d44 ("thunderbolt: Rework capability handling")
f67cf491175a ("thunderbolt: Add support for Internal Connection Manager 
(ICM)")
fa6d513aefe4 ("drivers:gpu: vga :vga_switcheroo.c : Fixed some coding style 
issues")

v4.4.174: Failed to apply! Possible dependencies:
01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
14d2000182ed ("drm/radeon: Defer probe if gmux is present but its driver 
isn't")
156d7d4120e1 ("vga_switcheroo: Add handler flags infrastructure")
3a848662c751 ("vga_switcheroo: Prettify documentation")
412c8f7de011 ("drm/radeon: Return -EPROBE_DEFER when amdkfd not loaded")
704ab614ec12 ("drm/i915: Defer probe if gmux is present but its driver 
isn't")
8948ca1a12c9 ("vga_switcheroo: Deduplicate power state tracking")
989561de9b51 ("PM / Domains: add setter for dev.pm_domain")
98b3a3402eb6 ("drm/nouveau: Defer probe if gmux is present but its driver 
isn't")
a345918d6ee6 ("vga_switcheroo: Support deferred probing of audio clients")
ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")
b00e5334ab1b ("vga_switcheroo: Add helper for deferred probing")
b5f88dd1d6ef ("Revert "ACPI / LPSS: allow to use specific PM domain during 
->probe()"")
c1e1655bb892 ("apple-gmux: Assign apple_gmux_data before registering")
c68f4528a2e9 ("drm/amdkfd: Track when module's init is complete")
fa6d513aefe4 ("drivers:gpu: vga :vga_switcheroo.c : Fixed some coding style 
issues")

v3.18.134: Failed to apply! Possible dependencies:
01d5d7fa8376 ("PCI: Add macro for Switchtec quirk declarations")
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
083dba02947d ("drm/nouveau/device: recognise GM204")
2f4a58e852d1 ("drm/nouveau/subdev: always upcast through 
nouveau_subdev()/nouveau_engine()")
4766ec53945f ("drm/nouveau/bios: add parsing of BIT M(v2) +0x03 table")
50e216d6e7c3 ("drm/nouveau/bios: add parsing of pmu image tables")
5444204036b2 ("drm/nouveau: switch to new-style timer macros")
7bb6d4428d3d ("drm/nouveau: move the (far too many...) different s/r paths 
to the same place")
8d5e3af15c79 ("drm/nouveau/device: Add support for GK208B, resolves bug 
86935")
8d85e06b5e04 ("drm/nouveau/bios: add pci data structure parsing")
989aa5b76ad2 ("drm/nouveau/nvif: namespace of nvkm accessors (no binary 
change)")
a01ca78c8f11 ("drm/nouveau/nvif: simplify and tidy library interfaces")
ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB")
ad4a36263535 ("drm/nouveau/bios: split out shadow methods")
b71a1344ec20 ("drm/nouveau/bios: add NPDE parsing")
ba6e34e61271 ("drm/gm204/devinit: initial implementation")
be83cd4ef9a2 ("drm/nouveau: finalise nvkm namespace switch (no binary 
change)")
c39f472e9f14 ("drm/nouveau: remove symlinks, move core/ to nvkm/ (no code 
changes)")
cb8bb9cedb60 ("drm/nouveau/tmr: cosmetic changes")
d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
f3867f439fd6 ("drm/nouveau/clk: rename from clock (no binary change)")
f8a8546194d7 ("drm/nouveau

[Bug 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #27 from Alex Deucher  ---
(In reply to nmr from comment #26)
> I'm getting the impression that AMD does not regard the kernel hang as the
> underlying issue. Is that correct?

The GPU hang is most likely caused by a bug in mesa.  What kernel are you
using?  GPU reset was only recently enabled by default on certain asics.  Even
if a GPU reset is successful, user mode programs (like X or the wayland desktop
compositor) need to properly catch and handle GPU resets which they don't
currently today.  Can you try 4.20 or newer?

-- 
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 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #26 from nmr  ---
I'm getting the impression that AMD does not regard the kernel hang as the
underlying issue. Is that correct?

-- 
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 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107978

--- Comment #57 from Alex Deucher  ---
(In reply to Shmerl from comment #56)
> I see the fix in this submission though:
> https://lists.freedesktop.org/archives/amd-gfx/2019-February/031437.html

This patch missed the window for last week's -fixes pull.

> 
> So it's coming in 5.1 only?

It can still land in 5.0 and prior kernels via stable if it doesn't make it in
for 5.0 final.

-- 
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 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

Alex Deucher  changed:

   What|Removed |Added

Product|DRI |Mesa
  Component|DRM/AMDgpu  |Drivers/Gallium/radeonsi
 QA Contact||dri-devel@lists.freedesktop
   ||.org

-- 
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 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Thomas Hellstrom]

On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
> Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
> > On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
> > > Another good question is also why the heck the acc_size counts
> > > towards
> > > the DMA32 zone?
> > DMA32 TTM pages are accounted in the DMA32 zone. Other pages are
> > not.
> 
> Yeah, I'm perfectly aware of this. But this is for the accounting
> size!
> 
> We have an accounting for the stuff needed additional to the pages 
> backing the BO (e.g. the page and DMA addr array).
> 
> And from the bug description it sounds like we use the DMA32 zone
> for 
> this accounting which of course is completely nonsense.

It's actually accounted in all available zones, since it would be
pretty hard to determine exactly where that memory should be accounted.
In particular if it's vmalloced. It might be DMA32, it might not. Given
the objective of stopping malicious user-space from exhausting the
DMA32 zone it was, at the time the code was written, a reasonable
approximation. With ever increasing memory sizes, there might be better
solutions?

/Thomas

> 
> Christian.
> 
> > For small persistent allocations using ttm_mem_global_alloc(), they
> > are
> > accounted also in the DMA32 zone, which may cause over-accounting
> > of
> > that zone, but that's pretty unlikely to be a big problem..
> > 
> > /Thomas
> > 
> > 
> > 
> > 
> > 
> > > In other words why should the internal bookkeeping pages be
> > > allocated
> > > in
> > > the DMA32 zone?
> > > 
> > > That doesn't sounds valid to me in any way,
> > > Christian.
> > > 
> > > Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:
> > > > Hmm,
> > > > 
> > > > This zone was intended to stop TTM page allocations from
> > > > exhausting
> > > > the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by
> > > > default,
> > > > which
> > > > means if we drop this check, other devices may stop functioning
> > > > unexpectedly?
> > > > 
> > > > However, in the end I'd expect the kernel page allocation
> > > > system
> > > > to
> > > > make sure there are some pages left in the DMA32 zone,
> > > > otherwise
> > > > random non-IO page allocations would also potentially exhaust
> > > > the
> > > > DMA32 zone without anybody caring, which means removing this
> > > > zone
> > > > wouldn't be any worse than whatever other subsystems may be
> > > > doing
> > > > already...
> > > > 
> > > > /Thomas
> > > > 
> > > > 
> > > > On 2/16/19 12:02 AM, Kuehling, Felix wrote:
> > > > > This is an RFC. I'm not sure this is the right solution, but
> > > > > it
> > > > > highlights the problem I'm trying to solve.
> > > > > 
> > > > > The dma32_zone limits the acc_size of all allocated BOs to
> > > > > 2GB.
> > > > > On a
> > > > > 64-bit system with hundreds of GB of system memory and GPU
> > > > > memory,
> > > > > this can become a bottle neck. We're seeing TTM memory
> > > > > allocation
> > > > > failures not because we're truly out of memory, but because
> > > > > we're
> > > > > out of space in the dma32_zone for the acc_size needed for
> > > > > our BO
> > > > > book-keeping.
> > > > > 
> > > > > Signed-off-by: Felix Kuehling 
> > > > > CC: thellst...@vmware.com
> > > > > CC: christian.koe...@amd.com
> > > > > ---
> > > > >drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
> > > > >1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
> > > > > b/drivers/gpu/drm/ttm/ttm_memory.c
> > > > > index f1567c3..bb05365 100644
> > > > > --- a/drivers/gpu/drm/ttm/ttm_memory.c
> > > > > +++ b/drivers/gpu/drm/ttm/ttm_memory.c
> > > > > @@ -363,7 +363,7 @@ static int
> > > > > ttm_mem_init_highmem_zone(struct
> > > > > ttm_mem_global *glob,
> > > > >glob->zones[glob->num_zones++] = zone;
> > > > >return 0;
> > > > >}
> > > > > -#else
> > > > > +#elifndef CONFIG_64BIT
> > > > >static int ttm_mem_init_dma32_zone(struct ttm_mem_global
> > > > > *glob,
> > > > >   const struct sysinfo *si)
> > > > >{
> > > > > @@ -441,7 +441,7 @@ int ttm_mem_global_init(struct
> > > > > ttm_mem_global
> > > > > *glob)
> > > > >ret = ttm_mem_init_highmem_zone(glob, &si);
> > > > >if (unlikely(ret != 0))
> > > > >goto out_no_zone;
> > > > > -#else
> > > > > +#elifndef CONFIG_64BIT
> > > > >ret = ttm_mem_init_dma32_zone(glob, &si);
> > > > >if (unlikely(ret != 0))
> > > > >goto out_no_zone;
> > ___
> > amd-gfx mailing list
> > amd-...@lists.freedesktop.org
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cthellstrom%40vmware.com%7C1a84a2a700cd48b3980a08d695c38ade%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636861064581303965&sdata=6FCAP6YbostgKfEEhRKKh9eQSrfXR%2BfCczYB8WwlPVY%3D&reserved=0
___
dri-devel mailing list
dri-devel@

[Bug 108879] [CIK] [regression] All opencl apps hangs indefinitely in si_create_context

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108879

--- Comment #8 from Marco  ---
I applied the two patches:
https://lists.freedesktop.org/archives/mesa-dev/2019-February/215057.html
https://lists.freedesktop.org/archives/mesa-dev/2019-February/215058.html

but problem persist on my card:
AMD KABINI (DRM 3.27.0, 4.20.8-bfq-zstd+, LLVM 8.0.0)
AMD Radeon HD 8500M Series (HAINAN, DRM 3.27.0, 4.20.8-bfq-zstd+, LLVM 8.0.0)

The result is the same, clinfo freezes with the same stack trace

-- 
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 libdrm] RELEASING: update instructions to use meson instead of autotools

[Daniel Vetter]

On Mon, Feb 18, 2019 at 05:42:38PM +, Eric Engestrom wrote:
> On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > Signed-off-by: Eric Engestrom 
> > > ---
> > >  RELEASING | 27 ---
> > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/RELEASING b/RELEASING
> > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > --- a/RELEASING
> > > +++ b/RELEASING
> > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the feature 
> > > in question.
> > >  
> > >  Follow these steps to release a new version of libdrm:
> > >  
> > > -  1) Bump the version number in configure.ac and meson.build. We seem
> > > - to have settled for 2.4.x as the versioning scheme for libdrm, so
> > > - just bump the  micro version.
> > > -
> > > -  2) Run autoconf and then re-run ./configure so the build system
> > > - picks up the new version number.
> > > -
> > > -  3) Verify that the code passes "make distcheck".  Running "make
> > > - distcheck" should result in no warnings or errors and end with a
> > > - message of the form:
> > > -
> > > -   =
> > > -   libdrm-X.Y.Z archives ready for distribution:
> > > -   libdrm-X.Y.Z.tar.gz
> > > -   libdrm-X.Y.Z.tar.bz2
> > > -   =
> > > -
> > > - Make sure that the version number reported by distcheck and in
> > > - the tarball names matches the number you bumped to in configure.ac.
> > > +  1) Bump the version number in meson.build. We seem to have settled for
> > > + 2.4.x as the versioning scheme for libdrm, so just bump the micro
> > > + version.
> > > +
> > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > + Make sure that the version number of the tarball name in
> > > + builddir/meson-dist/ matches the number you bumped to. Move that
> > > + tarball to the libdrm repo root for the release script to pick up.
> > >  
> > >4) Push the updated master branch with the bumped version number:
> 
> Just noticed I forgot to decrement item 4 & 5 :]
> 
> > >  
> > > -- 
> > > Cheers,
> > >   Eric
> > > 
> > 
> > Acked-by: Dylan Baker 
> > 
> > But you should probably get someone other than just me to look at this.
> 
> There is no "libdrm maintainer", which makes everyone a libdrm
> maintainer :]
> 
> If nobody object, I'll push this in a few weeks (there's really no rush,
> but I want to make that move at some point, we have no reason to stay
> dependant on autotools now that we have better tools).

I double-checked that ninja dist does run the tests, so lgtm (with the
numbering adjusted):

Acked-by: Daniel Vetter 

> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109667] r5 m330 hung if dpm enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109667

--- Comment #1 from Slava  ---
Created attachment 143397
  --> https://bugs.freedesktop.org/attachment.cgi?id=143397&action=edit
dmesg

-- 
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 v7 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel

[Sam Ravnborg]

Hi Thierry

> Pleas let me know if you any further comments on this?
No further comments from my side, and I consider it
ready to apply.

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [v16 2/4] drm: Add DP colorspace property

[Ville Syrjälä]

On Wed, Feb 13, 2019 at 12:35:09PM +0530, Uma Shankar wrote:
> This patch adds a DP colorspace property, enabling
> userspace to switch to various supported colorspaces.
> This will help enable BT2020 along with other colorspaces.
> 
> v2: Addressed Maarten and Ville's review comments. Enhanced
> the colorspace enum to incorporate both HDMI and DP supported
> colorspaces. Also, added a default option for colorspace.
> 
> v3: Split the changes to have separate colorspace property for
> DP and HDMI.
> 
> v4: Addressed Chris and Ville's review comments, and created a
> common colorspace property for DP and HDMI, filtered the list
> based on the colorspaces supported by the respective protocol
> standard.
> 
> v5: Merged the DP handling along with platform colorspace
> handling as per Shashank's comments.
> 
> v6: Reverted to old design of exposing all colorspaces to
> userspace as per Ville's review comment
> 
> v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
> 
> v8: Addressed Ville's review comments and updated the colorspace
> macro definitions.
> 
> Signed-off-by: Uma Shankar 
> Acked-by: Jani Nikula 
> Reviewed-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_connector.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 07d65a1..5473bea 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -853,6 +853,24 @@ int drm_display_info_set_bus_formats(struct 
> drm_display_info *info,
>   { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
>  };
>  
> +static const struct drm_prop_enum_list dp_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
> + /* Colorimetry based on IEC 61966-2-5 */
> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> + /* DP MSA Colorimetry */
> + { DRM_MODE_DP_COLORIMETRY_BT601_YCC, "BT601_YCC" },
> + { DRM_MODE_DP_COLORIMETRY_BT709_YCC, "BT709_YCC" },
> + { DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
> + { DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
> + { DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" },
> +};

I think we should postpone this patch (and the DP related bits in the
previous patch) until we have the implementation done. Ie. let's just
get HDMI working initially.

> +
>  /**
>   * DOC: standard connector properties
>   *
> @@ -1614,6 +1632,14 @@ int drm_mode_create_colorspace_property(struct 
> drm_connector *connector)
>   ARRAY_SIZE(hdmi_colorspaces));
>   if (!prop)
>   return -ENOMEM;
> + } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
> +connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) 
> {
> + prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
> + "Colorspace", dp_colorspaces,
> + ARRAY_SIZE(dp_colorspaces));
> +
> + if (!prop)
> + return -ENOMEM;
>   } else {
>   DRM_DEBUG_KMS("Colorspace property not supported\n");
>   return 0;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [v16 3/4] drm: Add colorspace info to AVI Infoframe

[Ville Syrjälä]

On Wed, Feb 13, 2019 at 12:35:10PM +0530, Uma Shankar wrote:
> This adds colorspace information to HDMI AVI infoframe.
> A helper function is added to program the same.
> 
> v2: Moved this to drm core instead of i915 driver.
> 
> v3: Exported the helper function.
> 
> v4: Added separate HDMI specific macro as per CTA spec.
> This is separate from user exposed enum values. This is
> as per Ville's suggestion.
> 
> v5: Appended BT709 and SMPTE 170M with YCC information as per Ville's
> review comment to be clear and not to be confused with RGB.
> 
> v6: Added bit wise macro for various fields of colorimetry for easier
> understanding and review as per Ville's comments. Moved the same out of
> header file to avoid any namespace issues.
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/drm_edid.c | 66 
> ++
>  include/drm/drm_edid.h |  6 +
>  2 files changed, 72 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 990b190..64816c0 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4924,6 +4924,72 @@ static bool is_hdmi2_sink(struct drm_connector 
> *connector)
>  }
>  EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
>  
> +/* HDMI Colorspace Spec Definitions */
> +#define FULL_COLORIMETRY_MASK0x1FF
> +#define NORMAL_COLORIMETRY_MASK  0x3
> +#define EXTENDED_COLORIMETRY_MASK0x7
> +#define EXTENDED_ACE_COLORIMETRY_MASK0xF
> +
> +#define C(x) ((x) << 0)
> +#define EC(x) ((x) << 2)
> +#define ACE(x) ((x) << 5)
> +
> +#define HDMI_COLORIMETRY_NO_DATA 0x0
> +#define HDMI_COLORIMETRY_SMPTE_170M_YCC  (C(1) | EC(0) | ACE(0))
> +#define HDMI_COLORIMETRY_BT709_YCC   (C(2) | EC(0) | ACE(0))
> +#define HDMI_COLORIMETRY_XVYCC_601   (C(3) | EC(0) | ACE(0))
> +#define HDMI_COLORIMETRY_XVYCC_709   (C(3) | EC(1) | ACE(0))
> +#define HDMI_COLORIMETRY_SYCC_601(C(3) | EC(2) | ACE(0))
> +#define HDMI_COLORIMETRY_OPYCC_601   (C(3) | EC(3) | ACE(0))
> +#define HDMI_COLORIMETRY_OPRGB   (C(3) | EC(4) | ACE(0))
> +#define HDMI_COLORIMETRY_BT2020_CYCC (C(3) | EC(5) | ACE(0))
> +#define HDMI_COLORIMETRY_BT2020_RGB  (C(3) | EC(6) | ACE(0))
> +#define HDMI_COLORIMETRY_BT2020_YCC  (C(3) | EC(6) | ACE(0))
> +#define HDMI_COLORIMETRY_DCI_P3_RGB_D65  (C(3) | EC(7) | ACE(0))
> +#define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER  (C(3) | EC(7) | ACE(1))
> +
> +static const u32 hdmi_colorimetry_val[] = {
> + [DRM_MODE_COLORIMETRY_NO_DATA] = HDMI_COLORIMETRY_NO_DATA,
> + [DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = HDMI_COLORIMETRY_SMPTE_170M_YCC,
> + [DRM_MODE_COLORIMETRY_BT709_YCC] = HDMI_COLORIMETRY_BT709_YCC,
> + [DRM_MODE_COLORIMETRY_XVYCC_601] = HDMI_COLORIMETRY_XVYCC_601,
> + [DRM_MODE_COLORIMETRY_XVYCC_709] = HDMI_COLORIMETRY_XVYCC_709,
> + [DRM_MODE_COLORIMETRY_SYCC_601] = HDMI_COLORIMETRY_SYCC_601,
> + [DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
> + [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
> + [DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
> + [DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
> + [DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
> +};

Probably best to

#undef C
#undef EC
#undef ACE

here to avoid accidents.

With that
Reviewed-by: Ville Syrjälä 

> +
> +/**
> + * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
> + *   colorspace information
> + * @frame: HDMI AVI infoframe
> + * @conn_state: connector state
> + */
> +void
> +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
> +   const struct drm_connector_state *conn_state)
> +{
> + u32 colorimetry_val;
> + u32 colorimetry_index = conn_state->colorspace & FULL_COLORIMETRY_MASK;
> +
> + if (colorimetry_index >= ARRAY_SIZE(hdmi_colorimetry_val))
> + colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
> + else
> + colorimetry_val = hdmi_colorimetry_val[colorimetry_index];
> +
> + frame->colorimetry = colorimetry_val & NORMAL_COLORIMETRY_MASK;
> + /*
> +  * ToDo: Extend it for ACE formats as well. Modify the infoframe
> +  * structure and extend it in drivers/video/hdmi
> +  */
> + frame->extended_colorimetry = (colorimetry_val >> 2) &
> + EXTENDED_COLORIMETRY_MASK;
> +}
> +EXPORT_SYMBOL(drm_hdmi_avi_infoframe_colorspace);
> +
>  /**
>   * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
>   *quantization range information
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 8dc1a08..9d3b5b9 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -331,6 +331,7 @@ struct cea_sad {

[Bug 109667] r5 m330 hung if dpm enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109667

Bug ID: 109667
   Summary: r5 m330 hung if dpm enabled
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: masterxa...@gmail.com

I have laptop with AMD A9-9420 cpu and discrete r5 m330.

01:00.0 0380: 1002:6660 (rev 83)
Subsystem: 103c:8331
Physical Slot: 0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: radeon
Kernel modules: radeon, amdgpu

Integrated gpu works flawlessly, but running something with DRI_PRIME=1 causes
gpu hung after some time(from 30s to few minutes). this happens on BOTH radeon
and amdgpu modules. Disabling dpm prevents hung for both drivers, but makes gpu
useless because little default clocks.
Kernel parametres I'm using right now: radeon.dpm=0 amdgpu.dpm=1 amdgpu.dc=1
amdgpu.gpu_recovery=1
Also tried with amdgpu.si_support=1 radeon.si_support=0 but as I sain before
problem happens with both modules.
this happens on all kernels i tried. 4.9 is oldest i can install, because wifi
driver woks only on post 4.9 kernels

-- 
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 2/2] dt-bindings: panel: td028ttec1: add backlight property

[Rob Herring]

On Tue,  5 Feb 2019 07:38:13 +0100, Andreas Kemnade wrote:
> This adds an additional backlight property as described
> in panel-common.txt
> 
> Signed-off-by: Andreas Kemnade 
> ---
>  Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 06/11] drm/sun4i: rgb: Add DT property to disable strict clock rate check

[Vasily Khoruzhick]

On Mon, Feb 18, 2019 at 10:26 AM Rob Herring  wrote:
>
> On Thu, Feb 14, 2019 at 09:09:52PM -0800, Vasily Khoruzhick wrote:
> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> > Validate the clock rate") prevents some panel and bridges from working with
> > sun4i driver.
>
> Sounds lile a regression that should be reverted. The fix is not a
> backwards compatible change either.

anx6345 driver isn't mainlined yet and I'm not sure if this change
breaks any mainlined boards. So likely there's not enough
justification to revert it.

> > Unfortunately, dotclock frequency for some modes are not achievable on
> > sunxi hardware, and there's a slight deviation in rate returned by
> > clk_round_rate(), so they fail this check.
> >
> > Experiments show that panels and bridges work fine with this slight
> > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> > fine.
> >
> > This patch adds DT property to disable strict clock rate check
> >
> > Signed-off-by: Vasily Khoruzhick 
> > ---
> >  .../devicetree/bindings/display/sunxi/sun4i-drm.txt  | 2 ++
> >  drivers/gpu/drm/sun4i/sun4i_rgb.c| 5 +
> >  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 3 +++
> >  drivers/gpu/drm/sun4i/sun4i_tcon.h   | 1 +
> >  4 files changed, 11 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > index f426bdb42f18..18c8b053a28d 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > @@ -63,6 +63,8 @@ Required properties:
> >  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> >  first port should be the input endpoint. The second should be the
> >  output, usually to an HDMI connector.
> > +  - no-strict-clock-check: don't reject timings if exact dot clock can't be
> > +reached.
>
> This should be the default IMO. Most panels are a single timing, so if
> we reject it the fallback no display?

As far as I remember the change was introduced to reject some modes
for which dotclock can't be reached when driver is used with VGA
bridge. So if we make it default it'll break boards with VGA bridge
and old DT.

> I thought we had some mechanism already to allow some range of
> frequencies. I think the chromeos guys needed something IIRC.

You can specify frequency range for panels, but there's nothing for
bridges. In my case EDID doesn't specify clock tolerance.

>
> Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 10/11] drm/panel: simple: Add NewEast Optoelectronics CO., LTD WJFH116008A panel support

[Vasily Khoruzhick]

On Mon, Feb 18, 2019 at 10:33 AM Rob Herring  wrote:
>
> On Thu, Feb 14, 2019 at 09:09:56PM -0800, Vasily Khoruzhick wrote:
> > This commit adds support for the NewEast Optoelectronics CO., LTD
> > WJFH116008A 11.6" 1920x1080 TFT LCD panel.
> >
> > Signed-off-by: Vasily Khoruzhick 
> > ---
> >  .../display/panel/neweast,wjfh116008a.txt |  7 
> >  drivers/gpu/drm/panel/panel-simple.c  | 39 +++
> >  2 files changed, 46 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt 
> > b/Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt
> > new file mode 100644
> > index ..d76579f9f55e
> > --- /dev/null
> > +++ 
> > b/Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt
> > @@ -0,0 +1,7 @@
> > +NewEast Optoelectronics CO., LTD WJFH116008A 11.6" 1920x1080 TFT LCD panel
> > +
> > +Required properties:
> > +- compatible: should be "neweast,wjfh116008a"
> > +
> > +This binding is compatible with the simple-panel binding, which is 
> > specified
> > +in simple-panel.txt in this directory.
>
> We already established that this goes thru a standard eDP connector. We
> should describe that and everything associated with it.

I believe using eDP connector binding wouldn't help much in my case
and it won't improve accuracy of hardware description while adding
unnecessary code duplication (edp-connector will be pretty much
simple-panel).

Since currently there're no standalone connector drivers, implementing
one requires significant refactoring of the code that I'm not
familiar.

> Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_vm: Mark expected switch fall-throughs

[Daniel Vetter]

On Mon, Feb 18, 2019 at 7:02 PM Gustavo A. R. Silva
 wrote:
>
> Hi Daniel,
>
> On 2/18/19 2:57 AM, Daniel Vetter wrote:
> > On Fri, Feb 15, 2019 at 11:05:46AM -0600, Gustavo A. R. Silva wrote:
> >> In preparation to enabling -Wimplicit-fallthrough, mark switch
> >> cases where we are expecting to fall through.
> >>
> >> Warning level 3 was used: -Wimplicit-fallthrough=3
> >>
> >> Notice that, in this particular case, the code comment is modified
> >> in accordance with what GCC is expecting to find.
> >>
> >> This patch is part of the ongoing efforts to enable
> >> -Wimplicit-fallthrough.
> >>
> >> Signed-off-by: Gustavo A. R. Silva 
> >
> > Queued for 5.2, thanks for your patch.
> > -Daniel
> >
>
> I wonder if you could take this one too, or give me some feedback
> about it:
>
> https://patchwork.kernel.org/patch/10646783/
>
> I've pinged twice, but I haven't received any responses.

Dave? nouveau is kinda your thing, at least all the fallout :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 10/11] drm/panel: simple: Add NewEast Optoelectronics CO., LTD WJFH116008A panel support

[Rob Herring]

On Thu, Feb 14, 2019 at 09:09:56PM -0800, Vasily Khoruzhick wrote:
> This commit adds support for the NewEast Optoelectronics CO., LTD
> WJFH116008A 11.6" 1920x1080 TFT LCD panel.
> 
> Signed-off-by: Vasily Khoruzhick 
> ---
>  .../display/panel/neweast,wjfh116008a.txt |  7 
>  drivers/gpu/drm/panel/panel-simple.c  | 39 +++
>  2 files changed, 46 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt 
> b/Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt
> new file mode 100644
> index ..d76579f9f55e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt
> @@ -0,0 +1,7 @@
> +NewEast Optoelectronics CO., LTD WJFH116008A 11.6" 1920x1080 TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "neweast,wjfh116008a"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.

We already established that this goes thru a standard eDP connector. We 
should describe that and everything associated with it.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 09/11] dt-bindings: Add Guangdong Neweast Optoelectronics CO. LTD vendor prefix

[Rob Herring]

On Thu, 14 Feb 2019 21:09:55 -0800, Vasily Khoruzhick wrote:
> Add vendor prefix for Guangdong Neweast Optoelectronics CO. LTD
> 
> Signed-off-by: Vasily Khoruzhick 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.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 v3 06/11] drm/sun4i: rgb: Add DT property to disable strict clock rate check

[Rob Herring]

On Thu, Feb 14, 2019 at 09:09:52PM -0800, Vasily Khoruzhick wrote:
> Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> Validate the clock rate") prevents some panel and bridges from working with
> sun4i driver.

Sounds lile a regression that should be reverted. The fix is not a 
backwards compatible change either.

> 
> Unfortunately, dotclock frequency for some modes are not achievable on
> sunxi hardware, and there's a slight deviation in rate returned by
> clk_round_rate(), so they fail this check.
> 
> Experiments show that panels and bridges work fine with this slight
> deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> fine.
> 
> This patch adds DT property to disable strict clock rate check
> 
> Signed-off-by: Vasily Khoruzhick 
> ---
>  .../devicetree/bindings/display/sunxi/sun4i-drm.txt  | 2 ++
>  drivers/gpu/drm/sun4i/sun4i_rgb.c| 5 +
>  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 3 +++
>  drivers/gpu/drm/sun4i/sun4i_tcon.h   | 1 +
>  4 files changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index f426bdb42f18..18c8b053a28d 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -63,6 +63,8 @@ Required properties:
>  Documentation/devicetree/bindings/media/video-interfaces.txt. The
>  first port should be the input endpoint. The second should be the
>  output, usually to an HDMI connector.
> +  - no-strict-clock-check: don't reject timings if exact dot clock can't be
> +reached.

This should be the default IMO. Most panels are a single timing, so if 
we reject it the fallback no display? 

I thought we had some mechanism already to allow some range of 
frequencies. I think the chromeos guys needed something IIRC.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 04/11] dt-bindings: Add ANX6345 DP/eDP transmitter binding

[Rob Herring]

On Thu, 14 Feb 2019 21:09:50 -0800, Vasily Khoruzhick wrote:
> From: Icenowy Zheng 
> 
> The ANX6345 is an ultra-low power DisplayPort/eDP transmitter designed
> for portable devices.
> 
> Add a binding document for it.
> 
> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Vasily Khoruzhick 
> ---
>  .../bindings/display/bridge/anx6345.txt   | 56 +++
>  1 file changed, 56 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/anx6345.txt
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_vm: Mark expected switch fall-throughs

[Gustavo A. R. Silva]

Hi Daniel,

On 2/18/19 2:57 AM, Daniel Vetter wrote:
> On Fri, Feb 15, 2019 at 11:05:46AM -0600, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> Notice that, in this particular case, the code comment is modified
>> in accordance with what GCC is expecting to find.
>>
>> This patch is part of the ongoing efforts to enable
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva 
> 
> Queued for 5.2, thanks for your patch.
> -Daniel
> 

I wonder if you could take this one too, or give me some feedback
about it:

https://patchwork.kernel.org/patch/10646783/

I've pinged twice, but I haven't received any responses.

Thanks
--
Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107978

--- Comment #56 from Shmerl  ---
I see the fix in this submission though:
https://lists.freedesktop.org/archives/amd-gfx/2019-February/031437.html

So it's coming in 5.1 only?

-- 
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 109550] [regression][amd tahiti xt][vm fault] Rise of the Tomb Raider hangs the system

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109550

--- Comment #5 from Sylvain BERTRAND  ---
same, all git from yesterday, still broken

-- 
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 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107978

--- Comment #55 from Shmerl  ---
Looks like the fix didn't make it into 5.0-rc7:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c?h=v5.0-rc7#n789

-- 
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 libdrm] RELEASING: update instructions to use meson instead of autotools

[Eric Engestrom]

On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-12-19 08:23:40)
> > Signed-off-by: Eric Engestrom 
> > ---
> >  RELEASING | 27 ---
> >  1 file changed, 8 insertions(+), 19 deletions(-)
> > 
> > diff --git a/RELEASING b/RELEASING
> > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > --- a/RELEASING
> > +++ b/RELEASING
> > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the feature in 
> > question.
> >  
> >  Follow these steps to release a new version of libdrm:
> >  
> > -  1) Bump the version number in configure.ac and meson.build. We seem
> > - to have settled for 2.4.x as the versioning scheme for libdrm, so
> > - just bump the  micro version.
> > -
> > -  2) Run autoconf and then re-run ./configure so the build system
> > - picks up the new version number.
> > -
> > -  3) Verify that the code passes "make distcheck".  Running "make
> > - distcheck" should result in no warnings or errors and end with a
> > - message of the form:
> > -
> > -   =
> > -   libdrm-X.Y.Z archives ready for distribution:
> > -   libdrm-X.Y.Z.tar.gz
> > -   libdrm-X.Y.Z.tar.bz2
> > -   =
> > -
> > - Make sure that the version number reported by distcheck and in
> > - the tarball names matches the number you bumped to in configure.ac.
> > +  1) Bump the version number in meson.build. We seem to have settled for
> > + 2.4.x as the versioning scheme for libdrm, so just bump the micro
> > + version.
> > +
> > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > + Make sure that the version number of the tarball name in
> > + builddir/meson-dist/ matches the number you bumped to. Move that
> > + tarball to the libdrm repo root for the release script to pick up.
> >  
> >4) Push the updated master branch with the bumped version number:

Just noticed I forgot to decrement item 4 & 5 :]

> >  
> > -- 
> > Cheers,
> >   Eric
> > 
> 
> Acked-by: Dylan Baker 
> 
> But you should probably get someone other than just me to look at this.

There is no "libdrm maintainer", which makes everyone a libdrm
maintainer :]

If nobody object, I'll push this in a few weeks (there's really no rush,
but I want to make that move at some point, we have no reason to stay
dependant on autotools now that we have better tools).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/3] xf86drm: dedupe `#define`s

[Eric Engestrom]

On Wednesday, 2018-12-19 17:08:01 +, Eric Engestrom wrote:
> Adapted from a local patch carried by DragonFlyBSD:
> https://github.com/DragonFlyBSD/DPorts/blob/bc056f88f7e4d468d8c9751f831a47b5ae1326e3/graphics/libdrm/files/patch-xf86drm.h
> 
> Patch is sadly uncredited (a bot authored the commit), so I can't credit
> the author here either.
> 
> Signed-off-by: Eric Engestrom 

Ping? :)

> ---
>  xf86drm.c | 10 --
>  xf86drm.h | 16 ++--
>  2 files changed, 10 insertions(+), 16 deletions(-)
> 
> diff --git a/xf86drm.c b/xf86drm.c
> index 377ddf917d2cb902899a..07425b19897d00a19e8a 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -71,16 +71,6 @@
>  
>  #include "util_math.h"
>  
> -#ifdef __OpenBSD__
> -#define DRM_PRIMARY_MINOR_NAME  "drm"
> -#define DRM_CONTROL_MINOR_NAME  "drmC"
> -#define DRM_RENDER_MINOR_NAME   "drmR"
> -#else
> -#define DRM_PRIMARY_MINOR_NAME  "card"
> -#define DRM_CONTROL_MINOR_NAME  "controlD"
> -#define DRM_RENDER_MINOR_NAME   "renderD"
> -#endif
> -
>  #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || 
> defined(__DragonFly__)
>  #define DRM_MAJOR 145
>  #endif
> diff --git a/xf86drm.h b/xf86drm.h
> index 7773d71a803084e86920..18668ff3d40d7db55c95 100644
> --- a/xf86drm.h
> +++ b/xf86drm.h
> @@ -78,17 +78,21 @@ extern "C" {
>  
>  #ifdef __OpenBSD__
>  #define DRM_DIR_NAME  "/dev"
> -#define DRM_DEV_NAME  "%s/drm%d"
> -#define DRM_CONTROL_DEV_NAME  "%s/drmC%d"
> -#define DRM_RENDER_DEV_NAME  "%s/drmR%d"
> +#define DRM_PRIMARY_MINOR_NAME  "drm"
> +#define DRM_CONTROL_MINOR_NAME  "drmC"
> +#define DRM_RENDER_MINOR_NAME   "drmR"
>  #else
>  #define DRM_DIR_NAME  "/dev/dri"
> -#define DRM_DEV_NAME  "%s/card%d"
> -#define DRM_CONTROL_DEV_NAME  "%s/controlD%d"
> -#define DRM_RENDER_DEV_NAME  "%s/renderD%d"
> +#define DRM_PRIMARY_MINOR_NAME  "card"
> +#define DRM_CONTROL_MINOR_NAME  "controlD"
> +#define DRM_RENDER_MINOR_NAME   "renderD"
>  #define DRM_PROC_NAME "/proc/dri/" /* For backward Linux compatibility */
>  #endif
>  
> +#define DRM_DEV_NAME  "%s/" DRM_PRIMARY_MINOR_NAME "%d"
> +#define DRM_CONTROL_DEV_NAME  "%s/" DRM_CONTROL_MINOR_NAME "%d"
> +#define DRM_RENDER_DEV_NAME   "%s/" DRM_RENDER_MINOR_NAME  "%d"
> +
>  #define DRM_ERR_NO_DEVICE  (-1001)
>  #define DRM_ERR_NO_ACCESS  (-1002)
>  #define DRM_ERR_NOT_ROOT   (-1003)
> -- 
> Cheers,
>   Eric
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Christian König]

Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:

On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:

Another good question is also why the heck the acc_size counts
towards
the DMA32 zone?

DMA32 TTM pages are accounted in the DMA32 zone. Other pages are not.


Yeah, I'm perfectly aware of this. But this is for the accounting size!

We have an accounting for the stuff needed additional to the pages 
backing the BO (e.g. the page and DMA addr array).


And from the bug description it sounds like we use the DMA32 zone for 
this accounting which of course is completely nonsense.


Christian.



For small persistent allocations using ttm_mem_global_alloc(), they are
accounted also in the DMA32 zone, which may cause over-accounting of
that zone, but that's pretty unlikely to be a big problem..

/Thomas






In other words why should the internal bookkeeping pages be allocated
in
the DMA32 zone?

That doesn't sounds valid to me in any way,
Christian.

Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:

Hmm,

This zone was intended to stop TTM page allocations from
exhausting
the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by default,
which
means if we drop this check, other devices may stop functioning
unexpectedly?

However, in the end I'd expect the kernel page allocation system
to
make sure there are some pages left in the DMA32 zone, otherwise
random non-IO page allocations would also potentially exhaust the
DMA32 zone without anybody caring, which means removing this zone
wouldn't be any worse than whatever other subsystems may be doing
already...

/Thomas


On 2/16/19 12:02 AM, Kuehling, Felix wrote:

This is an RFC. I'm not sure this is the right solution, but it
highlights the problem I'm trying to solve.

The dma32_zone limits the acc_size of all allocated BOs to 2GB.
On a
64-bit system with hundreds of GB of system memory and GPU
memory,
this can become a bottle neck. We're seeing TTM memory allocation
failures not because we're truly out of memory, but because we're
out of space in the dma32_zone for the acc_size needed for our BO
book-keeping.

Signed-off-by: Felix Kuehling 
CC: thellst...@vmware.com
CC: christian.koe...@amd.com
---
   drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
b/drivers/gpu/drm/ttm/ttm_memory.c
index f1567c3..bb05365 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -363,7 +363,7 @@ static int ttm_mem_init_highmem_zone(struct
ttm_mem_global *glob,
   glob->zones[glob->num_zones++] = zone;
   return 0;
   }
-#else
+#elifndef CONFIG_64BIT
   static int ttm_mem_init_dma32_zone(struct ttm_mem_global *glob,
  const struct sysinfo *si)
   {
@@ -441,7 +441,7 @@ int ttm_mem_global_init(struct ttm_mem_global
*glob)
   ret = ttm_mem_init_highmem_zone(glob, &si);
   if (unlikely(ret != 0))
   goto out_no_zone;
-#else
+#elifndef CONFIG_64BIT
   ret = ttm_mem_init_dma32_zone(glob, &si);
   if (unlikely(ret != 0))
   goto out_no_zone;

___
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 09/11] drm/syncobj: add transition iotcls between binary and timeline

[Koenig, Christian]

Am 18.02.19 um 13:07 schrieb Lionel Landwerlin:
Thanks guys :)

You mentioned that signaling out of order is illegal.
Is this illegal with regard to the vulkan spec or to the syncobj implementation?

David is the expert on that, but as far as I know that is forbidden by the 
vulkan spec.

I'm not finding anything in the vulkan spec that makes out of order signaling 
illegal.
That's why I came up with this test, just verifying that the timeline does not 
go backward in term of its payload.

Well we need to handle this case gracefully in the kernel, so it is still a 
good testcase.

Christian.


-Lionel

On 18/02/2019 11:01, Koenig, Christian wrote:
Hi David,

well I think Lionel is testing the invalid signal order on purpose :)

Anyway we really need to handle invalid order graceful here. E.g. either the 
same way as during CS or we abort and return an error message.

I think just using the same approach as during CS ist the best we can do.

Regards,
Christian


Am 18.02.2019 11:35 schrieb "Zhou, David(ChunMing)" 
:

Hi Lionel,

I checked your igt test case,

uint64_t points[5] = { 1, 5, 3, 7, 6 };

which is illegal signal order.

I must admit we should handle it gracefully if signal isn't in-order, and we 
shouldn't lead to deadlock.

Hi Christian,

Can we just ignore when signal point X <= timeline Y? Or just give a warning?

Otherwise like Lionel's unexpected use cases, which easily leads to deadlock.


-David

On 2019年02月15日 22:28, Lionel Landwerlin wrote:

Hi David,

Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9

Trying to kill the deadlocked process I got this backtrace :


[   33.969136] [IGT] syncobj_timeline: starting subtest signal-order
[   60.452823] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[syncobj_timelin:2021]
[   60.452826] Modules linked in: rfcomm cmac bnep binfmt_misc
nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio sch_fq_codel ib_iser snd_hda_intel
rdma_cm iw_cm snd_hda_codec ib_cm snd_hda_core snd_hwdep intel_rapl
snd_pcm ib_core x86_pkg_temp_thermal intel_powerclamp configf
s coretemp iscsi_tcp snd_seq_midi libiscsi_tcp snd_seq_midi_event
libiscsi kvm_intel scsi_transport_iscsi kvm btusb snd_rawmidi irqbypass
btrtl intel_cstate intel_rapl_perf btbcm btintel bluetooth snd_seq
snd_seq_device snd_timer input_leds ecdh_generic snd soundcore mei_me
mei intel_pch_thermal mac_hid acpi_pad parp
ort_pc ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_decompress
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
hid_generic usbhid hid i915 crct10dif_pclmul crc32_pclmul i2c_algo_bit
ghash_clmulni_intel prime_numbers
drm_kms_helper aesni_intel syscopyarea sysfillrect
[   60.452876]  sysimgblt fb_sys_fops aes_x86_64 crypto_simd sdhci_pci
cryptd drm e1000e glue_helper cqhci sdhci wmi video
[   60.452881] CPU: 6 PID: 2021 Comm: syncobj_timelin Tainted: G
U5.0.0-rc5+ #337
[   60.452882] Hardware name:  /NUC6i7KYB, BIOS
KYSKLi70.86A.0042.2016.0929.1933 09/29/2016
[   60.452886] RIP: 0010:dma_fence_chain_walk+0x22c/0x260
[   60.452888] Code: ff e9 93 fe ff ff 48 8b 45 08 48 8b 40 18 48 85 c0
74 0c 48 89 ef e8 33 0f 58 00 84 c0 75 23 f0 41 ff 4d 00 0f 88 99 87 2f
00 <0f> 85 05 fe ff ff 4c 89 ef e8 56 ea ff ff 48 89 d8 5b 5d 41 5c 41
[   60.452888] RSP: 0018:9a5804653ca8 EFLAGS: 00010296 ORIG_RAX:
ff13
[   60.452889] RAX:  RBX: 8f5690fb2480 RCX:
8f5690fb2f00
[   60.452890] RDX: 003e3730 RSI:  RDI:
8f5690fb2180
[   60.452891] RBP: 8f5690fb2180 R08:  R09:
8f5690fb2eb0
[   60.452891] R10:  R11: 8f5660469860 R12:
8f5690fb2f68
[   60.452892] R13: 8f5690fb2f00 R14: 0003 R15:
8f5655a45fc0
[   60.452913] FS:  7fdc5c459980() GS:8f569eb8()
knlGS:
[   60.452913] CS:  0010 DS:  ES:  CR0: 80050033
[   60.452914] CR2: 7f9d74336dd8 CR3: 00084a67e004 CR4:
003606e0
[   60.452915] DR0:  DR1:  DR2:

[   60.452915] DR3:  DR6: fffe0ff0 DR7:
0400
[   60.452916] Call Trace:
[   60.452958]  drm_syncobj_add_point+0x102/0x160 [drm]
[   60.452965]  ? drm_syncobj_fd_to_handle_ioctl+0x1b0/0x1b0 [drm]
[   60.452971]  drm_syncobj_transfer_ioctl+0x10f/0x180 [drm]
[   60.452978]  drm_ioctl_kernel+0xac/0xf0 [drm]
[   60.452984]  drm_ioctl+0x2eb/0x3b0 [drm]
[   60.452990]  ? drm_syncobj_fd_to_handle_ioctl+0x1b0/0x1b0 [drm]
[   60.452992]  ? sw_sync_ioctl+0x347/0x370
[   60.452994]  do_vfs_ioctl+0xa4/0x640
[   60.452995]  ? __fput+0x134/0x2

[Bug 109666] Raven Ridge on drm-fixes-5.0 restarts instead of going to sleep

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109666

--- Comment #1 from Samantha McVey  ---
Created attachment 143396
  --> https://bugs.freedesktop.org/attachment.cgi?id=143396&action=edit
xorg log

Commit is v4.20-rc7-13233-g1d69511e49b0

Also ignore the kernel name being 5.0.0-rc5amd-staging-drm-next+. I had set a
static kernel suffix and didn't change it when I recompiled.

-- 
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 109666] Raven Ridge on drm-fixes-5.0 restarts instead of going to sleep

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109666

Bug ID: 109666
   Summary: Raven Ridge on drm-fixes-5.0 restarts instead of going
to sleep
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: samant...@posteo.net

Created attachment 143395
  --> https://bugs.freedesktop.org/attachment.cgi?id=143395&action=edit
dmesg log

This issue is not present in 4.20.7. It does not happen every time, but will
happen for me consistently over a days usage. Not present at all on 4.20.7.

Laptop is Lenovo A485.

-- 
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

Cursors uAPI vs async update - questions

[Helen Koike]

Hello,

After some discussions I had with some people I would like to discuss
some design choices regarding uAPI to expose async updates.

The plan is to allow userspace to update the cursor plane through the
atomic API instead of the legacy cursor API.

The steps I was following were:
1) Make the legacy cursor implementation use async updates
path/helpers; and this should work as before
2) Expose a way for userspace to trigger an async updates for any
plane (adding proper tests to igt)

Assuming that async here means: update the hw immediately.

But for this to happen, the idea of legacy cursor API and async update
should be similar, and my question is: are they?

The question that was raised was:

When we perform 100 legacy cursor updates to the kernel between 2
v-blanks, how many times does the screen update cursor?
(a) 1 - at vblank
(b) 100
(c) depends on the hw and driver

I would say (b), is that correct?
If it's (b), then async updates should allow the same.
(NOTE: Actually not really with the current implementation, if there is
a sync pending commit, then async update blocks,
which makes the name confusing).

Also, if async is not possible, in the current implementation we fall
back to a sync update. But this is not that interesting for userspace,
for example,
if drmModeSetCursor succeeds, xorg will call that every single time it
gets an input event, but if it fails, there are no expectations
that cursor moves are async and xorg handles cursor updates it self
(using the primary plane for instance). So another question here
is: should we have another flag to say that async update should fail
instead of falling back to a sync update ?

Another point is, if we perform an async update while there is still a
pending commit, It seems to me that instead of falling back to a
sync update, it would be better for the userspace if we could amend the
pending commit, what do you think?

And I just want to clarify (just because this wans't clear to me before
and might not be clear to others) that async update (programming
the hw immediately) can cause tearing if the hw reads the configuration
dynamically during a scanout.

Thanks
Helen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #25 from nmr  ---
Is it likely that this hang will get any traction with the AMDGPU team? Or
should I just close it and reset my expectations?

-- 
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] drivers/component: kerneldoc polish

[Daniel Vetter]

Polish the kerneldoc a bit with suggestions from Randy.

v2: Randy found another typo: s/compent/component/

Cc: Randy Dunlap 
Signed-off-by: Daniel Vetter 
Cc: Greg Kroah-Hartman 
Cc: "Rafael J. Wysocki" 
Cc: Daniel Vetter 
Cc: Ramalingam C 
---
 drivers/base/component.c  | 14 +++---
 include/linux/component.h |  2 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index 7dbc41cccd58..532a3a5d8f63 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -27,7 +27,7 @@
  * helper fills the niche of aggregate drivers for specific hardware, where
  * further standardization into a subsystem would not be practical. The common
  * example is when a logical device (e.g. a DRM display driver) is spread 
around
- * the SoC on various component (scanout engines, blending blocks, transcoders
+ * the SoC on various components (scanout engines, blending blocks, transcoders
  * for various outputs and so on).
  *
  * The component helper also doesn't solve runtime dependencies, e.g. for 
system
@@ -378,7 +378,7 @@ static void __component_match_add(struct device *master,
 }
 
 /**
- * component_match_add_release - add a component match with release callback
+ * component_match_add_release - add a component match entry with release 
callback
  * @master: device with the aggregate driver
  * @matchptr: pointer to the list of component matches
  * @release: release function for @compare_data
@@ -408,7 +408,7 @@ void component_match_add_release(struct device *master,
 EXPORT_SYMBOL(component_match_add_release);
 
 /**
- * component_match_add_typed - add a compent match for a typed component
+ * component_match_add_typed - add a component match entry for a typed 
component
  * @master: device with the aggregate driver
  * @matchptr: pointer to the list of component matches
  * @compare_typed: compare function to match against all typed components
@@ -537,11 +537,11 @@ static void component_unbind(struct component *component,
 }
 
 /**
- * component_unbind_all - unbind all component to an aggregate driver
+ * component_unbind_all - unbind all components of an aggregate driver
  * @master_dev: device with the aggregate driver
  * @data: opaque pointer, passed to all components
  *
- * Unbinds all components to the aggregate @dev by passing @data to their
+ * Unbinds all components of the aggregate @dev by passing @data to their
  * &component_ops.unbind functions. Should be called from
  * &component_master_ops.unbind.
  */
@@ -619,11 +619,11 @@ static int component_bind(struct component *component, 
struct master *master,
 }
 
 /**
- * component_bind_all - bind all component to an aggregate driver
+ * component_bind_all - bind all components of an aggregate driver
  * @master_dev: device with the aggregate driver
  * @data: opaque pointer, passed to all components
  *
- * Binds all components to the aggregate @dev by passing @data to their
+ * Binds all components of the aggregate @dev by passing @data to their
  * &component_ops.bind functions. Should be called from
  * &component_master_ops.bind.
  */
diff --git a/include/linux/component.h b/include/linux/component.h
index 30bcc7e590eb..16de18f473d7 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -98,7 +98,7 @@ void component_match_add_typed(struct device *master,
int (*compare_typed)(struct device *, int, void *), void *compare_data);
 
 /**
- * component_match_add - add a compent match
+ * component_match_add - add a component match entry
  * @master: device with the aggregate driver
  * @matchptr: pointer to the list of component matches
  * @compare: compare function to match against all components
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #24 from Alex Deucher  ---
(In reply to nmr from comment #23)
> Marek, is this even the right bug tracker for the kernel module or is this
> just for user space?

Same bug tracker for all components.

-- 
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 109607] [CI][DRMTIP] Time is passing at a different rate between IGT machines and the controller

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109607

--- Comment #4 from CI Bug Log  ---
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u2, fi-icl-u3: random tests - incomplete -}
{+ fi-icl-u2, fi-icl-u3: random tests - incomplete +}

New failures caught by the filter:

*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_221/fi-icl-u2/igt@kms_pl...@pixel-format-pipe-a-planes.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_221/fi-icl-u2/igt@kms_pl...@pixel-format-pipe-b-planes.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_221/fi-icl-u3/igt@kms_pl...@pixel-format-pipe-a-planes.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_221/fi-icl-u3/igt@kms_pl...@pixel-format-pipe-b-planes.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_222/fi-icl-u2/igt@kms_pl...@pixel-format-pipe-b-planes.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_223/fi-icl-u2/igt@kms_pl...@pixel-format-pipe-b-planes.html

-- 
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 1/2] drm: panel-orientation-quirks: Get rid of superfluous (void *) casting

[Thierry Reding]

On Sat, Feb 16, 2019 at 08:58:33PM +0100, David Santamaría Rogado wrote:
> From: howl 

Any reason why this differs from the Signed-off-by line? Perhaps check
your git configuration if this wasn't on purpose. Or perhaps you've
fixed the configuration since you authored the commits, in which case
you should be able to fix this by doing this:

$ git commit --reset-author --amend

You'd need to run that for each of the commits.

Thierry

> 
> The (void *) casting in the driver_data variable assignment is superfluous.
> Spotted by Jani Nikula.
> 
> Signed-off-by: David Santamaría Rogado 
> ---
>  drivers/gpu/drm/drm_panel_orientation_quirks.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index 52e445bb1aa5..61d3361381b7 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -86,13 +86,13 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Acer"),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"),
>   },
> - .driver_data = (void *)&acer_s1003,
> + .driver_data = &acer_s1003,
>   }, {/* Asus T100HA */
>   .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
>   },
> - .driver_data = (void *)&asus_t100ha,
> + .driver_data = &asus_t100ha,
>   }, {/*
>* GPD Pocket, note that the the DMI data is less generic then
>* it seems, devices with a board-vendor of "AMI Corporation"
> @@ -105,7 +105,7 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
>   },
> - .driver_data = (void *)&gpd_pocket,
> + .driver_data = &gpd_pocket,
>   }, {/* GPD Win (same note on DMI match as GPD Pocket) */
>   .matches = {
> DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
> @@ -113,7 +113,7 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
>   },
> - .driver_data = (void *)&gpd_win,
> + .driver_data = &gpd_win,
>   }, {/* GPD Win 2 (too generic strings, also match on bios date) */
>   .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
> @@ -121,7 +121,7 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
> DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
>   },
> - .driver_data = (void *)&gpd_win2,
> + .driver_data = &gpd_win2,
>   }, {/* I.T.Works TW891 */
>   .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."),
> @@ -129,7 +129,7 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "To be filled by O.E.M."),
> DMI_EXACT_MATCH(DMI_BOARD_NAME, "TW891"),
>   },
> - .driver_data = (void *)&itworks_tw891,
> + .driver_data = &itworks_tw891,
>   }, {/*
>* Lenovo Ideapad Miix 310 laptop, only some production batches
>* have a portrait screen, the resolution checks makes the quirk
> @@ -140,20 +140,20 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80SG"),
> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "MIIX 310-10ICR"),
>   },
> - .driver_data = (void *)&lcd800x1280_rightside_up,
> + .driver_data = &lcd800x1280_rightside_up,
>   }, {/* Lenovo Ideapad Miix 320 */
>   .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80XF"),
> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX 320-10ICR"),
>   },
> - .driver_data = (void *)&lcd800x1280_rightside_up,
> + .driver_data = &lcd800x1280_rightside_up,
>   }, {/* VIOS LTH17 */
>   .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "LTH17"),
>   },
> - .driver_data = (void *)&lcd800x1280_rightside_up,
> + .driver_data = &lcd800x1280_rightside_up,
>   },
>   {}
>  };
> -- 
> 2.20.1
> 


signature.asc
Description

Re: [PATCH v7 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel

[Jagan Teki]

Hi Thierry and Sam,

On Wed, Feb 13, 2019 at 2:11 AM Jagan Teki  wrote:
>
> Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
>
> Add panel driver for it.
>
> Signed-off-by: Jagan Teki 
> Reviewed-by: Sam Ravnborg 
> Tested-by: Bhushan Shah 
> Tested-by: Merlijn Wajer 
> ---
> Changes for v7:
> - rebase on master
> - collect Merlijn Tested-by
> - add tabs about drm timings
> Changes for v6:
> - add space b/w msleep and comment line
> - use multi comment line style
> - add sentinel
> - collect Sam Ravnborg Reviewed-by
> Changes for v5:
> - drop drmP.h header
> - order include files
> - add empty line after kzalloc()
> - drop gpio set for reset
> - drop backlight put_device from probe()
> - drop backlight put_device from remove()
> - collect Tested-by from Bhushan Shah
> Changes for v4:
> - rebase on master
> - adjust the hporch values to satisfy the refresh
> Changes for v3:
> - use simple structure for command init
> - update proper comments on power, reset delay sequnce
> - fix to use set_display_off in disable function
> - move mode type to structure
> - drop refres rate value, let drm compute
> Changes for v2:
> - new patch, derived from another dsi series

Pleas let me know if you any further comments on this?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tegra: vic: fix implicit function declaration warning

[Thierry Reding]

On Mon, Feb 18, 2019 at 12:00:50PM +0100, Anders Roxell wrote:
> When CONFIG_IOMMU_API isn't set the following warnings pops up:
> 
> drivers/gpu/drm/tegra/vic.c: In function ‘vic_boot’:
> drivers/gpu/drm/tegra/vic.c:110:31: error: implicit declaration of function 
> ‘dev_iommu_fwspec_get’; did you mean ‘iommu_fwspec_free’? 
> [-Werror=implicit-function-declaration]
>struct iommu_fwspec *spec = dev_iommu_fwspec_get(vic->dev);
>^~~~
>iommu_fwspec_free
> drivers/gpu/drm/tegra/vic.c:110:31: warning: initialization of ‘struct 
> iommu_fwspec *’ from ‘int’ makes pointer from integer without a cast 
> [-Wint-conversion]
> drivers/gpu/drm/tegra/vic.c:117:19: error: ‘struct iommu_fwspec’ has no 
> member named ‘num_ids’
>if (spec && spec->num_ids > 0) {
>^~
> drivers/gpu/drm/tegra/vic.c:118:16: error: ‘struct iommu_fwspec’ has no 
> member named ‘ids’
> value = spec->ids[0] & 0x;
> ^~
> 
> Rework so that its inside a '#ifdef CONFIG_IOMMU_API' block.
> 
> Fixes: f3779cb190a5 ("drm/tegra: vic: Support stream ID register programming")
> Signed-off-by: Anders Roxell 
> ---
>  drivers/gpu/drm/tegra/vic.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #23 from nmr  ---
Marek, is this even the right bug tracker for the kernel module or is this just
for user space?

-- 
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 v4 0/7] VSP1: Display writeback support

[Brian Starkey]

Hi Laurent,

On Sun, Feb 17, 2019 at 04:48:45AM +0200, Laurent Pinchart wrote:
> Hello,
> 
> This patch series implements display writeback support for the R-Car
> Gen3 platforms in the VSP1 driver.
> 
> DRM/KMS provides a writeback API through a special type of writeback
> connectors. This series takes a different approach by exposing writeback
> as a V4L2 device. While there is nothing fundamentally wrong with
> writeback connectors, display for R-Car Gen3 platforms relies on the
> VSP1 driver behind the scene, which already implements V4L2 support.
> Enabling writeback through V4L2 is thus significantly easier in this
> case.

How does this look to an application? (I'm entirely ignorant about
R-Car). They are interacting with the DRM device, and then need to
open and configure a v4l2 device to get the writeback? Can the process
which isn't controlling the DRM device independently capture the
screen output?

I didn't see any major complication to implementing this as a
writeback connector. If you want/need to use the vb2_queue, couldn't
you just do that entirely from within the kernel?

Honestly (predictably?), to me it seems like a bad idea to introduce a
second, non-compatible interface for display writeback. Any
application interested in display writeback (e.g. compositors) will
need to implement both in order to support all HW. drm_hwcomposer
already supports writeback via DRM writeback connectors.

While I can see the advantages of having writeback exposed via v4l2
for streaming use-cases, I think it would be better to have it done in
such a way that it works for all writeback connectors, rather than
being VSP1-specific. That would allow any application to choose
whichever method is most appropriate for their use-case, without
limiting themselves to a subset of hardware.

> 
> The writeback pixel format is restricted to RGB, due to the VSP1
> outputting RGB to the display and lacking a separate colour space
> conversion unit for writeback. The resolution can be freely picked by
> will result in cropping or composing, not scaling.
> 
> Writeback requests are queued to the hardware on page flip (atomic
> flush), and complete at the next vblank. This means that a queued
> writeback buffer will not be processed until the next page flip, but
> once it starts being written to by the VSP, it will complete at the next
> vblank regardless of whether another page flip occurs at that time.
> 

This sounds the same as mali-dp, and so fits directly with the
semantics of writeback connectors.

Thanks,
-Brian

> The code is based on a merge of the media master branch, the drm-next
> branch and the R-Car DT next branch. For convenience patches can be
> found at
> 
>   git://linuxtv.org/pinchartl/media.git v4l2/vsp1/writeback
> 
> Kieran Bingham (2):
>   Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
>   media: vsp1: Provide a writeback video device
> 
> Laurent Pinchart (5):
>   media: vsp1: wpf: Fix partition configuration for display pipelines
>   media: vsp1: Replace leftover occurrence of fragment with body
>   media: vsp1: Fix addresses of display-related registers for VSP-DL
>   media: vsp1: Refactor vsp1_video_complete_buffer() for later reuse
>   media: vsp1: Replace the display list internal flag with a flags field
> 
>  drivers/media/platform/vsp1/vsp1_dl.c| 118 --
>  drivers/media/platform/vsp1/vsp1_dl.h|   6 +-
>  drivers/media/platform/vsp1/vsp1_drm.c   |  24 ++-
>  drivers/media/platform/vsp1/vsp1_drv.c   |  17 +-
>  drivers/media/platform/vsp1/vsp1_pipe.c  |   5 +
>  drivers/media/platform/vsp1/vsp1_pipe.h  |   6 +
>  drivers/media/platform/vsp1/vsp1_regs.h  |   6 +-
>  drivers/media/platform/vsp1/vsp1_rwpf.h  |   2 +
>  drivers/media/platform/vsp1/vsp1_video.c | 198 +++
>  drivers/media/platform/vsp1/vsp1_video.h |   6 +
>  drivers/media/platform/vsp1/vsp1_wpf.c   |  65 ++--
>  11 files changed, 378 insertions(+), 75 deletions(-)
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm/radeon: remove set but not used variable 'vbi_time_out'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/radeon/si_dpm.c: In function 'si_program_response_times':
drivers/gpu/drm/radeon/si_dpm.c:3640:29: warning:
 variable 'backbias_response_time' set but not used [-Wunused-but-set-variable]

It never used since introduction.

Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/radeon/si_dpm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 0a785ef0ab66..de8bd245497f 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3637,14 +3637,13 @@ static int si_notify_smc_display_change(struct 
radeon_device *rdev,
 
 static void si_program_response_times(struct radeon_device *rdev)
 {
-   u32 voltage_response_time, backbias_response_time, acpi_delay_time, 
vbi_time_out;
+   u32 voltage_response_time, acpi_delay_time, vbi_time_out;
u32 vddc_dly, acpi_dly, vbi_dly;
u32 reference_clock;
 
si_write_smc_soft_register(rdev, SI_SMC_SOFT_REGISTER_mvdd_chg_time, 1);
 
voltage_response_time = (u32)rdev->pm.dpm.voltage_response_time;
-   backbias_response_time = (u32)rdev->pm.dpm.backbias_response_time;
 
if (voltage_response_time == 0)
voltage_response_time = 1000;



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm/qxl: remove set but not used variable 'bo_old'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/qxl/qxl_display.c: In function 'qxl_primary_atomic_update':
drivers/gpu/drm/qxl/qxl_display.c:538:17: warning:
 variable 'bo_old' set but not used [-Wunused-but-set-variable]

It's not used any more after 4979904c62b9 ("drm/qxl: use shadow bo directly")

Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/qxl/qxl_display.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 08c725544a2f..8b319ebbb0fb 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -535,7 +535,7 @@ static void qxl_primary_atomic_update(struct drm_plane 
*plane,
 {
struct qxl_device *qdev = plane->dev->dev_private;
struct qxl_bo *bo = gem_to_qxl_bo(plane->state->fb->obj[0]);
-   struct qxl_bo *bo_old, *primary;
+   struct qxl_bo *primary;
struct drm_clip_rect norect = {
.x1 = 0,
.y1 = 0,
@@ -544,12 +544,6 @@ static void qxl_primary_atomic_update(struct drm_plane 
*plane,
};
uint32_t dumb_shadow_offset = 0;
 
-   if (old_state->fb) {
-   bo_old = gem_to_qxl_bo(old_state->fb->obj[0]);
-   } else {
-   bo_old = NULL;
-   }
-
primary = bo->shadow ? bo->shadow : bo;
 
if (!primary->is_primary) {





___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/tegra: vic: fix implicit function declaration warning

[Anders Roxell]

When CONFIG_IOMMU_API isn't set the following warnings pops up:

drivers/gpu/drm/tegra/vic.c: In function ‘vic_boot’:
drivers/gpu/drm/tegra/vic.c:110:31: error: implicit declaration of function 
‘dev_iommu_fwspec_get’; did you mean ‘iommu_fwspec_free’? 
[-Werror=implicit-function-declaration]
   struct iommu_fwspec *spec = dev_iommu_fwspec_get(vic->dev);
   ^~~~
   iommu_fwspec_free
drivers/gpu/drm/tegra/vic.c:110:31: warning: initialization of ‘struct 
iommu_fwspec *’ from ‘int’ makes pointer from integer without a cast 
[-Wint-conversion]
drivers/gpu/drm/tegra/vic.c:117:19: error: ‘struct iommu_fwspec’ has no member 
named ‘num_ids’
   if (spec && spec->num_ids > 0) {
   ^~
drivers/gpu/drm/tegra/vic.c:118:16: error: ‘struct iommu_fwspec’ has no member 
named ‘ids’
value = spec->ids[0] & 0x;
^~

Rework so that its inside a '#ifdef CONFIG_IOMMU_API' block.

Fixes: f3779cb190a5 ("drm/tegra: vic: Support stream ID register programming")
Signed-off-by: Anders Roxell 
---
 drivers/gpu/drm/tegra/vic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index 39bfed9623de..982ce37ecde1 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -106,6 +106,7 @@ static int vic_boot(struct vic *vic)
if (vic->booted)
return 0;
 
+#ifdef CONFIG_IOMMU_API
if (vic->config->supports_sid) {
struct iommu_fwspec *spec = dev_iommu_fwspec_get(vic->dev);
u32 value;
@@ -121,6 +122,7 @@ static int vic_boot(struct vic *vic)
vic_writel(vic, value, VIC_THI_STREAMID1);
}
}
+#endif
 
/* setup clockgating registers */
vic_writel(vic, CG_IDLE_CG_DLY_CNT(4) |
-- 
2.19.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/11] drm/syncobj: add transition iotcls between binary and timeline

[Lionel Landwerlin]

Thanks guys :)

You mentioned that signaling out of order is illegal.
Is this illegal with regard to the vulkan spec or to the syncobj 
implementation?


I'm not finding anything in the vulkan spec that makes out of order 
signaling illegal.
That's why I came up with this test, just verifying that the timeline 
does not go backward in term of its payload.


-Lionel

On 18/02/2019 11:01, Koenig, Christian wrote:

Hi David,

well I think Lionel is testing the invalid signal order on purpose :)

Anyway we really need to handle invalid order graceful here. E.g. 
either the same way as during CS or we abort and return an error message.


I think just using the same approach as during CS ist the best we can do.

Regards,
Christian


Am 18.02.2019 11:35 schrieb "Zhou, David(ChunMing)" :

Hi Lionel,

I checked your igt test case,

uint64_t points[5] = { 1, 5, 3, 7, 6 };

which is illegal signal order.

I must admit we should handle it gracefully if signal isn't in-order, 
and we shouldn't lead to deadlock.


Hi Christian,

Can we just ignore when signal point X <= timeline Y? Or just give a 
warning?


Otherwise like Lionel's unexpected use cases, which easily leads to 
deadlock.



-David


On 2019年02月15日 22:28, Lionel Landwerlin wrote:

Hi David,

Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9

Trying to kill the deadlocked process I got this backtrace :


[   33.969136] [IGT] syncobj_timeline: starting subtest signal-order
[   60.452823] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[syncobj_timelin:2021]
[   60.452826] Modules linked in: rfcomm cmac bnep binfmt_misc
nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio sch_fq_codel ib_iser snd_hda_intel
rdma_cm iw_cm snd_hda_codec ib_cm snd_hda_core snd_hwdep intel_rapl
snd_pcm ib_core x86_pkg_temp_thermal intel_powerclamp configf
s coretemp iscsi_tcp snd_seq_midi libiscsi_tcp snd_seq_midi_event
libiscsi kvm_intel scsi_transport_iscsi kvm btusb snd_rawmidi irqbypass
btrtl intel_cstate intel_rapl_perf btbcm btintel bluetooth snd_seq
snd_seq_device snd_timer input_leds ecdh_generic snd soundcore mei_me
mei intel_pch_thermal mac_hid acpi_pad parp
ort_pc ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_decompress
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
hid_generic usbhid hid i915 crct10dif_pclmul crc32_pclmul i2c_algo_bit
ghash_clmulni_intel prime_numbers
drm_kms_helper aesni_intel syscopyarea sysfillrect
[   60.452876]  sysimgblt fb_sys_fops aes_x86_64 crypto_simd sdhci_pci
cryptd drm e1000e glue_helper cqhci sdhci wmi video
[   60.452881] CPU: 6 PID: 2021 Comm: syncobj_timelin Tainted: G
U    5.0.0-rc5+ #337
[   60.452882] Hardware name:  /NUC6i7KYB, BIOS
KYSKLi70.86A.0042.2016.0929.1933 09/29/2016
[   60.452886] RIP: 0010:dma_fence_chain_walk+0x22c/0x260
[   60.452888] Code: ff e9 93 fe ff ff 48 8b 45 08 48 8b 40 18 48 85 c0
74 0c 48 89 ef e8 33 0f 58 00 84 c0 75 23 f0 41 ff 4d 00 0f 88 99 87 2f
00 <0f> 85 05 fe ff ff 4c 89 ef e8 56 ea ff ff 48 89 d8 5b 5d 41 5c 41
[   60.452888] RSP: 0018:9a5804653ca8 EFLAGS: 00010296 ORIG_RAX:
ff13
[   60.452889] RAX:  RBX: 8f5690fb2480 RCX:
8f5690fb2f00
[   60.452890] RDX: 003e3730 RSI:  RDI:
8f5690fb2180
[   60.452891] RBP: 8f5690fb2180 R08:  R09:
8f5690fb2eb0
[   60.452891] R10:  R11: 8f5660469860 R12:
8f5690fb2f68
[   60.452892] R13: 8f5690fb2f00 R14: 0003 R15:
8f5655a45fc0
[   60.452913] FS:  7fdc5c459980() GS:8f569eb8()
knlGS:
[   60.452913] CS:  0010 DS:  ES:  CR0: 80050033
[   60.452914] CR2: 7f9d74336dd8 CR3: 00084a67e004 CR4:
003606e0
[   60.452915] DR0:  DR1:  DR2:

[   60.452915] DR3:  DR6: fffe0ff0 DR7:
0400
[   60.452916] Call Trace:
[   60.452958]  drm_syncobj_add_point+0x102/0x160 [drm]
[   60.452965]  ? drm_syncobj_fd_to_handle_ioctl+0x1b0/0x1b0 [drm]
[   60.452971]  drm_syncobj_transfer_ioctl+0x10f/0x180 [drm]
[   60.452978]  drm_ioctl_kernel+0xac/0xf0 [drm]
[   60.452984]  drm_ioctl+0x2eb/0x3b0 [drm]
[   60.452990]  ? drm_syncobj_fd_to_handle_ioctl+0x1b0/0x1b0 [drm]
[   60.452992]  ? sw_sync_ioctl+0x347/0x370
[   60.452994]  do_vfs_ioctl+0xa4/0x640
[   60.452995]  ? __fput+0x134/0x220
[   60.452997]  ? do_fcntl+0x1a5/0x650
[   60.452998]  ksys_ioctl+0x70/0x80
[   60.452999]  __x64_sys_ioctl+0x16/0x20
[   60.453002]  do_syscall_64+0x55/0x110
[   60.453004]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   60.453005] RIP: 0033:0x7fdc5b6e45d7
[ 

Re: [EARLY RFC][PATCH 0/4] ION per heap devices

[Brian Starkey]

Hi John,

On Fri, Feb 15, 2019 at 12:24:08PM -0800, John Stultz wrote:
> This is a *very early RFC* (it builds, that's all I'll say :)
> but I wanted to share it to get some initial feedback before I
> go down the rabit hole of trying to adapt the Android userland
> code to get this fully validated.
> 
> This patchset tries to implement the per-heap devices for ION.
> The main benefit is that it avoids multiplexing heap operations
> through the /dev/ion interface, and allows for each heap to have
> its own permissions/sepolicy rules.

In general, I've always thought that having a device node per-heap is
a bit messy for userspace. Multiplexing through the single node
doesn't seem like an insurmountable problem, but the point about
permissions/sepolicy is reasonably compelling if it's a real
requirement. What would be the reasons for that?

Thanks,
-Brian

> 
> Feedback would be greatly appreciated!
> thanks
> -john
> 
> Cc: Laura Abbott 
> Cc: Sumit Semwal 
> Cc: Liam Mark 
> Cc: Brian Starkey 
> Cc: Andrew F. Davis 
> Cc: Alistair Strachan 
> Cc: dri-devel@lists.freedesktop.org
> 
> John Stultz (4):
>   ion: Add ION_VERSION ioctl
>   ion: Initial hack to create per heap devices
>   ion: Add HEAP_INFO ioctl to be able to fetch heap type
>   ion: Make "legacy" /dev/ion support optional
> 
>  drivers/staging/android/ion/Kconfig |  7 +++
>  drivers/staging/android/ion/ion-ioctl.c | 80 
> +
>  drivers/staging/android/ion/ion.c   | 51 -
>  drivers/staging/android/ion/ion.h   |  6 +++
>  drivers/staging/android/uapi/ion.h  | 57 +++
>  5 files changed, 191 insertions(+), 10 deletions(-)
> 
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/11] drm/syncobj: add timeline payload query ioctl v4

[Lionel Landwerlin]

On 18/02/2019 07:28, Koenig, Christian wrote:

Am 18.02.19 um 04:10 schrieb zhoucm1:


On 2019年02月17日 03:22, Christian König wrote:

Am 15.02.19 um 20:31 schrieb Lionel Landwerlin via amd-gfx:

On 07/12/2018 09:55, Chunming Zhou wrote:

user mode can query timeline payload.
v2: check return value of copy_to_user
v3: handle querying entry by entry
v4: rebase on new chain container, simplify interface

Signed-off-by: Chunming Zhou 
Cc: Daniel Rakos 
Cc: Jason Ekstrand 
Cc: Bas Nieuwenhuizen 
Cc: Dave Airlie 
Cc: Christian König 
Cc: Chris Wilson 
---
   drivers/gpu/drm/drm_internal.h |  2 ++
   drivers/gpu/drm/drm_ioctl.c    |  2 ++
   drivers/gpu/drm/drm_syncobj.c  | 43
++
   include/uapi/drm/drm.h | 10 
   4 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h
b/drivers/gpu/drm/drm_internal.h
index 18b41e10195c..dab4d5936441 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -184,6 +184,8 @@ int drm_syncobj_reset_ioctl(struct drm_device
*dev, void *data,
   struct drm_file *file_private);
   int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
    struct drm_file *file_private);
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+    struct drm_file *file_private);
     /* drm_framebuffer.c */
   void drm_framebuffer_print_info(struct drm_printer *p, unsigned
int indent,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index a9a17ed35cc4..7578ef6dc1d1 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -681,6 +681,8 @@ static const struct drm_ioctl_desc drm_ioctls[]
= {
     DRM_UNLOCKED|DRM_RENDER_ALLOW),
   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL,
drm_syncobj_signal_ioctl,
     DRM_UNLOCKED|DRM_RENDER_ALLOW),
+    DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
+  DRM_UNLOCKED|DRM_RENDER_ALLOW),
   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE,
drm_crtc_get_sequence_ioctl, DRM_UNLOCKED),
   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE,
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
   DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE,
drm_mode_create_lease_ioctl, DRM_MASTER|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index 348079bb0965..f97fa00ca1d0 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1061,3 +1061,46 @@ drm_syncobj_signal_ioctl(struct drm_device
*dev, void *data,
     return ret;
   }
+
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+    struct drm_file *file_private)
+{
+    struct drm_syncobj_timeline_array *args = data;
+    struct drm_syncobj **syncobjs;
+    uint64_t __user *points = u64_to_user_ptr(args->points);
+    uint32_t i;
+    int ret;
+
+    if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+    return -ENODEV;
+
+    if (args->pad != 0)
+    return -EINVAL;
+
+    if (args->count_handles == 0)
+    return -EINVAL;
+
+    ret = drm_syncobj_array_find(file_private,
+ u64_to_user_ptr(args->handles),
+ args->count_handles,
+ &syncobjs);
+    if (ret < 0)
+    return ret;
+
+    for (i = 0; i < args->count_handles; i++) {
+    struct dma_fence_chain *chain;
+    struct dma_fence *fence;
+    uint64_t point;
+
+    fence = drm_syncobj_fence_get(syncobjs[i]);
+    chain = to_dma_fence_chain(fence);
+    point = chain ? fence->seqno : 0;


Sorry, I don' t want to sound annoying, but this looks like this
could report values going backward.

Well please be annoying as much as you can :) But yeah all that stuff
has been discussed before as well.


Anything add a point X to a timeline that has reached value Y with X
< Y would trigger that.

Yes, that can indeed happen.

trigger what? when adding x (x < y), then return 0 when query?
Why would this happen?
No, syncobj->fence should always be there and the last chain node, if
it is ever added.

Well maybe Lionel should clarify a bit what he means?

I thought he is concerned that the call could return values where X < Y,
but that doesn't seem to be the case.

Christian.



I meant something like this :


t = create_timeline_syncobj()

signal(t, 2)

query(t) => 2

signal(t, 1)

query(t) => 1


-Lionel






-David

But adding a timeline point X which is before the already added point
Y is illegal in the first place :)

So when the application does something stupid and breaks it can just
keep the pieces.

In the kernel we still do the most defensive thing and sync to
everything in this case.

I'm just not sure if we should print an error into syslog or just
continue silently.

Regards,
Christian.


Either through the submission or userspace signaling or importing
another syncpoint's fence.


-Lionel



+    ret = copy_to_user(&points[i], &point, sizeof(uint6

Re: [PATCH v2] staging: android: ion: Allocate from heap ID directly without mask

[Brian Starkey]

On Fri, Feb 15, 2019 at 11:01:59AM -0800, John Stultz wrote:
> On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey  wrote:
> >
> > Hi John,
> >
> > On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
> > >
> > [snip]
> >
> > > Some thoughts, as this ABI break has the potential to be pretty painful.
> > >
> > > 1) Unfortunately, this ABI is exposed *through* libion via
> > > ion_alloc/ion_alloc_fd out to gralloc implementations. Which means it
> > > will have a wider impact to vendor userland code.
> >
> > I figured libion could fairly easily loop through all the set bits in
> > heap_mask and call the ioctl for each until it succeeds. That
> > preserves the old behaviour from the libion clients' perspective.
> 
> Potentially, though that implicitly still caps the heaps to 32.  So
> I'm not sure what the net benefit would be.
> 

It's purely a transitionary compatibility measure. Users of the old
API inherit the old limitation - they shouldn't care about that.

Alongside it, we'd want to add new function(s) exposing whatever the
new API is.

Cheers,
-Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: panel-orientation-quirks: Get rid of superfluous (void *) casting

[Jani Nikula]

On Sat, 16 Feb 2019, David Santamaría Rogado  wrote:
> From: howl 
>
> The (void *) casting in the driver_data variable assignment is superfluous.
> Spotted by Jani Nikula.
>
> Signed-off-by: David Santamaría Rogado 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/drm_panel_orientation_quirks.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index 52e445bb1aa5..61d3361381b7 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -86,13 +86,13 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Acer"),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"),
>   },
> - .driver_data = (void *)&acer_s1003,
> + .driver_data = &acer_s1003,
>   }, {/* Asus T100HA */
>   .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
>   },
> - .driver_data = (void *)&asus_t100ha,
> + .driver_data = &asus_t100ha,
>   }, {/*
>* GPD Pocket, note that the the DMI data is less generic then
>* it seems, devices with a board-vendor of "AMI Corporation"
> @@ -105,7 +105,7 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
>   },
> - .driver_data = (void *)&gpd_pocket,
> + .driver_data = &gpd_pocket,
>   }, {/* GPD Win (same note on DMI match as GPD Pocket) */
>   .matches = {
> DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
> @@ -113,7 +113,7 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
>   },
> - .driver_data = (void *)&gpd_win,
> + .driver_data = &gpd_win,
>   }, {/* GPD Win 2 (too generic strings, also match on bios date) */
>   .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
> @@ -121,7 +121,7 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
> DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
>   },
> - .driver_data = (void *)&gpd_win2,
> + .driver_data = &gpd_win2,
>   }, {/* I.T.Works TW891 */
>   .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."),
> @@ -129,7 +129,7 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "To be filled by O.E.M."),
> DMI_EXACT_MATCH(DMI_BOARD_NAME, "TW891"),
>   },
> - .driver_data = (void *)&itworks_tw891,
> + .driver_data = &itworks_tw891,
>   }, {/*
>* Lenovo Ideapad Miix 310 laptop, only some production batches
>* have a portrait screen, the resolution checks makes the quirk
> @@ -140,20 +140,20 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80SG"),
> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "MIIX 310-10ICR"),
>   },
> - .driver_data = (void *)&lcd800x1280_rightside_up,
> + .driver_data = &lcd800x1280_rightside_up,
>   }, {/* Lenovo Ideapad Miix 320 */
>   .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80XF"),
> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX 320-10ICR"),
>   },
> - .driver_data = (void *)&lcd800x1280_rightside_up,
> + .driver_data = &lcd800x1280_rightside_up,
>   }, {/* VIOS LTH17 */
>   .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "LTH17"),
>   },
> - .driver_data = (void *)&lcd800x1280_rightside_up,
> + .driver_data = &lcd800x1280_rightside_up,
>   },
>   {}
>  };

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/11] drm/syncobj: add transition iotcls between binary and timeline

[Koenig, Christian]

Hi David,

well I think Lionel is testing the invalid signal order on purpose :)

Anyway we really need to handle invalid order graceful here. E.g. either the 
same way as during CS or we abort and return an error message.

I think just using the same approach as during CS ist the best we can do.

Regards,
Christian


Am 18.02.2019 11:35 schrieb "Zhou, David(ChunMing)" :

Hi Lionel,

I checked your igt test case,

uint64_t points[5] = { 1, 5, 3, 7, 6 };

which is illegal signal order.

I must admit we should handle it gracefully if signal isn't in-order, and we 
shouldn't lead to deadlock.

Hi Christian,

Can we just ignore when signal point X <= timeline Y? Or just give a warning?

Otherwise like Lionel's unexpected use cases, which easily leads to deadlock.


-David

On 2019年02月15日 22:28, Lionel Landwerlin wrote:

Hi David,

Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9

Trying to kill the deadlocked process I got this backtrace :


[   33.969136] [IGT] syncobj_timeline: starting subtest signal-order
[   60.452823] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[syncobj_timelin:2021]
[   60.452826] Modules linked in: rfcomm cmac bnep binfmt_misc
nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio sch_fq_codel ib_iser snd_hda_intel
rdma_cm iw_cm snd_hda_codec ib_cm snd_hda_core snd_hwdep intel_rapl
snd_pcm ib_core x86_pkg_temp_thermal intel_powerclamp configf
s coretemp iscsi_tcp snd_seq_midi libiscsi_tcp snd_seq_midi_event
libiscsi kvm_intel scsi_transport_iscsi kvm btusb snd_rawmidi irqbypass
btrtl intel_cstate intel_rapl_perf btbcm btintel bluetooth snd_seq
snd_seq_device snd_timer input_leds ecdh_generic snd soundcore mei_me
mei intel_pch_thermal mac_hid acpi_pad parp
ort_pc ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_decompress
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
hid_generic usbhid hid i915 crct10dif_pclmul crc32_pclmul i2c_algo_bit
ghash_clmulni_intel prime_numbers
drm_kms_helper aesni_intel syscopyarea sysfillrect
[   60.452876]  sysimgblt fb_sys_fops aes_x86_64 crypto_simd sdhci_pci
cryptd drm e1000e glue_helper cqhci sdhci wmi video
[   60.452881] CPU: 6 PID: 2021 Comm: syncobj_timelin Tainted: G
U5.0.0-rc5+ #337
[   60.452882] Hardware name:  /NUC6i7KYB, BIOS
KYSKLi70.86A.0042.2016.0929.1933 09/29/2016
[   60.452886] RIP: 0010:dma_fence_chain_walk+0x22c/0x260
[   60.452888] Code: ff e9 93 fe ff ff 48 8b 45 08 48 8b 40 18 48 85 c0
74 0c 48 89 ef e8 33 0f 58 00 84 c0 75 23 f0 41 ff 4d 00 0f 88 99 87 2f
00 <0f> 85 05 fe ff ff 4c 89 ef e8 56 ea ff ff 48 89 d8 5b 5d 41 5c 41
[   60.452888] RSP: 0018:9a5804653ca8 EFLAGS: 00010296 ORIG_RAX:
ff13
[   60.452889] RAX:  RBX: 8f5690fb2480 RCX:
8f5690fb2f00
[   60.452890] RDX: 003e3730 RSI:  RDI:
8f5690fb2180
[   60.452891] RBP: 8f5690fb2180 R08:  R09:
8f5690fb2eb0
[   60.452891] R10:  R11: 8f5660469860 R12:
8f5690fb2f68
[   60.452892] R13: 8f5690fb2f00 R14: 0003 R15:
8f5655a45fc0
[   60.452913] FS:  7fdc5c459980() GS:8f569eb8()
knlGS:
[   60.452913] CS:  0010 DS:  ES:  CR0: 80050033
[   60.452914] CR2: 7f9d74336dd8 CR3: 00084a67e004 CR4:
003606e0
[   60.452915] DR0:  DR1:  DR2:

[   60.452915] DR3:  DR6: fffe0ff0 DR7:
0400
[   60.452916] Call Trace:
[   60.452958]  drm_syncobj_add_point+0x102/0x160 [drm]
[   60.452965]  ? drm_syncobj_fd_to_handle_ioctl+0x1b0/0x1b0 [drm]
[   60.452971]  drm_syncobj_transfer_ioctl+0x10f/0x180 [drm]
[   60.452978]  drm_ioctl_kernel+0xac/0xf0 [drm]
[   60.452984]  drm_ioctl+0x2eb/0x3b0 [drm]
[   60.452990]  ? drm_syncobj_fd_to_handle_ioctl+0x1b0/0x1b0 [drm]
[   60.452992]  ? sw_sync_ioctl+0x347/0x370
[   60.452994]  do_vfs_ioctl+0xa4/0x640
[   60.452995]  ? __fput+0x134/0x220
[   60.452997]  ? do_fcntl+0x1a5/0x650
[   60.452998]  ksys_ioctl+0x70/0x80
[   60.452999]  __x64_sys_ioctl+0x16/0x20
[   60.453002]  do_syscall_64+0x55/0x110
[   60.453004]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   60.453005] RIP: 0033:0x7fdc5b6e45d7
[   60.453006] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00
48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48
[   60.453007] RSP: 002b:7fff25c4d198 EFLAGS: 0206 ORIG_RAX:
0010
[   60.453008] RAX: ffda RBX:  RCX:
7fdc5b6e45d7
[   60.453008] RDX: 7fff25c4d200 RSI: 00

Re: [PATCH 09/11] drm/syncobj: add transition iotcls between binary and timeline

[zhoucm1]

Hi Lionel,

I checked your igt test case,

uint64_t points[5] = { 1, 5, 3, 7, 6 };

which is illegal signal order.

I must admit we should handle it gracefully if signal isn't in-order, 
and we shouldn't lead to deadlock.


Hi Christian,

Can we just ignore when signal point X <= timeline Y? Or just give a 
warning?


Otherwise like Lionel's unexpected use cases, which easily leads to 
deadlock.



-David


On 2019年02月15日 22:28, Lionel Landwerlin wrote:

Hi David,

Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9

Trying to kill the deadlocked process I got this backtrace :


[   33.969136] [IGT] syncobj_timeline: starting subtest signal-order
[   60.452823] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[syncobj_timelin:2021]
[   60.452826] Modules linked in: rfcomm cmac bnep binfmt_misc
nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio sch_fq_codel ib_iser snd_hda_intel
rdma_cm iw_cm snd_hda_codec ib_cm snd_hda_core snd_hwdep intel_rapl
snd_pcm ib_core x86_pkg_temp_thermal intel_powerclamp configf
s coretemp iscsi_tcp snd_seq_midi libiscsi_tcp snd_seq_midi_event
libiscsi kvm_intel scsi_transport_iscsi kvm btusb snd_rawmidi irqbypass
btrtl intel_cstate intel_rapl_perf btbcm btintel bluetooth snd_seq
snd_seq_device snd_timer input_leds ecdh_generic snd soundcore mei_me
mei intel_pch_thermal mac_hid acpi_pad parp
ort_pc ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_decompress
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
hid_generic usbhid hid i915 crct10dif_pclmul crc32_pclmul i2c_algo_bit
ghash_clmulni_intel prime_numbers
drm_kms_helper aesni_intel syscopyarea sysfillrect
[   60.452876]  sysimgblt fb_sys_fops aes_x86_64 crypto_simd sdhci_pci
cryptd drm e1000e glue_helper cqhci sdhci wmi video
[   60.452881] CPU: 6 PID: 2021 Comm: syncobj_timelin Tainted: G
U    5.0.0-rc5+ #337
[   60.452882] Hardware name:  /NUC6i7KYB, BIOS
KYSKLi70.86A.0042.2016.0929.1933 09/29/2016
[   60.452886] RIP: 0010:dma_fence_chain_walk+0x22c/0x260
[   60.452888] Code: ff e9 93 fe ff ff 48 8b 45 08 48 8b 40 18 48 85 c0
74 0c 48 89 ef e8 33 0f 58 00 84 c0 75 23 f0 41 ff 4d 00 0f 88 99 87 2f
00 <0f> 85 05 fe ff ff 4c 89 ef e8 56 ea ff ff 48 89 d8 5b 5d 41 5c 41
[   60.452888] RSP: 0018:9a5804653ca8 EFLAGS: 00010296 ORIG_RAX:
ff13
[   60.452889] RAX:  RBX: 8f5690fb2480 RCX:
8f5690fb2f00
[   60.452890] RDX: 003e3730 RSI:  RDI:
8f5690fb2180
[   60.452891] RBP: 8f5690fb2180 R08:  R09:
8f5690fb2eb0
[   60.452891] R10:  R11: 8f5660469860 R12:
8f5690fb2f68
[   60.452892] R13: 8f5690fb2f00 R14: 0003 R15:
8f5655a45fc0
[   60.452913] FS:  7fdc5c459980() GS:8f569eb8()
knlGS:
[   60.452913] CS:  0010 DS:  ES:  CR0: 80050033
[   60.452914] CR2: 7f9d74336dd8 CR3: 00084a67e004 CR4:
003606e0
[   60.452915] DR0:  DR1:  DR2:

[   60.452915] DR3:  DR6: fffe0ff0 DR7:
0400
[   60.452916] Call Trace:
[   60.452958]  drm_syncobj_add_point+0x102/0x160 [drm]
[   60.452965]  ? drm_syncobj_fd_to_handle_ioctl+0x1b0/0x1b0 [drm]
[   60.452971]  drm_syncobj_transfer_ioctl+0x10f/0x180 [drm]
[   60.452978]  drm_ioctl_kernel+0xac/0xf0 [drm]
[   60.452984]  drm_ioctl+0x2eb/0x3b0 [drm]
[   60.452990]  ? drm_syncobj_fd_to_handle_ioctl+0x1b0/0x1b0 [drm]
[   60.452992]  ? sw_sync_ioctl+0x347/0x370
[   60.452994]  do_vfs_ioctl+0xa4/0x640
[   60.452995]  ? __fput+0x134/0x220
[   60.452997]  ? do_fcntl+0x1a5/0x650
[   60.452998]  ksys_ioctl+0x70/0x80
[   60.452999]  __x64_sys_ioctl+0x16/0x20
[   60.453002]  do_syscall_64+0x55/0x110
[   60.453004]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   60.453005] RIP: 0033:0x7fdc5b6e45d7
[   60.453006] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00
48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48
[   60.453007] RSP: 002b:7fff25c4d198 EFLAGS: 0206 ORIG_RAX:
0010
[   60.453008] RAX: ffda RBX:  RCX:
7fdc5b6e45d7
[   60.453008] RDX: 7fff25c4d200 RSI: c02064cc RDI:
0003
[   60.453009] RBP: 7fff25c4d1d0 R08:  R09:
001e
[   60.453010] R10:  R11: 0206 R12:
563d3959e4d0
[   60.453010] R13: 7fff25c4d620 R14:  R15:

[   88.447359] watchdog: BUG: soft lockup - CPU#6 stuck for 22s!
[syncobj_timelin:2021]

Re: [PATCH v3 0/8] drm/sun4i: dsi: Add burst mode support

[Jagan Teki]

Hi Paul and Maxime,

On Mon, Feb 18, 2019 at 1:56 PM Paul Kocialkowski
 wrote:
>
> Hi Jagan,
>
> On Fri, 2019-02-15 at 22:37 +0530, Jagan Teki wrote:
> > Hi Maxime,
> >
> > On 15/02/19 8:10 PM, Jagan Teki wrote:
> > >
> > > On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard,  > > > wrote:
> > >
> > > On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
> > >  > Hi,
> > >  >
> > >  > Here is a series implementing the burst mode support for DSI.
> > >  >
> > >  > It's been tested on an A33 board with the panel supported on the 
> > > last
> > >  > patch, which should remove all quirks due to a different SoC from 
> > > the
> > >  > equation.
> > >
> > > I should have sent that mail yesterday, but patches 1-4 and 6-7 were
> > > merged. Patch 5 was discarded since it was not consistent with the
> > > rest of the driver, and 8 had some comments.
> > >
> > >
> > > Are the applied patches from this series or from my v7 series?
> > >
> > >   Would you please point me the branch.
> > >
> >
> > Unfortunately my last mail didn't reach arm mailing list.
> >
> > Just wanted to know are the applied patches from this series or from my
> > v7 series? Would you please point me the repo, I couldn't find it on
> > git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
>
> This series is the one that was applied upstream. You can find the
> commits merged at: https://cgit.freedesktop.org/drm/drm-misc/log/

Thanks for sharing the link Paul.

This is really really discouraging.

Don't know whom to ask directly about this, but I am really upset
about this move.

Most of the changes from applied series have similar patches that are
been part of my series of patches. I've been sending this since last
September (which was sent way prior than this series).

How come the same series is recreated and applied with minor changes
while the original series was still in discussion. At least Maxime
should have informed me or he should have rejected my work from
patchwork or atleast NAK in ML?

All these burst changes and random fixes are reviewed in couple of
versions, now the versioning moved to v8[1] [2]. For each and every
versioning I'm trying to fix the previous version comments, code
improvements, commit messages. In fact for each rotation I'm trying to
validate 4 different panels which eventually consume all my 16 hours
in day.

Please let me know to how could we better collaborate?

[2] https://patchwork.kernel.org/cover/10813573/
[1] https://patchwork.kernel.org/cover/10813623/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Thomas Hellstrom]

On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
> Another good question is also why the heck the acc_size counts
> towards 
> the DMA32 zone?

DMA32 TTM pages are accounted in the DMA32 zone. Other pages are not.

For small persistent allocations using ttm_mem_global_alloc(), they are
accounted also in the DMA32 zone, which may cause over-accounting of
that zone, but that's pretty unlikely to be a big problem..

/Thomas





> 
> In other words why should the internal bookkeeping pages be allocated
> in 
> the DMA32 zone?
> 
> That doesn't sounds valid to me in any way,
> Christian.
> 
> Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:
> > Hmm,
> > 
> > This zone was intended to stop TTM page allocations from
> > exhausting 
> > the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by default,
> > which 
> > means if we drop this check, other devices may stop functioning 
> > unexpectedly?
> > 
> > However, in the end I'd expect the kernel page allocation system
> > to 
> > make sure there are some pages left in the DMA32 zone, otherwise 
> > random non-IO page allocations would also potentially exhaust the 
> > DMA32 zone without anybody caring, which means removing this zone 
> > wouldn't be any worse than whatever other subsystems may be doing 
> > already...
> > 
> > /Thomas
> > 
> > 
> > On 2/16/19 12:02 AM, Kuehling, Felix wrote:
> > > This is an RFC. I'm not sure this is the right solution, but it
> > > highlights the problem I'm trying to solve.
> > > 
> > > The dma32_zone limits the acc_size of all allocated BOs to 2GB.
> > > On a
> > > 64-bit system with hundreds of GB of system memory and GPU
> > > memory,
> > > this can become a bottle neck. We're seeing TTM memory allocation
> > > failures not because we're truly out of memory, but because we're
> > > out of space in the dma32_zone for the acc_size needed for our BO
> > > book-keeping.
> > > 
> > > Signed-off-by: Felix Kuehling 
> > > CC: thellst...@vmware.com
> > > CC: christian.koe...@amd.com
> > > ---
> > >   drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/ttm/ttm_memory.c 
> > > b/drivers/gpu/drm/ttm/ttm_memory.c
> > > index f1567c3..bb05365 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_memory.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_memory.c
> > > @@ -363,7 +363,7 @@ static int ttm_mem_init_highmem_zone(struct 
> > > ttm_mem_global *glob,
> > >   glob->zones[glob->num_zones++] = zone;
> > >   return 0;
> > >   }
> > > -#else
> > > +#elifndef CONFIG_64BIT
> > >   static int ttm_mem_init_dma32_zone(struct ttm_mem_global *glob,
> > >  const struct sysinfo *si)
> > >   {
> > > @@ -441,7 +441,7 @@ int ttm_mem_global_init(struct ttm_mem_global
> > > *glob)
> > >   ret = ttm_mem_init_highmem_zone(glob, &si);
> > >   if (unlikely(ret != 0))
> > >   goto out_no_zone;
> > > -#else
> > > +#elifndef CONFIG_64BIT
> > >   ret = ttm_mem_init_dma32_zone(glob, &si);
> > >   if (unlikely(ret != 0))
> > >   goto out_no_zone;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Koenig, Christian]

Another good question is also why the heck the acc_size counts towards 
the DMA32 zone?

In other words why should the internal bookkeeping pages be allocated in 
the DMA32 zone?

That doesn't sounds valid to me in any way,
Christian.

Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:
> Hmm,
>
> This zone was intended to stop TTM page allocations from exhausting 
> the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by default, which 
> means if we drop this check, other devices may stop functioning 
> unexpectedly?
>
> However, in the end I'd expect the kernel page allocation system to 
> make sure there are some pages left in the DMA32 zone, otherwise 
> random non-IO page allocations would also potentially exhaust the 
> DMA32 zone without anybody caring, which means removing this zone 
> wouldn't be any worse than whatever other subsystems may be doing 
> already...
>
> /Thomas
>
>
> On 2/16/19 12:02 AM, Kuehling, Felix wrote:
>> This is an RFC. I'm not sure this is the right solution, but it
>> highlights the problem I'm trying to solve.
>>
>> The dma32_zone limits the acc_size of all allocated BOs to 2GB. On a
>> 64-bit system with hundreds of GB of system memory and GPU memory,
>> this can become a bottle neck. We're seeing TTM memory allocation
>> failures not because we're truly out of memory, but because we're
>> out of space in the dma32_zone for the acc_size needed for our BO
>> book-keeping.
>>
>> Signed-off-by: Felix Kuehling 
>> CC: thellst...@vmware.com
>> CC: christian.koe...@amd.com
>> ---
>>   drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c 
>> b/drivers/gpu/drm/ttm/ttm_memory.c
>> index f1567c3..bb05365 100644
>> --- a/drivers/gpu/drm/ttm/ttm_memory.c
>> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
>> @@ -363,7 +363,7 @@ static int ttm_mem_init_highmem_zone(struct 
>> ttm_mem_global *glob,
>>   glob->zones[glob->num_zones++] = zone;
>>   return 0;
>>   }
>> -#else
>> +#elifndef CONFIG_64BIT
>>   static int ttm_mem_init_dma32_zone(struct ttm_mem_global *glob,
>>  const struct sysinfo *si)
>>   {
>> @@ -441,7 +441,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
>>   ret = ttm_mem_init_highmem_zone(glob, &si);
>>   if (unlikely(ret != 0))
>>   goto out_no_zone;
>> -#else
>> +#elifndef CONFIG_64BIT
>>   ret = ttm_mem_init_dma32_zone(glob, &si);
>>   if (unlikely(ret != 0))
>>   goto out_no_zone;
>
>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/audio: declaration of struct device

[Daniel Vetter]

On Sat, Feb 16, 2019 at 10:34:59AM +0530, Ramalingam C wrote:
> Header has used the references to struct device without it definition
> or declaration. Hence resulting in compilation warning such as
> 
>   "'struct device' declared inside parameter list..."
> 
> This changes adds a declaration to struct device in the header to avoid
> any such warnings.
> 
> Signed-off-by: Ramalingam C 
> cc: Takashi Iwai 
> cc: Daniel Vetter 

Ok, I'll pick this one up for the mei-hdcp topic branch too.
-Daniel

> ---
>  include/drm/drm_audio_component.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/drm/drm_audio_component.h 
> b/include/drm/drm_audio_component.h
> index d0c7444319f5..a45f93487039 100644
> --- a/include/drm/drm_audio_component.h
> +++ b/include/drm/drm_audio_component.h
> @@ -5,6 +5,7 @@
>  #define _DRM_AUDIO_COMPONENT_H_
>  
>  struct drm_audio_component;
> +struct device;
>  
>  /**
>   * struct drm_audio_component_ops - Ops implemented by DRM driver, called by 
> hda driver
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 202537] amdgpu/DC failed to reserve new abo buffer before flip

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=202537

--- Comment #19 from Christian König (christian.koe...@amd.com) ---
(In reply to Paul Menzel from comment #18)
> (In reply to Christian König from comment #17)
> > We completely disabled the feature added in "5d35ed4832d" for upstreaming
> > later on.
> 
> Sorry, I do not understand your reply at all. Could you please rephrase?
> What commit does that, what you describe?

Commit 5d35ed4832d is a bug fix for bulk moves, which is a feature which should
be completely disabled in 4.20. So your bisecting is most likely incorrect.

> > Can you guys please test amd-staging-drm-next as well and check if the
> > problem occurs there as well. If not then please bisect what fixed it.
> 
> Bernd and I seem to have different problems – or I updated user space not
> triggering the problematic path anymore or did not do the steps to reproduce
> it (although starting GDM should have been enough).
> 
> Anyway, why should the fix be bisected? To apply it to stable?

Yes, exactly.

It looks like that 4.20 is either using bulk moves (which it shouldn't) or we
have introduced another problem which also caused memory leaks.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_vm: Mark expected switch fall-throughs

[Daniel Vetter]

On Fri, Feb 15, 2019 at 11:05:46AM -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
> 
> Warning level 3 was used: -Wimplicit-fallthrough=3
> 
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
> 
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
> 
> Signed-off-by: Gustavo A. R. Silva 

Queued for 5.2, thanks for your patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_vm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index c3301046dfaa..8987501f53b2 100644
> --- a/drivers/gpu/drm/drm_vm.c
> +++ b/drivers/gpu/drm/drm_vm.c
> @@ -584,8 +584,8 @@ static int drm_mmap_locked(struct file *filp, struct 
> vm_area_struct *vma)
>   vma->vm_ops = &drm_vm_ops;
>   break;
>   }
> - /* fall through to _DRM_FRAME_BUFFER... */
>  #endif
> + /* fall through - to _DRM_FRAME_BUFFER... */
>   case _DRM_FRAME_BUFFER:
>   case _DRM_REGISTERS:
>   offset = drm_core_get_reg_ofs(dev);
> @@ -610,7 +610,7 @@ static int drm_mmap_locked(struct file *filp, struct 
> vm_area_struct *vma)
>   vma->vm_end - vma->vm_start, vma->vm_page_prot))
>   return -EAGAIN;
>   vma->vm_page_prot = drm_dma_prot(map->type, vma);
> - /* fall through to _DRM_SHM */
> + /* fall through - to _DRM_SHM */
>   case _DRM_SHM:
>   vma->vm_ops = &drm_vm_shm_ops;
>   vma->vm_private_data = (void *)map;
> -- 
> 2.20.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drivers/component: kerneldoc polish

[Daniel Vetter]

Polish the kerneldoc a bit with suggestions from Randy.

Cc: Randy Dunlap 
Signed-off-by: Daniel Vetter 
Cc: Greg Kroah-Hartman 
Cc: "Rafael J. Wysocki" 
Cc: Daniel Vetter 
Cc: Ramalingam C 
--
Greg, I don't need this in any of the topic branches, best if you
pick this one up into your -next tree directly.

Cheers, Daniel
---
 drivers/base/component.c  | 14 +++---
 include/linux/component.h |  2 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index 7dbc41cccd58..6954e448f46b 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -27,7 +27,7 @@
  * helper fills the niche of aggregate drivers for specific hardware, where
  * further standardization into a subsystem would not be practical. The common
  * example is when a logical device (e.g. a DRM display driver) is spread 
around
- * the SoC on various component (scanout engines, blending blocks, transcoders
+ * the SoC on various components (scanout engines, blending blocks, transcoders
  * for various outputs and so on).
  *
  * The component helper also doesn't solve runtime dependencies, e.g. for 
system
@@ -378,7 +378,7 @@ static void __component_match_add(struct device *master,
 }
 
 /**
- * component_match_add_release - add a component match with release callback
+ * component_match_add_release - add a component match entry with release 
callback
  * @master: device with the aggregate driver
  * @matchptr: pointer to the list of component matches
  * @release: release function for @compare_data
@@ -408,7 +408,7 @@ void component_match_add_release(struct device *master,
 EXPORT_SYMBOL(component_match_add_release);
 
 /**
- * component_match_add_typed - add a compent match for a typed component
+ * component_match_add_typed - add a compent match entry for a typed component
  * @master: device with the aggregate driver
  * @matchptr: pointer to the list of component matches
  * @compare_typed: compare function to match against all typed components
@@ -537,11 +537,11 @@ static void component_unbind(struct component *component,
 }
 
 /**
- * component_unbind_all - unbind all component to an aggregate driver
+ * component_unbind_all - unbind all components of an aggregate driver
  * @master_dev: device with the aggregate driver
  * @data: opaque pointer, passed to all components
  *
- * Unbinds all components to the aggregate @dev by passing @data to their
+ * Unbinds all components of the aggregate @dev by passing @data to their
  * &component_ops.unbind functions. Should be called from
  * &component_master_ops.unbind.
  */
@@ -619,11 +619,11 @@ static int component_bind(struct component *component, 
struct master *master,
 }
 
 /**
- * component_bind_all - bind all component to an aggregate driver
+ * component_bind_all - bind all components of an aggregate driver
  * @master_dev: device with the aggregate driver
  * @data: opaque pointer, passed to all components
  *
- * Binds all components to the aggregate @dev by passing @data to their
+ * Binds all components of the aggregate @dev by passing @data to their
  * &component_ops.bind functions. Should be called from
  * &component_master_ops.bind.
  */
diff --git a/include/linux/component.h b/include/linux/component.h
index 30bcc7e590eb..8628d4d0aff1 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -98,7 +98,7 @@ void component_match_add_typed(struct device *master,
int (*compare_typed)(struct device *, int, void *), void *compare_data);
 
 /**
- * component_match_add - add a compent match
+ * component_match_add - add a compent match entry
  * @master: device with the aggregate driver
  * @matchptr: pointer to the list of component matches
  * @compare: compare function to match against all components
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109048] [amdgpu] [apitrace] Penumbra Overture crash in radeonsi_dri.so on RX580

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109048

--- Comment #15 from Henri Valta  ---
https://bugs.archlinux.org/task/61797

-- 
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] drm: Updated documentation regarding atomic_check

[Stanislav Lisovskiy]

According to documentation, currently atomic_check hook
can't return -ERANGE and -ENOSPC, which is wrong as in
reality it does(from drm_atomic_plane_check). This caused
some issues and wrong assumptions in some IGT test cases
(see fdo#109225).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109225
Signed-off-by: Stanislav Lisovskiy 
---
 include/drm/drm_mode_config.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 1e6cb885994d..b817dadf8544 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -187,11 +187,15 @@ struct drm_mode_config_funcs {
 *  - -ENOMEM, if allocating additional state sub-structures failed due
 *to lack of memory.
 *
+*  - -ENOSPC, if plane source coordinates are outside of the 
framebuffer.
+*
 *  - -EINTR, -EAGAIN or -ERESTARTSYS, if the IOCTL should be restarted.
 *This can either be due to a pending signal, or because the driver
 *needs to completely bail out to recover from an exceptional
 *situation like a GPU hang. From a userspace point all errors are
 *treated equally.
+*
+*  - -ERANGE, if plane coordinates are bigger than INT_MAX.
 */
int (*atomic_check)(struct drm_device *dev,
struct drm_atomic_state *state);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109048] [amdgpu] [apitrace] Penumbra Overture crash in radeonsi_dri.so on RX580

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109048

--- Comment #14 from Henri Valta  ---
(In reply to Timothy Arceri from comment #13)
> What version of GCC are you using to build Mesa?

It's from arch linux package 8.2.1+20181127-1

>I wonder if this is actually a compiler bug rather than a Mesa bug given your 
>find above.

I'll open a bug for the arch mesa package and link it to this, so the people
there who know what's going on with the gcc version might be able to help.

-- 
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 v3 0/8] drm/sun4i: dsi: Add burst mode support

[Paul Kocialkowski]

Hi Jagan,

On Fri, 2019-02-15 at 22:37 +0530, Jagan Teki wrote:
> Hi Maxime,
> 
> On 15/02/19 8:10 PM, Jagan Teki wrote:
> > 
> > On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard,  > > wrote:
> > 
> > On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
> >  > Hi,
> >  >
> >  > Here is a series implementing the burst mode support for DSI.
> >  >
> >  > It's been tested on an A33 board with the panel supported on the last
> >  > patch, which should remove all quirks due to a different SoC from the
> >  > equation.
> > 
> > I should have sent that mail yesterday, but patches 1-4 and 6-7 were
> > merged. Patch 5 was discarded since it was not consistent with the
> > rest of the driver, and 8 had some comments.
> > 
> > 
> > Are the applied patches from this series or from my v7 series?
> > 
> >   Would you please point me the branch.
> > 
> 
> Unfortunately my last mail didn't reach arm mailing list.
> 
> Just wanted to know are the applied patches from this series or from my 
> v7 series? Would you please point me the repo, I couldn't find it on
> git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git

This series is the one that was applied upstream. You can find the
commits merged at: https://cgit.freedesktop.org/drm/drm-misc/log/

The sunxi tree is not used for changes taking place in specific
subsystems that have their own maintainer trees. In this case, changes
to the DRM driver are going through the DRM misc tree (of which Maxime
is also a maintainer).

With this basis merged, you should be able to respin your series in a
lighter form. Hopefully, that'll help get your changes in shape faster!

Cheers,

Paul

-- 
Paul Kocialkowski, 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

[PATCH v4 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_map_pages()

[Souptick Joarder via dri-devel]

Convert to use vm_map_pages() to map range of kernel
memory to user vma.

Tested on Rockchip hardware and display is working,
including talking to Lima via prime.

Signed-off-by: Souptick Joarder 
Tested-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index a8db758..a2ebb08 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -221,26 +221,13 @@ static int rockchip_drm_gem_object_mmap_iommu(struct 
drm_gem_object *obj,
  struct vm_area_struct *vma)
 {
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
-   unsigned int i, count = obj->size >> PAGE_SHIFT;
+   unsigned int count = obj->size >> PAGE_SHIFT;
unsigned long user_count = vma_pages(vma);
-   unsigned long uaddr = vma->vm_start;
-   unsigned long offset = vma->vm_pgoff;
-   unsigned long end = user_count + offset;
-   int ret;
 
if (user_count == 0)
return -ENXIO;
-   if (end > count)
-   return -ENXIO;
 
-   for (i = offset; i < end; i++) {
-   ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
-   if (ret)
-   return ret;
-   uaddr += PAGE_SIZE;
-   }
-
-   return 0;
+   return vm_map_pages(vma, rk_obj->pages, count);
 }
 
 static int rockchip_drm_gem_object_mmap_dma(struct drm_gem_object *obj,
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re:bulk mailing service/fresh office 365 emails avaiable

[smtp tools/cpanel/RDP via dri-devel]

How are you? my friend,
we sell tools for email blast (inbox SMTP/bulletproof cpanel/fresh 
eamils),please check blow list
Skype ID live:tools2018_2
ICQ UIN 742 624 895
Wechat ID smtptools_1
Whats app: 0086-13857707871 (China)
 
Package 1: Unlimited SMTP server + Turbo Mailer + admin RDP/Price: $175/Per 
Month
(once SMTP blacklist, we will give 2 times replacement for free)

Package 2: Unlimited web-based SMTP/Price:$175/Per Month
interspire email marketer installed

Package 3: Supmer mailer + admin RDP + 5 SMTP rotate/price: $300/Per Month

Package 4: Unlimited SMTP server/Price: $99/Per Month
(once SMTP blacklist, we will give 2 times replacement for free)

Package 5: Unlimited webmail 
Roundcube webmail (bcc up to 1000 emails)price: $135/Per Month
Zimbra webmail (bcc up to 1000 emails)price: $155/Per Month

Package 6: spam and scan friendly Admin RDP/price: $45/Per Month
multiple locations RDP avaiable

Package 7: Email Sorter and Email list manager/price: $135 with lifetime license

Package 8: general business/office 365/CEO & CFO email leads
1- general business company email leads: $50 per 100k
2- office 365 emails: $60 per 100k
3- CEO & CFO email leads: $100 per 100k 

Package 9: bulletproof cpanel/WHM Price: $75/Per Month
host any page no trouble/ignore any reports/create unlimited cpanel accounts

Package 10: email extractor/price: $155 with lifetime license
(extract email by keyword /also can extract by country)

Package 11:email verifier/price $135 with lifetime license 
(remove invalied emails)

For payment, we accept below:
1- Perfect Money
2- Bitcoin
3- Western Union
4- Money Gram
5- Bank T/T
 
Intelligence online marketing solutions ltd (China based company)
Skype ID live:tools2018_2
ICQ UIN 742 624 895
Wechat ID smtptools_1
Whats app: 0086-13857707871
Email:728556...@qq.com
 
 
 
 
 
 
 
 
 
 
 
 
 
 ___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] component: Add documentation

[Randy Dunlap]

On 2/7/19 3:27 PM, Daniel Vetter wrote:

Hi Daniel,

I have a few possible changes for this documentation (see below).

> ---
>  Documentation/driver-api/component.rst   |  17 
>  Documentation/driver-api/device_link.rst |   3 +
>  Documentation/driver-api/index.rst   |   1 +
>  drivers/base/component.c | 106 ++-
>  include/linux/component.h|  70 +++
>  5 files changed, 194 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/driver-api/component.rst
> 



> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index ddcea8739c12..1624c2a892a5 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -16,6 +16,32 @@
>  #include 
>  #include 
>  
> +/**
> + * DOC: overview
> + *
> + * The component helper allows drivers to collect a pile of sub-devices,
> + * including their bound drivers, into an aggregate driver. Various 
> subsystems
> + * already provide functions to get hold of such components, e.g.
> + * of_clk_get_by_name(). The component helper can be used when such a
> + * subsystem-specific way to find a device is not available: The component
> + * helper fills the niche of aggregate drivers for specific hardware, where
> + * further standardization into a subsystem would not be practical. The 
> common
> + * example is when a logical device (e.g. a DRM display driver) is spread 
> around
> + * the SoC on various component (scanout engines, blending blocks, 
> transcoders

  on various components

> + * for various outputs and so on).
> + *
> + * The component helper also doesn't solve runtime dependencies, e.g. for 
> system
> + * suspend and resume operations. See also :ref:`device links`.
> + *
> + * Components are registered using component_add() and unregistered with
> + * component_del(), usually from the driver's probe and disconnect functions.
> + *
> + * Aggregate drivers first assemble a component match list of what they need
> + * using component_match_add(). This is then registered as an aggregate 
> driver
> + * using component_master_add_with_match(), and unregistered using
> + * component_master_del().
> + */
> +
>  struct component;
>  
>  struct component_match_array {
> @@ -301,10 +327,24 @@ static int component_match_realloc(struct device *dev,
>   return 0;
>  }
>  
> -/*
> - * Add a component to be matched, with a release function.
> +/**
> + * component_match_add_release - add a component match with release callback
> + * @master: device with the aggregate driver
> + * @matchptr: pointer to the list of component matches
> + * @release: release function for @compare_data
> + * @compare: compare function to match against all components
> + * @compare_data: opaque pointer passed to the @compare function
> + *
> + * Adds a new component match to the list stored in @matchptr, which the 
> @master
> + * aggregate driver needs to function. The list of component matches pointed 
> to
> + * by @matchptr must be initialized to NULL before adding the first match.
> + *
> + * The allocated match list in @matchptr is automatically released using devm
> + * actions, where upon @release will be called to free any references held by
> + * @compare_data, e.g. when @compare_data is a &device_node that must be
> + * released with of_node_put().
>   *
> - * The match array is first created or extended if necessary.
> + * See also component_match_add().
>   */
>  void component_match_add_release(struct device *master,
>   struct component_match **matchptr,
> @@ -367,6 +407,18 @@ static void free_master(struct master *master)
>   kfree(master);
>  }
>  
> +/**
> + * component_master_add_with_match - register an aggregate driver
> + * @dev: device with the aggregate driver
> + * @ops: callbacks for the aggregate driver
> + * @match: component match list for the aggregate driver
> + *
> + * Registers a new aggregate driver consisting of the components added to 
> @match
> + * by calling one of the component_match_add() functions. Once all 
> components in
> + * @match are available, it will be assembled by calling
> + * &component_master_ops.bind from @ops. Must be unregistered by calling
> + * component_master_del().
> + */
>  int component_master_add_with_match(struct device *dev,
>   const struct component_master_ops *ops,
>   struct component_match *match)
> @@ -403,6 +455,15 @@ int component_master_add_with_match(struct device *dev,
>  }
>  EXPORT_SYMBOL_GPL(component_master_add_with_match);
>  
> +/**
> + * component_master_del - unregister an aggregate driver
> + * @dev: device with the aggregate driver
> + * @ops: callbacks for the aggregate driver
> + *
> + * Unregisters an aggregate driver registered with
> + * component_master_add_with_match(). If necessary the aggregate driver is 
> first
> + * disassembled by calling &component_master_ops.unbind from @ops.
> + */
>  void component_master_del(struct device *dev,
>   const struct compone

Re: [PATCH v3 0/8] drm/sun4i: dsi: Add burst mode support

[Jagan Teki]

Hi Maxime,

On 15/02/19 8:10 PM, Jagan Teki wrote:



On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard, > wrote:


On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
 > Hi,
 >
 > Here is a series implementing the burst mode support for DSI.
 >
 > It's been tested on an A33 board with the panel supported on the last
 > patch, which should remove all quirks due to a different SoC from the
 > equation.

I should have sent that mail yesterday, but patches 1-4 and 6-7 were
merged. Patch 5 was discarded since it was not consistent with the
rest of the driver, and 8 had some comments.


Are the applied patches from this series or from my v7 series?

  Would you please point me the branch.



Unfortunately my last mail didn't reach arm mailing list.

Just wanted to know are the applied patches from this series or from my 
v7 series? Would you please point me the repo, I couldn't find it on

git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git

Jagan.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm/bridge: cdns: Remove set but not used variable 'bpp'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/bridge/cdns-dsi.c: In function 'cdns_dsi_bridge_enable':
drivers/gpu/drm/bridge/cdns-dsi.c:986:6: warning:
 variable 'bpp' set but not used [-Wunused-but-set-variable]

It never used since introduction.

Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/bridge/cdns-dsi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
index 6166dca6be81..07ee1685fdfe 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -785,13 +785,12 @@ static void cdns_dsi_bridge_enable(struct drm_bridge 
*bridge)
unsigned long tx_byte_period;
struct cdns_dsi_cfg dsi_cfg;
u32 tmp, reg_wakeup, div;
-   int bpp, nlanes;
+   int nlanes;
 
if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0))
return;
 
mode = &bridge->encoder->crtc->state->adjusted_mode;
-   bpp = mipi_dsi_pixel_format_to_bpp(output->dev->format);
nlanes = output->dev->lanes;
 
WARN_ON_ONCE(cdns_dsi_check_conf(dsi, mode, &dsi_cfg, false));



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/imx: ipuv3-plane: add zpos property

[Marius Vlad via dri-devel]

Hi Philipp,

Tested-By: Marius Vlad 

Thanks!

On Fri, Feb 15, 2019 at 11:17:59AM +0100, Philipp Zabel wrote:
> Hi,
> 
> I have added (most of) you to Cc: because I think you have either
> recently or significantly touched zpos property code. Could I ask
> for a review or ack of this patch from zpos point of view?
> 
> If you have tested this patch, a Tested-by: would be appreciated
> as well.
> 
> regards
> Philipp
> 
> On Mon, 2018-12-03 at 10:49 +0100, Philipp Zabel wrote:
> > Add a zpos property to planes. Call drm_atomic_helper_check() instead of
> > calling drm_atomic_helper_check_modeset() and drm_atomic_check_planes()
> > manually. This effectively adds a call to drm_atoimic_normalize_zpos()
Small typo.
> > before checking planes. Reorder atomic update to allow changing plane
> > zpos without modeset.
``, by using global alpha (of the combining unit)''?
> > 
> > Note that the initial zpos is set in ipu_plane_state_reset(). The
> > initial value set in ipu_plane_init() is just for show. The zpos
> > parameter of drm_plane_create_zpos_property() is ignored because
> > the newly created plane do not have state yet.
> > 
> > Signed-off-by: Philipp Zabel 
> > ---
> >  drivers/gpu/drm/imx/imx-drm-core.c |  7 ++--
> >  drivers/gpu/drm/imx/ipuv3-plane.c  | 56 +-
> >  2 files changed, 33 insertions(+), 30 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> > b/drivers/gpu/drm/imx/imx-drm-core.c
> > index 820c7e3878f0..687cfb9d410e 100644
> > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > @@ -49,11 +49,7 @@ static int imx_drm_atomic_check(struct drm_device *dev,
> >  {
> > int ret;
> >  
> > -   ret = drm_atomic_helper_check_modeset(dev, state);
> > -   if (ret)
> > -   return ret;
> > -
> > -   ret = drm_atomic_helper_check_planes(dev, state);
> > +   ret = drm_atomic_helper_check(dev, state);
> > if (ret)
> > return ret;
> >  
> > @@ -229,6 +225,7 @@ static int imx_drm_bind(struct device *dev)
> > drm->mode_config.funcs = &imx_drm_mode_config_funcs;
> > drm->mode_config.helper_private = &imx_drm_mode_config_helpers;
> > drm->mode_config.allow_fb_modifiers = true; 
> > +   drm->mode_config.normalize_zpos = true;
> >  
> > drm_mode_config_init(drm);
> >  
> > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> > b/drivers/gpu/drm/imx/ipuv3-plane.c
> > index d6d9ab5b33db..508ce655d638 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> > @@ -273,6 +273,7 @@ static void ipu_plane_destroy(struct drm_plane *plane)
> >  
> >  static void ipu_plane_state_reset(struct drm_plane *plane)
> >  {
> > +   unsigned int zpos = (plane->type == DRM_PLANE_TYPE_PRIMARY) ? 0 : 1;
> > struct ipu_plane_state *ipu_state;
> >  
> > if (plane->state) {
> > @@ -284,8 +285,11 @@ static void ipu_plane_state_reset(struct drm_plane 
> > *plane)
> >  
> > ipu_state = kzalloc(sizeof(*ipu_state), GFP_KERNEL);
> >  
> > -   if (ipu_state)
> > +   if (ipu_state) {
> > __drm_atomic_helper_plane_reset(plane, &ipu_state->base);
> > +   ipu_state->base.zpos = zpos;
> > +   ipu_state->base.normalized_zpos = zpos;
> > +   }
> >  }
> >  
> >  static struct drm_plane_state *
> > @@ -560,6 +564,25 @@ static void ipu_plane_atomic_update(struct drm_plane 
> > *plane,
> > if (ipu_plane->dp_flow == IPU_DP_FLOW_SYNC_FG)
> > ipu_dp_set_window_pos(ipu_plane->dp, dst->x1, dst->y1);
> >  
> > +   switch (ipu_plane->dp_flow) {
> > +   case IPU_DP_FLOW_SYNC_BG:
> > +   if (state->normalized_zpos == 1) {
> > +   ipu_dp_set_global_alpha(ipu_plane->dp,
> > +   !fb->format->has_alpha, 0xff,
> > +   true);
> > +   } else {
> > +   ipu_dp_set_global_alpha(ipu_plane->dp, true, 0, true);
> > +   }
> > +   break;
> > +   case IPU_DP_FLOW_SYNC_FG:
> > +   if (state->normalized_zpos == 1) {
> > +   ipu_dp_set_global_alpha(ipu_plane->dp,
> > +   !fb->format->has_alpha, 0xff,
> > +   false);
> > +   }
> > +   break;
> > +   }
> > +
> > eba = drm_plane_state_to_eba(state, 0);
> >  
> > /*
> > @@ -596,34 +619,11 @@ static void ipu_plane_atomic_update(struct drm_plane 
> > *plane,
> > switch (ipu_plane->dp_flow) {
> > case IPU_DP_FLOW_SYNC_BG:
> > ipu_dp_setup_channel(ipu_plane->dp, ics, IPUV3_COLORSPACE_RGB);
> > -   ipu_dp_set_global_alpha(ipu_plane->dp, true, 0, true);
> > break;
> > case IPU_DP_FLOW_SYNC_FG:
> > ipu_dp_setup_channel(ipu_plane->dp, ics,
> > IPUV3_COLORSPACE_UNKNOWN);
> > -   /* Enable local alpha on partial plane */
> > -   switch (fb->format->format) {

[PATCH 1/2] drm: panel-orientation-quirks: Get rid of superfluous (void *) casting

[David Santamaría Rogado via dri-devel]

From: howl 

The (void *) casting in the driver_data variable assignment is superfluous.
Spotted by Jani Nikula.

Signed-off-by: David Santamaría Rogado 
---
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 52e445bb1aa5..61d3361381b7 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -86,13 +86,13 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Acer"),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"),
},
-   .driver_data = (void *)&acer_s1003,
+   .driver_data = &acer_s1003,
}, {/* Asus T100HA */
.matches = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
},
-   .driver_data = (void *)&asus_t100ha,
+   .driver_data = &asus_t100ha,
}, {/*
 * GPD Pocket, note that the the DMI data is less generic then
 * it seems, devices with a board-vendor of "AMI Corporation"
@@ -105,7 +105,7 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
},
-   .driver_data = (void *)&gpd_pocket,
+   .driver_data = &gpd_pocket,
}, {/* GPD Win (same note on DMI match as GPD Pocket) */
.matches = {
  DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
@@ -113,7 +113,7 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
},
-   .driver_data = (void *)&gpd_win,
+   .driver_data = &gpd_win,
}, {/* GPD Win 2 (too generic strings, also match on bios date) */
.matches = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
@@ -121,7 +121,7 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
  DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
},
-   .driver_data = (void *)&gpd_win2,
+   .driver_data = &gpd_win2,
}, {/* I.T.Works TW891 */
.matches = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."),
@@ -129,7 +129,7 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "To be filled by O.E.M."),
  DMI_EXACT_MATCH(DMI_BOARD_NAME, "TW891"),
},
-   .driver_data = (void *)&itworks_tw891,
+   .driver_data = &itworks_tw891,
}, {/*
 * Lenovo Ideapad Miix 310 laptop, only some production batches
 * have a portrait screen, the resolution checks makes the quirk
@@ -140,20 +140,20 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80SG"),
  DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "MIIX 310-10ICR"),
},
-   .driver_data = (void *)&lcd800x1280_rightside_up,
+   .driver_data = &lcd800x1280_rightside_up,
}, {/* Lenovo Ideapad Miix 320 */
.matches = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80XF"),
  DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX 320-10ICR"),
},
-   .driver_data = (void *)&lcd800x1280_rightside_up,
+   .driver_data = &lcd800x1280_rightside_up,
}, {/* VIOS LTH17 */
.matches = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "LTH17"),
},
-   .driver_data = (void *)&lcd800x1280_rightside_up,
+   .driver_data = &lcd800x1280_rightside_up,
},
{}
 };
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel