Re: [Intel-gfx] [PATCH 2/4] drm/i915: restrict unclaimed register checking
Paulo Zanoni writes:
> The unclaimed register bit is only triggered when someone touches the
> specified register range.
>
I got the impression that we get the unclaimed access also
for other ranges, if they are powered down during access?
-Mika
> For the normal use case (with i915.mmio_debug=0), this commit will
> avoid the extra __raw_i915_read32() call for every register outside
> the specified range, at the expense of a few additional "if"
> statements.
>
> v2: Put the register range checking earlier (Chris).
>
> Cc: Chris Wilson
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 10c61a6..65e0ea8 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -595,6 +595,8 @@ void assert_forcewakes_inactive(struct drm_i915_private
> *dev_priv)
>!FORCEWAKE_GEN9_MEDIA_RANGE_OFFSET(reg) && \
>!FORCEWAKE_GEN9_COMMON_RANGE_OFFSET(reg))
>
> +#define UNCLAIMED_CHECK_RANGE(reg) REG_RANGE(reg, 0x4, 0xC)
> +
> static void
> ilk_dummy_write(struct drm_i915_private *dev_priv)
> {
> @@ -611,6 +613,9 @@ hsw_unclaimed_reg_debug(struct drm_i915_private
> *dev_priv, u32 reg, bool read,
> const char *op = read ? "reading" : "writing to";
> const char *when = before ? "before" : "after";
>
> + if (!UNCLAIMED_CHECK_RANGE(reg))
> + return;
> +
> if (!i915.mmio_debug)
> return;
>
> @@ -623,10 +628,13 @@ hsw_unclaimed_reg_debug(struct drm_i915_private
> *dev_priv, u32 reg, bool read,
> }
>
> static void
> -hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
> +hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv, u32 reg)
> {
> static bool mmio_debug_once = true;
>
> + if (!UNCLAIMED_CHECK_RANGE(reg))
> + return;
> +
> if (i915.mmio_debug || !mmio_debug_once)
> return;
>
> @@ -892,7 +900,7 @@ hsw_write##x(struct drm_i915_private *dev_priv, off_t
> reg, u##x val, bool trace)
> gen6_gt_check_fifodbg(dev_priv); \
> } \
> hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
> - hsw_unclaimed_reg_detect(dev_priv); \
> + hsw_unclaimed_reg_detect(dev_priv, reg); \
> GEN6_WRITE_FOOTER; \
> }
>
> @@ -934,7 +942,7 @@ gen8_write##x(struct drm_i915_private *dev_priv, off_t
> reg, u##x val, bool trace
> __force_wake_get(dev_priv, FORCEWAKE_RENDER); \
> __raw_i915_write##x(dev_priv, reg, val); \
> hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
> - hsw_unclaimed_reg_detect(dev_priv); \
> + hsw_unclaimed_reg_detect(dev_priv, reg); \
> GEN6_WRITE_FOOTER; \
> }
>
> @@ -1000,7 +1008,7 @@ gen9_write##x(struct drm_i915_private *dev_priv, off_t
> reg, u##x val, \
> __force_wake_get(dev_priv, fw_engine); \
> __raw_i915_write##x(dev_priv, reg, val); \
> hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
> - hsw_unclaimed_reg_detect(dev_priv); \
> + hsw_unclaimed_reg_detect(dev_priv, reg); \
> GEN6_WRITE_FOOTER; \
> }
>
> --
> 2.5.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add kerneldoc for i915_audio_component
On Fri, 04 Sep 2015, "Yang, Libin" wrote:
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
>> Daniel Vetter
>> Sent: Wednesday, September 02, 2015 8:18 PM
>> To: Yang, Libin
>> Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch;
>> jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com
>> Subject: Re: [PATCH] drm/i915: add kerneldoc for
>> i915_audio_component
>>
>> On Wed, Sep 02, 2015 at 02:12:24PM +0800, libin.y...@intel.com
>> wrote:
>> > From: Libin Yang
>> >
>> > Add the kerneldoc for i915_audio_component in i915_component.h
>> >
>> > Signed-off-by: Libin Yang
>> > ---
>> > include/drm/i915_component.h | 39 --
>> -
>> > 1 file changed, 24 insertions(+), 15 deletions(-)
>> >
>> > diff --git a/include/drm/i915_component.h
>> b/include/drm/i915_component.h
>> > index 8ad6f1b..187acc8 100644
>> > --- a/include/drm/i915_component.h
>> > +++ b/include/drm/i915_component.h
>> > @@ -24,23 +24,32 @@
>> > #ifndef _I915_COMPONENT_H_
>> > #define _I915_COMPONENT_H_
>> >
>> > +/**
>> > + * struct i915_audio_component_ops - callbacks defined in gfx
>> driver
>> > + * @owner: the module owner
>> > + * @get_power: get the POWER_DOMAIN_AUDIO power well
>> > + * @put_power: put the POWER_DOMAIN_AUDIO power well
>> > + * @codec_wake_override: Enable/Disable generating the codec
>> wake signal
>> > + * @get_cdclk_freq: get the Core Display Clock in KHz
>> > + * @sync_audio_rate: set n/cts based on the sample rate
>> > + */
>> > +struct i915_audio_component_ops {
>> > + struct module *owner;
>>
>> New kerneldoc in 4.3 allows you to split structure documentation up
>> into
>> per-member comments. Especially with vtables I think this makes a lot
>> of
>> sense, since then you have enough space to document where and how
>> exactly
>> a given hook is called (looks, place in the overall sequence).
>>
>> Also please include your stancas in the drm.tmpl docbook template,
>> otherwise it won't be included in the html docs. And finally please add
>
> OK, I will add it in drm.tmpl.
>
>> a
>> DOC: overview section which explains at a high level how i915 and
>> hda-intel corporate for hdmi/dp audio.
>
> Where the DOC should be located in?
i915/intel_audio.c already has a "DOC: High Definition Audio over HDMI
and Display Port" comment. IMO you could just amend that, as there's
already some references to the audio driver.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset
On Fri, 04 Sep 2015 03:56:26 +0200, Yang, Libin wrote: > > > > -Original Message- > > From: Takashi Iwai [mailto:ti...@suse.de] > > Sent: Wednesday, September 02, 2015 11:36 PM > > To: Daniel Vetter > > Cc: Jani Nikula; Yang, Libin; alsa-de...@alsa-project.org; intel- > > g...@lists.freedesktop.org; daniel.vet...@ffwll.ch; > > ville.syrj...@linux.intel.com > > Subject: Re: [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset > > > > On Wed, 02 Sep 2015 17:22:01 +0200, > > Daniel Vetter wrote: > > > > > > On Wed, Sep 02, 2015 at 03:46:40PM +0200, Takashi Iwai wrote: > > > > On Wed, 02 Sep 2015 15:44:34 +0200, > > > > Jani Nikula wrote: > > > > > > > > > > On Wed, 02 Sep 2015, Takashi Iwai wrote: > > > > > > On Wed, 02 Sep 2015 11:02:42 +0200, > > > > > > Jani Nikula wrote: > > > > > >> > > > > > >> >> Nitpick. I'd prefer some sharing with the similar blocks from > > the > > > > > >> >> earlier patch. Also a debug message on n == 0 would be > > nice; you > > > > > >> >> probably didn't notice your audio_config_get_rate() wasn't > > working > > > > > >> >> right > > > > > >> >> because this silently fell back to the automatic mode here. > > > > > >> > > > > > > >> > OK, I will add the msg. As you and Ville are insisting on > > > > > >> > sharing code, I will do it in next version. > > > > > >> > > > > > >> Well, really, I'm fine with having that part duplicated as-is for > > now, > > > > > >> we can fix it later. More important to focus on getting > > > > > >> audio_config_get_rate() right. > > > > > >> > > > > > >> I don't know if you're still targeting v4.3 with this (up to > > Takashi I > > > > > >> guess) we'll really need to wrap this up soon. > > > > > > > > > > > > I'm in favor of merging this into 4.3, so it'd be appreciated if > > Libin > > > > > > can prepare the fixed version soonish, indeed. > > > > > > > > > > IIUC patches 1-3 would be useful on their own already, and a > > fixed > > > > > version of patch 4 could follow. Just a thought. > > > > > > > > That's good, then I can take the first three patches. > > > > > > > > Daniel, would you like to review these three before I merge them? > > > > I assumed your previous mail as a kind of ack to this series, too. > > > > > > fwiw ack on that plan, but given how much I made a mess out of > > these two > > > series and mixed them up I wouldn't trust me anyway ;-) > > > > > > Once the code settles I'll rebase/backmerge so that I can apply the > > > follow-up documentation/kerneldoc work that's still getting done. > > > > FYI, I've pushed a branch including Libin's patchset (but only patches > > 1-3) just for checking. Let me know if this looks OK. > > Thanks, Takashi, Daniel, Jani and Ville. > > So I need submit the 4th patch only next time, right? Yes. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset
> -Original Message- > From: Takashi Iwai [mailto:ti...@suse.de] > Sent: Wednesday, September 02, 2015 11:36 PM > To: Daniel Vetter > Cc: Jani Nikula; Yang, Libin; alsa-de...@alsa-project.org; intel- > g...@lists.freedesktop.org; daniel.vet...@ffwll.ch; > ville.syrj...@linux.intel.com > Subject: Re: [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset > > On Wed, 02 Sep 2015 17:22:01 +0200, > Daniel Vetter wrote: > > > > On Wed, Sep 02, 2015 at 03:46:40PM +0200, Takashi Iwai wrote: > > > On Wed, 02 Sep 2015 15:44:34 +0200, > > > Jani Nikula wrote: > > > > > > > > On Wed, 02 Sep 2015, Takashi Iwai wrote: > > > > > On Wed, 02 Sep 2015 11:02:42 +0200, > > > > > Jani Nikula wrote: > > > > >> > > > > >> >> Nitpick. I'd prefer some sharing with the similar blocks from > the > > > > >> >> earlier patch. Also a debug message on n == 0 would be > nice; you > > > > >> >> probably didn't notice your audio_config_get_rate() wasn't > working > > > > >> >> right > > > > >> >> because this silently fell back to the automatic mode here. > > > > >> > > > > > >> > OK, I will add the msg. As you and Ville are insisting on > > > > >> > sharing code, I will do it in next version. > > > > >> > > > > >> Well, really, I'm fine with having that part duplicated as-is for > now, > > > > >> we can fix it later. More important to focus on getting > > > > >> audio_config_get_rate() right. > > > > >> > > > > >> I don't know if you're still targeting v4.3 with this (up to > Takashi I > > > > >> guess) we'll really need to wrap this up soon. > > > > > > > > > > I'm in favor of merging this into 4.3, so it'd be appreciated if > Libin > > > > > can prepare the fixed version soonish, indeed. > > > > > > > > IIUC patches 1-3 would be useful on their own already, and a > fixed > > > > version of patch 4 could follow. Just a thought. > > > > > > That's good, then I can take the first three patches. > > > > > > Daniel, would you like to review these three before I merge them? > > > I assumed your previous mail as a kind of ack to this series, too. > > > > fwiw ack on that plan, but given how much I made a mess out of > these two > > series and mixed them up I wouldn't trust me anyway ;-) > > > > Once the code settles I'll rebase/backmerge so that I can apply the > > follow-up documentation/kerneldoc work that's still getting done. > > FYI, I've pushed a branch including Libin's patchset (but only patches > 1-3) just for checking. Let me know if this looks OK. Thanks, Takashi, Daniel, Jani and Ville. So I need submit the 4th patch only next time, right? > > > Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add kerneldoc for i915_audio_component
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, September 02, 2015 8:18 PM
> To: Yang, Libin
> Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com
> Subject: Re: [PATCH] drm/i915: add kerneldoc for
> i915_audio_component
>
> On Wed, Sep 02, 2015 at 02:12:24PM +0800, libin.y...@intel.com
> wrote:
> > From: Libin Yang
> >
> > Add the kerneldoc for i915_audio_component in i915_component.h
> >
> > Signed-off-by: Libin Yang
> > ---
> > include/drm/i915_component.h | 39 --
> -
> > 1 file changed, 24 insertions(+), 15 deletions(-)
> >
> > diff --git a/include/drm/i915_component.h
> b/include/drm/i915_component.h
> > index 8ad6f1b..187acc8 100644
> > --- a/include/drm/i915_component.h
> > +++ b/include/drm/i915_component.h
> > @@ -24,23 +24,32 @@
> > #ifndef _I915_COMPONENT_H_
> > #define _I915_COMPONENT_H_
> >
> > +/**
> > + * struct i915_audio_component_ops - callbacks defined in gfx
> driver
> > + * @owner: the module owner
> > + * @get_power: get the POWER_DOMAIN_AUDIO power well
> > + * @put_power: put the POWER_DOMAIN_AUDIO power well
> > + * @codec_wake_override: Enable/Disable generating the codec
> wake signal
> > + * @get_cdclk_freq: get the Core Display Clock in KHz
> > + * @sync_audio_rate: set n/cts based on the sample rate
> > + */
> > +struct i915_audio_component_ops {
> > + struct module *owner;
>
> New kerneldoc in 4.3 allows you to split structure documentation up
> into
> per-member comments. Especially with vtables I think this makes a lot
> of
> sense, since then you have enough space to document where and how
> exactly
> a given hook is called (looks, place in the overall sequence).
>
> Also please include your stancas in the drm.tmpl docbook template,
> otherwise it won't be included in the html docs. And finally please add
OK, I will add it in drm.tmpl.
> a
> DOC: overview section which explains at a high level how i915 and
> hda-intel corporate for hdmi/dp audio.
Where the DOC should be located in?
>
> Thanks, Daniel
>
> > + void (*get_power)(struct device *);
> > + void (*put_power)(struct device *);
> > + void (*codec_wake_override)(struct device *, bool enable);
> > + int (*get_cdclk_freq)(struct device *);
> > + int (*sync_audio_rate)(struct device *, int port, int rate);
> > +};
> > +
> > +/**
> > + * struct i915_audio_component - used for audio video interaction
> > + * @dev: the device from gfx driver
> > + * @ops: callback for audio driver calling
> > + */
> > struct i915_audio_component {
> > struct device *dev;
> > -
> > - const struct i915_audio_component_ops {
> > - struct module *owner;
> > - void (*get_power)(struct device *);
> > - void (*put_power)(struct device *);
> > - void (*codec_wake_override)(struct device *, bool
> enable);
> > - int (*get_cdclk_freq)(struct device *);
> > - /**
> > -* @sync_audio_rate: set n/cts based on the sample
> rate
> > -*
> > -* Called from audio driver. After audio driver sets the
> > -* sample rate, it will call this function to set n/cts
> > -*/
> > - int (*sync_audio_rate)(struct device *, int port, int
> rate);
> > - } *ops;
> > + const struct i915_audio_component_ops *ops;
> > };
> >
> > #endif /* _I915_COMPONENT_H_ */
> > --
> > 1.9.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-firmware-i915 pull request
On Thu, Aug 20, 2015 at 03:42:27PM +, Vivi, Rodrigo wrote:
> Hi,
>
> Please consider pulling i915 updates to linux-firmware.git.
>
> The following changes since commit
> 38358cfcf50436bf4462b3e45f5b30ab66bb63a6:
>
> firmware: tegra: Update XHCI firmware to v50.10 for T210 (2015-08-12
> 14:39:31 -0400)
>
> are available in the git repository at:
>
> git://people.freedesktop.org/~vivijim/linux-firmware-i915
>
> for you to fetch changes up to
> d1fa230aff5d7bd198c9697b1eee396fd66d88a4:
>
pulled, thanks! (sorry for the delay, have been on vacation.)
regards, --kyle
> linux-firmware: New major GuC release for Skylake. (2015-08-20
> 08:28:18 -0700)
>
>
> Rodrigo Vivi (6):
> linux-firmware: New minor DMC release for Skylake - ver1_19
> linux-firmware: New minor DMC release for Broxton - ver1_05
> linux-firmware: New minor DMC release for Skylake - ver1_20
> linux-firmware: New minor DMC release for Skylake - ver1_21
> linux-firmware: Clean up i915 by removing old skl dmc firmware.
> linux-firmware: New major GuC release for Skylake.
>
> WHENCE| 15 ++
> -
> i915/bxt_dmc_ver1.bin | 2 +-
> i915/bxt_dmc_ver1_05.bin | Bin 0 -> 5872
> bytes
> i915/skl_dmc_ver1.bin | 2 +-
> i915/skl_dmc_ver1_04.bin | Bin 8048 -> 0
> bytes
> i915/{skl_dmc_ver1_16.bin => skl_dmc_ver1_19.bin} | Bin 7892 -> 8380
> bytes
> i915/{skl_dmc_ver1_18.bin => skl_dmc_ver1_20.bin} | Bin 7892 -> 8380
> bytes
> i915/skl_dmc_ver1_21.bin | Bin 0 -> 8824
> bytes
> i915/skl_guc_ver4.bin | 1 +
> i915/skl_guc_ver4_3.bin | Bin 0 -> 128320
> bytes
> 10 files changed, 13 insertions(+), 7 deletions(-)
> create mode 100644 i915/bxt_dmc_ver1_05.bin
> delete mode 100644 i915/skl_dmc_ver1_04.bin
> rename i915/{skl_dmc_ver1_16.bin => skl_dmc_ver1_19.bin} (90%)
> rename i915/{skl_dmc_ver1_18.bin => skl_dmc_ver1_20.bin} (58%)
> create mode 100644 i915/skl_dmc_ver1_21.bin
> create mode 12 i915/skl_guc_ver4.bin
> create mode 100644 i915/skl_guc_ver4_3.bin
>
> Thanks,
> Rodrigo.
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Future proof uncore_init.
Unless future specs tells otherwise we can assume future gens
inherit some stuff from the previous so let's handle
missed cases when we know tehy should't be there and assume
default equals newest one.
No functional changes.
v2: Remove useless case as pointed out by Ville.
Ville Syrjälä
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_uncore.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index dec20d6..440e2a5 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1202,8 +1202,6 @@ void intel_uncore_init(struct drm_device *dev)
switch (INTEL_INFO(dev)->gen) {
default:
- MISSING_CASE(INTEL_INFO(dev)->gen);
- return;
case 9:
ASSIGN_WRITE_MMIO_VFUNCS(gen9);
ASSIGN_READ_MMIO_VFUNCS(gen9);
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915/gtt: Avoid calling kcalloc in a loop when allocating temp bitmaps
On Thu, Sep 03, 2015 at 07:22:18PM +0200, Michał Winiarski wrote: > + pts = kcalloc(pdpes * BITS_TO_LONGS(I915_PDES), > + sizeof(unsigned long), GFP_TEMPORARY); Something to remember is that kcalloc is written presuming that the size argument (the second) is constant. pts = kcalloc(pdpes, BITS_TO_LONGS(I915_PDES) * sizeof(unsigned long), GFP_TEMPORARY); should be infinitesimally more efficient. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Reduce frequency of unspecific HSW reg debugging
From: Chris Wilson
Delay the expensive read on the FPGA_DBG register from once per mmio to
once per forcewake section when we are doing the general wellbeing
check rather than the targetted error detection. This almost reduces
the overhead of the debug facility (for example when submitting execlists)
to zero whilst keeping the debug checks around.
v2: Enable one-shot mmio debugging from the interrupt check as well as a
safeguard to catch invalid display writes from outside the powerwell.
v3 (from Paulo): rebase since gen9 addition and intel_uncore_check_errors
removal
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Mika Kuoppala
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_uncore.c | 52 +
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 8844c314..1fe63fc 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -148,6 +148,31 @@ fw_domains_put(struct drm_i915_private *dev_priv, enum
forcewake_domains fw_doma
}
static void
+hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
+{
+ static bool mmio_debug_once = true;
+
+ if (i915.mmio_debug || !mmio_debug_once)
+ return;
+
+ if (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM) {
+ DRM_ERROR("Unclaimed register detected, "
+ "enabling oneshot unclaimed register reporting. "
+ "Please use i915.mmio_debug=N for more
information.\n");
+ __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
+ i915.mmio_debug = mmio_debug_once--;
+ }
+}
+
+static void
+fw_domains_put_debug(struct drm_i915_private *dev_priv,
+enum forcewake_domains fw_domains)
+{
+ hsw_unclaimed_reg_detect(dev_priv);
+ fw_domains_put(dev_priv, fw_domains);
+}
+
+static void
fw_domains_posting_read(struct drm_i915_private *dev_priv)
{
struct intel_uncore_forcewake_domain *d;
@@ -627,26 +652,6 @@ hsw_unclaimed_reg_debug(struct drm_i915_private *dev_priv,
u32 reg, bool read,
}
}
-static void
-hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv, u32 reg)
-{
- static bool mmio_debug_once = true;
-
- if (!UNCLAIMED_CHECK_RANGE(reg))
- return;
-
- if (i915.mmio_debug || !mmio_debug_once)
- return;
-
- if (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM) {
- DRM_ERROR("Unclaimed register detected, "
- "enabling oneshot unclaimed register reporting. "
- "Please use i915.mmio_debug=N for more
information.\n");
- __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
- i915.mmio_debug = mmio_debug_once--;
- }
-}
-
#define GEN2_READ_HEADER(x) \
u##x val = 0; \
assert_device_not_suspended(dev_priv);
@@ -900,7 +905,6 @@ hsw_write##x(struct drm_i915_private *dev_priv, off_t reg,
u##x val, bool trace)
gen6_gt_check_fifodbg(dev_priv); \
} \
hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
- hsw_unclaimed_reg_detect(dev_priv, reg); \
GEN6_WRITE_FOOTER; \
}
@@ -942,7 +946,6 @@ gen8_write##x(struct drm_i915_private *dev_priv, off_t reg,
u##x val, bool trace
__force_wake_get(dev_priv, FORCEWAKE_RENDER); \
__raw_i915_write##x(dev_priv, reg, val); \
hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
- hsw_unclaimed_reg_detect(dev_priv, reg); \
GEN6_WRITE_FOOTER; \
}
@@ -1008,7 +1011,6 @@ gen9_write##x(struct drm_i915_private *dev_priv, off_t
reg, u##x val, \
__force_wake_get(dev_priv, fw_engine); \
__raw_i915_write##x(dev_priv, reg, val); \
hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
- hsw_unclaimed_reg_detect(dev_priv, reg); \
GEN6_WRITE_FOOTER; \
}
@@ -1194,6 +1196,10 @@ static void intel_uncore_fw_domains_init(struct
drm_device *dev)
FORCEWAKE, FORCEWAKE_ACK);
}
+ if (HAS_FPGA_DBG_UNCLAIMED(dev) &&
+ dev_priv->uncore.funcs.force_wake_put == fw_domains_put)
+ dev_priv->uncore.funcs.force_wake_put = fw_domains_put_debug;
+
/* All future platforms are expected to require complex power gating */
WARN_ON(dev_priv->uncore.fw_domains == 0);
}
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Unclaimed register improvements
Hi Following the discussions between Chris and I, here are some updated patches for the unclaimed register subsystem. I still have some unanswered questions regarding patch 4, but I decided to rebase it on top of my work, just in case we decide to move forward with it. Thanks, Paulo Chris Wilson (1): drm/i915: Reduce frequency of unspecific HSW reg debugging Paulo Zanoni (3): drm/i915: make unclaimed register be errors again drm/i915: restrict unclaimed register checking drm/i915: remove intel_uncore_check_errors() drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_irq.c | 4 --- drivers/gpu/drm/i915/intel_uncore.c | 65 +++-- 3 files changed, 34 insertions(+), 36 deletions(-) -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: make unclaimed registers be errors again
Fixes an issue introduced by:
commit 48572edd9d736d6fabd40b810a0de844ee4f800b
Author: Chris Wilson
Date: Thu Dec 18 10:55:50 2014 +
drm/i915: Disable the mmio.debug WARN after it fires
Since the above commit, on the default use case - i915.mmio_debug=0 -,
whenever we detect a single access to an unclaimed register we will
print a DRM_DEBUG() message that is very likely to get ignored by
pretty much everybody, including PRTS and QA. Of course, we will
increment i915.mmio_debug, and then the next time a problem happens we
will print a big WARN(), but then if we never ever hit the same
problem again, the error will go unnoticed.
The case I imagine here is the following: we have a platform with no
unclaimed register errors happening, then someone submits a patch that
does just one wrong access (e.g., when loading the driver). That bad
register access gets noticed, we print DRM_DEBUG(), but then our QA
processes won't notice the problem until someone introduces a second
unclaimed register bug to trigger the WARN. We'll probably not even
get a bug report for that once the problem reaches the general
audience.
So what this patch does is to make sure we print an error message even
if we only ever detect a single unclaimed register problem in order to
not hide the possible bugs.
Cc: Chris Wilson
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index dec20d6..10c61a6 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -631,7 +631,7 @@ hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
return;
if (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM) {
- DRM_DEBUG("Unclaimed register detected, "
+ DRM_ERROR("Unclaimed register detected, "
"enabling oneshot unclaimed register reporting. "
"Please use i915.mmio_debug=N for more
information.\n");
__raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: remove intel_uncore_check_errors()
I added this code on 8664281b64c457705db72fc60143d03827e75ca9, on
April 12 2013. Back then, we only had support for detecting unclaimed
registers on I915_WRITE operations, and we didn't have the
i915.mmio_debug infrastructure.
I tried to remember exactly why I added this code, and the only reason
I can think is: to help debugging. With this code, we would be able to
differentiate between the "your interrupt handler did something wrong"
and the "something bad happened before the interrupt handler" cases,
at the cost of one extra register read operation per interrupt.
Since then, we added unclaimed register checking support for
I915_READ, we added the i915.mmio_debug infrastructure and we also
fixed most (all?) of the unclaimed register problems on HSW. Due
to this, I don't think the extra register read at every interrupt is
necesary anymore: we're probably good in terms of debugging.
So let's kill this function in order to make sure it completely
disappears from perf.
Notice that this only affects HSW.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_irq.c | 4
drivers/gpu/drm/i915/intel_uncore.c | 11 ---
3 files changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1287007..194e864 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2703,7 +2703,6 @@ extern void intel_uncore_sanitize(struct drm_device *dev);
extern void intel_uncore_early_sanitize(struct drm_device *dev,
bool restore_forcewake);
extern void intel_uncore_init(struct drm_device *dev);
-extern void intel_uncore_check_errors(struct drm_device *dev);
extern void intel_uncore_fini(struct drm_device *dev);
extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore);
const char *intel_uncore_forcewake_domain_to_str(const enum
forcewake_domain_id id);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2063279..57ec55e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2064,10 +2064,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
if (!intel_irqs_enabled(dev_priv))
return IRQ_NONE;
- /* We get interrupts on unclaimed registers, so check for this before we
-* do any I915_{READ,WRITE}. */
- intel_uncore_check_errors(dev);
-
/* disable master interrupt before clearing iir */
de_ier = I915_READ(DEIER);
I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 65e0ea8..8844c314 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1554,14 +1554,3 @@ bool intel_has_gpu_reset(struct drm_device *dev)
{
return intel_get_gpu_reset(dev) != NULL;
}
-
-void intel_uncore_check_errors(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
-
- if (HAS_FPGA_DBG_UNCLAIMED(dev) &&
- (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM)) {
- DRM_ERROR("Unclaimed register before interrupt\n");
- __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
- }
-}
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: restrict unclaimed register checking
The unclaimed register bit is only triggered when someone touches the
specified register range.
For the normal use case (with i915.mmio_debug=0), this commit will
avoid the extra __raw_i915_read32() call for every register outside
the specified range, at the expense of a few additional "if"
statements.
v2: Put the register range checking earlier (Chris).
Cc: Chris Wilson
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_uncore.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 10c61a6..65e0ea8 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -595,6 +595,8 @@ void assert_forcewakes_inactive(struct drm_i915_private
*dev_priv)
!FORCEWAKE_GEN9_MEDIA_RANGE_OFFSET(reg) && \
!FORCEWAKE_GEN9_COMMON_RANGE_OFFSET(reg))
+#define UNCLAIMED_CHECK_RANGE(reg) REG_RANGE(reg, 0x4, 0xC)
+
static void
ilk_dummy_write(struct drm_i915_private *dev_priv)
{
@@ -611,6 +613,9 @@ hsw_unclaimed_reg_debug(struct drm_i915_private *dev_priv,
u32 reg, bool read,
const char *op = read ? "reading" : "writing to";
const char *when = before ? "before" : "after";
+ if (!UNCLAIMED_CHECK_RANGE(reg))
+ return;
+
if (!i915.mmio_debug)
return;
@@ -623,10 +628,13 @@ hsw_unclaimed_reg_debug(struct drm_i915_private
*dev_priv, u32 reg, bool read,
}
static void
-hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
+hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv, u32 reg)
{
static bool mmio_debug_once = true;
+ if (!UNCLAIMED_CHECK_RANGE(reg))
+ return;
+
if (i915.mmio_debug || !mmio_debug_once)
return;
@@ -892,7 +900,7 @@ hsw_write##x(struct drm_i915_private *dev_priv, off_t reg,
u##x val, bool trace)
gen6_gt_check_fifodbg(dev_priv); \
} \
hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
- hsw_unclaimed_reg_detect(dev_priv); \
+ hsw_unclaimed_reg_detect(dev_priv, reg); \
GEN6_WRITE_FOOTER; \
}
@@ -934,7 +942,7 @@ gen8_write##x(struct drm_i915_private *dev_priv, off_t reg,
u##x val, bool trace
__force_wake_get(dev_priv, FORCEWAKE_RENDER); \
__raw_i915_write##x(dev_priv, reg, val); \
hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
- hsw_unclaimed_reg_detect(dev_priv); \
+ hsw_unclaimed_reg_detect(dev_priv, reg); \
GEN6_WRITE_FOOTER; \
}
@@ -1000,7 +1008,7 @@ gen9_write##x(struct drm_i915_private *dev_priv, off_t
reg, u##x val, \
__force_wake_get(dev_priv, fw_engine); \
__raw_i915_write##x(dev_priv, reg, val); \
hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
- hsw_unclaimed_reg_detect(dev_priv); \
+ hsw_unclaimed_reg_detect(dev_priv, reg); \
GEN6_WRITE_FOOTER; \
}
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/14] drm/i915: Reject 'Center' scaling mode for eDP/DSI on GMCH platforms
From: Ville Syrjälä
We don't have a LVDS_BORDER_ENABLE type of bit for either eDP or DSI,
and just trying to frob the display timings to include borders results
in a corrupted picture. So reject the 'Center' scaling mode on GMCH
platforms for eDP and DSI.
TODO: Should really filter out the unsupported modes from the prop,
but that would be fairly invasive since the prop is now created and
stored by drm core. So leave it for a rainy day.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
drivers/gpu/drm/i915/intel_dsi.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f8f4d99..7e251b4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4981,6 +4981,11 @@ intel_dp_set_property(struct drm_connector *connector,
DRM_DEBUG_KMS("no scaling not supported\n");
return -EINVAL;
}
+ if (HAS_GMCH_DISPLAY(dev_priv) &&
+ val == DRM_MODE_SCALE_CENTER) {
+ DRM_DEBUG_KMS("centering not supported\n");
+ return -EINVAL;
+ }
if (intel_connector->panel.fitting_mode == val) {
/* the eDP scaling property is not changed */
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 8977ee3..a2f29b1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -968,6 +968,11 @@ static int intel_dsi_set_property(struct drm_connector
*connector,
DRM_DEBUG_KMS("no scaling not supported\n");
return -EINVAL;
}
+ if (HAS_GMCH_DISPLAY(dev) &&
+ val == DRM_MODE_SCALE_CENTER) {
+ DRM_DEBUG_KMS("centering not supported\n");
+ return -EINVAL;
+ }
if (intel_connector->panel.fitting_mode == val)
return 0;
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/14] drm/i915: Compute DSI PLL parameters during .compute_config()
From: Ville Syrjälä
Compute the DSI PLL parameters during .compute_config() rather than
.pre_pll_enable() so that we can fail gracefully if we can't find
suitable parameters.
In order to do that we need to store the DSI PLL parameters in
pipe_config.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 3 ++
drivers/gpu/drm/i915/intel_drv.h | 5
drivers/gpu/drm/i915/intel_dsi.c | 16 +++
drivers/gpu/drm/i915/intel_dsi.h | 8 --
drivers/gpu/drm/i915/intel_dsi_pll.c | 56 +---
5 files changed, 57 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1ec39b0..9a77ca5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12488,6 +12488,9 @@ intel_pipe_config_compare(struct drm_device *dev,
PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr1);
PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr2);
+ PIPE_CONF_CHECK_X(dsi_pll.ctrl);
+ PIPE_CONF_CHECK_X(dsi_pll.div);
+
if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5)
PIPE_CONF_CHECK_I(pipe_bpp);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cf971ef..8bb74eb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -407,6 +407,11 @@ struct intel_crtc_state {
/* Actual register state of the dpll, for shared dpll cross-checking. */
struct intel_dpll_hw_state dpll_hw_state;
+ /* DSI PLL registers */
+ struct {
+ u32 ctrl, div;
+ } dsi_pll;
+
int pipe_bpp;
struct intel_link_m_n dp_m_n;
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index e0ccaf1..4cf6c0d 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -270,6 +270,7 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
struct intel_connector *intel_connector = intel_dsi->attached_connector;
struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
struct drm_display_mode *adjusted_mode = &config->base.adjusted_mode;
+ int ret;
DRM_DEBUG_KMS("\n");
@@ -279,10 +280,10 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
/* DSI uses short packets for sync events, so clear mode flags for DSI
*/
adjusted_mode->flags = 0;
- /*
-* FIXME move the DSI PLL calc from vlv_enable_dsi_pll()
-* to .compute_config().
-*/
+ ret = vlv_compute_dsi_pll(encoder, config);
+ if (ret)
+ return false;
+
config->clock_set = true;
return true;
@@ -629,7 +630,8 @@ static void intel_dsi_get_config(struct intel_encoder
*encoder,
u32 pclk;
DRM_DEBUG_KMS("\n");
- pclk = vlv_get_dsi_pclk(encoder, pipe_config->pipe_bpp);
+ pclk = vlv_get_dsi_pclk(encoder, pipe_config->pipe_bpp,
+ pipe_config);
if (!pclk)
return;
@@ -900,6 +902,8 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
static void intel_dsi_pre_pll_enable(struct intel_encoder *encoder)
{
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+
DRM_DEBUG_KMS("\n");
intel_dsi_prepare(encoder);
@@ -909,7 +913,7 @@ static void intel_dsi_pre_pll_enable(struct intel_encoder
*encoder)
* lock. It needs to be fully powered down to fix it.
*/
vlv_disable_dsi_pll(encoder);
- vlv_enable_dsi_pll(encoder);
+ vlv_enable_dsi_pll(encoder, intel_crtc->config);
}
static enum drm_connector_status
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 42a6859..58c39b4 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -124,9 +124,13 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
return container_of(encoder, struct intel_dsi, base.base);
}
-extern void vlv_enable_dsi_pll(struct intel_encoder *encoder);
+extern int vlv_compute_dsi_pll(struct intel_encoder *encoder,
+ struct intel_crtc_state *config);
+extern void vlv_enable_dsi_pll(struct intel_encoder *encoder,
+ const struct intel_crtc_state *config);
extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
-extern u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
+extern u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp,
+ struct intel_crtc_state *config);
struct drm_panel *vbt_panel_init(struct intel_dsi *intel_dsi, u16 panel_id);
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index c6a8975..79c18a0 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i
[Intel-gfx] [PATCH 12/14] drm/i915: Hook up pfit for DSI
From: Ville Syrjälä
Add the scaling mode property to DSI connectors, handle changes in the
property value, and compute the panel fitter state during
.compute_config().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dsi.c | 69 +---
1 file changed, 64 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 4cf6c0d..8977ee3 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -268,15 +268,20 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
base);
struct intel_connector *intel_connector = intel_dsi->attached_connector;
- struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
+ struct intel_crtc *crtc = to_intel_crtc(config->base.crtc);
+ const struct drm_display_mode *fixed_mode =
intel_connector->panel.fixed_mode;
struct drm_display_mode *adjusted_mode = &config->base.adjusted_mode;
int ret;
DRM_DEBUG_KMS("\n");
- if (fixed_mode)
+ if (fixed_mode) {
intel_fixed_panel_mode(fixed_mode, adjusted_mode);
+ intel_gmch_panel_fitting(crtc, config,
+intel_connector->panel.fitting_mode);
+ }
+
/* DSI uses short packets for sync events, so clear mode flags for DSI
*/
adjusted_mode->flags = 0;
@@ -644,7 +649,7 @@ intel_dsi_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
- struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
+ const struct drm_display_mode *fixed_mode =
intel_connector->panel.fixed_mode;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
DRM_DEBUG_KMS("\n");
@@ -945,6 +950,43 @@ static int intel_dsi_get_modes(struct drm_connector
*connector)
return 1;
}
+static int intel_dsi_set_property(struct drm_connector *connector,
+ struct drm_property *property,
+ uint64_t val)
+{
+ struct drm_device *dev = connector->dev;
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct drm_crtc *crtc;
+ int ret;
+
+ ret = drm_object_property_set_value(&connector->base, property, val);
+ if (ret)
+ return ret;
+
+ if (property == dev->mode_config.scaling_mode_property) {
+ if (val == DRM_MODE_SCALE_NONE) {
+ DRM_DEBUG_KMS("no scaling not supported\n");
+ return -EINVAL;
+ }
+
+ if (intel_connector->panel.fitting_mode == val)
+ return 0;
+
+ intel_connector->panel.fitting_mode = val;
+ }
+
+ crtc = intel_attached_encoder(connector)->base.crtc;
+ if (crtc && crtc->state->enable) {
+ /*
+* If the CRTC is enabled, the display will be changed
+* according to the new panel fitting mode.
+*/
+ intel_crtc_restore_mode(crtc);
+ }
+
+ return 0;
+}
+
static void intel_dsi_connector_destroy(struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -987,11 +1029,25 @@ static const struct drm_connector_funcs
intel_dsi_connector_funcs = {
.detect = intel_dsi_detect,
.destroy = intel_dsi_connector_destroy,
.fill_modes = drm_helper_probe_single_connector_modes,
+ .set_property = intel_dsi_set_property,
.atomic_get_property = intel_connector_atomic_get_property,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
};
+static void intel_dsi_add_properties(struct intel_connector *connector)
+{
+ struct drm_device *dev = connector->base.dev;
+
+ if (connector->panel.fixed_mode) {
+ drm_mode_create_scaling_mode_property(dev);
+ drm_object_attach_property(&connector->base.base,
+
dev->mode_config.scaling_mode_property,
+ DRM_MODE_SCALE_ASPECT);
+ connector->panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
+ }
+}
+
void intel_dsi_init(struct drm_device *dev)
{
struct intel_dsi *intel_dsi;
@@ -,8 +1167,6 @@ void intel_dsi_init(struct drm_device *dev)
intel_connector_attach_encoder(intel_connector, intel_encoder);
- drm_connector_register(connector);
-
drm_panel_attach(intel_dsi->panel, connector);
mutex_lock(&dev->mod
[Intel-gfx] [PATCH 03/14] drm/i915: Power down the DSI PLL before reconfiguring it
From: Ville Syrjälä The BIOS may leave the DSI PLL enabled in some wonky state where it just refuses to lock. Simply disabling the PLL before reconfiguring it is not enough to fix it, but power gating the PLL prior to reconfiguring does work. This happens on BYT FFRD8 when booting with HDMI connected so the DSI display will not be lit up by the BIOS. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dsi.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 781c267..8c9f1c5 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -915,6 +915,11 @@ static void intel_dsi_pre_pll_enable(struct intel_encoder *encoder) intel_dsi_prepare(encoder); + /* +* The BIOS may leave the PLL in a wonky state where it doesn't +* lock. It needs to be fully powered down to fix it. +*/ + vlv_disable_dsi_pll(encoder); vlv_enable_dsi_pll(encoder); } -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/14] drm/i915: Dump pfit state as hex
From: Ville Syrjälä
The pfit state is stored as register values, so dump them as hex instead
of decimal to make some sense of the error messages.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2776974..4aab8f4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12442,16 +12442,16 @@ intel_pipe_config_compare(struct drm_device *dev,
PIPE_CONF_CHECK_I(pipe_src_w);
PIPE_CONF_CHECK_I(pipe_src_h);
- PIPE_CONF_CHECK_I(gmch_pfit.control);
+ PIPE_CONF_CHECK_X(gmch_pfit.control);
/* pfit ratios are autocomputed by the hw on gen4+ */
if (INTEL_INFO(dev)->gen < 4)
PIPE_CONF_CHECK_I(gmch_pfit.pgm_ratios);
- PIPE_CONF_CHECK_I(gmch_pfit.lvds_border_bits);
+ PIPE_CONF_CHECK_X(gmch_pfit.lvds_border_bits);
PIPE_CONF_CHECK_I(pch_pfit.enabled);
if (current_config->pch_pfit.enabled) {
- PIPE_CONF_CHECK_I(pch_pfit.pos);
- PIPE_CONF_CHECK_I(pch_pfit.size);
+ PIPE_CONF_CHECK_X(pch_pfit.pos);
+ PIPE_CONF_CHECK_X(pch_pfit.size);
}
PIPE_CONF_CHECK_I(scaler_state.scaler_id);
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/14] drm/i915: Fix CHV DSI PLL refclk during state readout
From: Ville Syrjälä
Use the proper refclock frequency (100MHz) when reading out the
current DSI clock on CHV.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 79c18a0..19bebd8 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -316,7 +316,7 @@ u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int
pipe_bpp,
u32 dsi_clock, pclk;
u32 pll_ctl, pll_div;
u32 m = 0, p = 0, n;
- int refclk = 25000;
+ int refclk = IS_CHERRYVIEW(dev_priv) ? 10 : 25000;
int i;
DRM_DEBUG_KMS("\n");
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/14] drm/i915: Throw out BUGs from DPLL/PCH functions
From: Ville Syrjälä
These BUGs don't serve any purpose IMO. Throw them out.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9a77ca5..2776974 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1592,9 +1592,6 @@ static void vlv_enable_pll(struct intel_crtc *crtc,
assert_pipe_disabled(dev_priv, pipe);
- /* No really, not for ILK+ */
- BUG_ON(!IS_VALLEYVIEW(dev_priv->dev));
-
/* PLL is protected by panel, make sure we can write it */
assert_panel_unlocked(dev_priv, pipe);
@@ -1644,8 +1641,6 @@ static void chv_enable_pll(struct intel_crtc *crtc,
assert_pipe_disabled(dev_priv, pipe);
- BUG_ON(!IS_CHERRYVIEW(dev_priv->dev));
-
/* PLL is protected by panel, make sure we can write it */
assert_panel_unlocked(dev_priv, pipe);
@@ -1696,9 +1691,6 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
assert_pipe_disabled(dev_priv, crtc->pipe);
- /* No really, not for ILK+ */
- BUG_ON(INTEL_INFO(dev)->gen >= 5);
-
/* PLL is protected by panel, make sure we can write it */
if (IS_MOBILE(dev) && !IS_I830(dev))
assert_panel_unlocked(dev_priv, crtc->pipe);
@@ -1955,9 +1947,6 @@ static void ironlake_enable_pch_transcoder(struct
drm_i915_private *dev_priv,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
uint32_t reg, val, pipeconf_val;
- /* PCH only available on ILK+ */
- BUG_ON(!HAS_PCH_SPLIT(dev));
-
/* Make sure PCH DPLL is enabled */
assert_shared_dpll_enabled(dev_priv,
intel_crtc_to_shared_dpll(intel_crtc));
@@ -2012,9 +2001,6 @@ static void lpt_enable_pch_transcoder(struct
drm_i915_private *dev_priv,
{
u32 val, pipeconf_val;
- /* PCH only available on ILK+ */
- BUG_ON(!HAS_PCH_SPLIT(dev_priv->dev));
-
/* FDI must be feeding us bits for PCH ports */
assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder);
assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/14] drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV
From: Ville Syrjälä
Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While
the DPLL isn't used to provide the clock we still need the refclock, and
it appears that the pixel repeat factor also has an effect on DSI
output. So set up eveyrhing in DPLL and DPLL_MD as we would do for
DP/HDMI/VGA, but don't actually enable the DPLL or configure the
dividers via DPIO.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 136 +++
drivers/gpu/drm/i915/intel_dsi.c | 25 ++-
2 files changed, 82 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b33450f..1ec39b0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1570,14 +1570,25 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMID);
}
+static void _vlv_enable_pll(struct intel_crtc *crtc,
+ const struct intel_crtc_state *pipe_config)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ I915_WRITE(DPLL(pipe), pipe_config->dpll_hw_state.dpll);
+ POSTING_READ(DPLL(pipe));
+ udelay(150);
+
+ if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) ==
DPLL_LOCK_VLV), 1))
+ DRM_ERROR("DPLL %d failed to lock\n", pipe);
+}
+
static void vlv_enable_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config)
{
- struct drm_device *dev = crtc->base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
- int reg = DPLL(pipe);
- u32 dpll = pipe_config->dpll_hw_state.dpll;
assert_pipe_disabled(dev_priv, pipe);
@@ -1587,33 +1598,22 @@ static void vlv_enable_pll(struct intel_crtc *crtc,
/* PLL is protected by panel, make sure we can write it */
assert_panel_unlocked(dev_priv, pipe);
- I915_WRITE(reg, dpll);
- POSTING_READ(reg);
- udelay(150);
-
- if (wait_for(((I915_READ(reg) & DPLL_LOCK_VLV) == DPLL_LOCK_VLV), 1))
- DRM_ERROR("DPLL %d failed to lock\n", pipe);
+ if (pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE)
+ _vlv_enable_pll(crtc, pipe_config);
I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
POSTING_READ(DPLL_MD(pipe));
}
-static void chv_enable_pll(struct intel_crtc *crtc,
- const struct intel_crtc_state *pipe_config)
+
+static void _chv_enable_pll(struct intel_crtc *crtc,
+ const struct intel_crtc_state *pipe_config)
{
- struct drm_device *dev = crtc->base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
enum dpio_channel port = vlv_pipe_to_channel(pipe);
u32 tmp;
- assert_pipe_disabled(dev_priv, crtc->pipe);
-
- BUG_ON(!IS_CHERRYVIEW(dev_priv->dev));
-
- /* PLL is protected by panel, make sure we can write it */
- assert_panel_unlocked(dev_priv, pipe);
-
mutex_lock(&dev_priv->sb_lock);
/* Enable back the 10bit clock to display controller */
@@ -1634,6 +1634,23 @@ static void chv_enable_pll(struct intel_crtc *crtc,
/* Check PLL is locked */
if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) ==
DPLL_LOCK_VLV), 1))
DRM_ERROR("PLL %d failed to lock\n", pipe);
+}
+
+static void chv_enable_pll(struct intel_crtc *crtc,
+ const struct intel_crtc_state *pipe_config)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ assert_pipe_disabled(dev_priv, pipe);
+
+ BUG_ON(!IS_CHERRYVIEW(dev_priv->dev));
+
+ /* PLL is protected by panel, make sure we can write it */
+ assert_panel_unlocked(dev_priv, pipe);
+
+ if (pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE)
+ _chv_enable_pll(crtc, pipe_config);
if (pipe != PIPE_A) {
/*
@@ -6006,14 +6023,11 @@ static void valleyview_crtc_enable(struct drm_crtc
*crtc)
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *encoder;
- int pipe = intel_crtc->pipe;
- bool is_dsi;
+ enum pipe pipe = intel_crtc->pipe;
if (WARN_ON(intel_crtc->active))
return;
- is_dsi = intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DSI);
-
if (intel_crtc->config->has_dp_encoder)
intel_dp_set_m_n(intel_crtc, M1_N1);
@@ -6036,14 +6050,12 @@ static void valleyview_crtc_enable(stru
[Intel-gfx] [PATCH 06/14] drm/i915: Remove the "three times for luck" trick from vlv_enable_pll()
From: Ville Syrjälä VLV DPLL is sane and doesn't run on luck. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index bddc17f..b33450f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1596,17 +1596,6 @@ static void vlv_enable_pll(struct intel_crtc *crtc, I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md); POSTING_READ(DPLL_MD(pipe)); - - /* We do this three times for luck */ - I915_WRITE(reg, dpll); - POSTING_READ(reg); - udelay(150); /* wait for warmup */ - I915_WRITE(reg, dpll); - POSTING_READ(reg); - udelay(150); /* wait for warmup */ - I915_WRITE(reg, dpll); - POSTING_READ(reg); - udelay(150); /* wait for warmup */ } static void chv_enable_pll(struct intel_crtc *crtc, -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/14] drm/i915: Change lfsr_converts[] to u16
From: Ville Syrjälä
All the values in the DSI PLL LFSR seed table fit into 9bits, so change
the type to u16 from u32 to save a bit of space.
drivers/gpu/drm/i915/i915.ko:
-.rodata90824
+.rodata90760
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 19bebd8..2331b34 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -60,7 +60,7 @@ static int dsi_pixel_format_bpp(int pixel_format)
}
-static const u32 lfsr_converts[] = {
+static const u16 lfsr_converts[] = {
426, 469, 234, 373, 442, 221, 110, 311, 411,/* 62 - 70 */
461, 486, 243, 377, 188, 350, 175, 343, 427, 213, /* 71 - 80 */
106, 53, 282, 397, 454, 227, 113, 56, 284, 142, /* 81 - 90 */
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/14] drm/i915: assert_panel_unlocked() in chv_enable_pll()
From: Ville Syrjälä Supposedly the power sequencer still locks out the DPLL registers on CHV, so let's issue a warning if it's still locked when enabling the DPLL. Also drop the redundant IS_MOBILE() check for VLV when we check the same thing. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 13bcc81..bddc17f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1585,8 +1585,7 @@ static void vlv_enable_pll(struct intel_crtc *crtc, BUG_ON(!IS_VALLEYVIEW(dev_priv->dev)); /* PLL is protected by panel, make sure we can write it */ - if (IS_MOBILE(dev_priv->dev)) - assert_panel_unlocked(dev_priv, pipe); + assert_panel_unlocked(dev_priv, pipe); I915_WRITE(reg, dpll); POSTING_READ(reg); @@ -1623,6 +1622,9 @@ static void chv_enable_pll(struct intel_crtc *crtc, BUG_ON(!IS_CHERRYVIEW(dev_priv->dev)); + /* PLL is protected by panel, make sure we can write it */ + assert_panel_unlocked(dev_priv, pipe); + mutex_lock(&dev_priv->sb_lock); /* Enable back the 10bit clock to display controller */ -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/14] drm/i915: Add a local pipe variable to vlv_enable_pll()
From: Ville Syrjälä
Avoid redundant crtc->pipe lookups by giving vlv_enable_pll() a local
pipe variable. Also makes it look more like the corresponding CHV code.
While at is change the CHV code to enum pipe from int,
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d805d99..13bcc81 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1575,27 +1575,28 @@ static void vlv_enable_pll(struct intel_crtc *crtc,
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- int reg = DPLL(crtc->pipe);
+ enum pipe pipe = crtc->pipe;
+ int reg = DPLL(pipe);
u32 dpll = pipe_config->dpll_hw_state.dpll;
- assert_pipe_disabled(dev_priv, crtc->pipe);
+ assert_pipe_disabled(dev_priv, pipe);
/* No really, not for ILK+ */
BUG_ON(!IS_VALLEYVIEW(dev_priv->dev));
/* PLL is protected by panel, make sure we can write it */
if (IS_MOBILE(dev_priv->dev))
- assert_panel_unlocked(dev_priv, crtc->pipe);
+ assert_panel_unlocked(dev_priv, pipe);
I915_WRITE(reg, dpll);
POSTING_READ(reg);
udelay(150);
if (wait_for(((I915_READ(reg) & DPLL_LOCK_VLV) == DPLL_LOCK_VLV), 1))
- DRM_ERROR("DPLL %d failed to lock\n", crtc->pipe);
+ DRM_ERROR("DPLL %d failed to lock\n", pipe);
- I915_WRITE(DPLL_MD(crtc->pipe), pipe_config->dpll_hw_state.dpll_md);
- POSTING_READ(DPLL_MD(crtc->pipe));
+ I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
+ POSTING_READ(DPLL_MD(pipe));
/* We do this three times for luck */
I915_WRITE(reg, dpll);
@@ -1614,7 +1615,7 @@ static void chv_enable_pll(struct intel_crtc *crtc,
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- int pipe = crtc->pipe;
+ enum pipe pipe = crtc->pipe;
enum dpio_channel port = vlv_pipe_to_channel(pipe);
u32 tmp;
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/14] drm/i915: Implement WaPixelRepeatModeFixForC0:chv
From: Ville Syrjälä
DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added
chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B)
to either pipe B or C. So do that to make pixel repeat work on pipes
B and C. Pipe A is fine without any tricks.
Fortunately the pixel repeat propagation appears to be a oneshot
operation, so once the value has been written we can clear the
chicken bits. So it is still possible to drive pipe B and C with
different pixel multipliers simultaneosly.
Looks like DPLL_VGA_MODE_DIS must also be set in DPLL(PIPE_B)
for this to work. But since we keep that bit always set in all
DPLLs there's no problem.
This of course means we can't reliably read out the pixel multiplier
for pipes B and C. That would make the state checker unhappy, so I
added shadow copies of those registers in to dev_priv. The other
option would have been to skip pixel multiplier, dpll_md an dotclock
checks entirely on CHV, but that feels like a serious loss of cross
checking, so just pretending that we have working DPLL MD registers
seemed better. Obviously with the shadow copies we can't detect if
the pixel multiplier was properly configured, nor can we take over
its state from the BIOS, but hopefully people won't have displays
that would be limitd to such crappy modes.
There is one strange flicker still remaining. It's visible on
pipe C/HDMID when HDMIB is enabled while driven by pipe B.
It doesn't occur if pipe A drives HDMIB, nor is there any glitch
on pipe B/HDMIB when port C/HDMID starts up. I don't have a board
with HDMIC so not sure if it happens there too. So I'm not sure
if it's somehow tied in with this strange linkage between pipe B
and C. Sadly I was unable to find an enable sequence that would
avoid the glitch, but at least it's not fatal ie. the output
recovers afterwards.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 30 ++
3 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1287007..b45e10e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1900,7 +1900,14 @@ struct drm_i915_private {
u32 fdi_rx_config;
+ /* Shadow for DISPLAY_PHY_CONTROL which can't be safely read */
u32 chv_phy_control;
+ /*
+* Shadows for CHV DPLL_MD regs to keep the state
+* checker somewhat working in the presence hardware
+* crappiness (can't read out DPLL_MD for pipes B & C).
+*/
+ u32 chv_dpll_md[I915_MAX_PIPES];
u32 suspend_count;
struct i915_suspend_saved_registers regfile;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 84ed9ab..fbf8ce5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4648,6 +4648,9 @@ enum skl_disp_power_wells {
#define CBR1_VLV (VLV_DISPLAY_BASE + 0x70400)
#define CBR_PND_DEADLINE_DISABLE (1<<31)
+#define CBR4_VLV (VLV_DISPLAY_BASE + 0x70450)
+#define CBR_DPLLBMD_PIPE_C(1<<29)
+#define CBR_DPLLBMD_PIPE_B(1<<18)
/* FIFO watermark sizes etc */
#define G4X_FIFO_LINE_SIZE 64
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d31b109..d805d99 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1643,9 +1643,27 @@ static void chv_enable_pll(struct intel_crtc *crtc,
if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) ==
DPLL_LOCK_VLV), 1))
DRM_ERROR("PLL %d failed to lock\n", pipe);
- /* not sure when this should be written */
- I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
- POSTING_READ(DPLL_MD(pipe));
+ if (pipe != PIPE_A) {
+ /*
+* WaPixelRepeatModeFixForC0:chv
+*
+* DPLLCMD is AWOL. Use chicken bits to propagate
+* the value from DPLLBMD to either pipe B or C.
+*/
+ I915_WRITE(CBR4_VLV, pipe == PIPE_B ? CBR_DPLLBMD_PIPE_B :
CBR_DPLLBMD_PIPE_C);
+ I915_WRITE(DPLL_MD(PIPE_B), pipe_config->dpll_hw_state.dpll_md);
+ I915_WRITE(CBR4_VLV, 0);
+ dev_priv->chv_dpll_md[pipe] =
pipe_config->dpll_hw_state.dpll_md;
+
+ /*
+* DPLLB VGA mode also seems to cause problems.
+* We should always have it disabled.
+*/
+ WARN_ON((I915_READ(DPLL(PIPE_B)) & DPLL_VGA_MODE_DIS) == 0);
+ } else {
+ I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
+ POSTING_READ(DPLL_MD(pipe));
+ }
}
static int intel_num_dvo_pipes(struct drm_device *dev)
@@ -8035,7 +80
[Intel-gfx] [PATCH v2 01/14] drm/i915: Make {vlv, chv}_{disable, update}_pll() more similar
From: Ville Syrjälä
The VLV and CHV DPLL disable and update are almost identical in
how the DPLL/DPLL_MD registers need to be set up. But the code
looks more different than it really is. Try to bring them into
line.
v2: s/chv_update_pll/chv_compute_dpll/
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 63 ++--
1 file changed, 25 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0377520..d31b109 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1761,16 +1761,13 @@ static void vlv_disable_pll(struct drm_i915_private
*dev_priv, enum pipe pipe)
/* Make sure the pipe isn't still relying on us */
assert_pipe_disabled(dev_priv, pipe);
- /*
-* Leave integrated clock source and reference clock enabled for pipe B.
-* The latter is needed for VGA hotplug / manual detection.
-*/
- val = DPLL_VGA_MODE_DIS;
- if (pipe == PIPE_B)
- val = DPLL_INTEGRATED_CRI_CLK_VLV | DPLL_REF_CLK_ENABLE_VLV;
+ val = DPLL_INTEGRATED_REF_CLK_VLV |
+ DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
+ if (pipe != PIPE_A)
+ val |= DPLL_INTEGRATED_CRI_CLK_VLV;
+
I915_WRITE(DPLL(pipe), val);
POSTING_READ(DPLL(pipe));
-
}
static void chv_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
@@ -1781,11 +1778,11 @@ static void chv_disable_pll(struct drm_i915_private
*dev_priv, enum pipe pipe)
/* Make sure the pipe isn't still relying on us */
assert_pipe_disabled(dev_priv, pipe);
- /* Set PLL en = 0 */
val = DPLL_SSC_REF_CLK_CHV |
DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
if (pipe != PIPE_A)
val |= DPLL_INTEGRATED_CRI_CLK_VLV;
+
I915_WRITE(DPLL(pipe), val);
POSTING_READ(DPLL(pipe));
@@ -7178,24 +7175,27 @@ void intel_dp_set_m_n(struct intel_crtc *crtc, enum
link_m_n_set m_n)
static void vlv_compute_dpll(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config)
{
- u32 dpll, dpll_md;
+ pipe_config->dpll_hw_state.dpll = DPLL_INTEGRATED_REF_CLK_VLV |
+ DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS |
+ DPLL_VCO_ENABLE | DPLL_EXT_BUFFER_ENABLE_VLV;
+ if (crtc->pipe != PIPE_A)
+ pipe_config->dpll_hw_state.dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
- /*
-* Enable DPIO clock input. We should never disable the reference
-* clock for pipe B, since VGA hotplug / manual detection depends
-* on it.
-*/
- dpll = DPLL_EXT_BUFFER_ENABLE_VLV | DPLL_REF_CLK_ENABLE_VLV |
- DPLL_VGA_MODE_DIS | DPLL_INTEGRATED_REF_CLK_VLV;
- /* We should never disable this, set it here for state tracking */
- if (crtc->pipe == PIPE_B)
- dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
- dpll |= DPLL_VCO_ENABLE;
- pipe_config->dpll_hw_state.dpll = dpll;
+ pipe_config->dpll_hw_state.dpll_md =
+ (pipe_config->pixel_multiplier - 1) <<
DPLL_MD_UDI_MULTIPLIER_SHIFT;
+}
+
+static void chv_compute_dpll(struct intel_crtc *crtc,
+struct intel_crtc_state *pipe_config)
+{
+ pipe_config->dpll_hw_state.dpll = DPLL_SSC_REF_CLK_CHV |
+ DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS |
+ DPLL_VCO_ENABLE;
+ if (crtc->pipe != PIPE_A)
+ pipe_config->dpll_hw_state.dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
- dpll_md = (pipe_config->pixel_multiplier - 1)
- << DPLL_MD_UDI_MULTIPLIER_SHIFT;
- pipe_config->dpll_hw_state.dpll_md = dpll_md;
+ pipe_config->dpll_hw_state.dpll_md =
+ (pipe_config->pixel_multiplier - 1) <<
DPLL_MD_UDI_MULTIPLIER_SHIFT;
}
static void vlv_prepare_pll(struct intel_crtc *crtc,
@@ -7289,19 +7289,6 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
mutex_unlock(&dev_priv->sb_lock);
}
-static void chv_compute_dpll(struct intel_crtc *crtc,
-struct intel_crtc_state *pipe_config)
-{
- pipe_config->dpll_hw_state.dpll = DPLL_SSC_REF_CLK_CHV |
- DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS |
- DPLL_VCO_ENABLE;
- if (crtc->pipe != PIPE_A)
- pipe_config->dpll_hw_state.dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
-
- pipe_config->dpll_hw_state.dpll_md =
- (pipe_config->pixel_multiplier - 1) <<
DPLL_MD_UDI_MULTIPLIER_SHIFT;
-}
-
static void chv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config)
{
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/14] drm/i915: VLV/CHV DPLL and DSI stuff
From: Ville Syrjälä
As my previous half assed attempt [1] avoiding state checker warnings
for VLV/CHV DSI output shot down during review, I decided to actually
figure out what's the relationship between DSI and the DPLL registers.
Turns out there is one, so this series aims to make things robust by
properly programming the DPLL/DPLL_MD registers when driving DSI
outputs.
I've included the other stragglers from my last DPLL series, mainly
dealing with WaPixelRepeatModeFixForC0.
I also got annoyed by DSI not setting up the panel fitter, so I
plugged that in as well.
Series available at:
git://github.com/vsyrjala/linux.git vlv_chv_dsi_dpll
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-June/070040.html
Ville Syrjälä (14):
drm/i915: Make {vlv,chv}_{disable,update}_pll() more similar
drm/i915: Implement WaPixelRepeatModeFixForC0:chv
drm/i915: Power down the DSI PLL before reconfiguring it
drm/i915: Add a local pipe variable to vlv_enable_pll()
drm/i915: assert_panel_unlocked() in chv_enable_pll()
drm/i915: Remove the "three times for luck" trick from
vlv_enable_pll()
drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV
drm/i915: Compute DSI PLL parameters during .compute_config()
drm/i915: Fix CHV DSI PLL refclk during state readout
drm/i915: Change lfsr_converts[] to u16
drm/i915: Throw out BUGs from DPLL/PCH functions
drm/i915: Hook up pfit for DSI
drm/i915: Reject 'Center' scaling mode for eDP/DSI on GMCH platforms
drm/i915: Dump pfit state as hex
drivers/gpu/drm/i915/i915_drv.h | 7 +
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_display.c | 262 ++-
drivers/gpu/drm/i915/intel_dp.c | 5 +
drivers/gpu/drm/i915/intel_drv.h | 5 +
drivers/gpu/drm/i915/intel_dsi.c | 112 +++
drivers/gpu/drm/i915/intel_dsi.h | 8 +-
drivers/gpu/drm/i915/intel_dsi_pll.c | 60
8 files changed, 281 insertions(+), 181 deletions(-)
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/2] Adding kms_nv12 to test display NV12 feature
> > > > + > > > > + /* redo AddFB */ > > > > + memset(&f, 0, sizeof(f)); > > > > + > > > > + f.width = d->fb1_nv12.width; > > > > + f.height = d->fb1_nv12.height; > > > > + f.pixel_format = d->fb1_nv12.drm_format; > > > > + f.flags = LOCAL_DRM_MODE_FB_MODIFIERS; > > > > + f.handles[0] = d->fb1_nv12.gem_handle; > > > > + f.pitches[0] = d->fb1_nv12.stride; > > > > + f.modifier[0] = LOCAL_I915_FORMAT_MOD_Yf_TILED; > > > > + f.modifier[1] = LOCAL_I915_FORMAT_MOD_Yf_TILED; > > > > + > > > > + /* test invalid uv start */ > > > > + f.handles[1] = d->fb1_nv12.gem_handle; > > > > + f.pitches[1] = d->fb1_nv12.stride; > > > > + f.offsets[1] = 0; /* invalid uv start */ > > > > + igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, > > > &f) != 0); > > > > > > For such simple invalid input paramaters tests the usual approach is to > > > split them out. Also you don't have to do a modeset for addfb (which will > > > speed things up). Essentially each block with an igt_assert should be its > > > own subtest. > > > -Daniel > > > > > > > If each block is split into it's own subtest, if one runs just a subtest > > and without a modeset, I don't know in which state the system is to start > > the test and doing a modeset will start with a known state. > > ADDFB ioctl doesn't need any known modeset state at all, and that seems to > be the only ioctl you do. Which means you really don't need to do a > modeset (it's just overhead). See e.g. the other addfb testcases we have > in kms_addfb_basic.c. > -Daniel I see your point. will check on that and make any necessary updates. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Wednesday, September 02, 2015 1:02 AM
> To: Konduru, Chandra
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Vetter, Daniel; Syrjala,
> Ville
> Subject: Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds
>
> On Thu, Aug 27, 2015 at 01:44:06AM +, Konduru, Chandra wrote:
> > > > -static char intel_get_stepping(struct drm_device *dev)
> > > > +char intel_get_stepping(struct drm_device *dev)
> > >
> > > I guess we should have a new home for this now that it's used outside of
> > > intel_csr.c Plus kerneldoc, as usual.
> >
> > Will add kerneldoc header and respun, but where do you want to move to?
>
> If you want my dice-roll, I'd shovel it into intel_uncore.c for lack of
> better home.
> -Daniel
I sent updated patch series couple days ago moving to intel_display.c.
I hope that is fine.
By the way, can you start giving RB tags for the patches you reviewed?
>
> >
> > >
> > > > {
> > > > if (IS_SKYLAKE(dev) && (dev->pdev->revision <
> > > > ARRAY_SIZE(skl_stepping_info)))
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 419660d..2158b8f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -3196,6 +3196,16 @@ static void
> skylake_update_primary_plane(struct
> > > drm_crtc *crtc,
> > > > I915_WRITE(PLANE_AUX_DIST(pipe, 0), aux_dist | aux_stride);
> > > > I915_WRITE(PLANE_AUX_OFFSET(pipe, 0), aux_y_offset << 16 |
> > > aux_x_offset);
> > > >
> > > > + DRM_DEBUG_KMS("KCM: is_skl = %d is_bxt = %d\n",
> > > > + IS_SKYLAKE(dev), IS_BROXTON(dev));
> > > > +
> > >
> > > Wa comments are missing here. Also generally we do 1 wa per commit.
> > > -Daniel
> >
> > Sure, will split and respun.
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915/gtt: Avoid calling kcalloc in a loop when allocating temp bitmaps
On each call to gen8_alloc_va_range_3lvl we're allocating temporary
bitmaps needed for error handling. Unfortunately, when we increase
address space size (48b ppgtt) we do additional (512 - 4) calls to
kcalloc, increasing latency between exec and actual start of execution
on the GPU. Let's just do a single kcalloc, we can also drop the size
from free_gen8_temp_bitmaps since it's no longer used.
v2: Use GFP_TEMPORARY to make the allocations reclaimable.
v3: Drop the 2D array, just allocate a single block.
v4: Rebase to handle gen8_preallocate_top_level_pdps.
v5: Align misaligned bracket.
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 49 ++---
1 file changed, 18 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bdb7adc..b40a9cb 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1164,13 +1164,8 @@ unwind_out:
}
static void
-free_gen8_temp_bitmaps(unsigned long *new_pds, unsigned long **new_pts,
- uint32_t pdpes)
+free_gen8_temp_bitmaps(unsigned long *new_pds, unsigned long *new_pts)
{
- int i;
-
- for (i = 0; i < pdpes; i++)
- kfree(new_pts[i]);
kfree(new_pts);
kfree(new_pds);
}
@@ -1180,29 +1175,20 @@ free_gen8_temp_bitmaps(unsigned long *new_pds, unsigned
long **new_pts,
*/
static
int __must_check alloc_gen8_temp_bitmaps(unsigned long **new_pds,
-unsigned long ***new_pts,
+unsigned long **new_pts,
uint32_t pdpes)
{
- int i;
unsigned long *pds;
- unsigned long **pts;
+ unsigned long *pts;
- pds = kcalloc(BITS_TO_LONGS(pdpes), sizeof(unsigned long), GFP_KERNEL);
+ pds = kcalloc(BITS_TO_LONGS(pdpes), sizeof(unsigned long),
GFP_TEMPORARY);
if (!pds)
return -ENOMEM;
- pts = kcalloc(pdpes, sizeof(unsigned long *), GFP_KERNEL);
- if (!pts) {
- kfree(pds);
- return -ENOMEM;
- }
-
- for (i = 0; i < pdpes; i++) {
- pts[i] = kcalloc(BITS_TO_LONGS(I915_PDES),
-sizeof(unsigned long), GFP_KERNEL);
- if (!pts[i])
- goto err_out;
- }
+ pts = kcalloc(pdpes * BITS_TO_LONGS(I915_PDES),
+ sizeof(unsigned long), GFP_TEMPORARY);
+ if (!pts)
+ goto err_out;
*new_pds = pds;
*new_pts = pts;
@@ -1210,7 +1196,7 @@ int __must_check alloc_gen8_temp_bitmaps(unsigned long
**new_pds,
return 0;
err_out:
- free_gen8_temp_bitmaps(pds, pts, pdpes);
+ free_gen8_temp_bitmaps(pds, pts);
return -ENOMEM;
}
@@ -1231,7 +1217,7 @@ static int gen8_alloc_va_range_3lvl(struct
i915_address_space *vm,
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
- unsigned long *new_page_dirs, **new_page_tables;
+ unsigned long *new_page_dirs, *new_page_tables;
struct drm_device *dev = vm->dev;
struct i915_page_directory *pd;
const uint64_t orig_start = start;
@@ -1258,14 +1244,14 @@ static int gen8_alloc_va_range_3lvl(struct
i915_address_space *vm,
ret = gen8_ppgtt_alloc_page_directories(vm, pdp, start, length,
new_page_dirs);
if (ret) {
- free_gen8_temp_bitmaps(new_page_dirs, new_page_tables, pdpes);
+ free_gen8_temp_bitmaps(new_page_dirs, new_page_tables);
return ret;
}
/* For every page directory referenced, allocate page tables */
gen8_for_each_pdpe(pd, pdp, start, length, temp, pdpe) {
ret = gen8_ppgtt_alloc_pagetabs(vm, pd, start, length,
- new_page_tables[pdpe]);
+ new_page_tables + pdpe *
BITS_TO_LONGS(I915_PDES));
if (ret)
goto err_out;
}
@@ -1316,20 +1302,21 @@ static int gen8_alloc_va_range_3lvl(struct
i915_address_space *vm,
gen8_setup_page_directory(ppgtt, pdp, pd, pdpe);
}
- free_gen8_temp_bitmaps(new_page_dirs, new_page_tables, pdpes);
+ free_gen8_temp_bitmaps(new_page_dirs, new_page_tables);
mark_tlbs_dirty(ppgtt);
return 0;
err_out:
while (pdpe--) {
- for_each_set_bit(temp, new_page_tables[pdpe], I915_PDES)
+ for_each_set_bit(temp, new_page_tables + pdpe *
+ BITS_TO_LONGS(I915_PDES), I915_PDES)
free_pt(dev,
pdp->page_directory[pdpe]->page_table[temp]);
}
for_each_set_bit(pdpe, new_p
Re: [Intel-gfx] Request Linux Graphic Driver for Intel GMA 3150
On Wed, Sep 2, 2015 at 9:14 PM Matt Turner wrote: > On Wed, Sep 2, 2015 at 9:01 PM, David Ho wrote: > > Dear Rodrigo, > > > > Thank you for your help. > > > > I'll take a look at the PCI ID. > > > > However, > > when I search GMA 3150 at 01.org, I came across this page: > > > https://01.org/linuxgraphics/downloads/2013q1-intel-graphics-stack-release > > > > and also this page at Intel.com > > http://www.intel.com/support/graphics/sb/cs-010512.htm > > > > it seems that the driver of GMA 3150 for older Ubuntu version is > available (supported by open source driver). > > Wikipedia says GMA 3150 is just a "Pineview" [0] > Oh, Pineview! I'm sorry, I have forgotten GMA 3150 was Pineview. > > If so, it's supported by both the i915 kernel and Mesa drivers. But > grep Mesa's include/pci_ids/ to be sure that's what you have. > Indeed. > > [0] https://en.wikipedia.org/wiki/Intel_GMA#GMA_3150 > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add GuC css header parser
On 09/03/2015 12:36 AM, Jani Nikula wrote:
On Thu, 03 Sep 2015, yu@intel.com wrote:
> From: Alex Dai
>
> By using information from GuC css header, we can eliminate some
> hard code w.r.t size of some components of firmware.
>
> Signed-off-by: Alex Dai
> ---
> drivers/gpu/drm/i915/intel_guc.h| 2 +-
> drivers/gpu/drm/i915/intel_guc_fwif.h | 36 +
> drivers/gpu/drm/i915/intel_guc_loader.c | 91
++---
> 3 files changed, 98 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
> index 4ec2d27..e1389fc 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -71,6 +71,7 @@ struct intel_guc_fw {
>struct drm_i915_gem_object *guc_fw_obj;
>enum intel_guc_fw_statusguc_fw_fetch_status;
>enum intel_guc_fw_statusguc_fw_load_status;
> + struct guc_css_header guc_fw_header;
>
>uint16_tguc_fw_major_wanted;
>uint16_tguc_fw_minor_wanted;
> @@ -80,7 +81,6 @@ struct intel_guc_fw {
>
> struct intel_guc {
>struct intel_guc_fw guc_fw;
> -
>uint32_t log_flags;
>struct drm_i915_gem_object *log_obj;
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index e1f47ba..d6cb4e8 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -122,6 +122,42 @@
>
> #define GUC_CTL_MAX_DWORDS(GUC_CTL_RSRVD + 1)
>
> +struct guc_css_header {
> + uint32_t module_type;
> + uint32_t header_len; /* header length plus size of all other keys */
> + uint32_t header_version;
> + uint32_t module_id;
> + uint32_t module_vendor;
> + union {
> + struct {
> + uint8_t day;
> + uint8_t month;
> + uint16_t year;
> + };
> + uint32_t date;
> + };
> + uint32_t size; /* uCode size plus header_len */
> + uint32_t key_size;
> + uint32_t modulus_size;
> + uint32_t exponent_size;
> + union {
> + struct {
> + uint8_t hour;
> + uint8_t min;
> + uint16_t sec;
> + };
> + uint32_t time;
> + };
> +
> + char username[8];
> + char buildnumber[12];
> + uint32_t device_id;
> + uint32_t guc_sw_version;
> + uint32_t prod_preprod_fw;
> + uint32_t reserved[12];
> + uint32_t header_info;
> +};
Drive-by review, this will need __packed.
Yes, will correct this in next version. Thanks, -Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/gem_bad_reloc: use correct page table size
From: Daniele Ceraolo Spurio
2 subparts of gem_bad_reloc check that the reloc address is below the
global gtt boundary. However, when executing from ppgtt the reloc
address can be greater than that and still be a valid address.
To be sure that we're using the right upper limit, select it based on
the ppgtt mode.
Cc: Michel Thierry
Signed-off-by: Daniele Ceraolo Spurio
---
tests/gem_bad_reloc.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/tests/gem_bad_reloc.c b/tests/gem_bad_reloc.c
index 563571e..d2e0b70 100644
--- a/tests/gem_bad_reloc.c
+++ b/tests/gem_bad_reloc.c
@@ -44,6 +44,32 @@ IGT_TEST_DESCRIPTION("Simulates SNA behaviour using negative
self-relocations"
#define USE_LUT (1 << 12)
+static uint64_t get_page_table_size(int fd)
+{
+ struct drm_i915_getparam gp;
+ int val = 0;
+
+ memset(&gp, 0, sizeof(gp));
+ gp.param = 18; /* HAS_ALIASING_PPGTT */
+ gp.value = &val;
+
+ if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, &gp))
+ return 0;
+ errno = 0;
+
+ switch (val) {
+ case 0:
+ case 1:
+ return gem_aperture_size(fd);
+ case 2:
+ return 1ULL << 32;
+ case 3:
+ return 1ULL << 48;
+ }
+
+ return 0;
+}
+
/* Simulates SNA behaviour using negative self-relocations for
* STATE_BASE_ADDRESS command packets. If they wrap around (to values greater
* than the total size of the GTT), the GPU will hang.
@@ -54,7 +80,7 @@ static int negative_reloc(int fd, unsigned flags)
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 gem_exec[2];
struct drm_i915_gem_relocation_entry gem_reloc[1000];
- uint64_t gtt_max = gem_aperture_size(fd);
+ uint64_t gtt_max = get_page_table_size(fd);
uint32_t buf[1024] = {MI_BATCH_BUFFER_END};
int i;
@@ -86,7 +112,7 @@ static int negative_reloc(int fd, unsigned flags)
&execbuf));
gem_close(fd, gem_exec[1].handle);
- igt_info("Found offset %ld for 4k batch\n", (long)gem_exec[0].offset);
+ igt_info("Found offset %lld for 4k batch\n", (long
long)gem_exec[0].offset);
/*
* Ideally we'd like to be able to control where the kernel is going to
* place the buffer. We don't SKIP here because it causes the test
@@ -114,7 +140,7 @@ static int negative_reloc(int fd, unsigned flags)
DRM_IOCTL_I915_GEM_EXECBUFFER2,
&execbuf));
- igt_info("Batch is now at offset %ld\n", (long)gem_exec[0].offset);
+ igt_info("Batch is now at offset %lld\n", (long
long)gem_exec[0].offset);
gem_read(fd, gem_exec[0].handle, 0, buf, sizeof(buf));
gem_close(fd, gem_exec[0].handle);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Refactor common ringbuffer allocation code
"Zanoni, Paulo R" writes:
> Em Qui, 2015-09-03 às 13:01 +0100, Chris Wilson escreveu:
>> A small, very small, step to sharing the duplicate code between
>> execlists and legacy submission engines, starting with the ringbuffer
>> allocation code.
>>
>> Signed-off-by: Chris Wilson
>> Cc: Arun Siluvery
>> Cc: Mika Kuoppala
>> Cc: Dave Gordon
>> ---
>> drivers/gpu/drm/i915/intel_lrc.c| 49 +-
>> drivers/gpu/drm/i915/intel_ringbuffer.c | 89 ---
>> --
>> drivers/gpu/drm/i915/intel_ringbuffer.h | 8 +--
>> 3 files changed, 70 insertions(+), 76 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>> b/drivers/gpu/drm/i915/intel_lrc.c
>> index 40cbba4ea4ba..28a712e7d2d0 100644
>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> @@ -2340,8 +2340,7 @@ void intel_lr_context_free(struct intel_context
>> *ctx)
>> i915_gem_object_ggtt_unpin(ctx_obj);
>> }
>> WARN_ON(ctx->engine[ring->id].pin_count);
>> -intel_destroy_ringbuffer_obj(ringbuf);
>> -kfree(ringbuf);
>> +intel_ringbuffer_free(ringbuf);
>> drm_gem_object_unreference(&ctx_obj->base);
>> }
>> }
>> @@ -2442,42 +2441,20 @@ int intel_lr_context_deferred_create(struct
>> intel_context *ctx,
>> I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
>> }
>>
>> -ringbuf = kzalloc(sizeof(*ringbuf), GFP_KERNEL);
>> -if (!ringbuf) {
>> -DRM_DEBUG_DRIVER("Failed to allocate ringbuffer
>> %s\n",
>
> We got rid of this message, but I suppose it's not a problem, since it
> was not a loud error message.
>
>
>> -ring->name);
>> -ret = -ENOMEM;
>> +ringbuf = intel_engine_create_ringbuffer(ring, 4 *
>> PAGE_SIZE);
>> +if (IS_ERR(ringbuf)) {
>> +ret = PTR_ERR(ringbuf);
>> goto error_unpin_ctx;
>> }
>>
>> -ringbuf->ring = ring;
>> -
>> -ringbuf->size = 4 * PAGE_SIZE;
>> -ringbuf->effective_size = ringbuf->size;
>> -ringbuf->head = 0;
>> -ringbuf->tail = 0;
>> -ringbuf->last_retired_head = -1;
>> -intel_ring_update_space(ringbuf);
>> -
>> -if (ringbuf->obj == NULL) {
>> -ret = intel_alloc_ringbuffer_obj(dev, ringbuf);
>> +if (is_global_default_ctx) {
>> +ret = intel_pin_and_map_ringbuffer_obj(dev,
>> ringbuf);
>> if (ret) {
>> -DRM_DEBUG_DRIVER(
>> -"Failed to allocate ringbuffer obj
>> %s: %d\n",
>> -ring->name, ret);
>> -goto error_free_rbuf;
>> +DRM_ERROR(
>> + "Failed to pin and map ringbuffer
>> %s: %d\n",
>> + ring->name, ret);
>> +goto error_ringbuf;
>> }
>> -
>> -if (is_global_default_ctx) {
>> -ret = intel_pin_and_map_ringbuffer_obj(dev,
>> ringbuf);
>> -if (ret) {
>> -DRM_ERROR(
>> -"Failed to pin and map
>> ringbuffer %s: %d\n",
>> -ring->name, ret);
>> -goto error_destroy_rbuf;
>> -}
>> -}
>> -
>> }
>>
>> ret = populate_lr_context(ctx, ctx_obj, ring, ringbuf);
>> @@ -2519,10 +2496,8 @@ int intel_lr_context_deferred_create(struct
>> intel_context *ctx,
>> error:
>> if (is_global_default_ctx)
>> intel_unpin_ringbuffer_obj(ringbuf);
>> -error_destroy_rbuf:
>> -intel_destroy_ringbuffer_obj(ringbuf);
>> -error_free_rbuf:
>> -kfree(ringbuf);
>> +error_ringbuf:
>> +intel_ringbuffer_free(ringbuf);
>> error_unpin_ctx:
>> if (is_global_default_ctx)
>> i915_gem_object_ggtt_unpin(ctx_obj);
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index 6e6b8db996ef..20a75bb516ac 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> @@ -1996,14 +1996,14 @@ int intel_pin_and_map_ringbuffer_obj(struct
>> drm_device *dev,
>> return 0;
>> }
>>
>> -void intel_destroy_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
>> +static void intel_destroy_ringbuffer_obj(struct intel_ringbuffer
>> *ringbuf)
>> {
>> drm_gem_object_unreference(&ringbuf->obj->base);
>> ringbuf->obj = NULL;
>> }
>>
>> -int intel_alloc_ringbuffer_obj(struct drm_device *dev,
>> - struct intel_ringbuffer *ringbuf)
>> +static int intel_alloc_ringbuffer_obj(struct drm_device *dev,
>> + struct intel_ringbuffer
>> *ringbuf)
>> {
>> struct drm_i915_gem_object *obj;
>>
>> @@ -2023,6 +2023,48 @@ in
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Refactor common ringbuffer allocation code
On Thu, Sep 03, 2015 at 02:01:51PM +, Zanoni, Paulo R wrote:
> Em Qui, 2015-09-03 às 13:01 +0100, Chris Wilson escreveu:
> > A small, very small, step to sharing the duplicate code between
> > execlists and legacy submission engines, starting with the ringbuffer
> > allocation code.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Arun Siluvery
> > Cc: Mika Kuoppala
> > Cc: Dave Gordon
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c| 49 +-
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 89 ---
> > --
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 8 +--
> > 3 files changed, 70 insertions(+), 76 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 40cbba4ea4ba..28a712e7d2d0 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -2340,8 +2340,7 @@ void intel_lr_context_free(struct intel_context
> > *ctx)
> > i915_gem_object_ggtt_unpin(ctx_obj);
> > }
> > WARN_ON(ctx->engine[ring->id].pin_count);
> > - intel_destroy_ringbuffer_obj(ringbuf);
> > - kfree(ringbuf);
> > + intel_ringbuffer_free(ringbuf);
> > drm_gem_object_unreference(&ctx_obj->base);
> > }
> > }
> > @@ -2442,42 +2441,20 @@ int intel_lr_context_deferred_create(struct
> > intel_context *ctx,
> > I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> > }
> >
> > - ringbuf = kzalloc(sizeof(*ringbuf), GFP_KERNEL);
> > - if (!ringbuf) {
> > - DRM_DEBUG_DRIVER("Failed to allocate ringbuffer
> > %s\n",
>
> We got rid of this message, but I suppose it's not a problem, since it
> was not a loud error message.
I additionally added these to patch 2. I removed the ones in intel_lrc
that were simply repeating the error message (albeit in a more generic
fashion due to loss of information). At this level an oom squalk
followed by ENOMEM reported to userspace is fairly obvious (and
definitely not our error).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap (GSH) or Instruction State Heap (ISH) must be in a
32-bit range, because the General State Offset and Instruction State Offset
are limited to 32-bits.
The i915 driver has been modified to provide a flag to set when the 4GB
limit is not necessary in a given bo (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
48-bit range will only be used when explicitly requested.
Callers to the existing drm_intel_bo_emit_reloc function should set the
use_48b_address_range flag beforehand, in order to use full ppgtt range.
v2: Make set/clear functions nops on pre-gen8 platforms, and use them
internally in emit_reloc functions (Ben)
s/48BADDRESS/48B_ADDRESS/ (Dave)
v3: Keep set/clear functions internal, no-one needs to use them directly.
v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
before enabling set/clear function, print full offsets in debug
statements, using port of lower_32_bits and upper_32_bits from linux
kernel (Michał)
References:
http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
Cc: Ben Widawsky
Cc: Michał Winiarski
Signed-off-by: Michel Thierry
---
include/drm/i915_drm.h| 3 +-
intel/intel_bufmgr.c | 11 ++
intel/intel_bufmgr.h | 1 +
intel/intel_bufmgr_gem.c | 88 +--
intel/intel_bufmgr_priv.h | 14
5 files changed, 97 insertions(+), 20 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..426b25c 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -680,7 +680,8 @@ struct drm_i915_gem_exec_object2 {
#define EXEC_OBJECT_NEEDS_FENCE (1<<0)
#define EXEC_OBJECT_NEEDS_GTT (1<<1)
#define EXEC_OBJECT_WRITE (1<<2)
-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
+#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
+#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_SUPPORTS_48B_ADDRESS<<1)
__u64 flags;
__u64 rsvd1;
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 14ea9f9..0856e60 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -293,6 +293,17 @@ drm_intel_bo_madvise(drm_intel_bo *bo, int madv)
}
int
+drm_intel_bo_use_48b_address_range(drm_intel_bo *bo, uint32_t enable)
+{
+ if (bo->bufmgr->bo_use_48b_address_range) {
+ bo->bufmgr->bo_use_48b_address_range(bo, enable);
+ return 0;
+ }
+
+ return -ENODEV;
+}
+
+int
drm_intel_bo_references(drm_intel_bo *bo, drm_intel_bo *target_bo)
{
return bo->bufmgr->bo_references(bo, target_bo);
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 95eecb8..a14c78f 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -164,6 +164,7 @@ int drm_intel_bo_get_tiling(drm_intel_bo *bo, uint32_t *
tiling_mode,
int drm_intel_bo_flink(drm_intel_bo *bo, uint32_t * name);
int drm_intel_bo_busy(drm_intel_bo *bo);
int drm_intel_bo_madvise(drm_intel_bo *bo, int madv);
+int drm_intel_bo_use_48b_address_range(drm_intel_bo *bo, uint32_t enable);
int drm_intel_bo_disable_reuse(drm_intel_bo *bo);
int drm_intel_bo_is_reusable(drm_intel_bo *bo);
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 2723e21..09d82d2 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -83,6 +83,22 @@
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
#define MAX2(A, B) ((A) > (B) ? (A) : (B))
+/**
+ * upper_32_bits - return bits 32-63 of a number
+ * @n: the number we're accessing
+ *
+ * A basic shift-right of a 64- or 32-bit quantity. Use this to suppress
+ * the "right shift count >= width of type" warning when that quantity is
+ * 32-bits.
+ */
+#define upper_32_bits(n) ((__u32)(((n) >> 16) >> 16))
+
+/**
+ * lower_32_bits - return bits 0-31 of a number
+ * @n: the number we're accessing
+ */
+#define lower_32_bits(n) ((__u32)(n))
+
typedef struct _drm_intel_bo_gem drm_intel_bo_gem;
struct drm_intel_gem_bo_bucket {
@@ -237,6 +253,15 @@ struct _drm_intel_bo_gem {
bool is_userptr;
/**
+* Boolean of whether this buffer can be placed in the full 48-bit
+* address range on gen8+.
+*
+* By default, buffers will be keep in a 32-bit range, unless this
+* flag is explicitly set.
+*/
+ bool use_48b_address_range;
+
+ /**
* Size in bytes of this buffer and its relocation descendents.
*
* Used to avoid costly tree walking in
@@ -395,14 +420,16 @@ drm_intel_gem_dump_validation_list(drm_intel_bufmgr_gem
*bufmgr_gem)
drm_intel_bo_gem *target_gem =
(drm_intel_bo_gem *) target_bo;
- DBG("%2d: %d (%s)@0x%08llx -> "
- "%d (%s)@0x%08lx + 0x%08x\n",
+
[Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in i915
This new version picks the suggestion from Michał Winiarski related to v3 [1]. 48-bit virtual address range will be enabled in i915 soon, but some objects must be referenced by 32-bit offsets. These patches use a new kernel flag to specify if this restriction applies or not. I'm sending these patches to comply with the i915 merge process. Once the kernel patch is merged, I'll make a new libdrm release and address the mesa build dependency. [1] http://lists.freedesktop.org/archives/dri-devel/2015-August/087837.html Michel Thierry (2): intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag) intel: add drm_intel_bo_use_48b_address_range to symbol-check test include/drm/i915_drm.h| 3 +- intel/intel-symbol-check | 1 + intel/intel_bufmgr.c | 11 ++ intel/intel_bufmgr.h | 1 + intel/intel_bufmgr_gem.c | 88 +-- intel/intel_bufmgr_priv.h | 14 6 files changed, 98 insertions(+), 20 deletions(-) -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/2] intel: add drm_intel_bo_use_48b_address_range to symbol-check test
Signed-off-by: Michel Thierry --- intel/intel-symbol-check | 1 + 1 file changed, 1 insertion(+) diff --git a/intel/intel-symbol-check b/intel/intel-symbol-check index c555e6d..64ec4ed 100755 --- a/intel/intel-symbol-check +++ b/intel/intel-symbol-check @@ -39,6 +39,7 @@ drm_intel_bo_subdata drm_intel_bo_unmap drm_intel_bo_unpin drm_intel_bo_unreference +drm_intel_bo_use_48b_address_range drm_intel_bo_wait_rendering drm_intel_bufmgr_check_aperture_space drm_intel_bufmgr_destroy -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Refactor common ringbuffer allocation code
Em Qui, 2015-09-03 às 13:01 +0100, Chris Wilson escreveu:
> A small, very small, step to sharing the duplicate code between
> execlists and legacy submission engines, starting with the ringbuffer
> allocation code.
>
> Signed-off-by: Chris Wilson
> Cc: Arun Siluvery
> Cc: Mika Kuoppala
> Cc: Dave Gordon
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 49 +-
> drivers/gpu/drm/i915/intel_ringbuffer.c | 89 ---
> --
> drivers/gpu/drm/i915/intel_ringbuffer.h | 8 +--
> 3 files changed, 70 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 40cbba4ea4ba..28a712e7d2d0 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2340,8 +2340,7 @@ void intel_lr_context_free(struct intel_context
> *ctx)
> i915_gem_object_ggtt_unpin(ctx_obj);
> }
> WARN_ON(ctx->engine[ring->id].pin_count);
> - intel_destroy_ringbuffer_obj(ringbuf);
> - kfree(ringbuf);
> + intel_ringbuffer_free(ringbuf);
> drm_gem_object_unreference(&ctx_obj->base);
> }
> }
> @@ -2442,42 +2441,20 @@ int intel_lr_context_deferred_create(struct
> intel_context *ctx,
> I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> }
>
> - ringbuf = kzalloc(sizeof(*ringbuf), GFP_KERNEL);
> - if (!ringbuf) {
> - DRM_DEBUG_DRIVER("Failed to allocate ringbuffer
> %s\n",
We got rid of this message, but I suppose it's not a problem, since it
was not a loud error message.
> - ring->name);
> - ret = -ENOMEM;
> + ringbuf = intel_engine_create_ringbuffer(ring, 4 *
> PAGE_SIZE);
> + if (IS_ERR(ringbuf)) {
> + ret = PTR_ERR(ringbuf);
> goto error_unpin_ctx;
> }
>
> - ringbuf->ring = ring;
> -
> - ringbuf->size = 4 * PAGE_SIZE;
> - ringbuf->effective_size = ringbuf->size;
> - ringbuf->head = 0;
> - ringbuf->tail = 0;
> - ringbuf->last_retired_head = -1;
> - intel_ring_update_space(ringbuf);
> -
> - if (ringbuf->obj == NULL) {
> - ret = intel_alloc_ringbuffer_obj(dev, ringbuf);
> + if (is_global_default_ctx) {
> + ret = intel_pin_and_map_ringbuffer_obj(dev,
> ringbuf);
> if (ret) {
> - DRM_DEBUG_DRIVER(
> - "Failed to allocate ringbuffer obj
> %s: %d\n",
> - ring->name, ret);
> - goto error_free_rbuf;
> + DRM_ERROR(
> + "Failed to pin and map ringbuffer
> %s: %d\n",
> + ring->name, ret);
> + goto error_ringbuf;
> }
> -
> - if (is_global_default_ctx) {
> - ret = intel_pin_and_map_ringbuffer_obj(dev,
> ringbuf);
> - if (ret) {
> - DRM_ERROR(
> - "Failed to pin and map
> ringbuffer %s: %d\n",
> - ring->name, ret);
> - goto error_destroy_rbuf;
> - }
> - }
> -
> }
>
> ret = populate_lr_context(ctx, ctx_obj, ring, ringbuf);
> @@ -2519,10 +2496,8 @@ int intel_lr_context_deferred_create(struct
> intel_context *ctx,
> error:
> if (is_global_default_ctx)
> intel_unpin_ringbuffer_obj(ringbuf);
> -error_destroy_rbuf:
> - intel_destroy_ringbuffer_obj(ringbuf);
> -error_free_rbuf:
> - kfree(ringbuf);
> +error_ringbuf:
> + intel_ringbuffer_free(ringbuf);
> error_unpin_ctx:
> if (is_global_default_ctx)
> i915_gem_object_ggtt_unpin(ctx_obj);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 6e6b8db996ef..20a75bb516ac 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1996,14 +1996,14 @@ int intel_pin_and_map_ringbuffer_obj(struct
> drm_device *dev,
> return 0;
> }
>
> -void intel_destroy_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
> +static void intel_destroy_ringbuffer_obj(struct intel_ringbuffer
> *ringbuf)
> {
> drm_gem_object_unreference(&ringbuf->obj->base);
> ringbuf->obj = NULL;
> }
>
> -int intel_alloc_ringbuffer_obj(struct drm_device *dev,
> -struct intel_ringbuffer *ringbuf)
> +static int intel_alloc_ringbuffer_obj(struct drm_device *dev,
> + struct intel_ringbuffer
> *ringbuf)
> {
> struct drm_i915_gem_object *obj;
>
> @@ -2023,6 +2023,48 @@ int intel_alloc_ringbuffer_obj(struct
> drm_device *dev,
> return 0;
> }
>
> +struct intel_ring
Re: [Intel-gfx] [PATCH 1/2] drm/i915: access the PP_CONTROL reg only pre GEN5
On Thu, Sep 03, 2015 at 04:40:13PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 03, 2015 at 04:24:35PM +0300, Imre Deak wrote:
> > This register exists only pre GEN5, but atm we also access it on
> > VLV/BXT/CHV. Prevent accessing it on these latter platforms.
>
> We don't have LVDS on any of those platforms.
Bah. Imre pointed out that we call intel_lvds_init() uncodnditionally on
all platforms, so the patch does make sense.
What a mess. Someone should really move the PPS unlock to some early
modeset init/resume code and also fix it for VLV/CHV/etc.
In the meantime this does what it says, so
Reviewed-by: Ville Syrjälä
>
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_lvds.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index 0794dc8..a16308a 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -955,7 +955,7 @@ void intel_lvds_init(struct drm_device *dev)
> > if (HAS_PCH_SPLIT(dev)) {
> > I915_WRITE(PCH_PP_CONTROL,
> >I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
> > - } else {
> > + } else if (INTEL_INFO(dev_priv)->gen < 5) {
> > I915_WRITE(PP_CONTROL,
> >I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
> > }
> > --
> > 2.1.4
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: access the PP_ON_DELAYS/PP_OFF_DELAYS regs only pre GEN5
On Thu, Sep 03, 2015 at 04:24:36PM +0300, Imre Deak wrote:
> These registers exist only before GEN5, so currently we may access
> undefined registers on VLV/CHV and BXT. Apply the workaround only pre
> GEN5.
>
> Since the workaround is relevant only when LVDS is present, for clarity
> apply it only if this is the case.
>
> This triggered an unclaimed register access warning on BXT.
>
> v2: (Ville)
> - move the workaround to the LVDS init code
> - print a debug note about the workaround
>
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_dma.c | 2 --
> drivers/gpu/drm/i915/intel_bios.c | 18 --
> drivers/gpu/drm/i915/intel_bios.h | 1 -
> drivers/gpu/drm/i915/intel_lvds.c | 12
> 4 files changed, 12 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index f0eaa6f..066a0ef 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -997,8 +997,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> intel_setup_gmbus(dev);
> intel_opregion_setup(dev);
>
> - intel_setup_bios(dev);
> -
> i915_gem_load(dev);
>
> /* On the 945G/GM, the chipset reports the MSI capability on the
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index b3e437b..c8acc29 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1340,21 +1340,3 @@ intel_parse_bios(struct drm_device *dev)
>
> return 0;
> }
> -
> -/* Ensure that vital registers have been initialised, even if the BIOS
> - * is absent or just failing to do its job.
> - */
> -void intel_setup_bios(struct drm_device *dev)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
> - /* Set the Panel Power On/Off timings if uninitialized. */
> - if (!HAS_PCH_SPLIT(dev) &&
> - I915_READ(PP_ON_DELAYS) == 0 && I915_READ(PP_OFF_DELAYS) == 0) {
> - /* Set T2 to 40ms and T5 to 200ms */
> - I915_WRITE(PP_ON_DELAYS, 0x019007d0);
> -
> - /* Set T3 to 35ms and Tx to 200ms */
> - I915_WRITE(PP_OFF_DELAYS, 0x015e07d0);
> - }
> -}
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index 46cd5c7..1b7417e 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -588,7 +588,6 @@ struct bdb_psr {
> struct psr_table psr_table[16];
> } __packed;
>
> -void intel_setup_bios(struct drm_device *dev);
> int intel_parse_bios(struct drm_device *dev);
>
> /*
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index a16308a..2c2d1f0 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -985,6 +985,18 @@ void intel_lvds_init(struct drm_device *dev)
> DRM_DEBUG_KMS("LVDS is not present in VBT, but enabled
> anyway\n");
> }
>
> + /* Set the Panel Power On/Off timings if uninitialized. */
> + if (INTEL_INFO(dev_priv)->gen < 5 &&
> + I915_READ(PP_ON_DELAYS) == 0 && I915_READ(PP_OFF_DELAYS) == 0) {
> + /* Set T2 to 40ms and T5 to 200ms */
> + I915_WRITE(PP_ON_DELAYS, 0x019007d0);
> +
> + /* Set T3 to 35ms and Tx to 200ms */
> + I915_WRITE(PP_OFF_DELAYS, 0x015e07d0);
> +
> + DRM_DEBUG_KMS("Panel power timings uninitialized, setting
> defaults\n");
> + }
> +
> lvds_encoder = kzalloc(sizeof(*lvds_encoder), GFP_KERNEL);
> if (!lvds_encoder)
> return;
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: access the PP_CONTROL reg only pre GEN5
On Thu, Sep 03, 2015 at 04:24:35PM +0300, Imre Deak wrote:
> This register exists only pre GEN5, but atm we also access it on
> VLV/BXT/CHV. Prevent accessing it on these latter platforms.
We don't have LVDS on any of those platforms.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_lvds.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index 0794dc8..a16308a 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -955,7 +955,7 @@ void intel_lvds_init(struct drm_device *dev)
> if (HAS_PCH_SPLIT(dev)) {
> I915_WRITE(PCH_PP_CONTROL,
> I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
> - } else {
> + } else if (INTEL_INFO(dev_priv)->gen < 5) {
> I915_WRITE(PP_CONTROL,
> I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
> }
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: access the PP_ON_DELAYS/PP_OFF_DELAYS regs only pre GEN5
These registers exist only before GEN5, so currently we may access
undefined registers on VLV/CHV and BXT. Apply the workaround only pre
GEN5.
Since the workaround is relevant only when LVDS is present, for clarity
apply it only if this is the case.
This triggered an unclaimed register access warning on BXT.
v2: (Ville)
- move the workaround to the LVDS init code
- print a debug note about the workaround
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_dma.c | 2 --
drivers/gpu/drm/i915/intel_bios.c | 18 --
drivers/gpu/drm/i915/intel_bios.h | 1 -
drivers/gpu/drm/i915/intel_lvds.c | 12
4 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f0eaa6f..066a0ef 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -997,8 +997,6 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
intel_setup_gmbus(dev);
intel_opregion_setup(dev);
- intel_setup_bios(dev);
-
i915_gem_load(dev);
/* On the 945G/GM, the chipset reports the MSI capability on the
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index b3e437b..c8acc29 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1340,21 +1340,3 @@ intel_parse_bios(struct drm_device *dev)
return 0;
}
-
-/* Ensure that vital registers have been initialised, even if the BIOS
- * is absent or just failing to do its job.
- */
-void intel_setup_bios(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
-
-/* Set the Panel Power On/Off timings if uninitialized. */
- if (!HAS_PCH_SPLIT(dev) &&
- I915_READ(PP_ON_DELAYS) == 0 && I915_READ(PP_OFF_DELAYS) == 0) {
- /* Set T2 to 40ms and T5 to 200ms */
- I915_WRITE(PP_ON_DELAYS, 0x019007d0);
-
- /* Set T3 to 35ms and Tx to 200ms */
- I915_WRITE(PP_OFF_DELAYS, 0x015e07d0);
- }
-}
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 46cd5c7..1b7417e 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -588,7 +588,6 @@ struct bdb_psr {
struct psr_table psr_table[16];
} __packed;
-void intel_setup_bios(struct drm_device *dev);
int intel_parse_bios(struct drm_device *dev);
/*
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index a16308a..2c2d1f0 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -985,6 +985,18 @@ void intel_lvds_init(struct drm_device *dev)
DRM_DEBUG_KMS("LVDS is not present in VBT, but enabled
anyway\n");
}
+/* Set the Panel Power On/Off timings if uninitialized. */
+ if (INTEL_INFO(dev_priv)->gen < 5 &&
+ I915_READ(PP_ON_DELAYS) == 0 && I915_READ(PP_OFF_DELAYS) == 0) {
+ /* Set T2 to 40ms and T5 to 200ms */
+ I915_WRITE(PP_ON_DELAYS, 0x019007d0);
+
+ /* Set T3 to 35ms and Tx to 200ms */
+ I915_WRITE(PP_OFF_DELAYS, 0x015e07d0);
+
+ DRM_DEBUG_KMS("Panel power timings uninitialized, setting
defaults\n");
+ }
+
lvds_encoder = kzalloc(sizeof(*lvds_encoder), GFP_KERNEL);
if (!lvds_encoder)
return;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: access the PP_CONTROL reg only pre GEN5
This register exists only pre GEN5, but atm we also access it on
VLV/BXT/CHV. Prevent accessing it on these latter platforms.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 0794dc8..a16308a 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -955,7 +955,7 @@ void intel_lvds_init(struct drm_device *dev)
if (HAS_PCH_SPLIT(dev)) {
I915_WRITE(PCH_PP_CONTROL,
I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
- } else {
+ } else if (INTEL_INFO(dev_priv)->gen < 5) {
I915_WRITE(PP_CONTROL,
I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: read dpcd 0 - 12 & link_status always
On Wed, 02 Sep 2015, Daniel Vetter wrote:
> On Tue, Sep 01, 2015 at 01:16:49PM +0300, Jani Nikula wrote:
>> On Thu, 27 Aug 2015, Sivakumar Thulasimani
>> wrote:
>> > From: "Thulasimani,Sivakumar"
>> >
>> > Compliance requires the driver to read dpcd register 0 to 12 and
>> > registers 0x200 to 0x205 to be read always.
>> > Current code performs dpcd read for short pulse interrupts only
>> > if the sink is enabled. This patch forces read for link status
>> > and registers 0 to 12.
>>
>> While this seems a bit silly from the driver perspective, I don't see it
>> doing much harm either.
>
> I don't think this is silly, but fixing it like this might be - currently
> we don't do _any_ detection of sink ports, so if you have a hub with two
> outputs and then plug in another one and plug out the first userspace
> won't reprobe. So probably what we should be doing is not just read the
> dpcd, but actually look at it, figure out whether something has changed
> and make sure we send out the uevent even if the hpd line stays unchanged
> on short pulses to make userspace aware of the changes.
>
> Punting on this for now since I suspect there's a bigger story to be had
> here ...
Well, I'll bet this would be a preliminary step for that anyway.
BR,
Jani.
> -Daniel
>
>>
>> Note that We do read dpcd 0 to 14 no matter what the spec says.
>>
>> Reviewed-by: Jani Nikula
>>
>> >
>> > Signed-off-by: Sivakumar Thulasimani
>> > ---
>> > drivers/gpu/drm/i915/intel_dp.c | 12 ++--
>> > 1 file changed, 6 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> > b/drivers/gpu/drm/i915/intel_dp.c
>> > index 8a66a44..76561e0 100644
>> > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > @@ -4374,12 +4374,6 @@ intel_dp_check_link_status(struct intel_dp
>> > *intel_dp)
>> >
>> >WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
>> >
>> > - if (!intel_encoder->base.crtc)
>> > - return;
>> > -
>> > - if (!to_intel_crtc(intel_encoder->base.crtc)->active)
>> > - return;
>> > -
>> >/* Try to read receiver status if the link appears to be up */
>> >if (!intel_dp_get_link_status(intel_dp, link_status)) {
>> >return;
>> > @@ -4390,6 +4384,12 @@ intel_dp_check_link_status(struct intel_dp
>> > *intel_dp)
>> >return;
>> >}
>> >
>> > + if (!intel_encoder->base.crtc)
>> > + return;
>> > +
>> > + if (!to_intel_crtc(intel_encoder->base.crtc)->active)
>> > + return;
>> > +
>> >/* Try to read the source of the interrupt */
>> >if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
>> >intel_dp_get_sink_irq(intel_dp, &sink_irq_vector)) {
>> > --
>> > 1.7.9.5
>> >
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Protect MST retraining with connection_mutex
On Thu, Aug 27, 2015 at 06:36:48PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Grab the connection_mutex around MSR link retraining to protect it
> against a concurrent modeset. We already do the same for SST.
>
> DP hpd_pulse can still otherwise race against modeset and ->detect(), so
> it's not clear what will happen when both want to scribble into eg.
> intel_dp->dpcd[] at the same time. But sorting it all out requires way
> more thought than I'm willing to expend now.
Actually I suppose this might not work out so well after all. I suppose
MST depends on short HPDs during modeset due to the sideband stuff.
So if we want to grab modeset locks for retraining, I suppose we'd
need to move the retraining to happen from .hot_plug() which gets run
from the other hotplug work, and so wouldn't interfere with sideband.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9e90a2b..1259c9b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4391,6 +4391,7 @@ update_status:
> static int
> intel_dp_check_mst_status(struct intel_dp *intel_dp)
> {
> + struct drm_device *dev = dp_to_dig_port(intel_dp)->base.base.dev;
> bool bret;
>
> if (intel_dp->is_mst) {
> @@ -4402,6 +4403,8 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> go_again:
> if (bret == true) {
>
> + drm_modeset_lock(&dev->mode_config.connection_mutex,
> NULL);
> +
> /* check link status - esi[10] = 0x200c */
> if (intel_dp->active_mst_links &&
> !drm_dp_channel_eq_ok(&esi[10],
> intel_dp->lane_count)) {
> @@ -4411,6 +4414,8 @@ go_again:
> intel_dp_stop_link_train(intel_dp);
> }
>
> + drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> DRM_DEBUG_KMS("got esi %3ph\n", esi);
> ret = drm_dp_mst_hpd_irq(&intel_dp->mst_mgr, esi,
> &handled);
>
> --
> 2.4.6
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix cmdparser STORE/LOAD command descriptors
Arun Siluvery writes:
> On 02/09/2015 12:29, Chris Wilson wrote:
>> Fixes regression from
>> commit f1afe24f0e736b9d7f2275e2b1504af3fe612f2a
>> Author: Arun Siluvery
>> Date: Tue Aug 4 16:22:20 2015 +0100
>>
>> drm/i915: Change SRM, LRM instructions to use correct length
>>
>> which forgot to account for the length bias when declaring the fixed
>> length.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91844
>> Reported-by: Andreas Reis
>> Signed-off-by: Chris Wilson
>> Cc: Dave Gordon
>> Cc: Arun Siluvery
>> Cc: Mika Kuoppala
>> Cc: Daniel Vetter
>> ---
>> drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
>> b/drivers/gpu/drm/i915/i915_cmd_parser.c
>> index ad7d7ab76d3f..09932cab1a3f 100644
>> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
>> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
>> @@ -124,14 +124,14 @@ static const struct drm_i915_cmd_descriptor
>> common_cmds[] = {
>> CMD( MI_STORE_DWORD_INDEX, SMI, !F, 0xFF, R ),
>> CMD( MI_LOAD_REGISTER_IMM(1), SMI, !F, 0xFF, W,
>>.reg = { .offset = 1, .mask = 0x007C, .step = 2 }),
>> -CMD( MI_STORE_REGISTER_MEM,SMI,F, 1, W | B,
>> +CMD( MI_STORE_REGISTER_MEM,SMI,F, 3, W | B,
>>.reg = { .offset = 1, .mask = 0x007C },
>>.bits = {{
>> .offset = 0,
>> .mask = MI_GLOBAL_GTT,
>> .expected = 0,
>>}}, ),
>> -CMD( MI_LOAD_REGISTER_MEM, SMI,F, 1, W | B,
>> +CMD( MI_LOAD_REGISTER_MEM, SMI,F, 3, W | B,
>>.reg = { .offset = 1, .mask = 0x007C },
>>.bits = {{
>> .offset = 0,
>>
> My mistake, I should have verified on Gen7 hw.
Review is for mistakes, and review failed.
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Recover all available ringbuffer space following reset
Having flushed all requests from all queues, we know that all
ringbuffers must now be empty. However, since we do not reclaim
all space when retiring the request (to prevent HEADs colliding
with rapid ringbuffer wraparound) the amount of available space
on each ringbuffer upon reset is less than when we start. Do one
more pass over all the ringbuffers to reset the available space
Signed-off-by: Chris Wilson
Cc: Arun Siluvery
Cc: Mika Kuoppala
Cc: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 14 ++
drivers/gpu/drm/i915/intel_lrc.c| 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 13 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
4 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 41263cd4170c..3a42c350fec9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2738,6 +2738,8 @@ static void i915_gem_reset_ring_status(struct
drm_i915_private *dev_priv,
static void i915_gem_reset_ring_cleanup(struct drm_i915_private *dev_priv,
struct intel_engine_cs *ring)
{
+ struct intel_ringbuffer *buffer;
+
while (!list_empty(&ring->active_list)) {
struct drm_i915_gem_object *obj;
@@ -2783,6 +2785,18 @@ static void i915_gem_reset_ring_cleanup(struct
drm_i915_private *dev_priv,
i915_gem_request_retire(request);
}
+
+ /* Having flushed all requests from all queues, we know that all
+* ringbuffers must now be empty. However, since we do not reclaim
+* all space when retiring the request (to prevent HEADs colliding
+* with rapid ringbuffer wraparound) the amount of available space
+* upon reset is less than when we start. Do one more pass over
+* all the ringbuffers to reset last_retired_head.
+*/
+ list_for_each_entry(buffer, &ring->buffers, link) {
+ buffer->last_retired_head = buffer->tail;
+ intel_ring_update_space(buffer);
+ }
}
void i915_gem_reset(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 28a712e7d2d0..de52ddc108a7 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1881,6 +1881,7 @@ static int logical_ring_init(struct drm_device *dev,
struct intel_engine_cs *rin
i915_gem_batch_pool_init(dev, &ring->batch_pool);
init_waitqueue_head(&ring->irq_queue);
+ INIT_LIST_HEAD(&ring->buffers);
INIT_LIST_HEAD(&ring->execlist_queue);
INIT_LIST_HEAD(&ring->execlist_retired_req_list);
spin_lock_init(&ring->execlist_lock);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 20a75bb516ac..d2e0b3b7efbf 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2030,10 +2030,14 @@ intel_engine_create_ringbuffer(struct intel_engine_cs
*engine, int size)
int ret;
ring = kzalloc(sizeof(*ring), GFP_KERNEL);
- if (ring == NULL)
+ if (ring == NULL) {
+ DRM_DEBUG_DRIVER("Failed to allocate ringbuffer %s\n",
+engine->name);
return ERR_PTR(-ENOMEM);
+ }
ring->ring = engine;
+ list_add(&ring->link, &engine->buffers);
ring->size = size;
/* Workaround an erratum on the i830 which causes a hang if
@@ -2049,8 +2053,9 @@ intel_engine_create_ringbuffer(struct intel_engine_cs
*engine, int size)
ret = intel_alloc_ringbuffer_obj(engine->dev, ring);
if (ret) {
- DRM_ERROR("Failed to allocate ringbuffer %s: %d\n",
- engine->name, ret);
+ DRM_DEBUG_DRIVER("Failed to allocate ringbuffer %s: %d\n",
+engine->name, ret);
+ list_del(&ring->link);
kfree(ring);
return ERR_PTR(ret);
}
@@ -2062,6 +2067,7 @@ void
intel_ringbuffer_free(struct intel_ringbuffer *ring)
{
intel_destroy_ringbuffer_obj(ring);
+ list_del(&ring->link);
kfree(ring);
}
@@ -2077,6 +2083,7 @@ static int intel_init_ring_buffer(struct drm_device *dev,
INIT_LIST_HEAD(&ring->active_list);
INIT_LIST_HEAD(&ring->request_list);
INIT_LIST_HEAD(&ring->execlist_queue);
+ INIT_LIST_HEAD(&ring->buffers);
i915_gem_batch_pool_init(dev, &ring->batch_pool);
memset(ring->semaphore.sync_seqno, 0,
sizeof(ring->semaphore.sync_seqno));
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 49fa41dc0eb6..58b1976a7d0a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -100,6 +100,7 @@ struct intel_ringbuffer {
void __iomem *virtual_start;
st
[Intel-gfx] [PATCH 1/2] drm/i915: Refactor common ringbuffer allocation code
A small, very small, step to sharing the duplicate code between
execlists and legacy submission engines, starting with the ringbuffer
allocation code.
Signed-off-by: Chris Wilson
Cc: Arun Siluvery
Cc: Mika Kuoppala
Cc: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c| 49 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 89 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 8 +--
3 files changed, 70 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 40cbba4ea4ba..28a712e7d2d0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2340,8 +2340,7 @@ void intel_lr_context_free(struct intel_context *ctx)
i915_gem_object_ggtt_unpin(ctx_obj);
}
WARN_ON(ctx->engine[ring->id].pin_count);
- intel_destroy_ringbuffer_obj(ringbuf);
- kfree(ringbuf);
+ intel_ringbuffer_free(ringbuf);
drm_gem_object_unreference(&ctx_obj->base);
}
}
@@ -2442,42 +2441,20 @@ int intel_lr_context_deferred_create(struct
intel_context *ctx,
I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
}
- ringbuf = kzalloc(sizeof(*ringbuf), GFP_KERNEL);
- if (!ringbuf) {
- DRM_DEBUG_DRIVER("Failed to allocate ringbuffer %s\n",
- ring->name);
- ret = -ENOMEM;
+ ringbuf = intel_engine_create_ringbuffer(ring, 4 * PAGE_SIZE);
+ if (IS_ERR(ringbuf)) {
+ ret = PTR_ERR(ringbuf);
goto error_unpin_ctx;
}
- ringbuf->ring = ring;
-
- ringbuf->size = 4 * PAGE_SIZE;
- ringbuf->effective_size = ringbuf->size;
- ringbuf->head = 0;
- ringbuf->tail = 0;
- ringbuf->last_retired_head = -1;
- intel_ring_update_space(ringbuf);
-
- if (ringbuf->obj == NULL) {
- ret = intel_alloc_ringbuffer_obj(dev, ringbuf);
+ if (is_global_default_ctx) {
+ ret = intel_pin_and_map_ringbuffer_obj(dev, ringbuf);
if (ret) {
- DRM_DEBUG_DRIVER(
- "Failed to allocate ringbuffer obj %s: %d\n",
- ring->name, ret);
- goto error_free_rbuf;
+ DRM_ERROR(
+ "Failed to pin and map ringbuffer %s: %d\n",
+ ring->name, ret);
+ goto error_ringbuf;
}
-
- if (is_global_default_ctx) {
- ret = intel_pin_and_map_ringbuffer_obj(dev, ringbuf);
- if (ret) {
- DRM_ERROR(
- "Failed to pin and map ringbuffer %s:
%d\n",
- ring->name, ret);
- goto error_destroy_rbuf;
- }
- }
-
}
ret = populate_lr_context(ctx, ctx_obj, ring, ringbuf);
@@ -2519,10 +2496,8 @@ int intel_lr_context_deferred_create(struct
intel_context *ctx,
error:
if (is_global_default_ctx)
intel_unpin_ringbuffer_obj(ringbuf);
-error_destroy_rbuf:
- intel_destroy_ringbuffer_obj(ringbuf);
-error_free_rbuf:
- kfree(ringbuf);
+error_ringbuf:
+ intel_ringbuffer_free(ringbuf);
error_unpin_ctx:
if (is_global_default_ctx)
i915_gem_object_ggtt_unpin(ctx_obj);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6e6b8db996ef..20a75bb516ac 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1996,14 +1996,14 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device
*dev,
return 0;
}
-void intel_destroy_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
+static void intel_destroy_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
{
drm_gem_object_unreference(&ringbuf->obj->base);
ringbuf->obj = NULL;
}
-int intel_alloc_ringbuffer_obj(struct drm_device *dev,
- struct intel_ringbuffer *ringbuf)
+static int intel_alloc_ringbuffer_obj(struct drm_device *dev,
+ struct intel_ringbuffer *ringbuf)
{
struct drm_i915_gem_object *obj;
@@ -2023,6 +2023,48 @@ int intel_alloc_ringbuffer_obj(struct drm_device *dev,
return 0;
}
+struct intel_ringbuffer *
+intel_engine_create_ringbuffer(struct intel_engine_cs *engine, int size)
+{
+ struct intel_ringbuffer *ring;
+ int ret;
+
+ ring = kzalloc(sizeof(*ring), GFP_KERNEL);
+ if (ring == NULL)
+ return ERR_PTR(-ENOMEM);
+
+ ring->ring = engine;
+
+ ring->size
Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Avoid using un-initialized bits_per_pixel
Reviewed-by: Sonika Jindal
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Kumar, Mahesh
Sent: Thursday, September 3, 2015 4:17 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Avoid using un-initialized
bits_per_pixel
Don't rely on fb->bits_per_pixel as intel_framebuffer_init is not filling
bits_per_pixel field of fb-struct for YUV pixel format.
This leads to divide by zero error during watermark calculation.
Signed-off-by: Kumar, Mahesh
Cc: Konduru, Chandra
---
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ea49661..1b90f03 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3170,7 +3170,8 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
if (fb) {
p->plane[0].enabled = true;
p->plane[0].bytes_per_pixel = fb->pixel_format ==
DRM_FORMAT_NV12 ?
- drm_format_plane_cpp(fb->pixel_format, 1) :
fb->bits_per_pixel / 8;
+ drm_format_plane_cpp(fb->pixel_format, 1) :
+ drm_format_plane_cpp(fb->pixel_format, 0);
p->plane[0].y_bytes_per_pixel = fb->pixel_format ==
DRM_FORMAT_NV12 ?
drm_format_plane_cpp(fb->pixel_format, 0) : 0;
p->plane[0].tiling = fb->modifier[0];
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl+: Add YUV pixel format in Capability list
Reviewed-by: Sonika Jindal
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Kumar, Mahesh
Sent: Thursday, September 3, 2015 4:17 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 2/2] drm/i915/skl+: Add YUV pixel format in
Capability list
GEN >= 9 supports YUV format for all planes, but it's not exported in
Capability list of primary plane. Add YUV formats in skl_primary_formats list.
Testcase: igt/kms_universal_plane.c
Signed-off-by: Kumar, Mahesh
Cc: Konduru, Chandra
---
drivers/gpu/drm/i915/intel_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0377520..5ab8a1a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,10 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_ABGR,
DRM_FORMAT_XRGB2101010,
DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
};
/* Cursor formats */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Improve kernel-doc for i915_audio_component struct
To make kernel-doc happy, the i915_audio_component_audio_ops struct
cannot be nested.
Signed-off-by: David Henningsson
---
Note that I didn't do the same un-nesting for i915_audio_component_ops.
This is to make it easier to merge the pending sync_audio_rate patch set.
It applies on top of my just sent patches so should probably be taken
through Takashi's tree.
Documentation/DocBook/drm.tmpl | 1 +
include/drm/i915_component.h | 33 +++--
2 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 2fb9a54..7554679 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -4048,6 +4048,7 @@ int num_ioctls;
High Definition Audio
!Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and
Display Port
!Idrivers/gpu/drm/i915/intel_audio.c
+!Iinclude/drm/i915_component.h
Panel Self Refresh PSR (PSR/SRD)
diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
index b2d56dd..89d6362 100644
--- a/include/drm/i915_component.h
+++ b/include/drm/i915_component.h
@@ -24,6 +24,28 @@
#ifndef _I915_COMPONENT_H_
#define _I915_COMPONENT_H_
+/**
+ * struct i915_audio_component_audio_ops - i915 directly calling hda driver
+ *
+ * @audio_ptr: Pointer to pass when calling pin_eld_notify.
+ * @pin_eld_notify: Called from i915 driver, notifying the HDA driver that
+ * pin sense and/or ELD information has changed.
+ *
+ * These functions are implemented by hda driver and called by the i915
+ * driver.
+ */
+struct i915_audio_component_audio_ops {
+ void *audio_ptr;
+ void (*pin_eld_notify)(void *audio_ptr, int port);
+};
+
+/**
+ * struct i915_audio_component - Used for direct communication between i915
and hda drivers
+ *
+ * @dev: i915 device, used as parameter for ops
+ * @ops: Ops implemented by i915 driver, called by hda driver
+ * @audio_ops: Ops implemented by hda driver, called by i915 driver
+ */
struct i915_audio_component {
struct device *dev;
@@ -35,16 +57,7 @@ struct i915_audio_component {
int (*get_cdclk_freq)(struct device *);
} *ops;
- const struct i915_audio_component_audio_ops {
- void *audio_ptr;
- /**
-* Call from i915 driver, notifying the HDA driver that
-* pin sense and/or ELD information has changed.
-* @audio_ptr: HDA driver object
-* @port: Which port has changed (PORTA / PORTB /
PORTC etc)
-*/
- void (*pin_eld_notify)(void *audio_ptr, int port);
- } *audio_ops;
+ const struct i915_audio_component_audio_ops *audio_ops;
};
#endif /* _I915_COMPONENT_H_ */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Future proof uncore_init.
On Wed, Sep 02, 2015 at 03:19:25PM -0700, Rodrigo Vivi wrote:
> Unless future specs tells otherwise we can assume future gens
> inherit some stuff from the previous so let's handle
> missed cases when we know tehy should't be there and assume
> default equals newest one.
>
> No functional changes.
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index dec20d6..e633d36 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1202,8 +1202,6 @@ void intel_uncore_init(struct drm_device *dev)
>
> switch (INTEL_INFO(dev)->gen) {
> default:
> - MISSING_CASE(INTEL_INFO(dev)->gen);
> - return;
> case 9:
> ASSIGN_WRITE_MMIO_VFUNCS(gen9);
> ASSIGN_READ_MMIO_VFUNCS(gen9);
> @@ -1242,6 +1240,10 @@ void intel_uncore_init(struct drm_device *dev)
> ASSIGN_WRITE_MMIO_VFUNCS(gen2);
> ASSIGN_READ_MMIO_VFUNCS(gen2);
> break;
> + case 1:
> + case 0:
> + MISSING_CASE(INTEL_INFO(dev)->gen);
> + return;
Seems pointless, and confusing since we don't support gen0-1.
> }
>
> if (intel_vgpu_active(dev)) {
> --
> 2.4.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] watermark problem in kernel 3.14
On Thu, Sep 03, 2015 at 10:33:44AM +0300, Jani Nikula wrote: > On Thu, 03 Sep 2015, "Xie, William" wrote: > > We suspect watermark has problem in kernel 3.14, > > Does anyone have a new watermark patch for 3.14 similar as below patch: > > http://patchwork.freedesktop.org/bundle/anderco/matt-watermarks/ > > Obviously can't speak for everyone out there, but the educated guess is > no, nobody is working on watermark code for v3.14. You should try > upgrading to newer kernels, even if only to see if the problems you're > experiencing go away. The only tree with properly done watermark updates was my watermark branch. Since gitorious has died I suppose my branches have disappeared too. Fortunately I have it all locally still, so I pushed something to git://github.com/vsyrjala/linux.git watermarks_intm_33 That looked to be one of the last versions of that code that may actually have been tested. After that a bunch of skl code landed in the middle of the wm code and the rebase became very painful, and apparently I never finished it properly (juddging by what I have in later versions of the branch). -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/skl+: Add YUV pixel format in Capability list
GEN >= 9 supports YUV format for all planes, but it's not exported in
Capability list of primary plane. Add YUV formats in skl_primary_formats
list.
Testcase: igt/kms_universal_plane.c
Signed-off-by: Kumar, Mahesh
Cc: Konduru, Chandra
---
drivers/gpu/drm/i915/intel_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0377520..5ab8a1a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,10 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_ABGR,
DRM_FORMAT_XRGB2101010,
DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
};
/* Cursor formats */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/skl: Avoid using un-initialized bits_per_pixel
Don't rely on fb->bits_per_pixel as intel_framebuffer_init is not
filling bits_per_pixel field of fb-struct for YUV pixel format.
This leads to divide by zero error during watermark calculation.
Signed-off-by: Kumar, Mahesh
Cc: Konduru, Chandra
---
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ea49661..1b90f03 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3170,7 +3170,8 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
if (fb) {
p->plane[0].enabled = true;
p->plane[0].bytes_per_pixel = fb->pixel_format ==
DRM_FORMAT_NV12 ?
- drm_format_plane_cpp(fb->pixel_format, 1) :
fb->bits_per_pixel / 8;
+ drm_format_plane_cpp(fb->pixel_format, 1) :
+ drm_format_plane_cpp(fb->pixel_format, 0);
p->plane[0].y_bytes_per_pixel = fb->pixel_format ==
DRM_FORMAT_NV12 ?
drm_format_plane_cpp(fb->pixel_format, 0) : 0;
p->plane[0].tiling = fb->modifier[0];
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug
On Thu, 03 Sep 2015, Takashi Iwai wrote: > Argh, that's bad. Could you post incremental patches to correct to > v5? > > At the next time please put revision number in the patch itself, not > only in cover letter. You can do it with --subject-prefix option of > git-format-patch. FWIW you can also use -vN (i.e. -v5 in this case) parameter. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix cmdparser STORE/LOAD command descriptors
On 02/09/2015 12:29, Chris Wilson wrote:
Fixes regression from
commit f1afe24f0e736b9d7f2275e2b1504af3fe612f2a
Author: Arun Siluvery
Date: Tue Aug 4 16:22:20 2015 +0100
drm/i915: Change SRM, LRM instructions to use correct length
which forgot to account for the length bias when declaring the fixed
length.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91844
Reported-by: Andreas Reis
Signed-off-by: Chris Wilson
Cc: Dave Gordon
Cc: Arun Siluvery
Cc: Mika Kuoppala
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index ad7d7ab76d3f..09932cab1a3f 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -124,14 +124,14 @@ static const struct drm_i915_cmd_descriptor common_cmds[]
= {
CMD( MI_STORE_DWORD_INDEX, SMI, !F, 0xFF, R ),
CMD( MI_LOAD_REGISTER_IMM(1), SMI, !F, 0xFF, W,
.reg = { .offset = 1, .mask = 0x007C, .step = 2 }),
- CMD( MI_STORE_REGISTER_MEM,SMI,F, 1, W | B,
+ CMD( MI_STORE_REGISTER_MEM,SMI,F, 3, W | B,
.reg = { .offset = 1, .mask = 0x007C },
.bits = {{
.offset = 0,
.mask = MI_GLOBAL_GTT,
.expected = 0,
}}, ),
- CMD( MI_LOAD_REGISTER_MEM, SMI,F, 1, W | B,
+ CMD( MI_LOAD_REGISTER_MEM, SMI,F, 3, W | B,
.reg = { .offset = 1, .mask = 0x007C },
.bits = {{
.offset = 0,
My mistake, I should have verified on Gen7 hw.
Reviewed-by: Arun Siluvery
regards
Arun
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug
On 2015-09-03 10:31, Takashi Iwai wrote: On Thu, 03 Sep 2015 09:52:00 +0200, David Henningsson wrote: On 2015-08-28 19:02, David Henningsson wrote: Hopefully last version? :-) * Added commit text about duplicate events (patch 4/4) * Added locks in bind/unbind on i915 side (patch 2/4) * Fixed docbook comments in i915 struct (patch 1/4) * Removed port_mst_streaming parameter (patch 1/4) * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi. Hopefully this was correct, otherwise feel free to adjust yourself before committing. Hi Takashi, Thanks for finally merging it. Just want to make you aware that it seems like you merged v4 instead of v5, so the changes mentioned above did not make it in. Anything either you or I should do about that? Argh, that's bad. Could you post incremental patches to correct to v5? Posted now. To avoid spamming it was to you and the alsa-devel ML only. http://mailman.alsa-project.org/pipermail/alsa-devel/2015-September/097216.html At the next time please put revision number in the patch itself, not only in cover letter. You can do it with --subject-prefix option of git-format-patch. Ok, will try to remember :-) -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix broken mst get_hw_state.
On Wed, 2015-09-02 at 16:14 +0200, Maarten Lankhorst wrote:
> Op 02-09-15 om 16:07 schreef Ander Conselvan De Oliveira:
> > On Thu, 2015-08-27 at 13:13 +0200, Maarten Lankhorst wrote:
> > > connector->encoder is initialized as NULL. Fix this by setting it in
> > > during pre enable. MST connectors are not read out during initial hw
> > > readout, and have no fixed encoder mappings. So it's harmless to
> > > return false when the connector has never been assigned to an encoder.
> > >
> > > Signed-off-by: Maarten Lankhorst
> > > ---
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 738178a0ac96..e3922d973db0 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -6283,7 +6283,7 @@ static void intel_connector_check_state(struct
> > > intel_connector
> > > *connector)
> > > connector->base.name);
> > >
> > > if (connector->get_hw_state(connector)) {
> > > - struct drm_encoder *encoder = &connector->encoder->base;
> > > + struct intel_encoder *encoder = connector->encoder;
> > > struct drm_connector_state *conn_state = connector->base.state;
> > >
> > > I915_STATE_WARN(!crtc,
> > > @@ -6295,13 +6295,13 @@ static void intel_connector_check_state(struct
> > > intel_connector
> > > *connector)
> > > I915_STATE_WARN(!crtc->state->active,
> > > "connector is active, but attached crtc isn't\n");
> > >
> > > - if (!encoder)
> > > + if (!encoder || encoder->type == INTEL_OUTPUT_DP_MST)
> > > return;
> > >
> > > - I915_STATE_WARN(conn_state->best_encoder != encoder,
> > > + I915_STATE_WARN(conn_state->best_encoder != &encoder->base,
> > > "atomic encoder doesn't match attached encoder\n");
> > >
> > > - I915_STATE_WARN(conn_state->crtc != encoder->crtc,
> > > + I915_STATE_WARN(conn_state->crtc != encoder->base.crtc,
> > > "attached encoder crtc differs from connector crtc\n");
> > > } else {
> > > I915_STATE_WARN(crtc && crtc->state->active,
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index ebf205462631..d606721b1788 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -159,6 +159,11 @@ static void intel_mst_pre_enable_dp(struct
> > > intel_encoder *encoder)
> > > return;
> > > }
> > >
> > > + /* MST encoders are bound to a crtc, not to a connector,
> > > + * force the mapping here for get_hw_state.
> > > + */
> > > + found->encoder = encoder;
> > > +
> > > DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> > > intel_mst->port = found->port;
> > >
> > > @@ -392,7 +397,7 @@ static const struct drm_encoder_funcs
> > > intel_dp_mst_enc_funcs = {
> > >
> > > static bool intel_dp_mst_get_hw_state(struct intel_connector *connector)
> > > {
> > > - if (connector->encoder) {
> > > + if (connector->encoder && connector->base.state->crtc) {
> > Is this here to cover the case where we disable this connector and assign
> > the encoder to a
> > different
> > connector? I guess this should work since if we disable the connector than
> > crtc will be null,
> > and
> > we'll assign a proper encoder when re-enabling. But now I'm wondering if it
> > would make sense to
> > set
> > connector->encoder back to NULL in post_disable.
> >
> Yes, it's harmless to keep it non-null if conn_state->crtc is checked though.
> Saves another
> pointless loop.
Fair enough.
Reviewed-by: Ander Conselvan de Oliveira
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] tests/gem_storedw_loop: remove redundant ppgtt check
All tests require ppgtt, so checking for it later on has no effect.
Signed-off-by: Thomas Wood
---
tests/gem_storedw_loop.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/tests/gem_storedw_loop.c b/tests/gem_storedw_loop.c
index 1bb276e..08a6ad6 100644
--- a/tests/gem_storedw_loop.c
+++ b/tests/gem_storedw_loop.c
@@ -45,7 +45,6 @@ IGT_TEST_DESCRIPTION("Basic CS check using
MI_STORE_DATA_IMM.");
static drm_intel_bufmgr *bufmgr;
struct intel_batchbuffer *batch;
static drm_intel_bo *target_buffer;
-static int has_ppgtt = 0;
static int devid;
/*
@@ -57,8 +56,6 @@ emit_store_dword_imm(drm_intel_bo *dest, uint32_t val)
{
int cmd;
cmd = MI_STORE_DWORD_IMM;
- if (!has_ppgtt)
- cmd |= MI_MEM_VIRTUAL;
BEGIN_BATCH(4, 0);
OUT_BATCH(cmd);
@@ -163,14 +160,12 @@ igt_main
bufmgr = drm_intel_bufmgr_gem_init(fd, 4096);
igt_assert(bufmgr);
- has_ppgtt = gem_uses_aliasing_ppgtt(fd);
-
igt_skip_on_f(intel_gen(devid) < 6,
"MI_STORE_DATA can only use GTT address on
gen4+/g33 and "
"needs snoopable mem on pre-gen6\n");
/* This only works with ppgtt */
- igt_require(has_ppgtt);
+ igt_require(gem_uses_aliasing_ppgtt(fd));
}
for (i = 0; i < ARRAY_SIZE(rings); i++) {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] tests/gem_storedw_loop: skip on gen6 bsd
Signed-off-by: Thomas Wood
---
tests/gem_storedw_loop.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/tests/gem_storedw_loop.c b/tests/gem_storedw_loop.c
index 2263397..1bb276e 100644
--- a/tests/gem_storedw_loop.c
+++ b/tests/gem_storedw_loop.c
@@ -144,6 +144,14 @@ struct ring {
{ "vebox", I915_EXEC_VEBOX },
};
+static void
+check_test_requirements(int fd, int ringid)
+{
+ gem_require_ring(fd, ringid);
+ igt_skip_on_f(intel_gen(devid) == 6 && ringid == I915_EXEC_BSD,
+ "MI_STORE_DATA broken on gen6 bsd\n");
+}
+
igt_main
{
int fd, i;
@@ -166,13 +174,14 @@ igt_main
}
for (i = 0; i < ARRAY_SIZE(rings); i++) {
+
igt_subtest_f("basic-%s", rings[i].name) {
- gem_require_ring(fd, rings[i].id);
+ check_test_requirements(fd, rings[i].id);
store_test(rings[i].id, 16*1024);
}
igt_subtest_f("long-%s", rings[i].name) {
- gem_require_ring(fd, rings[i].id);
+ check_test_requirements(fd, rings[i].id);
store_test(rings[i].id, 1024*1024);
}
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug
On Thu, 03 Sep 2015 09:52:00 +0200, David Henningsson wrote: > > > > On 2015-08-28 19:02, David Henningsson wrote: > > Hopefully last version? :-) > > > > * Added commit text about duplicate events (patch 4/4) > > * Added locks in bind/unbind on i915 side (patch 2/4) > > * Fixed docbook comments in i915 struct (patch 1/4) > > * Removed port_mst_streaming parameter (patch 1/4) > > * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi. > > Hopefully this was correct, otherwise feel free to adjust > > yourself before committing. > > Hi Takashi, > > Thanks for finally merging it. Just want to make you aware that it seems > like you merged v4 instead of v5, so the changes mentioned above did not > make it in. Anything either you or I should do about that? Argh, that's bad. Could you post incremental patches to correct to v5? At the next time please put revision number in the patch itself, not only in cover letter. You can do it with --subject-prefix option of git-format-patch. thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: force full detect on sink count change
On 9/2/2015 2:43 PM, Daniel Vetter wrote:
On Thu, Aug 27, 2015 at 02:18:32PM +0530, Sivakumar Thulasimani wrote:
From: "Thulasimani,Sivakumar"
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)
Signed-off-by: Sivakumar Thulasimani
That's still incomplete since in the hotplug work function we check
whether ->detect status has changed. If that doesn't happen (e.g. sink
count changes from 1->2 or whatever) then we'll fail to generate the
required uevent.
I suspect the only clean way to fix this is to merge all the dp hpd
handling together into one place and stop using ->detect for some parts of
it. Then we would have one place only that decides whether anything
changed, and whether we need to send anything to userspace or not.
-Daniel
i doubt sink count change from 1->2 is valid.
1) we support only edp and SST displays in intel_dp_detect.
we should handle all mst related code in intel_dp_hpd_pulse.
2) check_link_status is called from withing !mst check so i dont see it
change from 1 to 2.
3) even if it changes from 1 to 2, for the given port without mst there
is no way to
switch between first sink to second one outside mst logic.
correct me if i am wrong, the only reason to call intel_dp_detect is to
see if
"one display is connected or disconnected" which i feel is fine with
current code.
But i do agree that we need to clean up intel_dp_hpd_pulse since it does
a lot of things
then repeats those same operations in intel_dp_detect. for example we
read dpcd 0-14,
link status and probe oui only to repeat the same steps in the
intel_dp_detect. considering
that our dpcd read has 1ms delay this can add up pretty quick.
if the intention of intel_dp_hpd_pulse is to handle mst displays, that
should be checked first
and continue only if display is mst otherwise we should just jump to
intel_dp_detect.
---
drivers/gpu/drm/i915/intel_dp.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 834f513..279e52c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4370,26 +4370,39 @@ go_again:
* 4. Check link status on receipt of hot-plug interrupt
*/
static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool
*perform_full_detect)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
u8 sink_irq_vector;
+ u8 old_sink_count = intel_dp->sink_count;
+ bool ret;
u8 link_status[DP_LINK_STATUS_SIZE];
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
+ *perform_full_detect = false;
+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
}
- /* Now read the DPCD to see if it's actually running */
- if (!intel_dp_get_dpcd(intel_dp)) {
+ /* Now read the DPCD to see if it's actually running
+* Don't return immediately if dpcd read failed,
+* if sink count was 1 and dpcd read failed we need
+* to do full detection
+*/
+ ret = intel_dp_get_dpcd(intel_dp);
+
+ if (old_sink_count != intel_dp->sink_count)
+ *perform_full_detect = true;
+
+ /* No need to proceed if we are going to do full detect */
+ if (!ret || *perform_full_detect)
return;
- }
if (!intel_encoder->base.crtc)
return;
@@ -5031,13 +5044,17 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
}
if (!intel_dp->is_mst) {
+ bool full_detect;
/*
* we'll check the link status via the normal hot plug
path later -
* but for short hpds we should check it now
*/
drm_modeset_lock(&dev->mode_config.connection_mutex,
NULL);
- intel_dp_check_link_status(intel_dp);
+ intel_dp_check_link_status(intel_dp, &full_detect);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ if (full_detect)
+ goto put_power;
}
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.free
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/dp: use the drm dp helper for determining sink tps3 support
On Tue, 01 Sep 2015, Daniel Vetter wrote: > On Thu, Aug 27, 2015 at 01:25:37PM +0300, Jani Nikula wrote: >> No functional changes. >> >> Signed-off-by: Jani Nikula > > Merged the first 2 patches to dinq (rebased on top of the drm dp helper as > the series originally did). But can't merge more since this depends upon > the tp3 reverts in dinf, so need a suitable backmerge first. Okay, when you get to it, I've sent the remaining patches rebased on top of nightly [1]. BR, Jani. [1] http://mid.gmane.org/cover.1441267909.git.jani.nik...@intel.com -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [REBASED PATCH 3/3] drm/i915: use the yesno helper for logging
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
3 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4563f8b955ea..41629faaf939 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1382,17 +1382,16 @@ static int ironlake_drpc_info(struct seq_file *m)
intel_runtime_pm_put(dev_priv);
mutex_unlock(&dev->struct_mutex);
- seq_printf(m, "HD boost: %s\n", (rgvmodectl & MEMMODE_BOOST_EN) ?
- "yes" : "no");
+ seq_printf(m, "HD boost: %s\n", yesno(rgvmodectl & MEMMODE_BOOST_EN));
seq_printf(m, "Boost freq: %d\n",
(rgvmodectl & MEMMODE_BOOST_FREQ_MASK) >>
MEMMODE_BOOST_FREQ_SHIFT);
seq_printf(m, "HW control enabled: %s\n",
- rgvmodectl & MEMMODE_HWIDLE_EN ? "yes" : "no");
+ yesno(rgvmodectl & MEMMODE_HWIDLE_EN));
seq_printf(m, "SW control enabled: %s\n",
- rgvmodectl & MEMMODE_SWMODE_EN ? "yes" : "no");
+ yesno(rgvmodectl & MEMMODE_SWMODE_EN));
seq_printf(m, "Gated voltage change: %s\n",
- rgvmodectl & MEMMODE_RCLK_GATE ? "yes" : "no");
+ yesno(rgvmodectl & MEMMODE_RCLK_GATE));
seq_printf(m, "Starting frequency: P%d\n",
(rgvmodectl & MEMMODE_FSTART_MASK) >> MEMMODE_FSTART_SHIFT);
seq_printf(m, "Max P-state: P%d\n",
@@ -1401,7 +1400,7 @@ static int ironlake_drpc_info(struct seq_file *m)
seq_printf(m, "RS1 VID: %d\n", (crstandvid & 0x3f));
seq_printf(m, "RS2 VID: %d\n", ((crstandvid >> 8) & 0x3f));
seq_printf(m, "Render standby enabled: %s\n",
- (rstdbyctl & RCX_SW_EXIT) ? "no" : "yes");
+ yesno(!(rstdbyctl & RCX_SW_EXIT)));
seq_puts(m, "Current RS state: ");
switch (rstdbyctl & RSX_STATUS_MASK) {
case RSX_STATUS_ON:
@@ -2844,8 +2843,7 @@ static void intel_dp_info(struct seq_file *m,
struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base);
seq_printf(m, "\tDPCD rev: %x\n", intel_dp->dpcd[DP_DPCD_REV]);
- seq_printf(m, "\taudio support: %s\n", intel_dp->has_audio ? "yes" :
- "no");
+ seq_printf(m, "\taudio support: %s\n", yesno(intel_dp->has_audio));
if (intel_encoder->type == INTEL_OUTPUT_EDP)
intel_panel_info(m, &intel_connector->panel);
}
@@ -2856,8 +2854,7 @@ static void intel_hdmi_info(struct seq_file *m,
struct intel_encoder *intel_encoder = intel_connector->encoder;
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&intel_encoder->base);
- seq_printf(m, "\taudio support: %s\n", intel_hdmi->has_audio ? "yes" :
- "no");
+ seq_printf(m, "\taudio support: %s\n", yesno(intel_hdmi->has_audio));
}
static void intel_lvds_info(struct seq_file *m,
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44e753d5f7f5..45ab25e479ae 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4014,8 +4014,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
}
DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
- intel_dp_source_supports_hbr2(dev) ? "yes" : "no",
- drm_dp_tps3_supported(intel_dp->dpcd) ? "yes" : "no");
+ yesno(intel_dp_source_supports_hbr2(dev)),
+ yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
/* Intermediate frequency support */
if (is_edp(intel_dp) &&
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ea4966144650..b2fbd819559f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5549,7 +5549,7 @@ static void cherryview_enable_rps(struct drm_device *dev)
/* RPS code assumes GPLL is used */
WARN_ONCE((val & GPLLENABLE) == 0, "GPLL not enabled\n");
- DRM_DEBUG_DRIVER("GPLL enabled? %s\n", val & GPLLENABLE ? "yes" : "no");
+ DRM_DEBUG_DRIVER("GPLL enabled? %s\n", yesno(val & GPLLENABLE));
DRM_DEBUG_DRIVER("GPU status: 0x%08x\n", val);
dev_priv->rps.cur_freq = (val >> 8) & 0xff;
@@ -5639,7 +5639,7 @@ static void valleyview_enable_rps(struct drm_device *dev)
/* RPS code assumes GPLL is used */
WARN_ONCE((val & GPLLENABLE) == 0, "GPLL not enabled\n");
- DRM_DEBUG_DRIVER("GPLL enabled? %s\n", val & GPLLENABLE ? "yes" : "no");
+ DRM_DEBUG_DRIVER("GPLL enabled? %s\n", yesno(val & GPLLENABLE));
DRM_DEBUG_DRIVER("GPU status: 0x%08x\n", val);
dev_priv->rps.cur_freq = (val >> 8) & 0xff;
--
2.1.4
__
[Intel-gfx] [REBASED PATCH 0/3] drm/i915: tps3 updates, use yesno helper
The remaining patches from [1] rebased on top of current nightly for convenience. Just s/intel_dp_tps3_supported/drm_dp_tps3_supported/g. BR, Jani. [1] http://mid.gmane.org/1440671138-17174-1-git-send-email-jani.nik...@intel.com Jani Nikula (3): drm/i915/dp: move TPS3 logic to where it's used drm/i915: ignore link rate in TPS3 selection drm/i915: use the yesno helper for logging drivers/gpu/drm/i915/i915_debugfs.c | 17 +++-- drivers/gpu/drm/i915/intel_dp.c | 32 ++-- drivers/gpu/drm/i915/intel_drv.h| 1 - drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 4 files changed, 27 insertions(+), 27 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [REBASED PATCH 2/3] drm/i915: ignore link rate in TPS3 selection
TPS3 is mandatory for downstream devices that support HBR2, and Intel
platforms that support HBR2 also support TPS3. Whenever TPS3 is
supported by both the source and sink, it should be used. In other
words, whenever the source and sink are capable of 5.4 Gbps link, we
should anyway go for TPS3, regardless of the link rate being selected.
Log an error if the sink has advertized HBR2 capability without TPS3
capability.
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9a6fb5dbf021..44e753d5f7f5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3828,10 +3828,11 @@ intel_dp_complete_link_train(struct intel_dp *intel_dp)
* Due to WaDisableHBR2 SKL < B0 is the only exception where TPS3 is
* supported but still not enabled.
*/
- if (intel_dp->link_rate == 54 ||
- (intel_dp_source_supports_hbr2(dev) &&
-drm_dp_tps3_supported(intel_dp->dpcd)))
+ if (intel_dp_source_supports_hbr2(dev) &&
+ drm_dp_tps3_supported(intel_dp->dpcd))
training_pattern = DP_TRAINING_PATTERN_3;
+ else if (intel_dp->link_rate == 54)
+ DRM_ERROR("5.4 Gbps link rate without HBR2/TPS3 support\n");
/* channel equalization */
if (!intel_dp_set_link_train(intel_dp, &DP,
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [REBASED PATCH 1/3] drm/i915/dp: move TPS3 logic to where it's used
There is no need to have a separate flag for tps3 as the information is
only used at one location. Move the logic there to make it easier to
follow.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 31 +--
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f8f4d99440c1..9a6fb5dbf021 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3812,13 +3812,25 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
void
intel_dp_complete_link_train(struct intel_dp *intel_dp)
{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
bool channel_eq = false;
int tries, cr_tries;
uint32_t DP = intel_dp->DP;
uint32_t training_pattern = DP_TRAINING_PATTERN_2;
- /* Training Pattern 3 for HBR2 or 1.2 devices that support it*/
- if (intel_dp->link_rate == 54 || intel_dp->use_tps3)
+ /*
+* Training Pattern 3 for HBR2 or 1.2 devices that support it.
+*
+* Intel platforms that support HBR2 also support TPS3. TPS3 support is
+* also mandatory for downstream devices that support HBR2.
+*
+* Due to WaDisableHBR2 SKL < B0 is the only exception where TPS3 is
+* supported but still not enabled.
+*/
+ if (intel_dp->link_rate == 54 ||
+ (intel_dp_source_supports_hbr2(dev) &&
+drm_dp_tps3_supported(intel_dp->dpcd)))
training_pattern = DP_TRAINING_PATTERN_3;
/* channel equalization */
@@ -4000,18 +4012,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
}
}
- /* Training Pattern 3 support, Intel platforms that support HBR2 alone
-* have support for TP3 hence that check is used along with dpcd check
-* to ensure TP3 can be enabled.
-* SKL < B0: due it's WaDisableHBR2 is the only exception where TP3 is
-* supported but still not enabled.
-*/
- if (drm_dp_tps3_supported(intel_dp->dpcd) &&
- intel_dp_source_supports_hbr2(dev)) {
- intel_dp->use_tps3 = true;
- DRM_DEBUG_KMS("Displayport TPS3 supported\n");
- } else
- intel_dp->use_tps3 = false;
+ DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
+ intel_dp_source_supports_hbr2(dev) ? "yes" : "no",
+ drm_dp_tps3_supported(intel_dp->dpcd) ? "yes" : "no");
/* Intermediate frequency support */
if (is_edp(intel_dp) &&
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cf971ef60633..46484e4ac1cd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -746,7 +746,6 @@ struct intel_dp {
enum pipe pps_pipe;
struct edp_power_seq pps_delays;
- bool use_tps3;
bool can_mst; /* this port supports mst */
bool is_mst;
int active_mst_links;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug
On 2015-08-28 19:02, David Henningsson wrote: Hopefully last version? :-) * Added commit text about duplicate events (patch 4/4) * Added locks in bind/unbind on i915 side (patch 2/4) * Fixed docbook comments in i915 struct (patch 1/4) * Removed port_mst_streaming parameter (patch 1/4) * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi. Hopefully this was correct, otherwise feel free to adjust yourself before committing. Hi Takashi, Thanks for finally merging it. Just want to make you aware that it seems like you merged v4 instead of v5, so the changes mentioned above did not make it in. Anything either you or I should do about that? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes
On Thu, Aug 27, 2015 at 05:23:29PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > A address-only I2C_WRITE can't be replied with a short i2c ack, but I > suppose it could be replied with an i2c defer. So the code should be > prepared for an address-only I2C_WRITE_STATUS_UPDATE. > > Cc: Thierry Reding > Cc: "Terje Bergström" > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/tegra/dpaux.c | 1 + > 1 file changed, 1 insertion(+) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add GuC css header parser
On Thu, 03 Sep 2015, yu@intel.com wrote:
> From: Alex Dai
>
> By using information from GuC css header, we can eliminate some
> hard code w.r.t size of some components of firmware.
>
> Signed-off-by: Alex Dai
> ---
> drivers/gpu/drm/i915/intel_guc.h| 2 +-
> drivers/gpu/drm/i915/intel_guc_fwif.h | 36 +
> drivers/gpu/drm/i915/intel_guc_loader.c | 91
> ++---
> 3 files changed, 98 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc.h
> b/drivers/gpu/drm/i915/intel_guc.h
> index 4ec2d27..e1389fc 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -71,6 +71,7 @@ struct intel_guc_fw {
> struct drm_i915_gem_object *guc_fw_obj;
> enum intel_guc_fw_statusguc_fw_fetch_status;
> enum intel_guc_fw_statusguc_fw_load_status;
> + struct guc_css_header guc_fw_header;
>
> uint16_tguc_fw_major_wanted;
> uint16_tguc_fw_minor_wanted;
> @@ -80,7 +81,6 @@ struct intel_guc_fw {
>
> struct intel_guc {
> struct intel_guc_fw guc_fw;
> -
> uint32_t log_flags;
> struct drm_i915_gem_object *log_obj;
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
> b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index e1f47ba..d6cb4e8 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -122,6 +122,42 @@
>
> #define GUC_CTL_MAX_DWORDS (GUC_CTL_RSRVD + 1)
>
> +struct guc_css_header {
> + uint32_t module_type;
> + uint32_t header_len; /* header length plus size of all other keys */
> + uint32_t header_version;
> + uint32_t module_id;
> + uint32_t module_vendor;
> + union {
> + struct {
> + uint8_t day;
> + uint8_t month;
> + uint16_t year;
> + };
> + uint32_t date;
> + };
> + uint32_t size; /* uCode size plus header_len */
> + uint32_t key_size;
> + uint32_t modulus_size;
> + uint32_t exponent_size;
> + union {
> + struct {
> + uint8_t hour;
> + uint8_t min;
> + uint16_t sec;
> + };
> + uint32_t time;
> + };
> +
> + char username[8];
> + char buildnumber[12];
> + uint32_t device_id;
> + uint32_t guc_sw_version;
> + uint32_t prod_preprod_fw;
> + uint32_t reserved[12];
> + uint32_t header_info;
> +};
Drive-by review, this will need __packed.
BR,
Jani.
> +
> struct guc_doorbell_info {
> u32 db_status;
> u32 cookie;
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 5823615..96826ae 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -215,18 +215,24 @@ static inline bool guc_ucode_response(struct
> drm_i915_private *dev_priv,
> ((val & GS_MIA_CORE_STATE) && uk_val == GS_UKERNEL_LAPIC_DONE));
> }
>
> -/*
> +/**
> * Transfer the firmware image to RAM for execution by the microcontroller.
> *
> * GuC Firmware layout:
> - * +---+
> - * | CSS header | 128B
> + * +---+
> + * |guc_css_header |
> * | contains major/minor version |
> - * +---+
> + * +---+
> * | uCode |
> - * +---+
> - * | RSA signature | 256B
> - * +---+
> + * +---+
> + * | RSA signature |
> + * +---+
> + * | modulus key |
> + * +---+
> + * | exponent val |
> + * +---+
> + * The firmware may or may not have modulus key and exponent data. The
> header,
> + * uCode and RSA signature are must-have components that will be used by
> driver.
> *
> * Architecturally, the DMA engine is bidirectional, and can potentially even
> * transfer between GTT locations. This functionality is left out of the API
> @@ -236,30 +242,39 @@ static inline bool guc_ucode_response(struct
> drm_i915_private *dev_priv,
> * DMA engine in one operation, whereas the RSA signature is loaded via MMIO.
> */
>
> -#define UOS_CSS_HEADER_OFFSET0
> -#define UOS_VER_MINOR_OFFSET 0x44
> -#define UOS_VER_MAJOR_OFFSET 0x46
> -#define UOS_CSS_HEADER_SIZE 0x80
> -#define UOS_RSA_SIG_SIZE 0x100
> -
> static int guc_ucode_xfer_dma(struct drm_i915_private *dev_priv)
> {
> struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
> + struct guc_css_header *header = &guc_fw->guc_fw_header;
> s
Re: [Intel-gfx] watermark problem in kernel 3.14
On Thu, 03 Sep 2015, "Xie, William" wrote: > We suspect watermark has problem in kernel 3.14, > Does anyone have a new watermark patch for 3.14 similar as below patch: > http://patchwork.freedesktop.org/bundle/anderco/matt-watermarks/ Obviously can't speak for everyone out there, but the educated guess is no, nobody is working on watermark code for v3.14. You should try upgrading to newer kernels, even if only to see if the problems you're experiencing go away. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
