[PATCH 7/9] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling

[Paulo Zanoni]

2015-03-31 14:15 GMT-03:00 Todd Previte :
> For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
> device must attempt at least 7 times to read the EDID when it receives an
> I2C defer. The normal DRM code makes only 7 retries, regardless of whether
> or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
> since there are native defers interspersed with the I2C defers which
> results in less than 7 EDID read attempts.
>
> The solution is to decrement the retry counter when an I2C DEFER is returned
> such that another read attempt will be made. This situation should normally
> only occur in compliance testing, however, as a worse case real-world
> scenario, it would result in 13 attempts ( 6 native defers, 7 I2C defers)
> for a single transaction to complete. The net result is a slightly slower
> response to an EDID read that shouldn't significantly impact overall
> performance.
>
> Signed-off-by: Todd Previte 
> Cc: dri-devel at lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 79968e3..0539758 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -469,6 +469,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
> case DP_AUX_I2C_REPLY_DEFER:
> DRM_DEBUG_KMS("I2C defer\n");
> aux->i2c_defer_count++;
> +   /* DP Compliance Test 4.2.2.5 Requirement:
> +* Must have at least 7 retries for I2C defers on the
> +* transaction to pass this test
> +*/
> +   retry--;

I wouldn't be surprised if someone discovers a monitor or some sort of
dongle that keeps sending I2C defer errors forever, keeping us in an
infinite loop. Shouldn't we count each error in separate? Or maybe
just loop up to 14 times, in case that doesn't violate any spec (I
didn't check)?


> usleep_range(400, 500);
> continue;
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Paulo Zanoni

[PATCH -v3 00/11] drm/exynos: Add atomic modesetting support

[Inki Dae]

On 2015년 04월 04일 03:09, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Hi,
> 
> Here goes the full support for atomic modesetting on exynos. I've
> split the patches in the various phases of atomic support.
> 
> These patches sits on top of the clean up patches I've sent yesterday
> to this mailing list[1].
> 
> v2: fixes comments by Joonyoung
> - remove unused var in patch 09
> - use ->disable instead of outdated ->dpms in hdmi code
> - remove WARN_ON from crtc enable/disable
> 
> v3: fixes comment by Joonyoung
>   - move the removal of drm_helper_disable_unused_functions() to 
>   separated patch

With this patch series, Kernel booting is halted at end of kernel
booting. I tested this patch series on Trats2 board based on Exynos4412 SoC.

Below is a part of full booting logs, which was halted,
[1.992015] exynos-drm-ipp exynos-drm-ipp: drm ipp registered
successfully.
[1.993009] exynos-drm exynos-drm: bound exynos-drm-vidi (ops
vidi_component_ops)
[1.993036] exynos-drm exynos-drm: bound 11c0.fimd (ops
fimd_component_ops)
[1.993385] exynos-drm exynos-drm: bound 11c8.dsi (ops
exynos_dsi_component_ops)
[1.993390] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.993393] [drm] No driver support for vblank timestamp query.
[1.993442] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[2.043358] WARNING: CPU: 2 PID: 1209 at drivers/clk/clk.c:898
clk_unprepare+0x24/0x2c()
[2.051412] Modules linked in:
[2.054422] CPU: 2 PID: 1209 Comm: kworker/2:1 Tainted: GW
4.0.0-rc6-00526-gc49d7de-dirty #1278
[2.064337] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[2.070428] Workqueue: pm pm_runtime_work>

After that, I tested it again without FIMD and the booting is ok. So I
guess that this atomic feature has a bug to FIMD driver.

Thanks,
Inki Dae

> 
>   Gustavo
> ---
> 
> Gustavo Padovan (11):
>   drm/exynos: atomic phase 1: use drm_plane_helper_update()
>   drm/exynos: atomic phase 1: use drm_plane_helper_disable()
>   drm/exynos: atomic phase 1: add .mode_set_nofb() callback
>   drm/exynos: atomic phase 2: wire up state reset(), duplicate() and
> destroy()
>   drm/exynos: atomic phase 2: keep track of framebuffer pointer
>   drm/exynos: atomic phase 3: atomic updates of planes
>   drm/exynos: atomic phase 3: use atomic .set_config helper
>   drm/exynos: atomic phase 3: convert page flips
>   drm/exynos: remove exported functions from exynos_drm_plane
>   drm/exynos: don't disable unused functions at init
>   drm/exynos: atomic dpms support
> 
>  drivers/gpu/drm/bridge/ptn3460.c  |   4 +
>  drivers/gpu/drm/exynos/exynos_dp_core.c   |   6 +-
>  drivers/gpu/drm/exynos/exynos_drm_connector.c |   6 +-
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 226 
> --
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |   6 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |   2 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |   4 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |   6 +-
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c   |  27 +--
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  12 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   3 -
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 113 +++--
>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  11 --
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   6 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  10 +-
>  15 files changed, 187 insertions(+), 255 deletions(-)
> 

