Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On to, 2016-04-07 at 11:00 +0100, Tvrtko Ursulin wrote: > On 07/04/16 08:58, Jani Nikula wrote: > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > b/drivers/gpu/drm/i915/intel_dp.c > > index da0c3d29fda8..0890e71db188 100644 > > --- a/drivers/gpu/drm/i915/intel_dp.c > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) > > */ > > intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count); > > > > + if (is_edp(intel_dp)) > > + intel_dp->sink_count = max(intel_dp->sink_count, 1); It should be max(intel_dp->sink_count, (u8)1) Which is essentially the same as max_t(u8, ...) > > + > > /* > > * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that > > * a dongle is present but no display. Unless we require to know > FWIW this patch fixes it on my BDW RVP. > > I just had to change it to max_t since max has an issue with taking an > address of const 1 by the look of it. The problem is differing types, taking address of a constant is not a problem, differing types when comparing pointers is. The whole address taking line in max macro is there to make the pointer type comparison at compile time. Regards, joonas > > Regards, > > Tvrtko > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On Thursday 07 April 2016 03:26 PM, Thulasimani, Sivakumar wrote: On 4/7/2016 1:54 PM, Ander Conselvan De Oliveira wrote: On Thu, 2016-04-07 at 10:58 +0300, Jani Nikula wrote: On Wed, 06 Apr 2016, Tvrtko Ursulin wrote: On 04/04/16 12:41, Tvrtko Ursulin wrote: On 04/04/16 12:08, Jani Nikula wrote: On Mon, 04 Apr 2016, Tvrtko Ursulin wrote: On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect URL : https://patchwork.freedesktop.org/series/5044/ State : success I pushed those to dinq. This series seems to break eDP detection on BDW RVP. I presume this is due to the sink count check. Can you add debug logging to print intel_dp->sink_count after it's been read in intel_dp_get_dpcd() please? intel_dp->sink_count is zero here. (raw value, before the DP_GET_SINK_COUNT.) Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage with not overly confident wording for the workaround there. Then the question is, is this just because you have an RVP with who knows what panel, or do we have to take into account potentially broken panels too? Then I assume the fix would be to to ignore sink count for eDP. No idea. :) I could really use a solution for this. My only development platform is incapacitated unless I revert this series which, apart from the extra work when preparing and sending out patches this is taking, including lost time waiting on CI which I suspect dislikes patches from top of unknown bases, I think it won't be so easy to continue doing so when the conflicts start arriving. :( Ander, Shubhangi? Would something like this be sensible? Tvrtko, can you give it a go? diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index da0c3d29fda8..0890e71db188 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) */ intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count); +if (is_edp(intel_dp)) +intel_dp->sink_count = max(intel_dp->sink_count, 1); I couldn't find anything in the spec that would make SINK_COUNT behave differently for eDP, but eDP with 0 sinks simply doesn't make sense, so this seems sensible to me. Ander its possible that manufacturers might not have filled sink count dpcd registers. i would prefer ignoring sink_count for edp rather than hardcoding 1 in case of edp. Also just to be safe, we should add a similar check in short pulse handling too where we check sink count. Shubhangi, can you share a patch to handle this asap ? regards, Sivakumar Shared the patch.. https://patchwork.freedesktop.org/patch/79924/ Shubhangi. /* * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that * a dongle is present but no display. Unless we require to know BR, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On 07/04/16 08:58, Jani Nikula wrote: On Wed, 06 Apr 2016, Tvrtko Ursulin wrote: On 04/04/16 12:41, Tvrtko Ursulin wrote: On 04/04/16 12:08, Jani Nikula wrote: On Mon, 04 Apr 2016, Tvrtko Ursulin wrote: On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect URL : https://patchwork.freedesktop.org/series/5044/ State : success I pushed those to dinq. This series seems to break eDP detection on BDW RVP. I presume this is due to the sink count check. Can you add debug logging to print intel_dp->sink_count after it's been read in intel_dp_get_dpcd() please? intel_dp->sink_count is zero here. (raw value, before the DP_GET_SINK_COUNT.) Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage with not overly confident wording for the workaround there. Then the question is, is this just because you have an RVP with who knows what panel, or do we have to take into account potentially broken panels too? Then I assume the fix would be to to ignore sink count for eDP. No idea. :) I could really use a solution for this. My only development platform is incapacitated unless I revert this series which, apart from the extra work when preparing and sending out patches this is taking, including lost time waiting on CI which I suspect dislikes patches from top of unknown bases, I think it won't be so easy to continue doing so when the conflicts start arriving. :( Ander, Shubhangi? Would something like this be sensible? Tvrtko, can you give it a go? diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index da0c3d29fda8..0890e71db188 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) */ intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count); + if (is_edp(intel_dp)) + intel_dp->sink_count = max(intel_dp->sink_count, 1); + /* * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that * a dongle is present but no display. Unless we require to know FWIW this patch fixes it on my BDW RVP. I just had to change it to max_t since max has an issue with taking an address of const 1 by the look of it. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On 4/7/2016 1:54 PM, Ander Conselvan De Oliveira wrote: On Thu, 2016-04-07 at 10:58 +0300, Jani Nikula wrote: On Wed, 06 Apr 2016, Tvrtko Ursulin wrote: On 04/04/16 12:41, Tvrtko Ursulin wrote: On 04/04/16 12:08, Jani Nikula wrote: On Mon, 04 Apr 2016, Tvrtko Ursulin wrote: On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect URL : https://patchwork.freedesktop.org/series/5044/ State : success I pushed those to dinq. This series seems to break eDP detection on BDW RVP. I presume this is due to the sink count check. Can you add debug logging to print intel_dp->sink_count after it's been read in intel_dp_get_dpcd() please? intel_dp->sink_count is zero here. (raw value, before the DP_GET_SINK_COUNT.) Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage with not overly confident wording for the workaround there. Then the question is, is this just because you have an RVP with who knows what panel, or do we have to take into account potentially broken panels too? Then I assume the fix would be to to ignore sink count for eDP. No idea. :) I could really use a solution for this. My only development platform is incapacitated unless I revert this series which, apart from the extra work when preparing and sending out patches this is taking, including lost time waiting on CI which I suspect dislikes patches from top of unknown bases, I think it won't be so easy to continue doing so when the conflicts start arriving. :( Ander, Shubhangi? Would something like this be sensible? Tvrtko, can you give it a go? diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index da0c3d29fda8..0890e71db188 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) */ intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count); + if (is_edp(intel_dp)) + intel_dp->sink_count = max(intel_dp->sink_count, 1); I couldn't find anything in the spec that would make SINK_COUNT behave differently for eDP, but eDP with 0 sinks simply doesn't make sense, so this seems sensible to me. Ander its possible that manufacturers might not have filled sink count dpcd registers. i would prefer ignoring sink_count for edp rather than hardcoding 1 in case of edp. Also just to be safe, we should add a similar check in short pulse handling too where we check sink count. Shubhangi, can you share a patch to handle this asap ? regards, Sivakumar /* * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that * a dongle is present but no display. Unless we require to know BR, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On Thu, 2016-04-07 at 10:58 +0300, Jani Nikula wrote: > On Wed, 06 Apr 2016, Tvrtko Ursulin wrote: > > On 04/04/16 12:41, Tvrtko Ursulin wrote: > > > > > > On 04/04/16 12:08, Jani Nikula wrote: > > > > On Mon, 04 Apr 2016, Tvrtko Ursulin > > > > wrote: > > > > > On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: > > > > > > On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: > > > > > > > == Series Details == > > > > > > > > > > > > > > Series: series starting with [1/5] drm/i915: Splitting > > > > > > > intel_dp_detect > > > > > > > URL : https://patchwork.freedesktop.org/series/5044/ > > > > > > > State : success > > > > > > > > > > > > I pushed those to dinq. > > > > > > > > > > This series seems to break eDP detection on BDW RVP. > > > > > > > > I presume this is due to the sink count check. Can you add debug logging > > > > to print intel_dp->sink_count after it's been read in > > > > intel_dp_get_dpcd() please? > > > > > > intel_dp->sink_count is zero here. (raw value, before the > > > DP_GET_SINK_COUNT.) > > > > > > Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage > > > with not overly confident wording for the workaround there. > > > > > > > Then the question is, is this just because you have an RVP with who > > > > knows what panel, or do we have to take into account potentially broken > > > > panels too? Then I assume the fix would be to to ignore sink count for > > > > eDP. > > > > > > No idea. :) > > > > I could really use a solution for this. My only development platform is > > incapacitated unless I revert this series which, apart from the extra > > work when preparing and sending out patches this is taking, including > > lost time waiting on CI which I suspect dislikes patches from top of > > unknown bases, I think it won't be so easy to continue doing so when the > > conflicts start arriving. :( > > Ander, Shubhangi? > > Would something like this be sensible? Tvrtko, can you give it a go? > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index da0c3d29fda8..0890e71db188 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) >*/ > intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count); > > + if (is_edp(intel_dp)) > + intel_dp->sink_count = max(intel_dp->sink_count, 1); I couldn't find anything in the spec that would make SINK_COUNT behave differently for eDP, but eDP with 0 sinks simply doesn't make sense, so this seems sensible to me. Ander > /* >* SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that >* a dongle is present but no display. Unless we require to know > > BR, > Jani. > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On Wed, 06 Apr 2016, Tvrtko Ursulin wrote: > On 04/04/16 12:41, Tvrtko Ursulin wrote: >> >> On 04/04/16 12:08, Jani Nikula wrote: >>> On Mon, 04 Apr 2016, Tvrtko Ursulin >>> wrote: On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: > On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: >> == Series Details == >> >> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect >> URL : https://patchwork.freedesktop.org/series/5044/ >> State : success > > I pushed those to dinq. This series seems to break eDP detection on BDW RVP. >>> >>> I presume this is due to the sink count check. Can you add debug logging >>> to print intel_dp->sink_count after it's been read in >>> intel_dp_get_dpcd() please? >> >> intel_dp->sink_count is zero here. (raw value, before the >> DP_GET_SINK_COUNT.) >> >> Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage >> with not overly confident wording for the workaround there. >> >>> Then the question is, is this just because you have an RVP with who >>> knows what panel, or do we have to take into account potentially broken >>> panels too? Then I assume the fix would be to to ignore sink count for >>> eDP. >> >> No idea. :) > > I could really use a solution for this. My only development platform is > incapacitated unless I revert this series which, apart from the extra > work when preparing and sending out patches this is taking, including > lost time waiting on CI which I suspect dislikes patches from top of > unknown bases, I think it won't be so easy to continue doing so when the > conflicts start arriving. :( Ander, Shubhangi? Would something like this be sensible? Tvrtko, can you give it a go? diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index da0c3d29fda8..0890e71db188 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) */ intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count); + if (is_edp(intel_dp)) + intel_dp->sink_count = max(intel_dp->sink_count, 1); + /* * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that * a dongle is present but no display. Unless we require to know BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On 04/04/16 12:41, Tvrtko Ursulin wrote: On 04/04/16 12:08, Jani Nikula wrote: On Mon, 04 Apr 2016, Tvrtko Ursulin wrote: On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect URL : https://patchwork.freedesktop.org/series/5044/ State : success I pushed those to dinq. This series seems to break eDP detection on BDW RVP. I presume this is due to the sink count check. Can you add debug logging to print intel_dp->sink_count after it's been read in intel_dp_get_dpcd() please? intel_dp->sink_count is zero here. (raw value, before the DP_GET_SINK_COUNT.) Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage with not overly confident wording for the workaround there. Then the question is, is this just because you have an RVP with who knows what panel, or do we have to take into account potentially broken panels too? Then I assume the fix would be to to ignore sink count for eDP. No idea. :) I could really use a solution for this. My only development platform is incapacitated unless I revert this series which, apart from the extra work when preparing and sending out patches this is taking, including lost time waiting on CI which I suspect dislikes patches from top of unknown bases, I think it won't be so easy to continue doing so when the conflicts start arriving. :( Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On 04/04/16 12:08, Jani Nikula wrote: On Mon, 04 Apr 2016, Tvrtko Ursulin wrote: On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect URL : https://patchwork.freedesktop.org/series/5044/ State : success I pushed those to dinq. This series seems to break eDP detection on BDW RVP. I presume this is due to the sink count check. Can you add debug logging to print intel_dp->sink_count after it's been read in intel_dp_get_dpcd() please? intel_dp->sink_count is zero here. (raw value, before the DP_GET_SINK_COUNT.) Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage with not overly confident wording for the workaround there. Then the question is, is this just because you have an RVP with who knows what panel, or do we have to take into account potentially broken panels too? Then I assume the fix would be to to ignore sink count for eDP. No idea. :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On Mon, 04 Apr 2016, Tvrtko Ursulin wrote: > On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: >> On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: >>> == Series Details == >>> >>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect >>> URL : https://patchwork.freedesktop.org/series/5044/ >>> State : success >> >> I pushed those to dinq. > > This series seems to break eDP detection on BDW RVP. I presume this is due to the sink count check. Can you add debug logging to print intel_dp->sink_count after it's been read in intel_dp_get_dpcd() please? Then the question is, is this just because you have an RVP with who knows what panel, or do we have to take into account potentially broken panels too? Then I assume the fix would be to to ignore sink count for eDP. BR, Jani. > > Old kernel: > > [1.554183] [drm:intel_dp_init_connector] Adding eDP connector on port A > [1.554245] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 > t9 2000 t10 500 t11_t12 6000 > [1.554254] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 > t9 2000 t10 500 t11_t12 5000 > [1.554263] [drm:intel_dp_init_panel_power_sequencer] panel power up delay > 200, power down delay 50, power cycle delay 600 > [1.554271] [drm:intel_dp_init_panel_power_sequencer] backlight on delay > 1, off delay 200 > [1.554279] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1 > [1.554530] [drm:edp_panel_vdd_on] Turning eDP port A VDD on > [1.554562] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: > 0xabcd000f > [1.556670] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 > 00 00 00 00 > [1.557617] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, > sink no > [1.557627] [drm:intel_dp_print_rates] source rates: 162000, 27, 54 > [1.557633] [drm:intel_dp_print_rates] sink rates: 162000, 27 > [1.557638] [drm:intel_dp_print_rates] common rates: 162000, 27 > [1.557651] [drm:intel_dp_init_panel_power_sequencer_registers] panel > power sequencer register settings: PP_ON 0x7d1, PP_OFF 0x1f40001, PP_DIV > 0x4af06 > [1.567299] [drm:drm_edid_to_eld] ELD: no CEA Extension found > [1.567308] [drm:intel_dp_drrs_init] VBT doesn't support DRRS > [1.567319] [drm:intel_panel_setup_backlight] Connector eDP-1 backlight > initialized, enabled, brightness 937/937 > > > Todays nightly: > > [4.306321] [drm:intel_dp_init_connector] Adding eDP connector on port A > [4.306370] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 > t9 2000 t10 500 t11_t12 6000 > [4.306371] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 > t9 2000 t10 500 t11_t12 5000 > [4.306373] [drm:intel_dp_init_panel_power_sequencer] panel power up delay > 200, power down delay 50, power cycle delay 600 > [4.306374] [drm:intel_dp_init_panel_power_sequencer] backlight on delay > 1, off delay 200 > [4.306375] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1 > [4.306402] [drm:edp_panel_vdd_on] Turning eDP port A VDD on > [4.306413] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: > 0xabcd000f > [4.319361] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 > 00 00 00 00 > [4.331840] [drm] failed to retrieve link info, disabling eDP > [4.331862] [drm:edp_panel_vdd_off_sync] Turning eDP port A VDD off > > Series reverted: > > [4.770004] [drm:intel_dp_init_connector] Adding eDP connector on port A > [4.777651] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 > t9 2000 t10 500 t11_t12 6000 > [4.788222] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 > t9 2000 t10 500 t11_t12 5000 > [4.798890] [drm:intel_dp_init_panel_power_sequencer] panel power up delay > 200, power down delay 50, power cycle delay 600 > [4.811424] [drm:intel_dp_init_panel_power_sequencer] backlight on delay > 1, off delay 200 > [4.820705] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1 > [4.828631] [drm:edp_panel_vdd_on] Turning eDP port A VDD on > [4.835061] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: > 0xabcd000f > [4.843757] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 > 00 00 00 00 > [4.853032] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, > sink no > [4.861624] [drm:intel_dp_print_rates] source rates: 162000, 27, 54 > [4.869551] [drm:intel_dp_print_rates] sink rates: 162000, 27 > [4.876558] [drm:intel_dp_print_rates] common rates: 162000, 27 > [4.883812] [drm:intel_dp_init_panel_power_sequencer_registers] panel > power sequencer register settings: PP_ON 0x7d1, PP_OFF 0x1f40001, PP_DIV > 0x4af06 > [4.900522] asix 1-2:1.0 eth0: register 'asix' at usb-:00:14.0-2, ASIX > AX88772 USB 2.0 Ethernet, b6:c3:97:fe:06:71 > [4.905379] [drm:drm_edid_to_eld] ELD: no CEA Exten
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On Friday 01 April 2016 01:11 PM, Ander Conselvan De Oliveira wrote:
On Thu, 2016-03-31 at 12:38 +, Patchwork wrote:
== Series Details ==
Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
URL : https://patchwork.freedesktop.org/series/5044/
State : success
I pushed those to dinq.
I fixed a couple of "Alignment should match open parenthesis" errors from
checkpatch. I should have pointed those out during review, but I missed them.
Ohh.. Apology for the inconvenience caused..
Thanks for fixing these errors..
Shubhangi
For future reference, in a expression like below,
DRM_DEBUG_KMS("debug message %d",
number),
the second line should be aligned with the opening '('.
Ander
Sure.. Will ensure that in future patches..
Shubhangi
== Summary ==
Series 5044v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5044/revisions/1/mbox/
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS (bsw-nuc-2)
bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12
bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21
bsw-nuc-2total:196 pass:159 dwarn:0 dfail:0 fail:0 skip:37
byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35
hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22
hsw-gt2 total:27 pass:24 dwarn:0 dfail:0 fail:0 skip:2
skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23
skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11
snb-dellxps total:79 pass:68 dwarn:0 dfail:0 fail:0 skip:10
Results at /archive/results/CI_IGT_test/Patchwork_1753/
03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly: 2016y-03m-31d-10h
-50m-15s UTC integration manifest
c448c6c059ae7bcdb7345feafd5324dd6dd164a7 drm/i915: force full detect on sink
count change
c1a69603958ccde4084f379f6c1a02314b8f5245 drm/i915: Read sink_count dpcd always
5f91fb8d635f35130714bf60601948996ee976e3 drm/i915: Reorganizing
intel_dp_check_link_status
950d50e19edac435bed7a08f6147af55cd2c8835 drm/i915: Cleaning up
intel_dp_hpd_pulse
41fd654a2ac9ffc2d59ccf2353b28f6271b1 drm/i915: Splitting intel_dp_detect
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: > On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: >> == Series Details == >> >> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect >> URL : https://patchwork.freedesktop.org/series/5044/ >> State : success > > I pushed those to dinq. This series seems to break eDP detection on BDW RVP. Old kernel: [1.554183] [drm:intel_dp_init_connector] Adding eDP connector on port A [1.554245] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 2000 t10 500 t11_t12 6000 [1.554254] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 5000 [1.554263] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 200, power down delay 50, power cycle delay 600 [1.554271] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, off delay 200 [1.554279] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1 [1.554530] [drm:edp_panel_vdd_on] Turning eDP port A VDD on [1.554562] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: 0xabcd000f [1.556670] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00 [1.557617] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, sink no [1.557627] [drm:intel_dp_print_rates] source rates: 162000, 27, 54 [1.557633] [drm:intel_dp_print_rates] sink rates: 162000, 27 [1.557638] [drm:intel_dp_print_rates] common rates: 162000, 27 [1.557651] [drm:intel_dp_init_panel_power_sequencer_registers] panel power sequencer register settings: PP_ON 0x7d1, PP_OFF 0x1f40001, PP_DIV 0x4af06 [1.567299] [drm:drm_edid_to_eld] ELD: no CEA Extension found [1.567308] [drm:intel_dp_drrs_init] VBT doesn't support DRRS [1.567319] [drm:intel_panel_setup_backlight] Connector eDP-1 backlight initialized, enabled, brightness 937/937 Todays nightly: [4.306321] [drm:intel_dp_init_connector] Adding eDP connector on port A [4.306370] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 2000 t10 500 t11_t12 6000 [4.306371] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 5000 [4.306373] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 200, power down delay 50, power cycle delay 600 [4.306374] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, off delay 200 [4.306375] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1 [4.306402] [drm:edp_panel_vdd_on] Turning eDP port A VDD on [4.306413] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: 0xabcd000f [4.319361] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00 [4.331840] [drm] failed to retrieve link info, disabling eDP [4.331862] [drm:edp_panel_vdd_off_sync] Turning eDP port A VDD off Series reverted: [4.770004] [drm:intel_dp_init_connector] Adding eDP connector on port A [4.777651] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 2000 t10 500 t11_t12 6000 [4.788222] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 5000 [4.798890] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 200, power down delay 50, power cycle delay 600 [4.811424] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, off delay 200 [4.820705] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1 [4.828631] [drm:edp_panel_vdd_on] Turning eDP port A VDD on [4.835061] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: 0xabcd000f [4.843757] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00 [4.853032] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, sink no [4.861624] [drm:intel_dp_print_rates] source rates: 162000, 27, 54 [4.869551] [drm:intel_dp_print_rates] sink rates: 162000, 27 [4.876558] [drm:intel_dp_print_rates] common rates: 162000, 27 [4.883812] [drm:intel_dp_init_panel_power_sequencer_registers] panel power sequencer register settings: PP_ON 0x7d1, PP_OFF 0x1f40001, PP_DIV 0x4af06 [4.900522] asix 1-2:1.0 eth0: register 'asix' at usb-:00:14.0-2, ASIX AX88772 USB 2.0 Ethernet, b6:c3:97:fe:06:71 [4.905379] [drm:drm_edid_to_eld] ELD: no CEA Extension found [4.905380] [drm:intel_dp_drrs_init] VBT doesn't support DRRS [4.905385] [drm:intel_panel_setup_backlight] Connector eDP-1 backlight initialized, enabled, brightness 937/937 Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On Thu, 2016-03-31 at 12:38 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
> URL : https://patchwork.freedesktop.org/series/5044/
> State : success
I pushed those to dinq.
I fixed a couple of "Alignment should match open parenthesis" errors from
checkpatch. I should have pointed those out during review, but I missed them.
For future reference, in a expression like below,
DRM_DEBUG_KMS("debug message %d",
number),
the second line should be aligned with the opening '('.
Ander
>
> == Summary ==
>
> Series 5044v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/5044/revisions/1/mbox/
>
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS (bsw-nuc-2)
>
> bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12
> bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21
> bsw-nuc-2total:196 pass:159 dwarn:0 dfail:0 fail:0 skip:37
> byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35
> hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22
> hsw-gt2 total:27 pass:24 dwarn:0 dfail:0 fail:0 skip:2
> skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23
> skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11
> snb-dellxps total:79 pass:68 dwarn:0 dfail:0 fail:0 skip:10
>
> Results at /archive/results/CI_IGT_test/Patchwork_1753/
>
> 03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly: 2016y-03m-31d-10h
> -50m-15s UTC integration manifest
> c448c6c059ae7bcdb7345feafd5324dd6dd164a7 drm/i915: force full detect on sink
> count change
> c1a69603958ccde4084f379f6c1a02314b8f5245 drm/i915: Read sink_count dpcd always
> 5f91fb8d635f35130714bf60601948996ee976e3 drm/i915: Reorganizing
> intel_dp_check_link_status
> 950d50e19edac435bed7a08f6147af55cd2c8835 drm/i915: Cleaning up
> intel_dp_hpd_pulse
> 41fd654a2ac9ffc2d59ccf2353b28f6271b1 drm/i915: Splitting intel_dp_detect
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
