Re: [PATCH 1/2] dma-fence: Flag when a fence-array is using signal-on-any

[Christian König]

Am 17.02.2017 um 19:35 schrieb Chris Wilson:

Indicate that the fence array will be signaled on the first completion
(signal-on-any mode) as opposed to waiting for all to be signaled.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Daniel Vetter 
Cc: "Christian König" 


Reviewed-by: Christian König 


---
  drivers/dma-buf/dma-fence-array.c | 3 +++
  include/linux/dma-fence-array.h   | 4 
  2 files changed, 7 insertions(+)

diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 67eb7c8fb88c..8c48402a2daa 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -137,6 +137,9 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
dma_fence_init(>base, _fence_array_ops, >lock,
   context, seqno);
  
+	if (num_fences > 1 && signal_on_any)

+   __set_bit(DMA_FENCE_ARRAY_SIGNAL_ANY, >base.flags);
+
array->num_fences = num_fences;
atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 5900945f962d..4270d33d05b3 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -49,6 +49,10 @@ struct dma_fence_array {
struct dma_fence **fences;
  };
  
+enum {

+   DMA_FENCE_ARRAY_SIGNAL_ANY = DMA_FENCE_FLAG_USER_BITS,
+};
+
  extern const struct dma_fence_ops dma_fence_array_ops;
  
  /**



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

[Bug 99843] Geometry Shader - Incorrect Output

[bugzilla-daemon]

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

--- Comment #8 from d...@jerber.co.uk ---
The hardware is Radeon HD 4890.

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

[PATCH trivial 3/4] drm/amd: Spelling s/SDMA_WRTIE_SUB_OPCODE_TILED/SDMA_WRITE_SUB_OPCODE_TILED/

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven 
Cc: Alex Deucher 
Cc: Christian König 
Cc: dri-devel@lists.freedesktop.orgamd-...@lists.freedesktop.org
---
 drivers/gpu/drm/amd/amdgpu/cikd.h | 2 +-
 drivers/gpu/drm/radeon/cikd.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/cikd.h 
b/drivers/gpu/drm/amd/amdgpu/cikd.h
index 6cbd913fd12ed6f9..6a9e38a3d2a0bbee 100644
--- a/drivers/gpu/drm/amd/amdgpu/cikd.h
+++ b/drivers/gpu/drm/amd/amdgpu/cikd.h
@@ -502,7 +502,7 @@
 #   define SDMA_COPY_SUB_OPCODE_T2T_SUB_WINDOW6
 #defineSDMA_OPCODE_WRITE 2
 #   define SDMA_WRITE_SUB_OPCODE_LINEAR   0
-#   define SDMA_WRTIE_SUB_OPCODE_TILED1
+#   define SDMA_WRITE_SUB_OPCODE_TILED1
 #defineSDMA_OPCODE_INDIRECT_BUFFER   4
 #defineSDMA_OPCODE_FENCE 5
 #defineSDMA_OPCODE_TRAP  6
diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
index 48db93577c1dacad..e21015475ed52f31 100644
--- a/drivers/gpu/drm/radeon/cikd.h
+++ b/drivers/gpu/drm/radeon/cikd.h
@@ -2016,7 +2016,7 @@
 #   define SDMA_COPY_SUB_OPCODE_T2T_SUB_WINDOW6
 #defineSDMA_OPCODE_WRITE 2
 #   define SDMA_WRITE_SUB_OPCODE_LINEAR   0
-#   define SDMA_WRTIE_SUB_OPCODE_TILED1
+#   define SDMA_WRITE_SUB_OPCODE_TILED1
 #defineSDMA_OPCODE_INDIRECT_BUFFER   4
 #defineSDMA_OPCODE_FENCE 5
 #defineSDMA_OPCODE_TRAP  6
-- 
1.9.1

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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Alexandre Belloni]

On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote:
> > The device tree is a representation of the hardware itself. The state
> > of the driver support doesn't change the hardware you're running on,
> > just like your BIOS/UEFI on x86 won't change the device it reports to
> > Linux based on whether it has a driver for it.
> Like Emil already said, the new bindings and the DT entries are solely
> introduced to support a proprietary out-of-tree module.
> 

Because device tree describes the hardware, the added binding doesn't
support any particular module. The eventually upstreamed drvier will
share the same bindings.

> The current workflow when introducing new DT entries is the following:
> - upstream a driver that uses the entries
> - THEN add the new entries
> 

Exactly not, if you do that, checkpatch will complain loudly. Because
you must not add a driver using bindings that are not documented first.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 17/35] drivers/gpu: Convert remaining uses of pr_warning to pr_warn

[Edward O'Callaghan]

On 02/18/2017 01:22 AM, Christian König wrote:
> Am 17.02.2017 um 08:11 schrieb Joe Perches:
>> To enable eventual removal of pr_warning
>>
>> This makes pr_warn use consistent for drivers/gpu
>>
>> Prior to this patch, there were 15 uses of pr_warning and
>> 20 uses of pr_warn in drivers/gpu
>>
>> Signed-off-by: Joe Perches 
> 
> Acked-by: Christian König .

Reviewed-by: Edward O'Callaghan 

> 
>> ---
>>   drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c |  2 +-
>>   drivers/gpu/drm/amd/powerplay/inc/pp_debug.h |  2 +-
>>   drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c  |  4 ++--
>>   drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c   | 14
>> +++---
>>   drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c |  4 ++--
>>   drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c |  4 ++--
>>   6 files changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> index b1de9e8ccdbc..83266408634e 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> @@ -1535,7 +1535,7 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
>> *hwmgr)
>>   if (vddc >= 2000 || vddc == 0)
>>   return -EINVAL;
>>   } else {
>> -pr_warning("failed to retrieving EVV voltage!\n");
>> +pr_warn("failed to retrieving EVV voltage!\n");
>>   continue;
>>   }
>>   diff --git a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> index 072880130cfb..f3f9ebb631a5 100644
>> --- a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> +++ b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> @@ -37,7 +37,7 @@
>>   #define PP_ASSERT_WITH_CODE(cond, msg, code)\
>>   do {\
>>   if (!(cond)) {\
>> -pr_warning("%s\n", msg);\
>> +pr_warn("%s\n", msg);\
>>   code;\
>>   }\
>>   } while (0)
>> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> index 0f7a77b7312e..5450f5ef8e89 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> @@ -2131,7 +2131,7 @@ uint32_t fiji_get_offsetof(uint32_t type,
>> uint32_t member)
>>   return offsetof(SMU73_Discrete_DpmTable,
>> LowSclkInterruptThreshold);
>>   }
>>   }
>> -pr_warning("can't get the offset of type %x member %x\n", type,
>> member);
>> +pr_warn("can't get the offset of type %x member %x\n", type,
>> member);
>>   return 0;
>>   }
>>   @@ -2156,7 +2156,7 @@ uint32_t fiji_get_mac_definition(uint32_t value)
>>   return SMU73_MAX_LEVELS_MVDD;
>>   }
>>   -pr_warning("can't get the mac of %x\n", value);
>> +pr_warn("can't get the mac of %x\n", value);
>>   return 0;
>>   }
>>   diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> index ad82161df831..51adf04ab4b3 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> @@ -122,7 +122,7 @@ static void
>> iceland_initialize_power_tune_defaults(struct pp_hwmgr *hwmgr)
>>   break;
>>   default:
>>   smu_data->power_tune_defaults = _iceland;
>> -pr_warning("Unknown V.I. Device ID.\n");
>> +pr_warn("Unknown V.I. Device ID.\n");
>>   break;
>>   }
>>   return;
>> @@ -378,7 +378,7 @@ static int
>> iceland_get_std_voltage_value_sidd(struct pp_hwmgr *hwmgr,
>>   return -EINVAL);
>> if (NULL == hwmgr->dyn_state.cac_leakage_table) {
>> -pr_warning("CAC Leakage Table does not exist, using vddc.\n");
>> +pr_warn("CAC Leakage Table does not exist, using vddc.\n");
>>   return 0;
>>   }
>>   @@ -394,7 +394,7 @@ static int
>> iceland_get_std_voltage_value_sidd(struct pp_hwmgr *hwmgr,
>>   *lo =
>> hwmgr->dyn_state.cac_leakage_table->entries[v_index].Vddc *
>> VOLTAGE_SCALE;
>>   *hi =
>> (uint16_t)(hwmgr->dyn_state.cac_leakage_table->entries[v_index].Leakage *
>> VOLTAGE_SCALE);
>>   } else {
>> -pr_warning("Index from SCLK/VDDC Dependency Table
>> exceeds the CAC Leakage Table index, using maximum index from CAC
>> table.\n");
>> +pr_warn("Index from SCLK/VDDC Dependency Table
>> exceeds the CAC Leakage Table index, using maximum index from CAC
>> table.\n");
>>   *lo =
>> hwmgr->dyn_state.cac_leakage_table->entries[hwmgr->dyn_state.cac_leakage_table->count
>> - 1].Vddc * VOLTAGE_SCALE;
>>  

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Rask Ingemann Lambertsen]

On Fri, Feb 17, 2017 at 04:44:19PM +0100, Maxime Ripard wrote:
[...]
> We already have DT bindings for out of tree drivers, there's really
> nothing new here.

We have DT bindings for *hardware*, not for drivers. As stated in
Documentation/devicetree/usage-model.txt:

"The "Open Firmware Device Tree", or simply Device Tree (DT), is a data
structure and language for describing hardware.  More specifically, it
is a description of hardware that is readable by an operating system
so that the operating system doesn't need to hard code details of the
machine."

"2.1 High Level View
---
The most important thing to understand is that the DT is simply a data
structure that describes the hardware."

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

[drm] bea5b158ff BUG: unable to handle kernel NULL pointer dereference at 0000000000000748

[Fengguang Wu]

] bochs_init+0x17/0x19
[   11.781978]  [] do_one_initcall+0x89/0x11a
[   11.783233]  [] ? do_early_param+0x8f/0x8f
[   11.784497]  [] kernel_init_freeable+0x17f/0x215
[   11.785866]  [] kernel_init+0x9/0xf0
[   11.786990]  [] ret_from_fork+0x1f/0x40
[   11.788216]  [] ? rest_init+0xc0/0xc0
[   11.789367] Code: 85 93 07 00 00 48 c7 c1 5a 44 d7 81 48 c7 c2 2e 10 d7 81 
be 92 0c 00 00 48 c7 c7 20 84 d7 81 e8 94 0f fd ff e9 f1 08 00 00 89 f0 <49> 8b 
44 c6 08 48 85 c0 75 21 31 d2 4c 89 f7 44 89 45 d0 89 4d 
[   11.794799] RIP  [] __lock_acquire+0x93/0x9a0
[   11.796299]  RSP 
[   11.797093] CR2: 0748
[   11.797859] ---[ end trace 103f598e68dbf79f ]---
[   11.798934] Kernel panic - not syncing: Fatal exception

git bisect start v4.9 v4.8 --
git bisect  bad 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942  # 05:25  0-  
1  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect  bad 5fa0eb0b4d4780fbd6d8a09850cc4fd539e9fe65  # 05:35  0-  
4  Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad d8ea757b25ec82687c497fc90aa83f9bcea24b5b  # 05:50  0-  
1  Merge tag 'xtensa-20161005' of git://github.com/jcmvbkbc/linux-xtensa
git bisect  bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c  # 06:14  0-  
1  Merge tag 'usb-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
git bisect good 1a4a2bc460721bc8f91e4c1294d39b38e5af132f  # 06:45 20+  
0  Merge branch 'x86-asm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 49deffe0b0e4c2030696c7a6fd680bacf4761069  # 07:35 20+  
0  Merge tag 'arc-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
git bisect good 597f03f9d133e9837d00965016170271d4f87dcf  # 08:15 20+  
0  Merge branch 'smp-hotplug-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad 9929780e86854833e649b39b290b5fe921eb1701  # 08:43  0-  
1  Merge tag 'driver-core-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
git bisect good 7a53eea1f7b527fd3b6d7ca992914840981afe99  # 08:57 21+  
1  Merge tag 'char-misc-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git bisect  bad 775115c06091fcfa1189a50aca488fa596839617  # 09:29  0-  
2  drivers/base dmam_declare_coherent_memory leaks
git bisect  bad 426bc8e789f8ac84270b196191904d347586032f  # 09:40  0-  
3  base: soc: make it explicitly non-modular
git bisect  bad bea5b158ff0da9c7246ff391f754f5f38e34577a  # 09:53  0-  
2  driver core: add test of driver remove calls during probe
git bisect good cebf8fd16900fdfd58c0028617944f808f97fe50  # 10:04 21+  
0  driver core: fix race between creating/querying glue dir and its cleanup
# first bad commit: [bea5b158ff0da9c7246ff391f754f5f38e34577a] driver core: add 
test of driver remove calls during probe
git bisect good cebf8fd16900fdfd58c0028617944f808f97fe50  # 10:13 60+  
0  driver core: fix race between creating/querying glue dir and its cleanup
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect  bad bea5b158ff0da9c7246ff391f754f5f38e34577a  # 10:25  0- 
12  driver core: add test of driver remove calls during probe
# extra tests on HEAD of linux-devel/devel-spot-201702160837
git bisect  bad b1ac88375913cf81c56dbf5a2c9b64863f188ee2  # 10:25  0- 
25  0day head guard for 'devel-spot-201702160837'
# extra tests on tree/branch linus/master
git bisect  bad 6dc39c50e4aeb769c8ae06edf2b1a732f3490913  # 10:43  0-  
1  Merge branch 'for-linus' of git://git.kernel.dk/linux-block
# extra tests on tree/branch linus/master
git bisect  bad 6dc39c50e4aeb769c8ae06edf2b1a732f3490913  # 10:43  0-  
2  Merge branch 'for-linus' of git://git.kernel.dk/linux-block
# extra tests on tree/branch linux-next/master
git bisect  bad 4ce4a759a3e221b5265ebd03c2fb69a7cf3e  # 11:07  0-  
1  Add linux-next specific files for 20170217


---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/lkp  Intel Corporation


dmesg-quantal-vp-95:20170218095527:x86_64-randconfig-ne0-02160954:4.8.0-rc4-3-gbea5b15:1.gz
Description: application/gzip
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.8.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CON

Re: [PATCH 2/2] drm/ast: Support AST2500

[Benjamin Herrenschmidt]

On Fri, 2017-02-17 at 21:27 +, Emil Velikov wrote:
> Hi Ben,

 .../...

> Not sure why you opted for splitting each suggestion in separate
> email, but it seems to have lead to a [serious] bugfix to go
> unnoticed.

Many thanks for your reviews. I've put a tentative new series there

https://github.com/ozbenh/linux-ast

I'm waiting for Aspeed to test on Monday on their HW (they can test
the POST code) and I'll be testing again on POWER8 and POWER9 this
week-end. If all goes well I'll send the new series to the list then.

I've changed my refactoring of mmc_test_* to be closer to the original
code as I had missed a difference in loop exit condition.

Cheers,
Ben.

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

[Bug 194579] AMDGPU: Possible size overflow detected by PaX in ttm_bo_handle_move_mem (drivers/gpu/drm/ttm/ttm_bo.c:388)

[bugzilla-daemon]

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

--- Comment #9 from PaX Team (pagee...@freemail.hu) ---
would the following workaround do the job of not triggering the overflow and
not causing any other logic bugs for our purposes:

--- a/drivers/gpu/drm/ttm/ttm_bo.c  2016-12-13 12:11:19.867579755 +0100
+++ b/drivers/gpu/drm/ttm/ttm_bo.c2017-02-18 01:19:44.122817874 +0100
@@ -384,7 +384,7 @@
bo->evicted = false;
}

-   if (bo->mem.mm_node) {
+   if (bo->mem.mm_node && bo->mem.start != AMDGPU_BO_INVALID_OFFSET) {
bo->offset = (bo->mem.start << PAGE_SHIFT) +
bdev->man[bo->mem.mem_type].gpu_offset;
bo->cur_placement = bo->mem.placement;

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

[Bug 99843] Geometry Shader - Incorrect Output

[bugzilla-daemon]

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

--- Comment #7 from Ilia Mirkin  ---
FWIW it appears to render correctly on both nouveau (GK208) as well as i965
(SKL).

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

[Bug 99843] Geometry Shader - Incorrect Output

[bugzilla-daemon]

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

--- Comment #6 from Tom St Denis  ---
What hardware is this on?  I wonder if it's a dup of 99850 (which was found on
a Carrizo).

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

Re: [PATCH 2/2] drm/ast: Support AST2500

[Benjamin Herrenschmidt]

On Fri, 2017-02-17 at 21:27 +, Emil Velikov wrote:
> > Heh ok. I don't want to change that POST code too much as I'm not
> > equipped to test it, but I'll have a look later today.
> > 
> 
> Not sure why you opted for splitting each suggestion in separate
> email, but it seems to have lead to a [serious] bugfix to go
> unnoticed.
> Namely:

Dunno why either. I think I was distracted doing too many things at
once.

> > > > +static bool ddr_test_2500(struct ast_private *ast)
> > > > +{
> > > > +   ast_moutdwm(ast, 0x1E6E0074, 0x);
> > > > +   ast_moutdwm(ast, 0x1E6E007C, 0xFF00FF00);
> > > > +   if (mmc_test_burst(ast, 0) < 0)
> > > > +   return false;
> > > > +   if (mmc_test_burst(ast, 1) < 0)
> > > > +   return false;
> > > > +   if (mmc_test_burst(ast, 2) < 0)
> > > > +   return false;
> > > > +   if (mmc_test_burst(ast, 3) < 0)
> > > > +   return false;
> > > > +   if (mmc_test_single_2500(ast, 0) < 0)
> > > > +   return false;
> > > > +   return false;
> > > 
> > > Final return should be true... either things got funny with v2 or
> > > the
> > > this patch was never tested ?

As I said, never tested, I don't have the means, I'm waiting for Aspeed
to test it, hopefully monday. I can test the basic function but not
POST. I'll send a respin anyway.

Note that the POST patch is purposefully at the end of the series, it
can wait. The reason is that that code is only useful if the BMC has
no code running on it, not even u-boot, and thus its memory controller
needs to be remotely initialized by the host.

Most servers out there have something running on the BMC and all my
POWER9 systems won't boot without something on the BMC making them do
so :-)

So the POST patch can be merged later once it has had more massaging
and testing.

Cheers,
Ben.
> 
> This here.
> 
> Regards,
> Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/ast: Support AST2500

[Emil Velikov]

Hi Ben,

On 16 February 2017 at 21:09, Benjamin Herrenschmidt
 wrote:
> On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote:
>> On 16 February 2017 at 09:09, Benjamin Herrenschmidt
>>  wrote:
>> > From: "Y.C. Chen" 
>> >
>> > Add detection and POST code for AST2500 generation chip,
>> > code originally from Aspeed and slightly reworked for
>> > coding style mostly by Ben.
>> >
>> > Signed-off-by: Y.C. Chen 
>> > Signed-off-by: Benjamin Herrenschmidt 
>> > ---
>> > v2. [BenH]
>> >   - Coding style fixes
>> >   - Add timeout to main DRAM init loop
>> >   - Improve boot time display of RAM info
>> >
>> > Y.C. Please check that I didn't break POST as I haven't manage to
>> > test
>> > that (we can't boot our machines if the BMC isn't already POSTed).
>> >
>>
>> Hi Ben,
>>
>> Barring the checkpatch.pl warnings/errors that you've spotted there's
>> a few other comments below.
>> I'm not familiar with the hardware, so it's just things that strike
>> me
>> as odd ;-)
>
> Heh ok. I don't want to change that POST code too much as I'm not
> equipped to test it, but I'll have a look later today.
>
Not sure why you opted for splitting each suggestion in separate
email, but it seems to have lead to a [serious] bugfix to go
unnoticed.
Namely:

>> > +static bool ddr_test_2500(struct ast_private *ast)
>> > +{
>> > +   ast_moutdwm(ast, 0x1E6E0074, 0x);
>> > +   ast_moutdwm(ast, 0x1E6E007C, 0xFF00FF00);
>> > +   if (mmc_test_burst(ast, 0) < 0)
>> > +   return false;
>> > +   if (mmc_test_burst(ast, 1) < 0)
>> > +   return false;
>> > +   if (mmc_test_burst(ast, 2) < 0)
>> > +   return false;
>> > +   if (mmc_test_burst(ast, 3) < 0)
>> > +   return false;
>> > +   if (mmc_test_single_2500(ast, 0) < 0)
>> > +   return false;
>> > +   return false;
>>
>> Final return should be true... either things got funny with v2 or the
>> this patch was never tested ?
>>
This here.

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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Emil Velikov]

Hi Maxime,

As I feared things have taken a turn for the bitter end :-]

It seems that this is a heated topic, so I'l kindly ask that we try
the following:

 - For people such as myself/Tobias/others who feel that driver and DT
bindings should go hand in hand, prove them wrong.
But please, do so by pointing to the documentation (conclusion of a
previous discussion). This way you don't have to repeat yourself and
get [too] annoyed over silly suggestions.

 - The series has code changes which [seemingly] cater for out of tree
module(s).
Clearly state in the commit message who is the user, why it's save to
do so and get an Ack from more prominent [DRM] developers.

Please try to understand that I do not want to annoy/agitate you, I'm
merely pointing what seems [to me] as incorrect.
Nobody is perfect, so if I/others are wrong do point me/us to a
reading to educate ourselves.

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

Re: [PULL] mxsfb fixes

[Dave Airlie]

On 17 February 2017 at 18:00, Marek Vasut  wrote:
> On 02/17/2017 03:41 AM, Dave Airlie wrote:
>> On 16 February 2017 at 08:16, Marek Vasut  wrote:
>>> Hi,
>>>
>>> I collected the MXSFB fixes, based on top of airlied/drm-fixes:
>>
>> At this stage I'd rather not give these to Linus, can you rebase them onto
>> drm-next, and resend, feel free to add stable cc's.
>>
>> Fixes like this should really be getting to me sooner than rc8.
>
> I know, sorry about that. I was totally overloaded in the past weeks.
> What about getting them to rc1, any chance for that ?

Yes if you can rebase them onto drm-next.

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

Re: [PATCH 02/14] drm: qxl: Consolidate bo reservation when pinning

[Gustavo Padovan]

Hi Gabriel,

2017-02-15 Gabriel Krisman Bertazi :

> Every attempt to pin/unpin objects in memory requires
> qxl_bo_reserve/unreserve calls around the pinning operation to protect
> the object from concurrent access, which causes that call sequence to be
> reproduced every place where pinning is needed.  In some cases, that
> sequence was not executed correctly, resulting in potential unprotected
> pinning operations.
> 
> This commit encapsulates the reservation inside a new wrapper to make
> sure it is always handled properly.  In cases where reservation must be
> done beforehand, for some reason, one can use the unprotected version
> __qxl_bo_pin/unpin.
> 
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
>  drivers/gpu/drm/qxl/qxl_display.c | 52 
> ++-
>  drivers/gpu/drm/qxl/qxl_fb.c  | 25 ++-
>  drivers/gpu/drm/qxl/qxl_object.c  | 41 --
>  3 files changed, 54 insertions(+), 64 deletions(-)

Reviewed-by: Gustavo Padovan 

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

Re: [PATCH 01/14] drm: qxl: Drop device flags attribute

[Gustavo Padovan]

Hi Gabriel,

2017-02-15 Gabriel Krisman Bertazi :

> There are no device specific flags that we need to keep track of here.
> Let it vanish.
> 
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
>  drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
>  drivers/gpu/drm/qxl/qxl_drv.h | 3 +--
>  drivers/gpu/drm/qxl/qxl_kms.c | 5 +
>  3 files changed, 3 insertions(+), 7 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

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

[PATCH 2/2] drm/i915: Avoid decomposing a signal-on-any fence-array

[Chris Wilson]

The code currently assumes that all fence arrays it sees are the normal
signal-on-all variety, and decomposes the array into its individual
fences so that it can extract the native i915 fences. If the fence array
is using signal-on-any, we should not decompose as we must not wait on
them all, just the first in *that* set.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 2f6cfa47dc61..2ab96c35cc5e 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -696,7 +696,8 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
if (dma_fence_is_i915(fence))
return i915_gem_request_await_request(req, to_request(fence));
 
-   if (!dma_fence_is_array(fence)) {
+   if (!dma_fence_is_array(fence) ||
+   test_bit(DMA_FENCE_ARRAY_SIGNAL_ANY, >flags)) {
ret = i915_sw_fence_await_dma_fence(>submit,
fence, I915_FENCE_TIMEOUT,
GFP_KERNEL);
-- 
2.11.0

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

[PATCH 1/2] dma-fence: Flag when a fence-array is using signal-on-any

[Chris Wilson]

Indicate that the fence array will be signaled on the first completion
(signal-on-any mode) as opposed to waiting for all to be signaled.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Daniel Vetter 
Cc: "Christian König" 
---
 drivers/dma-buf/dma-fence-array.c | 3 +++
 include/linux/dma-fence-array.h   | 4 
 2 files changed, 7 insertions(+)

diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 67eb7c8fb88c..8c48402a2daa 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -137,6 +137,9 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
dma_fence_init(>base, _fence_array_ops, >lock,
   context, seqno);
 
+   if (num_fences > 1 && signal_on_any)
+   __set_bit(DMA_FENCE_ARRAY_SIGNAL_ANY, >base.flags);
+
array->num_fences = num_fences;
atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 5900945f962d..4270d33d05b3 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -49,6 +49,10 @@ struct dma_fence_array {
struct dma_fence **fences;
 };
 
+enum {
+   DMA_FENCE_ARRAY_SIGNAL_ANY = DMA_FENCE_FLAG_USER_BITS,
+};
+
 extern const struct dma_fence_ops dma_fence_array_ops;
 
 /**
-- 
2.11.0

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

[PATCH 3/9] gpu: ipu-v3: add driver for Prefetch Resolve Engine

[Lucas Stach]

This adds support for the i.MX6 QuadPlus PRE units. Currently only
linear prefetch into SRAM is supported, other modes of operation
like the tiled-to-linear conversion will be added later.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/ipu-v3/Makefile  |   2 +-
 drivers/gpu/ipu-v3/ipu-pre.c | 290 +++
 drivers/gpu/ipu-v3/ipu-prv.h |  11 ++
 3 files changed, 302 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/ipu-v3/ipu-pre.c

diff --git a/drivers/gpu/ipu-v3/Makefile b/drivers/gpu/ipu-v3/Makefile
index 5f961416c4ee..8ae90de46b4d 100644
--- a/drivers/gpu/ipu-v3/Makefile
+++ b/drivers/gpu/ipu-v3/Makefile
@@ -2,4 +2,4 @@ obj-$(CONFIG_IMX_IPUV3_CORE) += imx-ipu-v3.o
 
 imx-ipu-v3-objs := ipu-common.o ipu-cpmem.o ipu-csi.o ipu-dc.o ipu-di.o \
ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-image-convert.o \
-   ipu-smfc.o ipu-vdi.o
+   ipu-pre.o ipu-smfc.o ipu-vdi.o
diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
new file mode 100644
index ..febe0cb8b094
--- /dev/null
+++ b/drivers/gpu/ipu-v3/ipu-pre.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright (c) 2017 Lucas Stach, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ipu-prv.h"
+
+#define IPU_PRE_MAX_WIDTH  2048
+#define IPU_PRE_NUM_SCANLINES  8
+
+#define IPU_PRE_CTRL   0x000
+#define IPU_PRE_CTRL_SET   0x004
+#define  IPU_PRE_CTRL_ENABLE   (1 << 0)
+#define  IPU_PRE_CTRL_BLOCK_EN (1 << 1)
+#define  IPU_PRE_CTRL_BLOCK_16 (1 << 2)
+#define  IPU_PRE_CTRL_SDW_UPDATE   (1 << 4)
+#define  IPU_PRE_CTRL_VFLIP(1 << 5)
+#define  IPU_PRE_CTRL_SO   (1 << 6)
+#define  IPU_PRE_CTRL_INTERLACED_FIELD (1 << 7)
+#define  IPU_PRE_CTRL_HANDSHAKE_EN (1 << 8)
+#define  IPU_PRE_CTRL_HANDSHAKE_LINE_NUM(v)((v & 0x3) << 9)
+#define  IPU_PRE_CTRL_HANDSHAKE_ABORT_SKIP_EN  (1 << 11)
+#define  IPU_PRE_CTRL_EN_REPEAT(1 << 28)
+#define  IPU_PRE_CTRL_TPR_REST_SEL (1 << 29)
+#define  IPU_PRE_CTRL_CLKGATE  (1 << 30)
+#define  IPU_PRE_CTRL_SFTRST   (1 << 31)
+
+#define IPU_PRE_CUR_BUF0x030
+
+#define IPU_PRE_NEXT_BUF   0x040
+
+#define IPU_PRE_TPR_CTRL   0x070
+#define  IPU_PRE_TPR_CTRL_TILE_FORMAT(v)   ((v & 0xff) << 0)
+#define  IPU_PRE_TPR_CTRL_TILE_FORMAT_MASK 0xff
+
+#define IPU_PRE_PREFETCH_ENG_CTRL  0x080
+#define  IPU_PRE_PREF_ENG_CTRL_PREFETCH_EN (1 << 0)
+#define  IPU_PRE_PREF_ENG_CTRL_RD_NUM_BYTES(v) ((v & 0x7) << 1)
+#define  IPU_PRE_PREF_ENG_CTRL_INPUT_ACTIVE_BPP(v) ((v & 0x3) << 4)
+#define  IPU_PRE_PREF_ENG_CTRL_INPUT_PIXEL_FORMAT(v)   ((v & 0x7) << 8)
+#define  IPU_PRE_PREF_ENG_CTRL_SHIFT_BYPASS(1 << 11)
+#define  IPU_PRE_PREF_ENG_CTRL_FIELD_INVERSE   (1 << 12)
+#define  IPU_PRE_PREF_ENG_CTRL_PARTIAL_UV_SWAP (1 << 14)
+#define  IPU_PRE_PREF_ENG_CTRL_TPR_COOR_OFFSET_EN  (1 << 15)
+
+#define IPU_PRE_PREFETCH_ENG_INPUT_SIZE0x0a0
+#define  IPU_PRE_PREFETCH_ENG_INPUT_SIZE_WIDTH(v)  ((v & 0x) << 0)
+#define  IPU_PRE_PREFETCH_ENG_INPUT_SIZE_HEIGHT(v) ((v & 0x) << 16)
+
+#define IPU_PRE_PREFETCH_ENG_PITCH 0x0d0
+#define  IPU_PRE_PREFETCH_ENG_PITCH_Y(v)   ((v & 0x) << 0)
+#define  IPU_PRE_PREFETCH_ENG_PITCH_UV(v)  ((v & 0x) << 16)
+
+#define IPU_PRE_STORE_ENG_CTRL 0x110
+#define  IPU_PRE_STORE_ENG_CTRL_STORE_EN   (1 << 0)
+#define  IPU_PRE_STORE_ENG_CTRL_WR_NUM_BYTES(v)((v & 0x7) << 1)
+#define  IPU_PRE_STORE_ENG_CTRL_OUTPUT_ACTIVE_BPP(v)   ((v & 0x3) << 4)
+
+#define IPU_PRE_STORE_ENG_SIZE 0x130
+#define  IPU_PRE_STORE_ENG_SIZE_INPUT_WIDTH(v) ((v & 0x) << 0)
+#define  IPU_PRE_STORE_ENG_SIZE_INPUT_HEIGHT(v)((v & 0x) 
<< 16)
+
+#define IPU_PRE_STORE_ENG_PITCH0x140
+#define  IPU_PRE_STORE_ENG_PITCH_OUT_PITCH(v)  ((v & 0x) << 0)
+
+#define 

[PATCH 7/9] gpu: ipu-v3: hook up PRG unit

[Lucas Stach]

The i.MX6 QuadPlus IPU needs to PRG unit to gain access to the
data bus. Make sure it is present and available to be used.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/ipu-v3/ipu-common.c | 7 +++
 drivers/gpu/ipu-v3/ipu-prv.h| 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index d0694ef95f28..37426dd94408 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -937,6 +937,7 @@ static const struct of_device_id imx_ipu_dt_ids[] = {
{ .compatible = "fsl,imx51-ipu", .data = _type_imx51, },
{ .compatible = "fsl,imx53-ipu", .data = _type_imx53, },
{ .compatible = "fsl,imx6q-ipu", .data = _type_imx6q, },
+   { .compatible = "fsl,imx6qp-ipu", .data = _type_imx6q, },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, imx_ipu_dt_ids);
@@ -1402,6 +1403,12 @@ static int ipu_probe(struct platform_device *pdev)
if (!ipu)
return -ENODEV;
 
+   if (of_device_is_compatible(np, "fsl,imx6qp-ipu")) {
+   ipu->prg_priv = ipu_prg_get_by_ipu_device(>dev);
+   if (!ipu->prg_priv)
+   return -EPROBE_DEFER;
+   }
+
for (i = 0; i < 64; i++)
ipu->channel[i].ipu = ipu;
ipu->devtype = devtype;
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index 0d1d2d667f3b..0d32a4f3a76a 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -204,6 +204,7 @@ struct ipu_soc {
struct ipu_vdi  *vdi_priv;
struct ipu_image_convert_priv *image_convert_priv;
struct ipu_smfc_priv*smfc_priv;
+   struct ipu_prg  *prg_priv;
 };
 
 static inline u32 ipu_idmac_read(struct ipu_soc *ipu, unsigned offset)
-- 
2.11.0

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

[PATCH 8/9] drm/imx: enable/disable PRG on CRTC enable/disable

[Lucas Stach]

On i.MX6 QuadPlus the PRG needs to be clocked in order to pass
through the data access requests from the IDMAC. This call is a
no-op for other all other SoCs.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/ipuv3-crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 6be515a9fb69..4299c7d07d80 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -55,6 +55,7 @@ static void ipu_crtc_enable(struct drm_crtc *crtc)
struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent);
 
+   ipu_prg_enable(ipu);
ipu_dc_enable(ipu);
ipu_dc_enable_channel(ipu_crtc->dc);
ipu_di_enable(ipu_crtc->di);
@@ -75,6 +76,7 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
 */
