Re: [PATCH] drm/mediatek: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

[CK Hu]

Hi, Vasyl:

Sorry for the late reply.
I've applied this to my branch mediatek-drm-next-4.18

Regards,
CK

On Thu, 2017-11-23 at 17:31 +0800, Philipp Zabel wrote:
> On Tue, 2017-11-21 at 23:31 +0100, Vasyl Gomonovych wrote:
> > Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)).
> > 
> > drivers/gpu/drm/mediatek/mtk_drm_gem.c:223:9-16: WARNING: ERR_CAST can be 
> > used with mtk_gem
> > Generated by: scripts/coccinelle/api/err_cast.cocci
> > 
> > Signed-off-by: Vasyl Gomonovych 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > index f595ac816b55..5766b42fc174 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > @@ -220,7 +220,7 @@ struct drm_gem_object 
> > *mtk_gem_prime_import_sg_table(struct drm_device *dev,
> > mtk_gem = mtk_drm_gem_init(dev, attach->dmabuf->size);
> >  
> > if (IS_ERR(mtk_gem))
> > -   return ERR_PTR(PTR_ERR(mtk_gem));
> > +   return ERR_CAST(mtk_gem));
> >  
> > expected = sg_dma_address(sg->sgl);
> > for_each_sg(sg->sgl, s, sg->nents, i) {
> 
> Acked-by: Philipp Zabel 
> 
> regards
> Philipp
> 


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

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
> Out of curiosity, how much virtual flushing stuff is there still out
> there? At least in drm we've pretty much ignore this, and seem to be
> getting away without a huge uproar (at least from driver developers
> and users, core folks are less amused about that).

As I've just been wading through the code, the following architectures
have non-coherent dma that flushes by virtual address for at least some
platforms:

 - arm [1], arm64, hexagon, nds32, nios2, parisc, sh, xtensa, mips,
   powerpc

These have non-coherent dma ops that flush by physical address:

 - arc, arm [1], c6x, m68k, microblaze, openrisc, sparc

And these do not have non-coherent dma ops at all:

 - alpha, h8300, riscv, unicore32, x86

[1] arm ѕeems to do both virtually and physically based ops, further
audit needed.

Note that using virtual addresses in the cache flushing interface
doesn't mean that the cache actually is virtually indexed, but it at
least allows for the possibility.

> > I think the most important thing about such a buffer object is that
> > it can distinguish the underlying mapping types.  While
> > dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
> > dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
> > back a dma_addr_t they are in now way interchangable.  And trying to
> > stuff them all into a structure like struct scatterlist that has
> > no indication what kind of mapping you are dealing with is just
> > asking for trouble.
> 
> Well the idea was to have 1 interface to allow all drivers to share
> buffers with anything else, no matter how exactly they're allocated.

Isn't that interface supposed to be dmabuf?  Currently dma_map leaks
a scatterlist through the sg_table in dma_buf_map_attachment /
->map_dma_buf, but looking at a few of the callers it seems like they
really do not even want a scatterlist to start with, but check that
is contains a physically contiguous range first.  So kicking the
scatterlist our there will probably improve the interface in general.

> dma-buf has all the functions for flushing, so you can have coherent
> mappings, non-coherent mappings and pretty much anything else. Or well
> could, because in practice people hack up layering violations until it
> works for the 2-3 drivers they care about. On top of that there's the
> small issue that x86 insists that dma is coherent (and that's true for
> most devices, including v4l drivers you might want to share stuff
> with), and gpus really, really really do want to make almost
> everything incoherent.

How do discrete GPUs manage to be incoherent when attached over PCIe?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106229] EEH problem at boot with Radeon HD 7950, in amdgpu_mm_rreg

[bugzilla-daemon]

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

--- Comment #3 from Luke-Jr  ---
It did work with the "radeon" driver on x86, and *mostly* works with "radeon"
on POWER9 as well (except that it limits itself to 32-bit DMA for some reason,
and eventually crashes when I bump up against the allocation limit; to
workaround that, I am currently using the fbdev Xorg driver with the radeon
kernel driver).

-- 
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 106229] EEH problem at boot with Radeon HD 7950, in amdgpu_mm_rreg

[bugzilla-daemon]

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

--- Comment #2 from Luke-Jr  ---
Never tried amdgpu on x86.

-- 
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 106229] EEH problem at boot with Radeon HD 7950, in amdgpu_mm_rreg

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher  ---
Does it work on x86?

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

[RFC PATCH radeon-alex] drm/amdkfd: amd_kfd_fence_ops can be static

[kbuild test robot]

Fixes: 61986dd6bef0 ("drm/amdkfd: Copy in KFD-related files")
Signed-off-by: Fengguang Wu 
---
 amdgpu_amdkfd_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
index cf2f1e9..e659e0b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
@@ -29,7 +29,7 @@
 #include 
 #include "amdgpu_amdkfd.h"
 
