Re: [Intel-gfx] [PATCH 1/3] drm/dp: Add definition for Display Control DPCD Registers capability size
On Wed, 30 Mar 2016, Yetunde Adebisi wrote: > This is used when reading Display Control capability Registers on the sink > device. > > cc: Jani Nikula > cc: dri-de...@lists.freedesktop.org > Signed-off-by: Yetunde Adebisi Reviewed-by: Jani Nikula > --- > include/drm/drm_dp_helper.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 1252108..92d9a52 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -621,6 +621,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 > link_status[DP_LINK_STATUS_SI > #define DP_BRANCH_OUI_HEADER_SIZE0xc > #define DP_RECEIVER_CAP_SIZE 0xf > #define EDP_PSR_RECEIVER_CAP_SIZE2 > +#define EDP_DISPLAY_CTL_CAP_SIZE 3 > > void drm_dp_link_train_clock_recovery_delay(const u8 > dpcd[DP_RECEIVER_CAP_SIZE]); > void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]); -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 08/46] hwmon: pwm-fan: use pwm_get_args() where appropriate
Hi Guenter,
On Wed, 30 Mar 2016 15:52:44 -0700
Guenter Roeck wrote:
> On Wed, Mar 30, 2016 at 10:03:31PM +0200, Boris Brezillon wrote:
> > The PWM framework has clarified the concept of reference PWM config
> > (the platform dependent config retrieved from the DT or the PWM
> > lookup table) and real PWM state.
> >
> > Use pwm_get_args() when the PWM user wants to retrieve this reference
> > config and not the current state.
> >
> > This is part of the rework allowing the PWM framework to support
> > hardware readout and expose real PWM state even when the PWM has
> > just been requested (before the user calls pwm_config/enable/disable()).
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > drivers/hwmon/pwm-fan.c | 19 +--
> > 1 file changed, 13 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> > index 3e23003..82c5656 100644
> > --- a/drivers/hwmon/pwm-fan.c
> > +++ b/drivers/hwmon/pwm-fan.c
> > @@ -40,15 +40,18 @@ struct pwm_fan_ctx {
> >
> > static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
> > {
> > + struct pwm_args pargs = { };
>
> Hi Boris,
>
> I guess I am missing some context; sorry for that. Unfortunately,
> I did not easily find an explanation, so please bear with me.
>
> Two questions: Why do we need a local copy of struct pwm_args instead
> of a pointer to it ? If it can change while being used, isn't it
> inconsistent anyway ?
It cannot change after pwm_get() is called. For the reason behind
prototype: I just followed the Thierry's proposal, but I'm perfectly
fine returning a const struct pwm_args pointer intead of passing
pwm_args as a parameter.
Thierry, what's your opinion?
>
> Also, assuming the local copy is necessary, why initialize pargs ?
> After all, pwm_get_args() just overwrites it.
It's a leftover from a previous version where pwm_get_args was
implemented this way:
static inline void pwm_get_args(pwm, args)
{
if (pwm)
*args = pwm->args
}
and this implementation was generating a lot of 'uninitialized
variable' warnings.
I just decided to drop the 'if (pwm)' test, because, IMO, this
should be checked way before calling pwm_get_args() is called.
Anyway, apparently I forgot to modify a few patches after this
modification.
Thanks for the review.
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 05/46] pwm: introduce the pwm_args concept
On Wed, 30 Mar 2016 14:55:10 -0700
Stephen Boyd wrote:
> On 03/30, Boris Brezillon wrote:
> > @@ -74,6 +74,23 @@ enum pwm_polarity {
> > PWM_POLARITY_INVERSED,
> > };
> >
> > +/**
> > + * struct pwm_args - PWM arguments
> > + * @period: reference period
> > + * @polarity: reference polarity
> > + *
> > + * This structure describe board-dependent arguments attached to a PWM
>
> s/describe/describes/
>
> > + * device. Those arguments are usually retrieved from the PWM lookup table
> > or
> > + * DT definition.
> > + * This should not be confused with the PWM state: PWM args not
> > representing
>
> s/not representing/don't represent/ ?
>
> > + * the current PWM state, but the configuration the PWM user plan to use
>
> s/plan/plans/
>
> > + * on this PWM device.
> > + */
> > +struct pwm_args {
> > + unsigned int period;
> > + enum pwm_polarity polarity;
> > +};
> > +
>
Will fix these errors.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 10/46] leds: pwm: use pwm_get_args() where appropriate
Hi Boris,
On 03/30/2016 10:03 PM, Boris Brezillon wrote:
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon
---
drivers/leds/leds-pwm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 4783bac..b48231c 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -91,6 +91,7 @@ static int led_pwm_add(struct device *dev, struct
led_pwm_priv *priv,
struct led_pwm *led, struct device_node *child)
{
struct led_pwm_data *led_data = &priv->leds[priv->num_leds];
+ struct pwm_args pargs = { };
int ret;
led_data->active_low = led->active_low;
@@ -117,7 +118,8 @@ static int led_pwm_add(struct device *dev, struct
led_pwm_priv *priv,
else
led_data->cdev.brightness_set_blocking = led_pwm_set_blocking;
- led_data->period = pwm_get_period(led_data->pwm);
+ pwm_get_args(led_data->pwm, &pargs);
+ led_data->period = pargs.period;
if (!led_data->period && (led->pwm_period_ns > 0))
led_data->period = led->pwm_period_ns;
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] system hang on ILK/SNB/IVB
Hello Lukas, The problem with the results in your link is that there is no HSW, ILK, IVB or SNB results. This might give the impression that everything is well. Most damning is lack of HSW-gt2 and SNB-dellxps: those machines hang on to APC, and have run quite stably for every Patchwork run. The case isn't strong enough yet that series should fail if either of those won't run, but it might be so in future. Tomi On Wednesday 30 March 2016 23:35:08 Lukas Wunner wrote: > Hi Gabriel, > > On Wed, Mar 30, 2016 at 08:20:26PM +0300, Gabriel Feceoru wrote: > > This commit causes a hang while running kms suspend tests > > (kms_pipe_crc_basic@suspend-read-crc-pipe-*) on ILK/SNB/IVB, affecting CI. > > This happened with v1 but not with v2 of the patch. > Please check if somehow v1 ended up in your tree. > > v2 passed CI fine, save for one warning not caused by the patch: > https://patchwork.freedesktop.org/series/4068/ > > For comparison, this was v1: > https://patchwork.freedesktop.org/patch/75840/ > > Best regards, > > Lukas > > > Probably the same problem with the one in v2, but on older HW. > > > > > > commit a7442b93cf32c1e1ddb721a26cd1f92302e2a222 > > Author: Lukas Wunner > > Date: Wed Mar 9 12:52:53 2016 +0100 > > > > drm/i915: Fix races on fbdev > > > > The ->lastclose callback invokes intel_fbdev_restore_mode() and has > > been witnessed to run before intel_fbdev_initial_config_async() > > has finished. > > > > We might likewise receive hotplug events before we've had a chance to > > fully set up the fbdev. > > > > Fix by waiting for the asynchronous thread to finish. > > > > v2: > > An async_synchronize_full() was also added to > > intel_fbdev_set_suspend() > > in v1 which turned out to be entirely gratuitous. It caused a deadlock > > on suspend (discovered by CI, thanks to Damien Lespiau and Tomi > > Sarvela > > for CI support) and was unnecessary since a device is never suspended > > until its ->probe callback (and all asynchronous tasks it scheduled) > > have finished. See dpm_prepare(), which calls wait_for_device_probe(), > > which calls async_synchronize_full(). > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580 > > Reported-by: Gustav Fägerlind > > Reported-by: "Li, Weinan Z" > > Cc: Chris Wilson > > Cc: sta...@vger.kernel.org > > Signed-off-by: Lukas Wunner > > Signed-off-by: Daniel Vetter > > Link: > > http://patchwork.freedesktop.org/patch/msgid/20160309115147.67B2B6E0D > > 3...@gabe.freedesktop.org> > > Regards, > > Gabriel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Add Backlight Control using DPCD for eDP connectors (v8)
On Wed, 30 Mar 2016, Yetunde Adebisi wrote:
> This patch adds support for eDP backlight control using DPCD registers to
> backlight hooks in intel_panel.
>
> It checks for backlight control over AUX channel capability and sets up
> function pointers to get and set the backlight brightness level if
> supported.
>
> v2: Moved backlight functions from intel_dp.c into a new file
> intel_dp_aux_backlight.c. Also moved reading of eDP display control
> registers to intel_dp_get_dpcd
>
> v3: Correct some formatting mistakes
>
> v4: Updated to use AUX backlight control if PWM control is not possible
> (Jani)
> v5: Moved call to initialize backlight registers to dp_aux_setup_backlight
> v6: Check DP_EDP_BACKLIGHT_PIN_ENABLE_CAP is disabled before setting up AUX
> backlight control. To fix BLM_PWM_ENABLE igt test warnings on bdw_ultra
> v7: Add enable_dpcd_backlight module parameter.
> v8: Rebase onto latest drm-intel-nightly branch
>
> This patch depends on http://patchwork.freedesktop.org/patch/64253/
>
> Cc: Bob Paauwe
> Cc: Jani Nikula
> Acked-by: Jesse Barnes
> Signed-off-by: Yetunde Adebisi
Please accept my apologies for taking so long to get back to
this. Overall looks fine, a couple of "mechanic" changes required (see
comments inline below).
As follow-up later on we should look at using vbt as in [1] to replace
the module parameter. This smells like the "panel driver
interface". Maybe.
BR,
Jani.
[1] http://mid.gmane.org/1459346623-30752-3-git-send-email-jani.nik...@intel.com
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/i915_params.c| 4 +
> drivers/gpu/drm/i915/i915_params.h| 1 +
> drivers/gpu/drm/i915/intel_dp.c | 17 ++-
> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 170
> ++
> drivers/gpu/drm/i915/intel_drv.h | 6 +
> drivers/gpu/drm/i915/intel_panel.c| 5 +
> 7 files changed, 198 insertions(+), 6 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 7ffb51b..11cc3e6 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -79,6 +79,7 @@ i915-y += dvo_ch7017.o \
> dvo_tfp410.o \
> intel_crt.o \
> intel_ddi.o \
> + intel_dp_aux_backlight.o \
> intel_dp_link_training.o \
> intel_dp_mst.o \
> intel_dp.o \
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 1779f02..383c076 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -58,6 +58,7 @@ struct i915_params i915 __read_mostly = {
> .guc_log_level = -1,
> .enable_dp_mst = true,
> .inject_load_failure = 0,
> + .enable_dpcd_backlight = false,
> };
>
> module_param_named(modeset, i915.modeset, int, 0400);
> @@ -210,3 +211,6 @@ MODULE_PARM_DESC(enable_dp_mst,
> module_param_named_unsafe(inject_load_failure, i915.inject_load_failure,
> uint, 0400);
> MODULE_PARM_DESC(inject_load_failure,
> "Force an error after a number of failure check points (0:disabled
> (default), N:force failure at the Nth failure check point)");
> +module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
> 0600);
> +MODULE_PARM_DESC(enable_dpcd_backlight,
> + "Enable support for DPCD backlight control (default:false)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 02bc278..65e73dd 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -61,6 +61,7 @@ struct i915_params {
> bool verbose_state_checks;
> bool nuclear_pageflip;
> bool enable_dp_mst;
> + bool enable_dpcd_backlight;
> };
>
> extern struct i915_params i915 __read_mostly;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3bdd8ba..9e9e7f1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3109,7 +3109,7 @@ static void chv_dp_post_pll_disable(struct
> intel_encoder *encoder)
> * Sinks are *supposed* to come up within 1ms from an off state, but we're
> also
> * supposed to retry 3 times per the spec.
> */
> -static ssize_t
> +ssize_t
> intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
> void *buffer, size_t size)
I'm going to have to ask you send another version dropping all the
changes to _wake, and switching to use the plain drm_dp_dpcd_read()
instead of intel_dp_dpcd_read_wake() all around. Otherwise, we'll
conflict badly with [2] getting merged.
[2] http://mid.gmane.org/1459175606-13875-1-git-send-email-cp...@redhat.com
> {
> @@ -3776,7 +3776,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct dr
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add backlight Control using DPCD registers for DP connectors
On Wed, 30 Mar 2016, Yetunde Adebisi wrote:
> This patch enables support for DPCD backlight control for DP connectors.
> The VESA spec defines DPCD backlight control only for eDP but some add-on
> cards like the Chrontel CH7511B DP-LVDS cards have the display control
> DPCD registers enabled.
> This patch registers a backlight device exposed via sysfs that controls the
> connected panel backlight by writing to DPCD registers on the CH7511B
> add-on card
I'm not convinced. Seems like a gross spec violating hack to work around
the issue that CH7511B is not configured as eDP in the first place.
BR,
Jani.
>
> Signed-off-by: Yetunde Adebisi
> ---
> drivers/gpu/drm/i915/intel_dp.c | 25
> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 7 ++
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_panel.c| 33
> +++
> 4 files changed, 57 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9e9e7f1..8bbfb7f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5631,6 +5631,30 @@ intel_dp_drrs_init(struct intel_connector
> *intel_connector,
> return downclock_mode;
> }
>
> +/*
> + * Called on DP connector initialization to check for aux backlight control
> + * capability on the sink device and if present, initialize it.
> + */
> +static void intel_dp_init_aux_backlight(struct intel_dp *intel_dp,
> + struct drm_connector *connector)
> +{
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> +
> + if (is_edp(intel_dp))
> + return;
> +
> + if (i915.enable_dpcd_backlight &&
> + (intel_dp_dpcd_read_wake(&intel_dp->aux,
> DP_EDP_DPCD_REV,
> + intel_dp->edp_dpcd,
> sizeof(intel_dp->edp_dpcd)) ==
> +
> sizeof(intel_dp->edp_dpcd)) &&
> +
> intel_dp_aux_init_backlight_funcs(intel_connector) == 0) {
> + intel_panel_setup_backlight(connector, INVALID_PIPE);
> +
> + intel_connector->panel.backlight.power =
> intel_dp_aux_backlight_power;
> + intel_connector->panel.backlight.enabled = true;
> + }
> +}
> +
> static bool intel_edp_init_connector(struct intel_dp *intel_dp,
>struct intel_connector *intel_connector)
> {
> @@ -5868,6 +5892,7 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> goto fail;
> }
>
> + intel_dp_init_aux_backlight(intel_dp, connector);
> intel_dp_add_properties(intel_dp, connector);
>
> /* For G4X desktop chip, PEG_BAND_GAP_DATA 3:0 must first be written
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index a5361d6..efa657f 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -168,3 +168,10 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *intel_connector)
>
> return 0;
> }
> +
> +void intel_dp_aux_backlight_power(struct intel_connector *connector,
> + bool enable)
> +{
> + set_aux_backlight_enable(enc_to_intel_dp(&connector->encoder->base),
> + enable);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 782a103..ab92e89 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1324,6 +1324,8 @@ ssize_t intel_dp_dpcd_read_wake(struct drm_dp_aux *aux,
> unsigned int offset,
>
> /* intel_dp_aux_backlight.c */
> int intel_dp_aux_init_backlight_funcs(struct intel_connector
> *intel_connector);
> +void intel_dp_aux_backlight_power(struct intel_connector *connector,
> + bool enable);
>
> /* intel_dp_mst.c */
> int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
> conn_id);
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index cdfcdad..d678e55 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1193,16 +1193,29 @@ static int intel_backlight_device_register(struct
> intel_connector *connector)
> else
> props.power = FB_BLANK_POWERDOWN;
>
> - /*
> - * Note: using the same name independent of the connector prevents
> - * registration of multiple backlight devices in the driver.
> - */
> - panel->backlight.device =
> - backlight_device_register("intel_backlight",
> - connector->base.kdev,
> - connector,
> -
[Intel-gfx] ✗ Fi.CI.BAT: failure for legacy gamma code cleanup
== Series Details == Series: legacy gamma code cleanup URL : https://patchwork.freedesktop.org/series/5037/ State : failure == Summary == Series 5037v1 legacy gamma code cleanup http://patchwork.freedesktop.org/api/1.0/series/5037/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:157 dwarn:1 dfail:0 fail:1 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-gt2 total:62 pass:56 dwarn:0 dfail:0 fail:0 skip:5 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 Results at /archive/results/CI_IGT_test/Patchwork_1743/ 0b513f37162f39401fe8fd2c1cb35b74212f367e drm-intel-nightly: 2016y-03m-31d-06h-04m-59s UTC integration manifest 4f0351f74b4a0949f9477348e69a194e39bb351e drm/tegra: Don't set a gamma table size 84b511bf9dc6ef362843c2b7a1cf852615ce1450 drm/qxl: Don't set a gamma table size 1fa7cea871f38dfc814d606381ef316fa2ae02cd drm/imx: Don't set a gamma table size f3fa1848b96d695ba4820da4b88dfb92d941a44b drm/virtio: Drop dummy gamma table support 9e2f624f1ec67a5d77b8324f642a9554a833485c drm/msm: Nuke dummy gamma_set/get functions 92e4dc00f2da245a954760c9b128b0c63e084009 drm/cirrus: Drop redundnant gamma size check 8652f4343171e7a4b9599cae27406be7f9d693fb drm/bochs: Drop fake gamma support 76ae578deb6d5f33a4fa4c00c70fb61b3f416246 drm/armada: Drop fb gamma_set/get functions 7ed0be65b1a77d09c37f80925d05d24843709a9b drm/fb-helper: Remove dead code in setcolreg 968022e5cae96de722d8a936950713437d9f6370 drm: Initialize a linear gamma table by default ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] system hang on ILK/SNB/IVB
On 31.03.2016 00:35, Lukas Wunner wrote: Hi Gabriel, On Wed, Mar 30, 2016 at 08:20:26PM +0300, Gabriel Feceoru wrote: This commit causes a hang while running kms suspend tests (kms_pipe_crc_basic@suspend-read-crc-pipe-*) on ILK/SNB/IVB, affecting CI. This happened with v1 but not with v2 of the patch. Please check if somehow v1 ended up in your tree. It's v2. Tomi already replied, meantime I also looked at the results. The current regression is for ILK/SNB/IVB only (v1 seemed to affect more platforms). Unfortunately these machines were not available when v2 was tested, so this couldn't be detected. Regards, Gabriel. v2 passed CI fine, save for one warning not caused by the patch: https://patchwork.freedesktop.org/series/4068/ For comparison, this was v1: https://patchwork.freedesktop.org/patch/75840/ Best regards, Lukas Probably the same problem with the one in v2, but on older HW. commit a7442b93cf32c1e1ddb721a26cd1f92302e2a222 Author: Lukas Wunner Date: Wed Mar 9 12:52:53 2016 +0100 drm/i915: Fix races on fbdev The ->lastclose callback invokes intel_fbdev_restore_mode() and has been witnessed to run before intel_fbdev_initial_config_async() has finished. We might likewise receive hotplug events before we've had a chance to fully set up the fbdev. Fix by waiting for the asynchronous thread to finish. v2: An async_synchronize_full() was also added to intel_fbdev_set_suspend() in v1 which turned out to be entirely gratuitous. It caused a deadlock on suspend (discovered by CI, thanks to Damien Lespiau and Tomi Sarvela for CI support) and was unnecessary since a device is never suspended until its ->probe callback (and all asynchronous tasks it scheduled) have finished. See dpm_prepare(), which calls wait_for_device_probe(), which calls async_synchronize_full(). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580 Reported-by: Gustav Fägerlind Reported-by: "Li, Weinan Z" Cc: Chris Wilson Cc: sta...@vger.kernel.org Signed-off-by: Lukas Wunner Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20160309115147.67b2b6e...@gabe.freedesktop.org Regards, Gabriel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 05/46] pwm: introduce the pwm_args concept
On Wed, 30 Mar 2016 14:55:10 -0700
Stephen Boyd wrote:
> On 03/30, Boris Brezillon wrote:
> > @@ -74,6 +74,23 @@ enum pwm_polarity {
> > PWM_POLARITY_INVERSED,
> > };
> >
> > +/**
> > + * struct pwm_args - PWM arguments
> > + * @period: reference period
> > + * @polarity: reference polarity
> > + *
> > + * This structure describe board-dependent arguments attached to a PWM
>
> s/describe/describes/
>
> > + * device. Those arguments are usually retrieved from the PWM lookup table
> > or
> > + * DT definition.
> > + * This should not be confused with the PWM state: PWM args not
> > representing
>
> s/not representing/don't represent/ ?
Yes, I meant "are not representing", but "don't represent" is fine.
>
> > + * the current PWM state, but the configuration the PWM user plan to use
>
> s/plan/plans/
>
> > + * on this PWM device.
> > + */
> > +struct pwm_args {
> > + unsigned int period;
> > + enum pwm_polarity polarity;
> > +};
> > +
>
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Unbind objects in shrinker only if device is runtime active
== Series Details == Series: drm/i915: Unbind objects in shrinker only if device is runtime active URL : https://patchwork.freedesktop.org/series/5038/ State : failure == Summary == Series 5038v1 drm/i915: Unbind objects in shrinker only if device is runtime active http://patchwork.freedesktop.org/api/1.0/series/5038/revisions/1/mbox/ bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:159 dwarn:0 dfail:0 fail:0 skip:37 hsw-gt2 total:13 pass:10 dwarn:0 dfail:0 fail:0 skip:2 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 Results at /archive/results/CI_IGT_test/Patchwork_1744/ 0b513f37162f39401fe8fd2c1cb35b74212f367e drm-intel-nightly: 2016y-03m-31d-06h-04m-59s UTC integration manifest 5796f9a3dc103e3fd59a4f87ce1472199e52e34e drm/i915: Unbind objects in shrinker only if device is runtime active ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 34/46] clk: pwm: switch to the atomic API
On 03/30, Boris Brezillon wrote:
> diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> index ebcd738..49ec5b1 100644
> --- a/drivers/clk/clk-pwm.c
> +++ b/drivers/clk/clk-pwm.c
> @@ -28,15 +28,29 @@ static inline struct clk_pwm *to_clk_pwm(struct clk_hw
> *hw)
> static int clk_pwm_prepare(struct clk_hw *hw)
> {
> struct clk_pwm *clk_pwm = to_clk_pwm(hw);
> + struct pwm_state pstate;
>
> - return pwm_enable(clk_pwm->pwm);
> + pwm_get_state(clk_pwm->pwm, &pstate);
> + if (pstate.enabled)
> + return 0;
> +
> + pstate.enabled = true;
> +
> + return pwm_apply_state(clk_pwm->pwm, &pstate);
This doesn't seem atomic anymore if we're checking the state and
then not calling apply_state if it's already enabled. But I
assume this doesn't matter because we "own" the pwm here?
Otherwise I would think this would be unconditional apply state
and duplicates would be ignored in the pwm framework.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 05/46] pwm: introduce the pwm_args concept
On 03/30, Boris Brezillon wrote:
> @@ -74,6 +74,23 @@ enum pwm_polarity {
> PWM_POLARITY_INVERSED,
> };
>
> +/**
> + * struct pwm_args - PWM arguments
> + * @period: reference period
> + * @polarity: reference polarity
> + *
> + * This structure describe board-dependent arguments attached to a PWM
s/describe/describes/
> + * device. Those arguments are usually retrieved from the PWM lookup table or
> + * DT definition.
> + * This should not be confused with the PWM state: PWM args not representing
s/not representing/don't represent/ ?
> + * the current PWM state, but the configuration the PWM user plan to use
s/plan/plans/
> + * on this PWM device.
> + */
> +struct pwm_args {
> + unsigned int period;
> + enum pwm_polarity polarity;
> +};
> +
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 07/46] clk: pwm: use pwm_get_args() where appropriate
On 03/30, Boris Brezillon wrote: > The PWM framework has clarified the concept of reference PWM config > (the platform dependent config retrieved from the DT or the PWM > lookup table) and real PWM state. > > Use pwm_get_args() when the PWM user wants to retrieve this reference > config and not the current state. > > This is part of the rework allowing the PWM framework to support > hardware readout and expose real PWM state even when the PWM has > just been requested (before the user calls pwm_config/enable/disable()). > > Signed-off-by: Boris Brezillon > --- Acked-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 26/46] pwm: sun4i: implement hardware readout
On 30/03/2016 at 22:03:49 +0200, Boris Brezillon wrote :
> Implement ->get_state() instead of only initializing the polarity in
> the probe function.
>
> This implementation also takes care of keeping the PWM clk enabled if at
> least one of the PWM exported by the PWM chip is already enabled, which
> should prevent glitches.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Alexandre Belloni
> ---
> drivers/pwm/pwm-sun4i.c | 74
> -
> 1 file changed, 55 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 03a99a5..34cb296 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -252,11 +252,65 @@ static void sun4i_pwm_disable(struct pwm_chip *chip,
> struct pwm_device *pwm)
> clk_disable_unprepare(sun4i_pwm->clk);
> }
>
> +static void sun4i_pwm_get_state(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + struct pwm_state *pstate)
> +{
> + struct sun4i_pwm_chip *sun4i_pwm = to_sun4i_pwm_chip(chip);
> + unsigned int clk_rate = clk_get_rate(sun4i_pwm->clk);
> + int prescaler, prescalerid;
> + int ret;
> + u32 val;
> +
> + ret = clk_prepare_enable(sun4i_pwm->clk);
> + if (ret) {
> + dev_err(chip->dev, "Failed to enable PWM clock");
> + return;
> + }
> +
> + val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> + if (val & BIT_CH(PWM_ACT_STATE, pwm->hwpwm))
> + pstate->polarity = PWM_POLARITY_INVERSED;
> + else
> + pstate->polarity = PWM_POLARITY_NORMAL;
> +
> + if ((val & BIT_CH(PWM_EN, pwm->hwpwm)) &&
> + (val & BIT_CH(PWM_CLK_GATING, pwm->hwpwm)))
> + pstate->enabled = true;
> + else
> + pstate->enabled = false;
> +
> + pstate->period = 0;
> + pstate->duty_cycle = 0;
> + prescalerid = (val >> (PWMCH_OFFSET * pwm->hwpwm)) & PWM_PRESCAL_MASK;
> + prescaler = prescaler_table[prescalerid];
> + if (prescaler) {
> + u64 timens;
> +
> + clk_rate /= prescaler;
> +
> + val = sun4i_pwm_readl(sun4i_pwm, PWM_CH_PRD(pwm->hwpwm));
> +
> + timens = ((val >> 16) & PWM_PRD_MASK) + 1;
> + timens *= NSEC_PER_SEC;
> + do_div(timens, clk_rate);
> + pstate->period = timens;
> +
> + timens = val & PWM_DTY_MASK;
> + timens *= NSEC_PER_SEC;
> + do_div(timens, clk_rate);
> + pstate->duty_cycle = timens;
> + }
> +
> + clk_disable_unprepare(sun4i_pwm->clk);
> +}
> +
> static const struct pwm_ops sun4i_pwm_ops = {
> .config = sun4i_pwm_config,
> .set_polarity = sun4i_pwm_set_polarity,
> .enable = sun4i_pwm_enable,
> .disable = sun4i_pwm_disable,
> + .get_state = sun4i_pwm_get_state,
> .owner = THIS_MODULE,
> };
>
> @@ -307,8 +361,7 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
> {
> struct sun4i_pwm_chip *pwm;
> struct resource *res;
> - u32 val;
> - int i, ret;
> + int ret;
> const struct of_device_id *match;
>
> match = of_match_device(sun4i_pwm_dt_ids, &pdev->dev);
> @@ -345,24 +398,7 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, pwm);
>
> - ret = clk_prepare_enable(pwm->clk);
> - if (ret) {
> - dev_err(&pdev->dev, "failed to enable PWM clock\n");
> - goto clk_error;
> - }
> -
> - val = sun4i_pwm_readl(pwm, PWM_CTRL_REG);
> - for (i = 0; i < pwm->chip.npwm; i++)
> - if (!(val & BIT_CH(PWM_ACT_STATE, i)))
> - pwm_set_polarity(&pwm->chip.pwms[i],
> - PWM_POLARITY_INVERSED);
> - clk_disable_unprepare(pwm->clk);
> -
> return 0;
> -
> -clk_error:
> - pwmchip_remove(&pwm->chip);
> - return ret;
> }
>
> static int sun4i_pwm_remove(struct platform_device *pdev)
> --
> 2.5.0
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dma-buf: Release module reference on creation failure
If we fail to create the anon file, we need to remember to release the
module reference on the owner.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 4a2c07ee6677..6f0f0b10a241 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -333,6 +333,7 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
struct reservation_object *resv = exp_info->resv;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
+ int ret;
if (!exp_info->resv)
alloc_size += sizeof(struct reservation_object);
@@ -356,8 +357,8 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
dmabuf = kzalloc(alloc_size, GFP_KERNEL);
if (!dmabuf) {
- module_put(exp_info->owner);
- return ERR_PTR(-ENOMEM);
+ ret = -ENOMEM;
+ goto free_module;
}
dmabuf->priv = exp_info->priv;
@@ -378,8 +379,8 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf,
exp_info->flags);
if (IS_ERR(file)) {
- kfree(dmabuf);
- return ERR_CAST(file);
+ ret = PTR_ERR(file);
+ goto free_dmabuf;
}
file->f_mode |= FMODE_LSEEK;
@@ -393,6 +394,12 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
mutex_unlock(&db_list.lock);
return dmabuf;
+
+free_dmabuf:
+ kfree(dmabuf);
+free_module:
+ module_put(exp_info->owner);
+ return ERR_PTR(ret);
}
EXPORT_SYMBOL_GPL(dma_buf_export);
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 45/46] drm: i915: switch to the atomic PWM API
On Thursday 31 March 2016 12:04 PM, Jani Nikula wrote:
[aggressively trimmed the recipient list, can't seem to be able to send
this otherwise]
On Wed, 30 Mar 2016, Boris Brezillon wrote:
pwm_config/enable/disable() have been deprecated and should be replaced
by pwm_apply_state().
Signed-off-by: Boris Brezillon
Reviewed-by: Jani Nikula
Cc: Shobhit, any additional comments?
Looks good to me.
Reviewed-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_panel.c | 39 +-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 21ee647..b86bd20 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -538,10 +538,10 @@ static u32 bxt_get_backlight(struct intel_connector
*connector)
static u32 pwm_get_backlight(struct intel_connector *connector)
{
struct intel_panel *panel = &connector->panel;
- int duty_ns;
+ struct pwm_state pstate;
- duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
- return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
+ pwm_get_state(panel->backlight.pwm, &pstate);
+ return DIV_ROUND_UP(pstate.duty_cycle * 100, CRC_PMIC_PWM_PERIOD_NS);
}
static u32 intel_panel_get_backlight(struct intel_connector *connector)
@@ -630,9 +630,12 @@ static void bxt_set_backlight(struct intel_connector
*connector, u32 level)
static void pwm_set_backlight(struct intel_connector *connector, u32 level)
{
struct intel_panel *panel = &connector->panel;
- int duty_ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+ struct pwm_state pstate;
- pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
+ pwm_get_state(panel->backlight.pwm, &pstate);
+ pstate.duty_cycle = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+ pstate.period = CRC_PMIC_PWM_PERIOD_NS;
+ pwm_apply_state(panel->backlight.pwm, &pstate);
}
static void
@@ -801,11 +804,15 @@ static void bxt_disable_backlight(struct intel_connector
*connector)
static void pwm_disable_backlight(struct intel_connector *connector)
{
struct intel_panel *panel = &connector->panel;
+ struct pwm_state pstate;
/* Disable the backlight */
- pwm_config(panel->backlight.pwm, 0, CRC_PMIC_PWM_PERIOD_NS);
+ pwm_get_state(panel->backlight.pwm, &pstate);
+ pstate.duty_cycle = 0;
+ pwm_apply_state(panel->backlight.pwm, &pstate);
usleep_range(2000, 3000);
- pwm_disable(panel->backlight.pwm);
+ pstate.enabled = false;
+ pwm_apply_state(panel->backlight.pwm, &pstate);
}
void intel_panel_disable_backlight(struct intel_connector *connector)
@@ -1068,8 +1075,11 @@ static void bxt_enable_backlight(struct intel_connector
*connector)
static void pwm_enable_backlight(struct intel_connector *connector)
{
struct intel_panel *panel = &connector->panel;
+ struct pwm_state pstate;
- pwm_enable(panel->backlight.pwm);
+ pwm_get_state(panel->backlight.pwm, &pstate);
+ pstate.enabled = true;
+ pwm_apply_state(panel->backlight.pwm, &pstate);
intel_panel_actually_set_backlight(connector, panel->backlight.level);
}
@@ -1630,6 +1640,7 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
{
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = &connector->panel;
+ struct pwm_state pstate;
int retval;
/* Get the PWM chip for backlight control */
@@ -1640,8 +1651,10 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
return -ENODEV;
}
- retval = pwm_config(panel->backlight.pwm, CRC_PMIC_PWM_PERIOD_NS,
- CRC_PMIC_PWM_PERIOD_NS);
+ pwm_get_state(panel->backlight.pwm, &pstate);
+ pstate.period = CRC_PMIC_PWM_PERIOD_NS;
+ pstate.duty_cycle = CRC_PMIC_PWM_PERIOD_NS;
+ retval = pwm_apply_state(panel->backlight.pwm, &pstate);
if (retval < 0) {
DRM_ERROR("Failed to configure the pwm chip\n");
pwm_put(panel->backlight.pwm);
@@ -1651,9 +1664,9 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
panel->backlight.min = 0; /* 0% */
panel->backlight.max = 100; /* 100% */
- panel->backlight.level = DIV_ROUND_UP(
-pwm_get_duty_cycle(panel->backlight.pwm) * 100,
-CRC_PMIC_PWM_PERIOD_NS);
+ pwm_get_state(panel->backlight.pwm, &pstate);
+ panel->backlight.level = DIV_ROUND_UP(pstate.duty_cycle * 100,
+ pstate.period);
panel->backlight.enabled = panel->backlight.level != 0;
return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://li
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: fix deadlock on lid open
== Series Details == Series: drm/i915: fix deadlock on lid open URL : https://patchwork.freedesktop.org/series/5025/ State : failure == Summary == Series 5025v1 drm/i915: fix deadlock on lid open http://patchwork.freedesktop.org/api/1.0/series/5025/revisions/1/mbox/ Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:159 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:8pass:6dwarn:0 dfail:0 fail:0 skip:1 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 Results at /archive/results/CI_IGT_test/Patchwork_1745/ 65496a062fd94984d5c6c6cfcee1caeac2d6e5f5 drm-intel-nightly: 2016y-03m-31d-08h-14m-17s UTC integration manifest ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/10] drm/tegra: Don't set a gamma table size
On Wed, Mar 30, 2016 at 11:51:25AM +0200, Daniel Vetter wrote: > tegra doesn't have any functions to set gamma tables, so this is > completely defunct. > > Not nice to lie to userspace, so let's stop! > > Cc: Thierry Reding > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/tegra/dc.c | 1 - > 1 file changed, 1 deletion(-) Applied, thanks. Thierry signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Update color management during vblank evasion.
On 30/03/16 17:41, Lionel Landwerlin wrote:
On 30/03/16 16:16, Maarten Lankhorst wrote:
Without this a vblank may occur between updating color management
and planes, which should be prevented.
intel_color_set_csc was called in update pipe config because the
handover from hardware may not have any csc set, which resulted
in a black screen. Because of this also update color management
during fastset.
Signed-off-by: Maarten Lankhorst
Tested-by: Lionel Landwerlin
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_display.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f913e5febf1..179461b45ce3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3222,9 +3222,6 @@ static void intel_update_pipe_config(struct
intel_crtc *crtc,
old_crtc_state->pipe_src_w, old_crtc_state->pipe_src_h,
pipe_config->pipe_src_w, pipe_config->pipe_src_h);
-if (HAS_DDI(dev))
-intel_color_set_csc(&pipe_config->base);
-
/*
* Update pipe size and adjust fitter if needed: the reason for
this is
* that in compute_mode_changes we check the native mode (not
the pfit
@@ -13603,18 +13600,6 @@ static int intel_atomic_commit(struct
drm_device *dev,
dev_priv->display.crtc_enable(crtc);
}
-if (!modeset &&
-crtc->state->active &&
-crtc->state->color_mgmt_changed) {
-/*
- * Only update color management when not doing
- * a modeset as this will be done by
- * crtc_enable already.
- */
-intel_color_set_csc(crtc->state);
-intel_color_load_luts(crtc->state);
-}
-
if (!modeset)
intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
@@ -13933,6 +13918,16 @@ static void intel_begin_crtc_commit(struct
drm_crtc *crtc,
if (modeset)
return;
+if (crtc->state->color_mgmt_changed ||
to_intel_crtc_state(crtc->state)->update_pipe) {
+/*
+ * Only update color management when not doing
+ * a modeset as this will be done by
+ * crtc_enable already.
+ */
I guess we can drop this comment.
+ intel_color_set_csc(crtc->state);
+intel_color_load_luts(crtc->state);
+}
+
if (to_intel_crtc_state(crtc->state)->update_pipe)
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_INFO(dev)->gen >= 9)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Update color management during vblank evasion.
On 30/03/16 17:41, Lionel Landwerlin wrote:
On 30/03/16 16:16, Maarten Lankhorst wrote:
Without this a vblank may occur between updating color management
and planes, which should be prevented.
intel_color_set_csc was called in update pipe config because the
handover from hardware may not have any csc set, which resulted
in a black screen. Because of this also update color management
during fastset.
Signed-off-by: Maarten Lankhorst
Tested-by: Lionel Landwerlin
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_display.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f913e5febf1..179461b45ce3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3222,9 +3222,6 @@ static void intel_update_pipe_config(struct
intel_crtc *crtc,
old_crtc_state->pipe_src_w, old_crtc_state->pipe_src_h,
pipe_config->pipe_src_w, pipe_config->pipe_src_h);
-if (HAS_DDI(dev))
-intel_color_set_csc(&pipe_config->base);
-
/*
* Update pipe size and adjust fitter if needed: the reason for
this is
* that in compute_mode_changes we check the native mode (not
the pfit
@@ -13603,18 +13600,6 @@ static int intel_atomic_commit(struct
drm_device *dev,
dev_priv->display.crtc_enable(crtc);
}
-if (!modeset &&
-crtc->state->active &&
-crtc->state->color_mgmt_changed) {
-/*
- * Only update color management when not doing
- * a modeset as this will be done by
- * crtc_enable already.
- */
-intel_color_set_csc(crtc->state);
-intel_color_load_luts(crtc->state);
-}
-
if (!modeset)
intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
@@ -13933,6 +13918,16 @@ static void intel_begin_crtc_commit(struct
drm_crtc *crtc,
if (modeset)
return;
+if (crtc->state->color_mgmt_changed ||
to_intel_crtc_state(crtc->state)->update_pipe) {
+/*
+ * Only update color management when not doing
+ * a modeset as this will be done by
+ * crtc_enable already.
+ */
I guess we can drop this comment.
+ intel_color_set_csc(crtc->state);
+intel_color_load_luts(crtc->state);
+}
+
if (to_intel_crtc_state(crtc->state)->update_pipe)
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_INFO(dev)->gen >= 9)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found
On 24/03/16 12:47, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 12:29:32PM +, Dave Gordon wrote:
On 24/03/16 09:54, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote:
[ build-script, build and config logs attached ]
Hi Chris,
I am just seeing this (or noticed for the first time, here on
Ubuntu/precise AMD64)...
$ zgrep -A1 -B1 ACLOCAL_FLAGS:
build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz
autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4
sh: 1: ACLOCAL_FLAGS: not found
autoreconf: configure.ac: tracing
--
libtoolize: copying file `m4/lt~obsolete.m4'
sh: 1: ACLOCAL_FLAGS: not found
autoreconf: running: /usr/bin/autoconf
What does this mean and it is ignore-able?
libtool vs automake. Haven't found the right fix yet.
If you want to locally patch s/$(ACLOCAL_FLAGS)// that'll do the trick.
I think that's what we'll have to do :|
-Chris
Is this a confusion between an (undefined) Make-variable vs a shell
variable? The syntax above with parentheses $(VAR) would be right
for expanding a Make-variable, but it looks like it's being passed
as-is to the shell, which interprets it as command-substitution and
tries to run the (non-existent) *command* ACLOCAL_FLAGS
Yes. The issue is that recently libtool spits out
an obtuse error if it sees ${ACLOCAL_FLAGS} in ACLOCAL_AMFLAGS
libtoolize: error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with
ACLOCAL_AMFLAGS=-I /opt/xorg/share/aclocal.
autoreconf: libtoolize failed with exit status: 1
i.e. it misses that we both include the user aclocal directory as well
as our own -I m4.
So I tried using it as a make variable instead, but then it is evaluated
as the shell $() command!
-Chris
Perhaps try setting AC_CONFIG_MACRO_DIRS to [/opt/xorg/share/aclocal,
m4] instead, and not use ACLOCAL_AMFLAGS? Or at least not to extend the
include path.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT
This patch sets the invert bit for hpd detection for each port
based on VBT configuration. Since each AOB can be designed to
depend on invert bit or not, it is expected if an AOB requires
invert bit, the user will set respective bit in VBT.
v2: Separated VBT parsing from the rest of the logic. (Jani)
v3: Moved setting invert bit logic to bxt_hpd_irq_setup()
and changed its logic to avoid looping twice. (Ville)
v4: Changed the logic to mask out the bits first and then
set them to remove need of temporary variable. (Ville)
v5: Moved defines to existing set of defines for the register
and added required breaks. (Ville)
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Durgadoss R
Signed-off-by: Shubhangi Shrivastava
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_irq.c | 20
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_bios.c | 38 ++
4 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 08b88c0..4e8d78a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3378,6 +3378,8 @@ bool intel_bios_is_tv_present(struct drm_i915_private
*dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
*port);
+bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
+enum port port);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a55a7cc..8fbec3e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3504,6 +3504,26 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
hotplug = I915_READ(PCH_PORT_HOTPLUG);
hotplug |= PORTC_HOTPLUG_ENABLE | PORTB_HOTPLUG_ENABLE |
PORTA_HOTPLUG_ENABLE;
+
+ DRM_DEBUG_KMS("Invert bit setting: hp_ctl:%x hp_port:%x\n",
+ hotplug, enabled_irqs);
+ hotplug &= ~BXT_DDI_HPD_INVERT_MASK;
+
+ /*
+* For BXT invert bit has to be set based on AOB design
+* for HPD detection logic, update it based on VBT fields.
+*/
+
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDIA) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_A))
+ hotplug |= BXT_DDIA_HPD_INVERT;
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDIB) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_B))
+ hotplug |= BXT_DDIB_HPD_INVERT;
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDIC) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_C))
+ hotplug |= BXT_DDIC_HPD_INVERT;
+
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f3ba43c..73a806c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6185,6 +6185,7 @@ enum skl_disp_power_wells {
/* digital port hotplug */
#define PCH_PORT_HOTPLUG _MMIO(0xc4030) /* SHOTPLUG_CTL */
#define PORTA_HOTPLUG_ENABLE (1 << 28) /* LPT:LP+ & BXT */
+#define BXT_DDIA_HPD_INVERT(1 << 27)
#define PORTA_HOTPLUG_STATUS_MASK (3 << 24) /* SPT+ & BXT */
#define PORTA_HOTPLUG_NO_DETECT (0 << 24) /* SPT+ & BXT */
#define PORTA_HOTPLUG_SHORT_DETECT(1 << 24) /* SPT+ & BXT */
@@ -6200,6 +6201,7 @@ enum skl_disp_power_wells {
#define PORTD_HOTPLUG_SHORT_DETECT(1 << 16)
#define PORTD_HOTPLUG_LONG_DETECT (2 << 16)
#define PORTC_HOTPLUG_ENABLE (1 << 12)
+#define BXT_DDIC_HPD_INVERT(1 << 11)
#define PORTC_PULSE_DURATION_2ms (0 << 10) /* pre-LPT */
#define PORTC_PULSE_DURATION_4_5ms(1 << 10) /* pre-LPT */
#define PORTC_PULSE_DURATION_6ms (2 << 10) /* pre-LPT */
@@ -6210,6 +6212,7 @@ enum skl_disp_power_wells {
#define PORTC_HOTPLUG_SHORT_DETECT(1 << 8)
#define PORTC_HOTPLUG_LONG_DETECT (2 << 8)
#define PORTB_HOTPLUG_ENABLE (1 << 4)
+#define BXT_DDIB_HPD_INVERT(1 << 3)
#define PORTB_PULSE_DURATION_2ms (0 << 2) /* pre-LPT */
#define PORTB_PULSE_DURATION_4_5ms(1 << 2) /* pre-LPT */
#define PORTB_PULSE_DURATION_6ms (2 << 2) /* pre-LPT */
@@ -6219,6 +6222,9 @@ enum skl_disp_power_wells {
#define PORTB_HOTPLUG_NO_DETECT (0 << 0)
#define PORTB_HOTPLUG_SHORT_DETECT(1 << 0)
#define PORTB_HOTPLUG_LONG_DETECT (2 << 0)
+#define BXT_DDI_HPD_INVERT_MASK (BXT_DDIA_HPD_INVERT | \
+ BXT_DDIB_HPD_INVERT | \
+ BXT_DDIC_HPD_INVERT)
#define PCH_PORT_HOTPLUG2 _MMIO(0xc403
[Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices
This patch adds new fields that are not yet added in drm code
in child devices struct
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Durgadoss R
Signed-off-by: Shubhangi Shrivastava
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_bios.c | 15 ++-
drivers/gpu/drm/i915/intel_vbt_defs.h | 18 --
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 083003b..e2f636c 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1126,7 +1126,7 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
}
/* Parse the I_boost config for SKL and above */
- if (bdb->version >= 196 && (child->common.flags_1 & IBOOST_ENABLE)) {
+ if (bdb->version >= 196 && child->common.iboost) {
info->dp_boost_level =
translate_iboost(child->common.iboost_level & 0xF);
DRM_DEBUG_KMS("VBT (e)DP boost level for port %c: %d\n",
port_name(port), info->dp_boost_level);
@@ -1244,6 +1244,19 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
*/
memcpy(child_dev_ptr, p_child,
min_t(size_t, p_defs->child_dev_size, sizeof(*p_child)));
+
+ /*
+* copied full block, now init values when they are not
+* available in current version
+*/
+ if (bdb->version < 196) {
+ /* Set default values for bits added from v196 */
+ child_dev_ptr->common.iboost = 0;
+ child_dev_ptr->common.hpd_invert = 0;
+ }
+
+ if (bdb->version < 192)
+ child_dev_ptr->common.lspcon = 0;
}
return;
}
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 749dcea..9ff1e96 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -261,9 +261,6 @@ struct old_child_dev_config {
* versions. Notice that the meaning of the contents contents may still change,
* but at least the offsets are consistent. */
-/* Definitions for flags_1 */
-#define IBOOST_ENABLE (1<<3)
-
struct common_child_dev_config {
u16 handle;
u16 device_type;
@@ -272,9 +269,18 @@ struct common_child_dev_config {
u8 not_common2[2];
u8 ddc_pin;
u16 edid_ptr;
- u8 obsolete;
- u8 flags_1;
- u8 not_common3[13];
+ u8 dvo_cfg; /* See DEVICE_CFG_* above */
+ u8 efp_routed:1;
+ u8 lane_reversal:1;
+ u8 lspcon:1;
+ u8 iboost:1;
+ u8 hpd_invert:1;
+ u8 flag_reserved:3;
+ u8 hdmi_support:1;
+ u8 dp_support:1;
+ u8 tmds_support:1;
+ u8 support_reserved:5;
+ u8 not_common3[12];
u8 iboost_level;
} __packed;
--
2.6.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add rpm get/put in i915_shrinker_oom
== Series Details == Series: drm/i915: Add rpm get/put in i915_shrinker_oom URL : https://patchwork.freedesktop.org/series/5039/ State : failure == Summary == Series 5039v1 drm/i915: Add rpm get/put in i915_shrinker_oom http://patchwork.freedesktop.org/api/1.0/series/5039/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> INCOMPLETE (bdw-nuci7) Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (bsw-nuc-2) bdw-nuci7total:194 pass:181 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:158 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:93 pass:86 dwarn:0 dfail:0 fail:0 skip:6 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:14 pass:12 dwarn:0 dfail:0 fail:0 skip:1 Results at /archive/results/CI_IGT_test/Patchwork_1747/ 65496a062fd94984d5c6c6cfcee1caeac2d6e5f5 drm-intel-nightly: 2016y-03m-31d-08h-14m-17s UTC integration manifest 85a746316d41d608d8bd2626dc41437dc391675a drm/i915: Add rpm get/put in i915_shrinker_oom ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices
On Wednesday 30 March 2016 08:18 PM, Jani Nikula wrote:
On Fri, 25 Mar 2016, Shubhangi Shrivastava
wrote:
This patch adds new fields that are not yet added in drm code
in child devices struct
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Durgadoss R
Signed-off-by: Shubhangi Shrivastava
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_bios.c | 15 ++-
drivers/gpu/drm/i915/intel_vbt_defs.h | 16 +++-
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 083003b..e2f636c 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1126,7 +1126,7 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
}
/* Parse the I_boost config for SKL and above */
- if (bdb->version >= 196 && (child->common.flags_1 & IBOOST_ENABLE)) {
+ if (bdb->version >= 196 && child->common.iboost) {
info->dp_boost_level = translate_iboost(child->common.iboost_level
& 0xF);
DRM_DEBUG_KMS("VBT (e)DP boost level for port %c: %d\n",
port_name(port), info->dp_boost_level);
@@ -1244,6 +1244,19 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
*/
memcpy(child_dev_ptr, p_child,
min_t(size_t, p_defs->child_dev_size, sizeof(*p_child)));
+
+ /*
+* copied full block, now init values when they are not
+* available in current version
+*/
+ if (bdb->version < 196) {
+ /* Set default values for bits added from v196 */
+ child_dev_ptr->common.iboost = 0;
+ child_dev_ptr->common.hpd_invert = 0;
+ }
+
+ if (bdb->version < 192)
+ child_dev_ptr->common.lspcon = 0;
}
return;
}
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 749dcea..2da7be8 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -261,9 +261,6 @@ struct old_child_dev_config {
* versions. Notice that the meaning of the contents contents may still
change,
* but at least the offsets are consistent. */
-/* Definitions for flags_1 */
-#define IBOOST_ENABLE (1<<3)
-
struct common_child_dev_config {
u16 handle;
u16 device_type;
@@ -272,8 +269,17 @@ struct common_child_dev_config {
u8 not_common2[2];
u8 ddc_pin;
u16 edid_ptr;
- u8 obsolete;
- u8 flags_1;
+ u8 dvo_cfg; /* See DEVICE_CFG_* above */
+ u8 efp_routed:1;
+ u8 lane_reversal:1;
+ u8 lspcon:1;
+ u8 iboost:1;
+ u8 hpd_invert:1;
+ u8 flag_reserved:3;
+ u8 hdmi_support:1;
+ u8 dp_support:1;
+ u8 tmds_support:1;
+ u8 support_reserved:5;
You replace two bytes with three bytes, shifting the rest.
Oh yes.. Thats a miss. Thanks.. Fixed..
u8 not_common3[13];
u8 iboost_level;
} __packed;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] kernfs: Move faulting copy_user operations outside of the mutex
A fault in a user provided buffer may lead anywhere, and lockdep warns
that we have a potential deadlock between the mm->mmap_sem and the
kernfs file mutex:
[ 82.811702] ==
[ 82.811705] [ INFO: possible circular locking dependency detected ]
[ 82.811709] 4.5.0-rc4-gfxbench+ #1 Not tainted
[ 82.811711] ---
[ 82.811714] kms_setmode/5859 is trying to acquire lock:
[ 82.811717] (&dev->struct_mutex){+.+.+.}, at: []
drm_gem_mmap+0x1a1/0x270
[ 82.811731]
but task is already holding lock:
[ 82.811734] (&mm->mmap_sem){++}, at: []
vm_mmap_pgoff+0x44/0xa0
[ 82.811745]
which lock already depends on the new lock.
[ 82.811749]
the existing dependency chain (in reverse order) is:
[ 82.811752]
-> #3 (&mm->mmap_sem){++}:
[ 82.811761][] lock_acquire+0xc3/0x1d0
[ 82.811766][] __might_fault+0x75/0xa0
[ 82.811771][] kernfs_fop_write+0x8a/0x180
[ 82.811787][] __vfs_write+0x23/0xe0
[ 82.811792][] vfs_write+0xa4/0x190
[ 82.811797][] SyS_write+0x44/0xb0
[ 82.811801][] entry_SYSCALL_64_fastpath+0x16/0x73
[ 82.811807]
-> #2 (s_active#6){.+}:
[ 82.811814][] lock_acquire+0xc3/0x1d0
[ 82.811819][] __kernfs_remove+0x210/0x2f0
[ 82.811823][] kernfs_remove_by_name_ns+0x40/0xa0
[ 82.811828][] sysfs_remove_file_ns+0x10/0x20
[ 82.811832][] device_del+0x124/0x250
[ 82.811837][] device_unregister+0x19/0x60
[ 82.811841][] cpu_cache_sysfs_exit+0x51/0xb0
[ 82.811846][] cacheinfo_cpu_callback+0x38/0x70
[ 82.811851][] notifier_call_chain+0x39/0xa0
[ 82.811856][] __raw_notifier_call_chain+0x9/0x10
[ 82.811860][] cpu_notify+0x1e/0x40
[ 82.811865][] cpu_notify_nofail+0x9/0x20
[ 82.811869][] _cpu_down+0x233/0x340
[ 82.811874][] disable_nonboot_cpus+0xc9/0x350
[ 82.811878][] suspend_devices_and_enter+0x5a1/0xb50
[ 82.811883][] pm_suspend+0x543/0x8d0
[ 82.811888][] state_store+0x77/0xe0
[ 82.811892][] kobj_attr_store+0xf/0x20
[ 82.811897][] sysfs_kf_write+0x40/0x50
[ 82.811902][] kernfs_fop_write+0x13c/0x180
[ 82.811906][] __vfs_write+0x23/0xe0
[ 82.811910][] vfs_write+0xa4/0x190
[ 82.811914][] SyS_write+0x44/0xb0
[ 82.811918][] entry_SYSCALL_64_fastpath+0x16/0x73
[ 82.811923]
-> #1 (cpu_hotplug.lock){+.+.+.}:
[ 82.811929][] lock_acquire+0xc3/0x1d0
[ 82.811933][] mutex_lock_nested+0x62/0x3b0
[ 82.811940][] get_online_cpus+0x61/0x80
[ 82.811944][] stop_machine+0x1b/0xe0
[ 82.811949][]
gen8_ggtt_insert_entries__BKL+0x2d/0x30 [i915]
[ 82.812009][] ggtt_bind_vma+0x46/0x70 [i915]
[ 82.812045][] i915_vma_bind+0x140/0x290 [i915]
[ 82.812081][] i915_gem_object_do_pin+0x899/0xb00
[i915]
[ 82.812117][] i915_gem_object_pin+0x35/0x40 [i915]
[ 82.812154][] intel_init_pipe_control+0xbe/0x210
[i915]
[ 82.812192][] intel_logical_rings_init+0xe2/0xde0
[i915]
[ 82.812232][] i915_gem_init+0xf3/0x130 [i915]
[ 82.812278][] i915_driver_load+0xf2d/0x1770 [i915]
[ 82.812318][] drm_dev_register+0xa4/0xb0
[ 82.812323][] drm_get_pci_dev+0xce/0x1e0
[ 82.812328][] i915_pci_probe+0x2f/0x50 [i915]
[ 82.812360][] pci_device_probe+0x87/0xf0
[ 82.812366][] driver_probe_device+0x229/0x450
[ 82.812371][] __driver_attach+0x83/0x90
[ 82.812375][] bus_for_each_dev+0x61/0xa0
[ 82.812380][] driver_attach+0x19/0x20
[ 82.812384][] bus_add_driver+0x1ef/0x290
[ 82.812388][] driver_register+0x5b/0xe0
[ 82.812393][] __pci_register_driver+0x5b/0x60
[ 82.812398][] drm_pci_init+0xd6/0x100
[ 82.812402][] 0xa027c094
[ 82.812406][] do_one_initcall+0xae/0x1d0
[ 82.812412][] do_init_module+0x5b/0x1cb
[ 82.812417][] load_module+0x1c20/0x2480
[ 82.812422][] SyS_finit_module+0x7e/0xa0
[ 82.812428][] entry_SYSCALL_64_fastpath+0x16/0x73
[ 82.812433]
-> #0 (&dev->struct_mutex){+.+.+.}:
[ 82.812439][] __lock_acquire+0x1fc9/0x20f0
[ 82.812443][] lock_acquire+0xc3/0x1d0
[ 82.812456][] drm_gem_mmap+0x1c7/0x270
[ 82.812460][] mmap_region+0x334/0x580
[ 82.812466][] do_mmap+0x364/0x410
[ 82.812470][] vm_mmap_pgoff+0x6d/0xa0
[ 82.812474][] SyS_mmap_pgoff+0x184/0x220
[ 82.812479][] SyS_mmap+0x1d/0x20
[ 82.812484][] entry_SYSCALL_64_fastpath+0x16/0x73
[ 82.812489]
other info that might help us debug this:
[ 82.812493] Chain exists of:
&dev->struct_mutex --> s_active#6 --> &mm->mmap_sem
[ 82.812502] Possible unsafe locking scenario:
[ 82.812506]CPU
[Intel-gfx] [PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.
It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.
drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.
Changes since v1:
- Add comment.
Changes since v2:
- Add fastpath for refcount = 1. (danvet)
Cc: sta...@vger.kernel.org #v4.4+
Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_flip.flip-vs-rmfb-interruptible
References:
https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom
Cc: David Herrmann
---
drivers/gpu/drm/drm_crtc.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 55ffde5a3a4a..743bece1f579 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
return 0;
}
+struct drm_mode_rmfb_work {
+ struct work_struct work;
+ struct drm_framebuffer *fb;
+};
+
+static void drm_mode_rmfb_work_fn(struct work_struct *w)
+{
+ struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
+
+ drm_framebuffer_remove(arg->fb);
+}
+
/**
* drm_mode_rmfb - remove an FB from the configuration
* @dev: drm device for the ioctl
@@ -3474,7 +3486,22 @@ int drm_mode_rmfb(struct drm_device *dev,
mutex_unlock(&dev->mode_config.fb_lock);
mutex_unlock(&file_priv->fbs_lock);
- drm_framebuffer_unreference(fb);
+ /*
+* drm_framebuffer_remove may fail with -EINTR on pending signals,
+* so run this in a separate stack as there's no way to correctly
+* handle this after the fb is already removed from the lookup table.
+*/
+ if (atomic_read(&fb->refcount.refcount) > 1) {
+ struct drm_mode_rmfb_work arg;
+
+ INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
+ arg.fb = fb;
+
+ schedule_work(&arg.work);
+ flush_work(&arg.work);
+ destroy_work_on_stack(&arg.work);
+ } else
+ drm_framebuffer_unreference(fb);
return 0;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/guc: always reset GuC before loading firmware
On 29/03/16 12:48, Daniel Vetter wrote: On Thu, Mar 24, 2016 at 06:40:15PM +, Dave Gordon wrote: After a suspend-resume cycle, the resumed kernel has no idea what the booted kernel may have done to the GuC before replacing itself with the resumed image. In particular, it may have already loaded the GuC with firmware, which will then cause this kernel's attempt to (re)load the firmware to fail (GuC program memory is write-once!). The symptoms (GuC firmware reload fails after hibernation) are further described in the Bugzilla reference below. So let's *always* reset the GuC just before (re)loading the firmware; then the hardware should then be in a well-known state, and we may even avoid some of the issues arising from unpredictable timing. Also added some more fields & values to the definition of the GUC_STATUS register, which is the key diagnostic indicator if the GuC load fails. Signed-off-by: Dave Gordon Reviewed-by: Arun Siluvery Cc: Alex Dai Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94390 I guess both of these should be labelled Cc: sta...@vger.kernel.org when merging. -Daniel Probably not necessary, as the patch to enable GuC loading (and fallback) by default hasn't yet been merged, so this code isn't reached unless the (unsafe) kernel parameter is overridden. .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Rename __force_wake_get to __force_wake_auto
== Series Details == Series: drm/i915: Rename __force_wake_get to __force_wake_auto URL : https://patchwork.freedesktop.org/series/4864/ State : failure == Summary == Series 4864v1 drm/i915: Rename __force_wake_get to __force_wake_auto 2016-03-30T10:43:14.185826 http://patchwork.freedesktop.org/api/1.0/series/4864/revisions/1/mbox/ Applying: drm/i915: Rename __force_wake_get to __force_wake_auto Patch failed at 0001 drm/i915: Rename __force_wake_get to __force_wake_auto ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH] drm/i915: s/i915_gem_obj_to_ggtt_view/i915_ggtt_view_to_vma/
This seems to be more in-line with what the function actually does, this
also makes it more consistent with i915_gem_obj_to_vma.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
drivers/gpu/drm/i915/i915_gem.c | 8
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 820c91f5..1cb38e6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3136,8 +3136,8 @@ struct i915_vma *
i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
struct i915_address_space *vm);
struct i915_vma *
-i915_gem_obj_to_ggtt_view(struct drm_i915_gem_object *obj,
- const struct i915_ggtt_view *view);
+i915_ggtt_view_to_vma(struct drm_i915_gem_object *obj,
+ const struct i915_ggtt_view *view);
struct i915_vma *
i915_gem_obj_lookup_or_create_vma(struct drm_i915_gem_object *obj,
@@ -3149,7 +3149,7 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct
drm_i915_gem_object *obj,
static inline struct i915_vma *
i915_gem_obj_to_ggtt(struct drm_i915_gem_object *obj)
{
- return i915_gem_obj_to_ggtt_view(obj, &i915_ggtt_view_normal);
+ return i915_ggtt_view_to_vma(obj, &i915_ggtt_view_normal);
}
bool i915_gem_obj_is_pinned(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 11a6ccd..96d0265 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4232,7 +4232,7 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
if (WARN_ON(i915_is_ggtt(vm) != !!ggtt_view))
return -EINVAL;
- vma = ggtt_view ? i915_gem_obj_to_ggtt_view(obj, ggtt_view) :
+ vma = ggtt_view ? i915_ggtt_view_to_vma(obj, ggtt_view) :
i915_gem_obj_to_vma(obj, vm);
if (vma) {
@@ -4307,7 +4307,7 @@ void
i915_gem_object_ggtt_unpin_view(struct drm_i915_gem_object *obj,
const struct i915_ggtt_view *view)
{
- struct i915_vma *vma = i915_gem_obj_to_ggtt_view(obj, view);
+ struct i915_vma *vma = i915_ggtt_view_to_vma(obj, view);
BUG_ON(!vma);
WARN_ON(vma->pin_count == 0);
@@ -4608,8 +4608,8 @@ struct i915_vma *i915_gem_obj_to_vma(struct
drm_i915_gem_object *obj,
return NULL;
}
-struct i915_vma *i915_gem_obj_to_ggtt_view(struct drm_i915_gem_object *obj,
- const struct i915_ggtt_view *view)
+struct i915_vma *i915_ggtt_view_to_vma(struct drm_i915_gem_object *obj,
+ const struct i915_ggtt_view *view)
{
struct i915_address_space *ggtt = i915_obj_to_ggtt(obj);
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f8f09d1..288cf1c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3353,7 +3353,7 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct
drm_i915_gem_object *obj,
const struct i915_ggtt_view *view)
{
struct i915_address_space *ggtt = i915_obj_to_ggtt(obj);
- struct i915_vma *vma = i915_gem_obj_to_ggtt_view(obj, view);
+ struct i915_vma *vma = i915_ggtt_view_to_vma(obj, view);
if (!vma)
vma = __i915_gem_vma_create(obj, ggtt, view);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 60bb486..394403c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2854,7 +2854,7 @@ u32 intel_plane_obj_offset(struct intel_plane
*intel_plane,
intel_fill_fb_ggtt_view(&view, intel_plane->base.state->fb,
intel_plane->base.state->rotation);
- vma = i915_gem_obj_to_ggtt_view(obj, &view);
+ vma = i915_ggtt_view_to_vma(obj, &view);
if (WARN(!vma, "ggtt vma for display object not found! (view=%u)\n",
view.type))
return -1;
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Protect fbdev across slow or failed initialisation
This almost fixes the problem , but with this:
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 5029f92..a6d3c58 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -123,8 +123,9 @@ static struct intel_fbdev
*intel_fbdev_get_if_active(struct drm_device *dev)
return NULL;
info = dev_priv->fbdev->helper.fbdev;
- if (info->screen_base == NULL)
+ if (info == NULL || info->screen_base == NULL)
return NULL;
if (info->state != FBINFO_STATE_RUNNING)
return NULL;
I got initially a page fault during init, but with this fix, the suspend
test passes.
Thank you, please consider this.
Regards,
Gabriel
On 30.03.2016 21:56, Chris Wilson wrote:
If the initialisation fails, we may be left with a dangling pointer with
an incomplete fbdev structure. Here we want to disable internal calls
into fbdev. Similarly, the initialisation may be slow and we haven't yet
enabled the fbdev (e.g. quick suspend or last-close before the async init
completes).
v3: To create a typo introduced when retyping
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
Reported-by: "Li, Weinan Z"
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fbdev.c | 48 --
1 file changed, 30 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 153ea7a3fcf6..5029f927fe0d 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -114,6 +114,24 @@ static struct fb_ops intelfb_ops = {
.fb_debug_leave = drm_fb_helper_debug_leave,
};
+static struct intel_fbdev *intel_fbdev_get_if_active(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct fb_info *info;
+
+ if (dev_priv->fbdev == NULL)
+ return NULL;
+
+ info = dev_priv->fbdev->helper.fbdev;
+ if (info->screen_base == NULL)
+ return NULL;
+
+ if (info->state != FBINFO_STATE_RUNNING)
+ return NULL;
+
+ return dev_priv->fbdev;
+}
+
static int intelfb_alloc(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
{
@@ -766,6 +784,8 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
state, bool synchronous
return;
info = ifbdev->helper.fbdev;
+ if (info->screen_base == NULL)
+ return;
if (synchronous) {
/* Flush any pending work to turn the console on, and then
@@ -807,32 +827,24 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
state, bool synchronous
void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_fbdev *ifbdev = intel_fbdev_get_if_active(dev);
+
+ if (ifbdev == NULL)
+ return;
- async_synchronize_full();
- if (dev_priv->fbdev)
- drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
+ drm_fb_helper_hotplug_event(&ifbdev->helper);
}
void intel_fbdev_restore_mode(struct drm_device *dev)
{
- int ret;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_fbdev *ifbdev = dev_priv->fbdev;
- struct drm_fb_helper *fb_helper;
+ struct intel_fbdev *ifbdev = intel_fbdev_get_if_active(dev);
- async_synchronize_full();
- if (!ifbdev)
+ if (ifbdev == NULL)
return;
- fb_helper = &ifbdev->helper;
-
- ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
- if (ret) {
- DRM_DEBUG("failed to restore crtc mode\n");
- } else {
- mutex_lock(&fb_helper->dev->struct_mutex);
+ if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper) == 0) {
+ mutex_lock(&dev->struct_mutex);
intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
- mutex_unlock(&fb_helper->dev->struct_mutex);
+ mutex_unlock(&dev->struct_mutex);
}
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915: s/i915_gem_obj_to_ggtt_view/i915_ggtt_view_to_vma/
On Thu, Mar 31, 2016 at 12:46:07PM +0100, Matthew Auld wrote: > This seems to be more in-line with what the function actually does, this > also makes it more consistent with i915_gem_obj_to_vma. All of these functions have been deleted in patches on the list that fix the bugs in partial vma and full vma handling. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: BXT DDI PHY sequence BUN
On ti, 2016-03-29 at 15:03 +0300, Imre Deak wrote:
> On ke, 2016-03-23 at 04:43 +, Kannan, Vandana wrote:
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > > Sent: Monday, March 21, 2016 7:34 PM
> > > To: Kannan, Vandana
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: BXT DDI PHY sequence
> > > BUN
> > >
> > > On Mon, Mar 21, 2016 at 12:12:40PM +0530, Vandana Kannan wrote:
> > > > According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register
> > > needs
> > > > to be checked to ensure that the register is in accessible
> > > > state.
> > > > Also, based on a BSpec update, changing the timeout value to
> > > > check
> > > > iphypwrgood, from 10ms to wait for up to 100us.
> > > >
> > > > Signed-off-by: Vandana Kannan
> > > > Reported-by: Philippe Lecluse
> > > > Cc: Deak, Imre
> > > > ---
> > > > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > > > drivers/gpu/drm/i915/intel_ddi.c | 11 +--
> > > > 2 files changed, 10 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h index 7dfc400..9a02bfc 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -1318,6 +1318,7 @@ enum skl_disp_power_wells {
> > > > #define _PORT_CL1CM_DW0_A 0x162000
> > > > #define _PORT_CL1CM_DW0_BC 0x6C000
> > > > #define PHY_POWER_GOOD (1 << 16)
> > > > +#define PHY_RESERVED (1 << 7)
> > > > #define BXT_PORT_CL1CM_DW0(phy)_BXT_PHY((phy),
> > > _PORT_CL1CM_DW0_BC, \
> > > > _PORT_
> > > > CL1CM_DW0_A)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index 62de9f4..354f949 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -2669,9 +2669,16 @@ static void broxton_phy_init(struct
> > > drm_i915_private *dev_priv,
> > > > val |= GT_DISPLAY_POWER_ON(phy);
> > > > I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
> > > >
> > > > - /* Considering 10ms timeout until BSpec is updated */
> > > > - if (wait_for(I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> > > PHY_POWER_GOOD, 10))
> > > > + /*
> > > > + * HW team confirmed that the time to reach
> > > > phypowergood status
> > > is
> > > > + * anywhere between 50 us and 100us.
> > > > + */
> > > > + if
> > > > (wait_for_atomic_us(((!(I915_READ(BXT_PORT_CL1CM_DW0(phy))
> > > &
> > >
> > > Switching to atomic wait seems silly.
> > >
> > [Vandana] You think wait_for_us should suffice here?
>
> Yes.
>
> > > > + PHY_RESERVED)) &&
> > > > + ((I915_READ(BXT_PORT_CL1CM_DW0
> > > > (phy)) &
> > > > + PHY_POWER_GOOD) ==
> > > PHY_POWER_GOOD)), 100)) {
> > > > DRM_ERROR("timeout during PHY%d power on\n",
> > > > phy);
> > > > + }
>
> Please also add a comment on how the detection magic works: Reading
> any
> PHY register while the PHY is powered down will result in all
> register
> bits set, while the reserved bit 7 is guaranteed to be 0 when the PHY
> is powered up.
Vandana, could you resend this patch with the comments addressed?
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
== Series Details == Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect URL : https://patchwork.freedesktop.org/series/5044/ State : success == Summary == Series 5044v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/5044/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:159 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:27 pass:24 dwarn:0 dfail:0 fail:0 skip:2 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:79 pass:68 dwarn:0 dfail:0 fail:0 skip:10 Results at /archive/results/CI_IGT_test/Patchwork_1753/ 03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly: 2016y-03m-31d-10h-50m-15s UTC integration manifest c448c6c059ae7bcdb7345feafd5324dd6dd164a7 drm/i915: force full detect on sink count change c1a69603958ccde4084f379f6c1a02314b8f5245 drm/i915: Read sink_count dpcd always 5f91fb8d635f35130714bf60601948996ee976e3 drm/i915: Reorganizing intel_dp_check_link_status 950d50e19edac435bed7a08f6147af55cd2c8835 drm/i915: Cleaning up intel_dp_hpd_pulse 41fd654a2ac9ffc2d59ccf2353b28f6271b1 drm/i915: Splitting intel_dp_detect ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 DDX] sna/video sprite patch: support for multiple xv ports
The current driver exposes only a single adaptor port so that only one
xv video can be played on sprite at a time. This change will allow
available hardware sprites to be used.
v4: re-formatted code, renamed sprite_disable_unlock() to sprite_unlock()
to be clearer. Also moved the sprite locking mechanism from
sprite_disable() to sna_crtc_sprite_unlock(), seperating the logic
between both functions and isolating them to their specific purposes.
v3: updated patch from lornax.mcne...@intel.com. removed/added
whitespace, re-formatted code, removed redundent variable allocation.
v2: removed/added whitespace, check for NULL return from calloc
made requested changes to simplify code (not exactly as requested
due to struct sprite being 'private' to sna_display.c).
Signed-off-by: Michael Hadley
Reviewed--by: Bob Paauwe
---
src/sna/sna.h| 7 +-
src/sna/sna_display.c| 201 ---
src/sna/sna_video.h | 2 +
src/sna/sna_video_sprite.c | 146 ++-
src/sna/sna_video_textured.c | 2 +-
5 files changed, 260 insertions(+), 98 deletions(-)
diff --git a/src/sna/sna.h b/src/sna/sna.h
index e5ca906..0fce602 100644
--- a/src/sna/sna.h
+++ b/src/sna/sna.h
@@ -608,8 +608,11 @@ static inline void sna_present_vblank_handler(struct
drm_event_vblank *event) {
static inline void sna_present_cancel_flip(struct sna *sna) { }
#endif
-extern bool sna_crtc_set_sprite_rotation(xf86CrtcPtr crtc, uint32_t rotation);
-extern uint32_t sna_crtc_to_sprite(xf86CrtcPtr crtc);
+extern bool sna_crtc_set_sprite_rotation(xf86CrtcPtr crtc, uint32_t rotation,
DrawablePtr draw);
+extern uint32_t sna_crtc_num_sprites(xf86CrtcPtr crtc);
+extern bool sna_crtc_drawable_to_sprite_id(xf86CrtcPtr crtc, DrawablePtr draw,
uint32_t *id);
+extern bool sna_crtc_sprite_lock(xf86CrtcPtr crtc, DrawablePtr draw);
+extern void sna_crtc_sprite_unlock(xf86CrtcPtr crtc, DrawablePtr draw);
extern bool sna_crtc_is_transformed(xf86CrtcPtr crtc);
#define CRTC_VBLANK 0x3
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 6ceb515..9495845 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -221,7 +221,15 @@ struct sna_crtc {
uint32_t supported;
uint32_t current;
} rotation;
- } primary, sprite;
+ } primary;
+
+ struct sprite {
+ struct plane plane;
+ DrawablePtr locked_to; /* drawable the sprite was grabbed for */
+ struct xorg_list link;
+ } sprite; /* TODO way to suppress anonymous struct warning "declaration
does not declare anything" without ming? */
+
+ struct xorg_list sprites; /* sprites that can be displayed on this crtc
*/
uint32_t mode_serial, flip_serial;
@@ -438,10 +446,111 @@ static inline uint32_t fb_id(struct kgem_bo *bo)
return bo->delta;
}
-uint32_t sna_crtc_to_sprite(xf86CrtcPtr crtc)
+uint32_t sna_crtc_num_sprites(xf86CrtcPtr crtc)
+{
+ struct sna_crtc *sna_crtc;
+ struct sprite *sp = NULL;
+ uint32_t num_sprites = 0;
+
+ sna_crtc = to_sna_crtc(crtc);
+
+ xorg_list_for_each_entry(sp, &sna_crtc->sprites, link) {
+ num_sprites++;
+ }
+
+ DBG(("%s: %d sprites\n", __FUNCTION__, num_sprites));
+
+ return num_sprites;
+}
+
+/*
+ * return the sprite attached to the specified crtc
+ * and locked to the specified drawable if there is one.
+ */
+static struct sprite * sna_crtc_drawable_to_sprite(xf86CrtcPtr crtc,
DrawablePtr draw)
{
+ struct sna_crtc *sna_crtc;
+ struct sprite *sp = NULL;
+
+ sna_crtc = to_sna_crtc(crtc);
+
+ xorg_list_for_each_entry(sp, &sna_crtc->sprites, link) {
+ if (sp->locked_to == draw) {
+ return sp;
+ }
+ }
+ return NULL;
+}
+
+/*
+ * gets the sprite id for the sprite attached to the specified crtc
+ * and locked to the specified drawable if there is one.
+ */
+bool sna_crtc_drawable_to_sprite_id(xf86CrtcPtr crtc, DrawablePtr draw,
uint32_t *sprite_id)
+{
+ struct sprite *sp = sna_crtc_drawable_to_sprite(crtc, draw);
+
+ if (sp) {
+ *sprite_id = sp->plane.id;
+ return true;
+ }
+ return false;
+}
+
+static void sprite_disable(struct sprite *sp, struct sna *sna)
+{
+ struct local_mode_set_plane s;
+
+ DBG(("%s: unlocking sprite %d\n", __FUNCTION__, sp->plane.id));
+ memset(&s, 0, sizeof(s));
+ s.plane_id = sp->plane.id;
+ if (drmIoctl(sna->kgem.fd, LOCAL_IOCTL_MODE_SETPLANE, &s))
+ xf86DrvMsg(sna->scrn->scrnIndex, X_ERROR, "failed to disable
plane\n");
+}
+
+/*
+ * If there's a sprite on this crtc using the specified drawable, then unlock
+ * it and disable the sprite
+ */
+void sna_crtc_sprite_unlock(xf86CrtcPtr crtc, DrawablePtr draw)
+{
+ struct sna_crtc *sna_crtc;
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [2/2] drm/i915/BXT: Get pipe conf from the port registers (rev3)
== Series Details == Series: series starting with [2/2] drm/i915/BXT: Get pipe conf from the port registers (rev3) URL : https://patchwork.freedesktop.org/series/5006/ State : failure == Summary == CC [M] drivers/net/ethernet/intel/igb/e1000_mac.o CC [M] drivers/net/ethernet/intel/e1000e/netdev.o CC [M] drivers/net/ethernet/intel/igb/e1000_nvm.o CC [M] drivers/net/ethernet/intel/e1000e/ptp.o CC [M] drivers/net/ethernet/intel/igb/e1000_phy.o CC [M] drivers/net/ethernet/intel/igb/e1000_mbx.o CC [M] drivers/net/ethernet/intel/igb/e1000_i210.o CC [M] drivers/net/ethernet/intel/igb/igb_ptp.o CC [M] drivers/net/ethernet/intel/igb/igb_hwmon.o LD drivers/usb/host/xhci-hcd.o LD drivers/usb/host/built-in.o LD drivers/usb/built-in.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o cc1: some warnings being treated as errors scripts/Makefile.build:291: recipe for target 'drivers/gpu/drm/i915/intel_display.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_display.o] Error 1 scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:440: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 make[1]: *** Waiting for unfinished jobs LD [M] drivers/net/ethernet/intel/igb/igb.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD drivers/net/ethernet/built-in.o LD drivers/net/built-in.o Makefile:962: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 DDX] sna/video sprite patch: support for multiple xv ports
On Thu, Mar 31, 2016 at 02:08:03PM +0100, Michael Hadley wrote: > The current driver exposes only a single adaptor port so that only one > xv video can be played on sprite at a time. This change will allow > available hardware sprites to be used. It's a bad change in semantics as you no longer guarrantee that you give the client the overlay plane they requested with the same set of compatible attributes. This code will not compile on older Xorg, and you have also randomly broken other features not related to Xv. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: force full detect on sink count change
On Wednesday 30 March 2016 04:39 PM, Ander Conselvan De Oliveira wrote:
On Thu, 2016-03-24 at 12:21 +, Shrivastava, Shubhangi wrote:
Hi Daniel,
Is something else required for this patch series (5 patches) to be merged?
It needs to please CI. The errors reported are probably not caused by this
series, but at this point is probably better to rebase and resend. CI seems to
be a lot happier lately. :)
Ander
Alright.. Rebased and resent.. Finally, CI has become happy.. :)
Thanks Ander!!
Shubhangi
Thanks and Regards,
Shubhangi Shrivastava.
-Original Message-
From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
Sent: Wednesday, January 20, 2016 8:07 PM
To: Shrivastava, Shubhangi ;
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 5/5] drm/i915: force full detect on sink count
change
On Tue, 2016-01-19 at 16:07 +0530, Shubhangi Shrivastava wrote:
This patch checks for changes in sink count between short pulse hpds
and forces full detect when there is a change.
This will allow both detection of hotplug and unplug of panels through
dongles that give only short pulse for such events.
v2: changed variable type from u8 to bool (Jani)
return immediately if perform_full_detect is set(Siva)
v3: changed method of determining full detection from using
pointer to return code (Siva)
v4: changed comments to indicate meaning of return value of
intel_dp_short_pulse and explain the use of return value
from intel_dp_get_dpcd in intel_dp_short_pulse (Ander)
Tested-by: Nathan D Ciobanu
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Shubhangi Shrivastava
Reviewed-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp.c | 33
+++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c index cdf4919..120d263 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4325,12 +4325,19 @@ intel_dp_check_link_status(struct intel_dp
*intel_dp)
* 2. Configure link according to Receiver Capabilities
* 3. Use Link Training from 2.5.3.3 and 3.5.1.3
* 4. Check link status on receipt of hot-plug interrupt
+ *
+ * intel_dp_short_pulse - handles short pulse interrupts
+ * when full detection is not required.
+ * Returns %true if short pulse is handled and full detection
+ * is NOT required and %false otherwise.
*/
-static void
+static bool
intel_dp_short_pulse(struct intel_dp *intel_dp) {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
u8 sink_irq_vector;
+ u8 old_sink_count = intel_dp->sink_count;
+ bool ret;
/*
* Clearing compliance test variables to allow capturing @@ -4340,9
+4347,17 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
intel_dp->compliance_test_type = 0;
intel_dp->compliance_test_data = 0;
- /* Now read the DPCD to see if it's actually running */
- if (!intel_dp_get_dpcd(intel_dp)) {
- return;
+ /*
+* Now read the DPCD to see if it's actually running
+* If the current value of sink count doesn't match with
+* the value that was stored earlier or dpcd read failed
+* we need to do full detection
+*/
+ ret = intel_dp_get_dpcd(intel_dp);
+
+ if ((old_sink_count != intel_dp->sink_count) || !ret) {
+ /* No need to proceed if we are going to do full detect */
+ return false;
}
/* Try to read the source of the interrupt */ @@ -4362,6 +4377,8 @@
intel_dp_short_pulse(struct intel_dp *intel_dp)
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
intel_dp_check_link_status(intel_dp);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ return true;
}
/* XXX this is probably wrong for multiple downstream ports */ @@
-5086,8 +5103,12 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
}
}
- if (!intel_dp->is_mst)
- intel_dp_short_pulse(intel_dp);
+ if (!intel_dp->is_mst) {
+ if (!intel_dp_short_pulse(intel_dp)) {
+ intel_dp_long_pulse(intel_dp
->attached_connector);
+ goto put_power;
+ }
+ }
}
ret = IRQ_HANDLED;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Add struct_mutex locking for debugs/i915_gem_framebuffer
== Series Details == Series: series starting with [1/2] drm/i915: Add struct_mutex locking for debugs/i915_gem_framebuffer URL : https://patchwork.freedesktop.org/series/5053/ State : success == Summary == Series 5053v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/5053/revisions/1/mbox/ bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:158 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-gt2 total:28 pass:26 dwarn:0 dfail:0 fail:0 skip:1 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:1pass:0dwarn:0 dfail:0 fail:0 skip:0 Results at /archive/results/CI_IGT_test/Patchwork_1756/ 03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly: 2016y-03m-31d-10h-50m-15s UTC integration manifest 2c59632353f8156281f58967d61d93fededfd4e1 drm/i915: Show PCI power state under debugfs/i915_runtime_pm_status c1e95e5718eb1d2765217d7e47f83d6fc5f69f30 drm/i915: Add struct_mutex locking for debugs/i915_gem_framebuffer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/2] drm/i915: Move fbdev_suspend_work to intel_fbdev
Since the suspend_work is entirely internal to intel_fbdev.c, move it
from the top level drm_i915_private and into struct intel_fbdev. This
requires splitting the internal interface for the suspend worker from
the external interface used by the higher layers to initiate suspend.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c| 4 +-
drivers/gpu/drm/i915/i915_drv.h| 1 -
drivers/gpu/drm/i915/intel_drv.h | 5 +-
drivers/gpu/drm/i915/intel_fbdev.c | 117 -
4 files changed, 68 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 020a31c5e2bb..100d0d92b1e6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -634,7 +634,7 @@ static int i915_drm_suspend(struct drm_device *dev)
intel_uncore_forcewake_reset(dev, false);
intel_opregion_fini(dev);
- intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
+ intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED);
dev_priv->suspend_count++;
@@ -784,7 +784,7 @@ static int i915_drm_resume(struct drm_device *dev)
intel_opregion_init(dev);
- intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
+ intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING);
mutex_lock(&dev_priv->modeset_restore_lock);
dev_priv->modeset_restore = MODESET_DONE;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 820c91f551ba..973a602c5077 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1880,7 +1880,6 @@ struct drm_i915_private {
#ifdef CONFIG_DRM_FBDEV_EMULATION
/* list of fbdev register on this device */
struct intel_fbdev *fbdev;
- struct work_struct fbdev_suspend_work;
#endif
struct drm_property *broadcast_rgb_property;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6ac46d921cde..00b6c60c1cb8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -158,6 +158,7 @@ struct intel_framebuffer {
struct intel_fbdev {
struct drm_fb_helper helper;
struct intel_framebuffer *fb;
+ struct work_struct suspend_work;
int preferred_bpp;
};
@@ -1335,7 +1336,7 @@ void intel_dvo_init(struct drm_device *dev);
extern int intel_fbdev_init(struct drm_device *dev);
extern void intel_fbdev_initial_config_async(struct drm_device *dev);
extern void intel_fbdev_fini(struct drm_device *dev);
-extern void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
synchronous);
+extern void intel_fbdev_set_suspend(struct drm_device *dev, int state);
extern void intel_fbdev_output_poll_changed(struct drm_device *dev);
extern void intel_fbdev_restore_mode(struct drm_device *dev);
#else
@@ -1352,7 +1353,7 @@ static inline void intel_fbdev_fini(struct drm_device
*dev)
{
}
-static inline void intel_fbdev_set_suspend(struct drm_device *dev, int state,
bool synchronous)
+static inline void intel_fbdev_set_suspend(struct drm_device *dev, int state)
{
}
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 5d4be71bdf22..66bb79613660 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -534,8 +534,7 @@ static const struct drm_fb_helper_funcs
intel_fb_helper_funcs = {
.fb_probe = intelfb_create,
};
-static void intel_fbdev_destroy(struct drm_device *dev,
- struct intel_fbdev *ifbdev)
+static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
{
/* We rely on the object-free to release the VMA pinning for
* the info->screen_base mmaping. Leaking the VMA is simpler than
@@ -681,13 +680,56 @@ out:
return false;
}
+static void __intel_fbdev_set_suspend(struct intel_fbdev *ifbdev,
+ int state, bool synchronous)
+{
+ if (synchronous) {
+ /* Flush any pending work to turn the console on, and then
+* wait to turn it off. It must be synchronous as we are
+* about to suspend or unload the driver.
+*
+* Note that from within the work-handler, we cannot flush
+* ourselves, so only flush outstanding work upon suspend!
+*/
+ if (state != FBINFO_STATE_RUNNING)
+ flush_work(&ifbdev->suspend_work);
+ console_lock();
+ } else {
+ /*
+* The console lock can be pretty contented on resume due
+* to all the printk activity. Try to keep it out of the hot
+* path of resume if possible.
+*/
+ WARN_ON(state != FBINFO_STATE_RUNNING);
+ if (!console_trylock()) {
+ /* Don't block our own workqueue as this c
[Intel-gfx] [PATCH v4 1/2] drm/i915: Protect fbdev across slow or failed initialisation
If the initialisation fails, we may be left with a dangling pointer with
an incomplete fbdev structure. Here we want to disable internal calls
into fbdev. Similarly, the initialisation may be slow and we haven't yet
enabled the fbdev (e.g. quick suspend or last-close before the async init
completes).
v3: To create a typo introduced when retyping
v4: Prevent info==NULL dereference in early boot
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
Reported-by: "Li, Weinan Z"
Tested-by: Gabriel Feceoru
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fbdev.c | 72 +-
1 file changed, 48 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 153ea7a3fcf6..5d4be71bdf22 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -756,17 +756,47 @@ void intel_fbdev_fini(struct drm_device *dev)
dev_priv->fbdev = NULL;
}
+static struct intel_fbdev *intel_fbdev_get(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct fb_info *info;
+
+ if (dev_priv->fbdev == NULL)
+ return NULL;
+
+ info = dev_priv->fbdev->helper.fbdev;
+ if (info == NULL)
+ return NULL;
+
+ if (info->screen_base == NULL)
+ return NULL;
+
+ return dev_priv->fbdev;
+}
+
+static struct intel_fbdev *intel_fbdev_get_if_active(struct drm_device *dev)
+{
+ struct intel_fbdev *ifbdev;
+
+ ifbdev = intel_fbdev_get(dev);
+ if (ifbdev == NULL)
+ return NULL;
+
+ if (ifbdev->helper.fbdev->state != FBINFO_STATE_RUNNING)
+ return NULL;
+
+ return ifbdev;
+}
+
void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
synchronous)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_fbdev *ifbdev = dev_priv->fbdev;
- struct fb_info *info;
+ struct intel_fbdev *ifbdev;
- if (!ifbdev)
+ ifbdev = intel_fbdev_get(dev);
+ if (ifbdev == NULL)
return;
- info = ifbdev->helper.fbdev;
-
if (synchronous) {
/* Flush any pending work to turn the console on, and then
* wait to turn it off. It must be synchronous as we are
@@ -798,8 +828,10 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
state, bool synchronous
* been restored from swap. If the object is stolen however, it will be
* full of whatever garbage was left in there.
*/
- if (state == FBINFO_STATE_RUNNING && ifbdev->fb->obj->stolen)
+ if (state == FBINFO_STATE_RUNNING && ifbdev->fb->obj->stolen) {
+ struct fb_info *info = ifbdev->helper.fbdev;
memset_io(info->screen_base, 0, info->screen_size);
+ }
drm_fb_helper_set_suspend(&ifbdev->helper, state);
console_unlock();
@@ -807,32 +839,24 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
state, bool synchronous
void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_fbdev *ifbdev = intel_fbdev_get_if_active(dev);
+
+ if (ifbdev == NULL)
+ return;
- async_synchronize_full();
- if (dev_priv->fbdev)
- drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
+ drm_fb_helper_hotplug_event(&ifbdev->helper);
}
void intel_fbdev_restore_mode(struct drm_device *dev)
{
- int ret;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_fbdev *ifbdev = dev_priv->fbdev;
- struct drm_fb_helper *fb_helper;
+ struct intel_fbdev *ifbdev = intel_fbdev_get_if_active(dev);
- async_synchronize_full();
- if (!ifbdev)
+ if (ifbdev == NULL)
return;
- fb_helper = &ifbdev->helper;
-
- ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
- if (ret) {
- DRM_DEBUG("failed to restore crtc mode\n");
- } else {
- mutex_lock(&fb_helper->dev->struct_mutex);
+ if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper) == 0) {
+ mutex_lock(&dev->struct_mutex);
intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
- mutex_unlock(&fb_helper->dev->struct_mutex);
+ mutex_unlock(&dev->struct_mutex);
}
}
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DRMJanitors
Welcome Rob! On Thu, Mar 31, 2016 at 3:35 PM, Robert Foss wrote: > Hey, > > I'm new to DRM development, but was thinking about getting into the shallow > side of pool, and doing some DRMJanitors development. > > Do you have a preference for a task for me to look at? Is there one that > would be particularly easy to get started with? Say hi on #dri-devel irc channel on irc and just jump in. Ime doing something that's somewhat relevant to yourself (driver for hw you're using or similar) is good for the motivation. And if you want to test-drive the patch submission process you can also do a simple cleanup patch first (coding style or similar work like for drivers/staging) and submit it. Also, please include always mailing lists, maybe someone else is interested or has ideas. I added them. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2] drm/i915: Rename GGTT init functions (rev5)
== Series Details ==
Series: series starting with [v2] drm/i915: Rename GGTT init functions (rev5)
URL : https://patchwork.freedesktop.org/series/4790/
State : warning
== Summary ==
Series 4790v5 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/4790/revisions/5/mbox/
Test gem_mmap_gtt:
Subgroup basic-read-no-prefault:
pass -> DMESG-WARN (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS (bsw-nuc-2)
bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12
bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21
bsw-nuc-2total:196 pass:158 dwarn:1 dfail:0 fail:0 skip:37
hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22
hsw-gt2 total:21 pass:19 dwarn:0 dfail:0 fail:0 skip:1
skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23
skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11
snb-dellxps total:27 pass:23 dwarn:0 dfail:0 fail:0 skip:3
Results at /archive/results/CI_IGT_test/Patchwork_1757/
03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly:
2016y-03m-31d-10h-50m-15s UTC integration manifest
5061b7bad84ec0d6047783dc1a23f1e592e7d5d8 drm/i915: Refer to GGTT {,VM}
consistently
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2] drm/i915: Rename GGTT init functions (rev5)
On to, 2016-03-31 at 13:44 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2] drm/i915: Rename GGTT init functions (rev5)
> URL : https://patchwork.freedesktop.org/series/4790/
> State : warning
>
> == Summary ==
>
> Series 4790v5 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/4790/revisions/5/mbox/
>
> Test gem_mmap_gtt:
> Subgroup basic-read-no-prefault:
> pass -> DMESG-WARN (bsw-nuc-2)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS (bsw-nuc-2)
This is the kernfs lockdep warn (awaiting comments from upstream
maintainers):
https://bugs.freedesktop.org/show_bug.cgi?id=94759
So I'm merging this other patch too as it was supposed to be NOOP too
(just renames).
Regards, Joonas
>
> bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12
> bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21
> bsw-nuc-2total:196 pass:158 dwarn:1 dfail:0 fail:0 skip:37
> hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22
> hsw-gt2 total:21 pass:19 dwarn:0 dfail:0 fail:0 skip:1
> skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23
> skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11
> snb-dellxps total:27 pass:23 dwarn:0 dfail:0 fail:0 skip:3
>
> Results at /archive/results/CI_IGT_test/Patchwork_1757/
>
> 03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly:
> 2016y-03m-31d-10h-50m-15s UTC integration manifest
> 5061b7bad84ec0d6047783dc1a23f1e592e7d5d8 drm/i915: Refer to GGTT {,VM}
> consistently
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for DPCD Backlight Control (rev5)
== Series Details == Series: DPCD Backlight Control (rev5) URL : https://patchwork.freedesktop.org/series/1864/ State : success == Summary == Series 1864v5 DPCD Backlight Control http://patchwork.freedesktop.org/api/1.0/series/1864/revisions/5/mbox/ bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:158 dwarn:1 dfail:0 fail:0 skip:37 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:85 pass:69 dwarn:0 dfail:0 fail:0 skip:15 Results at /archive/results/CI_IGT_test/Patchwork_1758/ 03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly: 2016y-03m-31d-10h-50m-15s UTC integration manifest 1e571fdbeaa28ce2b3b943b13c2cfa61e06fc025 drm/i915: Add backlight Control using DPCD registers for DP connectors f29b8fe12e0b7285774241f53e9ac7239687adc2 drm/i915: Add Backlight Control using DPCD for eDP connectors (v8) 3d25dc84cdec4a5f687c57a434845c123bee7a4a drm/dp: Add definition for Display Control DPCD Registers capability size ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Protect fbdev across slow or failed initialisation (rev2)
== Series Details == Series: drm/i915: Protect fbdev across slow or failed initialisation (rev2) URL : https://patchwork.freedesktop.org/series/5065/ State : failure == Summary == Series 5065v2 drm/i915: Protect fbdev across slow or failed initialisation http://patchwork.freedesktop.org/api/1.0/series/5065/revisions/2/mbox/ Test drv_module_reload_basic: pass -> INCOMPLETE (bsw-nuc-2) pass -> INCOMPLETE (skl-nuci5) pass -> INCOMPLETE (byt-nuc) Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (bsw-nuc-2) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-rte: pass -> DMESG-WARN (bsw-nuc-2) bsw-nuc-2total:154 pass:122 dwarn:2 dfail:0 fail:0 skip:29 byt-nuc total:57 pass:46 dwarn:0 dfail:0 fail:0 skip:10 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 skl-nuci5total:25 pass:22 dwarn:0 dfail:0 fail:0 skip:2 Results at /archive/results/CI_IGT_test/Patchwork_1761/ 03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly: 2016y-03m-31d-10h-50m-15s UTC integration manifest ab3a2f88b9f8b6a3109c325d42770c3c5fd714a4 drm/i915: Protect fbdev across slow or failed initialisation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Avoid unnecessary full synchronize for fbdev
This should make the code less fragile by synchronizing only up to the
relevant cookie. Otherwise we risk deadlocks particularly during suspend
and resume.
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbdev.c | 14 +-
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6ac46d9..5bc9606 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -158,6 +158,7 @@ struct intel_framebuffer {
struct intel_fbdev {
struct drm_fb_helper helper;
struct intel_framebuffer *fb;
+ async_cookie_t init_cookie;
int preferred_bpp;
};
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 153ea7a..8254ac8d 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -725,7 +725,7 @@ int intel_fbdev_init(struct drm_device *dev)
return 0;
}
-static void intel_fbdev_initial_config(void *data, async_cookie_t cookie)
+static void intel_fbdev_initial_config(void *data, async_cookie_t init_cookie)
{
struct drm_i915_private *dev_priv = data;
struct intel_fbdev *ifbdev = dev_priv->fbdev;
@@ -738,7 +738,11 @@ static void intel_fbdev_initial_config(void *data,
async_cookie_t cookie)
void intel_fbdev_initial_config_async(struct drm_device *dev)
{
- async_schedule(intel_fbdev_initial_config, to_i915(dev));
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_fbdev *ifbdev = dev_priv->fbdev;
+
+ ifbdev->init_cookie = async_schedule(intel_fbdev_initial_config,
+dev_priv);
}
void intel_fbdev_fini(struct drm_device *dev)
@@ -750,7 +754,7 @@ void intel_fbdev_fini(struct drm_device *dev)
flush_work(&dev_priv->fbdev_suspend_work);
if (!current_is_async())
- async_synchronize_full();
+ async_synchronize_cookie(dev_priv->fbdev->init_cookie);
intel_fbdev_destroy(dev, dev_priv->fbdev);
kfree(dev_priv->fbdev);
dev_priv->fbdev = NULL;
@@ -809,7 +813,7 @@ void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- async_synchronize_full();
+ async_synchronize_cookie(dev_priv->fbdev->init_cookie);
if (dev_priv->fbdev)
drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
}
@@ -821,7 +825,7 @@ void intel_fbdev_restore_mode(struct drm_device *dev)
struct intel_fbdev *ifbdev = dev_priv->fbdev;
struct drm_fb_helper *fb_helper;
- async_synchronize_full();
+ async_synchronize_cookie(dev_priv->fbdev->init_cookie);
if (!ifbdev)
return;
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] system hang on ILK/SNB/IVB
Hi Gabriel, On Thu, Mar 31, 2016 at 10:42:37AM +0300, Gabriel Feceoru wrote: > On 31.03.2016 00:35, Lukas Wunner wrote: > >On Wed, Mar 30, 2016 at 08:20:26PM +0300, Gabriel Feceoru wrote: > >>This commit causes a hang while running kms suspend tests > >>(kms_pipe_crc_basic@suspend-read-crc-pipe-*) on ILK/SNB/IVB, affecting CI. > > Tomi already replied, meantime I also looked at the results. > The current regression is for ILK/SNB/IVB only (v1 seemed to affect more > platforms). > Unfortunately these machines were not available when v2 was tested, so this > couldn't be detected. I dev on an IVB machine and cannot reproduce this. Suspend works fine. All the patch does is call async_synchronize_full() (1) when a hotplug event arrives or (2) when the last DRM client closes the connection. Either of these two things seems to be happening on your test machines when running the suspend test. The PM core suspends and resumes individual devices asynchronously and calls async_synchronize_full() in a couple of places. If a device's PM callbacks also call async_synchronize_full(), the machine deadlocks. It is unnecessary that we call async_synchronize_full(), we only need to synchronize up to a specific cookie (which represents initialization of the fbdev). So I've just posted a patch to replace the calls to async_synchronize_full() with async_synchronize_cookie(). This should make things less fragile and hopefully also solve the hangs you're seeing. Best regards, Lukas > >> > >>Probably the same problem with the one in v2, but on older HW. > >> > >> > >>commit a7442b93cf32c1e1ddb721a26cd1f92302e2a222 > >>Author: Lukas Wunner > >>Date: Wed Mar 9 12:52:53 2016 +0100 > >> > >> drm/i915: Fix races on fbdev > >> > >> The ->lastclose callback invokes intel_fbdev_restore_mode() and has > >> been witnessed to run before intel_fbdev_initial_config_async() > >> has finished. > >> > >> We might likewise receive hotplug events before we've had a chance to > >> fully set up the fbdev. > >> > >> Fix by waiting for the asynchronous thread to finish. > >> > >> v2: > >> An async_synchronize_full() was also added to intel_fbdev_set_suspend() > >> in v1 which turned out to be entirely gratuitous. It caused a deadlock > >> on suspend (discovered by CI, thanks to Damien Lespiau and Tomi Sarvela > >> for CI support) and was unnecessary since a device is never suspended > >> until its ->probe callback (and all asynchronous tasks it scheduled) > >> have finished. See dpm_prepare(), which calls wait_for_device_probe(), > >> which calls async_synchronize_full(). > >> > >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580 > >> Reported-by: Gustav Fägerlind > >> Reported-by: "Li, Weinan Z" > >> Cc: Chris Wilson > >> Cc: sta...@vger.kernel.org > >> Signed-off-by: Lukas Wunner > >> Signed-off-by: Daniel Vetter > >> Link: > >> http://patchwork.freedesktop.org/patch/msgid/20160309115147.67b2b6e...@gabe.freedesktop.org > >> > >> > >>Regards, > >>Gabriel > >v2 passed CI fine, save for one warning not caused by the patch: > >https://patchwork.freedesktop.org/series/4068/ > > > >For comparison, this was v1: > >https://patchwork.freedesktop.org/patch/75840/ > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Move fbdev_suspend_work to intel_fbdev
On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> Since the suspend_work is entirely internal to intel_fbdev.c, move it
> from the top level drm_i915_private and into struct intel_fbdev. This
> requires splitting the internal interface for the suspend worker from
> the external interface used by the higher layers to initiate suspend.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.c| 4 +-
> drivers/gpu/drm/i915/i915_drv.h| 1 -
> drivers/gpu/drm/i915/intel_drv.h | 5 +-
> drivers/gpu/drm/i915/intel_fbdev.c | 117
> -
> 4 files changed, 68 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 020a31c5e2bb..100d0d92b1e6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -634,7 +634,7 @@ static int i915_drm_suspend(struct drm_device *dev)
> intel_uncore_forcewake_reset(dev, false);
> intel_opregion_fini(dev);
>
> - intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
> + intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED);
>
> dev_priv->suspend_count++;
>
> @@ -784,7 +784,7 @@ static int i915_drm_resume(struct drm_device *dev)
>
> intel_opregion_init(dev);
>
> - intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
> + intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING);
>
> mutex_lock(&dev_priv->modeset_restore_lock);
> dev_priv->modeset_restore = MODESET_DONE;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 820c91f551ba..973a602c5077 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1880,7 +1880,6 @@ struct drm_i915_private {
> #ifdef CONFIG_DRM_FBDEV_EMULATION
> /* list of fbdev register on this device */
> struct intel_fbdev *fbdev;
> - struct work_struct fbdev_suspend_work;
> #endif
>
> struct drm_property *broadcast_rgb_property;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 6ac46d921cde..00b6c60c1cb8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -158,6 +158,7 @@ struct intel_framebuffer {
> struct intel_fbdev {
> struct drm_fb_helper helper;
> struct intel_framebuffer *fb;
> + struct work_struct suspend_work;
> int preferred_bpp;
> };
>
> @@ -1335,7 +1336,7 @@ void intel_dvo_init(struct drm_device *dev);
> extern int intel_fbdev_init(struct drm_device *dev);
> extern void intel_fbdev_initial_config_async(struct drm_device *dev);
> extern void intel_fbdev_fini(struct drm_device *dev);
> -extern void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
> synchronous);
> +extern void intel_fbdev_set_suspend(struct drm_device *dev, int state);
> extern void intel_fbdev_output_poll_changed(struct drm_device *dev);
> extern void intel_fbdev_restore_mode(struct drm_device *dev);
> #else
> @@ -1352,7 +1353,7 @@ static inline void intel_fbdev_fini(struct drm_device
> *dev)
> {
> }
>
> -static inline void intel_fbdev_set_suspend(struct drm_device *dev, int
> state, bool synchronous)
> +static inline void intel_fbdev_set_suspend(struct drm_device *dev, int state)
> {
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 5d4be71bdf22..66bb79613660 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -534,8 +534,7 @@ static const struct drm_fb_helper_funcs
> intel_fb_helper_funcs = {
> .fb_probe = intelfb_create,
> };
>
> -static void intel_fbdev_destroy(struct drm_device *dev,
> - struct intel_fbdev *ifbdev)
> +static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
> {
> /* We rely on the object-free to release the VMA pinning for
> * the info->screen_base mmaping. Leaking the VMA is simpler than
> @@ -681,13 +680,56 @@ out:
> return false;
> }
>
> +static void __intel_fbdev_set_suspend(struct intel_fbdev *ifbdev,
> + int state, bool synchronous)
> +{
> + if (synchronous) {
> + /* Flush any pending work to turn the console on, and then
> + * wait to turn it off. It must be synchronous as we are
> + * about to suspend or unload the driver.
> + *
> + * Note that from within the work-handler, we cannot flush
> + * ourselves, so only flush outstanding work upon suspend!
> + */
> + if (state != FBINFO_STATE_RUNNING)
> + flush_work(&ifbdev->suspend_work);
> + console_lock();
> + } else {
> + /*
> + * The console lock can be pretty contented on resume due
> + * to all the printk activity. Try to keep it out of the hot
> +
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Move fbdev_suspend_work to intel_fbdev
On Thu, Mar 31, 2016 at 06:22:01PM +0300, Joonas Lahtinen wrote:
> On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> > static void intel_fbdev_suspend_worker(struct work_struct *work)
> > {
> > - intel_fbdev_set_suspend(container_of(work,
> > - struct drm_i915_private,
> > - fbdev_suspend_work)->dev,
> > - FBINFO_STATE_RUNNING,
> > - true);
> > + __intel_fbdev_set_suspend(container_of(work,
> > + struct intel_fbdev,
> > + suspend_work),
>
> Have the container_of on separate line at least, maybe even with a
> macro.
Sure.
> > + FBINFO_STATE_RUNNING,
> > + true);
> > }
> >
> > int intel_fbdev_init(struct drm_device *dev)
> > @@ -716,9 +758,9 @@ int intel_fbdev_init(struct drm_device *dev)
> > }
> >
> > ifbdev->helper.atomic = true;
> > + INIT_WORK(&ifbdev->suspend_work, intel_fbdev_suspend_worker);
> >
> > dev_priv->fbdev = ifbdev;
> > - INIT_WORK(&dev_priv->fbdev_suspend_work, intel_fbdev_suspend_worker);
> >
> > drm_fb_helper_single_add_all_connectors(&ifbdev->helper);
> >
> > @@ -743,17 +785,21 @@ void intel_fbdev_initial_config_async(struct
> > drm_device *dev)
> >
> > void intel_fbdev_fini(struct drm_device *dev)
> > {
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > - if (!dev_priv->fbdev)
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > + struct intel_fbdev *ifbdev;
> > +
> > + ifbdev = dev_priv->fbdev;
>
> Straight assignment.
>
> > + if (ifbdev == NULL)
I was trying to group the local assignment with the if, and I like to leave
whitespace after the locals. By placing these two lines together this
function looks like the majority of the other functions.
> > return;
> >
> > - flush_work(&dev_priv->fbdev_suspend_work);
> > + dev_priv->fbdev = NULL;
> >
> > if (!current_is_async())
> > async_synchronize_full();
> > - intel_fbdev_destroy(dev, dev_priv->fbdev);
> > - kfree(dev_priv->fbdev);
> > - dev_priv->fbdev = NULL;
> > + flush_work(&ifbdev->suspend_work);
> > +
> > + intel_fbdev_destroy(ifbdev);
> > + kfree(ifbdev);
> > }
> >
> > static struct intel_fbdev *intel_fbdev_get(struct drm_device *dev)
> > @@ -788,53 +834,16 @@ static struct intel_fbdev
> > *intel_fbdev_get_if_active(struct drm_device *dev)
> > return ifbdev;
> > }
> >
> > -void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
> > synchronous)
> > +void intel_fbdev_set_suspend(struct drm_device *dev, int state)
> > {
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > struct intel_fbdev *ifbdev;
> >
> > ifbdev = intel_fbdev_get(dev);
> > if (ifbdev == NULL)
> > return;
> >
> > - if (synchronous) {
> > - /* Flush any pending work to turn the console on, and then
> > - * wait to turn it off. It must be synchronous as we are
> > - * about to suspend or unload the driver.
> > - *
> > - * Note that from within the work-handler, we cannot flush
> > - * ourselves, so only flush outstanding work upon suspend!
> > - */
> > - if (state != FBINFO_STATE_RUNNING)
> > - flush_work(&dev_priv->fbdev_suspend_work);
> > - console_lock();
> > - } else {
> > - /*
> > - * The console lock can be pretty contented on resume due
> > - * to all the printk activity. Try to keep it out of the hot
> > - * path of resume if possible.
> > - */
> > - WARN_ON(state != FBINFO_STATE_RUNNING);
> > - if (!console_trylock()) {
> > - /* Don't block our own workqueue as this can
> > - * be run in parallel with other i915.ko tasks.
> > - */
> > - schedule_work(&dev_priv->fbdev_suspend_work);
> > - return;
> > - }
> > - }
> > -
> > - /* On resume from hibernation: If the object is shmemfs backed, it has
> > - * been restored from swap. If the object is stolen however, it will be
> > - * full of whatever garbage was left in there.
> > - */
> > - if (state == FBINFO_STATE_RUNNING && ifbdev->fb->obj->stolen) {
> > - struct fb_info *info = ifbdev->helper.fbdev;
> > - memset_io(info->screen_base, 0, info->screen_size);
> > - }
> > -
> > - drm_fb_helper_set_suspend(&ifbdev->helper, state);
> > - console_unlock();
> > + __intel_fbdev_set_suspend(ifbdev, state,
> > + state != FBINFO_STATE_RUNNING);
>
> Could have changed this function name to make it easier to spot what
> you changed or not. Code motion as separate patches.
This was a separate patch! The
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Move fbdev_suspend_work to intel_fbdev
On to, 2016-03-31 at 16:30 +0100, Chris Wilson wrote:
> On Thu, Mar 31, 2016 at 06:22:01PM +0300, Joonas Lahtinen wrote:
> >
> > On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> > >
> > > static void intel_fbdev_suspend_worker(struct work_struct *work)
> > > {
> > > - intel_fbdev_set_suspend(container_of(work,
> > > - struct drm_i915_private,
> > > - fbdev_suspend_work)->dev,
> > > - FBINFO_STATE_RUNNING,
> > > - true);
> > > + __intel_fbdev_set_suspend(container_of(work,
> > > + struct intel_fbdev,
> > > + suspend_work),
> > Have the container_of on separate line at least, maybe even with a
> > macro.
> Sure.
>
> >
> > >
> > > + FBINFO_STATE_RUNNING,
> > > + true);
> > > }
> > >
> > > int intel_fbdev_init(struct drm_device *dev)
> > > @@ -716,9 +758,9 @@ int intel_fbdev_init(struct drm_device *dev)
> > > }
> > >
> > > ifbdev->helper.atomic = true;
> > > + INIT_WORK(&ifbdev->suspend_work, intel_fbdev_suspend_worker);
> > >
> > > dev_priv->fbdev = ifbdev;
> > > - INIT_WORK(&dev_priv->fbdev_suspend_work, intel_fbdev_suspend_worker);
> > >
> > > drm_fb_helper_single_add_all_connectors(&ifbdev->helper);
> > >
> > > @@ -743,17 +785,21 @@ void intel_fbdev_initial_config_async(struct
> > > drm_device *dev)
> > >
> > > void intel_fbdev_fini(struct drm_device *dev)
> > > {
> > > - struct drm_i915_private *dev_priv = dev->dev_private;
> > > - if (!dev_priv->fbdev)
> > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > + struct intel_fbdev *ifbdev;
> > > +
> > > + ifbdev = dev_priv->fbdev;
> > Straight assignment.
> >
> > >
> > > + if (ifbdev == NULL)
> I was trying to group the local assignment with the if, and I like to leave
> whitespace after the locals. By placing these two lines together this
> function looks like the majority of the other functions.
>
> >
> > >
> > > return;
> > >
> > > - flush_work(&dev_priv->fbdev_suspend_work);
> > > + dev_priv->fbdev = NULL;
> > >
> > > if (!current_is_async())
> > > async_synchronize_full();
> > > - intel_fbdev_destroy(dev, dev_priv->fbdev);
> > > - kfree(dev_priv->fbdev);
> > > - dev_priv->fbdev = NULL;
> > > + flush_work(&ifbdev->suspend_work);
> > > +
> > > + intel_fbdev_destroy(ifbdev);
> > > + kfree(ifbdev);
> > > }
> > >
> > > static struct intel_fbdev *intel_fbdev_get(struct drm_device *dev)
> > > @@ -788,53 +834,16 @@ static struct intel_fbdev
> > > *intel_fbdev_get_if_active(struct drm_device *dev)
> > > return ifbdev;
> > > }
> > >
> > > -void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
> > > synchronous)
> > > +void intel_fbdev_set_suspend(struct drm_device *dev, int state)
> > > {
> > > - struct drm_i915_private *dev_priv = dev->dev_private;
> > > struct intel_fbdev *ifbdev;
> > >
> > > ifbdev = intel_fbdev_get(dev);
> > > if (ifbdev == NULL)
> > > return;
> > >
> > > - if (synchronous) {
> > > - /* Flush any pending work to turn the console on, and then
> > > - * wait to turn it off. It must be synchronous as we are
> > > - * about to suspend or unload the driver.
> > > - *
> > > - * Note that from within the work-handler, we cannot flush
> > > - * ourselves, so only flush outstanding work upon suspend!
> > > - */
> > > - if (state != FBINFO_STATE_RUNNING)
> > > - flush_work(&dev_priv->fbdev_suspend_work);
> > > - console_lock();
> > > - } else {
> > > - /*
> > > - * The console lock can be pretty contented on resume due
> > > - * to all the printk activity. Try to keep it out of the hot
> > > - * path of resume if possible.
> > > - */
> > > - WARN_ON(state != FBINFO_STATE_RUNNING);
> > > - if (!console_trylock()) {
> > > - /* Don't block our own workqueue as this can
> > > - * be run in parallel with other i915.ko tasks.
> > > - */
> > > - schedule_work(&dev_priv->fbdev_suspend_work);
> > > - return;
> > > - }
> > > - }
> > > -
> > > - /* On resume from hibernation: If the object is shmemfs backed, it has
> > > - * been restored from swap. If the object is stolen however, it will be
> > > - * full of whatever garbage was left in there.
> > > - */
> > > - if (state == FBINFO_STATE_RUNNING && ifbdev->fb->obj->stolen) {
> > > - struct fb_info *info = ifbdev->helper.fbdev;
> > > - memset_io(info->screen_base, 0, info->screen_size);
> > > - }
> > > -
> > > - drm_fb_helper_set_suspend(&ifbdev->helper, state);
> > > - console_unlock();
> > > + __intel_fbdev_set_suspend(ifbdev, state,
> > > + state != FBI
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Protect fbdev across slow or failed initialisation
On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> If the initialisation fails, we may be left with a dangling pointer with
> an incomplete fbdev structure. Here we want to disable internal calls
> into fbdev. Similarly, the initialisation may be slow and we haven't yet
> enabled the fbdev (e.g. quick suspend or last-close before the async init
> completes).
>
> v3: To create a typo introduced when retyping
> v4: Prevent info==NULL dereference in early boot
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
> Reported-by: "Li, Weinan Z"
> Tested-by: Gabriel Feceoru
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 72
> +-
> 1 file changed, 48 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 153ea7a3fcf6..5d4be71bdf22 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -756,17 +756,47 @@ void intel_fbdev_fini(struct drm_device *dev)
> dev_priv->fbdev = NULL;
> }
>
> +static struct intel_fbdev *intel_fbdev_get(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct fb_info *info;
> +
> + if (dev_priv->fbdev == NULL)
> + return NULL;
> +
> + info = dev_priv->fbdev->helper.fbdev;
> + if (info == NULL)
> + return NULL;
> +
> + if (info->screen_base == NULL)
> + return NULL;
> +
This is rather verbose to my liking, I'd rather be dropping those '==
NULL' and convert to !. But either way to me.
> + return dev_priv->fbdev;
> +}
> +
> +static struct intel_fbdev *intel_fbdev_get_if_active(struct drm_device *dev)
> +{
> + struct intel_fbdev *ifbdev;
> +
> + ifbdev = intel_fbdev_get(dev);
> + if (ifbdev == NULL)
> + return NULL;
> +
> + if (ifbdev->helper.fbdev->state != FBINFO_STATE_RUNNING)
> + return NULL;
> +
> + return ifbdev;
> +}
> +
> void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
> synchronous)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_fbdev *ifbdev = dev_priv->fbdev;
> - struct fb_info *info;
> + struct intel_fbdev *ifbdev;
>
> - if (!ifbdev)
> + ifbdev = intel_fbdev_get(dev);
> + if (ifbdev == NULL)
> return;
>
> - info = ifbdev->helper.fbdev;
> -
> if (synchronous) {
> /* Flush any pending work to turn the console on, and then
> * wait to turn it off. It must be synchronous as we are
> @@ -798,8 +828,10 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
> state, bool synchronous
> * been restored from swap. If the object is stolen however, it will be
> * full of whatever garbage was left in there.
> */
> - if (state == FBINFO_STATE_RUNNING && ifbdev->fb->obj->stolen)
> + if (state == FBINFO_STATE_RUNNING && ifbdev->fb->obj->stolen) {
> + struct fb_info *info = ifbdev->helper.fbdev;
> memset_io(info->screen_base, 0, info->screen_size);
> + }
>
> drm_fb_helper_set_suspend(&ifbdev->helper, state);
> console_unlock();
> @@ -807,32 +839,24 @@ void intel_fbdev_set_suspend(struct drm_device *dev,
> int state, bool synchronous
>
> void intel_fbdev_output_poll_changed(struct drm_device *dev)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_fbdev *ifbdev = intel_fbdev_get_if_active(dev);
> +
> + if (ifbdev == NULL)
> + return;
>
> - async_synchronize_full();
> - if (dev_priv->fbdev)
> - drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
> + drm_fb_helper_hotplug_event(&ifbdev->helper);
> }
>
> void intel_fbdev_restore_mode(struct drm_device *dev)
> {
> - int ret;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_fbdev *ifbdev = dev_priv->fbdev;
> - struct drm_fb_helper *fb_helper;
> + struct intel_fbdev *ifbdev = intel_fbdev_get_if_active(dev);
>
> - async_synchronize_full();
What's with the async_synchronize_full() begin removed completely?
> - if (!ifbdev)
> + if (ifbdev == NULL)
Argh.
> return;
>
> - fb_helper = &ifbdev->helper;
> -
> - ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
> - if (ret) {
> - DRM_DEBUG("failed to restore crtc mode\n");
> - } else {
> - mutex_lock(&fb_helper->dev->struct_mutex);
> + if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper) == 0) {
> + mutex_lock(&dev->struct_mutex);
> intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
> - mutex_unlock(&fb_helper->dev->struct_mutex);
> + mutex_unlock(&dev->struct_mutex);
Above addressed,
Reviewed-by: Joonas Lahtinen
> }
> }
--
Joonas Lahtinen
Open Source
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Protect fbdev across slow or failed initialisation
On Thu, Mar 31, 2016 at 07:05:21PM +0300, Joonas Lahtinen wrote:
> On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> > void intel_fbdev_restore_mode(struct drm_device *dev)
> > {
> > - int ret;
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > - struct intel_fbdev *ifbdev = dev_priv->fbdev;
> > - struct drm_fb_helper *fb_helper;
> > + struct intel_fbdev *ifbdev = intel_fbdev_get_if_active(dev);
> >
> > - async_synchronize_full();
>
> What's with the async_synchronize_full() begin removed completely?
Because it's not just wrong, but completely broken imo.
During suspend, we want to freeze the async task not flush. Then here
and during resume we skip the restoration of the unregistered fbdev, and
then when the task is woken it can complete the registration and present
the vanilla ifbdev.
During hibernation, we really just want to cancel the task and start
from scratch on resume.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Release module reference on creation failure
On to, 2016-03-31 at 09:35 +0100, Chris Wilson wrote:
> If we fail to create the anon file, we need to remember to release the
> module reference on the owner.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Daniel Vetter
> Cc: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
> drivers/dma-buf/dma-buf.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 4a2c07ee6677..6f0f0b10a241 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -333,6 +333,7 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> struct reservation_object *resv = exp_info->resv;
> struct file *file;
> size_t alloc_size = sizeof(struct dma_buf);
> + int ret;
>
> if (!exp_info->resv)
> alloc_size += sizeof(struct reservation_object);
> @@ -356,8 +357,8 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
>
> dmabuf = kzalloc(alloc_size, GFP_KERNEL);
> if (!dmabuf) {
> - module_put(exp_info->owner);
> - return ERR_PTR(-ENOMEM);
> + ret = -ENOMEM;
> + goto free_module;
> }
>
> dmabuf->priv = exp_info->priv;
> @@ -378,8 +379,8 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf,
> exp_info->flags);
> if (IS_ERR(file)) {
> - kfree(dmabuf);
> - return ERR_CAST(file);
> + ret = PTR_ERR(file);
> + goto free_dmabuf;
> }
>
> file->f_mode |= FMODE_LSEEK;
> @@ -393,6 +394,12 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> mutex_unlock(&db_list.lock);
>
> return dmabuf;
> +
> +free_dmabuf:
> + kfree(dmabuf);
> +free_module:
> + module_put(exp_info->owner);
> + return ERR_PTR(ret);
Labels could really be err_dmabuf (/ out_dmabuf). That's more in line
with rest of the codebase and kernel coding style: 'An example of a
good name could be "out_buffer:" if the goto frees "buffer".'
"free_dmabuf" does sound to me like it could also be executed on the
normal execution path of the function.
Other than that,
Reviewed-by: Joonas Lahtinen
> }
> EXPORT_SYMBOL_GPL(dma_buf_export);
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Protect fbdev across slow or failed initialisation
On to, 2016-03-31 at 17:13 +0100, Chris Wilson wrote:
> On Thu, Mar 31, 2016 at 07:05:21PM +0300, Joonas Lahtinen wrote:
> >
> > On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> > >
> > > void intel_fbdev_restore_mode(struct drm_device *dev)
> > > {
> > > - int ret;
> > > - struct drm_i915_private *dev_priv = dev->dev_private;
> > > - struct intel_fbdev *ifbdev = dev_priv->fbdev;
> > > - struct drm_fb_helper *fb_helper;
> > > + struct intel_fbdev *ifbdev = intel_fbdev_get_if_active(dev);
> > >
> > > - async_synchronize_full();
> > What's with the async_synchronize_full() begin removed completely?
> Because it's not just wrong, but completely broken imo.
>
> During suspend, we want to freeze the async task not flush. Then here
> and during resume we skip the restoration of the unregistered fbdev, and
> then when the task is woken it can complete the registration and present
> the vanilla ifbdev.
>
> During hibernation, we really just want to cancel the task and start
> from scratch on resume.
Maybe Ack from Lukas with those? As this is effectively a revert of :
commit a7442b93cf32c1e1ddb721a26cd1f92302e2a222
Author: Lukas Wunner
Date: Wed Mar 9 12:52:53 2016 +0100
drm/i915: Fix races on fbdev
Committed without R-b by Daniel, so maybe he has a comment on it too.
Regards, Joonas
> -Chris
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Protect fbdev across slow or failed initialisation
Hi Chris,
On Thu, Mar 31, 2016 at 05:13:55PM +0100, Chris Wilson wrote:
> On Thu, Mar 31, 2016 at 07:05:21PM +0300, Joonas Lahtinen wrote:
> > On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> > > void intel_fbdev_restore_mode(struct drm_device *dev)
> > > {
> > > - int ret;
> > > - struct drm_i915_private *dev_priv = dev->dev_private;
> > > - struct intel_fbdev *ifbdev = dev_priv->fbdev;
> > > - struct drm_fb_helper *fb_helper;
> > > + struct intel_fbdev *ifbdev = intel_fbdev_get_if_active(dev);
> > >
> > > - async_synchronize_full();
> >
> > What's with the async_synchronize_full() begin removed completely?
>
> Because it's not just wrong, but completely broken imo.
>
> During suspend, we want to freeze the async task not flush.
> Then here and during resume we skip the restoration of the unregistered
> fbdev, and then when the task is woken it can complete the registration
> and present the vanilla ifbdev.
No. The fbdev initialization is guaranteed to have finished before
suspend. So "we want to freeze the async task" is wrong thinking.
There is no async task to freeze.
Please read the commit message of a7442b93cf32 ("drm/i915: Fix races
on fbdev"):
"a device is never suspended until its ->probe callback (and all
asynchronous tasks it scheduled) have finished. See dpm_prepare(),
which calls wait_for_device_probe(), which calls async_synchronize_full()."
Best regards,
Lukas
> During hibernation, we really just want to cancel the task and start
> from scratch on resume.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for pwm: add support for atomic update
== Series Details == Series: pwm: add support for atomic update URL : https://patchwork.freedesktop.org/series/5071/ State : failure == Summary == Series 5071v1 pwm: add support for atomic update http://patchwork.freedesktop.org/api/1.0/series/5071/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (bsw-nuc-2) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bsw-nuc-2total:196 pass:157 dwarn:1 dfail:0 fail:1 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:60 pass:53 dwarn:0 dfail:0 fail:0 skip:6 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_1762/ d42383d7815f4498871e8d73f10677cf1e48aa28 drm-intel-nightly: 2016y-03m-31d-14h-56m-52s UTC integration manifest 9f9c3c0506b26463d538a9bbd940584edd1cb6b7 ARM: s3c24xx: rx1950: switch to the atomic PWM API 75d8fe54ab35343dcc9848748dfd8c9e19387dd3 drm: i915: switch to the atomic PWM API 23781817a2fb84e2c51fe54bbb719e4fdf1d4fbf video: ssd1307fb: switch to the atomic PWM API d828dd126c102573cb603ca747bdff64dd6d042a backlight: pwm_bl: switch to the atomic PWM API 2f9fb91854be0b9088fa65e17957418fb6f621cd backlight: lp8788: switch to the atomic PWM API 7bb8580bb95d45f9b22009d0d7e22fc2f86ca69b backlight: lp855x: switch to the atomic PWM API fbd8abd7d85c9af226d99b6f237835e8364a3b2c backlight: lm3630a: switch to the atomic PWM API b895f742ae8abd9e5e0b0d1cab573dc22ae85b31 leds: pwm: switch to the atomic PWM API f91c66f0d00580cfe6bfa9840839368fd8982b9f input: misc: pwm-beeper: switch to the atomic PWM API 678ba7c81789d61cdb0f51e4b3c8843b25eecc55 input: misc: max8997: switch to the atomic PWM API fbaf303c6491d7d61873e36eb93c133f3e4ac2fd input: misc: max77693: switch to the atomic API 582e5cf6adfa35ca05911b819ab560723a86c029 hwmon: pwm-fan: switch to the atomic API baf8eed76d1d04781152263f23af236f1e8aa448 clk: pwm: switch to the atomic API 933502d9e7830dbe68fb8bf1b96f71b730d3e8cb pwm: replace pwm_disable() by pwm_apply_state() 8d3e25557ee47de6ab6825fde7622626ec6d0b64 pwm: deprecate pwm_config(), pwm_enable() and pwm_disable() 2a8a331c4507426f3757aae42470bcd3174dd2a0 pwm: update documentation b296ff7947e1e0aadc4c05879a5066f282feb051 regulator: pwm: retrieve correct voltage 1204ad007544a75bd04a8232aa2218635ddd788f regulator: pwm: properly initialize the ->state field 49344a5c8edebf1c6c4a99339f576bf7cad76205 regulator: pwm: swith to the atomic PWM API 7a564646f4875ba6f7d4f7d0535c053d32b708ae regulator: pwm: adjust PWM config at probe time b950f24348c7574e55ab794aa80add6f59b8531c pwm: sun4i: implement hardware readout 8791ff8087452e811cb69345374a72c8526f15a6 pwm: sti: avoid glitches on already running PWMs 5484ac0bcf242ca9f615aa8e076491af526fd18e pwm: sti: add support for initial state retrieval d2fa8eb1478a0fcd8284cac7cd1fbda7fd3c5c94 pwm: rockchip: add support for atomic update eff9f0f0e8d05c4b1e10759537f2c892d9d257b8 pwm: rockchip: avoid glitches on already running PWMs 4787861385531f936c90ec3a0d1a07a07b486037 pwm: rockchip: add initial state retrieval bf1c0fbab900a45b1c151f8ef986892049ce80c9 pwm: add information about polarity, duty cycle and period to debugfs 5538ff1cac1494fd71abb806cbdd00e599bd3390 pwm: switch to the atomic API 8fafbf04c07cabca9c223e30f4dac8d78832734a pwm: add the core infrastructure to allow atomic update 01c45e5ca50610117aeeb6ad0019ef13913f2fdb pwm: add the PWM initial state retrieval infra f219828a341e476e23862cac844b916aed289380 pwm: move the enabled/disabled info into pwm_state f50294f9ae5b8eb106f0f47ce6ac54f2663565ab pwm: introduce the pwm_state concept f07996b1a7520069323bb0b89d47cde67cedc6ed pwm: keep PWM state in sync with hardware state 9da79c4715fee7ee2e3d0b7ee5df9893e9b9bbe8 backlight: pwm_bl: use pwm_get_args() where appropriate 69bbc492e433c399613e611a61982870b5e625c7 fbdev: ssd1307fb: use pwm_get_args() where appropriate 0c0daaa9e391711948b10a3250148921aecd39c6 regulator: pwm: use pwm_get_args() where appropriate 9441751d1682edfb633b69f5a2fa2d646daccfb7 leds: pwm: use pwm_get_args() where appropriate 5d99addc05004f3e23a828a0bb94682655e9080f misc: max77693-haptic: use pwm_get_args() where appropriate 8c24bbb9c4485b20c72f8a9b21bd1634861a6712 hwmon: pwm-fan: use pwm_get_args() where appropriate 3599c2ae1317e943ca3aad748b1d7d421e415995 clk: pwm: use pwm_get_args() where appropriate f93b4e66a606f4a376f51d028806d886f818fe72 pwm: use pwm_get/set_xxx() helpers where appropriate 542ffa32b6
[Intel-gfx] ✗ Fi.CI.BAT: failure for dma-buf: Release module reference on creation failure
== Series Details == Series: dma-buf: Release module reference on creation failure URL : https://patchwork.freedesktop.org/series/5088/ State : failure == Summary == Series 5088v1 dma-buf: Release module reference on creation failure http://patchwork.freedesktop.org/api/1.0/series/5088/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-rte: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bsw-nuc-2total:196 pass:158 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:55 pass:50 dwarn:0 dfail:0 fail:0 skip:4 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_1763/ d42383d7815f4498871e8d73f10677cf1e48aa28 drm-intel-nightly: 2016y-03m-31d-14h-56m-52s UTC integration manifest 2823987be67a890e00b139d6cb255260af3d4a01 dma-buf: Release module reference on creation failure ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: BXT DDI PHY sequence BUN
According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register needs to be
checked to ensure that the register is in accessible state.
Also, based on a BSpec update, changing the timeout value to
check iphypwrgood, from 10ms to wait for up to 100us.
v2: use wait_for_us instead of the atomic call.
Signed-off-by: Vandana Kannan
Reported-by: Philippe Lecluse
Cc: Deak, Imre
Cc: Nikula, Jani
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 15 +--
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc400..9a02bfc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1318,6 +1318,7 @@ enum skl_disp_power_wells {
#define _PORT_CL1CM_DW0_A 0x162000
#define _PORT_CL1CM_DW0_BC 0x6C000
#define PHY_POWER_GOOD (1 << 16)
+#define PHY_RESERVED (1 << 7)
#define BXT_PORT_CL1CM_DW0(phy)_BXT_PHY((phy),
_PORT_CL1CM_DW0_BC, \
_PORT_CL1CM_DW0_A)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 62de9f4..05a5b3a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2669,9 +2669,20 @@ static void broxton_phy_init(struct drm_i915_private
*dev_priv,
val |= GT_DISPLAY_POWER_ON(phy);
I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
- /* Considering 10ms timeout until BSpec is updated */
- if (wait_for(I915_READ(BXT_PORT_CL1CM_DW0(phy)) & PHY_POWER_GOOD, 10))
+ /*
+* The PHY registers start out inaccessible and respond to reads with
+* all 1s. Eventually they become accessible as they power up, then
+* the reserved bit will give the default 0. Poll on the reserved bit
+* becoming 0 to find when the PHY is accessible.
+* HW team confirmed that the time to reach phypowergood status is
+* anywhere between 50 us and 100us.
+*/
+ if (wait_for_us(((!(I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
+ PHY_RESERVED)) &&
+ ((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
+ PHY_POWER_GOOD) == PHY_POWER_GOOD)), 100)) {
DRM_ERROR("timeout during PHY%d power on\n", phy);
+ }
for (port = (phy == DPIO_PHY0 ? PORT_B : PORT_A);
port <= (phy == DPIO_PHY0 ? PORT_C : PORT_A); port++) {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: BXT DDI PHY sequence BUN
On to, 2016-03-31 at 22:40 +0530, Vandana Kannan wrote:
> According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register needs to be
> checked to ensure that the register is in accessible state.
> Also, based on a BSpec update, changing the timeout value to
> check iphypwrgood, from 10ms to wait for up to 100us.
>
> v2: use wait_for_us instead of the atomic call.
>
> Signed-off-by: Vandana Kannan
> Reported-by: Philippe Lecluse
> Cc: Deak, Imre
> Cc: Nikula, Jani
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_ddi.c | 15 +--
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 7dfc400..9a02bfc 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1318,6 +1318,7 @@ enum skl_disp_power_wells {
> #define _PORT_CL1CM_DW0_A0x162000
> #define _PORT_CL1CM_DW0_BC 0x6C000
> #define PHY_POWER_GOOD (1 << 16)
> +#define PHY_RESERVED (1 << 7)
> #define BXT_PORT_CL1CM_DW0(phy) _BXT_PHY((phy),
> _PORT_CL1CM_DW0_BC, \
> _PORT_CL1CM_DW0_A)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 62de9f4..05a5b3a 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2669,9 +2669,20 @@ static void broxton_phy_init(struct drm_i915_private
> *dev_priv,
> val |= GT_DISPLAY_POWER_ON(phy);
> I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
>
> - /* Considering 10ms timeout until BSpec is updated */
> - if (wait_for(I915_READ(BXT_PORT_CL1CM_DW0(phy)) & PHY_POWER_GOOD, 10))
> + /*
> + * The PHY registers start out inaccessible and respond to reads with
> + * all 1s. Eventually they become accessible as they power up, then
> + * the reserved bit will give the default 0. Poll on the reserved bit
> + * becoming 0 to find when the PHY is accessible.
> + * HW team confirmed that the time to reach phypowergood status is
> + * anywhere between 50 us and 100us.
> + */
> + if (wait_for_us(((!(I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> + PHY_RESERVED)) &&
> + ((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> + PHY_POWER_GOOD) == PHY_POWER_GOOD)), 100)) {
> DRM_ERROR("timeout during PHY%d power on\n", phy);
Thanks. This is still missing Jani's comment, that is reading out the
register only once and applying a mask before comparing against
PHY_POWER_GOOD.
--Imre
> + }
>
> for (port = (phy == DPIO_PHY0 ? PORT_B : PORT_A);
> port <= (phy == DPIO_PHY0 ? PORT_C : PORT_A); port++) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: BXT DDI PHY sequence BUN
> -Original Message-
> From: Deak, Imre
> Sent: Thursday, March 31, 2016 9:45 AM
> To: Kannan, Vandana ; intel-
> g...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: Re: [PATCH v2] drm/i915: BXT DDI PHY sequence BUN
>
> On to, 2016-03-31 at 22:40 +0530, Vandana Kannan wrote:
> > According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register
> needs
> > to be checked to ensure that the register is in accessible state.
> > Also, based on a BSpec update, changing the timeout value to check
> > iphypwrgood, from 10ms to wait for up to 100us.
> >
> > v2: use wait_for_us instead of the atomic call.
> >
> > Signed-off-by: Vandana Kannan
> > Reported-by: Philippe Lecluse
> > Cc: Deak, Imre
> > Cc: Nikula, Jani
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_ddi.c | 15 +--
> > 2 files changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 7dfc400..9a02bfc 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1318,6 +1318,7 @@ enum skl_disp_power_wells {
> > #define _PORT_CL1CM_DW0_A 0x162000
> > #define _PORT_CL1CM_DW0_BC 0x6C000
> > #define PHY_POWER_GOOD (1 << 16)
> > +#define PHY_RESERVED (1 << 7)
> > #define BXT_PORT_CL1CM_DW0(phy)_BXT_PHY((phy),
> _PORT_CL1CM_DW0_BC, \
> > _PORT_CL1CM_DW0_A)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 62de9f4..05a5b3a 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2669,9 +2669,20 @@ static void broxton_phy_init(struct
> drm_i915_private *dev_priv,
> > val |= GT_DISPLAY_POWER_ON(phy);
> > I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
> >
> > - /* Considering 10ms timeout until BSpec is updated */
> > - if (wait_for(I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> PHY_POWER_GOOD, 10))
> > + /*
> > + * The PHY registers start out inaccessible and respond to reads
> with
> > + * all 1s. Eventually they become accessible as they power up, then
> > + * the reserved bit will give the default 0. Poll on the reserved bit
> > + * becoming 0 to find when the PHY is accessible.
> > + * HW team confirmed that the time to reach phypowergood status
> is
> > + * anywhere between 50 us and 100us.
> > + */
> > + if (wait_for_us(((!(I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> > + PHY_RESERVED)) &&
> > + ((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> > + PHY_POWER_GOOD) ==
> PHY_POWER_GOOD)), 100)) {
> > DRM_ERROR("timeout during PHY%d power on\n", phy);
>
> Thanks. This is still missing Jani's comment, that is reading out the register
> only once and applying a mask before comparing against
> PHY_POWER_GOOD.
>
> --Imre
>
[Vandana]
Oh! Thought he said its fine on an updated mail.
"
>> +if (wait_for_atomic_us(((!(I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
>> +PHY_RESERVED)) &&
>> +((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
>> + PHY_POWER_GOOD) == PHY_POWER_GOOD)), 100)) {
>
> Is there any reason why you'd need to do the read twice? Why not just
> write it as:
>
> (I915_READ(BXT_PORT_CL1CM_DW0(phy)) & (PHY_RESERVED | PHY_POWER_GOOD))
> == PHY_POWER_GOOD
AFAICT this should be fine.
BR,
Jani.
"
> > + }
> >
> > for (port = (phy == DPIO_PHY0 ? PORT_B : PORT_A);
> > port <= (phy == DPIO_PHY0 ? PORT_C : PORT_A); port++) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Do not use INTEL_INFO(dev_priv->dev)
dev_priv is what the macro works hard to extract, pass it directly.
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2d53b67..e99177a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2306,7 +2306,7 @@ void i915_check_and_clear_faults(struct drm_device *dev)
static void i915_ggtt_flush(struct drm_i915_private *dev_priv)
{
- if (INTEL_INFO(dev_priv->dev)->gen < 6) {
+ if (INTEL_INFO(dev_priv)->gen < 6) {
intel_gtt_chipset_flush();
} else {
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a9c1813..6b1dae7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2828,7 +2828,7 @@ semaphore_wait_to_signaller_ring(struct intel_engine_cs
*engine, u32 ipehr,
struct drm_i915_private *dev_priv = engine->dev->dev_private;
struct intel_engine_cs *signaller;
- if (INTEL_INFO(dev_priv->dev)->gen >= 8) {
+ if (INTEL_INFO(dev_priv)->gen >= 8) {
for_each_engine(signaller, dev_priv) {
if (engine == signaller)
continue;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e6b5ee5..a2853b1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1196,7 +1196,7 @@ static void assert_fdi_tx_pll_enabled(struct
drm_i915_private *dev_priv,
u32 val;
/* ILK FDI PLL is always enabled */
- if (INTEL_INFO(dev_priv->dev)->gen == 5)
+ if (INTEL_INFO(dev_priv)->gen == 5)
return;
/* On Haswell, DDI ports are responsible for the FDI PLL setup */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index ac1c545..8ecdbdc 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1161,7 +1161,7 @@ static void intel_uncore_fw_domains_init(struct
drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- if (INTEL_INFO(dev_priv->dev)->gen <= 5)
+ if (INTEL_INFO(dev_priv)->gen <= 5)
return;
if (IS_GEN9(dev)) {
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernfs: Move faulting copy_user operations outside of the mutex
On Thu, Mar 31, 2016 at 11:45:06AM +0100, Chris Wilson wrote: > A fault in a user provided buffer may lead anywhere, and lockdep warns > that we have a potential deadlock between the mm->mmap_sem and the > kernfs file mutex: ... > Reported-by: Ville Syrjälä > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350 > Signed-off-by: Chris Wilson > Reviewed-by: Joonas Lahtinen > Cc: Ville Syrjälä > Cc: Joonas Lahtinen > Cc: Tejun Heo > Cc: Greg Kroah-Hartman > Cc: NeilBrown > Cc: linux-ker...@vger.kernel.org Acked-by: Tejun Heo Thanks! -- tejun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Use i915_vm_to_ppgtt instead of manual container_of
As we have the function with error checking, use it.
Cc: Daniel Vetter
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 36
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ae9cb27..2d53b67 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -706,8 +706,7 @@ static void gen8_ppgtt_clear_pte_range(struct
i915_address_space *vm,
uint64_t length,
gen8_pte_t scratch_pte)
{
- struct i915_hw_ppgtt *ppgtt =
- container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
gen8_pte_t *pt_vaddr;
unsigned pdpe = gen8_pdpe_index(start);
unsigned pde = gen8_pde_index(start);
@@ -762,8 +761,7 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
uint64_t length,
bool use_scratch)
{
- struct i915_hw_ppgtt *ppgtt =
- container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
gen8_pte_t scratch_pte = gen8_pte_encode(px_dma(vm->scratch_page),
I915_CACHE_LLC, use_scratch);
@@ -788,8 +786,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_address_space *vm,
uint64_t start,
enum i915_cache_level cache_level)
{
- struct i915_hw_ppgtt *ppgtt =
- container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
gen8_pte_t *pt_vaddr;
unsigned pdpe = gen8_pdpe_index(start);
unsigned pde = gen8_pde_index(start);
@@ -829,8 +826,7 @@ static void gen8_ppgtt_insert_entries(struct
i915_address_space *vm,
enum i915_cache_level cache_level,
u32 unused)
{
- struct i915_hw_ppgtt *ppgtt =
- container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct sg_page_iter sg_iter;
__sg_page_iter_start(&sg_iter, pages->sgl, sg_nents(pages->sgl), 0);
@@ -981,8 +977,7 @@ static void gen8_ppgtt_cleanup_4lvl(struct i915_hw_ppgtt
*ppgtt)
static void gen8_ppgtt_cleanup(struct i915_address_space *vm)
{
- struct i915_hw_ppgtt *ppgtt =
- container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
if (intel_vgpu_active(vm->dev))
gen8_ppgtt_notify_vgt(ppgtt, false);
@@ -1216,8 +1211,7 @@ static int gen8_alloc_va_range_3lvl(struct
i915_address_space *vm,
uint64_t start,
uint64_t length)
{
- struct i915_hw_ppgtt *ppgtt =
- container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
unsigned long *new_page_dirs, *new_page_tables;
struct drm_device *dev = vm->dev;
struct i915_page_directory *pd;
@@ -1329,8 +1323,7 @@ static int gen8_alloc_va_range_4lvl(struct
i915_address_space *vm,
uint64_t length)
{
DECLARE_BITMAP(new_pdps, GEN8_PML4ES_PER_PML4);
- struct i915_hw_ppgtt *ppgtt =
- container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct i915_page_directory_pointer *pdp;
uint64_t pml4e;
int ret = 0;
@@ -1376,8 +1369,7 @@ err_out:
static int gen8_alloc_va_range(struct i915_address_space *vm,
uint64_t start, uint64_t length)
{
- struct i915_hw_ppgtt *ppgtt =
- container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
if (USES_FULL_48BIT_PPGTT(vm->dev))
return gen8_alloc_va_range_4lvl(vm, &ppgtt->pml4, start,
length);
@@ -1795,8 +1787,7 @@ static void gen6_ppgtt_clear_range(struct
i915_address_space *vm,
uint64_t length,
bool use_scratch)
{
- struct i915_hw_ppgtt *ppgtt =
- container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
gen6_pte_t *pt_vaddr, scratch_pte;
unsigned first_entry = start >> PAGE_SHIFT;
unsigned num_entries = length >> PAGE_SHIFT;
@@ -1830,8 +1821,7 @@ static void gen6_ppgtt_insert_entries(struct
i915_address_space *vm,
uint64_t start,
enum i915_cache_level cache_level, u32
flags)
{
- struct i915_
Re: [Intel-gfx] [PATCH v2] drm/i915: BXT DDI PHY sequence BUN
On to, 2016-03-31 at 19:47 +0300, Kannan, Vandana wrote:
> > -Original Message-
> > From: Deak, Imre
> > Sent: Thursday, March 31, 2016 9:45 AM
> > To: Kannan, Vandana ; intel-
> > g...@lists.freedesktop.org
> > Cc: Nikula, Jani
> > Subject: Re: [PATCH v2] drm/i915: BXT DDI PHY sequence BUN
> >
> > On to, 2016-03-31 at 22:40 +0530, Vandana Kannan wrote:
> > > According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register
> > needs
> > > to be checked to ensure that the register is in accessible state.
> > > Also, based on a BSpec update, changing the timeout value to check
> > > iphypwrgood, from 10ms to wait for up to 100us.
> > >
> > > v2: use wait_for_us instead of the atomic call.
> > >
> > > Signed-off-by: Vandana Kannan
> > > Reported-by: Philippe Lecluse
> > > Cc: Deak, Imre
> > > Cc: Nikula, Jani
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > > drivers/gpu/drm/i915/intel_ddi.c | 15 +--
> > > 2 files changed, 14 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h index 7dfc400..9a02bfc 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -1318,6 +1318,7 @@ enum skl_disp_power_wells {
> > > #define _PORT_CL1CM_DW0_A0x162000
> > > #define _PORT_CL1CM_DW0_BC 0x6C000
> > > #define PHY_POWER_GOOD (1 << 16)
> > > +#define PHY_RESERVED (1 << 7)
> > > #define BXT_PORT_CL1CM_DW0(phy) _BXT_PHY((phy),
> > _PORT_CL1CM_DW0_BC, \
> > > _PORT_CL1CM_DW0_A)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 62de9f4..05a5b3a 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -2669,9 +2669,20 @@ static void broxton_phy_init(struct
> > drm_i915_private *dev_priv,
> > > val |= GT_DISPLAY_POWER_ON(phy);
> > > I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
> > >
> > > - /* Considering 10ms timeout until BSpec is updated */
> > > - if (wait_for(I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> > PHY_POWER_GOOD, 10))
> > > + /*
> > > + * The PHY registers start out inaccessible and respond to reads
> > with
> > > + * all 1s. Eventually they become accessible as they power up, then
> > > + * the reserved bit will give the default 0. Poll on the reserved bit
> > > + * becoming 0 to find when the PHY is accessible.
> > > + * HW team confirmed that the time to reach phypowergood status
> > is
> > > + * anywhere between 50 us and 100us.
> > > + */
> > > + if (wait_for_us(((!(I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> > > + PHY_RESERVED)) &&
> > > + ((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> > > + PHY_POWER_GOOD) ==
> > PHY_POWER_GOOD)), 100)) {
> > > DRM_ERROR("timeout during PHY%d power on\n", phy);
> >
> > Thanks. This is still missing Jani's comment, that is reading out the
> > register
> > only once and applying a mask before comparing against
> > PHY_POWER_GOOD.
> >
> > --Imre
> >
> [Vandana]
> Oh! Thought he said its fine on an updated mail.
Hm, if you check below,
>
> "
> > > + if (wait_for_atomic_us(((!(I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> > > + PHY_RESERVED)) &&
> > > + ((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> > > + PHY_POWER_GOOD) == PHY_POWER_GOOD)), 100)) {
> >
> > Is there any reason why you'd need to do the read twice? Why not just
> > write it as:
> >
> > (I915_READ(BXT_PORT_CL1CM_DW0(phy)) & (PHY_RESERVED | PHY_POWER_GOOD))
> > == PHY_POWER_GOOD
>
> AFAICT this should be fine.
This just means what I also asked. I'd prefer this, since reading out the
register twice is redundant and makes the reader wonder why it was needed
in the first place.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Update VBT fields for child devices
== Series Details == Series: series starting with [1/2] drm/i915: Update VBT fields for child devices URL : https://patchwork.freedesktop.org/series/5095/ State : failure == Summary == Series 5095v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/5095/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> INCOMPLETE (bsw-nuc-2) Test pm_rpm: Subgroup basic-rte: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bsw-nuc-2total:114 pass:89 dwarn:1 dfail:0 fail:0 skip:23 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:81 pass:76 dwarn:0 dfail:0 fail:0 skip:4 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_1764/ d42383d7815f4498871e8d73f10677cf1e48aa28 drm-intel-nightly: 2016y-03m-31d-14h-56m-52s UTC integration manifest b178c2d87d15683606dc0ab01af9cf6be9dc9f09 drm/i915: Set invert bit for hpd based on VBT 2353f468233d83da6e45c337d6c0874b0d55e745 drm/i915: Update VBT fields for child devices ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use i915_vm_to_ppgtt instead of manual container_of
On Thu, Mar 31, 2016 at 07:49:38PM +0300, Joonas Lahtinen wrote: > As we have the function with error checking, use it. However, that error checking turns up in the profiles for some GL benchmarks. Crazy huh! Note also that you missed an opportunity in i915_gem_restore_gtt_mappins() Please let's just treat the programmer with a little respect here. If you kindly remove the WARN, then Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Do not use INTEL_INFO(dev_priv->dev)
On Thu, Mar 31, 2016 at 07:49:39PM +0300, Joonas Lahtinen wrote:
> dev_priv is what the macro works hard to extract, pass it directly.
=0 haswell:/usr/src/linux (tasklet)$ git grep -e '[A-Z].*(dev_priv->dev)' --
drivers/gpu/drm/i915/
drivers/gpu/drm/i915/i915_debugfs.c:if (!HAS_GUC_UCODE(dev_priv->dev))
drivers/gpu/drm/i915/i915_debugfs.c:if (!HAS_GUC_SCHED(dev_priv->dev))
drivers/gpu/drm/i915/i915_drv.c:if (!IS_CHERRYVIEW(dev_priv->dev))
drivers/gpu/drm/i915/i915_drv.c:if (!IS_CHERRYVIEW(dev_priv->dev))
drivers/gpu/drm/i915/i915_gem_gtt.c:if (INTEL_INFO(dev_priv->dev)->gen < 6)
{
drivers/gpu/drm/i915/i915_gem_gtt.c:if (!USES_PPGTT(dev_priv->dev))
drivers/gpu/drm/i915/i915_gpu_error.c: if (use_ggtt && src->cache_level !=
I915_CACHE_NONE && !HAS_LLC(dev_priv->dev))
drivers/gpu/drm/i915/i915_gpu_error.c: if (HAS_VEBOX(dev_priv->dev)) {
drivers/gpu/drm/i915/i915_irq.c:if (WARN_ON_ONCE(slice >=
NUM_L3_SLICES(dev_priv->dev)))
drivers/gpu/drm/i915/i915_irq.c:if (HAS_VEBOX(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_audio.c: if (HAS_PCH_IBX(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_display.c: if (HAS_DDI(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_display.c: if (INTEL_INFO(dev_priv->dev)->gen == 5)
drivers/gpu/drm/i915/intel_display.c: if (HAS_DDI(dev_priv->dev))
drivers/gpu/drm/i915/intel_display.c: if (HAS_PCH_CPT(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_display.c: } else if
(IS_CHERRYVIEW(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_display.c: if (HAS_PCH_CPT(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_display.c: } else if
(IS_CHERRYVIEW(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_display.c: if (HAS_PCH_CPT(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_display.c: if (HAS_PCH_CPT(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_display.c:
I915_STATE_WARN(HAS_PCH_IBX(dev_priv->dev) && (val & DP_PORT_EN) == 0
drivers/gpu/drm/i915/intel_display.c:
I915_STATE_WARN(HAS_PCH_IBX(dev_priv->dev) && (val & SDVO_ENABLE) == 0
drivers/gpu/drm/i915/intel_display.c: if (IS_MOBILE(dev_priv->dev))
drivers/gpu/drm/i915/intel_display.c: if (HAS_PCH_IBX(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_display.c: if (HAS_PCH_IBX(dev_priv->dev)
&&
drivers/gpu/drm/i915/intel_display.c: BUG_ON(!HAS_PCH_SPLIT(dev_priv->dev));
drivers/gpu/drm/i915/intel_display.c: if (HAS_PCH_LPT(dev_priv->dev))
drivers/gpu/drm/i915/intel_display.c: if (HAS_GMCH_DISPLAY(dev_priv->dev))
drivers/gpu/drm/i915/intel_display.c: if (IS_HASWELL(dev_priv->dev))
drivers/gpu/drm/i915/intel_display.c: if (HAS_PCH_IBX(dev_priv->dev))
{
drivers/gpu/drm/i915/intel_display.c: if (HAS_DDI(dev_priv->dev))
drivers/gpu/drm/i915/intel_dpll_mgr.c:
I915_STATE_WARN_ON(!(HAS_PCH_IBX(dev_priv->dev) || HAS_PCH_CPT(dev_priv->dev)));
drivers/gpu/drm/i915/intel_fifo_underrun.c: if (HAS_PCH_IBX(dev_priv->dev))
drivers/gpu/drm/i915/intel_fifo_underrun.c: if
(HAS_GMCH_DISPLAY(dev_priv->dev) &&
drivers/gpu/drm/i915/intel_hdmi.c: else if (HAS_PCH_SPLIT(dev_priv->dev))
drivers/gpu/drm/i915/intel_i2c.c: if (!IS_PINEVIEW(dev_priv->dev))
drivers/gpu/drm/i915/intel_i2c.c: if (!HAS_GMBUS_IRQ(dev_priv->dev))
drivers/gpu/drm/i915/intel_i2c.c: if (!HAS_GMBUS_IRQ(dev_priv->dev))
drivers/gpu/drm/i915/intel_pm.c:if (IS_GEN9(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_pm.c:if (IS_GEN9(dev_priv->dev))
drivers/gpu/drm/i915/intel_pm.c:else if (IS_CHERRYVIEW(dev_priv->dev))
drivers/gpu/drm/i915/intel_pm.c:else if (IS_VALLEYVIEW(dev_priv->dev))
drivers/gpu/drm/i915/intel_pm.c:if (IS_GEN9(dev_priv->dev))
drivers/gpu/drm/i915/intel_pm.c:else if (IS_CHERRYVIEW(dev_priv->dev))
drivers/gpu/drm/i915/intel_pm.c:else if (IS_VALLEYVIEW(dev_priv->dev))
drivers/gpu/drm/i915/intel_psr.c: if (HAS_DDI(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_runtime_pm.c:if (IS_HASWELL(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_runtime_pm.c:} else if
(IS_BROADWELL(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_runtime_pm.c:} else if
(IS_SKYLAKE(dev_priv->dev) || IS_KABYLAKE(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_runtime_pm.c:} else if
(IS_BROXTON(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_runtime_pm.c:} else if
(IS_CHERRYVIEW(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_runtime_pm.c:} else if
(IS_VALLEYVIEW(dev_priv->dev)) {
drivers/gpu/drm/i915/intel_uncore.c:if (IS_VALLEYVIEW(dev_priv->dev))
drivers/gpu/drm/i915/intel_uncore.c:if (INTEL_INFO(dev_priv->dev)->gen <= 5)
are all good candidates for contraction.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: BXT DDI PHY sequence BUN
According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register needs to be
checked to ensure that the register is in accessible state.
Also, based on a BSpec update, changing the timeout value to
check iphypwrgood, from 10ms to wait for up to 100us.
v2: [Ville] use wait_for_us instead of the atomic call.
v3: [Jani/Imre] read register only once
Signed-off-by: Vandana Kannan
Reported-by: Philippe Lecluse
Cc: Deak, Imre
Cc: Nikula, Jani
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc400..9a02bfc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1318,6 +1318,7 @@ enum skl_disp_power_wells {
#define _PORT_CL1CM_DW0_A 0x162000
#define _PORT_CL1CM_DW0_BC 0x6C000
#define PHY_POWER_GOOD (1 << 16)
+#define PHY_RESERVED (1 << 7)
#define BXT_PORT_CL1CM_DW0(phy)_BXT_PHY((phy),
_PORT_CL1CM_DW0_BC, \
_PORT_CL1CM_DW0_A)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 62de9f4..4a8f504 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2669,9 +2669,18 @@ static void broxton_phy_init(struct drm_i915_private
*dev_priv,
val |= GT_DISPLAY_POWER_ON(phy);
I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
- /* Considering 10ms timeout until BSpec is updated */
- if (wait_for(I915_READ(BXT_PORT_CL1CM_DW0(phy)) & PHY_POWER_GOOD, 10))
+ /*
+* The PHY registers start out inaccessible and respond to reads with
+* all 1s. Eventually they become accessible as they power up, then
+* the reserved bit will give the default 0. Poll on the reserved bit
+* becoming 0 to find when the PHY is accessible.
+* HW team confirmed that the time to reach phypowergood status is
+* anywhere between 50 us and 100us.
+*/
+ if (wait_for_us(((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
+ (PHY_RESERVED | PHY_POWER_GOOD)) == PHY_POWER_GOOD), 100)) {
DRM_ERROR("timeout during PHY%d power on\n", phy);
+ }
for (port = (phy == DPIO_PHY0 ? PORT_B : PORT_A);
port <= (phy == DPIO_PHY0 ? PORT_C : PORT_A); port++) {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernfs: Move faulting copy_user operations outside of the mutex
On to, 2016-03-31 at 12:49 -0400, Tejun Heo wrote: > On Thu, Mar 31, 2016 at 11:45:06AM +0100, Chris Wilson wrote: > > > > A fault in a user provided buffer may lead anywhere, and lockdep warns > > that we have a potential deadlock between the mm->mmap_sem and the > > kernfs file mutex: > ... > > > > Reported-by: Ville Syrjälä > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350 > > Signed-off-by: Chris Wilson > > Reviewed-by: Joonas Lahtinen > > Cc: Ville Syrjälä > > Cc: Joonas Lahtinen > > Cc: Tejun Heo > > Cc: Greg Kroah-Hartman > > Cc: NeilBrown > > Cc: linux-ker...@vger.kernel.org > Acked-by: Tejun Heo > Thanks. I have applied this locally to our repo to be included into our CI builds. We will drop the local patch once this waterfalls from upstream to our drm-intel-nightly repo. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 32/46] pwm: deprecate pwm_config(), pwm_enable() and pwm_disable()
Hi Boris,
On Wed, Mar 30, 2016 at 10:03:55PM +0200, Boris Brezillon wrote:
> Prefix those function as deprecated to encourage all existing users to
> switch to pwm_apply_state().
Why not keep at least some of them as wrappers where we do not need to
chnage several parameters at once? It is much easier to have a driver
do:
error = pwm_enable(pwm);
if (error)
...
rather than declaring the state variable, fectch it, adjust and then
apply.
>
> Signed-off-by: Boris Brezillon
> ---
> include/linux/pwm.h | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index 4aad4eb..9bac10f 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -225,8 +225,8 @@ int pwm_apply_state(struct pwm_device *pwm, struct
> pwm_state *state);
> *
> * Returns: 0 on success or a negative error code on failure.
> */
> -static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
> - int period_ns)
> +static inline int __deprecated pwm_config(struct pwm_device *pwm, int
> duty_ns,
> + int period_ns)
> {
> struct pwm_state pstate;
>
> @@ -252,8 +252,8 @@ static inline int pwm_config(struct pwm_device *pwm, int
> duty_ns,
> *
> * Returns: 0 on success or a negative error code on failure.
> */
> -static inline int pwm_set_polarity(struct pwm_device *pwm,
> -enum pwm_polarity polarity)
> +static inline int __deprecated pwm_set_polarity(struct pwm_device *pwm,
> + enum pwm_polarity polarity)
> {
> struct pwm_state pstate;
>
> @@ -284,7 +284,7 @@ static inline int pwm_set_polarity(struct pwm_device *pwm,
> *
> * Returns: 0 on success or a negative error code on failure.
> */
> -static inline int pwm_enable(struct pwm_device *pwm)
> +static inline int __deprecated pwm_enable(struct pwm_device *pwm)
> {
> struct pwm_state pstate;
>
> @@ -303,7 +303,7 @@ static inline int pwm_enable(struct pwm_device *pwm)
> * pwm_disable() - stop a PWM output toggling
> * @pwm: PWM device
> */
> -static inline void pwm_disable(struct pwm_device *pwm)
> +static inline void __deprecated pwm_disable(struct pwm_device *pwm)
> {
> struct pwm_state pstate;
>
> @@ -360,24 +360,24 @@ static inline int pwm_apply_state(struct pwm_device
> *pwm,
> return -ENOTSUPP;
> }
>
> -static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
> - int period_ns)
> +static inline int __deprecated pwm_config(struct pwm_device *pwm, int
> duty_ns,
> + int period_ns)
> {
> return -EINVAL;
> }
>
> -static inline int pwm_set_polarity(struct pwm_device *pwm,
> -enum pwm_polarity polarity)
> +static inline int __deprecated pwm_set_polarity(struct pwm_device *pwm,
> + enum pwm_polarity polarity)
> {
> return -ENOTSUPP;
> }
>
> -static inline int pwm_enable(struct pwm_device *pwm)
> +static inline int __deprecated pwm_enable(struct pwm_device *pwm)
> {
> return -EINVAL;
> }
>
> -static inline void pwm_disable(struct pwm_device *pwm)
> +static inline void __deprecated pwm_disable(struct pwm_device *pwm)
> {
> }
>
> --
> 2.5.0
>
--
Dmitry
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 36/46] input: misc: max77693: switch to the atomic API
Hi Boris,
On Wed, Mar 30, 2016 at 10:03:59PM +0200, Boris Brezillon wrote:
> pwm_config/enable/disable() have been deprecated and should be replaced
> by pwm_apply_state().
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/input/misc/max77693-haptic.c | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/input/misc/max77693-haptic.c
> b/drivers/input/misc/max77693-haptic.c
> index cf6aac0..aef7dc4 100644
> --- a/drivers/input/misc/max77693-haptic.c
> +++ b/drivers/input/misc/max77693-haptic.c
> @@ -70,13 +70,16 @@ struct max77693_haptic {
>
> static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
> {
> + struct pwm_state pstate;
> struct pwm_args pargs = { };
> - int delta;
> int error;
>
> pwm_get_args(haptic->pwm_dev, &pargs);
> - delta = (pargs.period + haptic->pwm_duty) / 2;
> - error = pwm_config(haptic->pwm_dev, delta, pargs.period);
> + pwm_get_state(haptic->pwm_dev, &pstate);
> +
> + pstate.period = pargs.period;
> + pstate.duty_cycle = (pargs.period + haptic->pwm_duty) / 2;
> + error = pwm_apply_state(haptic->pwm_dev, &pstate);
This does not make sense with regard to the atomic API. If you look in
max77693_haptic_play_work(), right after calling
max77693_haptic_set_duty_cycle() we either try to enable or disable the
pwm. When switching to this new API we should combine both actions.
> if (error) {
> dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
> return error;
> @@ -161,12 +164,16 @@ static int max77693_haptic_lowsys(struct
> max77693_haptic *haptic, bool enable)
>
> static void max77693_haptic_enable(struct max77693_haptic *haptic)
> {
> + struct pwm_state pstate;
> int error;
>
> if (haptic->enabled)
> return;
>
> - error = pwm_enable(haptic->pwm_dev);
> + pwm_get_state(haptic->pwm_dev, &pstate);
> + pstate.enabled = true;
> +
> + error = pwm_apply_state(haptic->pwm_dev, &pstate);
As I mentioned I'd rather we did not deprecate pwm_enable() and
pwm_disable() (and maybe others), as it forces us to add unnecessary
boilerplate code to the drivers.
> if (error) {
> dev_err(haptic->dev,
> "failed to enable haptic pwm device: %d\n", error);
> @@ -188,11 +195,13 @@ static void max77693_haptic_enable(struct
> max77693_haptic *haptic)
> err_enable_config:
> max77693_haptic_lowsys(haptic, false);
> err_enable_lowsys:
> - pwm_disable(haptic->pwm_dev);
> + pstate.enabled = false;
> + pwm_apply_state(haptic->pwm_dev, &pstate);
> }
>
> static void max77693_haptic_disable(struct max77693_haptic *haptic)
> {
> + struct pwm_state pstate;
> int error;
>
> if (!haptic->enabled)
> @@ -206,7 +215,9 @@ static void max77693_haptic_disable(struct
> max77693_haptic *haptic)
> if (error)
> goto err_disable_lowsys;
>
> - pwm_disable(haptic->pwm_dev);
> + pwm_get_state(haptic->pwm_dev, &pstate);
> + pstate.enabled = false;
> + pwm_apply_state(haptic->pwm_dev, &pstate);
Same here.
> haptic->enabled = false;
>
> return;
> --
> 2.5.0
>
Thanks.
--
Dmitry
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 32/46] pwm: deprecate pwm_config(), pwm_enable() and pwm_disable()
Hi Dmitry,
On Thu, 31 Mar 2016 10:38:58 -0700
Dmitry Torokhov wrote:
> Hi Boris,
>
> On Wed, Mar 30, 2016 at 10:03:55PM +0200, Boris Brezillon wrote:
> > Prefix those function as deprecated to encourage all existing users to
> > switch to pwm_apply_state().
>
> Why not keep at least some of them as wrappers where we do not need to
> chnage several parameters at once? It is much easier to have a driver
> do:
>
> error = pwm_enable(pwm);
> if (error)
> ...
>
> rather than declaring the state variable, fectch it, adjust and then
> apply.
True. Actually deprecating the non-atomic API was not my primary goal.
Thierry would you mind if we keep both APIs around?
>
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > include/linux/pwm.h | 24
> > 1 file changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> > index 4aad4eb..9bac10f 100644
> > --- a/include/linux/pwm.h
> > +++ b/include/linux/pwm.h
> > @@ -225,8 +225,8 @@ int pwm_apply_state(struct pwm_device *pwm, struct
> > pwm_state *state);
> > *
> > * Returns: 0 on success or a negative error code on failure.
> > */
> > -static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
> > -int period_ns)
> > +static inline int __deprecated pwm_config(struct pwm_device *pwm, int
> > duty_ns,
> > + int period_ns)
> > {
> > struct pwm_state pstate;
> >
> > @@ -252,8 +252,8 @@ static inline int pwm_config(struct pwm_device *pwm,
> > int duty_ns,
> > *
> > * Returns: 0 on success or a negative error code on failure.
> > */
> > -static inline int pwm_set_polarity(struct pwm_device *pwm,
> > - enum pwm_polarity polarity)
> > +static inline int __deprecated pwm_set_polarity(struct pwm_device *pwm,
> > + enum pwm_polarity polarity)
> > {
> > struct pwm_state pstate;
> >
> > @@ -284,7 +284,7 @@ static inline int pwm_set_polarity(struct pwm_device
> > *pwm,
> > *
> > * Returns: 0 on success or a negative error code on failure.
> > */
> > -static inline int pwm_enable(struct pwm_device *pwm)
> > +static inline int __deprecated pwm_enable(struct pwm_device *pwm)
> > {
> > struct pwm_state pstate;
> >
> > @@ -303,7 +303,7 @@ static inline int pwm_enable(struct pwm_device *pwm)
> > * pwm_disable() - stop a PWM output toggling
> > * @pwm: PWM device
> > */
> > -static inline void pwm_disable(struct pwm_device *pwm)
> > +static inline void __deprecated pwm_disable(struct pwm_device *pwm)
> > {
> > struct pwm_state pstate;
> >
> > @@ -360,24 +360,24 @@ static inline int pwm_apply_state(struct pwm_device
> > *pwm,
> > return -ENOTSUPP;
> > }
> >
> > -static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
> > -int period_ns)
> > +static inline int __deprecated pwm_config(struct pwm_device *pwm, int
> > duty_ns,
> > + int period_ns)
> > {
> > return -EINVAL;
> > }
> >
> > -static inline int pwm_set_polarity(struct pwm_device *pwm,
> > - enum pwm_polarity polarity)
> > +static inline int __deprecated pwm_set_polarity(struct pwm_device *pwm,
> > + enum pwm_polarity polarity)
> > {
> > return -ENOTSUPP;
> > }
> >
> > -static inline int pwm_enable(struct pwm_device *pwm)
> > +static inline int __deprecated pwm_enable(struct pwm_device *pwm)
> > {
> > return -EINVAL;
> > }
> >
> > -static inline void pwm_disable(struct pwm_device *pwm)
> > +static inline void __deprecated pwm_disable(struct pwm_device *pwm)
> > {
> > }
> >
> > --
> > 2.5.0
> >
>
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 36/46] input: misc: max77693: switch to the atomic API
On Thu, 31 Mar 2016 10:48:01 -0700
Dmitry Torokhov wrote:
> Hi Boris,
>
> On Wed, Mar 30, 2016 at 10:03:59PM +0200, Boris Brezillon wrote:
> > pwm_config/enable/disable() have been deprecated and should be replaced
> > by pwm_apply_state().
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > drivers/input/misc/max77693-haptic.c | 23 +--
> > 1 file changed, 17 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/input/misc/max77693-haptic.c
> > b/drivers/input/misc/max77693-haptic.c
> > index cf6aac0..aef7dc4 100644
> > --- a/drivers/input/misc/max77693-haptic.c
> > +++ b/drivers/input/misc/max77693-haptic.c
> > @@ -70,13 +70,16 @@ struct max77693_haptic {
> >
> > static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
> > {
> > + struct pwm_state pstate;
> > struct pwm_args pargs = { };
> > - int delta;
> > int error;
> >
> > pwm_get_args(haptic->pwm_dev, &pargs);
> > - delta = (pargs.period + haptic->pwm_duty) / 2;
> > - error = pwm_config(haptic->pwm_dev, delta, pargs.period);
> > + pwm_get_state(haptic->pwm_dev, &pstate);
> > +
> > + pstate.period = pargs.period;
> > + pstate.duty_cycle = (pargs.period + haptic->pwm_duty) / 2;
> > + error = pwm_apply_state(haptic->pwm_dev, &pstate);
>
> This does not make sense with regard to the atomic API. If you look in
> max77693_haptic_play_work(), right after calling
> max77693_haptic_set_duty_cycle() we either try to enable or disable the
> pwm. When switching to this new API we should combine both actions.
True. I'll address that, unless Thierry is fine keeping the non-atomic
API, in which case I'll just drop patches 32 to 46.
>
> > if (error) {
> > dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
> > return error;
> > @@ -161,12 +164,16 @@ static int max77693_haptic_lowsys(struct
> > max77693_haptic *haptic, bool enable)
> >
> > static void max77693_haptic_enable(struct max77693_haptic *haptic)
> > {
> > + struct pwm_state pstate;
> > int error;
> >
> > if (haptic->enabled)
> > return;
> >
> > - error = pwm_enable(haptic->pwm_dev);
> > + pwm_get_state(haptic->pwm_dev, &pstate);
> > + pstate.enabled = true;
> > +
> > + error = pwm_apply_state(haptic->pwm_dev, &pstate);
>
> As I mentioned I'd rather we did not deprecate pwm_enable() and
> pwm_disable() (and maybe others), as it forces us to add unnecessary
> boilerplate code to the drivers.
>
> > if (error) {
> > dev_err(haptic->dev,
> > "failed to enable haptic pwm device: %d\n", error);
> > @@ -188,11 +195,13 @@ static void max77693_haptic_enable(struct
> > max77693_haptic *haptic)
> > err_enable_config:
> > max77693_haptic_lowsys(haptic, false);
> > err_enable_lowsys:
> > - pwm_disable(haptic->pwm_dev);
> > + pstate.enabled = false;
> > + pwm_apply_state(haptic->pwm_dev, &pstate);
> > }
> >
> > static void max77693_haptic_disable(struct max77693_haptic *haptic)
> > {
> > + struct pwm_state pstate;
> > int error;
> >
> > if (!haptic->enabled)
> > @@ -206,7 +215,9 @@ static void max77693_haptic_disable(struct
> > max77693_haptic *haptic)
> > if (error)
> > goto err_disable_lowsys;
> >
> > - pwm_disable(haptic->pwm_dev);
> > + pwm_get_state(haptic->pwm_dev, &pstate);
> > + pstate.enabled = false;
> > + pwm_apply_state(haptic->pwm_dev, &pstate);
>
> Same here.
>
> > haptic->enabled = false;
> >
> > return;
> > --
> > 2.5.0
> >
>
> Thanks.
>
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm: Add helper for DP++ adaptors
Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Add a helper which aids in he identification of DP dual mode (aka. > DP++) > adaptors. There are several types of adaptors specified: > type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI > > Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 > adaptors > may go as high as 300MHz and they provide a register informing the > source device what the actual limit is. Supposedly also type 1 > adaptors > may optionally implement this register. This TMDS clock limit is the > main reason why we need to identify these adaptors. > > Type 1 adaptors provide access to their internal registers and the > sink > DDC bus through I2C. Type 2 adaptors provide this access both via I2C > and I2C-over-AUX. A type 2 source device may choose to implement > either > or both of these methods. If a source device implements only the > I2C-over-AUX method, then the driver will obviously need specific > support for such adaptors since the port is driven like an HDMI port, > but DDC communication happes over the AUX channel. > > This helper should be enough to identify the adaptor type (some > type 1 DVI adaptors may be a slight exception) and the maximum TMDS > clock limit. Another feature that may be available is control over > the TMDS output buffers on the adaptor, possibly allowing for some > power saving when the TMDS link is down. > > Other user controllable features that may be available in the > adaptors > are downstream i2c bus speed control when using i2c-over-aux, and > some control over the CEC pin. I chose not to provide any helper > functions for those since I have no use for them in i915 at this > time. > The rest of the registers in the adaptor are mostly just information, > eg. IEEE OUI, hardware and firmware revision, etc. Please run a spell checker and do some proof-reading both in the commit message and in the code comments. Multiple instances of "sizo", "Hoever", "adator", "Identyfy", etc. I also spotted some typos in the next commits. > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/drm_dp_dual_mode_helper.c | 328 > ++ > include/drm/drm_dp_dual_mode_helper.h | 80 > 3 files changed, 409 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c > create mode 100644 include/drm/drm_dp_dual_mode_helper.h > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 6eb94fc561dc..8ef50f36 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o > > drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o > drm_probe_helper.o \ > drm_plane_helper.o drm_dp_mst_topology.o > drm_atomic_helper.o \ > - drm_kms_helper_common.o > + drm_kms_helper_common.o drm_dp_dual_mode_helper.o > > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o > diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c > b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > new file mode 100644 > index ..bfe511c09568 > --- /dev/null > +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > @@ -0,0 +1,328 @@ > +/* > + * Copyright © 2016 Intel Corporation > + * > + * Permission is hereby granted, free of charge, to any person > obtaining a > + * copy of this software and associated documentation files (the > "Software"), > + * to deal in the Software without restriction, including without > limitation > + * the rights to use, copy, modify, merge, publish, distribute, > sublicense, > + * and/or sell copies of the Software, and to permit persons to whom > the > + * Software is furnished to do so, subject to the following > conditions: > + * > + * The above copyright notice and this permission notice shall be > included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO > EVENT SHALL > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, > DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR > OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE > USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/** > + * DOC: DP dual mode (aka. DP++) adaptor helpers > + * > + * Helper functions to deal with DP dual mode adaptors. > + * > + * Type 1: > + * Adaptor registers (if any) and the sink DDC bus may be accessed > via I2C. > + * > + * Type 2: > + * Adaptor registers and sink DDC bus can be acces
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed
Em Qui, 2016-02-25 às 14:51 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> To save a bit of power, let's try to turn off the TMDS output buffers
> in DP++ adaptors when we're not driving the port.
>
> v2: Let's not forget DDI, toss in a debug message while at it
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 12
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 31
> +--
> 3 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 21a9b83f3bfc..458c41788b80 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2301,6 +2301,12 @@ static void intel_ddi_pre_enable(struct
> intel_encoder *intel_encoder)
> enum port port = intel_ddi_get_encoder_port(intel_encoder);
> int type = intel_encoder->type;
>
> + if (type == INTEL_OUTPUT_HDMI) {
> + struct intel_hdmi *intel_hdmi =
> enc_to_intel_hdmi(encoder);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi,
> true);
> + }
> +
> intel_prepare_ddi_buffer(intel_encoder);
>
> if (type == INTEL_OUTPUT_EDP) {
> @@ -2367,6 +2373,12 @@ static void intel_ddi_post_disable(struct
> intel_encoder *intel_encoder)
> DPLL_CTRL2_DDI_CLK_OFF(port)
> ));
> else if (INTEL_INFO(dev)->gen < 9)
> I915_WRITE(PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
> +
> + if (type == INTEL_OUTPUT_HDMI) {
> + struct intel_hdmi *intel_hdmi =
> enc_to_intel_hdmi(encoder);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi,
> false);
> + }
> }
>
> static void intel_enable_ddi(struct intel_encoder *intel_encoder)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 944eacbfb6a9..2e4fa4337c59 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -706,6 +706,7 @@ struct intel_hdmi {
> int ddc_bus;
> struct {
> int max_tmds_clock;
> + bool tmds_output_control;
> } dp_dual_mode;
> bool limited_color_range;
> bool color_range_auto;
> @@ -1355,6 +1356,7 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
> bool intel_hdmi_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state
> *pipe_config);
> +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
> bool enable);
>
>
> /* intel_lvds.c */
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1e8cfdb18dc7..4b528a669f8e 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -837,6 +837,20 @@ static void hsw_set_infoframes(struct
> drm_encoder *encoder,
> intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
> }
>
> +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
> bool enable)
> +{
> + if (hdmi->dp_dual_mode.tmds_output_control) {
Or you could just do an early return here and save an indentation level
:)
> + struct drm_i915_private *dev_priv =
> to_i915(intel_hdmi_to_dev(hdmi));
> + struct i2c_adapter *adapter =
> + intel_gmbus_get_adapter(dev_priv, hdmi-
> >ddc_bus);
> +
> + DRM_DEBUG_KMS("%s DP dual mode adaptor TMDS
> output\n",
> + enable ? "Enabling" : "Disabling");
> +
> + drm_dp_dual_mode_set_tmds_output(adapter, enable);
> + }
> +}
> +
> static void intel_hdmi_prepare(struct intel_encoder *encoder)
> {
> struct drm_device *dev = encoder->base.dev;
> @@ -846,6 +860,8 @@ static void intel_hdmi_prepare(struct
> intel_encoder *encoder)
> const struct drm_display_mode *adjusted_mode = &crtc-
> >config->base.adjusted_mode;
> u32 hdmi_val;
>
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
> +
> hdmi_val = SDVO_ENCODING_HDMI;
> if (!HAS_PCH_SPLIT(dev) && crtc->config-
> >limited_color_range)
> hdmi_val |= HDMI_COLOR_RANGE_16_235;
> @@ -1144,6 +1160,8 @@ static void intel_disable_hdmi(struct
> intel_encoder *encoder)
> }
>
> intel_hdmi->set_infoframes(&encoder->base, false, NULL);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
> }
>
> static void g4x_disable_hdmi(struct intel_encoder *encoder)
> @@ -1369,6 +1387,7 @@ intel_hdmi_unset_edid(struct drm_connector
> *connector)
> intel_hdmi->rgb_quant_range_selectable = false;
>
> intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
> + intel_hdmi->dp_dual_mode.tmds_output_control = false;
>
> kfree(to_intel_connector(connector)->detect_edid);
> to_intel_connector(connector)->detect_edi
Re: [Intel-gfx] [PATCH] kernfs: Move faulting copy_user operations outside of the mutex
On Thu, Mar 31, 2016 at 08:30:05PM +0300, Joonas Lahtinen wrote: > On to, 2016-03-31 at 12:49 -0400, Tejun Heo wrote: > > On Thu, Mar 31, 2016 at 11:45:06AM +0100, Chris Wilson wrote: > > > > > > A fault in a user provided buffer may lead anywhere, and lockdep warns > > > that we have a potential deadlock between the mm->mmap_sem and the > > > kernfs file mutex: > > ... > > > > > > Reported-by: Ville Syrjälä > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350 > > > Signed-off-by: Chris Wilson > > > Reviewed-by: Joonas Lahtinen > > > Cc: Ville Syrjälä > > > Cc: Joonas Lahtinen > > > Cc: Tejun Heo > > > Cc: Greg Kroah-Hartman > > > Cc: NeilBrown > > > Cc: linux-ker...@vger.kernel.org > > Acked-by: Tejun Heo > > > > Thanks. > > I have applied this locally to our repo to be included into our CI > builds. > > We will drop the local patch once this waterfalls from upstream to our > drm-intel-nightly repo. So is this something that needs to get into 4.6-final because it resolves a reported issue? Or can it wait for 4.7-rc1? thanks, greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] system hang on ILK/SNB/IVB
Hi Tomi, On Thu, Mar 31, 2016 at 10:21:16AM +0300, Tomi Sarvela wrote: > The problem with the results in your link is that there is no HSW, ILK, IVB > or SNB results. This might give the impression that everything is well. > > Most damning is lack of HSW-gt2 and SNB-dellxps: those machines hang on to > APC, and have run quite stably for every Patchwork run. The case isn't strong > enough yet that series should fail if either of those won't run, but it might > be so in future. So my patch seeking to fix the hangs has passed Romania CI with "success": https://patchwork.freedesktop.org/series/5125/ However I don't see HSW-gt2 and SNB-dellxps in their hardware lineup. And I would still like to know what the actual cause of the hangs is since they do not occur on my IVB laptop. If you get the chance maybe you can repeat the test and include a "dump_stack();" at the beginning of intel_fbdev_output_poll_changed() and intel_fbdev_restore_mode(). This should show in the logs which of the two functions is called during suspend/resume and from where it's called. My guess is that this particular hardware causes a hotplug signal to be generated upon waking up. If the hangs do not stop with this patch, booting with "no_console_suspend" should at least show what's going on. Thank you & best regards, Lukas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm: Add helper for DP++ adaptors
On Thu, Mar 31, 2016 at 07:25:36PM +, Zanoni, Paulo R wrote: > Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com > escreveu: > > From: Ville Syrjälä > > > > Add a helper which aids in he identification of DP dual mode (aka. > > DP++) > > adaptors. There are several types of adaptors specified: > > type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI > > > > Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 > > adaptors > > may go as high as 300MHz and they provide a register informing the > > source device what the actual limit is. Supposedly also type 1 > > adaptors > > may optionally implement this register. This TMDS clock limit is the > > main reason why we need to identify these adaptors. > > > > Type 1 adaptors provide access to their internal registers and the > > sink > > DDC bus through I2C. Type 2 adaptors provide this access both via I2C > > and I2C-over-AUX. A type 2 source device may choose to implement > > either > > or both of these methods. If a source device implements only the > > I2C-over-AUX method, then the driver will obviously need specific > > support for such adaptors since the port is driven like an HDMI port, > > but DDC communication happes over the AUX channel. > > > > This helper should be enough to identify the adaptor type (some > > type 1 DVI adaptors may be a slight exception) and the maximum TMDS > > clock limit. Another feature that may be available is control over > > the TMDS output buffers on the adaptor, possibly allowing for some > > power saving when the TMDS link is down. > > > > Other user controllable features that may be available in the > > adaptors > > are downstream i2c bus speed control when using i2c-over-aux, and > > some control over the CEC pin. I chose not to provide any helper > > functions for those since I have no use for them in i915 at this > > time. > > The rest of the registers in the adaptor are mostly just information, > > eg. IEEE OUI, hardware and firmware revision, etc. > > Please run a spell checker and do some proof-reading both in the commit > message and in the code comments. Multiple instances of "sizo", > "Hoever", "adator", "Identyfy", etc. I also spotted some typos in the > next commits. > > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/Makefile | 2 +- > > drivers/gpu/drm/drm_dp_dual_mode_helper.c | 328 > > ++ > > include/drm/drm_dp_dual_mode_helper.h | 80 > > 3 files changed, 409 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c > > create mode 100644 include/drm/drm_dp_dual_mode_helper.h > > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > > index 6eb94fc561dc..8ef50f36 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o > > > > drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o > > drm_probe_helper.o \ > > drm_plane_helper.o drm_dp_mst_topology.o > > drm_atomic_helper.o \ > > - drm_kms_helper_common.o > > + drm_kms_helper_common.o drm_dp_dual_mode_helper.o > > > > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o > > diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > new file mode 100644 > > index ..bfe511c09568 > > --- /dev/null > > +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c > > @@ -0,0 +1,328 @@ > > +/* > > + * Copyright © 2016 Intel Corporation > > + * > > + * Permission is hereby granted, free of charge, to any person > > obtaining a > > + * copy of this software and associated documentation files (the > > "Software"), > > + * to deal in the Software without restriction, including without > > limitation > > + * the rights to use, copy, modify, merge, publish, distribute, > > sublicense, > > + * and/or sell copies of the Software, and to permit persons to whom > > the > > + * Software is furnished to do so, subject to the following > > conditions: > > + * > > + * The above copyright notice and this permission notice shall be > > included in > > + * all copies or substantial portions of the Software. > > + * > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > EXPRESS OR > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > > MERCHANTABILITY, > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO > > EVENT SHALL > > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, > > DAMAGES OR > > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR > > OTHERWISE, > > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE > > USE OR > > + * OTHER DEALINGS IN THE SOFTWARE. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#includ
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed
On Thu, Mar 31, 2016 at 07:26:25PM +, Zanoni, Paulo R wrote:
> Em Qui, 2016-02-25 às 14:51 +0200, ville.syrj...@linux.intel.com
> escreveu:
> > From: Ville Syrjälä
> >
> > To save a bit of power, let's try to turn off the TMDS output buffers
> > in DP++ adaptors when we're not driving the port.
> >
> > v2: Let's not forget DDI, toss in a debug message while at it
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 12
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > drivers/gpu/drm/i915/intel_hdmi.c | 31
> > +--
> > 3 files changed, 43 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 21a9b83f3bfc..458c41788b80 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2301,6 +2301,12 @@ static void intel_ddi_pre_enable(struct
> > intel_encoder *intel_encoder)
> > enum port port = intel_ddi_get_encoder_port(intel_encoder);
> > int type = intel_encoder->type;
> >
> > + if (type == INTEL_OUTPUT_HDMI) {
> > + struct intel_hdmi *intel_hdmi =
> > enc_to_intel_hdmi(encoder);
> > +
> > + intel_dp_dual_mode_set_tmds_output(intel_hdmi,
> > true);
> > + }
> > +
> > intel_prepare_ddi_buffer(intel_encoder);
> >
> > if (type == INTEL_OUTPUT_EDP) {
> > @@ -2367,6 +2373,12 @@ static void intel_ddi_post_disable(struct
> > intel_encoder *intel_encoder)
> > DPLL_CTRL2_DDI_CLK_OFF(port)
> > ));
> > else if (INTEL_INFO(dev)->gen < 9)
> > I915_WRITE(PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
> > +
> > + if (type == INTEL_OUTPUT_HDMI) {
> > + struct intel_hdmi *intel_hdmi =
> > enc_to_intel_hdmi(encoder);
> > +
> > + intel_dp_dual_mode_set_tmds_output(intel_hdmi,
> > false);
> > + }
> > }
> >
> > static void intel_enable_ddi(struct intel_encoder *intel_encoder)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 944eacbfb6a9..2e4fa4337c59 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -706,6 +706,7 @@ struct intel_hdmi {
> > int ddc_bus;
> > struct {
> > int max_tmds_clock;
> > + bool tmds_output_control;
> > } dp_dual_mode;
> > bool limited_color_range;
> > bool color_range_auto;
> > @@ -1355,6 +1356,7 @@ void intel_hdmi_init_connector(struct
> > intel_digital_port *intel_dig_port,
> > struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
> > bool intel_hdmi_compute_config(struct intel_encoder *encoder,
> > struct intel_crtc_state
> > *pipe_config);
> > +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
> > bool enable);
> >
> >
> > /* intel_lvds.c */
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 1e8cfdb18dc7..4b528a669f8e 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -837,6 +837,20 @@ static void hsw_set_infoframes(struct
> > drm_encoder *encoder,
> > intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
> > }
> >
> > +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
> > bool enable)
> > +{
> > + if (hdmi->dp_dual_mode.tmds_output_control) {
>
> Or you could just do an early return here and save an indentation level
> :)
Indeed. I had the code inlined originally so the extra indentation
made sense, and the I just copypasted it to this separate function,
and in my haste forgot to flatten it.
>
> > + struct drm_i915_private *dev_priv =
> > to_i915(intel_hdmi_to_dev(hdmi));
> > + struct i2c_adapter *adapter =
> > + intel_gmbus_get_adapter(dev_priv, hdmi-
> > >ddc_bus);
> > +
> > + DRM_DEBUG_KMS("%s DP dual mode adaptor TMDS
> > output\n",
> > + enable ? "Enabling" : "Disabling");
> > +
> > + drm_dp_dual_mode_set_tmds_output(adapter, enable);
> > + }
> > +}
> > +
> > static void intel_hdmi_prepare(struct intel_encoder *encoder)
> > {
> > struct drm_device *dev = encoder->base.dev;
> > @@ -846,6 +860,8 @@ static void intel_hdmi_prepare(struct
> > intel_encoder *encoder)
> > const struct drm_display_mode *adjusted_mode = &crtc-
> > >config->base.adjusted_mode;
> > u32 hdmi_val;
> >
> > + intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
> > +
> > hdmi_val = SDVO_ENCODING_HDMI;
> > if (!HAS_PCH_SPLIT(dev) && crtc->config-
> > >limited_color_range)
> > hdmi_val |= HDMI_COLOR_RANGE_16_235;
> > @@ -1144,6 +1160,8 @@ static void intel_disable_hdmi(struct
> > intel_encoder *encoder)
> > }
> >
> > intel_hdmi->set_infoframes(&encoder->base, false, NULL);
> > +
> > + intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
> > }
> >
> >
[Intel-gfx] [PATCH] drm/i915/hdmi: Fix weak connector detection
Currently, our implementation of drm_connector_funcs.detect is based on getting a valid EDID. This requirement makes the driver fail to detect connected connectors in case of EDID corruption, which prevents from falling back to modes provided by builtin or user-provided EDIDs. Let's fix this by improving the detection, with a DDC probe, if the current EDID-based detection failed. Note that a better way of dealing with this could calling drm_probe_ddc in drm_connector_funcs.detect, and do the EDID full reading and parsing in drm_connector_helper_funcs.get_modes, when it's actually needed. However, this would be more invasive and thus more error-prone. The current commit is an attempt to get some uninvasive fix, and allow for easier backporting. Signed-off-by: Ezequiel Garcia --- drivers/gpu/drm/i915/intel_hdmi.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index a0d8daed2470..c079206e6681 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1428,6 +1428,20 @@ intel_hdmi_detect(struct drm_connector *connector, bool force) } else status = connector_status_disconnected; + /* +* The above call to intel_hdmi_set_edid() checked for a valid EDID. +* However, the EDID can get corrupted for several reasons, resulting +* in a disconnected status despite the connector being connected. +* Hence, let's try one more time, by only probing the DDC. +* +* This allows the DRM core to fallback to builtin or user-provided +* EDID firmware, e.g. in drm_helper_probe_single_connector_modes. +*/ + if (status == connector_status_disconnected) + if (drm_probe_ddc(intel_gmbus_get_adapter(dev_priv, + intel_hdmi->ddc_bus))) + status = connector_status_connected; + intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS); return status; -- 2.7.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT
Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> DP dual mode type 1 DVI adaptors aren't required to implement any
> registers, so it's a bit hard to detect them. The best way would
> be to check the state of the CONFIG1 pin, but we have no way to
> do that. So as a last resort, check the VBT to see if the HDMI
> port is in fact a dual mode capable DP port.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_bios.h | 3 +++
> drivers/gpu/drm/i915/intel_dp.c | 28
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_hdmi.c | 23 +--
> 4 files changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index 350d4e0f75a4..50d1659efe47 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -730,6 +730,7 @@ struct bdb_psr {
> #define DEVICE_TYPE_INT_TV 0x1009
> #define DEVICE_TYPE_HDMI 0x60D2
> #define DEVICE_TYPE_DP 0x68C6
> +#define DEVICE_TYPE_DP_DUAL_MODE 0x60D6
> #define DEVICE_TYPE_eDP0x78C6
>
> #define DEVICE_TYPE_CLASS_EXTENSION (1 << 15)
> @@ -764,6 +765,8 @@ struct bdb_psr {
> DEVICE_TYPE_DISPLAYPORT_OUTPUT | \
> DEVICE_TYPE_ANALOG_OUTPUT)
>
> +#define DEVICE_TYPE_DP_DUAL_MODE_BITS ~DEVICE_TYPE_NOT_HDMI_OUTPUT
> +
> /* define the DVO port for HDMI output type */
> #define DVO_B 1
> #define DVO_C 2
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index cbc06596659a..f3edacf517ac 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5104,6 +5104,34 @@ bool intel_dp_is_edp(struct drm_device *dev,
> enum port port)
> return false;
> }
>
> +bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv, enum
> port port)
> +{
> + const union child_device_config *p_child;
> + int i;
> + static const short port_mapping[] = {
> + [PORT_B] = DVO_PORT_DPB,
> + [PORT_C] = DVO_PORT_DPC,
> + [PORT_D] = DVO_PORT_DPD,
> + [PORT_E] = DVO_PORT_DPE,
> + };
> +
> + if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> + return false;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return false;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + p_child = &dev_priv->vbt.child_dev[i];
> +
> + if (p_child->common.dvo_port == port_mapping[port]
> &&
> + (p_child->common.device_type &
> DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
> + (DEVICE_TYPE_DP_DUAL_MODE &
> DEVICE_TYPE_DP_DUAL_MODE_BITS))
> + return true;
> + }
Some thoughts:
This is going to be implemented for all VBT versions. Since there's no
real history about anything before version 155, is this really what we
want? A huge part of the "we don't trust the VBT" culture we have on
our team is because of those old versions being completely unreliable.
If this is the case, we could make this implementation just be a small
patch in parse_ddi_port(). I'm kinda afraid we may somehow break old
machines yet again.
- Instead of creating these complicated bit masks, why don't we just
specifically check "if bit 2 and bit 4 are enabled, we're using an
adaptor"? Much simpler IMHO.
- Jani's recent patch suggests you may want to move this function to
intel_bios.c in order to avoid including intel_vbt_defs.h from
intel_hdmi.c. Anyway, you'll have to rebase.
> + return false;
> +}
> +
> void
> intel_dp_add_properties(struct intel_dp *intel_dp, struct
> drm_connector *connector)
> {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3ca29a181e64..c7d1ea4dbe42 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1248,6 +1248,7 @@ int intel_dp_sink_crc(struct intel_dp
> *intel_dp, u8 *crc);
> bool intel_dp_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config);
> bool intel_dp_is_edp(struct drm_device *dev, enum port port);
> +bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv, enum
> port port);
> enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port,
> bool long_hpd);
> void intel_edp_backlight_on(struct intel_dp *intel_dp);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 660a65f48fd8..1476f3afb7e2 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1390,14 +1390,33 @@ intel_hdmi_unset_edid(struct drm_connector
> *connector)
> }
>
> static void
> -intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
> +intel_
[Intel-gfx] [PATCH 00/16] Pre-calculate SKL-style atomic watermarks
This series moves DDB allocation and watermark calculation for SKL-style
platforms to the atomic 'check' phase. This is important for two reasons,
described in more detail below.
1.) It allows us to reject atomic updates that would exceed the watermark
capabilities of the platform.
2.) Avoid exponentially redundant computation of watermark values (and
eliminate the WARN_ON(!wm_changed) errors).
1. Reject invalid configurations
If enough pipes and planes are turned on at the same time, it's possible that
we won't be able to find any valid watermark values that satisfy the display
configuration. Today we blindly assume that watermark programming will always
succeed (and potentially program the hardware incorrectly). We should take
advantage of the atomic modesetting design to recognize when a requested
display configuration exceeds our capabilities and reject the display update
before we get to the point of trying to program the hardware.
2. Avoid redundant computation
For historical reasons, our i915 legacy watermark entrypoints operate in a
per-crtc manner. They're called with a specific CRTC as a parameter that
indicates which CRTC is changing, but they actually wind up calculating and
programming state that can be global in nature on some platforms. On SKL-style
platforms specifically, calling update_wm on a single CRTC may actually
re-calculate the DDB allocation and watermarks for _all_ CRTC's. This worked
okay for legacy modesetting where an operation usually only updated a single
CRTC at a time and thus had only a single call into the update_watermarks
entrypoint. However now that our driver is atomic in nature, a single atomic
transaction may trigger changes to multiple CRTC's; our watermark entrypoints
get called for each CRTC of the transaction. On SKL, this means that a
transaction touching M crtc's on a platform with N crtc's will potentially call
the update_wm() entrypoint MxN times. I.e., we're redundantly computing and
programming watermark data more times than we need to. Effectively the
situation today is:
for each CRTC in atomic transaction {
for each affected CRTC {
calculate pipe-specific WM data;
}
combine per-pipe WM data into global WM data;
write global WM data;
}
(due to the nature of DDB programming on SKL-style platforms, the inner loop
may need to recompute for every CRTC on the platform, even if they aren't being
explicitly modified by the update).
Clearly this has a lot of unwanted redundancy (and is the source of the
WARN_ON(!wm_changed) warning that has been haunting the driver for a while
now). This series allows us to just calculate the necessary watermark data once
for the transaction.
A few notes on the series:
* This series deals with how watermark programming fits into the atomic design
of our driver, but doesn't focus on the lower-level computation of watermark
values (i.e., whether or not we're following the bspec's algorithms
properly). I've posted another series at
https://patchwork.freedesktop.org/series/4197/ (largely originating from
Mahesh and Shobhit) that implements new hardware workarounds from the bspec
or fixes bugs in areas where our logic didn't match the latest spec. That
series is mostly orthogonal to this series, but is arguably more important
since it fixes the low-level correctness of the driver whereas this series
is focused on higher-level design.
* This series untangles the computation half of watermarks a bit so that we're
not redundantly programming, but the final update of the hardware that
happens during atomic commit is still being performed more times than it
needs to be. I'll need to address that in a future patch series.
Kumar, Mahesh (1):
drm/i915/skl+: Use plane size for relative data rate calculation
Matt Roper (15):
drm/i915: Reorganize WM structs/unions in CRTC state
drm/i915: Make skl_plane_relative_data_rate use passed CRTC state
drm/i915: Rename s/skl_compute_pipe_wm/skl_build_pipe_wm/
drm/i915/gen9: Allow calculation of data rate for in-flight state
drm/i915: Ensure intel_state->active_crtcs is always set
drm/i915/gen9: Allow skl_allocate_pipe_ddb() to operate on in-flight
state
drm/i915/gen9: Compute DDB allocation at atomic check time
drm/i915/gen9: Drop re-allocation of DDB at atomic commit
drm/i915/gen9: Calculate plane WM's from state
drm/i915/gen9: Allow watermark calculation on in-flight atomic state
drm/i915/gen9: Use a bitmask to track dirty pipe watermarks
drm/i915/gen9: Propagate watermark calculation failures up the call
chain
drm/i915/gen9: Calculate watermarks during atomic 'check'
drm/i915/gen9: Reject display updates that exceed wm limitations
drm/i915: Remove wm_config from dev_priv/intel_atomic_state
drivers/gpu/drm/i915/i915_drv.h | 16 +-
drivers/gpu/drm/i915/intel_display.c | 44 +
[Intel-gfx] [PATCH 01/16] drm/i915: Reorganize WM structs/unions in CRTC state
Reorganize the nested structures and unions we have for pipe watermark
data in intel_crtc_state so that platform-specific data can be added in
a more sensible manner (and save a bit of memory at the same time).
The change basically changes the organization from:
union {
struct intel_pipe_wm ilk;
struct intel_pipe_wm skl;
} optimal;
struct intel_pipe_wm intermediate /* ILK-only */
to
union {
struct {
struct intel_pipe_wm intermediate;
struct intel_pipe_wm optimal;
} ilk;
struct {
struct intel_pipe_wm optimal;
} skl;
}
There should be no functional change here, but it will allow us to add
more platform-specific fields going forward (and more easily extend to
other platform types like VLV).
While we're at it, let's move the entire watermark substructure out to
its own structure definition to make the code slightly more readable.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_drv.h | 61 +++-
drivers/gpu/drm/i915/intel_pm.c | 18 ++--
2 files changed, 44 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6ac46d9..3b9c084 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -404,6 +404,40 @@ struct skl_pipe_wm {
uint32_t linetime;
};
+struct intel_crtc_wm_state {
+ union {
+ struct {
+ /*
+* Intermediate watermarks; these can be
+* programmed immediately since they satisfy
+* both the current configuration we're
+* switching away from and the new
+* configuration we're switching to.
+*/
+ struct intel_pipe_wm intermediate;
+
+ /*
+* Optimal watermarks, programmed post-vblank
+* when this state is committed.
+*/
+ struct intel_pipe_wm optimal;
+ } ilk;
+
+ struct {
+ /* gen9+ only needs 1-step wm programming */
+ struct skl_pipe_wm optimal;
+ } skl;
+ };
+
+ /*
+* Platforms with two-step watermark programming will need to
+* update watermark programming post-vblank to switch from the
+* safe intermediate watermarks to the optimal final
+* watermarks.
+*/
+ bool need_postvbl_update;
+};
+
struct intel_crtc_state {
struct drm_crtc_state base;
@@ -552,32 +586,7 @@ struct intel_crtc_state {
/* IVB sprite scaling w/a (WaCxSRDisabledForSpriteScaling:ivb) */
bool disable_lp_wm;
- struct {
- /*
-* Optimal watermarks, programmed post-vblank when this state
-* is committed.
-*/
- union {
- struct intel_pipe_wm ilk;
- struct skl_pipe_wm skl;
- } optimal;
-
- /*
-* Intermediate watermarks; these can be programmed immediately
-* since they satisfy both the current configuration we're
-* switching away from and the new configuration we're switching
-* to.
-*/
- struct intel_pipe_wm intermediate;
-
- /*
-* Platforms with two-step watermark programming will need to
-* update watermark programming post-vblank to switch from the
-* safe intermediate watermarks to the optimal final
-* watermarks.
-*/
- bool need_postvbl_update;
- } wm;
+ struct intel_crtc_wm_state wm;
/* Gamma mode programmed on the pipe */
uint32_t gamma_mode;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9bc9c25..a04e499 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2309,7 +2309,7 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state
*cstate)
int level, max_level = ilk_wm_max_level(dev), usable_level;
struct ilk_wm_maximums max;
- pipe_wm = &cstate->wm.optimal.ilk;
+ pipe_wm = &cstate->wm.ilk.optimal;
for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
struct intel_plane_state *ps;
@@ -2391,7 +2391,7 @@ static int ilk_compute_intermediate_wm(struct drm_device
*dev,
struct intel_crtc *intel_crtc,
struct intel_crtc_state *newstate)
{
- struct intel_pipe_wm *a = &newstate->wm.intermediat
[Intel-gfx] [PATCH 03/16] drm/i915: Rename s/skl_compute_pipe_wm/skl_build_pipe_wm/
When we added atomic watermarks, we added a new display vfunc
'compute_pipe_wm' that is used to compute any pipe-specific watermark
information that we can at atomic check time. This was a somewhat poor
naming choice since we already had a 'skl_compute_pipe_wm' function that
doesn't quite fit this model --- the existing SKL function is something
that gets used at atomic commit time, after the DDB allocation has been
determined. Let's rename the existing SKL function to avoid confusion.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8271b6c..c970c4e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3312,9 +3312,9 @@ static void skl_compute_transition_wm(struct
intel_crtc_state *cstate,
}
}
-static void skl_compute_pipe_wm(struct intel_crtc_state *cstate,
- struct skl_ddb_allocation *ddb,
- struct skl_pipe_wm *pipe_wm)
+static void skl_build_pipe_wm(struct intel_crtc_state *cstate,
+ struct skl_ddb_allocation *ddb,
+ struct skl_pipe_wm *pipe_wm)
{
struct drm_device *dev = cstate->base.crtc->dev;
const struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3581,7 +3581,7 @@ static bool skl_update_pipe_wm(struct drm_crtc *crtc,
struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
skl_allocate_pipe_ddb(cstate, ddb);
- skl_compute_pipe_wm(cstate, ddb, pipe_wm);
+ skl_build_pipe_wm(cstate, ddb, pipe_wm);
if (!memcmp(&intel_crtc->wm.active.skl, pipe_wm, sizeof(*pipe_wm)))
return false;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/16] drm/i915/gen9: Use a bitmask to track dirty pipe watermarks
Slightly easier to work with than an array of bools.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 35cebd4..34b843d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1575,7 +1575,7 @@ struct skl_ddb_allocation {
};
struct skl_wm_values {
- bool dirty[I915_MAX_PIPES];
+ unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
uint32_t wm_linetime[I915_MAX_PIPES];
uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0a7f4d7..be7fbff 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3454,7 +3454,7 @@ static void skl_write_wm_values(struct drm_i915_private
*dev_priv,
int i, level, max_level = ilk_wm_max_level(dev);
enum pipe pipe = crtc->pipe;
- if (!new->dirty[pipe])
+ if ((new->dirty_pipes & drm_crtc_mask(&crtc->base)) == 0)
continue;
I915_WRITE(PIPE_WM_LINETIME(pipe), new->wm_linetime[pipe]);
@@ -3679,7 +3679,7 @@ static void skl_update_other_pipe_wm(struct drm_device
*dev,
WARN_ON(!wm_changed);
skl_compute_wm_results(dev, &pipe_wm, r, intel_crtc);
- r->dirty[intel_crtc->pipe] = true;
+ r->dirty_pipes |= drm_crtc_mask(&intel_crtc->base);
}
}
@@ -3756,7 +3756,7 @@ static void skl_update_wm(struct drm_crtc *crtc)
/* Clear all dirty flags */
- memset(results->dirty, 0, sizeof(bool) * I915_MAX_PIPES);
+ results->dirty_pipes = 0;
skl_clear_wm(results, intel_crtc->pipe);
@@ -3764,7 +3764,7 @@ static void skl_update_wm(struct drm_crtc *crtc)
return;
skl_compute_wm_results(dev, pipe_wm, results, intel_crtc);
- results->dirty[intel_crtc->pipe] = true;
+ results->dirty_pipes |= drm_crtc_mask(&intel_crtc->base);
skl_update_other_pipe_wm(dev, crtc, results);
skl_write_wm_values(dev_priv, results);
@@ -3923,7 +3923,7 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc
*crtc)
if (!intel_crtc->active)
return;
- hw->dirty[pipe] = true;
+ hw->dirty_pipes |= drm_crtc_mask(crtc);
active->linetime = hw->wm_linetime[pipe];
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/16] drm/i915/gen9: Allow skl_allocate_pipe_ddb() to operate on in-flight state
We eventually want to calculate watermark values at atomic 'check' time
instead of atomic 'commit' time so that any requested configurations
that result in impossible watermark requirements are properly rejected.
The first step along this path is to allocate the DDB at atomic 'check'
time. As we perform this transition, allow the main allocation function
to operate successfully on either an in-flight state or an
already-commited state. Once we complete the transition in a future
patch, we'll come back and remove the unnecessary logic for the
already-committed case.
Note one other minor change here...when working with the
already-committed state, we pull the active CRTC's from
hweight(dev_priv->active_crtcs) instead of
dev_priv->wm.config.num_pipes_active. The values should be equivalent,
but dev_priv->wm.config is pretty much unused at this point and it would
be nice to eventually remove it entirely.
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++
drivers/gpu/drm/i915/intel_pm.c | 99 ++---
2 files changed, 78 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d3ebb2f..79f1974 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -318,6 +318,12 @@ struct i915_hotplug {
&dev->mode_config.plane_list, \
base.head)
+#define for_each_intel_plane_mask(dev, intel_plane, plane_mask)
\
+ list_for_each_entry(intel_plane, &dev->mode_config.plane_list, \
+ base.head) \
+ for_each_if ((plane_mask) & \
+(1 << drm_plane_index(&intel_plane->base)))
+
#define for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) \
list_for_each_entry(intel_plane,\
&(dev)->mode_config.plane_list, \
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e92513e..e0ca2b9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2849,15 +2849,15 @@ skl_wm_plane_id(const struct intel_plane *plane)
static void
skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
const struct intel_crtc_state *cstate,
- const struct intel_wm_config *config,
+ const unsigned active_crtcs,
struct skl_ddb_entry *alloc /* out */)
{
- struct drm_crtc *for_crtc = cstate->base.crtc;
- struct drm_crtc *crtc;
+ struct drm_crtc *crtc = cstate->base.crtc;
unsigned int pipe_size, ddb_size;
+ unsigned int num_active = hweight32(active_crtcs);
int nth_active_pipe;
- if (!cstate->base.active) {
+ if (!cstate->base.active || WARN_ON(num_active == 0)) {
alloc->start = 0;
alloc->end = 0;
return;
@@ -2870,25 +2870,16 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
*dev,
ddb_size -= 4; /* 4 blocks for bypass path allocation */
- nth_active_pipe = 0;
- for_each_crtc(dev, crtc) {
- if (!to_intel_crtc(crtc)->active)
- continue;
+ nth_active_pipe = hweight32(active_crtcs & (drm_crtc_mask(crtc) - 1));
- if (crtc == for_crtc)
- break;
-
- nth_active_pipe++;
- }
-
- pipe_size = ddb_size / config->num_pipes_active;
- alloc->start = nth_active_pipe * ddb_size / config->num_pipes_active;
+ pipe_size = ddb_size / num_active;
+ alloc->start = nth_active_pipe * ddb_size / num_active;
alloc->end = alloc->start + pipe_size;
}
-static unsigned int skl_cursor_allocation(const struct intel_wm_config *config)
+static unsigned int skl_cursor_allocation(const unsigned active_crtcs)
{
- if (config->num_pipes_active == 1)
+ if (hweight32(active_crtcs) == 1)
return 32;
return 8;
@@ -3018,14 +3009,13 @@ skl_get_total_relative_data_rate(const struct
intel_crtc_state *cstate)
return total_data_rate;
}
-static void
+static int
skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
struct skl_ddb_allocation *ddb /* out */)
{
struct drm_crtc *crtc = cstate->base.crtc;
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_wm_config *config = &dev_priv->wm.config;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_plane *intel_plane;
enum pipe pipe = intel_crtc->pipe;
@@ -3034,17 +3024,43 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
uint16_t minimum[I915_MAX_PLANES];
uint16_t y_minimum[I915_MAX_PLAN
[Intel-gfx] [PATCH 02/16] drm/i915: Make skl_plane_relative_data_rate use passed CRTC state
At the moment the CRTC state passed to skl_plane_relative_data_rate() is always the committed state so intel_crtc->config and cstate are equivalent. However going forward, we'd like to be able to call this function on in-flight state objects, so make sure we use the parameter. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_pm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index a04e499..8271b6c 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2953,8 +2953,7 @@ skl_plane_relative_data_rate(const struct intel_crtc_state *cstate, } /* for packed formats */ - return intel_crtc->config->pipe_src_w * - intel_crtc->config->pipe_src_h * + return cstate->pipe_src_w * cstate->pipe_src_h * drm_format_plane_cpp(fb->pixel_format, 0); } -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/16] drm/i915/gen9: Allow watermark calculation on in-flight atomic state
In an upcoming patch we'll move this calculation to the atomic 'check'
phase so that the display update can be rejected early if no valid
watermark programming is possible.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_drv.h | 21 +
drivers/gpu/drm/i915/intel_pm.c | 31 +++
2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 483261c..6471f69 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1667,6 +1667,27 @@ intel_atomic_get_existing_plane_state(struct
drm_atomic_state *state,
return to_intel_plane_state(plane_state);
}
+/*
+ * If cstate is in-flight, return in-flight plane state, otherwise
+ * return committed plane state.
+ */
+static inline struct intel_plane_state *
+intel_pstate_for_cstate_plane(struct intel_crtc_state *cstate,
+ struct intel_plane *plane)
+{
+ struct drm_atomic_state *state = cstate->base.state;
+ struct drm_plane_state *pstate;
+
+ if (state == NULL)
+ return to_intel_plane_state(plane->base.state);
+
+ pstate = drm_atomic_get_plane_state(state, &plane->base);
+
+ return to_intel_plane_state(pstate);
+}
+
+
+
int intel_atomic_setup_scalers(struct drm_device *dev,
struct intel_crtc *intel_crtc,
struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6aafbb1..0a7f4d7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3293,11 +3293,12 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
return true;
}
-static void skl_compute_wm_level(const struct drm_i915_private *dev_priv,
-struct skl_ddb_allocation *ddb,
-struct intel_crtc_state *cstate,
-int level,
-struct skl_wm_level *result)
+static int
+skl_compute_wm_level(const struct drm_i915_private *dev_priv,
+struct skl_ddb_allocation *ddb,
+struct intel_crtc_state *cstate,
+int level,
+struct skl_wm_level *result)
{
struct drm_device *dev = dev_priv->dev;
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
@@ -3309,7 +3310,11 @@ static void skl_compute_wm_level(const struct
drm_i915_private *dev_priv,
for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
int i = skl_wm_plane_id(intel_plane);
- intel_pstate = to_intel_plane_state(intel_plane->base.state);
+ intel_pstate = intel_pstate_for_cstate_plane(cstate,
+intel_plane);
+ if (IS_ERR(intel_pstate))
+ return PTR_ERR(intel_pstate);
+
ddb_blocks = skl_ddb_entry_size(&ddb->plane[pipe][i]);
result->plane_en[i] = skl_compute_plane_wm(dev_priv,
@@ -3320,6 +3325,8 @@ static void skl_compute_wm_level(const struct
drm_i915_private *dev_priv,
&result->plane_res_b[i],
&result->plane_res_l[i]);
}
+
+ return 0;
}
static uint32_t
@@ -3614,14 +3621,14 @@ static void skl_flush_wm_values(struct drm_i915_private
*dev_priv,
}
}
-static bool skl_update_pipe_wm(struct drm_crtc *crtc,
+static bool skl_update_pipe_wm(struct drm_crtc_state *cstate,
struct skl_ddb_allocation *ddb, /* out */
struct skl_pipe_wm *pipe_wm /* out */)
{
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
+ struct intel_crtc *intel_crtc = to_intel_crtc(cstate->crtc);
+ struct intel_crtc_state *intel_cstate = to_intel_crtc_state(cstate);
- skl_build_pipe_wm(cstate, ddb, pipe_wm);
+ skl_build_pipe_wm(intel_cstate, ddb, pipe_wm);
if (!memcmp(&intel_crtc->wm.active.skl, pipe_wm, sizeof(*pipe_wm)))
return false;
@@ -3661,7 +3668,7 @@ static void skl_update_other_pipe_wm(struct drm_device
*dev,
if (!intel_crtc->active)
continue;
- wm_changed = skl_update_pipe_wm(&intel_crtc->base,
+ wm_changed = skl_update_pipe_wm(intel_crtc->base.state,
&r->ddb, &pipe_wm);
/*
@@ -3753,7 +3760,7 @@ static void skl_update_wm(struct drm_crtc *crtc)
skl_clear_wm(results, intel_crtc->pipe);
- if (!skl_update_pipe_wm(crtc, &results->ddb, pipe_wm))
+ if (!skl_update_pipe_wm(crtc->state, &results->ddb, pipe_wm))
return;
[Intel-gfx] [PATCH 05/16] drm/i915/gen9: Allow calculation of data rate for in-flight state
Our skl_get_total_relative_data_rate() function gets passed a crtc state
object to calculate the data rate for, but it currently always looks
up the committed plane states that correspond to that CRTC. Let's
check whether the CRTC state is an in-flight state (meaning
cstate->state is non-NULL) and if so, use the corresponding in-flight
plane states.
We'll soon be using this function exclusively for in-flight states; at
that time we'll be able to simplify the function a bit, but for now we
allow it to be used in either mode.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1c3f772..e92513e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2969,18 +2969,36 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
static unsigned int
skl_get_total_relative_data_rate(const struct intel_crtc_state *cstate)
{
- struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
- struct drm_device *dev = intel_crtc->base.dev;
- const struct intel_plane *intel_plane;
+ struct drm_atomic_state *state = cstate->base.state;
+ struct drm_crtc *crtc = cstate->base.crtc;
+ struct drm_device *dev = crtc->dev;
+ struct drm_plane *plane;
unsigned int total_data_rate = 0;
- for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
- const struct drm_plane_state *pstate = intel_plane->base.state;
+ drm_for_each_plane_mask(plane, dev, cstate->base.plane_mask) {
+ struct drm_plane_state *pstate;
- if (pstate->fb == NULL)
- continue;
+ /*
+* FIXME: At the moment this function can be called on either
+* an in-flight or a committed state object. If it's in-flight
+* we want to also use the in-flight plane state; otherwise
+* use the committed plane state.
+*
+* Once we finish moving our DDB allocation to the atomic check
+* phase, we'll only be calling this function on in-flight
+* state objects and should never see a NULL state here.
+*/
+ if (state) {
+ pstate = drm_atomic_get_plane_state(state, plane);
+ if (IS_ERR(pstate))
+ return PTR_ERR(pstate);
+ } else {
+ pstate = plane->state;
+ }
- if (intel_plane->base.type == DRM_PLANE_TYPE_CURSOR)
+ if (!to_intel_plane_state(pstate)->visible)
+ continue;
+ if (plane->type == DRM_PLANE_TYPE_CURSOR)
continue;
/* packed/uv */
@@ -2995,6 +3013,8 @@ skl_get_total_relative_data_rate(const struct
intel_crtc_state *cstate)
1);
}
+ WARN_ON(cstate->base.plane_mask && total_data_rate == 0);
+
return total_data_rate;
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/16] drm/i915/gen9: Compute DDB allocation at atomic check time
Calculate the DDB blocks needed to satisfy the current atomic
transaction at atomic check time. This is a prerequisite to calculating
SKL watermarks during the 'check' phase and rejecting any configurations
that we can't find valid watermarks for.
Due to the nature of DDB allocation, it's possible for the addition of a
new CRTC to make the watermark configuration already in use on another,
unchanged CRTC become invalid. A change in which CRTC's are active
triggers a recompute of the entire DDB, which unfortunately means we
need to disallow any other atomic commits from racing with such an
update. If the active CRTC's change, we need to grab the lock on all
CRTC's and run all CRTC's through their 'check' handler to recompute and
re-check their per-CRTC DDB allocations.
Note that with this patch we only compute the DDB allocation but we
don't actually use the computed values during watermark programming yet.
For ease of review/testing/bisecting, we still recompute the DDB at
watermark programming time and just WARN() if it doesn't match the
precomputed values. A future patch will switch over to using the
precomputed values once we're sure they're being properly computed.
Another clarifying note: DDB allocation itself shouldn't ever fail with
the algorithm we use today (i.e., we have enough DDB blocks on BXT to
support the minimum needs of the worst-case scenario of every pipe/plane
enabled at full size). However the watermarks calculations based on the
DDB may fail and we'll be moving those to the atomic check as well in
future patches.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 5
drivers/gpu/drm/i915/intel_display.c | 18
drivers/gpu/drm/i915/intel_drv.h | 3 ++
drivers/gpu/drm/i915/intel_pm.c | 53
4 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 79f1974..35cebd4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -333,6 +333,10 @@ struct i915_hotplug {
#define for_each_intel_crtc(dev, intel_crtc) \
list_for_each_entry(intel_crtc, &dev->mode_config.crtc_list, base.head)
+#define for_each_intel_crtc_mask(dev, intel_crtc, crtc_mask) \
+ list_for_each_entry(intel_crtc, &dev->mode_config.crtc_list, base.head)
\
+ for_each_if ((crtc_mask) & (1 <<
drm_crtc_index(&intel_crtc->base)))
+
#define for_each_intel_encoder(dev, intel_encoder) \
list_for_each_entry(intel_encoder, \
&(dev)->mode_config.encoder_list, \
@@ -587,6 +591,7 @@ struct drm_i915_display_funcs {
struct intel_crtc_state *newstate);
void (*initial_watermarks)(struct intel_crtc_state *cstate);
void (*optimize_watermarks)(struct intel_crtc_state *cstate);
+ int (*compute_global_watermarks)(struct drm_atomic_state *state);
void (*update_wm)(struct drm_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ab1fc3d..6bf2ede 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13230,6 +13230,7 @@ static int intel_modeset_checks(struct drm_atomic_state
*state)
static void calc_watermark_data(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_crtc *crtc;
struct drm_crtc_state *cstate;
@@ -13259,6 +13260,10 @@ static void calc_watermark_data(struct
drm_atomic_state *state)
pstate->crtc_h != pstate->src_h >> 16)
intel_state->wm_config.sprites_scaled = true;
}
+
+ /* Is there platform-specific watermark information to calculate? */
+ if (dev_priv->display.compute_global_watermarks)
+ dev_priv->display.compute_global_watermarks(state);
}
/**
@@ -13631,6 +13636,19 @@ static int intel_atomic_commit(struct drm_device *dev,
modeset_put_power_domains(dev_priv, put_domains[i]);
}
+ /*
+* Temporary sanity check: make sure our pre-computed DDB matches the
+* one we actually wind up programming.
+*
+* Not a great place to put this, but the easiest place we have access
+* to both the pre-computed and final DDB's; we'll be removing this
+* check in the next patch anyway.
+*/
+ WARN(IS_GEN9(dev) &&
+memcmp(&intel_state->ddb, &dev_priv->wm.skl_results.ddb,
+ sizeof(intel_state->ddb)),
+"Pre-computed DDB does not match final DDB!\n");
+
if (intel_
[Intel-gfx] [PATCH 15/16] drm/i915/gen9: Reject display updates that exceed wm limitations
If we can't find any valid level 0 watermark values for the requested
atomic transaction, reject the configuration before we try to start
programming the hardware.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e4de5aa..8370bb5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3272,7 +3272,17 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
if (res_blocks >= ddb_allocation || res_lines > 31) {
*enabled = false;
- return 0;
+
+ /*
+* If there are no valid level 0 watermarks, then we can't
+* support this display configuration.
+*/
+ if (level) {
+ return 0;
+ } else {
+ DRM_DEBUG_KMS("Requested display configuration exceeds
system watermark limitations\n");
+ return -EINVAL;
+ }
}
*out_blocks = res_blocks;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/16] drm/i915: Ensure intel_state->active_crtcs is always set
We currently only setup intel_state->active_crtcs if we plan to modify
it and write the modification back to dev_priv. Let's ensure that
this value is always valid, even when it isn't changing as part of an
atomic transaction.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e6b5ee5..ab1fc3d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13185,7 +13185,6 @@ static int intel_modeset_checks(struct drm_atomic_state
*state)
}
intel_state->modeset = true;
- intel_state->active_crtcs = dev_priv->active_crtcs;
for_each_crtc_in_state(state, crtc, crtc_state, i) {
if (crtc_state->active)
@@ -13281,6 +13280,8 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
return ret;
+ intel_state->active_crtcs = dev_priv->active_crtcs;
+
for_each_crtc_in_state(state, crtc, crtc_state, i) {
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/16] drm/i915/gen9: Propagate watermark calculation failures up the call chain
Once we move watermark calculation to the atomic check phase, we'll want
to start rejecting display configurations that exceed out watermark
limits. At the moment we just assume that there's always a valid set of
watermarks, even though this may not actually be true. Let's prepare by
passing return codes up through the call stack in preparation.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 10 ++--
drivers/gpu/drm/i915/intel_pm.c | 90 ++--
2 files changed, 61 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fa4e5e3..c514549 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13227,7 +13227,7 @@ static int intel_modeset_checks(struct drm_atomic_state
*state)
* phase. The code here should be run after the per-crtc and per-plane 'check'
* handlers to ensure that all derived state has been updated.
*/
-static void calc_watermark_data(struct drm_atomic_state *state)
+static int calc_watermark_data(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -13263,7 +13263,9 @@ static void calc_watermark_data(struct drm_atomic_state
*state)
/* Is there platform-specific watermark information to calculate? */
if (dev_priv->display.compute_global_watermarks)
- dev_priv->display.compute_global_watermarks(state);
+ return dev_priv->display.compute_global_watermarks(state);
+
+ return 0;
}
/**
@@ -13349,9 +13351,7 @@ static int intel_atomic_check(struct drm_device *dev,
return ret;
intel_fbc_choose_crtc(dev_priv, state);
- calc_watermark_data(state);
-
- return 0;
+ return calc_watermark_data(state);
}
static int intel_atomic_prepare_commit(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index be7fbff..1bef89a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3204,13 +3204,14 @@ static bool skl_ddb_allocation_changed(const struct
skl_ddb_allocation *new_ddb,
return false;
}
-static bool skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
-struct intel_crtc_state *cstate,
-struct intel_plane_state *intel_pstate,
-uint16_t ddb_allocation,
-int level,
-uint16_t *out_blocks, /* out */
-uint8_t *out_lines /* out */)
+static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
+ struct intel_crtc_state *cstate,
+ struct intel_plane_state *intel_pstate,
+ uint16_t ddb_allocation,
+ int level,
+ uint16_t *out_blocks, /* out */
+ uint8_t *out_lines, /* out */
+ bool *enabled /* out */)
{
struct drm_plane_state *pstate = &intel_pstate->base;
struct drm_framebuffer *fb = pstate->fb;
@@ -3222,8 +3223,10 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint8_t cpp;
uint32_t width = 0, height = 0;
- if (latency == 0 || !cstate->base.active || !intel_pstate->visible)
- return false;
+ if (latency == 0 || !cstate->base.active || !intel_pstate->visible) {
+ *enabled = false;
+ return 0;
+ }
width = drm_rect_width(&intel_pstate->src) >> 16;
height = drm_rect_height(&intel_pstate->src) >> 16;
@@ -3284,13 +3287,16 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
res_blocks++;
}
- if (res_blocks >= ddb_allocation || res_lines > 31)
- return false;
+ if (res_blocks >= ddb_allocation || res_lines > 31) {
+ *enabled = false;
+ return 0;
+ }
*out_blocks = res_blocks;
*out_lines = res_lines;
+ *enabled = true;
- return true;
+ return 0;
}
static int
@@ -3306,6 +3312,7 @@ skl_compute_wm_level(const struct drm_i915_private
*dev_priv,
struct intel_plane_state *intel_pstate;
uint16_t ddb_blocks;
enum pipe pipe = intel_crtc->pipe;
+ int ret;
for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
int i = skl_wm_plane_id(intel_plane);
@@ -3317,13 +3324,16 @@ skl_compute_wm_level(const struct drm_i915_private
*dev_priv,
ddb_blocks = skl_ddb_entry_size(&ddb->plane[pipe][i]);
- result->plane_en[i] = skl_compute_plane_wm(dev_priv,
-
[Intel-gfx] [PATCH 16/16] drm/i915: Remove wm_config from dev_priv/intel_atomic_state
We calculate the watermark config into intel_atomic_state and then save
it into dev_priv, but never actually use it from there. This is
left-over from some early ILK-style watermark programming designs that
got changed over time.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 3 ---
drivers/gpu/drm/i915/intel_display.c | 31 ---
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 34b843d..044e977 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1937,9 +1937,6 @@ struct drm_i915_private {
*/
uint16_t skl_latency[8];
- /* Committed wm config */
- struct intel_wm_config config;
-
/*
* The skl_wm_values structure is a bit too big for stack
* allocation, so we keep the staging struct where we store
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f1bea9f..f650e8c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13231,35 +13231,6 @@ static int calc_watermark_data(struct drm_atomic_state
*state)
{
struct drm_device *dev = state->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct drm_crtc *crtc;
- struct drm_crtc_state *cstate;
- struct drm_plane *plane;
- struct drm_plane_state *pstate;
-
- /*
-* Calculate watermark configuration details now that derived
-* plane/crtc state is all properly updated.
-*/
- drm_for_each_crtc(crtc, dev) {
- cstate = drm_atomic_get_existing_crtc_state(state, crtc) ?:
- crtc->state;
-
- if (cstate->active)
- intel_state->wm_config.num_pipes_active++;
- }
- drm_for_each_legacy_plane(plane, dev) {
- pstate = drm_atomic_get_existing_plane_state(state, plane) ?:
- plane->state;
-
- if (!to_intel_plane_state(pstate)->visible)
- continue;
-
- intel_state->wm_config.sprites_enabled = true;
- if (pstate->crtc_w != pstate->src_w >> 16 ||
- pstate->crtc_h != pstate->src_h >> 16)
- intel_state->wm_config.sprites_scaled = true;
- }
/* Is there platform-specific watermark information to calculate? */
if (dev_priv->display.compute_global_watermarks)
@@ -13522,7 +13493,6 @@ static int intel_atomic_commit(struct drm_device *dev,
}
drm_atomic_helper_swap_state(dev, state);
- dev_priv->wm.config = intel_state->wm_config;
dev_priv->wm.skl_results = intel_state->wm_results;
intel_shared_dpll_commit(state);
@@ -15274,7 +15244,6 @@ retry:
}
/* Write calculated watermark values back */
- to_i915(dev)->wm.config = to_intel_atomic_state(state)->wm_config;
for_each_crtc_in_state(state, crtc, cstate, i) {
struct intel_crtc_state *cs = to_intel_crtc_state(cstate);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3abd394..a43da8e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -294,7 +294,6 @@ struct intel_atomic_state {
unsigned int min_pixclk[I915_MAX_PIPES];
struct intel_shared_dpll_config shared_dpll[I915_NUM_PLLS];
- struct intel_wm_config wm_config;
/*
* Current watermarks can't be trusted during hardware readout, so
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/16] drm/i915/gen9: Calculate watermarks during atomic 'check'
Moving watermark calculation into the check phase will allow us to to
reject display configurations for which there are no valid watermark
values before we start trying to program the hardware (although those
tests will come in a subsequent patch).
Another advantage of moving this calculation to the check phase is that
we can calculate the watermarks in a single shot as part of the atomic
transaction. The watermark interfaces we inherited from our legacy
modesetting days are a bit broken in the atomic design because they use
per-crtc entry points but actually re-calculate and re-program something
that is really more of a global state. That worked okay in the legacy
modesetting world because operations only ever updated a single CRTC at
a time. However in the atomic world, a transaction can involve multiple
CRTC's, which means we wind up computing and programming the watermarks
NxN times (where N is the number of CRTC's involved). With this patch
we eliminate the redundant re-calculation of watermark data for atomic
states (which was the cause of the WARN_ON(!wm_changed) problems that
have plagued us for a while).
We still need to work on the 'commit' side of watermark handling so that
we aren't doing redundant NxN programming of watermarks, but that's
content for future patches.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 141 +--
3 files changed, 55 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c514549..f1bea9f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13523,7 +13523,7 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_helper_swap_state(dev, state);
dev_priv->wm.config = intel_state->wm_config;
- dev_priv->wm.skl_results.ddb = intel_state->ddb;
+ dev_priv->wm.skl_results = intel_state->wm_results;
intel_shared_dpll_commit(state);
if (intel_state->modeset) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6471f69..3abd394 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -303,7 +303,7 @@ struct intel_atomic_state {
bool skip_intermediate_wm;
/* Gen9+ only */
- struct skl_ddb_allocation ddb;
+ struct skl_wm_values wm_results;
};
struct intel_plane_state {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1bef89a..e4de5aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3187,23 +3187,6 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
return ret;
}
-static bool skl_ddb_allocation_changed(const struct skl_ddb_allocation
*new_ddb,
- const struct intel_crtc *intel_crtc)
-{
- struct drm_device *dev = intel_crtc->base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- const struct skl_ddb_allocation *cur_ddb = &dev_priv->wm.skl_hw.ddb;
-
- /*
-* If ddb allocation of pipes changed, it may require recalculation of
-* watermarks
-*/
- if (memcmp(new_ddb->pipe, cur_ddb->pipe, sizeof(new_ddb->pipe)))
- return true;
-
- return false;
-}
-
static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
struct intel_plane_state *intel_pstate,
@@ -3654,72 +3637,16 @@ static int skl_update_pipe_wm(struct drm_crtc_state
*cstate,
else
*changed = true;
- intel_crtc->wm.active.skl = *pipe_wm;
-
return 0;
}
-static void skl_update_other_pipe_wm(struct drm_device *dev,
-struct drm_crtc *crtc,
-struct skl_wm_values *r)
-{
- struct intel_crtc *intel_crtc;
- struct intel_crtc *this_crtc = to_intel_crtc(crtc);
-
- /*
-* If the WM update hasn't changed the allocation for this_crtc (the
-* crtc we are currently computing the new WM values for), other
-* enabled crtcs will keep the same allocation and we don't need to
-* recompute anything for them.
-*/
- if (!skl_ddb_allocation_changed(&r->ddb, this_crtc))
- return;
-
- /*
-* Otherwise, because of this_crtc being freshly enabled/disabled, the
-* other active pipes need new DDB allocation and WM values.
-*/
- for_each_intel_crtc(dev, intel_crtc) {
- struct skl_pipe_wm pipe_wm = {};
- bool wm_changed;
-
- if (this_crtc->pipe == intel_crtc->pipe)
- continue;
-
- if (!intel_crtc->activ
[Intel-gfx] [PATCH 10/16] drm/i915/gen9: Calculate plane WM's from state
In a future patch we'll want to calculate plane watermarks for in-flight
atomic state rather than the already-committed state.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d58a405..6aafbb1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3206,16 +3206,14 @@ static bool skl_ddb_allocation_changed(const struct
skl_ddb_allocation *new_ddb,
static bool skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
-struct intel_plane *intel_plane,
+struct intel_plane_state *intel_pstate,
uint16_t ddb_allocation,
int level,
uint16_t *out_blocks, /* out */
uint8_t *out_lines /* out */)
{
- struct drm_plane *plane = &intel_plane->base;
- struct drm_framebuffer *fb = plane->state->fb;
- struct intel_plane_state *intel_pstate =
- to_intel_plane_state(plane->state);
+ struct drm_plane_state *pstate = &intel_pstate->base;
+ struct drm_framebuffer *fb = pstate->fb;
uint32_t latency = dev_priv->wm.skl_latency[level];
uint32_t method1, method2;
uint32_t plane_bytes_per_line, plane_blocks_per_line;
@@ -3230,7 +3228,7 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
width = drm_rect_width(&intel_pstate->src) >> 16;
height = drm_rect_height(&intel_pstate->src) >> 16;
- if (intel_rotation_90_or_270(plane->state->rotation))
+ if (intel_rotation_90_or_270(pstate->rotation))
swap(width, height);
cpp = drm_format_plane_cpp(fb->pixel_format, 0);
@@ -3250,7 +3248,7 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
uint32_t min_scanlines = 4;
uint32_t y_tile_minimum;
- if (intel_rotation_90_or_270(plane->state->rotation)) {
+ if (intel_rotation_90_or_270(pstate->rotation)) {
int cpp = (fb->pixel_format == DRM_FORMAT_NV12) ?
drm_format_plane_cpp(fb->pixel_format, 1) :
drm_format_plane_cpp(fb->pixel_format, 0);
@@ -3304,17 +3302,19 @@ static void skl_compute_wm_level(const struct
drm_i915_private *dev_priv,
struct drm_device *dev = dev_priv->dev;
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct intel_plane *intel_plane;
+ struct intel_plane_state *intel_pstate;
uint16_t ddb_blocks;
enum pipe pipe = intel_crtc->pipe;
for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
int i = skl_wm_plane_id(intel_plane);
+ intel_pstate = to_intel_plane_state(intel_plane->base.state);
ddb_blocks = skl_ddb_entry_size(&ddb->plane[pipe][i]);
result->plane_en[i] = skl_compute_plane_wm(dev_priv,
cstate,
- intel_plane,
+ intel_pstate,
ddb_blocks,
level,
&result->plane_res_b[i],
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/16] drm/i915/gen9: Drop re-allocation of DDB at atomic commit
Now that we're properly pre-allocating the DDB during the atomic check
phase and we trust that the allocation is appropriate, let's actually
use the allocation computed and not duplicate that work during the
commit phase.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 14 +-
drivers/gpu/drm/i915/intel_pm.c | 84
2 files changed, 18 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6bf2ede..fa4e5e3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13523,6 +13523,7 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_helper_swap_state(dev, state);
dev_priv->wm.config = intel_state->wm_config;
+ dev_priv->wm.skl_results.ddb = intel_state->ddb;
intel_shared_dpll_commit(state);
if (intel_state->modeset) {
@@ -13636,19 +13637,6 @@ static int intel_atomic_commit(struct drm_device *dev,
modeset_put_power_domains(dev_priv, put_domains[i]);
}
- /*
-* Temporary sanity check: make sure our pre-computed DDB matches the
-* one we actually wind up programming.
-*
-* Not a great place to put this, but the easiest place we have access
-* to both the pre-computed and final DDB's; we'll be removing this
-* check in the next patch anyway.
-*/
- WARN(IS_GEN9(dev) &&
-memcmp(&intel_state->ddb, &dev_priv->wm.skl_results.ddb,
- sizeof(intel_state->ddb)),
-"Pre-computed DDB does not match final DDB!\n");
-
if (intel_state->modeset)
intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8e283cf..d58a405 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2966,26 +2966,15 @@ skl_get_total_relative_data_rate(const struct
intel_crtc_state *cstate)
struct drm_plane *plane;
unsigned int total_data_rate = 0;
+ if (WARN_ON(!state))
+ return 0;
+
drm_for_each_plane_mask(plane, dev, cstate->base.plane_mask) {
struct drm_plane_state *pstate;
- /*
-* FIXME: At the moment this function can be called on either
-* an in-flight or a committed state object. If it's in-flight
-* we want to also use the in-flight plane state; otherwise
-* use the committed plane state.
-*
-* Once we finish moving our DDB allocation to the atomic check
-* phase, we'll only be calling this function on in-flight
-* state objects and should never see a NULL state here.
-*/
- if (state) {
- pstate = drm_atomic_get_plane_state(state, plane);
- if (IS_ERR(pstate))
- return PTR_ERR(pstate);
- } else {
- pstate = plane->state;
- }
+ pstate = drm_atomic_get_plane_state(state, plane);
+ if (IS_ERR(pstate))
+ return PTR_ERR(pstate);
if (!to_intel_plane_state(pstate)->visible)
continue;
@@ -3015,9 +3004,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
{
struct drm_crtc *crtc = cstate->base.crtc;
struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_plane *intel_plane;
+ struct intel_atomic_state *intel_state;
enum pipe pipe = intel_crtc->pipe;
struct skl_ddb_entry *alloc = &ddb->pipe[pipe];
uint16_t alloc_size, start, cursor_blocks;
@@ -3035,21 +3024,11 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
return 0;
}
- /*
-* TODO: At the moment we might call this on either an in-flight CRTC
-* state or an already-committed state, so look up the number of
-* active CRTC's accordingly. Eventually this will only be called
-* on in-flight states and we'll be able to drop some of this extra
-* logic.
-*/
- if (cstate->base.state) {
- struct intel_atomic_state *intel_state =
- to_intel_atomic_state(cstate->base.state);
+ if (WARN_ON(!cstate->base.state))
+ return 0;
- active_crtcs = intel_state->active_crtcs;
- } else {
- active_crtcs = dev_priv->active_crtcs;
- }
+ intel_state = to_intel_atomic_state(cstate->base.state);
+ active_crtcs = intel_state->active_crtcs;
skl_ddb_get_pipe_allocation_limits(dev, cstate, active
[Intel-gfx] [PATCH 04/16] drm/i915/skl+: Use plane size for relative data rate calculation
From: "Kumar, Mahesh"
Use plane size for relative data rate calculation. don't always use
pipe source width & height.
adjust height & width according to rotation.
use plane size for watermark calculations also.
v2: Address Matt's comments.
Use intel_plane_state->visible to avoid divide-by-zero error.
Where FB was present but not visible so causing total data rate to
be zero, hence divide-by-zero.
Cc: matthew.d.ro...@intel.com
Signed-off-by: Kumar, Mahesh
Reviewed-by: Matt Roper
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c970c4e..1c3f772 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2937,24 +2937,28 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
const struct drm_plane_state *pstate,
int y)
{
- struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
+ struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
struct drm_framebuffer *fb = pstate->fb;
+ uint32_t width = 0, height = 0;
+
+ width = drm_rect_width(&intel_pstate->src) >> 16;
+ height = drm_rect_height(&intel_pstate->src) >> 16;
+
+ if (intel_rotation_90_or_270(pstate->rotation))
+ swap(width, height);
/* for planar format */
if (fb->pixel_format == DRM_FORMAT_NV12) {
if (y) /* y-plane data rate */
- return intel_crtc->config->pipe_src_w *
- intel_crtc->config->pipe_src_h *
+ return width * height *
drm_format_plane_cpp(fb->pixel_format, 0);
else/* uv-plane data rate */
- return (intel_crtc->config->pipe_src_w/2) *
- (intel_crtc->config->pipe_src_h/2) *
+ return (width / 2) * (height / 2) *
drm_format_plane_cpp(fb->pixel_format, 1);
}
/* for packed formats */
- return cstate->pipe_src_w * cstate->pipe_src_h *
- drm_format_plane_cpp(fb->pixel_format, 0);
+ return width * height * drm_format_plane_cpp(fb->pixel_format, 0);
}
/*
@@ -3033,8 +3037,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
struct drm_framebuffer *fb = plane->state->fb;
int id = skl_wm_plane_id(intel_plane);
- if (fb == NULL)
+ if (!to_intel_plane_state(plane->state)->visible)
continue;
+
if (plane->type == DRM_PLANE_TYPE_CURSOR)
continue;
@@ -3060,7 +3065,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
uint16_t plane_blocks, y_plane_blocks = 0;
int id = skl_wm_plane_id(intel_plane);
- if (pstate->fb == NULL)
+ if (!to_intel_plane_state(pstate)->visible)
continue;
if (plane->type == DRM_PLANE_TYPE_CURSOR)
continue;
@@ -3183,26 +3188,36 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
{
struct drm_plane *plane = &intel_plane->base;
struct drm_framebuffer *fb = plane->state->fb;
+ struct intel_plane_state *intel_pstate =
+ to_intel_plane_state(plane->state);
uint32_t latency = dev_priv->wm.skl_latency[level];
uint32_t method1, method2;
uint32_t plane_bytes_per_line, plane_blocks_per_line;
uint32_t res_blocks, res_lines;
uint32_t selected_result;
uint8_t cpp;
+ uint32_t width = 0, height = 0;
- if (latency == 0 || !cstate->base.active || !fb)
+ if (latency == 0 || !cstate->base.active || !intel_pstate->visible)
return false;
+ width = drm_rect_width(&intel_pstate->src) >> 16;
+ height = drm_rect_height(&intel_pstate->src) >> 16;
+
+ if (intel_rotation_90_or_270(plane->state->rotation))
+ swap(width, height);
+
cpp = drm_format_plane_cpp(fb->pixel_format, 0);
method1 = skl_wm_method1(skl_pipe_pixel_rate(cstate),
cpp, latency);
method2 = skl_wm_method2(skl_pipe_pixel_rate(cstate),
cstate->base.adjusted_mode.crtc_htotal,
-cstate->pipe_src_w,
-cpp, fb->modifier[0],
+width,
+cpp,
+fb->modifier[0],
latency);
- plane_bytes_per_line = cstate->pipe_src_w * cpp;
+ plane_bytes_per_line = width * cpp;