drm_atomic_helper_disable_planes_on_crtc(old_crtc_state, false);
ipu_dc_disable(ipu);
+   ipu_prg_disable(ipu);
 
spin_lock_irq(>dev->event_lock);
if (crtc->state->event) {
-- 
2.11.0

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

[PATCH 9/9] drm/imx: use PRG/PRE when possible

[Lucas Stach]

Allow the planes to use the PRG/PRE units as linear prefetchers when
possible. This improves DRAM efficiency a bit and reduces the chance
for display underflow when the memory subsystem is under load.

This does not yet support scanning out tiled buffers directly, as this
needs more work, but it already wires up the basic interaction between
imx-drm, the IPUv3 driver and the PRG and PRE drivers.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/imx-drm-core.c |   5 ++
 drivers/gpu/drm/imx/imx-drm.h  |   3 +
 drivers/gpu/drm/imx/ipuv3-plane.c  | 122 -
 3 files changed, 127 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index bef76cb0d05d..f3fd94046e3e 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -147,6 +147,11 @@ static int imx_drm_atomic_check(struct drm_device *dev,
if (ret)
return ret;
 
+   /* Assign PRG/PRE channels and check if all constrains are satisfied. */
+   ret = ipu_planes_assign_pre(dev, state);
+   if (ret)
+   return ret;
+
return ret;
 }
 
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 5a91cb16c8fa..485df472fd34 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -52,4 +52,7 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
 void imx_drm_connector_destroy(struct drm_connector *connector);
 void imx_drm_encoder_destroy(struct drm_encoder *encoder);
 
+int ipu_planes_assign_pre(struct drm_device *dev,
+ struct drm_atomic_state *state);
+
 #endif /* _IMX_DRM_H_ */
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 57130352db3b..6867cd7f2da3 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -23,6 +23,17 @@
 #include "video/imx-ipu-v3.h"
 #include "ipuv3-plane.h"
 
+struct ipu_plane_state {
+   struct drm_plane_state base;
+   bool use_pre;
+};
+
+static inline struct ipu_plane_state *
+to_ipu_plane_state(struct drm_plane_state *p)
+{
+   return container_of(p, struct ipu_plane_state, base);
+}
+
 static inline struct ipu_plane *to_ipu_plane(struct drm_plane *p)
 {
return container_of(p, struct ipu_plane, base);
@@ -225,6 +236,8 @@ static int ipu_disable_plane(struct drm_plane *plane)
ipu_dmfc_disable_channel(ipu_plane->dmfc);
if (ipu_plane->dp)
ipu_dp_disable(ipu_plane->ipu);
+   if (ipu_prg_present(ipu_plane->ipu))
+   ipu_prg_channel_disable(ipu_plane->ipu_ch);
 
return 0;
 }
@@ -239,13 +252,56 @@ static void ipu_plane_destroy(struct drm_plane *plane)
kfree(ipu_plane);
 }
 
+void ipu_plane_state_reset(struct drm_plane *plane)
+{
+   struct ipu_plane_state *ipu_state;
+
+   if (plane->state) {
+   ipu_state = to_ipu_plane_state(plane->state);
+   __drm_atomic_helper_plane_destroy_state(plane->state);
+   kfree(ipu_state);
+   }
+
+   ipu_state = kzalloc(sizeof(*ipu_state), GFP_KERNEL);
+
+   if (ipu_state) {
+   ipu_state->base.plane = plane;
+   ipu_state->base.rotation = DRM_ROTATE_0;
+   }
+
+   plane->state = _state->base;
+}
+
+struct drm_plane_state *ipu_plane_duplicate_state(struct drm_plane *plane)
+{
+   struct ipu_plane_state *state;
+
+   if (WARN_ON(!plane->state))
+   return NULL;
+
+   state = kmalloc(sizeof(*state), GFP_KERNEL);
+   if (state)
+   __drm_atomic_helper_plane_duplicate_state(plane, >base);
+
+   return >base;
+}
+
+void ipu_plane_destroy_state(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+   struct ipu_plane_state *ipu_state = to_ipu_plane_state(state);
+
+   __drm_atomic_helper_plane_destroy_state(state);
+   kfree(ipu_state);
+}
+
 static const struct drm_plane_funcs ipu_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
