[PATCH 4/4] drm/i915: Implement Link Rate fallback on Link training failure
On Tue, 06 Dec 2016, Manasi Navare wrote:
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed, update the link status property
> to "BAD" and use a lower link rate to prune the modes. It will redo
> the modeset on the current mode at lower link rate or if the current
> mode gets pruned due to lower link constraints then, it will send a
> hotplug uevent for userspace to handle it.
>
> This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> 4.3.1.6.
>
> v9:
> * Use the trimmed max values of link rate/lane count based on
> link train fallback (Daniel Vetter)
> v8:
> * Set link_status to BAD first and then call mode_valid (Jani Nikula)
> v7:
> Remove the redundant variable in previous patch itself
> v6:
> * Obtain link rate index from fallback_link_rate using
> the helper intel_dp_link_rate_index (Jani Nikula)
> * Include fallback within intel_dp_start_link_train (Jani Nikula)
> v5:
> * Move set link status to drm core (Daniel Vetter, Jani Nikula)
> v4:
> * Add fallback support for non DDI platforms too
> * Set connector->link status inside set_link_status function
> (Jani Nikula)
> v3:
> * Set link status property to BAd unconditionally (Jani Nikula)
> * Dont use two separate variables link_train_failed and link_status
> to indicate same thing (Jani Nikula)
> v2:
> * Squashed a few patches (Jani Nikula)
>
> Acked-by: Tony Cheng
> Acked-by: Harry Wentland
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Signed-off-by: Manasi Navare
This is not a journey I'd like to do again, but I like the place where
we've finally arrived.
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 27
> +++
> drivers/gpu/drm/i915/intel_dp_link_training.c | 22 --
> drivers/gpu/drm/i915/intel_drv.h | 3 +++
> 3 files changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b5c7526f..404da32 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5676,6 +5676,29 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> return false;
> }
>
> +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> +{
> + struct intel_connector *intel_connector;
> + struct drm_connector *connector;
> +
> + intel_connector = container_of(work, typeof(*intel_connector),
> +modeset_retry_work);
> + connector = &intel_connector->base;
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> + connector->name);
> +
> + /* Grab the locks before changing connector property*/
> + mutex_lock(&connector->dev->mode_config.mutex);
> + /* Set connector link status to BAD and send a Uevent to notify
> + * userspace to do a modeset.
> + */
> + drm_mode_connector_set_link_status_property(connector,
> + DRM_MODE_LINK_STATUS_BAD);
> + mutex_unlock(&connector->dev->mode_config.mutex);
> + /* Send Hotplug uevent so userspace can reprobe */
> + drm_kms_helper_hotplug_event(connector->dev);
> +}
> +
> bool
> intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> struct intel_connector *intel_connector)
> @@ -5688,6 +5711,10 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> enum port port = intel_dig_port->port;
> int type;
>
> + /* Initialize the work for modeset in case of link train failure */
> + INIT_WORK(&intel_connector->modeset_retry_work,
> + intel_dp_modeset_retry_work_fn);
> +
> if (WARN(intel_dig_port->max_lanes < 1,
>"Not enough lanes (%d) for DP on port %c\n",
>intel_dig_port->max_lanes, port_name(port)))
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 0048b52..955b239 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -313,6 +313,24 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
> void
> intel_dp_start_link_train(struct intel_dp *intel_dp)
> {
> - intel_dp_link_training_clock_recovery(intel_dp);
> - intel_dp_link_training_channel_equalization(intel_dp);
> + struct intel_connector *intel_connector = intel_dp->attached_connector;
> +
> + if (!intel_dp_link_training_clock_recovery(intel_dp))
> + goto failure_handling;
> + if (!intel_dp_link_training_channel_equalization(intel_dp))
> + goto failure_handling;
> +
> + DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
> + intel_dp->link_rate, intel_dp->
[PATCH 3/4] drm/i915: Find fallback link rate/lane count
On Tue, 06 Dec 2016, Manasi Navare wrote:
> If link training fails, then we need to fallback to lower
> link rate first and if link training fails at RBR, then
> fallback to lower lane count.
> This function finds the next lower link rate/lane count
> value after link training failure and limits the max
> link_rate and lane_count values to these fallback values.
>
> v6:
> * Cap the max link rate and lane count to the max
> values obtained during fallback link training (Daniel Vetter)
> v5:
> * Start the fallback at the lane count value passed not
> the max lane count (Jani Nikula)
> v4:
> * Remove the redundant variable link_train_failed
> v3:
> * Remove fallback_link_rate_index variable, just obtain
> that using the helper intel_dp_link_rate_index (Jani Nikula)
> v2:
> Squash the patch that returns the link rate index (Jani Nikula)
>
> Acked-by: Tony Cheng
> Acked-by: Harry Wentland
> Cc: Ville Syrjala
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_dp.c | 40
>
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 434dc7d..b5c7526f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -278,6 +278,46 @@ static int intel_dp_common_rates(struct intel_dp
> *intel_dp,
> common_rates);
> }
>
> +static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> + int *common_rates, int link_rate)
> +{
> + int common_len;
> + int index;
> +
> + common_len = intel_dp_common_rates(intel_dp, common_rates);
> + for (index = 0; index < common_len; index++) {
> + if (link_rate == common_rates[common_len - index - 1])
> + return common_len - index - 1;
Probably somewhere in the history of the patch series there was a time
when it was necessary to search for the rates in reverse order. What
possible benefit could that offer at this point?
> + }
> +
> + return -1;
> +}
> +
> +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> + int link_rate, uint8_t lane_count)
> +{
> + int common_rates[DP_MAX_SUPPORTED_RATES] = {};
No need to initialize because you initialize it a couple of lines later.
> + int common_len;
> + int link_rate_index = -1;
No need to initialize because you initialize it a couple of lines later.
> +
> + common_len = intel_dp_common_rates(intel_dp, common_rates);
> + link_rate_index = intel_dp_link_rate_index(intel_dp,
> +common_rates,
> +link_rate);
Please stop and think, and don't rush each new iteration of the patches.
What's wrong with the above lines? Please think about it. Answer at the
end of the mail (*).
> + if (link_rate_index > 0) {
> + intel_dp->max_sink_link_bw =
> drm_dp_link_rate_to_bw_code(common_rates[link_rate_index - 1]);
> + intel_dp->max_sink_lane_count = lane_count;
> + } else if (lane_count > 1) {
> + intel_dp->max_sink_link_bw = intel_dp_max_link_bw(intel_dp);
> + intel_dp->max_sink_lane_count = lane_count >> 1;
> + } else {
> + DRM_ERROR("Link Training Unsuccessful\n");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> static enum drm_mode_status
> intel_dp_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index b6526ad..47e3671 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1400,6 +1400,8 @@ bool intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> void intel_dp_set_link_params(struct intel_dp *intel_dp,
> int link_rate, uint8_t lane_count,
> bool link_mst);
> +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> + int link_rate, uint8_t lane_count);
> void intel_dp_start_link_train(struct intel_dp *intel_dp);
> void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
(*) You do intel_dp_common_rates(intel_dp, common_rates) twice, for no
reason at all.
--
Jani Nikula, Intel Open Source Technology Center
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #135 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> --- (In reply to Jan Ziak from comment #134) > (In reply to Chris Waters from comment #133) > > I decided to record how my system behaves when using Linux and my 390 > > together. > > > > This is what I see https://www.youtube.com/watch?v=9uVIzHFlTZk > > > > This is Ubuntu MATE 16.10 with Firefox open¹, something that is not at all > > graphically intensive. On KDE Plasma 5 it's even worse, my entire system > > will sometimes crash. It's completely unusable and I'm stuck on Windows > > because of this. > > > > ¹ I know there is a tab that says "Chrome Experiments", but it's unloaded. > > I > > tried loading one to see what would happen if I tried something a bit > > intensive, but my entire system crashed. Ended up having to restart > > recovered my session in Firefox. > > > > This look the same for other 390 users? > > The video is similar to what I am seeing, in the video it is more severe. > > > > If the following commands are executable on your machine: > > $ ls -d /sys/class/drm/card? > /sys/class/drm/card0 /sys/class/drm/card1 > > $ cat /sys/class/drm/card1/device/pp_dpm_sclk > 0: 300Mhz * > 1: 500Mhz > 2: 698Mhz > 3: 858Mhz > 4: 899Mhz > 5: 935Mhz > 6: 969Mhz > 7: 1000Mhz > > then (question) does the flickering go away if you run: > > $ echo 1234567 > /sys/class/drm/card1/device/pp_dpm_sclk Correction: $ echo manual > sys/class/drm/card1/device/power_dpm_force_performance_level $ echo 1234567 > /sys/class/drm/card1/device/pp_dpm_sclk -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/d019211f/attachment.html>
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #134 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> --- (In reply to Chris Waters from comment #133) > I decided to record how my system behaves when using Linux and my 390 > together. > > This is what I see https://www.youtube.com/watch?v=9uVIzHFlTZk > > This is Ubuntu MATE 16.10 with Firefox open¹, something that is not at all > graphically intensive. On KDE Plasma 5 it's even worse, my entire system > will sometimes crash. It's completely unusable and I'm stuck on Windows > because of this. > > ¹ I know there is a tab that says "Chrome Experiments", but it's unloaded. I > tried loading one to see what would happen if I tried something a bit > intensive, but my entire system crashed. Ended up having to restart > recovered my session in Firefox. > > This look the same for other 390 users? The video is similar to what I am seeing, in the video it is more severe. If the following commands are executable on your machine: $ ls -d /sys/class/drm/card? /sys/class/drm/card0 /sys/class/drm/card1 $ cat /sys/class/drm/card1/device/pp_dpm_sclk 0: 300Mhz * 1: 500Mhz 2: 698Mhz 3: 858Mhz 4: 899Mhz 5: 935Mhz 6: 969Mhz 7: 1000Mhz then (question) does the flickering go away if you run: $ echo 1234567 > /sys/class/drm/card1/device/pp_dpm_sclk -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/7c3010ef/attachment.html>
[PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug
On Tue, 06 Dec 2016, Manasi Navare wrote:
> Sink's capabilities are advertised through DPCD registers and get
> updated only on hotplug. So they should be computed only once in the
> long pulse handler and saved off in intel_dp structure for the use
> later. For this reason two new fields max_sink_lane_count and
> max_sink_link_bw are added to intel_dp structure.
>
> This also simplifies the fallback link rate/lane count logic
> to handle link training failure. In that case, the max_sink_link_bw
> and max_sink_lane_count can be reccomputed to match the fallback
> values lowering the sink capabilities due to link train failure.
>
> Cc: Ville Syrjala
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Signed-off-by: Manasi Navare
Reviewed-by: Jani Nikula
Eventually we may want to call the fields *link* rates, because that's
what they'll effectively be. Transient values that don't reflect the
sink or source capabilities, but the link capabilities.
> ---
> drivers/gpu/drm/i915/intel_dp.c | 10 --
> drivers/gpu/drm/i915/intel_drv.h | 4
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index db75bb9..434dc7d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -156,7 +156,7 @@ static u8 intel_dp_max_lane_count(struct intel_dp
> *intel_dp)
> u8 source_max, sink_max;
>
> source_max = intel_dig_port->max_lanes;
> - sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
> + sink_max = intel_dp->max_sink_lane_count;
>
> return min(source_max, sink_max);
> }
> @@ -213,7 +213,7 @@ static u8 intel_dp_max_lane_count(struct intel_dp
> *intel_dp)
>
> *sink_rates = default_rates;
>
> - return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
> + return (intel_dp->max_sink_link_bw >> 3) + 1;
> }
>
> static int
> @@ -4395,6 +4395,12 @@ static bool intel_digital_port_connected(struct
> drm_i915_private *dev_priv,
> yesno(intel_dp_source_supports_hbr2(intel_dp)),
> yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
>
> + /* Set the max lane count for sink */
> + intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> +
> + /* Set the max link BW for sink */
> + intel_dp->max_sink_link_bw = intel_dp_max_link_bw(intel_dp);
> +
> intel_dp_print_rates(intel_dp);
>
> intel_dp_read_desc(intel_dp);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index fd77a3b..b6526ad 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -906,6 +906,10 @@ struct intel_dp {
> /* sink rates as reported by DP_SUPPORTED_LINK_RATES */
> uint8_t num_sink_rates;
> int sink_rates[DP_MAX_SUPPORTED_RATES];
> + /* Max lane count for the sink as per DPCD registers */
> + uint8_t max_sink_lane_count;
> + /* Max link BW for the sink as per DPCD registers */
> + int max_sink_link_bw;
> /* sink or branch descriptor */
> struct intel_dp_desc desc;
> struct drm_dp_aux aux;
--
Jani Nikula, Intel Open Source Technology Center
[Bug 95206] Display port bandwidth regression
https://bugs.freedesktop.org/show_bug.cgi?id=95206 --- Comment #13 from mrj at advancedcontrols.com.au --- May be causing https://bugzilla.redhat.com/show_bug.cgi?id=1402293 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/f74f844f/attachment-0001.html>
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #133 from Chris Waters --- I decided to record how my system behaves when using Linux and my 390 together. This is what I see https://www.youtube.com/watch?v=9uVIzHFlTZk This is Ubuntu MATE 16.10 with Firefox open¹, something that is not at all graphically intensive. On KDE Plasma 5 it's even worse, my entire system will sometimes crash. It's completely unusable and I'm stuck on Windows because of this. ¹ I know there is a tab that says "Chrome Experiments", but it's unloaded. I tried loading one to see what would happen if I tried something a bit intensive, but my entire system crashed. Ended up having to restart recovered my session in Firefox. This look the same for other 390 users? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/1caa301d/attachment.html>
[PATCH RFC 0/3] drm/bridge: adjust bridge module's refcount and more
There has been no comments to these patches, so I guess there are no major objections. I can go forward with this, and I think a similar job should be done for drm_panel too. But I wonder if this should be done for 4.10 any more? Best regards, Jyri On 12/01/16 17:52, Jyri Sarha wrote: > Note! This series is not yet ready and should not be used as is, it is > just an RFC. > > The function documentation is missing and so are the modifications to > all affected drivers. I have added the modification patches for tilcdc > and ti-tfp410 to serve as an example and I have put them into separate > patches for readability. > > For the matter of adding devres version of of_drm_get_bridge() and > drm_bridge_alloc(), I think that is a good idea. With reference > counting, each user can hold on to their reference to the bridge > object as long as they need it. The bridge object exists as long as > any of the users still holds on to it. > > Cheers, > Jyri > > Jyri Sarha (3): > drm/drm_bridge: adjust bridge module's refcount > drm/bridge: ti-tfp410: Adapt to bridge object and module refcounting > drm/tilcdc: Adapt to bridge object refcounting > > drivers/gpu/drm/bridge/ti-tfp410.c | 16 --- > drivers/gpu/drm/drm_bridge.c | 78 > > drivers/gpu/drm/tilcdc/tilcdc_external.c | 15 -- > include/drm/drm_bridge.h | 10 +++- > 4 files changed, 99 insertions(+), 20 deletions(-) >
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #148 from Daniel Exner --- (In reply to Marek Olšák from comment #147) > Possible fix: > https://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=6dc96de303290e8d1fc294da478c4f370be98dea I wonder how _that_ could have not been found earlier. Anyway, played for about an hour without crash using: OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN (DRM 2.48.0 / 4.9.0-rc8-dirty, LLVM 4.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.1.0-devel (git-31f988a9d6). Will try to crash it again tomorrow, but looks promising. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/e6415f16/attachment.html>
[RFC PATCH 0/3] staging: remove fbdev drivers
On Wednesday 23 November 2016 09:12 AM, Tomi Valkeinen wrote: > On 23/11/16 10:52, Greg Kroah-Hartman wrote: >> On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote: >>> Hi, >>> >>> Since the fbdev framework is in maintenance mode and all new display drivers >>> should be made with the DRM framework, remove the fbdev drivers from >>> staging. >>> > > Or do you mean that we should keep the drivers in staging until there's > a matching DRM driver, but drop any plans to move the drivers from > staging to drivers/video/? If so, I'm fine with that. This is an RFC, > mostly to raise some discussion and push people to actually write those > DRM drivers =). I already have plans to convert my drivers to DRM. But it will be great if you can point me to a simple driver which will help me to understand how DRM works. Regards Sudip
[Bug 93649] [radeonsi] Graphics lockup while playing tf2
https://bugs.freedesktop.org/show_bug.cgi?id=93649 --- Comment #65 from Marek Olšák --- (In reply to Amarildo from comment #27) > What I really think is that VALVe should investigate this since this problem > started happening after they introduced mandatory Texture Streaming. If you are right about texture streaming, the cso commit might fix it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/78c40a49/attachment-0001.html>
[Bug 99013] [regression, bisected] radeonsi: commit 4c8c13b3 "Use amdgcn intrinsics for fs interpolation" makes system unusable
https://bugs.freedesktop.org/show_bug.cgi?id=99013 --- Comment #10 from Marek Olšák --- Mesa only checks for LLVM 4.0. There is no distinction between LLVM 4.0 and 4.0svn. If you want LLVM git, you always have to update Mesa from git along with LLVM and hope for the best. Or you can stick with LLVM 3.9 and only use Mesa git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/267edb3e/attachment.html>
[PATCH] drm/mxsfb: use bus_format to determine LCD bus width
On 2016-12-08 15:33, Marek Vasut wrote:
> On 12/08/2016 11:52 PM, Stefan Agner wrote:
>> The LCD bus width does not need to align with the pixel format. The
>> LCDIF controller automatically converts between pixel formats and
>> bus width by padding or dropping LSBs.
>>
>> The DRM subsystem has the notion of bus_format which allows to
>> determine what bus_formats are supported by the display. Choose the
>> first available or fallback to 24 bit if none are available.
>>
>> Signed-off-by: Stefan Agner
>> ---
>> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 28 +---
>> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 1 +
>> 2 files changed, 26 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> index 4bcc8a3..00fa244 100644
>> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> @@ -65,13 +65,11 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
>> *mxsfb)
>
> You should probably drop the WARNING: comment in this function too.
>
>> switch (format) {
>> case DRM_FORMAT_RGB565:
>> dev_dbg(drm->dev, "Setting up RGB565 mode\n");
>> -ctrl |= CTRL_SET_BUS_WIDTH(STMLCDIF_16BIT);
>> ctrl |= CTRL_SET_WORD_LENGTH(0);
>> ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
>> break;
>> case DRM_FORMAT_XRGB:
>> dev_dbg(drm->dev, "Setting up XRGB mode\n");
>> -ctrl |= CTRL_SET_BUS_WIDTH(STMLCDIF_24BIT);
>> ctrl |= CTRL_SET_WORD_LENGTH(3);
>> /* Do not use packed pixels = one pixel per word instead. */
>> ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
>> @@ -89,6 +87,9 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
>> *mxsfb)
>>
>> static void mxsfb_enable_controller(struct mxsfb_drm_private *mxsfb)
>> {
>> +struct drm_crtc *crtc = &mxsfb->pipe.crtc;
>> +struct drm_device *drm = crtc->dev;
>> +u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>
> So why do you move the bus width configuration from
> mxsfb_set_pixel_fmt() to here ? Is there any reason
> for it?
>
To emphasize that it is not related to pixel format. Also, if you have a
controller with multiple framebuffers/layers, mxsfb_set_pixel_fmt would
get called per layer...
In a full DRM driver it probably would be part of a encoder function, I
feel here it seems to map best to enable controller. It could probably
also be in mxsfb_crtc_enable (or even mxsfb_crtc_mode_set_nofb I guess),
but we do not touch LCDC_CTRL there...
>> u32 reg;
>>
>> if (mxsfb->clk_disp_axi)
>> @@ -97,7 +98,28 @@ static void mxsfb_enable_controller(struct
>> mxsfb_drm_private *mxsfb)
>> mxsfb_enable_axi_clk(mxsfb);
>>
>> /* If it was disabled, re-enable the mode again */
>> -writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
>> +reg = readl(mxsfb->base + LCDC_CTRL);
>
> Wouldn't it make more sense to cache the LCDC_CTRL content rather than
> doing R-M-W on it ?
>
Not sure what you mean by cache? Isn't the variable reg counting as a
cache?
>> +reg |= CTRL_DOTCLK_MODE;
>> +
>> +if (mxsfb->connector.display_info.num_bus_formats)
>> +bus_format = mxsfb->connector.display_info.bus_formats[0];
>> +
>> +reg &= ~CTRL_BUS_WIDTH_MASK;
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_RGB565_1X16:
>> +reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_16BIT);
>> +break;
>> +case MEDIA_BUS_FMT_RGB666_1X18:
>> +reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_18BIT);
>> +break;
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_24BIT);
>> +break;
>> +default:
>> +dev_err(drm->dev, "Unknown media bus format %d\n", bus_format);
>> +break;
>> +}
>> +writel(reg, mxsfb->base + LCDC_CTRL);
>
> On MX6SX:
> Tested-by: Marek Vasut
Thx!
--
Stefan
[Bug 98777] GPU lockup in Guns of Icarus Online
https://bugs.freedesktop.org/show_bug.cgi?id=98777 Daniel Scharrer changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Daniel Scharrer --- Everything renders fine and there are not GPU lockups with LLVM r289080 and Mesa git-31f988a9d6. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/a584b733/attachment.html>
[Bug 98776] [regression] Rendering glitches in Life Is Strange
https://bugs.freedesktop.org/show_bug.cgi?id=98776 Daniel Scharrer changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Daniel Scharrer --- Everything renders fine with LLVM r289080 and Mesa git-31f988a9d6. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/55a03bed/attachment-0001.html>
[PATCH v7 3/4] drm/i915: Find fallback link rate/lane count
If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure and limits the max
link_rate and lane_count values to these fallback values.
v7:
* Remove unnecessary intializations and remove redundant
call to intel_dp_common_rates (Jani Nikula)
v6:
* Cap the max link rate and lane count to the max
values obtained during fallback link training (Daniel Vetter)
v5:
* Start the fallback at the lane count value passed not
the max lane count (Jani Nikula)
v4:
* Remove the redundant variable link_train_failed
v3:
* Remove fallback_link_rate_index variable, just obtain
that using the helper intel_dp_link_rate_index (Jani Nikula)
v2:
Squash the patch that returns the link rate index (Jani Nikula)
Acked-by: Tony Cheng
Acked-by: Harry Wentland
Cc: Ville Syrjala
Cc: Jani Nikula
Cc: Daniel Vetter
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_dp.c | 38 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 434dc7d..1b5e0d0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -278,6 +278,44 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
common_rates);
}
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+ int *common_rates, int link_rate)
+{
+ int common_len;
+ int index;
+
+ common_len = intel_dp_common_rates(intel_dp, common_rates);
+ for (index = 0; index < common_len; index++) {
+ if (link_rate == common_rates[common_len - index - 1])
+ return common_len - index - 1;
+ }
+
+ return -1;
+}
+
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+ int link_rate, uint8_t lane_count)
+{
+ int common_rates[DP_MAX_SUPPORTED_RATES];
+ int link_rate_index;
+
+ link_rate_index = intel_dp_link_rate_index(intel_dp,
+ common_rates,
+ link_rate);
+ if (link_rate_index > 0) {
+ intel_dp->max_sink_link_bw =
drm_dp_link_rate_to_bw_code(common_rates[link_rate_index - 1]);
+ intel_dp->max_sink_lane_count = lane_count;
+ } else if (lane_count > 1) {
+ intel_dp->max_sink_link_bw = intel_dp_max_link_bw(intel_dp);
+ intel_dp->max_sink_lane_count = lane_count >> 1;
+ } else {
+ DRM_ERROR("Link Training Unsuccessful\n");
+ return -1;
+ }
+
+ return 0;
+}
+
static enum drm_mode_status
intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 377693e..0a20422 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1400,6 +1400,8 @@ bool intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
void intel_dp_set_link_params(struct intel_dp *intel_dp,
int link_rate, uint8_t lane_count,
bool link_mst);
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+ int link_rate, uint8_t lane_count);
void intel_dp_start_link_train(struct intel_dp *intel_dp);
void intel_dp_stop_link_train(struct intel_dp *intel_dp);
void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
--
1.9.1
[Bug 93649] [radeonsi] Graphics lockup while playing tf2
https://bugs.freedesktop.org/show_bug.cgi?id=93649 --- Comment #64 from Amarildo --- Have any of you tried this? https://cgit.freedesktop.org/mesa/mesa/commit/?id=6dc96de303290e8d1fc294da478c4f370be98dea -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/ee7d730a/attachment.html>
[PATCH 5/5] drm/i915: Add support for DP Video pattern compliance tests
The intel_dp_autotest_video_pattern() function gets invoked through the
compliance test handler on a HPD short pulse if the test type is
set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
reads to read the requested test pattern, video pattern resolution,
frame rate and bits per color value. The results of this analysis
are handed off to userspace so that the userspace app can set the
video pattern mode appropriately for the test result/response.
When the test is requested with specific BPC value, we read the BPC
value from the DPCD register. If this BPC value in intel_dp structure
has a non-zero value and we're on a display port connector, then we use
the value to calculate the bpp for the pipe.
The compliance_test_active flag is set at the end of the individual
test handling functions. This is so that the kernel-side operations
can be completed without the risk of interruption from the userspace
app that is polling on that flag.
v2:
* Updated the DPCD Register reads based on proper defines in header (Jani
Nikula)
* Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani
Nikula)
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 +
drivers/gpu/drm/i915/intel_dp.c | 67 +
drivers/gpu/drm/i915/intel_dp_mst.c | 7 +++-
drivers/gpu/drm/i915/intel_drv.h| 3 ++
4 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b2ff532..e87a46d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4540,6 +4540,15 @@ static int i915_displayport_test_data_show(struct
seq_file *m, void *data)
DP_TEST_LINK_EDID_READ)
seq_printf(m, "%lx",
intel_dp->compliance.test_data.edid);
+ else if (intel_dp->compliance.test_type ==
+DP_TEST_LINK_VIDEO_PATTERN) {
+ seq_printf(m, "hdisplay: %d\n",
+
intel_dp->compliance.test_data.hdisplay);
+ seq_printf(m, "vdisplay: %d\n",
+
intel_dp->compliance.test_data.vdisplay);
+ seq_printf(m, "bpc: %u\n",
+ intel_dp->compliance.test_data.bpc);
+ }
} else
seq_puts(m, "0");
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fb6f9e5..5e91bfc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -28,8 +28,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -1539,6 +1541,12 @@ static int intel_dp_compute_bpp(struct intel_dp
*intel_dp,
if (bpc > 0)
bpp = min(bpp, 3*bpc);
+ /* For DP Compliance we override the computed bpp for the pipe */
+ if (intel_dp->compliance.test_data.bpc != 0) {
+ pipe_config->pipe_bpp = 3*intel_dp->compliance.test_data.bpc;
+ DRM_DEBUG_KMS("Setting pipe_bpp to %d\n",
+ pipe_config->pipe_bpp);
+ }
return bpp;
}
@@ -3859,6 +3867,65 @@ static uint8_t intel_dp_autotest_link_training(struct
intel_dp *intel_dp)
static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
{
uint8_t test_result = DP_TEST_NAK;
+ uint8_t test_pattern;
+ uint16_t test_misc;
+ __be16 h_width, v_height;
+ int status = 0;
+
+ /* Read the TEST_PATTERN (DP CTS 3.1.5) */
+ status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_PATTERN,
+ &test_pattern, 1);
+ if (status <= 0) {
+ DRM_DEBUG_KMS("Test pattern read failed\n");
+ return 0;
+ }
+ if (test_pattern != DP_COLOR_RAMP)
+ return test_result;
+ intel_dp->compliance.test_data.video_pattern = test_pattern;
+
+ status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_H_WIDTH_HI,
+ &h_width, 2);
+ if (status <= 0) {
+ DRM_DEBUG_KMS("H Width read failed\n");
+ return 0;
+ }
+ intel_dp->compliance.test_data.hdisplay = be16_to_cpu(h_width);
+
+ status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_V_HEIGHT_HI,
+ &v_height, 2);
+ if (status <= 0) {
+ DRM_DEBUG_KMS("V Height read failed\n");
+ return 0;
+ }
+ intel_dp->compliance.test_data.vdisplay = be16_to_cpu(v_height);
+
+ status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_MISC_LO,
+ &test_misc, 1);
+ if (sta
[PATCH 4/5] drm: Add definitions for DP compliance Video pattern tests
v2: * Add all the other DP Complianec TEST register defs (Jani Nikula) Cc: dri-devel at lists.freedesktop.org Cc: Jani Nikula Cc: Daniel Vetter Cc: Ville Syrjala Signed-off-by: Manasi Navare --- include/drm/drm_dp_helper.h | 58 + 1 file changed, 58 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 55bbeb0..3525d95 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -416,6 +416,64 @@ #define DP_TEST_LANE_COUNT 0x220 #define DP_TEST_PATTERN0x221 +# define DP_NO_TEST_PATTERN (0x0) +# define DP_COLOR_RAMP (0x1) +# define DP_BLACK_AND_WHITE_VERTICAL_LINES (0x2) +# define DP_COLOR_SQUARE(0x3) + +#define DP_TEST_H_TOTAL_HI 0x222 +#define DP_TEST_H_TOTAl_LO 0x223 + +#define DP_TEST_V_TOTAL_HI 0x224 +#define DP_TEST_V_TOTAl_LO 0x225 + +#define DP_TEST_H_START_HI 0x226 +#define DP_TEST_H_START_LO 0x227 + +#define DP_TEST_V_START_HI 0x228 +#define DP_TEST_V_START_LO 0x229 + +#define DP_TEST_HSYNC_HI0x22A +#define DP_TEST_HSYNC_LO0x22B + +#define DP_TEST_VSYNC_HI0x22C +#define DP_TEST_VSYNC_LO0x22D + +#define DP_TEST_H_WIDTH_HI 0x22E +#define DP_TESt_H_WIDTH_LO 0x22F + +#define DP_TEST_V_HEIGHT_HI 0x230 +#define DP_TEST_V_HEIGHT_LO 0x231 + +#define DP_TEST_MISC_LO 0x232 +# define DP_TEST_SYNC_CLOCK_MASK(1 << 0) +# define DP_CLOCK_ASYNC (0x0) +# define DP_CLOCK_SYNC (0x1) +# define DP_TEST_COLOR_FORMAT_MASK (3 << 1) +# define DP_TEST_COLOR_FORMAT_SHIFT 1 +# define DP_COLOR_FORMAT_RGB(0x0) +# define DP_COLOR_FORMAT_YCbCr422 (0x1) +# define DP_COLOR_FORMAT_YCbCr444 (0x2) +# define DP_TEST_DYNAMIC_RANGE_MASK (1 << 3) +# define DP_TEST_DYNAMIC_RANGE_SHIFT3 +# define DP_VESA_RANGE (0x0) +# define DP_CEA_RANGE (0x1) +# define DP_TEST_BIT_DEPTH_MASK (7 << 5) +# define DP_TEST_BIT_DEPTH_SHIFT5 +# define DP_TEST_BIT_DEPTH_6(0x0) +# define DP_TEST_BIT_DEPTH_8(0x1) +# define DP_TEST_BIT_DEPTH_10 (0x2) +# define DP_TEST_BIT_DEPTH_12 (0x3) +# define DP_TEST_BIT_DEPTH_16 (0x4) +#define DP_TEST_MISC_HI 0x233 +# define DP_TEST_REFRESH_DENOMINATOR_MASK (1 << 0) +# define REFRESH_DENOMINATOR_1 (0x0) +# define REFRESH_DENOMINATOR_1_001 (0x1) +# define DP_TEST_INTERLACED_MASK(1 << 1) +# define DP_NON_INTERLACED (0x0) +# define DP_INTERLACED (0x1) + +#define DP_TEST_REFRESH_RATE_NUMERATOR 0x234 #define DP_TEST_CRC_R_CR 0x240 #define DP_TEST_CRC_G_Y0x242 -- 1.9.1
[PATCH 3/5] drm/i915: Fixes to support DP Compliance EDID tests
This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte
Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bbf8cdc..fb6f9e5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3864,7 +3864,7 @@ static uint8_t intel_dp_autotest_video_pattern(struct
intel_dp *intel_dp)
static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
{
- uint8_t test_result = DP_TEST_NAK;
+ uint8_t test_result = DP_TEST_ACK;
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = &intel_connector->base;
@@ -3899,7 +3899,7 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp
*intel_dp)
DRM_DEBUG_KMS("Failed to write EDID checksum\n");
test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
- intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_STANDARD;
+ intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_PREFERRED;
}
/* Set test active flag here so userspace doesn't interrupt things */
--
1.9.1
[PATCH 2/5] drm/i915: Add support for DP link training compliance
This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is sent in order
to trigger another modeset during which the pipe is configured
and link is retrained and enabled for link parameters requested
by the test.
v2:
* Validate the test lane count before using it in
intel_dp_compute_config (Jani Nikula)
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
---
drivers/gpu/drm/i915/intel_dp.c | 62 +---
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 60 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c1e107c..bbf8cdc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -278,6 +278,21 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
common_rates);
}
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+ int *common_rates, int link_rate)
+{
+ int common_len;
+ int index;
+
+ common_len = intel_dp_common_rates(intel_dp, common_rates);
+ for (index = 0; index < common_len; index++) {
+ if (link_rate == common_rates[common_len - index - 1])
+ return common_len - index - 1;
+ }
+
+ return -1;
+}
+
static enum drm_mode_status
intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -1544,6 +1559,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
/* Conveniently, the link BW constants become indices with a shift...*/
int min_clock = 0;
int max_clock;
+ int link_rate_index;
int bpp, mode_rate;
int link_avail, link_clock;
int common_rates[DP_MAX_SUPPORTED_RATES] = {};
@@ -1585,6 +1601,17 @@ static int intel_dp_compute_bpp(struct intel_dp
*intel_dp,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
return false;
+ /* Use values requested by Compliance Test Request */
+ if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
+ link_rate_index = intel_dp_link_rate_index(intel_dp,
+ common_rates,
+
drm_dp_bw_code_to_link_rate(intel_dp->compliance.test_link_rate));
+ if (link_rate_index >= 0)
+ min_clock = max_clock = link_rate_index;
+ if (min_lane_count <= intel_dp->compliance.test_lane_count
+ && intel_dp->compliance.test_lane_count >= max_lane_count)
+ min_lane_count = max_lane_count =
intel_dp->compliance.test_lane_count;
+ }
DRM_DEBUG_KMS("DP link computation with max lane count %i "
"max bw %d pixel clock %iKHz\n",
max_lane_count, common_rates[max_clock],
@@ -1632,6 +1659,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
}
}
}
+
}
return false;
@@ -3804,6 +3832,27 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp)
{
uint8_t test_result = DP_TEST_ACK;
+ int status = 0;
+ /* (DP CTS 1.2)
+* 4.3.1.11
+*/
+ /* Read the TEST_LANE_COUNT and TEST_LINK_RTAE fields (DP CTS 3.1.4) */
+ status = drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_LANE_COUNT,
+ &intel_dp->compliance.test_lane_count);
+
+ if (status <= 0) {
+ DRM_DEBUG_KMS("Lane count read failed\n");
+ return 0;
+ }
+ intel_dp->compliance.test_lane_count &= DP_MAX_LANE_COUNT_MASK;
+
+ status = drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_LINK_RATE,
+ &intel_dp->compliance.test_link_rate);
+ if (status <= 0) {
+ DRM_DEBUG_KMS("Link Rate read failed\n");
+ return 0;
+ }
+
return test_result;
}
@@ -4018,9 +4067,8 @@ static void intel_dp_handle_test_request(struct intel_dp
*intel_dp)
if (WARN_ON_ONCE(!intel_dp->lane_count))
return;
- /* if link training is requested we should perform it always */
- if ((intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) ||
- (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
+ /* Retrain if Channel EQ or CR not ok */
+ if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
[PATCH 1/5] drm/i915: Move all the DP compliance data to a separate struct
This patch does not change anything functionally, just cleans up
the DP compliance related variables and stores them all together
in a separate struct intel_dp_compliance. There is another struct
intel_dp_compliance_data to store all the test data. This makes it easy to
reset the compliance variables through a memset instead of
individual resetting.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 -
drivers/gpu/drm/i915/intel_dp.c | 24 ++--
drivers/gpu/drm/i915/intel_drv.h| 14 +++---
3 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a746130..b2ff532 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4463,9 +4463,9 @@ static ssize_t i915_displayport_test_active_write(struct
file *file,
* testing code, only accept an actual value of 1 here
*/
if (val == 1)
- intel_dp->compliance_test_active = 1;
+ intel_dp->compliance.test_active = 1;
else
- intel_dp->compliance_test_active = 0;
+ intel_dp->compliance.test_active = 0;
}
}
out:
@@ -4492,7 +4492,7 @@ static int i915_displayport_test_active_show(struct
seq_file *m, void *data)
if (connector->status == connector_status_connected &&
connector->encoder != NULL) {
intel_dp = enc_to_intel_dp(connector->encoder);
- if (intel_dp->compliance_test_active)
+ if (intel_dp->compliance.test_active)
seq_puts(m, "1");
else
seq_puts(m, "0");
@@ -4536,7 +4536,10 @@ static int i915_displayport_test_data_show(struct
seq_file *m, void *data)
if (connector->status == connector_status_connected &&
connector->encoder != NULL) {
intel_dp = enc_to_intel_dp(connector->encoder);
- seq_printf(m, "%lx", intel_dp->compliance_test_data);
+ if (intel_dp->compliance.test_type ==
+ DP_TEST_LINK_EDID_READ)
+ seq_printf(m, "%lx",
+ intel_dp->compliance.test_data.edid);
} else
seq_puts(m, "0");
}
@@ -4575,7 +4578,7 @@ static int i915_displayport_test_type_show(struct
seq_file *m, void *data)
if (connector->status == connector_status_connected &&
connector->encoder != NULL) {
intel_dp = enc_to_intel_dp(connector->encoder);
- seq_printf(m, "%02lx", intel_dp->compliance_test_type);
+ seq_printf(m, "%02lx", intel_dp->compliance.test_type);
} else
seq_puts(m, "0");
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index db75bb9..c1e107c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3834,7 +3834,7 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp
*intel_dp)
DRM_DEBUG_KMS("EDID read had %d NACKs, %d DEFERs\n",
intel_dp->aux.i2c_nack_count,
intel_dp->aux.i2c_defer_count);
- intel_dp->compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
+ intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_FAILSAFE;
} else {
struct edid *block = intel_connector->detect_edid;
@@ -3850,11 +3850,11 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp
*intel_dp)
DRM_DEBUG_KMS("Failed to write EDID checksum\n");
test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
- intel_dp->compliance_test_data = INTEL_DP_RESOLUTION_STANDARD;
+ intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_STANDARD;
}
/* Set test active flag here so userspace doesn't interrupt things */
- intel_dp->compliance_test_active = 1;
+ intel_dp->compliance.test_active = 1;
return test_result;
}
@@ -3880,22 +3880,22 @@ static void intel_dp_handle_test_request(struct
intel_dp *intel_dp)
switch (rxdata) {
case DP_TEST_LINK_TRAINING:
DRM_DEBUG_KMS("LINK_TRAINING test requested\n");
- intel_dp->compliance_test_type = DP_TEST_LINK_TRAINING;
+ intel_dp->compliance.test_type = DP_TEST_LINK_TRAINING;
response = intel_dp_autotest_link_training(intel_dp);
[PATCH 0/5] Add Automation Support for DP Compliance Testing (Rev 2)
This addresses all the review comments from the earlier patch series: https://patchwork.freedesktop.org/series/15771/ DP 1.2 compliance testing can be acheived using DPR-120's CTS suite. This compliance unit sends a short pulse to initiate link training and video pattern generation compliance tests and sends a long pulse to initate EDID compliance tests. It also sets the AUTOMATED TEST REQUEST bit in Device IRQ to 1. These patches add support in the kernel to respond to these test requests sent by DPR-120. The test handler has been added for Link training/EDID and Video pattern compliance tests that gets invoked on short/long pulse sent by DPR-120. The test handler for each of the tests reads the corresponding DPCD registers to read the test parameters. These tests need to be run with the IGT DP compliance automation tool. Link Training Tests (4.3.1.1 - 4.3.2.3): It reads the DPCD registers to get the link rate and lane count requested by test and sends a hotplug uevent for the userspace to redo a modeset in order to train the link at the requested test parameters. EDID Tests (4.2.2.3 - 4.2.2.6): It reads the EDID set by the DPR-120, if EDID read succeeds, it sets the video mode to PREFERRED and sets the test_active flag. This flag wakes up the IGT compliance tool that then fills the framebuffers and triggers a modeset. Video Pattern Tests (4.3.3.1): It reads the DPCD registers to set the requested video pattern parameters. It then sets the test active flag that wakes up the IGT tool, userspace reads the video pattern values from corresponding debugfs files and fills the framebuffers and triggers a modeset. Manasi Navare (5): drm/i915: Move all the DP compliance data to a separate struct drm/i915: Add support for DP link training compliance drm/i915: Fixes to support DP Compliance EDID tests drm: Add definitions for DP compliance Video pattern tests drm/i915: Add support for DP Video pattern compliance tests drivers/gpu/drm/i915/i915_debugfs.c | 22 -- drivers/gpu/drm/i915/intel_dp.c | 153 +++- drivers/gpu/drm/i915/intel_dp_mst.c | 7 +- drivers/gpu/drm/i915/intel_drv.h| 19 - include/drm/drm_dp_helper.h | 58 ++ 5 files changed, 232 insertions(+), 27 deletions(-) -- 1.9.1
[PATCH] linux/types.h: enable endian checks for all sparse builds
On Thu, Dec 08, 2016 at 06:38:11AM +, Bart Van Assche wrote:
> On 12/07/16 21:54, Michael S. Tsirkin wrote:
> > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote:
> >> Additionally, there are notable exceptions to the rule that most drivers
> >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it
> >> would remain possible to check such drivers with sparse without enabling
> >> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__
> >> into e.g. #ifndef __DONT_CHECK_ENDIAN__?
> >
> > The right thing is probably just to fix these, isn't it?
> > Until then, why not just ignore the warnings?
>
> Neither option is realistic. With endian-checking enabled the qla2xxx
> driver triggers so many warnings that it becomes a real challenge to
> filter the non-endian warnings out manually:
>
> $ for f in "" CF=-D__CHECK_ENDIAN__; do make M=drivers/scsi/qla2xxx C=2\
> $f | &grep -c ': warning:'; done
> 4
> 752
You can always revert this patch in your tree, or whatever. It does not
look like this will get fixed otherwise.
> If you think it would be easy to fix the endian warnings triggered by
> the qla2xxx driver, you are welcome to try to fix these.
>
> Bart.
Yea, this hardware was designed by someone who thought mixing
LE and BE all over the place is a good idea.
But who said it should be easy?
Maybe this change will be enough to motivate the maintainers.
Here's a minor buglet for you as a motivator:
if (ct_rsp->header.response !=
cpu_to_be16(CT_ACCEPT_RESPONSE)) {
ql_dbg(ql_dbg_disc + ql_dbg_buffer, vha, 0x2077,
"%s failed rejected request on port_id:
%02x%02x%02x Compeltion status 0x%x, response 0x%x\n",
routine, vha->d_id.b.domain,
vha->d_id.b.area, vha->d_id.b.al_pa,
comp_status, ct_rsp->header.response);
response is BE and isn't printed correctly.
another:
eiter->a.max_frame_size = cpu_to_be32(eiter->a.max_frame_size);
size += 4 + 4;
ql_dbg(ql_dbg_disc, vha, 0x20bc,
"Max_Frame_Size = %x.\n", eiter->a.max_frame_size);
printed too late, it's be by that time.
Here's another suspicious line
ctio24->u.status1.flags = (atio->u.isp24.attr << 9) |
cpu_to_le16(CTIO7_FLAGS_STATUS_MODE_1 |
CTIO7_FLAGS_TERMINATE);
shifting attr by 9 bits gives different results on BE and LE,
mixing it with le16 looks rather strange.
Another:
ha->flags.dport_enabled =
(mid_init_cb->init_cb.firmware_options_1 & BIT_7) != 0;
BIT_7 is native endian, firmware_options_1 is LE I think.
Look at qla27xx_find_valid_image as well.
if (pri_image_status.signature != QLA27XX_IMG_STATUS_SIGN)
qla27xx_image_status seems to be data coming from flash, but is
somehow native-endian? Maybe ...
lun = a->u.isp24.fcp_cmnd.lun;
I think lun here is in hardware format (le?), code treats it
as native.
Not to speak about interface abuse all over the place.
How about this:
uint32_t *
qla24xx_read_flash_data(scsi_qla_host_t *vha, uint32_t *dwptr, uint32_t
faddr,
uint32_t dwords)
{
uint32_t i;
struct qla_hw_data *ha = vha->hw;
/* Dword reads to flash. */
for (i = 0; i < dwords; i++, faddr++)
dwptr[i] = cpu_to_le32(qla24xx_read_flash_dword(ha,
flash_data_addr(ha, faddr)));
return dwptr;
}
OK so we convert to LE ...
qla24xx_read_flash_data(vha, dcode, faddr, 4);
risc_addr = be32_to_cpu(dcode[2]);
*srisc_addr = *srisc_addr == 0 ? risc_addr : *srisc_addr;
risc_size = be32_to_cpu(dcode[3]);
then happily assume it's BE.
And again, coming from flash, it's unlikely to actually be in the native
endian-ness as callers seem to assume. I'm guessing it's all BE.
I poked at it a bit and was able to cut down # of warnings
from 1700 to 1400 in an hour. Someone familiar with the code
should look at it.
--
MST
[PATCH] drm: zte: add overlay plane support
On Thu, Dec 08, 2016 at 11:12:41AM +0800, Shawn Guo wrote:
> +static void zx_vl_plane_atomic_update(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> + struct zx_plane *zplane = to_zx_plane(plane);
> + struct drm_framebuffer *fb = plane->state->fb;
> + struct drm_gem_cma_object *cma_obj;
> + void __iomem *layer = zplane->layer;
> + void __iomem *hbsc = zplane->hbsc;
> + void __iomem *paddr_reg;
> + dma_addr_t paddr;
> + u32 src_x, src_y, src_w, src_h;
> + u32 dst_x, dst_y, dst_w, dst_h;
> + uint32_t format;
> + u32 fmt;
> + int num_planes;
> + int i;
> +
> + if (!fb)
> + return;
> +
> + format = fb->pixel_format;
> +
> + src_x = plane->state->src_x >> 16;
> + src_y = plane->state->src_y >> 16;
> + src_w = plane->state->src_w >> 16;
> + src_h = plane->state->src_h >> 16;
> +
> + dst_x = plane->state->crtc_x;
> + dst_y = plane->state->crtc_y;
> + dst_w = plane->state->crtc_w;
> + dst_h = plane->state->crtc_h;
This shouls use the clipped coordiantes.
> +
> + /* Set up data address registers for Y, Cb and Cr planes */
> + num_planes = drm_format_num_planes(format);
> + paddr_reg = layer + VL_Y;
> + for (i = 0; i < num_planes; i++) {
> + cma_obj = drm_fb_cma_get_gem_obj(fb, i);
> + paddr = cma_obj->paddr + fb->offsets[i];
> + paddr += src_y * fb->pitches[i];
> + paddr += src_x * drm_format_plane_cpp(format, i);
> + zx_writel(paddr_reg, paddr);
> + paddr_reg += 4;
> + }
> +
--
Ville Syrjälä
Intel OTC
[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #43 from Alex Deucher --- firmware is not involved with DCE. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/d9b22fd3/attachment.html>
[PATCH 2/2] ASoC: hdmi-codec: add channel mapping control
Add user interface to provide channel mapping.
In a first step this control is read only.
As TLV type, the control provides all configurations available for
HDMI sink(ELD), and provides current channel mapping selected by codec
based on ELD and number of channels specified by user on open.
When control is called before the number of the channel is specified
(i.e. hw_params is set), it returns all channels set to UNKNOWN.
Notice that SNDRV_CTL_TLVT_CHMAP_FIXED is used for all mappings,
as no information is available from HDMI driver to allow channel swapping.
Signed-off-by: Arnaud Pouliquen
---
sound/soc/codecs/hdmi-codec.c | 346 +-
1 file changed, 345 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index f27d115..0cb83a3 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -18,12 +18,137 @@
#include
#include
#include
+#include
#include
#include
#include
#include /* This is only to get MAX_ELD_BYTES */
+#define HDMI_MAX_SPEAKERS 8
+
+/*
+ * CEA speaker placement for HDMI 1.4:
+ *
+ * FL FLC FC FRC FR FRW
+ *
+ * LFE
+ *
+ * RL RLC RC RRC RR
+ *
+ * Speaker placement has to be extended to support HDMI 2.0
+ */
+enum hdmi_codec_cea_spk_placement {
+ FL = (1 << 0),/* Front Left */
+ FC = (1 << 1),/* Front Center */
+ FR = (1 << 2),/* Front Right */
+ FLC = (1 << 3),/* Front Left Center*/
+ FRC = (1 << 4),/* Front Right Center */
+ RL = (1 << 5),/* Rear Left*/
+ RC = (1 << 6),/* Rear Center */
+ RR = (1 << 7),/* Rear Right */
+ RLC = (1 << 8),/* Rear Left Center */
+ RRC = (1 << 9),/* Rear Right Center*/
+ LFE = (1 << 10),/* Low Frequency Effect */
+};
+
+/*
+ * ELD Speaker allocation bits in the CEA Speaker Allocation data block
+ */
+static int hdmi_codec_eld_spk_alloc_bits[] = {
+ [0] = FL | FR,
+ [1] = LFE,
+ [2] = FC,
+ [3] = RL | RR,
+ [4] = RC,
+ [5] = FLC | FRC,
+ [6] = RLC | RRC,
+};
+
+struct hdmi_codec_channel_map_table {
+ unsigned char map; /* ALSA API channel map position */
+ int spk_mask; /* speaker position bit mask */
+};
+
+static struct hdmi_codec_channel_map_table hdmi_codec_map_table[] = {
+ { SNDRV_CHMAP_FL, FL },
+ { SNDRV_CHMAP_FR, FR },
+ { SNDRV_CHMAP_RL, RL },
+ { SNDRV_CHMAP_RR, RR },
+ { SNDRV_CHMAP_LFE, LFE },
+ { SNDRV_CHMAP_FC, FC },
+ { SNDRV_CHMAP_RLC, RLC },
+ { SNDRV_CHMAP_RRC, RRC },
+ { SNDRV_CHMAP_RC, RC },
+ { SNDRV_CHMAP_FLC, FLC },
+ { SNDRV_CHMAP_FRC, FRC },
+ {} /* terminator */
+};
+
+/*
+ * cea Speaker allocation structure
+ */
+struct hdmi_codec_cea_spk_alloc {
+ int ca_index;
+ int speakers[HDMI_MAX_SPEAKERS];
+
+ /* Derived values, computed during init */
+ int channels;
+ int spk_mask;
+ int spk_na_mask;
+};
+
+/*
+ * This is an ordered list!
+ *
+ * The preceding ones have better chances to be selected by
+ * hdmi_channel_allocation().
+ */
+static struct hdmi_codec_cea_spk_alloc hdmi_codec_channel_alloc[] = {
+/* channel: 7 6543 210 */
+{ .ca_index = 0x00, .speakers = { 0,0, 0, 0, 0,0, FR, FL }
},
+/* 2.1 */
+{ .ca_index = 0x01, .speakers = { 0,0, 0, 0, 0, LFE, FR, FL }
},
+/* Dolby Surround */
+{ .ca_index = 0x02, .speakers = { 0,0, 0, 0, FC,0, FR, FL }
},
+/* surround51 */
+{ .ca_index = 0x0b, .speakers = { 0,0, RR, RL, FC, LFE, FR, FL }
},
+/* surround40 */
+{ .ca_index = 0x08, .speakers = { 0,0, RR, RL, 0,0, FR, FL }
},
+/* surround41 */
+{ .ca_index = 0x09, .speakers = { 0,0, RR, RL, 0, LFE, FR, FL }
},
+/* surround50 */
+{ .ca_index = 0x0a, .speakers = { 0,0, RR, RL, FC,0, FR, FL }
},
+/* 6.1 */
+{ .ca_index = 0x0f, .speakers = { 0, RC, RR, RL, FC, LFE, FR, FL }
},
+/* surround71 */
+{ .ca_index = 0x13, .speakers = { RRC, RLC, RR, RL, FC, LFE, FR, FL }
},
+
+{ .ca_index = 0x03, .speakers = { 0,0, 0, 0, FC, LFE, FR, FL }
},
+{ .ca_index = 0x04, .speakers = { 0,0, 0, RC, 0,0, FR, FL }
},
+{ .ca_index = 0x05, .speakers = { 0,0, 0, RC, 0, LFE, FR, FL }
},
+{ .ca_index = 0x06, .speakers = { 0,
[PATCH 1/2] DRM: add help to get ELD speaker allocation
Add helper to allow users to retrieve the speaker allocations without
knowledge of the ELD structure.
Signed-off-by: Arnaud Pouliquen
---
include/drm/drm_edid.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 919933d..0706cc6 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -245,6 +245,7 @@ struct detailed_timing {
# define DRM_ELD_AUD_SYNCH_DELAY_MAX 0xfa/* 500 ms */
#define DRM_ELD_SPEAKER7
+# define DRM_ELD_SPEAKER_MASK 0x7f
# define DRM_ELD_SPEAKER_RLRC (1 << 6)
# define DRM_ELD_SPEAKER_FLRC (1 << 5)
# define DRM_ELD_SPEAKER_RC(1 << 4)
@@ -412,6 +413,18 @@ static inline int drm_eld_size(const uint8_t *eld)
}
/**
+ * drm_eld_get_spk_alloc - Get speaker allocation
+ * @eld: pointer to an ELD memory structure
+ *
+ * The returned value is the speakers mask. User has to use %DRM_ELD_SPEAKER
+ * field definitions to identify speakers.
+ */
+static inline u8 drm_eld_get_spk_alloc(const uint8_t *eld)
+{
+ return eld[DRM_ELD_SPEAKER] & DRM_ELD_SPEAKER_MASK;
+}
+
+/**
* drm_eld_get_conn_type - Get device type hdmi/dp connected
* @eld: pointer to an ELD memory structure
*
--
1.9.1
[PATCH 0/2] Generic HDMI codec: Add channel mapping control
Aim of this patch is to add 'Playback Channel Map' control to export audio capabilities in term of HDMI sink speakers allocation. This patch follow discussion initiates here: [RFC] ASOC: HDMI audio info frame speaker allocation http://www.spinics.net/lists/alsa-devel/msg57363.html The code is fully inspired from HDA driver. On hw_param, HDMI sink speaker capabilities are exported via TLV ops and a CEA allocation is choson, based on ELD information and the number of channels requested by user. Mains differences with HDA implementation are: - Control is read only - Channel swap is not supported. Consequence is that unused channel in the mid of CEA audio infoframe channel mapping are considered as active. example for channel allocation 0x02: FL, FR, 0, FC) This configuration is only available for a 4 channels stream. - Channel allocation table has been reordered and HDMI 2.0 is not supported. Arnaud Pouliquen (2): DRM: add help to get ELD speaker allocation ASoC: hdmi-codec: add channel mapping control include/drm/drm_edid.h| 13 ++ sound/soc/codecs/hdmi-codec.c | 346 +- 2 files changed, 358 insertions(+), 1 deletion(-) -- 1.9.1
[Bug 99013] [regression, bisected] radeonsi: commit 4c8c13b3 "Use amdgcn intrinsics for fs interpolation" makes system unusable
https://bugs.freedesktop.org/show_bug.cgi?id=99013 --- Comment #9 from Alexandre Demers --- (In reply to Michel Dänzer from comment #7) > (In reply to Christoph Haag from comment #6) > > The build system already uses llvm-config --version which contains the > > revision for svn versions. > > That just prints "4.0.0svn" for me, using the LLVM Git mirror. Same here, so sadly no revision info. However, just to be clear (since I'm unable to test it right now): am I understanding from Christoph's comment that we are allowing the driver to be built against LLVM 3.9? If we rely on features included after the 3.9 release, shouldn't mesa check for 4.0.0svn (at least, beginning from 4c8c13b3)? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/0868c983/attachment.html>
[PATCH v4 1/4] drm: Add a new connector atomic property for link status
On Tue, 06 Dec 2016, Manasi Navare wrote:
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
> spec describes how the link should be reduced, but we can't reduce
> the link below the requirements of the mode. Black screen follows.
>
> One idea would be to have setcrtc return a failure. However, it
> already should not fail as the atomic checks have passed. It would
> also conflict with the idea of making setcrtc asynchronous in the
> future, returning before the actual mode setting and link training.
>
> Another idea is to train the link "upfront" at hotplug time, before
> pruning the mode list, so that we can do the pruning based on
> practical not theoretical capabilities. However, the changes for link
> training are pretty drastic, all for the sake of error handling and
> DP compliance, when the most common happy day scenario is the current
> approach of link training at mode setting time, using the optimal
> parameters for the mode. It is also not certain all hardware could do
> this without the pipe on; not even all our hardware can do this. Some
> of this can be solved, but not trivially.
>
> Both of the above ideas also fail to address link degradation *during*
> operation.
>
> The solution is to add a new "link-status" connector property in order
> to address link training failure in a way that:
> a) changes the current happy day scenario as little as possible, to
> avoid regressions, b) can be implemented the same way by all drm
> drivers, c) is still opt-in for the drivers and userspace, and opting
> out doesn't regress the user experience, d) doesn't prevent drivers
> from implementing better or alternate approaches, possibly without
> userspace involvement. And, of course, handles all the issues presented.
> In the usual happy day scenario, this is always "good". If something
> fails during or after a mode set, the kernel driver can set the link
> status to "bad" and issue a hotplug uevent for userspace to have it
> re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
> again. If the theoretical capabilities of the link can't be reached,
> the mode list is trimmed based on that.
>
> v4:
> * Add comments in kernel-doc format (Daniel Vetter)
> * Update the kernel-doc for link-status (Sean Paul)
> v3:
> * Fixed a build error (Jani Saarinen)
> v2:
> * Removed connector->link_status (Daniel Vetter)
> * Set connector->state->link_status in
> drm_mode_connector_set_link_status_property
> (Daniel Vetter)
> * Set the connector_changed flag to true if connector->state->link_status
> changed.
> * Reset link_status to GOOD in update_output_state (Daniel Vetter)
> * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
>
> Reviewed-by: Sean Paul
> Reviewed-by: Daniel Vetter
> Acked-by: Tony Cheng
> Acked-by: Harry Wentland
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Cc: Chris Wilson
> Cc: Sean Paul
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_atomic.c| 10 +++
> drivers/gpu/drm/drm_atomic_helper.c | 15 +++
> drivers/gpu/drm/drm_connector.c | 53
> +
> include/drm/drm_connector.h | 19 +
> include/drm/drm_mode_config.h | 5
> include/uapi/drm/drm_mode.h | 4 +++
> 6 files changed, 106 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 19d7bcb..70a5152 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,14 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>* now?) atomic writes to DPMS property:
>*/
> return -EINVAL;
> + } else if (property == config->link_status_property) {
> + /* Never downgrade from GOOD to BAD on userspace's request here,
> + * only hw issues can do that.
> + */
> + if (state->link_status == DRM_LINK_STATUS_GOOD)
> + return 0;
Is it conceivable we'd want to support the userspace requesting the
change from GOOD to BAD at a later point in time? If yes, perhaps the
right answer here is to return an error on GOOD->BAD transition, so the
userspace can distinguish between the kernel rejecting vs. accepting the
property set?
BR,
Jani.
> + state->link_status = val;
> + return 0;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -1135,6 +1143,8 @@ static void drm_atomic_connector_print_state(struct
> drm_printer *p,
> *val = (state->crtc) ? state->crtc->base.id : 0;
> } else if (property == config->dpms_property) {
> *va
[pull] radeon and amdgpu drm-next-4.10
Hi Dave, Misc fixes and cleanups for 4.10. Highlights: - Cursor fixes for radeon and amdgpu - DPM fixes for some new SI variants - Powerplay fixes - Clock and powergating fixes The following changes since commit 197aa6ed522cc44710687d3b02dd4e4573991416: Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next (2016-12-06 11:09:21 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.10 for you to fetch changes up to 32859f7335d838ee373c40ee0b3c0c6ebc87a488: drm/amdgpu/dce6: Set MASTER_UPDATE_MODE to 0 in resume_mc_access as well (2016-12-08 14:17:12 -0500) Alex Deucher (7): Revert "drm/amdgpu: use the kernel zone memory size as the max remote memory in amdgpu" drm/amdgpu/gfx8: move eop programming per queue drm/radeon: add additional pci revision to dpm workaround drm/radeon/si: load the proper firmware on 0x87 oland boards drm/amdgpu: add additional pci revision to dpm workaround drm/amdgpu/si: load the proper firmware on 0x87 oland boards drm/amdgpu: use pin rather than pin_restricted in a few cases Alex Xie (1): drm/amd/amdgpu: validate the shadow BO. Arindam Nath (2): drm/amd/amdgpu: enable GUI idle INT after enabling CGCG drm/amd/powerplay: use pr_debug to print function not implemented message Evan Quan (2): drm/amd/amdgpu: stored bios_size drm/amd/amdgpu: export vbios information (v2) Flora Cui (1): drm/amdgpu: fix gtt available page num accounting Hawking Zhang (1): drm/amd/powerplay: bypass fan table setup if no fan connected Huang Rui (1): drm/amdgpu: update golden setting of tonga Maruthi Srinivas Bayyavarapu (1): drm/amdgpu: enable VCE clockgating in Polaris-10/11 Michel Dänzer (7): drm/amdgpu: Store CRTC relative amdgpu_crtc->cursor_x/y values drm/amdgpu: Also call cursor_move_locked when the cursor size changes drm/amdgpu: Only update the CUR_SIZE register when necessary drm/radeon: Also call cursor_move_locked when the cursor size changes drm/radeon: Always store CRTC relative radeon_crtc->cursor_x/y values drm/radeon: Hide the HW cursor while it's out of bounds drm/amdgpu/dce6: Set MASTER_UPDATE_MODE to 0 in resume_mc_access as well Rex Zhu (5): drm/amdgpu: refine uvd 6.0 clock gate feature. drm/amdgpu: fix bug mclk can't change on Polaris drm/amdgpu: fix CI bug uvd status not true in debugfs. drm/amdgpu: no need to ungate uvd/vce clock when fini. drm/amd/powerplay: disable cg pg task when pp uninitialize. Tom St Denis (3): drm/amd/amdgpu: Add debugfs support for reading GPRs (v2) drm/amd/amdgpu: Add gpr reading for GFX v6 drm/amd/amdgpu: Add gpr reading for GFX v7 Xiangliang Yu (8): drm/amd/powerplay: fix firmware loading failure drm/amdgpu: remove error message when loading driver drm/amdgpu: drop redundant vi_mqd define drm/amd/powerplay: cut digest part drm/amd/powerplay: Ignore smu buffer usage drm/amd/powerplay: Adjust the position of data size initial drm/amdgpu: Don't touch GFX hw during HW fini drm/amd/powerplay: Fix potential NULL pointer issue drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 6 + drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 87 - drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 14 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 26 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 12 +- drivers/gpu/drm/amd/amdgpu/ci_dpm.c| 2 +- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 25 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 25 +- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 33 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 27 +- drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 25 ++ drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 25 ++ drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 363 - drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 7 +- drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 7 +- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 7 +- drivers/gpu/drm/amd/amdgpu/si_dpm.c| 2 + drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c | 6 +- drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 115 +-- drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/vi.c| 6 +- drivers/gpu/drm/amd/powerplay/am
[RFC PATCH 0/3] staging: remove fbdev drivers
On Thu, 08 Dec 2016, Geert Uytterhoeven wrote: > On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter wrote: >> If you're this good at mainting gpu and display subsystems, maybe you >> want to take over? > > No please ;-) Now that is indeed the right answer, and the attitude we're looking for! Being able to say "no", especially wrt fbdev drivers, is a must have quality. You're hired! ;D BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[RFC] Using DC in amdgpu for upcoming GPU
On Thu, Dec 08, 2016 at 04:41:52PM +0100, Christian König wrote: > Am 08.12.2016 um 16:34 schrieb Daniel Vetter: > > On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote: > > > Hi Daniel, > > > > > > just a quick clarification in-line about "validation" inside > > > atomic_commit. > > > > > > On 2016-12-08 04:59 AM, Daniel Vetter wrote: > > > > Hi Harry, > > > > > > > > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote: > > > > > We propose to use the Display Core (DC) driver for display support on > > > > > AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In > > > > > order to > > > > > avoid a flag day the plan is to only support uGPU initially and > > > > > transition > > > > > to older ASICs gradually. > > > > > > > > > > The DC component has received extensive testing within AMD for DCE8, > > > > > 10, and > > > > > 11 GPUs and is being prepared for uGPU. Support should be better than > > > > > amdgpu's current display support. > > > > > > > > > > * All of our QA effort is focused on DC > > > > > * All of our CQE effort is focused on DC > > > > > * All of our OEM preloads and custom engagements use DC > > > > > * DC behavior mirrors what we do for other OSes > > > > > > > > > > The new asic utilizes a completely re-designed atom interface, so we > > > > > cannot > > > > > easily leverage much of the existing atom-based code. > > > > > > > > > > We've introduced DC to the community earlier in 2016 and received a > > > > > fair > > > > > amount of feedback. Some of what we've addressed so far are: > > > > > > > > > > * Self-contain ASIC specific code. We did a bunch of work to pull > > > > > common sequences into dc/dce and leave ASIC specific code in > > > > > separate folders. > > > > > * Started to expose AUX and I2C through generic kernel/drm > > > > > functionality and are mostly using that. Some of that code is > > > > > still > > > > > needlessly convoluted. This cleanup is in progress. > > > > > * Integrated Dave and Jeromeâs work on removing abstraction in > > > > > bios > > > > > parser. > > > > > * Retire adapter service and asic capability > > > > > * Remove some abstraction in GPIO > > > > > > > > > > Since a lot of our code is shared with pre- and post-silicon > > > > > validation > > > > > suites changes need to be done gradually to prevent breakages due to > > > > > a major > > > > > flag day. This, coupled with adding support for new asics and lots > > > > > of new > > > > > feature introductions means progress has not been as quick as we > > > > > would have > > > > > liked. We have made a lot of progress none the less. > > > > > > > > > > The remaining concerns that were brought up during the last review > > > > > that we > > > > > are working on addressing: > > > > > > > > > > * Continue to cleanup and reduce the abstractions in DC where it > > > > > makes sense. > > > > > * Removing duplicate code in I2C and AUX as we transition to using > > > > > the > > > > > DRM core interfaces. We can't fully transition until we've helped > > > > > fill in the gaps in the drm core that we need for certain > > > > > features. > > > > > * Making sure Atomic API support is correct. Some of the semantics > > > > > of > > > > > the Atomic API were not particularly clear when we started this, > > > > > however, that is improving a lot as the core drm documentation > > > > > improves. Getting this code upstream and in the hands of more > > > > > atomic users will further help us identify and rectify any gaps we > > > > > have. > > > > > > > > > > Unfortunately we cannot expose code for uGPU yet. However refactor / > > > > > cleanup > > > > > work on DC is public. We're currently transitioning to a public patch > > > > > review. You can follow our progress on the amd-gfx mailing list. We > > > > > value > > > > > community feedback on our work. > > > > > > > > > > As an appendix I've included a brief overview of the how the code > > > > > currently > > > > > works to make understanding and reviewing the code easier. > > > > > > > > > > Prior discussions on DC: > > > > > > > > > > * > > > > > https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html > > > > > * > > > > > https://lists.freedesktop.org/archives/dri-devel/2016-February/100524.html > > > > > > > > > > Current version of DC: > > > > > > > > > > * > > > > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7 > > > > > > > > > > Once Alex pulls in the latest patches: > > > > > > > > > > * > > > > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7 > > > > > > > > > > Best Regards, > > > > > Harry > > > > > > > > > > > > > > > > > > > > *** Appendix: A Day in the Life of a Modeset *** > > > > > ***
[Bug 89534] radeonsi GPU lockup / crash with wine
https://bugs.freedesktop.org/show_bug.cgi?id=89534 --- Comment #33 from John --- WoW! I had given up on this, thank you Marek! And thank you for finding this bug report as well! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/e7923314/attachment.html>
[PATCH 4/6] drm/atomic: Wait for vblank whenever a plane is added to state.
On Thu, Dec 08, 2016 at 02:45:27PM +0100, Maarten Lankhorst wrote:
> The current api doesn't take into account that whenever properties like
> rotation or z-pos change we have to wait for vblank. To make sure
> that we wait correctly, err on the side of caution and wait whenever
> a plane is added to state.
Why do we need to wait when rotation or zpos has changed? I'm a bit lost
... So rotation makes sense since often that means a special, rotated
mapping (or a different offset on omap's TILER as a different example).
But z-pos I have no idad why that matters.
-Daniel
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ccf0bed9bf4a..fdeaea84a3b7 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1123,11 +1123,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> struct drm_crtc_state *new_crtc_state = crtc->state;
>
> - if (!new_crtc_state->active)
> - continue;
> -
> - if (!drm_atomic_helper_framebuffer_changed(dev,
> - old_state, crtc))
> + if (!new_crtc_state->active || !new_crtc_state->planes_changed)
> continue;
>
> ret = drm_crtc_vblank_get(crtc);
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[RFC] Using DC in amdgpu for upcoming GPU
Am 08.12.2016 um 16:34 schrieb Daniel Vetter:
> On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote:
>> Hi Daniel,
>>
>> just a quick clarification in-line about "validation" inside atomic_commit.
>>
>> On 2016-12-08 04:59 AM, Daniel Vetter wrote:
>>> Hi Harry,
>>>
>>> On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
We propose to use the Display Core (DC) driver for display support on
AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order
to
avoid a flag day the plan is to only support uGPU initially and transition
to older ASICs gradually.
The DC component has received extensive testing within AMD for DCE8, 10,
and
11 GPUs and is being prepared for uGPU. Support should be better than
amdgpu's current display support.
* All of our QA effort is focused on DC
* All of our CQE effort is focused on DC
* All of our OEM preloads and custom engagements use DC
* DC behavior mirrors what we do for other OSes
The new asic utilizes a completely re-designed atom interface, so we cannot
easily leverage much of the existing atom-based code.
We've introduced DC to the community earlier in 2016 and received a fair
amount of feedback. Some of what we've addressed so far are:
* Self-contain ASIC specific code. We did a bunch of work to pull
common sequences into dc/dce and leave ASIC specific code in
separate folders.
* Started to expose AUX and I2C through generic kernel/drm
functionality and are mostly using that. Some of that code is still
needlessly convoluted. This cleanup is in progress.
* Integrated Dave and Jeromeâs work on removing abstraction in bios
parser.
* Retire adapter service and asic capability
* Remove some abstraction in GPIO
Since a lot of our code is shared with pre- and post-silicon validation
suites changes need to be done gradually to prevent breakages due to a
major
flag day. This, coupled with adding support for new asics and lots of new
feature introductions means progress has not been as quick as we would have
liked. We have made a lot of progress none the less.
The remaining concerns that were brought up during the last review that we
are working on addressing:
* Continue to cleanup and reduce the abstractions in DC where it
makes sense.
* Removing duplicate code in I2C and AUX as we transition to using the
DRM core interfaces. We can't fully transition until we've helped
fill in the gaps in the drm core that we need for certain features.
* Making sure Atomic API support is correct. Some of the semantics of
the Atomic API were not particularly clear when we started this,
however, that is improving a lot as the core drm documentation
improves. Getting this code upstream and in the hands of more
atomic users will further help us identify and rectify any gaps we
have.
Unfortunately we cannot expose code for uGPU yet. However refactor /
cleanup
work on DC is public. We're currently transitioning to a public patch
review. You can follow our progress on the amd-gfx mailing list. We value
community feedback on our work.
As an appendix I've included a brief overview of the how the code currently
works to make understanding and reviewing the code easier.
Prior discussions on DC:
* https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html
*
https://lists.freedesktop.org/archives/dri-devel/2016-February/100524.html
Current version of DC:
*
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
Once Alex pulls in the latest patches:
*
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
Best Regards,
Harry
*** Appendix: A Day in the Life of a Modeset ***
Below is a high-level overview of a modeset with dc. Some of this might be
a
little out-of-date since it's based on my XDC presentation but it should be
more-or-less the same.
amdgpu_dm_atomic_commit()
{
/* setup atomic state */
drm_atomic_helper_prepare_planes(dev, state);
drm_atomic_helper_swap_state(dev, state);
drm_atomic_helper_update_legacy_modeset_state(dev, state);
/* create or remove targets */
/
* *** Call into DC to commit targets with list of all known targets
**
[Intel-gfx] [PATCH 2/6] drm/atomic: Unconditionally call prepare_fb.
On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote:
> Atomic drivers may set properties like rotation on the same fb, which
> may require a call to prepare_fb even when framebuffer stays identical.
>
> Instead of handling all the special cases in the core, let the driver
> decide when prepare_fb and cleanup_fb are noops.
>
> Signed-off-by: Maarten Lankhorst
I think this makes sense, but would be really good to get a pile of acks
from driver maintainers on this one. Rob, Eric, Laurent, others?
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 23767df72615..d19563651e07 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1664,9 +1664,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
> *dev,
>
> funcs = plane->helper_private;
>
> - if (!drm_atomic_helper_framebuffer_changed(dev, state,
> plane_state->crtc))
> - continue;
> -
> if (funcs->prepare_fb) {
> ret = funcs->prepare_fb(plane, plane_state);
> if (ret)
> @@ -1683,9 +1680,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
> *dev,
> if (j >= i)
> continue;
>
> - if (!drm_atomic_helper_framebuffer_changed(dev, state,
> plane_state->crtc))
> - continue;
> -
> funcs = plane->helper_private;
>
> if (funcs->cleanup_fb)
> @@ -1952,9 +1946,6 @@ void drm_atomic_helper_cleanup_planes(struct drm_device
> *dev,
> for_each_plane_in_state(old_state, plane, plane_state, i) {
> const struct drm_plane_helper_funcs *funcs;
>
> - if (!drm_atomic_helper_framebuffer_changed(dev, old_state,
> plane_state->crtc))
> - continue;
> -
> funcs = plane->helper_private;
>
> if (funcs->cleanup_fb)
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 3/6] drm/atomic: Clean up wait_for_vblanks
On Thu, Dec 08, 2016 at 02:45:26PM +0100, Maarten Lankhorst wrote:
> Stop relying on a per crtc_state last_vblank_count, we know in advance
> how many there can be. Also stop re-using new_crtc_state->enable,
> we can now simply set a bitmask with crtc_crtc_mask.
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 29 +++--
> include/drm/drm_crtc.h | 5 -
> 2 files changed, 15 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index d19563651e07..ccf0bed9bf4a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1110,19 +1110,20 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> struct drm_crtc *crtc;
> struct drm_crtc_state *old_crtc_state;
> int i, ret;
> + unsigned crtc_mask = 0;
> + unsigned last_vblank_count[dev->mode_config.num_crtc];
I think putting last_vblank_count into
drm_atomic_state->crtcs.last_vblank_count would be nice(r). At least I
always freak out when we have dynamically sized arrays on the stack ;-)
> +
> + /*
> + * Legacy cursor ioctls are completely unsynced, and userspace
> + * relies on that (by doing tons of cursor updates).
> + */
> + if (old_state->legacy_cursor_update)
> + return;
>
> for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> - /* No one cares about the old state, so abuse it for tracking
> - * and store whether we hold a vblank reference (and should do a
> - * vblank wait) in the ->enable boolean. */
> - old_crtc_state->enable = false;
> -
> - if (!crtc->state->active)
> - continue;
> + struct drm_crtc_state *new_crtc_state = crtc->state;
>
> - /* Legacy cursor ioctls are completely unsynced, and userspace
> - * relies on that (by doing tons of cursor updates). */
> - if (old_state->legacy_cursor_update)
> + if (!new_crtc_state->active)
> continue;
>
> if (!drm_atomic_helper_framebuffer_changed(dev,
> @@ -1133,16 +1134,16 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> if (ret != 0)
> continue;
if (WARN_ON(ret != 0))
continue;
... is the WARN_ON I meant in patch 1. Would be good to do that too while
we're at it.
-Daniel
>
> - old_crtc_state->enable = true;
> - old_crtc_state->last_vblank_count = drm_crtc_vblank_count(crtc);
> + crtc_mask |= drm_crtc_mask(crtc);
> + last_vblank_count[i] = drm_crtc_vblank_count(crtc);
> }
>
> for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> - if (!old_crtc_state->enable)
> + if (!(crtc_mask & drm_crtc_mask(crtc)))
> continue;
>
> ret = wait_event_timeout(dev->vblank[i].queue,
> - old_crtc_state->last_vblank_count !=
> + last_vblank_count[i] !=
> drm_crtc_vblank_count(crtc),
> msecs_to_jiffies(50));
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 946672f97e1e..e03d194be086 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -93,8 +93,6 @@ struct drm_plane_helper_funcs;
> * @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached planes
> * @connector_mask: bitmask of (1 << drm_connector_index(connector)) of
> attached connectors
> * @encoder_mask: bitmask of (1 << drm_encoder_index(encoder)) of attached
> encoders
> - * @last_vblank_count: for helpers and drivers to capture the vblank of the
> - * update to ensure framebuffer cleanup isn't done too early
> * @adjusted_mode: for use by helpers and drivers to compute adjusted mode
> timings
> * @mode: current mode timings
> * @mode_blob: &drm_property_blob for @mode
> @@ -140,9 +138,6 @@ struct drm_crtc_state {
> u32 connector_mask;
> u32 encoder_mask;
>
> - /* last_vblank_count: for vblank waits before cleanup */
> - u32 last_vblank_count;
> -
> /* adjusted_mode: for use by helpers and drivers */
> struct drm_display_mode adjusted_mode;
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] [PATCH 1/6] drm/atomic: Use active instead of enable in wait_for_vblanks.
On Thu, Dec 08, 2016 at 02:45:24PM +0100, Maarten Lankhorst wrote: > When DPMS was introduced to atomic, vblanks only worked when the crtc > was enabled and active. wait_for_vblanks were not converted to check for > crtc_state->active, which may cause an attempt for vblank_get to fail. > > This is probably harmless, but convert from enable to active anyway. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/drm_atomic_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 583f47f27b36..23767df72615 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1117,7 +1117,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device > *dev, >* vblank wait) in the ->enable boolean. */ > old_crtc_state->enable = false; > > - if (!crtc->state->enable) > + if (!crtc->state->active) Hm, with this change we /should/ be able to make the drm_crtc_vblank_get call a few lines below WARN when it fails. Not doing that was only done at first because there was no accurate active state tracking for the CRTC, and since the vblank state should match active I've used that. Care for that follow-up patch? Applied this one here meanwhile. -Daniel > continue; > > /* Legacy cursor ioctls are completely unsynced, and userspace > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video
https://bugs.freedesktop.org/show_bug.cgi?id=98914 --- Comment #10 from Jörg-Volker Peetz --- Please, go ahead and commit the patch. I think there might be many computers which could and do use this hardware acceleration. The mpeg2video codec applies to DVD's for example. Although IMO, the choice of vdpau hardware support (also for AMD GPUs) by installing the right package (mesa-vdpau-drivers on debian) and the configuration of mpc or vlc is not obvious. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/ab0dd888/attachment.html>
[RFC] Using DC in amdgpu for upcoming GPU
On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote:
> Hi Daniel,
>
> just a quick clarification in-line about "validation" inside atomic_commit.
>
> On 2016-12-08 04:59 AM, Daniel Vetter wrote:
> > Hi Harry,
> >
> > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> > > We propose to use the Display Core (DC) driver for display support on
> > > AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order
> > > to
> > > avoid a flag day the plan is to only support uGPU initially and transition
> > > to older ASICs gradually.
> > >
> > > The DC component has received extensive testing within AMD for DCE8, 10,
> > > and
> > > 11 GPUs and is being prepared for uGPU. Support should be better than
> > > amdgpu's current display support.
> > >
> > > * All of our QA effort is focused on DC
> > > * All of our CQE effort is focused on DC
> > > * All of our OEM preloads and custom engagements use DC
> > > * DC behavior mirrors what we do for other OSes
> > >
> > > The new asic utilizes a completely re-designed atom interface, so we
> > > cannot
> > > easily leverage much of the existing atom-based code.
> > >
> > > We've introduced DC to the community earlier in 2016 and received a fair
> > > amount of feedback. Some of what we've addressed so far are:
> > >
> > > * Self-contain ASIC specific code. We did a bunch of work to pull
> > >common sequences into dc/dce and leave ASIC specific code in
> > >separate folders.
> > > * Started to expose AUX and I2C through generic kernel/drm
> > >functionality and are mostly using that. Some of that code is still
> > >needlessly convoluted. This cleanup is in progress.
> > > * Integrated Dave and Jeromeâs work on removing abstraction in bios
> > >parser.
> > > * Retire adapter service and asic capability
> > > * Remove some abstraction in GPIO
> > >
> > > Since a lot of our code is shared with pre- and post-silicon validation
> > > suites changes need to be done gradually to prevent breakages due to a
> > > major
> > > flag day. This, coupled with adding support for new asics and lots of new
> > > feature introductions means progress has not been as quick as we would
> > > have
> > > liked. We have made a lot of progress none the less.
> > >
> > > The remaining concerns that were brought up during the last review that we
> > > are working on addressing:
> > >
> > > * Continue to cleanup and reduce the abstractions in DC where it
> > >makes sense.
> > > * Removing duplicate code in I2C and AUX as we transition to using the
> > >DRM core interfaces. We can't fully transition until we've helped
> > >fill in the gaps in the drm core that we need for certain features.
> > > * Making sure Atomic API support is correct. Some of the semantics of
> > >the Atomic API were not particularly clear when we started this,
> > >however, that is improving a lot as the core drm documentation
> > >improves. Getting this code upstream and in the hands of more
> > >atomic users will further help us identify and rectify any gaps we
> > >have.
> > >
> > > Unfortunately we cannot expose code for uGPU yet. However refactor /
> > > cleanup
> > > work on DC is public. We're currently transitioning to a public patch
> > > review. You can follow our progress on the amd-gfx mailing list. We value
> > > community feedback on our work.
> > >
> > > As an appendix I've included a brief overview of the how the code
> > > currently
> > > works to make understanding and reviewing the code easier.
> > >
> > > Prior discussions on DC:
> > >
> > > * https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html
> > > *
> > > https://lists.freedesktop.org/archives/dri-devel/2016-February/100524.html
> > >
> > > Current version of DC:
> > >
> > > *
> > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> > >
> > > Once Alex pulls in the latest patches:
> > >
> > > *
> > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> > >
> > > Best Regards,
> > > Harry
> > >
> > >
> > >
> > > *** Appendix: A Day in the Life of a Modeset ***
> > >
> > >
> > > Below is a high-level overview of a modeset with dc. Some of this might
> > > be a
> > > little out-of-date since it's based on my XDC presentation but it should
> > > be
> > > more-or-less the same.
> > >
> > > amdgpu_dm_atomic_commit()
> > > {
> > > /* setup atomic state */
> > > drm_atomic_helper_prepare_planes(dev, state);
> > > drm_atomic_helper_swap_state(dev, state);
> > > drm_atomic_helper_update_legacy_modeset_state(dev, state);
> > >
> > > /* create or remove targets */
> > >
> > > /
> > >* *** Call into DC to commit targets with list of all know
[Bug 97166] lockup during gameplay of Batman series of games
https://bugs.freedesktop.org/show_bug.cgi?id=97166 Marek Olšák changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Marek Olšák --- GPU hangs in Batman Arkham: Origins were fixed by this commit: https://cgit.freedesktop.org/mesa/mesa/commit/?id=6dc96de303290e8d1fc294da478c4f370be98dea Closing. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/85522ad9/attachment.html>
[Bug 89534] radeonsi GPU lockup / crash with wine
https://bugs.freedesktop.org/show_bug.cgi?id=89534 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #32 from Marek Olšák --- GPU hangs in Batman Arkham: Origins were fixed by this commit: https://cgit.freedesktop.org/mesa/mesa/commit/?id=6dc96de303290e8d1fc294da478c4f370be98dea Closing. You can create a new bug for hangs in other apps or search existing bugs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/cbe29737/attachment-0001.html>
[Intel-gfx] [PATCH v4 1/4] drm: Add a new connector atomic property for link status
On Thu, Dec 08, 2016 at 05:05:54PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > At the time userspace does setcrtc, we've already promised the mode
> > would work. The promise is based on the theoretical capabilities of
> > the link, but it's possible we can't reach this in practice. The DP
> > spec describes how the link should be reduced, but we can't reduce
> > the link below the requirements of the mode. Black screen follows.
> >
> > One idea would be to have setcrtc return a failure. However, it
> > already should not fail as the atomic checks have passed. It would
> > also conflict with the idea of making setcrtc asynchronous in the
> > future, returning before the actual mode setting and link training.
> >
> > Another idea is to train the link "upfront" at hotplug time, before
> > pruning the mode list, so that we can do the pruning based on
> > practical not theoretical capabilities. However, the changes for link
> > training are pretty drastic, all for the sake of error handling and
> > DP compliance, when the most common happy day scenario is the current
> > approach of link training at mode setting time, using the optimal
> > parameters for the mode. It is also not certain all hardware could do
> > this without the pipe on; not even all our hardware can do this. Some
> > of this can be solved, but not trivially.
> >
> > Both of the above ideas also fail to address link degradation *during*
> > operation.
> >
> > The solution is to add a new "link-status" connector property in order
> > to address link training failure in a way that:
> > a) changes the current happy day scenario as little as possible, to
> > avoid regressions, b) can be implemented the same way by all drm
> > drivers, c) is still opt-in for the drivers and userspace, and opting
> > out doesn't regress the user experience, d) doesn't prevent drivers
> > from implementing better or alternate approaches, possibly without
> > userspace involvement. And, of course, handles all the issues presented.
> > In the usual happy day scenario, this is always "good". If something
> > fails during or after a mode set, the kernel driver can set the link
> > status to "bad" and issue a hotplug uevent for userspace to have it
> > re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
> > again. If the theoretical capabilities of the link can't be reached,
> > the mode list is trimmed based on that.
> >
> > v4:
> > * Add comments in kernel-doc format (Daniel Vetter)
> > * Update the kernel-doc for link-status (Sean Paul)
> > v3:
> > * Fixed a build error (Jani Saarinen)
> > v2:
> > * Removed connector->link_status (Daniel Vetter)
> > * Set connector->state->link_status in
> > drm_mode_connector_set_link_status_property
> > (Daniel Vetter)
> > * Set the connector_changed flag to true if connector->state->link_status
> > changed.
> > * Reset link_status to GOOD in update_output_state (Daniel Vetter)
> > * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
> >
> > Reviewed-by: Sean Paul
> > Reviewed-by: Daniel Vetter
> > Acked-by: Tony Cheng
> > Acked-by: Harry Wentland
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Cc: Ville Syrjala
> > Cc: Chris Wilson
> > Cc: Sean Paul
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/drm_atomic.c| 10 +++
> > drivers/gpu/drm/drm_atomic_helper.c | 15 +++
> > drivers/gpu/drm/drm_connector.c | 53
> > +
> > include/drm/drm_connector.h | 19 +
> > include/drm/drm_mode_config.h | 5
> > include/uapi/drm/drm_mode.h | 4 +++
> > 6 files changed, 106 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 19d7bcb..70a5152 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1087,6 +1087,14 @@ int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> > * now?) atomic writes to DPMS property:
> > */
> > return -EINVAL;
> > + } else if (property == config->link_status_property) {
> > + /* Never downgrade from GOOD to BAD on userspace's request here,
> > +* only hw issues can do that.
> > +*/
> > + if (state->link_status == DRM_LINK_STATUS_GOOD)
> > + return 0;
>
> Is it conceivable we'd want to support the userspace requesting the
> change from GOOD to BAD at a later point in time? If yes, perhaps the
> right answer here is to return an error on GOOD->BAD transition, so the
> userspace can distinguish between the kernel rejecting vs. accepting the
> property set?
One of the design ideas behind atomic is that userspace doesn't need to be
able to understand all properties, but still needs to be able to restore
the state it wants on VT switch. Or as a "pls reset my display to boot-up
state because my compositor made a mess of it
[RFC PATCH 0/3] staging: remove fbdev drivers
[back from my walk, the sunset here is stellar ;-)] On Thu, Dec 08, 2016 at 03:44:30PM +0100, Geert Uytterhoeven wrote: > Hi Thomas, > > On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni > wrote: > > On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote: > >> > Wut. We have like 20+ small atomic drivers nowdays. > >> > >> That's fast! Only two weeks ago you said: > >> > >> | Bummer, they still haven't landed. But afaik there's at least 4 of > >> | them floating around in various places ... > > > > You're not talking about the same thing I believe. > > > > When Daniel says "small atomic drivers", he talks about the relatively > > small DRM drivers for SoC display controllers, such as the ones you can > > find in ARM SoCs. > > > > When you say "small driver", you're thinking about drivers for I2C or > > SPI connected displays. > > No, I wasn't thinking about I2C or SPI connected displays, but about simple > dumb memory-mapped frame buffers, which is what fbdev was initially > developed for. Yeah, small drivers like these we have piles now, things exploded a lot after atomic landed two years ago. And they seem to shrink with every release a bit more (since lots more drivers gives you lots more insight into what other refactorings would make sense). Those we have a big pile of, and nowadays (at least with developers expirienced with upstream, but not necessarily with drm) it takes but a few weeks from initial submission to getting them merged. What we don't yet have a nice tidy example driver of is the even simpler "dumb framebuffer behind a slow bus with explicit/manual upload", for like small i2c/spi panels (and conceptually also usb, even though there bw and panel size are a bit scaled up). We've gained some really nice helpers for this this year, and there's 3 drivers in-flight to make use of it. But since that's right now just a hobbyist effort it's moving a bit slower (and I was mistaken a few weeks back where I assumed that one of them landed already). Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #147 from Marek Olšák --- Possible fix: https://cgit.freedesktop.org/mesa/mesa/commit/?id=6dc96de303290e8d1fc294da478c4f370be98dea -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/d6c92ded/attachment.html>
[RFC PATCH 0/3] staging: remove fbdev drivers
Hi Thomas,
On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
wrote:
> On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
>> > Wut. We have like 20+ small atomic drivers nowdays.
>>
>> That's fast! Only two weeks ago you said:
>>
>> | Bummer, they still haven't landed. But afaik there's at least 4 of
>> | them floating around in various places ...
>
> You're not talking about the same thing I believe.
>
> When Daniel says "small atomic drivers", he talks about the relatively
> small DRM drivers for SoC display controllers, such as the ones you can
> find in ARM SoCs.
>
> When you say "small driver", you're thinking about drivers for I2C or
> SPI connected displays.
No, I wasn't thinking about I2C or SPI connected displays, but about simple
dumb memory-mapped frame buffers, which is what fbdev was initially
developed for.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[RFC PATCH 0/3] staging: remove fbdev drivers
Hello, On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote: > > Wut. We have like 20+ small atomic drivers nowdays. > > That's fast! Only two weeks ago you said: > > | Bummer, they still haven't landed. But afaik there's at least 4 of > | them floating around in various places ... You're not talking about the same thing I believe. When Daniel says "small atomic drivers", he talks about the relatively small DRM drivers for SoC display controllers, such as the ones you can find in ARM SoCs. When you say "small driver", you're thinking about drivers for I2C or SPI connected displays. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video
https://bugs.freedesktop.org/show_bug.cgi?id=98914 --- Comment #9 from Christian König --- Yeah, the problem is on line 155 in that file. Here "i" is used as signed and the calculation result can be negative. Brave enough to create a patch for this or should I do that? Thanks for the help and it's nice to know that this is still used. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/38c086e4/attachment.html>
[PATCH v2 2/2] drm/panel: simple: Add support BOE nv101wxmn51
10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.
Read the panel edid information;
EDID MODE DETAILS
name =
pixel_clock = 71900
lvds_dual_channel = 0
refresh = 0
ha = 1280
hbl = 160
hso = 48
hspw = 32
hborder = 0
va = 800
vbl = 32
vso = 3
vspw = 5
vborder = 0
phsync = +
pvsync = -
x_mm = 0
y_mm = 0
drm_display_mode
.hdisplay = 1280
.hsync_start = 1328
.hsync_end = 1360
.htotal = 1440
.vdisplay = 800
.vsync_start = 803
.vsync_end = 808
.vtotal = 832
Signed-off-by: Caesar Wang
---
Changes in v2:
- fix the vsync_start and vsync_end from the edid.
- change the commit.
drivers/gpu/drm/panel/panel-simple.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..7c90f16 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode boe_nv101wxmn51_mode = {
+ .clock = 71900,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 48,
+ .hsync_end = 1280 + 48 + 32,
+ .htotal = 1280 + 48 + 32 + 80,
+ .vdisplay = 800,
+ .vsync_start = 800 + 3,
+ .vsync_end = 800 + 3 + 5,
+ .vtotal = 800 + 3 + 5 + 24,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+ .modes = &boe_nv101wxmn51_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .delay = {
+ .prepare = 210,
+ .enable = 50,
+ .unprepare = 160,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
}, {
+ .compatible = "boe,nv101wxmn51",
+ .data = &boe_nv101wxmn51,
+ }, {
.compatible = "chunghwa,claa070wp03xg",
.data = &chunghwa_claa070wp03xg,
}, {
--
2.7.4
[PATCH v2 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding
The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. Signed-off-by: Caesar Wang --- Changes in v2: None .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt diff --git a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt new file mode 100644 index 000..b258d6a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt @@ -0,0 +1,7 @@ +BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "boe,nv101wxmn51" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.7.4
[RFC PATCH 0/3] staging: remove fbdev drivers
Dear dri-devel folks, My sincere apologies for hitting send on that mail. I got real mad and angry and typed a mail I shouldn't have submitted - pouring oil into flames for shit and giggles just doesn't help anyone, and it detracts from moving things forward and improving the code and drivers and everything in a friendly and constructive fashion. I want to be part of a great community, this wasnt :( /me out and off for a walk Thanks, Daniel On Thu, Dec 08, 2016 at 03:02:10PM +0100, Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote: > > On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter wrote: > > > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote: > > >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > > >> > Since the fbdev framework is in maintenance mode and all new display > > >> > drivers > > >> > should be made with the DRM framework, remove the fbdev drivers from > > >> > staging. > > >> > > > >> > Note: the patches are created with git format-patch -D, so they can't > > >> > be > > >> > applied. Only for review. > > >> > > >> I missed the discussion where this decision was made, I admit I am > > >> unimpressed by it. > > >> > > >> DRM drivers don't strike me as suitable for small/slow cores with dumb > > >> framebuffers or simple 2D only accel, such as the one found in the ASpeed > > >> BMCs. > > > > > > We have a helper for simple drivers now, if you take into account the > > > massive helper libraries for everything that comes along with drm I expect > > > if even dumb panels behind slow spi buses drm is now the more suitable > > > subsytem. > > > > This has been going on your years: > > 1. Fbdev is obsolete, everybody should use DRM instead! > > 2. Can you please point me to a small sample driver for a dumb frame > > buffer? > > 3. Several are being written, but none of them is upstream yet. > > 4. Goto 1. > > Wut. We have like 20+ small atomic drivers nowdays. > > > >> With drmfb you basically have to shadow everything into memory & copy > > >> over everything, and locks you out of simple 2D accel. For a simple text > > >> console the result is orders of magnitude slower and memory hungry than > > >> a simple fbdev. > > > > > > Not true, we have full fbdev emulation, and drivers can implement the 2d > > > accel in there. And a bunch of them do. It's just that most teams decided > > > that this is pointless waste of their time.j > > > > > >> At least that was the case last I looked at the DRM stuff with Dave, > > >> maybe things have changed... > > >> > > >> Not everything has a powerful 3D GPU. > > > > > > That's correct, and drm can cope. And compared to fbdev there's a very > > > active community who improves&refactors it every kernel release to make it > > > even better. Since about 2 years (when atomic landed) we merge new > > > drivers at > > > a rate of 2-3 per kernel release, and those new drivers get ever simpler > > > and smaller thanks to all this work. > > > > You mean the kind of refactoring that causes severe merge conflicts between > > drm-next and Linus' tree about every single day? > > (sorry, couldn't resist ;-) > > Yeah, for a subsystem that only consists of 10% of the overall kernel (by > patch count) we do an extremly shitty job. Maybe we should just all slow > down and stop merging support for new hw, and fuck Android and CrOS and > the billions of devices that don't ship upstream, who cares about those > folks. > > If you're this good at mainting gpu and display subsystems, maybe you want > to take over? > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[RFC PATCH 0/3] staging: remove fbdev drivers
Hi Daniel,
On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
>> On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter wrote:
>> > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
>> >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
>> >> > Since the fbdev framework is in maintenance mode and all new display
>> >> > drivers
>> >> > should be made with the DRM framework, remove the fbdev drivers from
>> >> > staging.
>> >> >
>> >> > Note: the patches are created with git format-patch -D, so they can't be
>> >> > applied. Only for review.
>> >>
>> >> I missed the discussion where this decision was made, I admit I am
>> >> unimpressed by it.
>> >>
>> >> DRM drivers don't strike me as suitable for small/slow cores with dumb
>> >> framebuffers or simple 2D only accel, such as the one found in the ASpeed
>> >> BMCs.
>> >
>> > We have a helper for simple drivers now, if you take into account the
>> > massive helper libraries for everything that comes along with drm I expect
>> > if even dumb panels behind slow spi buses drm is now the more suitable
>> > subsytem.
>>
>> This has been going on your years:
>> 1. Fbdev is obsolete, everybody should use DRM instead!
>> 2. Can you please point me to a small sample driver for a dumb frame
>> buffer?
>> 3. Several are being written, but none of them is upstream yet.
>> 4. Goto 1.
>
> Wut. We have like 20+ small atomic drivers nowdays.
That's fast! Only two weeks ago you said:
| Bummer, they still haven't landed. But afaik there's at least 4 of
| them floating around in various places ...
>> > That's correct, and drm can cope. And compared to fbdev there's a very
>> > active community who improves&refactors it every kernel release to make it
>> > even better. Since about 2 years (when atomic landed) we merge new drivers
>> > at
>> > a rate of 2-3 per kernel release, and those new drivers get ever simpler
>> > and smaller thanks to all this work.
>>
>> You mean the kind of refactoring that causes severe merge conflicts between
>> drm-next and Linus' tree about every single day?
>> (sorry, couldn't resist ;-)
>
> Yeah, for a subsystem that only consists of 10% of the overall kernel (by
> patch count) we do an extremly shitty job. Maybe we should just all slow
> down and stop merging support for new hw, and fuck Android and CrOS and
> the billions of devices that don't ship upstream, who cares about those
> folks.
My apologies. In hindsight, my comment sounded much more insulting than it
was meant to be.
> If you're this good at mainting gpu and display subsystems, maybe you want
> to take over?
No please ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[Intel-gfx] [PATCH] drm: Take ownership of the dmabuf->obj when exporting
On Thu, Dec 08, 2016 at 03:03:29PM +0200, Joonas Lahtinen wrote: > On ke, 2016-12-07 at 21:45 +, Chris Wilson wrote: > > Currently the reference for the dmabuf->obj is incremented for the > > dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace > > interface), but is released in drm_gem_dmabuf_release() (the lowlevel > > handler). Improve the symmetry of the dmabuf->obj ownership by acquiring > > the reference in drm_gem_dmabuf_export(). This makes it easier to use > > the prime functions directly. > > > > Signed-off-by: Chris Wilson > > Reviewed-by: Joonas Lahtinen Sorry forgot to reply here that I merged this, after some discussion with Chris on irc to make sure the kerneldoc is updated. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[RFC v2] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*
On Thu, Dec 08, 2016 at 11:57:25AM +, Robert Bragg wrote: > On Thu, Dec 8, 2016 at 12:17 AM, Daniel Vetter wrote: > > > > On Wed, Dec 07, 2016 at 06:35:29PM +, Robert Bragg wrote: > > > This is still missing corresponding documentation changes, and I haven't > > > moved anything to drm_print.h yet, as suggested. > > > > > > Sending out with a few functional improvements first to get agreement > > > before documenting anything (changes summarised in v2: section below) > > > > > > In particular, affecting the output format, I stole an idea from Tvrtko > > > Ursulin to have the prefix for messages be based on the driver name, > > > such as "[i915]" instead of always being "[drm]". > > > > > > Depending on peoples thoughts on compatibility, we could consider > > > removing the prefix given that the dynamic debug control interface has a > > > way of specifying that messages should include a module name, function > > > or line info like: > > > > > > echo "module i915 +mfp" > dynamic_debug/control > > > > > > That would enable all i915 debug messages with a module and function > > > prefix. > > > > > > A trade-off would be that anyone only using the drm.drm_debug interface > > > to control messages would loose some information. If we really wanted we > > > could have the best of both by adding a utility printing api that can > > > recognise when printing due to a dynamic debug control query vs > > > drm.drm_debug to conditionally add the prefix. > > > > > > --- >8 --- (git am --scissors) > > > > > > Dynamic debug messages (ref: Documentation/dynamic-debug-howto.txt) > > > allow fine grained control over which debug messages are enabled with > > > runtime control through /sysfs/kernel/debug/dynamic_debug/control > > > > > > This provides more control than the current drm.drm_debug parameter > > > which for some use cases is impractical to use given how chatty > > > some drm debug categories are. > > > > > > For example all debug messages in i915_drm.c can be enabled with: > > > echo "file i915_perf.c +p" > dynamic_debug/control > > > > > > This doesn't strictly maintain format compatibility with the previous > > > debug messages since the category is now added as part of the prefix > > > like "[drm][kms] No FB found". Adding the categories with a consistent > > > format makes it possible to enable categories with a dynamic debug > > > query like: echo "format [kms] +p" > dynamic_debug/control > > > > > > This maintains support for enabling debug messages using the drm_debug > > > parameter. If dynamic debug is not enabled via CONFIG_DYNAMIC_DEBUG the > > > debug messages essentially work as before, except with the inclusion of > > > categories in the format strings as described above. > > > > > > This removes the drm_[dev_]printk wrappers considering that the dynamic > > > debug macros are only useful if they can track the __FILE__, __func__ > > > and __LINE__ where they are called. The wrapper didn't seem necessary in > > > the DRM_UT_NONE case with no category flag. > > > > > > The non _DEV macros are no longer defined in terms of passing NULL to a > > > _DEV variant to avoid have the core.c dev_printk implementation adding > > > "(NULL device *)". The previous drm_[dev_]prink function used to handle > > > this as a special case. > > > > > > Instead of using DRM_NAME to add [drm] to the start of every message, > > > the prefix is now based on module_name(THIS_MODULE) so it will be [drm] > > > or e.g. [i915] for the Intel driver. Later we might consider removing > > > the prefix altogether considering that the dynamic debug control > > > interface has a way of optionally adding the module, function or line to > > > the formatting of messages. > > > > > > v2: > > > Add categories to format like "[drm][kms] No FB found" > > > Only single conditional call per message (macros expand to less code) > > > Uses __dynamic_pr_debug/dev_dbg for dynamic formatting features > > > Use module name for msg prefix like [drm] or [i915] > > > > > > Signed-off-by: Robert Bragg > > > Cc: dri-devel at lists.freedesktop.org > > > Cc: Daniel Vetter > > > Cc: Tvrtko Ursulin > > > > So assuming I understand it correctly - I like this 3way cascade of > > dynamic debug, then printk and no_printk fallback if CONFIG_DEBUG=n for > > the space concious. But I guess we do need to add a DRM Kconfig knob to > > set DEBUG, at least I'm not entirely sure how that's supposed to work. Or > > we might need to have our own #ifdef maze for this. Maybe we need to keep > > the old drm*printk stuff for that? > > Right, I wasn't really sure who/what's responsible for defining DEBUG. > > I just found this convention documented in Documentation/CodingStyle: > > > Coming up with good debugging messages can be quite a challenge; and once > > you have them, they can be a huge help for remote troubleshooting. However > > debug message printing is handled differently than printing other non-debug > > messages. While the other pr_XXX
[Intel-gfx] [PATCH] drm: Take ownership of the dmabuf->obj when exporting
On ke, 2016-12-07 at 21:45 +, Chris Wilson wrote: > Currently the reference for the dmabuf->obj is incremented for the > dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace > interface), but is released in drm_gem_dmabuf_release() (the lowlevel > handler). Improve the symmetry of the dmabuf->obj ownership by acquiring > the reference in drm_gem_dmabuf_export(). This makes it easier to use > the prime functions directly. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation
[RFC PATCH 0/3] staging: remove fbdev drivers
On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote: > On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter wrote: > > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote: > >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > >> > Since the fbdev framework is in maintenance mode and all new display > >> > drivers > >> > should be made with the DRM framework, remove the fbdev drivers from > >> > staging. > >> > > >> > Note: the patches are created with git format-patch -D, so they can't be > >> > applied. Only for review. > >> > >> I missed the discussion where this decision was made, I admit I am > >> unimpressed by it. > >> > >> DRM drivers don't strike me as suitable for small/slow cores with dumb > >> framebuffers or simple 2D only accel, such as the one found in the ASpeed > >> BMCs. > > > > We have a helper for simple drivers now, if you take into account the > > massive helper libraries for everything that comes along with drm I expect > > if even dumb panels behind slow spi buses drm is now the more suitable > > subsytem. > > This has been going on your years: > 1. Fbdev is obsolete, everybody should use DRM instead! > 2. Can you please point me to a small sample driver for a dumb frame buffer? > 3. Several are being written, but none of them is upstream yet. > 4. Goto 1. Wut. We have like 20+ small atomic drivers nowdays. > >> With drmfb you basically have to shadow everything into memory & copy > >> over everything, and locks you out of simple 2D accel. For a simple text > >> console the result is orders of magnitude slower and memory hungry than > >> a simple fbdev. > > > > Not true, we have full fbdev emulation, and drivers can implement the 2d > > accel in there. And a bunch of them do. It's just that most teams decided > > that this is pointless waste of their time.j > > > >> At least that was the case last I looked at the DRM stuff with Dave, > >> maybe things have changed... > >> > >> Not everything has a powerful 3D GPU. > > > > That's correct, and drm can cope. And compared to fbdev there's a very > > active community who improves&refactors it every kernel release to make it > > even better. Since about 2 years (when atomic landed) we merge new drivers > > at > > a rate of 2-3 per kernel release, and those new drivers get ever simpler > > and smaller thanks to all this work. > > You mean the kind of refactoring that causes severe merge conflicts between > drm-next and Linus' tree about every single day? > (sorry, couldn't resist ;-) Yeah, for a subsystem that only consists of 10% of the overall kernel (by patch count) we do an extremly shitty job. Maybe we should just all slow down and stop merging support for new hw, and fuck Android and CrOS and the billions of devices that don't ship upstream, who cares about those folks. If you're this good at mainting gpu and display subsystems, maybe you want to take over? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 99029] VCE VAAPI segfault using ffmpeg
https://bugs.freedesktop.org/show_bug.cgi?id=99029 --- Comment #1 from Martin Bednar --- Also dmesg |grep VCE: [drm] Found VCE firmware/feedback version 50.0.1 / 17! [drm] VCE initialized successfully. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/78b48604/attachment.html>
[PATCH] drm/panel: simple: specify bus width and flags for EDT displays
The display has a 18-Bit parallel LCD interface, require DE to be
active high and data driven by the controller on falling pixel
clock edge (display samples on rising edge).
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/panel/panel-simple.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 113db3c..02915b4 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -651,6 +651,8 @@ static const struct panel_desc edt_et057090dhu = {
.width = 115,
.height = 86,
},
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
};
static const struct drm_display_mode edt_etm0700g0dh6_mode = {
@@ -675,6 +677,8 @@ static const struct panel_desc edt_etm0700g0dh6 = {
.width = 152,
.height = 91,
},
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
};
static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = {
--
2.10.2
[PATCH] drm/mxsfb: use bus_format to determine LCD bus width
The LCD bus width does not need to align with the pixel format. The
LCDIF controller automatically converts between pixel formats and
bus width by padding or dropping LSBs.
The DRM subsystem has the notion of bus_format which allows to
determine what bus_formats are supported by the display. Choose the
first available or fallback to 24 bit if none are available.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 28 +---
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 1 +
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 4bcc8a3..00fa244 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -65,13 +65,11 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
*mxsfb)
switch (format) {
case DRM_FORMAT_RGB565:
dev_dbg(drm->dev, "Setting up RGB565 mode\n");
- ctrl |= CTRL_SET_BUS_WIDTH(STMLCDIF_16BIT);
ctrl |= CTRL_SET_WORD_LENGTH(0);
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
break;
case DRM_FORMAT_XRGB:
dev_dbg(drm->dev, "Setting up XRGB mode\n");
- ctrl |= CTRL_SET_BUS_WIDTH(STMLCDIF_24BIT);
ctrl |= CTRL_SET_WORD_LENGTH(3);
/* Do not use packed pixels = one pixel per word instead. */
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
@@ -89,6 +87,9 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
*mxsfb)
static void mxsfb_enable_controller(struct mxsfb_drm_private *mxsfb)
{
+ struct drm_crtc *crtc = &mxsfb->pipe.crtc;
+ struct drm_device *drm = crtc->dev;
+ u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
u32 reg;
if (mxsfb->clk_disp_axi)
@@ -97,7 +98,28 @@ static void mxsfb_enable_controller(struct mxsfb_drm_private
*mxsfb)
mxsfb_enable_axi_clk(mxsfb);
/* If it was disabled, re-enable the mode again */
- writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
+ reg = readl(mxsfb->base + LCDC_CTRL);
+ reg |= CTRL_DOTCLK_MODE;
+
+ if (mxsfb->connector.display_info.num_bus_formats)
+ bus_format = mxsfb->connector.display_info.bus_formats[0];
+
+ reg &= ~CTRL_BUS_WIDTH_MASK;
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_16BIT);
+ break;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_18BIT);
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_24BIT);
+ break;
+ default:
+ dev_err(drm->dev, "Unknown media bus format %d\n", bus_format);
+ break;
+ }
+ writel(reg, mxsfb->base + LCDC_CTRL);
/* Enable the SYNC signals first, then the DMA engine */
reg = readl(mxsfb->base + LCDC_VDCTRL4);
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_regs.h
b/drivers/gpu/drm/mxsfb/mxsfb_regs.h
index 31d62cd..66a6ba9 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_regs.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_regs.h
@@ -44,6 +44,7 @@
#define CTRL_DATA_SELECT (1 << 16)
#define CTRL_SET_BUS_WIDTH(x) (((x) & 0x3) << 10)
#define CTRL_GET_BUS_WIDTH(x) (((x) >> 10) & 0x3)
+#define CTRL_BUS_WIDTH_MASK(0x3 << 10)
#define CTRL_SET_WORD_LENGTH(x)(((x) & 0x3) << 8)
#define CTRL_GET_WORD_LENGTH(x)(((x) >> 8) & 0x3)
#define CTRL_MASTER(1 << 5)
--
2.10.2
[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video
https://bugs.freedesktop.org/show_bug.cgi?id=98914 --- Comment #8 from Jörg-Volker Peetz --- Thanks for caring and your git lesson. The culprit is the change in src/gallium/auxiliary/vl/vl_zscan.c . I double-checked by starting from mesa-13.0.2 and just reverted the type change in that file back to "signed i;" which is enough to repair this regression. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/a6496aac/attachment.html>
[PATCH 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic.
Do something similar to vc4, only allow updating the cursor state
in-place through a fastpath when the watermarks are unaffected. This
will allow cursor movement to be smooth, but changing cursor size or
showing/hiding cursor will still fall back so watermarks can be updated.
Only moving and changing fb is allowed.
Changes since v1:
- Set page flip to always_unused for trybot.
- Copy fence correctly, ignore plane_state->state, should be NULL.
- Check crtc_state for !active and modeset, go to slowpath if the case.
Signed-off-by: Maarten Lankhorst
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 47 +++-
drivers/gpu/drm/i915/intel_display.c | 123 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +
3 files changed, 153 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index dbe9fb41ae53..60d75ce8a989 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -103,36 +103,24 @@ intel_plane_destroy_state(struct drm_plane *plane,
drm_atomic_helper_plane_destroy_state(plane, state);
}
-static int intel_plane_atomic_check(struct drm_plane *plane,
- struct drm_plane_state *state)
+int intel_plane_atomic_check_with_state(struct intel_crtc_state *crtc_state,
+ struct intel_plane_state *intel_state)
{
+ struct drm_plane *plane = intel_state->base.plane;
struct drm_i915_private *dev_priv = to_i915(plane->dev);
- struct drm_crtc *crtc = state->crtc;
- struct intel_crtc *intel_crtc;
- struct intel_crtc_state *crtc_state;
+ struct drm_plane_state *state = &intel_state->base;
struct intel_plane *intel_plane = to_intel_plane(plane);
- struct intel_plane_state *intel_state = to_intel_plane_state(state);
- struct drm_crtc_state *drm_crtc_state;
int ret;
- crtc = crtc ? crtc : plane->state->crtc;
- intel_crtc = to_intel_crtc(crtc);
-
/*
* Both crtc and plane->crtc could be NULL if we're updating a
* property while the plane is disabled. We don't actually have
* anything driver-specific we need to test in that case, so
* just return success.
*/
- if (!crtc)
+ if (!intel_state->base.crtc && !plane->state->crtc)
return 0;
- drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
- if (WARN_ON(!drm_crtc_state))
- return -EINVAL;
-
- crtc_state = to_intel_crtc_state(drm_crtc_state);
-
/* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
intel_state->clip.x1 = 0;
intel_state->clip.y1 = 0;
@@ -184,6 +172,31 @@ static int intel_plane_atomic_check(struct drm_plane
*plane,
return intel_plane_atomic_calc_changes(&crtc_state->base, state);
}
+static int intel_plane_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_crtc *crtc = state->crtc;
+ struct drm_crtc_state *drm_crtc_state;
+
+ crtc = crtc ? crtc : plane->state->crtc;
+
+ /*
+* Both crtc and plane->crtc could be NULL if we're updating a
+* property while the plane is disabled. We don't actually have
+* anything driver-specific we need to test in that case, so
+* just return success.
+*/
+ if (!crtc)
+ return 0;
+
+ drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+ if (WARN_ON(!drm_crtc_state))
+ return -EINVAL;
+
+ return
intel_plane_atomic_check_with_state(to_intel_crtc_state(drm_crtc_state),
+ to_intel_plane_state(state));
+}
+
static void intel_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9eaf1e5bdae9..a8b8663ecda7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15028,6 +15029,124 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_destroy_state = intel_plane_destroy_state,
};
+static int
+intel_legacy_cursor_update(struct drm_plane *plane,
+ struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+ int ret;
+ struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct intel_plane *
[PATCH 5/6] drm/atomic: Remove drm_atomic_helper_framebuffer_changed.
This function is now completely unused, zap it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 35 ---
include/drm/drm_atomic_helper.h | 3 ---
2 files changed, 38 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index fdeaea84a3b7..69ee1a94e851 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1058,41 +1058,6 @@ int drm_atomic_helper_wait_for_fences(struct drm_device
*dev,
EXPORT_SYMBOL(drm_atomic_helper_wait_for_fences);
/**
- * drm_atomic_helper_framebuffer_changed - check if framebuffer has changed
- * @dev: DRM device
- * @old_state: atomic state object with old state structures
- * @crtc: DRM crtc
- *
- * Checks whether the framebuffer used for this CRTC changes as a result of
- * the atomic update. This is useful for drivers which cannot use
- * drm_atomic_helper_wait_for_vblanks() and need to reimplement its
- * functionality.
- *
- * Returns:
- * true if the framebuffer changed.
- */
-bool drm_atomic_helper_framebuffer_changed(struct drm_device *dev,
- struct drm_atomic_state *old_state,
- struct drm_crtc *crtc)
-{
- struct drm_plane *plane;
- struct drm_plane_state *old_plane_state;
- int i;
-
- for_each_plane_in_state(old_state, plane, old_plane_state, i) {
- if (plane->state->crtc != crtc &&
- old_plane_state->crtc != crtc)
- continue;
-
- if (plane->state->fb != old_plane_state->fb)
- return true;
- }
-
- return false;
-}
-EXPORT_SYMBOL(drm_atomic_helper_framebuffer_changed);
-
-/**
* drm_atomic_helper_wait_for_vblanks - wait for vblank on crtcs
* @dev: DRM device
* @old_state: atomic state object with old state structures
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 7ff92b09fd9c..4b2353dc34ba 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -48,9 +48,6 @@ int drm_atomic_helper_commit(struct drm_device *dev,
int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
struct drm_atomic_state *state,
bool pre_swap);
-bool drm_atomic_helper_framebuffer_changed(struct drm_device *dev,
- struct drm_atomic_state *old_state,
- struct drm_crtc *crtc);
void drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
struct drm_atomic_state *old_state);
--
2.7.4
[PATCH 4/6] drm/atomic: Wait for vblank whenever a plane is added to state.
The current api doesn't take into account that whenever properties like
rotation or z-pos change we have to wait for vblank. To make sure
that we wait correctly, err on the side of caution and wait whenever
a plane is added to state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ccf0bed9bf4a..fdeaea84a3b7 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1123,11 +1123,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
*dev,
for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
struct drm_crtc_state *new_crtc_state = crtc->state;
- if (!new_crtc_state->active)
- continue;
-
- if (!drm_atomic_helper_framebuffer_changed(dev,
- old_state, crtc))
+ if (!new_crtc_state->active || !new_crtc_state->planes_changed)
continue;
ret = drm_crtc_vblank_get(crtc);
--
2.7.4
[PATCH 3/6] drm/atomic: Clean up wait_for_vblanks
Stop relying on a per crtc_state last_vblank_count, we know in advance
how many there can be. Also stop re-using new_crtc_state->enable,
we can now simply set a bitmask with crtc_crtc_mask.
---
drivers/gpu/drm/drm_atomic_helper.c | 29 +++--
include/drm/drm_crtc.h | 5 -
2 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d19563651e07..ccf0bed9bf4a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1110,19 +1110,20 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
*dev,
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
int i, ret;
+ unsigned crtc_mask = 0;
+ unsigned last_vblank_count[dev->mode_config.num_crtc];
+
+/*
+ * Legacy cursor ioctls are completely unsynced, and userspace
+ * relies on that (by doing tons of cursor updates).
+ */
+ if (old_state->legacy_cursor_update)
+ return;
for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
- /* No one cares about the old state, so abuse it for tracking
-* and store whether we hold a vblank reference (and should do a
-* vblank wait) in the ->enable boolean. */
- old_crtc_state->enable = false;
-
- if (!crtc->state->active)
- continue;
+ struct drm_crtc_state *new_crtc_state = crtc->state;
- /* Legacy cursor ioctls are completely unsynced, and userspace
-* relies on that (by doing tons of cursor updates). */
- if (old_state->legacy_cursor_update)
+ if (!new_crtc_state->active)
continue;
if (!drm_atomic_helper_framebuffer_changed(dev,
@@ -1133,16 +1134,16 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
*dev,
if (ret != 0)
continue;
- old_crtc_state->enable = true;
- old_crtc_state->last_vblank_count = drm_crtc_vblank_count(crtc);
+ crtc_mask |= drm_crtc_mask(crtc);
+ last_vblank_count[i] = drm_crtc_vblank_count(crtc);
}
for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
- if (!old_crtc_state->enable)
+ if (!(crtc_mask & drm_crtc_mask(crtc)))
continue;
ret = wait_event_timeout(dev->vblank[i].queue,
- old_crtc_state->last_vblank_count !=
+ last_vblank_count[i] !=
drm_crtc_vblank_count(crtc),
msecs_to_jiffies(50));
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 946672f97e1e..e03d194be086 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -93,8 +93,6 @@ struct drm_plane_helper_funcs;
* @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached planes
* @connector_mask: bitmask of (1 << drm_connector_index(connector)) of
attached connectors
* @encoder_mask: bitmask of (1 << drm_encoder_index(encoder)) of attached
encoders
- * @last_vblank_count: for helpers and drivers to capture the vblank of the
- * update to ensure framebuffer cleanup isn't done too early
* @adjusted_mode: for use by helpers and drivers to compute adjusted mode
timings
* @mode: current mode timings
* @mode_blob: &drm_property_blob for @mode
@@ -140,9 +138,6 @@ struct drm_crtc_state {
u32 connector_mask;
u32 encoder_mask;
- /* last_vblank_count: for vblank waits before cleanup */
- u32 last_vblank_count;
-
/* adjusted_mode: for use by helpers and drivers */
struct drm_display_mode adjusted_mode;
--
2.7.4
[PATCH 2/6] drm/atomic: Unconditionally call prepare_fb.
Atomic drivers may set properties like rotation on the same fb, which
may require a call to prepare_fb even when framebuffer stays identical.
Instead of handling all the special cases in the core, let the driver
decide when prepare_fb and cleanup_fb are noops.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 23767df72615..d19563651e07 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1664,9 +1664,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
funcs = plane->helper_private;
- if (!drm_atomic_helper_framebuffer_changed(dev, state,
plane_state->crtc))
- continue;
-
if (funcs->prepare_fb) {
ret = funcs->prepare_fb(plane, plane_state);
if (ret)
@@ -1683,9 +1680,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
if (j >= i)
continue;
- if (!drm_atomic_helper_framebuffer_changed(dev, state,
plane_state->crtc))
- continue;
-
funcs = plane->helper_private;
if (funcs->cleanup_fb)
@@ -1952,9 +1946,6 @@ void drm_atomic_helper_cleanup_planes(struct drm_device
*dev,
for_each_plane_in_state(old_state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
- if (!drm_atomic_helper_framebuffer_changed(dev, old_state,
plane_state->crtc))
- continue;
-
funcs = plane->helper_private;
if (funcs->cleanup_fb)
--
2.7.4
[PATCH 1/6] drm/atomic: Use active instead of enable in wait_for_vblanks.
When DPMS was introduced to atomic, vblanks only worked when the crtc was enabled and active. wait_for_vblanks were not converted to check for crtc_state->active, which may cause an attempt for vblank_get to fail. This is probably harmless, but convert from enable to active anyway. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 583f47f27b36..23767df72615 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1117,7 +1117,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, * vblank wait) in the ->enable boolean. */ old_crtc_state->enable = false; - if (!crtc->state->enable) + if (!crtc->state->active) continue; /* Legacy cursor ioctls are completely unsynced, and userspace -- 2.7.4
[PATCH 0/6] drm/atomic: Remove drm_atomic_helper_framebuffer_changed
drm_atomic_helpers use framebuffer_changed to skip some vblank waits in case properties don't change. This may skip vblank waits also when properties like rotation are changed. Fix this by always waiting for vblank if planes are added to the state, and always calling prepare_fb even when fb stays the same. Any smarts for this should be in the driver, they know when waiting can be skipped. While at it, cleanup drm_atomic_helper_wait_for_vblanks. It's reusing members of the crtc_state for different things, Maarten Lankhorst (6): drm/atomic: Use active instead of enable in wait_for_vblanks. drm/atomic: Unconditionally call prepare_fb. drm/atomic: Clean up wait_for_vblanks drm/atomic: Wait for vblank whenever a plane is added to state. drm/atomic: Remove drm_atomic_helper_framebuffer_changed. drm/i915: Add a cursor hack to allow converting legacy page flip to atomic. drivers/gpu/drm/drm_atomic_helper.c | 77 --- drivers/gpu/drm/i915/intel_atomic_plane.c | 47 +++- drivers/gpu/drm/i915/intel_display.c | 123 +- drivers/gpu/drm/i915/intel_drv.h | 2 + include/drm/drm_atomic_helper.h | 3 - include/drm/drm_crtc.h| 5 -- 6 files changed, 168 insertions(+), 89 deletions(-) -- 2.7.4
[Bug 99029] VCE VAAPI segfault using ffmpeg
https://bugs.freedesktop.org/show_bug.cgi?id=99029 Martin Bednar changed: What|Removed |Added CC||serafean at gmail.com Hardware|Other |x86-64 (AMD64) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/07f867c3/attachment.html>
[Bug 99029] VCE VAAPI segfault using ffmpeg
https://bugs.freedesktop.org/show_bug.cgi?id=99029 Bug ID: 99029 Summary: VCE VAAPI segfault using ffmpeg Product: Mesa Version: 13.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: serafean at gmail.com QA Contact: dri-devel at lists.freedesktop.org lspci:00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] libva info: Trying to open /usr/lib64/va/drivers/r600_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.39 (libva 1.7.3) vainfo: Driver version: mesa gallium vaapi vainfo: Supported profile and entrypoints VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main: VAEntrypointVLD VAProfileVC1Advanced: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileNone : VAEntrypointVideoProc commandline: ffmpeg -vaapi_device /dev/dri/renderD128 -i Elephants_Dream_HD.avi -vf format=rgba,hwupload -bf 0 -c:v h264_vaapi test.mkv run on a console over ssh. backtrace: #0 0x7f4004a58e3f in create (enc=0x19ed530) at /var/tmp/portage/media-libs/mesa-13.0.2/work/mesa-13.0.2/src/gallium/drivers/radeon/radeon_vce_40_2_2.c:98 #1 0x7f4004a5cd3f in rvce_begin_frame (encoder=0x19ed530, source=0x16e1a70, picture=0x19131d8) at /var/tmp/portage/media-libs/mesa-13.0.2/work/mesa-13.0.2/src/gallium/drivers/radeon/radeon_vce.c:288 #2 0x7f400490cdec in vlVaEndPicture (ctx=, context_id=23) at /var/tmp/portage/media-libs/mesa-13.0.2/work/mesa-13.0.2/src/gallium/state_trackers/va/picture.c:572 #3 0x7f401cfcf08f in vaEndPicture (dpy=0x1691c20, context=23) at /var/tmp/portage/x11-libs/libva-1.7.3/work/libva-1.7.3/va/va.c:1232 #4 0x7f401e202a9b in vaapi_encode_issue (avctx=avctx at entry=0x16e5060, pic=pic at entry=0x1745500) at src/libavcodec/vaapi_encode.c:387 #5 0x7f401e202c16 in vaapi_encode_step (avctx=avctx at entry=0x16e5060, target=target at entry=0x1745500) at src/libavcodec/vaapi_encode.c:587 #6 0x7f401e202fe7 in ff_vaapi_encode2 (avctx=0x16e5060, pkt=0x190fa60, input_image=, got_packet=0x7ffc264290d4) at src/libavcodec/vaapi_encode.c:867 #7 0x7f401e1f6d15 in avcodec_encode_video2 (avctx=avctx at entry=0x16e5060, avpkt=0x190fa60, frame=frame at entry=0x19ad200, got_packet_ptr=got_packet_ptr at entry=0x7ffc264290d4) at src/libavcodec/utils.c:1994 #8 0x7f401e1f6fda in do_encode (avctx=0x16e5060, frame=0x19ad200, got_packet=0x7ffc264290d4) at src/libavcodec/utils.c:2939 #9 0x7f401e1fc167 in avcodec_send_frame (avctx=avctx at entry=0x16e5060, frame=0x19ad200) at src/libavcodec/utils.c:2988 #10 0x00420fdd in do_video_out (of=of at entry=0x1745be0, ost=ost at entry=0x16e4e00, next_picture=next_picture at entry=0x19ad200, sync_ipts=, sync_ipts at entry=-7.62939453125e-06) at src/ffmpeg.c:1251 #11 0x0042266f in reap_filters (flush=flush at entry=0) at src/ffmpeg.c:1451 #12 0x00409316 in transcode_step () at src/ffmpeg.c:4343 #13 transcode () at src/ffmpeg.c:4387 #14 main (argc=, argv=) at src/ffmpeg.c:4592 Testing patches is no problem. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/74a34ee1/attachment.html>
[PATCH v5 1/4] drm: Add a new connector atomic property for link status
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 72fa5b2..34eddb9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,22 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> * now?) atomic writes to DPMS property:
> */
> return -EINVAL;
> + } else if (property == config->link_status_property) {
> + /* Never downgrade from GOOD to BAD on userspace's request
> here,
> +* only hw issues can do that.
> +*
> +* For an atomic property the userspace doesn't need to be
> able
> +* to understand all the properties, but needs to be able to
> +* restore the state itw ants on VT switch. So if the
> userspace
s/itw ants/it wants/
[GIT PULL] omapdrm fixes for v4.10
Hi Dave, I found two omapdrm bugs in drm-next which are quite bad, so I'm sending these already. These are based on today's drm-next. Tomi The following changes since commit 8166255704edea288bb116375b3c2a47af2fe28c: drm: mxsfb: Select DRM_PANEL (2016-12-08 10:25:37 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/omapdrm-4.10-fixes for you to fetch changes up to 5c2a392d574231793a156bff4d4391b3c1ba11c5: drm/omap: tpd12s015: fix error handling (2016-12-08 13:42:58 +0200) omapdrm fixes for v4.10 * fix tpd12s015's error handling, which causes omap5 uevm HDMI to fail * fix omapdrm primary plane allocation bug, which makes the display to fail to come up Tomi Valkeinen (3): drm: fix possible_crtc's type drm/omap: fix primary-plane's possible_crtcs drm/omap: tpd12s015: fix error handling drivers/gpu/drm/drm_plane.c | 4 ++-- drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 13 + drivers/gpu/drm/omapdrm/omap_drv.c | 17 - drivers/gpu/drm/omapdrm/omap_drv.h | 3 ++- drivers/gpu/drm/omapdrm/omap_plane.c | 6 +++--- include/drm/drm_plane.h | 4 ++-- 6 files changed, 30 insertions(+), 17 deletions(-) -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/a00641ed/attachment.sig>
[PATCH] drm/edid: Don't print an error if the checksum of a CEA block is wrong
It's common to share screens within CI labs, and it's also common for
KVM switches to alter the contents of the CEA block but leave the
checksum outdated.
So in this case, print a debug message instead of an error.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Cc: Chris Wilson
Cc: Tomi Sarvela
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_edid.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6798c3ad9d53..db79bc949216 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1128,16 +1128,19 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool
print_bad_edid,
csum = drm_edid_block_checksum(raw_edid);
if (csum) {
- if (print_bad_edid) {
- DRM_ERROR("EDID checksum is invalid, remainder is
%d\n", csum);
- }
-
if (edid_corrupt)
*edid_corrupt = true;
/* allow CEA to slide through, switches mangle this */
- if (raw_edid[0] != 0x02)
+ if (raw_edid[0] == CEA_EXT) {
+ DRM_DEBUG("EDID checksum is invalid, remainder is
%d\n", csum);
+ DRM_DEBUG("Assuming a KVM switch modified the CEA block
but left the original checksum\n");
+ } else {
+ if (print_bad_edid)
+ DRM_ERROR("EDID checksum is invalid, remainder
is %d\n", csum);
+
goto bad;
+ }
}
/* per-block-type checks */
--
2.7.4
[PATCH 4/4] drm/i915: Implement Link Rate fallback on Link training failure
On Thu, Dec 08, 2016 at 11:51:30PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > If link training at a link rate optimal for a particular
> > mode fails during modeset's atomic commit phase, then we
> > let the modeset complete and then retry. We save the link rate
> > value at which link training failed, update the link status property
> > to "BAD" and use a lower link rate to prune the modes. It will redo
> > the modeset on the current mode at lower link rate or if the current
> > mode gets pruned due to lower link constraints then, it will send a
> > hotplug uevent for userspace to handle it.
> >
> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> > 4.3.1.6.
> >
> > v9:
> > * Use the trimmed max values of link rate/lane count based on
> > link train fallback (Daniel Vetter)
> > v8:
> > * Set link_status to BAD first and then call mode_valid (Jani Nikula)
> > v7:
> > Remove the redundant variable in previous patch itself
> > v6:
> > * Obtain link rate index from fallback_link_rate using
> > the helper intel_dp_link_rate_index (Jani Nikula)
> > * Include fallback within intel_dp_start_link_train (Jani Nikula)
> > v5:
> > * Move set link status to drm core (Daniel Vetter, Jani Nikula)
> > v4:
> > * Add fallback support for non DDI platforms too
> > * Set connector->link status inside set_link_status function
> > (Jani Nikula)
> > v3:
> > * Set link status property to BAd unconditionally (Jani Nikula)
> > * Dont use two separate variables link_train_failed and link_status
> > to indicate same thing (Jani Nikula)
> > v2:
> > * Squashed a few patches (Jani Nikula)
> >
> > Acked-by: Tony Cheng
> > Acked-by: Harry Wentland
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Cc: Ville Syrjala
> > Signed-off-by: Manasi Navare
>
> This is not a journey I'd like to do again, but I like the place where
> we've finally arrived.
>
> Reviewed-by: Jani Nikula
>
Thanks a lot Jani for all the reviews till now. Its actually
been a great journey for me learning so many things from you. I would def like
to do this
again.
Regards
Manasi
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 27
> > +++
> > drivers/gpu/drm/i915/intel_dp_link_training.c | 22 --
> > drivers/gpu/drm/i915/intel_drv.h | 3 +++
> > 3 files changed, 50 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index b5c7526f..404da32 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5676,6 +5676,29 @@ static bool intel_edp_init_connector(struct intel_dp
> > *intel_dp,
> > return false;
> > }
> >
> > +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> > +{
> > + struct intel_connector *intel_connector;
> > + struct drm_connector *connector;
> > +
> > + intel_connector = container_of(work, typeof(*intel_connector),
> > + modeset_retry_work);
> > + connector = &intel_connector->base;
> > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> > + connector->name);
> > +
> > + /* Grab the locks before changing connector property*/
> > + mutex_lock(&connector->dev->mode_config.mutex);
> > + /* Set connector link status to BAD and send a Uevent to notify
> > +* userspace to do a modeset.
> > +*/
> > + drm_mode_connector_set_link_status_property(connector,
> > + DRM_MODE_LINK_STATUS_BAD);
> > + mutex_unlock(&connector->dev->mode_config.mutex);
> > + /* Send Hotplug uevent so userspace can reprobe */
> > + drm_kms_helper_hotplug_event(connector->dev);
> > +}
> > +
> > bool
> > intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > struct intel_connector *intel_connector)
> > @@ -5688,6 +5711,10 @@ static bool intel_edp_init_connector(struct intel_dp
> > *intel_dp,
> > enum port port = intel_dig_port->port;
> > int type;
> >
> > + /* Initialize the work for modeset in case of link train failure */
> > + INIT_WORK(&intel_connector->modeset_retry_work,
> > + intel_dp_modeset_retry_work_fn);
> > +
> > if (WARN(intel_dig_port->max_lanes < 1,
> > "Not enough lanes (%d) for DP on port %c\n",
> > intel_dig_port->max_lanes, port_name(port)))
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 0048b52..955b239 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -313,6 +313,24 @@ void intel_dp_stop_link_train(struct intel_dp
> > *intel_dp)
> > void
> > intel_dp_start_link_train(struct intel_dp *intel_dp)
> > {
> > - intel_dp_link_training_clock_recovery(intel_dp);
> > - intel_dp_link_training_channel_equalization(intel_dp);
> > + stru
[Intel-gfx] [PATCH 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic.
On 8 December 2016 at 13:45, Maarten Lankhorst
wrote:
> Do something similar to vc4, only allow updating the cursor state
> in-place through a fastpath when the watermarks are unaffected. This
> will allow cursor movement to be smooth, but changing cursor size or
> showing/hiding cursor will still fall back so watermarks can be updated.
>
> Only moving and changing fb is allowed.
>
> Changes since v1:
> - Set page flip to always_unused for trybot.
> - Copy fence correctly, ignore plane_state->state, should be NULL.
> - Check crtc_state for !active and modeset, go to slowpath if the case.
>
> Signed-off-by: Maarten Lankhorst
> Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 47 +++-
> drivers/gpu/drm/i915/intel_display.c | 123
> +-
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> 3 files changed, 153 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index dbe9fb41ae53..60d75ce8a989 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -103,36 +103,24 @@ intel_plane_destroy_state(struct drm_plane *plane,
> drm_atomic_helper_plane_destroy_state(plane, state);
> }
>
> -static int intel_plane_atomic_check(struct drm_plane *plane,
> - struct drm_plane_state *state)
> +int intel_plane_atomic_check_with_state(struct intel_crtc_state *crtc_state,
> + struct intel_plane_state *intel_state)
> {
> + struct drm_plane *plane = intel_state->base.plane;
> struct drm_i915_private *dev_priv = to_i915(plane->dev);
> - struct drm_crtc *crtc = state->crtc;
> - struct intel_crtc *intel_crtc;
> - struct intel_crtc_state *crtc_state;
> + struct drm_plane_state *state = &intel_state->base;
> struct intel_plane *intel_plane = to_intel_plane(plane);
> - struct intel_plane_state *intel_state = to_intel_plane_state(state);
> - struct drm_crtc_state *drm_crtc_state;
> int ret;
>
> - crtc = crtc ? crtc : plane->state->crtc;
> - intel_crtc = to_intel_crtc(crtc);
> -
> /*
> * Both crtc and plane->crtc could be NULL if we're updating a
> * property while the plane is disabled. We don't actually have
> * anything driver-specific we need to test in that case, so
> * just return success.
> */
> - if (!crtc)
> + if (!intel_state->base.crtc && !plane->state->crtc)
> return 0;
>
> - drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> crtc);
> - if (WARN_ON(!drm_crtc_state))
> - return -EINVAL;
> -
> - crtc_state = to_intel_crtc_state(drm_crtc_state);
> -
> /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
> intel_state->clip.x1 = 0;
> intel_state->clip.y1 = 0;
> @@ -184,6 +172,31 @@ static int intel_plane_atomic_check(struct drm_plane
> *plane,
> return intel_plane_atomic_calc_changes(&crtc_state->base, state);
> }
>
> +static int intel_plane_atomic_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_crtc *crtc = state->crtc;
> + struct drm_crtc_state *drm_crtc_state;
> +
> + crtc = crtc ? crtc : plane->state->crtc;
> +
> + /*
> +* Both crtc and plane->crtc could be NULL if we're updating a
> +* property while the plane is disabled. We don't actually have
> +* anything driver-specific we need to test in that case, so
> +* just return success.
> +*/
> + if (!crtc)
> + return 0;
> +
> + drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> crtc);
> + if (WARN_ON(!drm_crtc_state))
> + return -EINVAL;
> +
> + return
> intel_plane_atomic_check_with_state(to_intel_crtc_state(drm_crtc_state),
> +
> to_intel_plane_state(state));
> +}
> +
> static void intel_plane_atomic_update(struct drm_plane *plane,
> struct drm_plane_state *old_state)
> {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9eaf1e5bdae9..a8b8663ecda7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15028,6 +15029,124 @@ const struct drm_plane_funcs intel_plane_funcs = {
> .atomic_destroy_state = intel_plane_destroy_state,
> };
>
> +static int
> +intel_legacy_cursor_update(struct drm_plane *plane,
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + int crtc_x, int crtc_y,
> + unsigned int crtc_w, unsigned int crtc_h,
> +
[PATCH 3/4] drm/i915: Find fallback link rate/lane count
On Thu, Dec 08, 2016 at 11:46:02PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > If link training fails, then we need to fallback to lower
> > link rate first and if link training fails at RBR, then
> > fallback to lower lane count.
> > This function finds the next lower link rate/lane count
> > value after link training failure and limits the max
> > link_rate and lane_count values to these fallback values.
> >
> > v6:
> > * Cap the max link rate and lane count to the max
> > values obtained during fallback link training (Daniel Vetter)
> > v5:
> > * Start the fallback at the lane count value passed not
> > the max lane count (Jani Nikula)
> > v4:
> > * Remove the redundant variable link_train_failed
> > v3:
> > * Remove fallback_link_rate_index variable, just obtain
> > that using the helper intel_dp_link_rate_index (Jani Nikula)
> > v2:
> > Squash the patch that returns the link rate index (Jani Nikula)
> >
> > Acked-by: Tony Cheng
> > Acked-by: Harry Wentland
> > Cc: Ville Syrjala
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 40
> >
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > 2 files changed, 42 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 434dc7d..b5c7526f 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -278,6 +278,46 @@ static int intel_dp_common_rates(struct intel_dp
> > *intel_dp,
> >common_rates);
> > }
> >
> > +static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> > + int *common_rates, int link_rate)
> > +{
> > + int common_len;
> > + int index;
> > +
> > + common_len = intel_dp_common_rates(intel_dp, common_rates);
> > + for (index = 0; index < common_len; index++) {
> > + if (link_rate == common_rates[common_len - index - 1])
> > + return common_len - index - 1;
>
> Probably somewhere in the history of the patch series there was a time
> when it was necessary to search for the rates in reverse order. What
> possible benefit could that offer at this point?
>
The advantage here is that the link rate is more likely to match quicker
if we search in reverse order.
> > + }
> > +
> > + return -1;
> > +}
> > +
> > +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > + int link_rate, uint8_t lane_count)
> > +{
> > + int common_rates[DP_MAX_SUPPORTED_RATES] = {};
>
> No need to initialize because you initialize it a couple of lines later.
>
Agreed
> > + int common_len;
> > + int link_rate_index = -1;
>
> No need to initialize because you initialize it a couple of lines later.
>
> > +
> > + common_len = intel_dp_common_rates(intel_dp, common_rates);
> > + link_rate_index = intel_dp_link_rate_index(intel_dp,
> > + common_rates,
> > + link_rate);
>
> Please stop and think, and don't rush each new iteration of the patches.
>
> What's wrong with the above lines? Please think about it. Answer at the
> end of the mail (*).
>
> > + if (link_rate_index > 0) {
> > + intel_dp->max_sink_link_bw =
> > drm_dp_link_rate_to_bw_code(common_rates[link_rate_index - 1]);
> > + intel_dp->max_sink_lane_count = lane_count;
> > + } else if (lane_count > 1) {
> > + intel_dp->max_sink_link_bw = intel_dp_max_link_bw(intel_dp);
> > + intel_dp->max_sink_lane_count = lane_count >> 1;
> > + } else {
> > + DRM_ERROR("Link Training Unsuccessful\n");
> > + return -1;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static enum drm_mode_status
> > intel_dp_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index b6526ad..47e3671 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1400,6 +1400,8 @@ bool intel_dp_init_connector(struct
> > intel_digital_port *intel_dig_port,
> > void intel_dp_set_link_params(struct intel_dp *intel_dp,
> > int link_rate, uint8_t lane_count,
> > bool link_mst);
> > +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > + int link_rate, uint8_t lane_count);
> > void intel_dp_start_link_train(struct intel_dp *intel_dp);
> > void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> > void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
>
>
> (*) You do intel_dp_common_rates(intel_dp, common_rates) twice, for no
> reason at all.
>
Actually the first call was to obtain the com
[RESEND PATCH 2/2] drm/panel: simple: Add support BOE nv101wxmn51
10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.
Signed-off-by: Caesar Wang
---
drivers/gpu/drm/panel/panel-simple.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..c9135dc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode boe_nv101wxmn51_mode = {
+ .clock = 71900,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 48,
+ .hsync_end = 1280 + 48 + 32,
+ .htotal = 1280 + 48 + 32 + 80,
+ .vdisplay = 800,
+ .vsync_start = 800 + 3,
+ .vsync_end = 800 + 3 + 20,
+ .vtotal = 800 + 3 + 20 + 9,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+ .modes = &boe_nv101wxmn51_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .delay = {
+ .prepare = 210,
+ .enable = 50,
+ .unprepare = 160,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
}, {
+ .compatible = "boe,nv101wxmn51",
+ .data = &boe_nv101wxmn51,
+ }, {
.compatible = "chunghwa,claa070wp03xg",
.data = &chunghwa_claa070wp03xg,
}, {
--
2.7.4
[RESEND PATCH 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding
The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. Signed-off-by: Caesar Wang --- .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt diff --git a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt new file mode 100644 index 000..b258d6a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt @@ -0,0 +1,7 @@ +BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "boe,nv101wxmn51" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.7.4
[PATCH] drm/panel: simple: Add support BOE nv101wxmn51
Resend the missing document.
Sorry for the noise.
å¨ 2016å¹´12æ08æ¥ 13:26, Caesar Wang åé:
> 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
> TFT's as an active switching devices. It can be supported by the
> simple-panel driver.
>
> Signed-off-by: Caesar Wang
> ---
>
> drivers/gpu/drm/panel/panel-simple.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 06aaf79..c9135dc 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
> },
> };
>
> +static const struct drm_display_mode boe_nv101wxmn51_mode = {
> + .clock = 71900,
> + .hdisplay = 1280,
> + .hsync_start = 1280 + 48,
> + .hsync_end = 1280 + 48 + 32,
> + .htotal = 1280 + 48 + 32 + 80,
> + .vdisplay = 800,
> + .vsync_start = 800 + 3,
> + .vsync_end = 800 + 3 + 20,
> + .vtotal = 800 + 3 + 20 + 9,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc boe_nv101wxmn51 = {
> + .modes = &boe_nv101wxmn51_mode,
> + .num_modes = 1,
> + .bpc = 8,
> + .size = {
> + .width = 217,
> + .height = 136,
> + },
> + .delay = {
> + .prepare = 210,
> + .enable = 50,
> + .unprepare = 160,
> + },
> +};
> +
> static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
> .clock = 66770,
> .hdisplay = 800,
> @@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "avic,tm070ddh03",
> .data = &avic_tm070ddh03,
> }, {
> + .compatible = "boe,nv101wxmn51",
> + .data = &boe_nv101wxmn51,
> + }, {
> .compatible = "chunghwa,claa070wp03xg",
> .data = &chunghwa_claa070wp03xg,
> }, {
[PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug
Daniel, can we merge this patch?
It has no dependency on other link train patches,
it is just a clean up for the existing driver code that
uses max link rate and lane count values.
Other link train patches have dependency on this thats why
it was part of the series.
But it would be great if this gets merged so that i dont have to
rebase it tremendously after 3 weeks when I am back and plus
its good for the driver to start using this clean up. This kind
of clean up was long due.
Regards
Manasi
On Thu, Dec 08, 2016 at 11:23:39PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > Sink's capabilities are advertised through DPCD registers and get
> > updated only on hotplug. So they should be computed only once in the
> > long pulse handler and saved off in intel_dp structure for the use
> > later. For this reason two new fields max_sink_lane_count and
> > max_sink_link_bw are added to intel_dp structure.
> >
> > This also simplifies the fallback link rate/lane count logic
> > to handle link training failure. In that case, the max_sink_link_bw
> > and max_sink_lane_count can be reccomputed to match the fallback
> > values lowering the sink capabilities due to link train failure.
> >
> > Cc: Ville Syrjala
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Signed-off-by: Manasi Navare
>
> Reviewed-by: Jani Nikula
>
> Eventually we may want to call the fields *link* rates, because that's
> what they'll effectively be. Transient values that don't reflect the
> sink or source capabilities, but the link capabilities.
>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 10 --
> > drivers/gpu/drm/i915/intel_drv.h | 4
> > 2 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index db75bb9..434dc7d 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -156,7 +156,7 @@ static u8 intel_dp_max_lane_count(struct intel_dp
> > *intel_dp)
> > u8 source_max, sink_max;
> >
> > source_max = intel_dig_port->max_lanes;
> > - sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
> > + sink_max = intel_dp->max_sink_lane_count;
> >
> > return min(source_max, sink_max);
> > }
> > @@ -213,7 +213,7 @@ static u8 intel_dp_max_lane_count(struct intel_dp
> > *intel_dp)
> >
> > *sink_rates = default_rates;
> >
> > - return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
> > + return (intel_dp->max_sink_link_bw >> 3) + 1;
> > }
> >
> > static int
> > @@ -4395,6 +4395,12 @@ static bool intel_digital_port_connected(struct
> > drm_i915_private *dev_priv,
> > yesno(intel_dp_source_supports_hbr2(intel_dp)),
> > yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
> >
> > + /* Set the max lane count for sink */
> > + intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > +
> > + /* Set the max link BW for sink */
> > + intel_dp->max_sink_link_bw = intel_dp_max_link_bw(intel_dp);
> > +
> > intel_dp_print_rates(intel_dp);
> >
> > intel_dp_read_desc(intel_dp);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index fd77a3b..b6526ad 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -906,6 +906,10 @@ struct intel_dp {
> > /* sink rates as reported by DP_SUPPORTED_LINK_RATES */
> > uint8_t num_sink_rates;
> > int sink_rates[DP_MAX_SUPPORTED_RATES];
> > + /* Max lane count for the sink as per DPCD registers */
> > + uint8_t max_sink_lane_count;
> > + /* Max link BW for the sink as per DPCD registers */
> > + int max_sink_link_bw;
> > /* sink or branch descriptor */
> > struct intel_dp_desc desc;
> > struct drm_dp_aux aux;
>
> --
> Jani Nikula, Intel Open Source Technology Center
[PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug
On Thu, Dec 08, 2016 at 11:23:39PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > Sink's capabilities are advertised through DPCD registers and get
> > updated only on hotplug. So they should be computed only once in the
> > long pulse handler and saved off in intel_dp structure for the use
> > later. For this reason two new fields max_sink_lane_count and
> > max_sink_link_bw are added to intel_dp structure.
> >
> > This also simplifies the fallback link rate/lane count logic
> > to handle link training failure. In that case, the max_sink_link_bw
> > and max_sink_lane_count can be reccomputed to match the fallback
> > values lowering the sink capabilities due to link train failure.
> >
> > Cc: Ville Syrjala
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Signed-off-by: Manasi Navare
>
> Reviewed-by: Jani Nikula
>
> Eventually we may want to call the fields *link* rates, because that's
> what they'll effectively be. Transient values that don't reflect the
> sink or source capabilities, but the link capabilities.
>
Thanks Jani for your r-b.
Yes I agree, should I change the name to link_rate instead of sink_link_rate
now?
The only reason I kept it as sink_link_rate is because we go ahead and calculate
the link capabilities later based on common link rate.
Regards
Manasi
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 10 --
> > drivers/gpu/drm/i915/intel_drv.h | 4
> > 2 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index db75bb9..434dc7d 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -156,7 +156,7 @@ static u8 intel_dp_max_lane_count(struct intel_dp
> > *intel_dp)
> > u8 source_max, sink_max;
> >
> > source_max = intel_dig_port->max_lanes;
> > - sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
> > + sink_max = intel_dp->max_sink_lane_count;
> >
> > return min(source_max, sink_max);
> > }
> > @@ -213,7 +213,7 @@ static u8 intel_dp_max_lane_count(struct intel_dp
> > *intel_dp)
> >
> > *sink_rates = default_rates;
> >
> > - return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
> > + return (intel_dp->max_sink_link_bw >> 3) + 1;
> > }
> >
> > static int
> > @@ -4395,6 +4395,12 @@ static bool intel_digital_port_connected(struct
> > drm_i915_private *dev_priv,
> > yesno(intel_dp_source_supports_hbr2(intel_dp)),
> > yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
> >
> > + /* Set the max lane count for sink */
> > + intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > +
> > + /* Set the max link BW for sink */
> > + intel_dp->max_sink_link_bw = intel_dp_max_link_bw(intel_dp);
> > +
> > intel_dp_print_rates(intel_dp);
> >
> > intel_dp_read_desc(intel_dp);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index fd77a3b..b6526ad 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -906,6 +906,10 @@ struct intel_dp {
> > /* sink rates as reported by DP_SUPPORTED_LINK_RATES */
> > uint8_t num_sink_rates;
> > int sink_rates[DP_MAX_SUPPORTED_RATES];
> > + /* Max lane count for the sink as per DPCD registers */
> > + uint8_t max_sink_lane_count;
> > + /* Max link BW for the sink as per DPCD registers */
> > + int max_sink_link_bw;
> > /* sink or branch descriptor */
> > struct intel_dp_desc desc;
> > struct drm_dp_aux aux;
>
> --
> Jani Nikula, Intel Open Source Technology Center
[PATCHv2 2/2] drm/omap: fix primary-plane's possible_crtcs
On 02/12/16 17:56, Laurent Pinchart wrote: > Hi Tomi, > > On Friday 02 Dec 2016 17:55:10 Tomi Valkeinen wrote: >> On 02/12/16 17:42, Laurent Pinchart wrote: >>> I can understand that (even if I'm not sure it's really an issue, and we >>> should really clean up the CRTC creation code at some point), but how >>> about adding a possible_crtcs field to the priv structure then ? I don't >>> really like having to pass it around through a bunch of functions. >> >> It is passed to two functions, I'm not sure if that's a bunch =). >> >> I can do as you suggest, but I don't like adding fields to structs for >> things that we only need once. > > I'm not too fond of that either, hence my first suggestion :-) > >> I think local variables and function parameters are for that. >> >> But I agree that the patch would be quite a bit smaller with the field, >> so... > > I won't nack any solution you end up selecting even if I have my preferences. I'll go with the posted v2. I agree it's not perfect, but every other option I've tried also feels bad =). I think the only good solution is to rewrite the init parts, but I don't want to do that for a fix. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/6eaa6384/attachment.sig>
[PATCH] drm/panel: simple: Add support BOE nv101wxmn51
10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.
Signed-off-by: Caesar Wang
---
drivers/gpu/drm/panel/panel-simple.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..c9135dc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode boe_nv101wxmn51_mode = {
+ .clock = 71900,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 48,
+ .hsync_end = 1280 + 48 + 32,
+ .htotal = 1280 + 48 + 32 + 80,
+ .vdisplay = 800,
+ .vsync_start = 800 + 3,
+ .vsync_end = 800 + 3 + 20,
+ .vtotal = 800 + 3 + 20 + 9,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+ .modes = &boe_nv101wxmn51_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .delay = {
+ .prepare = 210,
+ .enable = 50,
+ .unprepare = 160,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
}, {
+ .compatible = "boe,nv101wxmn51",
+ .data = &boe_nv101wxmn51,
+ }, {
.compatible = "chunghwa,claa070wp03xg",
.data = &chunghwa_claa070wp03xg,
}, {
--
2.7.4
[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video
https://bugs.freedesktop.org/show_bug.cgi?id=98914 --- Comment #7 from Christian König --- Good work, looks like this fix had some unintended side effects. Please try the following: Revert the change without creating a commit, e.g. run "git revert -n 1fb4179f927442354f93dfc8494f0236e50af838". Then reset the changes to their not added state, e.g. run "git reset HEAD". This should give you the following list: M src/gallium/auxiliary/vl/vl_deint_filter.c M src/gallium/auxiliary/vl/vl_idct.c M src/gallium/auxiliary/vl/vl_matrix_filter.c M src/gallium/auxiliary/vl/vl_median_filter.c M src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c M src/gallium/auxiliary/vl/vl_vlc.h M src/gallium/auxiliary/vl/vl_zscan.c Now use git checkout on each file (e.g. "git checkout src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c") to figure out what change actually broke the decoding. My best bet is vl_mpeg12_bitstream.c, but could as well be vl_idct.c, vl_zscan.c or vl_vlc.h. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/ddef16be/attachment.html>
[Intel-gfx] [RFC v2] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*
Hi, On 07/12/2016 18:35, Robert Bragg wrote: > This is still missing corresponding documentation changes, and I haven't > moved anything to drm_print.h yet, as suggested. > > Sending out with a few functional improvements first to get agreement > before documenting anything (changes summarised in v2: section below) > > In particular, affecting the output format, I stole an idea from Tvrtko > Ursulin to have the prefix for messages be based on the driver name, > such as "[i915]" instead of always being "[drm]". > > Depending on peoples thoughts on compatibility, we could consider > removing the prefix given that the dynamic debug control interface has a > way of specifying that messages should include a module name, function > or line info like: > > echo "module i915 +mfp" > dynamic_debug/control > > That would enable all i915 debug messages with a module and function > prefix. To check if I got it right, that would put the prefix on debug messages while the rest would not have it? (With the option of dropping the prefix in general that is.) Or you thought just removing the prefix from debug messages? > A trade-off would be that anyone only using the drm.drm_debug interface > to control messages would loose some information. If we really wanted we > could have the best of both by adding a utility printing api that can > recognise when printing due to a dynamic debug control query vs > drm.drm_debug to conditionally add the prefix. I think prefix by default, on non-debug messages, is required. We could perhaps make it like "drm: message", and not "[drm] message", to match the rest of the kernel? > > --- >8 --- (git am --scissors) > > Dynamic debug messages (ref: Documentation/dynamic-debug-howto.txt) > allow fine grained control over which debug messages are enabled with > runtime control through /sysfs/kernel/debug/dynamic_debug/control > > This provides more control than the current drm.drm_debug parameter > which for some use cases is impractical to use given how chatty > some drm debug categories are. > > For example all debug messages in i915_drm.c can be enabled with: > echo "file i915_perf.c +p" > dynamic_debug/control > > This doesn't strictly maintain format compatibility with the previous > debug messages since the category is now added as part of the prefix > like "[drm][kms] No FB found". Adding the categories with a consistent > format makes it possible to enable categories with a dynamic debug > query like: echo "format [kms] +p" > dynamic_debug/control If I got it right from the patch the actual debug format is: "[drm:function_name][kms] Message" Correct? In which case I would suggest different grouping, where category comes before the function name. For example: "[drm:kms:function_name] Message" I also find a lot of square braces hard to read. So the current "[function [module]]" is not my favourite so plus points for this initiative as well. In general this looks like a good cleanup and improvement so ack from me. Regards, Tvrtko P.S. Also eliminate DRM_NAME in this work? > > This maintains support for enabling debug messages using the drm_debug > parameter. If dynamic debug is not enabled via CONFIG_DYNAMIC_DEBUG the > debug messages essentially work as before, except with the inclusion of > categories in the format strings as described above. > > This removes the drm_[dev_]printk wrappers considering that the dynamic > debug macros are only useful if they can track the __FILE__, __func__ > and __LINE__ where they are called. The wrapper didn't seem necessary in > the DRM_UT_NONE case with no category flag. > > The non _DEV macros are no longer defined in terms of passing NULL to a > _DEV variant to avoid have the core.c dev_printk implementation adding > "(NULL device *)". The previous drm_[dev_]prink function used to handle > this as a special case. > > Instead of using DRM_NAME to add [drm] to the start of every message, > the prefix is now based on module_name(THIS_MODULE) so it will be [drm] > or e.g. [i915] for the Intel driver. Later we might consider removing > the prefix altogether considering that the dynamic debug control > interface has a way of optionally adding the module, function or line to > the formatting of messages. > > v2: > Add categories to format like "[drm][kms] No FB found" > Only single conditional call per message (macros expand to less code) > Uses __dynamic_pr_debug/dev_dbg for dynamic formatting features > Use module name for msg prefix like [drm] or [i915] > > Signed-off-by: Robert Bragg > Cc: dri-devel at lists.freedesktop.org > Cc: Daniel Vetter > Cc: Tvrtko Ursulin > --- > drivers/gpu/drm/drm_drv.c | 47 --- > include/drm/drmP.h| 202 > +- > 2 files changed, 127 insertions(+), 122 deletions(-) > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > index f74b7d0..25d00aa 100644 > --- a/drivers/gpu/drm/drm_drv.c > +++ b/drivers/gpu/drm/
[RFC PATCH 0/3] staging: remove fbdev drivers
On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
>> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
>> > Since the fbdev framework is in maintenance mode and all new display
>> > drivers
>> > should be made with the DRM framework, remove the fbdev drivers from
>> > staging.
>> >
>> > Note: the patches are created with git format-patch -D, so they can't be
>> > applied. Only for review.
>>
>> I missed the discussion where this decision was made, I admit I am
>> unimpressed by it.
>>
>> DRM drivers don't strike me as suitable for small/slow cores with dumb
>> framebuffers or simple 2D only accel, such as the one found in the ASpeed
>> BMCs.
>
> We have a helper for simple drivers now, if you take into account the
> massive helper libraries for everything that comes along with drm I expect
> if even dumb panels behind slow spi buses drm is now the more suitable
> subsytem.
This has been going on your years:
1. Fbdev is obsolete, everybody should use DRM instead!
2. Can you please point me to a small sample driver for a dumb frame buffer?
3. Several are being written, but none of them is upstream yet.
4. Goto 1.
>> With drmfb you basically have to shadow everything into memory & copy
>> over everything, and locks you out of simple 2D accel. For a simple text
>> console the result is orders of magnitude slower and memory hungry than
>> a simple fbdev.
>
> Not true, we have full fbdev emulation, and drivers can implement the 2d
> accel in there. And a bunch of them do. It's just that most teams decided
> that this is pointless waste of their time.j
>
>> At least that was the case last I looked at the DRM stuff with Dave,
>> maybe things have changed...
>>
>> Not everything has a powerful 3D GPU.
>
> That's correct, and drm can cope. And compared to fbdev there's a very
> active community who improves&refactors it every kernel release to make it
> even better. Since about 2 years (when atomic landed) we merge new drivers at
> a rate of 2-3 per kernel release, and those new drivers get ever simpler
> and smaller thanks to all this work.
You mean the kind of refactoring that causes severe merge conflicts between
drm-next and Linus' tree about every single day?
(sorry, couldn't resist ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #146 from Daniel Exner --- (In reply to Marek Olšák from comment #142) [..] > In my case, this is the data I've been able to obtain: > - Reproduced on everything I was testing on: Hawaii (radeon), Tonga, > Polaris11 (amdgpu) Out of curiosity: what about r600? > Action items: > - Reproduce the hang and do a hardware scan dump (it can only be done in the > AMD office AFAIK), and send it to hardware teams. Any news here? My best bet still is either something in DPM or LLVM. DPM path is supported by this card being one of those needing a DPM quirk in si_dpm.c. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161208/c31a8bef/attachment.html>
[PATCH] drm: Update drm_device docs about embedding.
On Thu, Dec 08, 2016 at 10:50:48AM +, Chris Wilson wrote: > On Thu, Dec 08, 2016 at 11:28:47AM +0100, Daniel Vetter wrote: > > It's supported now! Spotted while reviewing Chris' patch to add a > > release hook. > > > > Cc: Chris Wilson > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_drv.c | 11 +++ > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > index f74b7d06ec01..4ec61ac27477 100644 > > --- a/drivers/gpu/drm/drm_drv.c > > +++ b/drivers/gpu/drm/drm_drv.c > > @@ -323,9 +323,8 @@ void drm_minor_release(struct drm_minor *minor) > > * historical baggage. Hence use the reference counting provided by > > * drm_dev_ref() and drm_dev_unref() only carefully. > > * > > - * Also note that embedding of &drm_device is currently not (yet) > > supported (but > > - * it would be easy to add). Drivers can store driver-private data in the > > - * dev_priv field of &drm_device. > > + * It is recommended that drivers embed struct &drm_device into their own > > device > > + * structure, which is supported through drm_dev_init(). > > */ > > > > /** > > @@ -462,7 +461,11 @@ static void drm_fs_inode_free(struct inode *inode) > > * Note that for purely virtual devices @parent can be NULL. > > * > > * Drivers that do not want to allocate their own device struct > > - * embedding struct &drm_device can call drm_dev_alloc() instead. > > + * embedding struct &drm_device can call drm_dev_alloc() instead. For > > drivers > > + * that do embed struct &drm_device it must be placed first in the overall > > + * structure, and the overall structure must be allocated using kmalloc(): > > The > > + * drm core's release function unconditionally calls kfree() on the @dev > > pointer > > + * when the final reference is released. > > Hmm, the privates are getting pretty big (drm_i915_private fits inside > malloc-32678). We should start considering using drm_free_large() instead > as that more or less work transparently and allows fallback to vmalloc. Yeah, I wondered whether your new ->release hook should be the very last thing in drm_dev_release, and that it would replace the final kfree. Then we could do custom stuff in drivers that have an oversized dev struct ;-) > As it stands the doc update is correct, so > Reviewed-by: Chris Wilson Thanks for the review, applied to drm-misc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/mxsfb: fix pixel clock polarity
On 2016-12-07 18:37, Marek Vasut wrote: > On 12/08/2016 02:26 AM, Stefan Agner wrote: >> On 2016-12-07 16:59, Stefan Agner wrote: >>> On 2016-12-07 16:49, Marek Vasut wrote: On 12/08/2016 01:27 AM, Stefan Agner wrote: > The DRM subsystem specifies the pixel clock polarity from a > controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means > the controller drives the data on pixel clocks falling edge. > That is the controllers DOTCLK_POL=0 (Default is data launched > at negative edge). > > Also change the data enable logic to be high active by default > and only change if explicitly requested via bus_flags. With > that defaults are: > - Data enable: high active > - Pixel clock polarity: controller drives data on negative edge > > Signed-off-by: Stefan Agner > --- > Hi Marek, Hi, that was quick, thanks for checking this. >>> >>> Yeah, I couldn't wait seeing it flying :-) >>> > I discovered this while testing on a i.MX 7 eLCDIF IP. Particularly the > non-standard DE polarity was causing issues. I was using a EDT display > which is part of simple panel driver since a while now and does not > specify any bus_flags currently... Of course I could (and probably should) > add the proper bus_flags there too, but there are several displays > which do not specify any polarity and likely rely on sensible driver > standards (which is afact high active for the DE signal). I actually use a panel which requires correct settings of the flags, see e0932f9d7ba9a16f99a84943b720f109de8e3e06 in mainline , so this patch would break things for me. So I wonder whether you should fix the panel driver or whether the mxsfb should be fixed ? >>> >>> If you ask me, mxsfb. >>> >>> Ok, there are actually two things, one is a bug, one is a default >>> change. >>> >>> The bug: Pixel clock polarity is clearly defined to be controller >>> centric (see comments around DRM_BUS_FLAG_PIXDATA_*EDGE in >>> include/drm/drm_connector.h). The driver does it wrong currently. >>> >>> This might affect your display, and if it does, it is actually wrong >>> also in your display... However, since it is a bug, I think it is not >>> really a debate, it should be fixed... >> >> FWIW, it seems that Ortustech com43h4m85ulc samples on falling edge, so >> DRM_BUS_FLAG_PIXDATA_POSEDGE seems right. And it means that DOTCLK_POL >> should be 1 (inverted), so with this patch the polarity should actually >> be correct for that panel. > > Well, if I apply this patch, my image is shifted by 1 px to the left and > there is a 1px white bar on the right side, so I think I have some > polarity problem now ? Ok, lets create facts here: 1. SoloX Refrence Manual, Figure 37-13. shows DOTCLK_POL=0, and it shows that the controller drives signals on falling edge of the pixel clock. The i.MX 7 has the same figure. 2. Just to verify, I hooked up an oscilloscope on my i.MX 7: It shows that with DOTCLK_POL=0 the controller drives on falling edge: http://imgur.com/a/2f2Xt So my measurements verify what is in the i.MX data sheets. The current code sets the bit when negative edge (falling edge) is requested, which is wrong: #define VDCTRL0_DOTCLK_ACT_FALLING (1 << 25) ... if (bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE) vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING; Not sure what is going on with your display, maybe the datasheet is just wrong (it requires DRM_BUS_FLAG_PIXDATA_NEGEDGE in fact) or it is some other artifact. -- Stefan
[RFC] Using DC in amdgpu for upcoming GPU
On Thu, Dec 8, 2016 at 10:34 AM, Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote:
>> Hi Daniel,
>>
>> just a quick clarification in-line about "validation" inside atomic_commit.
>>
>> On 2016-12-08 04:59 AM, Daniel Vetter wrote:
>> > Hi Harry,
>> >
>> > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
>> > > We propose to use the Display Core (DC) driver for display support on
>> > > AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In
>> > > order to
>> > > avoid a flag day the plan is to only support uGPU initially and
>> > > transition
>> > > to older ASICs gradually.
>> > >
>> > > The DC component has received extensive testing within AMD for DCE8, 10,
>> > > and
>> > > 11 GPUs and is being prepared for uGPU. Support should be better than
>> > > amdgpu's current display support.
>> > >
>> > > * All of our QA effort is focused on DC
>> > > * All of our CQE effort is focused on DC
>> > > * All of our OEM preloads and custom engagements use DC
>> > > * DC behavior mirrors what we do for other OSes
>> > >
>> > > The new asic utilizes a completely re-designed atom interface, so we
>> > > cannot
>> > > easily leverage much of the existing atom-based code.
>> > >
>> > > We've introduced DC to the community earlier in 2016 and received a fair
>> > > amount of feedback. Some of what we've addressed so far are:
>> > >
>> > > * Self-contain ASIC specific code. We did a bunch of work to pull
>> > >common sequences into dc/dce and leave ASIC specific code in
>> > >separate folders.
>> > > * Started to expose AUX and I2C through generic kernel/drm
>> > >functionality and are mostly using that. Some of that code is still
>> > >needlessly convoluted. This cleanup is in progress.
>> > > * Integrated Dave and Jeromeâs work on removing abstraction in bios
>> > >parser.
>> > > * Retire adapter service and asic capability
>> > > * Remove some abstraction in GPIO
>> > >
>> > > Since a lot of our code is shared with pre- and post-silicon validation
>> > > suites changes need to be done gradually to prevent breakages due to a
>> > > major
>> > > flag day. This, coupled with adding support for new asics and lots of
>> > > new
>> > > feature introductions means progress has not been as quick as we would
>> > > have
>> > > liked. We have made a lot of progress none the less.
>> > >
>> > > The remaining concerns that were brought up during the last review that
>> > > we
>> > > are working on addressing:
>> > >
>> > > * Continue to cleanup and reduce the abstractions in DC where it
>> > >makes sense.
>> > > * Removing duplicate code in I2C and AUX as we transition to using the
>> > >DRM core interfaces. We can't fully transition until we've helped
>> > >fill in the gaps in the drm core that we need for certain features.
>> > > * Making sure Atomic API support is correct. Some of the semantics of
>> > >the Atomic API were not particularly clear when we started this,
>> > >however, that is improving a lot as the core drm documentation
>> > >improves. Getting this code upstream and in the hands of more
>> > >atomic users will further help us identify and rectify any gaps we
>> > >have.
>> > >
>> > > Unfortunately we cannot expose code for uGPU yet. However refactor /
>> > > cleanup
>> > > work on DC is public. We're currently transitioning to a public patch
>> > > review. You can follow our progress on the amd-gfx mailing list. We value
>> > > community feedback on our work.
>> > >
>> > > As an appendix I've included a brief overview of the how the code
>> > > currently
>> > > works to make understanding and reviewing the code easier.
>> > >
>> > > Prior discussions on DC:
>> > >
>> > > *
>> > > https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html
>> > > *
>> > > https://lists.freedesktop.org/archives/dri-devel/2016-February/100524.html
>> > >
>> > > Current version of DC:
>> > >
>> > > *
>> > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
>> > >
>> > > Once Alex pulls in the latest patches:
>> > >
>> > > *
>> > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
>> > >
>> > > Best Regards,
>> > > Harry
>> > >
>> > >
>> > >
>> > > *** Appendix: A Day in the Life of a Modeset ***
>> > >
>> > >
>> > > Below is a high-level overview of a modeset with dc. Some of this might
>> > > be a
>> > > little out-of-date since it's based on my XDC presentation but it should
>> > > be
>> > > more-or-less the same.
>> > >
>> > > amdgpu_dm_atomic_commit()
>> > > {
>> > > /* setup atomic state */
>> > > drm_atomic_helper_prepare_planes(dev, state);
>> > > drm_atomic_helper_swap_state(dev, state);
>> > > drm_atomic_helper_update_legacy_modeset_state(dev, state);
>> > >
>> > > /* cre
[PATCH] linux/types.h: enable endian checks for all sparse builds
On Thu, 8 Dec 2016 04:29:39 +0200 "Michael S. Tsirkin" wrote: > By now, linux is mostly endian-clean. Enabling endian-ness > checks for everyone produces about 200 new sparse warnings for me - > less than 10% over the 2000 sparse warnings already there. Out of curiousity: Where do most of those warnings show up? > > Not a big deal, OTOH enabling this helps people notice > they are introducing new bugs. > > So let's just drop __CHECK_ENDIAN__. Follow-up patches > can drop distinction between __bitwise and __bitwise__. > > Cc: Linus Torvalds > Suggested-by: Christoph Hellwig > Signed-off-by: Michael S. Tsirkin > --- > > Linus, could you ack this for upstream? If yes I'll > merge through my tree as a replacement for enabling > this just for virtio. > > include/uapi/linux/types.h | 4 > 1 file changed, 4 deletions(-) > > diff --git a/include/uapi/linux/types.h b/include/uapi/linux/types.h > index acf0979..41e5914 100644 > --- a/include/uapi/linux/types.h > +++ b/include/uapi/linux/types.h > @@ -23,11 +23,7 @@ > #else > #define __bitwise__ > #endif > -#ifdef __CHECK_ENDIAN__ > #define __bitwise __bitwise__ > -#else > -#define __bitwise > -#endif > > typedef __u16 __bitwise __le16; > typedef __u16 __bitwise __be16; FWIW, I like this better than just enabling it for the virtio code.
[RFC] Using DC in amdgpu for upcoming GPU
putation code between check and commit doesn't get out of sync. > > > >> As for the rest, I hear you and appreciate your feedback. Let me get back > >> to > >> you on that later. > > Just an added note on that: I do think that there's some driver teams > > who've managed to pull a shared codebase between validation and upstream > > linux (iirc some of the intel wireless drivers work like that). But it > > requires careful aligning of everything, and with something fast-moving > > like drm it might become real painful and not really worth it. So not > > outright rejecting DC (and the code sharing you want to achieve with it) > > as an idea here. > > I used to have examples of such a things for other network drivers as > well, but right now I can't find them of hand. Leave me a note if you > need more info on existing things. > > A good idea might as well be to take a look at drivers shared between > Linux and BSD as well, cause both code bases are usually public > available and you can see what changes during porting and what stays the > same. Although their core drivers are tightly the coupled with a given OS, the Chelsio 10GigE and Intel ethernet drivers in general have large amounts of platform agnostic code coupled with a fairly minimal OS abstraction layer. I don't know how analogous to DAL/DC this is. However, I will say that the Chelsio driver was an order of magnitude easier to port to FreeBSD and the end result much better than Solarflare's which felt obliged to not have any separation of concerns. -M
[PATCH] linux/types.h: enable endian checks for all sparse builds
On Thu, Dec 08, 2016 at 06:38:11AM +, Bart Van Assche wrote: > On 12/07/16 21:54, Michael S. Tsirkin wrote: > > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote: > >> Additionally, there are notable exceptions to the rule that most drivers > >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it > >> would remain possible to check such drivers with sparse without enabling > >> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__ > >> into e.g. #ifndef __DONT_CHECK_ENDIAN__? > > > > The right thing is probably just to fix these, isn't it? > > Until then, why not just ignore the warnings? > > Neither option is realistic. With endian-checking enabled the qla2xxx > driver triggers so many warnings that it becomes a real challenge to > filter the non-endian warnings out manually: > > $ for f in "" CF=-D__CHECK_ENDIAN__; do make M=drivers/scsi/qla2xxx C=2\ > $f | &grep -c ': warning:'; done > 4 > 752 > > If you think it would be easy to fix the endian warnings triggered by > the qla2xxx driver, you are welcome to try to fix these. Please don't let one crappy, obviously broken, driver prevent this good change from happening which will help ensure that the rest of the kernel (i.e. 99% of it) can be easily tested and fixed for endian issues. Sounds like you should just fix the driver up if it has so many problems, and it annoys you so much that you have to filter out some warnings to see the others :) thanks, greg k-h
[PATCH] drm: Update drm_device docs about embedding.
On Thu, Dec 08, 2016 at 12:53:07PM +0100, Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 10:50:48AM +, Chris Wilson wrote: > > On Thu, Dec 08, 2016 at 11:28:47AM +0100, Daniel Vetter wrote: > > > It's supported now! Spotted while reviewing Chris' patch to add a > > > release hook. > > > > > > Cc: Chris Wilson > > > Signed-off-by: Daniel Vetter > > > --- > > > drivers/gpu/drm/drm_drv.c | 11 +++ > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > > index f74b7d06ec01..4ec61ac27477 100644 > > > --- a/drivers/gpu/drm/drm_drv.c > > > +++ b/drivers/gpu/drm/drm_drv.c > > > @@ -323,9 +323,8 @@ void drm_minor_release(struct drm_minor *minor) > > > * historical baggage. Hence use the reference counting provided by > > > * drm_dev_ref() and drm_dev_unref() only carefully. > > > * > > > - * Also note that embedding of &drm_device is currently not (yet) > > > supported (but > > > - * it would be easy to add). Drivers can store driver-private data in the > > > - * dev_priv field of &drm_device. > > > + * It is recommended that drivers embed struct &drm_device into their > > > own device > > > + * structure, which is supported through drm_dev_init(). > > > */ > > > > > > /** > > > @@ -462,7 +461,11 @@ static void drm_fs_inode_free(struct inode *inode) > > > * Note that for purely virtual devices @parent can be NULL. > > > * > > > * Drivers that do not want to allocate their own device struct > > > - * embedding struct &drm_device can call drm_dev_alloc() instead. > > > + * embedding struct &drm_device can call drm_dev_alloc() instead. For > > > drivers > > > + * that do embed struct &drm_device it must be placed first in the > > > overall > > > + * structure, and the overall structure must be allocated using > > > kmalloc(): The > > > + * drm core's release function unconditionally calls kfree() on the @dev > > > pointer > > > + * when the final reference is released. > > > > Hmm, the privates are getting pretty big (drm_i915_private fits inside > > malloc-32678). We should start considering using drm_free_large() instead > > as that more or less work transparently and allows fallback to vmalloc. > > Yeah, I wondered whether your new ->release hook should be the very last > thing in drm_dev_release, and that it would replace the final kfree. Then > we could do custom stuff in drivers that have an oversized dev struct ;-) Also considered that, placing it first helped with the onion of dev = kmalloc() drm_dev_init(dev, &driver); i915_driver_init(dev); ... So we would teardown i915, then drm, then free. For now saying that it can either be kmalloc or vmalloc and having if (is_virt) vfree() else kfree() should suffice. That is until we start allocating new devices so regularly that they want a dedicated per-cpu slab ;) -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 4/4] drm/vc4: Don't use drm_put_dev
vc4 already has a proper load sequence, but the unload one needed some
fixups: First unregister, and last drop the final ref.
Cc: Eric Anholt
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 1dab9e5b3689..bfaf4e36f7ae 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -277,12 +277,14 @@ static void vc4_drm_unbind(struct device *dev)
struct drm_device *drm = platform_get_drvdata(pdev);
struct vc4_dev *vc4 = to_vc4_dev(drm);
+ drm_dev_unregister(drm);
+
if (vc4->fbdev)
drm_fbdev_cma_fini(vc4->fbdev);
drm_mode_config_cleanup(drm);
- drm_put_dev(drm);
+ drm_dev_unref(drm);
}
static const struct component_master_ops vc4_drm_ops = {
--
2.10.2
[PATCH 3/4] drm/mediatek: don't use drm_put_dev
fsl is already fully demidlayered in the probe function, but for
convenience stuck with drm_put_dev. Call the unregister/unref parts
separately, to make sure this driver works correct.
Cc: Philipp Zabel
Cc: CK Hu
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 4b7fe7eaec01..b5f88e6d078e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -321,7 +321,8 @@ static void mtk_drm_unbind(struct device *dev)
{
struct mtk_drm_private *private = dev_get_drvdata(dev);
- drm_put_dev(private->drm);
+ drm_dev_unregister(private->drm);
+ drm_dev_unref(private->drm);
private->drm = NULL;
}
--
2.10.2
[PATCH 2/4] drm/fsl: don't use drm_put_dev
fsl is already fully demidlayered in the probe function, but for convenience stuck with drm_put_dev. Call the unregister/unref parts separately, to make sure this driver works correct. Cc: Stefan Agner Signed-off-by: Daniel Vetter --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c index 320e4728c9b9..d36bf4f8b3de 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c @@ -426,7 +426,8 @@ static int fsl_dcu_drm_remove(struct platform_device *pdev) clk_disable_unprepare(fsl_dev->clk); clk_unregister(fsl_dev->pix_clk); - drm_put_dev(fsl_dev->drm); + drm_dev_unregister(fsl_dev->drm); + drm_dev_unref(fsl_dev->drm); return 0; } -- 2.10.2
[PATCH 1/4] drm/etnaviv: Use drm_dev_unref, not drm_put_dev
drm_put_dev is the old midlayer-broken device cleanup function, but
etnaviv has a proper unbind function which first unregisters and then
drops the final reference. No functional change since
drm_dev_unregister happens to be idempotent.
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 00368b14d08d..30d70ed143f7 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -592,7 +592,7 @@ static void etnaviv_unbind(struct device *dev)
drm->dev_private = NULL;
kfree(priv);
- drm_put_dev(drm);
+ drm_dev_unref(drm);
}
static const struct component_master_ops etnaviv_master_ops = {
--
2.10.2
[RFC PATCH 0/3] staging: remove fbdev drivers
On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > Hi, > > Since the fbdev framework is in maintenance mode and all new display drivers > should be made with the DRM framework, remove the fbdev drivers from staging. > > Note: the patches are created with git format-patch -D, so they can't be > applied. Only for review. I missed the discussion where this decision was made, I admit I am unimpressed by it. DRM drivers don't strike me as suitable for small/slow cores with dumb framebuffers or simple 2D only accel, such as the one found in the ASpeed BMCs. With drmfb you basically have to shadow everything into memory & copy over everything, and locks you out of simple 2D accel. For a simple text console the result is orders of magnitude slower and memory hungry than a simple fbdev. At least that was the case last I looked at the DRM stuff with Dave, maybe things have changed... Not everything has a powerful 3D GPU. Ben.