[PATCH 3/3] drm/exynos: mixer: add 2x scaling to mixer_graph_buffer

[Tobias Jakobi]

Hello Emil,

Emil Velikov wrote:
> Hi Tobias,
> 
> On 1 April 2015 at 14:29, Tobias Jakobi  
> wrote:
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 5ab0e32..6822b36 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> 
>> @@ -528,9 +552,8 @@ static void mixer_graph_buffer(struct mixer_context 
>> *ctx, int win)
>> fmt = ARGB;
>> }
>>
>> -   /* 2x scaling feature */
>> -   x_ratio = 0;
>> -   y_ratio = 0;
>> +   /* check if mixer supports requested scaling setup */
>> +   if (mixer_setup_scale(plane, _ratio, _ratio)) return;
>>
> Having return on the same line as the if statement will make
> checkpatch.pl unhappy :-(
right, I'm going to fix this and resend the series.

With best wishes,
Tobias

[PATCH -v4 0/8] drm/exynos: clean up patches (preparing for atomic)

[Inki Dae]

On 2015년 04월 02일 01:02, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Hi,
> 
> Here goes some clean ups to the exynos drivers. The main clean ups is
> the presetting and zpos making the property immutable and the removal
> of *_win_data structures.
> 
> v2 contains a extra patch to fix alpha setting for planes in fimd, so
> now fimd works fine even after the removal of struct fimd_win_data.
> 
> v3 removes a leftover var in the first commit and address the comment from
> Joonyoung about checking the return value of exynos_plane_init()
> 
> v4 rebases on top of Daniel Stone patch, currently only applied to
> exynos-drm-fixes

Applied.

Thanks,
Inki Dae

> 
> Gustavo Padovan (7):
>   drm/exynos: fimd: fix alpha setting for XR24 pixel format
>   drm/exynos: remove unused exynos_crtc->win_enable() callback
>   drm/exynos: remove struct *_win_data abstraction on planes
>   drm/exynos: preset zpos value for overlay planes
>   drm/exynos: make zpos property immutable
>   drm/exynos: remove exynos_plane_destroy()
>   drm/exynos: remove leftover functions declarations
> 
> Mandeep Singh Baines (1):
>   drm/exynos: track vblank events on a per crtc basis
> 
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c | 178 --
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c   | 101 ++---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   7 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|  27 
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|  20 +--
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 230 
> -
>  drivers/gpu/drm/exynos/exynos_drm_plane.c  |  66 ++---
>  drivers/gpu/drm/exynos/exynos_drm_plane.h  |   7 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 136 +
>  drivers/gpu/drm/exynos/exynos_mixer.c  | 221 ++-
>  include/video/samsung_fimd.h   |   5 +
>  11 files changed, 345 insertions(+), 653 deletions(-)
> 

[PATCH 07/11] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling

[Todd Previte]

For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
device must attempt at least 7 times to read the EDID when it receives an
I2C defer. The normal DRM code makes only 7 retries, regardless of whether
or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
since there are native defers interspersed with the I2C defers which
results in less than 7 EDID read attempts.

The solution is to decrement the retry counter when an I2C DEFER is returned
such that another read attempt will be made. This situation should normally
only occur in compliance testing, however, as a worse case real-world
scenario, it would result in 13 attempts ( 6 native defers, 7 I2C defers)
for a single transaction to complete. The net result is a slightly slower
response to an EDID read that shouldn't significantly impact overall
performance.

V2:
- Added a check on the number of I2C Defers to limit the number
  of times that the retries variable will be decremented. This
  is to address review feedback regarding possible infinite loops
  from misbehaving sink devices.

Signed-off-by: Todd Previte 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_dp_helper.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 79968e3..23025cf 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -469,6 +469,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)
case DP_AUX_I2C_REPLY_DEFER:
DRM_DEBUG_KMS("I2C defer\n");
aux->i2c_defer_count++;
+   /* DP Compliance Test 4.2.2.5 Requirement:
+* Must have at least 7 retries for I2C defers on the
+* transaction to pass this test
+*/
+   if (aux->i2c_defer_count < 8)
+   retry--;
usleep_range(400, 500);
continue;