.destroy= ipu_plane_destroy,
-   .reset  = drm_atomic_helper_plane_reset,
-   .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
-   .atomic_destroy_state   = drm_atomic_helper_plane_destroy_state,
+   .reset  = ipu_plane_state_reset,
+   .atomic_duplicate_state = ipu_plane_duplicate_state,
+   .atomic_destroy_state   = ipu_plane_destroy_state,
 };
 
 static int ipu_plane_atomic_check(struct drm_plane *plane,
@@ -458,14 +514,30 @@ static void ipu_plane_atomic_disable(struct drm_plane 
*plane,
ipu_disable_plane(plane);
 }
 
+static int ipu_chan_assign_axi_id(int ipu_chan)
+{
+   switch (ipu_chan) {
+   case IPUV3_CHANNEL_MEM_BG_SYNC:
+   return 1;
+   case IPUV3_CHANNEL_MEM_FG_SYNC:
+

[PATCH 4/9] gpu: ipu-v3: add DT binding for the Prefetch Resolve Gasket

[Lucas Stach]

This adds the the devicetree binding for the Prefetch Resolve Gasket,
as found on i.MX6 QuadPlus.
The PRG is fairly simple in that it only has a configuration register
range and two clocks, one for the AHB slave port and one for the AXI
ports and the functional units.

The PRE connections need to be described in the DT, as the PRE<->PRG
assignment is a mix between fixed and muxable connections.

Signed-off-by: Lucas Stach 
---
 .../bindings/display/imx/fsl-imx-drm.txt   | 25 ++
 1 file changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
index 1bd777d7c37d..5e4b8b13b9f8 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
@@ -79,6 +79,31 @@ pre@021c8000 {
fsl,ocram = <>;
 };
 
+Freescale i.MX PRG (Prefetch Resolve Gasket)
+
+
+Required properties:
+- compatible: should be "fsl,imx6qp-prg"
+- reg: should be register base and length as documented in the
+  datasheet
+- clocks : phandles to the PRG ipg and axi clock inputs, as described
+  in Documentation/devicetree/bindings/clock/clock-bindings.txt and
+  Documentation/devicetree/bindings/clock/imx6q-clock.txt.
+- clock-names: should be "ipg" and "axi"
+- fsl,pres: phandles to the PRE units attached to this PRG, with the fixed
+  PRE as the first entry and the muxable PREs following.
+
+example:
+
+prg@021cc000 {
+   compatible = "fsl,imx6qp-prg";
+   reg = <0x021cc000 0x1000>;
+   clocks = < IMX6QDL_CLK_PRG0_APB>,
+< IMX6QDL_CLK_PRG0_AXI>;
+   clock-names = "ipg", "axi";
+   fsl,pres = <>, <>, <>;
+};
+
 Parallel display support
 
 
-- 
2.11.0

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

[PATCH 2/9] gpu: ipu-v3: add DT binding for the Prefetch Resolve Engine

[Lucas Stach]

The Prefetch Resolve Engine is a prefetch and tile resolve engine
which prefetches display data from DRAM to an internal SRAM region.
It has a single clock for configuration register access and the
functional units. A single shared interrupt is used for status and
error signaling.

The only external dependency is the SRAM region to use for the
prefetch double buffer.

Signed-off-by: Lucas Stach 
---
 .../bindings/display/imx/fsl-imx-drm.txt   | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
index 971c3eedb1c7..1bd777d7c37d 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
@@ -53,6 +53,32 @@ ipu: ipu@1800 {
};
 };
 
+Freescale i.MX PRE (Prefetch Resolve Engine)
+
+
+Required properties:
+- compatible: should be "fsl,imx6qp-pre"
+- reg: should be register base and length as documented in the
+  datasheet
+- clocks : phandle to the PRE axi clock input, as described
+  in Documentation/devicetree/bindings/clock/clock-bindings.txt and
+  Documentation/devicetree/bindings/clock/imx6q-clock.txt.
+- clock-names: should be "axi"
+- interrupts: should contain the PRE interrupt
+- fsl,ocram: phandle pointing to the mmio-sram device node, that should be
+  used for the PRE SRAM double buffer.
+
+example:
+
+pre@021c8000 {
+   compatible = "fsl,imx6qp-pre";
+   reg = <0x021c8000 0x1000>;
+   interrupts = ;
+   clocks = < IMX6QDL_CLK_PRE0>;
+   clock-names = "axi";
+   fsl,ocram = <>;
+};
+
 Parallel display support
 
 
-- 
2.11.0

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

[PATCH 5/9] gpu: ipu-v3: add driver for Prefetch Resolve Gasket

[Lucas Stach]

This adds support for the i.MX6 QUadPlus PRG unit. It glues together the
IPU and the PRE units.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/ipu-v3/Makefile  |   2 +-
 drivers/gpu/ipu-v3/ipu-prg.c | 413 +++
 drivers/gpu/ipu-v3/ipu-prv.h |   3 +
 include/video/imx-ipu-v3.h   |  15 ++
 4 files changed, 432 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/ipu-v3/ipu-prg.c

diff --git a/drivers/gpu/ipu-v3/Makefile b/drivers/gpu/ipu-v3/Makefile
index 8ae90de46b4d..1ab9bceee755 100644
--- a/drivers/gpu/ipu-v3/Makefile
+++ b/drivers/gpu/ipu-v3/Makefile
@@ -2,4 +2,4 @@ obj-$(CONFIG_IMX_IPUV3_CORE) += imx-ipu-v3.o
 
 imx-ipu-v3-objs := ipu-common.o ipu-cpmem.o ipu-csi.o ipu-dc.o ipu-di.o \
ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-image-convert.o \
-   ipu-pre.o ipu-smfc.o ipu-vdi.o
+   ipu-pre.o ipu-prg.o ipu-smfc.o ipu-vdi.o
diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
new file mode 100644
index ..c1e1ab0ec5c5
--- /dev/null
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -0,0 +1,413 @@
+/*
+ * Copyright (c) 2016-2017 Lucas Stach, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ipu-prv.h"
+
+#define IPU_PRG_CTL0x00
+#define  IPU_PRG_CTL_BYPASS(i) (1 << (0 + i))
+#define  IPU_PRG_CTL_SOFT_ARID_MASK0x3
+#define  IPU_PRG_CTL_SOFT_ARID_SHIFT(i)(8 + i * 2)
+#define  IPU_PRG_CTL_SOFT_ARID(i, v)   ((v & 0x3) << (8 + 2 * i))
+#define  IPU_PRG_CTL_SO(i) (1 << (16 + i))
+#define  IPU_PRG_CTL_VFLIP(i)  (1 << (19 + i))
+#define  IPU_PRG_CTL_BLOCK_MODE(i) (1 << (22 + i))
+#define  IPU_PRG_CTL_CNT_LOAD_EN(i)(1 << (25 + i))
+#define  IPU_PRG_CTL_SOFTRST   (1 << 30)
+#define  IPU_PRG_CTL_SHADOW_EN (1 << 31)
+
+#define IPU_PRG_STATUS 0x04
+#define  IPU_PRG_STATUS_BUFFER0_READY(i)   (1 << (0 + i * 2))
+#define  IPU_PRG_STATUS_BUFFER1_READY(i)   (1 << (1 + i * 2))
+
+#define IPU_PRG_QOS0x08
+#define  IPU_PRG_QOS_ARID_MASK 0xf
+#define  IPU_PRG_QOS_ARID_SHIFT(i) (0 + i * 4)
+
+#define IPU_PRG_REG_UPDATE 0x0c
+#define  IPU_PRG_REG_UPDATE_REG_UPDATE (1 << 0)
+
+#define IPU_PRG_STRIDE(i)  (0x10 + i * 0x4)
+#define  IPU_PRG_STRIDE_STRIDE_MASK0x3fff
+
+#define IPU_PRG_CROP_LINE  0x1c
+
+#define IPU_PRG_THD0x20
+
+#define IPU_PRG_BADDR(i)   (0x24 + i * 0x4)
+
+#define IPU_PRG_OFFSET(i)  (0x30 + i * 0x4)
+
+#define IPU_PRG_ILO(i) (0x3c + i * 0x4)
+
+#define IPU_PRG_HEIGHT(i)  (0x48 + i * 0x4)
+#define  IPU_PRG_HEIGHT_PRE_HEIGHT_MASK0xfff
+#define  IPU_PRG_HEIGHT_PRE_HEIGHT_SHIFT   0
+#define  IPU_PRG_HEIGHT_IPU_HEIGHT_MASK0xfff
+#define  IPU_PRG_HEIGHT_IPU_HEIGHT_SHIFT   16
+
+struct ipu_prg_channel {
+   boolenabled;
+   int used_pre;
+};
+
+struct ipu_prg {
+   struct list_headlist;
+   struct device   *dev;
+   int id;
+
+   void __iomem*regs;
+   struct clk  *clk_ipg, *clk_axi;
+   struct regmap   *iomuxc_gpr;
+   struct ipu_pre  *pres[3];
+
+   struct ipu_prg_channel  chan[3];
+};
+
+static DEFINE_MUTEX(ipu_prg_list_mutex);
+static LIST_HEAD(ipu_prg_list);
+
+struct ipu_prg *
+ipu_prg_get_by_ipu_device(struct device *dev)
+{
+   struct device_node *prg_node = of_parse_phandle(dev->of_node,
+   "fsl,prg", 0);
+   struct ipu_prg *prg;
+
+   mutex_lock(_prg_list_mutex);
+   list_for_each_entry(prg, _prg_list, list) {
+   if (prg_node == prg->dev->of_node) {
+   mutex_unlock(_prg_list_mutex);
+   device_link_add(dev, prg->dev, DL_FLAG_AUTOREMOVE);
+   prg->id = of_alias_get_id(dev->of_node, "ipu");
+   return prg;
+   }
+   }
+   mutex_unlock(_prg_list_mutex);
+
+   return NULL;
+}
+
+int ipu_prg_max_active_channels(void)
+{
+   return 

[PATCH 6/9] gpu: ipu-v3: extend the IPUv3 DT binding for i.MX6 QuadPlus

[Lucas Stach]

On i.MX6 QuadPlus the IPU needs to know which PRG has to be
used for this IPU instance. Add a "fsl,prg" property containing
a phandle pointing to the correct PRG device.

Signed-off-by: Lucas Stach 
---
 Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
index 5e4b8b13b9f8..c8c7a7b3951f 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
@@ -28,6 +28,8 @@ Required properties:
   in this order.
 - resets: phandle pointing to the system reset controller and
   reset line index, see reset/fsl,imx-src.txt for details
+Additional required properties for fsl,imx6qp-ipu:
+- fsl,prg: phandle to prg node associated with this IPU instance
 Optional properties:
 - port@[0-3]: Port nodes with endpoint definitions as defined in
   Documentation/devicetree/bindings/media/video-interfaces.txt.
-- 
2.11.0

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

[PATCH 0/9] ipu-v3/imx-drm PRG/PRE extension

[Lucas Stach]

Hi all,

this is the first round of patches to enable the Prefetch Resolve Gasket
and the Prefetch Resolve Engine as found on the i.MX6 QuadPlus. Basically
those units are external extensions to the IPUv3 that are able to prefetch
display data from DRAM to an internal SRAM region, transforming the
periodic realtime requests from the display FIFOs into larger bursts of
normal memory requests, which do mix better with other DRAM traffic in the
system.

The PRE can do a number of transformations on the fly, like changing
component and plane ordering, as well resolving the Vivante GPU tiling
format into linear scanlines. None of those transformations are used
right now.

This initial patchset uses the PRG/PRE units as linear prefetchers only.
It does however hook up most of the interactions between imx-drm, IPUv3
and PRG/PRE, so that adding those transformations should be an
incremental change over that. Also the devicetree binding fully describe
the devices, so that no further changes should be necessary.

Regards,
Lucas

Lucas Stach (9):
  gpu: ipu-v3: remove AXI ID setting for IC channel
  gpu: ipu-v3: add DT binding for the Prefetch Resolve Engine
  gpu: ipu-v3: add driver for Prefetch Resolve Engine
  gpu: ipu-v3: add DT binding for the Prefetch Resolve Gasket
  gpu: ipu-v3: add driver for Prefetch Resolve Gasket
  gpu: ipu-v3: extend the IPUv3 DT binding for i.MX6 QuadPlus
  gpu: ipu-v3: hook up PRG unit
  drm/imx: enable/disable PRG on CRTC enable/disable
  drm/imx: use PRG/PRE when possible

 .../bindings/display/imx/fsl-imx-drm.txt   |  53 +++
 drivers/gpu/drm/imx/imx-drm-core.c |   5 +
 drivers/gpu/drm/imx/imx-drm.h  |   3 +
 drivers/gpu/drm/imx/ipuv3-crtc.c   |   2 +
 drivers/gpu/drm/imx/ipuv3-plane.c  | 122 +-
 drivers/gpu/ipu-v3/Makefile|   2 +-
 drivers/gpu/ipu-v3/ipu-common.c|   7 +
 drivers/gpu/ipu-v3/ipu-image-convert.c |   2 -
 drivers/gpu/ipu-v3/ipu-pre.c   | 290 +++
 drivers/gpu/ipu-v3/ipu-prg.c   | 413 +
 drivers/gpu/ipu-v3/ipu-prv.h   |  15 +
 include/video/imx-ipu-v3.h |  15 +
 12 files changed, 923 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/ipu-v3/ipu-pre.c
 create mode 100644 drivers/gpu/ipu-v3/ipu-prg.c

-- 
2.11.0

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

[PATCH 1/9] gpu: ipu-v3: remove AXI ID setting for IC channel

[Lucas Stach]

This is a pretty minor optimization for the IC channel to get
out-of-order AXI returns, but clashes with the AXI ID assignment
that needs to be done for the display channels on QuadPlus.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/ipu-v3/ipu-image-convert.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c 
b/drivers/gpu/ipu-v3/ipu-image-convert.c
index 805b6fa7b5f4..5e3cc6bd98fc 100644
--- a/drivers/gpu/ipu-v3/ipu-image-convert.c
+++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
@@ -671,8 +671,6 @@ static void init_idmac_channel(struct ipu_image_convert_ctx 
*ctx,
ipu_ic_task_idma_init(chan->ic, channel, width, height,
  burst_size, rot_mode);
 
-   ipu_cpmem_set_axi_id(channel, 1);
-
ipu_idmac_set_double_buffer(channel, ctx->double_buffering);
 }
 
-- 
2.11.0

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

Re: [Nouveau] nouveau preventing shutdown after suspend-resume

[poma]

On 17.02.2017 18:06, Ilia Mirkin wrote:
> On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita
>  wrote:
>> Hello Ilia,
>>
>> On 17 February 2017 at 11:14, Ilia Mirkin  wrote:
>>> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
>>>  wrote:
 I'm happy to file
 a bugzilla entry and provide any other needed information or help with
 testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo
 bugzilla?
>>>
>>> Nouveau bugs are tracked on the fdo bugzilla. It would appear that
>>> you're using a 4.8 kernel. Do issues persist with a 4.10 kernel? I'm
>>> thinking of upstream commit cae9ff036ee, but it's likely that there
>>> have also been others I'm not thinking of.
>>>
>>
>> Yes, although the logs I have pasted were indeed collected using a 4.8
>> kernel, the problem persists with a recent Linus' tree (v4.10-rc8 + a
>> couple of commits) which contains cae9ff036ee.
> 
> You should file a bug with all the relevant info. BTW, odd that the
> device is reported as 179c. 1780-17bf isn't allocated to anything.
> There *is* a 139c device, "GM107M [GeForce 940M]", but that would
> imply there's an extra 0x0400 bit set.
> 

$ curl -s ftp://download.nvidia.com/XFree86/Linux-x86/375.39/README/README.txt 
| grep -i 179c 
GeForce 940MX 179C   E


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

[Bug 99850] Tessellation bug on Carrizo

[bugzilla-daemon]

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

--- Comment #2 from Tom St Denis  ---
Dug up the original thread that introduced this patch.  Might prove useful in
debugging it.

https://lists.freedesktop.org/archives/mesa-dev/2016-May/116152.html

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

Re: nouveau preventing shutdown after suspend-resume

[Ilia Mirkin]

On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita
 wrote:
> Hello Ilia,
>
> On 17 February 2017 at 11:14, Ilia Mirkin  wrote:
>> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
>>  wrote:
>>> I'm happy to file
>>> a bugzilla entry and provide any other needed information or help with
>>> testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo
>>> bugzilla?
>>
>> Nouveau bugs are tracked on the fdo bugzilla. It would appear that
>> you're using a 4.8 kernel. Do issues persist with a 4.10 kernel? I'm
>> thinking of upstream commit cae9ff036ee, but it's likely that there
>> have also been others I'm not thinking of.
>>
>
> Yes, although the logs I have pasted were indeed collected using a 4.8
> kernel, the problem persists with a recent Linus' tree (v4.10-rc8 + a
> couple of commits) which contains cae9ff036ee.

You should file a bug with all the relevant info. BTW, odd that the
device is reported as 179c. 1780-17bf isn't allocated to anything.
There *is* a 139c device, "GM107M [GeForce 940M]", but that would
imply there's an extra 0x0400 bit set.

Cheers,

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

[Bug 99843] Geometry Shader - Incorrect Output

[bugzilla-daemon]

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

--- Comment #5 from d...@jerber.co.uk ---
Created attachment 129697
  --> https://bugs.freedesktop.org/attachment.cgi?id=129697=edit
Trace

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

[Bug 99843] Geometry Shader - Incorrect Output

[bugzilla-daemon]

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

--- Comment #4 from d...@jerber.co.uk ---
I created a minimal test program that simply draws the 3 polygons (12 sided). I
have used apitrace with this test program to generate a trace and I'll upload
this shortly. Thanks.

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

Re: nouveau preventing shutdown after suspend-resume

[João Paulo Rechi Vita]

Hello Ilia,

On 17 February 2017 at 11:14, Ilia Mirkin  wrote:
> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
>  wrote:
>> I'm happy to file
>> a bugzilla entry and provide any other needed information or help with
>> testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo
>> bugzilla?
>
> Nouveau bugs are tracked on the fdo bugzilla. It would appear that
> you're using a 4.8 kernel. Do issues persist with a 4.10 kernel? I'm
> thinking of upstream commit cae9ff036ee, but it's likely that there
> have also been others I'm not thinking of.
>

Yes, although the logs I have pasted were indeed collected using a 4.8
kernel, the problem persists with a recent Linus' tree (v4.10-rc8 + a
couple of commits) which contains cae9ff036ee.

Thanks,

--
João Paulo Rechi Vita
http://about.me/jprvita
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau preventing shutdown after suspend-resume

[Ilia Mirkin]

On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
 wrote:
> I'm happy to file
> a bugzilla entry and provide any other needed information or help with
> testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo
> bugzilla?

Nouveau bugs are tracked on the fdo bugzilla. It would appear that
you're using a 4.8 kernel. Do issues persist with a 4.10 kernel? I'm
thinking of upstream commit cae9ff036ee, but it's likely that there
have also been others I'm not thinking of.

Cheers,

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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Tobias Jakobi]

Alexandre Belloni wrote:
> On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote:
>>> The device tree is a representation of the hardware itself. The state
>>> of the driver support doesn't change the hardware you're running on,
>>> just like your BIOS/UEFI on x86 won't change the device it reports to
>>> Linux based on whether it has a driver for it.
>> Like Emil already said, the new bindings and the DT entries are solely
>> introduced to support a proprietary out-of-tree module.
>>
> 
> Because device tree describes the hardware, the added binding doesn't
> support any particular module. The eventually upstreamed drvier will
> share the same bindings.
OK, can we then agree that we _only_ merge the bindings and the entries,
once this driver is upstream?

Driver upstreaming and DT work go hand-in-hand. It's usually after a lot
of discussion that new bindings get finalised. And for that discussion
to happen we need to know how the driver uses the information from the
DT. Otherwise we have no way to evaluate if the description is in any
way "appropriate".

And no, I don't follow the "DT is a separate/independent thing" thought.
It maybe is in an ideal world, but we've seen it now often enough that
bindings turned out to be poorly designed, even though they looked fine
at first.

With best wishes,
Tobias


> 
>> The current workflow when introducing new DT entries is the following:
>> - upstream a driver that uses the entries
>> - THEN add the new entries
>>
> 
> Exactly not, if you do that, checkpatch will complain loudly. Because
> you must not add a driver using bindings that are not documented first.
> 
> 

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

nouveau preventing shutdown after suspend-resume

[João Paulo Rechi Vita]

Hello,

I'm working on a Asus X756UQK laptop with nvidia + intel graphics
cards. After a suspend-resume cycle, the machine hangs on shutdown,
requiring a forced power off. After resuming I sometimes see the
following messages on the kernel log:

[  186.117539] nouveau :01:00.0: DRM: evicting buffers...
[  186.118105] nouveau :01:00.0: DRM: waiting for kernel
channels to go idle...
[  201.139049] nouveau :01:00.0: DRM: failed to idle channel 0 [DRM]
[  201.139688] [ cut here ]
[  201.140297] WARNING: CPU: 0 PID: 1230 at
/usr/src/packages/BUILD/linux-4.8.0/drivers/pci/pci.c:1616
pci_disable_device+0x99/0xb0
[  201.140970] nouveau :01:00.0: disabling already-disabled device
[  201.140984] Modules linked in:
[  201.141608]  ccm arc4 rfcomm joydev cmac bnep intel_rapl
x86_pkg_temp_thermal coretemp i2c_designware_platform
i2c_designware_core kvm_intel asus_nb_wmi asus_wmi sparse_keymap
snd_hda_codec_hdmi snd_hda_codec_conexant snd_soc_skl
snd_hda_codec_generic snd_soc_skl_ipc snd_soc_sst_ipc kvm ath10k_pci
snd_soc_sst_dsp snd_hda_ext_core snd_soc_sst_match ath10k_core
snd_soc_core irqbypass crct10dif_pclmul snd_compress crc32_pclmul
ac97_bus ghash_clmulni_intel snd_pcm_dmaengine ath mac80211
snd_hda_intel aesni_intel snd_hda_codec aes_x86_64 snd_hda_core lrw
glue_helper uvcvideo snd_hwdep ablk_helper videobuf2_vmalloc cryptd
videobuf2_memops snd_pcm videobuf2_v4l2 cfg80211 videobuf2_core
videodev snd_timer media input_leds snd r8169 soundcore mii btusb
btrtl shpchp processor_thermal_device mei_me idma64 mei
[  201.143087]  intel_pch_thermal
[  201.143087]  virt_dma
[  201.143087]  intel_lpss_pci
[  201.143088]  intel_soc_dts_iosf
[  201.143088]  hci_uart
[  201.143089]  elan_i2c
[  201.143089]  btbcm
[  201.143089]  btqca
[  201.143090]  btintel
[  201.143090]  bluetooth
[  201.143090]  int3403_thermal
[  201.143091]  int340x_thermal_zone
[  201.143091]  acpi_als
[  201.143091]  kfifo_buf
[  201.143092]  int3400_thermal
[  201.143092]  acpi_thermal_rel
[  201.143093]  industrialio
[  201.143093]  intel_lpss_acpi
[  201.143093]  acpi_pad
[  201.143094]  tpm_crb
[  201.143094]  intel_lpss
[  201.143094]  fjes
[  201.143095]  mac_hid
[  201.143095]  asus_wireless
[  201.143095]  nouveau
[  201.143096]  i915
[  201.143096]  mxm_wmi
[  201.143096]  i2c_algo_bit
[  201.143097]  drm_kms_helper
[  201.143097]  syscopyarea
[  201.143098]  ttm
[  201.143098]  sysfillrect
[  201.143098]  serio_raw
[  201.143099]  sysimgblt
[  201.143099]  fb_sys_fops
[  201.143100]  drm
[  201.143100]  ahci
[  201.143100]  libahci
[  201.143101]  i2c_hid
[  201.143101]  hid
[  201.143101]  video
[  201.143102]  wmi

[  201.143104] CPU: 0 PID: 1230 Comm: kworker/0:6 Not tainted
4.8.0-32-generic #34+dev155.82734c4beos3.1.2-Endless
[  201.143104] Hardware name: ASUSTeK COMPUTER INC.
X756UQK/X756UQK, BIOS X756UQK.201 07/01/2016
[  201.143107] Workqueue: pm pm_runtime_work
[  201.143110]  0286 6307316f 953a9d933c08
9e031233
[  201.143111]  953a9d933c58  953a9d933c48
9dc832f1
[  201.143112]  0650 953a9ff44000 953a9feeeca0
953a997b1800
[  201.143113] Call Trace:
[  201.143116]  [] dump_stack+0x63/0x90
[  201.143118]  [] __warn+0xd1/0xf0
[  201.143120]  [] warn_slowpath_fmt+0x5f/0x80
[  201.143122]  [] ? pci_save_vc_state+0x34/0xe0
[  201.143124]  [] pci_disable_device+0x99/0xb0
[  201.143152]  []
nouveau_pmops_runtime_suspend+0x69/0xe0 [nouveau]
[  201.143153]  [] pci_pm_runtime_suspend+0x5b/0x180
[  201.143154]  [] __rpm_callback+0x33/0x70
[  201.143155]  [] rpm_callback+0x24/0x80
[  201.143156]  [] ? pci_pm_runtime_resume+0xa0/0xa0
[  201.143157]  [] rpm_suspend+0x12d/0x650
[  201.143158]  [] pm_runtime_work+0x78/0xa0
[  201.143160]  [] process_one_work+0x156/0x420
[  201.143161]  [] worker_thread+0x4e/0x4a0
[  201.143162]  [] ? rescuer_thread+0x380/0x380
[  201.143163]  [] ? rescuer_thread+0x380/0x380
[  201.143165]  [] kthread+0xd8/0xf0
[  201.143167]  [] ret_from_fork+0x1f/0x40
[  201.143168]  [] ? kthread_park+0x60/0x60
[  201.143169] ---[ end trace db73394a87e603e4 ]---

Disabling runtime pm (nouveau.runpm=0) the machine is able to
shutdown, but with a delay of ~30s, and the following messages on the
log:

nouveau :01:00.0: Xorg[691]: failed to idle channel 2 [Xorg[691]]
nouveau :01:00.0: Xorg[691]: failed to idle channel 2 [Xorg[691]]

lspci shows the card as:
01:00.0 3D controller: NVIDIA Corporation Device 179c (rev a2)

And according to nouveau logs, this card supports the Optimus technology:

[0.863470] pci :01:00.0: optimus capabilities: enabled, status
dynamic power, hda bios codec 

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Maxime Ripard]

On Thu, Feb 16, 2017 at 04:54:45PM +, Emil Velikov wrote:
> On 16 February 2017 at 12:43, Tobias Jakobi
>  wrote:
> > Hello,
> >
> > I was wondering about the following. Wasn't there some strict
> > requirement about code going upstream, which also included that there
> > was a full open-source driver stack for it?
> >
> > I don't see how this is the case for Mali, neither in the kernel, nor in
> > userspace. I'm aware that the Mali kernel driver is open-source. But it
> > is not upstream, maintained out of tree, and won't land upstream in its
> > current form (no resemblence to a DRM driver at all). And let's not talk
> > about the userspace part.
> >
> > So, why should this be here?
> >
> Have to agree with Tobias, here.
> 
> I can see the annoyance that Maxime and others have to go through to
> their systems working.
> At the same time, changing upstream kernel to suit out of tree
> module(s) is not how things work. Right ?
> 
> Not to mention that the series adds stable ABI exclusively(?) used by
> a module which does not seem to be in the process of getting merged.

It really doesn't have any relation to whether a particular component
is supported in Linux. Our git repo just happens to be the canonical
source of DT, but those DTs are also used in other systems and
projects that have *no* relation with Linux, and might have a
different view on things than we do.

There's been a long-running discussion about moving the DTs out of the
kernel and in a separate repo. Would you still be opposed to it if I
happened to contribute that binding to that repo, even if Linux didn't
have any in-tree support for it? I'm pretty sure you wouldn't, yet
this is the exact same case.

And taking the ACPI example once again, this doesn't seem to bother
you at all that ACPI reports that it has a device that is not
supported in-tree in Linux. Why is it any different in DT.

We already have DT bindings for out of tree drivers, there's really
nothing new here.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Maxime Ripard]

On Fri, Feb 17, 2017 at 01:45:44PM +0100, Tobias Jakobi wrote:
> Hello Maxime,
> 
> Maxime Ripard wrote:
> > Hi,
> > 
> > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
> >> I was wondering about the following. Wasn't there some strict
> >> requirement about code going upstream, which also included that there
> >> was a full open-source driver stack for it?
> >>
> >> I don't see how this is the case for Mali, neither in the kernel, nor in
> >> userspace. I'm aware that the Mali kernel driver is open-source. But it
> >> is not upstream, maintained out of tree, and won't land upstream in its
> >> current form (no resemblence to a DRM driver at all). And let's not talk
> >> about the userspace part.
> >>
> >> So, why should this be here?
> > 
> > The device tree is a representation of the hardware itself. The state
> > of the driver support doesn't change the hardware you're running on,
> > just like your BIOS/UEFI on x86 won't change the device it reports to
> > Linux based on whether it has a driver for it.
>
> Like Emil already said, the new bindings and the DT entries are solely
> introduced to support a proprietary out-of-tree module.

No. This new binding and the DT entries are solely introduced to
describe a device found in a number of SoCs, just like any other DT
binding we have.

> The current workflow when introducing new DT entries is the following:
> - upstream a driver that uses the entries
> - THEN add the new entries

And that's never been the preferred workflow, for *any* patches.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[Bug 99850] Tessellation bug on Carrizo

[bugzilla-daemon]

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

Bug ID: 99850
   Summary: Tessellation bug on Carrizo
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: tom.stde...@amd.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 129692
  --> https://bugs.freedesktop.org/attachment.cgi?id=129692=edit
carrizo run with HEAD

Tessellation is broken on Carrizo (A12-9800) hardware and apparently has been
for a while.  The offending commit is 

commit a4e2146a9d24592ed7e3bf778e3c21c6cfb89330
Author: Bas Nieuwenhuizen 
Date:   Mon May 2 14:55:52 2016 +0200

radeonsi: Use buffer loads and stores for passing data from TCS to TES.

We always try to use 4-component loads, as LLVM does not combine loads
and they bypass the L1 cache.

We can't use a similar strategy for stores and this is especially
notable with the tess factors, as they are often set with separate
MOV's per component in the TGSI.

We keep storing to LDS and the LDS space, so we can load the outputs
later, either due to the shader, of for wrting the tess factors.

Signed-off-by: Bas Nieuwenhuizen 
Reviewed-by: Nicolai Hähnle 
Reviewed-by: Marek Olšák 

I found it via running Unigine-Heaven with tessellation enabled.

The bug doesn't occur on other VI hardware (Polaris10, FIJI).

I can confirm that the HEAD~ commit leads to spec/arb_tessellation_shader/*
tests (in piglit) passing compared to running with HEAD.

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

[Bug 99850] Tessellation bug on Carrizo

[bugzilla-daemon]

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

--- Comment #1 from Tom St Denis  ---
Created attachment 129693
  --> https://bugs.freedesktop.org/attachment.cgi?id=129693=edit
Carrizo run with HEAD~

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

Re: [PATCH v2 0/4] drm: handle override/firmware edid at the lowest level

[Ville Syrjälä]

On Fri, Feb 17, 2017 at 05:20:50PM +0200, Jani Nikula wrote:
> v2 of cover.1487241304.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1487241304.git.jani.nikula@intel.com

lgtm. For the series
Reviewed-by: Ville Syrjälä 

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

Re: [PATCH] drm: add drm_get_connector_force_name

[Chris Wilson]

On Fri, Feb 17, 2017 at 05:14:47PM +0200, Jani Nikula wrote:
> Follow the naming in debugfs also for logging, add "unknown" for values
> beyond the enumerated ones.
> 
> Signed-off-by: Jani Nikula 
> ---

> +EXPORT_SYMBOL(drm_get_connector_force_name);

Do we need the symbol outside of drm-core? Mainly asking if you forsee a
user.

> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 2290a74a6e46..a6385d4b598b 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -261,30 +261,8 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
>  static int connector_show(struct seq_file *m, void *data)
>  {
> - seq_puts(m, status);
> + seq_puts(m, drm_get_connector_force_name(connector->force));

Loses the trailing '\n'. It's not required, but it looks neater on the
terminal.

Two small questions,
Reviwed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/color: Document CTM eqations

[Ville Syrjälä]

On Fri, Feb 17, 2017 at 03:05:28PM +, Lionel Landwerlin wrote:
> On 17/02/17 14:56, Ville Syrjälä wrote:
> > On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote:
> >> On 17/02/17 13:54, Brian Starkey wrote:
> >>> What's the verdict? We've got [1] which is about to become another
> >>> (driver) implementation - better to change before that merges than
> >>> after I guess.
> >>>
> >>> -Brian
> >>>
> >>> [1] https://lkml.org/lkml/2017/2/13/304
> >>>
> >>> On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote:
>  Hi,
> 
>  On 15 February 2017 at 11:39, Ville Syrjälä
>   wrote:
> > On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:
> >> On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
> >>  wrote:
> >>> Hmm. Two's complement is what I was thinking it is. Which shows that
> >>> I never managed to read the code in any detail. Definitely needs to
> >>> be documented properly.
> >> That sounds supremely backwards. I guess we can't fix this anymore?
> > I have no idea. Anyone else?
>  I don't know of any implementation using this; maybe closed Intel
>  Android stuff? Certainly GitHub showed no-one using it, and neither X
>  nor Weston/Mutter are using it yet.
> 
>  Cheers,
>  Daniel
> >> If we're talking fixed point reprsentation, ChromeOS is using this :
> >>
> >> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice=209
> > So it's already using the sign+magnitude stuff. Which presumably
> > means we can't change it to two's complement anymore :( Maybe we add a
> > CTM2 property ;)
> >
> > Using sign+magnitude definitely looks rather inefficient since there's
> > a branch inside the loop. With two's complement you wouldn't need that
> > thing slowing you down.
> >
> If you're seriously considering that, you might also want to bump struct 
> drm_color_lut to use 32bits fields.

Which is what I thought we had already agreed to do when we started
planning this color management stuff. But I guess that plan got
somehow scrapped after I was no longer part of the discussions.

> It seems some people have concerned about HDR.

HDR is definitely something I'd like to have a look at.

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

[PATCH v2 3/4] drm/edid: respect connector force for drm_get_edid ddc probe

[Jani Nikula]

Skip DDC probe for forced connector status. Don't try to read the EDID
if the connector is forced off. Skipping probe for forced on connectors
will make more sense when drm_do_get_edid() will handle override and
firmware EDIDs.

Suggested-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4bb50e0e7110..e1743ab276dc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1428,7 +1428,10 @@ struct edid *drm_get_edid(struct drm_connector 
*connector,
 {
struct edid *edid;
 
-   if (!drm_probe_ddc(adapter))
+   if (connector->force == DRM_FORCE_OFF)
+   return NULL;
+
+   if (connector->force == DRM_FORCE_UNSPECIFIED && 
!drm_probe_ddc(adapter))
return NULL;
 
edid = drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
-- 
2.1.4

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

[PATCH v2 1/4] drm: move edid property update and add modes out of edid firmware loader

[Jani Nikula]

Make the firmware loader more generic and generally useful.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid_load.c| 17 -
 drivers/gpu/drm/drm_probe_helper.c |  8 +++-
 include/drm/drm_edid.h |  7 ---
 3 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 622f788bff46..1c0495acf341 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -256,15 +256,14 @@ static void *edid_load(struct drm_connector *connector, 
const char *name,
return edid;
 }
 
-int drm_load_edid_firmware(struct drm_connector *connector)
+struct edid *drm_load_edid_firmware(struct drm_connector *connector)
 {
const char *connector_name = connector->name;
char *edidname, *last, *colon, *fwstr, *edidstr, *fallback = NULL;
-   int ret;
struct edid *edid;
 
if (edid_firmware[0] == '\0')
-   return 0;
+   return ERR_PTR(-ENOENT);
 
/*
 * If there are multiple edid files specified and separated
@@ -293,7 +292,7 @@ int drm_load_edid_firmware(struct drm_connector *connector)
if (!edidname) {
if (!fallback) {
kfree(fwstr);
-   return 0;
+   return ERR_PTR(-ENOENT);
}
edidname = fallback;
}
@@ -305,13 +304,5 @@ int drm_load_edid_firmware(struct drm_connector *connector)
edid = edid_load(connector, edidname, connector_name);
kfree(fwstr);
 
-   if (IS_ERR_OR_NULL(edid))
-   return 0;
-
-   drm_mode_connector_update_edid_property(connector, edid);
-   ret = drm_add_edid_modes(connector, edid);
-   drm_edid_to_eld(connector, edid);
-   kfree(edid);
-
-   return ret;
+   return edid;
 }
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 93381454bdf7..358957118ca9 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -311,7 +311,13 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
count = drm_add_edid_modes(connector, edid);
drm_edid_to_eld(connector, edid);
} else {
-   count = drm_load_edid_firmware(connector);
+   struct edid *edid = drm_load_edid_firmware(connector);
+   if (!IS_ERR_OR_NULL(edid)) {
+   drm_mode_connector_update_edid_property(connector, 
edid);
+   count = drm_add_edid_modes(connector, edid);
+   drm_edid_to_eld(connector, edid);
+   kfree(edid);
+   }
if (count == 0)
count = (*connector_funcs->get_modes)(connector);
}
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 43fb0ac5eb9c..a55eea4afb61 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -331,11 +331,12 @@ int drm_av_sync_delay(struct drm_connector *connector,
  const struct drm_display_mode *mode);
 
 #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
-int drm_load_edid_firmware(struct drm_connector *connector);
+struct edid *drm_load_edid_firmware(struct drm_connector *connector);
 #else
-static inline int drm_load_edid_firmware(struct drm_connector *connector)
+static inline struct edid *
+drm_load_edid_firmware(struct drm_connector *connector)
 {
-   return 0;
+   return ERR_PTR(-ENOENT);
 }
 #endif
 
-- 
2.1.4

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

[PATCH v2 2/4] drm: do not debug log about missing CEA extensions on NULL edid

[Jani Nikula]

Make the drm_edid_to_eld() function useful for resetting, not just
setting, the ELD and HDMI VSDB data, without debug warnings about
missing CEA extensions.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 24e7b282f16c..4bb50e0e7110 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3437,6 +3437,9 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
connector->video_latency[1] = 0;
connector->audio_latency[1] = 0;
 
+   if (!edid)
+   return;
+
cea = drm_find_cea_extension(edid);
if (!cea) {
DRM_DEBUG_KMS("ELD: no CEA Extension found\n");
-- 
2.1.4

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

[PATCH v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Jani Nikula]

Handle debugfs override edid and firmware edid at the low level to
transparently and completely replace the real edid. Previously, we
practically only used the modes from the override EDID, and none of the
other data. This also prevents actual EDID reads when the EDID is to be
overridden, but retains the DDC probe.

Move firmware EDID loading from helper to core, as the functionality
moves to lower level as well. This will result in a change of module
parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
arguably makes more sense anyway.

FIXME: validate override edid, deduplicate firmware edid validation.

v2: move firmware loading to core

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/Kconfig|  2 +-
 drivers/gpu/drm/Makefile   |  2 +-
 drivers/gpu/drm/drm_edid.c | 15 +++
 drivers/gpu/drm/drm_probe_helper.c | 19 +--
 4 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 90bc65d07a35..f983ef60299c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -101,7 +101,7 @@ config DRM_FBDEV_EMULATION
 
 config DRM_LOAD_EDID_FIRMWARE
bool "Allow to specify an EDID data set instead of probing for it"
-   depends on DRM_KMS_HELPER
+   depends on DRM
help
  Say Y here, if you want to use EDID data to be loaded from the
  /lib/firmware directory or one of the provided built-in
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 92de3991fa56..a10ac095608f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -27,13 +27,13 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
+drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o
 
-drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
 drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e1743ab276dc..4007998d5ce3 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector 
*connector,
  * level, drivers must make all reasonable efforts to expose it as an I2C
  * adapter and use drm_get_edid() instead of abusing this function.
  *
+ * The EDID may be overridden using debugfs override_edid or firmare EDID
+ * (drm_load_edid_firmware()), in this priority order. Having either of them
+ * bypasses actual EDID reads.
+ *
  * Return: Pointer to valid EDID or NULL if we couldn't find any.
  */
 struct edid *drm_do_get_edid(struct drm_connector *connector,
@@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
 {
int i, j = 0, valid_extensions = 0;
u8 *edid, *new;
+   struct edid *override = NULL;
+
+   if (connector->override_edid)
+   override = drm_edid_duplicate((const struct edid *)
+ connector->edid_blob_ptr->data);
+
+   if (!override)
+   override = drm_load_edid_firmware(connector);
+
+   if (!IS_ERR_OR_NULL(override))
+   return override;
 
if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
return NULL;
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 358957118ca9..871326cbc465 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, bool 
force)
  *drm_mode_probed_add(). New modes start their life with status as OK.
  *Modes are added from a single source using the following priority order.
  *
- *- debugfs 'override_edid' (used for testing only)
- *- firmware EDID (drm_load_edid_firmware())
  *- _connector_helper_funcs.get_modes vfunc
  *- if the connector status is connector_status_connected, standard
  *  VESA DMT modes up to 1024x768 are automatically added
@@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
goto prune;
}
 
-   if (connector->override_edid) {
-   struct edid *edid = (struct edid *) 
connector->edid_blob_ptr->data;
-
-   count = drm_add_edid_modes(connector, edid);
-   drm_edid_to_eld(connector, edid);
-   } else {
-   

Re: [PATCH v2] drm/color: Document CTM eqations

[Daniel Stone]

Hi,

On 17 February 2017 at 14:56, Ville Syrjälä
 wrote:
> On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote:
>> If we're talking fixed point reprsentation, ChromeOS is using this :
>>
>> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice=209
>
> So it's already using the sign+magnitude stuff. Which presumably
> means we can't change it to two's complement anymore :( Maybe we add a
> CTM2 property ;)

I wouldn't be so sure; AFAIK it only ships on platforms where the
kernel is also built from the same tree, and generally where the
support is backported anyway. So it would be possible to atomically
land a change to CrOS such that the kernels and Chrome move together
to a changed representation.

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

[PATCH] drm: add drm_get_connector_force_name

[Jani Nikula]

Follow the naming in debugfs also for logging, add "unknown" for values
beyond the enumerated ones.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_connector.c | 41 +
 drivers/gpu/drm/drm_debugfs.c   | 24 +---
 include/drm/drm_connector.h |  1 +
 3 files changed, 27 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 45464c8b797d..36ef9be17204 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -128,22 +128,8 @@ static void drm_connector_get_cmdline_mode(struct 
drm_connector *connector)
return;
 
if (mode->force) {
-   const char *s;
-
-   switch (mode->force) {
-   case DRM_FORCE_OFF:
-   s = "OFF";
-   break;
-   case DRM_FORCE_ON_DIGITAL:
-   s = "ON - dig";
-   break;
-   default:
-   case DRM_FORCE_ON:
-   s = "ON";
-   break;
-   }
-
-   DRM_INFO("forcing %s connector %s\n", connector->name, s);
+   DRM_INFO("forcing %s connector %s\n", connector->name,
+drm_get_connector_force_name(mode->force));
connector->force = mode->force;
}
 
@@ -488,6 +474,29 @@ const char *drm_get_connector_status_name(enum 
drm_connector_status status)
 }
 EXPORT_SYMBOL(drm_get_connector_status_name);
 
+/**
+ * drm_get_connector_force_name - return a string for connector force
+ * @force: connector force to get name of
+ *
+ * Returns: const pointer to name.
+ */
+const char *drm_get_connector_force_name(enum drm_connector_force force)
+{
+   switch (force) {
+   case DRM_FORCE_UNSPECIFIED:
+   return "unspecified";
+   case DRM_FORCE_OFF:
+   return "off";
+   case DRM_FORCE_ON:
+   return "on";
+   case DRM_FORCE_ON_DIGITAL:
+   return "digital";
+   default:
+   return "unknown";
+   }
+}
+EXPORT_SYMBOL(drm_get_connector_force_name);
+
 #ifdef CONFIG_LOCKDEP
 static struct lockdep_map connector_list_iter_dep_map = {
.name = "drm_connector_list_iter"
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 2290a74a6e46..a6385d4b598b 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -261,30 +261,8 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
 static int connector_show(struct seq_file *m, void *data)
 {
struct drm_connector *connector = m->private;
-   const char *status;
 
-   switch (connector->force) {
-   case DRM_FORCE_ON:
-   status = "on\n";
-   break;
-
-   case DRM_FORCE_ON_DIGITAL:
-   status = "digital\n";
-   break;
-
-   case DRM_FORCE_OFF:
-   status = "off\n";
-   break;
-
-   case DRM_FORCE_UNSPECIFIED:
-   status = "unspecified\n";
-   break;
-
-   default:
-   return 0;
-   }
-
-   seq_puts(m, status);
+   seq_puts(m, drm_get_connector_force_name(connector->force));
 
return 0;
 }
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index e5e1eddd19fb..2bf9f46808d3 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -817,6 +817,7 @@ static inline void drm_connector_unreference(struct 
drm_connector *connector)
 }
 
 const char *drm_get_connector_status_name(enum drm_connector_status status);
+const char *drm_get_connector_force_name(enum drm_connector_force force);
 const char *drm_get_subpixel_order_name(enum subpixel_order order);
 const char *drm_get_dpms_name(int val);
 const char *drm_get_dvi_i_subconnector_name(int val);
-- 
2.1.4

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

Re: [PATCH v2] drm/color: Document CTM eqations

[Lionel Landwerlin]

On 17/02/17 14:56, Ville Syrjälä wrote:

On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote:

On 17/02/17 13:54, Brian Starkey wrote:

What's the verdict? We've got [1] which is about to become another
(driver) implementation - better to change before that merges than
after I guess.

-Brian

[1] https://lkml.org/lkml/2017/2/13/304

On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote:

Hi,

On 15 February 2017 at 11:39, Ville Syrjälä
 wrote:

On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:

On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
 wrote:

Hmm. Two's complement is what I was thinking it is. Which shows that
I never managed to read the code in any detail. Definitely needs to
be documented properly.

That sounds supremely backwards. I guess we can't fix this anymore?

I have no idea. Anyone else?

I don't know of any implementation using this; maybe closed Intel
Android stuff? Certainly GitHub showed no-one using it, and neither X
nor Weston/Mutter are using it yet.

Cheers,
Daniel

If we're talking fixed point reprsentation, ChromeOS is using this :

https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice=209

So it's already using the sign+magnitude stuff. Which presumably
means we can't change it to two's complement anymore :( Maybe we add a
CTM2 property ;)

Using sign+magnitude definitely looks rather inefficient since there's
a branch inside the loop. With two's complement you wouldn't need that
thing slowing you down.

If you're seriously considering that, you might also want to bump struct 
drm_color_lut to use 32bits fields.

It seems some people have concerned about HDR.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/color: Document CTM eqations

[Ville Syrjälä]

On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote:
> On 17/02/17 13:54, Brian Starkey wrote:
> > What's the verdict? We've got [1] which is about to become another
> > (driver) implementation - better to change before that merges than
> > after I guess.
> >
> > -Brian
> >
> > [1] https://lkml.org/lkml/2017/2/13/304
> >
> > On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote:
> >> Hi,
> >>
> >> On 15 February 2017 at 11:39, Ville Syrjälä
> >>  wrote:
> >>> On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:
>  On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
>   wrote:
>  > Hmm. Two's complement is what I was thinking it is. Which shows that
>  > I never managed to read the code in any detail. Definitely needs to
>  > be documented properly.
> 
>  That sounds supremely backwards. I guess we can't fix this anymore?
> >>>
> >>> I have no idea. Anyone else?
> >>
> >> I don't know of any implementation using this; maybe closed Intel
> >> Android stuff? Certainly GitHub showed no-one using it, and neither X
> >> nor Weston/Mutter are using it yet.
> >>
> >> Cheers,
> >> Daniel
> >
> If we're talking fixed point reprsentation, ChromeOS is using this :
> 
> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice=209

So it's already using the sign+magnitude stuff. Which presumably
means we can't change it to two's complement anymore :( Maybe we add a
CTM2 property ;)

Using sign+magnitude definitely looks rather inefficient since there's
a branch inside the loop. With two's complement you wouldn't need that
thing slowing you down.

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

Re: [PATCH 17/35] drivers/gpu: Convert remaining uses of pr_warning to pr_warn

[Christian König]

Am 17.02.2017 um 08:11 schrieb Joe Perches:

To enable eventual removal of pr_warning

This makes pr_warn use consistent for drivers/gpu

Prior to this patch, there were 15 uses of pr_warning and
20 uses of pr_warn in drivers/gpu

Signed-off-by: Joe Perches 


Acked-by: Christian König .


---
  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c |  2 +-
  drivers/gpu/drm/amd/powerplay/inc/pp_debug.h |  2 +-
  drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c  |  4 ++--
  drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c   | 14 +++---
  drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c |  4 ++--
  drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c |  4 ++--
  6 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index b1de9e8ccdbc..83266408634e 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -1535,7 +1535,7 @@ static int smu7_get_evv_voltages(struct pp_hwmgr *hwmgr)
if (vddc >= 2000 || vddc == 0)
return -EINVAL;
} else {
-   pr_warning("failed to retrieving EVV 
voltage!\n");
+   pr_warn("failed to retrieving EVV 
voltage!\n");
continue;
}
  
diff --git a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h

index 072880130cfb..f3f9ebb631a5 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
@@ -37,7 +37,7 @@
  #define PP_ASSERT_WITH_CODE(cond, msg, code)  \
do {\
if (!(cond)) {  \
-   pr_warning("%s\n", msg);  \
+   pr_warn("%s\n", msg); \
code;   \
}   \
} while (0)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
index 0f7a77b7312e..5450f5ef8e89 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
@@ -2131,7 +2131,7 @@ uint32_t fiji_get_offsetof(uint32_t type, uint32_t member)
return offsetof(SMU73_Discrete_DpmTable, 
LowSclkInterruptThreshold);
}
}
-   pr_warning("can't get the offset of type %x member %x\n", type, member);
+   pr_warn("can't get the offset of type %x member %x\n", type, member);
return 0;
  }
  
