Re: [PATCH] staging: fbtft: Remove prohibited spaces before ')'

[kbuild test robot]

Hi Marcio,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on tegra-drm/drm/tegra/for-next v5.6-rc5 next-20200310]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Marcio-Albano/staging-fbtft-Remove-prohibited-spaces-before/20200311-095855
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
590a95e418d18894e34cd240b3e7ef278add05c7
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All error/warnings (new ones prefixed by >>):

>> drivers/staging/fbtft/fbtft-bus.c:65:53: error: macro 
>> "define_fbtft_write_reg" requires 4 arguments, but only 3 given
define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
^
>> drivers/staging/fbtft/fbtft-bus.c:15:1: error: expected '=', ',', ';', 'asm' 
>> or '__attribute__' before 'void'
void func(struct fbtft_par *par, int len, ...)  
  \
^
>> drivers/staging/fbtft/fbtft-bus.c:66:1: note: in expansion of macro 
>> 'define_fbtft_write_reg'
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
^~
   drivers/staging/fbtft/fbtft-bus.c:67:57: error: macro 
"define_fbtft_write_reg" requires 4 arguments, but only 3 given
define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
^
   drivers/staging/fbtft/fbtft-bus.c:69:1: error: expected '=', ',', ';', 'asm' 
or '__attribute__' before 'void'
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
^~~~

vim +/define_fbtft_write_reg +65 drivers/staging/fbtft/fbtft-bus.c

 7  
 8  
/*
 9   *
10   *   void (*write_reg)(struct fbtft_par *par, int len, ...);
11   *
12   
*/
13  
14  #define define_fbtft_write_reg(func, buffer_type, data_type, modifier)  
  \
  > 15  void func(struct fbtft_par *par, int len, ...)  
  \
16  {   
  \
17  va_list args;   
  \
18  int i, ret; 
  \
19  int offset = 0; 
  \
20  buffer_type *buf = (buffer_type *)par->buf; 
  \
21  
  \
22  if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {  
  \
23  va_start(args, len);
  \
24  for (i = 0; i < len; i++) { 
  \
25  buf[i] = modifier((data_type)va_arg(args,   
  \
26  unsigned 
int));   \
27  }   
  \
28  va_end(args);   
  \
29  fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
  \
30par->info->device, buffer_type, buf, 
len,   \
31"%s: ", __func__);
  \
32  }   
  \
33  
  \
34  va_start(args, len);
  \
35  
  \
36  if (par->startbyte) {   
  \
37  *(u8 *)par->buf = par->startbyte;   
  \
38  buf = (buffer_type *)(par->buf + 1);
  \
39  offset = 1; 
  \
40  }   
  \
41 

X.Org GSoC 2020 - call for project ideas and mentors

[Trevor Woerner]

Hello!

Once again X.Org has been fortunate to have been chosen to be part of GSoC!

Starting March 16 (this Monday) students will be able to register and
submit their applications for GSoC.

If you can spare a moment, please take a look at our current "idea"
page which help students to start thinking about potential project
ideas: https://www.x.org/wiki/SummerOfCodeIdeas/

If you have any project ideas that might suit a post-secondary
student, please add them to the list, or email me the details and I'll
be happy to update the list on your behalf. Conversely, if there are
projects on that list that are no longer relevant, please let me know
and I'll take them down.

Also, if you are considering being a mentor, please get in touch so I
can add you to the list.

If you have any thoughts or questions, please don't hesitate to get in touch.

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

[PATCH -next 019/491] Hyper-V CORE AND DRIVERS: Use fallthrough;

[Joe Perches]

Convert the various uses of fallthrough comments to fallthrough;

Done via script
Link: 
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/

Signed-off-by: Joe Perches 
---
 drivers/hv/hv_kvp.c | 4 +---
 drivers/hv/vmbus_drv.c  | 2 +-
 drivers/video/fbdev/hyperv_fb.c | 4 ++--
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index e74b144..da4686 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -353,9 +353,7 @@ static void process_ib_ipinfo(void *in_msg, void *out_msg, 
int op)
MAX_IP_ADDR_SIZE);
 
out->body.kvp_ip_val.dhcp_enabled = in->kvp_ip_val.dhcp_enabled;
-
-   /* fallthrough */
-
+   fallthrough;
case KVP_OP_GET_IP_INFO:
utf16s_to_utf8s((wchar_t *)in->kvp_ip_val.adapter_id,
MAX_ADAPTER_ID_SIZE,
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 029378..0befc0 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1188,7 +1188,7 @@ static void vmbus_chan_sched(struct hv_per_cpu_context 
*hv_cpu)
 
case HV_CALL_BATCHED:
hv_begin_read(>inbound);
-   /* fallthrough */
+   fallthrough;
case HV_CALL_DIRECT:
tasklet_schedule(>callback_event);
}
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index e4c3c8b..02411d 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -648,13 +648,13 @@ static int synthvid_connect_vsp(struct hv_device *hdev)
ret = synthvid_negotiate_ver(hdev, SYNTHVID_VERSION_WIN10);
if (!ret)
break;
-   /* Fallthrough */
+   fallthrough;
case VERSION_WIN8:
case VERSION_WIN8_1:
ret = synthvid_negotiate_ver(hdev, SYNTHVID_VERSION_WIN8);
if (!ret)
break;
-   /* Fallthrough */
+   fallthrough;
case VERSION_WS2008:
case VERSION_WIN7:
ret = synthvid_negotiate_ver(hdev, SYNTHVID_VERSION_WIN7);
-- 
2.24.0

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

[PATCH -next 025/491] AMD POWERPLAY: Use fallthrough;

[Joe Perches]

Convert the various uses of fallthrough comments to fallthrough;