-- 
1.9.1

[PATCH 7/9] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling

[Todd Previte]

On 4/6/15 5:05 PM, Paulo Zanoni wrote:
> 2015-03-31 14:15 GMT-03:00 Todd Previte :
>> For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
>> device must attempt at least 7 times to read the EDID when it receives an
>> I2C defer. The normal DRM code makes only 7 retries, regardless of whether
>> or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
>> since there are native defers interspersed with the I2C defers which
>> results in less than 7 EDID read attempts.
>>
>> The solution is to decrement the retry counter when an I2C DEFER is returned
>> such that another read attempt will be made. This situation should normally
>> only occur in compliance testing, however, as a worse case real-world
>> scenario, it would result in 13 attempts ( 6 native defers, 7 I2C defers)
>> for a single transaction to complete. The net result is a slightly slower
>> response to an EDID read that shouldn't significantly impact overall
>> performance.
>>
>> Signed-off-by: Todd Previte 
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>>   drivers/gpu/drm/drm_dp_helper.c | 5 +
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 79968e3..0539758 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -469,6 +469,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
>> struct drm_dp_aux_msg *msg)
>>  case DP_AUX_I2C_REPLY_DEFER:
>>  DRM_DEBUG_KMS("I2C defer\n");
>>  aux->i2c_defer_count++;
>> +   /* DP Compliance Test 4.2.2.5 Requirement:
>> +* Must have at least 7 retries for I2C defers on the
>> +* transaction to pass this test
>> +*/
>> +   retry--;
> I wouldn't be surprised if someone discovers a monitor or some sort of
> dongle that keeps sending I2C defer errors forever, keeping us in an
> infinite loop. Shouldn't we count each error in separate? Or maybe
> just loop up to 14 times, in case that doesn't violate any spec (I
> didn't check)?
I think the safest thing to do would be to put a failsafe on the 
i2c_defer_counter. That would ensure that the compliance test gets its 7 
retries and that if we do encounter a misbehaving device, the driver 
won't let the unending defers cause an infinite loop. Updated patch 
shortly.

>>  usleep_range(400, 500);
>>  continue;
>>
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>

[Intel-gfx] [PATCH 9/9] drm: Fix the 'native defer' message in drm_dp_i2c_do_msg()

[Paulo Zanoni]

2015-03-31 14:15 GMT-03:00 Todd Previte :
> The debug message is missing a newline at the end and it makes the
> logs hard to read when a device defers a lot. Simple 2-character fix
> adds the newline at the end.
>
> Signed-off-by: Todd Previte 
> Cc: dri-devel at lists.freedesktop.org

Why in some logs there is in fact a newline, such as here:
https://bugs.freedesktop.org/attachment.cgi?id=110049 ?