@@ -2156,7 +2156,7 @@ uint32_t fiji_get_mac_definition(uint32_t value)

return SMU73_MAX_LEVELS_MVDD;
}
  
-	pr_warning("can't get the mac of %x\n", value);

+   pr_warn("can't get the mac of %x\n", value);
return 0;
  }
  
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c

index ad82161df831..51adf04ab4b3 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
@@ -122,7 +122,7 @@ static void iceland_initialize_power_tune_defaults(struct 
pp_hwmgr *hwmgr)
break;
default:
smu_data->power_tune_defaults = _iceland;
-   pr_warning("Unknown V.I. Device ID.\n");
+   pr_warn("Unknown V.I. Device ID.\n");
break;
}
return;
@@ -378,7 +378,7 @@ static int iceland_get_std_voltage_value_sidd(struct 
pp_hwmgr *hwmgr,
return -EINVAL);
  
  	if (NULL == hwmgr->dyn_state.cac_leakage_table) {

-   pr_warning("CAC Leakage Table does not exist, using vddc.\n");
+   pr_warn("CAC Leakage Table does not exist, using vddc.\n");
return 0;
}
  
@@ -394,7 +394,7 @@ static int iceland_get_std_voltage_value_sidd(struct pp_hwmgr *hwmgr,

*lo = 
hwmgr->dyn_state.cac_leakage_table->entries[v_index].Vddc * VOLTAGE_SCALE;
*hi = 
(uint16_t)(hwmgr->dyn_state.cac_leakage_table->entries[v_index].Leakage * 
VOLTAGE_SCALE);
} else {
-   pr_warning("Index from SCLK/VDDC Dependency Table 
exceeds the CAC Leakage Table index, using maximum index from CAC table.\n");
+   pr_warn("Index from SCLK/VDDC Dependency Table 
exceeds the CAC Leakage Table index, using maximum index from CAC table.\n");
*lo = 
hwmgr->dyn_state.cac_leakage_table->entries[hwmgr->dyn_state.cac_leakage_table->count
 - 1].Vddc * VOLTAGE_SCALE;
  

Re: [PATCH v2] drm/color: Document CTM eqations

[Lionel Landwerlin]

On 17/02/17 13:54, Brian Starkey wrote:

What's the verdict? We've got [1] which is about to become another
(driver) implementation - better to change before that merges than
after I guess.

-Brian

[1] https://lkml.org/lkml/2017/2/13/304

On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote:

Hi,

On 15 February 2017 at 11:39, Ville Syrjälä
 wrote:

On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:

On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
 wrote:
> Hmm. Two's complement is what I was thinking it is. Which shows that
> I never managed to read the code in any detail. Definitely needs to
> be documented properly.

That sounds supremely backwards. I guess we can't fix this anymore?


I have no idea. Anyone else?


I don't know of any implementation using this; maybe closed Intel
Android stuff? Certainly GitHub showed no-one using it, and neither X
nor Weston/Mutter are using it yet.

Cheers,
Daniel



If we're talking fixed point reprsentation, ChromeOS is using this :

https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice=209

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

[PATCH v1 1/2] of: add devm_ functions for populate and depopulate

[Benjamin Gaignard]

Lost of calls to of_platform_populate() are not unbalanced by a call
to of_platform_depopulate(). This create issues while drivers are
bind/unbind.

In way to solve those issues is to add devm_of_platform_populate()
which will call of_platform_depopulate() when the device is unbound
from the bus.

Signed-off-by: Benjamin Gaignard 
---
 drivers/of/platform.c   | 77 +
 include/linux/of_platform.h | 20 
 2 files changed, 97 insertions(+)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b8064bc..3dbebf7 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -571,6 +571,83 @@ void of_platform_depopulate(struct device *parent)
 }
 EXPORT_SYMBOL_GPL(of_platform_depopulate);
 
+static void devm_of_platform_populate_release(struct device *dev, void *res)
+{
+   of_platform_depopulate(*(struct device **)res);
+}
+
+/**
+ * devm_of_platform_populate() - Populate platform_devices from device tree 
data
+ * @dev: device that requested to populate from device tree data
+ * @root: parent of the first level to probe or NULL for the root of the tree
+ * @matches: match table, NULL to use the default
+ * @lookup: auxdata table for matching id and platform_data with device nodes
+ * @parent: parent to hook devices from, NULL for toplevel
+ *
+ * Similar to of_platform_populate(), but will automatically call
+ * of_platform_depopulate() when the device is unbound from the bus.
+ *
+ * Returns 0 on success, < 0 on failure.
+ */
+int devm_of_platform_populate(struct device *dev,
+ struct device_node *root,
+ const struct of_device_id *matches,
+ const struct of_dev_auxdata *lookup,
+ struct device *parent)
+{
+   struct device **ptr;
+   int ret;
+
+   ptr = devres_alloc(devm_of_platform_populate_release,
+  sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return -ENOMEM;
+
+   ret = of_platform_populate(root, matches, lookup, parent);
+   if (ret) {
+   devres_free(ptr);
+   } else {
+   *ptr = parent;
+   devres_add(dev, ptr);
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(devm_of_platform_populate);
+
+static int devm_of_platform_match(struct device *dev, void *res, void *data)
+{
+   struct device **ptr = res;
+
+   if (!ptr) {
+   WARN_ON(!ptr);
+   return 0;
+   }
+
+   return *ptr == data;
+}
+
+/**
+ * devm_of_platform_depopulate() - Remove devices populated from device tree
+ * @dev: device that requested to populate from device tree data
+ * @parent: device which children will be removed
+ *
+ * Complementary to devm_of_platform_populate(), this function removes children
+ * of the given device (and, recurrently, their children) that have been
+ * created from their respective device tree nodes (and only those,
+ * leaving others - eg. manually created - unharmed).
+ */
+void devm_of_platform_depopulate(struct device *dev, struct device *parent)
+{
+   int ret;
+
+   ret = devres_release(dev, devm_of_platform_populate_release,
+devm_of_platform_match, parent);
+
+   WARN_ON(ret);
+}
+EXPORT_SYMBOL_GPL(devm_of_platform_depopulate);
+
 #ifdef CONFIG_OF_DYNAMIC
 static int of_platform_notify(struct notifier_block *nb,
unsigned long action, void *arg)
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 956a100..282fae3 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -76,6 +76,14 @@ extern int of_platform_default_populate(struct device_node 
*root,
const struct of_dev_auxdata *lookup,
struct device *parent);
 extern void of_platform_depopulate(struct device *parent);
+
+extern int devm_of_platform_populate(struct device *dev,
+struct device_node *root,
+const struct of_device_id *matches,
+const struct of_dev_auxdata *lookup,
+struct device *parent);
+extern void devm_of_platform_depopulate(struct device *dev,
+   struct device *parent);
 #else
 static inline int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
@@ -91,6 +99,18 @@ static inline int of_platform_default_populate(struct 
device_node *root,
return -ENODEV;
 }
 static inline void of_platform_depopulate(struct device *parent) { }
+
+static inline int devm_of_platform_populate(struct device *dev,
+   struct device_node *root,
+   const struct of_device_id 

[PATCH v1 0/2] Introduce devm_of_platform_populate() helper

[Benjamin Gaignard]

Lost of calls to of_platform_populate() are not unbalanced by a call
to of_platform_depopulate(). This create issues while drivers are
bind/unbind.

In way to solve those issues is to add devm_of_platform_populate()
which will call of_platform_depopulate() when the device is unbound
from the bus. This also could make drivers more robust in case that
probe failed after calling of_platform_populate().

Benjamin Gaignard (2):
  of: add devm_ functions for populate and depopulate
  drm: sti: make driver use devm_of_platform_populate()

 drivers/gpu/drm/sti/sti_drv.c |  3 +-
 drivers/of/platform.c | 77 +++
 include/linux/of_platform.h   | 20 +++
 3 files changed, 98 insertions(+), 2 deletions(-)

-- 
1.9.1

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

[PATCH v1 2/2] drm: sti: make driver use devm_of_platform_populate()

[Benjamin Gaignard]

This make sure that of_platform_depopulate() is called if an error
occur in probe after populating the date from the device tree.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_drv.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index ff71e25..01ef9a4 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -438,7 +438,7 @@ static int sti_platform_probe(struct platform_device *pdev)
 
dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
 
-   of_platform_populate(node, NULL, NULL, dev);
+   devm_of_platform_populate(dev, node, NULL, NULL, dev);
 
child_np = of_get_next_available_child(node, NULL);
 
@@ -454,7 +454,6 @@ static int sti_platform_probe(struct platform_device *pdev)
 static int sti_platform_remove(struct platform_device *pdev)
 {
component_master_del(>dev, _ops);
-   of_platform_depopulate(>dev);
 
return 0;
 }
-- 
1.9.1

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

Re: [PATCH 2/3] drm: reset ELD if NULL edid is passed to drm_edid_to_eld

[Ville Syrjälä]

On Fri, Feb 17, 2017 at 04:02:02PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> > On Thu, Feb 16, 2017 at 12:36:43PM +0200, Jani Nikula wrote:
> >> Make the function useful for resetting, not just setting, the ELD.
> >> 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  drivers/gpu/drm/drm_edid.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 24e7b282f16c..362036360724 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -3430,6 +3430,9 @@ void drm_edid_to_eld(struct drm_connector 
> >> *connector, struct edid *edid)
> >>  
> >>memset(eld, 0, sizeof(connector->eld));
> >>  
> >> +  if (!edid)
> >> +  return;
> >> +
> >>connector->latency_present[0] = false;
> >>connector->latency_present[1] = false;
> >>connector->video_latency[0] = 0;
> >
> > /me thinks the check should be after all these.
> 
> D'oh!
> 
> > Hmm. Actually the cea ext block check below should be safe wrt.
> > edid==NULL, so not sure we need this at all.
> 
> I'd just like to be explicit and avoid the debug message on missing CEA
> extensions if the whole EDID is missing.

Fair enough.

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

Re: [PATCH 2/3] drm: reset ELD if NULL edid is passed to drm_edid_to_eld

[Jani Nikula]

On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> On Thu, Feb 16, 2017 at 12:36:43PM +0200, Jani Nikula wrote:
>> Make the function useful for resetting, not just setting, the ELD.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/drm_edid.c | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 24e7b282f16c..362036360724 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3430,6 +3430,9 @@ void drm_edid_to_eld(struct drm_connector *connector, 
>> struct edid *edid)
>>  
>>  memset(eld, 0, sizeof(connector->eld));
>>  
>> +if (!edid)
>> +return;
>> +
>>  connector->latency_present[0] = false;
>>  connector->latency_present[1] = false;
>>  connector->video_latency[0] = 0;
>
> /me thinks the check should be after all these.

D'oh!

> Hmm. Actually the cea ext block check below should be safe wrt.
> edid==NULL, so not sure we need this at all.

I'd just like to be explicit and avoid the debug message on missing CEA
extensions if the whole EDID is missing.

BR,
Jani.



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

Re: [PATCH v2] drm/color: Document CTM eqations

[Brian Starkey]

What's the verdict? We've got [1] which is about to become another
(driver) implementation - better to change before that merges than
after I guess.

-Brian

[1] https://lkml.org/lkml/2017/2/13/304

On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote:

Hi,

On 15 February 2017 at 11:39, Ville Syrjälä
 wrote:

On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:

On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
 wrote:
> Hmm. Two's complement is what I was thinking it is. Which shows that
> I never managed to read the code in any detail. Definitely needs to
> be documented properly.

That sounds supremely backwards. I guess we can't fix this anymore?


I have no idea. Anyone else?


I don't know of any implementation using this; maybe closed Intel
Android stuff? Certainly GitHub showed no-one using it, and neither X
nor Weston/Mutter are using it yet.

Cheers,
Daniel

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

[GIT PULL FOR v4.12] Bye bye drm_platform midlayer

[Laurent Pinchart]

Hi Dave,

The following changes since commit 9ca70356a9260403c1bda40d942935e55d00c11c:

  Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04 +1000)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git drm/next/platform

for you to fetch changes up to 76adb460fd939756db689f238d5c2ddb45469705:

  drm: Remove the struct drm_device platformdev field (2017-02-17 15:27:24 
+0200)


Laurent Pinchart (4):
  drm: shmobile: Perform initialization/cleanup at probe/remove time
  drm: exynos: Perform initialization/cleanup at probe/remove time
  drm: Remove unused drm_platform midlayer
  drm: Remove the struct drm_device platformdev field

 Documentation/gpu/drm-internals.rst   |   3 -
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/armada/armada_drv.c   |   3 +-
 drivers/gpu/drm/drm_platform.c|  87 ---
 drivers/gpu/drm/exynos/exynos_dp.c|   1 -
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   |   1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 241 +++--
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   |   1 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   3 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   1 -
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   1 -
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |   2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c   |   2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c  |   2 +-
 drivers/gpu/drm/msm/msm_drv.c |   1 -
 drivers/gpu/drm/nouveau/nouveau_drm.c |   3 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c |   7 +-
 drivers/gpu/drm/shmobile/shmob_drm_drv.c  | 204 
 drivers/gpu/drm/sti/sti_drv.c |   2 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.c   |   1 -
 include/drm/drmP.h|   4 -
 21 files changed, 236 insertions(+), 336 deletions(-)
 delete mode 100644 drivers/gpu/drm/drm_platform.c

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

[Rafael J. Wysocki]

On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches  wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning for that directory tree and pr_warn is
> not used in tools/.
>
> Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.

Sorry about asking if that has been asked already.

Wouldn't it be slightly less intrusive to simply redefined
pr_warning() as a synonym for pr_warn()?

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

[PATCH 2/7] drm/sun4i: Fix up error path cleanup for master bind function

[Chen-Yu Tsai]

The master bind function calls numerous drm functions which initialize
underlying structures. It also tries to bind the various components
of the display pipeline, some of which may add additional drm objects.

This patch adds proper cleanup functions in the error path of the
master bind function.

This requires the patch "drm/sun4i: Move drm_mode_config_cleanup call
to main driver", which splits out drm_mode_config_cleanup from
sun4i_framebuffer_free so we can call it separately.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 99a0f1861be2..8e777167bca4 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -136,7 +136,7 @@ static int sun4i_drv_bind(struct device *dev)
ret = component_bind_all(drm->dev, drm);
if (ret) {
dev_err(drm->dev, "Couldn't bind all pipelines components\n");
-   goto free_drm;
+   goto cleanup_mode_config;
}
 
/* Create our layers */
@@ -144,7 +144,7 @@ static int sun4i_drv_bind(struct device *dev)
if (IS_ERR(drv->layers)) {
dev_err(drm->dev, "Couldn't create the planes\n");
ret = PTR_ERR(drv->layers);
-   goto free_drm;
+   goto cleanup_mode_config;
}
 
/* Create our CRTC */
@@ -152,7 +152,7 @@ static int sun4i_drv_bind(struct device *dev)
if (!drv->crtc) {
dev_err(drm->dev, "Couldn't create the CRTC\n");
ret = -EINVAL;
-   goto free_drm;
+   goto cleanup_mode_config;
}
drm->irq_enabled = true;
 
@@ -164,7 +164,7 @@ static int sun4i_drv_bind(struct device *dev)
if (IS_ERR(drv->fbdev)) {
dev_err(drm->dev, "Couldn't create our framebuffer\n");
ret = PTR_ERR(drv->fbdev);
-   goto free_drm;
+   goto cleanup_mode_config;
}
 
/* Enable connectors polling */
@@ -172,10 +172,16 @@ static int sun4i_drv_bind(struct device *dev)
 
ret = drm_dev_register(drm, 0);
if (ret)
-   goto free_drm;
+   goto finish_poll;
 
return 0;
 
+finish_poll:
+   drm_kms_helper_poll_fini(drm);
+   sun4i_framebuffer_free(drm);
+cleanup_mode_config:
+   drm_mode_config_cleanup(drm);
+   drm_vblank_cleanup(drm);
 free_drm:
drm_dev_unref(drm);
return ret;
-- 
2.11.0

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

[PATCH 0/7] drm/sun4i: Various fixes and cleanups part 1

[Chen-Yu Tsai]

Hi Maxime,

This is the first bunch of fixes for the sun4i drm driver. This is part
of the cleanup I am doing towards making the driver support multiple
display pipelines.

Patch 1 moves the drm_mode_config_cleanup call from sun4i_framebuffer_free
to be called directly in sun4i_drv_unbind. This is needed for patch 2, so
it doesn't get called twice.

Patch 2 adds proper clean up to the error return path in sun4i_drv_bind.

Patch 3 adds a check for drm_vblank_init's return value. It can fail if
no memory is available.

Patch 4 fixes the element size passed to kcalloc. Previously we were
allocating too much memory.

Patch 5 drops a useless assignment.

Patch 6 makes sun4i_layers_init actually store the created layers in the
list that it returns. This one was particularly nasty.

Patch 7 makes sun4i_crtc_init pass back error codes.

We probably don't need to tag stable for these. Patch 1 and 2 fix up
possible memory and object leakage, but unless the user keeps unloading
and loading the modules, it won't leak past a few times.

Regards
ChenYu


Chen-Yu Tsai (7):
  drm/sun4i: Move drm_mode_config_cleanup call to main driver
  drm/sun4i: Fix up error path cleanup for master bind function
  drm/sun4i: Check return value of drm_vblank_init
  drm/sun4i: Fix kcalloc element size in sun4i_layers_init
  drm/sun4i: Drop useless assignment in sun4i_layers_init
  drm/sun4i: Save newly created layer in layers array in
sun4i_layers_init
  drm/sun4i: Make sun4i_crtc_init return ERR_PTR style error codes

 drivers/gpu/drm/sun4i/sun4i_crtc.c|  4 ++--
 drivers/gpu/drm/sun4i/sun4i_drv.c | 27 +++
 drivers/gpu/drm/sun4i/sun4i_framebuffer.c |  1 -
 drivers/gpu/drm/sun4i/sun4i_layer.c   |  5 +++--
 4 files changed, 24 insertions(+), 13 deletions(-)

-- 
2.11.0

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

[PATCH 7/7] drm/sun4i: Make sun4i_crtc_init return ERR_PTR style error codes

[Chen-Yu Tsai]

sun4i_crtc_init can fail for a number of reasons. Instead of returning
a NULL pointer when it fails, pass back the encountered error using
ERR_PTR.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_crtc.c | 4 ++--
 drivers/gpu/drm/sun4i/sun4i_drv.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c 
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 4a192210574f..4e2e89c3104f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -121,7 +121,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm)
 
scrtc = devm_kzalloc(drm->dev, sizeof(*scrtc), GFP_KERNEL);
if (!scrtc)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
scrtc->drv = drv;
 
ret = drm_crtc_init_with_planes(drm, >crtc,
@@ -131,7 +131,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm)
NULL);
if (ret) {
dev_err(drm->dev, "Couldn't init DRM CRTC\n");
-   return NULL;
+   return ERR_PTR(ret);
}
 
drm_crtc_helper_add(>crtc, _crtc_helper_funcs);
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 63c46643fdd1..fc6ef4066c59 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -153,9 +153,9 @@ static int sun4i_drv_bind(struct device *dev)
 
/* Create our CRTC */
drv->crtc = sun4i_crtc_init(drm);
-   if (!drv->crtc) {
+   if (IS_ERR(drv->crtc)) {
dev_err(drm->dev, "Couldn't create the CRTC\n");
-   ret = -EINVAL;
+   ret = PTR_ERR(drv->crtc);
goto cleanup_mode_config;
}
drm->irq_enabled = true;
-- 
2.11.0

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

[PATCH 1/7] drm/sun4i: Move drm_mode_config_cleanup call to main driver

[Chen-Yu Tsai]

drm_mode_config_cleanup is the complement of drm_mode_config_init, which
is called in the bind function of sun4i_drv. drm_mode_config_cleanup
should be put in the unbind function to match.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
 drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 4ce665349f6b..99a0f1861be2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -188,6 +188,7 @@ static void sun4i_drv_unbind(struct device *dev)
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
sun4i_framebuffer_free(drm);
+   drm_mode_config_cleanup(drm);
drm_vblank_cleanup(drm);
drm_dev_unref(drm);
 }
diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c 
b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
index 8b6ce619ad81..0c72b54c047d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
@@ -50,5 +50,4 @@ void sun4i_framebuffer_free(struct drm_device *drm)
struct sun4i_drv *drv = drm->dev_private;
 
drm_fbdev_cma_fini(drv->fbdev);
-   drm_mode_config_cleanup(drm);
 }
-- 
2.11.0

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

[PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

[Joe Perches]

There are ~4300 uses of pr_warn and ~250 uses of the older
pr_warning in the kernel source tree.

Make the use of pr_warn consistent across all kernel files.

This excludes all files in tools/ as there is a separate
define pr_warning for that directory tree and pr_warn is
not used in tools/.

Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.

Miscellanea:

o Coalesce formats and realign arguments

Some files not compiled - no cross-compilers

Joe Perches (35):
  alpha: Convert remaining uses of pr_warning to pr_warn
  ARM: ep93xx: Convert remaining uses of pr_warning to pr_warn
  arm64: Convert remaining uses of pr_warning to pr_warn
  arch/blackfin: Convert remaining uses of pr_warning to pr_warn
  ia64: Convert remaining use of pr_warning to pr_warn
  powerpc: Convert remaining uses of pr_warning to pr_warn
  sh: Convert remaining uses of pr_warning to pr_warn
  sparc: Convert remaining use of pr_warning to pr_warn
  x86: Convert remaining uses of pr_warning to pr_warn
  drivers/acpi: Convert remaining uses of pr_warning to pr_warn
  block/drbd: Convert remaining uses of pr_warning to pr_warn
  gdrom: Convert remaining uses of pr_warning to pr_warn
  drivers/char: Convert remaining use of pr_warning to pr_warn
  clocksource: Convert remaining use of pr_warning to pr_warn
  drivers/crypto: Convert remaining uses of pr_warning to pr_warn
  fmc: Convert remaining use of pr_warning to pr_warn
  drivers/gpu: Convert remaining uses of pr_warning to pr_warn
  drivers/ide: Convert remaining uses of pr_warning to pr_warn
  drivers/input: Convert remaining uses of pr_warning to pr_warn
  drivers/isdn: Convert remaining uses of pr_warning to pr_warn
  drivers/macintosh: Convert remaining uses of pr_warning to pr_warn
  drivers/media: Convert remaining use of pr_warning to pr_warn
  drivers/mfd: Convert remaining uses of pr_warning to pr_warn
  drivers/mtd: Convert remaining uses of pr_warning to pr_warn
  drivers/of: Convert remaining uses of pr_warning to pr_warn
  drivers/oprofile: Convert remaining uses of pr_warning to pr_warn
  drivers/platform: Convert remaining uses of pr_warning to pr_warn
  drivers/rapidio: Convert remaining use of pr_warning to pr_warn
  drivers/scsi: Convert remaining use of pr_warning to pr_warn
  drivers/sh: Convert remaining use of pr_warning to pr_warn
  drivers/tty: Convert remaining uses of pr_warning to pr_warn
  drivers/video: Convert remaining uses of pr_warning to pr_warn
  kernel/trace: Convert remaining uses of pr_warning to pr_warn
  lib: Convert remaining uses of pr_warning to pr_warn
  sound/soc: Convert remaining uses of pr_warning to pr_warn

 arch/alpha/kernel/perf_event.c |  4 +-
 arch/arm/mach-ep93xx/core.c|  4 +-
 arch/arm64/include/asm/syscall.h   |  8 ++--
 arch/arm64/kernel/hw_breakpoint.c  |  8 ++--
 arch/arm64/kernel/smp.c|  4 +-
 arch/blackfin/kernel/nmi.c |  2 +-
 arch/blackfin/kernel/ptrace.c  |  2 +-
 arch/blackfin/mach-bf533/boards/stamp.c|  2 +-
 arch/blackfin/mach-bf537/boards/cm_bf537e.c|  2 +-
 arch/blackfin/mach-bf537/boards/cm_bf537u.c|  2 +-
 arch/blackfin/mach-bf537/boards/stamp.c|  2 +-
 arch/blackfin/mach-bf537/boards/tcm_bf537.c|  2 +-
 arch/blackfin/mach-bf561/boards/cm_bf561.c |  2 +-
 arch/blackfin/mach-bf561/boards/ezkit.c|  2 +-
 arch/blackfin/mm/isram-driver.c|  4 +-
 arch/ia64/kernel/setup.c   |  6 +--
 arch/powerpc/kernel/pci-common.c   |  4 +-
 arch/powerpc/mm/init_64.c  |  5 +--
 arch/powerpc/mm/mem.c  |  3 +-
 arch/powerpc/platforms/512x/mpc512x_shared.c   |  4 +-
 arch/powerpc/platforms/85xx/socrates_fpga_pic.c|  7 ++--
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |  2 +-
 arch/powerpc/platforms/pasemi/dma_lib.c|  4 +-
 arch/powerpc/platforms/powernv/opal.c  |  8 ++--
 arch/powerpc/platforms/powernv/pci-ioda.c  | 10 ++---
 arch/powerpc/platforms/ps3/device-init.c   | 14 +++
 arch/powerpc/platforms/ps3/mm.c|  4 +-
 arch/powerpc/platforms/ps3/os-area.c   |  2 +-
 arch/powerpc/platforms/pseries/iommu.c |  8 ++--
 arch/powerpc/platforms/pseries/setup.c |  4 +-
 arch/powerpc/sysdev/fsl_pci.c  |  9 ++---
 arch/powerpc/sysdev/mpic.c | 10 ++---
 arch/powerpc/sysdev/xics/icp-native.c  | 10 ++---
 arch/powerpc/sysdev/xics/ics-opal.c|  4 +-
 arch/powerpc/sysdev/xics/ics-rtas.c|  4 +-
 arch/powerpc/sysdev/xics/xics-common.c |  8 ++--
 arch/sh/boards/mach-sdk7786/nmi.c  |  2 +-
 arch/sh/drivers/pci/fixups-sdk7786.c   |  2 +-
 arch/sh/kernel/io_trapped.c

[PATCH 4/7] drm/sun4i: Fix kcalloc element size in sun4i_layers_init

[Chen-Yu Tsai]

In sun4i_layers_init we are allocating an array of pointers to struct
sun4i_layer:

layers = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes),
  sizeof(**layers), GFP_KERNEL);

The element size should be the size of an individual element of the
array. Change it to sizeof(*layers) to avoid wasting a lot of memory.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_layer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 5d53c977bca5..62552a356d66 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -140,7 +140,7 @@ struct sun4i_layer **sun4i_layers_init(struct drm_device 
*drm)
int i;
 
layers = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes),
- sizeof(**layers), GFP_KERNEL);
+ sizeof(*layers), GFP_KERNEL);
if (!layers)
return ERR_PTR(-ENOMEM);
 