Done via script
Link: 
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index bf04cf..fc5236c 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -1250,7 +1250,7 @@ static void smu7_set_dpm_event_sources(struct pp_hwmgr 
*hwmgr, uint32_t sources)
switch (sources) {
default:
pr_err("Unknown throttling event sources.");
-   /* fall through */
+   fallthrough;
case 0:
protection = false;
/* src is unused */
@@ -3698,12 +3698,12 @@ static int 
smu7_request_link_speed_change_before_state_change(
data->force_pcie_gen = PP_PCIEGen2;
if (current_link_speed == PP_PCIEGen2)
break;
-   /* fall through */
+   fallthrough;
case PP_PCIEGen2:
if (0 == 
amdgpu_acpi_pcie_performance_request(hwmgr->adev, PCIE_PERF_REQ_GEN2, false))
break;
 #endif
-   /* fall through */
+   fallthrough;
default:
data->force_pcie_gen = 
smu7_get_current_pcie_speed(hwmgr);
break;
-- 
2.24.0

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

[PATCH -next 024/491] AMD DISPLAY CORE: Use fallthrough;

[Joe Perches]

Convert the various uses of fallthrough comments to fallthrough;

Done via script
Link: 
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 4 ++--
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.c   | 2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index 2f1c958..37fa7b 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -267,7 +267,7 @@ static struct atom_display_object_path_v2 *get_bios_object(
&& id.enum_id == obj_id.enum_id)
return 
>object_info_tbl.v1_4->display_path[i];
}
-   /* fall through */
+   fallthrough;
case OBJECT_TYPE_CONNECTOR:
case OBJECT_TYPE_GENERIC:
/* Both Generic and Connector Object ID
@@ -280,7 +280,7 @@ static struct atom_display_object_path_v2 *get_bios_object(
&& id.enum_id == obj_id.enum_id)
return 
>object_info_tbl.v1_4->display_path[i];
}
-   /* fall through */
+   fallthrough;
default:
return NULL;
}
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index 68c4049..743042 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -645,7 +645,7 @@ bool dce_aux_transfer_with_retries(struct ddc_service *ddc,
case AUX_TRANSACTION_REPLY_AUX_DEFER:
case AUX_TRANSACTION_REPLY_I2C_OVER_AUX_DEFER:
retry_on_defer = true;
-   /* fall through */
+   fallthrough;
case AUX_TRANSACTION_REPLY_I2C_OVER_AUX_NACK:
if (++aux_defer_retries >= 
AUX_MAX_DEFER_RETRIES) {
goto fail;
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
index 8aa937f..51481e 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
@@ -479,7 +479,7 @@ static void program_grph_pixel_format(
case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616F:
sign = 1;
floating = 1;
-   /* fall through */
+   fallthrough;
case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616F: /* shouldn't this get 
float too? */
case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616:
grph_depth = 3;
-- 
2.24.0

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

[PATCH -next 023/491] AMD KFD: Use fallthrough;

[Joe Perches]

Convert the various uses of fallthrough comments to fallthrough;

Done via script
Link: 
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
index d6549e..6529ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
@@ -79,7 +79,7 @@ static uint32_t get_sdma_rlc_reg_offset(struct amdgpu_device 
*adev,
dev_warn(adev->dev,
 "Invalid sdma engine id (%d), using engine id 0\n",
 engine_id);
-   /* fall through */
+   fallthrough;
case 0:
sdma_engine_reg_base = SOC15_REG_OFFSET(SDMA0, 0,
mmSDMA0_RLC0_RB_CNTL) - mmSDMA0_RLC0_RB_CNTL;
-- 
2.24.0

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

[PATCH -next 026/491] INTEL GVT-g DRIVERS (Intel GPU Virtualization): Use fallthrough;

[Joe Perches]

Convert the various uses of fallthrough comments to fallthrough;

Done via script
Link: 
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index 1793f69..0e792f9 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1225,7 +1225,7 @@ static int handle_g2v_notification(struct intel_vgpu 
*vgpu, int notification)
switch (notification) {
case VGT_G2V_PPGTT_L3_PAGE_TABLE_CREATE:
root_entry_type = GTT_TYPE_PPGTT_ROOT_L3_ENTRY;
-   /* fall through */
+   fallthrough;
case VGT_G2V_PPGTT_L4_PAGE_TABLE_CREATE:
mm = intel_vgpu_get_ppgtt_mm(vgpu, root_entry_type, pdps);
return PTR_ERR_OR_ZERO(mm);
-- 
2.24.0

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

[PATCH -next 013/491] INGENIC JZ47xx SoCs: Use fallthrough;

[Joe Perches]

Convert the various uses of fallthrough comments to fallthrough;

Done via script
Link: 
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c   | 2 +-
 drivers/mmc/host/jz4740_mmc.c   | 6 ++
 drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c | 2 +-
 drivers/mtd/nand/raw/ingenic/jz4725b_bch.c  | 4 ++--
 drivers/mtd/nand/raw/ingenic/jz4780_bch.c   | 4 ++--
 sound/soc/codecs/jz4770.c   | 2 +-
 6 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 9dfe7c..8eefe7 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -305,7 +305,7 @@ static void ingenic_drm_crtc_update_ctrl(struct ingenic_drm 
*priv,
switch (finfo->format) {
case DRM_FORMAT_XRGB1555:
ctrl |= JZ_LCD_CTRL_RGB555;
-   /* fall-through */
+   fallthrough;
case DRM_FORMAT_RGB565:
ctrl |= JZ_LCD_CTRL_BPP_15_16;
break;
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index fbae87..9026af6 100644
--- a/drivers/mmc/host/jz4740_mmc.c
+++ b/drivers/mmc/host/jz4740_mmc.c
@@ -737,8 +737,7 @@ static irqreturn_t jz_mmc_irq_worker(int irq, void *devid)
break;
 
jz_mmc_prepare_data_transfer(host);
-   /* fall through */
-
+   fallthrough;
case JZ4740_MMC_STATE_TRANSFER_DATA:
if (host->use_dma) {
/* Use DMA if enabled.
@@ -772,8 +771,7 @@ static irqreturn_t jz_mmc_irq_worker(int irq, void *devid)
break;
}
jz4740_mmc_write_irq_reg(host, JZ_MMC_IRQ_DATA_TRAN_DONE);
-   /* fall through */
-
+   fallthrough;
case JZ4740_MMC_STATE_SEND_STOP:
if (!req->stop)
break;
diff --git a/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c 
b/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
index 49afeb..935c49 100644
--- a/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
+++ b/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
@@ -253,7 +253,7 @@ static int ingenic_nand_attach_chip(struct nand_chip *chip)
chip->ecc.hwctl = ingenic_nand_ecc_hwctl;
chip->ecc.calculate = ingenic_nand_ecc_calculate;
chip->ecc.correct = ingenic_nand_ecc_correct;
-   /* fall through */
+   fallthrough;
case NAND_ECC_SOFT:
dev_info(nfc->dev, "using %s (strength %d, size %d, bytes 
%d)\n",
 (nfc->ecc) ? "hardware ECC" : "software ECC",
diff --git a/drivers/mtd/nand/raw/ingenic/jz4725b_bch.c 
b/drivers/mtd/nand/raw/ingenic/jz4725b_bch.c
index 6c852ea..2d0e0a 100644
--- a/drivers/mtd/nand/raw/ingenic/jz4725b_bch.c
+++ b/drivers/mtd/nand/raw/ingenic/jz4725b_bch.c
@@ -145,10 +145,10 @@ static void jz4725b_bch_read_parity(struct ingenic_ecc 
*bch, u8 *buf,
switch (size8) {
case 3:
dest8[2] = (val >> 16) & 0xff;
-   /* fall-through */
+   fallthrough;
case 2:
dest8[1] = (val >> 8) & 0xff;
-   /* fall-through */
+   fallthrough;
case 1:
dest8[0] = val & 0xff;
break;
diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_bch.c 
b/drivers/mtd/nand/raw/ingenic/jz4780_bch.c
index 079266a..d67dbf 100644
--- a/drivers/mtd/nand/raw/ingenic/jz4780_bch.c
+++ b/drivers/mtd/nand/raw/ingenic/jz4780_bch.c
@@ -123,10 +123,10 @@ static void jz4780_bch_read_parity(struct ingenic_ecc 
*bch, void *buf,
switch (size8) {
case 3:
dest8[2] = (val >> 16) & 0xff;
-   /* fall through */
+   fallthrough;
case 2:
dest8[1] = (val >> 8) & 0xff;
-   /* fall through */
+   fallthrough;
case 1:
dest8[0] = val & 0xff;
break;
diff --git a/sound/soc/codecs/jz4770.c b/sound/soc/codecs/jz4770.c
index e7cf2c..6e2a91 100644
--- a/sound/soc/codecs/jz4770.c
+++ b/sound/soc/codecs/jz4770.c
@@ -202,7 +202,7 @@ static int jz4770_codec_set_bias_level(struct 
snd_soc_component *codec,
   REG_CR_VIC_SB_SLEEP, REG_CR_VIC_SB_SLEEP);
regmap_update_bits(regmap, JZ4770_CODEC_REG_CR_VIC,
   REG_CR_VIC_SB, REG_CR_VIC_SB);
-   /* fall-through */
+   fallthrough;
default:
break;
}
-- 
2.24.0

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

[PATCH 1/3] dma-buf: add dma_fence_array_for_each (v2)

[Jason Ekstrand]

From: Christian König 

Add a helper to iterate over all fences in a dma_fence_array object.

v2 (Jason Ekstrand)
 - Return NULL from dma_fence_array_first if head == NULL.  This matches
   the iterator behavior of dma_fence_chain_for_each in that it iterates
   zero times if head == NULL.
 - Return NULL from dma_fence_array_next if index > array->num_fences.

Signed-off-by: Jason Ekstrand 
---
 drivers/dma-buf/dma-fence-array.c | 27 +++
 include/linux/dma-fence-array.h   | 17 +
 2 files changed, 44 insertions(+)

diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index d3fbd950be94..2ac1afc697d0 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -201,3 +201,30 @@ bool dma_fence_match_context(struct dma_fence *fence, u64 
context)
return true;
 }
 EXPORT_SYMBOL(dma_fence_match_context);
+
+struct dma_fence *dma_fence_array_first(struct dma_fence *head)
+{
+   struct dma_fence_array *array;
+
+   if (!head)
+   return NULL;
+
+   array = to_dma_fence_array(head);
+   if (!array)
+   return head;
+
+   return array->fences[0];
+}
+EXPORT_SYMBOL(dma_fence_array_first);
+
+struct dma_fence *dma_fence_array_next(struct dma_fence *head,
+  unsigned int index)
+{
+   struct dma_fence_array *array = to_dma_fence_array(head);
+
+   if (!array || index >= array->num_fences)
+   return NULL;
+
+   return array->fences[index];
+}
+EXPORT_SYMBOL(dma_fence_array_next);
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 303dd712220f..588ac8089dd6 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -74,6 +74,19 @@ to_dma_fence_array(struct dma_fence *fence)
return container_of(fence, struct dma_fence_array, base);
 }
 
+/**
+ * dma_fence_array_for_each - iterate over all fences in array
+ * @fence: current fence
+ * @index: index into the array
+ * @head: potential dma_fence_array object
+ *
+ * Test if @array is a dma_fence_array object and if yes iterate over all 
fences
+ * in the array. If not just iterate over the fence in @array itself.
+ */
+#define dma_fence_array_for_each(fence, index, head)   \
+   for (index = 0, fence = dma_fence_array_first(head); fence; \
+++(index), fence = dma_fence_array_next(head, index))
+
 struct dma_fence_array *dma_fence_array_create(int num_fences,
   struct dma_fence **fences,
   u64 context, unsigned seqno,
@@ -81,4 +94,8 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
 
 bool dma_fence_match_context(struct dma_fence *fence, u64 context);
 
+struct dma_fence *dma_fence_array_first(struct dma_fence *head);
+struct dma_fence *dma_fence_array_next(struct dma_fence *head,
+  unsigned int index);
+
 #endif /* __LINUX_DMA_FENCE_ARRAY_H */
-- 
2.24.1

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

[PATCH 2/3] dma-buf: add dma_resv_get_singleton (v2)

[Jason Ekstrand]

From: Christian König 

Add a helper function to get a single fence representing
all fences in a dma_resv object.

This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.

v2 (Jason Ekstrand):
 - Take reference of fences both for creating the dma_fence_array and in
   the case where we return one fence.
 - Handle the case where dma_resv_get_list() returns NULL

Signed-off-by: Jason Ekstrand 
---
 drivers/dma-buf/dma-resv.c | 118 +
 include/linux/dma-resv.h   |   3 +
 2 files changed, 121 insertions(+)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 4264e64788c4..66591d8ab7ef 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -33,6 +33,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -47,6 +49,19 @@
  * write-side updates.
  */
 
+/**
+ * dma_fence_deep_dive_for_each - deep dive into the fence containers
+ * @fence: resulting fence
+ * @chain: variable for a dma_fence_chain
+ * @index: index into a dma_fence_array
+ * @head: starting point
+ *
+ * Helper to deep dive into the fence containers for flattening them.
+ */
+#define dma_fence_deep_dive_for_each(fence, chain, index, head)\
+   dma_fence_chain_for_each(chain, head)   \
+   dma_fence_array_for_each(fence, index, chain)
+
 DEFINE_WD_CLASS(reservation_ww_class);
 EXPORT_SYMBOL(reservation_ww_class);
 
@@ -516,6 +531,109 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj,
 }
 EXPORT_SYMBOL_GPL(dma_resv_get_fences_rcu);
 
+/**
+ * dma_resv_get_singleton - get a single fence for the dma_resv object
+ * @obj: the reservation object
+ * @extra: extra fence to add to the resulting array
+ * @result: resulting dma_fence
+ *
+ * Get a single fence representing all unsignaled fences in the dma_resv object
+ * plus the given extra fence. If we got only one fence return a new
+ * reference to that, otherwise return a dma_fence_array object.
+ *
+ * RETURNS
+ * Returns -NOMEM if allocations fail, zero otherwise.
+ */
+int dma_resv_get_singleton(struct dma_resv *obj, struct dma_fence *extra,
+  struct dma_fence **result)
+{
+   struct dma_resv_list *fobj = dma_resv_get_list(obj);
+   struct dma_fence *excl = dma_resv_get_excl(obj);
+   struct dma_fence *fence, *chain, **fences;
+   struct dma_fence_array *array;
+   unsigned int num_fences, shared_count;
+   unsigned int i, j;
+
+   num_fences = 0;
+   *result = NULL;
+
+   dma_fence_deep_dive_for_each(fence, chain, i, extra) {
+   if (dma_fence_is_signaled(fence))
+   continue;
+
+   *result = fence;
+   ++num_fences;
+   }
+
+   dma_fence_deep_dive_for_each(fence, chain, i, excl) {
+   if (dma_fence_is_signaled(fence))
+   continue;
+
+   *result = fence;
+   ++num_fences;
+   }
+
+   shared_count = fobj ? fobj->shared_count : 0;
+   for (i = 0; i < shared_count; ++i) {
+   struct dma_fence *f;
+
+   f = rcu_dereference_protected(fobj->shared[i],
+ dma_resv_held(obj));
+   dma_fence_deep_dive_for_each(fence, chain, j, f) {
+   if (dma_fence_is_signaled(fence))
+   continue;
+
+   *result = fence;
+   ++num_fences;
+   }
+   }
+
+   if (num_fences <= 1) {
+   *result = dma_fence_get(*result);
+   return 0;
+   }
+
+   fences = kmalloc_array(num_fences, sizeof(struct dma_fence*),
+  GFP_KERNEL);
+   if (!fences)
+   return -ENOMEM;
+
+   num_fences = 0;
+
+   dma_fence_deep_dive_for_each(fence, chain, i, extra)
+   if (!dma_fence_is_signaled(fence))
+   fences[num_fences++] = dma_fence_get(fence);
+
+   dma_fence_deep_dive_for_each(fence, chain, i, excl)
+   if (!dma_fence_is_signaled(fence))
+   fences[num_fences++] = dma_fence_get(fence);
+
+   for (i = 0; i < shared_count; ++i) {
+   struct dma_fence *f;
+
+   f = rcu_dereference_protected(fobj->shared[i],
+ dma_resv_held(obj));
+   dma_fence_deep_dive_for_each(fence, chain, j, f)
+   if (!dma_fence_is_signaled(fence))
+   fences[num_fences++] = dma_fence_get(fence);
+   }
+
+   array = dma_fence_array_create(num_fences, fences,
+  dma_fence_context_alloc(1),
+  1, false);
+   if (!array)
+   goto error_free;
+
+   *result = >base;
+   return 0;
+
+error_free:
+   while (num_fences--)
+  

[PATCH 3/3] RFC: dma-buf: Add an API for importing and exporting sync files (v4)

[Jason Ekstrand]

Explicit synchronization is the future.  At least, that seems to be what
most userspace APIs are agreeing on at this point.  However, most of our
Linux APIs (both userspace and kernel UAPI) are currently built around
implicit synchronization with dma-buf.  While work is ongoing to change
many of the userspace APIs and protocols to an explicit synchronization
model, switching over piecemeal is difficult due to the number of
potential components involved.  On the kernel side, many drivers use
dma-buf including GPU (3D/compute), display, v4l, and others.  In
userspace, we have X11, several Wayland compositors, 3D drivers, compute
drivers (OpenCL etc.), media encode/decode, and the list goes on.

This patch provides a path forward by allowing userspace to manually
manage the fences attached to a dma-buf.  Alternatively, one can think
of this as making dma-buf's implicit synchronization simply a carrier
for an explicit fence.  This is accomplished by adding two IOCTLs to
dma-buf for importing and exporting a sync file to/from the dma-buf.
This way a userspace component which is uses explicit synchronization,
such as a Vulkan driver, can manually set the write fence on a buffer
before handing it off to an implicitly synchronized component such as a
Wayland compositor or video encoder.  In this way, each of the different
components can be upgraded to an explicit synchronization model one at a
time as long as the userspace pieces connecting them are aware of it and
import/export fences at the right times.

There is a potential race condition with this API if userspace is not
careful.  A typical use case for implicit synchronization is to wait for
the dma-buf to be ready, use it, and then signal it for some other
component.  Because a sync_file cannot be created until it is guaranteed
to complete in finite time, userspace can only signal the dma-buf after
it has already submitted the work which uses it to the kernel and has
received a sync_file back.  There is no way to atomically submit a
wait-use-signal operation.  This is not, however, really a problem with
this API so much as it is a problem with explicit synchronization
itself.  The way this is typically handled is to have very explicit
ownership transfer points in the API or protocol which ensure that only
one component is using it at any given time.  Both X11 (via the PRESENT
extension) and Wayland provide such ownership transfer points via
explicit present and idle messages.

The decision was intentionally made in this patch to make the import and
export operations IOCTLs on the dma-buf itself rather than as a DRM
IOCTL.  This makes it the import/export operation universal across all
components which use dma-buf including GPU, display, v4l, and others.
It also means that a userspace component can do the import/export
without access to the DRM fd which may be tricky to get in cases where
the client communicates with DRM via a userspace API such as OpenGL or
Vulkan.  At a future date we may choose to add direct import/export APIs
to components such as drm_syncobj to avoid allocating a file descriptor
and going through two ioctls.  However, that seems to be something of a
micro-optimization as import/export operations are likely to happen at a
rate of a few per frame of rendered or decoded video.

v2 (Jason Ekstrand):
 - Use a wrapper dma_fence_array of all fences including the new one
   when importing an exclusive fence.

v3 (Jason Ekstrand):
 - Lock around setting shared fences as well as exclusive
 - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
 - Initialize ret to 0 in dma_buf_wait_sync_file

v4 (Jason Ekstrand):
 - Use the new dma_resv_get_singleton helper

Signed-off-by: Jason Ekstrand 
---
 drivers/dma-buf/dma-buf.c| 96 
 include/uapi/linux/dma-buf.h | 13 -
 2 files changed, 107 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d4097856c86b..09973c689866 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -348,6 +349,95 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const 
char __user *buf)
return ret;
 }
 
+static long dma_buf_wait_sync_file(struct dma_buf *dmabuf,
+  const void __user *user_data)
+{
+   struct dma_buf_sync_file arg;
+   struct dma_fence *fence;
+   int ret = 0;
+
+   if (copy_from_user(, user_data, sizeof(arg)))
+   return -EFAULT;
+
+   if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE)
+   return -EINVAL;
+
+   fence = sync_file_get_fence(arg.fd);
+   if (!fence)
+   return -EINVAL;
+
+   dma_resv_lock(dmabuf->resv, NULL);
+
+   if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) {
+   struct dma_fence *singleton = NULL;
+   ret = dma_resv_get_singleton(dmabuf->resv, 

Re: [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files

[Jason Ekstrand]

On Mon, Mar 9, 2020 at 11:21 AM Christian König
 wrote:
>
> Am 05.03.20 um 16:54 schrieb Jason Ekstrand:
> > On Thu, Mar 5, 2020 at 7:06 AM Christian König  
> > wrote:
> >> [SNIP]
> >> Well as far as I can see this won't work because it would break the
> >> semantics of the timeline sync.
> > I'm not 100% convinced it has to.  We already have support for the
> > seqno regressing and we ensure that we still wait for all the fences.
> > I thought maybe we could use that but I haven't spent enough time
> > looking at the details to be sure.  I may be missing something.
>
> That won't work. The seqno regression works by punishing userspace for
> doing something stupid and undefined.
>
> Be we can't do that under normal circumstances.
>
> >> I can prototype that if you want, shouldn't be more than a few hours of
> >> hacking anyway.
> > If you'd like to, go for it.  I'd be happy to give it a go as well but
> > if you already know what you want, it may be easier for you to just
> > write the patch for the cursor.
>
> Send you two patches for that a few minutes ago. But keep in mind that
> those are completely untested.

No worries.  They were full of bugs but I think I've got them sorted
out now.  The v2's I'm about to send seem to work.  I'm going to leave
a Vulkan demo running all night long just to make sure I'm not leaking
memory like mad.

--Jason

> > Two more questions:
> >
> >   1. Do you want this collapsing to happen every time we create a
> > dma_fence_array or should it be a special entrypoint?  Collapsing all
> > the time likely means doing extra array calculations instead of the
> > dma_fence_array taking ownership of the array that's passed in.  My
> > gut says that cost is ok; but my gut doesn't spend much time in kernel
> > space.
>
> In my prototype implementation that is a dma_resv function you call and
> get either a single fence or a dma_fence_array with the collapsed fences
> in return.
>
> But I wouldn't add that to the general dma_fence_array_init function
> since this is still a rather special case. Well see the patches, they
> should be pretty self explaining.
>
> >   2. When we do the collapsing, should we call dma_fence_is_signaled()
> > to avoid adding signaled fences to the array?  It seems like avoiding
> > adding references to fences that are already signaled would let the
> > kernel clean them up faster and reduce the likelihood that a fence
> > will hang around forever because it keeps getting added to arrays with
> > other unsignaled fences.
>
> I think so. Can't think of a good reason why we would want to add
> already signaled fences to the array.
>
> Christian.
>
> >
> > --Jason
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/gvt/vgpu.c

between commit:

  04d6067f1f19 ("drm/i915/gvt: Fix unnecessary schedule timer when no vGPU 
exits")

from the drm-intel-fixes tree and commit:

  12d5861973c7 ("drm/i915/gvt: Make WARN* drm specific where vgpu ptr is 
available")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/gvt/vgpu.c
index 345c2aa3b491,abcde8ce1a9a..
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@@ -271,18 -272,12 +272,19 @@@ void intel_gvt_release_vgpu(struct inte
  void intel_gvt_destroy_vgpu(struct intel_vgpu *vgpu)
  {
struct intel_gvt *gvt = vgpu->gvt;
+   struct drm_i915_private *i915 = gvt->gt->i915;
  
-   WARN(vgpu->active, "vGPU is still active!\n");
 -  mutex_lock(>vgpu_lock);
 -
+   drm_WARN(>drm, vgpu->active, "vGPU is still active!\n");
  
 +  /*
 +   * remove idr first so later clean can judge if need to stop
 +   * service if no active vgpu.
 +   */
 +  mutex_lock(>lock);
 +  idr_remove(>vgpu_idr, vgpu->id);
 +  mutex_unlock(>lock);
 +
 +  mutex_lock(>vgpu_lock);
intel_gvt_debugfs_remove_vgpu(vgpu);
intel_vgpu_clean_sched_policy(vgpu);
intel_vgpu_clean_submission(vgpu);


pgpaq1RDIqnFA.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL v2] exynos-drm-fixes

[Inki Dae]

Hi Dave,

   Just one fixup to IOMMU initialization failure and memory leak
   detected by kmemleak detector.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae


The following changes since commit 513dc792d6060d5ef572e43852683097a8420f56:

  vgacon: Fix a UAF in vgacon_invert_region (2020-03-06 21:06:34 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-v5.6-rc5-v2

for you to fetch changes up to 07dc3678bacc2a75b1900febea7d996a31f178a2:

  drm/exynos: Fix cleanup of IOMMU related objects (2020-03-10 13:25:18 +0900)


Fix IOMMU initialization failure when Exynos DRM driver is rebound,
and also fix memory leak to iommu mapping object, which was
detected by kmemleak detector.


Marek Szyprowski (1):
  drm/exynos: Fix cleanup of IOMMU related objects

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  5 +++--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  5 +++--
 drivers/gpu/drm/exynos/exynos_drm_dma.c   | 28 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  6 --
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  |  5 +++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  5 +++--
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |  5 +++--
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   |  5 +++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   |  5 +++--
 drivers/gpu/drm/exynos/exynos_drm_scaler.c|  6 --
 drivers/gpu/drm/exynos/exynos_mixer.c |  7 +--
 11 files changed, 53 insertions(+), 29 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] spi: spi-fsl-dspi: fix DMA mapping

[Michael Walle]

Am 2020-03-10 14:02, schrieb Vladimir Oltean:

On Tue, 10 Mar 2020 at 10:12, Michael Walle  wrote:


Am 2020-03-10 08:40, schrieb Michael Walle:
> Am 2020-03-10 08:33, schrieb Michael Walle:
>> Use the correct device to request the DMA mapping. Otherwise the IOMMU
>> doesn't get the mapping and it will generate a page fault.
>>
>> The error messages look like:
>> [3.008452] arm-smmu 500.iommu: Unhandled context fault:
>> fsr=0x402, iova=0xf980, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
>> [3.020123] arm-smmu 500.iommu: Unhandled context fault:
>> fsr=0x402, iova=0xf980, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
>>
>> This was tested on a custom board with a LS1028A SoC.
>
> Oh fu.. please disregard this patch. DMA mapping still isn't working.
> Somehow I missed that the transfer mode was turned back to its default
> XSPI mode.

Damn. I need more coffee.. this patch IS working. Only the first probe
fails due to EPROBE_DEFER.

[2.539706] fsl-dspi 212.spi: rx dma channel not available 
(-517)

[2.546200] fsl-dspi 212.spi: can't get dma channels
[3.622774] spi-nor spi1.0: w25q128fw (16384 Kbytes)

-michael


I'm testing LS1028A with IOMMU_DEFAULT_PASSTHROUGH=y and I didn't have
time to change my setup now. I've also sent a v3 to my patch series
which is going to conflict with this one, sorry.


No worries, its easy enough to rebase.


I would have picked
your patch up with my series but I didn't have the right environment
to test it.


I'll resend a v2 once your series is working.

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

[PATCH v2 15/17] drm: make various debugfs_init() functions return 0

[Wambui Karuga]

Since commit 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails and should return void. Therefore, remove its use as the
return value of various debugfs_init() functions in drm, and have these
functions return 0 directly.

v2: convert debugfs_init() functions to return 0 instead of void to
avoid build breakage.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/drm_atomic.c  | 7 ---
 drivers/gpu/drm/drm_client.c  | 8 +---
 drivers/gpu/drm/drm_framebuffer.c | 8 +---
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9ccfbf213d72..c0056d9cc139 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1643,8 +1643,9 @@ static const struct drm_info_list 
drm_atomic_debugfs_list[] = {
 
 int drm_atomic_debugfs_init(struct drm_minor *minor)
 {
-   return drm_debugfs_create_files(drm_atomic_debugfs_list,
-   ARRAY_SIZE(drm_atomic_debugfs_list),
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(drm_atomic_debugfs_list,
+ARRAY_SIZE(drm_atomic_debugfs_list),
+minor->debugfs_root, minor);
+   return 0;
 }
 #endif
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 6b0c6ef8b9b3..82fbdee407b2 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -459,8 +459,10 @@ static const struct drm_info_list 
drm_client_debugfs_list[] = {
 
 int drm_client_debugfs_init(struct drm_minor *minor)
 {
-   return drm_debugfs_create_files(drm_client_debugfs_list,
-   ARRAY_SIZE(drm_client_debugfs_list),
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(drm_client_debugfs_list,
+ARRAY_SIZE(drm_client_debugfs_list),
+minor->debugfs_root, minor);
+
+   return 0;
 }
 #endif
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 57ac94ce9b9e..46be88271fe5 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -1209,8 +1209,10 @@ static const struct drm_info_list 
drm_framebuffer_debugfs_list[] = {
 
 int drm_framebuffer_debugfs_init(struct drm_minor *minor)
 {
-   return drm_debugfs_create_files(drm_framebuffer_debugfs_list,
-   ARRAY_SIZE(drm_framebuffer_debugfs_list),
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(drm_framebuffer_debugfs_list,
+ARRAY_SIZE(drm_framebuffer_debugfs_list),
+minor->debugfs_root, minor);
+
+   return 0;
 }
 #endif
-- 
2.25.1

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

Re: [PATCH v11 3/5] soc: mediatek: Move mt8173 MMSYS to platform driver

[Enric Balletbo i Serra]

Hi all,

On 10/3/20 10:40, Matthias Brugger wrote:
> 
> 
> On 09/03/2020 23:50, Stephen Boyd wrote:
>> Quoting Enric Balletbo Serra (2020-03-06 14:09:50)
>>> Missatge de Stephen Boyd  del dia dv., 6 de mar
>>> 2020 a les 22:37:

 Quoting Enric Balletbo i Serra (2020-03-06 08:30:16)
> On 5/3/20 22:01, Stephen Boyd wrote:
>> Quoting Enric Balletbo i Serra (2020-03-02 03:01:26)
>>> diff --git a/drivers/soc/mediatek/mtk-mmsys.c 
>>> b/drivers/soc/mediatek/mtk-mmsys.c
>>> new file mode 100644
>>> index ..473cdf732fb5
>>> --- /dev/null
>>> +++ b/drivers/soc/mediatek/mtk-mmsys.c
>>> @@ -0,0 +1,154 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +/*
>>> + * Copyright (c) 2014 MediaTek Inc.
>>> + * Author: James Liao 
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include "../../clk/mediatek/clk-gate.h"
>>> +#include "../../clk/mediatek/clk-mtk.h"
>>
>> Why not use include/linux/clk/?
>>
>
> I can move these files to include, this will impact a lot more of drivers 
> but,
> yes, I think is the right way.
>
>> But I also don't understand why the clk driver is moved outside of
>> drivers/clk/ into drivers/soc/. Commit text saying that it has shared
>> registers doesn't mean it can't still keep the clk driver part in the
>> drivers/clk/ area.
>>
>
> Actually moving this to the soc directory has been requested by CK 
> (mediatek) as
> a change in v8. You can see the discussion in [1]
>

 I can reply there in that thread if necessary, but we shouldn't need to
 force simple-mfd into DT bindings to support this. Match the compatible
 string in drivers/soc/ and register devices in software for the
 different pieces of this overall hardware block. If necessary, pass down
 the ioremapped addresss down through device data to each logical driver
 in the respective subsystem.

 So yes, it looks like an MFD, but that doesn't mean we have to change
 the DT binding or put it in drivers/mfd to support that. And we don't
 have to fix any problems with allowing two drivers to probe the same
 compatible string.

>>>
>>> That thread maybe has too much information and things evolved since
>>> then. Note that the final solution is not an MFD neither we change the
>>> bindings. I pointed to that thread just because CK (CK please correct
>>> me if I'm wrong) thought that the driver is not a pure clock driver
>>> and he preferred to move to drivers/soc/mediatek (in that thread, he
>>> exposes his opinion on that).  Sorry to introduce more confusion.
>>>
>>> You seem to be fine with the approach (just minor changes), so it
>>> looks to me that the only problem is if this should be in drivers/clk
>>> or drivers/soc. Honestly, this is not something I can't decide and
>>> I'll let you (the soc and clk maintainers) decide. I don't really have
>>> a strong opinion here. I don't mind move again to drivers/clk if that
>>> is what we want but let's come to an agreement.
>>>
>>
>> It's already in drivers/clk, so leave the clk part there and register
>> the clk device and any other devices by matching the compatible in
>> drivers/soc. That is my preferred solution. Can that be done?
>>
> 
> I think we can once again create a platform device in drivers/soc which 
> matches
> the drivers/clk and then do the routing in drivers/soc. Enric any thoughts?
> 

Yes, working already on a new version.

Thanks,
 Enric

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

[PATCH v2 06/17] drm/arm: make hdlcd_debugfs_init() return 0

[Wambui Karuga]

Since commit 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails and should return void. Therefore, remove its use as the
return value of hdlcd_debugfs_init() and have the latter function return
0 directly.

v2: make hdlcd_debugfs_init() return 0 instead of void to ensure that
each patch compiles individually.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/arm/hdlcd_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 2e053815b54a..bd0ad6f46a97 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -226,8 +226,10 @@ static struct drm_info_list hdlcd_debugfs_list[] = {
 
 static int hdlcd_debugfs_init(struct drm_minor *minor)
 {
-   return drm_debugfs_create_files(hdlcd_debugfs_list,
-   ARRAY_SIZE(hdlcd_debugfs_list), minor->debugfs_root, minor);
+   drm_debugfs_create_files(hdlcd_debugfs_list,
+ARRAY_SIZE(hdlcd_debugfs_list),
+minor->debugfs_root, minor);
+   return 0;
 }
 #endif
 
-- 
2.25.1

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

[PATCH v2 17/17] drm: convert .debugfs_init() hook to return void.

[Wambui Karuga]

As a result of commit 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail) and changes to various debugfs
functions in drm/core and across various drivers, there is no need for
the drm_driver.debugfs_init() hook to have a return value. Therefore,
declare it as void.

This also includes refactoring all users of the .debugfs_init() hook to
return void across the subsystem.

v2: include changes to the hook and drivers that use it in one patch to
prevent driver breakage and enable individual successful compilation of
this change.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/arc/arcpgu_drv.c  |  3 +--
 drivers/gpu/drm/arm/hdlcd_drv.c   |  3 +--
 drivers/gpu/drm/arm/malidp_drv.c  |  3 +--
 drivers/gpu/drm/drm_atomic.c  |  3 +--
 drivers/gpu/drm/drm_client.c  |  4 +---
 drivers/gpu/drm/drm_crtc_internal.h   |  2 +-
 drivers/gpu/drm/drm_debugfs.c | 12 +++-
 drivers/gpu/drm/drm_framebuffer.c |  4 +---
 drivers/gpu/drm/drm_gem_vram_helper.c |  6 +-
 drivers/gpu/drm/drm_internal.h|  2 +-
 drivers/gpu/drm/drm_mipi_dbi.c|  6 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c |  4 +---
 drivers/gpu/drm/msm/adreno/a5xx_debugfs.c |  6 ++
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h |  2 +-
 drivers/gpu/drm/msm/msm_debugfs.c | 12 +++-
 drivers/gpu/drm/msm/msm_debugfs.h |  2 +-
 drivers/gpu/drm/msm/msm_gpu.h |  2 +-
 drivers/gpu/drm/nouveau/nouveau_debugfs.c |  6 ++
 drivers/gpu/drm/nouveau/nouveau_debugfs.h |  8 +++-
 drivers/gpu/drm/omapdrm/omap_debugfs.c|  4 +---
 drivers/gpu/drm/omapdrm/omap_drv.h|  2 +-
 drivers/gpu/drm/pl111/pl111_debugfs.c |  4 +---
 drivers/gpu/drm/pl111/pl111_drm.h |  2 +-
 drivers/gpu/drm/qxl/qxl_debugfs.c | 21 +++--
 drivers/gpu/drm/qxl/qxl_drv.h | 13 +
 drivers/gpu/drm/qxl/qxl_ttm.c |  6 ++
 drivers/gpu/drm/sti/sti_drv.c |  3 +--
 drivers/gpu/drm/tegra/drm.c   |  3 +--
 drivers/gpu/drm/tilcdc/tilcdc_drv.c   |  4 +---
 drivers/gpu/drm/v3d/v3d_debugfs.c |  3 +--
 drivers/gpu/drm/v3d/v3d_drv.h |  2 +-
 drivers/gpu/drm/vc4/vc4_debugfs.c |  4 +---
 drivers/gpu/drm/vc4/vc4_drv.h |  2 +-
 drivers/gpu/drm/virtio/virtgpu_debugfs.c  |  3 +--
 drivers/gpu/drm/virtio/virtgpu_drv.h  |  2 +-
 include/drm/drm_client.h  |  2 +-
 include/drm/drm_drv.h |  2 +-
 include/drm/drm_gem_vram_helper.h |  2 +-
 include/drm/drm_mipi_dbi.h|  2 +-
 39 files changed, 58 insertions(+), 118 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 660b25f9588e..c05d001163e0 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -137,12 +137,11 @@ static struct drm_info_list arcpgu_debugfs_list[] = {
{ "clocks", arcpgu_show_pxlclock, 0 },
 };
 
-static int arcpgu_debugfs_init(struct drm_minor *minor)
+static void arcpgu_debugfs_init(struct drm_minor *minor)
 {
drm_debugfs_create_files(arcpgu_debugfs_list,
 ARRAY_SIZE(arcpgu_debugfs_list),
 minor->debugfs_root, minor);
-   return 0;
 }
 #endif
 
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index bd0ad6f46a97..194419f47c5e 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -224,12 +224,11 @@ static struct drm_info_list hdlcd_debugfs_list[] = {
{ "clocks", hdlcd_show_pxlclock, 0 },
 };
 
-static int hdlcd_debugfs_init(struct drm_minor *minor)
+static void hdlcd_debugfs_init(struct drm_minor *minor)
 {
drm_debugfs_create_files(hdlcd_debugfs_list,
 ARRAY_SIZE(hdlcd_debugfs_list),
 minor->debugfs_root, minor);
-   return 0;
 }
 #endif
 
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 37d92a06318e..def8c9ffafca 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -548,7 +548,7 @@ static const struct file_operations malidp_debugfs_fops = {
.release = single_release,
 };
 
-static int malidp_debugfs_init(struct drm_minor *minor)
+static void malidp_debugfs_init(struct drm_minor *minor)
 {
struct malidp_drm *malidp = minor->dev->dev_private;
 
@@ -557,7 +557,6 @@ static int malidp_debugfs_init(struct drm_minor *minor)
spin_lock_init(>errors_lock);
debugfs_create_file("debug", S_IRUGO | S_IWUSR, minor->debugfs_root,
minor->dev, _debugfs_fops);
-   return 0;
 }
 
 #endif //CONFIG_DEBUG_FS
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c

Re: [linux-sunxi] [PATCH 2/2] ARM: dts: sun4i: Add support for Topwise A721 tablet

[Ondřej Jirman]

On Tue, Mar 10, 2020 at 11:27:24AM +0100, Pascal Roeleven wrote:
> The Topwise A721/LY-F1 tablet is a tablet sold around 2012 under
> different brands. The mainboard mentions A721 clearly, so this tablet
> is best known under this name.
> 
> Signed-off-by: Pascal Roeleven 
> ---
>  arch/arm/boot/dts/Makefile   |   3 +-
>  arch/arm/boot/dts/sun4i-a10-topwise-a721.dts | 302 +++
>  2 files changed, 304 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
> 
> +/dts-v1/;
> +#include "sun4i-a10.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Topwise A721";
> + compatible = "topwise,a721", "allwinner,sun4i-a10";

And you also need to add the compatible to:

  Documentation/devicetree/bindings/arm/sunxi.yaml

regards,
o.

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

[PATCH v2 10/17] drm/vram-helper: make drm_vram_mm_debugfs_init() return 0

[Wambui Karuga]

Since 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails and should return void. Therefore, remove its use as the
return value of drm_vram_mm_debugfs_init(), and have the function
return 0 directly.

v2: have drm_vram_mm_debugfs_init() return 0 instead of void to avoid
introducing build issues and build breakage.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
Acked-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 92a11bb42365..c8bcc8609650 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1048,14 +1048,12 @@ static const struct drm_info_list 
drm_vram_mm_debugfs_list[] = {
  */
 int drm_vram_mm_debugfs_init(struct drm_minor *minor)
 {
-   int ret = 0;
-
 #if defined(CONFIG_DEBUG_FS)
-   ret = drm_debugfs_create_files(drm_vram_mm_debugfs_list,
-  ARRAY_SIZE(drm_vram_mm_debugfs_list),
-  minor->debugfs_root, minor);
+   drm_debugfs_create_files(drm_vram_mm_debugfs_list,
+ARRAY_SIZE(drm_vram_mm_debugfs_list),
+minor->debugfs_root, minor);
 #endif
-   return ret;
+   return 0;
 }
 EXPORT_SYMBOL(drm_vram_mm_debugfs_init);
 
-- 
2.25.1

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

[PATCH v2 01/17] drm/tegra: remove checks for debugfs functions return value

[Wambui Karuga]

Since 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail) there is no need to check the
return value of drm_debugfs_create_files(). Therefore, remove the
return checks and error handling of the drm_debugfs_create_files()
function from various debugfs init functions in drm/tegra and have
them return 0 directly.

v2: remove conversion of tegra_debugfs_init() to void to avoid build
breakage.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/tegra/dc.c   | 11 +--
 drivers/gpu/drm/tegra/drm.c  |  7 ---
 drivers/gpu/drm/tegra/dsi.c  | 11 +--
 drivers/gpu/drm/tegra/hdmi.c | 11 +--
 drivers/gpu/drm/tegra/sor.c  | 11 +--
 5 files changed, 8 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 7c70fd31a4c2..e70d58b21964 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1496,7 +1496,6 @@ static int tegra_dc_late_register(struct drm_crtc *crtc)
struct drm_minor *minor = crtc->dev->primary;
struct dentry *root;
struct tegra_dc *dc = to_tegra_dc(crtc);
-   int err;
 
 #ifdef CONFIG_DEBUG_FS
root = crtc->debugfs_entry;
@@ -1512,17 +1511,9 @@ static int tegra_dc_late_register(struct drm_crtc *crtc)
for (i = 0; i < count; i++)
dc->debugfs_files[i].data = dc;
 
-   err = drm_debugfs_create_files(dc->debugfs_files, count, root, minor);
-   if (err < 0)
-   goto free;
+   drm_debugfs_create_files(dc->debugfs_files, count, root, minor);
 
return 0;
-
-free:
-   kfree(dc->debugfs_files);
-   dc->debugfs_files = NULL;
-
-   return err;
 }
 
 static void tegra_dc_early_unregister(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index bd268028fb3d..6ec224f3d824 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -841,9 +841,10 @@ static struct drm_info_list tegra_debugfs_list[] = {
 
 static int tegra_debugfs_init(struct drm_minor *minor)
 {
-   return drm_debugfs_create_files(tegra_debugfs_list,
-   ARRAY_SIZE(tegra_debugfs_list),
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(tegra_debugfs_list,
+ARRAY_SIZE(tegra_debugfs_list),
+minor->debugfs_root, minor);
+   return 0;
 }
 #endif
 
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 88b9d64c77bf..30626fcf61eb 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -234,7 +234,6 @@ static int tegra_dsi_late_register(struct drm_connector 
*connector)
struct drm_minor *minor = connector->dev->primary;
struct dentry *root = connector->debugfs_entry;
struct tegra_dsi *dsi = to_dsi(output);
-   int err;
 
dsi->debugfs_files = kmemdup(debugfs_files, sizeof(debugfs_files),
 GFP_KERNEL);
@@ -244,17 +243,9 @@ static int tegra_dsi_late_register(struct drm_connector 
*connector)
for (i = 0; i < count; i++)
dsi->debugfs_files[i].data = dsi;
 
-   err = drm_debugfs_create_files(dsi->debugfs_files, count, root, minor);
-   if (err < 0)
-   goto free;
+   drm_debugfs_create_files(dsi->debugfs_files, count, root, minor);
 
return 0;
-
-free:
-   kfree(dsi->debugfs_files);
-   dsi->debugfs_files = NULL;
-
-   return err;
 }
 
 static void tegra_dsi_early_unregister(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 6f117628f257..d7799d13d8ad 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -1064,7 +1064,6 @@ static int tegra_hdmi_late_register(struct drm_connector 
*connector)
struct drm_minor *minor = connector->dev->primary;
struct dentry *root = connector->debugfs_entry;
struct tegra_hdmi *hdmi = to_hdmi(output);
-   int err;
 
hdmi->debugfs_files = kmemdup(debugfs_files, sizeof(debugfs_files),
  GFP_KERNEL);
@@ -1074,17 +1073,9 @@ static int tegra_hdmi_late_register(struct drm_connector 
*connector)
for (i = 0; i < count; i++)
hdmi->debugfs_files[i].data = hdmi;
 
-   err = drm_debugfs_create_files(hdmi->debugfs_files, count, root, minor);
-   if (err < 0)
-   goto free;
+   drm_debugfs_create_files(hdmi->debugfs_files, count, root, minor);
 
return 0;
-
-free:
-   kfree(hdmi->debugfs_files);
-   hdmi->debugfs_files = NULL;
-
-   return err;
 }
 
 static void tegra_hdmi_early_unregister(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 81226a4953c1..47c1d133069a 

[PATCH v2 04/17] drm/vc4: remove check of return value of drm_debugfs functions

[Wambui Karuga]

Since 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails and should return void. Therefore, remove unnecessary check and
error handling for the return value of drm_debugfs_create_files()
in vc4_debugfs_init().

v2: remove conversion of vc4_debugfs_init() to void to enable individual
compilation and avoid build issues and breakage.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/vc4/vc4_debugfs.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_debugfs.c 
b/drivers/gpu/drm/vc4/vc4_debugfs.c
index b61b2d3407b5..1835f12337ec 100644
--- a/drivers/gpu/drm/vc4/vc4_debugfs.c
+++ b/drivers/gpu/drm/vc4/vc4_debugfs.c
@@ -30,11 +30,8 @@ vc4_debugfs_init(struct drm_minor *minor)
minor->debugfs_root, >load_tracker_enabled);
 
list_for_each_entry(entry, >debugfs_list, link) {
-   int ret = drm_debugfs_create_files(>info, 1,
-  minor->debugfs_root, minor);
-
-   if (ret)
-   return ret;
+   drm_debugfs_create_files(>info, 1,
+minor->debugfs_root, minor);
}
 
return 0;
-- 
2.25.1

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

[PATCH v3 0/2] Add LVDS panel support to HiHope RZ/G2M

[Lad Prabhakar]

Dear All,

The HiHope RZ/G2M is advertised as supporting panel idk-1110wr from
Advantech, but the panel doesn't come with the board, it has to purchased
separatey, therefore this series adds panel support to a new DT.

The v2 version somehow missed being merged.

v2->v3
 * Included Reviewed-by from Rob and Laurent
 * Switched to dual license
 * Added myself as the maintainer
 * Updated copyright year
 * Rebased the patches

v1->v2
 * fixed a space according to Geert's feedback.

Thanks,
Prabhakar

Fabrizio Castro (2):
  dt-bindings: display: Add idk-1110wr binding
  arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display

 .../display/panel/advantech,idk-1110wr.yaml| 69 +
 arch/arm64/boot/dts/renesas/Makefile   |  1 +
 .../r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts| 86 ++
 3 files changed, 156 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
 create mode 100644 
arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts

-- 
2.7.4

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

[PATCH 0/2] Add support for Topwise A721 tablet

[Pascal Roeleven]

This series add support for the Topwise A721 tablet and it's display.
It is an old tablet (around 2012) but it might be useful as reference
as the devicetree is pretty complete.

Pascal Roeleven (2):
  drm/panel: Add Starry KR070PE2T
  ARM: dts: sun4i: Add support for Topwise A721 tablet

 .../display/panel/starry,kr070pe2t.txt|   7 +
 arch/arm/boot/dts/Makefile|   3 +-
 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts  | 302 ++
 drivers/gpu/drm/panel/panel-simple.c  |  26 ++
 4 files changed, 337 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
 create mode 100644 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts

-- 
2.20.1

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

Re: [PATCH] spi: spi-fsl-dspi: fix DMA mapping

[Vladimir Oltean]

On Tue, 10 Mar 2020 at 10:12, Michael Walle  wrote:
>
> Am 2020-03-10 08:40, schrieb Michael Walle:
> > Am 2020-03-10 08:33, schrieb Michael Walle:
> >> Use the correct device to request the DMA mapping. Otherwise the IOMMU
> >> doesn't get the mapping and it will generate a page fault.
> >>
> >> The error messages look like:
> >> [3.008452] arm-smmu 500.iommu: Unhandled context fault:
> >> fsr=0x402, iova=0xf980, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
> >> [3.020123] arm-smmu 500.iommu: Unhandled context fault:
> >> fsr=0x402, iova=0xf980, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
> >>
> >> This was tested on a custom board with a LS1028A SoC.
> >
> > Oh fu.. please disregard this patch. DMA mapping still isn't working.
> > Somehow I missed that the transfer mode was turned back to its default
> > XSPI mode.
>
> Damn. I need more coffee.. this patch IS working. Only the first probe
> fails due to EPROBE_DEFER.
>
> [2.539706] fsl-dspi 212.spi: rx dma channel not available (-517)
> [2.546200] fsl-dspi 212.spi: can't get dma channels
> [3.622774] spi-nor spi1.0: w25q128fw (16384 Kbytes)
>
> -michael

I'm testing LS1028A with IOMMU_DEFAULT_PASSTHROUGH=y and I didn't have
time to change my setup now. I've also sent a v3 to my patch series
which is going to conflict with this one, sorry. I would have picked
your patch up with my series but I didn't have the right environment
to test it.

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

[PATCH v8] dt-bindings: display: Add idk-2121wr binding

[Lad Prabhakar]

From: Fabrizio Castro 

Add binding for the idk-2121wr LVDS panel from Advantech.

Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm

Signed-off-by: Fabrizio Castro 
Signed-off-by: Lad Prabhakar 
---

Hi All,
This patch is part of series [1] ("Add dual-LVDS panel support to EK874),
all the patches have been accepted from it except this one. I have fixed
Rob's comments in this version of the patch.

[1] https://patchwork.kernel.org/cover/11297589/

V7->8
 * Dropped ref to lvds.yaml, since the panel a dual channel LVDS, as a
   result the root port is called as ports instead of port and the child
   node port@0 and port@1 are used for even and odd pixels, hence binding
   has required property as ports instead of port.

v6->7
 * Added reference to lvds.yaml
 * Changed maintainer to myself
 * Switched to dual license
 * Dropped required properties except for ports as rest are already listed
   in lvds.panel
 * Dropped Reviewed-by tag of Laurent, due to the changes made it might not
   be valid.

v5->v6:
 * No change

v4->v5:
* No change

v3->v4:
* Absorbed patch "dt-bindings: display: Add bindings for LVDS
  bus-timings"
* Big restructuring after Rob's and Laurent's comments

v2->v3:
* New patch

 .../display/panel/advantech,idk-2121wr.yaml| 122 +
 1 file changed, 122 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml 
b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
new file mode 100644
index 000..6b7fddc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/advantech,idk-2121wr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech IDK-2121WR 21.5" Full-HD dual-LVDS panel
+
+maintainers:
+  - Lad Prabhakar 
+  - Thierry Reding 
+
+description: |
+  The IDK-2121WR from Advantech is a Full-HD dual-LVDS panel.
+  A dual-LVDS interface is a dual-link connection with even pixels traveling
+  on one link, and with odd pixels traveling on the other link.
+
+  The panel expects odd pixels on the first port, and even pixels on the
+  second port, therefore the ports must be marked accordingly (with either
+  dual-lvds-odd-pixels or dual-lvds-even-pixels).
+
+properties:
+  compatible:
+items:
+  - const: advantech,idk-2121wr
+  - {} # panel-lvds, but not listed here to avoid false select
+
+  width-mm:
+const: 476
+
+  height-mm:
+const: 268
+
+  data-mapping:
+const: vesa-24
+
+  panel-timing: true
+
+  ports:
+type: object
+properties:
+  port@0:
+type: object
+description: The sink for odd pixels.
+properties:
+  reg:
+const: 0
+
+  dual-lvds-odd-pixels: true
+
+required:
+  - reg
+  - dual-lvds-odd-pixels
+
+  port@1:
+type: object
+description: The sink for even pixels.
+properties:
+  reg:
+const: 1
+
+  dual-lvds-even-pixels: true
+
+required:
+  - reg
+  - dual-lvds-even-pixels
+
+additionalProperties: false
+
+required:
+  - compatible
+  - width-mm
+  - height-mm
+  - data-mapping
+  - panel-timing
+  - ports
+
+examples:
+  - |+
+panel-lvds {
+  compatible = "advantech,idk-2121wr", "panel-lvds";
+
+  width-mm = <476>;
+  height-mm = <268>;
+
+  data-mapping = "vesa-24";
+
+  panel-timing {
+clock-frequency = <14850>;
+hactive = <1920>;
+vactive = <1080>;
+hsync-len = <44>;
+hfront-porch = <88>;
+hback-porch = <148>;
+vfront-porch = <4>;
+vback-porch = <36>;
+vsync-len = <5>;
+  };
+
+  ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+  reg = <0>;
+  dual-lvds-odd-pixels;
+  panel_in0: endpoint {
+remote-endpoint = <_out>;
+  };
+};
+
+port@1 {
+  reg = <1>;
+  dual-lvds-even-pixels;
+  panel_in1: endpoint {
+remote-endpoint = <_out>;
+  };
+};
+  };
+};
+
+...
-- 
2.7.4

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

[PATCH v2 13/17] drm/omap: remove checks for return value of drm_debugfs functions

[Wambui Karuga]

Since 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), there is no need to ever check
the return value for drm_debugfs_create_files(). Therefore remove the
checks for the return value and subsequent error handling in
omap_debugfs_init().

These changes also enables the changing of omap_debugfs_init() to return
0 directly.

v2: convert omap_debugfs_init() to return 0 instead of void to avoid
introduction of build issues and enable individual driver compilation.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/omapdrm/omap_debugfs.c | 27 +++---
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_debugfs.c 
b/drivers/gpu/drm/omapdrm/omap_debugfs.c
index 34dfb33145b4..ed63dcced79a 100644
--- a/drivers/gpu/drm/omapdrm/omap_debugfs.c
+++ b/drivers/gpu/drm/omapdrm/omap_debugfs.c
@@ -82,29 +82,16 @@ static struct drm_info_list omap_dmm_debugfs_list[] = {
 
 int omap_debugfs_init(struct drm_minor *minor)
 {
-   struct drm_device *dev = minor->dev;
-   int ret;
-
-   ret = drm_debugfs_create_files(omap_debugfs_list,
-   ARRAY_SIZE(omap_debugfs_list),
-   minor->debugfs_root, minor);
-
-   if (ret) {
-   dev_err(dev->dev, "could not install omap_debugfs_list\n");
-   return ret;
-   }
+   drm_debugfs_create_files(omap_debugfs_list,
+ARRAY_SIZE(omap_debugfs_list),
+minor->debugfs_root, minor);
 
if (dmm_is_available())
-   ret = drm_debugfs_create_files(omap_dmm_debugfs_list,
-   ARRAY_SIZE(omap_dmm_debugfs_list),
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(omap_dmm_debugfs_list,
+ARRAY_SIZE(omap_dmm_debugfs_list),
+minor->debugfs_root, minor);
 
-   if (ret) {
-   dev_err(dev->dev, "could not install omap_dmm_debugfs_list\n");
-   return ret;
-   }
-
-   return ret;
+   return 0;
 }
 
 #endif
-- 
2.25.1

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

Re: [PATCH v7 12/13] backlight: pwm_bl: Use 64-bit division macros for period and duty cycle

[Guru Das Srinagesh]

On Tue, Mar 10, 2020 at 02:34:32PM +, Daniel Thompson wrote:
> This patch looks like it is a tiny change to get the pwm_backlight to
> perform 64-bit division. Most of the above text is completely irrelevant
> to the change contained in this patch. No need to justify the change in
> the PWM structures here since that can go in the patch that changes
> those structures.  Just describe what this patch does, perhaps something
> like the following:
> 
> The PWM API will shortly switch the state.period and
> state.duty_cycle fields to 64-bit values. Make pwm_bl
> ready for this transition by adopting 64-bit division
> macros.

Will update the commit text accordingly.

> Also please copy the backlight maintainers into the covering letter. It
> is useful to place patches like this into context.

Will do.

Thank you.

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

[PATCH v2 02/17] drm/tilcdc: remove check for return value of debugfs functions.

[Wambui Karuga]

Since 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails. Therefore, remove the check and error handling of the return
value of drm_debugfs_create_files() as it is not needed in
tilcdc_debugfs_init().

Also remove local variables that are not used after the changes.

v2: remove conversion of tilcdc_debugfs_init() to void to avoid build
breakage and enable individual compilation.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 0791a0200cc3..3f7071eb9c78 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -480,24 +480,17 @@ static struct drm_info_list tilcdc_debugfs_list[] = {
 
 static int tilcdc_debugfs_init(struct drm_minor *minor)
 {
-   struct drm_device *dev = minor->dev;
struct tilcdc_module *mod;
-   int ret;
 
-   ret = drm_debugfs_create_files(tilcdc_debugfs_list,
-   ARRAY_SIZE(tilcdc_debugfs_list),
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(tilcdc_debugfs_list,
+ARRAY_SIZE(tilcdc_debugfs_list),
+minor->debugfs_root, minor);
 
list_for_each_entry(mod, _list, list)
if (mod->funcs->debugfs_init)
mod->funcs->debugfs_init(mod, minor);
 
-   if (ret) {
-   dev_err(dev->dev, "could not install tilcdc_debugfs_list\n");
-   return ret;
-   }
-
-   return ret;
+   return 0;
 }
 #endif
 
-- 
2.25.1

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

RE: [PATCH v8] dt-bindings: display: Add idk-2121wr binding

[Prabhakar Mahadev Lad]

Hi Sam,

> -Original Message-
> From: Sam Ravnborg 
> Sent: 10 March 2020 19:54
> To: Prabhakar Mahadev Lad 
> Cc: Thierry Reding ; David Airlie
> ; Daniel Vetter ; Rob Herring
> ; Mark Rutland ; dri-
> de...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Fabrizio Castro 
> Subject: Re: [PATCH v8] dt-bindings: display: Add idk-2121wr binding
>
> Hi Prabhakar
>
> On Tue, Mar 10, 2020 at 07:39:29PM +, Lad Prabhakar wrote:
> > From: Fabrizio Castro 
> >
> > Add binding for the idk-2121wr LVDS panel from Advantech.
> >
> > Some panel-specific documentation can be found here:
> > https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-
> Brightness/mo
> > del-IDK-2121WR-K2FHA2E.htm
> >
> > Signed-off-by: Fabrizio Castro 
> > Signed-off-by: Lad Prabhakar  lad...@bp.renesas.com>
> > ---
> >
> > Hi All,
> > This patch is part of series [1] ("Add dual-LVDS panel support to
> > EK874), all the patches have been accepted from it except this one. I
> > have fixed Rob's comments in this version of the patch.
> >
> > [1] https://patchwork.kernel.org/cover/11297589/
> >
> > V7->8
> >  * Dropped ref to lvds.yaml, since the panel a dual channel LVDS, as a
> >result the root port is called as ports instead of port and the child
> >node port@0 and port@1 are used for even and odd pixels, hence
> binding
> >has required property as ports instead of port.
>
> Looks good, thanks for your persistence..
> Applied and pushed to drm-misc-next.
>
Thank you for the review and acceptance.

Cheers,
--Prabhakar

> Sam


Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, 
Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 
Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 
3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. 
no.: DE 14978647
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] spi: spi-fsl-dspi: fix DMA mapping

[Vladimir Oltean]

On Tue, 10 Mar 2020 at 19:14, Mark Brown  wrote:
>
> On Tue, Mar 10, 2020 at 03:12:45PM +0100, Michael Walle wrote:
> > Am 2020-03-10 14:02, schrieb Vladimir Oltean:
>
> > > I'm testing LS1028A with IOMMU_DEFAULT_PASSTHROUGH=y and I didn't have
> > > time to change my setup now. I've also sent a v3 to my patch series
> > > which is going to conflict with this one, sorry.
>
> > No worries, its easy enough to rebase.
>
> > > I would have picked
> > > your patch up with my series but I didn't have the right environment
> > > to test it.
>
> > I'll resend a v2 once your series is working.
>
> Since it looks like your series might need another spin anyway I'm
> thinking it's sensible to apply this now and you rebase instead?  Cuts
> down on the number of pending patches if nothing else (unless the
> testing stuff gets sorted out of course).

Sure, go ahead.

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

[PATCH v2] fbdev: s1d13xxxfb: add missed unregister_framebuffer in remove

[Chuhong Yuan]

The driver calls register_framebuffer() in probe but does not call
unregister_framebuffer() in remove.
Rename current remove to __s1d13xxxfb_remove() for error handler.
Then add a new remove to call unregister_framebuffer().

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Rename the existing remove and add a new one to ensure the correctness
of error handler in probe.

 drivers/video/fbdev/s1d13xxxfb.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/s1d13xxxfb.c b/drivers/video/fbdev/s1d13xxxfb.c
index 8048499e398d..bafea3d09bba 100644
--- a/drivers/video/fbdev/s1d13xxxfb.c
+++ b/drivers/video/fbdev/s1d13xxxfb.c
@@ -721,9 +721,8 @@ static void s1d13xxxfb_fetch_hw_state(struct fb_info *info)
xres, yres, xres_virtual, yres_virtual, is_color, is_dual, 
is_tft);
 }
 
-
 static int
-s1d13xxxfb_remove(struct platform_device *pdev)
+__s1d13xxxfb_remove(struct platform_device *pdev)
 {
struct fb_info *info = platform_get_drvdata(pdev);
struct s1d13xxxfb_par *par = NULL;
@@ -752,6 +751,18 @@ s1d13xxxfb_remove(struct platform_device *pdev)
return 0;
 }
 
+static int
+s1d13xxxfb_remove(struct platform_device *pdev)
+{
+   struct fb_info *info = platform_get_drvdata(pdev);
+
+   if (info)
+   unregister_framebuffer(info);
+
+   return __s1d13xxxfb_remove(pdev);
+}
+
+
 static int s1d13xxxfb_probe(struct platform_device *pdev)
 {
struct s1d13xxxfb_par *default_par;
@@ -895,7 +906,7 @@ static int s1d13xxxfb_probe(struct platform_device *pdev)
return 0;
 
 bail:
-   s1d13xxxfb_remove(pdev);
+   __s1d13xxxfb_remove(pdev);
return ret;
 
 }
-- 
2.25.1

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

[PATCH v2 12/17] drm/pl111: make pl111_debugfs_init return 0

[Wambui Karuga]

Since 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail) drm_debugfs_create_files()
should return void. Therefore, remove its use as the return value in
pl111_debugfs_init(), and have the function return 0 directly.

v2: have pl111_debugfs_init() return 0 instead of void to avoid build
breakage for individual compilation.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/pl111/pl111_debugfs.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_debugfs.c 
b/drivers/gpu/drm/pl111/pl111_debugfs.c
index 3c8e82016854..5595b19c91ce 100644
--- a/drivers/gpu/drm/pl111/pl111_debugfs.c
+++ b/drivers/gpu/drm/pl111/pl111_debugfs.c
@@ -54,7 +54,9 @@ static const struct drm_info_list pl111_debugfs_list[] = {
 int
 pl111_debugfs_init(struct drm_minor *minor)
 {
-   return drm_debugfs_create_files(pl111_debugfs_list,
-   ARRAY_SIZE(pl111_debugfs_list),
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(pl111_debugfs_list,
+ARRAY_SIZE(pl111_debugfs_list),
+minor->debugfs_root, minor);
+
+   return 0;
 }
-- 
2.25.1

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

[PATCH v2 08/17] drm/msm: remove checks for return value of drm_debugfs_create_files()

[Wambui Karuga]

Since commit 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files never
fails and only returns 0. Therefore, the unnecessary checks for its
return value and error handling in various debugfs_init() functions in
drm/msm and have the functions return 0 directly.

v2: have debug functions return 0 instead of void to avoid build
breakage and ensure standalone compilation.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 12 +++-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  | 14 +++---
 drivers/gpu/drm/msm/msm_debugfs.c | 13 -
 3 files changed, 10 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c 
b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
index 075ecce4b5e0..011ab6353dbb 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
@@ -151,21 +151,15 @@ DEFINE_SIMPLE_ATTRIBUTE(reset_fops, NULL, reset_set, 
"%llx\n");
 int a5xx_debugfs_init(struct msm_gpu *gpu, struct drm_minor *minor)
 {
struct drm_device *dev;
-   int ret;
 
if (!minor)
return 0;
 
dev = minor->dev;
 
-   ret = drm_debugfs_create_files(a5xx_debugfs_list,
-   ARRAY_SIZE(a5xx_debugfs_list),
-   minor->debugfs_root, minor);
-
-   if (ret) {
-   DRM_DEV_ERROR(dev->dev, "could not install 
a5xx_debugfs_list\n");
-   return ret;
-   }
+   drm_debugfs_create_files(a5xx_debugfs_list,
+ARRAY_SIZE(a5xx_debugfs_list),
+minor->debugfs_root, minor);
 
debugfs_create_file("reset", S_IWUGO, minor->debugfs_root, dev,
_fops);
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 6650f478b226..41b461128bbc 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -259,17 +259,9 @@ static struct drm_info_list mdp5_debugfs_list[] = {
 
 static int mdp5_kms_debugfs_init(struct msm_kms *kms, struct drm_minor *minor)
 {
-   struct drm_device *dev = minor->dev;
-   int ret;
-
-   ret = drm_debugfs_create_files(mdp5_debugfs_list,
-   ARRAY_SIZE(mdp5_debugfs_list),
-   minor->debugfs_root, minor);
-
-   if (ret) {
-   DRM_DEV_ERROR(dev->dev, "could not install 
mdp5_debugfs_list\n");
-   return ret;
-   }
+   drm_debugfs_create_files(mdp5_debugfs_list,
+ARRAY_SIZE(mdp5_debugfs_list),
+minor->debugfs_root, minor);
 
return 0;
 }
diff --git a/drivers/gpu/drm/msm/msm_debugfs.c 
b/drivers/gpu/drm/msm/msm_debugfs.c
index 1c74381a4fc9..6378157e1fff 100644
--- a/drivers/gpu/drm/msm/msm_debugfs.c
+++ b/drivers/gpu/drm/msm/msm_debugfs.c
@@ -220,14 +220,9 @@ int msm_debugfs_init(struct drm_minor *minor)
struct msm_drm_private *priv = dev->dev_private;
int ret;
 
-   ret = drm_debugfs_create_files(msm_debugfs_list,
-   ARRAY_SIZE(msm_debugfs_list),
-   minor->debugfs_root, minor);
-
-   if (ret) {
-   DRM_DEV_ERROR(dev->dev, "could not install msm_debugfs_list\n");
-   return ret;
-   }
+   drm_debugfs_create_files(msm_debugfs_list,
+ARRAY_SIZE(msm_debugfs_list),
+minor->debugfs_root, minor);
 
debugfs_create_file("gpu", S_IRUSR, minor->debugfs_root,
dev, _gpu_fops);
@@ -238,7 +233,7 @@ int msm_debugfs_init(struct drm_minor *minor)
return ret;
}
 
-   return ret;
+   return 0;
 }
 #endif
 
-- 
2.25.1

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

[PATCH v2 03/17] drm/v3d: make v3d_debugfs_init() return 0

[Wambui Karuga]

Since commit 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails and should return void. Therefore, remove its use as the
return value of v3d_debugfs_init() and have the function return 0
directly instead.

v2: remove conversion of v3d_debugfs_init() to void to avoid build
breakage and enable individual compilation.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/v3d/v3d_debugfs.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c 
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index 9e953ce64ef7..57dded6a3957 100644
--- a/drivers/gpu/drm/v3d/v3d_debugfs.c
+++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
@@ -261,7 +261,8 @@ static const struct drm_info_list v3d_debugfs_list[] = {
 int
 v3d_debugfs_init(struct drm_minor *minor)
 {
-   return drm_debugfs_create_files(v3d_debugfs_list,
-   ARRAY_SIZE(v3d_debugfs_list),
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(v3d_debugfs_list,
+ARRAY_SIZE(v3d_debugfs_list),
+minor->debugfs_root, minor);
+   return 0;
 }
-- 
2.25.1

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

[PATCH v2 16/17] drm/debugfs: remove checks for return value of drm_debugfs functions.

[Wambui Karuga]

Since 987d65d01356 (drm: debugfs: make drm_debugfs_create_files() never
fail), there is no need to check the return value of
drm_debugfs_create_files(). Therefore, remove remove unnecessary checks
and error handling statement blocks for its return value.

These changes also enable changing drm_debugfs_create_files() to return
void.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/drm_debugfs.c | 33 +++--
 include/drm/drm_debugfs.h | 16 +++-
 2 files changed, 14 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4e673d318503..e13f21642f88 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -172,8 +172,8 @@ static const struct file_operations drm_debugfs_fops = {
  *  drm_info_list in the given root directory. These files will be 
removed
  * automatically on drm_debugfs_cleanup().
  */
-int drm_debugfs_create_files(const struct drm_info_list *files, int count,
-struct dentry *root, struct drm_minor *minor)
+void drm_debugfs_create_files(const struct drm_info_list *files, int count,
+ struct dentry *root, struct drm_minor *minor)
 {
struct drm_device *dev = minor->dev;
struct drm_info_node *tmp;
@@ -199,7 +199,6 @@ int drm_debugfs_create_files(const struct drm_info_list 
*files, int count,
list_add(>list, >debugfs_list);
mutex_unlock(>debugfs_lock);
}
-   return 0;
 }
 EXPORT_SYMBOL(drm_debugfs_create_files);
 
@@ -215,35 +214,17 @@ int drm_debugfs_init(struct drm_minor *minor, int 
minor_id,
sprintf(name, "%d", minor_id);
minor->debugfs_root = debugfs_create_dir(name, root);
 
-   ret = drm_debugfs_create_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES,
-  minor->debugfs_root, minor);
-   if (ret) {
-   debugfs_remove(minor->debugfs_root);
-   minor->debugfs_root = NULL;
-   DRM_ERROR("Failed to create core drm debugfs files\n");
-   return ret;
-   }
+   drm_debugfs_create_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES,
+minor->debugfs_root, minor);
 
if (drm_drv_uses_atomic_modeset(dev)) {
-   ret = drm_atomic_debugfs_init(minor);
-   if (ret) {
-   DRM_ERROR("Failed to create atomic debugfs files\n");
-   return ret;
-   }
+   drm_atomic_debugfs_init(minor);
}
 
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
-   ret = drm_framebuffer_debugfs_init(minor);
-   if (ret) {
-   DRM_ERROR("Failed to create framebuffer debugfs 
file\n");
-   return ret;
-   }
+   drm_framebuffer_debugfs_init(minor);
 
-   ret = drm_client_debugfs_init(minor);
-   if (ret) {
-   DRM_ERROR("Failed to create client debugfs file\n");
-   return ret;
-   }
+   drm_client_debugfs_init(minor);
}
 
if (dev->driver->debugfs_init) {
diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
index 7501e323d383..2188dc83957f 100644
--- a/include/drm/drm_debugfs.h
+++ b/include/drm/drm_debugfs.h
@@ -80,18 +80,16 @@ struct drm_info_node {
 };
 
 #if defined(CONFIG_DEBUG_FS)
-int drm_debugfs_create_files(const struct drm_info_list *files,
-int count, struct dentry *root,
-struct drm_minor *minor);
+void drm_debugfs_create_files(const struct drm_info_list *files,
+ int count, struct dentry *root,
+ struct drm_minor *minor);
 int drm_debugfs_remove_files(const struct drm_info_list *files,
 int count, struct drm_minor *minor);
 #else
-static inline int drm_debugfs_create_files(const struct drm_info_list *files,
-  int count, struct dentry *root,
-  struct drm_minor *minor)
-{
-   return 0;
-}
+static inline void drm_debugfs_create_files(const struct drm_info_list *files,
+   int count, struct dentry *root,
+   struct drm_minor *minor)
+{}
 
 static inline int drm_debugfs_remove_files(const struct drm_info_list *files,
   int count, struct drm_minor *minor)
-- 
2.25.1

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

[PATCH v3 1/2] dt-bindings: display: Add idk-1110wr binding

[Lad Prabhakar]

From: Fabrizio Castro 

Add binding for the idk-1110wr LVDS panel from Advantech.

Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htm

Signed-off-by: Fabrizio Castro 
Reviewed-by: Rob Herring 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Lad Prabhakar 
---
 .../display/panel/advantech,idk-1110wr.yaml| 69 ++
 1 file changed, 69 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml 
b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
new file mode 100644
index 000..93878c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/advantech,idk-1110wr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech IDK-1110WR 10.1" WSVGA LVDS Display Panel
+
+maintainers:
+  - Lad Prabhakar 
+  - Thierry Reding 
+
+allOf:
+  - $ref: lvds.yaml#
+
+properties:
+  compatible:
+items:
+  - const: advantech,idk-1110wr
+  - {} # panel-lvds, but not listed here to avoid false select
+
+  data-mapping:
+const: jeida-24
+
+  width-mm:
+const: 223
+
+  height-mm:
+const: 125
+
+  panel-timing: true
+  port: true
+
+additionalProperties: false
+
+required:
+  - compatible
+
+examples:
+  - |+
+panel {
+  compatible = "advantech,idk-1110wr", "panel-lvds";
+
+  width-mm = <223>;
+  height-mm = <125>;
+
+  data-mapping = "jeida-24";
+
+  panel-timing {
+/* 1024x600 @60Hz */
+clock-frequency = <5120>;
+hactive = <1024>;
+vactive = <600>;
+hsync-len = <240>;
+hfront-porch = <40>;
+hback-porch = <40>;
+vsync-len = <10>;
+vfront-porch = <15>;
+vback-porch = <10>;
+  };
+
+  port {
+panel_in: endpoint {
+  remote-endpoint = <_encoder>;
+};
+  };
+};
+
+...
-- 
2.7.4

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

[PATCH 2/2] ARM: dts: sun4i: Add support for Topwise A721 tablet

[Pascal Roeleven]

The Topwise A721/LY-F1 tablet is a tablet sold around 2012 under
different brands. The mainboard mentions A721 clearly, so this tablet
is best known under this name.

Signed-off-by: Pascal Roeleven 
---
 arch/arm/boot/dts/Makefile   |   3 +-
 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts | 302 +++
 2 files changed, 304 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 78f144e33..6e6141e00 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1040,7 +1040,8 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-olinuxino-lime.dtb \
sun4i-a10-pcduino.dtb \
sun4i-a10-pcduino2.dtb \
-   sun4i-a10-pov-protab2-ips9.dtb
+   sun4i-a10-pov-protab2-ips9.dtb \
+   sun4i-a10-topwise-a721.dtb
 dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-auxtek-t003.dtb \
sun5i-a10s-auxtek-t004.dtb \
diff --git a/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts 
b/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
new file mode 100644
index 0..ff43c9c12
--- /dev/null
+++ b/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
@@ -0,0 +1,302 @@
+/*
+ * Copyright 2020 Pascal Roeleven 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun4i-a10.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   model = "Topwise A721";
+   compatible = "topwise,a721", "allwinner,sun4i-a10";
+
+   aliases {
+   serial0 = 
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 10 PWM_POLARITY_INVERTED>;
+   power-supply = <_vbat>;
+   enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+   brightness-levels = <0 30 40 50 60 70 80 90 100>;
+   default-brightness-level = <8>;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   panel: panel {
+   compatible = "starry,kr070pe2t";
+   backlight = <>;
+   power-supply = <_lcd_power>;
+
+   port {
+   panel_input: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+   };
+
+   reg_lcd_power: reg-lcd-power {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_power_pin>;
+   regulator-name = "reg-lcd-power";
+   gpio = < 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */
+   enable-active-high;
+   };
+
+   reg_vbat: reg-vbat {
+   compatible = "regulator-fixed";
+   regulator-name = "vbat";
+   regulator-min-microvolt = <370>;
+   regulator-max-microvolt = <370>;
+   };
+
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   cpu-supply = <_dcdc2>;
+};
+
+ {
+   status = "okay";

Re: [PATCH] drm/rockchip: rgb: don't count non-existent devices when determining subdrivers

[Miquel Raynal]

Hi Heiko,

Heiko Stuebner  wrote on Tue, 21 Jan 2020 23:48:28
+0100:

> From: Heiko Stuebner 
> 
> rockchip_drm_endpoint_is_subdriver() may also return error codes.
> For example if the target-node is in the disabled state, so no
> platform-device is getting created for it.
> 
> In that case current code would count that as external rgb device,
> which in turn would make probing the rockchip-drm device fail.
> 
> So only count the target as rgb device if the function actually
> returns 0.
> 
> Signed-off-by: Heiko Stuebner 
> ---
>  drivers/gpu/drm/rockchip/rockchip_rgb.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c 
> b/drivers/gpu/drm/rockchip/rockchip_rgb.c
> index ae730275a34f..79a7e60633e0 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_rgb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
> @@ -98,7 +98,8 @@ struct rockchip_rgb *rockchip_rgb_init(struct device *dev,
>   if (of_property_read_u32(endpoint, "reg", _id))
>   endpoint_id = 0;
>  
> - if (rockchip_drm_endpoint_is_subdriver(endpoint) > 0)
> + /* if subdriver (> 0) or error case (< 0), ignore entry */
> + if (rockchip_drm_endpoint_is_subdriver(endpoint) != 0)
>   continue;
>  
>   child_count++;

Reviewed-by: Miquel Raynal 

Thanks,
Miquèl
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 14/17] drm/i915: have *_debugfs_init() functions return void.

[Wambui Karuga]

Since commit 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails and should return void. Therefore, remove its use as the
return value of debugfs_init() functions and have the functions return
void.

v2: convert intel_display_debugfs_register() stub to return void too.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/display/intel_display_debugfs.c | 8 
 drivers/gpu/drm/i915/display/intel_display_debugfs.h | 4 ++--
 drivers/gpu/drm/i915/i915_debugfs.c  | 8 
 drivers/gpu/drm/i915/i915_debugfs.h  | 4 ++--
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 1e6eb7f2f72d..424f4e52f783 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1927,7 +1927,7 @@ static const struct {
{"i915_edp_psr_debug", _edp_psr_debug_fops},
 };
 
-int intel_display_debugfs_register(struct drm_i915_private *i915)
+void intel_display_debugfs_register(struct drm_i915_private *i915)
 {
struct drm_minor *minor = i915->drm.primary;
int i;
@@ -1940,9 +1940,9 @@ int intel_display_debugfs_register(struct 
drm_i915_private *i915)
intel_display_debugfs_files[i].fops);
}
 
-   return drm_debugfs_create_files(intel_display_debugfs_list,
-   ARRAY_SIZE(intel_display_debugfs_list),
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(intel_display_debugfs_list,
+ARRAY_SIZE(intel_display_debugfs_list),
+minor->debugfs_root, minor);
 }
 
 static int i915_panel_show(struct seq_file *m, void *data)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.h 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.h
index a3bea1ce04c2..c922c1745bfe 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.h
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.h
@@ -10,10 +10,10 @@ struct drm_connector;
 struct drm_i915_private;
 
 #ifdef CONFIG_DEBUG_FS
-int intel_display_debugfs_register(struct drm_i915_private *i915);
+void intel_display_debugfs_register(struct drm_i915_private *i915);
 int intel_connector_debugfs_add(struct drm_connector *connector);
 #else
-static inline int intel_display_debugfs_register(struct drm_i915_private 
*i915) { return 0; }
+static inline void intel_display_debugfs_register(struct drm_i915_private 
*i915) {}
 static inline int intel_connector_debugfs_add(struct drm_connector *connector) 
{ return 0; }
 #endif
 
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8f2525e4ce0f..de313199c714 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2392,7 +2392,7 @@ static const struct i915_debugfs_files {
{"i915_guc_log_relay", _guc_log_relay_fops},
 };
 
-int i915_debugfs_register(struct drm_i915_private *dev_priv)
+void i915_debugfs_register(struct drm_i915_private *dev_priv)
 {
struct drm_minor *minor = dev_priv->drm.primary;
int i;
@@ -2409,7 +2409,7 @@ int i915_debugfs_register(struct drm_i915_private 
*dev_priv)
i915_debugfs_files[i].fops);
}
 
-   return drm_debugfs_create_files(i915_debugfs_list,
-   I915_DEBUGFS_ENTRIES,
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(i915_debugfs_list,
+I915_DEBUGFS_ENTRIES,
+minor->debugfs_root, minor);
 }
diff --git a/drivers/gpu/drm/i915/i915_debugfs.h 
b/drivers/gpu/drm/i915/i915_debugfs.h
index 6da39c76ab5e..1de2736f1248 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.h
+++ b/drivers/gpu/drm/i915/i915_debugfs.h
@@ -12,10 +12,10 @@ struct drm_i915_private;
 struct seq_file;
 
 #ifdef CONFIG_DEBUG_FS
-int i915_debugfs_register(struct drm_i915_private *dev_priv);
+void i915_debugfs_register(struct drm_i915_private *dev_priv);
 void i915_debugfs_describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj);
 #else
-static inline int i915_debugfs_register(struct drm_i915_private *dev_priv) { 
return 0; }
+static inline void i915_debugfs_register(struct drm_i915_private *dev_priv) {}
 static inline void i915_debugfs_describe_obj(struct seq_file *m, struct 
drm_i915_gem_object *obj) {}
 #endif
 
-- 
2.25.1

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

[PATCH v3] video: fbdev: arcfb: add missed free_irq and fix the order of request_irq

[Chuhong Yuan]

The driver forgets to free irq in remove which is requested in
probe.
Add the missed call to fix it.
Also, the position of request_irq() in probe should be put before
register_framebuffer().

Signed-off-by: Chuhong Yuan 
---
Changes in v3:
  - Add missed variable par in remove.

 drivers/video/fbdev/arcfb.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
index 314ab82e01c0..9a720c14056c 100644
--- a/drivers/video/fbdev/arcfb.c
+++ b/drivers/video/fbdev/arcfb.c
@@ -544,10 +544,6 @@ static int arcfb_probe(struct platform_device *dev)
par->cslut[1] = 0x06;
info->flags = FBINFO_FLAG_DEFAULT;
spin_lock_init(>lock);
-   retval = register_framebuffer(info);
-   if (retval < 0)
-   goto err1;
-   platform_set_drvdata(dev, info);
if (irq) {
par->irq = irq;
if (request_irq(par->irq, _interrupt, IRQF_SHARED,
@@ -558,6 +554,10 @@ static int arcfb_probe(struct platform_device *dev)
goto err1;
}
}
+   retval = register_framebuffer(info);
+   if (retval < 0)
+   goto err1;
+   platform_set_drvdata(dev, info);
fb_info(info, "Arc frame buffer device, using %dK of video memory\n",
videomemorysize >> 10);
 
@@ -590,9 +590,12 @@ static int arcfb_probe(struct platform_device *dev)
 static int arcfb_remove(struct platform_device *dev)
 {
struct fb_info *info = platform_get_drvdata(dev);
+   struct arcfb_par *par = info->par;
 
if (info) {
unregister_framebuffer(info);
+   if (irq)
+   free_irq(par->irq, info);
vfree((void __force *)info->screen_base);
framebuffer_release(info);
}
-- 
2.25.1

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

[PATCH v2 07/17] drm/etnaviv: remove check for return value of drm_debugfs_create_files()

[Wambui Karuga]

Since commit 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails and only returns 0. Therefore, remove the unnecessary check of its
return value and error handling in etnaviv_debugfs_init() and have the
function return 0 directly.

v2: have etnaviv_debugfs_init() return 0 instead of void to ensure
individual compilation and avoid build breakage.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 6b43c1c94e8f..a65d30a48a9d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -233,19 +233,11 @@ static struct drm_info_list etnaviv_debugfs_list[] = {
 
 static int etnaviv_debugfs_init(struct drm_minor *minor)
 {
-   struct drm_device *dev = minor->dev;
-   int ret;
-
-   ret = drm_debugfs_create_files(etnaviv_debugfs_list,
-   ARRAY_SIZE(etnaviv_debugfs_list),
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(etnaviv_debugfs_list,
+ARRAY_SIZE(etnaviv_debugfs_list),
+minor->debugfs_root, minor);
 
-   if (ret) {
-   dev_err(dev->dev, "could not install etnaviv_debugfs_list\n");
-   return ret;
-   }
-
-   return ret;
+   return 0;
 }
 #endif
 
-- 
2.25.1

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

Re: [linux-sunxi] [PATCH 2/2] ARM: dts: sun4i: Add support for Topwise A721 tablet

[Ondřej Jirman]

Hello Pascal,

On Tue, Mar 10, 2020 at 11:27:24AM +0100, Pascal Roeleven wrote:
> The Topwise A721/LY-F1 tablet is a tablet sold around 2012 under
> different brands. The mainboard mentions A721 clearly, so this tablet
> is best known under this name.
> 
> Signed-off-by: Pascal Roeleven 
> ---
>  arch/arm/boot/dts/Makefile   |   3 +-
>  arch/arm/boot/dts/sun4i-a10-topwise-a721.dts | 302 +++
>  2 files changed, 304 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 78f144e33..6e6141e00 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1040,7 +1040,8 @@ dtb-$(CONFIG_MACH_SUN4I) += \
>   sun4i-a10-olinuxino-lime.dtb \
>   sun4i-a10-pcduino.dtb \
>   sun4i-a10-pcduino2.dtb \
> - sun4i-a10-pov-protab2-ips9.dtb
> + sun4i-a10-pov-protab2-ips9.dtb \
> + sun4i-a10-topwise-a721.dtb
>  dtb-$(CONFIG_MACH_SUN5I) += \
>   sun5i-a10s-auxtek-t003.dtb \
>   sun5i-a10s-auxtek-t004.dtb \
> diff --git a/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts 
> b/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
> new file mode 100644
> index 0..ff43c9c12
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
> @@ -0,0 +1,302 @@
> +/*
> + * Copyright 2020 Pascal Roeleven 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */

You should use SPDX license identifier instead of boilerplate license
text.

> +/dts-v1/;
> +#include "sun4i-a10.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Topwise A721";
> + compatible = "topwise,a721", "allwinner,sun4i-a10";

topwise is not in vendor-prefixes.yaml

> + aliases {
> + serial0 = 
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 10 PWM_POLARITY_INVERTED>;
> + power-supply = <_vbat>;
> + enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
> + brightness-levels = <0 30 40 50 60 70 80 90 100>;
> + default-brightness-level = <8>;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + panel: panel {
> + compatible = "starry,kr070pe2t";
> + backlight = <>;
> + power-supply = <_lcd_power>;
> +
> + port {
> + panel_input: endpoint {
> + remote-endpoint = <_out_panel>;
> + };
> + };
> + };
> +
> + reg_lcd_power: reg-lcd-power {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <_power_pin>;
> + regulator-name = "reg-lcd-power";
> + gpio = < 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */
> + enable-active-high;
> + 

[PATCH v2 00/17] drm: subsytem-wide debugfs functions refactor

[Wambui Karuga]

This series includes work on various debugfs functions both in drm/core
and across various drivers in the subsystem.
Since commit 987d65d01356 (drm: debugfs: make drm_debugfs_create_files()
never fail), drm_debugfs_create_files() does not fail and only returns
zero. This series therefore removes the left over error handling and
checks for its return value across drm drivers.

As a result of these changes, most drm_debugfs functions are converted
to return void in this series. This also enables the
drm_driver, debugfs_init() hook to be changed to return void. 

v2: individual driver patches have been converted to have debugfs
functions return 0 instead of void to prevent breaking individual driver
builds.
The last patch then converts the .debugfs_hook() and its users across
all drivers to return void.

Wambui Karuga (17):
  drm/tegra: remove checks for debugfs functions return value
  drm/tilcdc: remove check for return value of debugfs functions.
  drm/v3d: make v3d_debugfs_init() return 0
  drm/vc4: remove check of return value of drm_debugfs functions
  drm/arc: make arcgpu_debugfs_init() return 0.
  drm/arm: make hdlcd_debugfs_init() return 0
  drm/etnaviv: remove check for return value of
drm_debugfs_create_files()
  drm/msm: remove checks for return value of drm_debugfs_create_files()
  drm/sti: remove use of drm_debugfs functions as return values
  drm/vram-helper: make drm_vram_mm_debugfs_init() return 0
  drm/nouveau: make nouveau_drm_debugfs_init() return 0
  drm/pl111: make pl111_debugfs_init return 0
  drm/omap: remove checks for return value of drm_debugfs functions
  drm/i915: have *_debugfs_init() functions return void.
  drm: make various debugfs_init() functions return 0
  drm/debugfs: remove checks for return value of drm_debugfs functions.
  drm: convert .debugfs_init() hook to return void.

 drivers/gpu/drm/arc/arcpgu_drv.c  |  7 +--
 drivers/gpu/drm/arm/hdlcd_drv.c   |  7 +--
 drivers/gpu/drm/arm/malidp_drv.c  |  3 +-
 drivers/gpu/drm/drm_atomic.c  |  8 ++--
 drivers/gpu/drm/drm_client.c  |  8 ++--
 drivers/gpu/drm/drm_crtc_internal.h   |  2 +-
 drivers/gpu/drm/drm_debugfs.c | 45 +--
 drivers/gpu/drm/drm_framebuffer.c |  8 ++--
 drivers/gpu/drm/drm_gem_vram_helper.c | 14 ++
 drivers/gpu/drm/drm_internal.h|  2 +-
 drivers/gpu/drm/drm_mipi_dbi.c|  6 +--
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 18 ++--
 .../drm/i915/display/intel_display_debugfs.c  |  8 ++--
 .../drm/i915/display/intel_display_debugfs.h  |  4 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  8 ++--
 drivers/gpu/drm/i915/i915_debugfs.h   |  4 +-
 drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 18 +++-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h |  2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  | 14 ++
 drivers/gpu/drm/msm/msm_debugfs.c | 23 +++---
 drivers/gpu/drm/msm/msm_debugfs.h |  2 +-
 drivers/gpu/drm/msm/msm_gpu.h |  2 +-
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 26 +--
 drivers/gpu/drm/nouveau/nouveau_debugfs.h |  8 ++--
 drivers/gpu/drm/omapdrm/omap_debugfs.c| 29 +++-
 drivers/gpu/drm/omapdrm/omap_drv.h|  2 +-
 drivers/gpu/drm/pl111/pl111_debugfs.c |  8 ++--
 drivers/gpu/drm/pl111/pl111_drm.h |  2 +-
 drivers/gpu/drm/qxl/qxl_debugfs.c | 21 +++--
 drivers/gpu/drm/qxl/qxl_drv.h | 13 +++---
 drivers/gpu/drm/qxl/qxl_ttm.c |  6 +--
 drivers/gpu/drm/sti/sti_compositor.c  |  6 +--
 drivers/gpu/drm/sti/sti_compositor.h  |  4 +-
 drivers/gpu/drm/sti/sti_crtc.c|  2 +-
 drivers/gpu/drm/sti/sti_cursor.c  | 14 +++---
 drivers/gpu/drm/sti/sti_drv.c | 16 ++-
 drivers/gpu/drm/sti/sti_dvo.c | 13 +++---
 drivers/gpu/drm/sti/sti_gdp.c |  7 +--
 drivers/gpu/drm/sti/sti_hda.c | 13 +++---
 drivers/gpu/drm/sti/sti_hdmi.c| 13 +++---
 drivers/gpu/drm/sti/sti_hqvdp.c   | 12 ++---
 drivers/gpu/drm/sti/sti_mixer.c   | 10 ++---
 drivers/gpu/drm/sti/sti_mixer.h   |  2 +-
 drivers/gpu/drm/sti/sti_tvout.c   | 13 +++---
 drivers/gpu/drm/sti/sti_vid.c |  8 ++--
 drivers/gpu/drm/sti/sti_vid.h |  2 +-
 drivers/gpu/drm/tegra/dc.c| 11 +
 drivers/gpu/drm/tegra/drm.c   |  8 ++--
 drivers/gpu/drm/tegra/dsi.c   | 11 +
 drivers/gpu/drm/tegra/hdmi.c  | 11 +
 drivers/gpu/drm/tegra/sor.c   | 11 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.c   | 17 ++-
 drivers/gpu/drm/v3d/v3d_debugfs.c |  8 ++--
 drivers/gpu/drm/v3d/v3d_drv.h |  2 +-
 drivers/gpu/drm/vc4/vc4_debugfs.c 

[PATCH v2 09/17] drm/sti: remove use of drm_debugfs functions as return values

[Wambui Karuga]

Since commit 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails, and should return void. This change therefore removes it uses as
a return value in various functions across drm/sti.

With these changes, the affected functions have been changed to use a void
return value.

v2: convert sti_mixer_debugfs_init() and sti_compositor_debugfs_init()
to return void too. Also have sti_drm_dbg_init() to return 0 to avoid
build issues.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/sti/sti_compositor.c |  6 ++
 drivers/gpu/drm/sti/sti_compositor.h |  4 ++--
 drivers/gpu/drm/sti/sti_crtc.c   |  2 +-
 drivers/gpu/drm/sti/sti_cursor.c | 14 --
 drivers/gpu/drm/sti/sti_drv.c| 13 +++--
 drivers/gpu/drm/sti/sti_dvo.c| 13 +
 drivers/gpu/drm/sti/sti_gdp.c|  7 ---
 drivers/gpu/drm/sti/sti_hda.c| 13 +
 drivers/gpu/drm/sti/sti_hdmi.c   | 13 +
 drivers/gpu/drm/sti/sti_hqvdp.c  | 12 +++-
 drivers/gpu/drm/sti/sti_mixer.c  | 10 +-
 drivers/gpu/drm/sti/sti_mixer.h  |  2 +-
 drivers/gpu/drm/sti/sti_tvout.c  | 13 +
 drivers/gpu/drm/sti/sti_vid.c|  8 
 drivers/gpu/drm/sti/sti_vid.h|  2 +-
 15 files changed, 58 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
index c7652584255d..319962a2c17b 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -42,8 +42,8 @@ static const struct sti_compositor_data 
stih407_compositor_data = {
},
 };
 
-int sti_compositor_debugfs_init(struct sti_compositor *compo,
-   struct drm_minor *minor)
+void sti_compositor_debugfs_init(struct sti_compositor *compo,
+struct drm_minor *minor)
 {
unsigned int i;
 
@@ -54,8 +54,6 @@ int sti_compositor_debugfs_init(struct sti_compositor *compo,
for (i = 0; i < STI_MAX_MIXER; i++)
if (compo->mixer[i])
sti_mixer_debugfs_init(compo->mixer[i], minor);
-
-   return 0;
 }
 
 static int sti_compositor_bind(struct device *dev,
diff --git a/drivers/gpu/drm/sti/sti_compositor.h 
b/drivers/gpu/drm/sti/sti_compositor.h
index ac4bb3834810..25bb01bdd013 100644
--- a/drivers/gpu/drm/sti/sti_compositor.h
+++ b/drivers/gpu/drm/sti/sti_compositor.h
@@ -79,7 +79,7 @@ struct sti_compositor {
struct notifier_block vtg_vblank_nb[STI_MAX_MIXER];
 };
 
-int sti_compositor_debugfs_init(struct sti_compositor *compo,
-   struct drm_minor *minor);
+void sti_compositor_debugfs_init(struct sti_compositor *compo,
+struct drm_minor *minor);
 
 #endif
diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index 49e6cb8f5836..6f37c104c46f 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -319,7 +319,7 @@ static int sti_crtc_late_register(struct drm_crtc *crtc)
struct sti_compositor *compo = dev_get_drvdata(mixer->dev);
 
if (drm_crtc_index(crtc) == 0)
-   return sti_compositor_debugfs_init(compo, crtc->dev->primary);
+   sti_compositor_debugfs_init(compo, crtc->dev->primary);
 
return 0;
 }
diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index ea64c1dcaf63..a98057431023 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -131,17 +131,17 @@ static struct drm_info_list cursor_debugfs_files[] = {
{ "cursor", cursor_dbg_show, 0, NULL },
 };
 
-static int cursor_debugfs_init(struct sti_cursor *cursor,
-  struct drm_minor *minor)
+static void cursor_debugfs_init(struct sti_cursor *cursor,
+   struct drm_minor *minor)
 {
unsigned int i;
 
for (i = 0; i < ARRAY_SIZE(cursor_debugfs_files); i++)
cursor_debugfs_files[i].data = cursor;
 
-   return drm_debugfs_create_files(cursor_debugfs_files,
-   ARRAY_SIZE(cursor_debugfs_files),
-   minor->debugfs_root, minor);
+   drm_debugfs_create_files(cursor_debugfs_files,
+ARRAY_SIZE(cursor_debugfs_files),
+minor->debugfs_root, minor);
 }
 
 static void sti_cursor_argb_to_clut8(struct sti_cursor *cursor, u32 *src)
@@ -342,7 +342,9 @@ static int sti_cursor_late_register(struct drm_plane 
*drm_plane)
struct sti_plane *plane = to_sti_plane(drm_plane);
struct sti_cursor *cursor = to_sti_cursor(plane);
 
-   return cursor_debugfs_init(cursor, drm_plane->dev->primary);
+   cursor_debugfs_init(cursor, 

[PATCH v2 05/17] drm/arc: make arcgpu_debugfs_init() return 0.

[Wambui Karuga]

Since commit 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails and should return void. Therefore, remove its use as the
return value of arcpgu_debugfs_init() and have the latter function return
0 directly.

v2: convert the function to return 0 instead of void to avoid breaking
the build and ensure that this individual patch compiles properly.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index d6a6692db0ac..660b25f9588e 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -139,8 +139,10 @@ static struct drm_info_list arcpgu_debugfs_list[] = {
 
 static int arcpgu_debugfs_init(struct drm_minor *minor)
 {
-   return drm_debugfs_create_files(arcpgu_debugfs_list,
-   ARRAY_SIZE(arcpgu_debugfs_list), minor->debugfs_root, minor);
+   drm_debugfs_create_files(arcpgu_debugfs_list,
+ARRAY_SIZE(arcpgu_debugfs_list),
+minor->debugfs_root, minor);
+   return 0;
 }
 #endif
 
-- 
2.25.1

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

[PATCH 1/2] drm/panel: Add Starry KR070PE2T

[Pascal Roeleven]

The KR070PE2T is a 7" panel with a resolution of 800x480.

KR070PE2T is the marking present on the ribbon cable. As this panel is
probably available under different brands, this marking will catch
most devices.

Signed-off-by: Pascal Roeleven 
---
 .../display/panel/starry,kr070pe2t.txt|  7 +
 drivers/gpu/drm/panel/panel-simple.c  | 26 +++
 2 files changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt 
b/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
new file mode 100644
index 0..699ad5eb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
@@ -0,0 +1,7 @@
+Starry 7" (800x480 pixels) LCD panel
+
+Required properties:
+- compatible: should be "starry,kr070pe2t"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index e14c14ac6..027a2612b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2842,6 +2842,29 @@ static const struct panel_desc shelly_sca07010_bfn_lnn = 
{
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
 };
 
+static const struct drm_display_mode starry_kr070pe2t_mode = {
+   .clock = 33000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 209,
+   .hsync_end = 800 + 209 + 1,
+   .htotal = 800 + 209 + 1 + 45,
+   .vdisplay = 480,
+   .vsync_start = 480 + 22,
+   .vsync_end = 480 + 22 + 1,
+   .vtotal = 480 + 22 + 1 + 22,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc starry_kr070pe2t = {
+   .modes = _kr070pe2t_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 152,
+   .height = 86,
+   },
+};
+
 static const struct drm_display_mode starry_kr122ea0sra_mode = {
.clock = 147000,
.hdisplay = 1920,
@@ -3474,6 +3497,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "shelly,sca07010-bfn-lnn",
.data = _sca07010_bfn_lnn,
+   }, {
+   .compatible = "starry,kr070pe2t",
+   .data = _kr070pe2t,
}, {
.compatible = "starry,kr122ea0sra",
.data = _kr122ea0sra,
-- 
2.20.1

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

Re: [PATCH v11 3/5] soc: mediatek: Move mt8173 MMSYS to platform driver

[Matthias Brugger]

On 09/03/2020 23:50, Stephen Boyd wrote:
> Quoting Enric Balletbo Serra (2020-03-06 14:09:50)
>> Missatge de Stephen Boyd  del dia dv., 6 de mar
>> 2020 a les 22:37:
>>>
>>> Quoting Enric Balletbo i Serra (2020-03-06 08:30:16)
 On 5/3/20 22:01, Stephen Boyd wrote:
> Quoting Enric Balletbo i Serra (2020-03-02 03:01:26)
>> diff --git a/drivers/soc/mediatek/mtk-mmsys.c 
>> b/drivers/soc/mediatek/mtk-mmsys.c
>> new file mode 100644
>> index ..473cdf732fb5
>> --- /dev/null
>> +++ b/drivers/soc/mediatek/mtk-mmsys.c
>> @@ -0,0 +1,154 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) 2014 MediaTek Inc.
>> + * Author: James Liao 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "../../clk/mediatek/clk-gate.h"
>> +#include "../../clk/mediatek/clk-mtk.h"
>
> Why not use include/linux/clk/?
>

 I can move these files to include, this will impact a lot more of drivers 
 but,
 yes, I think is the right way.

> But I also don't understand why the clk driver is moved outside of
> drivers/clk/ into drivers/soc/. Commit text saying that it has shared
> registers doesn't mean it can't still keep the clk driver part in the
> drivers/clk/ area.
>

 Actually moving this to the soc directory has been requested by CK 
 (mediatek) as
 a change in v8. You can see the discussion in [1]

>>>
>>> I can reply there in that thread if necessary, but we shouldn't need to
>>> force simple-mfd into DT bindings to support this. Match the compatible
>>> string in drivers/soc/ and register devices in software for the
>>> different pieces of this overall hardware block. If necessary, pass down
>>> the ioremapped addresss down through device data to each logical driver
>>> in the respective subsystem.
>>>
>>> So yes, it looks like an MFD, but that doesn't mean we have to change
>>> the DT binding or put it in drivers/mfd to support that. And we don't
>>> have to fix any problems with allowing two drivers to probe the same
>>> compatible string.
>>>
>>
>> That thread maybe has too much information and things evolved since
>> then. Note that the final solution is not an MFD neither we change the
>> bindings. I pointed to that thread just because CK (CK please correct
>> me if I'm wrong) thought that the driver is not a pure clock driver
>> and he preferred to move to drivers/soc/mediatek (in that thread, he
>> exposes his opinion on that).  Sorry to introduce more confusion.
>>
>> You seem to be fine with the approach (just minor changes), so it
>> looks to me that the only problem is if this should be in drivers/clk
>> or drivers/soc. Honestly, this is not something I can't decide and
>> I'll let you (the soc and clk maintainers) decide. I don't really have
>> a strong opinion here. I don't mind move again to drivers/clk if that
>> is what we want but let's come to an agreement.
>>
> 
> It's already in drivers/clk, so leave the clk part there and register
> the clk device and any other devices by matching the compatible in
> drivers/soc. That is my preferred solution. Can that be done?
> 

I think we can once again create a platform device in drivers/soc which matches
the drivers/clk and then do the routing in drivers/soc. Enric any thoughts?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 11/17] drm/nouveau: make nouveau_drm_debugfs_init() return 0

[Wambui Karuga]

Since 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail), there is no need to ever check
for the the return value of debugfs_create_file() and
drm_debugfs_create_files(). Therefore, remove unnecessary checks and
error handling in nouveau_drm_debugfs_init() and have the function
return 0 directly.

v2: have nouveau_drm_debugfs_init() return 0 instead of void so as not
to introduce any build warnings to enable individual patch compilation.

References: 
https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c 
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 7dfbbbc1beea..15a3d40edf02 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -222,22 +222,18 @@ nouveau_drm_debugfs_init(struct drm_minor *minor)
 {
struct nouveau_drm *drm = nouveau_drm(minor->dev);
struct dentry *dentry;
-   int i, ret;
+   int i;
 
for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++) {
-   dentry = debugfs_create_file(nouveau_debugfs_files[i].name,
-S_IRUGO | S_IWUSR,
-minor->debugfs_root, minor->dev,
-nouveau_debugfs_files[i].fops);
-   if (!dentry)
-   return -ENOMEM;
+   debugfs_create_file(nouveau_debugfs_files[i].name,
+   S_IRUGO | S_IWUSR,
+   minor->debugfs_root, minor->dev,
+   nouveau_debugfs_files[i].fops);
}
 
-   ret = drm_debugfs_create_files(nouveau_debugfs_list,
-  NOUVEAU_DEBUGFS_ENTRIES,
-  minor->debugfs_root, minor);
-   if (ret)
-   return ret;
+   drm_debugfs_create_files(nouveau_debugfs_list,
+NOUVEAU_DEBUGFS_ENTRIES,
+minor->debugfs_root, minor);
 
/* Set the size of the vbios since we know it, and it's confusing to
 * userspace if it wants to seek() but the file has a length of 0
-- 
2.25.1

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

[PATCH v3 2/2] arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display

[Lad Prabhakar]

From: Fabrizio Castro 

The HiHope RZ/G2M is advertised as compatible with panel idk-1110wr
from Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
work the HiHope RZ/G2M, is the most convenient way to support the
HiHope RZ/G2M when it's connected to the idk-1110wr.

Signed-off-by: Fabrizio Castro 
Acked-by: Laurent Pinchart 
Signed-off-by: Lad Prabhakar 
---
 arch/arm64/boot/dts/renesas/Makefile   |  1 +
 .../r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts| 86 ++
 2 files changed, 87 insertions(+)
 create mode 100644 
arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts

diff --git a/arch/arm64/boot/dts/renesas/Makefile 
b/arch/arm64/boot/dts/renesas/Makefile
index 2153842..82dd245 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m.dtb
 dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex.dtb
+dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex-idk-1110wr.dtb
 dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n.dtb
 dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n-ex.dtb
 dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb \
diff --git 
a/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts 
b/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
new file mode 100644
index 000..6033cae
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the HiHope RZ/G2M sub board connected to an
+ * Advantech IDK-1110WR 10.1" LVDS panel
+ *
+ * Copyright (C) 2020 Renesas Electronics Corp.
+ */
+
+#include "r8a774a1-hihope-rzg2m-ex.dts"
+
+/ {
+   backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 5>;
+
+   brightness-levels = <0 2 8 16 32 64 128 255>;
+   default-brightness-level = <6>;
+   };
+
+   panel-lvds {
+   compatible = "advantech,idk-1110wr", "panel-lvds";
+
+   width-mm = <223>;
+   height-mm = <125>;
+
+   data-mapping = "jeida-24";
+
+   panel-timing {
+   /* 1024x600 @60Hz */
+   clock-frequency = <5120>;
+   hactive = <1024>;
+   vactive = <600>;
+   hsync-len = <240>;
+   hfront-porch = <40>;
+   hback-porch = <40>;
+   vfront-porch = <15>;
+   vback-porch = <10>;
+   vsync-len = <10>;
+   };
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
+
+ {
+   /*
+* When GP1_20 is LOW LVDS0 is connected to the LVDS connector
+* When GP1_20 is HIGH LVDS0 is connected to the LT8918L
+*/
+   lvds-connector-en-gpio {
+   gpio-hog;
+   gpios = <20 GPIO_ACTIVE_HIGH>;
+   output-low;
+   line-name = "lvds-connector-en-gpio";
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
+   port@1 {
+   lvds0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+};
+
+ {
+   pwm0_pins: pwm0 {
+   groups = "pwm0";
+   function = "pwm0";
+   };
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+};
-- 
2.7.4

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

[PATCH v6 2/2] drm/edid: Add function to parse EDID descriptors for monitor range

[Manasi Navare]

Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
amdgpu_dm_update_freesync_caps() to make it generic and be used
across all DRM drivers

v6:
* Call it monitor_range (Ville)
v5:
* Use the renamed flags
v4:
* Use is_display_descriptor() (Ville)
* Name the monitor range flags (Ville)
v3:
* Remove the edid parsing restriction for just DP (Nicholas)
* Use drm_for_each_detailed_block (Ville)
* Make the drm_get_adaptive_sync_range function static (Harry, Jani)
v2:
* Change vmin and vmax to use u8 (Ville)
* Dont store pixel clock since that is just a max dotclock
and not related to VRR mode (Manasi)

Cc: Ville Syrjälä 
Cc: Harry Wentland 
Cc: Clinton A Taylor 
Cc: Kazlauskas Nicholas 
Signed-off-by: Manasi Navare 
Reviewed-by: Nicholas Kazlauskas 
---
 drivers/gpu/drm/drm_edid.c  | 44 +
 include/drm/drm_connector.h | 22 +++
 2 files changed, 66 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ad41764a4ebe..b269cd7f7679 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
}
 }
 
+static
+void get_monitor_range(struct detailed_timing *timing,
+  void *info_monitor_range)
+{
+   struct drm_monitor_range_info *monitor_range = info_monitor_range;
+   const struct detailed_non_pixel *data = >data.other_data;
+   const struct detailed_data_monitor_range *range = >data.range;
+
+   if (!is_display_descriptor((const u8 *)timing, 
EDID_DETAIL_MONITOR_RANGE))
+   return;
+
+   /*
+* Check for flag range limits only. If flag == 1 then
+* no additional timing information provided.
+* Default GTF, GTF Secondary curve and CVT are not
+* supported
+*/
+   if (range->flags != DRM_EDID_RANGE_LIMITS_ONLY_FLAG)
+   return;
+
+   monitor_range->min_vfreq = range->min_vfreq;
+   monitor_range->max_vfreq = range->max_vfreq;
+}
+
+static
+void drm_get_monitor_range(struct drm_connector *connector,
+  const struct edid *edid)
+{
+   struct drm_display_info *info = >display_info;
+
+   if (!version_greater(edid, 1, 1))
+   return;
+
+   drm_for_each_detailed_block((u8 *)edid, get_monitor_range,
+   >monitor_range);
+
+   DRM_DEBUG_KMS("Supported Monitor Refresh rate range is %d Hz - %d Hz\n",
+ info->monitor_range.min_vfreq,
+ info->monitor_range.max_vfreq);
+}
+
 /* A connector has no EDID information, so we've got no EDID to compute quirks 
from. Reset
  * all of the values which would have been set from EDID
  */
@@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector *connector)
memset(>hdmi, 0, sizeof(info->hdmi));
 
info->non_desktop = 0;
+   memset(>monitor_range, 0, sizeof(info->monitor_range));
 }
 
 u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
*edid)
@@ -4975,6 +5017,8 @@ u32 drm_add_display_info(struct drm_connector *connector, 
const struct edid *edi
 
info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
 
+   drm_get_monitor_range(connector, edid);
+
DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
 
if (edid->revision < 3)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 0df7a95ca5d9..19ae6bb5c85b 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -254,6 +254,23 @@ enum drm_panel_orientation {
DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
 };
 
+/**
+ * struct drm_monitor_range_info - Panel's Monitor range in EDID for
+ * _display_info
+ *
+ * This struct is used to store a frequency range supported by panel
+ * as parsed from EDID's detailed monitor range descriptor block.
+ *
+ * @min_vfreq: This is the min supported refresh rate in Hz from
+ * EDID's detailed monitor range.
+ * @max_vfreq: This is the max supported refresh rate in Hz from
+ * EDID's detailed monitor range
+ */
+struct drm_monitor_range_info {
+   u8 min_vfreq;
+   u8 max_vfreq;
+};
+
 /*
  * This is a consolidated colorimetry list supported by HDMI and
  * DP protocol standard. The respective connectors will register
@@ -473,6 +490,11 @@ struct drm_display_info {
 * @non_desktop: Non desktop display (HMD).
 */
bool non_desktop;
+
+   /**
+* @monitor_range: Frequency range supported by monitor range descriptor
+*/
+   struct drm_monitor_range_info monitor_range;
 };
 
 int drm_display_info_set_bus_formats(struct drm_display_info *info,
-- 
2.19.1

[PATCH v6 1/2] drm/edid: Name the detailed monitor range flags

[Manasi Navare]

This patch adds defines for the detailed monitor
range flags as per the EDID specification.

v2:
* Rename the flags with DRM_EDID_ (Jani N)

Suggested-by: Ville Syrjälä 
Cc: Ville Syrjälä 
Cc: Harry Wentland 
Cc: Clinton A Taylor 
Cc: Kazlauskas Nicholas 
Cc: Jani Nikula 
Signed-off-by: Manasi Navare 
Reviewed-by: Nicholas Kazlauskas 
---
 include/drm/drm_edid.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index f0b03d401c27..34b15e3d070c 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -91,6 +91,11 @@ struct detailed_data_string {
u8 str[13];
 } __attribute__((packed));
 
+#define DRM_EDID_DEFAULT_GTF_SUPPORT_FLAG   0x00
+#define DRM_EDID_RANGE_LIMITS_ONLY_FLAG 0x01
+#define DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG 0x02
+#define DRM_EDID_CVT_SUPPORT_FLAG   0x04
+
 struct detailed_data_monitor_range {
u8 min_vfreq;
u8 max_vfreq;
-- 
2.19.1

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

Re: [RFC PATCH 0/8] *** Per context fencing ***

[Gurchetan Singh]

On Tue, Mar 10, 2020 at 12:43 AM Gerd Hoffmann  wrote:

> On Mon, Mar 09, 2020 at 06:08:10PM -0700, Gurchetan Singh wrote:
> > We don't want fences from different 3D contexts/processes (GL, VK) to
> > be on the same timeline. Sending this out as a RFC to solicit feedback
> > on the general approach.
>
> NACK.
>
> virtio fences are global, period.  You can't simply change fence
> semantics like this.  At least not without a virtio protocol update
> because guest and host need to be on the same page here.


I should've been more clear -- this is an internal cleanup/preparation and
the per-context changes are invisible to host userspace.

Just look at
> virgl_renderer_callbacks->write_fences() and how it doesn't consider
> contexts at all.
>
> So one way out would be to add a virtio feature flag for this, so guest
> & host can negotiate whenever fences are global or per-context.
>

Yeah, we'll need something like VIRTIO_GPU_FLAG_FENCE_V2 eventually, which
means fences virgl_write_fence can not assume fence_id is the global
sequence number.  It's a bit tricky, and we have to consider a few cases:

1) Current kernel/current host userspace.  Everything works.

2) Newer kernel (with this series) on current host userspace.  For
that, fence_id needs to be a monotonically increasing value, which it
remains to be.  I ran the standard test apps (Unigine Valley, dEQP, etc.)
with this change and things seem fine.

3) Current kernel on newer host userspace.  New host won't see
VIRTIO_GPU_FLAG_FENCE_V2, everything should work as usual.

4) Newer kernel on new host host userspace.  virgl_write_fence signals
fences only in a specific context (or possibly only one fence at a time).
The guest kernel processing based on {fence_id, fence_context} will make a
difference in a multi-process environment.

If I have things right (and again, it's a bit tricky), so the virtio
protocol update will be required at (4).  It would be nice to get in
refactorings to avoid mega-changes if we agree on the general approach..

Side note:

Fences do have an associated context ID in virglrenderer [1], though we
don't pass down the correct ctx ID just yet [2].

[1]
https://gitlab.freedesktop.org/virgl/virglrenderer/-/blob/master/src/virglrenderer.h#L204
[2] https://github.com/qemu/qemu/blob/master/hw/display/virtio-gpu-3d.c#L490

Another approach would be to go multiqueue, with each virtqueue being
> roughly the same as a rendering pipeline on physical hardware, then have
> per-virtqueue fences.
>

Multi-queue sounds very interesting indeed, especially with VK
multi-threaded command submission.  That to me is V3 rather than V2.. let's
start easy!

When going multiqueue we might also rethink the cursor queue approach.
> I think it makes sense to simply allow sending cursor commands to any
> queue then.  A separate cursor queue continues to be an option for the
> guest then, but I'm not sure how useful that actually is in practice
> given that cursor image updates are regular resource updates and have to
> go through the control queue, so virtio_gpu_cursor_plane_update() has to
> wait for the resource update finish before it can queue the cursor
> command.  I suspect the idea to fast-track cursor updates with a
> separate queue doesn't work that well in practice because of that.
>
> cheers,
>   Gerd
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu, amdkfd, scheduler drm-next-5.7

[Alex Deucher]

Hi Dave, Daniel,

Updates for 5.7.

The following changes since commit 60347451ddb0646c1a9cc5b9581e5bcf648ad1aa:

  Merge tag 'drm-misc-next-2020-02-27' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2020-02-28 16:22:41 
+1000)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.7-2020-03-10

for you to fetch changes up to 5d11e37c021f925496a3a3c019cadf69435f65ed:

  drm/amdgpu/runpm: disable runpm on Vega10 (2020-03-10 15:55:18 -0400)


amd-drm-next-5.7-2020-03-10:

amdgpu:
- SR-IOV fixes
- Fix up fallout from drm load/unload callback removal
- Navi, renoir power management watermark fixes
- Refactor smu parameter handling
- Display FEC fixes
- Display DCC fixes
- HDCP fixes
- Add support for USB-C PD firmware updates
- Pollock detection fix
- Rework compute ring priority handling
- RAS fixes
- Misc cleanups

amdkfd:
- Consolidate more gfx config details in amdgpu
- Consolidate bo alloc flags
- Improve code comments
- SDMA MQD fixes
- Misc cleanups

gpu scheduler:
- Add suport for modifying the sched list

uapi:
- Clarify comments about GEM_CREATE flags that are not used by userspace.
  The kernel driver has always prevented userspace from using these.
  They are only used internally in the kernel driver.


Aly-Tawfik (2):
  drm/amdgpu/display: fix pci revision id fetching
  drm/amdgpu/display: Fix Pollock Variant Detection

Andrey Grodzovsky (6):
  drm/amdgpu: Add USBC PD FW load interface to PSP.
  drm/amdgpu: Add USBC PD FW load to PSP 11
  drm/amdgpu: Add support for USBC PD FW download
  drm/amdgpu: Wrap clflush_cache_range with x86 ifdef
  drm/amdgpu: Fix GPU reset error.
  drm/amdgpu: Enter low power state if CRTC active.

Aric Cyr (2):
  drm/amd/display: 3.2.75
  drm/amd/display: 3.2.76

Bhawanpreet Lakha (1):
  drm/amd/display: Clear link settings on MST disable connector

Braden Bakker (1):
  drm/amd/display: Add registry for mem pwr control

Chengming Gui (2):
  drm/amdgpu: add lock option for smu_set_soft_freq_range()
  drm/amdgpu: Add debugfs interface to set arbitrary sclk for navi14 (v2)

Colin Ian King (2):
  drm/amdkfd: fix indentation issue
  drm/amd/display: fix indentation issue on a hunk of code

Dan Carpenter (1):
  drm/amd/display: Fix dmub_psr_destroy()

Emily Deng (1):
  drm/amdgpu/sriov: Use kiq to copy the gpu clock

Eric Bernstein (1):
  drm/amd/display: Fix default logger mask definition

Eric Huang (1):
  drm/amdkfd: change SDMA MQD memory type

Feifei Xu (1):
  drm/amdgpu/runpm: disable runpm on Vega10

Felix Kuehling (1):
  drm/amdkfd: Signal eviction fence on process destruction (v2)

George Shen (1):
  drm/amd/display: Workaround to do HDCP authentication twice on certain 
displays

Guchun Chen (1):
  drm/amdgpu: toggle DF-Cstate when accessing UMC ras error related 
registers

Hawking Zhang (10):
  drm/amdgpu: add reset_ras_error_count function for SDMA
  drm/amdgpu: add reset_ras_error_count function for MMHUB
  drm/amdgpu: add reset_ras_error_count function for GFX
  drm/amdgpu: add reset_ras_error_count function for HDP
  drm/amdgpu: correct ROM_INDEX/DATA offset for VEGA20
  drm/amdgpu: add xgmi ip headers
  drm/amdgpu: add wafl2 ip headers
  drm/amdgpu: add helper funcs to detect PCS error
  drm/amdgpu: enable PCS error report on VG20
  drm/amdgpu: enable PCS error report on arcturus

Hersen Wu (2):
  drm/amdgpu/powerplay: nv1x, renior copy dcn clock settings of watermark 
to smu during boot up
  drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu 
resume from s3 (v2)

Isabel Zhang (2):
  drm/amd/display: Move mod_hdcp_displays to mod_hdcp struct
  drm/amd/display: Add stay count and bstatus to HDCP log

Jacob He (2):
  drm/amdgpu: Initialize SPM_VMID with 0xf (v2)
  drm/amdgpu: Update SPM_VMID with the job's vmid when application reserves 
the vmid

John Clements (2):
  drm/amdgpu: increase atombios cmd timeout
  drm/amdgpu: update page retirement sequence

Joseph Gravenor (1):
  drm/amd/display: add worst case dcc meta pitch to fake plane

Josip Pavic (1):
  drm/amd/display: fix dcc swath size calculations on dcn1

Martin Leung (3):
  drm/amd/display: Link training TPS1 workaround add back in dpcd
  drm/amd/display: update soc bb for nv14
  drm/amd/display: writing stereo polarity register if swapped

Matt Coffin (3):
  drm/amdgpu/powerplay: Refactor SMU message handling for safety
  drm/amdgpu/powerplay: Remove deprecated smc_read_arg
  drm/amdgpu/smu: Add message sending lock

Melissa Wen (3):
  drm/amd/display: dc_link: code clean up on enable_link_dp function
  drm/amd/display: dc_link: code clean up on detect_dp function
  drm/amd/display: 

Re: [DPU PATCH v4 1/5] dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon

[Rob Herring]

On Wed, Mar 04, 2020 at 04:10:24PM -0800, Vara Reddy wrote:
> From: Chandan Uddaraju 
> 
> Add bindings for Snapdragon DisplayPort and
> display-port PLL driver.
> 
> Changes in V2:
> Provide details about sel-gpio
> 
> Changes in V4:
> Provide details about max dp lanes
> Change the commit text
> 
> Signed-off-by: Chandan Uddaraju 
> Signed-off-by: Vara Reddy 
> ---
>  .../devicetree/bindings/display/msm/dp.txt | 252 
> +
>  .../devicetree/bindings/display/msm/dpu.txt|  16 +-
>  2 files changed, 264 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/msm/dp.txt

Sorry for the moving target, but bindings have moved to DT schema format 
now.

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

Re: [PATCH v3] drm/i915/mst: Hookup DRM DP MST late_register/early_unregister callbacks

[Ville Syrjälä]

On Tue, Mar 10, 2020 at 03:51:21PM -0400, Lyude Paul wrote:
> i915 can enable aux device nodes for DP MST by calling
> drm_dp_mst_connector_late_register()/drm_dp_mst_connector_early_unregister(),
> so let's hook that up.
> 
> Changes since v1:
> * Call intel_connector_register/unregister() from
>   intel_dp_mst_connector_late_register/unregister() so we don't lose
>   error injection - Ville Syrjälä
> Changes since v2:
> * Don't forget to clean up if intel_connector_register() fails - Ville
> 
> Cc: Ville Syrjälä 
> Cc: Manasi Navare 
> Cc: "Lee, Shawn C" 
> Signed-off-by: Lyude Paul 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 33 +++--
>  1 file changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index d53978ed3c12..e08caca658c6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -548,12 +548,41 @@ static int intel_dp_mst_get_ddc_modes(struct 
> drm_connector *connector)
>   return ret;
>  }
>  
> +static int
> +intel_dp_mst_connector_late_register(struct drm_connector *connector)
> +{
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> + int ret;
> +
> + ret = drm_dp_mst_connector_late_register(connector,
> +  intel_connector->port);
> + if (ret < 0)
> + return ret;
> +
> + ret = intel_connector_register(connector);
> + if (ret < 0)
> + drm_dp_mst_connector_early_unregister(connector,
> +   intel_connector->port);
> +
> + return ret;
> +}
> +
> +static void
> +intel_dp_mst_connector_early_unregister(struct drm_connector *connector)
> +{
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> +
> + intel_connector_unregister(connector);
> + drm_dp_mst_connector_early_unregister(connector,
> +   intel_connector->port);
> +}
> +
>  static const struct drm_connector_funcs intel_dp_mst_connector_funcs = {
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .atomic_get_property = intel_digital_connector_atomic_get_property,
>   .atomic_set_property = intel_digital_connector_atomic_set_property,
> - .late_register = intel_connector_register,
> - .early_unregister = intel_connector_unregister,
> + .late_register = intel_dp_mst_connector_late_register,
> + .early_unregister = intel_dp_mst_connector_early_unregister,
>   .destroy = intel_connector_destroy,
>   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>   .atomic_duplicate_state = intel_digital_connector_duplicate_state,
> -- 
> 2.24.1

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

Re: [PATCH v8] dt-bindings: display: Add idk-2121wr binding

[Sam Ravnborg]

Hi Prabhakar

On Tue, Mar 10, 2020 at 07:39:29PM +, Lad Prabhakar wrote:
> From: Fabrizio Castro 
> 
> Add binding for the idk-2121wr LVDS panel from Advantech.
> 
> Some panel-specific documentation can be found here:
> https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
> 
> Signed-off-by: Fabrizio Castro 
> Signed-off-by: Lad Prabhakar 
> ---
> 
> Hi All,
> This patch is part of series [1] ("Add dual-LVDS panel support to EK874),
> all the patches have been accepted from it except this one. I have fixed
> Rob's comments in this version of the patch.
> 
> [1] https://patchwork.kernel.org/cover/11297589/
> 
> V7->8
>  * Dropped ref to lvds.yaml, since the panel a dual channel LVDS, as a
>result the root port is called as ports instead of port and the child
>node port@0 and port@1 are used for even and odd pixels, hence binding
>has required property as ports instead of port.

Looks good, thanks for your persistence..
Applied and pushed to drm-misc-next.

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

[PATCH v3] drm/i915/mst: Hookup DRM DP MST late_register/early_unregister callbacks

[Lyude Paul]

i915 can enable aux device nodes for DP MST by calling
drm_dp_mst_connector_late_register()/drm_dp_mst_connector_early_unregister(),
so let's hook that up.

Changes since v1:
* Call intel_connector_register/unregister() from
  intel_dp_mst_connector_late_register/unregister() so we don't lose
  error injection - Ville Syrjälä
Changes since v2:
* Don't forget to clean up if intel_connector_register() fails - Ville

Cc: Ville Syrjälä 
Cc: Manasi Navare 
Cc: "Lee, Shawn C" 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 33 +++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index d53978ed3c12..e08caca658c6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -548,12 +548,41 @@ static int intel_dp_mst_get_ddc_modes(struct 
drm_connector *connector)
return ret;
 }
 
+static int
+intel_dp_mst_connector_late_register(struct drm_connector *connector)
+{
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+   int ret;
+
+   ret = drm_dp_mst_connector_late_register(connector,
+intel_connector->port);
+   if (ret < 0)
+   return ret;
+
+   ret = intel_connector_register(connector);
+   if (ret < 0)
+   drm_dp_mst_connector_early_unregister(connector,
+ intel_connector->port);
+
+   return ret;
+}
+
+static void
+intel_dp_mst_connector_early_unregister(struct drm_connector *connector)
+{
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+
+   intel_connector_unregister(connector);
+   drm_dp_mst_connector_early_unregister(connector,
+ intel_connector->port);
+}
+
 static const struct drm_connector_funcs intel_dp_mst_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.atomic_get_property = intel_digital_connector_atomic_get_property,
.atomic_set_property = intel_digital_connector_atomic_set_property,
-   .late_register = intel_connector_register,
-   .early_unregister = intel_connector_unregister,
+   .late_register = intel_dp_mst_connector_late_register,
+   .early_unregister = intel_dp_mst_connector_early_unregister,
.destroy = intel_connector_destroy,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
-- 
2.24.1

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

Re: [PATCH v2] drm/i915/mst: Hookup DRM DP MST late_register/early_unregister callbacks

[Lyude Paul]

On Tue, 2020-03-10 at 21:06 +0200, Ville Syrjälä wrote:
> On Tue, Mar 10, 2020 at 02:54:16PM -0400, Lyude Paul wrote:
> > i915 can enable aux device nodes for DP MST by calling
> > drm_dp_mst_connector_late_register()/drm_dp_mst_connector_early_unregister
> > (),
> > so let's hook that up.
> > 
> > Changes since v1:
> > * Call intel_connector_register/unregister() from
> >   intel_dp_mst_connector_late_register/unregister() so we don't lose
> >   error injection - Ville Syrjälä
> > 
> > Cc: Ville Syrjälä 
> > Cc: Manasi Navare 
> > Cc: "Lee, Shawn C" 
> > Signed-off-by: Lyude Paul 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 28 +++--
> >  1 file changed, 26 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index d53978ed3c12..9311c10f5b1b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -548,12 +548,36 @@ static int intel_dp_mst_get_ddc_modes(struct
> > drm_connector *connector)
> > return ret;
> >  }
> >  
> > +static int
> > +intel_dp_mst_connector_late_register(struct drm_connector *connector)
> > +{
> > +   struct intel_connector *intel_connector =
> > to_intel_connector(connector);
> > +   int ret;
> > +
> > +   ret = drm_dp_mst_connector_late_register(connector,
> > +intel_connector->port);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   return intel_connector_register(connector);
> 
> Don't we have to undo the damage if this fails?

Yep, whoops. Will send out another respin with this fixed

> 
> > +}
> > +
> > +static void
> > +intel_dp_mst_connector_early_unregister(struct drm_connector *connector)
> > +{
> > +   struct intel_connector *intel_connector =
> > to_intel_connector(connector);
> > +
> > +   intel_connector_unregister(connector);
> > +   drm_dp_mst_connector_early_unregister(connector,
> > + intel_connector->port);
> > +}
> > +
> >  static const struct drm_connector_funcs intel_dp_mst_connector_funcs = {
> > .fill_modes = drm_helper_probe_single_connector_modes,
> > .atomic_get_property = intel_digital_connector_atomic_get_property,
> > .atomic_set_property = intel_digital_connector_atomic_set_property,
> > -   .late_register = intel_connector_register,
> > -   .early_unregister = intel_connector_unregister,
> > +   .late_register = intel_dp_mst_connector_late_register,
> > +   .early_unregister = intel_dp_mst_connector_early_unregister,
> > .destroy = intel_connector_destroy,
> > .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> > .atomic_duplicate_state = intel_digital_connector_duplicate_state,
> > -- 
> > 2.24.1
-- 
Cheers,
Lyude Paul (she/her)
Associate Software Engineer at Red Hat

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

[PATCH v7] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

[Karol Herbst]

Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.

Depending on the used kernel there might be messages like those in demsg:

"nouveau :01:00.0: Refused to change power state, currently in D3"
"nouveau :01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.

It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.

Signed-off-by: Karol Herbst 
Cc: Bjorn Helgaas 
Cc: Lyude Paul 
Cc: Rafael J. Wysocki 
Cc: Mika Westerberg 
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
Reviewed-by: Mika Westerberg 

---
v2: convert to pci_dev quirk
put a proper technical explanation of the issue as a in-code comment
v3: disable it only for certain combinations of intel and nvidia hardware
v4: simplify quirk by setting flag on the GPU itself
v5: restructure quirk to make it easier to add new IDs
fix whitespace issues
fix potential NULL pointer access
update the quirk documentation
v6: move quirk into nouveau
v7: fix typos and commit message

 drivers/gpu/drm/nouveau/nouveau_drm.c | 57 +++
 drivers/pci/pci.c |  8 
 include/linux/pci.h   |  1 +
 3 files changed, 66 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b65ae817eabf..2c86f0248305 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -618,6 +618,60 @@ nouveau_drm_device_fini(struct drm_device *dev)
kfree(drm);
 }
 
+/*
+ * On some Intel PCIe bridge controllers doing a
+ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
+ * Skipping the intermediate D3hot step seems to make it work again. This is
+ * probably caused by not meeting the expectation the involved AML code has
+ * when the GPU is put into D3hot state before invoking it.
+ *
+ * This leads to various manifestations of this issue:
+ *  - AML code execution to power on the GPU hits an infinite loop (as the
+ *code waits on device memory to change).
+ *  - kernel crashes, as all PCI reads return -1, which most code isn't able
+ *to handle well enough.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not
+ * documented PCI config space register 0x248 of the Intel PCIe bridge
+ * controller (0x1901) in order to change the state of the PCIe link between
+ * the PCIe port and the GPU. There are alternative code paths using other
+ * registers, which seem to work fine (executed pre Windows 8):
+ *  - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ *  - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear whether
+ * this issue only occurs in combination with listed Intel PCIe bridge
+ * controllers and the mentioned GPUs or other devices as well.
+ *
+ * documentation on the PCIe bridge controller can be found in the
+ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume 
2"
+ * Section "12 PCI Express* Controller (x16) Registers"
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *dev)
+{
+   struct pci_dev *bridge = pci_upstream_bridge(dev);
+
+   if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
+   return;
+
+   switch (bridge->device) {
+   case 0x1901:
+   dev->parent_d3cold = 1;
+   break;
+   }
+}
+
 static int nouveau_drm_probe(struct pci_dev *pdev,
 const struct pci_device_id *pent)
 {
@@ -699,6 +753,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (ret)
goto fail_drm_dev_init;
 
+   quirk_broken_nv_runpm(pdev);
return 0;
 
 fail_drm_dev_init:
@@ -735,6 +790,8 @@ nouveau_drm_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
 
+   /* revert our workaround */
+   pdev->parent_d3cold = false;

Re: [PATCH v5 2/2] drm/edid: Add function to parse EDID descriptors for adaptive sync limits

[Manasi Navare]

On Tue, Mar 10, 2020 at 09:13:30PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 10, 2020 at 12:08:33PM -0700, Manasi Navare wrote:
> > Hi Ville,
> > 
> > Please find answers to your concerns below:
> > 
> > On Mon, Mar 09, 2020 at 02:39:40PM -0700, Manasi Navare wrote:
> > > Adaptive Sync is a VESA feature so add a DRM core helper to parse
> > > the EDID's detailed descritors to obtain the adaptive sync monitor range.
> > > Store this info as part fo drm_display_info so it can be used
> > > across all drivers.
> > > This part of the code is stripped out of amdgpu's function
> > > amdgpu_dm_update_freesync_caps() to make it generic and be used
> > > across all DRM drivers
> > > 
> > > v5:
> > > * Use the renamed flags
> > > v4:
> > > * Use is_display_descriptor() (Ville)
> > > * Name the monitor range flags (Ville)
> > > v3:
> > > * Remove the edid parsing restriction for just DP (Nicholas)
> > > * Use drm_for_each_detailed_block (Ville)
> > > * Make the drm_get_adaptive_sync_range function static (Harry, Jani)
> > > v2:
> > > * Change vmin and vmax to use u8 (Ville)
> > > * Dont store pixel clock since that is just a max dotclock
> > > and not related to VRR mode (Manasi)
> > > 
> > > Cc: Ville Syrjälä 
> > > Cc: Harry Wentland 
> > > Cc: Clinton A Taylor 
> > > Cc: Kazlauskas Nicholas 
> > > Signed-off-by: Manasi Navare 
> > > Reviewed-by: Nicholas Kazlauskas 
> > > ---
> > >  drivers/gpu/drm/drm_edid.c  | 44 +
> > >  include/drm/drm_connector.h | 22 +++
> > >  2 files changed, 66 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index ad41764a4ebe..24b76ae58fdd 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector 
> > > *connector,
> > >   }
> > >  }
> > >  
> > > +static
> > > +void get_adaptive_sync_range(struct detailed_timing *timing,
> > > +  void *info_adaptive_sync)
> > > +{
> > > + struct drm_adaptive_sync_info *adaptive_sync = info_adaptive_sync;
> > > + const struct detailed_non_pixel *data = >data.other_data;
> > > + const struct detailed_data_monitor_range *range = >data.range;
> > > +
> > > + if (!is_display_descriptor((const u8 *)timing, 
> > > EDID_DETAIL_MONITOR_RANGE))
> > > + return;
> > > +
> > > + /*
> > > +  * Check for flag range limits only. If flag == 1 then
> > > +  * no additional timing information provided.
> > > +  * Default GTF, GTF Secondary curve and CVT are not
> > > +  * supported
> > > +  */
> > > + if (range->flags != DRM_EDID_RANGE_LIMITS_ONLY_FLAG)
> > > + return;
> > > +
> > > + adaptive_sync->min_vfreq = range->min_vfreq;
> > > + adaptive_sync->max_vfreq = range->max_vfreq;
> > > +}
> > > +
> > > +static
> > > +void drm_get_adaptive_sync_range(struct drm_connector *connector,
> > > +  const struct edid *edid)
> > > +{
> > > + struct drm_display_info *info = >display_info;
> > > +
> > > + if (!version_greater(edid, 1, 1))
> > > + return;
> > > +
> > > + drm_for_each_detailed_block((u8 *)edid, get_adaptive_sync_range,
> > > + >adaptive_sync);
> > 
> > Some functions like get_monitor_name also pass something like _name, I 
> > dont
> > think there is any specific convention of the argument name to be passed.
> 
> Hmm. Yeah, it's a bit all over. Still I'd probably follow 
> the majority vote.
>

I feel that this name makes it more intuitive rather than adding a generic name
If you dont feel strongly about changing it, I would like to keep this as is
 
> > 
> > > +
> > > + DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d Hz\n",
> > > +   info->adaptive_sync.min_vfreq,
> > > +   info->adaptive_sync.max_vfreq);
> > 
> > Yes I agree that this is just a monitor range and unless the dpcd ignore 
> > msa bit is set
> > and the range is atleast 10Hz apart , it might not be vrr range.
> > 
> > Would you prefer renaming this info->adaptive_sync as info->monitor_range ? 
> > Or
> > should i just print it out as Monitor range is in the dmesg but leave the 
> > info->adaptive_sync
> > naming as is?
> 
> If we want to parse it uncoditionally then I guess I'd go with the
> monitor_rage naming, and leave it up to the vrr code to know what to do
> with it.
>

Yes I plan to add a function in the driver code that checks for the msa bit and 
this range to be
greater than 10 to say that the sink is adaptive sync capable.

So i will just rename this struct to monitor range then?

Manasi 
> > 
> > Manasi
> > 
> > > +}
> > > +
> > >  /* A connector has no EDID information, so we've got no EDID to compute 
> > > quirks from. Reset
> > >   * all of the values which would have been set from EDID
> > >   */
> > > @@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector 
> > > *connector)
> > >   memset(>hdmi, 0, sizeof(info->hdmi));
> > >  
> > >  

Re: [PATCH v5 2/2] drm/edid: Add function to parse EDID descriptors for adaptive sync limits

[Ville Syrjälä]

On Tue, Mar 10, 2020 at 12:08:33PM -0700, Manasi Navare wrote:
> Hi Ville,
> 
> Please find answers to your concerns below:
> 
> On Mon, Mar 09, 2020 at 02:39:40PM -0700, Manasi Navare wrote:
> > Adaptive Sync is a VESA feature so add a DRM core helper to parse
> > the EDID's detailed descritors to obtain the adaptive sync monitor range.
> > Store this info as part fo drm_display_info so it can be used
> > across all drivers.
> > This part of the code is stripped out of amdgpu's function
> > amdgpu_dm_update_freesync_caps() to make it generic and be used
> > across all DRM drivers
> > 
> > v5:
> > * Use the renamed flags
> > v4:
> > * Use is_display_descriptor() (Ville)
> > * Name the monitor range flags (Ville)
> > v3:
> > * Remove the edid parsing restriction for just DP (Nicholas)
> > * Use drm_for_each_detailed_block (Ville)
> > * Make the drm_get_adaptive_sync_range function static (Harry, Jani)
> > v2:
> > * Change vmin and vmax to use u8 (Ville)
> > * Dont store pixel clock since that is just a max dotclock
> > and not related to VRR mode (Manasi)
> > 
> > Cc: Ville Syrjälä 
> > Cc: Harry Wentland 
> > Cc: Clinton A Taylor 
> > Cc: Kazlauskas Nicholas 
> > Signed-off-by: Manasi Navare 
> > Reviewed-by: Nicholas Kazlauskas 
> > ---
> >  drivers/gpu/drm/drm_edid.c  | 44 +
> >  include/drm/drm_connector.h | 22 +++
> >  2 files changed, 66 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index ad41764a4ebe..24b76ae58fdd 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector 
> > *connector,
> > }
> >  }
> >  
> > +static
> > +void get_adaptive_sync_range(struct detailed_timing *timing,
> > +void *info_adaptive_sync)
> > +{
> > +   struct drm_adaptive_sync_info *adaptive_sync = info_adaptive_sync;
> > +   const struct detailed_non_pixel *data = >data.other_data;
> > +   const struct detailed_data_monitor_range *range = >data.range;
> > +
> > +   if (!is_display_descriptor((const u8 *)timing, 
> > EDID_DETAIL_MONITOR_RANGE))
> > +   return;
> > +
> > +   /*
> > +* Check for flag range limits only. If flag == 1 then
> > +* no additional timing information provided.
> > +* Default GTF, GTF Secondary curve and CVT are not
> > +* supported
> > +*/
> > +   if (range->flags != DRM_EDID_RANGE_LIMITS_ONLY_FLAG)
> > +   return;
> > +
> > +   adaptive_sync->min_vfreq = range->min_vfreq;
> > +   adaptive_sync->max_vfreq = range->max_vfreq;
> > +}
> > +
> > +static
> > +void drm_get_adaptive_sync_range(struct drm_connector *connector,
> > +const struct edid *edid)
> > +{
> > +   struct drm_display_info *info = >display_info;
> > +
> > +   if (!version_greater(edid, 1, 1))
> > +   return;
> > +
> > +   drm_for_each_detailed_block((u8 *)edid, get_adaptive_sync_range,
> > +   >adaptive_sync);
> 
> Some functions like get_monitor_name also pass something like _name, I 
> dont
> think there is any specific convention of the argument name to be passed.

Hmm. Yeah, it's a bit all over. Still I'd probably follow 
the majority vote.

> 
> > +
> > +   DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d Hz\n",
> > + info->adaptive_sync.min_vfreq,
> > + info->adaptive_sync.max_vfreq);
> 
> Yes I agree that this is just a monitor range and unless the dpcd ignore msa 
> bit is set
> and the range is atleast 10Hz apart , it might not be vrr range.
> 
> Would you prefer renaming this info->adaptive_sync as info->monitor_range ? Or
> should i just print it out as Monitor range is in the dmesg but leave the 
> info->adaptive_sync
> naming as is?

If we want to parse it uncoditionally then I guess I'd go with the
monitor_rage naming, and leave it up to the vrr code to know what to do
with it.

> 
> Manasi
> 
> > +}
> > +
> >  /* A connector has no EDID information, so we've got no EDID to compute 
> > quirks from. Reset
> >   * all of the values which would have been set from EDID
> >   */
> > @@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector 
> > *connector)
> > memset(>hdmi, 0, sizeof(info->hdmi));
> >  
> > info->non_desktop = 0;
> > +   memset(>adaptive_sync, 0, sizeof(info->adaptive_sync));
> >  }
> >  
> >  u32 drm_add_display_info(struct drm_connector *connector, const struct 
> > edid *edid)
> > @@ -4975,6 +5017,8 @@ u32 drm_add_display_info(struct drm_connector 
> > *connector, const struct edid *edi
> >  
> > info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
> >  
> > +   drm_get_adaptive_sync_range(connector, edid);
> > +
> > DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
> >  
> > if (edid->revision < 3)
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 

Re: [PATCH 1/2] drm/panel: Add Starry KR070PE2T

[Ville Syrjälä]

On Tue, Mar 10, 2020 at 07:54:23PM +0100, Sam Ravnborg wrote:
> Hi Pascal.
> 
> Thanks for submitting.
> 
> On Tue, Mar 10, 2020 at 11:27:23AM +0100, Pascal Roeleven wrote:
> > The KR070PE2T is a 7" panel with a resolution of 800x480.
> > 
> > KR070PE2T is the marking present on the ribbon cable. As this panel is
> > probably available under different brands, this marking will catch
> > most devices.
> > 
> > Signed-off-by: Pascal Roeleven 
> 
> A few things to improve.
> 
> The binding should be a separate patch.
> subject - shall start with dt-bindings:
> Shall be sent to deveicetree mailing list.
> 
> For panel we no longer accept .txt bindings.
> But the good news is that since the panel is simple,
> you only need to list your compatible in the file
> bindings/display/panel/panel-simple.yaml
> - must be en alphabetical order
> - vendor prefix must be present in vendor-prefixes
> 
> 
> 
> > ---
> >  .../display/panel/starry,kr070pe2t.txt|  7 +
> >  drivers/gpu/drm/panel/panel-simple.c  | 26 +++
> >  2 files changed, 33 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt 
> > b/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
> > new file mode 100644
> > index 0..699ad5eb2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
> > @@ -0,0 +1,7 @@
> > +Starry 7" (800x480 pixels) LCD panel
> > +
> > +Required properties:
> > +- compatible: should be "starry,kr070pe2t"
> > +
> > +This binding is compatible with the simple-panel binding, which is 
> > specified
> > +in simple-panel.txt in this directory.
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index e14c14ac6..027a2612b 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2842,6 +2842,29 @@ static const struct panel_desc 
> > shelly_sca07010_bfn_lnn = {
> > .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> >  };
> >  
> > +static const struct drm_display_mode starry_kr070pe2t_mode = {
> > +   .clock = 33000,
> > +   .hdisplay = 800,
> > +   .hsync_start = 800 + 209,
> > +   .hsync_end = 800 + 209 + 1,
> > +   .htotal = 800 + 209 + 1 + 45,
> > +   .vdisplay = 480,
> > +   .vsync_start = 480 + 22,
> > +   .vsync_end = 480 + 22 + 1,
> > +   .vtotal = 480 + 22 + 1 + 22,
> > +   .vrefresh = 60,
> > +};
> 
> Please adjust so:
> vrefresh * htotal * vtotal == clock.
> I cannot say what needs to be adjusted.
> But we are moving away from specifying vrefresh and want the
> data to be OK.

This one actually looks OK to me. Unless I typoed the numbers
the timings give us a vrefresh of 59.58 which gets rounded to 60.
So no change once .vrefresh disappears AFAICS.

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

Re: [PATCH v5 1/2] drm/edid: Name the detailed monitor range flags

[Manasi Navare]

On Tue, Mar 10, 2020 at 06:20:27PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2020 at 02:39:39PM -0700, Manasi Navare wrote:
> > This patch adds defines for the detailed monitor
> > range flags as per the EDID specification.
> > 
> > v2:
> > * Rename the flags with DRM_EDID_ (Jani N)
> > 
> > Suggested-by: Ville Syrjälä 
> > Cc: Ville Syrjälä 
> > Cc: Harry Wentland 
> > Cc: Clinton A Taylor 
> > Cc: Kazlauskas Nicholas 
> > Cc: Jani Nikula 
> > Signed-off-by: Manasi Navare 
> > Reviewed-by: Nicholas Kazlauskas 
> > ---
> >  include/drm/drm_edid.h | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index f0b03d401c27..34b15e3d070c 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -91,6 +91,11 @@ struct detailed_data_string {
> > u8 str[13];
> >  } __attribute__((packed));
> >  
> > +#define DRM_EDID_DEFAULT_GTF_SUPPORT_FLAG   0x00
> > +#define DRM_EDID_RANGE_LIMITS_ONLY_FLAG 0x01
> > +#define DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG 0x02
> > +#define DRM_EDID_CVT_SUPPORT_FLAG   0x04
> 
> No indication what flags thse are. Also missing the
> actual change to use them in drm_edid.c.
>

The name of the flag in #define indicates what flag it is, how else do you
want me to add teh indication?

I have done the change in my second patch to use this flag #define 
Use of these flags in other places in drm_edid.c will be follow up patches

SOunds good?

Manasi
 
> > +
> >  struct detailed_data_monitor_range {
> > u8 min_vfreq;
> > u8 max_vfreq;
> > -- 
> > 2.19.1
> 
> -- 
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/2] drm/edid: Add function to parse EDID descriptors for adaptive sync limits

[Manasi Navare]

Hi Ville,

Please find answers to your concerns below:

On Mon, Mar 09, 2020 at 02:39:40PM -0700, Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
> This part of the code is stripped out of amdgpu's function
> amdgpu_dm_update_freesync_caps() to make it generic and be used
> across all DRM drivers
> 
> v5:
> * Use the renamed flags
> v4:
> * Use is_display_descriptor() (Ville)
> * Name the monitor range flags (Ville)
> v3:
> * Remove the edid parsing restriction for just DP (Nicholas)
> * Use drm_for_each_detailed_block (Ville)
> * Make the drm_get_adaptive_sync_range function static (Harry, Jani)
> v2:
> * Change vmin and vmax to use u8 (Ville)
> * Dont store pixel clock since that is just a max dotclock
> and not related to VRR mode (Manasi)
> 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Clinton A Taylor 
> Cc: Kazlauskas Nicholas 
> Signed-off-by: Manasi Navare 
> Reviewed-by: Nicholas Kazlauskas 
> ---
>  drivers/gpu/drm/drm_edid.c  | 44 +
>  include/drm/drm_connector.h | 22 +++
>  2 files changed, 66 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ad41764a4ebe..24b76ae58fdd 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>   }
>  }
>  
> +static
> +void get_adaptive_sync_range(struct detailed_timing *timing,
> +  void *info_adaptive_sync)
> +{
> + struct drm_adaptive_sync_info *adaptive_sync = info_adaptive_sync;
> + const struct detailed_non_pixel *data = >data.other_data;
> + const struct detailed_data_monitor_range *range = >data.range;
> +
> + if (!is_display_descriptor((const u8 *)timing, 
> EDID_DETAIL_MONITOR_RANGE))
> + return;
> +
> + /*
> +  * Check for flag range limits only. If flag == 1 then
> +  * no additional timing information provided.
> +  * Default GTF, GTF Secondary curve and CVT are not
> +  * supported
> +  */
> + if (range->flags != DRM_EDID_RANGE_LIMITS_ONLY_FLAG)
> + return;
> +
> + adaptive_sync->min_vfreq = range->min_vfreq;
> + adaptive_sync->max_vfreq = range->max_vfreq;
> +}
> +
> +static
> +void drm_get_adaptive_sync_range(struct drm_connector *connector,
> +  const struct edid *edid)
> +{
> + struct drm_display_info *info = >display_info;
> +
> + if (!version_greater(edid, 1, 1))
> + return;
> +
> + drm_for_each_detailed_block((u8 *)edid, get_adaptive_sync_range,
> + >adaptive_sync);

Some functions like get_monitor_name also pass something like _name, I dont
think there is any specific convention of the argument name to be passed.

> +
> + DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d Hz\n",
> +   info->adaptive_sync.min_vfreq,
> +   info->adaptive_sync.max_vfreq);

Yes I agree that this is just a monitor range and unless the dpcd ignore msa 
bit is set
and the range is atleast 10Hz apart , it might not be vrr range.

Would you prefer renaming this info->adaptive_sync as info->monitor_range ? Or
should i just print it out as Monitor range is in the dmesg but leave the 
info->adaptive_sync
naming as is?

Manasi

> +}
> +
>  /* A connector has no EDID information, so we've got no EDID to compute 
> quirks from. Reset
>   * all of the values which would have been set from EDID
>   */
> @@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector *connector)
>   memset(>hdmi, 0, sizeof(info->hdmi));
>  
>   info->non_desktop = 0;
> + memset(>adaptive_sync, 0, sizeof(info->adaptive_sync));
>  }
>  
>  u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
> *edid)
> @@ -4975,6 +5017,8 @@ u32 drm_add_display_info(struct drm_connector 
> *connector, const struct edid *edi
>  
>   info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
>  
> + drm_get_adaptive_sync_range(connector, edid);
> +
>   DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
>  
>   if (edid->revision < 3)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 0df7a95ca5d9..2b22c0fa42c4 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -254,6 +254,23 @@ enum drm_panel_orientation {
>   DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
>  };
>  
> +/**
> + * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
> + * _display_info
> + *
> + * This struct is used to store a Panel's Adaptive Sync capabilities
> + * as parsed from EDID's detailed monitor range descriptor block.
> + *
> + * @min_vfreq: This is the min 

Re: [PATCH v2] drm/i915/mst: Hookup DRM DP MST late_register/early_unregister callbacks

[Ville Syrjälä]

On Tue, Mar 10, 2020 at 02:54:16PM -0400, Lyude Paul wrote:
> i915 can enable aux device nodes for DP MST by calling
> drm_dp_mst_connector_late_register()/drm_dp_mst_connector_early_unregister(),
> so let's hook that up.
> 
> Changes since v1:
> * Call intel_connector_register/unregister() from
>   intel_dp_mst_connector_late_register/unregister() so we don't lose
>   error injection - Ville Syrjälä
> 
> Cc: Ville Syrjälä 
> Cc: Manasi Navare 
> Cc: "Lee, Shawn C" 
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 28 +++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index d53978ed3c12..9311c10f5b1b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -548,12 +548,36 @@ static int intel_dp_mst_get_ddc_modes(struct 
> drm_connector *connector)
>   return ret;
>  }
>  
> +static int
> +intel_dp_mst_connector_late_register(struct drm_connector *connector)
> +{
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> + int ret;
> +
> + ret = drm_dp_mst_connector_late_register(connector,
> +  intel_connector->port);
> + if (ret < 0)
> + return ret;
> +
> + return intel_connector_register(connector);

Don't we have to undo the damage if this fails?

> +}
> +
> +static void
> +intel_dp_mst_connector_early_unregister(struct drm_connector *connector)
> +{
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> +
> + intel_connector_unregister(connector);
> + drm_dp_mst_connector_early_unregister(connector,
> +   intel_connector->port);
> +}
> +
>  static const struct drm_connector_funcs intel_dp_mst_connector_funcs = {
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .atomic_get_property = intel_digital_connector_atomic_get_property,
>   .atomic_set_property = intel_digital_connector_atomic_set_property,
> - .late_register = intel_connector_register,
> - .early_unregister = intel_connector_unregister,
> + .late_register = intel_dp_mst_connector_late_register,
> + .early_unregister = intel_dp_mst_connector_early_unregister,
>   .destroy = intel_connector_destroy,
>   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>   .atomic_duplicate_state = intel_digital_connector_duplicate_state,
> -- 
> 2.24.1

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

[PATCH v2] drm/i915/mst: Hookup DRM DP MST late_register/early_unregister callbacks

[Lyude Paul]

i915 can enable aux device nodes for DP MST by calling
drm_dp_mst_connector_late_register()/drm_dp_mst_connector_early_unregister(),
so let's hook that up.

Changes since v1:
* Call intel_connector_register/unregister() from
  intel_dp_mst_connector_late_register/unregister() so we don't lose
  error injection - Ville Syrjälä

Cc: Ville Syrjälä 
Cc: Manasi Navare 
Cc: "Lee, Shawn C" 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 28 +++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index d53978ed3c12..9311c10f5b1b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -548,12 +548,36 @@ static int intel_dp_mst_get_ddc_modes(struct 
drm_connector *connector)
return ret;
 }
 
+static int
+intel_dp_mst_connector_late_register(struct drm_connector *connector)
+{
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+   int ret;
+
+   ret = drm_dp_mst_connector_late_register(connector,
+intel_connector->port);
+   if (ret < 0)
+   return ret;
+
+   return intel_connector_register(connector);
+}
+
+static void
+intel_dp_mst_connector_early_unregister(struct drm_connector *connector)
+{
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+
+   intel_connector_unregister(connector);
+   drm_dp_mst_connector_early_unregister(connector,
+ intel_connector->port);
+}
+
 static const struct drm_connector_funcs intel_dp_mst_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.atomic_get_property = intel_digital_connector_atomic_get_property,
.atomic_set_property = intel_digital_connector_atomic_set_property,
-   .late_register = intel_connector_register,
-   .early_unregister = intel_connector_unregister,
+   .late_register = intel_dp_mst_connector_late_register,
+   .early_unregister = intel_dp_mst_connector_early_unregister,
.destroy = intel_connector_destroy,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
-- 
2.24.1

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

Re: [PATCH 1/2] drm/panel: Add Starry KR070PE2T

[Sam Ravnborg]

Hi Pascal.

Thanks for submitting.

On Tue, Mar 10, 2020 at 11:27:23AM +0100, Pascal Roeleven wrote:
> The KR070PE2T is a 7" panel with a resolution of 800x480.
> 
> KR070PE2T is the marking present on the ribbon cable. As this panel is
> probably available under different brands, this marking will catch
> most devices.
> 
> Signed-off-by: Pascal Roeleven 

A few things to improve.

The binding should be a separate patch.
subject - shall start with dt-bindings:
Shall be sent to deveicetree mailing list.

For panel we no longer accept .txt bindings.
But the good news is that since the panel is simple,
you only need to list your compatible in the file
bindings/display/panel/panel-simple.yaml
- must be en alphabetical order
- vendor prefix must be present in vendor-prefixes



> ---
>  .../display/panel/starry,kr070pe2t.txt|  7 +
>  drivers/gpu/drm/panel/panel-simple.c  | 26 +++
>  2 files changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt 
> b/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
> new file mode 100644
> index 0..699ad5eb2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
> @@ -0,0 +1,7 @@
> +Starry 7" (800x480 pixels) LCD panel
> +
> +Required properties:
> +- compatible: should be "starry,kr070pe2t"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index e14c14ac6..027a2612b 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2842,6 +2842,29 @@ static const struct panel_desc shelly_sca07010_bfn_lnn 
> = {
>   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
>  };
>  
> +static const struct drm_display_mode starry_kr070pe2t_mode = {
> + .clock = 33000,
> + .hdisplay = 800,
> + .hsync_start = 800 + 209,
> + .hsync_end = 800 + 209 + 1,
> + .htotal = 800 + 209 + 1 + 45,
> + .vdisplay = 480,
> + .vsync_start = 480 + 22,
> + .vsync_end = 480 + 22 + 1,
> + .vtotal = 480 + 22 + 1 + 22,
> + .vrefresh = 60,
> +};

Please adjust so:
vrefresh * htotal * vtotal == clock.
I cannot say what needs to be adjusted.
But we are moving away from specifying vrefresh and want the
data to be OK.

> +
> +static const struct panel_desc starry_kr070pe2t = {
> + .modes = _kr070pe2t_mode,
> + .num_modes = 1,
> + .bpc = 8,
> + .size = {
> + .width = 152,
> + .height = 86,
> + },
> +};

For this part specifying the connector type is today mandatory.
And please investigate if you can be more precise concerning
bus_format, flags, etc.
See also what other panels do in the same file.

Sam


> +
>  static const struct drm_display_mode starry_kr122ea0sra_mode = {
>   .clock = 147000,
>   .hdisplay = 1920,
> @@ -3474,6 +3497,9 @@ static const struct of_device_id platform_of_match[] = {
>   }, {
>   .compatible = "shelly,sca07010-bfn-lnn",
>   .data = _sca07010_bfn_lnn,
> + }, {
> + .compatible = "starry,kr070pe2t",
> + .data = _kr070pe2t,
>   }, {
>   .compatible = "starry,kr122ea0sra",
>   .data = _kr122ea0sra,
> -- 
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/mst: Hookup DRM DP MST late_register/early_unregister callbacks

[Lyude Paul]

On Tue, 2020-03-10 at 20:42 +0200, Ville Syrjälä wrote:
> On Tue, Mar 10, 2020 at 02:28:54PM -0400, Lyude Paul wrote:
> > i915 can enable aux device nodes for DP MST by calling
> > drm_dp_mst_connector_late_register()/drm_dp_mst_connector_early_unregister
> > (),
> > so let's hook that up.
> 
> Oh, we didn't have that yet? I thought it got hooked up for everyone
> but I guess not.
> 
> > Cc: Ville Syrjälä 
> > Cc: Manasi Navare 
> > Cc: "Lee, Shawn C" 
> > Signed-off-by: Lyude Paul 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 22 +++--
> >  1 file changed, 20 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index d53978ed3c12..bcff2e06ead6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -548,12 +548,30 @@ static int intel_dp_mst_get_ddc_modes(struct
> > drm_connector *connector)
> > return ret;
> >  }
> >  
> > +static int
> > +intel_dp_mst_connector_late_register(struct drm_connector *connector)
> > +{
> > +   struct intel_connector *intel_connector =
> > to_intel_connector(connector);
> > +
> > +   return drm_dp_mst_connector_late_register(connector,
> > + intel_connector->port);
> > +}
> > +
> > +static void
> > +intel_dp_mst_connector_early_unregister(struct drm_connector *connector)
> > +{
> > +   struct intel_connector *intel_connector =
> > to_intel_connector(connector);
> > +
> > +   drm_dp_mst_connector_early_unregister(connector,
> > + intel_connector->port);
> > +}
> > +
> >  static const struct drm_connector_funcs intel_dp_mst_connector_funcs = {
> > .fill_modes = drm_helper_probe_single_connector_modes,
> > .atomic_get_property = intel_digital_connector_atomic_get_property,
> > .atomic_set_property = intel_digital_connector_atomic_set_property,
> > -   .late_register = intel_connector_register,
> 
> Dunno if we want to lose the error injection...

Gotcha, will send out a fixed respin in just a moment
> 
> > -   .early_unregister = intel_connector_unregister,
> > +   .late_register = intel_dp_mst_connector_late_register,
> > +   .early_unregister = intel_dp_mst_connector_early_unregister,
> > .destroy = intel_connector_destroy,
> > .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> > .atomic_duplicate_state = intel_digital_connector_duplicate_state,
> > -- 
> > 2.24.1
-- 
Cheers,
Lyude Paul (she/her)
Associate Software Engineer at Red Hat

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

Re: [PATCH] drm/i915/mst: Hookup DRM DP MST late_register/early_unregister callbacks

[Ville Syrjälä]

On Tue, Mar 10, 2020 at 02:28:54PM -0400, Lyude Paul wrote:
> i915 can enable aux device nodes for DP MST by calling
> drm_dp_mst_connector_late_register()/drm_dp_mst_connector_early_unregister(),
> so let's hook that up.

Oh, we didn't have that yet? I thought it got hooked up for everyone
but I guess not.

> 
> Cc: Ville Syrjälä 
> Cc: Manasi Navare 
> Cc: "Lee, Shawn C" 
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 22 +++--
>  1 file changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index d53978ed3c12..bcff2e06ead6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -548,12 +548,30 @@ static int intel_dp_mst_get_ddc_modes(struct 
> drm_connector *connector)
>   return ret;
>  }
>  
> +static int
> +intel_dp_mst_connector_late_register(struct drm_connector *connector)
> +{
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> +
> + return drm_dp_mst_connector_late_register(connector,
> +   intel_connector->port);
> +}
> +
> +static void
> +intel_dp_mst_connector_early_unregister(struct drm_connector *connector)
> +{
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> +
> + drm_dp_mst_connector_early_unregister(connector,
> +   intel_connector->port);
> +}
> +
>  static const struct drm_connector_funcs intel_dp_mst_connector_funcs = {
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .atomic_get_property = intel_digital_connector_atomic_get_property,
>   .atomic_set_property = intel_digital_connector_atomic_set_property,
> - .late_register = intel_connector_register,

Dunno if we want to lose the error injection...

> - .early_unregister = intel_connector_unregister,
> + .late_register = intel_dp_mst_connector_late_register,
> + .early_unregister = intel_dp_mst_connector_early_unregister,
>   .destroy = intel_connector_destroy,
>   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>   .atomic_duplicate_state = intel_digital_connector_duplicate_state,
> -- 
> 2.24.1

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

Applied "spi: spi-fsl-dspi: fix DMA mapping" to the spi tree

[Mark Brown]

The patch

   spi: spi-fsl-dspi: fix DMA mapping

has been applied to the spi tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 22ee9de1ecfb4459a9b3a959994f6ccb4a3827a4 Mon Sep 17 00:00:00 2001
From: Michael Walle 
Date: Tue, 10 Mar 2020 08:33:13 +0100
Subject: [PATCH] spi: spi-fsl-dspi: fix DMA mapping

Use the correct device to request the DMA mapping. Otherwise the IOMMU
doesn't get the mapping and it will generate a page fault.

The error messages look like:
[3.008452] arm-smmu 500.iommu: Unhandled context fault: fsr=0x402, 
iova=0xf980, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
[3.020123] arm-smmu 500.iommu: Unhandled context fault: fsr=0x402, 
iova=0xf980, fsynr=0x3f0022, cbfrsynra=0x828, cb=8

This was tested on a custom board with a LS1028A SoC.

Signed-off-by: Michael Walle 
Link: https://lore.kernel.org/r/20200310073313.21277-1-mich...@walle.cc
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-fsl-dspi.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 0683a3fbd48c..50e3382f0c50 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -497,14 +497,16 @@ static int dspi_request_dma(struct fsl_dspi *dspi, 
phys_addr_t phy_addr)
goto err_tx_channel;
}
 
-   dma->tx_dma_buf = dma_alloc_coherent(dev, 
dspi->devtype_data->dma_bufsize,
+   dma->tx_dma_buf = dma_alloc_coherent(dma->chan_tx->device->dev,
+dspi->devtype_data->dma_bufsize,
 >tx_dma_phys, GFP_KERNEL);
if (!dma->tx_dma_buf) {
ret = -ENOMEM;
goto err_tx_dma_buf;
}
 
-   dma->rx_dma_buf = dma_alloc_coherent(dev, 
dspi->devtype_data->dma_bufsize,
+   dma->rx_dma_buf = dma_alloc_coherent(dma->chan_rx->device->dev,
+dspi->devtype_data->dma_bufsize,
 >rx_dma_phys, GFP_KERNEL);
if (!dma->rx_dma_buf) {
ret = -ENOMEM;
@@ -541,10 +543,12 @@ static int dspi_request_dma(struct fsl_dspi *dspi, 
phys_addr_t phy_addr)
return 0;
 
 err_slave_config:
-   dma_free_coherent(dev, dspi->devtype_data->dma_bufsize,
+   dma_free_coherent(dma->chan_rx->device->dev,
+ dspi->devtype_data->dma_bufsize,
  dma->rx_dma_buf, dma->rx_dma_phys);
 err_rx_dma_buf:
-   dma_free_coherent(dev, dspi->devtype_data->dma_bufsize,
+   dma_free_coherent(dma->chan_tx->device->dev,
+ dspi->devtype_data->dma_bufsize,
  dma->tx_dma_buf, dma->tx_dma_phys);
 err_tx_dma_buf:
dma_release_channel(dma->chan_tx);
@@ -560,20 +564,19 @@ static int dspi_request_dma(struct fsl_dspi *dspi, 
phys_addr_t phy_addr)
 static void dspi_release_dma(struct fsl_dspi *dspi)
 {
struct fsl_dspi_dma *dma = dspi->dma;
-   struct device *dev = >pdev->dev;
 
if (!dma)
return;
 
if (dma->chan_tx) {
-   dma_unmap_single(dev, dma->tx_dma_phys,
+   dma_unmap_single(dma->chan_tx->device->dev, dma->tx_dma_phys,
 dspi->devtype_data->dma_bufsize,
 DMA_TO_DEVICE);
dma_release_channel(dma->chan_tx);
}
 
if (dma->chan_rx) {
-   dma_unmap_single(dev, dma->rx_dma_phys,
+   dma_unmap_single(dma->chan_rx->device->dev, dma->rx_dma_phys,
 dspi->devtype_data->dma_bufsize,
 DMA_FROM_DEVICE);
dma_release_channel(dma->chan_rx);
-- 
2.20.1

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

Re: [PATCH V3 1/4] backlight: qcom-wled: convert the wled bindings to .yaml format

[Rob Herring]

On Mon,  9 Mar 2020 18:55:59 +0530, Kiran Gunda wrote:
> Convert the qcom-wled bindings from .txt to .yaml format.
> 
> Signed-off-by: Kiran Gunda 
> ---
>  .../bindings/leds/backlight/qcom-wled.txt  | 154 -
>  .../bindings/leds/backlight/qcom-wled.yaml | 184 
> +
>  2 files changed, 184 insertions(+), 154 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml: $id: relative 
path/filename doesn't match actual path or filename
expected: http://devicetree.org/schemas/leds/backlight/qcom-wled.yaml#

See https://patchwork.ozlabs.org/patch/1251567
Please check and re-submit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915/mst: Hookup DRM DP MST late_register/early_unregister callbacks

[Lyude Paul]

i915 can enable aux device nodes for DP MST by calling
drm_dp_mst_connector_late_register()/drm_dp_mst_connector_early_unregister(),
so let's hook that up.

Cc: Ville Syrjälä 
Cc: Manasi Navare 
Cc: "Lee, Shawn C" 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 22 +++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index d53978ed3c12..bcff2e06ead6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -548,12 +548,30 @@ static int intel_dp_mst_get_ddc_modes(struct 
drm_connector *connector)
return ret;
 }
 
+static int
+intel_dp_mst_connector_late_register(struct drm_connector *connector)
+{
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+
+   return drm_dp_mst_connector_late_register(connector,
+ intel_connector->port);
+}
+
+static void
+intel_dp_mst_connector_early_unregister(struct drm_connector *connector)
+{
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+
+   drm_dp_mst_connector_early_unregister(connector,
+ intel_connector->port);
+}
+
 static const struct drm_connector_funcs intel_dp_mst_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.atomic_get_property = intel_digital_connector_atomic_get_property,
.atomic_set_property = intel_digital_connector_atomic_set_property,
-   .late_register = intel_connector_register,
-   .early_unregister = intel_connector_unregister,
+   .late_register = intel_dp_mst_connector_late_register,
+   .early_unregister = intel_dp_mst_connector_early_unregister,
.destroy = intel_connector_destroy,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
-- 
2.24.1

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

Re: [v2] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings

[Sam Ravnborg]

Hi Krishna

On Mon, Mar 09, 2020 at 03:52:46PM +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsytem(MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for the device tree bindings for the same.
> 
> Signed-off-by: Krishna Manikandan 
Looks good ow - thanks.
Acked-by: Sam Ravnborg 

But you should wait for a review by someone more fluent in this area
too.

Sam
> 
> Changes in v2:
>   - Changed dpu to DPU (Sam Ravnborg)
>   - Fixed indentation issues (Sam Ravnborg)
>   - Added empty line between different properties (Sam Ravnborg)
>   - Replaced reference txt files with  their corresponding
> yaml files (Sam Ravnborg)
>   - Modified the file to use "|" only when it is
> necessary (Sam Ravnborg)
> ---
>  .../bindings/display/msm/dpu-sc7180.yaml   | 261 +++
>  .../bindings/display/msm/dpu-sdm845.yaml   | 259 +++
>  .../bindings/display/msm/dsi-sc7180.yaml   | 362 
> +
>  .../bindings/display/msm/dsi-sdm845.yaml   | 362 
> +
>  4 files changed, 1244 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-sc7180.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-sdm845.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml 
> b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> new file mode 100644
> index 000..2a9efc5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> @@ -0,0 +1,261 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/dpu-sc7180.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Description of Qualcomm Display DPU dt properties.
> +
> +maintainers:
> +  - Krishna Manikandan 
> +
> +description: |
> +  Device tree bindings for MSM Mobile Display Subsytem(MDSS) that 
> encapsulates
> +  sub-blocks like DPU display controller, DSI and DP interfaces etc. Device 
> tree
> +  bindings of MDSS and DPU are mentioned for SC7180 target.
> +
> +properties:
> +  "mdss":
> +type: object
> +description: |
> +  Node containing MDSS that encapsulated sub-blocks like DPU, DSI and DP
> +  interfaces.
> +
> +properties:
> + compatible:
> +   items:
> + - const: qcom,sc7180-mdss
> +
> + reg:
> +   description: Physical base address and length of controller's 
> registers.
> +
> + reg-names:
> +   description: |
> + Names for different register regions defined above. The required 
> region
> + is mentioned below.
> +   items:
> + - const: mdss
> +
> + power-domains:
> +   description: |
> + A power domain consumer specifier according to
> + Documentation/devicetree/bindings/power/power-domain.yaml.
> +
> + clocks:
> +   description: List of clock specifiers for clocks needed by the device.
> +
> + clock-names:
> +   description: |
> + Device clock names in the same order as mentioned in clocks 
> property.
> + The required clocks are mentioned below.
> +   items:
> + - const: iface
> + - const: bus
> + - const: ahb
> + - const: core
> +
> + interrupts:
> +   description: Interrupt signal from MDSS.
> +
> + interrupt-controller:
> +   description: Identifies the node as an interrupt controller.
> +
> + "#interrupt-cells":
> +   description: |
> + Specifies the number of cells needed to encode an interrupt source.
> +   const: 1
> +
> + iommus:
> +   description: Phandle of iommu device node.
> +
> + "#address-cells":
> +   description: |
> + Indicate how many cells (32 bits values) are needed to form the base
> + address part in the reg property.
> +
> + "#size-cells":
> +   description: |
> + Indicate how many cells (32 bits values) are needed to specify the
> + size part in the reg property.
> +
> + ranges:
> +   description: |
> + Parent bus address space is the same as the child bus address space.
> +
> + interconnects :
> +   description: |
> + Interconnect path specifier for MDSS according to
> + Documentation/devicetree/bindings/interconnect/interconnect.txt.
> + Should be 2 paths corresponding to 2 AXI ports.
> +
> + interconnect-names:
> +   description: |
> + MDSS will have 2 port names to differentiate between the
> + 2 interconnect paths defined with interconnect specifier.
> +
> + properties:
> +   description: |
> + The optional properties for MDSS are mentioned below.
> 

Re: [PATCH v4 2/2] drm/panel: add support for rm69299 visionox panel driver

[Sam Ravnborg]

Hi Harigovindan

Thanks for the v4. nice work!

There is one tiny detail to fix.

With this fixed:
Reviewed-by: Sam Ravnborg 

Sam

On Fri, Mar 06, 2020 at 04:06:28PM +0530, Harigovindan P wrote:
> Add support for Visionox panel driver.
> 
> Signed-off-by: Harigovindan P 
> ---
> 
> Changes in v2:
>   - Dropping redundant space in Kconfig(Sam Ravnborg).
>   - Changing structure for include files(Sam Ravnborg).
>   - Removing backlight related code and functions(Sam Ravnborg).
>   - Removing repeated printing of error message(Sam Ravnborg).
>   - Adding drm_connector as an argument for get_modes function.
> Changes in v3:
>   - Adding arguments for drm_panel_init to support against mainline.
> Changes in v4:
>   - Removing error messages from regulator_set_load.
>   - Removing dev struct entry.
>   - Removing checks.
>   - Dropping empty comment lines.
> 
>  drivers/gpu/drm/panel/Kconfig |   8 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  .../gpu/drm/panel/panel-visionox-rm69299.c| 322 ++
>  3 files changed, 331 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-visionox-rm69299.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index ae44ac2ec106..7b696f304a99 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -389,6 +389,14 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
> Say Y here if you want to enable support for Truly NT35597 WQXGA Dual 
> DSI
> Video Mode panel
>  
> +config DRM_PANEL_VISIONOX_RM69299
> + tristate "Visionox RM69299"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + help
> +   Say Y here if you want to enable support for Visionox
> +   RM69299  DSI Video Mode panel.
> +
>  config DRM_PANEL_XINPENG_XPP055C272
>   tristate "Xinpeng XPP055C272 panel driver"
>   depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 7c4d3c581fd4..9f11d067a6b2 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -41,4 +41,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += 
> panel-tpo-td028ttec1.o
>  obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
>  obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
>  obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> +obj-$(CONFIG_DRM_PANEL_VISIONOX_RM69299) += panel-visionox-rm69299.o
>  obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
> diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c 
> b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
> new file mode 100644
> index ..eb15dca15398
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
> @@ -0,0 +1,322 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
Sort alphabetically. Ignore length of line.

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

Re: [PATCH v4 1/2] dt-bindings: display: add visionox rm69299 panel variant

[Sam Ravnborg]

Hi Harigovindan

Thanks for the follow-up. There are still a few things to improve.
See below.

Sam

On Fri, Mar 06, 2020 at 04:06:27PM +0530, Harigovindan P wrote:
> Add bindings for visionox rm69299 panel.
> 
> Signed-off-by: Harigovindan P 
> ---
> 
> Changes in v2:
>   - Removed unwanted properties from description.
>   - Creating source files without execute permissions(Rob Herring).
> Changes in v3:
>   - Changing txt file into yaml
> Changes in v4:
>   - Updating license identifier.
>   - Moving yaml file inside panel directory.
>   - Removing pinctrl entries.
>   - Adding documentation for reset-gpios.
> 
>  .../display/panel/visionox,rm69299.yaml   | 85 +++
>  1 file changed, 85 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml 
> b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
> new file mode 100644
> index ..93cae431207c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
> @@ -0,0 +1,85 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/visionox,rm69299.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Visionox model RM69299 Panels Device Tree Bindings.
> +
> +maintainers:
> + - Harigovindan P 
> +
> +description: |
> + This binding is for display panels using a Visionox RM692999 panel.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +patternProperties:
> +  "^(panel|panel-dsi)@[0-9]$":
> +type: object

This looks wrong. None of the other panels needs to specify
a patternProperties, and neither do we need to do so for this panel.


> +properties:
> +  compatible:
> +const: visionox,rm69299-1080p-display
The compatible is what we use to match this binding.


> +
> +  reg:
> +maxItems: 1
> +
> +  vdda-supply:
> +description:
> +  Phandle of the regulator that provides the vdda supply voltage.
> +
> +  vdd3p3-supply:
> +description:
> +  Phandle of the regulator that provides the vdd3p3 supply voltage.
> +
> +  ports:
> +type: object
> +description:
> +  A node containing DSI input & output port nodes with endpoint
> +  definitions as documented in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt
> +  Documentation/devicetree/bindings/graph.txt

I think you miss as " |" after "description:"
Again, see other panel bindings.


> +properties:
> +  port@0:

Please just use
port: true

port is already documented in panel-common.yaml.

> +type: object
> +description:
> +  DSI input port node.
> +
> +  reset-gpios:
reset-gpios is part of panel-common.
So specify only:
 reset-gpios: true

No description, as it is in panel-common.


> +description:
> +  a GPIO spec for the reset pin.
> +
> +required:
> +  - compatible
> +  - reg
> +  - vdda-supply
> +  - vdd3p3-supply
> +  - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> +- |
> +dsi@ae94000 {
No @ae94000 - this will warn with upcoming dt_binding_check
improvements.

> +panel@0 {
> +compatible = "visionox,rm69299-1080p-display";
> +
> +vdda-supply = <_pp1800_l8c>;
> +vdd3p3-supply = <_pp2800_l18a>;
> +
> +reset-gpios = <_gpio 3 0>;
reg property is required, but missing in the example.


> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@0 {
> +reg = <0>;
> +panel0_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +};
> +};
> +...
> +
> -- 
> 2.25.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/dp_mst: Rewrite and fix bandwidth limit checks

[Mikita Lipski]

On 3/9/20 5:01 PM, Lyude Paul wrote:

Sigh, this is mostly my fault for not giving commit cd82d82cbc04
("drm/dp_mst: Add branch bandwidth validation to MST atomic check")
enough scrutiny during review. The way we're checking bandwidth
limitations here is mostly wrong:

For starters, drm_dp_mst_atomic_check_bw_limit() determines the
pbn_limit of a branch by simply scanning each port on the current branch
device, then uses the last non-zero full_pbn value that it finds. It
then counts the sum of the PBN used on each branch device for that
level, and compares against the full_pbn value it found before.

This is wrong because ports can and will have different PBN limitations
on many hubs, especially since a number of DisplayPort hubs out there
will be clever and only use the smallest link rate required for each
downstream sink - potentially giving every port a different full_pbn
value depending on what link rate it's trained at. This means with our
current code, which max PBN value we end up with is not well defined.

Additionally, we also need to remember when checking bandwidth
limitations that the top-most device in any MST topology is a branch
device, not a port. This means that the first level of a topology
doesn't technically have a full_pbn value that needs to be checked.
Instead, we should assume that so long as our VCPI allocations fit we're
within the bandwidth limitations of the primary MSTB.

We do however, want to check full_pbn on every port including those of
the primary MSTB. However, it's important to keep in mind that this
value represents the minimum link rate /between a port's sink or mstb,
and the mstb itself/. A quick diagram to explain:

 MSTB #1
/   \
   / \
Port #1Port #2
full_pbn for Port #1 → |  | ← full_pbn for Port #2
Sink #1MSTB #2
  |
etc...

Note that in the above diagram, the combined PBN from all VCPI
allocations on said hub should not exceed the full_pbn value of port #2,
and the display configuration on sink #1 should not exceed the full_pbn
value of port #1. However, port #1 and port #2 can otherwise consume as
much bandwidth as they want so long as their VCPI allocations still fit.

And finally - our current bandwidth checking code also makes the mistake
of not checking whether something is an end device or not before trying
to traverse down it.

So, let's fix it by rewriting our bandwidth checking helpers. We split
the function into one part for handling branches which simply adds up
the total PBN on each branch and returns it, and one for checking each
port to ensure we're not going over its PBN limit. Phew.

This should fix regressions seen, where we erroneously reject display
configurations due to thinking they're going over our bandwidth limits
when they're not.

Changes since v1:
* Took an even closer look at how PBN limitations are supposed to be
   handled, and did some experimenting with Sean Paul. Ended up rewriting
   these helpers again, but this time they should actually be correct!
Changes since v2:
* Small indenting fix
* Fix pbn_used check in drm_dp_mst_atomic_check_port_bw_limit()



Thank you for rewriting the bandwidth check helper!

My initial understanding of available_pbn was completely wrong and 
therefore the bandwidth validation was not doing what it intended.
This version is much cleaner and  easier to follow than the initial one, 
since you're separating branch and port validation into 2 different 
functions, and also go down the device topology rather than starting 
from the end nodes. Also the explanation and the diagram help a lot to 
understand how it should have be done initially.


This change makes sense and looks correct to me, therefore:
Reviewed-by: Mikita Lipski 

Thanks,
Mikita



Signed-off-by: Lyude Paul 
Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic 
check")
Cc: Mikita Lipski 
Cc: Sean Paul 
Cc: Hans de Goede 
---
  drivers/gpu/drm/drm_dp_mst_topology.c | 119 --
  1 file changed, 93 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index b81ad444c24f..d2f464bdcfff 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4841,41 +4841,102 @@ static bool 
drm_dp_mst_port_downstream_of_branch(struct drm_dp_mst_port *port,
return false;
  }
  
-static inline

-int drm_dp_mst_atomic_check_bw_limit(struct drm_dp_mst_branch *branch,
-struct drm_dp_mst_topology_state 
*mst_state)
+static int
+drm_dp_mst_atomic_check_port_bw_limit(struct drm_dp_mst_port *port,
+ struct drm_dp_mst_topology_state *state);
+
+static int

Re: [PATCH] drm/panel-simple: Fix dotclock for Ortustech COM37H3M

[Sam Ravnborg]

Hi Nikolaus

Thanks for the detailed explanation.

Applied and pushed to drm-misc-next.

Sam

On Tue, Mar 10, 2020 at 08:43:19AM +0100, H. Nikolaus Schaller wrote:
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
> 
> There are two variants of the COM37H3M panel.
> The older one's COM37H3M05DTC data sheet specifies:
> 
>  MIN  TYP MAX
> CLK frequencyfCLK --   22.426.3 MHz (in VGA mode)
> VSYNC Frequency  fVSYNC   54   60  66   Hz
> VSYNC cycle time tv   --  650  --   H
> HSYNC frequency  fHSYNC   --   39.3--   kHz
> HSYNC cycle time th   --  570  --   CLK
> 
> The newer one's COM37H3M99DTC data sheet says:
> 
>  MIN  TYP MAX
> CLK frequencyfCLK 18   19.827   MHz
> VSYNC Frequency  fVSYNC   54   60  66   Hz
> VSYNC cycle time tv  646  650 700   H
> HSYNC frequency  fHSYNC  --39.050.0 kHz
> HSYNC cycle time th  504  508 630   CLK
> 
> So we choose a parameter set that lies within the specs
> of both variants. We start at .vrefresh = 60,
> choose .htotal = 570 and .vtotal = 650 and end up
> in a clock of 22.230 MHz.
> 
> Reported-by: Ville Syrjala 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index e14c14ac62b5..b4cb23d4898d 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2390,15 +2390,15 @@ static const struct panel_desc ontat_yx700wv03 = {
>  };
>  
>  static const struct drm_display_mode ortustech_com37h3m_mode  = {
> - .clock = 22153,
> + .clock = 22230,
>   .hdisplay = 480,
> - .hsync_start = 480 + 8,
> - .hsync_end = 480 + 8 + 10,
> - .htotal = 480 + 8 + 10 + 10,
> + .hsync_start = 480 + 40,
> + .hsync_end = 480 + 40 + 10,
> + .htotal = 480 + 40 + 10 + 40,
>   .vdisplay = 640,
>   .vsync_start = 640 + 4,
> - .vsync_end = 640 + 4 + 3,
> - .vtotal = 640 + 4 + 3 + 4,
> + .vsync_end = 640 + 4 + 2,
> + .vtotal = 640 + 4 + 2 + 4,
>   .vrefresh = 60,
>   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
>  };
> -- 
> 2.23.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: panel: Set connector type for OrtusTech COM43H4M85ULC panel

[Sam Ravnborg]

Hi Laurent.

On Mon, Mar 09, 2020 at 09:01:27PM +0200, Laurent Pinchart wrote:
> Hi Sam,
> 
> On Mon, Mar 09, 2020 at 08:00:47PM +0100, Sam Ravnborg wrote:
> > On Mon, Mar 09, 2020 at 08:42:10PM +0200, Laurent Pinchart wrote:
> > > The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type
> > > accordingly.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> >
> > Reviewed-by: Sam Ravnborg 
> > 
> > I assume you will apply to drm-misc-next - OK?
> 
> I still haven't got around to using dim :-)
OK.

Applied and pushed to drm-misc-next.

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

Re: [PATCH] drm: panel: Set connector type for OrtusTech COM43H4M85ULC panel

[Sam Ravnborg]

Hi Ville.

> > > 
> > > My lame and simple workflow
> > > 
> > > dim update-branches
> > > # save patch from mutt
> > > cat mbox | dim apply
> 
> Why don't you just pipe the thing into dim straight from mutt?
> That's what I do. Followed by some amount of dim extract-tag
> also piped in from mutt.

Because you did not tell me this was possible :-)
So I just tried '|' dim apply - it worked like wonders.
Thanks!

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

Re: [PATCH] spi: spi-fsl-dspi: fix DMA mapping

[Mark Brown]

On Tue, Mar 10, 2020 at 03:12:45PM +0100, Michael Walle wrote:
> Am 2020-03-10 14:02, schrieb Vladimir Oltean:

> > I'm testing LS1028A with IOMMU_DEFAULT_PASSTHROUGH=y and I didn't have
> > time to change my setup now. I've also sent a v3 to my patch series
> > which is going to conflict with this one, sorry.

> No worries, its easy enough to rebase.

> > I would have picked
> > your patch up with my series but I didn't have the right environment
> > to test it.

> I'll resend a v2 once your series is working.

Since it looks like your series might need another spin anyway I'm
thinking it's sensible to apply this now and you rebase instead?  Cuts
down on the number of pending patches if nothing else (unless the
testing stuff gets sorted out of course).


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

[PATCH v1.1 16/21] drm: mxsfb: Add i.MX7 to the list of supported SoCs in Kconfig

[Laurent Pinchart]

Extend the Kconfig option description by listing the i.MX7 SoCs, as they
are supported by the same driver. Replace the list of SoCs in the short
description with just "(e)LCDIF LCD controller" to avoid expanding it
further in the future as support for more SoCs is added.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/mxsfb/Kconfig | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 0dca8f27169e..0b407338dd46 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -5,7 +5,7 @@ config DRM_MXS
  Choose this option to select drivers for MXS FB devices
 
 config DRM_MXSFB
-   tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller"
+   tristate "i.MX (e)LCDIF LCD controller"
depends on DRM && OF
depends on COMMON_CLK
select DRM_MXS
@@ -14,7 +14,8 @@ config DRM_MXSFB
select DRM_KMS_CMA_HELPER
select DRM_PANEL
help
- Choose this option if you have an i.MX23/i.MX28/i.MX6SX MXSFB
- LCD controller.
+ Choose this option if you have an LCDIF or eLCDIF LCD controller.
+ Those devices are found in various i.MX SoC (including i.MX23,
+ i.MX28, i.MX6SX and i.MX7).
 
  If M is selected the module will be called mxsfb.
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 16/21] drm: mxsfb: Add i.MX7 to the list of supported SoCs in Kconfig

[Laurent Pinchart]

Hi Fabio,

On Tue, Mar 10, 2020 at 01:28:35PM -0300, Fabio Estevam wrote:
> On Mon, Mar 9, 2020 at 4:53 PM Laurent Pinchart wrote:
> 
> >  config DRM_MXSFB
> > -   tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller"
> > +   tristate "i.MX23/i.MX28/i.MX6SX/i.MX7 MXSFB LCD controller"
> 
> Can't we just make it simpler and write: tristate "i.MX eLCDIF
> controller" instead?

It should then be "LCDIF and eLCDIF controllers" or "(e)LCDIF
controller", as the versions prior to i.MX6 were LCDIF and got later
extended to eLCDIF.

> Otherwise this list will get longer each time a new SoC is supported:
> 
> tristate 
> "i.MX23/i.MX28/i.MX6SX/i.MX6SL/i.MX7/i.MX7ULP/i.MX8M/i.MX8MM/i.MX8QXP/i.MX8M
> MXSFB LCD controller"
> 
> and probably more :-)

It's a good point, and I agree. I'll fix this.

-- 
Regards,

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

Re: [PATCH 16/21] drm: mxsfb: Add i.MX7 to the list of supported SoCs in Kconfig

[Fabio Estevam]

Hi Laurent,

On Mon, Mar 9, 2020 at 4:53 PM Laurent Pinchart
 wrote:

>  config DRM_MXSFB
> -   tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller"
> +   tristate "i.MX23/i.MX28/i.MX6SX/i.MX7 MXSFB LCD controller"

Can't we just make it simpler and write: tristate "i.MX eLCDIF
controller" instead?

Otherwise this list will get longer each time a new SoC is supported:

tristate 
"i.MX23/i.MX28/i.MX6SX/i.MX6SL/i.MX7/i.MX7ULP/i.MX8M/i.MX8MM/i.MX8QXP/i.MX8M
MXSFB LCD controller"

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

Re: [PATCH v5 2/2] drm/edid: Add function to parse EDID descriptors for adaptive sync limits

[Ville Syrjälä]

On Mon, Mar 09, 2020 at 02:39:40PM -0700, Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
> This part of the code is stripped out of amdgpu's function
> amdgpu_dm_update_freesync_caps() to make it generic and be used
> across all DRM drivers
> 
> v5:
> * Use the renamed flags
> v4:
> * Use is_display_descriptor() (Ville)
> * Name the monitor range flags (Ville)
> v3:
> * Remove the edid parsing restriction for just DP (Nicholas)
> * Use drm_for_each_detailed_block (Ville)
> * Make the drm_get_adaptive_sync_range function static (Harry, Jani)
> v2:
> * Change vmin and vmax to use u8 (Ville)
> * Dont store pixel clock since that is just a max dotclock
> and not related to VRR mode (Manasi)
> 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Clinton A Taylor 
> Cc: Kazlauskas Nicholas 
> Signed-off-by: Manasi Navare 
> Reviewed-by: Nicholas Kazlauskas 
> ---
>  drivers/gpu/drm/drm_edid.c  | 44 +
>  include/drm/drm_connector.h | 22 +++
>  2 files changed, 66 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ad41764a4ebe..24b76ae58fdd 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>   }
>  }
>  
> +static
> +void get_adaptive_sync_range(struct detailed_timing *timing,
> +  void *info_adaptive_sync)

closure/data/c is what everyone else calls this. Why are we being
different?

> +{
> + struct drm_adaptive_sync_info *adaptive_sync = info_adaptive_sync;
> + const struct detailed_non_pixel *data = >data.other_data;
> + const struct detailed_data_monitor_range *range = >data.range;
> +
> + if (!is_display_descriptor((const u8 *)timing, 
> EDID_DETAIL_MONITOR_RANGE))
> + return;
> +
> + /*
> +  * Check for flag range limits only. If flag == 1 then
> +  * no additional timing information provided.
> +  * Default GTF, GTF Secondary curve and CVT are not
> +  * supported
> +  */
> + if (range->flags != DRM_EDID_RANGE_LIMITS_ONLY_FLAG)
> + return;
> +
> + adaptive_sync->min_vfreq = range->min_vfreq;
> + adaptive_sync->max_vfreq = range->max_vfreq;
> +}
> +
> +static
> +void drm_get_adaptive_sync_range(struct drm_connector *connector,
> +  const struct edid *edid)
> +{
> + struct drm_display_info *info = >display_info;
> +
> + if (!version_greater(edid, 1, 1))
> + return;
> +
> + drm_for_each_detailed_block((u8 *)edid, get_adaptive_sync_range,
> + >adaptive_sync);
> +
> + DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d Hz\n",
> +   info->adaptive_sync.min_vfreq,
> +   info->adaptive_sync.max_vfreq);

This seems a bit misleading since these are just the limits from the
range descriptor. We don't know whether adaptive is supported or not.

> +}
> +
>  /* A connector has no EDID information, so we've got no EDID to compute 
> quirks from. Reset
>   * all of the values which would have been set from EDID
>   */
> @@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector *connector)
>   memset(>hdmi, 0, sizeof(info->hdmi));
>  
>   info->non_desktop = 0;
> + memset(>adaptive_sync, 0, sizeof(info->adaptive_sync));
>  }
>  
>  u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
> *edid)
> @@ -4975,6 +5017,8 @@ u32 drm_add_display_info(struct drm_connector 
> *connector, const struct edid *edi
>  
>   info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
>  
> + drm_get_adaptive_sync_range(connector, edid);
> +
>   DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
>  
>   if (edid->revision < 3)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 0df7a95ca5d9..2b22c0fa42c4 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -254,6 +254,23 @@ enum drm_panel_orientation {
>   DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
>  };
>  
> +/**
> + * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
> + * _display_info
> + *
> + * This struct is used to store a Panel's Adaptive Sync capabilities
> + * as parsed from EDID's detailed monitor range descriptor block.
> + *
> + * @min_vfreq: This is the min supported refresh rate in Hz from
> + * EDID's detailed monitor range.
> + * @max_vfreq: This is the max supported refresh rate in Hz from
> + * EDID's detailed monitor range
> + */
> +struct drm_adaptive_sync_info {
> + u8 min_vfreq;
> + u8 max_vfreq;
> +};
> +
>  /*
>   * This is a consolidated colorimetry 

Re: [PATCH v5 1/2] drm/edid: Name the detailed monitor range flags

[Ville Syrjälä]

On Mon, Mar 09, 2020 at 02:39:39PM -0700, Manasi Navare wrote:
> This patch adds defines for the detailed monitor
> range flags as per the EDID specification.
> 
> v2:
> * Rename the flags with DRM_EDID_ (Jani N)
> 
> Suggested-by: Ville Syrjälä 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Clinton A Taylor 
> Cc: Kazlauskas Nicholas 
> Cc: Jani Nikula 
> Signed-off-by: Manasi Navare 
> Reviewed-by: Nicholas Kazlauskas 
> ---
>  include/drm/drm_edid.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index f0b03d401c27..34b15e3d070c 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -91,6 +91,11 @@ struct detailed_data_string {
>   u8 str[13];
>  } __attribute__((packed));
>  
> +#define DRM_EDID_DEFAULT_GTF_SUPPORT_FLAG   0x00
> +#define DRM_EDID_RANGE_LIMITS_ONLY_FLAG 0x01
> +#define DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG 0x02
> +#define DRM_EDID_CVT_SUPPORT_FLAG   0x04

No indication what flags thse are. Also missing the
actual change to use them in drm_edid.c.

> +
>  struct detailed_data_monitor_range {
>   u8 min_vfreq;
>   u8 max_vfreq;
> -- 
> 2.19.1

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

Re: [RFC][PATCH 5/5] drm/i915/display: Add Nearest-neighbor based integer scaling support

[Ville Syrjälä]

On Tue, Feb 25, 2020 at 12:35:45PM +0530, Pankaj Bharadiya wrote:
> Integer scaling (IS) is a nearest-neighbor upscaling technique that
> simply scales up the existing pixels by an integer
> (i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
> works by filling in the missing color values in the upscaled image
> with that of the coordinate-mapped nearest source pixel value.
> 
> Both IS and NN preserve the clarity of the original image. Integer
> scaling is particularly useful for pixel art games that rely on
> sharp, blocky images to deliver their distinctive look.
> 
> Program the scaler filter coefficients to enable the NN filter if
> scaling filter property is set to DRM_SCALING_FILTER_NEAREST_NEIGHBOR
> and enable integer scaling.
> 
> Bspec: 49247
> 
> Signed-off-by: Pankaj Bharadiya 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 83 +++-
>  drivers/gpu/drm/i915/display/intel_display.h |  2 +
>  drivers/gpu/drm/i915/display/intel_sprite.c  | 20 +++--
>  3 files changed, 97 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b5903ef3c5a0..6d5f59203258 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6237,6 +6237,73 @@ void skl_scaler_disable(const struct intel_crtc_state 
> *old_crtc_state)
>   skl_detach_scaler(crtc, i);
>  }
>  
> +/**
> + *  Theory behind setting nearest-neighbor integer scaling:
> + *
> + *  17 phase of 7 taps requires 119 coefficients in 60 dwords per set.
> + *  The letter represents the filter tap (D is the center tap) and the number
> + *  represents the coefficient set for a phase (0-16).
> + *
> + * ++++
> + * |Index value | Data value coeffient 1 | Data value coeffient 2 |
> + * ++++
> + * |   00h  |  B0|  A0|
> + * ++++
> + * |   01h  |  D0|  C0|
> + * ++++
> + * |   02h  |  F0|  E0|
> + * ++++
> + * |   03h  |  A1|  G0|
> + * ++++
> + * |   04h  |  C1|  B1|
> + * ++++
> + * |   ...  |  ...   |  ...   |
> + * ++++
> + * |   38h  |  B16   |  A16   |
> + * ++++
> + * |   39h  |  D16   |  C16   |
> + * ++++
> + * |   3Ah  |  F16   |  C16   |
> + * ++++
> + * |   3Bh  |Reserved|  G16   |
> + * ++++
> + *
> + *  To enable nearest-neighbor scaling:  program scaler coefficents with
> + *  the center tap (Dxx) values set to 1 and all other values set to 0 as per
> + *  SCALER_COEFFICIENT_FORMAT
> + *
> + */
> +void skl_setup_nearest_neighbor_filter(struct drm_i915_private *dev_priv,
> +   enum pipe pipe, int scaler_id)

skl_scaler_... 

> +{
> +
> + int coeff = 0;
> + int phase = 0;
> + int tap;
> + int val = 0;

Needlessly wide scope for most of these.

> +
> + /*enable the index auto increment.*/
> + intel_de_write_fw(dev_priv, SKL_PS_COEF_INDEX_SET0(pipe, scaler_id),
> +   _PS_COEE_INDEX_AUTO_INC);
> +
> + for (phase = 0; phase < 17; phase++) {
> + for (tap = 0; tap < 7; tap++) {
> + coeff++;

Can be part of the % check.

> + if (tap == 3)
> + val = (phase % 2) ? (0x800) : (0x800 << 16);

Parens overload.

> +
> + if (coeff % 2 == 0) {
> + intel_de_write_fw(dev_priv, 
> SKL_PS_COEF_DATA_SET0(pipe, scaler_id), val);
> + val = 0;

Can drop this val=0 if you move the variable into tight scope and
initialize there.

I was trying to think of a bit more generic way to do this, but couldn't
really think of anything apart from 

Re: [RFC][PATCH 4/5] drm/i915: Introduce scaling filter related registers and bit fields.

[Ville Syrjälä]

On Tue, Feb 25, 2020 at 12:35:44PM +0530, Pankaj Bharadiya wrote:
> Introduce scaler registers and bit fields needed to configure the
> scaling filter in prgrammed mode and configure scaling filter
> coefficients.
> 
> Signed-off-by: Pankaj Bharadiya 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 34923b1c284c..bba4ad3be611 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7289,6 +7289,18 @@ enum {
>  #define _PS_ECC_STAT_2B 0x68AD0
>  #define _PS_ECC_STAT_1C 0x691D0
>  
> +#define _PS_COEF_SET0_INDEX_1A 0x68198
> +#define _PS_COEF_SET0_INDEX_2A 0x68298
> +#define _PS_COEF_SET0_INDEX_1B 0x68998
> +#define _PS_COEF_SET0_INDEX_2B 0x68A98
> +
> +#define _PS_COEF_SET0_DATA_1A 0x6819C
> +#define _PS_COEF_SET0_DATA_2A 0x6829C
> +#define _PS_COEF_SET0_DATA_1B 0x6899C
> +#define _PS_COEF_SET0_DATA_2B 0x68A9C
> +

Sourious whitespace.

> +#define _PS_COEE_INDEX_AUTO_INC (1 << 10)

Wrong indentation (though looks like most scaler register
definitions get that wrong already), and the leading '_' shouldn't
be here at all.

> +
>  #define _ID(id, a, b) _PICK_EVEN(id, a, b)
>  #define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
>   _ID(id, _PS_1A_CTRL, _PS_2A_CTRL),   \
> @@ -7318,6 +7330,14 @@ enum {
>   _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
>   _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
>  
> +#define SKL_PS_COEF_INDEX_SET0(pipe, id)  _MMIO_PIPE(pipe,\
> + _ID(id, _PS_COEF_SET0_INDEX_1A, 
> _PS_COEF_SET0_INDEX_2A), \
> + _ID(id, _PS_COEF_SET0_INDEX_1B, _PS_COEF_SET0_INDEX_2B))
> +
> +#define SKL_PS_COEF_DATA_SET0(pipe, id)  _MMIO_PIPE(pipe, \
> + _ID(id, _PS_COEF_SET0_DATA_1A, _PS_COEF_SET0_DATA_2A), \
> + _ID(id, _PS_COEF_SET0_DATA_1B, _PS_COEF_SET0_DATA_2B))

Please parametrize by 'set' as well.

> +
>  /* legacy palette */
>  #define _LGC_PALETTE_A   0x4a000
>  #define _LGC_PALETTE_B   0x4a800
> -- 
> 2.23.0

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

Re: [RFC][PATCH 3/5] drm/i915: Enable scaling filter for plane and pipe

[Ville Syrjälä]

On Tue, Feb 25, 2020 at 12:35:43PM +0530, Pankaj Bharadiya wrote:
> Attach scaling filter property for crtc and plane and program the
> scaler control register for the selected filter type.
> 
> This is preparatory patch to enable Nearest-neighbor integer scaling.
> 
> Signed-off-by: Pankaj Bharadiya 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 17 +++--
>  drivers/gpu/drm/i915/display/intel_sprite.c  | 12 +++-
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  3 files changed, 27 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3031e64ee518..b5903ef3c5a0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6242,6 +6242,8 @@ static void skl_pfit_enable(const struct 
> intel_crtc_state *crtc_state)
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   enum pipe pipe = crtc->pipe;
> + const struct drm_crtc_state *state = _state->uapi;
> + u32 scaling_filter = PS_FILTER_MEDIUM;
>   const struct intel_crtc_scaler_state *scaler_state =
>   _state->scaler_state;
>  
> @@ -6258,6 +6260,11 @@ static void skl_pfit_enable(const struct 
> intel_crtc_state *crtc_state)
>   pfit_w = (crtc_state->pch_pfit.size >> 16) & 0x;
>   pfit_h = crtc_state->pch_pfit.size & 0x;
>  
> + if (state->scaling_filter ==
> + DRM_SCALING_FILTER_NEAREST_NEIGHBOR) {
> + scaling_filter = PS_FILTER_PROGRAMMED;
> + }

Just make that a function that can be used all over.
skl_scaler_filter(scaling_filter) or something.

> +
>   hscale = (crtc_state->pipe_src_w << 16) / pfit_w;
>   vscale = (crtc_state->pipe_src_h << 16) / pfit_h;
>  
> @@ -6268,8 +6275,10 @@ static void skl_pfit_enable(const struct 
> intel_crtc_state *crtc_state)
>  
>   spin_lock_irqsave(_priv->uncore.lock, irqflags);
>  
> - intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), PS_SCALER_EN 
> |
> -   PS_FILTER_MEDIUM | 
> scaler_state->scalers[id].mode);
> + intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id),
> +   PS_SCALER_EN |
> +   scaling_filter |
> +   scaler_state->scalers[id].mode);
>   intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, id),
> PS_Y_PHASE(0) | 
> PS_UV_RGB_PHASE(uv_rgb_vphase));
>   intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id),
> @@ -16695,6 +16704,10 @@ static int intel_crtc_init(struct drm_i915_private 
> *dev_priv, enum pipe pipe)
>   dev_priv->plane_to_crtc_mapping[i9xx_plane] = crtc;
>   }
>  
> +
> + if (INTEL_GEN(dev_priv) >= 11)

gen >= 10 actually. Even glk seems to have it but bspec says not to
use it on glk. Supposedly not validated.

ilk/snb/ivb pfits also has programmable coefficients actually. So
IMO we should enable this on those as well.

The bigger problem will be how is userspace supposed to use this if it's
a crtc property? Those will not get automagically exposed via xrandr.

> + drm_crtc_enable_scaling_filter(>base);
> +
>   intel_color_init(crtc);
>  
>   drm_WARN_ON(_priv->drm, drm_crtc_index(>base) != crtc->pipe);
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 7abeefe8dce5..fd7b31a21723 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -414,6 +414,12 @@ skl_program_scaler(struct intel_plane *plane,
>   u16 y_hphase, uv_rgb_hphase;
>   u16 y_vphase, uv_rgb_vphase;
>   int hscale, vscale;
> + const struct drm_plane_state *state = _state->uapi;
> + u32 scaling_filter = PS_FILTER_MEDIUM;
> +
> + if (state->scaling_filter == DRM_SCALING_FILTER_NEAREST_NEIGHBOR) {
> + scaling_filter = PS_FILTER_PROGRAMMED;
> + }
>  
>   hscale = drm_rect_calc_hscale(_state->uapi.src,
> _state->uapi.dst,
> @@ -441,7 +447,8 @@ skl_program_scaler(struct intel_plane *plane,
>   }
>  
>   intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, scaler_id),
> -   PS_SCALER_EN | PS_PLANE_SEL(plane->id) | 
> scaler->mode);
> +   scaling_filter | PS_SCALER_EN |
> +   PS_PLANE_SEL(plane->id) | scaler->mode);
>   intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, scaler_id),
> PS_Y_PHASE(y_vphase) | 
> PS_UV_RGB_PHASE(uv_rgb_vphase));
>   intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, scaler_id),
> @@ -3104,6 +3111,9 @@ skl_universal_plane_create(struct 

Re: [RFC][PATCH 1/5] drm: Introduce scaling filter property

[Ville Syrjälä]

On Tue, Feb 25, 2020 at 12:35:41PM +0530, Pankaj Bharadiya wrote:
> Introduce new scaling filter property to allow userspace to select
> the driver's default scaling filter or Nearest-neighbor(NN) filter
> for upscaling operations on crtc/plane.
> 
> Drivers can set up this property for a plane by calling
> drm_plane_enable_scaling_filter() and for a CRTC by calling
> drm_crtc_enable_scaling_filter().
> 
> NN filter works by filling in the missing color values in the upscaled
> image with that of the coordinate-mapped nearest source pixel value.
> 
> NN filter for integer multiple scaling can be particularly useful for
> for pixel art games that rely on sharp, blocky images to deliver their
> distinctive look.
> 
> Signed-off-by: Pankaj Bharadiya 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c |  8 +++
>  drivers/gpu/drm/drm_crtc.c| 16 ++
>  drivers/gpu/drm/drm_mode_config.c | 13 
>  drivers/gpu/drm/drm_plane.c   | 35 +++
>  include/drm/drm_crtc.h| 10 +
>  include/drm/drm_mode_config.h |  6 ++
>  include/drm/drm_plane.h   | 14 +
>  7 files changed, 102 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index a1e5e262bae2..4e3c1f3176e4 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
> *crtc,
>   return ret;
>   } else if (property == config->prop_vrr_enabled) {
>   state->vrr_enabled = val;
> + } else if (property == config->scaling_filter_property) {
> + state->scaling_filter = val;

I think we want a per-plane/per-crtc prop for this. If we start adding
more filters we are surely going to need different sets for different hw
blocks.

>   } else if (property == config->degamma_lut_property) {
>   ret = drm_atomic_replace_property_blob_from_id(dev,
>   >degamma_lut,
> @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>   *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
>   else if (property == config->prop_out_fence_ptr)
>   *val = 0;
> + else if (property == config->scaling_filter_property)
> + *val = state->scaling_filter;
>   else if (crtc->funcs->atomic_get_property)
>   return crtc->funcs->atomic_get_property(crtc, state, property, 
> val);
>   else
> @@ -583,6 +587,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>   sizeof(struct drm_rect),
>   );
>   return ret;
> + } else if (property == config->scaling_filter_property) {
> + state->scaling_filter = val;
>   } else if (plane->funcs->atomic_set_property) {
>   return plane->funcs->atomic_set_property(plane, state,
>   property, val);
> @@ -641,6 +647,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   } else if (property == config->prop_fb_damage_clips) {
>   *val = (state->fb_damage_clips) ?
>   state->fb_damage_clips->base.id : 0;
> + } else if (property == config->scaling_filter_property) {
> + *val = state->scaling_filter;
>   } else if (plane->funcs->atomic_get_property) {
>   return plane->funcs->atomic_get_property(plane, state, 
> property, val);
>   } else {
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 4936e1080e41..1ce7b2ac9eb5 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -748,3 +748,19 @@ int drm_mode_crtc_set_obj_prop(struct drm_mode_object 
> *obj,
>  
>   return ret;
>  }
> +
> +/**
> + * drm_crtc_enable_scaling_filter - Enables crtc scaling filter property.
> + * @crtc: CRTC on which to enable scaling filter property.
> + *
> + * This function lets driver to enable the scaling filter property on a crtc.
> + */
> +void drm_crtc_enable_scaling_filter(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> +
> + drm_object_attach_property(>base,
> +dev->mode_config.scaling_filter_property,
> +0);
> +}
> +EXPORT_SYMBOL(drm_crtc_enable_scaling_filter);
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index 08e6eff6a179..1024a8d1cd5d 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -214,6 +214,11 @@ static const struct drm_prop_enum_list 
> drm_plane_type_enum_list[] = {
>   { DRM_PLANE_TYPE_CURSOR, "Cursor" },
>  };
>  
> +static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
> + { 

Re: [PATCH V3 3/4] backlight: qcom-wled: Add support for WLED5 peripheral in PM8150L

[Daniel Thompson]

On Mon, Mar 09, 2020 at 06:56:01PM +0530, Kiran Gunda wrote:
> Add support for WLED5 peripheral that is present on PM8150L PMICs.
> 
> PM8150L WLED supports the following:
> - Two modulators and each sink can use any of the modulator
> - Multiple CABC selection options
> - Multiple brightness width selection (12 bits to 15 bits)
> 
> Signed-off-by: Kiran Gunda 

Mostly just style comments below...


> ---
>  .../bindings/leds/backlight/qcom-wled.yaml |  39 +++
>  drivers/video/backlight/qcom-wled.c| 336 
> -

Shouldn't the bindings and driver be separate?


>  2 files changed, 374 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml 
> b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
> index d334f81..e0dadc4 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
> +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
> @@ -20,6 +20,7 @@ properties:
> - qcom,pm8941-wled
> - qcom,pmi8998-wled
> - qcom,pm660l-wled
> +   - qcom,pm8150l-wled
>  
>reg:
>  maxItems: 1
> @@ -28,10 +29,23 @@ properties:
>  maxItems: 1
>  description:
>brightness value on boot, value from 0-4095.
> +  For pm8150l this value vary from 0-4095 or 0-32767
> +  depending on the brightness control mode. If CABC is
> +  enabled 0-4095 range is used.

Is this a pm8150l restriction or a WLED5 restriction (will other WLED5
have different ranges)?


>  allOf:
>- $ref: /schemas/types.yaml#/definitions/uint32
>  default: 2048
>  
> +  max-brightness:
> +maxItems: 1
> +description:
> +  Maximum brightness level. Allowed values are,
> +  for pmi8998 it is  0-4095.
> +  For pm8150l, this can be either 4095 or 32767.

Ditto.


> +  If CABC is enabled, this is capped to 4095.
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/uint32
> +
>label:
>  maxItems: 1
>  description:
> @@ -124,6 +138,31 @@ properties:
>value for PM8941 from 1 to 3. Default 2
>For PMI8998 from 1 to 4.
>  
> +  qcom,modulator-sel:
> +maxItems: 1
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/uint32
> +description:
> +  Selects the modulator used for brightness modulation.
> +  Allowed values are,
> +   0 - Modulator A
> +   1 - Modulator B
> +  If not specified, then modulator A will be used by default.
> +  This property is applicable only to WLED5 peripheral.
> +
> +  qcom,cabc-sel:
> +maxItems: 1
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/uint32
> +description:
> +  Selects the CABC pin signal used for brightness modulation.
> +  Allowed values are,
> +  0 - CABC disabled
> +  1 - CABC 1
> +  2 - CABC 2
> +  3 - External signal (e.g. LPG) is used for dimming
> +  This property is applicable only to WLED5 peripheral.
> +
>interrupts:
>  maxItems: 2
>  description:
> diff --git a/drivers/video/backlight/qcom-wled.c 
> b/drivers/video/backlight/qcom-wled.c
> index b73f273..edbbcb2 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -19,6 +19,8 @@
>  #define WLED_DEFAULT_BRIGHTNESS  2048
>  #define WLED_SOFT_START_DLY_US   1
>  #define WLED3_SINK_REG_BRIGHT_MAX0xFFF
> +#define WLED5_SINK_REG_BRIGHT_MAX_12B0xFFF
> +#define WLED5_SINK_REG_BRIGHT_MAX_15B0x7FFF
>  
>  /* WLED3/WLED4 control registers */
>  #define WLED3_CTRL_REG_FAULT_STATUS  0x08
> @@ -40,6 +42,7 @@
>  
>  #define WLED3_CTRL_REG_OVP   0x4d
>  #define  WLED3_CTRL_REG_OVP_MASK GENMASK(1, 0)
> +#define  WLED5_CTRL_REG_OVP_MASK GENMASK(3, 0)
>  
>  #define WLED3_CTRL_REG_ILIMIT0x4e
>  #define  WLED3_CTRL_REG_ILIMIT_MASK  GENMASK(2, 0)
> @@ -101,6 +104,40 @@
>  
>  #define WLED4_SINK_REG_BRIGHT(n) (0x57 + (n * 0x10))
>  
> +/* WLED5 specific sink registers */
> +#define WLED5_SINK_REG_MOD_A_EN  0x50
> +#define WLED5_SINK_REG_MOD_B_EN  0x60
> +#define  WLED5_SINK_REG_MOD_EN_MASK  BIT(7)
> +
> +#define WLED5_SINK_REG_MOD_A_SRC_SEL 0x51
> +#define WLED5_SINK_REG_MOD_B_SRC_SEL 0x61
> +#define  WLED5_SINK_REG_MOD_SRC_SEL_HIGH 0
> +#define  WLED5_SINK_REG_MOD_SRC_SEL_EXT  0x03
> +#define  WLED5_SINK_REG_MOD_SRC_SEL_MASK GENMASK(1, 0)
> +
> +#define WLED5_SINK_REG_MOD_A_BRIGHTNESS_WIDTH_SEL0x52
> +#define WLED5_SINK_REG_MOD_B_BRIGHTNESS_WIDTH_SEL0x62
> +#define  

Re: [PATCH v2 06/17] drm/arm: make hdlcd_debugfs_init() return 0

[Liviu Dudau]

On Tue, Mar 10, 2020 at 04:31:10PM +0300, Wambui Karuga wrote:
> Since commit 987d65d01356 (drm: debugfs: make
> drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
> fails and should return void. Therefore, remove its use as the
> return value of hdlcd_debugfs_init() and have the latter function return
> 0 directly.
> 
> v2: make hdlcd_debugfs_init() return 0 instead of void to ensure that
> each patch compiles individually.
> 
> References: 
> https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
> Signed-off-by: Wambui Karuga 

Acked-by: Liviu Dudau 

Best regards,
Liviu

> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 2e053815b54a..bd0ad6f46a97 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -226,8 +226,10 @@ static struct drm_info_list hdlcd_debugfs_list[] = {
>  
>  static int hdlcd_debugfs_init(struct drm_minor *minor)
>  {
> - return drm_debugfs_create_files(hdlcd_debugfs_list,
> - ARRAY_SIZE(hdlcd_debugfs_list), minor->debugfs_root, minor);
> + drm_debugfs_create_files(hdlcd_debugfs_list,
> +  ARRAY_SIZE(hdlcd_debugfs_list),
> +  minor->debugfs_root, minor);
> + return 0;
>  }
>  #endif
>  
> -- 
> 2.25.1
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] drm/dp_mst: Use full_pbn instead of available_pbn for bandwidth checks

[Mikita Lipski]

On 3/6/20 6:46 PM, Lyude Paul wrote:

DisplayPort specifications are fun. For a while, it's been really
unclear to us what available_pbn actually does. There's a somewhat vague
explanation in the DisplayPort spec (starting from 1.2) that partially
explains it:

   The minimum payload bandwidth number supported by the path. Each node
   updates this number with its available payload bandwidth number if its
   payload bandwidth number is less than that in the Message Transaction
   reply.

So, it sounds like available_pbn represents the smallest link rate in
use between the source and the branch device. Cool, so full_pbn is just
the highest possible PBN that the branch device supports right?

Well, we assumed that for quite a while until Sean Paul noticed that on
some MST hubs, available_pbn will actually get set to 0 whenever there's
any active payloads on the respective branch device. This caused quite a
bit of confusion since clearing the payload ID table would end up fixing
the available_pbn value.

So, we just went with that until commit cd82d82cbc04 ("drm/dp_mst: Add
branch bandwidth validation to MST atomic check") started breaking
people's setups due to us getting erroneous available_pbn values. So, we
did some more digging and got confused until we finally looked at the
definition for full_pbn:

   The bandwidth of the link at the trained link rate and lane count
   between the DP Source device and the DP Sink device with no time slots
   allocated to VC Payloads, represented as a Payload Bandwidth Number. As
   with the Available_Payload_Bandwidth_Number, this number is determined
   by the link with the lowest lane count and link rate.

That's what we get for not reading specs closely enough, hehe. So, since
full_pbn is definitely what we want for doing bandwidth restriction
checks - let's start using that instead and ignore available_pbn
entirely.




Thank you for the fix and a very detailed explanation.
I was really confused by available_pbn and why it wouldn't get updated 
and was searching for the solution in wrong places. But I'm glad you 
were able to identify the solution.
I still think the port should have an available_pbn value so it could be 
updated when driver parses RESOURCE_STATUS_NOTIFY and 
ENUM_PATH_RESOURCES messages.

With that being said it is a great find. Thanks.

Reviewed-by: Mikita Lipski 


Signed-off-by: Lyude Paul 
Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic 
check")
Cc: Mikita Lipski 
Cc: Hans de Goede 
Cc: Sean Paul 
---
  drivers/gpu/drm/drm_dp_mst_topology.c | 15 +++
  include/drm/drm_dp_mst_helper.h   |  4 ++--
  2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6714d8a5c558..79ebb871230b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2306,7 +2306,7 @@ drm_dp_mst_handle_link_address_port(struct 
drm_dp_mst_branch *mstb,
port);
}
} else {
-   port->available_pbn = 0;
+   port->full_pbn = 0;
}
}
  
@@ -2401,7 +2401,7 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch *mstb,

if (port->ddps) {
dowork = true;
} else {
-   port->available_pbn = 0;
+   port->full_pbn = 0;
}
}
  