Anyway, it looks correct, so:
Reviewed-by: Paulo Zanoni 

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 0539758..281bb67 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -433,7 +433,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
> return -EREMOTEIO;
>
> case DP_AUX_NATIVE_REPLY_DEFER:
> -   DRM_DEBUG_KMS("native defer");
> +   DRM_DEBUG_KMS("native defer\n");
> /*
>  * We could check for I2C bit rate capabilities and if
>  * available adjust this interval. We could also be
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Paulo Zanoni

gma500_gfx: spread spectrum clocking?

[George McCollister]

emgd had an option to enable spread spectrum clocking on LVDS. The
documentation is vague but the setting that works is:
Option "ALL/1/Port/4/Attr/43""7"

Anyone have any idea how to set this with gma500_gfx or if it doesn't
support it, how to put the hardware in this mode?

Thanks,
George McCollister

[PATCH -v3 11/11] drm/exynos: atomic dpms support

[Gustavo Padovan]

Hi Inki,

2015-04-05 Inki Dae :

> Hi,
> 
> 2015-04-04 3:09 GMT+09:00 Gustavo Padovan :
> > From: Gustavo Padovan 
> >
> > Run dpms operations through the atomic intefaces. This basically removes
> > the .dpms() callback from econders and crtcs and use .disable() and
> > .enable() to turn the crtc on and off.
> >
> > v2: Address comments by Joonyoung:
> > - make hdmi code call ->disable() instead of ->dpms()
> > - do not use WARN_ON on crtc enable/disable
> >
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/gpu/drm/exynos/exynos_dp_core.c   |  2 +-
> >  drivers/gpu/drm/exynos/exynos_drm_connector.c |  2 +-
> >  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 99 
> > +++
> >  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  2 +-
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 +-
> >  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  2 +-
> >  drivers/gpu/drm/exynos/exynos_drm_encoder.c   | 27 ++--
> >  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  2 +-
> >  drivers/gpu/drm/exynos/exynos_hdmi.c  |  6 +-
> >  9 files changed, 70 insertions(+), 76 deletions(-)
> >
> 
> ...snip...
> 
> > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> > b/drivers/gpu/drm/exynos/exynos_hdmi.c
> > index 5b597bc..2ea7d01 100644
> > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> > @@ -1051,7 +1051,7 @@ static void hdmi_connector_destroy(struct 
> > drm_connector *connector)
> >  }
> >
> >  static struct drm_connector_funcs hdmi_connector_funcs = {
> > -   .dpms = drm_helper_connector_dpms,
> > +   .dpms = drm_atomic_helper_connector_dpms,
> > .fill_modes = drm_helper_probe_single_connector_modes,
> > .detect = hdmi_detect,
> > .destroy = hdmi_connector_destroy,
> > @@ -2127,8 +2127,8 @@ static void hdmi_dpms(struct exynos_drm_display 
> > *display, int mode)
> >  */
> > if (crtc)
> > funcs = crtc->helper_private;
> > -   if (funcs && funcs->dpms)
> > -   (*funcs->dpms)(crtc, mode);
> > +   if (funcs && funcs->disable)
> > +   (*funcs->disable)(crtc, mode);
> 
> This patch makes funcs->disable callback to be called instead of
> funcs->dpms callback. However, funcs->disable callback isn't required
> for second argument so the build is failed like below,
> 
> drivers/gpu/drm/exynos/exynos_hdmi.c: In function 'hdmi_dpms':
> drivers/gpu/drm/exynos/exynos_hdmi.c:2131:4: error: too many arguments
> to function 'funcs->disable'
> 
> Please, keep in mind that you should build it and at least have a
> basic test before posting.

Sure, I think this happened because I've been using exynos_defconfig to test
my kernels and HDMI is not there. Maybe should we add the EXYNOS_DRM_HDMI to
defconfig? What do you think?

Gustavo

[Bug 89734] GL_AMD_pinned_memory extension causing a kernel hardlock

[bugzilla-dae...@freedesktop.org]

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