-- 
2.11.0

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

Re: [PULL] mxsfb fixes

[Marek Vasut]

On 02/17/2017 03:41 AM, Dave Airlie wrote:
> On 16 February 2017 at 08:16, Marek Vasut  wrote:
>> Hi,
>>
>> I collected the MXSFB fixes, based on top of airlied/drm-fixes:
> 
> At this stage I'd rather not give these to Linus, can you rebase them onto
> drm-next, and resend, feel free to add stable cc's.
> 
> Fixes like this should really be getting to me sooner than rc8.

I know, sorry about that. I was totally overloaded in the past weeks.
What about getting them to rc1, any chance for that ?

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

[PATCH 3/7] drm/sun4i: Check return value of drm_vblank_init

[Chen-Yu Tsai]

drm_vblank_init can fail due to insufficient memory. Ignoring the error
and proceeding may cause the kernel to dereference an invalid pointer
when vblank is enabled.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 8e777167bca4..63c46643fdd1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -130,7 +130,11 @@ static int sun4i_drv_bind(struct device *dev)
}
drm->dev_private = drv;
 
-   drm_vblank_init(drm, 1);
+   /* drm_vblank_init calls kcalloc, which can fail */
+   ret = drm_vblank_init(drm, 1);
+   if (ret)
+   goto free_drm;
+
drm_mode_config_init(drm);
 