-const struct dma_fence_ops amd_kfd_fence_ops;
+static const struct dma_fence_ops amd_kfd_fence_ops;
 static atomic_t fence_seq = ATOMIC_INIT(0);
 
 /* Eviction Fence
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106229] EEH problem at boot with Radeon HD 7950, in amdgpu_mm_rreg

[bugzilla-daemon]

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

Bug ID: 106229
   Summary: EEH problem at boot with Radeon HD 7950, in
amdgpu_mm_rreg
   Product: DRI
   Version: XOrg git
  Hardware: PowerPC
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: luke-jr+freedesktopb...@utopios.org

Created attachment 139092
  --> https://bugs.freedesktop.org/attachment.cgi?id=139092=edit
Full dmesg

[   33.420520] Call Trace:
[   33.420523] [c000200724883570] [c0ad0e14] dump_stack+0xb4/0x100
(unreliable)
[   33.420527] [c0002007248835b0] [c002be78]
eeh_dev_check_failure+0x558/0x580
[   33.420529] [c000200724883660] [c002bf24]
eeh_check_failure+0x84/0xd0
[   33.420549] [c0002007248836a0] [c00808731864] amdgpu_mm_rreg+0x9c/0x1b0
[amdgpu]
[   33.420566] [c0002007248836f0] [c008087ca9fc]
amdgpu_si_send_msg_to_smc+0x94/0x100 [amdgpu]
[   33.420582] [c000200724883720] [c008087c267c]
si_thermal_enable_alert+0x64/0x100 [amdgpu]
[   33.420599] [c000200724883790] [c008087c9e48]
si_dpm_enable+0x3540/0x3900 [amdgpu]
[   33.420616] [c0002007248838c0] [c008087ca34c] si_dpm_hw_init+0x74/0xd0
[amdgpu]
[   33.420633] [c000200724883900] [c008087e3e98]
amdgpu_pp_hw_init+0x50/0x90 [amdgpu]
[   33.420645] [c000200724883930] [c00808734098]
amdgpu_device_init+0xf30/0x1520 [amdgpu]
[   33.420657] [c000200724883a30] [c00808737f4c]
amdgpu_driver_load_kms+0xa4/0x280 [amdgpu]
[   33.420664] [c000200724883ab0] [c00807aba32c]
drm_dev_register+0x1c4/0x280 [drm]
[   33.420676] [c000200724883b50] [c00808730778]
amdgpu_pci_probe+0x120/0x250 [amdgpu]
[   33.420679] [c000200724883bd0] [c0625f04] local_pci_probe+0x64/0x130
[   33.420681] [c000200724883c60] [c00cf360] work_for_cpu_fn+0x30/0x50
[   33.420683] [c000200724883c90] [c00d3144]
process_one_work+0x284/0x470
[   33.420685] [c000200724883d20] [c00d3600] worker_thread+0x2d0/0x610
[   33.420688] [c000200724883dc0] [c00dbd8c] kthread+0x19c/0x1b0
[   33.420690] [c000200724883e30] [c000b594]
ret_from_kernel_thread+0x5c/0xc8

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

Re: [PATCH v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel

[Doug Anderson]

Hi,

On Tue, Apr 24, 2018 at 7:31 AM, Ezequiel Garcia
 wrote:
> Hi Doug, Sean:
>
> I would like to move this forward.
>
> On 26 February 2018 at 15:23, Doug Anderson  wrote:
>> Hi,
>>
>> On Thu, Feb 8, 2018 at 9:48 AM, Sean Paul  wrote:
>>> This patch adds an override mode for kevin devices. The mode increases
>>> both back porches to allow a pixel clock of 2kHz as opposed to the
>>> 'typical' value of 252750kHz. This is needed to avoid interference with
>>> the touch digitizer on these laptops.
>>>
>>> Changes in v2:
>>>  - Wrap the timing in display-timings node to match binding (Rob/Thierry)
>>> Changes in v3:
>>>  - Unwrap the timing from display-timings and rename panel-timing (Rob)
>>>
>>> Cc: Doug Anderson 
>>> Cc: Eric Anholt 
>>> Cc: Heiko Stuebner 
>>> Cc: Jeffy Chen 
>>> Cc: Rob Herring 
>>> Cc: Stéphane Marchesin 
>>> Cc: Thierry Reding 
>>> Cc: devicet...@vger.kernel.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: linux-rockc...@lists.infradead.org
>>> Signed-off-by: Sean Paul 
>>> ---
>>>  arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 14 ++
>>>  1 file changed, 14 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
>>> b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>>> index 191a6bcb1704..658411ce37ea 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>>> @@ -98,6 +98,20 @@
>>> backlight = <>;
>>> power-supply = <_disp>;
>>>
>>> +   panel-timing {
>>> +   clock-frequency = <266604720>;
>>> +   hactive = <2400>;
>>> +   hfront-porch = <48>;
>>> +   hback-porch = <84>;
>>> +   hsync-len = <32>;
>>> +   hsync-active = <0>;
>>> +   vactive = <1600>;
>>> +   vfront-porch = <3>;
>>> +   vback-porch = <120>;
>>> +   vsync-len = <10>;
>>> +   vsync-active = <0>;
>>> +   };
>>> +
>>> ports {
>>> panel_in_edp: endpoint {
>>> remote-endpoint = <_out_panel>;
>>
>> Kristian brought an old bug to my attention
>>  and it
>> made me think.  Should we somehow adjust the bindings here to account
>> for the fact that a board may source several different panels?
>>
>> AKA: on some boards an ODM may want to second source (or third source,
>> or ...) the panel.  They'll randomly connect several different panels
>> to the board and ship the boards out.  The panels are all compatible
>> electrically (same power sequencing) but might need slightly different
>> timings.  In this particular case there's no board-level strappings
>> for the different panels--it's assumed that the EDID on the panels can
>> be used to distinguish them.
>>
>> In that case it seems like it would be nice to allow specifying more
>> than one "panel-timing" nodes.  Maybe keyed off some type of ID that's
>> present in the EDID?
>>
>>
>> Is that something we'd want to account for before we land this series?
>>  It seems like it would just be adding an extra level of nodes?
>>
>
> AFAICS, there is no EDID without a DDC bus, which we don't
> seem to have on gru platforms, do we?

I'm fairly certain we can read the EDID on gru devices.  I see the
"aux" channel connected on the schematics.  That'll do it, right?
...and I could have sworn that at some point in time I could read the
EDID in the software.  My kevin devices are not connected for
debugging so I can't check right now, but I'm pretty sure I was able
to read the EDID in the past...

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

[Bug 106228] amdgpu reads back brightness 0 (which is not true) if checked before a brightness has been explicitly set

[bugzilla-daemon]

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

Bug ID: 106228
   Summary: amdgpu reads back brightness 0 (which is not true) if
checked before a brightness has been explicitly set
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: jian-h...@endlessm.com

Created attachment 139091
  --> https://bugs.freedesktop.org/attachment.cgi?id=139091=edit
The full dmesg

I have tried to install Linux OS on ASUS laptop which is equipped with AMD
Ryzen 5 2500U with Radeon Vega Mobile Gfx.

When the Linux installation completed and entered to the OS, the brightness of
display looks normal but the brightness bar is shown as the lowest level within
the display's brightness GUI setting.

Also check "cat /sys/class/backlight/amdgpu_bl0/brightness" and it is 0.

After a system reboot, Brightness is dimmed to the lowest level.
Check "cat /sys/class/backlight/amdgpu_bl0/brightness" again and it is 12.

To make sure it is the problem that "system always reads back brightness 0 if
checked before a brightness has been explicitly set".
I disable all of the brightness setting applications, including masking
systemd-backlight service and than reboot.
"cat /sys/class/backlight/amdgpu_bl0/brightness" before set brightness manually
again and it reads back 0, but the brightness of display looks normal actually.
Then, if I drag the brightness bar in GUI, the actual brightness changes and
the "/sys/class/backlight/amdgpu_bl0/brightness" goes to the right value.
And, I reboot again, then the same things happen again.

I also tried this with kernel v4.17.0-rc2.  It still has the same problem.

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

[radeon-alex:amd-mainline-dkms-4.15 1429/1759] cc1: fatal error: drivers/gpu/drm/amd/amdkfd/backport/backport.h: No such file or directory

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.15
head:   9556f93f18f7923978fb90f860c107fed9ca7f57
commit: 54df8c4830456ee6d9f9cb16c281e8bef8780dce [1429/1759] drm/amd/dkms: add 
amdkfd module
config: x86_64-federa-25 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 54df8c4830456ee6d9f9cb16c281e8bef8780dce
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> cc1: fatal error: drivers/gpu/drm/amd/amdkfd/backport/backport.h: No such 
>> file or directory
   compilation terminated.

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


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-mainline-dkms-4.15 1098/1759] drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:70:1-3: ERROR: test of a variable/field address

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.15
head:   9556f93f18f7923978fb90f860c107fed9ca7f57
commit: 02349fbb559640a1f948df9c84e8f65bd2565d57 [1098/1759] drm/amdkcl: [4.11] 
fix debugfs func


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:70:1-3: ERROR: test of a 
>> variable/field address

vim +70 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c

64  
65  #if defined(BUILD_AS_DKMS) &&  LINUX_VERSION_CODE < KERNEL_VERSION(4, 
11, 0)
66  void amdgpu_debugfs_cleanup(struct drm_minor *minor)
67  {
68  struct drm_info_node *node, *tmp;
69  
  > 70  if (!>debugfs_root)
71  return 0;
72  
73  mutex_lock(>debugfs_lock);
74  list_for_each_entry_safe(node, tmp,
75  >debugfs_list, list) {
76  debugfs_remove(node->dent);
77  list_del(>list);
78  kfree(node);
79  }
80  mutex_unlock(>debugfs_lock);
81  
82  return 0;
83  }
84  #endif
85  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106191] FirePro v8800 Failure to recognize DisplayPort signal

[bugzilla-daemon]

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

--- Comment #13 from François Jacques  ---
Created attachment 139083
  --> https://bugs.freedesktop.org/attachment.cgi?id=139083=edit
REAL dmesg output (with debug messages)

Last attachment for tonight. This one its not /var/log/messages but really
dmesg output. We can see the debug messages as I disconnected the HDMI cable,
then connected the DP cable (no image, audio enabled), then disconnected and
reconnected the HDMI cable.

Hopefully that will be useful to stabilize DP display with audio.

Interesting bits:
[ 1288.208351] [drm:radeon_process_aux_ch.constprop.2 [radeon]] dp_aux_ch flags
not zero
[ 1288.208354] [drm:drm_dp_dpcd_access] Too many retries, giving up. First
error: -5

-- 
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 106191] FirePro v8800 Failure to recognize DisplayPort signal

[bugzilla-daemon]

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

--- Comment #12 from François Jacques  ---
Created attachment 139082
  --> https://bugs.freedesktop.org/attachment.cgi?id=139082=edit
dmesg (Linux 4.16.3, drm.debug=0x06, audio enabled)

-- 
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 106191] FirePro v8800 Failure to recognize DisplayPort signal

[bugzilla-daemon]

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

--- Comment #11 from François Jacques  ---

The bug is caused by having both the audio signal and image simultaneously, it
seems. 

After I added "radeon.audio=0" to the kernel argument list and rebooted, the
video interface and the monitor concluded their signal handshake successfully
(!) and I could switch the monitor to full res and, lo' behol',  a 1440p image
(!!).

For future reference, should anyone have issues, try radeon.audio=0. If you
were relying on the radeon for audio, look for an alternative, or use a
DP-to-HDMI adapter and tolerate the lower resolution until the bug is fixed.



Googling on this specific symptom revealed multiple regressions on this matter
before, it could be a new one or it's been lurking for a while. Which means
either:
- tons of dupes in the DRM bugs list wrt radeon and DP /w audio enabled and
users don't know how to disable it.
- all radeon users having switched their audio off
- most radeon users gave up on their DisplayPort or their radeon-based card
altogether (perhaps switching brand in the process, frustration kicking in)
- it's a recent regression and I've been lucky to catch it before the kernel
goes mainstream in major distros.

I'll still provide a dmesg dump, this time with drm.debug=0x06 (0x06 any good?
any prefered value?) by rebooting with audio back on and image gone.

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

Re: [PATCH] drm: rcar-du: of: Include header to define prototypes

[kbuild test robot]

Hi Kieran,

I love your patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.17-rc2 next-20180424]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kieran-Bingham/drm-rcar-du-of-Include-header-to-define-prototypes/20180425-062015
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

>> drivers/gpu//drm/rcar-du/rcar_du_of.c:320:13: error: redefinition of 
>> 'rcar_du_of_init'
void __init rcar_du_of_init(const struct of_device_id *of_ids)
^~~
   In file included from drivers/gpu//drm/rcar-du/rcar_du_of.c:21:0:
   drivers/gpu//drm/rcar-du/rcar_du_of.h:17:20: note: previous definition of 
'rcar_du_of_init' was here
static inline void rcar_du_of_init(const struct of_device_id *of_ids) { }
   ^~~

vim +/rcar_du_of_init +320 drivers/gpu//drm/rcar-du/rcar_du_of.c

81c0e3dd Laurent Pinchart 2018-01-10  319  
81c0e3dd Laurent Pinchart 2018-01-10 @320  void __init rcar_du_of_init(const 
struct of_device_id *of_ids)

:: The code at line 320 was first introduced by commit
:: 81c0e3dd82927064a2f56a31a0974a0d110fcdb0 drm: rcar-du: Fix legacy DT to 
create LVDS encoder nodes

:: TO: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
:: CC: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>

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


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-mainline-dkms-4.15 1409/1759] drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd.c:23:0: warning: "pr_fmt" redefined

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.15
head:   9556f93f18f7923978fb90f860c107fed9ca7f57
commit: 61986dd6bef0b17e85a9846bb4d1ca610f9d6ce0 [1409/1759] drm/amdkfd: Copy 
in KFD-related files
config: i386-randconfig-a1-04241604 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 61986dd6bef0b17e85a9846bb4d1ca610f9d6ce0
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

>> drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd.c:23:0: warning: "pr_fmt" redefined
#define pr_fmt(fmt) "kfd2kgd: " fmt
^
   In file included from include/linux/kernel.h:14:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/kref.h:18,
from include/kcl/kcl_kref.h:5,
from drivers/gpu//drm/amd/amdgpu/../backport/backport.h:7,
from :0:
   include/linux/printk.h:285:0: note: this is the location of the previous 
definition
#define pr_fmt(fmt) fmt
^
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/kref.h:18,
from include/kcl/kcl_kref.h:5,
from drivers/gpu//drm/amd/amdgpu/../backport/backport.h:7,
from :0:
   drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd.c: In function 
'amdgpu_amdkfd_get_dmabuf_info':
   drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd.c:448:23: error: 
'amdgpu_dmabuf_ops' undeclared (first use in this function)
 if (dma_buf->ops != _dmabuf_ops)
  ^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd.c:448:2: note: in expansion of 
macro 'if'
 if (dma_buf->ops != _dmabuf_ops)
 ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd.c:448:23: note: each undeclared 
identifier is reported only once for each function it appears in
 if (dma_buf->ops != _dmabuf_ops)
  ^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd.c:448:2: note: in expansion of 
macro 'if'
 if (dma_buf->ops != _dmabuf_ops)
 ^
--
>> drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c:23:0: warning: "pr_fmt" 
>> redefined
#define pr_fmt(fmt) "kfd2kgd: " fmt
^
   In file included from include/linux/kernel.h:14:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/kref.h:18,
from include/kcl/kcl_kref.h:5,
from drivers/gpu//drm/amd/amdgpu/../backport/backport.h:7,
from :0:
   include/linux/printk.h:285:0: note: this is the location of the previous 
definition
#define pr_fmt(fmt) fmt
^
--
>> drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c:23:0: warning: "pr_fmt" 
>> redefined
#define pr_fmt(fmt) "kfd2kgd: " fmt
^
   In file included from include/linux/kernel.h:14:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/kref.h:18,
from include/kcl/kcl_kref.h:5,
from drivers/gpu//drm/amd/amdgpu/../backport/backport.h:7,
from :0:
   include/linux/printk.h:285:0: note: this is the location of the previous 
definition
#define pr_fmt(fmt) fmt
^
--
>> drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:23:0: warning: "pr_fmt" 
>> redefined
#define pr_fmt(fmt) "kfd2kgd: " fmt
^
   In file included from include/linux/kernel.h:14:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/kref.h:18,
from include/kcl/kcl_kref.h:5,
from drivers/gpu//drm/amd/amdgpu/../backport/backport.h:7,
from :0:
   include/linux/printk.h:285:0: note: this is the location of the previous 
definition
#define pr_fmt(fmt) fmt
^
   In file included from 
drivers/gpu//drm/amd/amdgpu/../backport/include/kcl/kcl_amdgpu.h:5:0,
from drivers/gpu//drm/amd/amdgpu/../backport/backport.h:12,
from :0:
   

Re: [PATCH] drm: xlnx: pl_disp: fix odd_ptr_err.cocci warnings

[Laurent Pinchart]

Hi Julia,

Thank you for the patch.

On Tuesday, 10 April 2018 08:49:40 EEST Julia Lawall wrote:
> From: Fengguang Wu 
> 
>  PTR_ERR should normally access the value just tested by IS_ERR
> 
> Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
> 
> Fixes: 742243a44a73 ("drm: xlnx: pl_disp: Use xlnx pipeline calls")
> CC: Hyun Kwon 
> Signed-off-by: Fengguang Wu 
> Signed-off-by: Julia Lawall 

Reviewed-by: Laurent Pinchart 

Hyun, do you plan to take care of this patch ? I suppose you can squash it 
into the offending commit when upstreaming the driver.

> ---
> 
> tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
> head:   fe04d2ee0dfea6b5fdbb04f4f6dbcaa13bfd2fda
> commit: 742243a44a738b165f8da5cbdb6662139e85a5c5 [651/842] drm: xlnx:
> pl_disp: Use xlnx pipeline calls
> 
> 
>  xlnx_pl_disp.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/gpu/drm/xlnx/xlnx_pl_disp.c
> +++ b/drivers/gpu/drm/xlnx/xlnx_pl_disp.c
> @@ -482,7 +482,7 @@ static int xlnx_pl_disp_probe(struct pla
> 
>   xlnx_pl_disp->master = xlnx_drm_pipeline_init(pdev);
>   if (IS_ERR(xlnx_pl_disp->master)) {
> - ret = PTR_ERR(xlnx_pl_disp->dev);
> + ret = PTR_ERR(xlnx_pl_disp->master);
>   dev_err(dev, "failed to initialize the drm pipeline\n");
>   goto err_component;
>   }

-- 
Regards,

Laurent Pinchart



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

[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows

[bugzilla-daemon]

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

--- Comment #10 from Mike Bendel  ---
I have the same issue. For me amdgpu.dc=0 does not really fix it either. I have
a 3840x1600 monitor running at 75 Hz. This is the different behavior I noticed
when toggling the DC setting:

amdgpu.dc=0

Moving windows smooth most of the time but cursor frequently skips frames

amdgpu.dc=1

There is stutter/tearing in the movement of windows but the cursor is
completely smooth otherwise.

Running 4.16.2 kernel here with a Radeon Pro WX 7100.

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

Re: [PATCH v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel

[Stéphane Marchesin]

On Tue, Apr 24, 2018 at 7:31 AM, Ezequiel Garcia
 wrote:
> Hi Doug, Sean:
>
> I would like to move this forward.
>
> On 26 February 2018 at 15:23, Doug Anderson  wrote:
>> Hi,
>>
>> On Thu, Feb 8, 2018 at 9:48 AM, Sean Paul  wrote:
>>> This patch adds an override mode for kevin devices. The mode increases
>>> both back porches to allow a pixel clock of 2kHz as opposed to the
>>> 'typical' value of 252750kHz. This is needed to avoid interference with
>>> the touch digitizer on these laptops.
>>>
>>> Changes in v2:
>>>  - Wrap the timing in display-timings node to match binding (Rob/Thierry)
>>> Changes in v3:
>>>  - Unwrap the timing from display-timings and rename panel-timing (Rob)
>>>
>>> Cc: Doug Anderson 
>>> Cc: Eric Anholt 
>>> Cc: Heiko Stuebner 
>>> Cc: Jeffy Chen 
>>> Cc: Rob Herring 
>>> Cc: Stéphane Marchesin 
>>> Cc: Thierry Reding 
>>> Cc: devicet...@vger.kernel.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: linux-rockc...@lists.infradead.org
>>> Signed-off-by: Sean Paul 
>>> ---
>>>  arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 14 ++
>>>  1 file changed, 14 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
>>> b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>>> index 191a6bcb1704..658411ce37ea 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>>> @@ -98,6 +98,20 @@
>>> backlight = <>;
>>> power-supply = <_disp>;
>>>
>>> +   panel-timing {
>>> +   clock-frequency = <266604720>;
>>> +   hactive = <2400>;
>>> +   hfront-porch = <48>;
>>> +   hback-porch = <84>;
>>> +   hsync-len = <32>;
>>> +   hsync-active = <0>;
>>> +   vactive = <1600>;
>>> +   vfront-porch = <3>;
>>> +   vback-porch = <120>;
>>> +   vsync-len = <10>;
>>> +   vsync-active = <0>;
>>> +   };
>>> +
>>> ports {
>>> panel_in_edp: endpoint {
>>> remote-endpoint = <_out_panel>;
>>
>> Kristian brought an old bug to my attention
>>  and it
>> made me think.  Should we somehow adjust the bindings here to account
>> for the fact that a board may source several different panels?
>>
>> AKA: on some boards an ODM may want to second source (or third source,
>> or ...) the panel.  They'll randomly connect several different panels
>> to the board and ship the boards out.  The panels are all compatible
>> electrically (same power sequencing) but might need slightly different
>> timings.  In this particular case there's no board-level strappings
>> for the different panels--it's assumed that the EDID on the panels can
>> be used to distinguish them.
>>
>> In that case it seems like it would be nice to allow specifying more
>> than one "panel-timing" nodes.  Maybe keyed off some type of ID that's
>> present in the EDID?
>>
>>
>> Is that something we'd want to account for before we land this series?
>>  It seems like it would just be adding an extra level of nodes?
>>
>
> AFAICS, there is no EDID without a DDC bus, which we don't
> seem to have on gru platforms, do we?

IIRC historically we've only done second sourcing when
doable because either:
1. the timings between all the panels we use are compatible, or
2. we have a working DDC to figure it out for us.

In other words, we haven't handled the case where timings are not
compatible and we can't address this by reading EDIDs.

Stéphane

>
> Regards,
> --
> Ezequiel García, VanguardiaSur
> www.vanguardiasur.com.ar
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

[bugzilla-daemon]

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

Bug ID: 106225
   Summary: Kernel panic after modesetting (not on every boot) on
ryzen 5 2400g
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: f.pinamart...@gmail.com

Created attachment 139081
  --> https://bugs.freedesktop.org/attachment.cgi?id=139081=edit
journaltcl log file

On a new Ryzen 5 2400G build, I am using linux-4.16.3 (Arch Linux).
On some boots (~1 out of every 3) I get a kernel panic after modesetting
occurs.
I have attached the relevant systemd logfile (for the entire boot process).
I am not sure what component is failing, but I suspect AMDGPU, since it happens
suspiciously after modesetting.
If it matters, the mainboard is a Gigabyte "AB350N-Gaminig Wifi", with the
latest available BIOS as of writing (BIOS F23d 04/17/2018).
Please advise if more information is required.

-- 
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: [Intel-gfx] [PATCH v7 02/10] drm/i915: Move DP modeset retry work into intel_dp

[Dhinakaran Pandiyan]

On Wed, 2018-04-11 at 18:54 -0400, Lyude Paul wrote:
> While having the modeset_retry_work in intel_connector makes sense with
> SST, this paradigm doesn't make a whole ton of sense when it comes to
> MST since we have to deal with multiple connectors. In most cases, it's
> more useful to just use the intel_dp struct since it indicates whether
> or not we're dealing with an MST device, along with being able to easily
> trace the intel_dp struct back to it's respective connector (if there is
> any). So, move the modeset_retry_work function out of the
> intel_connector struct and into intel_dp.
> 
> Signed-off-by: Lyude Paul 
> Reviewed-by: Manasi Navare 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> 
> V2:
>  - Remove accidental duplicate modeset_retry_work in intel_connector
> V3:
>  - Also check against eDP in intel_hpd_poll_fini() - mdnavare

contradicts with 

commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677
Author: Manasi Navare 
Date:   Thu Oct 12 12:13:38 2017 -0700

drm/i915/edp: Do not do link training fallback or prune modes on EDP

In case of eDP because the panel has a fixed mode, the link rate
and lane count at which it is trained corresponds to the link BW
required to support the native resolution of the panel. In case of
panles with lower resolutions where fewer lanes are hooked up
internally,
that number is reflected in the MAX_LANE_COUNT DPCD register of the
panel.
So it is pointless to fallback to lower link rate/lane count in case
of link training failure on eDP connector since the lower link BW
will not support the native resolution of the panel and we cannot
prune the preferred mode on the eDP connector.




> V4:
>  - Don't bother looping over connectors for canceling modeset rety work,
>just encoders.
> V7:
>  - Fix CHECKPATCH errors
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/i915/intel_display.c  | 14 +++---
>  drivers/gpu/drm/i915/intel_dp.c   | 10 --
>  drivers/gpu/drm/i915/intel_dp_link_training.c |  2 +-
>  drivers/gpu/drm/i915/intel_drv.h  |  6 +++---
>  4 files changed, 19 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e04050ea3e28..18edb9628a54 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15471,20 +15471,28 @@ void intel_connector_unregister(struct 
> drm_connector *connector)
>  
>  static void intel_hpd_poll_fini(struct drm_device *dev)
>  {
> - struct intel_connector *connector;
>   struct drm_connector_list_iter conn_iter;
> + struct intel_connector *connector;
> + struct intel_encoder *encoder;
> + struct intel_dp *intel_dp;
>  
>   /* Kill all the work that may have been queued by hpd. */
>   drm_connector_list_iter_begin(dev, _iter);
>   for_each_intel_connector_iter(connector, _iter) {
> - if (connector->modeset_retry_work.func)
> - cancel_work_sync(>modeset_retry_work);
>   if (connector->hdcp_shim) {
>   cancel_delayed_work_sync(>hdcp_check_work);
>   cancel_work_sync(>hdcp_prop_work);
>   }
>   }
>   drm_connector_list_iter_end(_iter);
> +
> + for_each_intel_encoder(dev, encoder) {
> + if (encoder->type == INTEL_OUTPUT_DP ||

commit 7e732cacb1ae27b2eb6902cabd93e9da086c54f0
Author: Ville Syrjälä 
Date:   Fri Oct 27 22:31:24 2017 +0300

drm/i915: Stop frobbing with DDI encoder->type

Currently the DDI encoder->type will change at runtime depending on
what kind of hotplugs we've processed. That's quite bad since we
can't
really trust that that current value of encoder->type actually
matches
the type of signal we're trying to drive through it.

Let's eliminate that problem by declaring that non-eDP DDI port will
always have the encoder type as INTEL_OUTPUT_DDI. This means the
code
can no longer try to distinguish DP vs. HDMI based on encoder->type.
We'll leave eDP as INTEL_OUTPUT_EDP, since it'll never change and
there's a bunch of code that relies on that value to identify eDP
encoders.



> + encoder->type == INTEL_OUTPUT_EDP) {
> + intel_dp = enc_to_intel_dp(>base);
> + cancel_work_sync(_dp->modeset_retry_work);
> + }
> + }
>  }
>  
>  void intel_modeset_cleanup(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62f82c4298ac..fbb467bc227d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6249,12 +6249,10 @@ static bool intel_edp_init_connector(struct intel_dp 
> *intel_dp,
>  
>  

[PATCH v2 1/3] drm/vc4: Syncobj import support

[Stefan Schake]

Allow userland to specify a syncobj that is waited on before a render job
starts processing.

v2: Use 0 as invalid syncobj to drop flag (Eric)
Drop extra newline (Eric)

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_drv.h |  1 +
 drivers/gpu/drm/vc4/vc4_gem.c | 30 +-
 include/uapi/drm/vc4_drm.h|  7 +++
 3 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 22589d3..554a4e8 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "uapi/drm/vc4_drm.h"
 
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 2107b0d..e305ccde 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "uapi/drm/vc4_drm.h"
 #include "vc4_drv.h"
@@ -1115,6 +1116,7 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
struct drm_vc4_submit_cl *args = data;
struct vc4_exec_info *exec;
struct ww_acquire_ctx acquire_ctx;
+   struct dma_fence *in_fence;
int ret = 0;
 
if ((args->flags & ~(VC4_SUBMIT_CL_USE_CLEAR_COLOR |
@@ -1125,11 +1127,6 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
return -EINVAL;
}
 
-   if (args->pad2 != 0) {
-   DRM_DEBUG("->pad2 must be set to zero\n");
-   return -EINVAL;
-   }
-
exec = kcalloc(1, sizeof(*exec), GFP_KERNEL);
if (!exec) {
DRM_ERROR("malloc failure on exec struct\n");
@@ -1164,6 +1161,29 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
}
}
 
+   if (args->in_sync) {
+   ret = drm_syncobj_find_fence(file_priv, args->in_sync,
+_fence);
+   if (ret)
+   goto fail;
+
+   /* When the fence (or fence array) is exclusively from our
+* context we can skip the wait since jobs are executed in
+* order of their submission through this ioctl and this can
+* only have fences from a prior job.
+*/
+   if (!dma_fence_match_context(in_fence,
+vc4->dma_fence_context)) {
+   ret = dma_fence_wait(in_fence, true);
+   if (ret) {
+   dma_fence_put(in_fence);
+   goto fail;
+   }
+   }
+
+   dma_fence_put(in_fence);
+   }
+
if (exec->args->bin_cl_size != 0) {
ret = vc4_get_bcl(dev, exec);
if (ret)
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
index b95a0e1..d97065b 100644
--- a/include/uapi/drm/vc4_drm.h
+++ b/include/uapi/drm/vc4_drm.h
@@ -183,11 +183,10 @@ struct drm_vc4_submit_cl {
/* ID of the perfmon to attach to this job. 0 means no perfmon. */
__u32 perfmonid;
 
-   /* Unused field to align this struct on 64 bits. Must be set to 0.
-* If one ever needs to add an u32 field to this struct, this field
-* can be used.
+   /* Syncobj handle to wait on. If set, processing of this render job
+* will not start until the syncobj is signaled. 0 means ignore.
 */
-   __u32 pad2;
+   __u32 in_sync;
 };
 
 /**
-- 
2.7.4

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

[PATCH v2 2/3] drm/vc4: Export fence through syncobj

[Stefan Schake]

Allow specifying a syncobj on render job submission where we store the
fence for the job. This gives userland flexible access to the fence.

v2: Use 0 as invalid syncobj to drop flag (Eric)
Don't reintroduce the padding (Eric)

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_gem.c | 30 --
 include/uapi/drm/vc4_drm.h|  6 ++
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index e305ccde..a4c4be3 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -656,7 +656,8 @@ vc4_lock_bo_reservations(struct drm_device *dev,
  */
 static int
 vc4_queue_submit(struct drm_device *dev, struct vc4_exec_info *exec,
-struct ww_acquire_ctx *acquire_ctx)
+struct ww_acquire_ctx *acquire_ctx,
+struct drm_syncobj *out_sync)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_exec_info *renderjob;
@@ -679,6 +680,9 @@ vc4_queue_submit(struct drm_device *dev, struct 
vc4_exec_info *exec,
fence->seqno = exec->seqno;
exec->fence = >base;
 
+   if (out_sync)
+   drm_syncobj_replace_fence(out_sync, exec->fence);
+
vc4_update_bo_seqnos(exec, seqno);
 
vc4_unlock_bo_reservations(dev, exec, acquire_ctx);
@@ -1114,6 +1118,7 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_file *vc4file = file_priv->driver_priv;
struct drm_vc4_submit_cl *args = data;
+   struct drm_syncobj *out_sync = NULL;
struct vc4_exec_info *exec;
struct ww_acquire_ctx acquire_ctx;
struct dma_fence *in_fence;
@@ -1201,12 +1206,33 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
if (ret)
goto fail;
 
+   if (args->out_sync) {
+   out_sync = drm_syncobj_find(file_priv, args->out_sync);
+   if (!out_sync) {
+   ret = -EINVAL;
+   goto fail;
+   }
+
+   /* We replace the fence in out_sync in vc4_queue_submit since
+* the render job could execute immediately after that call.
+* If it finishes before our ioctl processing resumes the
+* render job fence could already have been freed.
+*/
+   }
+
/* Clear this out of the struct we'll be putting in the queue,
 * since it's part of our stack.
 */
exec->args = NULL;
 
-   ret = vc4_queue_submit(dev, exec, _ctx);
+   ret = vc4_queue_submit(dev, exec, _ctx, out_sync);
+
+   /* The syncobj isn't part of the exec data and we need to free our
+* reference even if job submission failed.
+*/
+   if (out_sync)
+   drm_syncobj_put(out_sync);
+
if (ret)
goto fail;
 
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
index d97065b..2be4fe3 100644
--- a/include/uapi/drm/vc4_drm.h
+++ b/include/uapi/drm/vc4_drm.h
@@ -187,6 +187,12 @@ struct drm_vc4_submit_cl {
 * will not start until the syncobj is signaled. 0 means ignore.
 */
__u32 in_sync;
+
+   /* Syncobj handle to export fence to. If set, the fence in the syncobj
+* will be replaced with a fence that signals upon completion of this
+* render job. 0 means ignore.
+*/
+   __u32 out_sync;
 };
 
 /**
-- 
2.7.4

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

[PATCH v2 0/3] drm/vc4: Syncobj import export

[Stefan Schake]

v2 drops the extra syncobj parameter and gets rid of the submit flags
since 0 is never a valid syncobj handle.

This series allows userspace to submit syncobj handles for importing
a fence to wait on or exporting the job fence as part of submission.

The primary use of this is to enable native fence fd support in Mesa.
Userspace implementation is under review and available here:

https://patchwork.freedesktop.org/series/42081/

Stefan Schake (3):
  drm/vc4: Syncobj import support
  drm/vc4: Export fence through syncobj
  drm/vc4: Enable syncobj support

 drivers/gpu/drm/vc4/vc4_drv.c |  3 ++-
 drivers/gpu/drm/vc4/vc4_drv.h |  1 +
 drivers/gpu/drm/vc4/vc4_gem.c | 60 ++-
 include/uapi/drm/vc4_drm.h| 13 +++---
 4 files changed, 65 insertions(+), 12 deletions(-)

-- 
2.7.4

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

[PATCH v2 3/3] drm/vc4: Enable syncobj support

[Stefan Schake]

This doesn't require any additional functionality from the driver but
is a prerequisite to userland calling the syncobj ioctls.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 40ddeaa..d9b8b70 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -175,7 +175,8 @@ static struct drm_driver vc4_drm_driver = {
DRIVER_GEM |
DRIVER_HAVE_IRQ |
DRIVER_RENDER |
-   DRIVER_PRIME),
+   DRIVER_PRIME |
+   DRIVER_SYNCOBJ),
.lastclose = drm_fb_helper_lastclose,
.open = vc4_open,
.postclose = vc4_close,
-- 
2.7.4

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

Re: RFC for a render API to support adaptive sync and VRR

[Daniel Vetter]

On Tue, Apr 24, 2018 at 4:28 PM, Harry Wentland  wrote:
>
>
> On 2018-04-24 08:09 AM, Daniel Vetter wrote:
>> On Mon, Apr 23, 2018 at 02:19:44PM -0700, Manasi Navare wrote:
>>> On Mon, Apr 23, 2018 at 10:40:06AM -0400, Harry Wentland wrote:
 On 2018-04-20 04:32 PM, Manasi Navare wrote:
> On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote:
>> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard  wrote:
>>> Michel Dänzer  writes:
 Time-based presentation seems to be the right approach for preventing
 micro-stutter in games as well, Croteam developers have been 
 researching
 this.
>>>
>>> Both the Vulkan GOOGLE_display_timing extension and X11 Present
>>> extension offer the ability to specify the desired display time in
>>> seconds.
>>>
>>> Similarly, I'd suggest that the min/max display refresh rate values be
>>> advertised as time between frames rather than frames per second.
>
> So there is a global min and max refresh rate as advertised by the monitor
> range descriptor. That I guess can be exposed as a global range in terms 
> of
> min and max time between frames as a global property of the connector.
>
> We dont need the per mode min and max refresh rate to be exposed right?

 If I understand VRR right, with CinemaVRR acceptable refresh rates might 
 fall outside the range advertised by the monitor. Would we
  1) advertise 24/1.001 as a lower bound,
  2) expect media apps to use the lower bound simply for informational 
 purposes,
  3) or simply not support CinemaVRR?

 (1) has the added caveat that not all reported rates would be supported.

 Alternatively a bit could indicate that CinemaVRR is support, but I'm not 
 sure if user mode would need all these details.

 Harry
>>>
>>> Are there special CinemaVRR suported monitors? In that case we need to 
>>> understand how those monitors
>>> advertise the monitor range and if they have a bit in EDID that indicate 
>>> they are CinemaVRR capable
>>> as opposed to just the Adaptive Sync/VRR.
>>> Harry, if you have one of those monitors, could you send the EDID dump for 
>>> that?
>>
>> As long as the any multiple of the 24/1.001 refresh rate is within the
>> officially supported refresh range rate this should work out. Maybe we'll
>> end up uploading 2x (to run at ~48Hz), maybe the kernel only uploads at
>> 24Hz. But should all be fine.
>>
>
> Would kernel driver upload 48Hz when UMD asks for 24Hz or would UMD be 
> expected to submit double frames?
>
> If kernel driver supports frame doubling (like our DC driver) we would 
> probably report half of monitor-reported min-refresh (or rather double of 
> monitor-reported max frame time).

Your driver (amdgpu) already supports frame doubling, except only for
vblank seqno instead of timestamps. Whether VRR can get down to 24Hz
or not is totally irrelevant from userspace's point of view. By
default the kernel is expected to keep display the current frame for
as long as userspace gives it a new one. There's no expectation that
userspace provides a new buffer for every vblank (whether that's a
fixed or variable refresh rate doesn't matter).
-Daniel

>
> Harry
>
>> Ofc if we have CinemaVRR screens which don't fit this, then maybe we need
>> to figure out something ...
>> -Daniel
>>
>>>
>>> Manasi
>>>

>
>>>
>>> I'd also encourage using a single unit for all of these values,
>>> preferably nanoseconds. Absolute times should all be referenced to
>>> CLOCK_MONOTONIC.
>>
>> +1 on everything Keith said. I got somehow dragged in khr vk
>> discussions around preventing micro-stuttering, and consensus seems to
>> be that timestamps for scheduling frames is the way to go, most likely
>> absolute ones (not everything is running Linux unfortunately, so can't
>> go outright and claim it's guaranteed to be CLOCK_MONOTONIC).
>> -Daniel
>
> And yes I also got consensus from Mesa and media folks about using the
> absolute timestamp for scheduling the frames and then the driver will
> modify the vblank logic to "present no earlier than the timestamp"
>
> Manasi
>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing 

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

[Daniel Vetter]

On Tue, Apr 24, 2018 at 05:02:40PM -0400, Andrey Grodzovsky wrote:
> 
> 
> On 04/24/2018 03:44 PM, Daniel Vetter wrote:
> > On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
> > > Adding the dri-devel list, since this is driver independent code.
> > > 
> > > 
> > > On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
> > > > Avoid calling wait_event_killable when you are possibly being called
> > > > from get_signal routine since in that case you end up in a deadlock
> > > > where you are alreay blocked in singla processing any trying to wait
> > > Multiple typos here, "[...] already blocked in signal processing and 
> > > [...]"?
> > > 
> > > 
> > > > on a new signal.
> > > > 
> > > > Signed-off-by: Andrey Grodzovsky 
> > > > ---
> > > >   drivers/gpu/drm/scheduler/gpu_scheduler.c | 5 +++--
> > > >   1 file changed, 3 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
> > > > b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > > > index 088ff2b..09fd258 100644
> > > > --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > > > +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > > > @@ -227,9 +227,10 @@ void drm_sched_entity_do_release(struct 
> > > > drm_gpu_scheduler *sched,
> > > > return;
> > > > /**
> > > >  * The client will not queue more IBs during this fini, consume 
> > > > existing
> > > > -* queued IBs or discard them on SIGKILL
> > > > +* queued IBs or discard them when in death signal state since
> > > > +* wait_event_killable can't receive signals in that state.
> > > > */
> > > > -   if ((current->flags & PF_SIGNALED) && current->exit_code == 
> > > > SIGKILL)
> > > > +   if (current->flags & PF_SIGNALED)
> > You want fatal_signal_pending() here, instead of inventing your own broken
> > version.
> 
> I rely on current->flags & PF_SIGNALED because this being set from within
> get_signal,
> meaning I am within signal processing  in which case I want to avoid any
> signal based wait for that task,
> From what i see in the code, task_struct.pending.signal is being set for
> other threads in same
> group (zap_other_threads) or for other scenarios, those task are still able
> to receive signals
> so calling wait_event_killable there will not have problem.
> > > > entity->fini_status = -ERESTARTSYS;
> > > > else
> > > > entity->fini_status = 
> > > > wait_event_killable(sched->job_scheduled,
> > But really this smells like a bug in wait_event_killable, since
> > wait_event_interruptible does not suffer from the same bug. It will return
> > immediately when there's a signal pending.
> 
> Even when wait_event_interruptible is called as following -
> ...->do_signal->get_signal->->wait_event_interruptible ?
> I haven't tried it but wait_event_interruptible is very much alike to
> wait_event_killable so I would assume it will also
> not be interrupted if called like that. (Will give it a try just out of
> curiosity anyway)

wait_event_killabel doesn't check for fatal_signal_pending before calling
schedule, so definitely has a nice race there.

But if you're sure that you really need to check PF_SIGNALED, then I'm
honestly not clear on what you're trying to pull off here. Your sparse
explanation of what happens isn't enough, since I have no idea how you can
get from get_signal() to the above wait_event_killable callsite.
-Daniel

> 
> Andrey
> 
> > 
> > I think this should be fixed in core code, not papered over in some
> > subsystem.
> > -Daniel
> > 
> > > 
> > > -- 
> > > Earthling Michel Dänzer   |   http://www.amd.com
> > > Libre software enthusiast | Mesa and X developer
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

[bugzilla-daemon]

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

--- Comment #23 from dwagner  ---
(I should mention that a very long time ago, I also posted a bug report
specifically regarding the EDID-loading feature:
https://bugs.freedesktop.org/show_bug.cgi?id=102202)

-- 
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/3] drm/scheduler: Don't call wait_event_killable for signaled process.

[Andrey Grodzovsky]

On 04/24/2018 05:21 PM, Eric W. Biederman wrote:

Andrey Grodzovsky  writes:


On 04/24/2018 03:44 PM, Daniel Vetter wrote:

On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:

Adding the dri-devel list, since this is driver independent code.


On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:

Avoid calling wait_event_killable when you are possibly being called
from get_signal routine since in that case you end up in a deadlock
where you are alreay blocked in singla processing any trying to wait

Multiple typos here, "[...] already blocked in signal processing and [...]"?



on a new signal.

Signed-off-by: Andrey Grodzovsky 
---
   drivers/gpu/drm/scheduler/gpu_scheduler.c | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 088ff2b..09fd258 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -227,9 +227,10 @@ void drm_sched_entity_do_release(struct drm_gpu_scheduler 
*sched,
return;
/**
 * The client will not queue more IBs during this fini, consume existing
-* queued IBs or discard them on SIGKILL
+* queued IBs or discard them when in death signal state since
+* wait_event_killable can't receive signals in that state.
*/
-   if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL)
+   if (current->flags & PF_SIGNALED)

You want fatal_signal_pending() here, instead of inventing your own broken
version.

I rely on current->flags & PF_SIGNALED because this being set from
within get_signal,

It doesn't mean that.  Unless you are called by do_coredump (you
aren't).


Looking in latest code here
https://elixir.bootlin.com/linux/v4.17-rc2/source/kernel/signal.c#L2449
i see that current->flags |= PF_SIGNALED; is out side of
if (sig_kernel_coredump(signr)) {...} scope

Andrey


The closing of files does not happen in do_coredump.
Which means you are being called from do_exit.
In fact you are being called after exit_files which closes
the files.  The actual __fput processing happens in task_work_run.


meaning I am within signal processing  in which case I want to avoid
any signal based wait for that task,
 From what i see in the code, task_struct.pending.signal is being set
for other threads in same
group (zap_other_threads) or for other scenarios, those task are still
able to receive signals
so calling wait_event_killable there will not have problem.

Excpet that you are geing called after from do_exit and after exit_files
which is after exit_signal.  Which means that PF_EXITING has been set.
Which implies that the kernel signal handling machinery has already
started being torn down.

Not as much as I would like to happen at that point as we are still
left with some old CLONE_PTHREAD messes in the code that need to be
cleaned up.

Still given the fact you are task_work_run it is quite possible even
release_task has been run on that task before the f_op->release method
is called.  So you simply can not count on signals working.

Which in practice leaves a timeout for ending your wait.  That code can
legitimately be in a context that is neither interruptible nor killable.


entity->fini_status = -ERESTARTSYS;
else
entity->fini_status = wait_event_killable(sched->job_scheduled,

But really this smells like a bug in wait_event_killable, since
wait_event_interruptible does not suffer from the same bug. It will return
immediately when there's a signal pending.

Even when wait_event_interruptible is called as following -
...->do_signal->get_signal->->wait_event_interruptible ?
I haven't tried it but wait_event_interruptible is very much alike to
wait_event_killable so I would assume it will also
not be interrupted if called like that. (Will give it a try just out
of curiosity anyway)

As PF_EXITING is set want_signal should fail and the signal state of the
task should not be updatable by signals.

Eric




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

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

[bugzilla-daemon]

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

--- Comment #7 from dwagner  ---
I cannot comment on how useful above patches are for the topic of this bug
report, but they are helpful for bug report
https://bugs.freedesktop.org/show_bug.cgi?id=103277

-- 
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 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

[bugzilla-daemon]

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

dwagner  changed:

   What|Removed |Added

 Status|NEEDINFO|REOPENED

-- 
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 106224] "Medieval 2 Total War" will sometimes crash system on a R9 270 card

[bugzilla-daemon]

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

Bug ID: 106224
   Summary: "Medieval 2 Total War" will sometimes crash system on
a R9 270 card
   Product: Mesa
   Version: 18.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: jo...@lunarg.com
QA Contact: dri-devel@lists.freedesktop.org

Overview:
After rebooting the machine and starting the game "Medieval 2:total war", and
not giving any input from the keyboard after the game starts, the game will
crash the system.

Steps to Reproduce:
While I wasn't able to reproduce this on my machine using my AMD RX480 card, my
co-workers machine using an AMD R9 270 seemed pretty consistent. 

As stated above to reproduce the issue: after a reboot of the machine, if the
game is started through steam and left alone with no input from the keyboard
the machine will freeze.

Additional Info:
I've been having trouble getting any log messages or output as the machine will
freeze completely needing a hard reboot. If I can get any I will post it here.

-- 
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 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

[bugzilla-daemon]

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

--- Comment #22 from dwagner  ---
Two patches posted by Harry Wentland in bug report
https://bugs.freedesktop.org/show_bug.cgi?id=106159
today may hold the key to get finally rid of this long-standing bug:

When I apply 
https://bugs.freedesktop.org/attachment.cgi?id=139069
and
https://bugs.freedesktop.org/attachment.cgi?id=139070
on top of
"commit ecdd681a62f592e03c3783709526278bdc7ad5cc (HEAD,
origin/drm-next-4.18-wip)"
_then_ I can S3-resume without crashing with amdgpu.dc=1

_But_ the system will still crash on S3-resume if I use the
"drm.edid_firmware=edid/LG_EG9609_edid.bin"
kernel command line option (which I would like to use to make X11 mode
detection independent of whether the connected TV is off when booting/resuming)

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

Re: [PATCH] drm: Don't EXPORT drm_add/reset_display_info

[Daniel Vetter]

On Tue, Apr 24, 2018 at 08:29:36PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 24, 2018 at 04:22:42PM +0200, Daniel Vetter wrote:
> > Only used within drm.ko, no need to tempt drivers.
> > 
> > Cc: Keith Packard 
> > Cc: Ville Syrjala 
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Ville Syrjälä 

Thanks for review, applied.
-Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_crtc_internal.h | 2 ++
> >  drivers/gpu/drm/drm_edid.c  | 2 --
> >  include/drm/drm_edid.h  | 2 --
> >  3 files changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> > b/drivers/gpu/drm/drm_crtc_internal.h
> > index 3c2b82865ad2..5d307b23a4e6 100644
> > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > @@ -220,3 +220,5 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> >  
> >  /* drm_edid.c */
> >  void drm_mode_fixup_1366x768(struct drm_display_mode *mode);
> > +void drm_reset_display_info(struct drm_connector *connector);
> > +u32 drm_add_display_info(struct drm_connector *connector, const struct 
> > edid *edid);
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 134069f36482..61dd9a2fbe5b 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4454,7 +4454,6 @@ drm_reset_display_info(struct drm_connector 
> > *connector)
> >  
> > info->non_desktop = 0;
> >  }
> > -EXPORT_SYMBOL_GPL(drm_reset_display_info);
> >  
> >  u32 drm_add_display_info(struct drm_connector *connector, const struct 
> > edid *edid)
> >  {
> > @@ -4538,7 +4537,6 @@ u32 drm_add_display_info(struct drm_connector 
> > *connector, const struct edid *edi
> > info->color_formats |= DRM_COLOR_FORMAT_YCRCB422;
> > return quirks;
> >  }
> > -EXPORT_SYMBOL_GPL(drm_add_display_info);
> >  
> >  static int validate_displayid(u8 *displayid, int length, int idx)
> >  {
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 8d89a9c3748d..b25d12ef120a 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -465,8 +465,6 @@ struct edid *drm_get_edid(struct drm_connector 
> > *connector,
> >  struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
> >  struct i2c_adapter *adapter);
> >  struct edid *drm_edid_duplicate(const struct edid *edid);
> > -void drm_reset_display_info(struct drm_connector *connector);
> > -u32 drm_add_display_info(struct drm_connector *connector, const struct 
> > edid *edid);
> >  int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
> >  
> >  u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
> > -- 
> > 2.16.2
> 
> -- 
> Ville Syrjälä
> Intel

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

Re: [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

[Sean Paul]

On Fri, Apr 13, 2018 at 6:01 AM Daniel Vetter 
wrote:

> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.

> We also tend to not revoke commit rights for people no longer
> regularly active in a given project, as long as they're still part of
> the larger community.

> Finally make sure that commit rights, like anything happening on fd.o
> infrastructre, is subject to the fd.o's Code of Conduct.

> v2: Point at MAINTAINERS for contact info (Daniel S.)

> v3:
> - Make it clear that commit rights are voluntary and that committers
>need to acknowledge positively when they're nominated by someone
>else (Keith).
> - Encourage committers to drop their commit rights when they're no
>longer active, and make it clear they'll get readded (Keith).
> - Add a line that maintainers and committers should actively nominate
>new committers (me).

> v4: Typo (Petri).

> v5: Typo (Sean).

I don't remember this, but good for me!

Current revision looks good, and I am supportive of applying it to drm-misc.

Acked-by: Sean Paul 


> v6: Wording clarifications and spelling (Jani).

> v7: Require an explicit commitment to the documented merge criteria
> and rules, instead of just the implied one through the Code of Conduct
> threat (Jani).

> Acked-by: Alex Deucher 
> Acked-by: Arkadiusz Hiler 
> Acked-by: Daniel Stone 
> Acked-by: Eric Anholt 
> Acked-by: Gustavo Padovan 
> Acked-by: Petri Latvala 
> Cc: Alex Deucher 
> Cc: Arkadiusz Hiler 
> Cc: Ben Widawsky 
> Cc: Daniel Stone 
> Cc: Dave Airlie 
> Cc: Eric Anholt 
> Cc: Gustavo Padovan 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Keith Packard 
> Cc: Kenneth Graunke 
> Cc: Kristian H. Kristensen 
> Cc: Maarten Lankhorst 
> Cc: Petri Latvala 
> Cc: Rodrigo Vivi 
> Cc: Sean Paul 
> Reviewed-by: Keith Packard 
> Signed-off-by: Daniel Vetter 
> ---
> If you wonder about the wide distribution list for an igt patch: I'd
> like to start a discussions about x.org community norms around commit
> rights at large, at least for all the shared repos. I plan to propose
> the same text for drm-misc and libdrm too, and hopefully others like
> mesa/xserver/wayland would follow.

> fd.o admins also plan to discuss this (and a pile of other topics and
> hosting and code of conduct) with all projects, ideally this here
> would end up as the starting point for establishing some community
> norms.
> -Daniel
> ---
>   CONTRIBUTING | 48 
>   1 file changed, 48 insertions(+)

> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index 0180641be3aa..8a118134275c 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -51,4 +51,52 @@ A short list of contribution guidelines:
>   - Changes to the testcases are automatically tested. Take the results
into
> account before merging.

> +Commit rights
> +-
> +
> +Commit rights will be granted to anyone who requests them and fulfills
the
> +below criteria:
> +
> +- Submitted a few (5-10 as a rule of thumb) non-trivial (not just simple
> +  spelling fixes and whitespace adjustment) patches that have been merged
> +  already.
> +
> +- Are actively participating on discussions about their work (on the
mailing
> +  list or IRC). This should not be interpreted as a requirement to
review other
> +  peoples patches but just make sure that patch submission isn't one-way
> +  communication. Cross-review is still highly encouraged.
> +
> +- Will be regularly contributing further patches. This includes regular
> +  contributors to other parts of the open source graphics stack who only
> +  do the oddball rare patch within igt itself.
> +
> +- Agrees to use their commit rights in accordance with the documented
merge
> +  criteria, tools, and processes.
> +
> +Apply for an account (and any other account change requests) through
> +
> +https://www.freedesktop.org/wiki/AccountRequests/
> +
> +and please ping the maintainers if your request is stuck.
> +
> +Committers are encouraged to request their commit rights get removed
when they
> +no longer contribute to the project. Commit rights will be reinstated
when they
> +come back to the project.
> +
> +Maintainers and committers should encourage contributors to request
commit
> +rights, especially junior contributors tend to underestimate their

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

[Andrey Grodzovsky]

On 04/24/2018 03:44 PM, Daniel Vetter wrote:

On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:

Adding the dri-devel list, since this is driver independent code.


On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:

Avoid calling wait_event_killable when you are possibly being called
from get_signal routine since in that case you end up in a deadlock
where you are alreay blocked in singla processing any trying to wait

Multiple typos here, "[...] already blocked in signal processing and [...]"?



on a new signal.

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/scheduler/gpu_scheduler.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 088ff2b..09fd258 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -227,9 +227,10 @@ void drm_sched_entity_do_release(struct drm_gpu_scheduler 
*sched,
return;
/**
 * The client will not queue more IBs during this fini, consume existing
-* queued IBs or discard them on SIGKILL
+* queued IBs or discard them when in death signal state since
+* wait_event_killable can't receive signals in that state.
*/
-   if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL)
+   if (current->flags & PF_SIGNALED)

You want fatal_signal_pending() here, instead of inventing your own broken
version.


I rely on current->flags & PF_SIGNALED because this being set from 
within get_signal,
meaning I am within signal processing  in which case I want to avoid any 
signal based wait for that task,
From what i see in the code, task_struct.pending.signal is being set 
for other threads in same
group (zap_other_threads) or for other scenarios, those task are still 
able to receive signals

so calling wait_event_killable there will not have problem.

entity->fini_status = -ERESTARTSYS;
else
entity->fini_status = wait_event_killable(sched->job_scheduled,

But really this smells like a bug in wait_event_killable, since
wait_event_interruptible does not suffer from the same bug. It will return
immediately when there's a signal pending.


Even when wait_event_interruptible is called as following - 
...->do_signal->get_signal->->wait_event_interruptible ?
I haven't tried it but wait_event_interruptible is very much alike to 
wait_event_killable so I would assume it will also
not be interrupted if called like that. (Will give it a try just out of 
curiosity anyway)


Andrey



I think this should be fixed in core code, not papered over in some
subsystem.
-Daniel



--
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

[Bug 106006] Kernel 4.16.0+ switch amdgpu.dc=1 causes screen brightness set to 1 to be dimmed by default

[bugzilla-daemon]

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

--- Comment #14 from Joel Sass  ---
Sorry, I completely forgot that I was using a custom kernel. I downloaded it
from here:

https://github.com/M-Bab/linux-kernel-amdgpu-binaries

and installed the .deb files directly.

Here's the source: https://github.com/M-Bab/linux-kernel-amdgpu

-- 
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: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Dongwon Kim]

Had a meeting with Daniel and talked about bringing out generic
part of hyper-dmabuf to the userspace, which means we most likely
reuse IOCTLs defined in xen-zcopy for our use-case if we follow
his suggestion.

So assuming we use these IOCTLs as they are,
Several things I would like you to double-check..

1. returning gref as is to the user space is still unsafe because
it is a constant, easy to guess and any process that hijacks it can easily
exploit the buffer. So I am wondering if it's possible to keep dmabuf-to
-gref or gref-to-dmabuf in kernel space and add other layers on top
of those in actual IOCTLs to add some safety.. We introduced flink like
hyper_dmabuf_id including random number but many says even that is still
not safe.

2. maybe we could take hypervisor-independent process (e.g. SGT<->page)
out of xen-zcopy and put those in a new helper library. 

3. please consider the case where original DMA-BUF's first offset
and last length are not 0 and PAGE_SIZE respectively. I assume current
xen-zcopy only supports page-aligned buffer with PAGE_SIZE x n big.

thanks,
DW

On Tue, Apr 24, 2018 at 02:59:39PM +0300, Oleksandr Andrushchenko wrote:
> On 04/24/2018 02:54 PM, Daniel Vetter wrote:
> >On Mon, Apr 23, 2018 at 03:10:35PM +0300, Oleksandr Andrushchenko wrote:
> >>On 04/23/2018 02:52 PM, Wei Liu wrote:
> >>>On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote:
> >>  the gntdev.
> >>
> >>I think this is generic enough that it could be implemented by a
> >>device not tied to Xen. AFAICT the hyper_dma guys also wanted
> >>something similar to this.
> >You can't just wrap random userspace memory into a dma-buf. We've just 
> >had
> >this discussion with kvm/qemu folks, who proposed just that, and after a
> >bit of discussion they'll now try to have a driver which just wraps a
> >memfd into a dma-buf.
> So, we have to decide either we introduce a new driver
> (say, under drivers/xen/xen-dma-buf) or extend the existing
> gntdev/balloon to support dma-buf use-cases.
> 
> Can anybody from Xen community express their preference here?
> 
> >>>Oleksandr talked to me on IRC about this, he said a few IOCTLs need to
> >>>be added to either existing drivers or a new driver.
> >>>
> >>>I went through this thread twice and skimmed through the relevant
> >>>documents, but I couldn't see any obvious pros and cons for either
> >>>approach. So I don't really have an opinion on this.
> >>>
> >>>But, assuming if implemented in existing drivers, those IOCTLs need to
> >>>be added to different drivers, which means userspace program needs to
> >>>write more code and get more handles, it would be slightly better to
> >>>implement a new driver from that perspective.
> >>If gntdev/balloon extension is still considered:
> >>
> >>All the IOCTLs will be in gntdev driver (in current xen-zcopy terminology):
> I was lazy to change dumb to dma-buf, so put this notice ;)
> >>  - DRM_ICOTL_XEN_ZCOPY_DUMB_FROM_REFS
> >>  - DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS
> >>  - DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE
> >s/DUMB/DMA_BUF/ please. This is generic dma-buf, it has nothing to do with
> >the dumb scanout buffer support in the drm/gfx subsystem. This here can be
> >used for any zcopy sharing among guests (as long as your endpoints
> >understands dma-buf, which most relevant drivers do).
> Of course, please see above
> >-Daniel
> >
> >>Balloon driver extension, which is needed for contiguous/DMA
> >>buffers, will be to provide new *kernel API*, no UAPI is needed.
> >>
> >>>Wei.
> >>Thank you,
> >>Oleksandr
> >>___
> >>dri-devel mailing list
> >>dri-devel@lists.freedesktop.org
> >>https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

[bugzilla-daemon]

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

--- Comment #6 from Joel Sass  ---
Will do! Sorry, I haven't had much time for testing recently.

-- 
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 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+

[bugzilla-daemon]

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

--- Comment #4 from Joel Sass  ---
Hey Harry,

Thanks for your help.

Should I be using my current kernel, or just download the newest source to
apply these patches against?

Some of the other patches didn't really have the context useful to patch
against, and I am not sure if these kernels will have the amdgpu.dc kernel
switches.

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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #49 from MirceaKitsune  ---
Sorry about that: I posted my last message before reading your last one, and
didn't notice your mention about /var/log/messages being obsolete. Just
mentioning so you don't think I ignored what you said.

I'll look deeper in /var/log for anything useful. Here's what that directory
contains in case the list is of any use:

linux-qz0r:/var/log # ls ./ -1
acpid
alternatives.log
apache2
apparmor
audit
boot.log
boot.msg
boot.omsg
btmp
chrony
cluster
ConsoleKit
cups
fglrx-build.log
firebird
firewall
firewall-20180313.xz
hp
journal
kdm.log
kdm.log-20130112.xz
kdm.log-20130331.xz
kdm.log-20130601.xz
kdm.log-20130818.xz
kdm.log-20131108.xz
krb5
lastlog
localmessages
mail
mail.err
mail.info
mail.warn
mcelog
messages
messages-20180313.xz
messages-20180402.xz
messages-20180411.xz
messages-20180421.xz
mumble-server
mysql
NetworkManager
NetworkManager-20180313.xz
news
nscd.log
ntp
pbl-20180313.log.xz
pbl.log
pk_backend_zypp
pk_backend_zypp-1
pm-powersave.log
samba
snapper.log
speech-dispatcher
sssd
tallylog
teamviewer11
tor
tuned
updateTestcase-2018-04-21-16-05-56
updateTestcase-2018-04-24-15-18-49
warn
warn-20180313.xz
wpa_supplicant.log
wpa_supplicant.log-20180313.xz
wtmp
wtmp-20180313.xz
wtmp-20180413.xz
xinetd.log
Xorg.0.log
Xorg.0.log.old
Xorg.1.log
Xorg.1.log.old
YaST2
zypp
zypper.log
zypper.log-20180313
zypper.log-20180316.xz
zypper.log-20180321.xz
zypper.log-20180324.xz
zypper.log-20180328.xz
zypper.log-20180329.xz
zypper.log-20180402.xz
zypper.log-20180405.xz
zypper.log-20180409.xz
zypper.log-20180411.xz
zypper.log-20180414.xz
zypper.log-20180416.xz
zypper.log-20180419.xz
zypper.log-20180421.xz

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #48 from MirceaKitsune  ---
Created attachment 139071
  --> https://bugs.freedesktop.org/attachment.cgi?id=139071=edit
/var/log/messages

I managed to trigger the GPU freeze while running Xonotic through apitrace.
Upon restarting the machine, I still found the resulting xonotic-glx.trace file
on my drive. Unfortunately the trace seems to end several seconds before the
crash, despite my attempts to restart the system using the REISUB SysRq keys. A
warning in the console also indicates this when playing back the trace:

warning: unexpected end of file while reading trace

Do you have any advice on how I can make sure the trace captures the moment of
the freeze, rather than last recording several seconds before it happens? Would
it perhaps be possible to use SSH or some other library to create or deposit
the recorded trace on my other computer via LAN connection?

Meanwhile I'm attaching the output of /var/log/messages which I understand is
the name of /var/log/syslog for my distribution. Please let me know if this is
the correct kernel log you mentioned.

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #47 from i...@yahoo.com ---
(In reply to MirceaKitsune from comment #46)
> I found out what's causing the apitrace crash: It no longer happens when I
> use fresh settings, therefore something in my config was breaking it. Upon
> further inspection it seems to be one of the visual effects. I'll try again
> with different settings, and see if I can find a config that still triggers
> the GPU lockup without also making apitrace crash to the desktop.
> 
> I also looked up where the kernel output should be located on openSUSE. I'm
> told that it's /var/log/messages which indeed exists on my system. Next time
> I experience the freeze, I will post that file here as instructed.

You can report the apitrace crash to the apitrace issue tracker. Include
everything needed to replicate it (aka Xonotic version, options, commands).
https://github.com/apitrace/apitrace/issues

You already have posted a /var/log/messages with a crash here, it doesn't have
any kernel oops/panics. No point of posting another.
See if there are any other /var/log/* files that might contain these.

Here is how a shader hang look in my logs (that bug was reported and fixed):

kernel: [19746.660911] radeon :01:00.0: ring 0 stalled for more than
10030msec
kernel: [19746.660915] radeon :01:00.0: GPU lockup (current fence id
0x0039874d last fence id 0x00398759 on ring 0)
kernel: [19746.844799] radeon :01:00.0: couldn't schedule ib
kernel: [19746.844837] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error
destroying UVD (-22)!
kernel: [19748.260945] [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait
timed out.
kernel: [19748.260965] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon:
failed testing IB on GFX ring (-110).
kernel: [19748.438730] radeon :01:00.0: couldn't schedule ib
kernel: [19748.438761] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error
destroying UVD (-22)!

-- 
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] Intel: Add a Kaby Lake PCI ID

[Rodrigo Vivi]

On Tue, Apr 24, 2018 at 12:42:39PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> Based on kernel commit '672e314b21dc ("drm/i915/kbl: Add KBL GT2 sku")'
> 
> v2: name change M -> ULX, add enumeration in KBL ULX
> v3: add entry to IS_KABYLAKE

reviewed and pushed. Thanks for the patch.

> 
> Signed-off-by: Matt Atwood 
> ---
>  intel/intel_chipset.h | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 01d250e..ba2e3ac 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -200,7 +200,8 @@
>  #define PCI_CHIP_KABYLAKE_ULT_GT2F   0x5921
>  #define PCI_CHIP_KABYLAKE_ULX_GT1_5  0x5915
>  #define PCI_CHIP_KABYLAKE_ULX_GT10x590E
> -#define PCI_CHIP_KABYLAKE_ULX_GT20x591E
> +#define PCI_CHIP_KABYLAKE_ULX_GT2_0  0x591E
> +#define PCI_CHIP_KABYLAKE_ULX_GT2_1  0x591C
>  #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912
>  #define PCI_CHIP_KABYLAKE_M_GT2  0x5917
>  #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902
> @@ -455,7 +456,8 @@
>  
>  #define IS_KBL_GT2(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT2   || \
>(devid) == PCI_CHIP_KABYLAKE_ULT_GT2F  || \
> -  (devid) == PCI_CHIP_KABYLAKE_ULX_GT2   || \
> +  (devid) == PCI_CHIP_KABYLAKE_ULX_GT2_0 || \
> +  (devid) == PCI_CHIP_KABYLAKE_ULX_GT2_1 || \
>(devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \
>(devid) == PCI_CHIP_KABYLAKE_M_GT2 || \
>(devid) == PCI_CHIP_KABYLAKE_HALO_GT2  || \
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Intel: Add a Kaby Lake PCI ID

[matthew . s . atwood]

From: Matt Atwood 

Based on kernel commit '672e314b21dc ("drm/i915/kbl: Add KBL GT2 sku")'

v2: name change M -> ULX, add enumeration in KBL ULX
v3: add entry to IS_KABYLAKE

Signed-off-by: Matt Atwood 
---
 intel/intel_chipset.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 01d250e..ba2e3ac 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -200,7 +200,8 @@
 #define PCI_CHIP_KABYLAKE_ULT_GT2F 0x5921
 #define PCI_CHIP_KABYLAKE_ULX_GT1_50x5915
 #define PCI_CHIP_KABYLAKE_ULX_GT1  0x590E
-#define PCI_CHIP_KABYLAKE_ULX_GT2  0x591E
+#define PCI_CHIP_KABYLAKE_ULX_GT2_00x591E
+#define PCI_CHIP_KABYLAKE_ULX_GT2_10x591C
 #define PCI_CHIP_KABYLAKE_DT_GT2   0x5912
 #define PCI_CHIP_KABYLAKE_M_GT20x5917
 #define PCI_CHIP_KABYLAKE_DT_GT1   0x5902
@@ -455,7 +456,8 @@
 
 #define IS_KBL_GT2(devid)  ((devid) == PCI_CHIP_KABYLAKE_ULT_GT2   || \
 (devid) == PCI_CHIP_KABYLAKE_ULT_GT2F  || \
-(devid) == PCI_CHIP_KABYLAKE_ULX_GT2   || \
+(devid) == PCI_CHIP_KABYLAKE_ULX_GT2_0 || \
+(devid) == PCI_CHIP_KABYLAKE_ULX_GT2_1 || \
 (devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \
 (devid) == PCI_CHIP_KABYLAKE_M_GT2 || \
 (devid) == PCI_CHIP_KABYLAKE_HALO_GT2  || \
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v8 01/10] drm/atomic: Print debug message on atomic check failure

[Dhinakaran Pandiyan]

On Wed, 2018-04-11 at 19:42 -0400, Lyude Paul wrote:
> Does what it says on the label, it's a little confusing debugging atomic
> check failures otherwise.
> 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/drm_atomic.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7d25c42f22db..972a7e9634ab 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1705,8 +1705,11 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>   if (config->funcs->atomic_check)
>   ret = config->funcs->atomic_check(state->dev, state);
>  
> - if (ret)
> + if (ret) {
> + DRM_DEBUG_ATOMIC("atomic driver check for %p failed: %d\n",
> +  state, ret);
>   return ret;
> + }
>  

nit: Would have slightly looked better if the 'ret' check was moved
inside the branch for funcs->atomic_check.

Reviewed-by: Dhinakaran Pandiyan 



>   if (!state->allow_modeset) {
>   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {

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

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

[Daniel Vetter]

On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
> 
> Adding the dri-devel list, since this is driver independent code.
> 
> 
> On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
> > Avoid calling wait_event_killable when you are possibly being called
> > from get_signal routine since in that case you end up in a deadlock
> > where you are alreay blocked in singla processing any trying to wait
> 
> Multiple typos here, "[...] already blocked in signal processing and [...]"?
> 
> 
> > on a new signal.
> > 
> > Signed-off-by: Andrey Grodzovsky 
> > ---
> >  drivers/gpu/drm/scheduler/gpu_scheduler.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
> > b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > index 088ff2b..09fd258 100644
> > --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > @@ -227,9 +227,10 @@ void drm_sched_entity_do_release(struct 
> > drm_gpu_scheduler *sched,
> > return;
> > /**
> >  * The client will not queue more IBs during this fini, consume existing
> > -* queued IBs or discard them on SIGKILL
> > +* queued IBs or discard them when in death signal state since
> > +* wait_event_killable can't receive signals in that state.
> > */
> > -   if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL)
> > +   if (current->flags & PF_SIGNALED)

You want fatal_signal_pending() here, instead of inventing your own broken
version.
> > entity->fini_status = -ERESTARTSYS;
> > else
> > entity->fini_status = wait_event_killable(sched->job_scheduled,

But really this smells like a bug in wait_event_killable, since
wait_event_interruptible does not suffer from the same bug. It will return
immediately when there's a signal pending.

I think this should be fixed in core code, not papered over in some
subsystem.
-Daniel

> > 
> 
> 
> -- 
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v3 1/2] drm/panel: Remove drm_panel_detach() calls from all panel drives

[Daniel Vetter]

On Tue, Apr 24, 2018 at 06:51:07PM +0300, Jyri Sarha wrote:
> Remove all drm_panel_detach() calls from all panel drives update the
> kernel doc for drm_panel_detach().
> 
> Setting the connector and drm to NULL when the drm panel device is
> going away hardly serves any purpose. Usually the the whole memory
> structure is freed right after the remove call. However, calling the
> detach function from the master drm device, and setting the connector
> pointer to NULL, has the logic of marking the panel again as available
> for another drm master to attach. The usual situation would be the same
> drm master device binding again.
> 
> Signed-off-by: Jyri Sarha 

Yeah this makes tons of sense, no panel driver calls attach either.

> ---
>  drivers/gpu/drm/drm_panel.c  | 4 
>  drivers/gpu/drm/panel/panel-innolux-p079zca.c| 1 -
>  drivers/gpu/drm/panel/panel-jdi-lt070me05000.c   | 1 -
>  drivers/gpu/drm/panel/panel-lvds.c   | 1 -
>  drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 1 -
>  drivers/gpu/drm/panel/panel-seiko-43wvf1g.c  | 1 -
>  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c  | 1 -
>  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c  | 1 -
>  drivers/gpu/drm/panel/panel-simple.c | 1 -
>  drivers/gpu/drm/panel/panel-sitronix-st7789v.c   | 1 -
>  10 files changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index 308d442..29d2c74 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -115,6 +115,10 @@ EXPORT_SYMBOL(drm_panel_attach);
>   * Detaches a panel from the connector it is attached to. If a panel is not
>   * attached to any connector this is effectively a no-op.
>   *
> + * NOTE: This function should not be called by the panel device
> + *   itself. It is only for the drm device that called the
> + *   drm_panel_attach().

Does this result in pretty output when building the docs with

$ make htmldocs

Also might be good to add something like

 * When unloading, the driver should detach from the panel by calling
 * drm_panel_detach().

to the kerneldoc of drm_panel_attach.

Either way:

Reviewed-by: Daniel Vetter 

> + *
>   * Return: 0 on success or a negative error code on failure.
>   */
>  int drm_panel_detach(struct drm_panel *panel)
> diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
> b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> index 57df39b..bb53e08 100644
> --- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> +++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> @@ -292,7 +292,6 @@ static int innolux_panel_remove(struct mipi_dsi_device 
> *dsi)
>   DRM_DEV_ERROR(>dev, "failed to detach from DSI host: %d\n",
> err);
>  
> - drm_panel_detach(>base);
>   innolux_panel_del(innolux);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
> b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
> index 0a94ab7..99caa78 100644
> --- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
> +++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
> @@ -500,7 +500,6 @@ static int jdi_panel_remove(struct mipi_dsi_device *dsi)
>   dev_err(>dev, "failed to detach from DSI host: %d\n",
>   ret);
>  
> - drm_panel_detach(>base);
>   jdi_panel_del(jdi);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
> b/drivers/gpu/drm/panel/panel-lvds.c
> index 5185819..8a16878 100644
> --- a/drivers/gpu/drm/panel/panel-lvds.c
> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> @@ -282,7 +282,6 @@ static int panel_lvds_remove(struct platform_device *pdev)
>  {
>   struct panel_lvds *lvds = dev_get_drvdata(>dev);
>  
> - drm_panel_detach(>panel);
>   drm_panel_remove(>panel);
>  
>   panel_lvds_disable(>panel);
> diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c 
> b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> index 74a8061..cb4dfb9 100644
> --- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> +++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> @@ -299,7 +299,6 @@ static int wuxga_nt_panel_remove(struct mipi_dsi_device 
> *dsi)
>   if (ret < 0)
>   dev_err(>dev, "failed to detach from DSI host: %d\n", ret);
>  
> - drm_panel_detach(_nt->base);
>   wuxga_nt_panel_del(wuxga_nt);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c 
> b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
> index 71c09ed..75f9253 100644
> --- a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
> +++ b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
> @@ -292,7 +292,6 @@ static int seiko_panel_remove(struct platform_device 
> *pdev)
>  {
>   struct seiko_panel *panel = dev_get_drvdata(>dev);
>  
> - drm_panel_detach(>base);
>   drm_panel_remove(>base);
>  
>   

Re: [Intel-gfx] [PATCH] drm/edid: Reset more of the display info

[Daniel Vetter]

On Tue, Apr 24, 2018 at 05:26:30PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 24, 2018 at 04:18:37PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 24, 2018 at 04:02:50PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > We're currently failing to reset everything in display_info.hdmi
> > > which will potentially cause us to use stale information when
> > > swapping monitors. Eg. if the user replaces a HDMI 2.0 monitor
> > > with a HDMI 1.x monitor we will continue to think that the monitor
> > > supports scrambling. That will lead to a black screen since the
> > > HDMI 1.x monitor won't understand the scrambled signal.
> > > 
> > > Fix the problem by clearing display_info.hdmi fully. And while at
> > > eliminate some duplicated code by calling drm_reset_display_info()
> > > in drm_add_display_info().
> > > 
> > > Cc: Antony Chen 
> > > Cc: Shashank Sharma 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105655
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/drm_edid.c | 11 +++
> > >  1 file changed, 3 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 134069f36482..39f1db4acda4 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -4451,6 +4451,7 @@ drm_reset_display_info(struct drm_connector 
> > > *connector)
> > >   info->max_tmds_clock = 0;
> > >   info->dvi_dual = false;
> > >   info->has_hdmi_infoframe = false;
> > > + memset(>hdmi, 0, sizeof(info->hdmi));
> > >  
> > >   info->non_desktop = 0;
> > >  }
> > > @@ -4462,17 +4463,11 @@ u32 drm_add_display_info(struct drm_connector 
> > > *connector, const struct edid *edi
> > >  
> > >   u32 quirks = edid_get_quirks(edid);
> > >  
> > > + drm_reset_display_info(connector);
> > > +
> > 
> > Strictly speaking this is a separate bugfix, for the case where you
> > immediately go from one output to a different one. Keith already fixed the
> > case where at least somewhere in between you go to the disconnected state
> > in:
> > 
> > commit 170178fe99dd212bf25e70c89bc4b6e195564ffc
> > Author: Keith Packard 
> > Date:   Wed Dec 13 00:44:26 2017 -0800
> > 
> > drm: Update edid-derived drm_display_info fields at edid property set 
> > [v2]
> > 
> > With the above explained in the commit message:
> 
> The drm_reset_display_info() call is just the "deduplicate the code"
> part. The memset() is the bugfix, and applies in all cases.

Hm ... I guess my brain wasn't fully working.

Reviewed-by: Daniel Vetter 

as-is.
-Daniel

> 
> > 
> > Reviewed-by: Daniel Vetter 
> > 
> > >   info->width_mm = edid->width_cm * 10;
> > >   info->height_mm = edid->height_cm * 10;
> > >  
> > > - /* driver figures it out in this case */
> > > - info->bpc = 0;
> > > - info->color_formats = 0;
> > > - info->cea_rev = 0;
> > > - info->max_tmds_clock = 0;
> > > - info->dvi_dual = false;
> > > - info->has_hdmi_infoframe = false;
> > > -
> > >   info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
> > >  
> > >   DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
> > > -- 
> > > 2.16.1
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> -- 
> Ville Syrjälä
> Intel

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

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Tue, Apr 24, 2018 at 8:48 PM, Christoph Hellwig  wrote:
> On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote:
>> > At the very lowest level they will need to be handled differently for
>> > many architectures, the questions is at what point we'll do the
>> > branching out.
>>
>> Having at least struct page also in that list with (dma_addr_t, lenght)
>> pairs has a bunch of benefits for drivers in unifying buffer handling
>> code. You just pass that one single list around, use the dma_addr_t side
>> for gpu access (generally bashing it into gpu ptes). And the struct page
>> (if present) for cpu access, using kmap or vm_insert_*. We generally
>> ignore virt, if we do need a full mapping then we construct a vmap for
>> that buffer of our own.
>
> Well, for mapping a resource (which gets back to the start of the
> discussion) you will need an explicit virt pointer.  You also need
> an explicit virt pointer and not just page_address/kmap for users of
> dma_get_sgtable, because for many architectures you will need to flush
> the virtual address used to access the data, which might be a
> vmap/ioremap style mapping retourned from dma_alloc_address, and not
> the directly mapped kernel address.

Out of curiosity, how much virtual flushing stuff is there still out
there? At least in drm we've pretty much ignore this, and seem to be
getting away without a huge uproar (at least from driver developers
and users, core folks are less amused about that).

And at least for gpus that seems to have been the case since forever,
or at least since AGP was a thing 20 years ago: AGP isn't coherent, so
needs explicit cache flushing, and we have our own implementations of
that in drivers/char/agp. Luckily AGP died 10 years ago, so no one yet
proposed to port it all over to the iommu framework and hide it behind
the dma api (which really would be the "clean" way to do this, AGP is
simply an IOMMU + special socket dedicated for the add-on gpu).

> Here is another idea at the low-level dma API level:
>
>  - dma_get_sgtable goes away.  The replacement is a new
>dma_alloc_remap helper that takes the virtual address returned
>from dma_alloc_attrs/coherent and creates a dma_addr_t for the
>given new device.  If the original allocation was a coherent
>one no cache flushing is required either (because the arch
>made sure it is coherent), if the original allocation used
>DMA_ATTR_NON_CONSISTENT the new allocation will need
>dma_cache_sync calls as well.

Yeah I think that should work. dma_get_sgtable is a pretty nasty
layering violation.

>  - you never even try to share a mapping retourned from
>dma_map_resource - instead each device using it creates a new
>mapping, which makes sense as no virtual addresses are involved
>at all.

Yeah the dma-buf exporter always knows what kind of backing storage it
is dealing with, and for which struct device it should set up a new
view. Hence can make sure that it calls the right functions to
establish a new mapping, whether that's dma_map_sg, dma_map_resource
or the new dma_alloc_remap (instead of the dma_get_sgtable layering
mixup). The importer doesn't know.

>> So maybe a list of (struct page *, dma_addr_t, num_pages) would suit best,
>> with struct page * being optional (if it's a resource, or something else
>> that the kernel core mm isn't aware of). But that only has benefits if we
>> really roll it out everywhere, in all the subsystems and drivers, since if
>> we don't we've made the struct pages ** <-> sgt conversion fun only worse
>> by adding a 3 representation of gpu buffer object backing storage.
>
> I think the most important thing about such a buffer object is that
> it can distinguish the underlying mapping types.  While
> dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
> dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
> back a dma_addr_t they are in now way interchangable.  And trying to
> stuff them all into a structure like struct scatterlist that has
> no indication what kind of mapping you are dealing with is just
> asking for trouble.

Well the idea was to have 1 interface to allow all drivers to share
buffers with anything else, no matter how exactly they're allocated.
dma-buf has all the functions for flushing, so you can have coherent
mappings, non-coherent mappings and pretty much anything else. Or well
could, because in practice people hack up layering violations until it
works for the 2-3 drivers they care about. On top of that there's the
small issue that x86 insists that dma is coherent (and that's true for
most devices, including v4l drivers you might want to share stuff
with), and gpus really, really really do want to make almost
everything incoherent.

The end result is pretty epic :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

[bugzilla-daemon]

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

--- Comment #5 from Harry Wentland  ---
Created attachment 139070
  --> https://bugs.freedesktop.org/attachment.cgi?id=139070=edit
[PATCH 2/2] drm/amd/display: Check dc_sink every time in MST hotplug

Can you try patches 1 and 2?

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

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

[bugzilla-daemon]

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

--- Comment #4 from Harry Wentland  ---
Created attachment 139069
  --> https://bugs.freedesktop.org/attachment.cgi?id=139069=edit
[PATCH 1/2] drm/amd/display: Update MST edid property every time

-- 
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 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

Kevin McCormack (harlemsquir...@gmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #26 from Kevin McCormack (harlemsquir...@gmail.com) ---
It looks like this commit has made it into 4.16.4

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.16.4

Thanks all!

-- 
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 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

--- Comment #25 from Thomas Crider (tcride...@gmail.com) ---
I can also confirm the flicker is gone with 4.17rc2

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #46 from MirceaKitsune  ---
I found out what's causing the apitrace crash: It no longer happens when I use
fresh settings, therefore something in my config was breaking it. Upon further
inspection it seems to be one of the visual effects. I'll try again with
different settings, and see if I can find a config that still triggers the GPU
lockup without also making apitrace crash to the desktop.

I also looked up where the kernel output should be located on openSUSE. I'm
told that it's /var/log/messages which indeed exists on my system. Next time I
experience the freeze, I will post that file here as instructed.

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

Re: [PATCH] drm/tinydrm/mi0283qt: Always set rotation value

[Noralf Trønnes]

Den 24.04.2018 21.16, skrev Daniel Vetter:

On Tue, Apr 24, 2018 at 6:52 PM, Noralf Trønnes  wrote:

Den 23.04.2018 18.16, skrev Tom Callaway:

The PiTFT (ili9340) has a hardware reset circuit that resets only
on power-on and not on each reboot through a gpio like the
rpi-display does. As a result, we need to always apply the
rotation value regardless of the display "on/off" state.
Moved the rotation setting code below out_enable:.

Signed-off-by: Tom Callaway 
---
   drivers/gpu/drm/tinydrm/mi0283qt.c | 41
+-
   1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 4e6d2ee94e55..2bb9e3ce4823 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -84,24 +84,6 @@ static void mi0283qt_enable(struct
drm_simple_display_pipe *pipe,
 /* Memory Access Control */
 mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT,
MIPI_DCS_PIXEL_FMT_16BIT);
   - switch (mipi->rotation) {
-   default:
-   addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY |
-   ILI9341_MADCTL_MX;
-   break;
-   case 90:
-   addr_mode = ILI9341_MADCTL_MY;
-   break;
-   case 180:
-   addr_mode = ILI9341_MADCTL_MV;
-   break;
-   case 270:
-   addr_mode = ILI9341_MADCTL_MX;
-   break;
-   }
-   addr_mode |= ILI9341_MADCTL_BGR;
-   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
-
 /* Frame Rate */
 mipi_dbi_command(mipi, ILI9341_FRMCTR1, 0x00, 0x1b);
   @@ -127,6 +109,29 @@ static void mi0283qt_enable(struct
drm_simple_display_pipe *pipe,
 msleep(100);
 out_enable:
+   /* The PiTFT (ili9340) has a hardware reset circuit that
+* resets only on power-on and not on each reboot through
+* a gpio like the rpi-display does.
+* As a result, we need to always apply the rotation value
+* regardless of the display "on/off" state.
+*/
+   switch (mipi->rotation) {
+   default:
+   addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY |
+   ILI9341_MADCTL_MX;
+   break;
+   case 90:
+   addr_mode = ILI9341_MADCTL_MY;
+   break;
+   case 180:
+   addr_mode = ILI9341_MADCTL_MV;
+   break;
+   case 270:
+   addr_mode = ILI9341_MADCTL_MX;
+   break;
+   }
+   addr_mode |= ILI9341_MADCTL_BGR;
+   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
 mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
   }



Thanks for fixing this.

Reviewed-by: Noralf Trønnes 

Tom doesn't have commit rights, so would be on you to get this merged.
-Daniel


Sure, that was my intention, should have mentioned it.

Noralf.

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

[PATCH] Intel: Add a Kaby Lake PCI ID

[matthew . s . atwood]

From: Matt Atwood 

Based on kernel commit '672e314b21dc ("drm/i915/kbl: Add KBL GT2 sku")'

v2: name change M -> ULX, add enumeration in KBL ULX

Signed-off-by: Matt Atwood 
---
 intel/intel_chipset.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 01d250e..f479bc4 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -200,7 +200,8 @@
 #define PCI_CHIP_KABYLAKE_ULT_GT2F 0x5921
 #define PCI_CHIP_KABYLAKE_ULX_GT1_50x5915
 #define PCI_CHIP_KABYLAKE_ULX_GT1  0x590E
-#define PCI_CHIP_KABYLAKE_ULX_GT2  0x591E
+#define PCI_CHIP_KABYLAKE_ULX_GT2_00x591E
+#define PCI_CHIP_KABYLAKE_ULX_GT2_10x591C
 #define PCI_CHIP_KABYLAKE_DT_GT2   0x5912
 #define PCI_CHIP_KABYLAKE_M_GT20x5917
 #define PCI_CHIP_KABYLAKE_DT_GT1   0x5902
-- 
2.7.4

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

Re: [PATCH] drm/tinydrm/mi0283qt: Always set rotation value

[Daniel Vetter]

On Tue, Apr 24, 2018 at 6:52 PM, Noralf Trønnes  wrote:
>
> Den 23.04.2018 18.16, skrev Tom Callaway:
>>
>> The PiTFT (ili9340) has a hardware reset circuit that resets only
>> on power-on and not on each reboot through a gpio like the
>> rpi-display does. As a result, we need to always apply the
>> rotation value regardless of the display "on/off" state.
>> Moved the rotation setting code below out_enable:.
>>
>> Signed-off-by: Tom Callaway 
>> ---
>>   drivers/gpu/drm/tinydrm/mi0283qt.c | 41
>> +-
>>   1 file changed, 23 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
>> b/drivers/gpu/drm/tinydrm/mi0283qt.c
>> index 4e6d2ee94e55..2bb9e3ce4823 100644
>> --- a/drivers/gpu/drm/tinydrm/mi0283qt.c
>> +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
>> @@ -84,24 +84,6 @@ static void mi0283qt_enable(struct
>> drm_simple_display_pipe *pipe,
>> /* Memory Access Control */
>> mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT,
>> MIPI_DCS_PIXEL_FMT_16BIT);
>>   - switch (mipi->rotation) {
>> -   default:
>> -   addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY |
>> -   ILI9341_MADCTL_MX;
>> -   break;
>> -   case 90:
>> -   addr_mode = ILI9341_MADCTL_MY;
>> -   break;
>> -   case 180:
>> -   addr_mode = ILI9341_MADCTL_MV;
>> -   break;
>> -   case 270:
>> -   addr_mode = ILI9341_MADCTL_MX;
>> -   break;
>> -   }
>> -   addr_mode |= ILI9341_MADCTL_BGR;
>> -   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
>> -
>> /* Frame Rate */
>> mipi_dbi_command(mipi, ILI9341_FRMCTR1, 0x00, 0x1b);
>>   @@ -127,6 +109,29 @@ static void mi0283qt_enable(struct
>> drm_simple_display_pipe *pipe,
>> msleep(100);
>> out_enable:
>> +   /* The PiTFT (ili9340) has a hardware reset circuit that
>> +* resets only on power-on and not on each reboot through
>> +* a gpio like the rpi-display does.
>> +* As a result, we need to always apply the rotation value
>> +* regardless of the display "on/off" state.
>> +*/
>> +   switch (mipi->rotation) {
>> +   default:
>> +   addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY |
>> +   ILI9341_MADCTL_MX;
>> +   break;
>> +   case 90:
>> +   addr_mode = ILI9341_MADCTL_MY;
>> +   break;
>> +   case 180:
>> +   addr_mode = ILI9341_MADCTL_MV;
>> +   break;
>> +   case 270:
>> +   addr_mode = ILI9341_MADCTL_MX;
>> +   break;
>> +   }
>> +   addr_mode |= ILI9341_MADCTL_BGR;
>> +   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
>> mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
>>   }
>>
>
>
> Thanks for fixing this.
>
> Reviewed-by: Noralf Trønnes 

Tom doesn't have commit rights, so would be on you to get this merged.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

[Daniel Vetter]

On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov  wrote:
> On 13 April 2018 at 11:00, Daniel Vetter  wrote:
>> This tries to align with the X.org communities's long-standing
>> tradition of trying to be an inclusive community and handing out
>> commit rights fairly freely.
>>
>> We also tend to not revoke commit rights for people no longer
>> regularly active in a given project, as long as they're still part of
>> the larger community.
>>
>> Finally make sure that commit rights, like anything happening on fd.o
>> infrastructre, is subject to the fd.o's Code of Conduct.
>>
>> v2: Point at MAINTAINERS for contact info (Daniel S.)
>>
>> v3:
>> - Make it clear that commit rights are voluntary and that committers
>>   need to acknowledge positively when they're nominated by someone
>>   else (Keith).
>> - Encourage committers to drop their commit rights when they're no
>>   longer active, and make it clear they'll get readded (Keith).
>> - Add a line that maintainers and committers should actively nominate
>>   new committers (me).
>>
>> v4: Typo (Petri).
>>
>> v5: Typo (Sean).
>>
>> v6: Wording clarifications and spelling (Jani).
>>
>> v7: Require an explicit commitment to the documented merge criteria
>> and rules, instead of just the implied one through the Code of Conduct
>> threat (Jani).
>>
>> Acked-by: Alex Deucher 
>> Acked-by: Arkadiusz Hiler 
>> Acked-by: Daniel Stone 
>> Acked-by: Eric Anholt 
>> Acked-by: Gustavo Padovan 
>> Acked-by: Petri Latvala 
>> Cc: Alex Deucher 
>> Cc: Arkadiusz Hiler 
>> Cc: Ben Widawsky 
>> Cc: Daniel Stone 
>> Cc: Dave Airlie 
>> Cc: Eric Anholt 
>> Cc: Gustavo Padovan 
>> Cc: Jani Nikula 
>> Cc: Joonas Lahtinen 
>> Cc: Keith Packard 
>> Cc: Kenneth Graunke 
>> Cc: Kristian H. Kristensen 
>> Cc: Maarten Lankhorst 
>> Cc: Petri Latvala 
>> Cc: Rodrigo Vivi 
>> Cc: Sean Paul 
>> Reviewed-by: Keith Packard 
>> Signed-off-by: Daniel Vetter 
>> ---
>> If you wonder about the wide distribution list for an igt patch: I'd
>> like to start a discussions about x.org community norms around commit
>> rights at large, at least for all the shared repos. I plan to propose
>> the same text for drm-misc and libdrm too, and hopefully others like
>> mesa/xserver/wayland would follow.
>>
> I think the idea is pretty good, simply highlighting some bits.
>
> What you've outlined in this patch has been in practise for many years:
>  a) undocumented, applicable to most xorg projects [1]
>  b) documented, mesa

Hm, I chatted with a few mesa devs about this, and I wasn't aware
there's explicit documentation for mesa. Where is it? I'd very much
want to align as much as we can.

> IMHO having this explicitly documented and others
> (wayland/weston/wayland-protocols and xserver repos) following suite
> is a big plus.

Yeah, that's the idea. Hence plenty of Cc: for this igt patch.
-Daniel

>
> HTH
> Emil
>
> [1] As in all of https://cgit.freedesktop.org/xorg but xserver



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdkfd: fix typing in (*hqd_destroy)

[Felix Kuehling]

On 2018-04-24 09:14 AM, Luc Van Oostenryck wrote:
> The method (*hqd_destroy) is defined as using an 'uint32_t'
> as 3rd argument but the the actual implementation of this
> method and all its calls actually uses an 'enum kfd_preempt_type'
> for this argument.
>
> Fix this by using 'enum kfd_preempt_type' for (*hqd_destroy) too.
>
> Signed-off-by: Luc Van Oostenryck 

Interesting. I'm surprised I never saw a compiler warning about a
function pointer type mismatch. I guess C isn't picky about integer
types as long as the size is the same.

Anyway, this patch is Reviewed-by: Felix Kuehling 

> ---
>  drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h 
> b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
> index 237289a72..2890e8581 100644
> --- a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
> +++ b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
> @@ -298,7 +298,7 @@ struct kfd2kgd_calls {
>   bool (*hqd_is_occupied)(struct kgd_dev *kgd, uint64_t queue_address,
>   uint32_t pipe_id, uint32_t queue_id);
>  
> - int (*hqd_destroy)(struct kgd_dev *kgd, void *mqd, uint32_t reset_type,
> + int (*hqd_destroy)(struct kgd_dev *kgd, void *mqd, enum 
> kfd_preempt_type reset_type,
>   unsigned int timeout, uint32_t pipe_id,
>   uint32_t queue_id);
>  

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

Re: [Patch v2 1/6] drm/omap: Add ability to filter out modes which can't be supported

[Laurent Pinchart]

Hi Tomi,

On Thursday, 5 April 2018 13:21:30 EEST Tomi Valkeinen wrote:
> On 04/04/18 17:23, Laurent Pinchart wrote:
>  +WARN(out_width > dispc.feat->ovl_width_max,
>  + "Requested OVL width (%d) is larger than can be supported
>  (%d).\n",
>  + out_width, dispc.feat->ovl_width_max);
> >>> 
> >>> Why don't you return an error here? I don't see a need for WARN here.
> >> 
> >> So here you mean replace the WARN with something like this:
> >>if (out_width > dispc.feat->ovl_width_max) {
> >>DSSERR("Requested OVL width (%d) is larger than can be supported
> >>(%d).\n",
> >> out_width, dispc.feat->ovl_width_max);
> >> return -EINVAL;
> >>}
> > 
> > Can this happen ? If we reject invalid settings in omapdrm we should never
> > get them here.
> 
> That's true. And we should check them in the plane atomic check (but do
> we?).

We don't, that should be added.

> In that case I don't mind a warn there, but you should still return an
> error if it happens, instead of continuing with bad config.

But this should really not happen if we add a check to the CRTC 
atomic_check() handler. Do you distrust the DRM core that much ? :-)

>  +/* Check if the advertised width exceed what the pipeline can 
>  do */
>  +if (!r) {
>  +struct omap_drm_private *priv = dev->dev_private;
>  +u16 width, height;
>  +
>  +priv->dispc_ops->ovl_get_max_size(, );
>  +if (mode->hdisplay > width)
>  +r = -EINVAL;
> >>> 
> >>> You should check the height also.
> >> 
> >> Yeah, I'll fix that.
> > 
> > Unless I'm mistaken the restriction doesn't come from the output side of
> > the display controller but from the overlays (planes), right ? Shouldn't
> > it then be implemented in the drm_plane_helper_funcs.atomic_check
> > operation ?
> 
> Yes, but I don't so. If our planes can support up to, say, 1000. Then we
> plug in a monitor with native width of 1100, which omapdrm would accept
> happily and try to use it by default. But we can't show fbdev or any
> normal setup there, because the planes won't support it. How would we
> manage that?
> 
> While not strictly correct, I think it's fine to reject videomodes which
> can't be shown with a normal full-screen plane.

It could be argued that such modes would still be useful even if planes can't 
be shown full-screen, or that two planes could be used side by side to achieve 
a larger full-screen display than what would be possible with a single plane. 
I'll leave it up to you to decide whether we should support such use cases.

-- 
Regards,

Laurent Pinchart



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

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver

[bugzilla-daemon]

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

Harry Wentland  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #39 from Harry Wentland  ---
Marking resolved as fix has been in mainline for a while now. If this is still
an issue feel free to reopen.

-- 
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 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

--- Comment #24 from Harry Wentland (harry.wentl...@amd.com) ---
Kevin, can you mark this as resolved?

-- 
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 102820] [bisected][DC] commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 prevents X11 from starting

[bugzilla-daemon]

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

Harry Wentland  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Harry Wentland  ---
Marking resolved as fix has been in mainline for a while now. If this is still
an issue feel free to reopen.

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

Re: [PATCH] drm/amdkfd: Integer overflows in ioctl

[Felix Kuehling]

Reviewed-by: Felix Kuehling 

We could probably add a sanity check for n_devices to avoid user mode
causing excessive memory allocations in the kernel. There is no good
reason for this to be bigger than the number of GPUs in the system. The
maximum number of GPUs supported due to device minor limit in DRM is 128.

Regards,
  Felix


On 2018-04-24 09:35 AM, Dan Carpenter wrote:
> args->n_devices is a u32 that comes from the user.  The multiplication
> could overflow on 32 bit systems possibly leading to privilege
> escalation.
>
> Fixes: 5ec7e02854b3 ("drm/amdkfd: Add ioctls for GPUVM memory management")
> Signed-off-by: Dan Carpenter dan.carpen...@oracle.com>
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> index cd679cf1fd30..ce36e556da38 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> @@ -1295,8 +1295,8 @@ static int kfd_ioctl_map_memory_to_gpu(struct file 
> *filep,
>   return -EINVAL;
>   }
>  
> - devices_arr = kmalloc(args->n_devices * sizeof(*devices_arr),
> -   GFP_KERNEL);
> + devices_arr = kmalloc_array(args->n_devices, sizeof(*devices_arr),
> + GFP_KERNEL);
>   if (!devices_arr)
>   return -ENOMEM;
>  
> @@ -1404,8 +1404,8 @@ static int kfd_ioctl_unmap_memory_from_gpu(struct file 
> *filep,
>   return -EINVAL;
>   }
>  
> - devices_arr = kmalloc(args->n_devices * sizeof(*devices_arr),
> -   GFP_KERNEL);
> + devices_arr = kmalloc_array(args->n_devices, sizeof(*devices_arr),
> + GFP_KERNEL);
>   if (!devices_arr)
>   return -ENOMEM;
>  

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

[Bug 103987] [DC] drm:drm_atomic_helper_wait_for_dependencies - flip_done timed out

[bugzilla-daemon]

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

Harry Wentland  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Harry Wentland  ---
Marking resolved as fix should be in mainline for a while now. If this is still
an issue feel free to reopen.

-- 
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 104319] AMDGPU/DC: Internal display corrupted when connecting (mirroring/extending) an external monitor on HDMI

[bugzilla-daemon]

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

Harry Wentland  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Harry Wentland  ---
Marking resolved as reported to work fine on amd-staging-drm-next. If this is
still an issue feel free to reopen.

-- 
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 105880] [dc] No support for LVDS or VGA connectors (Cannot find any crtc or sizes)

[bugzilla-daemon]

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

--- Comment #18 from David Henningsson  ---
(In reply to Michel Dänzer from comment #10)
> (In reply to David Henningsson from comment #8)
> > The regression is between 4.15rc2 and 4.15rc3
> 
> Any chance you can bisect between these two?

So I did the bisection (which took some time) and it turned out empty. What
tricked me was the fact that Ubuntu changed their kernel configs between
4.15rc2 and 4.15rc3, mainly by enabling CONFIG_DRM_AMD_DC_PRE_VEGA and
CONFIG_DRM_AMD_DC_DCN1_0. This was the cause of regression for me rather than
patches between rc2 and rc3. 

Anyhow, it's probably a separate bug from this one, so sorry for the confusion.

-- 
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 104281] black / corrupted screen when resuming from S3 [AMDGPU]

[bugzilla-daemon]

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

Harry Wentland  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Harry Wentland  ---
Marking resolved as reported to work fine on drm-next-4.17-wip. If this is
still an issue feel free to reopen.

-- 
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 105284] Every boot I get an error in dmesg "WARNING: CPU: 2 PID: 1380 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu]"

[bugzilla-daemon]

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

Harry Wentland  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Harry Wentland  ---
Marking resolved as no longer an issue on recent mainline.

-- 
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: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote:
> > At the very lowest level they will need to be handled differently for
> > many architectures, the questions is at what point we'll do the
> > branching out.
> 
> Having at least struct page also in that list with (dma_addr_t, lenght)
> pairs has a bunch of benefits for drivers in unifying buffer handling
> code. You just pass that one single list around, use the dma_addr_t side
> for gpu access (generally bashing it into gpu ptes). And the struct page
> (if present) for cpu access, using kmap or vm_insert_*. We generally
> ignore virt, if we do need a full mapping then we construct a vmap for
> that buffer of our own.

Well, for mapping a resource (which gets back to the start of the
discussion) you will need an explicit virt pointer.  You also need
an explicit virt pointer and not just page_address/kmap for users of
dma_get_sgtable, because for many architectures you will need to flush
the virtual address used to access the data, which might be a
vmap/ioremap style mapping retourned from dma_alloc_address, and not
the directly mapped kernel address.

Here is another idea at the low-level dma API level:

 - dma_get_sgtable goes away.  The replacement is a new
   dma_alloc_remap helper that takes the virtual address returned
   from dma_alloc_attrs/coherent and creates a dma_addr_t for the
   given new device.  If the original allocation was a coherent
   one no cache flushing is required either (because the arch
   made sure it is coherent), if the original allocation used
   DMA_ATTR_NON_CONSISTENT the new allocation will need
   dma_cache_sync calls as well.
 - you never even try to share a mapping retourned from
   dma_map_resource - instead each device using it creates a new
   mapping, which makes sense as no virtual addresses are involved
   at all.

> So maybe a list of (struct page *, dma_addr_t, num_pages) would suit best,
> with struct page * being optional (if it's a resource, or something else
> that the kernel core mm isn't aware of). But that only has benefits if we
> really roll it out everywhere, in all the subsystems and drivers, since if
> we don't we've made the struct pages ** <-> sgt conversion fun only worse
> by adding a 3 representation of gpu buffer object backing storage.

I think the most important thing about such a buffer object is that
it can distinguish the underlying mapping types.  While
dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
back a dma_addr_t they are in now way interchangable.  And trying to
stuff them all into a structure like struct scatterlist that has
no indication what kind of mapping you are dealing with is just
asking for trouble.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106006] Kernel 4.16.0+ switch amdgpu.dc=1 causes screen brightness set to 1 to be dimmed by default

[bugzilla-daemon]

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

--- Comment #13 from Harry Wentland  ---
Not sure exactly how that kernel is assembled but it contains the problematic
code in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c. You should be
able to simply delete the block for if (__is_lut_linear(...)) in
amdgpu_dm_set_regamma_lut to fix this, if the patch doesn't straight-up apply.

-- 
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: [RFC][PATCH 2/2] drm_hwcomposer: Fall back to client compositon if the gl precompostior fails

[John Stultz]

On Tue, Apr 24, 2018 at 3:34 AM, Stefan Schake  wrote:
> On Tue, Apr 24, 2018 at 10:09 AM, Alexandru-Cosmin Gheorghe
>  wrote:
>> On Mon, Apr 23, 2018 at 05:06:44PM -0700, John Stultz wrote:
>>> @@ -695,6 +704,15 @@ HWC2::Error 
>>> DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types,
>>>  layer.set_validated_type(HWC2::Composition::Client);
>>>  ++*num_types;
>>>  break;
>>> +  case HWC2::Composition::Device:
>>> +if (!compositor_.uses_GL() && !avail_planes) {
>>
>> Something is not entirely correct here, you can't assume just because
>> you have planes available they can be used.
>> E.g Layer has rotation, but the plane doesn't support it.
>> This part is handled by the planning part in presentDisplay which
>> falls back on GPU.

Ah. Thanks for the correction here!

This is part of the disconnect I have been having with the
drm_hwcomposer logic. The plan/validate step doesn't really do either,
instead it defers all the checking/planning to the set/present step.
But unfortunately it seems if we want to use the surfaceflinger gl
composer, we need to mark the layers as client rendered in the
validate function.

>> I think the easiest and safe way is to just fallback to
>> Composition::Client whenever the GLCompositor failed to initialize.
>>
>
> I agree, this would only work out for the single plane case where you end
> up using client composition for everything.

True, but maybe as a first step we simply fall back on the
glcompositor, just so we have something displaying in that case (right
now nothing gets displayed).

> In the spirit of DRM what we would probably want is to atomic test a
> composition, and if that fails we can still fallback to client or GL
> compositor depending on its availability. And then in a far far away
> future we might even do a few iterations simplifying our composition until
> it atomic tests correctly so we can still offload some "simple" parts
> like the cursor.

This sounds reasonable. I suspect it will take some heavier rework of
the drm_hwcomposer to move such logic to the validate step.

Marissa/Sean: Any objections here? Doing more planning in the validate
step sounds like it aligns closer to the HWC2 interface goals, but I
don't want to have to relearn-the-hard-way any lessons that resulted
in the current mode of accept it all and sort it in present.

In the meantime I'll drop the flawed plane/layer allocation from this
patch and resend.

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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #45 from MirceaKitsune  ---
(In reply to iive from comment #44)

I'm doing my best to debug this as well as possible, but there are a lot of
points and it's hard to pay attention to everything. I thought the crashing to
the desktop in the trace I posted might still hold some information, especially
as it seemed to complain about some OpenGL related issues.

I'll try the GLX version as well and let you know if that works. If not it
means I can't test using apitrace, because Xonotic crashes for some reason I
can't explain when I run it on that.

And I don't yet know where to extract the kernel logs from on my distribution.
I don't have a /var/log/syslog so it must be somewhere else. I'll try looking
that up as well and will post them once I find them.

-- 
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 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

Hi Maxime and all,
I resend the e-mail since it was refused by some address(my phone 
composed it in HTML). Sorry.


Il 24/04/2018 10:41, Maxime Ripard ha scritto:

Hi,

On Mon, Apr 23, 2018 at 04:37:33PM +0200, Giulio Benetti wrote:

Il 22/03/2018 19:05, Maxime Ripard ha scritto:

On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:

The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 7" 24-bits Tft 800x480 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins

HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.


So this is essentially the same board than in patch 6, but with a
different screen?

You should have a single DT then, and handle the two different panels
using DT overlays.


Ok for having different DT overlays.
But do I have to submit them as patches? Or keep them in my company's repo?
I ask you this because this involves sending also patches for displays
and other little modifications to mainline ex:
- rgb888 pins
- 2 simple-panels
- 1 uart iomux pins
etc.

If I don't submit those overlays, the other patches wouldn't make sense
alone as I've seen, just like rgb888 pins.


We don't have a repo for overlays yet


Ok I can provide them on my company Repo.

But, sorry if insist(please don't kill me! :) ), I would try to explain 
better how it's made LiNova, because I think I didn't provide enough 
information about it:
LiNova1 is not a board with various headers to connect other peripherals 
such display, pcap etc.
It's an HMI that I would consider the same as a Tablet, because it has a 
plastic enclosure also.


So I would like to understand how to manage it in the best way.
Try to consider LiNova1 as a Tablet series, with following list:
LiNova1 4.3" ctp
LiNova1 7" ctp
LiNova1 10.1" ctp
LiNova1 4.3" rtp
LiNova1 7" rtp
LiNova1 10.1" rtp

Every of those has a slightly different BOM, so they are 6 different 
boards with a common base(uP, ram). And same pcb.


So I don't know if submit only the common base and provide separately on 
our github DT-overlays, or provide as many dts patches as the HMI number 
with a base dtsi.


Basically Micronova provides entire system without the capability to 
hack hardware adding shields of various type.


There are also other 2 LiNova:
LiNova2 and LiNova3

So I understand that this could lead to 18 different dts files and 3 
dtsi files.


But with Tablet it should be the same way.
For sure people would be more interested on famous tablets instead of 
our HMI.


In the case I need to use dt-overlays, you mean .dto files with 
fragments inside loaded by u-boot or runtime, right?


Sorry if I bother you again but I wanted to understand better.




+_otg {
+   dr_mode = "otg";


You're saying that this is a USB-A connector? Then it's not OTG since
it doesn't have an ID pin, this is an host.


Right, with a special overlay I will activate Usb Device for RNDIS,
so modified as host


That doesn't really make much sense. The USB OTG is wired only using a
daughter board?


My fault, I've meant "peripheral" in one case and "host" in another case.
Usually "host".
Are there problem with this?
There is no daughter board.

Thank you very very much in advance for you patience :)

--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642





One last question:
now I have some patch already reviewed-by.
Do I have to re-submit entire patchset?


Yes

Maxime





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

Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

[Jyri Sarha]

On 24/04/18 20:06, Russell King - ARM Linux wrote:
> On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote:
>> On 24/04/18 13:14, Peter Rosin wrote:
>>> On 2018-04-24 10:08, Russell King - ARM Linux wrote:
 On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote:
> On 2018-04-23 18:08, Russell King - ARM Linux wrote:
>> On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote:
>>>  static int tda998x_remove(struct i2c_client *client)
>>>  {
>>> -   component_del(>dev, _ops);
>>> +   struct device *dev = >dev;
>>> +   struct tda998x_bridge *bridge = dev_get_drvdata(dev);
>>> +
>>> +   drm_bridge_remove(>bridge);
>>> +   component_del(dev, _ops);
>>> +
>>
>> I'd like to ask a rather fundamental question about DRM bridge support,
>> because I suspect that there's a major fsckup here.
>>
>> The above is the function that deals with the TDA998x device being
>> unbound from the driver.  With the component API, this results in the
>> DRM device correctly being torn down, because one of the hardware
>> devices has gone.
>>
>> With DRM bridge, the bridge is merely removed from the list of
>> bridges:
>>
>> void drm_bridge_remove(struct drm_bridge *bridge)
>> {
>> mutex_lock(_lock);
>> list_del_init(>list);
>> mutex_unlock(_lock);
>> }
>> EXPORT_SYMBOL(drm_bridge_remove);
>>
>> and the memory backing the "struct tda998x_bridge" (which contains
>> the struct drm_bridge) will be freed by the devm subsystem.
>>
>> However, there is no notification into the rest of the DRM subsystem
>> that the device has gone away.  Worse, the memory that is still in
>> use by DRM has now been freed, so further use of the DRM device
>> results in a use-after-free bug.
>>
>> This is really not good, and to me looks like a fundamental problem
>> with the DRM bridge code.  I see nothing in the DRM bridge code that
>> deals with the lifetime of a "DRM bridge" or indeed the lifetime of
>> the actual device itself.
>>
>> So, from what I can see, there seems to be a fundamental lifetime
>> issue with the design of the DRM bridge code.  This needs to be
>> fixed.
>
> Oh crap. A gigantic can of worms...

 Yes, it's especially annoying for me, having put the effort in to
 the component helper to cover all these cases.

> Would a patch (completely untested btw) along this line of thinking make
> any difference whatsoever?

 It looks interesting - from what I can see of the device links code,
 it would have the effect of unbinding the DRM device just before
 TDA998x is unbound, so that's an improvement.

 However, from what I can see, the link vanishes at that point (as
 DL_FLAG_AUTOREMOVE is set), and re-binding the TDA998x device results
 in nothing further happening - the link will be recreated, but there
 appears to be nothing that triggers the "consumer" to rebind at that
 point.  Maybe I've missed something?
>>>
>>> Right, auto-remove is a no-go. So, improving on the previous...
>>>
>>> (I think drm_panel might suffer from this issue too?)
>>
>> Yes it does and I took a shot at trying to fix it at the end of the
>> previous merge window, but gave up as I run out of time. I re-spun the
>> work now after reading this thread. I add you and Russell to cc.
> 
> Right, and these exact problems are what the component helper is
> there to sort out, in a subsystem independent way.
> 
> What is the problem with the component helper that people seem to
> be soo loathed to use it, instead preferring to come up with sub-
> standard and broken alternatives?
> 

Nothing but time. Embedding component helpers seamlessly into drm
framework does not sound like a couple of days job. Right now I simply
do not have time to take on a challenge like that. If someone does it I
am all for it.

However, I would not call device links substandard. They are in the
device core after all.

Best regards,
Jyri

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Intel: Add a Kaby Lake PCI ID

[Rodrigo Vivi]

On Tue, Apr 24, 2018 at 10:55:05AM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 

please add the message:

Based on kernel commit '672e314b21dc ("drm/i915/kbl: Add KBL GT2 sku")'

> 
> v2: name change M -> ULX, add enumeration in KBL ULX
> 
> Signed-off-by: Matt Atwood 
> ---
>  intel/intel_chipset.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 01d250e..f479bc4 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -200,7 +200,8 @@
>  #define PCI_CHIP_KABYLAKE_ULT_GT2F   0x5921
>  #define PCI_CHIP_KABYLAKE_ULX_GT1_5  0x5915
>  #define PCI_CHIP_KABYLAKE_ULX_GT10x590E
> -#define PCI_CHIP_KABYLAKE_ULX_GT20x591E
> +#define PCI_CHIP_KABYLAKE_ULX_GT2_0  0x591E
> +#define PCI_CHIP_KABYLAKE_ULX_GT2_1  0x591C
>  #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912
>  #define PCI_CHIP_KABYLAKE_M_GT2  0x5917
>  #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902

The define itself isn't enough... you still missed the enable part:

#define IS_KBL_GT2(devid)   ((devid) == PCI_CHIP_KABYLAKE_ULX_GT2_...

sorry for not being clear about the "enable" part on previous review.

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

[PATCH v3 5/5] drm/arm/malidp: Added the late system pm functions

[Ayan Kumar Halder]

malidp_pm_suspend_late checks if the runtime status is not suspended
and if so, invokes malidp_runtime_pm_suspend which disables the
display engine/core interrupts and the clocks. It sets the runtime status
as suspended.

The difference between suspend() and suspend_late() is as follows:-
1. suspend() makes the device quiescent. In our case, we invoke the DRM
helper which disables the CRTC. This would have invoked runtime pm
suspend but the system suspend process disables runtime pm.
2. suspend_late() It continues the suspend operations of the drm device 
which was started by suspend(). In our case, it performs the same functionality
as runtime_suspend().

The complimentary functions are resume() and resume_early(). In the case of
resume_early(), we invoke malidp_runtime_pm_resume() which enables the clocks
and the interrupts. It sets the runtime status as active. If the device was
in runtime suspend mode before system suspend was called, pm_runtime_work()
will put the device back in runtime suspended mode( after the complete system
has been resumed).

Signed-off-by: Ayan Kumar Halder 

---
Changes in v3:-
- Rebased on top of earlier v3 patches, 

Changes in v2:-
- Removed the change id and modified the commit message
---
 drivers/gpu/drm/arm/malidp_drv.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 82221ea..c53b46a 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -768,8 +768,25 @@ static int __maybe_unused malidp_pm_resume(struct device 
*dev)
return 0;
 }
 
+static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
+{
+   if (!pm_runtime_status_suspended(dev)) {
+   malidp_runtime_pm_suspend(dev);
+   pm_runtime_set_suspended(dev);
+   }
+   return 0;
+}
+
+static int __maybe_unused malidp_pm_resume_early(struct device *dev)
+{
+   malidp_runtime_pm_resume(dev);
+   pm_runtime_set_active(dev);
+   return 0;
+}
+
 static const struct dev_pm_ops malidp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \
+   SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, 
malidp_pm_resume_early) \
SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, malidp_runtime_pm_resume, 
NULL)
 };
 
-- 
2.7.4

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

[PATCH v3 4/5] drm/arm/malidp: Set the output_depth register in modeset

[Ayan Kumar Halder]

One needs to store the value of the OUTPUT_DEPTH that one has parsed from
device tree, so that it can be restored on system resume. This value is
set in the modeset function as this gets reset when the system suspends.

Signed-off-by: Ayan Kumar Halder 

---
Changes in v3:-
- Rebased the patch on top of the earlier v3 patches.

Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_drv.c | 1 +
 drivers/gpu/drm/arm/malidp_hw.c  | 4 
 drivers/gpu/drm/arm/malidp_hw.h  | 1 +
 3 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 983b854..82221ea 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -603,6 +603,7 @@ static int malidp_bind(struct device *dev)
for (i = 0; i < MAX_OUTPUT_CHANNELS; i++)
out_depth = (out_depth << 8) | (output_width[i] & 0xf);
malidp_hw_write(hwdev, out_depth, hwdev->hw->map.out_depth_base);
+   hwdev->output_color_depth = out_depth;
 
atomic_set(>config_valid, 0);
init_waitqueue_head(>wq);
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 3f53f7e8..52c7031 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -233,6 +233,8 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
 {
u32 val = 0;
 
+   malidp_hw_write(hwdev, hwdev->output_color_depth,
+   hwdev->hw->map.out_depth_base);
malidp_hw_clearbits(hwdev, MALIDP500_DC_CLEAR_MASK, 
MALIDP500_DC_CONTROL);
if (mode->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= MALIDP500_HSYNCPOL;
@@ -457,6 +459,8 @@ static void malidp550_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
 {
u32 val = MALIDP_DE_DEFAULT_PREFETCH_START;
 
+   malidp_hw_write(hwdev, hwdev->output_color_depth,
+   hwdev->hw->map.out_depth_base);
malidp_hw_write(hwdev, val, MALIDP550_DE_CONTROL);
/*
 * Mali-DP550 and Mali-DP650 encode the background color like this:
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 864fe92..6e3db57 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -228,6 +228,7 @@ struct malidp_hw_device {
 
u8 min_line_size;
u16 max_line_size;
+   u32 output_color_depth;
 
/* track the device PM state */
bool pm_suspended;
-- 
2.7.4

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

[PATCH v3 2/5] drm/arm/malidp: Split malidp interrupt initialization functions.

[Ayan Kumar Halder]

Malidp uses two interrupts ie 1. se_irq - used for memory writeback. 
 and 2. de_irq - used for display output.
Extract the hardware initialization part from malidp interrupt registration
ie (malidp_de_irq_init()/ malidp_se_irq_init()) into a separate function 
(ie malidp_de_irq_hw_init()/malidp_se_irq_hw_init())
which will be later invoked from runtime_pm_resume function when it needs
to re-enable the interrupts.

Signed-off-by: Ayan Kumar Halder 

---
Changes in v3:-
- Squashed https://patchwork.kernel.org/patch/10357203/ and 
https://patchwork.kernel.org/patch/10357209/ into a single commit.
The reason being that although the two functions belong to different units
of malidp (ie scaling engine and display engine), the intent for splitting 
these functions remain the same.

Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_hw.c | 38 +-
 drivers/gpu/drm/arm/malidp_hw.h |  2 ++
 2 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 8fb02f3..3f53f7e8 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -869,6 +869,23 @@ static irqreturn_t malidp_de_irq_thread_handler(int irq, 
void *arg)
return IRQ_HANDLED;
 }
 
+void malidp_de_irq_hw_init(struct malidp_hw_device *hwdev)
+{
+   /* ensure interrupts are disabled */
+   malidp_hw_disable_irq(hwdev, MALIDP_DE_BLOCK, 0x);
+   malidp_hw_clear_irq(hwdev, MALIDP_DE_BLOCK, 0x);
+   malidp_hw_disable_irq(hwdev, MALIDP_DC_BLOCK, 0x);
+   malidp_hw_clear_irq(hwdev, MALIDP_DC_BLOCK, 0x);
+
+   /* first enable the DC block IRQs */
+   malidp_hw_enable_irq(hwdev, MALIDP_DC_BLOCK,
+hwdev->hw->map.dc_irq_map.irq_mask);
+
+   /* now enable the DE block IRQs */
+   malidp_hw_enable_irq(hwdev, MALIDP_DE_BLOCK,
+hwdev->hw->map.de_irq_map.irq_mask);
+}
+
 int malidp_de_irq_init(struct drm_device *drm, int irq)
 {
struct malidp_drm *malidp = drm->dev_private;
@@ -889,13 +906,7 @@ int malidp_de_irq_init(struct drm_device *drm, int irq)
return ret;
}
 
-   /* first enable the DC block IRQs */
-   malidp_hw_enable_irq(hwdev, MALIDP_DC_BLOCK,
-hwdev->hw->map.dc_irq_map.irq_mask);
-
-   /* now enable the DE block IRQs */
-   malidp_hw_enable_irq(hwdev, MALIDP_DE_BLOCK,
-hwdev->hw->map.de_irq_map.irq_mask);
+   malidp_de_irq_hw_init(hwdev);
 
return 0;
 }
@@ -941,6 +952,16 @@ static irqreturn_t malidp_se_irq(int irq, void *arg)
return IRQ_HANDLED;
 }
 
+void malidp_se_irq_hw_init(struct malidp_hw_device *hwdev)
+{
+   /* ensure interrupts are disabled */
+   malidp_hw_disable_irq(hwdev, MALIDP_SE_BLOCK, 0x);
+   malidp_hw_clear_irq(hwdev, MALIDP_SE_BLOCK, 0x);
+
+   malidp_hw_enable_irq(hwdev, MALIDP_SE_BLOCK,
+hwdev->hw->map.se_irq_map.irq_mask);
+}
+
 static irqreturn_t malidp_se_irq_thread_handler(int irq, void *arg)
 {
return IRQ_HANDLED;
@@ -964,8 +985,7 @@ int malidp_se_irq_init(struct drm_device *drm, int irq)
return ret;
}
 
-   malidp_hw_enable_irq(hwdev, MALIDP_SE_BLOCK,
-hwdev->hw->map.se_irq_map.irq_mask);
+   malidp_se_irq_hw_init(hwdev);
 
return 0;
 }
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 6607aba..864fe92 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -297,6 +297,8 @@ static inline void malidp_hw_enable_irq(struct 
malidp_hw_device *hwdev,
 }
 
 int malidp_de_irq_init(struct drm_device *drm, int irq);
+void malidp_se_irq_hw_init(struct malidp_hw_device *hwdev);
+void malidp_de_irq_hw_init(struct malidp_hw_device *hwdev);
 void malidp_de_irq_fini(struct malidp_hw_device *hwdev);
 int malidp_se_irq_init(struct drm_device *drm, int irq);
 void malidp_se_irq_fini(struct malidp_hw_device *hwdev);
-- 
2.7.4

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

[PATCH v3 1/5] drm/arm/malidp: Modified the prototype of malidp irq de-initializers

[Ayan Kumar Halder]

Malidp uses two interrupts ie 1. se_irq - used for memory writeback. 
 and 2. de_irq - used for display output.
'struct drm_device' is being replaced with 'struct malidp_hw_device'
as the function argument. The reason being the dependency of
malidp_de_irq_fini on 'struct drm_device' needs to be removed so as to
enable it to call from functions which receives 'struct malidp_hw_device'
as argument. Furthermore, there is no way to retrieve 'struct drm_device'
from 'struct malidp_hw_device'.

Signed-off-by: Ayan Kumar Halder 

---
Changes in v3:-
- Squashed https://patchwork.kernel.org/patch/10357201/ and 
https://patchwork.kernel.org/patch/10308283/ into a single commit.
The reason being that although the two functions belong to different units
of malidp (ie scaling engine and display engine), the intent for modifying 
the prototype of these functions remain the same.

Changes in v2:-
- Removed the change id and modified the commit messages
---
 drivers/gpu/drm/arm/malidp_drv.c | 13 -
 drivers/gpu/drm/arm/malidp_hw.c  | 10 ++
 drivers/gpu/drm/arm/malidp_hw.h  |  4 ++--
 3 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 4b0c4b4..f7a8beb 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -295,6 +295,8 @@ static int malidp_irq_init(struct platform_device *pdev)
 {
int irq_de, irq_se, ret = 0;
struct drm_device *drm = dev_get_drvdata(>dev);
+   struct malidp_drm *malidp = drm->dev_private;
+   struct malidp_hw_device *hwdev = malidp->dev;
 
/* fetch the interrupts from DT */
irq_de = platform_get_irq_byname(pdev, "DE");
@@ -314,7 +316,7 @@ static int malidp_irq_init(struct platform_device *pdev)
 
ret = malidp_se_irq_init(drm, irq_se);
if (ret) {
-   malidp_de_irq_fini(drm);
+   malidp_de_irq_fini(hwdev);
return ret;
}
 
@@ -651,8 +653,8 @@ static int malidp_bind(struct device *dev)
 fbdev_fail:
pm_runtime_get_sync(dev);
 vblank_fail:
-   malidp_se_irq_fini(drm);
-   malidp_de_irq_fini(drm);
+   malidp_se_irq_fini(hwdev);
+   malidp_de_irq_fini(hwdev);
drm->irq_enabled = false;
 irq_init_fail:
component_unbind_all(dev, drm);
@@ -681,14 +683,15 @@ static void malidp_unbind(struct device *dev)
 {
struct drm_device *drm = dev_get_drvdata(dev);
struct malidp_drm *malidp = drm->dev_private;
+   struct malidp_hw_device *hwdev = malidp->dev;
 
drm_dev_unregister(drm);
drm_fb_cma_fbdev_fini(drm);
drm_kms_helper_poll_fini(drm);
pm_runtime_get_sync(dev);
drm_crtc_vblank_off(>crtc);
-   malidp_se_irq_fini(drm);
-   malidp_de_irq_fini(drm);
+   malidp_se_irq_fini(hwdev);
+   malidp_de_irq_fini(hwdev);
drm->irq_enabled = false;
component_unbind_all(dev, drm);
of_node_put(malidp->crtc.port);
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index e4d9ebc..8fb02f3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -900,11 +900,8 @@ int malidp_de_irq_init(struct drm_device *drm, int irq)
return 0;
 }
 
-void malidp_de_irq_fini(struct drm_device *drm)
+void malidp_de_irq_fini(struct malidp_hw_device *hwdev)
 {
-   struct malidp_drm *malidp = drm->dev_private;
-   struct malidp_hw_device *hwdev = malidp->dev;
-
malidp_hw_disable_irq(hwdev, MALIDP_DE_BLOCK,
  hwdev->hw->map.de_irq_map.irq_mask);
malidp_hw_disable_irq(hwdev, MALIDP_DC_BLOCK,
@@ -973,11 +970,8 @@ int malidp_se_irq_init(struct drm_device *drm, int irq)
return 0;
 }
 
-void malidp_se_irq_fini(struct drm_device *drm)
+void malidp_se_irq_fini(struct malidp_hw_device *hwdev)
 {
-   struct malidp_drm *malidp = drm->dev_private;
-   struct malidp_hw_device *hwdev = malidp->dev;
-
malidp_hw_disable_irq(hwdev, MALIDP_SE_BLOCK,
  hwdev->hw->map.se_irq_map.irq_mask);
 }
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index a242e97..6607aba 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -297,9 +297,9 @@ static inline void malidp_hw_enable_irq(struct 
malidp_hw_device *hwdev,
 }
 
 int malidp_de_irq_init(struct drm_device *drm, int irq);
-void malidp_de_irq_fini(struct drm_device *drm);
+void malidp_de_irq_fini(struct malidp_hw_device *hwdev);
 int malidp_se_irq_init(struct drm_device *drm, int irq);
-void malidp_se_irq_fini(struct drm_device *drm);
+void malidp_se_irq_fini(struct malidp_hw_device *hwdev);
 
 u8 malidp_hw_get_format_id(const struct malidp_hw_regmap *map,
   u8 layer_id, u32 format);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v3 3/5] drm/arm/malidp: Enable/disable interrupts in runtime pm

[Ayan Kumar Halder]

Display and scaling engine interrupts need to be disabled when the
runtime pm invokes malidp_runtime_pm_suspend(). Conversely, they
need to be enabled in malidp_runtime_pm_resume().

This patch depends on:
https://lkml.org/lkml/2017/5/15/695

Signed-off-by: Ayan Kumar Halder 
Signed-off-by: Alexandru-Cosmin Gheorghe 
Reported-by: Alexandru-Cosmin Gheorghe 

---
Changes in v3:-
- Abandoned https://patchwork.kernel.org/patch/10357213/ bacause scaling (aka 
writeback) interrupts are enabled or disabled when a commit posts a scene 
with or without writeback framebuffer respectively. This causes an issue in the
following sequence:-
(It is to be noted that scaling engine interrupts are used for writeback)
1. Commit with writeback attached.
2. Before writeback finishes, commit without writeback, which calls 
disable_writeback -> disable scaling interrupts (ie clears the scaling
interrupt mask).
3. Scaling (ie for writeback completion) interrupt is called for commit
 in step 1. However, as the scaling interrupt mask has been cleared by
step 2, so writeback completion is not signalled to userspace app. 
This is a BUG.

Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index f7a8beb..983b854 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -470,6 +470,8 @@ static int malidp_runtime_pm_suspend(struct device *dev)
/* we can only suspend if the hardware is in config mode */
WARN_ON(!hwdev->hw->in_config_mode(hwdev));
 
+   malidp_se_irq_fini(hwdev);
+   malidp_de_irq_fini(hwdev);
hwdev->pm_suspended = true;
clk_disable_unprepare(hwdev->mclk);
clk_disable_unprepare(hwdev->aclk);
@@ -488,6 +490,8 @@ static int malidp_runtime_pm_resume(struct device *dev)
clk_prepare_enable(hwdev->aclk);
clk_prepare_enable(hwdev->mclk);
hwdev->pm_suspended = false;
+   malidp_de_irq_hw_init(hwdev);
+   malidp_se_irq_hw_init(hwdev);
 
return 0;
 }
-- 
2.7.4

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

[PATCH v3 0/5] Enhance support for system and runtime power management on malidp.

[Ayan Kumar Halder]

This patch series enhances and fixes certain issues relevant to system and
runtime power management on malidp.

---
Changes in v3:
- Squashed some commits. 
- Fixed an issue related to writeback.
  Reported-by: Alexandru-Cosmin Gheorghe 

Changes in v2:
- Removed the change ids and modified some commit messages

---
Ayan Kumar Halder (5):
  drm/arm/malidp: Modified the prototype of malidp irq de-initializers
  drm/arm/malidp: Split malidp interrupt initialization functions.
  drm/arm/malidp: Enable/disable interrupts in runtime pm
  drm/arm/malidp: Set the output_depth register in modeset
  drm/arm/malidp: Added the late system pm functions

 drivers/gpu/drm/arm/malidp_drv.c | 35 +++
 drivers/gpu/drm/arm/malidp_hw.c  | 52 +++-
 drivers/gpu/drm/arm/malidp_hw.h  |  7 --
 3 files changed, 70 insertions(+), 24 deletions(-)

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

[PATCH] Intel: Add a Kaby Lake PCI ID

[matthew . s . atwood]

From: Matt Atwood 

v2: name change M -> ULX, add enumeration in KBL ULX

Signed-off-by: Matt Atwood 
---
 intel/intel_chipset.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 01d250e..f479bc4 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -200,7 +200,8 @@
 #define PCI_CHIP_KABYLAKE_ULT_GT2F 0x5921
 #define PCI_CHIP_KABYLAKE_ULX_GT1_50x5915
 #define PCI_CHIP_KABYLAKE_ULX_GT1  0x590E
-#define PCI_CHIP_KABYLAKE_ULX_GT2  0x591E
+#define PCI_CHIP_KABYLAKE_ULX_GT2_00x591E
+#define PCI_CHIP_KABYLAKE_ULX_GT2_10x591C
 #define PCI_CHIP_KABYLAKE_DT_GT2   0x5912
 #define PCI_CHIP_KABYLAKE_M_GT20x5917
 #define PCI_CHIP_KABYLAKE_DT_GT1   0x5902
-- 
2.7.4

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

Re: [PATCH] Intel: Add a Kaby Lake PCI ID

[Rodrigo Vivi]

On Tue, Apr 24, 2018 at 10:42:26AM -0700, Rodrigo Vivi wrote:
> On Mon, Apr 23, 2018 at 03:08:31PM -0700, matthew.s.atw...@intel.com wrote:
> > From: Matt Atwood 
> 
> Based on kernel commit '672e314b21dc ("drm/i915/kbl: Add KBL GT2 sku")'
> 
> (I'm adding this and pushing. Thanks for the patch)
> 
> > 
> > Signed-off-by: Matt Atwood 
> 
> Reviewed-by: Rodrigo Vivi 

ops... I take it back... sorry

I just reviewed the id and had match the
spec and kernel patch, but I had forgotten here we need a different
identifier for this platform.

You are just redefining the existent one. You need to define a new
one and add enable it.

> 
> > ---
> >  intel/intel_chipset.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > index 01d250e..6b8fd1d 100644
> > --- a/intel/intel_chipset.h
> > +++ b/intel/intel_chipset.h
> > @@ -203,6 +203,7 @@
> >  #define PCI_CHIP_KABYLAKE_ULX_GT2  0x591E
> >  #define PCI_CHIP_KABYLAKE_DT_GT2   0x5912
> >  #define PCI_CHIP_KABYLAKE_M_GT20x5917
> > +#define PCI_CHIP_KABYLAKE_M_GT20x591C
> >  #define PCI_CHIP_KABYLAKE_DT_GT1   0x5902
> >  #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B
> >  #define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B
> > -- 
> > 2.7.4
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/1] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

[Daniel Vetter]

On Mon, Apr 09, 2018 at 11:14:17AM +0200, Daniel Vetter wrote:
> On Fri, Apr 06, 2018 at 04:56:48PM -0700, Keith Packard wrote:
> > (This is an RFC on whether this pair of ioctls seems reasonable. The
> > code compiles, but I haven't tested it as I'm away from home this
> > weekend.)
> > 
> > I'm rewriting my implementation of the Vulkan EXT_display_control
> > extension, which provides a way to signal a Vulkan fence at vblank
> > time. I had implemented it using events, but that isn't great as the
> > Vulkan API includes the ability to wait for any of a set of fences to
> > be signaled. As the other Vulkan fences are implemented using
> > dma_fences in the kernel, and (eventually) using syncobj up in user
> > space, it seems reasonable to use syncobjs for everything and hook
> > vblank to those.
> > 
> > In any case, I'm proposing two new syncobj/vblank ioctls (the names
> > aren't great; suggestions welcome, as usual):
> > 
> > DRM_IOCTL_CRTC_QUEUE_SYNCOBJ
> > 
> > Create a new syncobj that will be signaled at (or after) the
> > specified vblank sequence value. This uses the same parameters
> > to specify the target sequence as
> > DRM_IOCTL_CRTC_QUEUE_SEQUENCE.
> 
> My understanding of drm_syncobj is that you:
> 
> - Create a syncobj with the drm_syncobj_create ioctl.
> 
> - Pass it around to various driver callbacks who update the attached
>   dma_fence pointer using drm_syncobj_replace_fence().
> 
> Yes amdgpu does this a bit differently, but that seems to be the
> exception.
> 
> From that pov I'd massage the uapi to just extend
> drm_crtc_queue_sequence_ioctl with a new syncobj flag. Syncobj we can just
> add at the bottom of struct drm_crtc_queue_sequence (drm structs can be
> extended like that, it's part of the uapi). Or we reuse user_data, but
> that's a bit a hack.
> 
> We also don't need a new event type, vblank code simply singals
> event->fence, which we'll arrange to be the fence behind the syncobj.
> 
> > DRM_IOCTL_CRTC_GET_SYNCOBJ
> > 
> > Once the above syncobj has been signaled, this ioctl allows
> > the application to find out when that happened, returning both
> > the vblank sequence count and time (in ns).
> 
> The android syncpt stuff already had the concept of a fence timestamp, and
> we carried it over as part of struct dma_fence.timestamp. It's just not
> exposed yet as proper uapi. I think we should aim a bit more into that
> direction with something like the below sketch:
> 
> - Add a dma_fence_signal_ts, which allows us to set the timestamp from a
>   hw clock.
> 
> - Use that in the vblank code.
> 
> - Add new drm_syncobj ioctl to query the timestamp of the attached fence
>   (if it's signalled).
> 
> That would entirely avoid the special-case ioctl just for vblank syncobj
> here. Also, this might be useful in your implementation of
> VK_GOOGLE_display_timing, since the current query timestamp you're using
> won't take into account irq wakeup latency. Using fence->timestamp will
> still miss the irq->atomic worker wakupe latency, but should be a lot
> better already.

Ok, I'm going to retract my entire suggestion above for the GET ioctl. It
would neatly work for vk_google_display_timing, but the KHR version of
that extensions very much sounds like we want the kernel to report 2 (or
maybe even 3) different timestamps back. An ioctl is much easier to extend
than shoe-horning all that into the dma_fence/drm_syncobj abstraction.

One bikeshed maybe on top: Maybe call the ioctl CRTC_GET_TS_DATA, since
that's what you're getting, not the syncobj.

Sorry for flopping around on this, just learned this all in discussions
past week.
-Daniel

> 
> > I'd like to hear comments on whether this seems reasonable, or whether
> > I should go in some other direction.
> 
> Besides a few bikesheds to align better with other stuff going around I
> think this looks good.
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

Hi Maxime, Il 24 apr 2018 10:41, Maxime Ripard  ha scritto:Hi,



On Mon, Apr 23, 2018 at 04:37:33PM +0200, Giulio Benetti wrote:

> Il 22/03/2018 19:05, Maxime Ripard ha scritto:

> > On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:

> > > The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production

> > > label, is an industrial Human Machine Interface.

> > > It features:

> > > - 512MB DDR RAM

> > > - 1 Sd-card >= 4GB

> > > - 1 Usb otg(programmable via software) with A-Usb Connector

> > > - 1 Usb host

> > > - 1 Buzzer

> > > - 1 Input for LiPo

> > > - 1 Relay to signal absence of power supply

> > > - 1 External Rtc with 56 bytes of ram + CR2032 battery

> > > - 1 7" 24-bits Tft 800x480 with PCap on

> > > - 1 Mono audio 1-watt amplifier

> > > - 1 RS485 port

> > > - 1 Power On Line through +12Vdc reaching 57.600baud,

> > >    from where it can be supplied and placed in a network of 50 units

> > > - exposed jtag pins

> > > 

> > > HMI is supplied from +12Vdc.

> > > Ethernet is absent, so for debugging, need to enable rndis on Usb otg

> > > port through an A-A usb cable.

> > > It comes in different flavours for connector types and can be found with

> > > umounted features as requested by customers.

> > 

> > So this is essentially the same board than in patch 6, but with a

> > different screen?

> > 

> > You should have a single DT then, and handle the two different panels

> > using DT overlays.

> 

> Ok for having different DT overlays.

> But do I have to submit them as patches? Or keep them in my company's repo?

> I ask you this because this involves sending also patches for displays

> and other little modifications to mainline ex:

> - rgb888 pins

> - 2 simple-panels

> - 1 uart iomux pins

> etc.

> 

> If I don't submit those overlays, the other patches wouldn't make sense

> alone as I've seen, just like rgb888 pins.



We don't have a repo for overlays yet
Ok I can provide them on my company Repo. But, sorry if insist, I would try to explain better how it's made LiNova, because I think I didn't provide enough information about it:LiNova1 is not a board with various headers to connect other peripherals such display, pcap etc. It's an HMI that I would consider the same as a Tablet, because it has a plastic enclosure also. So I would like to understand how to manage it in the best way. Try to consider LiNova1 as a Tablet series, with following list:LiNova1 4.3" ctpLiNova1 7" ctpLiNova1 10.1" ctpLiNova1 4.3" rtpLiNova1 7" rtpLiNova1 10.1" rtpEvery of those has a slightly different BOM, so they are 6 different boards with a common base(uP, ram). And same pcb. So I don't know if submit only the common base and provide separately on our github DT-overlays, or provide as many dts patches as the HMI number with a base dtsi.Basically Micronova provides entire system without the capability to hack hardware adding shields of various type.There are also other 2 LiNova:LiNova2 and LiNova3So I understand that this could lead to 18 different dts files and 3 dtsi files. But with Tablet it should be the same way. For sure people would be more interested on famous tablets instead of our HMI. Sorry if I bother you again but I wanted to understand better. 


> > > +_otg {

> > > +	dr_mode = "otg";

> > 

> > You're saying that this is a USB-A connector? Then it's not OTG since

> > it doesn't have an ID pin, this is an host.

> 

> Right, with a special overlay I will activate Usb Device for RNDIS,

> so modified as host



That doesn't really make much sense. The USB OTG is wired only using a

daughter board?
My fault, I've meant "peripheral" in one case and "host" in another case. Usually "host". Are there problem with this? I can't understand why it shouldn't make sense. There is no daughter board. Thank you very much in advance for you patience :) Giulio 




> One last question:

> now I have some patch already reviewed-by.

> Do I have to re-submit entire patchset?



Yes



Maxime



-- 

Maxime Ripard, Bootlin (formerly Free Electrons)

Embedded Linux and Kernel engineering

https://bootlin.com


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

[Bug 106222] kernel BUG at __slab_free from dc_sink_release

[bugzilla-daemon]

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

--- Comment #2 from Ernst Sjöstrand  ---
My screens always act a bit weird when waking up, they often blink very many
times and jump around a bit and give warnings in the logs etc. The Windows
driver also shows warnings every now and then, FYI.

-- 
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] Intel: Add a Kaby Lake PCI ID

[Rodrigo Vivi]

On Mon, Apr 23, 2018 at 03:08:31PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 

Based on kernel commit '672e314b21dc ("drm/i915/kbl: Add KBL GT2 sku")'

(I'm adding this and pushing. Thanks for the patch)

> 
> Signed-off-by: Matt Atwood 

Reviewed-by: Rodrigo Vivi 

> ---
>  intel/intel_chipset.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 01d250e..6b8fd1d 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -203,6 +203,7 @@
>  #define PCI_CHIP_KABYLAKE_ULX_GT20x591E
>  #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912
>  #define PCI_CHIP_KABYLAKE_M_GT2  0x5917
> +#define PCI_CHIP_KABYLAKE_M_GT2  0x591C
>  #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902
>  #define PCI_CHIP_KABYLAKE_HALO_GT2   0x591B
>  #define PCI_CHIP_KABYLAKE_HALO_GT4   0x593B
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

[Emil Velikov]

On 13 April 2018 at 11:00, Daniel Vetter  wrote:
> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.
>
> We also tend to not revoke commit rights for people no longer
> regularly active in a given project, as long as they're still part of
> the larger community.
>
> Finally make sure that commit rights, like anything happening on fd.o
> infrastructre, is subject to the fd.o's Code of Conduct.
>
> v2: Point at MAINTAINERS for contact info (Daniel S.)
>
> v3:
> - Make it clear that commit rights are voluntary and that committers
>   need to acknowledge positively when they're nominated by someone
>   else (Keith).
> - Encourage committers to drop their commit rights when they're no
>   longer active, and make it clear they'll get readded (Keith).
> - Add a line that maintainers and committers should actively nominate
>   new committers (me).
>
> v4: Typo (Petri).
>
> v5: Typo (Sean).
>
> v6: Wording clarifications and spelling (Jani).
>
> v7: Require an explicit commitment to the documented merge criteria
> and rules, instead of just the implied one through the Code of Conduct
> threat (Jani).
>
> Acked-by: Alex Deucher 
> Acked-by: Arkadiusz Hiler 
> Acked-by: Daniel Stone 
> Acked-by: Eric Anholt 
> Acked-by: Gustavo Padovan 
> Acked-by: Petri Latvala 
> Cc: Alex Deucher 
> Cc: Arkadiusz Hiler 
> Cc: Ben Widawsky 
> Cc: Daniel Stone 
> Cc: Dave Airlie 
> Cc: Eric Anholt 
> Cc: Gustavo Padovan 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Keith Packard 
> Cc: Kenneth Graunke 
> Cc: Kristian H. Kristensen 
> Cc: Maarten Lankhorst 
> Cc: Petri Latvala 
> Cc: Rodrigo Vivi 
> Cc: Sean Paul 
> Reviewed-by: Keith Packard 
> Signed-off-by: Daniel Vetter 
> ---
> If you wonder about the wide distribution list for an igt patch: I'd
> like to start a discussions about x.org community norms around commit
> rights at large, at least for all the shared repos. I plan to propose
> the same text for drm-misc and libdrm too, and hopefully others like
> mesa/xserver/wayland would follow.
>
I think the idea is pretty good, simply highlighting some bits.

What you've outlined in this patch has been in practise for many years:
 a) undocumented, applicable to most xorg projects [1]
 b) documented, mesa

IMHO having this explicitly documented and others
(wayland/weston/wayland-protocols and xserver repos) following suite
is a big plus.

HTH
Emil

[1] As in all of https://cgit.freedesktop.org/xorg but xserver
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Don't EXPORT drm_add/reset_display_info

[Ville Syrjälä]

On Tue, Apr 24, 2018 at 04:22:42PM +0200, Daniel Vetter wrote:
> Only used within drm.ko, no need to tempt drivers.
> 
> Cc: Keith Packard 
> Cc: Ville Syrjala 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_crtc_internal.h | 2 ++
>  drivers/gpu/drm/drm_edid.c  | 2 --
>  include/drm/drm_edid.h  | 2 --
>  3 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 3c2b82865ad2..5d307b23a4e6 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -220,3 +220,5 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>  
>  /* drm_edid.c */
>  void drm_mode_fixup_1366x768(struct drm_display_mode *mode);
> +void drm_reset_display_info(struct drm_connector *connector);
> +u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
> *edid);
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 134069f36482..61dd9a2fbe5b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4454,7 +4454,6 @@ drm_reset_display_info(struct drm_connector *connector)
>  
>   info->non_desktop = 0;
>  }
> -EXPORT_SYMBOL_GPL(drm_reset_display_info);
>  
>  u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
> *edid)
>  {
> @@ -4538,7 +4537,6 @@ u32 drm_add_display_info(struct drm_connector 
> *connector, const struct edid *edi
>   info->color_formats |= DRM_COLOR_FORMAT_YCRCB422;
>   return quirks;
>  }
> -EXPORT_SYMBOL_GPL(drm_add_display_info);
>  
>  static int validate_displayid(u8 *displayid, int length, int idx)
>  {
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 8d89a9c3748d..b25d12ef120a 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -465,8 +465,6 @@ struct edid *drm_get_edid(struct drm_connector *connector,
>  struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
>struct i2c_adapter *adapter);
>  struct edid *drm_edid_duplicate(const struct edid *edid);
> -void drm_reset_display_info(struct drm_connector *connector);
> -u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
> *edid);
>  int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
>  
>  u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
> -- 
> 2.16.2

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

[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows

[bugzilla-daemon]

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

--- Comment #9 from tempel.jul...@gmail.com ---
I got them too. Before those commits, my issue was way more severe. It's still
really nasty stutter though.

-- 
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 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

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

Aaron Watry  changed:

   What|Removed |Added

 Depends on||106209


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=106209
[Bug 106209] [opencl] [llvm-svn] build failure   undefined reference to
`clang::FrontendTimesIsEnabled'
-- 
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 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

c...@mailinator.com changed:

   What|Removed |Added

 CC||c...@mailinator.com

--- Comment #23 from c...@mailinator.com ---
I experienced the flicker on 4.16.3 & I had to use amdgpu.dc=0 to suppress the
flicker (but it also disabled audio over HDMI) on my RX 560.

The flicker seems to be gone on 4.16.4 for me (amdgpu.dc=0 was also removed),
and audio over HDMI is working too.

-- 
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 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows

[bugzilla-daemon]

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

--- Comment #8 from Mariusz Ceier  ---
I had these patches in the kernel tree - mine is from 22nd April, while these
patches were committed on 12th April.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?ofs=350

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

Re: [PATCH] drm/vc4: plane: Expand the lower bits using the LSB

[Eric Anholt]

Maxime Ripard  writes:

> The vc4 HVS uses an internal RGB888 representation of the frames, and will
> by default expand formats using a lower depth using zeros.
>
> This causes an issue when we try to use other compositing software such as
> pixman that seems to be filling the missing bits using the format least
> significant bit value. As such, this prevents us from checking the display
> output in a reliable way.

I don't think this is the right expansion function, though?  My
understanding of proper unorm expansion, and what pixman's
unorm_to_unorm() does, is that you replicate the value in the missing
bits until you've filled them all (so SCALER_CTL0_EXPAND_REPEAT)


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

Re: [PATCH] drm/tinydrm/mi0283qt: Always set rotation value

[Noralf Trønnes]

Den 23.04.2018 18.16, skrev Tom Callaway:

The PiTFT (ili9340) has a hardware reset circuit that resets only
on power-on and not on each reboot through a gpio like the
rpi-display does. As a result, we need to always apply the
rotation value regardless of the display "on/off" state.
Moved the rotation setting code below out_enable:.

Signed-off-by: Tom Callaway 
---
  drivers/gpu/drm/tinydrm/mi0283qt.c | 41 +-
  1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 4e6d2ee94e55..2bb9e3ce4823 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -84,24 +84,6 @@ static void mi0283qt_enable(struct drm_simple_display_pipe 
*pipe,
/* Memory Access Control */
mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT, 
MIPI_DCS_PIXEL_FMT_16BIT);
  
-	switch (mipi->rotation) {

-   default:
-   addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY |
-   ILI9341_MADCTL_MX;
-   break;
-   case 90:
-   addr_mode = ILI9341_MADCTL_MY;
-   break;
-   case 180:
-   addr_mode = ILI9341_MADCTL_MV;
-   break;
-   case 270:
-   addr_mode = ILI9341_MADCTL_MX;
-   break;
-   }
-   addr_mode |= ILI9341_MADCTL_BGR;
-   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
-
/* Frame Rate */
mipi_dbi_command(mipi, ILI9341_FRMCTR1, 0x00, 0x1b);
  
@@ -127,6 +109,29 @@ static void mi0283qt_enable(struct drm_simple_display_pipe *pipe,

msleep(100);
  
  out_enable:

+   /* The PiTFT (ili9340) has a hardware reset circuit that
+* resets only on power-on and not on each reboot through
+* a gpio like the rpi-display does.
+* As a result, we need to always apply the rotation value
+* regardless of the display "on/off" state.
+*/
+   switch (mipi->rotation) {
+   default:
+   addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY |
+   ILI9341_MADCTL_MX;
+   break;
+   case 90:
+   addr_mode = ILI9341_MADCTL_MY;
+   break;
+   case 180:
+   addr_mode = ILI9341_MADCTL_MV;
+   break;
+   case 270:
+   addr_mode = ILI9341_MADCTL_MX;
+   break;
+   }
+   addr_mode |= ILI9341_MADCTL_BGR;
+   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
  }
  


Thanks for fixing this.

Reviewed-by: Noralf Trønnes 

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

Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel

[Rob Herring]

On Thu, Apr 19, 2018 at 05:32:23PM +0800, Chen-Yu Tsai wrote:
> This panel is marketed as Banana Pi 7" LCD display. On the back is
> a sticker denoting the model name S070WV20-CT16.
> 
> This is a 7" 800x480 panel connected through a 24-bit RGB interface.
> However the panel only does 262k colors.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../display/panel/bananapi,s070wv20-ct16.txt  |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c  | 25 +++
>  2 files changed, 32 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt 
> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
> new file mode 100644
> index ..2ec35ce36e9a
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
> @@ -0,0 +1,7 @@
> +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
> +
> +Required properties:
> +- compatible: should be "bananapi,s070wv20-ct16"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.

Does this panel have a power supply (or more than 1) or backlight? I 
can't know that by just refering to simple-panel.txt.

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

Re: [PATCH 2/8] dt-bindings: display: bridge: thc63lvd1024: Add lvds map property

[Rob Herring]

On Thu, Apr 19, 2018 at 11:31:03AM +0200, Jacopo Mondi wrote:
> The THC63LVD1024 LVDS to RGB bridge supports two different input mapping
> modes, selectable by means of an external pin.
> 
> Describe the LVDS mode map through a newly defined mandatory property in
> device tree bindings.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/display/bridge/thine,thc63lvd1024.txt  | 3 
> +++
>  1 file changed, 3 insertions(+)

+1 for what Laurent said.

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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #44 from i...@yahoo.com ---
You haven't looked for the kernel panic message in the logs.
I'm still waiting for it.


As for the trace. I did download and traced Xonotic before writing the
instructions. I had no issues using the EXACT commands I have given you.
Why are you asking for instructions if you do not follow them!

You are using the SDL instead of the GLX and that might be what causes issues.

Please remove the failed traces. If the trace cannot reliably reproduce the
hang then it is useless.

Let me say it again. If you cannot hang your computer using the recorded trace,
we have no use for it. And it must hang at the exact same place.

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