--- Comment #17 from Daniel Stone  ---
(In reply to Christian König from comment #16)
> (In reply to poub365-bugzilla from comment #15)
> > The program 'dolphin-emu' received an X Window System error.
> > This probably reflects a bug in the program.
> > The error was 'BadWindow (invalid Window parameter)'.
> >   (Details: serial 8835 error_code 3 request_code 38 minor_code 0)
> >   (Note to programmers: normally, X errors are reported asynchronously;
> >that is, you will receive the error a while after causing it.
> >To debug your program, run it with the --sync command line
> >option to change this behavior. You can then get a meaningful
> >backtrace from your debugger if you break on the gdk_x_error() function.)
> > terminate called without an active exception
> > Abandon (core dumped)
> > 
> > I attach my dmesg and xorg.log just in case.
> 
> That's a completely different issue, not even sure if it is a driver problem
> at all.

It's not - request #38 is XQueryPointer, which GL drivers don't do.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150406/7f5b2731/attachment.html>

[Bug 89734] GL_AMD_pinned_memory extension causing a kernel hardlock

[bugzilla-dae...@freedesktop.org]

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

--- Comment #16 from Christian König  ---
(In reply to poub365-bugzilla from comment #15)
> Created attachment 114842 [details]
> dmesg with patch
> 
> Very strange: I booted on the patch kernel today to get a Xlog. No
> flickering on desktop neither on fullscreen game. I didn't upgrade any
> component since last time. Dolphin is working fine from my quick test.

Mhm, could be an uninitialized variable or something like this. Not sure off
hand. But if it works fine now it's unlikely that this is a driver problem.

> 
> So, I can now exit dolphin without freezing. I get this message on the
> console:
> 
> The program 'dolphin-emu' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadWindow (invalid Window parameter)'.
>   (Details: serial 8835 error_code 3 request_code 38 minor_code 0)
>   (Note to programmers: normally, X errors are reported asynchronously;
>that is, you will receive the error a while after causing it.
>To debug your program, run it with the --sync command line
>option to change this behavior. You can then get a meaningful
>backtrace from your debugger if you break on the gdk_x_error() function.)
> terminate called without an active exception
> Abandon (core dumped)
> 
> I attach my dmesg and xorg.log just in case.

That's a completely different issue, not even sure if it is a driver problem at
all.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150406/1b7f6607/attachment.html>

[PATCH v2 1/4] break kconfig dependency loop

[Paul Bolle]

On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote:
> I think part of the problem is that "select" is often used not as
> documented [1] but rather as "show my config in menuconfig for
> convenience even if my dependency is not met, and select the dependency
> even though I know it can screw up the dependency chain".

Perhaps people use select because it offers, given the problem they
face, a reasonable way to make the kconfig tools generate a
sensible .config. It helps them to spend less time fiddling with Kconfig
files. And they expect that it helps others to configure their build
more easily, as it might save those others some work.

> In the big picture, it feels like menuconfig needs a way to display
> items whose dependencies are not met, and a way to recursively enable
> said items and all their dependencies when told.

How could that work its way through (multiple levels of) things like:
depends on FOO || (BAZ && BAR)

> This would reduce the
> resistance to sticking with "select" when clearly "depends" is what's
> meant.

I had drafted a rather verbose response to this. But I think I'm not
really sure what you're saying here, probably because "select" and
"depends on" are rather different. How would you know that the actual
intention was to use "depends on"?


Paul Bolle

[Bug 89916] DRI PRIME renders only black window

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 89916
   Summary: DRI PRIME renders only black window
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: towo at siduction.org

a have a Lenovo Notebook which contains a FX-7500.
There are 2 graphics devices in:

root at lenovo-nb:/home/towo# lspci | egrep -i "displ|vga"
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Kaveri [Radeon R6/R7 Graphics]
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Jet PRO
[Radeon R5 M230] (rev ff)

The system is using the Kaveri graphics.


towo:lenovo-nb> glxinfo | grep "OpenGL renderer string"
OpenGL renderer string: Gallium 0.4 on AMD KAVERI

towo:lenovo-nb> xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x86 cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 4 outputs: 3 associated providers: 1 name:radeon
Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 0 outputs: 0 associated providers: 1 name:radeon

both devices are listed.

xrandr --setprovideroffloadsink 0x4f 0x86
towo:lenovo-nb> DRI_PRIME=1 glxinfo | grep "renderer string"
OpenGL renderer string: Gallium 0.4 on AMD HAINAN

seems to work correct.

DRI_PRIME=1 glxgears

shows only a black window, but the fps are shown in the terminal, i start from.

towo:lenovo-nb> LIBGL_DEBUG=verbose DRI_PRIME=1 glxgears 
libGL: screen 0 does not appear to be DRI3 capable
libGL: pci id for fd 4: 1002:6665, driver radeonsi
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
8793 frames in 5.0 seconds = 1758.569 FPS

doesn't even give any error, but the windows stayes black.

I use xfce 4.12 and have tryed 3 different compositors, with all i get the same
black window. Resizing the windows does not help (that i read in many bug
reports).
kernel is 4.0.0-rc6, xserver is 1.16.4, mesa is 10.6-git and radeon driver is
7.5.0
There are zero errors in the terminal or logfiles.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150406/bed530e3/attachment.html>

[PATCH v2 1/4] break kconfig dependency loop

[Mauro Carvalho Chehab]

Em Mon, 06 Apr 2015 11:50:21 +0200
Paul Bolle  escreveu:

> On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote:
> > I think part of the problem is that "select" is often used not as
> > documented [1] but rather as "show my config in menuconfig for
> > convenience even if my dependency is not met, and select the dependency
> > even though I know it can screw up the dependency chain".
> 
> Perhaps people use select because it offers, given the problem they
> face, a reasonable way to make the kconfig tools generate a
> sensible .config. It helps them to spend less time fiddling with Kconfig
> files. And they expect that it helps others to configure their build
> more easily, as it might save those others some work.

At least on media, the main usage of select is to handle complex hardware
where lots of drivers are needed in order to have support for all
boards supported by a given board.

On a practical example, let's take a look at em28xx driver. This is a
bridge driver for media boards. It supports ~100 different boards.
Each board may have different tuners, different analog TV demods,
different digital TV demods, eeproms attached into one of its I2C buses.

As this is an USB stick, the normal user will never know what are the
other components of the board without some hard work (by opening the USB
stick by seeking for the information at the Internet until he discovers
all the components).

Even after knowing the hardware components, he has to figure out what
drivers implement support for each component.

So, for the normal user, we offer a way for the user to select all
possible combinations via MEDIA_SUBDRV_AUTOSELECT. This way, he'll know
for sure that all boards supported by em28xx will be available.

For those that would embedded em28xx on some hardware (like a TV
PVR box), he can disable such option and manually select the specific
components his hardware uses.

For obvious reasons, we recommend distros to always enable
MEDIA_SUBDRV_AUTOSELECT.

So, yes, select saves a lot of work to configure the build what they
want on an easy and sane way.

That's said, while it would be possible to convert select into
depends on, the result would be really ugly, and very hard to be
maintained, as I2C drivers that don't actually depend on the bridge
drivers would need a fake depends on list:

config DVB_MB86A20S
tristate "Fujitsu mb86a20s"
# real dependency chain
depends on DVB_CORE && I2C
# fake dependency chain
depends on (!MEDIA_SUBDRV_AUTOSELECT || CONFIG_VIDEO_CX23885_DVB || 
CONFIG_VIDEO_CX231XX_DVB || CONFIG_VIDEO_EM28xx_DVB)

I got here an easy example of an ISDB-T driver, with is not used on
many boards. There are other I2C drivers that are used by almost all
media drivers, with would result on a very complex fake dependency chain.

The worse thing with such ugly fake dependency chain is that people adding
a new driver (or support for a new board) would need to remember to dig
into drivers that weren't touched, adding new stuff on their Kconfig.

> > In the big picture, it feels like menuconfig needs a way to display
> > items whose dependencies are not met, and a way to recursively enable
> > said items and all their dependencies when told.

I believe so.

> How could that work its way through (multiple levels of) things like:
> depends on FOO || (BAZ && BAR)

At least for our typical use case, the dependency chain should not have
things like the above, as we use this mainly for I2C drivers, and the
bridge drivers also depend on I2C.

I would say that, if Kconfig adds a recursive select implementation, such
implementation should:

- stop recursion if the depends condition was met;
- if the depends condition is unmet and has two or more possible options
  to satisfy (like on your above example), it should prompt the user about
  what option it would want. If it can't do it (for example, for a "silent"
  type of config, where it shouldn't be expected any userspace interaction),
  it should print a warning and not enable the driver.

Granted, this is easier said than done. We have this problem mapped
for a long time, but none was brave enough (or had enough time) to
actually try to implement something like that. So, what we generally
do, as a workaround, is to try to simplify the Kconfig stuff to avoid
complex use cases. We do that by adding fake dependencies to drivers
that might require another driver for some board to work. For example,
several USB media drivers now depends on I2C_MUX just because a few of
the possible drivers it may need should select I2C_MUX.

Btw, I2C_MUX is an optional feature of the I2C core. There's no way
for a normal user to know if a driver would need such feature or not,
as it basically depends on how the device was internally wired and if
the Kernel driver would use it (older drivers have their own solution
without using the I2C_MUX new way).

There are a few other such options at the I2C sub-system. All of them
depends on I2C 

[PATCH] wayland-drm: add a description for every item.

[Pekka Paalanen]

On Wed, 25 Mar 2015 13:10:24 +0100
Emmanuel Gil Peyrot  wrote:

> This makes the generated protocol headers a lot more readable.
> ---
>  src/egl/wayland/wayland-drm/wayland-drm.xml | 159 
> +---
>  1 file changed, 100 insertions(+), 59 deletions(-)
> 
> diff --git a/src/egl/wayland/wayland-drm/wayland-drm.xml 
> b/src/egl/wayland/wayland-drm/wayland-drm.xml
> index 5e64622..7cf06d9 100644
> --- a/src/egl/wayland/wayland-drm/wayland-drm.xml
> +++ b/src/egl/wayland/wayland-drm/wayland-drm.xml
> @@ -27,19 +27,31 @@
>  THIS SOFTWARE.
>
>  
> -  
>
> +
> +  This object is created by the server and published using the
> +  display's global event.

Hi,

you can say that a lot shorter: "This is a global object
interface." But you could also say more:
- is this a singleton?
- this is a detail of an EGL implementation
- this is specific to Mesa, an internal implementation detail that
  no-one outside Mesa is supposed to access.

> +
> +
>  
> -  
> -  
> -  
> +  
> +These errors can be emitted in response to wl_drm requests.

That's obvious, isn't it?

> +  
> +   + summary="authentication failure"/>
> +   + summary="buffer format is not supported"/>
> +   + summary="invalid name for buffer creation"/>

Ok.

>  
>  
>  
> -  
> +  
> +The drm format codes match the #defines in drm_fourcc.h.
> +
> +The formats actually supported by the compositor will be
> +reported by the format event.
> +  

Ok.

>
>
>
> @@ -100,84 +112,113 @@
>
>  
>  
> -
>  
> -  
> +  
> +Call this request with the magic received from drmGetMagic().
> +
> +It will be passed on to the drmAuthMagic() or
> +DRIAuthConnection() call.  This authentication must be
> +completed before create_buffer could be used.
> +  
> +  

Ok.

>  
>  
> -
>  
> -  
> -  
> -  
> -  
> -  
> -  
> +  
> +Create a wayland buffer for the named DRM buffer.
> +
> +The DRM surface must have a name using the flink ioctl.
> +  
> +   +   summary="wl_buffer assigned to this drm buffer"/>
> +  

Would be much more explicit to say that is a flink name, not just
any freely chosen unique number.

> +  
> +  

Units?

> +  

Units?

Without specifying the units, you are not really adding any
information here.

> +  
>  
>  
> -
>  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> +  
> +Create a wayland buffer for the named planar DRM buffer.
> +
> +The DRM surface must have a name using the flink ioctl.
> +  
> +   +   summary="wl_buffer assigned to this drm buffer"/>
> +  

Flink name.

> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  

Units?

>  
>  
> -
>  
> -  
> +  
> +Notification of the path of the drm device which is used by the
> +server.
> +
> +The client should use this device for creating local buffers.
> +Only buffers created from this device should be be passed to
> +the server using this drm object's create_buffer request.
> +  
> +  

Ok.

>  
>  
>  
> -  
> +  
> +Informs the client about a valid pixel format that can be used
> +for buffers.
> +  
> +  
>  
>  
> -
> -
> +
> +  
> +Raised if the authenticate request succeeded.
> +  
> +

Ok.

>  
>  
> -  
> -Bitmask of capabilities.
> +  
> +Lists the available capabilities the server can expose.

You lost the most important word of the description: "bitmask". It
tells how to add new values to this enum.

>
>
>  
>  
>  
> -  
> +  
> +Bitmask of capabilities supported by the server.
> +  
> +  

Ok. Might add "see wl_drm_capability".

>  
>  
>  
>  
> -
>  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> -  
> +  
> +Create a wayland buffer for the prime fd.
> +
> +Use for regular and planar buffers.  Pass 0 for offset and
> +stride for unused planes.
> +  
> +   +   summary="wl_buffer assigned to this drm buffer"/>
> +  

I'm not really sure what a "prime fd" is, care to explain it in the
description? Is it a dmabuf fd? Any additional semantics or
constraints?

> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
>  
>  
>

I don't mind if you don't add the extra information I asked for.
So, if you put the "bitmask" back, then this would be:
Revieved-by: Pekka Paalanen 


Thanks,
pq

PS. the proper mailing lists 

of_parse_phandle: "could not find phandle"

[Steve Longerbeam]

On 04/05/2015 04:14 PM, Steve Longerbeam wrote:
> Hi all,
>
> If --strip-disabled option is passed to dtc, of_parse_phandle() emits
> this error message for disabled nodes.
>

NM, I mistakenly thought the strip-disabled patch was merged, it isn't.

Steve

Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Niveditha Rau]

On 04/05/15 11:33, randyf at sibernet.com wrote:
>
>
> On Sun, 5 Apr 2015, Emil Velikov wrote:
>
>>> Note that the move of KMS drivers to this repo is recent, so there 
>>> is little
>>> history of their evolution.
>>>
>> Right, so things are a few newer than I thought, but still a bit off
>> from upstream drm. Not too shocking though considering the amount of
>> work that goes in there ;-)
>
>   It is a bit overwhelming, so I (currently) tend to scan this list 
> irregularly, and look for some source snapshot for porting reference.
>
>
>> The thing that struck me is that every drm driver comes with its own 
>> version of core drm. Not critisizing, just a bit unusual.
>
>   So technically, only one driver has it's own version, and that is 
> mostly driven by a lack of hardware to verify it continues to work as 
> drm changes (and is slated for removal as the hardware is obsolete and 
> unavailable).
>
>   With (currently) only one other drm driver, it would appear that the 
> drm core is unique to it (and to some extent it is), but the evolution 
> would be to be towards a common drm.
>
>
>>>
>>>   AFAICT, we aren't that bad.  And where we divert is probably more 
>>> driven
>>> by our lack of knowlege at the time than the ability to properly 
>>> converge,
>>> but I have lots of ground to cover before I can properly resolve the
>>> differences.
>>>
>> Afaics you're using the last UMS-capable xf86-video-radeon, so maybe
>> not all places are updated/ported to KMS ? Not a big deal though.
>>
>
>   We're hopeful that this will change in the near future (we have 
> someone working on a radeon KMS port, which is expected to use a 
> common drm).
>
>
>>>
>>>   For the most part, I have no problem with killing off any legacy 
>>> layers
>>> that should go, as we will catch up (we do have the ability to at least
>>> offer a working frozen solution in the intrim).  At least in the 
>>> near term,
>>> there are bodies actively working on getting the above driver source 
>>> in sync
>>> with what the community has.
>>>
>> Great - glad to hear. Meanwhile I've noticed a few workarounds for
>> libdrm in the hg repo:
>> - Force use of GCC and GNU make.
>> - Disabled tests.
>>
>> If you can provide some more information that would be appreciated.
>> Wouldn't mind squashing some bugs :-)
>
IIRC, we had issues with getting drm.7 without using GNU make.   And the 
build of libdrm_radeon was failing without using gcc.  I'll revert back 
to Studio and get you the failures since its been a while having made 
the switch.