@@ -2553,7 +2553,7 @@ static int drm_dp_check_and_send_link_address(struct drm_dp_mst_topology_mgr *mg

if (port->input || !port->ddps)
continue;
  
-		if (!port->available_pbn) {

+   if (!port->full_pbn) {
drm_modeset_lock(>base.lock, NULL);
drm_dp_send_enum_path_resources(mgr, mstb, port);
drm_modeset_unlock(>base.lock);
@@ -2999,8 +2999,7 @@ drm_dp_send_enum_path_resources(struct 
drm_dp_mst_topology_mgr *mgr,
  path_res->port_number,
  path_res->full_payload_bw_number,
  path_res->avail_payload_bw_number);
-   port->available_pbn =
-   path_res->avail_payload_bw_number;
+   port->full_pbn = path_res->full_payload_bw_number;
port->fec_capable = path_res->fec_capable;
}
}
@@ -3585,7 +3584,7 @@ drm_dp_mst_topology_mgr_invalidate_mstb(struct 
drm_dp_mst_branch *mstb)
  
  	list_for_each_entry(port, >ports, next) {

/* The PBN for each port will also need to be re-probed */
-   port->available_pbn = 0;
+   port->full_pbn = 0;
  
  		if (port->mstb)

drm_dp_mst_topology_mgr_invalidate_mstb(port->mstb);

Re: [PATCH V3 2/4] backlight: qcom-wled: Add callback functions

[Daniel Thompson]

On Mon, Mar 09, 2020 at 06:56:00PM +0530, Kiran Gunda wrote:
> Add cabc_config, sync_toggle, wled_ovp_fault_status and wled_ovp_delay
> callback functions to prepare the driver for adding WLED5 support.
> 
> Signed-off-by: Kiran Gunda 

Overall this code would a lot easier to review if
> ---
>  drivers/video/backlight/qcom-wled.c | 196 
> +++-
>  1 file changed, 126 insertions(+), 70 deletions(-)
> 
> diff --git a/drivers/video/backlight/qcom-wled.c 
> b/drivers/video/backlight/qcom-wled.c
> index 3d276b3..b73f273 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -128,6 +128,7 @@ struct wled_config {
>   bool cs_out_en;
>   bool ext_gen;
>   bool cabc;
> + bool en_cabc;

Does this ever get set to true?

>   bool external_pfet;
>   bool auto_detection_enabled;
>  };
> @@ -147,14 +148,20 @@ struct wled {
>   u32 max_brightness;
>   u32 short_count;
>   u32 auto_detect_count;
> + u32 version;
>   bool disabled_by_short;
>   bool has_short_detect;
> + bool cabc_disabled;
>   int short_irq;
>   int ovp_irq;
>  
>   struct wled_config cfg;
>   struct delayed_work ovp_work;
>   int (*wled_set_brightness)(struct wled *wled, u16 brightness);
> + int (*cabc_config)(struct wled *wled, bool enable);
> + int (*wled_sync_toggle)(struct wled *wled);
> + int (*wled_ovp_fault_status)(struct wled *wled, bool *fault_set);
> + int (*wled_ovp_delay)(struct wled *wled);

Let's get some doc comments explaining what these callbacks do (and
which versions they apply to).

cabc_config() in particular appears to have a very odd interface for
wled4.  It looks like it relies on being initially called with enable
set a particular way and prevents itself from acting again. Therefore if
the comment you end up writing doesn't sound "right" then please also
fix the API!

Finally, why is everything except cabc_config() prefixed with wled?


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

Re: [PATCH V3 1/4] backlight: qcom-wled: convert the wled bindings to .yaml format

[Daniel Thompson]

On Mon, Mar 09, 2020 at 06:55:59PM +0530, Kiran Gunda wrote:
> Convert the qcom-wled bindings from .txt to .yaml format.
> 
> Signed-off-by: Kiran Gunda 

Acked-by: Daniel Thompson 


> ---
>  .../bindings/leds/backlight/qcom-wled.txt  | 154 -
>  .../bindings/leds/backlight/qcom-wled.yaml | 184 
> +
>  2 files changed, 184 insertions(+), 154 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
> 
> diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
> b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> deleted file mode 100644
> index c06863b..000
> --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> +++ /dev/null
> @@ -1,154 +0,0 @@
> -Binding for Qualcomm Technologies, Inc. WLED driver
> -
> -WLED (White Light Emitting Diode) driver is used for controlling display
> -backlight that is part of PMIC on Qualcomm Technologies, Inc. reference
> -platforms. The PMIC is connected to the host processor via SPMI bus.
> -
> -- compatible
> - Usage:required
> - Value type:   
> - Definition:   should be one of:
> - "qcom,pm8941-wled"
> - "qcom,pmi8998-wled"
> - "qcom,pm660l-wled"
> -
> -- reg
> - Usage:required
> - Value type:   
> - Definition:   Base address of the WLED modules.
> -
> -- default-brightness
> - Usage:optional
> - Value type:   
> - Definition:   brightness value on boot, value from: 0-4095.
> -   Default: 2048
> -
> -- label
> - Usage:required
> - Value type:   
> - Definition:   The name of the backlight device
> -
> -- qcom,cs-out
> - Usage:optional
> - Value type:   
> - Definition:   enable current sink output.
> -   This property is supported only for PM8941.
> -
> -- qcom,cabc
> - Usage:optional
> - Value type:   
> - Definition:   enable content adaptive backlight control.
> -
> -- qcom,ext-gen
> - Usage:optional
> - Value type:   
> - Definition:   use externally generated modulator signal to dim.
> -   This property is supported only for PM8941.
> -
> -- qcom,current-limit
> - Usage:optional
> - Value type:   
> - Definition:   mA; per-string current limit; value from 0 to 25 with
> -   1 mA step. Default 20 mA.
> -   This property is supported only for pm8941.
> -
> -- qcom,current-limit-microamp
> - Usage:optional
> - Value type:   
> - Definition:   uA; per-string current limit; value from 0 to 3 with
> -   2500 uA step. Default 25 mA.
> -
> -- qcom,current-boost-limit
> - Usage:optional
> - Value type:   
> - Definition:   mA; boost current limit.
> -   For pm8941: one of: 105, 385, 525, 805, 980, 1260, 1400,
> -   1680. Default: 805 mA.
> -   For pmi8998: one of: 105, 280, 450, 620, 970, 1150, 1300,
> -   1500. Default: 970 mA.
> -
> -- qcom,switching-freq
> - Usage:optional
> - Value type:   
> -  Definition:   kHz; switching frequency; one of: 600, 640, 685, 738,
> -800, 872, 960, 1066, 1200, 1371, 1600, 1920, 2400, 3200,
> -4800, 9600.
> -Default: for pm8941: 1600 kHz
> - for pmi8998: 800 kHz
> -
> -- qcom,ovp
> - Usage:optional
> - Value type:   
> - Definition:   V; Over-voltage protection limit; one of:
> -   27, 29, 32, 35. Default: 29V
> -   This property is supported only for PM8941.
> -
> -- qcom,ovp-millivolt
> - Usage:optional
> - Value type:   
> - Definition:   mV; Over-voltage protection limit;
> -   For pmi8998: one of 18100, 19600, 29600, 31100.
> -   Default 29600 mV.
> -   If this property is not specified for PM8941, it
> -   falls back to "qcom,ovp" property.
> -
> -- qcom,num-strings
> - Usage:optional
> - Value type:   
> - Definition:   #; number of led strings attached;
> -   value: For PM8941 from 1 to 3. Default: 2
> -  For PMI8998 from 1 to 4.
> -
> -- interrupts
> - Usage:optional
> - Value type:   
> - Definition:   Interrupts associated with WLED. This should be
> -   "short" and "ovp" interrupts. Interrupts can be
> -   specified as per the encoding listed under
> -   Documentation/devicetree/bindings/spmi/
> -   qcom,spmi-pmic-arb.txt.
> -
> -- interrupt-names
> - Usage:optional
> - Value 

Re: [PATCH v7 12/13] backlight: pwm_bl: Use 64-bit division macros for period and duty cycle

[Daniel Thompson]

On Mon, Mar 09, 2020 at 12:35:15PM -0700, Guru Das Srinagesh wrote:
> Because period and duty cycle are defined in the PWM framework structs
> as ints with units of nanoseconds, the maximum time duration that can be
> set is limited to ~2.147 seconds. Redefining them as u64 values will
> enable larger time durations to be set.
> 
> As a first step, prepare drivers to handle the switch to u64 period and
> duty_cycle by replacing division operations involving pwm period and duty 
> cycle
> with their 64-bit equivalents as appropriate. The actual switch to u64 period
> and duty_cycle follows as a separate patch.
> 
> Where the dividend is 64-bit but the divisor is 32-bit, use *_ULL
> macros:
> - DIV_ROUND_UP_ULL
> - DIV_ROUND_CLOSEST_ULL
> - div_u64
> 
> Where the divisor is 64-bit (dividend may be 32-bit or 64-bit), use
> DIV64_* macros:
> - DIV64_U64_ROUND_CLOSEST
> - div64_u64

This patch looks like it is a tiny change to get the pwm_backlight to
perform 64-bit division. Most of the above text is completely irrelevant
to the change contained in this patch. No need to justify the change in
the PWM structures here since that can go in the patch that changes
those structures.  Just describe what this patch does, perhaps something
like the following:

The PWM API will shortly switch the state.period and
state.duty_cycle fields to 64-bit values. Make pwm_bl
ready for this transition by adopting 64-bit division
macros.

Also please copy the backlight maintainers into the covering letter. It
is useful to place patches like this into context.


Daniel.

 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: linux-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> 
> Signed-off-by: Guru Das Srinagesh 
> ---
>  drivers/video/backlight/pwm_bl.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/video/backlight/pwm_bl.c 
> b/drivers/video/backlight/pwm_bl.c
> index efb4efc..3e5dbcf 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device 
> *pdev)
>   pb->scale = data->max_brightness;
>   }
>  
> - pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
> + pb->lth_brightness = data->lth_brightness * (div_u64(state.period,
> + pb->scale));
>  
>   props.type = BACKLIGHT_RAW;
>   props.max_brightness = data->max_brightness;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/17] drm: subsytem-wide debugfs functions refactor