ret = component_bind_all(drm->dev, drm);
-- 
2.11.0

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

[PATCH] backport commit bb98e72adaf9d19719aba35f802d4836f5d5176c to 4.4.49 fixed i915 dsi init bug passed test on my Lenovo Miix 2 8 (Bay Trail Z3740)

[River Zhou]

commit bb98e72adaf9d19719aba35f802d4836f5d5176c
Author: Hans de Goede 
Date:   Fri Dec 2 15:29:04 2016 +0100

drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from 
vlv_init_display_clock_gating

On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
Once the i915 driver has successfully loaded, the panel can be disabled /
enabled without hitting this issue.

The getting stuck is caused by vlv_init_display_clock_gating() clearing
the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled
driving the DSI LCD by the BIOS.

Clearing this bit while DSI is in use is a known issue and
intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
as appropriate.

This commit modifies vlv_init_display_clock_gating() to leave the
DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck.

Changes in v2:
-Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and
comment

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede 
Reviewed-by: Ville Syrjälä 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20161202142904.25613-1-hdego...@redhat.com
Signed-off-by: Ville Syrjälä 
(cherry picked from commit 721d484563e1a51ada760089c490cbc47e909756)
Signed-off-by: Jani Nikula 

Signed-off-by: River Zhou 
---
 drivers/gpu/drm/i915/intel_pm.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3f80216..e7c1851 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6803,7 +6803,18 @@ static void ivybridge_init_clock_gating(struct 
drm_device *dev)
 
 static void vlv_init_display_clock_gating(struct drm_i915_private *dev_priv)
 {
-   I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
+u32 val;
+
+/*
+* On driver load, a pipe may be active and driving a DSI display.
+* Preserve DPOUNIT_CLOCK_GATE_DISABLE to avoid the pipe getting stuck
+* (and never recovering) in this case. intel_dsi_post_disable() will
+* clear it when we turn off the display.
+*/
+val = I915_READ(DSPCLK_GATE_D);
+val &= DPOUNIT_CLOCK_GATE_DISABLE;
+val |= VRHUNIT_CLOCK_GATE_DISABLE;
+I915_WRITE(DSPCLK_GATE_D, val);
 
/*
 * Disable trickle feed and enable pnd deadline calculation
-- 
2.7.4


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

[PATCH 5/7] drm/sun4i: Drop useless assignment in sun4i_layers_init

[Chen-Yu Tsai]

The assignment found in the main loop in sun4i_layers_init:

struct sun4i_layer *layer = layers[i];

is useless as it gets overwritten by the next line:

layer = sun4i_layer_init_one(drm, plane);

Drop the assignment.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_layer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 62552a356d66..92ecc967dcb1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -167,7 +167,7 @@ struct sun4i_layer **sun4i_layers_init(struct drm_device 
*drm)
 */
for (i = 0; i < ARRAY_SIZE(sun4i_backend_planes); i++) {
const struct sun4i_plane_desc *plane = _backend_planes[i];
-   struct sun4i_layer *layer = layers[i];
+   struct sun4i_layer *layer;
 
layer = sun4i_layer_init_one(drm, plane);
if (IS_ERR(layer)) {
-- 
2.11.0

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

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

[Geert Uytterhoeven]

Hi Rafael,

On Fri, Feb 17, 2017 at 1:27 PM, Rafael J. Wysocki  wrote:
> On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches  wrote:
>> There are ~4300 uses of pr_warn and ~250 uses of the older
>> pr_warning in the kernel source tree.
>>
>> Make the use of pr_warn consistent across all kernel files.
>>
>> This excludes all files in tools/ as there is a separate
>> define pr_warning for that directory tree and pr_warn is
>> not used in tools/.
>>
>> Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
>
> Sorry about asking if that has been asked already.
>
> Wouldn't it be slightly less intrusive to simply redefined
> pr_warning() as a synonym for pr_warn()?

That's already the case.

This series cleans up the cruft, so we can catch all users with
"git grep -w pr_warn".

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7] drm/sun4i: Save newly created layer in layers array in sun4i_layers_init

[Chen-Yu Tsai]

sun4i_layers_init allocates an array to store pointers to newly created
layers returned by sun4i_layer_init_one(), but fails to actually store
them. But it actually returns the empty array to unsuspecting users.

Save the pointers in the array, so that they may be used later.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_layer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 92ecc967dcb1..41bc0f860f5c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -183,6 +183,7 @@ struct sun4i_layer **sun4i_layers_init(struct drm_device 
*drm)
   
SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(plane->pipe));
 
layer->id = i;
+   layers[i] = layer;
};
 
return layers;
-- 
2.11.0

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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Emil Velikov]

On 17 February 2017 at 12:45, Tobias Jakobi
 wrote:
> Hello Maxime,
>
> Maxime Ripard wrote:
>> Hi,
>>
>> On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
>>> I was wondering about the following. Wasn't there some strict
>>> requirement about code going upstream, which also included that there
>>> was a full open-source driver stack for it?
>>>
>>> I don't see how this is the case for Mali, neither in the kernel, nor in
>>> userspace. I'm aware that the Mali kernel driver is open-source. But it
>>> is not upstream, maintained out of tree, and won't land upstream in its
>>> current form (no resemblence to a DRM driver at all). And let's not talk
>>> about the userspace part.
>>>
>>> So, why should this be here?
>>
>> The device tree is a representation of the hardware itself. The state
>> of the driver support doesn't change the hardware you're running on,
>> just like your BIOS/UEFI on x86 won't change the device it reports to
>> Linux based on whether it has a driver for it.
> Like Emil already said, the new bindings and the DT entries are solely
> introduced to support a proprietary out-of-tree module.
>
> The current workflow when introducing new DT entries is the following:
> - upstream a driver that uses the entries
> - THEN add the new entries
>
That's the ideal route that I was thinking of.

At the same time, if prominent DRM people believe that we can/should
turn a blind eye, so be it.
I'm not trying to make Maxime's life hard, but point out that things
feel iffy IMHO.

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

KMS backlight ABI proposition

[Martin Peres]

Hey everyone,

We have been working towards exposing the backlight as a KMS property 
instead of relying on the backlight drivers. We have CC:ed the people we 
have found to be the more likely to be interested in the discussion but 
please add everyone you think would have some experience with this issue.


== Introduction ==

We are trying to bring the same level of support for the backlight on 
both the xf86-video-intel and -modesetting DDX.


Looking into the situation of the backlight, we identified these 
problems which are almost show-stoppers for -modesetting and wayland 
compositors:


 - There is no mapping between the backlight driver and DRM-connectors. 
This means that, in case there are multiple backlight drivers, the 
userspace has to have knowledge of the machine to know which driver 
should be used. See the priority list for the intel driver [0].


 - The luminance curve of the backlight drivers is not specified, which 
can lead to a bad user experience: Little changes in the highest levels 
but drastic changes in the low levels.


 - Writing to the backlight driver still requires root rights. Given 
that the xserver and wayland compositors are now running root-less, this 
means we would need a complex dance involving a setuid helper [1].


Hans de Goede has already given a presentation about these issues at 
XDC2014. The slides are a good read[2].


[0] 
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n259


[1] 
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n348


[2] 
https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/backlight.pdf


== Proposal ==

Since David Hermann already worked on this and proposed what I consider 
being greats foundations for building towards a solution addressing the 
issues above, I will just ask you to read his original words:


https://lists.freedesktop.org/archives/dri-devel/2014-September/067984.html

== Open issues ==

Here are the open issues we have identified with the solution proposed 
by David:


  1) Backlight device interoperability: How far should we support
 mixing the backlight device and brightness property? Should it be
 unidirectional or bi-directional? What about the start-up value
 exposed by the brightness property?

  2) How many steps should be exposed: fixed or driver-dependent?

  3) Expected output curve: power? luminance? Simply monotonically
 increasing?

  4) Should the userspace be able to turn off the backlight? If so, how
 should it do it? What can we do to let the userspace distinguish
 between backlight off or on?

  5) Should we expose to the userspace what is the current backlight
 power?

Here is our current point of view on the matter:

=== 1) Backlight device interoperability ===

Since we need to keep backward compatibility of the backlight, we have 
to keep the current backlight drivers.


Here are possible options:

 - Exclusive access: Unregister a backlight device when the drm 
brightness property is requested/used;
 - Unidirectional access: When writing to the backlight property, 
update the backlight device;
 - Bi-directional access: Propagate back changes from the backlight 
device to the property's value.


Being bi-directional would be of course the best, but this requires that 
both drivers have the same number of steps, otherwise, we may write a 
value to the property, but get another one when reading it right after, 
due to the non-bijective nature of the transformation.


Uni-directional would work in all cases, with the caveat that mixing 
calls to the KMS property and the backlight device will not be supported 
(changes mades through the sysfs interface of the backlight driver will 
not be reflected in the KMS property). At boot time, we should however 
initialize the value of the backlight property with a value close to 
what is currently set in the backlight driver.


Giving exclusive access does not sound very good to me, as it would be 
hard for the userspace to deal with disappearing drivers...


=== 2) How many steps should be exposed ===