We had disabled tests because of parfait failures which is part of our 
build process.  But I think we should be able to enable it now since we 
have an updated version of parfait that we are building with.

Thanks
Niveditha

[PATCH -v3 11/11] drm/exynos: atomic dpms support

[Inki Dae]

Hi,

2015-04-04 3:09 GMT+09:00 Gustavo Padovan :
> From: Gustavo Padovan 
>
> Run dpms operations through the atomic intefaces. This basically removes
> the .dpms() callback from econders and crtcs and use .disable() and
> .enable() to turn the crtc on and off.
>
> v2: Address comments by Joonyoung:
> - make hdmi code call ->disable() instead of ->dpms()
> - do not use WARN_ON on crtc enable/disable
>
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_connector.c |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 99 
> +++
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c   | 27 ++--
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  2 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  6 +-
>  9 files changed, 70 insertions(+), 76 deletions(-)
>

...snip...

> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 5b597bc..2ea7d01 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1051,7 +1051,7 @@ static void hdmi_connector_destroy(struct drm_connector 
> *connector)
>  }
>
>  static struct drm_connector_funcs hdmi_connector_funcs = {
> -   .dpms = drm_helper_connector_dpms,
> +   .dpms = drm_atomic_helper_connector_dpms,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .detect = hdmi_detect,
> .destroy = hdmi_connector_destroy,
> @@ -2127,8 +2127,8 @@ static void hdmi_dpms(struct exynos_drm_display 
> *display, int mode)
>  */
> if (crtc)
> funcs = crtc->helper_private;
> -   if (funcs && funcs->dpms)
> -   (*funcs->dpms)(crtc, mode);
> +   if (funcs && funcs->disable)
> +   (*funcs->disable)(crtc, mode);

This patch makes funcs->disable callback to be called instead of
funcs->dpms callback. However, funcs->disable callback isn't required
for second argument so the build is failed like below,

drivers/gpu/drm/exynos/exynos_hdmi.c: In function 'hdmi_dpms':
drivers/gpu/drm/exynos/exynos_hdmi.c:2131:4: error: too many arguments
to function 'funcs->disable'

Please, keep in mind that you should build it and at least have a
basic test before posting.

Thanks,
Inki Dae

>
> hdmi_poweroff(hdata);
> break;
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel