On Thu, 2018-08-23 at 14:00 +0200, Karol Herbst wrote:
> Patches 1-5 are Reviewed-by: Karol Herbst
>
> I think it might be worth to test those patches on a system without
> any backlight devices just to verify we don't break things, but the
> code looked good already, so maybe we don't really
On 2018-08-17 10:11 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
>
> Signed-off-by: Hans Verkuil
> Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++--
>
Hi,
We are facing a suspend/resume problem with many different Asus laptop
models (30+ products) with Intel chipsets (multiple generations) and
nvidia GPUs (several different ones). Reproducers include:
1. Boot
2. Suspend/resume
3. Load nouveau driver
4. Start X
5. Observe slow X startup and
From: Hans Verkuil
Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++--
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
So far, struct ttm_bo_global_ref was the only way of initializing a struct
ttm_bo_global. Providing separate initializer and release functions for
struct ttm_bo_global gives drivers the option of implementing their own
init and release callbacks for drm_global_references of type
DRM_GLOBAL_TTM_BO.
From: Hans Verkuil
Add DisplayPort CEC-Tunneling-over-AUX support to nouveau.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
Hi
Am 13.08.2018 um 12:33 schrieb Christian König:
> Yes, please! I had it on my TODO list to clean that up for an eternity.
On top of these patches, I have a patch set that provides a single
init/release interface for TTM global data. I'll post it when the
current patches got some feed back.
On Friday, 3 August 2018 18:43:41 MSK Robin Murphy wrote:
> On 02/08/18 19:24, Dmitry Osipenko wrote:
> > On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
> >> On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
> >>> On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
>
Hi,
My dmesg is filled up with these errors
nouveau :01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1
nouveau :01:00.0: DRM: DDC responded, but no EDID for VGA-1
nouveau :01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1
nouveau :01:00.0: DRM: DDC responded, but no
On Fri, Aug 03, 2018 at 04:43:41PM +0100, Robin Murphy wrote:
> On 02/08/18 19:24, Dmitry Osipenko wrote:
> >On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
> >>On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
> >>>On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
nv40_sensor_setup() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself
Signed-off-by: Jia-Ju Bai
---
From: Hans Verkuil
When parsing the reply of a DP_REMOTE_DPCD_READ DPCD command the
result is wrong due to a missing idx increment.
This was never noticed since DP_REMOTE_DPCD_READ is currently not
used, but if you enable it, then it is all wrong.
Signed-off-by: Hans Verkuil
---
On 08/13/2018 02:28 PM, Thomas Zimmermann wrote:
Hi
Am 13.08.2018 um 12:33 schrieb Christian König:
Yes, please! I had it on my TODO list to clean that up for an eternity.
On top of these patches, I have a patch set that provides a single
init/release interface for TTM global data. I'll post
From: Hans Verkuil
A big problem with DP CEC-Tunneling-over-AUX is that it is tricky
to find adapters with a chipset that supports this AND where the
manufacturer actually connected the HDMI CEC line to the chipset.
Add a mention of the MegaChips 2900 chipset which seems to support
this feature
On 15/08/18 20:56, Dmitry Osipenko wrote:
On Friday, 3 August 2018 18:43:41 MSK Robin Murphy wrote:
On 02/08/18 19:24, Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
On Fri, Jul 27, 2018 at
On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
> On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
> > On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
> > > On 27/07/18 15:10, Dmitry Osipenko wrote:
> > > >On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
>
On 02/08/18 19:24, Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
On 27/07/18 15:10, Dmitry Osipenko wrote:
On Friday, 27 July 2018
From: Hans Verkuil
Now that the DisplayPort CEC-Tunneling-over-AUX drm+i915 support
has been merged in the mainline kernel it is time to roll this
out to nouveau and amdgpu as well.
I combined both in the same patch series since both depend on the
same first patch, the comments in this cover
nv50_sensor_setup() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
From: Hans Verkuil
If aux->transfer == NULL, then just return without doing
anything. In that case the function is likely called for
a non-(e)DP connector.
This never happened for the i915 driver, but the nouveau and amdgpu
drivers need this check.
The alternative would be to add this check in
Make sure Pm_runtime_* calls does not use unnecessary IS_ERR_VALUE.
when I run pm_runtime.cocci, I find the issue. So just replace it.
Signed-off-by: zhong jiang
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The functions ttm_bo_global_init() and ttm_bo_global_release() do not
receive an argument of type struct ttm_bo_global. Both take a struct
drm_global_reference that contains points to a struct ttm_bo_global_ref.
Renaming them reflects this.
Signed-off-by: Thomas Zimmermann
---
Yes, please! I had it on my TODO list to clean that up for an eternity.
Actually I never understood why that should be driver work to setup TTM?
I mean can't we just have a module_init/module_exit for TTM?
Thanks,
Christian.
Am 13.08.2018 um 12:24 schrieb Thomas Zimmermann:
TTM uses global
TTM uses global memory and BO for backing graphics buffers. These are
represented by struct ttm_mem_global and struct ttm_bo_global.
Currently, struct ttm_bo_global can only be initialized and released through
struct ttm_bo_global_ref. This is a workaround for passing an instance of
It looks like that when we moved over to using
drm_connector_for_each_possible_encoder() in nouveau, that one rather
important part of this function got dropped by accident:
/* Right v here */
for (i = 0; nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER; i++) {
Patches 1-5 are Reviewed-by: Karol Herbst
I think it might be worth to test those patches on a system without
any backlight devices just to verify we don't break things, but the
code looked good already, so maybe we don't really need to test.
On Thu, Aug 23, 2018 at 3:21 AM, Lyude Paul wrote:
26 matches
Mail list logo