If the KMS property exposes the same number of steps as the backlight 
driver, it allows us to get a bijective function between the two 
interfaces, and allow a bi-directional communication. The downside of 
this is that it forces the userspace to deal with a variable number of 
steps which can range from 4 to 1k+. Also, the userspace would be able 
to handle the case where there are less steps than it would like to expose.


If the KMS property exposes a fixed number of steps (say 100), it 
becomes easy for the userspace to express the wanted brightness. 
However, on drivers exposing less than these 100 steps, we cannot 
guarantee that any change in the value will produce any change. If there 
is only one possible value (on or off), the user may be trying the 
change the brightness, a GUI would show what is the expected backlight 
state, but no change in the 

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Tobias Jakobi]

Hello Maxime,

Maxime Ripard wrote:
> Hi,
> 
> On Thu, Feb 16, 2017 at 01:28:24PM +0100, Tobias Jakobi wrote:
>> Hello,
>>
>> I'm not sure if I'm missing something here, but I don't see how this is
>> supposed to work.
>>
>> This just multiplies the height of the drm_mode_fb_cmd2 object with the
>> number of buffers. Let's say I have width=1024, height=768, then now I
>> have a framebuffer which has height=2304 (in the num_buffers=3 case). At
>> some point this FB is set as the primary plane, giving us a 1024x2304
>> mode. I don't think that this is intended.
>>
>> In my opinion this multi-buffer thing should touch drm_mode_fb_cmd2 at
>> all. The underlying BO should be larger, but not the FB itself. If this
>> is supposed to work, then the fbdev helpers should create as many FBs as
>> there are buffers, and then offset each of these FB into the BO.
> 
> This only increases the virtual resolution, not the visible one.
hmm, OK, I guess I need to test this again then. The last time I checked
such an approach was on vanilla-4.7.y IIRC. And there it failed miserably.


>> What I'm also not seeing is code that handles the fbdev's virtual
>> resolutions. After all num_buffers should only increase those. Same for
>> the panning ioctl().
> 
> This is already implemented through drm_fb_helper_pan_display.
Thanks, I'll take a look!

With best wishes,
Tobias


> 
> Maxime
> 

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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Tobias Jakobi]

Hello Maxime,

Maxime Ripard wrote:
> Hi,
> 
> On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
>> I was wondering about the following. Wasn't there some strict
>> requirement about code going upstream, which also included that there
>> was a full open-source driver stack for it?
>>
>> I don't see how this is the case for Mali, neither in the kernel, nor in
>> userspace. I'm aware that the Mali kernel driver is open-source. But it
>> is not upstream, maintained out of tree, and won't land upstream in its
>> current form (no resemblence to a DRM driver at all). And let's not talk
>> about the userspace part.
>>
>> So, why should this be here?
> 
> The device tree is a representation of the hardware itself. The state
> of the driver support doesn't change the hardware you're running on,
> just like your BIOS/UEFI on x86 won't change the device it reports to
> Linux based on whether it has a driver for it.
Like Emil already said, the new bindings and the DT entries are solely
introduced to support a proprietary out-of-tree module.

The current workflow when introducing new DT entries is the following:
- upstream a driver that uses the entries
- THEN add the new entries

I'm against adding such entries without having any upstream "consumer".


With best wishes,
Tobias


> So yes, unfortunately, we don't have a driver upstream at the
> moment. But that doesn't prevent us from describing the hardware
> accurately.
> 
> Maxime
> 

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

Re: [Intel-gfx] [PATCH v3 6/6] drm/i915: allow HDMI 2.0 clock rates

[Ander Conselvan De Oliveira]

On Fri, 2017-02-10 at 21:59 +0530, Shashank Sharma wrote:
> Geminilake has a native HDMI 2.0 controller, which is capable of
> driving clocks upto 594Mhz. This patch updates the max tmds clock
> limit for the same.
> 
> V2: rebase
> V3: rebase
> 
> Cc: Ander Conselvan De Oliveira 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 9970131..b1ddcc5 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1210,6 +1210,8 @@ static int intel_hdmi_source_max_tmds_clock(struct 
> drm_i915_private *dev_priv)
>  {
>   if (IS_G4X(dev_priv))
>   return 165000;
> + else if (IS_GEMINILAKE(dev_priv))
> + return 594000;
>   else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
>   return 30;
>   else

Reviewed-by: Ander Conselvan de Oliveira 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Laurent Pinchart]

Hi Maxime,

On Wednesday 15 Feb 2017 13:51:29 Maxime Ripard wrote:
> On Tue, Feb 14, 2017 at 11:25:08PM +0200, Laurent Pinchart wrote:
> > On Tuesday 14 Feb 2017 21:09:51 Daniel Vetter wrote:
> >> On Mon, Feb 13, 2017 at 11:20:51AM +, Daniel Stone wrote:
> >>> On 13 February 2017 at 10:54, Maxime Ripard wrote:
>  On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote:
> > On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote:
> >> This patch add a config to support to create multi buffer for cma
> >> fbdev. Such as double buffer and triple buffer.
> >> 
> >> Cma fbdev is convient to add a legency fbdev. And still many
> >> Android devices use fbdev now and at least double buffer is needed
> >> for these Android devices, so that a buffer flip can be operated. It
> >> will need some time for Android device vendors to abondon legency
> >> fbdev. So multi buffer for fbdev is needed.
> > 
> > How exactly do we expect Android to move away from fbdev if we add
> > features to the fbdev compat layer ? I'd much rather make it clear
> > to them that fbdev is a thing from the past and that they'd better
> > migrate now.
>  
>  If your point is that merging this patch will slow down the Android
>  move away from fbdev, I disagree with that (obviously).
>  
>  I don't care at all about Android on my platform of choice, but don't
>  see how that merging this patch will change anything.
>  
>  Let's be honest, Android trees typically have thousands of patches on
>  top of mainline. Do you think a simple, 15 LoC, patch will make any
>  difference to vendors? If they want to stay on fbdev and have that
>  feature, they'll just merge this patch, done.
> >>> 
> >>> So, in that case, why not just let them do that? They'd already have
> >>> to add patches to use this, surely; we don't have anything in mainline
> >>> kernels which allows people to actually use this larger allocation.
> >>> Apart from software mmap() and using panning to do flips, but I'm
> >>> taking it as a given that people shipping Android on their devices
> >>> aren't using software rendering.
> >> 
> >> I think we need to make a distinction between fbdev the subsystem in the
> >> kernel, and fbdev the uabi:
> >> 
> >> - fbdev the subsystem is completely dead in upstream. I think we have
> >>   full agreement on that.
> >> 
> >> - fbdev the uabi isn't, and if we can get more users from fbdev based
> >>   drivers to kms/atomic drivers by adding fairly simple stuff like this,
> >>   I'm all for it.
> > 
> > The real question, in my opinion, is how to get more users for the DRM/KMS
> > userspace API, to help killing the fbdev API. What's the incentive for
> > userspace to migrate if we tell them that we're going to support the fbdev
> > API forever, and will even go through the trouble of extending the
> > supported feature set ? I have a customer who wouldn't have migrated
> > their userspace to DRM/KMS if these two patches had been merged a few
> > years ago.
> 
> If those patches are not in, then I can see three ways to support old
> / deficient userspaces:
>   1) Carry those patches out of tree
>   2) Write an fbdev driver for the display engine
>   3) Rewrite the userspace components
> 
> While 3. would arguably be the best option, this isn't always one,
> unfortunately.

I agree that it's not a solution that can be deployed overnight, but it's 
clearly what we all (as in kernel community and system vendors) need to head 
towards.

> And as a community, I think 1 and 2 are not very good for us. 1. will
> drive away vendors from our community, undermining the effort we've
> been doing for a few years. And 2 will result in a driver we really
> don't want to merge (so useless), and even if it would out of tree,
> that would make it one less system / board / SoC *with* DRM/KMS APIs,
> reducing the interest of switching for application developpers.
> 
> If we really want to make people switch to DRM / KMS, we have to make
> it ubiquitous. And if we want to make it ubiquitous, we really want to
> have a transition period where people will have both APIs, supported
> in a decent enough way.

Haven't we had such a grace period already, until the fbdev subsystem stopped 
accepting new drivers ? It has hardly been an overnight switch.

> And then, that's a win for everyone, because in the process you get
> fbdev (booo!) and KMS (yay!), allowing for people to switch over, and
> eventually kill the emulation entirely. But it's far too early for
> that. I mean, we don't even have an fbv replacement yet...

We're talking about http://s-tech.elsat.net.pl/fbv/, whose latest release 
dates from 2011 ? :-)

https://github.com/tomba/kmsxx/blob/master/utils/kmsview.cpp

It won't be hard to add support for BMP, GIF, JPG or PNG.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Laurent Pinchart]

Hi Maxime,

On Wednesday 15 Feb 2017 13:38:44 Maxime Ripard wrote:
> On Mon, Feb 13, 2017 at 11:20:51AM +, Daniel Stone wrote:
> > On 13 February 2017 at 10:54, Maxime Ripard wrote:
> >> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote:
> >>> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote:
>  This patch add a config to support to create multi buffer for cma
>  fbdev. Such as double buffer and triple buffer.
>  
>  Cma fbdev is convient to add a legency fbdev. And still many Android
>  devices use fbdev now and at least double buffer is needed for these
>  Android devices, so that a buffer flip can be operated. It will need
>  some time for Android device vendors to abondon legency fbdev. So
>  multi buffer for fbdev is needed.
> >>> 
> >>> How exactly do we expect Android to move away from fbdev if we add
> >>> features to the fbdev compat layer ? I'd much rather make it clear to
> >>> them that fbdev is a thing from the past and that they'd better
> >>> migrate now.
> >> 
> >> If your point is that merging this patch will slow down the Android
> >> move away from fbdev, I disagree with that (obviously).
> >> 
> >> I don't care at all about Android on my platform of choice, but don't
> >> see how that merging this patch will change anything.
> >> 
> >> Let's be honest, Android trees typically have thousands of patches on
> >> top of mainline. Do you think a simple, 15 LoC, patch will make any
> >> difference to vendors? If they want to stay on fbdev and have that
> >> feature, they'll just merge this patch, done.
> > 
> > So, in that case, why not just let them do that? They'd already have
> > to add patches to use this, surely; we don't have anything in mainline
> > kernels which allows people to actually use this larger allocation.
> > Apart from software mmap() and using panning to do flips, but I'm
> > taking it as a given that people shipping Android on their devices
> > aren't using software rendering.
> 
> My point was that you're not doing it more difficult for people not
> willing to contribute upstream, you're just making it more difficult
> for people who want to contribute.
> 
> The whole argument to engage vendors upstream is that we sell them
> that eventually they will be able to just use whatever kernel release
> is on kernel.org or in their distro of choice.
> 
> If those people depend on a feature that is entirely rejected
> upstream, then they'll have to carry that patch in their tree,
> creating a BSP in the process. And that reduces greatly the strength
> of the "you should contribute" argument, making them less involved.

No, they should not carry an out-of-tree patch, they should not use that 
feature in the first place. fbdev is a dead-end, Linux has clearly decided to 
move to DRM/KMS. Any vendor who wants to keep using fbdev is shooting 
themselves in the foot, as the more they depend on fbdev, the more painful it 
will be to switch later when they will have no choice. Switching sooner than 
later is the best decision, and I'd argue that by making it easier to stay on 
fbdev we would actually hurt those vendors in the longer term.

> >> However, what I do see is that three different people/organisations
> >> have now expressed interest in that feature, on three different
> >> SoCs. If that patch needed a significant rework of the fbdev layer,
> >> then yes, I might agree that it's not worth it. But in this case, it's
> >> pretty trivial.
> >> 
> >> The only people you're "punishing" here with that kind of concern are
> >> the people who actually play fair and want not to have any patches and
> >> everything upstream.
> > 
> > I would hazard a guess that most users of this have out-of-tree GPU
> > drivers.
> 
> Out of tree GPU drivers, that can be distributed separately from the
> kernel, just like any out of tree module can. This doesn't require any
> kernel patches at all.

That might be true in some cases, but usually those GPU drivers require heavy 
patching of at least the display controller driver.

-- 
Regards,

Laurent Pinchart

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

[GIT PULL] imx-drm: TVE regulator, fb size limit, and ipu-v3 module fixes

[Philipp Zabel]

Hi Dave,

this tag has a few IPUv3 fixes that are helpful for the ongoing i.MX
media driver development, a fix for the i.MX53 TV encoder on device
trees that don't set the regulator property, and a patch to drop the
arbitrary minimum framebuffer size limit of 64x64 pixels.

regards
Philipp

The following changes since commit 7089db84e356562f8ba737c29e472cc42d530dbc:

  Linux 4.10-rc8 (2017-02-12 13:03:20 -0800)

are available in the git repository at:

  https://git.pengutronix.de/git/pza/linux tags/imx-drm-fixes-2017-02-17

for you to fetch changes up to 0e47b0275bdb40a9dab7a86535b1fcd85d874007:

  gpu: ipu-v3: Stop overwriting pdev->dev.of_node of child devices (2017-02-17 
08:04:27 +0100)


imx-drm: TVE regulator, fb size limit, and ipu-v3 module fixes

- Fix i.MX5 TV encoder probing in case no dac-supply regulator
  is set in the device tree.
- Remove 64 pixel min_width/height limit, which unnecessarily
  prohibits creation of small frame buffers.
- Add missing ipu_csi_set_downsize export, for media drivers
  built as modules.
- Stop modifying pdev->dev.of_node for IPU client devices that
  do not have an OF modalias to fix module autoloading.


Fabio Estevam (1):
  drm/imx: imx-tve: Do not set the regulator voltage

Philipp Zabel (3):
  drm/imx: lift 64x64 pixel minimum framebuffer size requirement
  gpu: ipu-v3: export ipu_csi_set_downsize
  gpu: ipu-v3: Stop overwriting pdev->dev.of_node of child devices

 drivers/gpu/drm/imx/imx-drm-core.c | 4 ++--
 drivers/gpu/drm/imx/imx-tve.c  | 7 ---
 drivers/gpu/ipu-v3/ipu-common.c| 6 --
 drivers/gpu/ipu-v3/ipu-csi.c   | 1 +
 4 files changed, 7 insertions(+), 11 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/3] video/sti/cec: add HPD notifier support

[Benjamin Gaignard]

This patch series following what Hans is doing on exynos to support
hotplug detect notifier code.

It add support of HPD in sti_hdmi drm driver and stih-cec driver which
move out of staging.

Those patches should be applied on top of Hans branch exynos4-cec.

I have tested hdmi notifier by pluging/unpluging HDMI cable and check
the value of the physical address with "cec-ctl --tuner".
"cec-compliance -A" is also functional.

version 3:
- change hdmi phandle from "st,hdmi-handle" to "hdmi-handle"
- fix typo in bindings

version 2:
- use HPD notifier instead of HDMI notifier
- move stih-cec out of staging
- rebase code on top of git://linuxtv.org/hverkuil/media_tree.git exynos4-cec
  branch
- split DT modifications in a separate patch

Benjamin Gaignard (3):
  sti: hdmi: add HPD notifier support
  stih-cec: add HPD notifier support
  arm: sti: update sti-cec for HPD notifier support

 .../devicetree/bindings/media/stih-cec.txt |   2 +
 arch/arm/boot/dts/stih407-family.dtsi  |  12 -
 arch/arm/boot/dts/stih410.dtsi |  13 +
 drivers/gpu/drm/sti/Kconfig|   1 +
 drivers/gpu/drm/sti/sti_hdmi.c |  14 +
 drivers/gpu/drm/sti/sti_hdmi.h |   3 +
 drivers/media/platform/Kconfig |  10 +
 drivers/media/platform/Makefile|   1 +
 drivers/media/platform/sti/cec/Makefile|   1 +
 drivers/media/platform/sti/cec/stih-cec.c  | 404 +
 drivers/staging/media/Kconfig  |   2 -
 drivers/staging/media/Makefile |   1 -
 drivers/staging/media/st-cec/Kconfig   |   8 -
 drivers/staging/media/st-cec/Makefile  |   1 -
 drivers/staging/media/st-cec/TODO  |   7 -
 drivers/staging/media/st-cec/stih-cec.c| 379 ---
 16 files changed, 449 insertions(+), 410 deletions(-)
 create mode 100644 drivers/media/platform/sti/cec/Makefile
 create mode 100644 drivers/media/platform/sti/cec/stih-cec.c
 delete mode 100644 drivers/staging/media/st-cec/Kconfig
 delete mode 100644 drivers/staging/media/st-cec/Makefile
 delete mode 100644 drivers/staging/media/st-cec/TODO
 delete mode 100644 drivers/staging/media/st-cec/stih-cec.c

-- 
1.9.1

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

[PATCH v3 2/3] stih-cec: add HPD notifier support

[Benjamin Gaignard]

By using the HPD notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.

Update the bindings documentation the new hdmi phandle.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
CC: devicet...@vger.kernel.org

version 3:
- change hdmi phandle from "st,hdmi-handle" to "hdmi-handle"
---
 .../devicetree/bindings/media/stih-cec.txt |   2 +
 drivers/media/platform/Kconfig |  10 +
 drivers/media/platform/Makefile|   1 +
 drivers/media/platform/sti/cec/Makefile|   1 +
 drivers/media/platform/sti/cec/stih-cec.c  | 404 +
 drivers/staging/media/Kconfig  |   2 -
 drivers/staging/media/Makefile |   1 -
 drivers/staging/media/st-cec/Kconfig   |   8 -
 drivers/staging/media/st-cec/Makefile  |   1 -
 drivers/staging/media/st-cec/TODO  |   7 -
 drivers/staging/media/st-cec/stih-cec.c| 379 ---
 11 files changed, 418 insertions(+), 398 deletions(-)
 create mode 100644 drivers/media/platform/sti/cec/Makefile
 create mode 100644 drivers/media/platform/sti/cec/stih-cec.c
 delete mode 100644 drivers/staging/media/st-cec/Kconfig
 delete mode 100644 drivers/staging/media/st-cec/Makefile
 delete mode 100644 drivers/staging/media/st-cec/TODO
 delete mode 100644 drivers/staging/media/st-cec/stih-cec.c

diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt 
b/Documentation/devicetree/bindings/media/stih-cec.txt
index 71c4b2f..1f7da58 100644
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ b/Documentation/devicetree/bindings/media/stih-cec.txt
@@ -9,6 +9,7 @@ Required properties:
  - pinctrl-names: Contains only one value - "default"
  - pinctrl-0: Specifies the pin control groups used for CEC hardware.
  - resets: Reference to a reset controller
+ - hdmi-handle: Phandle to the HDMI controller
 
 Example for STIH407:
 
@@ -22,4 +23,5 @@ sti-cec@094a087c {
pinctrl-names = "default";
pinctrl-0 = <_cec0_default>;
resets = < STIH407_LPM_SOFTRESET>;
+   hdmi-handle = <>;
 };
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 9920726..46db8a3 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -422,6 +422,16 @@ config VIDEO_SAMSUNG_S5P_CEC
  CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
+config VIDEO_STI_HDMI_CEC
+   tristate "STMicroelectronics STiH4xx HDMI CEC driver"
+   depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (ARCH_STI || COMPILE_TEST)
+   select HPD_NOTIFIER
+   ---help---
+ This is a driver for STIH4xx HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 endif #V4L_CEC_DRIVERS
 
 menuconfig V4L_TEST_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index ad3bf22..01b689c 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC)+= exynos-gsc/
 obj-$(CONFIG_VIDEO_STI_BDISP)  += sti/bdisp/
 obj-$(CONFIG_VIDEO_STI_HVA)+= sti/hva/
 obj-$(CONFIG_DVB_C8SECTPFE)+= sti/c8sectpfe/
+obj-$(CONFIG_VIDEO_STI_HDMI_CEC)   += sti/cec/
 
 obj-$(CONFIG_BLACKFIN)  += blackfin/
 
diff --git a/drivers/media/platform/sti/cec/Makefile 
b/drivers/media/platform/sti/cec/Makefile
new file mode 100644
index 000..f07905e
--- /dev/null
+++ b/drivers/media/platform/sti/cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_STI_HDMI_CEC) += stih-cec.o
diff --git a/drivers/media/platform/sti/cec/stih-cec.c 
b/drivers/media/platform/sti/cec/stih-cec.c
new file mode 100644
index 000..4242dad
--- /dev/null
+++ b/drivers/media/platform/sti/cec/stih-cec.c
@@ -0,0 +1,404 @@
+/*
+ * STIH4xx CEC driver
+ * Copyright (C) STMicroelectronic SA 2016
+ *
+ * This program 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.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define CEC_NAME   "stih-cec"
+
+/* CEC registers  */
+#define CEC_CLK_DIV   0x0
+#define CEC_CTRL  0x4
+#define CEC_IRQ_CTRL  0x8
+#define CEC_STATUS0xC
+#define CEC_EXT_STATUS0x10
+#define CEC_TX_CTRL   0x14
+#define CEC_FREE_TIME_THRESH  0x18
+#define CEC_BIT_TOUT_THRESH   

[PATCH v3 3/3] arm: sti: update sti-cec for HPD notifier support