[Greg KH]

On Tue, Mar 10, 2020 at 04:31:04PM +0300, Wambui Karuga wrote:
> This series includes work on various debugfs functions both in drm/core
> and across various drivers in the subsystem.
> Since commit 987d65d01356 (drm: debugfs: make drm_debugfs_create_files()
> never fail), drm_debugfs_create_files() does not fail and only returns
> zero. This series therefore removes the left over error handling and
> checks for its return value across drm drivers.
> 
> As a result of these changes, most drm_debugfs functions are converted
> to return void in this series. This also enables the
> drm_driver, debugfs_init() hook to be changed to return void. 
> 
> v2: individual driver patches have been converted to have debugfs
> functions return 0 instead of void to prevent breaking individual driver
> builds.
> The last patch then converts the .debugfs_hook() and its users across
> all drivers to return void.

This looks much better to me, nice job:

Reviewed-by: Greg Kroah-Hartman 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 00/22] Move media documentation files

[Mauro Carvalho Chehab]

That's a second version of a patch series with moves the media documents
to better places.

The first version was actually a RFC. This one is more complete. Yet,
my plan is to merge it only at the media trees only after the end of the
next merge window.

I'm preparing several patches on the top of this series, with are updating
old documents that were at the driver-specific part of the documentation.

Mauro Carvalho Chehab (22):
  media: docs: avermedia.rst: mark a table as such
  media: docs: move soc-camera.rst to staging
  media: docs: split cpia2.rst on two files
  media: docs: split ci.rst into uAPI and user guide docs
  media: docs: split meye.rst into admin and uAPI docs
  media: docs: split vimc.rst into devel and admin parts
  media: docs: split development info from bttv.rst
  media: docs: split development info from cx88.rst
  media: docs: split cx2341x.rst into different audiences
  media: docs: cx18-streams.c: fix broken references to docs
  media: docs: split uAPI info from davinci-vpbe.rst
  media: docs: split uAPI info from fimc.rst
  media: docs: split uAPI info from saa7134-devel.rst
  media: docs: split uAPI info from omap3isp.rst
  media: docs: split uAPI info from imx.rst
  media: docs: move uAPI book to userspace-api/media
  media: docs: kAPI docs: move them to driver-api
  media: docs: move fourcc file to the uAPI document
  media: docs: move user-facing docs to the admin guide
  media: docs: move driver-specific info to driver-api
  media: docs: add an uAPI chapter for driver-specific stuff
  media: docs: get rid of Documentation/media/

 .../ABI/testing/debugfs-cec-error-inj |   2 +-
 Documentation/Makefile|  10 +-
 Documentation/admin-guide/index.rst   |   1 +
 .../admin-guide/kernel-parameters.txt |   4 +-
 .../media}/au0828-cardlist.rst|   0
 .../media}/avermedia.rst  |   4 +
 .../media}/bt8xx.rst  |   8 +-
 .../media}/bttv-cardlist.rst  |   0
 .../media}/bttv.rst   | 120 
 .../media}/cafe_ccic.rst  |   0
 .../media}/cardlist.rst   |   0
 .../media}/cards.rst  |   0
 Documentation/admin-guide/media/ci.rst|  77 
 .../media}/cpia2.rst  |  46 -
 .../media}/cx23885-cardlist.rst   |   0
 .../media}/cx88-cardlist.rst  |   0
 Documentation/admin-guide/media/cx88.rst  |  58 ++
 .../media}/davinci-vpbe.rst   |  42 +---
 .../media}/em28xx-cardlist.rst|   0
 .../dvb-drivers => admin-guide/media}/faq.rst |   0
 .../media}/fimc.rst   |  22 +--
 .../media}/gspca-cardlist.rst |   0
 .../v4l-drivers => admin-guide/media}/imx.rst |  88 +
 .../media}/imx7.rst   |   0
 Documentation/admin-guide/media/index.rst | 104 ++
 .../media}/intro.rst  |   0
 .../media}/ipu3.rst   |   0
 .../media}/ipu3_rcb.svg   |   0
 .../media}/ivtv-cardlist.rst  |   0
 .../media}/ivtv.rst   |   0
 .../media}/lmedm04.rst|   0
 .../media}/meye.rst   |  41 
 Documentation/admin-guide/media/omap3isp.rst  |  92 +
 .../media}/omap4_camera.rst   |   0
 .../media}/opera-firmware.rst |   0
 .../media}/philips.rst|   0
 .../media}/pulse8-cec.rst |   0
 .../media}/qcom_camss.rst |   0
 .../media}/qcom_camss_8x96_graph.dot  |   0
 .../media}/qcom_camss_graph.dot   |   0
 .../media}/rcar-fdp1.rst  |   0
 .../media}/saa7134-cardlist.rst   |   0
 Documentation/admin-guide/media/saa7134.rst   |  61 ++
 .../media}/saa7164-cardlist.rst   |   0
 .../media}/si470x.rst |   0
 .../media}/si4713.rst |   0
 .../media}/si476x.rst |   0
 .../media}/technisat.rst  |   0
 .../media}/tm6000-cardlist.rst|   0
 .../media}/ttusb-dec.rst  |   0
 .../media}/tuner-cardlist.rst |   0
 .../media}/udev.rst   |   0
 .../media}/usbvision-cardlist.rst |   0
 .../media}/v4l-with-ir.rst|   0
 .../media}/vimc.dot   |   0
 .../media}/vimc.rst   |  11 --
 .../media}/vivid.rst  |   0
 .../media}/zr364xx.rst|   0
 Documentation/doc-guide/parse-headers.rst |   2 +-
 Documentation/driver-api/index.rst|   1 +
 .../kapi => driver-api/media}/cec-core.rst|   0
 .../{media/kapi => driver-api/media}/csi2.rst |   0
 