[Benjamin Gaignard]

To use HPD notifier sti CEC driver needs to get phandle
of the hdmi device.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
CC: devicet...@vger.kernel.org

version 3:
- change hdmi phandle from "st,hdmi-handle" to "hdmi-handle"
---
 arch/arm/boot/dts/stih407-family.dtsi | 12 
 arch/arm/boot/dts/stih410.dtsi| 13 +
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index c8b2944..592d235 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -756,18 +756,6 @@
 <_s_c0_flexgen CLK_ETH_PHY>;
};
 
-   cec: sti-cec@094a087c {
-   compatible = "st,stih-cec";
-   reg = <0x94a087c 0x64>;
-   clocks = <_sysin>;
-   clock-names = "cec-clk";
-   interrupts = ;
-   interrupt-names = "cec-irq";
-   pinctrl-names = "default";
-   pinctrl-0 = <_cec0_default>;
-   resets = < STIH407_LPM_SOFTRESET>;
-   };
-
rng10: rng@08a89000 {
compatible  = "st,rng";
reg = <0x08a89000 0x1000>;
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index 281a124..71deb02 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -259,5 +259,18 @@
clocks = <_sysin>;
interrupts = ;
};
+
+   sti-cec@094a087c {
+   compatible = "st,stih-cec";
+   reg = <0x94a087c 0x64>;
+   clocks = <_sysin>;
+   clock-names = "cec-clk";
+   interrupts = ;
+   interrupt-names = "cec-irq";
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec0_default>;
+   resets = < STIH407_LPM_SOFTRESET>;
+   hdmi-handle = <_hdmi>;
+   };
};
 };
-- 
1.9.1

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

[PATCH v3 1/3] sti: hdmi: add HPD notifier support

[Benjamin Gaignard]

Implement the HPD notifier support to allow CEC drivers to
be informed when there is a new EDID and when a connect or
disconnect happens.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/sti/Kconfig|  1 +
 drivers/gpu/drm/sti/sti_hdmi.c | 14 ++
 drivers/gpu/drm/sti/sti_hdmi.h |  3 +++
 3 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index acd7286..f5c9572 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -8,5 +8,6 @@ config DRM_STI
select DRM_PANEL
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
+   select HPD_NOTIFIER
help
  Choose this option to enable DRM on STM stiH4xx chipset
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 376b076..d32a383 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -786,6 +786,8 @@ static void sti_hdmi_disable(struct drm_bridge *bridge)
clk_disable_unprepare(hdmi->clk_pix);
 
hdmi->enabled = false;
+
+   hpd_event_disconnect(hdmi->notifier);
 }
 
 static void sti_hdmi_pre_enable(struct drm_bridge *bridge)
@@ -892,6 +894,9 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
if (!edid)
goto fail;
 
+   hpd_event_new_edid(hdmi->notifier, edid,
+  EDID_LENGTH * (edid->extensions + 1));
+
count = drm_add_edid_modes(connector, edid);
drm_mode_connector_update_edid_property(connector, edid);
drm_edid_to_eld(connector, edid);
@@ -949,10 +954,12 @@ struct drm_connector_helper_funcs 
sti_hdmi_connector_helper_funcs = {
 
if (hdmi->hpd) {
DRM_DEBUG_DRIVER("hdmi cable connected\n");
+   hpd_event_connect(hdmi->notifier);
return connector_status_connected;
}
 
DRM_DEBUG_DRIVER("hdmi cable disconnected\n");
+   hpd_event_disconnect(hdmi->notifier);
return connector_status_disconnected;
 }
 
@@ -1464,6 +1471,10 @@ static int sti_hdmi_probe(struct platform_device *pdev)
goto release_adapter;
}
 
+   hdmi->notifier = hpd_notifier_get(>dev);
+   if (!hdmi->notifier)
+   goto release_adapter;
+
hdmi->reset = devm_reset_control_get(dev, "hdmi");
/* Take hdmi out of reset */
if (!IS_ERR(hdmi->reset))
@@ -1483,11 +1494,14 @@ static int sti_hdmi_remove(struct platform_device *pdev)
 {
struct sti_hdmi *hdmi = dev_get_drvdata(>dev);
 
+   hpd_event_disconnect(hdmi->notifier);
+
i2c_put_adapter(hdmi->ddc_adapt);
if (hdmi->audio_pdev)
platform_device_unregister(hdmi->audio_pdev);
component_del(>dev, _hdmi_ops);
 
+   hpd_notifier_put(hdmi->notifier);
return 0;
 }
 
diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
index 119bc35..2109c97 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.h
+++ b/drivers/gpu/drm/sti/sti_hdmi.h
@@ -8,6 +8,7 @@
 #define _STI_HDMI_H_
 
 #include 
+#include 
 #include 
 
 #include 
@@ -77,6 +78,7 @@ enum sti_hdmi_modes {
  * @audio_pdev: ASoC hdmi-codec platform device
  * @audio: hdmi audio parameters.
  * @drm_connector: hdmi connector
+ * @notifier: hotplug detect notifier
  */
 struct sti_hdmi {
struct device dev;
@@ -102,6 +104,7 @@ struct sti_hdmi {
struct platform_device *audio_pdev;
struct hdmi_audio_params audio;
struct drm_connector *drm_connector;
+   struct hpd_notifier *notifier;
 };
 
 u32 hdmi_read(struct sti_hdmi *hdmi, int offset);
-- 
1.9.1

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

Re: [PATCH 1/9] drm/ast: Handle configuration without P2A bridge

[Benjamin Herrenschmidt]

On Fri, 2017-02-17 at 16:32 +1100, Benjamin Herrenschmidt wrote:
> The ast driver configures a window to enable access into BMC
> memory space in order to read some configuration registers.

Aspeed suggested a couple of refinements for some chipsets,
so I'll respin either this week-end or monday.

> If this window is disabled, which it can be from the BMC side,
> the ast driver can't function.
> 
> Closing this window is a necessity for security if a machine's
> host side and BMC side are controlled by different parties;
> i.e. a cloud provider offering machines "bare metal".
> 
> A recent patch went in to try to check if that window is open
> but it does so by trying to access the registers in question
> and testing if the result is 0x.
> 
> This method will trigger a PCIe error when the window is closed
> which on some systems will be fatal (it will trigger an EEH
> for example on POWER which will take out the device).
> 
> This patch improves this in two ways:
> 
>  - First, if the firmware has put properties in the device-tree
> containing the relevant configuration information, we use these.
> 
>  - Otherwise, a bit in one of the SCU scratch registers (which
> are readable via the VGA register space and writeable by the BMC)
> will indicate if the BMC has closed the window. This bit has been
> defined by Y.C Chen from Aspeed.
> 
> If the window is closed and the configuration isn't available from
> the device-tree, some sane defaults are used. Those defaults are
> hopefully sufficient for standard video modes used on a server.
> 
> Signed-off-by: Russell Currey 
> Signed-off-by: Benjamin Herrenschmidt 
> --
> 
> v2. [BenH]
> - Reworked on top of Aspeed P2A patch
> - Cleanup overall detection via a "config_mode" and log the
>   selected mode for diagnostics purposes
> - Add a property for the SCU straps
> 
> v3. [BenH]
> - Moved the config mode detection to a separate functionn
> - Add reading of SCU 0x40 D[12] to detect the window is
>   closed as to not trigger a bus error by just "trying".
>   (change provided by Y.C. Chen)
> ---
>  drivers/gpu/drm/ast/ast_drv.h  |   6 +-
>  drivers/gpu/drm/ast/ast_main.c | 223 +
> 
>  drivers/gpu/drm/ast/ast_post.c |   7 +-
>  3 files changed, 141 insertions(+), 95 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_drv.h
> b/drivers/gpu/drm/ast/ast_drv.h
> index 7abda94..3bedcf7 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -113,7 +113,11 @@ struct ast_private {
>   struct ttm_bo_kmap_obj cache_kmap;
>   int next_cursor;
>   bool support_wide_screen;
> - bool DisableP2A;
> + enum {
> + ast_use_p2a,
> + ast_use_dt,
> + ast_use_defaults
> + } config_mode;
>  
>   enum ast_tx_chip tx_chip_type;
>   u8 dp501_maxclk;
> diff --git a/drivers/gpu/drm/ast/ast_main.c
> b/drivers/gpu/drm/ast/ast_main.c
> index 533e762..823c68f 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -62,13 +62,58 @@ uint8_t ast_get_index_reg_mask(struct ast_private
> *ast,
>   return ret;
>  }
>  
> +static void ast_detect_config_mode(struct drm_device *dev, u32
> *scu_rev)
> +{
> + struct device_node *np = dev->pdev->dev.of_node;
> + struct ast_private *ast = dev->dev_private;
> + uint32_t data, jreg;
> +
> + /* Check if we have device-tree properties */
> + if (np && !of_property_read_u32(np, "ast,scu-revision-id",
> scu_rev)) {
> + /* We do, disable P2A access */
> + ast->config_mode = ast_use_dt;
> + DRM_INFO("Using device-tree for configuration\n");
> + return;
> + }
> +
> + /*
> +  * The BMC will set SCU 0x40 D[12] to 1 if the P2 bridge
> +  * is disabled
> +  */
> + jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd1,
> 0xff);
> + if (!(jreg & 0x10)) {
> + /* Double check it's actually working */
> + data = ast_read32(ast, 0xf004);
> + if (data != 0x) {
> + /* P2A works, grab silicon revision */
> + ast->config_mode = ast_use_p2a;
> +
> + DRM_INFO("Using P2A bridge for
> configuration\n");
> +
> + /* Read SCU7c (silicon revision register) */
> + ast_write32(ast, 0xf004, 0x1e6e);
> + ast_write32(ast, 0xf000, 0x1);
> + *scu_rev = ast_read32(ast, 0x1207c);
> + return;
> + }
> + }
> +
> + DRM_INFO("P2A bridge disabled, using default
> configuration\n");
> + ast->config_mode = ast_use_defaults;
> + *scu_rev = 0x;
> +}
>  
>  static int ast_detect_chip(struct drm_device *dev, bool *need_post)
>  {
>   struct ast_private *ast = dev->dev_private;
> - uint32_t data, jreg;
> + 

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Archit Taneja]

On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:

On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:

Hi,

On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:

It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and clearing
it's state. So, lets add void * objects and helper functions that operate
on void * types to keep these objects and states private to the core.
Drivers can then implement specific functions to swap and clear states.
The other advantage having just void * for these objects in
drm_atomic_state is that objects of different types can be managed in the
same state array.

v2: Added docs and new iterator to filter private objects (Daniel)

Suggested-by: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_atomic.c| 68 +++
 drivers/gpu/drm/drm_atomic_helper.c |  5 ++
 include/drm/drm_atomic.h| 91 +
 3 files changed, 164 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a567310..1a9ffe8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state 
*state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+   kfree(state->private_objs);
 }
 EXPORT_SYMBOL(drm_atomic_state_default_release);

@@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
}
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   void *private_obj = state->private_objs[i].obj;
+   void *obj_state = state->private_objs[i].obj_state;
+
+   if (!private_obj)
+   continue;
+
+   state->private_objs[i].funcs->destroy_state(obj_state);
+   state->private_objs[i].obj = NULL;
+   state->private_objs[i].obj_state = NULL;
+   state->private_objs[i].funcs = NULL;
+   }
+
 }
 EXPORT_SYMBOL(drm_atomic_state_default_clear);

@@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
 }

 /**
+ * drm_atomic_get_private_obj_state - get private object state
+ * @state: global atomic state
+ * @obj: private object to get the state for
+ * @funcs: pointer to the struct of function pointers that identify the object
+ * type
+ *
+ * This function returns the private object state for the given private object,
+ * allocating the state if needed. It does not grab any locks as the caller is
+ * expected to care of any required locking.
+ *
+ * RETURNS:
+ *
+ * Either the allocated state or the error code encoded into a pointer.
+ */
+void *
+drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
+ const struct drm_private_state_funcs *funcs)
+{
+   int index, num_objs, i;
+   size_t size;
+   struct __drm_private_objs_state *arr;
+
+   for (i = 0; i < state->num_private_objs; i++)
+   if (obj == state->private_objs[i].obj &&
+   state->private_objs[i].obj_state)
+   return state->private_objs[i].obj_state;


Comparing this func to drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it
doesn't seem to call drm_modeset_lock if the obj_state doesn't already exist. I
don't understand the locking stuff toowell, I just noticed this difference when
comparing this approach with what is done in the msm kms driver (where we
have subclassed drm_atomic_state to msm_kms_state).

Thanks,
Archit




The caller is expected to take care of any required locking. The
driver-private objects are opaque from core's pov, so the core is not
aware of necessary locks for that object type.


I had a look at the rest of the series, and I couldn't easily understand
whether the caller code protects the MST related driver private state. Is
it expected to be protect via the drm_mode_config.connection_mutex lock?

Thanks,
Archit

--
Qualcomm Innovation Center, Inc. is a member of 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

[Bug 194579] AMDGPU: Possible size overflow detected by PaX in ttm_bo_handle_move_mem (drivers/gpu/drm/ttm/ttm_bo.c:388)

[bugzilla-daemon]

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

--- Comment #8 from Christian König (deathsim...@vodafone.de) ---
(In reply to Nicolai Hähnle from comment #7)
> Therefore, I'm inclined to say that this is probably not an actual bug.

Yeah, correct. The calculated offset is never used, so the overflow is
irrelevant.

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

[PULL] drm-intel-next-fixes

[Jani Nikula]

Hi Dave, i915 and GVT fixes for the v4.11 merge window. There's quite a
bit of cc: stable stuff that either didn't apply cleanly to v4.10 or
just arrived too late. I played it safe, and didn't try to rush them to
v4.10 anymore.

This one superseeds [1]. I rebased/recreated the branch to get rid of
the funny stuff.


BR,
Jani.

[1] 87fujfpmz7.fsf@intel.com">http://mid.mail-archive.com/87fujfpmz7.fsf@intel.com


The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442:

  Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2017-02-10 10:13:30 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel 
tags/drm-intel-next-fixes-2017-02-17

for you to fetch changes up to 998d75730b40afc218c059d811869abe9676b305:

  drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT 
(2017-02-16 11:59:14 +0200)


i915 and GVT fixes for v4.11 merge window


Changbin Du (5):
  drm/i915/gvt: remove a noisy unimportant log in sched_policy
  drm/i915/gvt: remove a redundant end of line in debug log
  drm/i915/gvt: reduce the line of interrupt logs and log friendly
  drm/i915/gvt: fix crash at function release_shadow_wa_ctx
  drm/i915/gvt: add missing display part reset for vGPU reset

Chris Wilson (6):
  drm/i915: Recreate internal objects with single page segments if dmar 
fails
  drm/i915: Reject set-tiling-ioctl with stride==0 and a tiling mode
  drm/i915: Restore context and pd for ringbuffer submission after reset
  drm/i915: Check for timeout completion when waiting for the rq to 
submitted
  drm/i915/gvt: Disable access to stolen memory as a guest
  drm/i915: Pass timeout==0 on to i915_gem_object_wait_fence()

Chuanxiao Dong (6):
  drm/i915/gvt: add more resolutions in virtual edid
  drm/i915/gvt: Map shadow page before using it in shadow page table
  drm/i915/gvt: map pfn for PTE entry in kvm
  drm/i915/gvt: enable IOMMU for gvt
  drm/i915/gvt: optimize the inhibit context mmio load
  drm/i915/gvt: return error code if dma map iova failed

Dan Carpenter (1):
  drm/i915/gvt/kvmgt: remove some dead code

Hans de Goede (1):
  drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

Imre Deak (2):
  drm/i915/gen9+: Enable hotplug detection early
  drm/i915/lspcon: Fix resume time initialization due to unasserted HPD

Jani Nikula (2):
  Merge tag 'gvt-next-2017-02-07' of https://github.com/01org/gvt-linux 
into drm-intel-next-fixes
  Merge tag 'gvt-next-2017-02-15' of https://github.com/01org/gvt-linux 
into drm-intel-next-fixes

Ville Syrjälä (1):
  drm/i915: Avoid spurious WARNs about the wrong pipe in the PPS code

Xu Han (1):
  drm/i915/gvt: add sprite plane flip done support.

Zhenyu Wang (7):
  drm/i915: make intel_gvt_init() later instead of too early
  drm/i915/gvt: move intel iommu detection to intel_gvt_init()
  drm/i915/gvt: remove detect_host() MPT hook
  drm/i915/gvt: use normal mmio read function for firmware exposure
  drm/i915/gvt: fix vgpu type size init
  drm/i915/gvt: Fix alignment for GTT allocation
  drm/i915/gvt: Fix shadow context descriptor

Zhi Wang (2):
  drm/i915: Let execlist_update_context() cover !FULL_PPGTT mode.
  drm/i915: A hotfix for making aliasing PPGTT work for GVT-g

 drivers/gpu/drm/i915/gvt/aperture_gm.c   |  15 +++--
 drivers/gpu/drm/i915/gvt/cmd_parser.c|  20 +-
 drivers/gpu/drm/i915/gvt/display.c   |  31 +++--
 drivers/gpu/drm/i915/gvt/display.h   |   1 +
 drivers/gpu/drm/i915/gvt/execlist.c  |   2 +-
 drivers/gpu/drm/i915/gvt/firmware.c  |  47 ++
 drivers/gpu/drm/i915/gvt/gtt.c   |  70 ++--
 drivers/gpu/drm/i915/gvt/gvt.c   |   7 --
 drivers/gpu/drm/i915/gvt/hypercall.h |   1 -
 drivers/gpu/drm/i915/gvt/interrupt.c |  57 +---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 108 +++
 drivers/gpu/drm/i915/gvt/mpt.h   |  12 
 drivers/gpu/drm/i915/gvt/render.c|  17 +
 drivers/gpu/drm/i915/gvt/sched_policy.c  |   1 -
 drivers/gpu/drm/i915/gvt/scheduler.c |   5 +-
 drivers/gpu/drm/i915/gvt/vgpu.c  |  14 ++--
 drivers/gpu/drm/i915/i915_drv.c  |  14 ++--
 drivers/gpu/drm/i915/i915_gem.c  |  22 +++
 drivers/gpu/drm/i915/i915_gem_gtt.c  |   7 +-
 drivers/gpu/drm/i915/i915_gem_internal.c |  37 +++
 drivers/gpu/drm/i915/i915_gem_request.c  |   7 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c   |   5 ++
 drivers/gpu/drm/i915/i915_gem_tiling.c   |   2 +-
 drivers/gpu/drm/i915/i915_irq.c  |  69 ++--
 drivers/gpu/drm/i915/i915_reg.h  |   6 +-
 drivers/gpu/drm/i915/intel_dp.c  |  10 +--
 

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Maxime Ripard]

Hi,

On Thu, Feb 16, 2017 at 01:28:24PM +0100, Tobias Jakobi wrote:
> Hello,
> 
> I'm not sure if I'm missing something here, but I don't see how this is
> supposed to work.
> 
> This just multiplies the height of the drm_mode_fb_cmd2 object with the
> number of buffers. Let's say I have width=1024, height=768, then now I
> have a framebuffer which has height=2304 (in the num_buffers=3 case). At
> some point this FB is set as the primary plane, giving us a 1024x2304
> mode. I don't think that this is intended.
> 
> In my opinion this multi-buffer thing should touch drm_mode_fb_cmd2 at
> all. The underlying BO should be larger, but not the FB itself. If this
> is supposed to work, then the fbdev helpers should create as many FBs as
> there are buffers, and then offset each of these FB into the BO.

This only increases the virtual resolution, not the visible one.

> What I'm also not seeing is code that handles the fbdev's virtual
> resolutions. After all num_buffers should only increase those. Same for
> the panning ioctl().

This is already implemented through drm_fb_helper_pan_display.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Maxime Ripard]

Hi,

On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
> I was wondering about the following. Wasn't there some strict
> requirement about code going upstream, which also included that there
> was a full open-source driver stack for it?
> 
> I don't see how this is the case for Mali, neither in the kernel, nor in
> userspace. I'm aware that the Mali kernel driver is open-source. But it
> is not upstream, maintained out of tree, and won't land upstream in its
> current form (no resemblence to a DRM driver at all). And let's not talk
> about the userspace part.
> 
> So, why should this be here?

The device tree is a representation of the hardware itself. The state
of the driver support doesn't change the hardware you're running on,
just like your BIOS/UEFI on x86 won't change the device it reports to
Linux based on whether it has a driver for it.

So yes, unfortunately, we don't have a driver upstream at the
moment. But that doesn't prevent us from describing the hardware
accurately.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PULL] drm-misc-next-fixes, take 2

[Jani Nikula]

On Fri, 17 Feb 2017, Dave Airlie  wrote:
> On 16 February 2017 at 19:49, Jani Nikula  wrote:
>>
>> Hi Dave, this one superseeds [1]. Better to flush out the single uapi
>> fix for v4.11 now so it's not forgotten.
>
> Looks like I had already pulled, I just reverted Maarten's patch on
> top of drm-next.

Okay, thanks. Cc: Maarten FYI.

BR,
Jani.

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