[PATCH 5.5 144/189] drm: kirin: Revert "Fix for hikey620 display offset problem"

[Greg Kroah-Hartman]

From: John Stultz 

commit 1b79cfd99ff5127e6a143767b51694a527b3ea38 upstream.

This reverts commit ff57c6513820efe945b61863cf4a51b79f18b592.

With the commit ff57c6513820 ("drm: kirin: Fix for hikey620
display offset problem") we added support for handling LDI
overflows by resetting the hardware.

However, its been observed that when we do hit the LDI overflow
condition, the irq seems to be screaming, and we do nothing but
stream:
  [drm:ade_irq_handler [kirin_drm]] *ERROR* LDI underflow!
over and over to the screen

I've tried a few appraoches to avoid this, but none has yet
been successful and the cure here is worse then the original
disease, so revert this for now.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: Sam Ravnborg 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Fixes: ff57c6513820 ("drm: kirin: Fix for hikey620 display offset problem")
Signed-off-by: John Stultz 
Acked-by: Xinliang Liu 
Signed-off-by: Xinliang Liu 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20200303163228.52741-1-john.stu...@linaro.org
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h |1 -
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |   20 
 2 files changed, 21 deletions(-)

--- a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
@@ -83,7 +83,6 @@
 #define VSIZE_OFST 20
 #define LDI_INT_EN 0x741C
 #define FRAME_END_INT_EN_OFST  1
-#define UNDERFLOW_INT_EN_OFST  2
 #define LDI_CTRL   0x7420
 #define BPP_OFST   3
 #define DATA_GATE_EN   BIT(2)
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -46,7 +46,6 @@ struct ade_hw_ctx {
struct clk *media_noc_clk;
struct clk *ade_pix_clk;
struct reset_control *reset;
-   struct work_struct display_reset_wq;
bool power_on;
int irq;
 
@@ -136,7 +135,6 @@ static void ade_init(struct ade_hw_ctx *
 */
ade_update_bits(base + ADE_CTRL, FRM_END_START_OFST,
FRM_END_START_MASK, REG_EFFECTIVE_IN_ADEEN_FRMEND);
-   ade_update_bits(base + LDI_INT_EN, UNDERFLOW_INT_EN_OFST, MASK(1), 1);
 }
 
 static bool ade_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -304,17 +302,6 @@ static void ade_crtc_disable_vblank(stru
MASK(1), 0);
 }
 
-static void drm_underflow_wq(struct work_struct *work)
-{
-   struct ade_hw_ctx *ctx = container_of(work, struct ade_hw_ctx,
- display_reset_wq);
-   struct drm_device *drm_dev = ctx->crtc->dev;
-   struct drm_atomic_state *state;
-
-   state = drm_atomic_helper_suspend(drm_dev);
-   drm_atomic_helper_resume(drm_dev, state);
-}
-
 static irqreturn_t ade_irq_handler(int irq, void *data)
 {
struct ade_hw_ctx *ctx = data;
@@ -331,12 +318,6 @@ static irqreturn_t ade_irq_handler(int i
MASK(1), 1);
drm_crtc_handle_vblank(crtc);
}
-   if (status & BIT(UNDERFLOW_INT_EN_OFST)) {
-   ade_update_bits(base + LDI_INT_CLR, UNDERFLOW_INT_EN_OFST,
-   MASK(1), 1);
-   DRM_ERROR("LDI underflow!");
-   schedule_work(>display_reset_wq);
-   }
 
return IRQ_HANDLED;
 }
@@ -919,7 +900,6 @@ static void *ade_hw_ctx_alloc(struct pla
if (ret)
return ERR_PTR(-EIO);
 
-   INIT_WORK(>display_reset_wq, drm_underflow_wq);
ctx->crtc = crtc;
 
return ctx;


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