Re: [Intel-gfx] [alsa-devel] [PATCH 3/4] ALSA: hda - display audio call ncts callback
>
> > -Original Message-
> > From: Takashi Iwai [mailto:ti...@suse.de]
> > Sent: Thursday, August 06, 2015 6:03 PM
> > To: Yang, Libin
> > Cc: alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Lin,
> > Mengdong
> > Subject: Re: [PATCH 3/4] ALSA: hda - display audio call ncts callback
> >
> > On Thu, 06 Aug 2015 08:52:56 +0200,
> > libin.y...@intel.com wrote:
> > >
> > > From: Libin Yang
> > >
> > > On some Intel platforms, display audio need set N/CTS
> > > manually at some TMDS frequencies.
> > >
> > > Signed-off-by: Libin Yang
> > > ---
> > > sound/pci/hda/patch_hdmi.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/sound/pci/hda/patch_hdmi.c
> > b/sound/pci/hda/patch_hdmi.c
> > > index a97db5f..4bd11ff 100644
> > > --- a/sound/pci/hda/patch_hdmi.c
> > > +++ b/sound/pci/hda/patch_hdmi.c
> > > @@ -1786,6 +1786,8 @@ static int
> > generic_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo,
> > > int pin_idx = hinfo_to_pin_index(codec, hinfo);
> > > struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx);
> > > hda_nid_t pin_nid = per_pin->pin_nid;
> > > + struct snd_pcm_runtime *runtime = substream->runtime;
> > > + struct i915_audio_component *acomp = codec->bus-
> > >core.audio_component;
> > > bool non_pcm;
> > > int pinctl;
> > >
> > > @@ -1802,6 +1804,11 @@ static int
> > generic_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo,
> > > intel_not_share_assigned_cvt(codec, pin_nid, per_pin-
> > >mux_idx);
> > > }
> > >
> > > + if (is_haswell_plus(codec)) {
> > > + if (acomp && acomp->ops && acomp->ops->set_ncts)
> > > + acomp->ops->set_ncts(acomp->dev, per_pin-
> > >pin_nid - 4,
> >
> > Please describe more how "pin_nid - 4" is supposed to work. Also...
>
> OK, I see.
>
> >
> > > + 0, runtime->rate);
> >
> > ... this implies that no MST support included?
>
> We will support MST later. Currently I just add the
> interface to support MST, but not implementing it.
Refer to DCN HDA040-A
Multi-stream over Single Display Port
Can the driver use subdevices for those display port support multi
streaming ?
The specification allow up to 64 device entries
This mean the number of subdevices is equal to the device list length
More than one audio output /converters can be connected to the multi stream
displayport pin widget but different device entry while only one audio
output can be dynamically allocated to other HDMI pin widget
7.3.3.42 Device Select
For Digital Display Pin Widget that is multi stream capable, the Device
Select control determines which Device Entry is currently selected and
accessible by the Pin Widget verbs which are controlling the sink device
operations. This control verb is only required if it is a Digital Display
Pin Widget and multi stream capable.
The index is in relation to the Device List associated with the widget.
The index is a zero-based offset into the Device List. Once the Device
Entry is selected by the Set index, all subsequent Pin Widget verbs
controlling the sink device operations will be directed to the selected
Device Entry, until the Device Select verb get updated with a new value.
Device Entry: Indicate the index of Device Entry (0 63) which the UR bit of
is generated for a multi stream capable Digital Display Pin Widget. Not
valid for non Digital Display Pin Widget or Digital Display Pin Widget that
is not multi stream capable
Device List Length is a 0 based integer value indicating the number of sink
device that a multi stream capable Digital Display Pin Widget can support.
If Device List Length is value is 0, there is only one sink device
connection possible indicating the Pin Widget is not multi stream capable,
and there is no Device Select control (see Section 7.3.3.42). If the
Device List Length value is 1 – 63, it indicates the Pin Widget is multi
stream capable, and 2 – 64 Device Entries are supported in the Pin Widget.
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 2/4] drm/i915: implement set_ncts callback
Hi Takashi,
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Thursday, August 06, 2015 5:21 PM
> To: Yang, Libin
> Cc: alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Lin,
> Mengdong
> Subject: Re: [alsa-devel] [PATCH 2/4] drm/i915: implement set_ncts
> callback
>
> On Thu, 06 Aug 2015 08:52:55 +0200,
> libin.y...@intel.com wrote:
> >
> > From: Libin Yang
> >
> > Display audio may not work at some frequencies
> > with the HW provided N/CTS.
> >
> > This patch sets the proper N value for the
> > given audio sample rate at the impacted frequencies.
> > At other frequencies, it will use the N/CTS value
> > which HW provides.
> >
> > Signed-off-by: Libin Yang
> > ---
> > drivers/gpu/drm/i915/i915_reg.h| 2 +
> > drivers/gpu/drm/i915/intel_audio.c | 93
> ++
> > 2 files changed, 95 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> > index 3a77678..0b1cd72 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7010,6 +7010,8 @@ enum skl_disp_power_wells {
> > _HSW_AUD_MISC_CTRL_A, \
> > _HSW_AUD_MISC_CTRL_B)
> >
> > +#define HSW_AUD_PIPE_CONN_SEL_CTRL 0x650ac
> > +
> > #define _HSW_AUD_DIP_ELD_CTRL_ST_A 0x650b4
> > #define _HSW_AUD_DIP_ELD_CTRL_ST_B 0x651b4
> > #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> > index dc32cf4..f1148cd 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -68,6 +68,28 @@ static const struct {
> > { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> > };
> >
> > +static const struct {
> > + int sample_rate;
> > + int clock;
> > + int n;
> > + int cts;
> > +} aud_ncts[] = {
> > + { 44100, DIV_ROUND_UP(297000 * 1000, 1001), 4459, 234375 },
> > + { 44100, 297000, 4704, 247500 },
>
> As these two clock values are referred repeatedly in other places,
> it'd be better to define constants.
Do you mean use Macro such as:
#define 297MHZ 297000
#define 296MHZ DIV_ROUND_UP(297000 * 1000, 1001)
>
>
> Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] ALSA: hda - display audio call ncts callback
Hi Takashi,
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Thursday, August 06, 2015 6:03 PM
> To: Yang, Libin
> Cc: alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Lin,
> Mengdong
> Subject: Re: [PATCH 3/4] ALSA: hda - display audio call ncts callback
>
> On Thu, 06 Aug 2015 08:52:56 +0200,
> libin.y...@intel.com wrote:
> >
> > From: Libin Yang
> >
> > On some Intel platforms, display audio need set N/CTS
> > manually at some TMDS frequencies.
> >
> > Signed-off-by: Libin Yang
> > ---
> > sound/pci/hda/patch_hdmi.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_hdmi.c
> b/sound/pci/hda/patch_hdmi.c
> > index a97db5f..4bd11ff 100644
> > --- a/sound/pci/hda/patch_hdmi.c
> > +++ b/sound/pci/hda/patch_hdmi.c
> > @@ -1786,6 +1786,8 @@ static int
> generic_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo,
> > int pin_idx = hinfo_to_pin_index(codec, hinfo);
> > struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx);
> > hda_nid_t pin_nid = per_pin->pin_nid;
> > + struct snd_pcm_runtime *runtime = substream->runtime;
> > + struct i915_audio_component *acomp = codec->bus-
> >core.audio_component;
> > bool non_pcm;
> > int pinctl;
> >
> > @@ -1802,6 +1804,11 @@ static int
> generic_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo,
> > intel_not_share_assigned_cvt(codec, pin_nid, per_pin-
> >mux_idx);
> > }
> >
> > + if (is_haswell_plus(codec)) {
> > + if (acomp && acomp->ops && acomp->ops->set_ncts)
> > + acomp->ops->set_ncts(acomp->dev, per_pin-
> >pin_nid - 4,
>
> Please describe more how "pin_nid - 4" is supposed to work. Also...
OK, I see.
>
> > + 0, runtime->rate);
>
> ... this implies that no MST support included?
We will support MST later. Currently I just add the
interface to support MST, but not implementing it.
After we enabled MST, I will submit another patch
to support MST. Currently, it seems the display audio
driver need do some change to support MST.
>
> Overall, it'd be appreciated if you put more information text in
> changelog or comment. it series looks like a black magic to me unless
> clearly explained.
OK, I will add the comments about the details.
>
>
> thanks,
>
> Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Split sink_crc function in start, stop and read.
On Thu, Aug 6, 2015 at 5:20 AM Daniel Vetter wrote:
> On Wed, Aug 05, 2015 at 08:30:01PM +, Vivi, Rodrigo wrote:
> > On Wed, 2015-08-05 at 10:07 +0200, Daniel Vetter wrote:
> > > On Thu, Jul 30, 2015 at 04:26:39PM -0700, Rodrigo Vivi wrote:
> > > > This is just a preparation patch to make clear what operation we
> > > > are performing. There is no functional change on the sink crc
> > > > logic.
> > > >
> > > > hsw_disable_ips has been moved a bit further in the start function
> > > > to avoid disabling ips when sink crc is not going to be started.
> > > > and to avoid goto on this function.
> > > >
> > > > v2: explain why hsw_disable_ips() call place has changed.
> > > >
> > > > Cc: Daniel Vetter
> > > > Reviewed-by: Rafael Antognolli
> > > > Signed-off-by: Rodrigo Vivi
> > >
> > > Thanks for the updated commit message. Queued for -next, thanks for the
> > > patch.
> >
> > Thanks!
> >
> > Do you intend to merge the other 3 remaining patches?
> > Or am I missing something there?
>
> Nah just oversight, merged 3 more patches. Do I have them all now?
>
yes, thanks!
> -Daniel
>
> >
> > Thanks,
> > Rodrigo.
> >
> > > -Daniel
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp.c | 89
> +++--
> > > > 1 file changed, 50 insertions(+), 39 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 44f8a32..10cbc98 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -3958,40 +3958,64 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
> > > > return intel_dp->is_mst;
> > > > }
> > > >
> > > > -int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
> > > > +static void intel_dp_sink_crc_stop(struct intel_dp *intel_dp)
> > > > {
> > > > - struct intel_digital_port *intel_dig_port =
> dp_to_dig_port(intel_dp);
> > > > - struct drm_device *dev = intel_dig_port->base.base.dev;
> > > > - struct intel_crtc *intel_crtc =
> > > > - to_intel_crtc(intel_dig_port->base.base.crtc);
> > > > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > > + struct intel_crtc *intel_crtc =
> to_intel_crtc(dig_port->base.base.crtc);
> > > > u8 buf;
> > > > - int test_crc_count;
> > > > - int attempts = 6;
> > > > - int ret = 0;
> > > > -
> > > > - hsw_disable_ips(intel_crtc);
> > > >
> > > > - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) <
> 0) {
> > > > - ret = -EIO;
> > > > - goto out;
> > > > + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
> > > > + DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> > > > + return;
> > > > }
> > > >
> > > > - if (!(buf & DP_TEST_CRC_SUPPORTED)) {
> > > > - ret = -ENOTTY;
> > > > - goto out;
> > > > - }
> > > > + if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> > > > +buf & ~DP_TEST_SINK_START) < 0)
> > > > + DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> > > >
> > > > - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
> > > > - ret = -EIO;
> > > > - goto out;
> > > > - }
> > > > + hsw_enable_ips(intel_crtc);
> > > > +}
> > > > +
> > > > +static int intel_dp_sink_crc_start(struct intel_dp *intel_dp)
> > > > +{
> > > > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > > + struct intel_crtc *intel_crtc =
> to_intel_crtc(dig_port->base.base.crtc);
> > > > + u8 buf;
> > > > +
> > > > + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0)
> > > > + return -EIO;
> > > > +
> > > > + if (!(buf & DP_TEST_CRC_SUPPORTED))
> > > > + return -ENOTTY;
> > > > +
> > > > + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0)
> > > > + return -EIO;
> > > > +
> > > > + hsw_disable_ips(intel_crtc);
> > > >
> > > > if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> > > > - buf | DP_TEST_SINK_START) < 0) {
> > > > - ret = -EIO;
> > > > - goto out;
> > > > +buf | DP_TEST_SINK_START) < 0) {
> > > > + hsw_enable_ips(intel_crtc);
> > > > + return -EIO;
> > > > }
> > > >
> > > > + return 0;
> > > > +}
> > > > +
> > > > +int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
> > > > +{
> > > > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > > + struct drm_device *dev = dig_port->base.base.dev;
> > > > + struct intel_crtc *intel_crtc =
> to_intel_crtc(dig_port->base.base.crtc);
> > > > + u8 buf;
> > > > + int test_crc_count;
> > > > + int attempts = 6;
> > > > + int ret;
> > > > +
> > > > + ret = intel_dp_sink_crc_start(intel_dp);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) <
> 0) {
> > > > ret = -EIO;
> > > > goto stop;
> > > > @@ -4014,23 +4038,10 @@ int intel_dp_sink_c
Re: [Intel-gfx] Enable PSR in IvyBridge?
On Thu, Aug 6, 2015 at 1:20 PM harrykipper wrote: > Hello, > > I just discovered that Intel introduced PSR with IvyBridge, so I tried > Unfortunately this information is incorrect. There is no PSR on IVB. No single mention in the specs here. > to enable it for my laptop, which has an eDP panel that supports psr. So yes, you might have a panel that supports PSR that came with IVB, but PSR musts be supported on both sides, on panel and on gpu. > The patch is attached (all I do is enable all things IvyBridge, I am > not familiar with the kernel at all, apologies if you see absurdities). > > However, I had *some* success, I have: > > Sink_Support: yes > Source_OK: yes > Enabled: yes > Active: yes > Busy frontbuffer bits: 0x000 > Re-enable work scheduled: no > HW Enabled & Active bit: no > actually this line here tells you didn't have success. > Link standby: no > Performance_Counter: 0 > > and so far I am only seeing one error, whenever the screen is turned > on/off (at boot and when gnome blanks it to save power, for example). > All the problems seem to be in intel_psr_exit() and intel_psr_flush(). > I read in Rodrigo Vivi's blog that a psr test should exist in > intel-gpu-tools, but I couldn't find it. > kms_psr_sink_crc and kms_frontbuffer_tracking can be used to test PSR, but in your case it will probably just test a state machine entry exit with no actual PSR entry/exit on the panel side. > > I am inclined to think that enabling psr for IvyBridge shouldn't be too > hard for someone who knows what they are doing. If someone wants to > take this on I will be happy to test and report bugs, although my > hardware is fairly bizarre. > I would be happy to help if IVB had any PSR related patch... however this is simply impossible. Thanks for the interest, Rodrigo > Best regards > [ cut here ] > kernel: WARNING: CPU: 3 PID: 726 at > drivers/gpu/drm/i915/intel_psr.c:532 intel_psr_exit+0x152/0x160() > kernel: WARN_ON(!(val & EDP_PSR_ENABLE)) > kernel: Modules linked in: > kernel: fuse acpi_call(O) nls_iso8859_15 nls_cp850 vfat fat > snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_cod > kernel: CPU: 3 PID: 726 Comm: Xorg Tainted: G U O4.1.4-eDP > #1 > kernel: Hardware name: LENOVO 2324B14/2324B14, BIOS G2ETA3WW (2.63 ) > 02/05/2015 > kernel: 81718e70 0bfa939c 81718e70 > 815b820b > kernel: 8800c50d7c50 810709a7 8802146c > > kernel: 880214a4a800 880214a4a800 > 81070a38 > kernel: Call Trace: > kernel: [] ? dump_stack+0x47/0x67 > kernel: [] ? warn_slowpath_common+0x77/0xb0 > kernel: [] ? warn_slowpath_fmt+0x58/0x80 > kernel: [] ? intel_psr_exit+0x152/0x160 > kernel: [] ? intel_psr_invalidate+0x42/0x70 > kernel: [] ? intel_fb_obj_invalidate+0xa8/0x110 > kernel: [] ? > i915_gem_object_set_to_gtt_domain+0x127/0x150 > kernel: [] ? i915_gem_fault+0x1e3/0x3f0 > kernel: [] ? __do_fault+0x4a/0xe0 > kernel: [] ? __mem_cgroup_count_vm_event+0x10/0x70 > kernel: [] ? handle_mm_fault+0x438/0x15b0 > kernel: [] ? __fget+0x63/0xa0 > kernel: [] ? recalc_sigpending+0x15/0x50 > kernel: [] ? __set_task_blocked+0x38/0x90 > kernel: [] ? __do_page_fault+0x158/0x3d0 > kernel: [] ? SyS_rt_sigprocmask+0x89/0xd0 > kernel: [] ? page_fault+0x22/0x30 > kernel: ---[ end trace cb3b5b396afe8d4e ]--- > > > ___ > 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] Intel-kms in Linux-4.2rc causes regression due to dithering always on.
On 08/07/2015 12:12 AM, Daniel Vetter wrote: On Thu, Aug 6, 2015 at 11:56 PM, Mario Kleiner wrote: Hi Daniel and all, since Linux 4.2 (tested with rc4), i think this commit d328c9d78d64ca11e744fe227096990430a88477 "drm/i915: Select starting pipe bpp irrespective or the primary plane" causes trouble for me and my users, as tested on Intel HD Ironlake and Ivy Bridge with MiniDP->Singlelink-DVI adapter -> Measurement device. Afaics it causes dithering to always be enabled on a regular 8bpc framebuffer, even when outputting to a 8 bpc DVI-D output, and that dithering causes my display measurement equipment and other special display devices used for neuro-science and medical applications to fail. This equipment requires an identity passthrough of 8 bpc framebuffer pixels to the digital outputs, iow. dithering off. Log output on Linux 4.1 (good): Aug 1 06:39:26 twisty kernel: [ 154.175394] [drm:connected_sink_compute_bpp] [CONNECTOR:35:HDMI-A-1] checking for sink bpp constrains Aug 1 06:39:26 twisty kernel: [ 154.175396] [drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output Aug 1 06:39:26 twisty kernel: [ 154.175397] [drm:intel_hdmi_compute_config] forcing pipe bpc to 24 for HDMI Aug 1 06:39:26 twisty kernel: [ 154.175400] [drm:ironlake_check_fdi_lanes] checking fdi config on pipe A, lanes 1 Aug 1 06:39:26 twisty kernel: [ 154.175402] [drm:intel_modeset_pipe_config] plane bpp: 24, pipe bpp: 24, dithering: 0 Aug 1 06:39:26 twisty kernel: [ 154.175403] [drm:intel_dump_pipe_config] [CRTC:20][modeset] config for pipe A Aug 1 06:39:26 twisty kernel: [ 154.175404] [drm:intel_dump_pipe_config] cpu_transcoder: A Aug 1 06:39:26 twisty kernel: [ 154.175405] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 0 Log output on Linux 4.2-rc4 (bad): Aug 1 06:21:31 twisty kernel: [ 200.924831] [drm:connected_sink_compute_bpp] [CONNECTOR:36:HDMI-A-1] checking for sink bpp constrains Aug 1 06:21:31 twisty kernel: [ 200.924832] [drm:connected_sink_compute_bpp] clamping display bpp (was 36) to default limit of 24 Aug 1 06:21:31 twisty kernel: [ 200.924834] [drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output Aug 1 06:21:31 twisty kernel: [ 200.924835] [drm:intel_hdmi_compute_config] forcing pipe bpc to 24 for HDMI Aug 1 06:21:31 twisty kernel: [ 200.924838] [drm:ironlake_check_fdi_lanes] checking fdi config on pipe A, lanes 1 Aug 1 06:21:31 twisty kernel: [ 200.924840] [drm:intel_modeset_pipe_config] plane bpp: 36, pipe bpp: 24, dithering: 1 Aug 1 06:21:31 twisty kernel: [ 200.924841] [drm:intel_dump_pipe_config] [CRTC:21][modeset] config 880131a5c800 for pipe A Aug 1 06:21:31 twisty kernel: [ 200.924842] [drm:intel_dump_pipe_config] cpu_transcoder: A Aug 1 06:21:31 twisty kernel: [ 200.924843] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 1 Ideas what to do about this? Well I somehow assumed the dither bit would be sane and not wreak havoc with the lower bits when they would fit into the final bpc pipe mode ... Can you confirm with your equipment that we seem to be doing 8bpc->6bpc dithering on the 8bpc sink? It will need a bit of work to find this out when i'm back in the lab. So far i just know something bad is happening to the signal and i assume it's the dithering, because the visual error pattern of messiness looks like that caused by dithering. E.g., on a static framebuffer i see some repeating pattern over the screen, but the pattern changes with every OpenGL bufferswap, even if i swap to the same fb content, as if the swap triggers some change of the spatial dither pattern (assuming PIPECONF_DITHER_TYPE_SP = spatial dithering?) If that's the case we simply limit to only ever dither when the sink is 6bpc, and not in any other case. -Daniel That would be an improvement for my immediate problem if that works. But assuming we have 10 bpc framebuffers at some point, dithering 10 bpc -> 8 bpc would also have some practical use. Probably some dynamic check would be good, a la if there is a mismatch between the max(bpc) over all active planes and the supported depth of the sink then dither? It's not clear to me where the dithering happens on intel hw. I'd expected that with a 24 bpp framebuffer feeding into a 24 bpp pipe, dithering simply wouldn't do anything even if enabled. -mario ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel-kms in Linux-4.2rc causes regression due to dithering always on.
On Thu, Aug 6, 2015 at 11:56 PM, Mario Kleiner wrote: > Hi Daniel and all, > > since Linux 4.2 (tested with rc4), i think this commit > d328c9d78d64ca11e744fe227096990430a88477 > "drm/i915: Select starting pipe bpp irrespective or the primary plane" > > causes trouble for me and my users, as tested on Intel HD Ironlake and Ivy > Bridge with MiniDP->Singlelink-DVI adapter -> Measurement device. > > Afaics it causes dithering to always be enabled on a regular 8bpc > framebuffer, even when outputting to a 8 bpc DVI-D output, and that > dithering causes my display measurement equipment and other special display > devices used for neuro-science and medical applications to fail. This > equipment requires an identity passthrough of 8 bpc framebuffer pixels to > the digital outputs, iow. dithering off. > > Log output on Linux 4.1 (good): > > Aug 1 06:39:26 twisty kernel: [ 154.175394] > [drm:connected_sink_compute_bpp] [CONNECTOR:35:HDMI-A-1] checking for sink > bpp constrains > Aug 1 06:39:26 twisty kernel: [ 154.175396] > [drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output > Aug 1 06:39:26 twisty kernel: [ 154.175397] > [drm:intel_hdmi_compute_config] forcing pipe bpc to 24 for HDMI > Aug 1 06:39:26 twisty kernel: [ 154.175400] [drm:ironlake_check_fdi_lanes] > checking fdi config on pipe A, lanes 1 > Aug 1 06:39:26 twisty kernel: [ 154.175402] > [drm:intel_modeset_pipe_config] plane bpp: 24, pipe bpp: 24, dithering: 0 > Aug 1 06:39:26 twisty kernel: [ 154.175403] [drm:intel_dump_pipe_config] > [CRTC:20][modeset] config for pipe A > Aug 1 06:39:26 twisty kernel: [ 154.175404] [drm:intel_dump_pipe_config] > cpu_transcoder: A > Aug 1 06:39:26 twisty kernel: [ 154.175405] [drm:intel_dump_pipe_config] > pipe bpp: 24, dithering: 0 > > Log output on Linux 4.2-rc4 (bad): > > Aug 1 06:21:31 twisty kernel: [ 200.924831] > [drm:connected_sink_compute_bpp] [CONNECTOR:36:HDMI-A-1] checking for sink > bpp constrains > Aug 1 06:21:31 twisty kernel: [ 200.924832] > [drm:connected_sink_compute_bpp] clamping display bpp (was 36) to default > limit of 24 > Aug 1 06:21:31 twisty kernel: [ 200.924834] > [drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output > Aug 1 06:21:31 twisty kernel: [ 200.924835] > [drm:intel_hdmi_compute_config] forcing pipe bpc to 24 for HDMI > Aug 1 06:21:31 twisty kernel: [ 200.924838] [drm:ironlake_check_fdi_lanes] > checking fdi config on pipe A, lanes 1 > Aug 1 06:21:31 twisty kernel: [ 200.924840] > [drm:intel_modeset_pipe_config] plane bpp: 36, pipe bpp: 24, dithering: 1 > Aug 1 06:21:31 twisty kernel: [ 200.924841] [drm:intel_dump_pipe_config] > [CRTC:21][modeset] config 880131a5c800 for pipe A > Aug 1 06:21:31 twisty kernel: [ 200.924842] [drm:intel_dump_pipe_config] > cpu_transcoder: A > Aug 1 06:21:31 twisty kernel: [ 200.924843] [drm:intel_dump_pipe_config] > pipe bpp: 24, dithering: 1 > > Ideas what to do about this? Well I somehow assumed the dither bit would be sane and not wreak havoc with the lower bits when they would fit into the final bpc pipe mode ... Can you confirm with your equipment that we seem to be doing 8bpc->6bpc dithering on the 8bpc sink? If that's the case we simply limit to only ever dither when the sink is 6bpc, and not in any other case. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm-intel:for-linux-next 479/497] drivers/gpu/drm/i915/i915_gem_gtt.c:1086:26: sparse: Using plain integer as NULL pointer
On Thu, Aug 6, 2015 at 10:17 PM, kbuild test robot wrote: > 1070 if (IS_ENABLED(CONFIG_X86_32)) > 1071 /* While we have a proliferation of size_t variables > 1072 * we cannot represent the full ppgtt size on 32bit, > 1073 * so limit it to the same size as the GGTT (currently > 1074 * 2GiB). > 1075 */ > 1076 ppgtt->base.total = > to_i915(ppgtt->base.dev)->gtt.base.total; > 1077 ppgtt->base.cleanup = gen8_ppgtt_cleanup; > 1078 ppgtt->base.allocate_va_range = gen8_alloc_va_range; > 1079 ppgtt->base.insert_entries = gen8_ppgtt_insert_entries; > 1080 ppgtt->base.clear_range = gen8_ppgtt_clear_range; > 1081 ppgtt->base.unbind_vma = ppgtt_unbind_vma; > 1082 ppgtt->base.bind_vma = ppgtt_bind_vma; > 1083 > 1084 ppgtt->switch_mm = gen8_mm_switch; > 1085 >> 1086 ret = __pdp_init(false, &ppgtt->pdp); So the first argument of pdp_init ist struct drm_device *dev and yes the first thing it does is deref it. How exactly was this tested again? Oh and the hunk right below with the CONFIG_X86_32 needs to got too - if we're 48b safe then we should be 32b safe too ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10 v5] Batch submission via GuC
On Wed, Jul 29, 2015 at 06:48:28PM +0100, Dave Gordon wrote: > This patch series enables command submission via the GuC. In this mode, > instead of the host CPU driving the execlist port directly, it hands > over work items to the GuC, using a doorbell mechanism to tell the GuC > that new items have been added to its work queue. The GuC then dispatches > contexts to the various GPU engines, and manages the resulting context- > switch interrupts. Completion of a batch is however still signalled to > the CPU; the GuC is not involved in handling user interrupts. > > There are two subsequences within the patch series: > > drm/i915: GuC-specific firmware loader > drm/i915: Debugfs interface to read GuC load status > > These two patches provide the GuC loader and a debugfs interface to > verify the resulting state. At this point in the sequence we can load > and activate the GuC firmware, but not submit any batches through it. > (This is nonetheless a potentially useful state, as the GuC could do > other useful work even when not handling batch submissions). > > drm/i915: Expose one LRC function for GuC submission mode > drm/i915: Prepare for GuC-based command submission > drm/i915: Enable GuC firmware log > drm/i915: Implementation of GuC submission client > drm/i915: Interrupt routing for GuC submission > drm/i915: Integrate GuC-based command submission > drm/i915: Debugfs interface for GuC submission statistics > drm/i915: Enable GuC submission, where supported > > In this second section, we implement the GuC submission mechanism, link > it into the (execlist-based) submission path, and finally enable it > (on supported platforms). > > On platforms where there is no GuC, or if GuC submission is explicitly > disabled, batch submission will revert to using the execlist mechanism > directly. On the other hand, if the GuC firmware cannot be found or is > invalid, the GPU will be unusable. > > The GuC firmware itself is not included in this patchset; it is or will > be available for download from https://01.org/linuxgraphics/downloads/ > This driver works with and requires GuC firmware revision 3.x. It will > not work with any firmware version 1.x, as the GuC protocol in those > revisions was incompatible and is no longer supported. > [TOR:] This patch set looks good. There is one comment in the first patch that should be updated. Otherwise, I did not see any changes required. For the 10 patches: Reviewed-by: Tom O'Rourke However, the guc firmware version 3.x is still not available on 01.org. For that reason the 10th patch should not be merged yet. The first 9 patches can be merged now; hopefully before there are difficult merge conflicts. Also, the guc firmware going through the release process is version 4.x. Alex Dai is working on a few patches needed for version 4.x. Thanks, Tom > Ben Widawsky (0): > Vinit Azad (0): > Michael H. Nguyen (0): > created the original versions on which some of these patches are based. > > Alex Dai (5): > drm/i915: GuC-specific firmware loader > drm/i915: Debugfs interface to read GuC load status > drm/i915: Prepare for GuC-based command submission > drm/i915: Enable GuC firmware log > drm/i915: Integrate GuC-based command submission > > Dave Gordon (5): > drm/i915: Expose one LRC function for GuC submission mode > drm/i915: Implementation of GuC submission client > drm/i915: Interrupt routing for GuC submission > drm/i915: Debugfs interface for GuC submission statistics > drm/i915: Enable GuC submission, where supported > > Documentation/DocBook/drm.tmpl | 14 + > drivers/gpu/drm/i915/Makefile | 4 + > drivers/gpu/drm/i915/i915_debugfs.c| 122 +++- > drivers/gpu/drm/i915/i915_dma.c| 9 + > drivers/gpu/drm/i915/i915_drv.h| 11 + > drivers/gpu/drm/i915/i915_gem.c| 16 + > drivers/gpu/drm/i915/i915_gpu_error.c | 13 +- > drivers/gpu/drm/i915/i915_guc_reg.h| 17 +- > drivers/gpu/drm/i915/i915_guc_submission.c | 887 > + > drivers/gpu/drm/i915/i915_params.c | 4 +- > drivers/gpu/drm/i915/i915_reg.h| 15 +- > drivers/gpu/drm/i915/intel_guc.h | 122 > drivers/gpu/drm/i915/intel_guc_fwif.h | 3 +- > drivers/gpu/drm/i915/intel_guc_loader.c| 613 > drivers/gpu/drm/i915/intel_lrc.c | 65 ++- > drivers/gpu/drm/i915/intel_lrc.h | 8 + > 16 files changed, 1881 insertions(+), 42 deletions(-) > create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c > create mode 100644 drivers/gpu/drm/i915/intel_guc.h > create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c > > -- > 1.9.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Intel-kms in Linux-4.2rc causes regression due to dithering always on.
Hi Daniel and all, since Linux 4.2 (tested with rc4), i think this commit d328c9d78d64ca11e744fe227096990430a88477 "drm/i915: Select starting pipe bpp irrespective or the primary plane" causes trouble for me and my users, as tested on Intel HD Ironlake and Ivy Bridge with MiniDP->Singlelink-DVI adapter -> Measurement device. Afaics it causes dithering to always be enabled on a regular 8bpc framebuffer, even when outputting to a 8 bpc DVI-D output, and that dithering causes my display measurement equipment and other special display devices used for neuro-science and medical applications to fail. This equipment requires an identity passthrough of 8 bpc framebuffer pixels to the digital outputs, iow. dithering off. Log output on Linux 4.1 (good): Aug 1 06:39:26 twisty kernel: [ 154.175394] [drm:connected_sink_compute_bpp] [CONNECTOR:35:HDMI-A-1] checking for sink bpp constrains Aug 1 06:39:26 twisty kernel: [ 154.175396] [drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output Aug 1 06:39:26 twisty kernel: [ 154.175397] [drm:intel_hdmi_compute_config] forcing pipe bpc to 24 for HDMI Aug 1 06:39:26 twisty kernel: [ 154.175400] [drm:ironlake_check_fdi_lanes] checking fdi config on pipe A, lanes 1 Aug 1 06:39:26 twisty kernel: [ 154.175402] [drm:intel_modeset_pipe_config] plane bpp: 24, pipe bpp: 24, dithering: 0 Aug 1 06:39:26 twisty kernel: [ 154.175403] [drm:intel_dump_pipe_config] [CRTC:20][modeset] config for pipe A Aug 1 06:39:26 twisty kernel: [ 154.175404] [drm:intel_dump_pipe_config] cpu_transcoder: A Aug 1 06:39:26 twisty kernel: [ 154.175405] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 0 Log output on Linux 4.2-rc4 (bad): Aug 1 06:21:31 twisty kernel: [ 200.924831] [drm:connected_sink_compute_bpp] [CONNECTOR:36:HDMI-A-1] checking for sink bpp constrains Aug 1 06:21:31 twisty kernel: [ 200.924832] [drm:connected_sink_compute_bpp] clamping display bpp (was 36) to default limit of 24 Aug 1 06:21:31 twisty kernel: [ 200.924834] [drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output Aug 1 06:21:31 twisty kernel: [ 200.924835] [drm:intel_hdmi_compute_config] forcing pipe bpc to 24 for HDMI Aug 1 06:21:31 twisty kernel: [ 200.924838] [drm:ironlake_check_fdi_lanes] checking fdi config on pipe A, lanes 1 Aug 1 06:21:31 twisty kernel: [ 200.924840] [drm:intel_modeset_pipe_config] plane bpp: 36, pipe bpp: 24, dithering: 1 Aug 1 06:21:31 twisty kernel: [ 200.924841] [drm:intel_dump_pipe_config] [CRTC:21][modeset] config 880131a5c800 for pipe A Aug 1 06:21:31 twisty kernel: [ 200.924842] [drm:intel_dump_pipe_config] cpu_transcoder: A Aug 1 06:21:31 twisty kernel: [ 200.924843] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 1 Ideas what to do about this? thanks, -mario ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10 v5] drm/i915: GuC-specific firmware loader
On Wed, Jul 29, 2015 at 06:48:29PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> This fetches the required firmware image from the filesystem,
> then loads it into the GuC's memory via a dedicated DMA engine.
>
> This patch is derived from GuC loading work originally done by
> Vinit Azad and Ben Widawsky.
>
> v2:
> Various improvements per review comments by Chris Wilson
>
> v3:
> Removed 'wait' parameter to intel_guc_ucode_load() as firmware
> prefetch is no longer supported in the common firmware loader,
> per Daniel Vetter's request.
> Firmware checker callback fn now returns errno rather than bool.
>
> v4:
> Squash uC-independent code into GuC-specifc loader [Daniel Vetter]
> Don't keep the driver working (by falling back to execlist mode)
> if GuC firmware loading fails [Daniel Vetter]
>
> v5:
> Clarify WOPCM-related #defines [Tom O'Rourke]
> Delete obsolete code no longer required with current h/w & f/w
> [Tom O'Rourke]
> Move the call to intel_guc_ucode_init() later, so that it can
> allocate GEM objects, and have it fetch the firmware; then
> intel_guc_ucode_load() doesn't need to fetch it later.
> [Daniel Vetter].
>
> Issue: VIZ-4884
> Signed-off-by: Alex Dai
> Signed-off-by: Dave Gordon
> ---
> drivers/gpu/drm/i915/Makefile | 3 +
> drivers/gpu/drm/i915/i915_dma.c | 9 +
> drivers/gpu/drm/i915/i915_drv.h | 11 +
> drivers/gpu/drm/i915/i915_gem.c | 16 +
> drivers/gpu/drm/i915/i915_guc_reg.h | 17 +-
> drivers/gpu/drm/i915/i915_reg.h | 4 +-
> drivers/gpu/drm/i915/intel_guc.h| 67
> drivers/gpu/drm/i915/intel_guc_fwif.h | 3 +-
> drivers/gpu/drm/i915/intel_guc_loader.c | 531
>
> 9 files changed, 652 insertions(+), 9 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_guc.h
> create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 41fb8a9..cc359e0 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -40,6 +40,9 @@ i915-y += i915_cmd_parser.o \
> intel_ringbuffer.o \
> intel_uncore.o
>
> +# general-purpose microcontroller (GuC) support
> +i915-y += intel_guc_loader.o
> +
> # autogenerated null render state
> i915-y += intel_renderstate_gen6.o \
> intel_renderstate_gen7.o \
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index ab37d11..2193cc2 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -435,6 +435,11 @@ static int i915_load_modeset_init(struct drm_device *dev)
>* working irqs for e.g. gmbus and dp aux transfers. */
> intel_modeset_init(dev);
>
> + /* intel_guc_ucode_init() needs the mutex to allocate GEM objects */
> + mutex_lock(&dev->struct_mutex);
> + intel_guc_ucode_init(dev);
> + mutex_unlock(&dev->struct_mutex);
> +
> ret = i915_gem_init(dev);
> if (ret)
> goto cleanup_irq;
> @@ -476,6 +481,9 @@ cleanup_gem:
> i915_gem_context_fini(dev);
> mutex_unlock(&dev->struct_mutex);
> cleanup_irq:
> + mutex_lock(&dev->struct_mutex);
> + intel_guc_ucode_fini(dev);
> + mutex_unlock(&dev->struct_mutex);
> drm_irq_uninstall(dev);
> cleanup_gem_stolen:
> i915_gem_cleanup_stolen(dev);
> @@ -1128,6 +1136,7 @@ int i915_driver_unload(struct drm_device *dev)
> flush_workqueue(dev_priv->wq);
>
> mutex_lock(&dev->struct_mutex);
> + intel_guc_ucode_fini(dev);
> i915_gem_cleanup_ringbuffer(dev);
> i915_gem_context_fini(dev);
> mutex_unlock(&dev->struct_mutex);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 04aa34a..2c539df 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -50,6 +50,7 @@
> #include
> #include
> #include
> +#include "intel_guc.h"
>
> /* General customization:
> */
> @@ -1697,6 +1698,8 @@ struct drm_i915_private {
>
> struct i915_virtual_gpu vgpu;
>
> + struct intel_guc guc;
> +
> struct intel_csr csr;
>
> /* Display CSR-related protection */
> @@ -1941,6 +1944,11 @@ static inline struct drm_i915_private
> *dev_to_i915(struct device *dev)
> return to_i915(dev_get_drvdata(dev));
> }
>
> +static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
> +{
> + return container_of(guc, struct drm_i915_private, guc);
> +}
> +
> /* Iterate over initialised rings */
> #define for_each_ring(ring__, dev_priv__, i__) \
> for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \
> @@ -2544,6 +2552,9 @@ struct drm_i915_cmd_table {
>
> #define HAS_CSR(dev) (IS_SKYLAKE(dev))
>
> +#define HAS_GUC_UCODE(dev) (IS_GEN9(dev))
> +#define HAS_GUC_SCHED(dev) (IS_GEN9(dev))
> +
> #define HAS_RESOU
[Intel-gfx] [PATCH i-g-t] Revert "tests/gem_ctx_param_basic: fix invalid params"
This reverts commit 0b45b0746f45deea11670a8b2c949776bbbef55c.
The point of testing for LAST_FLAG + 1 is to catch abi extensions -
despite our best efforts we really suck at properly reviewing for test
coverage when extending ABI.
The real bug here is that David Weinhall hasn't submitted updated igts
for the NO_ZEROMAP feature yet. Imo the right course of action is to
revert that feature if the testcase don't show up within a few days.
Cc: David Weinehall
Cc: Jesse Barnes
Signed-off-by: Daniel Vetter
---
tests/gem_ctx_param_basic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/gem_ctx_param_basic.c b/tests/gem_ctx_param_basic.c
index 5ff3b13f4c7a..b44b37cf0538 100644
--- a/tests/gem_ctx_param_basic.c
+++ b/tests/gem_ctx_param_basic.c
@@ -98,7 +98,7 @@ igt_main
ctx_param.size = 0;
}
- ctx_param.param = -1;
+ ctx_param.param = LOCAL_CONTEXT_PARAM_BAN_PERIOD + 1;
igt_subtest("invalid-param-get") {
ctx_param.context = ctx;
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 4/3] tests/gem_ctx_param_basic: Expand ctx_param tests
On 08/06/2015 02:30 PM, Daniel Vetter wrote: > On Fri, May 29, 2015 at 09:52:52AM +0200, Daniel Vetter wrote: >> On Thu, May 28, 2015 at 05:53:17PM +0300, David Weinehall wrote: >>> On Wed, May 27, 2015 at 01:32:10PM +0200, Daniel Vetter wrote: A simple functional test here which does: a) an execbuf with just 1 batch. With full ppgtt you should get that one at offset 0. If not, skip the testcase. b) set the NO_ZEROMAP property. c) re-run the same batch, assert that now the buffer is relocated to something non-0. Just to make sure we have a bare minimal testcase to make sure we don't break this. >>> >>> Maybe this should be added to another test rather than here? This test >>> is described as a: >>> >>> "Basic test for context set/get param input validation." >>> >>> Somehow I feel that testing whether the *functionality* is correct >>> does not belong in this test, but rather in some test case that's >>> already related to execbufs, or even a dedicated test case. >>> >>> But that might be over-engineering. Opinions? >> >> Yeah separate testcase would fit better, agreed. > > Update version of this patch is still missing. I'll need to revert the > kernel side if this one doesn't show up soonish. > > Also you're breaking the invalid-flags testcase (did you bother to run > them all and check for regressions?) which Jesse spotted, and with the new > basic set this will be a P1 "I'm going to block everything" bug. We really need man pages for new ioctls as well in libdrm. Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 4/3] tests/gem_ctx_param_basic: Expand ctx_param tests
On Thu, Aug 06, 2015 at 11:30:00PM +0200, Daniel Vetter wrote: > On Fri, May 29, 2015 at 09:52:52AM +0200, Daniel Vetter wrote: > > On Thu, May 28, 2015 at 05:53:17PM +0300, David Weinehall wrote: > > > On Wed, May 27, 2015 at 01:32:10PM +0200, Daniel Vetter wrote: > > > > A simple functional test here which does: > > > > a) an execbuf with just 1 batch. With full ppgtt you should get that one > > > > at offset 0. If not, skip the testcase. > > > > b) set the NO_ZEROMAP property. > > > > c) re-run the same batch, assert that now the buffer is relocated to > > > > something non-0. > > > > > > > > Just to make sure we have a bare minimal testcase to make sure we don't > > > > break this. > > > > > > Maybe this should be added to another test rather than here? This test > > > is described as a: > > > > > > "Basic test for context set/get param input validation." > > > > > > Somehow I feel that testing whether the *functionality* is correct > > > does not belong in this test, but rather in some test case that's > > > already related to execbufs, or even a dedicated test case. > > > > > > But that might be over-engineering. Opinions? > > > > Yeah separate testcase would fit better, agreed. > > Update version of this patch is still missing. I'll need to revert the > kernel side if this one doesn't show up soonish. > > Also you're breaking the invalid-flags testcase (did you bother to run > them all and check for regressions?) which Jesse spotted, and with the new > basic set this will be a P1 "I'm going to block everything" bug. Forgot to add Jesse. -Daniel -- 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] [PATCH i-g-t 4/3] tests/gem_ctx_param_basic: Expand ctx_param tests
On Fri, May 29, 2015 at 09:52:52AM +0200, Daniel Vetter wrote: > On Thu, May 28, 2015 at 05:53:17PM +0300, David Weinehall wrote: > > On Wed, May 27, 2015 at 01:32:10PM +0200, Daniel Vetter wrote: > > > A simple functional test here which does: > > > a) an execbuf with just 1 batch. With full ppgtt you should get that one > > > at offset 0. If not, skip the testcase. > > > b) set the NO_ZEROMAP property. > > > c) re-run the same batch, assert that now the buffer is relocated to > > > something non-0. > > > > > > Just to make sure we have a bare minimal testcase to make sure we don't > > > break this. > > > > Maybe this should be added to another test rather than here? This test > > is described as a: > > > > "Basic test for context set/get param input validation." > > > > Somehow I feel that testing whether the *functionality* is correct > > does not belong in this test, but rather in some test case that's > > already related to execbufs, or even a dedicated test case. > > > > But that might be over-engineering. Opinions? > > Yeah separate testcase would fit better, agreed. Update version of this patch is still missing. I'll need to revert the kernel side if this one doesn't show up soonish. Also you're breaking the invalid-flags testcase (did you bother to run them all and check for regressions?) which Jesse spotted, and with the new basic set this will be a P1 "I'm going to block everything" bug. -Daniel -- 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] Enable PSR in IvyBridge?
Hello,
I just discovered that Intel introduced PSR with IvyBridge, so I tried
to enable it for my laptop, which has an eDP panel that supports psr.
The patch is attached (all I do is enable all things IvyBridge, I am
not familiar with the kernel at all, apologies if you see absurdities).
However, I had *some* success, I have:
Sink_Support: yes
Source_OK: yes
Enabled: yes
Active: yes
Busy frontbuffer bits: 0x000
Re-enable work scheduled: no
HW Enabled & Active bit: no
Link standby: no
Performance_Counter: 0
and so far I am only seeing one error, whenever the screen is turned
on/off (at boot and when gnome blanks it to save power, for example).
All the problems seem to be in intel_psr_exit() and intel_psr_flush().
I read in Rodrigo Vivi's blog that a psr test should exist in
intel-gpu-tools, but I couldn't find it.
I am inclined to think that enabling psr for IvyBridge shouldn't be too
hard for someone who knows what they are doing. If someone wants to
take this on I will be happy to test and report bugs, although my
hardware is fairly bizarre.
Best regards
[ cut here ]
kernel: WARNING: CPU: 3 PID: 726 at
drivers/gpu/drm/i915/intel_psr.c:532 intel_psr_exit+0x152/0x160()
kernel: WARN_ON(!(val & EDP_PSR_ENABLE))
kernel: Modules linked in:
kernel: fuse acpi_call(O) nls_iso8859_15 nls_cp850 vfat fat
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_cod
kernel: CPU: 3 PID: 726 Comm: Xorg Tainted: G U O4.1.4-eDP
#1
kernel: Hardware name: LENOVO 2324B14/2324B14, BIOS G2ETA3WW (2.63 )
02/05/2015
kernel: 81718e70 0bfa939c 81718e70
815b820b
kernel: 8800c50d7c50 810709a7 8802146c
kernel: 880214a4a800 880214a4a800
81070a38
kernel: Call Trace:
kernel: [] ? dump_stack+0x47/0x67
kernel: [] ? warn_slowpath_common+0x77/0xb0
kernel: [] ? warn_slowpath_fmt+0x58/0x80
kernel: [] ? intel_psr_exit+0x152/0x160
kernel: [] ? intel_psr_invalidate+0x42/0x70
kernel: [] ? intel_fb_obj_invalidate+0xa8/0x110
kernel: [] ?
i915_gem_object_set_to_gtt_domain+0x127/0x150
kernel: [] ? i915_gem_fault+0x1e3/0x3f0
kernel: [] ? __do_fault+0x4a/0xe0
kernel: [] ? __mem_cgroup_count_vm_event+0x10/0x70
kernel: [] ? handle_mm_fault+0x438/0x15b0
kernel: [] ? __fget+0x63/0xa0
kernel: [] ? recalc_sigpending+0x15/0x50
kernel: [] ? __set_task_blocked+0x38/0x90
kernel: [] ? __do_page_fault+0x158/0x3d0
kernel: [] ? SyS_rt_sigprocmask+0x89/0xd0
kernel: [] ? page_fault+0x22/0x30
kernel: ---[ end trace cb3b5b396afe8d4e ]---
diff -uNr linux-4.1.4-vanilla/drivers/gpu/drm/i915/i915_debugfs.c linux-4.1.4/drivers/gpu/drm/i915/i915_debugfs.c
--- linux-4.1.4-vanilla/drivers/gpu/drm/i915/i915_debugfs.c 2015-08-03 17:30:08.0 +0100
+++ linux-4.1.4/drivers/gpu/drm/i915/i915_debugfs.c 2015-08-06 12:10:26.335922540 +0100
@@ -2269,7 +2269,7 @@
seq_printf(m, "Re-enable work scheduled: %s\n",
yesno(work_busy(&dev_priv->psr.work.work)));
- if (HAS_DDI(dev))
+ if (HAS_DDI(dev) || IS_IVYBRIDGE(dev))
enabled = I915_READ(EDP_PSR_CTL(dev)) & EDP_PSR_ENABLE;
else {
for_each_pipe(dev_priv, pipe) {
@@ -2282,7 +2282,7 @@
}
seq_printf(m, "HW Enabled & Active bit: %s", yesno(enabled));
- if (!HAS_DDI(dev))
+ if (!HAS_DDI(dev) || !IS_IVYBRIDGE(dev))
for_each_pipe(dev_priv, pipe) {
if ((stat[pipe] == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
(stat[pipe] == VLV_EDP_PSR_ACTIVE_SF_UPDATE))
@@ -2294,7 +2294,7 @@
yesno((bool)dev_priv->psr.link_standby));
/* CHV PSR has no kind of performance counter */
- if (HAS_DDI(dev)) {
+ if (HAS_DDI(dev) || IS_IVYBRIDGE(dev)) {
psrperf = I915_READ(EDP_PSR_PERF_CNT(dev)) &
EDP_PSR_PERF_CNT_MASK;
diff -uNr linux-4.1.4-vanilla/drivers/gpu/drm/i915/i915_drv.h linux-4.1.4/drivers/gpu/drm/i915/i915_drv.h
--- linux-4.1.4-vanilla/drivers/gpu/drm/i915/i915_drv.h 2015-08-03 17:30:08.0 +0100
+++ linux-4.1.4/drivers/gpu/drm/i915/i915_drv.h 2015-08-06 09:43:32.558967848 +0100
@@ -2398,7 +2398,7 @@
#define HAS_DDI(dev) (INTEL_INFO(dev)->has_ddi)
#define HAS_FPGA_DBG_UNCLAIMED(dev) (INTEL_INFO(dev)->has_fpga_dbg)
-#define HAS_PSR(dev) (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
+#define HAS_PSR(dev) (IS_HASWELL(dev) || IS_IVYBRIDGE(dev) || IS_BROADWELL(dev) || \
IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev) || \
IS_SKYLAKE(dev))
#define HAS_RUNTIME_PM(dev) (IS_GEN6(dev) || IS_HASWELL(dev) || \
diff -uNr linux-4.1.4-vanilla/drivers/gpu/drm/i915/intel_dp.c linux-4.1.4/drivers/gpu/drm/i915/intel_dp.c
--- linux-4.1.4-vanilla/drivers/gpu/drm/i915/intel_dp.c 2015-08-03 17:30:08.0 +0100
+++ linux-4.1.4/drivers/gpu/drm/i915/intel_dp.c 2015-08-06 12:58:22.562701511 +0100
static struct drm_device *intel_dp_to_dev(struct intel_dp *intel_dp)
@@ -2291,9 +2290,6 @@
if (crtc->config->has_audio)
intel_audio_codec_disable(encoder);
- if (HAS_PSR(dev) && (!HAS_DDI(dev)))
+ if (HAS_PSR(dev) && (!HAS_DDI(dev) || !
[Intel-gfx] [drm-intel:for-linux-next 479/497] drivers/gpu/drm/i915/i915_gem_gtt.c:1086:26: sparse: Using plain integer as NULL pointer
tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: 176b15ab89a89f5bd5f73f96afcc5c4a6105fa5e commit: fb6c09f3ae620c5e0db5b4c2058a9c25b52197f9 [479/497] drm/i915/gen8: Make pdp allocation more dynamic reproduce: # apt-get install sparse git checkout fb6c09f3ae620c5e0db5b4c2058a9c25b52197f9 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/i915/i915_gem_gtt.c:1086:26: sparse: Using plain integer as >> NULL pointer vim +1086 drivers/gpu/drm/i915/i915_gem_gtt.c 1070 if (IS_ENABLED(CONFIG_X86_32)) 1071 /* While we have a proliferation of size_t variables 1072 * we cannot represent the full ppgtt size on 32bit, 1073 * so limit it to the same size as the GGTT (currently 1074 * 2GiB). 1075 */ 1076 ppgtt->base.total = to_i915(ppgtt->base.dev)->gtt.base.total; 1077 ppgtt->base.cleanup = gen8_ppgtt_cleanup; 1078 ppgtt->base.allocate_va_range = gen8_alloc_va_range; 1079 ppgtt->base.insert_entries = gen8_ppgtt_insert_entries; 1080 ppgtt->base.clear_range = gen8_ppgtt_clear_range; 1081 ppgtt->base.unbind_vma = ppgtt_unbind_vma; 1082 ppgtt->base.bind_vma = ppgtt_bind_vma; 1083 1084 ppgtt->switch_mm = gen8_mm_switch; 1085 > 1086 ret = __pdp_init(false, &ppgtt->pdp); 1087 1088 if (ret) 1089 goto free_scratch; 1090 1091 return 0; 1092 1093 free_scratch: 1094 gen8_free_scratch(&ppgtt->base); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] scripts/kernel-doc Allow struct arguments documentation in struct body
On Tue, 4 Aug 2015 09:04:08 -0300 Danilo Cesar Lemes de Paula wrote: > Describing arguments at top of a struct definition works fine > for small/medium size structs, but it definitely doesn't work well > for struct with a huge list of elements. > > Keeping the arguments list inside the struct body makes it easier > to maintain the documentation. OK, this change has been merged into the docs tree. Thanks, jon ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages
We have for a long time been ultra-paranoid about the situation whereby
we hand back pages to the system that have been written to by the GPU
and potentially simultaneously by the user through a CPU mmapping. We
can relax this restriction when we know that the cache domain tracking
is true and there can be no stale cacheline invalidatations. This is
true if the object has never been CPU mmaped as all internal accesses
(i.e. kmap/iomap) are carefully flushed. For a CPU mmaping, one would
expect that the invalid cache lines are resolved on PTE/TLB shootdown
during munmap(), so the only situation we need to be paranoid about is
when such a CPU mmaping exists at the time of put_pages. Given that we
need to treat put_pages carefully as we may return live data to the
system that we want to use again in the future (i.e. I915_MADV_WILLNEED
pages) we can simply treat a live CPU mmaping as a special case of
WILLNEED (which it is!). Any I915_MADV_DONTNEED pages and their
mmapings are shotdown immediately following put_pages.
Signed-off-by: Chris Wilson
Cc: "Goel, Akash"
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem.c | 49 ++---
1 file changed, 36 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2dfe707f11d3..24deace364a5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2047,22 +2047,45 @@ i915_gem_object_put_pages_gtt(struct
drm_i915_gem_object *obj)
BUG_ON(obj->madv == __I915_MADV_PURGED);
- ret = i915_gem_object_set_to_cpu_domain(obj, true);
- if (ret) {
- /* In the event of a disaster, abandon all caches and
-* hope for the best.
-*/
- WARN_ON(ret != -EIO);
- i915_gem_clflush_object(obj, true);
- obj->base.read_domains = obj->base.write_domain =
I915_GEM_DOMAIN_CPU;
- }
-
i915_gem_gtt_finish_object(obj);
- if (i915_gem_object_needs_bit17_swizzle(obj))
- i915_gem_object_save_bit_17_swizzle(obj);
+ /* If we need to access the data in the future, we need to
+* be sure that the contents of the object is coherent with
+* the CPU prior to releasing the pages back to the system.
+* Once we unpin them, the mm is free to move them to different
+* zones or even swap them out to disk - all without our
+* intervention. (Though we could track such operations with our
+* own gemfs, if we ever write one.) As such if we want to keep
+* the data, set it to the CPU domain now just in case someone
+* else touches it.
+*
+* For a long time we have been paranoid about handing back
+* pages to the system with stale cacheline invalidation. For
+* all internal use (kmap/iomap), we know that the domain tracking is
+* accurate. However, the userspace API is lax and the user can CPU
+* mmap the object and invalidate cachelines without our accurate
+* tracking. We have been paranoid to be sure that we always flushed
+* the cachelines when we stopped using the pages. However, given
+* that the CPU PTE/TLB shootdown must have invalidated the cachelines
+* upon munmap(), we only need to be paranoid about a live CPU mmap
+* now. For this, we need only treat it as live data see
+* discard_backing_storage().
+*/
+ if (obj->madv == I915_MADV_WILLNEED) {
+ ret = i915_gem_object_set_to_cpu_domain(obj, true);
+ if (ret) {
+ /* In the event of a disaster, abandon all caches and
+* hope for the best.
+*/
+ WARN_ON(ret != -EIO);
+ i915_gem_clflush_object(obj, true);
+ obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+ obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+ }
- if (obj->madv == I915_MADV_DONTNEED)
+ if (i915_gem_object_needs_bit17_swizzle(obj))
+ i915_gem_object_save_bit_17_swizzle(obj);
+ } else
obj->dirty = 0;
st_for_each_page(&iter, obj->pages) {
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/18] drm: Add structure for set/get a CTM color property
From: Kausal Malladi
Color Manager framework defines a color correction property for color
space transformation and Gamut mapping. This property is called CTM (Color
Transformation Matrix).
This patch adds a new structure in DRM layer for CTM.
This structure can be used by all user space agents to
configure CTM coefficients for color correction.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index f72b916..9580772 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -867,6 +867,18 @@ struct drm_palette {
struct drm_r32g32b32 lut[0];
};
+struct drm_ctm {
+ /* Structure version. Should be 1 currently */
+ __u32 version;
+ /*
+* Each value is in S31.32 format.
+* This is 3x3 matrix in row major format.
+* Integer part will be clipped to nearest
+* max/min boundary as supported by the HW platform.
+*/
+ __s64 ctm_coeff[9];
+};
+
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/18] drm/i915: Add DeGamma correction for BDW/SKL/BXT
From: Kausal Malladi
BDW/SKL/BXT supports DeGamma color correction feature, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Adds the core function to program DeGamma correction values for
BDW/SKL/BXT platform
2. Adds DeGamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_color_manager.c | 68 ++
drivers/gpu/drm/i915/intel_color_manager.h | 2 +
2 files changed, 70 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index a894f4c..9f9fb1a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -154,6 +154,72 @@ u32 gen9_write_10bit_gamma_precision(u32 red, u32 green,
u32 blue)
return word;
}
+int gen9_set_degamma(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ struct drm_palette *degamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_r32g32b32 *correction_values = NULL;
+ u32 mode, pal_prec_index, pal_prec_data;
+ int count = 0;
+ u32 blue, green, red;
+ enum pipe pipe;
+ int num_samples, length;
+ u32 index, word;
+
+ if (!blob) {
+ DRM_ERROR("Null Blob\n");
+ return -EINVAL;
+ }
+
+ degamma_data = (struct drm_palette *)blob->data;
+
+ if (degamma_data->version != GEN9_DEGAMMA_DATA_STRUCT_VERSION) {
+ DRM_ERROR("Invalid DeGamma Data struct version\n");
+ return -EINVAL;
+ }
+
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = degamma_data->num_samples;
+ if (num_samples != GEN9_SPLITGAMMA_MAX_VALS) {
+ DRM_ERROR("Invalid number of samples\n");
+ return -EINVAL;
+ }
+
+ length = num_samples * sizeof(struct drm_r32g32b32);
+ mode = I915_READ(GAMMA_MODE(pipe));
+
+ pal_prec_index = _PREC_PAL_INDEX(pipe);
+ pal_prec_data = _PREC_PAL_DATA(pipe);
+
+ correction_values = (struct drm_r32g32b32 *)°amma_data->lut;
+ index = I915_READ(pal_prec_index);
+ index |= GEN9_INDEX_AUTO_INCREMENT | GEN9_INDEX_SPLIT_MODE;
+ I915_WRITE(pal_prec_index, index);
+
+ while (count < num_samples) {
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ word = gen9_write_10bit_gamma_precision(red, green, blue);
+ I915_WRITE(pal_prec_data, word);
+ count++;
+ }
+
+ mode &= ~GAMMA_MODE_MODE_MASK;
+ I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_SPLIT);
+
+ /* Enable DeGamma on Pipe */
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe),
+ I915_READ(_PIPE_CGM_CONTROL(pipe)) | CGM_DEGAMMA_EN);
+
+ DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",
+ pipe_name(pipe));
+
+ return 0;
+}
+
int chv_set_degamma(struct drm_device *dev, struct drm_property_blob *blob,
struct drm_crtc *crtc)
{
@@ -640,6 +706,8 @@ void intel_color_manager_crtc_commit(struct drm_device *dev,
/* degamma correction */
if (IS_CHERRYVIEW(dev))
ret = chv_set_degamma(dev, blob, crtc);
+ else if (IS_BROADWELL(dev) || IS_GEN9(dev))
+ ret = gen9_set_degamma(dev, blob, crtc);
if (ret)
DRM_ERROR("set degamma correction failed\n");
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index fa9d0b0..ca89f25 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -72,6 +72,8 @@
#define CHV_DEGAMMA_DATA_STRUCT_VERSION1
#define CHV_DEGAMMA_MSB_SHIFT 2
#define CHV_DEGAMMA_GREEN_SHIFT16
+/* Gen 9 */
+#define GEN9_DEGAMMA_DATA_STRUCT_VERSION 1
/* CSC correction */
#define CHV_CSC_DATA_STRUCT_VERSION1
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/18] drm/i915: Add CSC correction for BDW/SKL/BXT
From: Kausal Malladi
BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.
This patch does the following:
1. Adds the core function to program CSC correction values for
BDW/SKL/BXT platform
2. Adds CSC correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 5 ++
drivers/gpu/drm/i915/intel_color_manager.c | 90 ++
drivers/gpu/drm/i915/intel_color_manager.h | 17 ++
3 files changed, 112 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 92233ce..31d7ff8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7943,6 +7943,9 @@ enum skl_disp_power_wells {
#define PAL_PREC_DATA_A0x4A404
#define PAL_PREC_DATA_B0x4AC04
#define PAL_PREC_DATA_C0x4B404
+#define CSC_COEFF_A0x49010
+#define CSC_COEFF_B0x49110
+#define CSC_COEFF_C0x49210
#define _PIPE_CGM_CONTROL(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
@@ -7957,5 +7960,7 @@ enum skl_disp_power_wells {
(_PIPE3(pipe, PAL_PREC_INDEX_A, PAL_PREC_INDEX_B, PAL_PREC_INDEX_C))
#define _PREC_PAL_DATA(pipe) \
(_PIPE3(pipe, PAL_PREC_DATA_A, PAL_PREC_DATA_B, PAL_PREC_DATA_C))
+#define _PIPE_CSC_COEFF(pipe) \
+ (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 9f9fb1a..fc08e67 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,94 @@
#include "intel_color_manager.h"
+s16 get_csc_s2_7_format(s64 csc_value)
+{
+ s32 csc_int_value;
+ u32 csc_fract_value;
+ s16 csc_s2_7_format;
+
+ if (csc_value >= 0) {
+ csc_value += GEN9_CSC_FRACT_ROUNDOFF;
+ if (csc_value > GEN9_CSC_COEFF_MAX)
+ csc_value = GEN9_CSC_COEFF_MAX;
+ } else {
+ csc_value = -csc_value;
+ csc_value += GEN9_CSC_FRACT_ROUNDOFF;
+ if (csc_value > GEN9_CSC_COEFF_MAX + 1)
+ csc_value = GEN9_CSC_COEFF_MAX + 1;
+ csc_value = -csc_value;
+ }
+
+ csc_int_value = csc_value >> GEN9_CSC_COEFF_SHIFT;
+ csc_int_value <<= GEN9_CSC_COEFF_INT_SHIFT;
+ if (csc_value < 0)
+ csc_int_value |= CSC_COEFF_SIGN;
+ csc_fract_value = csc_value;
+ csc_fract_value >>= GEN9_CSC_COEFF_FRACT_SHIFT;
+ csc_s2_7_format = csc_int_value | csc_fract_value;
+
+ return csc_s2_7_format;
+}
+
+int gen9_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ struct drm_ctm *csc_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 reg, plane_ctl;
+ enum pipe pipe;
+ enum plane plane;
+ s32 word;
+ int i, j;
+
+ if (!blob) {
+ DRM_ERROR("NULL Blob\n");
+ return -EINVAL;
+ }
+
+ if (blob->length != sizeof(struct drm_ctm)) {
+ DRM_ERROR("Invalid length of data received\n");
+ return -EINVAL;
+ }
+
+ csc_data = (struct drm_ctm *)blob->data;
+ if (csc_data->version != GEN9_CSC_DATA_STRUCT_VERSION) {
+ DRM_ERROR("Invalid CSC Data struct version\n");
+ return -EINVAL;
+ }
+
+ pipe = to_intel_crtc(crtc)->pipe;
+ plane = to_intel_crtc(crtc)->plane;
+
+ plane_ctl = I915_READ(PLANE_CTL(pipe, plane));
+ plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
+
+ I915_WRITE(PLANE_CTL(pipe, plane), plane_ctl);
+
+ reg = _PIPE_CSC_COEFF(pipe);
+
+ /* Write csc coeff to csc regs */
+ for (i = 0, j = 0; i < CSC_MAX_VALS; i++) {
+ word = get_csc_s2_7_format(csc_data->ctm_coeff[i]);
+ word = word << GEN9_CSC_SHIFT;
+ if (i % 3 != 2)
+ word = word |
+ get_csc_s2_7_format(csc_data->ctm_coeff[i]);
+
+ I915_WRITE(reg + j, word);
+ j = j + 4;
+ }
+
+ DRM_DEBUG_DRIVER("All CSC values written to registers\n");
+
+ /* Enable CSC functionality */
+ reg = _PIPE_CGM_CONTROL(pipe);
+ I915_WRITE(reg, I915_READ(reg) | CGM_CSC_EN);
+ DRM_DEBUG_DRIVER("CSC enabled on Pipe %c\n", pipe_name(pipe));
+
+ return 0;
+}
+
s16 get_csc_s3_12_format(s64 csc_value)
{
s32 csc_int_value;
@@ -720,6 +808,8 @@ void intel_color_manager_crtc_commit(struct drm_device *dev,
/* CSC correction */
if (IS_CHERRYV
[Intel-gfx] [PATCH 16/18] drm/i915: Gen8 pipe level Gamma correction
From: Kausal Malladi
BDW/SKL/BXT platforms support various Gamma correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit mode
3. 10-bit Split Gamma mode
4. 12-bit mode
This patch does the following:
1. Adds the core function to program Gamma correction values for BDW/SKL/BXT
platform
2. Adds Gamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 17 +-
drivers/gpu/drm/i915/intel_color_manager.c | 269 +
drivers/gpu/drm/i915/intel_color_manager.h | 16 ++
3 files changed, 301 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9ce259e..92233ce 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5591,7 +5591,9 @@ enum skl_disp_power_wells {
#define _GAMMA_MODE_A 0x4a480
#define _GAMMA_MODE_B 0x4ac80
-#define GAMMA_MODE(pipe) _PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
+#define _GAMMA_MODE_C 0x4b480
+#define GAMMA_MODE(pipe) \
+ _PIPE3(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B, _GAMMA_MODE_C)
#define GAMMA_MODE_MODE_MASK (3 << 0)
#define GAMMA_MODE_MODE_8BIT (0 << 0)
#define GAMMA_MODE_MODE_10BIT (1 << 0)
@@ -7934,6 +7936,14 @@ enum skl_disp_power_wells {
#define PIPEA_CGM_CSC (VLV_DISPLAY_BASE + 0x67900)
#define PIPEB_CGM_CSC (VLV_DISPLAY_BASE + 0x69900)
#define PIPEC_CGM_CSC (VLV_DISPLAY_BASE + 0x6B900)
+
+#define PAL_PREC_INDEX_A 0x4A400
+#define PAL_PREC_INDEX_B 0x4AC00
+#define PAL_PREC_INDEX_C 0x4B400
+#define PAL_PREC_DATA_A0x4A404
+#define PAL_PREC_DATA_B0x4AC04
+#define PAL_PREC_DATA_C0x4B404
+
#define _PIPE_CGM_CONTROL(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
#define _PIPE_GAMMA_BASE(pipe) \
@@ -7943,4 +7953,9 @@ enum skl_disp_power_wells {
#define _PIPE_CSC_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+#define _PREC_PAL_INDEX(pipe) \
+ (_PIPE3(pipe, PAL_PREC_INDEX_A, PAL_PREC_INDEX_B, PAL_PREC_INDEX_C))
+#define _PREC_PAL_DATA(pipe) \
+ (_PIPE3(pipe, PAL_PREC_DATA_A, PAL_PREC_DATA_B, PAL_PREC_DATA_C))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index bc77ab5..a894f4c 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -120,6 +120,40 @@ int chv_set_csc(struct drm_device *dev, struct
drm_property_blob *blob,
return 0;
}
+u32 gen9_write_10bit_gamma_precision(u32 red, u32 green, u32 blue)
+{
+ u32 word;
+ u8 blue_int, green_int, red_int;
+ u16 blue_fract, green_fract, red_fract;
+
+ blue_int = _GAMMA_INT_PART(blue);
+ if (blue_int > GAMMA_INT_MAX)
+ blue = GEN9_MAX_GAMMA;
+ green_int = _GAMMA_INT_PART(green);
+ if (green_int > GAMMA_INT_MAX)
+ green = GEN9_MAX_GAMMA;
+ red_int = _GAMMA_INT_PART(red);
+ if (red_int > GAMMA_INT_MAX)
+ red = GEN9_MAX_GAMMA;
+
+ blue_fract = _GAMMA_FRACT_PART(blue);
+ green_fract = _GAMMA_FRACT_PART(green);
+ red_fract = _GAMMA_FRACT_PART(red);
+
+ blue_fract >>= GEN9_10BIT_GAMMA_MSB_SHIFT;
+ green_fract >>= GEN9_10BIT_GAMMA_MSB_SHIFT;
+ red_fract >>= GEN9_10BIT_GAMMA_MSB_SHIFT;
+
+ /* Red (29:20) Green (19:10) and Blue (9:0) */
+ word = red_fract;
+ word <<= GEN9_GAMMA_SHIFT;
+ word = word | green_fract;
+ word <<= GEN9_GAMMA_SHIFT;
+ word = word | blue_fract;
+
+ return word;
+}
+
int chv_set_degamma(struct drm_device *dev, struct drm_property_blob *blob,
struct drm_crtc *crtc)
{
@@ -225,6 +259,238 @@ int chv_set_degamma(struct drm_device *dev, struct
drm_property_blob *blob,
return ret;
}
+int gen9_set_gamma(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ u8 blue_int, green_int, red_int;
+ u16 blue_fract, green_fract, red_fract;
+ u16 blue_odd, green_odd, red_odd;
+ u16 blue_even, green_even, red_even;
+ int ret, count, num_samples, length;
+ enum pipe pipe;
+ u32 blue, green, red;
+ u32 mode, pal_prec_index, pal_prec_data;
+ u32 cgm_control_reg = 0;
+ u32 index, word;
+ struct drm_palette *gamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_r32g32b32 *correction_values = NULL;
+
+ if (!blob) {
+ DRM_ERROR("Null Blob\n");
+ return -EINVAL;
+ }
+
+ gamma_data = (struct drm_palette *)blob->data;
+
+ if (gamma_data->v
[Intel-gfx] [PATCH 13/18] drm/i915: Add set/get property handlers for CSC correction
From: Kausal Malladi
This patch adds set and get property handlers for CSC color correction
and enhancement capability at Pipe level on CHV/BSW platform. The set
function just attaches the CSC blob to CRTC state, that later
gets committed using atomic path.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c| 5 +
drivers/gpu/drm/i915/intel_color_manager.c | 19 +++
drivers/gpu/drm/i915/intel_drv.h | 3 +++
3 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 1d8cb09..a6f0b71 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -334,6 +334,9 @@ int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
if (property == config->cm_palette_before_ctm_property)
return intel_color_manager_set_pipe_degamma(dev, state,
&crtc->base, val);
+ if (property == config->cm_ctm_property)
+ return intel_color_manager_set_pipe_csc(dev, state,
+ &crtc->base, val);
DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
return -EINVAL;
@@ -353,6 +356,8 @@ int intel_crtc_atomic_get_property(struct drm_crtc *crtc,
if (property == config->cm_palette_before_ctm_property)
*val = (state->palette_before_ctm_blob) ?
state->palette_before_ctm_blob->base.id : 0;
+ if (property == config->cm_ctm_property)
+ *val = (state->ctm_blob) ? state->ctm_blob->base.id : 0;
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index ae92825..3eea857 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -287,6 +287,25 @@ void intel_color_manager_crtc_commit(struct drm_device
*dev,
}
}
+int intel_color_manager_set_pipe_csc(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id)
+{
+ struct drm_property_blob *blob;
+
+ blob = drm_property_lookup_blob(dev, blob_id);
+ if (!blob) {
+ DRM_ERROR("Invalid Blob ID\n");
+ return -EINVAL;
+ }
+
+ if (crtc_state->ctm_blob)
+ drm_property_unreference_blob(crtc_state->ctm_blob);
+
+ crtc_state->ctm_blob = blob;
+ return 0;
+}
+
int intel_color_manager_set_pipe_degamma(struct drm_device *dev,
struct drm_crtc_state *crtc_state,
struct drm_mode_object *obj, uint32_t blob_id)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d3b42ec..cb80e81 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1447,6 +1447,9 @@ int intel_color_manager_set_pipe_gamma(struct drm_device
*dev,
int intel_color_manager_set_pipe_degamma(struct drm_device *dev,
struct drm_crtc_state *crtc_state,
struct drm_mode_object *obj, uint32_t blob_id);
+int intel_color_manager_set_pipe_csc(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id);
void intel_color_manager_crtc_commit(struct drm_device *dev,
struct drm_crtc_state *crtc_state);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/18] drm/i915: Add DeGamma correction for CHV/BSW
From: Kausal Malladi
CHV/BSW supports DeGamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Attach deGamma property to CRTC
2. Add the core function to program DeGamma correction values for
CHV/BSW platform
2. Add DeGamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 5 ++
drivers/gpu/drm/i915/intel_color_manager.c | 120 +
drivers/gpu/drm/i915/intel_color_manager.h | 6 ++
3 files changed, 131 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4997ebd..523aad9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7928,9 +7928,14 @@ enum skl_disp_power_wells {
#define PIPEA_CGM_GAMMA(VLV_DISPLAY_BASE +
0x67000)
#define PIPEB_CGM_GAMMA(VLV_DISPLAY_BASE +
0x69000)
#define PIPEC_CGM_GAMMA(VLV_DISPLAY_BASE +
0x6B000)
+#define PIPEA_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x66000)
+#define PIPEB_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x68000)
+#define PIPEC_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x6A000)
#define _PIPE_CGM_CONTROL(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
#define _PIPE_GAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+#define _PIPE_DEGAMMA_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 5fc8e41..ae92825 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,111 @@
#include "intel_color_manager.h"
+int chv_set_degamma(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ struct drm_palette *degamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 cgm_control_reg = 0;
+ u32 cgm_degamma_reg = 0;
+ enum pipe pipe;
+ u32 red, green, blue;
+ u8 red_int, green_int, blue_int;
+ u16 red_fract, green_fract, blue_fract;
+ u32 count = 0;
+ struct drm_r32g32b32 *correction_values = NULL;
+ u32 num_samples;
+ u32 word;
+ int ret = 0, length;
+
+ if (!blob) {
+ DRM_ERROR("NULL Blob\n");
+ return -EINVAL;
+ }
+
+ degamma_data = (struct drm_palette *)blob->data;
+
+ if (degamma_data->version != CHV_DEGAMMA_DATA_STRUCT_VERSION) {
+ DRM_ERROR("Invalid DeGamma Data struct version\n");
+ return -EINVAL;
+ }
+
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = degamma_data->num_samples;
+ length = num_samples * sizeof(struct drm_r32g32b32);
+
+ if (num_samples == 0) {
+
+ /* Disable DeGamma functionality on Pipe - CGM Block */
+ cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+ cgm_control_reg &= ~CGM_DEGAMMA_EN;
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+
+ DRM_DEBUG_DRIVER("DeGamma disabled on Pipe %c\n",
+ pipe_name(pipe));
+ ret = 0;
+ } else if (num_samples == CHV_DEGAMMA_MAX_VALS) {
+ cgm_degamma_reg = _PIPE_DEGAMMA_BASE(pipe);
+
+ count = 0;
+ correction_values = (struct drm_r32g32b32 *)°amma_data->lut;
+ while (count < CHV_DEGAMMA_MAX_VALS) {
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ blue_int = _GAMMA_INT_PART(blue);
+ if (blue_int > GAMMA_INT_MAX)
+ blue = CHV_MAX_GAMMA;
+ green_int = _GAMMA_INT_PART(green);
+ if (green_int > GAMMA_INT_MAX)
+ green = CHV_MAX_GAMMA;
+ red_int = _GAMMA_INT_PART(red);
+ if (red_int > GAMMA_INT_MAX)
+ red = CHV_MAX_GAMMA;
+
+ blue_fract = _GAMMA_FRACT_PART(blue);
+ green_fract = _GAMMA_FRACT_PART(green);
+ red_fract = _GAMMA_FRACT_PART(red);
+
+ blue_fract >>= CHV_DEGAMMA_MSB_SHIFT;
+ green_fract >>= CHV_DEGAMMA_MSB_SHIFT;
+ red_fract >>= CHV_DEGAMMA_MSB_SHIFT;
+
+ /* Green (29:16) and Blue (13:0) in DWORD1 */
+ wor
[Intel-gfx] [PATCH 15/18] drm/i915: Initialize Gen8 pipe gamma correction
From: Kausal Malladi
This patch initializes gamma color correction proeprty
for Gen8 and higher platforms.
It does the following :
1. Load pipe Gamma color correction capabilities for BDW/SKL/BXT
2. Attach the color properties to CRTC
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_color_manager.c | 30 +-
drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 5fa575b..bc77ab5 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -475,11 +475,39 @@ int get_chv_pipe_gamma_capabilities(struct drm_device
*dev,
return 0;
}
+int get_gen9_pipe_gamma_capabilities(struct drm_device *dev,
+ struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
+{
+ struct drm_property_blob *blob = NULL;
+
+ /*
+* This function exposes best capability for DeGamma and Gamma
+* For BXT, the DeGamma LUT has 512 entries
+* and the best Gamma capability has 512 entries
+*/
+ palette_caps->version = GEN9_PALETTE_STRUCT_VERSION;
+ palette_caps->num_samples_before_ctm =
+ GEN9_SPLITGAMMA_MAX_VALS;
+ palette_caps->num_samples_after_ctm =
+ GEN9_SPLITGAMMA_MAX_VALS;
+
+ blob = drm_property_create_blob(dev, sizeof(struct drm_palette_caps),
+ (const void *) palette_caps);
+
+ if (blob)
+ return blob->base.id;
+
+ return 0;
+}
+
int get_pipe_gamma_capabilities(struct drm_device *dev,
struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
{
if (IS_CHERRYVIEW(dev))
return get_chv_pipe_gamma_capabilities(dev, palette_caps, crtc);
+ if (IS_BROADWELL(dev) || IS_GEN9(dev))
+ return get_gen9_pipe_gamma_capabilities(dev,
+ palette_caps, crtc);
return -EINVAL;
}
@@ -491,7 +519,7 @@ void intel_attach_color_properties_to_crtc(struct
drm_device *dev,
struct drm_crtc *crtc;
int capabilities_blob_id;
- if (IS_CHERRYVIEW(dev)) {
+ if (IS_CHERRYVIEW(dev) || IS_BROADWELL(dev) || IS_GEN9(dev)) {
crtc = obj_to_crtc(mode_obj);
palette_caps = kzalloc(sizeof(struct drm_palette_caps),
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index b2ee847..78de1a2 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -35,6 +35,9 @@
#define CHV_DEGAMMA_MAX_VALS 65
#define CHV_10BIT_GAMMA_MAX_VALS 257
+#define GEN9_PALETTE_STRUCT_VERSION1
+#define GEN9_SPLITGAMMA_MAX_VALS 512
+
/* Gamma correction */
#define CHV_GAMMA_DATA_STRUCT_VERSION 1
#define CHV_10BIT_GAMMA_MAX_VALS 257
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/18] drm/i915: Add CSC correction for CHV/BSW
From: Kausal Malladi
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.
This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 5 ++
drivers/gpu/drm/i915/intel_color_manager.c | 108 +
drivers/gpu/drm/i915/intel_color_manager.h | 20 ++
3 files changed, 133 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 523aad9..9ce259e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7931,11 +7931,16 @@ enum skl_disp_power_wells {
#define PIPEA_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x66000)
#define PIPEB_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x68000)
#define PIPEC_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x6A000)
+#define PIPEA_CGM_CSC (VLV_DISPLAY_BASE + 0x67900)
+#define PIPEB_CGM_CSC (VLV_DISPLAY_BASE + 0x69900)
+#define PIPEC_CGM_CSC (VLV_DISPLAY_BASE + 0x6B900)
#define _PIPE_CGM_CONTROL(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
#define _PIPE_GAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
#define _PIPE_DEGAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+#define _PIPE_CSC_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 3eea857..5fa575b 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,99 @@
#include "intel_color_manager.h"
+s16 get_csc_s3_12_format(s64 csc_value)
+{
+ s32 csc_int_value;
+ u32 csc_fract_value;
+ s16 csc_s3_12_format;
+
+ if (csc_value >= 0) {
+ csc_value += CHV_CSC_FRACT_ROUNDOFF;
+ if (csc_value > CHV_CSC_COEFF_MAX)
+ csc_value = CHV_CSC_COEFF_MAX;
+ } else {
+ csc_value = -csc_value;
+ csc_value += CHV_CSC_FRACT_ROUNDOFF;
+ if (csc_value > CHV_CSC_COEFF_MAX + 1)
+ csc_value = CHV_CSC_COEFF_MAX + 1;
+ csc_value = -csc_value;
+ }
+
+ csc_int_value = csc_value >> CHV_CSC_COEFF_SHIFT;
+ csc_int_value <<= CHV_CSC_COEFF_INT_SHIFT;
+ if (csc_value < 0)
+ csc_int_value |= CSC_COEFF_SIGN;
+ csc_fract_value = csc_value;
+ csc_fract_value >>= CHV_CSC_COEFF_FRACT_SHIFT;
+ csc_s3_12_format = csc_int_value | csc_fract_value;
+
+ return csc_s3_12_format;
+}
+
+int chv_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ struct drm_ctm *csc_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 reg;
+ enum pipe pipe;
+ s32 word, temp;
+ int count = 0;
+
+ if (!blob) {
+ DRM_ERROR("NULL Blob\n");
+ return -EINVAL;
+ }
+
+ if (blob->length != sizeof(struct drm_ctm)) {
+ DRM_ERROR("Invalid length of data received\n");
+ return -EINVAL;
+ }
+
+ csc_data = (struct drm_ctm *)blob->data;
+ if (csc_data->version != CHV_CSC_DATA_STRUCT_VERSION) {
+ DRM_ERROR("Invalid CSC Data struct version\n");
+ return -EINVAL;
+ }
+
+ pipe = to_intel_crtc(crtc)->pipe;
+
+ /* Disable CSC functionality */
+ reg = _PIPE_CGM_CONTROL(pipe);
+ I915_WRITE(reg, I915_READ(reg) & (~CGM_CSC_EN));
+
+ DRM_DEBUG_DRIVER("Disabled CSC Functionality on Pipe %c\n",
+ pipe_name(pipe));
+
+ reg = _PIPE_CSC_BASE(pipe);
+ while (count < CSC_MAX_VALS) {
+ word = get_csc_s3_12_format(csc_data->ctm_coeff[count]);
+
+ /*
+* Last value to be written in 1 register.
+* Otherwise, each pair of CSC values go
+* into 1 register
+*/
+ if (count != (CSC_MAX_VALS - 1)) {
+ count++;
+ temp = get_csc_s3_12_format(csc_data->ctm_coeff[count]);
+ word |= temp;
+ }
+ I915_WRITE(reg, word);
+ reg += 4;
+ count++;
+ }
+
+ DRM_DEBUG_DRIVER("All CSC values written to registers\n");
+
+ /* Enable CSC functionality */
+ reg = _PIPE_CGM_CONTROL(pipe);
+ I915_WRITE(reg, I915_READ(reg) | CGM_CSC_EN);
+ DRM_DEB
[Intel-gfx] [PATCH 10/18] drm/i915: Add pipe deGamma correction handlers
From: Kausal Malladi
This patch adds set_property and get_property handlers for deGamma
color correction capability at Pipe level.
Set function just attaches the deGamma correction blob to CRTC state, which
will be later commited in the atomic commit path.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c| 7 +++
drivers/gpu/drm/i915/intel_color_manager.c | 19 +++
drivers/gpu/drm/i915/intel_drv.h | 3 +++
3 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 9f55e6c..1d8cb09 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -331,6 +331,10 @@ int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
return intel_color_manager_set_pipe_gamma(dev, state,
&crtc->base, val);
+ if (property == config->cm_palette_before_ctm_property)
+ return intel_color_manager_set_pipe_degamma(dev, state,
+ &crtc->base, val);
+
DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
return -EINVAL;
}
@@ -346,6 +350,9 @@ int intel_crtc_atomic_get_property(struct drm_crtc *crtc,
if (property == config->cm_palette_after_ctm_property)
*val = (state->palette_after_ctm_blob) ?
state->palette_after_ctm_blob->base.id : 0;
+ if (property == config->cm_palette_before_ctm_property)
+ *val = (state->palette_before_ctm_blob) ?
+ state->palette_before_ctm_blob->base.id : 0;
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index f8c8d26..5fc8e41 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -170,6 +170,25 @@ void intel_color_manager_crtc_commit(struct drm_device
*dev,
}
}
+int intel_color_manager_set_pipe_degamma(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id)
+{
+ struct drm_property_blob *blob;
+
+ blob = drm_property_lookup_blob(dev, blob_id);
+ if (!blob) {
+ DRM_ERROR("Invalid Blob ID\n");
+ return -EINVAL;
+ }
+
+ if (crtc_state->palette_before_ctm_blob)
+
drm_property_unreference_blob(crtc_state->palette_before_ctm_blob);
+
+ crtc_state->palette_before_ctm_blob = blob;
+ return 0;
+}
+
int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
struct drm_crtc_state *crtc_state,
struct drm_mode_object *obj, uint32_t blob_id)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index de3e6e7..d3b42ec 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1444,6 +1444,9 @@ void intel_attach_color_properties_to_crtc(struct
drm_device *dev,
int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
struct drm_crtc_state *crtc_state,
struct drm_mode_object *obj, uint32_t blob_id);
+int intel_color_manager_set_pipe_degamma(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id);
void intel_color_manager_crtc_commit(struct drm_device *dev,
struct drm_crtc_state *crtc_state);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/18] drm/i915: Pipe level Gamma correction for CHV/BSW
From: Kausal Malladi
CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode
This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 12 +++
drivers/gpu/drm/i915/intel_color_manager.c | 146 +
drivers/gpu/drm/i915/intel_color_manager.h | 20
drivers/gpu/drm/i915/intel_display.c | 2 +
drivers/gpu/drm/i915/intel_drv.h | 2 +
5 files changed, 182 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3a77678..4997ebd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7921,4 +7921,16 @@ enum skl_disp_power_wells {
#define GEN9_VEBOX_MOCS_0 0xcb00 /* Video MOCS base register*/
#define GEN9_BLT_MOCS_00xcc00 /* Blitter MOCS base register*/
+/* Color Management */
+#define PIPEA_CGM_CONTROL (VLV_DISPLAY_BASE + 0x67A00)
+#define PIPEB_CGM_CONTROL (VLV_DISPLAY_BASE + 0x69A00)
+#define PIPEC_CGM_CONTROL (VLV_DISPLAY_BASE + 0x6BA00)
+#define PIPEA_CGM_GAMMA(VLV_DISPLAY_BASE +
0x67000)
+#define PIPEB_CGM_GAMMA(VLV_DISPLAY_BASE +
0x69000)
+#define PIPEC_CGM_GAMMA(VLV_DISPLAY_BASE +
0x6B000)
+#define _PIPE_CGM_CONTROL(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
+#define _PIPE_GAMMA_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 9a6126c..f8c8d26 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,149 @@
#include "intel_color_manager.h"
+int chv_set_gamma(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ bool flag = false;
+ enum pipe pipe;
+ u8 red_int, blue_int, green_int;
+ u16 red_fract, green_fract, blue_fract;
+ u32 red, green, blue;
+ u32 cgm_control_reg = 0;
+ u32 cgm_gamma_reg = 0;
+ u32 count = 0, num_samples, word;
+ int ret = 0, length;
+ struct drm_r32g32b32 *correction_values = NULL;
+ struct drm_palette *gamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (!blob) {
+ DRM_ERROR("NULL Blob\n");
+ return -EINVAL;
+ }
+
+ gamma_data = (struct drm_palette *)blob->data;
+
+ if (gamma_data->version != CHV_GAMMA_DATA_STRUCT_VERSION) {
+ DRM_ERROR("Invalid Gamma Data struct version\n");
+ return -EINVAL;
+ }
+
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = gamma_data->num_samples;
+ length = num_samples * sizeof(struct drm_r32g32b32);
+
+ switch (num_samples) {
+ case 0:
+
+ /* Disable Gamma functionality on Pipe - CGM Block */
+ cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+ cgm_control_reg &= ~CGM_GAMMA_EN;
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+
+ DRM_DEBUG_DRIVER("Gamma disabled on Pipe %c\n",
+ pipe_name(pipe));
+ ret = 0;
+ break;
+
+ case CHV_8BIT_GAMMA_MAX_VALS:
+ case CHV_10BIT_GAMMA_MAX_VALS:
+
+ count = 0;
+ cgm_gamma_reg = _PIPE_GAMMA_BASE(pipe);
+ correction_values = (struct drm_r32g32b32 *)&gamma_data->lut;
+
+ while (count < num_samples) {
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ blue_int = _GAMMA_INT_PART(blue);
+ if (blue_int > GAMMA_INT_MAX)
+ blue = CHV_MAX_GAMMA;
+
+ green_int = _GAMMA_INT_PART(green);
+ if (green_int > GAMMA_INT_MAX)
+ green = CHV_MAX_GAMMA;
+
+ red_int = _GAMMA_INT_PART(red);
+ if (red_int > GAMMA_INT_MAX)
+ red = CHV_MAX_GAMMA;
+
+ blue_fract = _GAMMA_FRACT_PART(blue);
+ green_fract = _GAMMA_FRACT_PART(green);
+ red_fract = _GAMMA_FRACT_PART(red);
+
+ blue_fract >>= CHV_10BIT_GAMMA_MSB_SHIFT;
+ green_fract >>= CHV_10BIT_G
[Intel-gfx] [PATCH 05/18] drm/i915: Initialize color manager and add gamma correction
From: Kausal Malladi
As per Color Manager design, each driver is responsible to load its
palette color correction and enhancement capabilities in the form of
a DRM blob property, so that user space can query and read.
This patch does the following:
1. Create new files intel_color_manager(.c/.h)
2. Attach CRTC Palette Capabilities property to CRTC
3. Load all CHV platform specific gamma color capabilities
for CRTC into a blob that can be accessible by user space to
query capabilities via DRM property interface.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/intel_color_manager.c | 83 ++
drivers/gpu/drm/i915/intel_color_manager.h | 33
drivers/gpu/drm/i915/intel_display.c | 2 +
drivers/gpu/drm/i915/intel_drv.h | 4 ++
5 files changed, 124 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 41fb8a9..303b903 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -60,7 +60,8 @@ i915-y += intel_audio.o \
intel_overlay.o \
intel_psr.o \
intel_sideband.o \
- intel_sprite.o
+ intel_sprite.o \
+ intel_color_manager.o
i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
new file mode 100644
index 000..1c9c477
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -0,0 +1,83 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma
+ * Kausal Malladi
+ */
+
+#include "intel_color_manager.h"
+
+int get_chv_pipe_gamma_capabilities(struct drm_device *dev,
+ struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
+{
+ struct drm_property_blob *blob;
+
+ /*
+* This function exposes best capability for DeGamma and Gamma
+* For CHV, the DeGamma LUT has 65 entries
+* and the best Gamma capability has 257 entries (CGM unit)
+*/
+ palette_caps->version = CHV_PALETTE_STRUCT_VERSION;
+ palette_caps->num_samples_before_ctm =
+ CHV_DEGAMMA_MAX_VALS;
+ palette_caps->num_samples_after_ctm =
+ CHV_10BIT_GAMMA_MAX_VALS;
+
+ blob = drm_property_create_blob(dev, sizeof(struct drm_palette_caps),
+ (const void *) palette_caps);
+
+ if (blob)
+ return blob->base.id;
+
+ return 0;
+}
+
+int get_pipe_gamma_capabilities(struct drm_device *dev,
+ struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
+{
+ if (IS_CHERRYVIEW(dev))
+ return get_chv_pipe_gamma_capabilities(dev, palette_caps, crtc);
+ return -EINVAL;
+}
+
+void intel_attach_color_properties_to_crtc(struct drm_device *dev,
+ struct drm_mode_object *mode_obj)
+{
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_palette_caps *palette_caps;
+ struct drm_crtc *crtc;
+ int capabilities_blob_id;
+
+ if (IS_CHERRYVIEW(dev)) {
+ crtc = obj_to_crtc(mode_obj);
+
+ palette_caps = kzalloc(sizeof(struct drm_palette_caps),
+ GFP_KERNEL);
+ capabilities_blob_id = get_pipe_gamma_capabilities(dev,
palette_caps, crtc);
+ kfree(palette_caps);
+ if (config->cm_crtc_palette_capabilities_property)
+ drm_object_attach_property(mode_obj,
+ config->cm_crtc_palette_
[Intel-gfx] [PATCH 06/18] drm: Add color correction blobs in CRTC state
From: Kausal Malladi
This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs will be required during the atomic commit
for writing the color correction values in correction registers.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/drm/drm_crtc.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3c59045..504539a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -304,6 +304,11 @@ struct drm_crtc_state {
/* blob property to expose current mode to atomic userspace */
struct drm_property_blob *mode_blob;
+ /* blob properties to hold the color properties' blobs */
+ struct drm_property_blob *palette_before_ctm_blob;
+ struct drm_property_blob *palette_after_ctm_blob;
+ struct drm_property_blob *ctm_blob;
+
struct drm_pending_vblank_event *event;
struct drm_atomic_state *state;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/18] drm: Add structure for querying palette color capabilities
From: Kausal Malladi
The DRM color management framework is targeting various hardware
platforms and drivers. Different platforms can have different color
correction and enhancement capabilities.
A commom user space application can query these capabilities using the
DRM property interface. Each driver can fill this property with its
platform's palette color capabilities.
This patch adds new structure in DRM layer for querying palette color
capabilities. This structure will be used by all user space
agents to configure appropriate color configurations.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..e3c642f 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -829,6 +829,17 @@ struct drm_event_vblank {
__u32 reserved;
};
+struct drm_palette_caps {
+ /* Structure version. Should be 1 currently */
+ __u32 version;
+ /* For padding and future use */
+ __u32 reserved;
+ /* This may be 0 if not supported. e.g. plane palette or VLV pipe */
+ __u32 num_samples_before_ctm;
+ /* This will be non-zero for pipe. May be zero for planes on some HW */
+ __u32 num_samples_after_ctm;
+};
+
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/18] drm: Add drm structures for palette color property
From: Kausal Malladi
This patch adds new structures in DRM layer for Palette color
correction.These structures will be used by user space agents
to configure appropriate number of samples and Palette LUT for
a platform.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index e3c642f..f72b916 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -840,6 +840,33 @@ struct drm_palette_caps {
__u32 num_samples_after_ctm;
};
+struct drm_r32g32b32 {
+ /*
+* Data is in U8.24 fixed point format.
+* All platforms support values within [0, 1.0] range,
+* for Red, Green and Blue colors.
+*/
+ __u32 r32;
+ __u32 g32;
+ __u32 b32;
+};
+
+struct drm_palette {
+ /* Structure version. Should be 1 currently */
+ __u32 version;
+ /*
+* This has to be a supported value during get call.
+* Feature will be disabled if this is 0 while set
+*/
+ __u32 num_samples;
+ /*
+* Starting of palette LUT in R32G32B32 format.
+* Each of RGB value is in U8.24 fixed point format.
+* Actual number of samples will depend upon num_samples
+*/
+ struct drm_r32g32b32 lut[0];
+};
+
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/18] drm/i915: Add pipe gamma correction handlers
From: Kausal Malladi
I915 driver registers gamma correction as palette correction
property with DRM layer. This patch adds set_property() and get_property()
handlers for pipe level gamma correction.
The set function attaches the Gamma correction blob to CRTC state, these
values will be committed during atomic commit.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c| 14 ++
drivers/gpu/drm/i915/intel_color_manager.c | 20
drivers/gpu/drm/i915/intel_drv.h | 3 +++
3 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 8d04ee8..9f55e6c 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -324,6 +324,13 @@ int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
struct drm_property *property,
uint64_t val)
{
+ struct drm_device *dev = crtc->dev;
+ struct drm_mode_config *config = &dev->mode_config;
+
+ if (property == config->cm_palette_after_ctm_property)
+ return intel_color_manager_set_pipe_gamma(dev, state,
+ &crtc->base, val);
+
DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
return -EINVAL;
}
@@ -333,5 +340,12 @@ int intel_crtc_atomic_get_property(struct drm_crtc *crtc,
struct drm_property *property,
uint64_t *val)
{
+ struct drm_device *dev = crtc->dev;
+ struct drm_mode_config *config = &dev->mode_config;
+
+ if (property == config->cm_palette_after_ctm_property)
+ *val = (state->palette_after_ctm_blob) ?
+ state->palette_after_ctm_blob->base.id : 0;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 1c9c477..9a6126c 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,26 @@
#include "intel_color_manager.h"
+int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id)
+{
+ struct drm_property_blob *blob;
+
+ blob = drm_property_lookup_blob(dev, blob_id);
+ if (!blob) {
+ DRM_ERROR("Invalid Blob ID\n");
+ return -EINVAL;
+ }
+
+ if (crtc_state->palette_after_ctm_blob)
+
drm_property_unreference_blob(crtc_state->palette_after_ctm_blob);
+
+ /* Attach the blob to be commited in state */
+ crtc_state->palette_after_ctm_blob = blob;
+ return 0;
+}
+
int get_chv_pipe_gamma_capabilities(struct drm_device *dev,
struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dee5f91..820ded7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1441,5 +1441,8 @@ extern const struct drm_plane_helper_funcs
intel_plane_helper_funcs;
/* intel_color_manager.c */
void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_mode_object *mode_obj);
+int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id);
#endif /* __INTEL_DRV_H__ */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/18] Color Management for DRM
This patch set adds Color Manager implementation in DRM layer. Color Manager is an extension in DRM framework to support color correction/enhancement. Various Hardware platforms can support several color correction capabilities. Color Manager provides abstraction of these capabilities and allows a user space UI agent to correct/enhance the display using the DRM property interface. How is this going to work? == 1. This patch series adds a few new properties in DRM framework. These properties are: a. color_capabilities property (type blob) b. Color Transformation Matrix property for corrections like CSC (called CTM, type blob) c. Palette correction properties for corrections like gamma fixup (called palette_correction, type blob) 2. Also, this patch series adds few structures to indicate specifications of a property like size, no_of_samples for correction etc. 3. These properties are present in mode_config. 4. When the platform's display driver loads, it fills up the values of color_capabilities property using the standard structures (added in step 2). For example, Intel's I915 driver adds following color correction capabilities: a. gamma correction capability as palette correction property, with 257 correction coefficients and a max/min value b. csc correction capability as CTM correction property, with 3x3 transformation matrix values and max/min values 5. Now when userspace comes up, it queries the platform's color capabilities by doing a get_property() on color_capabilities DRM property 6. Reading the blob, the userspace understands the color capabilities of the platform. For example, userspace will understand it can support: a. palette_correction with 257 coefficients b. CSC correction with 3x3 = 9 values 7. To set color correction values, userspace: a. creates a blob using the create_blob_ioctl in standard palette_correction structure format, with the correction values b. calls the set_property_ioctl with the blob_id as value for the property 8. Driver refers to the blob, gets the correction values and applies the correction in HW. 9. To get currently applied color correction values, userspace: a. calls a get_property_ioctl on that color property b. gets the blob_id for the currently applied correction from DRM infrastructure c. gets the blob using get_blob_ioctl and hence the currently applied values That's all! :) About the patch series: === The first patch adds fix for ensuring atomic commit for CRTC properties. The subsequent patches add code for the framework, which will be common across all the Hardware platforms. 1. Create Color Management DRM properties 2. Attach color properties to CRTC 3. Add structures at DRM level for color management The generic properties supported in this patch set are 1. Color Transformation Matrix (CTM) for generic usecases like color space conversion and Gamut Mapping 2. Palette correction before CTM for specific usecases like DeGamma color correction 3. Palette correction after CTM for specific usecases like Gamma color correction In the subsequent patches, we are adding support for Gamma, DeGamma and CSC color properties for one of the Intel platforms. Our thanks to all the reviewers who have given valuable comments in terms of design and implementation to our previous sets of patches. Special mention of thanks should go to Matt Roper for all his inputs/suggestions in implementation of this module, using DRM atomic CRTC commit path. V2: Worked on review comments from Matt, Jim, Thierry, Rob. Shashank Sharma (18): drm: Create Color Management DRM properties drm/i915: Add atomic set property interface for CRTC drm/i915: Add atomic get property interface for CRTC drm: Add structure for querying palette color capabilities drm/i915: Initialize color manager and add gamma correction drm: Add color correction blobs in CRTC state drm: Add drm structures for palette color property drm/i915: Add pipe gamma correction handlers drm/i915: Pipe level Gamma correction for CHV/BSW drm/i915: Add pipe deGamma correction handlers drm/i915: Add DeGamma correction for CHV/BSW drm: Add structure for set/get a CTM color property drm/i915: Add set/get property handlers for CSC correction drm/i915: Add CSC correction for CHV/BSW drm/i915: Initialize Gen8 pipe gamma correction drm/i915: Gen8 pipe level Gamma correction drm/i915: Add DeGamma correction for BDW/SKL/BXT drm/i915: Add CSC correction for BDW/SKL/BXT drivers/gpu/drm/drm_crtc.c | 26 + drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/i915_reg.h| 44 +- drivers/gpu/drm/i915/intel_atomic.c| 43 ++ drivers/gpu/drm/i915/intel_color_manager.c | 970 + drivers/gpu/drm/i915/intel_color_manager.h | 117 drivers/gpu/drm/i915/intel_di
[Intel-gfx] [PATCH 02/18] drm/i915: Add atomic set property interface for CRTC
From: Kausal Malladi
This patch adds atomic set property interface for Intel CRTC. This
interface will be used for set operation on any DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c | 9 +
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 4
3 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index e2531cf..922fecf 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -318,3 +318,12 @@ void intel_atomic_state_clear(struct drm_atomic_state *s)
drm_atomic_state_default_clear(&state->base);
state->dpll_set = false;
}
+
+int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
+ struct drm_crtc_state *state,
+ struct drm_property *property,
+ uint64_t val)
+{
+ DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
+ return -EINVAL;
+}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 43b0f17..1fbf0ff 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13351,6 +13351,8 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy = intel_crtc_destroy,
.page_flip = intel_crtc_page_flip,
+ .set_property = drm_atomic_helper_crtc_set_property,
+ .atomic_set_property = intel_crtc_atomic_set_property,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
};
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6..c0ae529 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1422,6 +1422,10 @@ intel_atomic_get_crtc_state(struct drm_atomic_state
*state,
int intel_atomic_setup_scalers(struct drm_device *dev,
struct intel_crtc *intel_crtc,
struct intel_crtc_state *crtc_state);
+int intel_crtc_atomic_set_property(struct drm_crtc *plane,
+ struct drm_crtc_state *state,
+ struct drm_property *property,
+ uint64_t val);
/* intel_atomic_plane.c */
struct intel_plane_state *intel_create_plane_state(struct drm_plane *plane);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/18] drm: Create Color Management DRM properties
From: Kausal Malladi
Color Management is an extension to Kernel display framework. It allows
abstraction of hardware color correction and enhancement capabilities by
virtue of DRM properties.
This patch initializes color management framework by :
1. Introducing new pointers in DRM mode_config structure to
carry CTM and Palette color correction properties.
2. Creating these DRM properties in DRM standard properties creation
sequence.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm/drm_crtc.h | 6 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index bd515da..c12871c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1462,6 +1462,32 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_mode_id = prop;
+ /* Color Management properties */
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB | DRM_MODE_PROP_IMMUTABLE,
+ "CRTC_PALETTE_CAPABILITIES", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_crtc_palette_capabilities_property = prop;
+
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "PALETTE_AFTER_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_palette_after_ctm_property = prop;
+
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "PALETTE_BEFORE_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_palette_before_ctm_property = prop;
+
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_ctm_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5746569..3c59045 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1157,6 +1157,12 @@ struct drm_mode_config {
struct drm_property *suggested_x_property;
struct drm_property *suggested_y_property;
+ /* Color Management Properties */
+ struct drm_property *cm_crtc_palette_capabilities_property;
+ struct drm_property *cm_palette_before_ctm_property;
+ struct drm_property *cm_palette_after_ctm_property;
+ struct drm_property *cm_ctm_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/18] drm/i915: Add atomic get property interface for CRTC
From: Kausal Malladi
This patch adds atomic get property interface for Intel CRTC. This
interface will be used for get operation on any non-core DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c | 8
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 4
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 922fecf..8d04ee8 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -327,3 +327,11 @@ int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
return -EINVAL;
}
+
+int intel_crtc_atomic_get_property(struct drm_crtc *crtc,
+ const struct drm_crtc_state *state,
+ struct drm_property *property,
+ uint64_t *val)
+{
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1fbf0ff..1412e21 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13353,6 +13353,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.page_flip = intel_crtc_page_flip,
.set_property = drm_atomic_helper_crtc_set_property,
.atomic_set_property = intel_crtc_atomic_set_property,
+ .atomic_get_property = intel_crtc_atomic_get_property,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
};
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c0ae529..b3dc138 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1426,6 +1426,10 @@ int intel_crtc_atomic_set_property(struct drm_crtc
*plane,
struct drm_crtc_state *state,
struct drm_property *property,
uint64_t val);
+int intel_crtc_atomic_get_property(struct drm_crtc *plane,
+ const struct drm_crtc_state *state,
+ struct drm_property *property,
+ uint64_t *val);
/* intel_atomic_plane.c */
struct intel_plane_state *intel_create_plane_state(struct drm_plane *plane);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 17/19] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset
On 8/6/2015 1:47 PM, Daniel Vetter wrote: On Wed, Aug 05, 2015 at 05:14:33PM +0100, Michel Thierry wrote: On 8/5/2015 4:58 PM, Daniel Vetter wrote: On Wed, Jul 29, 2015 at 05:24:01PM +0100, Michel Thierry wrote: There are some allocations that must be only referenced by 32-bit offsets. To limit the chances of having the first 4GB already full, objects not requiring this workaround use DRM_MM_SEARCH_BELOW/ DRM_MM_CREATE_TOP flags 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. Objects must have EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag to indicate if they can be allocated above the 32-bit address range. To limit the chances of having the first 4GB already full, objects will use DRM_MM_SEARCH_BELOW + DRM_MM_CREATE_TOP flags when possible. v2: Changed flag logic from neeeds_32b, to supports_48b. v3: Moved 48-bit support flag back to exec_object. (Chris, Daniel) v4: Split pin flags into PIN_ZONE_4G and PIN_HIGH; update PIN_OFFSET_MASK to use last PIN_ defined instead of hard-coded value; use correct limit check in eb_vma_misplaced. (Chris) v5: Don't touch PIN_OFFSET_MASK and update workaround comment (Chris) v6: Apply pin-high for ggtt too (Chris) v7: Handle simultaneous pin-high and pin-mappable end correctly (Akash) Fix check for entries currently using +4GB addresses, use min_t and other polish in object_bind_to_vm (Chris) Cc: Chris Wilson Cc: Akash Goel Reviewed-by: Chris Wilson (v4) Signed-off-by: Michel Thierry For the record, where can I find the mesa patches for this? I think for simple things like this a References: line point to the relevant UMD patches in mailing-list archives would be great. -Daniel Here they are, References: http://lists.freedesktop.org/archives/dri-devel/2015-July/085501.html and http://lists.freedesktop.org/archives/mesa-dev/2015-July/088003.html Sounds like there's still another revision we need to do on those? Yes, a couple of changes, set/clear functions internal in libdrm and update the symbol-check test. I put it on hold, because I was also asked to not include the libdrm changes until the updated kernel header (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag) was merged. Then I also need to create a libdrm release, and update mesa's dependency to this new version number. -Michel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use masked write for Context Status Buffer Pointer
On 8/6/2015 5:03 PM, Daniel Vetter wrote: On Thu, Aug 06, 2015 at 03:25:55PM +0100, Michel Thierry wrote: On 8/6/2015 3:00 PM, Mika Kuoppala wrote: This register needs to be updated with masked writes. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 99bba8e..29347e7 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -521,7 +521,7 @@ void intel_lrc_irq_handler(struct intel_engine_cs *ring) ring->next_context_status_buffer = write_pointer % 6; I915_WRITE(RING_CONTEXT_STATUS_PTR(ring), - ((u32)ring->next_context_status_buffer & 0x07) << 8); + _MASKED_FIELD(0x07 << 8, ((u32)ring->next_context_status_buffer & 0x07) << 8)); } static int execlists_context_queue(struct drm_i915_gem_request *request) -- 2.1.4 bspec agrees... but I remember seeing these bits being written without the mask in gen8. Impact? Do I need this for -fixes with cc: stable? lrc is shipping as released code, please be a bit more elaborate in your commit messages. I'll let Mika give more details, but it looks inoffensive to me. The lrc irq handler relies on bits[3:0] only (the read pointer, which is read-only and is updated by the hw automatically), and never reads the write pointer back. It would only impact us when reading the register directly, e.g. while debugging another issue. -Michel Thanks, Daniel Reviewed-by: Michel Thierry ___ 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: Check idle to active before processing CSQ
On Thu, Aug 06, 2015 at 05:09:17PM +0300, Mika Kuoppala wrote:
> If idle to active bit is set, the rest of the fields
> in CSQ are not valid.
>
> Bail out early if this is the case in order to prevent
> rest of the loop inspecting stale values.
>
> Signed-off-by: Mika Kuoppala
Same questions here too, what's the impact. E.g. if you only found this by
bspec/code inspection then it's for -next, but if it's to fix some known
breakage then it's for -fixes + cc: stable.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 99bba8e..96218bf 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -497,6 +497,9 @@ void intel_lrc_irq_handler(struct intel_engine_cs *ring)
> status_id = I915_READ(RING_CONTEXT_STATUS_BUF(ring) +
> (read_pointer % 6) * 8 + 4);
>
> + if (status & GEN8_CTX_STATUS_IDLE_ACTIVE)
> + continue;
> +
> if (status & GEN8_CTX_STATUS_PREEMPTED) {
> if (status & GEN8_CTX_STATUS_LITE_RESTORE) {
> if (execlists_check_remove_request(ring,
> status_id))
> --
> 2.1.4
>
> ___
> 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use masked write for Context Status Buffer Pointer
On Thu, Aug 06, 2015 at 03:25:55PM +0100, Michel Thierry wrote: > On 8/6/2015 3:00 PM, Mika Kuoppala wrote: > >This register needs to be updated with masked writes. > > > >Signed-off-by: Mika Kuoppala > >--- > > drivers/gpu/drm/i915/intel_lrc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >b/drivers/gpu/drm/i915/intel_lrc.c > >index 99bba8e..29347e7 100644 > >--- a/drivers/gpu/drm/i915/intel_lrc.c > >+++ b/drivers/gpu/drm/i915/intel_lrc.c > >@@ -521,7 +521,7 @@ void intel_lrc_irq_handler(struct intel_engine_cs *ring) > > ring->next_context_status_buffer = write_pointer % 6; > > > > I915_WRITE(RING_CONTEXT_STATUS_PTR(ring), > >- ((u32)ring->next_context_status_buffer & 0x07) << 8); > >+ _MASKED_FIELD(0x07 << 8, > >((u32)ring->next_context_status_buffer & 0x07) << 8)); > > } > > > > static int execlists_context_queue(struct drm_i915_gem_request *request) > >-- > >2.1.4 > > > > bspec agrees... but I remember seeing these bits being written without the > mask in gen8. Impact? Do I need this for -fixes with cc: stable? lrc is shipping as released code, please be a bit more elaborate in your commit messages. Thanks, Daniel > Reviewed-by: Michel Thierry > ___ > 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 12/13] drm/i915: Only update mode related state if a modeset happened.
On Thu, Aug 06, 2015 at 04:06:58PM +0200, Maarten Lankhorst wrote:
> Op 06-08-15 om 15:12 schreef Daniel Vetter:
> > On Wed, Aug 05, 2015 at 12:37:10PM +0200, Maarten Lankhorst wrote:
> >> The rest will be a noop anyway, since without modeset there will be
> >> no updated dplls and no modeset state to update.
> >>
> >> Signed-off-by: Maarten Lankhorst
> >> ---
> >> drivers/gpu/drm/i915/intel_display.c | 30 +++---
> >> 1 file changed, 7 insertions(+), 23 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 1fd8b7dec7da..aa444cbc2262 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -12181,33 +12181,15 @@ fail:
> >>return ret;
> >> }
> >>
> >> -static bool intel_crtc_in_use(struct drm_crtc *crtc)
> >> -{
> >> - struct drm_encoder *encoder;
> >> - struct drm_device *dev = crtc->dev;
> >> -
> >> - list_for_each_entry(encoder, &dev->mode_config.encoder_list, head)
> >> - if (encoder->crtc == crtc)
> >> - return true;
> >> -
> >> - return false;
> >> -}
> >> -
> >> static void
> >> -intel_modeset_update_state(struct drm_atomic_state *state)
> >> +intel_modeset_update_crtc_state(struct drm_atomic_state *state)
> >> {
> >>struct drm_crtc *crtc;
> >>struct drm_crtc_state *crtc_state;
> >>int i;
> >>
> >> - intel_shared_dpll_commit(state);
> > This should be right next to swap_state, and we should probably rename it
> > to be consistent.
> After some digging I think this could work if we no longer check
> pll->config.crtc_mask
> in intel_disable_shared_dpll.
>
> If we check crtc_mask in intel_enable_shared_dpll we can remove the one from
> disable
> and prepare, and let the hw checker deal with it.
Yeah I think moving all the state checks into the checker would be useful
- my comment was really a high-level "this is how it should be" comment,
without looking into the details ;-9
> >> -
> >> - drm_atomic_helper_update_legacy_modeset_state(state->dev, state);
> > This helper should always work, why try to optimize things?
> I didn't see the point of going through the connector state,
> but shrug I guess the extra loops probably don't matter.
modeset is expensive, a few more loops won't hurt I think.
> >> -
> >>/* Double check state. */
> >>for_each_crtc_in_state(state, crtc, crtc_state, i) {
> >> - WARN_ON(crtc->state->enable != intel_crtc_in_use(crtc));
> > I guess this WARN_ON should be moved into the state checker? Or entirely
> > removed if redundant.
> It's removed because the atomic core does this for us.
Separate patch and should be explained in the commit message ;-)
-Daniel
--
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] [PATCH v3.1 1/3] drm/i915: Fix broken mst get_hw_state.
On Thu, Aug 06, 2015 at 03:37:08PM +0200, Maarten Lankhorst wrote:
> Op 06-08-15 om 14:59 schreef Daniel Vetter:
> > On Thu, Aug 06, 2015 at 01:47:35PM +0200, Maarten Lankhorst wrote:
> >> This function always returned false because intel_connector->encoder
> >> is always NULL. Instead use the attached encoder from atomic.
> > Note that you've broken this since you removed the updating of
> > intel_connector->encoder somewhere in the 4.3 atomic series. So this is a
> > regression fix. Can you please digg out the right commit?
>
> Looks like 'Use full atomic modeset' broke it. intel_connector->encoder was
> updated in its set_config function..
>
> Would below amend for this commit be good?
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index ee2a77144373..671715ba8538 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -173,6 +173,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;
>
>
> And corresponding amendment to the convert connector to atomic..
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a6617283b1bd..90caa62cf2c3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6313,7 +6313,7 @@ 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;
Nah, I don't want to keep using the legacy stuff, your patch is good imo.
What I wanted is sha1 of the patches which broke the old
intel_connector->encoder trick.
And of course we get to chase around the code for all the other users of
intel_connector->encoder.
-Daniel
>
> I915_STATE_WARN(conn_state->best_encoder != encoder,
>
> >> Signed-off-by: Maarten Lankhorst
> >> ---
> >> drivers/gpu/drm/i915/intel_dp_mst.c | 7 +--
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> >> b/drivers/gpu/drm/i915/intel_dp_mst.c
> >> index e3a5864160fa..ff01569158ea 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> >> @@ -395,9 +395,12 @@ 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) {
> >> + struct intel_encoder *encoder;
> >> +
> >> + encoder = to_intel_encoder(connector->base.state->best_encoder);
> > Strictly speaking this won't work for hw state readout since what we
> > really need to do is ask the mst connector which mst stream it accepts and
> > then compare that with all the mst encoders ...
> It's good enough to make sure the encoder callbacks did run.
> > But that's been broken since forever. Only side-effect here is that
> > fastboot won't work with mst and that's imo totally ok. Please also add
> > this to your commit message.
> HW readout runs before mst probing, so you wouldn't get the mst connectors
> anyway with fastboot. Not sure it needs a fixme. :-)
--
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] [PATCH 1/6] drm/i915/skl: Enable DDI-E
On Thu, 2015-08-06 at 17:14 +0200, Daniel Vetter wrote:
> On Thu, Aug 06, 2015 at 03:51:36PM +0800, Xiong Zhang wrote:
> > From: Rodrigo Vivi
> >
> > There are OEMs using DDI-E out there,
> > so let's enable it.
> >
> > Unfortunately there is no detection bit for DDI-E
> > So we need to rely on VBT for that.
> >
> > I also need to give credits to Xiong since before seing
> > his approach to check info->support_* I was creating an ugly
> > vbt->ddie_sfuse_strap in order to propagate the ddi presence info
> >
> > Credits-to: "Zhang, Xiong Y"
> > Cc: "Zhang, Xiong Y"
> > Signed-off-by: Rodrigo Vivi
>
> btw how is this series related to
>
> http://lists.freedesktop.org/archives/intel-gfx/2015-April/065227.html
>
> Do we need that still? Can you please include that patch in your series if
> so?
yes, that patch is related because DDI-A and DDI-E shares 2 lanes...
when DDI-E is in use DDI-A needs to be configured to use only 2 lanes
and 4 otherwise.
However the approach on that patch was wrong anyway since on the last
line we see that DDI_A_4_LANES was being set unconditionally already.
So I believe we probably need to unset or avoid setting this when vbt
tells ddi-e is in use instead of setting it when ddi-e is not used like
in that patch.
Thanks
> -Daniel
>
> > ---
> > drivers/gpu/drm/i915/intel_bios.c| 14 +++---
> > drivers/gpu/drm/i915/intel_bios.h| 2 ++
> > drivers/gpu/drm/i915/intel_display.c | 9 +
> > 3 files changed, 18 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 2ff9eb0..55b5072 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -898,19 +898,19 @@ static void parse_ddi_port(struct drm_i915_private
> > *dev_priv, enum port port,
> > /* Each DDI port can have more than one value on the "DVO Port" field,
> > * so look for all the possible values for each port and abort if more
> > * than one is found. */
> > - int dvo_ports[][2] = {
> > - {DVO_PORT_HDMIA, DVO_PORT_DPA},
> > - {DVO_PORT_HDMIB, DVO_PORT_DPB},
> > - {DVO_PORT_HDMIC, DVO_PORT_DPC},
> > - {DVO_PORT_HDMID, DVO_PORT_DPD},
> > - {DVO_PORT_CRT, -1 /* Port E can only be DVO_PORT_CRT */ },
> > + int dvo_ports[][3] = {
> > + {DVO_PORT_HDMIA, DVO_PORT_DPA, -1},
> > + {DVO_PORT_HDMIB, DVO_PORT_DPB, -1},
> > + {DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
> > + {DVO_PORT_HDMID, DVO_PORT_DPD, -1},
> > + {DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
> > };
> >
> > /* Find the child device to use, abort if more than one found. */
> > for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> > it = dev_priv->vbt.child_dev + i;
> >
> > - for (j = 0; j < 2; j++) {
> > + for (j = 0; j < 3; j++) {
> > if (dvo_ports[port][j] == -1)
> > break;
> >
> > diff --git a/drivers/gpu/drm/i915/intel_bios.h
> > b/drivers/gpu/drm/i915/intel_bios.h
> > index f7ad6a5..02255d8 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.h
> > +++ b/drivers/gpu/drm/i915/intel_bios.h
> > @@ -764,6 +764,8 @@ int intel_parse_bios(struct drm_device *dev);
> > #define DVO_PORT_DPC 8
> > #define DVO_PORT_DPD 9
> > #define DVO_PORT_DPA 10
> > +#define DVO_PORT_DPE 11
> > +#define DVO_PORT_HDMIE 12
> > #define DVO_PORT_MIPIA 21
> > #define DVO_PORT_MIPIB 22
> > #define DVO_PORT_MIPIC 23
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index af0bcfe..aaa34b8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14123,6 +14123,15 @@ static void intel_setup_outputs(struct drm_device
> > *dev)
> > intel_ddi_init(dev, PORT_C);
> > if (found & SFUSE_STRAP_DDID_DETECTED)
> > intel_ddi_init(dev, PORT_D);
> > + /*
> > +* On SKL we don't have a way to detect DDI-E so we rely on VBT.
> > +*/
> > + if (IS_SKYLAKE(dev) &&
> > + (dev_priv->vbt.ddi_port_info[PORT_E].supports_dp ||
> > +dev_priv->vbt.ddi_port_info[PORT_E].supports_dvi ||
> > +dev_priv->vbt.ddi_port_info[PORT_E].supports_hdmi))
> > + intel_ddi_init(dev, PORT_E);
> > +
> > } else if (HAS_PCH_SPLIT(dev)) {
> > int found;
> > dpd_is_edp = intel_dp_is_edp(dev, PORT_D);
> > --
> > 2.1.4
> >
> > ___
> > 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 v3.1 3/3] drm/i915: Don't try to remove MST cleanly when force removed.
On Thu, Aug 06, 2015 at 03:51:31PM +0200, Maarten Lankhorst wrote: > Hey, > > Op 06-08-15 om 15:01 schreef Daniel Vetter: > > On Thu, Aug 06, 2015 at 01:47:37PM +0200, Maarten Lankhorst wrote: > >> Physically disconnecting a DP connector with an active MST stream > >> can lead to a kernel panic in intel_mst_disable_dp when calling > >> drm_dp_update_payload_part1. Examining the code it seems that the > >> port is freed while work to remove the connector is scheduled. > >> > >> This probably means it's fine to skip call all the mst helper calls > >> and only attempt to disable the real encoder. > > I think this is a refcounting bug in the dp mst helpers, the port > > shouldn't just go poof when we still hold a reference to it. Can you > > please try to figure out what's really broken here, and if that's too > > tricky add a big FIXME comment? > Look at drm_dp_destroy_port, it calls > schedule_work(&mgr->destroy_connector_work), and also calls kfree(port). > > Doesn't look like a refcounting bug to me, more like something intentional. Intentionally buggy is still buggy ;-) And yeah we probably need to separate the port cleanup due to unplug (i.e. the driver callback) from freeing the port. And the intel_connector should hold a reference onto the underlying port I think. Of course it would be best to do the get/put on the port in the mst helper itself (so that we don't need to change i915/radeon). -Daniel -- 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] [SKL-DMC-BUGFIX 2/5] drm/i915/skl: Making DC6 entry is the last call in suspend flow.
On Thu, Aug 06, 2015 at 08:08:58PM +0530, Animesh Manna wrote:
>
>
> On 8/6/2015 6:48 PM, Daniel Vetter wrote:
> >On Thu, Aug 06, 2015 at 02:47:22PM +0530, Animesh Manna wrote:
> >>
> >>On 8/5/2015 2:35 PM, Daniel Vetter wrote:
> >>>On Mon, Aug 03, 2015 at 09:55:33PM +0530, Animesh Manna wrote:
> Mmio register access after dc6/dc5 entry is not allowed when
> DC6 power states are enabled according to bspec (bspec-id 0527),
> so enabling dc6 as the last call in suspend flow.
>
> v1: Initial version.
>
> v2: commit message updated based on comment from Vathsala.
>
> Cc: Daniel Vetter
> Cc: Damien Lespiau
> Cc: Imre Deak
> Cc: Sunil Kamath
> Signed-off-by: Animesh Manna
> Signed-off-by: Vathsala Nagaraju
> Signed-off-by: Rajneesh Bhardwaj
> ---
> drivers/gpu/drm/i915/i915_drv.c | 12 ++--
> drivers/gpu/drm/i915/intel_drv.h| 2 ++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 33
> -
> 3 files changed, 16 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 0d6775a..e1d0102 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1017,14 +1017,11 @@ static int skl_suspend_complete(struct
> drm_i915_private *dev_priv)
> {
> /* Enabling DC6 is not a hard requirement to enter runtime D3 */
> - /*
> - * This is to ensure that CSR isn't identified as loaded before
> - * CSR-loading program is called during runtime-resume.
> - */
> - intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
> >>>Seems like an unrelated hunk. Separate patch (in the dmc loader rework
> >>>series) or an explanation why we need this.
> >>In the same skl_suspend_complete() later we are checking if firmware is
> >>loaded,
> >>based on that we trigger dc6, so the above hunk has to be removed in this
> >>patch.
> >I know that later on we'll replace this with something else, but you can't
> >remove old code before the new code is there. And you can't do changes
> >like this here in unrelated patches.
>
> code snippet added in this patch:
> + if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
> + skl_enable_dc6(dev_priv);
>
> We can add uninitilized call here after this which will be related changes.
> After dmc redesign will remove it completely the function call for csr
> uninitialization.
Oh right I was getting a bit confused here, that change does make sense.
But the patch should explain better why/how this all gets changed.
Obviously if we keep on setting status to UNITIALIZED then this check here
will always fall over.
Might be good to split up this patch into parts
1. Remove the UNITIALIZED from suspend path since dmc stays around. Also
handle re-loading on hibernate resume correctly.
2. Adjust ordering between dc5 and dc6 for dmc.
I think there's still more parts in this patch, e.g. you also remove the
wait_for ...
> >>On the other hand firmware team confirmed that one time firmware loading
> >>during driver loading is sufficient, no need to load firmware in
> >>csr-address-space every suspend (dc6 entry) - resume (dc6 exit) flow, dmc
> >>will
> >>take care of it which eliminate any chance of regression.
> >And what about hibernate?
>
> Yes, during hibernate I assumed os will restore the ram content from disk.
> But specially for csr program we need to load it again. Thanks for the
> pointer.
Hibernate is really tricky, so please try to test that fully. The big risk
is resume:
- first we load a normal kernel, including i915 and everything
- then that first kernel loads the hibernate image
- then all hw gets shut down like with a normal suspend call
- then we resume everything again
Given all this we might need to check the hw state itself whether dmc is
loaded already and only load it if that's the case. Otherwise bad stuff
might happen.
-Daniel
>
>
> -Animesh
>
> >-Daniel
> >>- Animesh
> >>
> -
> skl_uninit_cdclk(dev_priv);
> + if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
> + skl_enable_dc6(dev_priv);
> +
> return 0;
> }
> @@ -1071,6 +1068,9 @@ static int skl_resume_prepare(struct
> drm_i915_private *dev_priv)
> {
> struct drm_device *dev = dev_priv->dev;
> + if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
> + skl_disable_dc6(dev_priv);
> +
> skl_init_cdclk(dev_priv);
> intel_csr_load_program(dev);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 47cef0e..06f346f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1117,6 +1117,8 @@ void bxt_enable_dc9(struct drm_i915_private
> *dev_priv);
> void
Re: [Intel-gfx] [PATCH 1/6] drm/i915/skl: Enable DDI-E
On Thu, 2015-08-06 at 15:30 +0200, Daniel Vetter wrote:
> On Thu, Aug 06, 2015 at 03:51:36PM +0800, Xiong Zhang wrote:
> > From: Rodrigo Vivi
> >
> > There are OEMs using DDI-E out there,
> > so let's enable it.
> >
> > Unfortunately there is no detection bit for DDI-E
> > So we need to rely on VBT for that.
> >
> > I also need to give credits to Xiong since before seing
> > his approach to check info->support_* I was creating an ugly
> > vbt->ddie_sfuse_strap in order to propagate the ddi presence info
> >
> > Credits-to: "Zhang, Xiong Y"
> > Cc: "Zhang, Xiong Y"
> > Signed-off-by: Rodrigo Vivi
>
> Enable patches like these should be last in the series, since before all
> the other stuff things will simply be broken.
ops, my bad...
totally agree...
I will rebase locally here moving this up...
> -Daniel
>
> > ---
> > drivers/gpu/drm/i915/intel_bios.c| 14 +++---
> > drivers/gpu/drm/i915/intel_bios.h| 2 ++
> > drivers/gpu/drm/i915/intel_display.c | 9 +
> > 3 files changed, 18 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 2ff9eb0..55b5072 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -898,19 +898,19 @@ static void parse_ddi_port(struct drm_i915_private
> > *dev_priv, enum port port,
> > /* Each DDI port can have more than one value on the "DVO Port" field,
> > * so look for all the possible values for each port and abort if more
> > * than one is found. */
> > - int dvo_ports[][2] = {
> > - {DVO_PORT_HDMIA, DVO_PORT_DPA},
> > - {DVO_PORT_HDMIB, DVO_PORT_DPB},
> > - {DVO_PORT_HDMIC, DVO_PORT_DPC},
> > - {DVO_PORT_HDMID, DVO_PORT_DPD},
> > - {DVO_PORT_CRT, -1 /* Port E can only be DVO_PORT_CRT */ },
> > + int dvo_ports[][3] = {
> > + {DVO_PORT_HDMIA, DVO_PORT_DPA, -1},
> > + {DVO_PORT_HDMIB, DVO_PORT_DPB, -1},
> > + {DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
> > + {DVO_PORT_HDMID, DVO_PORT_DPD, -1},
> > + {DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
> > };
> >
> > /* Find the child device to use, abort if more than one found. */
> > for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> > it = dev_priv->vbt.child_dev + i;
> >
> > - for (j = 0; j < 2; j++) {
> > + for (j = 0; j < 3; j++) {
> > if (dvo_ports[port][j] == -1)
> > break;
> >
> > diff --git a/drivers/gpu/drm/i915/intel_bios.h
> > b/drivers/gpu/drm/i915/intel_bios.h
> > index f7ad6a5..02255d8 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.h
> > +++ b/drivers/gpu/drm/i915/intel_bios.h
> > @@ -764,6 +764,8 @@ int intel_parse_bios(struct drm_device *dev);
> > #define DVO_PORT_DPC 8
> > #define DVO_PORT_DPD 9
> > #define DVO_PORT_DPA 10
> > +#define DVO_PORT_DPE 11
> > +#define DVO_PORT_HDMIE 12
> > #define DVO_PORT_MIPIA 21
> > #define DVO_PORT_MIPIB 22
> > #define DVO_PORT_MIPIC 23
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index af0bcfe..aaa34b8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14123,6 +14123,15 @@ static void intel_setup_outputs(struct drm_device
> > *dev)
> > intel_ddi_init(dev, PORT_C);
> > if (found & SFUSE_STRAP_DDID_DETECTED)
> > intel_ddi_init(dev, PORT_D);
> > + /*
> > +* On SKL we don't have a way to detect DDI-E so we rely on VBT.
> > +*/
> > + if (IS_SKYLAKE(dev) &&
> > + (dev_priv->vbt.ddi_port_info[PORT_E].supports_dp ||
> > +dev_priv->vbt.ddi_port_info[PORT_E].supports_dvi ||
> > +dev_priv->vbt.ddi_port_info[PORT_E].supports_hdmi))
> > + intel_ddi_init(dev, PORT_E);
> > +
> > } else if (HAS_PCH_SPLIT(dev)) {
> > int found;
> > dpd_is_edp = intel_dp_is_edp(dev, PORT_D);
> > --
> > 2.1.4
> >
> > ___
> > 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: Per-DDI I_boost override
On Thu, Aug 06, 2015 at 05:11:03PM +0300, David Weinehall wrote: > On Fri, Jul 10, 2015 at 02:10:55PM +0300, Antti Koskipaa wrote: > > An OEM may request increased I_boost beyond the recommended values > > by specifying an I_boost value to be applied to all swing entries for > > a port. These override values are specified in VBT. > > > > v2: rebase and remove unused iboost_bit variable > > > > Issue: VIZ-5676 > > Signed-off-by: Antti Koskipaa > > Now that patch 1/2 has been updated, I'm ready to give this: > > Reviewed-by: David Weinehall Someone needs to ping me in a few weeks about this one again since atm I can't merge it do -next, need a backmerge first. -Daniel -- 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] [PATCH 1/2 v2] drm/i915: Allow parsing of variable size child device entries from VBT
On Thu, Aug 06, 2015 at 05:08:55PM +0300, David Weinehall wrote:
> On Thu, Aug 06, 2015 at 02:59:10PM +0100, Michel Thierry wrote:
> > On 8/5/2015 9:59 AM, Daniel Vetter wrote:
> > >On Tue, Aug 04, 2015 at 04:55:52PM +0300, David Weinehall wrote:
> > >>VBT version 196 increased the size of common_child_dev_config. The parser
> > >>code assumed that the size of this structure would not change.
> > >>
> > >>The modified code now copies the amount needed based on the VBT version,
> > >>and emits a debug message if the VBT version is unknown (too new);
> > >>since the struct config block won't shrink in newer versions it should
> > >>be harmless to copy the maximum known size in such cases, so that's
> > >>what we do, but emitting the warning is probably sensible anyway.
> > >>
> > >>In the longer run it might make sense to modify the parser code to
> > >>use a version/feature mapping, rather than hardcoding things like this,
> > >>but for now the variants are fairly managable.
> > >>
> > >>v2: Stricter size checks
> > >>
> > >>Signed-off-by: David Weinehall
> > >
> > >Since Chris mentioned that this should fix a regression I applied it to
> > >drm-intel-fixes.
> > >-Daniel
> > >
> > >>---
> > >> drivers/gpu/drm/i915/intel_bios.c | 26 ++
> > >> 1 file changed, 22 insertions(+), 4 deletions(-)
> > >>
> > >>diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > >>b/drivers/gpu/drm/i915/intel_bios.c
> > >>index 2ff9eb00fdec..8a1f3e1fc598 100644
> > >>--- a/drivers/gpu/drm/i915/intel_bios.c
> > >>+++ b/drivers/gpu/drm/i915/intel_bios.c
> > >>@@ -1015,15 +1015,33 @@ parse_device_mapping(struct drm_i915_private
> > >>*dev_priv,
> > >> const union child_device_config *p_child;
> > >> union child_device_config *child_dev_ptr;
> > >> int i, child_device_num, count;
> > >>- u16 block_size;
> > >>+ u8 expected_size;
> > >>+ u16 block_size;
> > >>
> > >> p_defs = find_section(bdb, BDB_GENERAL_DEFINITIONS);
> > >> if (!p_defs) {
> > >> DRM_DEBUG_KMS("No general definition block is found, no
> > >> devices defined.\n");
> > >> return;
> > >> }
> > >>- if (p_defs->child_dev_size < sizeof(*p_child)) {
> > >>- DRM_ERROR("General definiton block child device size is too
> > >>small.\n");
> > >>+ if (bdb->version < 195) {
> > >>+ expected_size = 33;
> > >>+ } else if (bdb->version == 195) {
> > >>+ expected_size = 37;
> > >>+ } else if (bdb->version <= 197) {
> > >>+ expected_size = 38;
> > >>+ } else {
> > >>+ expected_size = 38;
> > >>+ DRM_DEBUG_DRIVER("Expected child_device_config size for BDB
> > >>version %u not known; assuming %u\n", expected_size);
> >
> > Hi, the line above throws a warning because there are two '%u' but only one
> > variable. Looks like bdb->version should be the 1st printed value.
>
> Good catch, your analysis is indeed correct.
>
> Daniel, will you do the fixup or should I submit a fixed version?
Fixed up locally.
-Daniel
--
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] [PATCH 1/6] drm/i915/skl: Enable DDI-E
On Thu, Aug 06, 2015 at 03:51:36PM +0800, Xiong Zhang wrote:
> From: Rodrigo Vivi
>
> There are OEMs using DDI-E out there,
> so let's enable it.
>
> Unfortunately there is no detection bit for DDI-E
> So we need to rely on VBT for that.
>
> I also need to give credits to Xiong since before seing
> his approach to check info->support_* I was creating an ugly
> vbt->ddie_sfuse_strap in order to propagate the ddi presence info
>
> Credits-to: "Zhang, Xiong Y"
> Cc: "Zhang, Xiong Y"
> Signed-off-by: Rodrigo Vivi
btw how is this series related to
http://lists.freedesktop.org/archives/intel-gfx/2015-April/065227.html
Do we need that still? Can you please include that patch in your series if
so?
-Daniel
> ---
> drivers/gpu/drm/i915/intel_bios.c| 14 +++---
> drivers/gpu/drm/i915/intel_bios.h| 2 ++
> drivers/gpu/drm/i915/intel_display.c | 9 +
> 3 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 2ff9eb0..55b5072 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -898,19 +898,19 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv, enum port port,
> /* Each DDI port can have more than one value on the "DVO Port" field,
>* so look for all the possible values for each port and abort if more
>* than one is found. */
> - int dvo_ports[][2] = {
> - {DVO_PORT_HDMIA, DVO_PORT_DPA},
> - {DVO_PORT_HDMIB, DVO_PORT_DPB},
> - {DVO_PORT_HDMIC, DVO_PORT_DPC},
> - {DVO_PORT_HDMID, DVO_PORT_DPD},
> - {DVO_PORT_CRT, -1 /* Port E can only be DVO_PORT_CRT */ },
> + int dvo_ports[][3] = {
> + {DVO_PORT_HDMIA, DVO_PORT_DPA, -1},
> + {DVO_PORT_HDMIB, DVO_PORT_DPB, -1},
> + {DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
> + {DVO_PORT_HDMID, DVO_PORT_DPD, -1},
> + {DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
> };
>
> /* Find the child device to use, abort if more than one found. */
> for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> it = dev_priv->vbt.child_dev + i;
>
> - for (j = 0; j < 2; j++) {
> + for (j = 0; j < 3; j++) {
> if (dvo_ports[port][j] == -1)
> break;
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index f7ad6a5..02255d8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -764,6 +764,8 @@ int intel_parse_bios(struct drm_device *dev);
> #define DVO_PORT_DPC 8
> #define DVO_PORT_DPD 9
> #define DVO_PORT_DPA 10
> +#define DVO_PORT_DPE 11
> +#define DVO_PORT_HDMIE 12
> #define DVO_PORT_MIPIA 21
> #define DVO_PORT_MIPIB 22
> #define DVO_PORT_MIPIC 23
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index af0bcfe..aaa34b8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14123,6 +14123,15 @@ static void intel_setup_outputs(struct drm_device
> *dev)
> intel_ddi_init(dev, PORT_C);
> if (found & SFUSE_STRAP_DDID_DETECTED)
> intel_ddi_init(dev, PORT_D);
> + /*
> + * On SKL we don't have a way to detect DDI-E so we rely on VBT.
> + */
> + if (IS_SKYLAKE(dev) &&
> + (dev_priv->vbt.ddi_port_info[PORT_E].supports_dp ||
> + dev_priv->vbt.ddi_port_info[PORT_E].supports_dvi ||
> + dev_priv->vbt.ddi_port_info[PORT_E].supports_hdmi))
> + intel_ddi_init(dev, PORT_E);
> +
> } else if (HAS_PCH_SPLIT(dev)) {
> int found;
> dpd_is_edp = intel_dp_is_edp(dev, PORT_D);
> --
> 2.1.4
>
> ___
> 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl WaDisableSbeCacheDispatchPortSharing
On 06/08/2015 15:45, Mika Kuoppala wrote:
"Siluvery, Arun" writes:
On 06/08/2015 14:51, Mika Kuoppala wrote:
Add WaDisableSbeCacheDispatchPortSharing:skl
Cc: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1c14233..1a10358 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1059,6 +1059,13 @@ static int skl_init_workarounds(struct intel_engine_cs
*ring)
HDC_FENCE_DEST_SLM_DISABLE |
HDC_BARRIER_PERFORMANCE_DISABLE);
+ /* WaDisableSbeCacheDispatchPortSharing:skl */
+ if (INTEL_REVID(dev) <= SKL_REVID_F0) {
+ WA_SET_BIT_MASKED(
+ GEN7_HALF_SLICE_CHICKEN1,
+ GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
+ }
+
seems to be applicable for BXT also until B0.
Yes, we have that in bxt_init_workarounds. I pondered
it is more clean to have rev check for each in their
respective setup functions.
fine with this.
Reviewed-by: Arun Siluvery
regards
Arun
-Mika
regards
Arun
return skl_tune_iz_hashing(ring);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl WaDisableSbeCacheDispatchPortSharing
"Siluvery, Arun" writes:
> On 06/08/2015 14:51, Mika Kuoppala wrote:
>> Add WaDisableSbeCacheDispatchPortSharing:skl
>>
>> Cc: Arun Siluvery
>> Signed-off-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index 1c14233..1a10358 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> @@ -1059,6 +1059,13 @@ static int skl_init_workarounds(struct
>> intel_engine_cs *ring)
>>HDC_FENCE_DEST_SLM_DISABLE |
>>HDC_BARRIER_PERFORMANCE_DISABLE);
>>
>> +/* WaDisableSbeCacheDispatchPortSharing:skl */
>> +if (INTEL_REVID(dev) <= SKL_REVID_F0) {
>> +WA_SET_BIT_MASKED(
>> +GEN7_HALF_SLICE_CHICKEN1,
>> +GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
>> +}
>> +
> seems to be applicable for BXT also until B0.
>
Yes, we have that in bxt_init_workarounds. I pondered
it is more clean to have rev check for each in their
respective setup functions.
-Mika
> regards
> Arun
>
>> return skl_tune_iz_hashing(ring);
>> }
>>
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [SKL-DMC-BUGFIX 2/5] drm/i915/skl: Making DC6 entry is the last call in suspend flow.
On 8/6/2015 6:48 PM, Daniel Vetter wrote:
On Thu, Aug 06, 2015 at 02:47:22PM +0530, Animesh Manna wrote:
On 8/5/2015 2:35 PM, Daniel Vetter wrote:
On Mon, Aug 03, 2015 at 09:55:33PM +0530, Animesh Manna wrote:
Mmio register access after dc6/dc5 entry is not allowed when
DC6 power states are enabled according to bspec (bspec-id 0527),
so enabling dc6 as the last call in suspend flow.
v1: Initial version.
v2: commit message updated based on comment from Vathsala.
Cc: Daniel Vetter
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/i915/i915_drv.c | 12 ++--
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 33 -
3 files changed, 16 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0d6775a..e1d0102 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1017,14 +1017,11 @@ static int skl_suspend_complete(struct drm_i915_private
*dev_priv)
{
/* Enabling DC6 is not a hard requirement to enter runtime D3 */
- /*
-* This is to ensure that CSR isn't identified as loaded before
-* CSR-loading program is called during runtime-resume.
-*/
- intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
Seems like an unrelated hunk. Separate patch (in the dmc loader rework
series) or an explanation why we need this.
In the same skl_suspend_complete() later we are checking if firmware is loaded,
based on that we trigger dc6, so the above hunk has to be removed in this patch.
I know that later on we'll replace this with something else, but you can't
remove old code before the new code is there. And you can't do changes
like this here in unrelated patches.
code snippet added in this patch:
+ if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
+ skl_enable_dc6(dev_priv);
We can add uninitilized call here after this which will be related changes.
After dmc redesign will remove it completely the function call for csr
uninitialization.
On the other hand firmware team confirmed that one time firmware loading
during driver loading is sufficient, no need to load firmware in
csr-address-space every suspend (dc6 entry) - resume (dc6 exit) flow, dmc will
take care of it which eliminate any chance of regression.
And what about hibernate?
Yes, during hibernate I assumed os will restore the ram content from disk.
But specially for csr program we need to load it again. Thanks for the pointer.
-Animesh
-Daniel
- Animesh
-
skl_uninit_cdclk(dev_priv);
+ if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
+ skl_enable_dc6(dev_priv);
+
return 0;
}
@@ -1071,6 +1068,9 @@ static int skl_resume_prepare(struct drm_i915_private
*dev_priv)
{
struct drm_device *dev = dev_priv->dev;
+ if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
+ skl_disable_dc6(dev_priv);
+
skl_init_cdclk(dev_priv);
intel_csr_load_program(dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 47cef0e..06f346f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1117,6 +1117,8 @@ void bxt_enable_dc9(struct drm_i915_private *dev_priv);
void bxt_disable_dc9(struct drm_i915_private *dev_priv);
void skl_init_cdclk(struct drm_i915_private *dev_priv);
void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
+void skl_enable_dc6(struct drm_i915_private *dev_priv);
+void skl_disable_dc6(struct drm_i915_private *dev_priv);
void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6393b76..c660245 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -532,7 +532,7 @@ static void assert_can_disable_dc6(struct drm_i915_private
*dev_priv)
"DC6 already programmed to be disabled.\n");
}
-static void skl_enable_dc6(struct drm_i915_private *dev_priv)
+void skl_enable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -549,7 +549,7 @@ static void skl_enable_dc6(struct drm_i915_private
*dev_priv)
POSTING_READ(DC_STATE_EN);
}
-static void skl_disable_dc6(struct drm_i915_private *dev_priv)
+void skl_disable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
Everything above seems to roughly be matching your patch description, but
not perfectly: You talk about suspend flow but also touch resume flow.
But the hunks below are completely unexplained magic afaict. Either this
needs a separate patch or i
Re: [Intel-gfx] [PATCH] drm/i915/skl WaDisableSbeCacheDispatchPortSharing
On 06/08/2015 14:51, Mika Kuoppala wrote:
Add WaDisableSbeCacheDispatchPortSharing:skl
Cc: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1c14233..1a10358 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1059,6 +1059,13 @@ static int skl_init_workarounds(struct intel_engine_cs
*ring)
HDC_FENCE_DEST_SLM_DISABLE |
HDC_BARRIER_PERFORMANCE_DISABLE);
+ /* WaDisableSbeCacheDispatchPortSharing:skl */
+ if (INTEL_REVID(dev) <= SKL_REVID_F0) {
+ WA_SET_BIT_MASKED(
+ GEN7_HALF_SLICE_CHICKEN1,
+ GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
+ }
+
seems to be applicable for BXT also until B0.
regards
Arun
return skl_tune_iz_hashing(ring);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use masked write for Context Status Buffer Pointer
On 8/6/2015 3:00 PM, Mika Kuoppala wrote: This register needs to be updated with masked writes. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 99bba8e..29347e7 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -521,7 +521,7 @@ void intel_lrc_irq_handler(struct intel_engine_cs *ring) ring->next_context_status_buffer = write_pointer % 6; I915_WRITE(RING_CONTEXT_STATUS_PTR(ring), - ((u32)ring->next_context_status_buffer & 0x07) << 8); + _MASKED_FIELD(0x07 << 8, ((u32)ring->next_context_status_buffer & 0x07) << 8)); } static int execlists_context_queue(struct drm_i915_gem_request *request) -- 2.1.4 bspec agrees... but I remember seeing these bits being written without the mask in gen8. Reviewed-by: Michel Thierry ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2 v2] drm/i915: Allow parsing of variable size child device entries from VBT
On Thu, Aug 06, 2015 at 02:18:35PM +0200, Daniel Vetter wrote: > On Wed, Aug 05, 2015 at 06:32:01PM +0300, David Weinehall wrote: > > On Wed, Aug 05, 2015 at 10:59:00AM +0200, Daniel Vetter wrote: > > > On Tue, Aug 04, 2015 at 04:55:52PM +0300, David Weinehall wrote: > > > > VBT version 196 increased the size of common_child_dev_config. The > > > > parser > > > > code assumed that the size of this structure would not change. > > > > > > > > The modified code now copies the amount needed based on the VBT version, > > > > and emits a debug message if the VBT version is unknown (too new); > > > > since the struct config block won't shrink in newer versions it should > > > > be harmless to copy the maximum known size in such cases, so that's > > > > what we do, but emitting the warning is probably sensible anyway. > > > > > > > > In the longer run it might make sense to modify the parser code to > > > > use a version/feature mapping, rather than hardcoding things like this, > > > > but for now the variants are fairly managable. > > > > > > > > v2: Stricter size checks > > > > > > > > Signed-off-by: David Weinehall > > > > > > Since Chris mentioned that this should fix a regression I applied it to > > > drm-intel-fixes. > > > > Great! Will you merge the other patch in the series to the nightly > > build? > > I only merged this fast-tracked because it fixes a regression. For the > other patch normal review rules still apply (i.e. I won't do it). I wasn't expecting fast tracking. I'd missed the fact that patch 2/2 wasn't reviewed by anyone yet; I've done so now. Kind regards, David ___ 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: Per-DDI I_boost override
On Fri, Jul 10, 2015 at 02:10:55PM +0300, Antti Koskipaa wrote: > An OEM may request increased I_boost beyond the recommended values > by specifying an I_boost value to be applied to all swing entries for > a port. These override values are specified in VBT. > > v2: rebase and remove unused iboost_bit variable > > Issue: VIZ-5676 > Signed-off-by: Antti Koskipaa Now that patch 1/2 has been updated, I'm ready to give this: Reviewed-by: David Weinehall Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check idle to active before processing CSQ
If idle to active bit is set, the rest of the fields
in CSQ are not valid.
Bail out early if this is the case in order to prevent
rest of the loop inspecting stale values.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 99bba8e..96218bf 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -497,6 +497,9 @@ void intel_lrc_irq_handler(struct intel_engine_cs *ring)
status_id = I915_READ(RING_CONTEXT_STATUS_BUF(ring) +
(read_pointer % 6) * 8 + 4);
+ if (status & GEN8_CTX_STATUS_IDLE_ACTIVE)
+ continue;
+
if (status & GEN8_CTX_STATUS_PREEMPTED) {
if (status & GEN8_CTX_STATUS_LITE_RESTORE) {
if (execlists_check_remove_request(ring,
status_id))
--
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/2 v2] drm/i915: Allow parsing of variable size child device entries from VBT
On Thu, Aug 06, 2015 at 02:59:10PM +0100, Michel Thierry wrote:
> On 8/5/2015 9:59 AM, Daniel Vetter wrote:
> >On Tue, Aug 04, 2015 at 04:55:52PM +0300, David Weinehall wrote:
> >>VBT version 196 increased the size of common_child_dev_config. The parser
> >>code assumed that the size of this structure would not change.
> >>
> >>The modified code now copies the amount needed based on the VBT version,
> >>and emits a debug message if the VBT version is unknown (too new);
> >>since the struct config block won't shrink in newer versions it should
> >>be harmless to copy the maximum known size in such cases, so that's
> >>what we do, but emitting the warning is probably sensible anyway.
> >>
> >>In the longer run it might make sense to modify the parser code to
> >>use a version/feature mapping, rather than hardcoding things like this,
> >>but for now the variants are fairly managable.
> >>
> >>v2: Stricter size checks
> >>
> >>Signed-off-by: David Weinehall
> >
> >Since Chris mentioned that this should fix a regression I applied it to
> >drm-intel-fixes.
> >-Daniel
> >
> >>---
> >> drivers/gpu/drm/i915/intel_bios.c | 26 ++
> >> 1 file changed, 22 insertions(+), 4 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/intel_bios.c
> >>b/drivers/gpu/drm/i915/intel_bios.c
> >>index 2ff9eb00fdec..8a1f3e1fc598 100644
> >>--- a/drivers/gpu/drm/i915/intel_bios.c
> >>+++ b/drivers/gpu/drm/i915/intel_bios.c
> >>@@ -1015,15 +1015,33 @@ parse_device_mapping(struct drm_i915_private
> >>*dev_priv,
> >> const union child_device_config *p_child;
> >> union child_device_config *child_dev_ptr;
> >> int i, child_device_num, count;
> >>- u16 block_size;
> >>+ u8 expected_size;
> >>+ u16 block_size;
> >>
> >> p_defs = find_section(bdb, BDB_GENERAL_DEFINITIONS);
> >> if (!p_defs) {
> >> DRM_DEBUG_KMS("No general definition block is found, no
> >> devices defined.\n");
> >> return;
> >> }
> >>- if (p_defs->child_dev_size < sizeof(*p_child)) {
> >>- DRM_ERROR("General definiton block child device size is too
> >>small.\n");
> >>+ if (bdb->version < 195) {
> >>+ expected_size = 33;
> >>+ } else if (bdb->version == 195) {
> >>+ expected_size = 37;
> >>+ } else if (bdb->version <= 197) {
> >>+ expected_size = 38;
> >>+ } else {
> >>+ expected_size = 38;
> >>+ DRM_DEBUG_DRIVER("Expected child_device_config size for BDB
> >>version %u not known; assuming %u\n", expected_size);
>
> Hi, the line above throws a warning because there are two '%u' but only one
> variable. Looks like bdb->version should be the 1st printed value.
Good catch, your analysis is indeed correct.
Daniel, will you do the fixup or should I submit a fixed version?
Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 12/13] drm/i915: Only update mode related state if a modeset happened.
Op 06-08-15 om 15:12 schreef Daniel Vetter:
> On Wed, Aug 05, 2015 at 12:37:10PM +0200, Maarten Lankhorst wrote:
>> The rest will be a noop anyway, since without modeset there will be
>> no updated dplls and no modeset state to update.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 30 +++---
>> 1 file changed, 7 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 1fd8b7dec7da..aa444cbc2262 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -12181,33 +12181,15 @@ fail:
>> return ret;
>> }
>>
>> -static bool intel_crtc_in_use(struct drm_crtc *crtc)
>> -{
>> -struct drm_encoder *encoder;
>> -struct drm_device *dev = crtc->dev;
>> -
>> -list_for_each_entry(encoder, &dev->mode_config.encoder_list, head)
>> -if (encoder->crtc == crtc)
>> -return true;
>> -
>> -return false;
>> -}
>> -
>> static void
>> -intel_modeset_update_state(struct drm_atomic_state *state)
>> +intel_modeset_update_crtc_state(struct drm_atomic_state *state)
>> {
>> struct drm_crtc *crtc;
>> struct drm_crtc_state *crtc_state;
>> int i;
>>
>> -intel_shared_dpll_commit(state);
> This should be right next to swap_state, and we should probably rename it
> to be consistent.
After some digging I think this could work if we no longer check
pll->config.crtc_mask
in intel_disable_shared_dpll.
If we check crtc_mask in intel_enable_shared_dpll we can remove the one from
disable
and prepare, and let the hw checker deal with it.
>> -
>> -drm_atomic_helper_update_legacy_modeset_state(state->dev, state);
> This helper should always work, why try to optimize things?
I didn't see the point of going through the connector state,
but shrug I guess the extra loops probably don't matter.
>> -
>> /* Double check state. */
>> for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> -WARN_ON(crtc->state->enable != intel_crtc_in_use(crtc));
> I guess this WARN_ON should be moved into the state checker? Or entirely
> removed if redundant.
It's removed because the atomic core does this for us.
>> -
>> to_intel_crtc(crtc)->config = to_intel_crtc_state(crtc->state);
>>
>> /* Update hwmode for vblank functions */
>> @@ -13110,12 +13092,14 @@ static int intel_atomic_commit(struct drm_device
>> *dev,
>>
>> /* Only after disabling all output pipelines that will be changed can we
>> * update the the output configuration. */
>> -intel_modeset_update_state(state);
>> +intel_modeset_update_crtc_state(state);
>>
>> -/* The state has been swaped above, so state actually contains the
>> - * old state now. */
>> -if (any_ms)
>> +if (any_ms) {
>> +intel_shared_dpll_commit(state);
>> +
>> +drm_atomic_helper_update_legacy_modeset_state(state->dev,
>> state);
>> modeset_update_crtc_power_domains(state);
>> +}
>>
>> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
>> for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> --
>> 2.1.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
[Intel-gfx] [PATCH] drm/i915: Use masked write for Context Status Buffer Pointer
This register needs to be updated with masked writes. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 99bba8e..29347e7 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -521,7 +521,7 @@ void intel_lrc_irq_handler(struct intel_engine_cs *ring) ring->next_context_status_buffer = write_pointer % 6; I915_WRITE(RING_CONTEXT_STATUS_PTR(ring), - ((u32)ring->next_context_status_buffer & 0x07) << 8); + _MASKED_FIELD(0x07 << 8, ((u32)ring->next_context_status_buffer & 0x07) << 8)); } static int execlists_context_queue(struct drm_i915_gem_request *request) -- 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/2 v2] drm/i915: Allow parsing of variable size child device entries from VBT
On 8/5/2015 9:59 AM, Daniel Vetter wrote:
On Tue, Aug 04, 2015 at 04:55:52PM +0300, David Weinehall wrote:
VBT version 196 increased the size of common_child_dev_config. The parser
code assumed that the size of this structure would not change.
The modified code now copies the amount needed based on the VBT version,
and emits a debug message if the VBT version is unknown (too new);
since the struct config block won't shrink in newer versions it should
be harmless to copy the maximum known size in such cases, so that's
what we do, but emitting the warning is probably sensible anyway.
In the longer run it might make sense to modify the parser code to
use a version/feature mapping, rather than hardcoding things like this,
but for now the variants are fairly managable.
v2: Stricter size checks
Signed-off-by: David Weinehall
Since Chris mentioned that this should fix a regression I applied it to
drm-intel-fixes.
-Daniel
---
drivers/gpu/drm/i915/intel_bios.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 2ff9eb00fdec..8a1f3e1fc598 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1015,15 +1015,33 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
const union child_device_config *p_child;
union child_device_config *child_dev_ptr;
int i, child_device_num, count;
- u16 block_size;
+ u8 expected_size;
+ u16 block_size;
p_defs = find_section(bdb, BDB_GENERAL_DEFINITIONS);
if (!p_defs) {
DRM_DEBUG_KMS("No general definition block is found, no devices
defined.\n");
return;
}
- if (p_defs->child_dev_size < sizeof(*p_child)) {
- DRM_ERROR("General definiton block child device size is too
small.\n");
+ if (bdb->version < 195) {
+ expected_size = 33;
+ } else if (bdb->version == 195) {
+ expected_size = 37;
+ } else if (bdb->version <= 197) {
+ expected_size = 38;
+ } else {
+ expected_size = 38;
+ DRM_DEBUG_DRIVER("Expected child_device_config size for BDB version %u
not known; assuming %u\n", expected_size);
Hi, the line above throws a warning because there are two '%u' but only
one variable. Looks like bdb->version should be the 1st printed value.
+ }
+
+ if (expected_size > sizeof(*p_child)) {
+ DRM_ERROR("child_device_config cannot fit in p_child\n");
+ return;
+ }
+
+ if (p_defs->child_dev_size != expected_size) {
+ DRM_ERROR("Size mismatch; child_device_config size=%u (expected %u);
bdb->version: %u\n",
+ p_defs->child_dev_size, expected_size, bdb->version);
return;
}
/* get the block size of general definitions */
@@ -1070,7 +1088,7 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
child_dev_ptr = dev_priv->vbt.child_dev + count;
count++;
- memcpy(child_dev_ptr, p_child, sizeof(*p_child));
+ memcpy(child_dev_ptr, p_child, p_defs->child_dev_size);
}
return;
}
___
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
___
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 v3.1 3/3] drm/i915: Don't try to remove MST cleanly when force removed.
Hey, Op 06-08-15 om 15:01 schreef Daniel Vetter: > On Thu, Aug 06, 2015 at 01:47:37PM +0200, Maarten Lankhorst wrote: >> Physically disconnecting a DP connector with an active MST stream >> can lead to a kernel panic in intel_mst_disable_dp when calling >> drm_dp_update_payload_part1. Examining the code it seems that the >> port is freed while work to remove the connector is scheduled. >> >> This probably means it's fine to skip call all the mst helper calls >> and only attempt to disable the real encoder. > I think this is a refcounting bug in the dp mst helpers, the port > shouldn't just go poof when we still hold a reference to it. Can you > please try to figure out what's really broken here, and if that's too > tricky add a big FIXME comment? Look at drm_dp_destroy_port, it calls schedule_work(&mgr->destroy_connector_work), and also calls kfree(port). Doesn't look like a refcounting bug to me, more like something intentional. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/skl WaDisableSbeCacheDispatchPortSharing
Add WaDisableSbeCacheDispatchPortSharing:skl
Cc: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1c14233..1a10358 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1059,6 +1059,13 @@ static int skl_init_workarounds(struct intel_engine_cs
*ring)
HDC_FENCE_DEST_SLM_DISABLE |
HDC_BARRIER_PERFORMANCE_DISABLE);
+ /* WaDisableSbeCacheDispatchPortSharing:skl */
+ if (INTEL_REVID(dev) <= SKL_REVID_F0) {
+ WA_SET_BIT_MASKED(
+ GEN7_HALF_SLICE_CHICKEN1,
+ GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
+ }
+
return skl_tune_iz_hashing(ring);
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Spam less on dp aux send/receive problems
If we encounter frequent problems with dp aux channel
communications, we end up spamming the dmesg with the
exact similar trace and status.
Inject a new backtrace only if we have new information
to share as otherwise we flush out all other important
stuff.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_dp.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index df7e2cf..6b2f7af 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -849,8 +849,15 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
}
if (try == 3) {
- WARN(1, "dp_aux_ch not started status 0x%08x\n",
-I915_READ(ch_ctl));
+ static u32 last_status = -1;
+ const u32 status = I915_READ(ch_ctl);
+
+ if (status != last_status) {
+ WARN(1, "dp_aux_ch not started status 0x%08x\n",
+status);
+ last_status = status;
+ }
+
ret = -EBUSY;
goto out;
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3.1 1/3] drm/i915: Fix broken mst get_hw_state.
Op 06-08-15 om 14:59 schreef Daniel Vetter:
> On Thu, Aug 06, 2015 at 01:47:35PM +0200, Maarten Lankhorst wrote:
>> This function always returned false because intel_connector->encoder
>> is always NULL. Instead use the attached encoder from atomic.
> Note that you've broken this since you removed the updating of
> intel_connector->encoder somewhere in the 4.3 atomic series. So this is a
> regression fix. Can you please digg out the right commit?
Looks like 'Use full atomic modeset' broke it. intel_connector->encoder was
updated in its set_config function..
Would below amend for this commit be good?
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index ee2a77144373..671715ba8538 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -173,6 +173,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;
And corresponding amendment to the convert connector to atomic..
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a6617283b1bd..90caa62cf2c3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6313,7 +6313,7 @@ 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,
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_dp_mst.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
>> b/drivers/gpu/drm/i915/intel_dp_mst.c
>> index e3a5864160fa..ff01569158ea 100644
>> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
>> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
>> @@ -395,9 +395,12 @@ 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) {
>> +struct intel_encoder *encoder;
>> +
>> +encoder = to_intel_encoder(connector->base.state->best_encoder);
> Strictly speaking this won't work for hw state readout since what we
> really need to do is ask the mst connector which mst stream it accepts and
> then compare that with all the mst encoders ...
It's good enough to make sure the encoder callbacks did run.
> But that's been broken since forever. Only side-effect here is that
> fastboot won't work with mst and that's imo totally ok. Please also add
> this to your commit message.
HW readout runs before mst probing, so you wouldn't get the mst connectors
anyway with fastboot. Not sure it needs a fixme. :-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/skl: Enable DDI-E
On Thu, Aug 06, 2015 at 03:51:36PM +0800, Xiong Zhang wrote:
> From: Rodrigo Vivi
>
> There are OEMs using DDI-E out there,
> so let's enable it.
>
> Unfortunately there is no detection bit for DDI-E
> So we need to rely on VBT for that.
>
> I also need to give credits to Xiong since before seing
> his approach to check info->support_* I was creating an ugly
> vbt->ddie_sfuse_strap in order to propagate the ddi presence info
>
> Credits-to: "Zhang, Xiong Y"
> Cc: "Zhang, Xiong Y"
> Signed-off-by: Rodrigo Vivi
Enable patches like these should be last in the series, since before all
the other stuff things will simply be broken.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_bios.c| 14 +++---
> drivers/gpu/drm/i915/intel_bios.h| 2 ++
> drivers/gpu/drm/i915/intel_display.c | 9 +
> 3 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 2ff9eb0..55b5072 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -898,19 +898,19 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv, enum port port,
> /* Each DDI port can have more than one value on the "DVO Port" field,
>* so look for all the possible values for each port and abort if more
>* than one is found. */
> - int dvo_ports[][2] = {
> - {DVO_PORT_HDMIA, DVO_PORT_DPA},
> - {DVO_PORT_HDMIB, DVO_PORT_DPB},
> - {DVO_PORT_HDMIC, DVO_PORT_DPC},
> - {DVO_PORT_HDMID, DVO_PORT_DPD},
> - {DVO_PORT_CRT, -1 /* Port E can only be DVO_PORT_CRT */ },
> + int dvo_ports[][3] = {
> + {DVO_PORT_HDMIA, DVO_PORT_DPA, -1},
> + {DVO_PORT_HDMIB, DVO_PORT_DPB, -1},
> + {DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
> + {DVO_PORT_HDMID, DVO_PORT_DPD, -1},
> + {DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
> };
>
> /* Find the child device to use, abort if more than one found. */
> for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> it = dev_priv->vbt.child_dev + i;
>
> - for (j = 0; j < 2; j++) {
> + for (j = 0; j < 3; j++) {
> if (dvo_ports[port][j] == -1)
> break;
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index f7ad6a5..02255d8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -764,6 +764,8 @@ int intel_parse_bios(struct drm_device *dev);
> #define DVO_PORT_DPC 8
> #define DVO_PORT_DPD 9
> #define DVO_PORT_DPA 10
> +#define DVO_PORT_DPE 11
> +#define DVO_PORT_HDMIE 12
> #define DVO_PORT_MIPIA 21
> #define DVO_PORT_MIPIB 22
> #define DVO_PORT_MIPIC 23
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index af0bcfe..aaa34b8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14123,6 +14123,15 @@ static void intel_setup_outputs(struct drm_device
> *dev)
> intel_ddi_init(dev, PORT_C);
> if (found & SFUSE_STRAP_DDID_DETECTED)
> intel_ddi_init(dev, PORT_D);
> + /*
> + * On SKL we don't have a way to detect DDI-E so we rely on VBT.
> + */
> + if (IS_SKYLAKE(dev) &&
> + (dev_priv->vbt.ddi_port_info[PORT_E].supports_dp ||
> + dev_priv->vbt.ddi_port_info[PORT_E].supports_dvi ||
> + dev_priv->vbt.ddi_port_info[PORT_E].supports_hdmi))
> + intel_ddi_init(dev, PORT_E);
> +
> } else if (HAS_PCH_SPLIT(dev)) {
> int found;
> dpd_is_edp = intel_dp_is_edp(dev, PORT_D);
> --
> 2.1.4
>
> ___
> 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [SKL-DMC-BUGFIX 2/5] drm/i915/skl: Making DC6 entry is the last call in suspend flow.
On Thu, Aug 06, 2015 at 02:47:22PM +0530, Animesh Manna wrote:
>
>
> On 8/5/2015 2:35 PM, Daniel Vetter wrote:
> >On Mon, Aug 03, 2015 at 09:55:33PM +0530, Animesh Manna wrote:
> >>Mmio register access after dc6/dc5 entry is not allowed when
> >>DC6 power states are enabled according to bspec (bspec-id 0527),
> >>so enabling dc6 as the last call in suspend flow.
> >>
> >>v1: Initial version.
> >>
> >>v2: commit message updated based on comment from Vathsala.
> >>
> >>Cc: Daniel Vetter
> >>Cc: Damien Lespiau
> >>Cc: Imre Deak
> >>Cc: Sunil Kamath
> >>Signed-off-by: Animesh Manna
> >>Signed-off-by: Vathsala Nagaraju
> >>Signed-off-by: Rajneesh Bhardwaj
> >>---
> >> drivers/gpu/drm/i915/i915_drv.c | 12 ++--
> >> drivers/gpu/drm/i915/intel_drv.h| 2 ++
> >> drivers/gpu/drm/i915/intel_runtime_pm.c | 33
> >> -
> >> 3 files changed, 16 insertions(+), 31 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.c
> >>b/drivers/gpu/drm/i915/i915_drv.c
> >>index 0d6775a..e1d0102 100644
> >>--- a/drivers/gpu/drm/i915/i915_drv.c
> >>+++ b/drivers/gpu/drm/i915/i915_drv.c
> >>@@ -1017,14 +1017,11 @@ static int skl_suspend_complete(struct
> >>drm_i915_private *dev_priv)
> >> {
> >>/* Enabling DC6 is not a hard requirement to enter runtime D3 */
> >>- /*
> >>-* This is to ensure that CSR isn't identified as loaded before
> >>-* CSR-loading program is called during runtime-resume.
> >>-*/
> >>- intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
> >Seems like an unrelated hunk. Separate patch (in the dmc loader rework
> >series) or an explanation why we need this.
>
> In the same skl_suspend_complete() later we are checking if firmware is
> loaded,
> based on that we trigger dc6, so the above hunk has to be removed in this
> patch.
> I will add explanation in my next patchset.
I know that later on we'll replace this with something else, but you can't
remove old code before the new code is there. And you can't do changes
like this here in unrelated patches.
> On the other hand firmware team confirmed that one time firmware loading
> during driver loading is sufficient, no need to load firmware in
> csr-address-space every suspend (dc6 entry) - resume (dc6 exit) flow, dmc will
> take care of it which eliminate any chance of regression.
And what about hibernate?
-Daniel
>
> - Animesh
>
> >
> >>-
> >>skl_uninit_cdclk(dev_priv);
> >>+ if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
> >>+ skl_enable_dc6(dev_priv);
> >>+
> >>return 0;
> >> }
> >>@@ -1071,6 +1068,9 @@ static int skl_resume_prepare(struct drm_i915_private
> >>*dev_priv)
> >> {
> >>struct drm_device *dev = dev_priv->dev;
> >>+ if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
> >>+ skl_disable_dc6(dev_priv);
> >>+
> >>skl_init_cdclk(dev_priv);
> >>intel_csr_load_program(dev);
> >>diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >>b/drivers/gpu/drm/i915/intel_drv.h
> >>index 47cef0e..06f346f 100644
> >>--- a/drivers/gpu/drm/i915/intel_drv.h
> >>+++ b/drivers/gpu/drm/i915/intel_drv.h
> >>@@ -1117,6 +1117,8 @@ void bxt_enable_dc9(struct drm_i915_private
> >>*dev_priv);
> >> void bxt_disable_dc9(struct drm_i915_private *dev_priv);
> >> void skl_init_cdclk(struct drm_i915_private *dev_priv);
> >> void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
> >>+void skl_enable_dc6(struct drm_i915_private *dev_priv);
> >>+void skl_disable_dc6(struct drm_i915_private *dev_priv);
> >> void intel_dp_get_m_n(struct intel_crtc *crtc,
> >> struct intel_crtc_state *pipe_config);
> >> void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
> >>diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >>b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >>index 6393b76..c660245 100644
> >>--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >>+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >>@@ -532,7 +532,7 @@ static void assert_can_disable_dc6(struct
> >>drm_i915_private *dev_priv)
> >>"DC6 already programmed to be disabled.\n");
> >> }
> >>-static void skl_enable_dc6(struct drm_i915_private *dev_priv)
> >>+void skl_enable_dc6(struct drm_i915_private *dev_priv)
> >> {
> >>uint32_t val;
> >>@@ -549,7 +549,7 @@ static void skl_enable_dc6(struct drm_i915_private
> >>*dev_priv)
> >>POSTING_READ(DC_STATE_EN);
> >> }
> >>-static void skl_disable_dc6(struct drm_i915_private *dev_priv)
> >>+void skl_disable_dc6(struct drm_i915_private *dev_priv)
> >> {
> >>uint32_t val;
> >Everything above seems to roughly be matching your patch description, but
> >not perfectly: You talk about suspend flow but also touch resume flow.
> >
> >But the hunks below are completely unexplained magic afaict. Either this
> >needs a separate patch or it needs seriously more explanation of what's
> >going on.
> >
> >>@@ -610,10 +610,10 @@ static void skl_set_power_well(struct
> >>drm_i915_private
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use CPU mapping for userspace dma-buf mmap()
On Wed, Aug 05, 2015 at 05:10:17PM -0300, Tiago Vignatti wrote:
> On 08/05/2015 04:08 AM, Daniel Vetter wrote:
> >On Tue, Aug 04, 2015 at 06:30:25PM -0300, Tiago Vignatti wrote:
> >Nah they don't have to be equal since the problem isn't that nothing goes
> >out to memory where the display can see it, but usually only parts of it.
> >I.e. you need to change your test to
> >- draw black screen (it starts that way so nothing to do really), grab crtc
> >- draw white screen and make sure you flush correctly, don't bother with
> > crc (we can't test for inequality
> > because collisions are too easy)
> >- draw black screen again without flushing, grab crc
> >
> >Then assert that your two crc will be inequal (which they shouldn't be
> >because some cachelines will still be stuck). Maybe also add a delay
> >somewhere so you can see the cacheline dirt pattern, it's very
> >characteristic.
>
> Cool, I've got it now. The test below makes the cachelines dirt, requiring
> them to get flushed correctly -- I'll work on it now. Should we add that
> kind of test somewhere in igt BTW?
Yeah if you expect me to merge dma-buf mmap with the begin/end stuff I'll
ask for an igt for it ;-)
> PS: I had an issue with the original kms_pwrite_crc which returns frequent
> fails. Paulo helped though and showed me that pwrite is currently broken:
> https://bugs.freedesktop.org/show_bug.cgi?id=86422
If you do dma-buf mmap with begin/end it should work, since in there we'll
just to manual range-based clflushing.
-Daniel
>
> Tiago
>
> diff --git a/tests/kms_pwrite_crc.c b/tests/kms_pwrite_crc.c
> index 05b9e38..419b46d 100644
> --- a/tests/kms_pwrite_crc.c
> +++ b/tests/kms_pwrite_crc.c
> @@ -50,6 +50,20 @@ typedef struct {
> uint32_t devid;
> } data_t;
>
> +static char *dmabuf_mmap_framebuffer(int drm_fd, struct igt_fb *fb)
> +{
> + int dma_buf_fd;
> + char *ptr = NULL;
> +
> + dma_buf_fd = prime_handle_to_fd(drm_fd, fb->gem_handle);
> + igt_assert(errno == 0);
> +
> + ptr = mmap(NULL, fb->size, PROT_READ | PROT_WRITE, MAP_SHARED,
> dma_buf_fd,
> 0);
> + igt_assert(ptr != MAP_FAILED);
> +
> + return ptr;
> +}
> +
> static void test(data_t *data)
> {
> igt_display_t *display = &data->display;
> @@ -57,6 +71,7 @@ static void test(data_t *data)
> struct igt_fb *fb = &data->fb[1];
> drmModeModeInfo *mode;
> cairo_t *cr;
> + char *ptr;
> uint32_t caching;
> void *buf;
> igt_crc_t crc;
> @@ -67,6 +82,8 @@ static void test(data_t *data)
> igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
> DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE, fb);
>
> + ptr = dmabuf_mmap_framebuffer(data->drm_fd, fb);
> +
> cr = igt_get_cairo_ctx(data->drm_fd, fb);
> igt_paint_test_pattern(cr, fb->width, fb->height);
> cairo_destroy(cr);
> @@ -83,11 +100,11 @@ static void test(data_t *data)
> caching = gem_get_caching(data->drm_fd, fb->gem_handle);
> igt_assert(caching == I915_CACHING_NONE || caching ==
> I915_CACHING_DISPLAY);
>
> - /* use pwrite to make the other fb all white too */
> + /* use dmabuf pointer to make the other fb all white too */
> buf = malloc(fb->size);
> igt_assert(buf != NULL);
> memset(buf, 0xff, fb->size);
> - gem_write(data->drm_fd, fb->gem_handle, 0, buf, fb->size);
> + memcpy(ptr, buf, fb->size);
> free(buf);
>
> /* and flip to it */
>
--
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] [PATCH v3 00/13] DPMS updates and atomic state checking.
On Wed, Aug 05, 2015 at 12:36:58PM +0200, Maarten Lankhorst wrote: > Mixed bag of fixes for -next now that the first merge happened. > Patch series deals with getting rid of intel DPMS handling and > making the state checker atomic. > > The state checker is now atomic and only checks the affected > crtc's, encoders and connectors. > > This is just a resend with all the fixes done after v2. Ok finally done the backmerge and merged everything I didn't comment on. Thanks, Daniel > > Maarten Lankhorst (13): > drm/i915: Make the force_thru workaround atomic, v2. > drm/i915: Validate the state after an atomic modeset only, and pass the > state. > drm/i915: Update atomic state when removing mst connector. > drm/i915: Convert connector checking to atomic, v2. > drm/i915: Remove some unneeded checks from check_crtc_state. > drm/i915: Remove connectors_active from state checking. > drm/i915: Make crtc checking use the atomic state, v2. > drm/i915: Get rid of dpms handling. > drm/i915: Remove connectors_active from sanitization, v2. > drm/i915: Remove connectors_active from intel_dp.c, v2. > drm/i915: Remove connectors_active. > drm/i915: Only update mode related state if a modeset happened. > drm/i915: Handle return value in intel_pin_and_fence_fb_obj, v2. > > drivers/gpu/drm/i915/i915_debugfs.c | 82 ++- > drivers/gpu/drm/i915/intel_crt.c | 51 + > drivers/gpu/drm/i915/intel_display.c | 426 > +++ > drivers/gpu/drm/i915/intel_dp.c | 9 +- > drivers/gpu/drm/i915/intel_dp_mst.c | 47 +++- > drivers/gpu/drm/i915/intel_drv.h | 5 - > drivers/gpu/drm/i915/intel_dsi.c | 2 +- > drivers/gpu/drm/i915/intel_dvo.c | 48 +--- > drivers/gpu/drm/i915/intel_hdmi.c| 2 +- > drivers/gpu/drm/i915/intel_lvds.c| 2 +- > drivers/gpu/drm/i915/intel_sdvo.c| 49 +--- > drivers/gpu/drm/i915/intel_tv.c | 2 +- > 12 files changed, 213 insertions(+), 512 deletions(-) > > -- > 2.1.0 > > ___ > 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 12/13] drm/i915: Only update mode related state if a modeset happened.
On Wed, Aug 05, 2015 at 12:37:10PM +0200, Maarten Lankhorst wrote:
> The rest will be a noop anyway, since without modeset there will be
> no updated dplls and no modeset state to update.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 30 +++---
> 1 file changed, 7 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 1fd8b7dec7da..aa444cbc2262 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12181,33 +12181,15 @@ fail:
> return ret;
> }
>
> -static bool intel_crtc_in_use(struct drm_crtc *crtc)
> -{
> - struct drm_encoder *encoder;
> - struct drm_device *dev = crtc->dev;
> -
> - list_for_each_entry(encoder, &dev->mode_config.encoder_list, head)
> - if (encoder->crtc == crtc)
> - return true;
> -
> - return false;
> -}
> -
> static void
> -intel_modeset_update_state(struct drm_atomic_state *state)
> +intel_modeset_update_crtc_state(struct drm_atomic_state *state)
> {
> struct drm_crtc *crtc;
> struct drm_crtc_state *crtc_state;
> int i;
>
> - intel_shared_dpll_commit(state);
This should be right next to swap_state, and we should probably rename it
to be consistent.
> -
> - drm_atomic_helper_update_legacy_modeset_state(state->dev, state);
This helper should always work, why try to optimize things?
> -
> /* Double check state. */
> for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - WARN_ON(crtc->state->enable != intel_crtc_in_use(crtc));
I guess this WARN_ON should be moved into the state checker? Or entirely
removed if redundant.
> -
> to_intel_crtc(crtc)->config = to_intel_crtc_state(crtc->state);
>
> /* Update hwmode for vblank functions */
> @@ -13110,12 +13092,14 @@ static int intel_atomic_commit(struct drm_device
> *dev,
>
> /* Only after disabling all output pipelines that will be changed can we
>* update the the output configuration. */
> - intel_modeset_update_state(state);
> + intel_modeset_update_crtc_state(state);
>
> - /* The state has been swaped above, so state actually contains the
> - * old state now. */
> - if (any_ms)
> + if (any_ms) {
> + intel_shared_dpll_commit(state);
> +
> + drm_atomic_helper_update_legacy_modeset_state(state->dev,
> state);
> modeset_update_crtc_power_domains(state);
> + }
>
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> for_each_crtc_in_state(state, crtc, crtc_state, i) {
> --
> 2.1.0
>
> ___
> 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Call ww_acquire_done after check phase is complete
On Thu, Aug 06, 2015 at 06:17:28AM +0200, Maarten Lankhorst wrote:
> Op 06-08-15 om 00:25 schreef Daniel Vetter:
> > On Wed, Aug 5, 2015 at 8:13 PM, Maarten Lankhorst
> > wrote:
> >> Op 05-08-15 om 17:03 schreef Daniel Vetter:
> >>> On Wed, Aug 5, 2015 at 4:57 PM, Maarten Lankhorst
> >>> wrote:
> Op 05-08-15 om 15:08 schreef Daniel Vetter:
> > We want to make sure that no one tries to acquire more locks and
> > states, and ww mutexes provide debug facilities for that. So use them.
> >
> > Cc: Rob Clark
> > Cc: Maarten Lankhorst
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_atomic.c | 2 ++
> > 1 file changed, 2 insertions(+)
> I like the idea, played with the thought myself, but I think it might
> need to be slightly less strict for transitional drivers.
> >>> What would blow up? This should only be called fairly late in the
> >>> transition when most of the atomic handling is correctly done. And
> >>> i915 is probably the most extreme example of a conversion, so if it
> >>> works out for us I think everyone else should be fine too.
> >> Might blow up with transitional helpers, though not 100% sure if it would.
> > Transitional helpers don't use the top-level atomic_commit/check entry
> > points and hence don't use this function here at all.
> >
> >> Also if atomic_check returns -EDEADLK you would still say acquire_done,
> >> that will definitely blow up in legitimate cases..
> >>
> >> If it doesn't blow up transitional helpers and you fix the -EDEADLK,
> >> acked-by. :-)
> > Yeah that needs to be fixed ;-)
> After some sleep I think only when ret == 0 we should call acquire_done.
> >>> Generally drivers only started to do fancy stuff with get_*_state once
> >>> converted to atomic to start exploiting it, not before the transition
> >>> is completed. i915 is different since we have a lot of our own modeset
> >> Should we electrify drm_atomic_get_{*}_state too, to force everyone to use
> >> the get_existing_state versions?
> > And I think this is the killer - we unconditionally take the locks
> > again, taking advantage of -EALREADY. But with this patch that will
> > blow and we need to patch up all the existing code to use the
> > get_existing_state functions. That will be a bigger series I guess ...
> Depends, this only happens when the object can not be found in the state the
> locks are taken for planes and crtc's.
> But it seems for connectors it happens unconditionally.
> > I'll make a note about this and defer this for now. But the
> > get_*_state vs. get_existing_*_state thing will actually make these
> > two functions more distinctive, so I think this patch here will be
> > really useful. But needs driver fixes and kerneldoc updates too.
> I think this is fine; grabbing existing state for crtc's and planes will work
> and grabbing new state during atomic_commit is a bug anyway.
> The only driver that uses drm_atomic_get_connector_state is i915, which uses
> it for the setup phase.
Yeah I've done a full audit too, everything seems to be fine.
-Daniel
--
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] drm/atomic: Call ww_acquire_done after check phase is complete
We want to make sure that no one tries to acquire more locks and states, and ww mutexes provide debug facilities for that. So use them. v2: Only call acquire_done when ->atomic_check was successful to avoid falling over an -EDEADLK (spotted by Maarten). Cc: Rob Clark Cc: Maarten Lankhorst Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 422183e7ee7d..750ee96097b9 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1268,6 +1268,9 @@ int drm_atomic_check_only(struct drm_atomic_state *state) } } + if (ret == 0) + ww_acquire_done(&state->acquire_ctx->ww_ctx); + return ret; } EXPORT_SYMBOL(drm_atomic_check_only); -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3.1 3/3] drm/i915: Don't try to remove MST cleanly when force removed.
On Thu, Aug 06, 2015 at 01:47:37PM +0200, Maarten Lankhorst wrote:
> Physically disconnecting a DP connector with an active MST stream
> can lead to a kernel panic in intel_mst_disable_dp when calling
> drm_dp_update_payload_part1. Examining the code it seems that the
> port is freed while work to remove the connector is scheduled.
>
> This probably means it's fine to skip call all the mst helper calls
> and only attempt to disable the real encoder.
I think this is a refcounting bug in the dp mst helpers, the port
shouldn't just go poof when we still hold a reference to it. Can you
please try to figure out what's really broken here, and if that's too
tricky add a big FIXME comment?
Thanks, Daniel
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_dp_mst.c | 19 ++-
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 91ad17110c2f..19c9e49d74e0 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -110,6 +110,9 @@ static void intel_mst_disable_dp(struct intel_encoder
> *encoder)
>
> DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
>
> + if (!intel_mst->port)
> + return;
> +
> drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr, intel_mst->port);
>
> ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> @@ -126,12 +129,14 @@ static void intel_mst_post_disable_dp(struct
> intel_encoder *encoder)
>
> DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
>
> - /* this can fail */
> - drm_dp_check_act_status(&intel_dp->mst_mgr);
> - /* and this can also fail */
> - drm_dp_update_payload_part2(&intel_dp->mst_mgr);
> + if (intel_mst->port) {
> + /* this can fail */
> + drm_dp_check_act_status(&intel_dp->mst_mgr);
> + /* and this can also fail */
> + drm_dp_update_payload_part2(&intel_dp->mst_mgr);
>
> - drm_dp_mst_deallocate_vcpi(&intel_dp->mst_mgr, intel_mst->port);
> + drm_dp_mst_deallocate_vcpi(&intel_dp->mst_mgr, intel_mst->port);
> + }
>
> intel_dp->active_mst_links--;
> intel_mst->port = NULL;
> @@ -471,9 +476,13 @@ static void intel_dp_destroy_mst_connector(struct
> drm_dp_mst_topology_mgr *mgr,
> /* need to nuke the connector */
> drm_modeset_lock_all(dev);
> if (connector->state->crtc) {
> + struct drm_encoder *encoder = connector->state->best_encoder;
> + struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> struct drm_mode_set set;
> int ret;
>
> + intel_mst->port = NULL;
> +
> memset(&set, 0, sizeof(set));
> set.crtc = connector->state->crtc,
>
> --
> 2.1.0
>
> ___
> 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3.1 1/3] drm/i915: Fix broken mst get_hw_state.
On Thu, Aug 06, 2015 at 01:47:35PM +0200, Maarten Lankhorst wrote:
> This function always returned false because intel_connector->encoder
> is always NULL. Instead use the attached encoder from atomic.
Note that you've broken this since you removed the updating of
intel_connector->encoder somewhere in the 4.3 atomic series. So this is a
regression fix. Can you please digg out the right commit?
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_dp_mst.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index e3a5864160fa..ff01569158ea 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -395,9 +395,12 @@ 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) {
> + struct intel_encoder *encoder;
> +
> + encoder = to_intel_encoder(connector->base.state->best_encoder);
Strictly speaking this won't work for hw state readout since what we
really need to do is ask the mst connector which mst stream it accepts and
then compare that with all the mst encoders ...
But that's been broken since forever. Only side-effect here is that
fastboot won't work with mst and that's imo totally ok. Please also add
this to your commit message.
-Daniel
> + if (encoder) {
> enum pipe pipe;
> - if (!connector->encoder->get_hw_state(connector->encoder,
> &pipe))
> + if (!encoder->get_hw_state(encoder, &pipe))
> return false;
> return true;
> }
> --
> 2.1.0
>
> ___
> 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequences
On Wed, Aug 05, 2015 at 03:28:54PM -0300, Paulo Zanoni wrote:
> 2015-08-05 5:30 GMT-03:00 Daniel Vetter :
> > On Thu, Jul 30, 2015 at 06:20:28PM -0300, Paulo Zanoni wrote:
> >> From: Damien Lespiau
> >>
> >> Before this patch, we used the intel_display_power_{get,put} functions
> >> to make sure the PW1 and Misc I/O power wells were enabled all the
> >> time while LCPLL was enabled. We called a get() at
> >> intel_ddi_pll_init() when we discovered that LCPLL was enabled, then
> >> we would call put/get at skl_{un,}init_cdclk().
> >>
> >> The problem is that skl_uninit_cdclk() is indirectly called by
> >> intel_runtime_suspend(). So it will only release its power well
> >> _after_ we already decided to runtime suspend. But since we only
> >> decide to runtime suspend after all power wells and refcounts are
> >> released, that basically means we will never decide to runtime
> >> suspend.
> >>
> >> So what this patch does to fix that problem is move the PW1 + Misc I/O
> >> power well handling out of the runtime PM mechanism: instead of
> >> calling intel_display_power_{get_put} - functions that touch the
> >> refcount -, we'll call the low level intel_power_well_{en,dis}able,
> >> which don't change the refcount. This way, it is now possible for the
> >> refcount to actually reach zero, and we'll now start runtime
> >> suspending/resuming.
> >>
> >> v2 (from Paulo):
> >> - Write a commit message since the original patch left it empty.
> >> - Rebase after the intel_power_well_{en,dis}able rename.
> >> - Use lookup_power_well() instead of hardcoded indexes.
> >>
> >> Testcase: igt/pm_rpm/rte (and every other rpm test)
> >> Signed-off-by: Damien Lespiau
> >> Reviewed-by: Paulo Zanoni
> >> Signed-off-by: Paulo Zanoni
> >
> > This is imo too much of a hack. If we go with this then we should either
> > completely remove the pw1 and misc pw from the power well code and just
> > directly call the relevant functions.
>
> What do you mean by "the relevant functions"? Notice that the patch
> already moved us outside of the "power domains" framework, but not the
> "power wells" framework, since those are actual power wells. I'm still
> trying to fully understand what you wanted here.
The power wells abstraction doesn't buy anything here if we have a power
well that we always enable/disable with something else (device rpm here).
So instead of the lookup_power_well + enable call just remove pw1 and
pw-misc from the list of power wells and call the enable code directly.
Otherwise we just have a bit of abstraction that gets in the way. Also
note that dmc has similar requirements of enable pw1 and lcpll together to
avoid upsetting the firmware.
The overall idea is that abstraction should only be used when it actually
makes sense for a given platform. And I think using power wells
abstraction for pw1 and pw-misc on skl doesn't make sense since we can't
actually use it as an independent power well from the software pov - the
hw itself is different, but that's all managed by dmc firmware for us.
-Daniel
--
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] drm/atomic: Reject events for inactive crtc's.
On Thu, Aug 06, 2015 at 01:19:35PM +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 06-08-15 om 11:47 schreef Daniel Stone:
> > Hi,
> >
> > On 30 July 2015 at 08:03, Maarten Lankhorst
> > wrote:
> >> This will cause drm_atomic_helper_page_flip and drm_mode_atomic_ioctl to
> >> fail with -EINVAL if a event is requested on a inactive crtc.
> >>
> >> Signed-off-by: Maarten Lankhorst
> >> ---
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index d719ce0b10a0..679577e8e02d 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -476,6 +476,12 @@ static int drm_atomic_crtc_check(struct drm_crtc
> >> *crtc,
> >> return -EINVAL;
> >> }
> >>
> >> + if (!state->active && state->event) {
> >> + DRM_DEBUG_ATOMIC("[CRTC:%d] requesting event and not
> >> active\n",
> >> +crtc->base.id);
> >> + return -EINVAL;
> >> + }
> > Hmm, even if disabling? Maybe (!crtc->state->active && !state->active)
> > && state->event.
> How do you want to send a vblank event after disabling?
The event would be when we stop scanning out, but yeah that's a bit a
tricky one. I guess for now (until we have someone who needs this) we
could just merge Maarten's patch as the easier thing to do right now?
Maybe with a small code comment that this is intentional?
Atomic is a ridiculously complex interface, restricting it to just the
features we actually need is imo the right approach.
-Daniel
--
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] [PATCH v6 17/19] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset
On Wed, Aug 05, 2015 at 05:14:33PM +0100, Michel Thierry wrote: > On 8/5/2015 4:58 PM, Daniel Vetter wrote: > >On Wed, Jul 29, 2015 at 05:24:01PM +0100, Michel Thierry wrote: > >>There are some allocations that must be only referenced by 32-bit > >>offsets. To limit the chances of having the first 4GB already full, > >>objects not requiring this workaround use DRM_MM_SEARCH_BELOW/ > >>DRM_MM_CREATE_TOP flags > >> > >>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. > >> > >>Objects must have EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag to indicate if > >>they can be allocated above the 32-bit address range. To limit the > >>chances of having the first 4GB already full, objects will use > >>DRM_MM_SEARCH_BELOW + DRM_MM_CREATE_TOP flags when possible. > >> > >>v2: Changed flag logic from neeeds_32b, to supports_48b. > >>v3: Moved 48-bit support flag back to exec_object. (Chris, Daniel) > >>v4: Split pin flags into PIN_ZONE_4G and PIN_HIGH; update PIN_OFFSET_MASK > >>to use last PIN_ defined instead of hard-coded value; use correct limit > >>check in eb_vma_misplaced. (Chris) > >>v5: Don't touch PIN_OFFSET_MASK and update workaround comment (Chris) > >>v6: Apply pin-high for ggtt too (Chris) > >>v7: Handle simultaneous pin-high and pin-mappable end correctly (Akash) > >> Fix check for entries currently using +4GB addresses, use min_t and > >> other polish in object_bind_to_vm (Chris) > >> > >>Cc: Chris Wilson > >>Cc: Akash Goel > >>Reviewed-by: Chris Wilson (v4) > >>Signed-off-by: Michel Thierry > > > >For the record, where can I find the mesa patches for this? I think for > >simple things like this a References: line point to the relevant UMD > >patches in mailing-list archives would be great. > >-Daniel > > > > Here they are, > > References: > http://lists.freedesktop.org/archives/dri-devel/2015-July/085501.html and > http://lists.freedesktop.org/archives/mesa-dev/2015-July/088003.html Sounds like there's still another revision we need to do on those? -Daniel > > The name for the macro will be OUT_RELOC64_INSIDE_4G, as suggested by Chris. > -- 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] [PATCH 2/6] drm/atomic: pass old crtc state to atomic_begin/flush.
Hey, Op 05-08-15 om 08:18 schreef Tomi Valkeinen: > Hi, > > On 21/07/15 14:28, Maarten Lankhorst wrote: >> In intel it's useful to keep track of some state changes with old >> crtc state vs new state, for example to disable initial planes or >> when a modeset's prevented during fastboot. >> >> Cc: dri-de...@lists.freedesktop.org >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 6 -- >> drivers/gpu/drm/drm_atomic_helper.c| 8 >> drivers/gpu/drm/drm_plane_helper.c | 4 ++-- >> drivers/gpu/drm/i915/intel_display.c | 10 ++ >> drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 6 -- >> drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 6 -- >> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 -- >> drivers/gpu/drm/sti/sti_drm_crtc.c | 6 -- >> drivers/gpu/drm/tegra/dc.c | 6 -- >> include/drm/drm_crtc_helper.h | 6 -- >> 10 files changed, 40 insertions(+), 24 deletions(-) > Looks like this broke omapdrm in linux-next: > > drivers/gpu/drm/omapdrm/omap_crtc.c:470:2: error: initialization from > incompatible pointer type [-Werror] > drivers/gpu/drm/omapdrm/omap_crtc.c:470:2: error: (near initialization > for ‘omap_crtc_helper_funcs.atomic_begin’) [-Werror] > drivers/gpu/drm/omapdrm/omap_crtc.c:471:2: error: initialization from > incompatible pointer type [-Werror] > drivers/gpu/drm/omapdrm/omap_crtc.c:471:2: error: (near initialization > for ‘omap_crtc_helper_funcs.atomic_flush’) [-Werror] > > Tomi > This has been fixed up in topic/drm-misc? Compiles for me cleanly there. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 15/19] drm/i915: batch_obj vm offset must be u64
On Wed, Aug 05, 2015 at 05:14:03PM +0100, Michel Thierry wrote:
> On 8/5/2015 5:01 PM, Daniel Vetter wrote:
> >On Wed, Jul 29, 2015 at 05:23:59PM +0100, Michel Thierry wrote:
> >>Otherwise it can overflow in 48-bit mode, and cause an incorrect
> >>exec_start.
> >>
> >>Before commit 5f19e2bffa63a91cd4ac1adcec648e14a44277ce ("drm/i915: Merged
> >>the many do_execbuf() parameters into a structure"), it was already an u64.
> >>
> >>Signed-off-by: Michel Thierry
> >
> >So we have a few more u64, but the i915_gem_obj_offset is still unsigned
> >long. Am I missing a patch?
>
> http://news.gmane.org/find-root.php?message_id=1437063498-31930-1-git-send-email-michel.thie...@intel.com
>
> Which I need to re-send with the comments I got.
> Thanks for remind me.
Process reminder: If your patch series has depencies either
- include them at the start (git will correctly keep authorship), which is
the preferred approach
- or at least mention your depencies in the cover letter
Relying on your maintainer's mind-reader to figure this out doesn't scale ;-)
Cheers, Daniel
--
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] [PATCH v3.1 2/3] drm/i915: Update atomic state when removing mst connector, v3.
thanks for the change :)
Reviewed-by: Sivakumar Thulasimani
On 8/6/2015 5:17 PM, Maarten Lankhorst wrote:
Fully remove the MST connector from the atomic state, and remove the
early returns in check_*_state for MST connectors.
With atomic the state can be made consistent all the time.
Thanks to Sivakumar Thulasimani for the idea of using
drm_atomic_helper_set_config.
Changes since v1:
- Remove the MST check in intel_connector_check_state too.
Changes since v2:
- Use drm_atomic_helper_set_config.
Signed-off-by: Maarten Lankhorst
Cc: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
drivers/gpu/drm/i915/intel_dp_mst.c | 13 -
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5e40b7e7013a..77b4da7e698c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6370,10 +6370,6 @@ static void intel_connector_check_state(struct
intel_connector *connector)
connector->base.base.id,
connector->base.name);
- /* there is no real hw state for MST connectors */
- if (connector->mst_port)
- return;
-
I915_STATE_WARN(connector->base.dpms == DRM_MODE_DPMS_OFF,
"wrong connector dpms state\n");
I915_STATE_WARN(connector->base.encoder != &encoder->base,
@@ -12749,13 +12745,6 @@ check_encoder_state(struct drm_device *dev)
encoder->base.crtc,
"connector's crtc doesn't match encoder crtc\n");
}
- /*
-* for MST connectors if we unplug the connector is gone
-* away but the encoder is still connected to a crtc
-* until a modeset happens in response to the hotplug.
-*/
- if (!enabled && encoder->base.encoder_type ==
DRM_MODE_ENCODER_DPMST)
- continue;
I915_STATE_WARN(!!encoder->base.crtc != enabled,
"encoder's enabled state mismatch "
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index ff01569158ea..91ad17110c2f 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -467,9 +467,20 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
{
struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_device *dev = connector->dev;
+
/* need to nuke the connector */
drm_modeset_lock_all(dev);
- intel_connector_dpms(connector, DRM_MODE_DPMS_OFF);
+ if (connector->state->crtc) {
+ struct drm_mode_set set;
+ int ret;
+
+ memset(&set, 0, sizeof(set));
+ set.crtc = connector->state->crtc,
+
+ ret = drm_atomic_helper_set_config(&set);
+
+ WARN(ret, "Disabling mst crtc failed with %i\n", ret);
+ }
drm_modeset_unlock_all(dev);
intel_connector->unregister(intel_connector);
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 02/19] drm/i915/gen8: Make pdp allocation more dynamic
On Wed, Aug 05, 2015 at 04:49:17PM +0100, Michel Thierry wrote: > On 8/5/2015 4:31 PM, Daniel Vetter wrote: > >On Wed, Jul 29, 2015 at 05:23:46PM +0100, Michel Thierry wrote: > >>This transitional patch doesn't do much for the existing code. However, > >>it should make upcoming patches to use the full 48b address space a bit > >>easier. > > > >commit message should also mention how exactly it's more dynamic and why > >exactly that's useful ... It's ofc possible to infer that from the > >context, but that won't be the case any more if you look at the patch > >alone (with git blame or after a bisect). Please follow up with a few > >words so I can add them to the commit message. > >-Daniel > > > > Hi Daniel, > Agree the description is vague. Here's the updated commit message, let me > know what you think (and if you want a new patch): > > drm/i915/gen8: Make pdp allocation more dynamic > > This transitional patch doesn't do much for the existing code. However, > it should make upcoming patches to use the full 48b address space a bit > easier. > > 32-bit ppgtt uses just 4 PDPs, while 48-bit ppgtt will have up-to 512; > this patch prepares the existing functions to query the right number of pdps > at run-time. This also means that used_pdpes should also be allocated during > ppgtt_init, as the bitmap size will depend on the ppgtt address range > selected. Existing patch amended, thanks. -Daniel > > v2: Renamed pdp_free to be similar to pd/pt (unmap_and_free_pdp). > v3: To facilitate testing, 48b mode will be available on Broadwell and > GEN9+, when i915.enable_ppgtt = 3. > v4: Rebase after s/page_tables/page_table/, added extra information > about 4-level page table formats and use IS_ENABLED macro. > v5: Check CONFIG_X86_64 instead of CONFIG_64BIT. > v6: Rebase after Mika's ppgtt cleanup / scratch merge patch series, and > follow > his nomenclature in pdp functions (there is no alloc_pdp yet). > v7: Rebase after merged version of Mika's ppgtt cleanup patch series. > v8: Rebase after final merged version of Mika's ppgtt/scratch patches. > v9: Introduce PML4 (and 48-bit checks) until next patch (Akash). > v10: Also use test_bit to detect when pd/pt are already allocated (Akash) > v11: > > Cc: Akash Goel > Signed-off-by: Ben Widawsky > Signed-off-by: Michel Thierry (v2+) -- 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] [PATCH] drm/i915: Split sink_crc function in start, stop and read.
On Wed, Aug 05, 2015 at 08:30:01PM +, Vivi, Rodrigo wrote:
> On Wed, 2015-08-05 at 10:07 +0200, Daniel Vetter wrote:
> > On Thu, Jul 30, 2015 at 04:26:39PM -0700, Rodrigo Vivi wrote:
> > > This is just a preparation patch to make clear what operation we
> > > are performing. There is no functional change on the sink crc
> > > logic.
> > >
> > > hsw_disable_ips has been moved a bit further in the start function
> > > to avoid disabling ips when sink crc is not going to be started.
> > > and to avoid goto on this function.
> > >
> > > v2: explain why hsw_disable_ips() call place has changed.
> > >
> > > Cc: Daniel Vetter
> > > Reviewed-by: Rafael Antognolli
> > > Signed-off-by: Rodrigo Vivi
> >
> > Thanks for the updated commit message. Queued for -next, thanks for the
> > patch.
>
> Thanks!
>
> Do you intend to merge the other 3 remaining patches?
> Or am I missing something there?
Nah just oversight, merged 3 more patches. Do I have them all now?
-Daniel
>
> Thanks,
> Rodrigo.
>
> > -Daniel
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 89
> > > +++--
> > > 1 file changed, 50 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 44f8a32..10cbc98 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -3958,40 +3958,64 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
> > > return intel_dp->is_mst;
> > > }
> > >
> > > -int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
> > > +static void intel_dp_sink_crc_stop(struct intel_dp *intel_dp)
> > > {
> > > - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > - struct drm_device *dev = intel_dig_port->base.base.dev;
> > > - struct intel_crtc *intel_crtc =
> > > - to_intel_crtc(intel_dig_port->base.base.crtc);
> > > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > + struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
> > > u8 buf;
> > > - int test_crc_count;
> > > - int attempts = 6;
> > > - int ret = 0;
> > > -
> > > - hsw_disable_ips(intel_crtc);
> > >
> > > - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0) {
> > > - ret = -EIO;
> > > - goto out;
> > > + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
> > > + DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> > > + return;
> > > }
> > >
> > > - if (!(buf & DP_TEST_CRC_SUPPORTED)) {
> > > - ret = -ENOTTY;
> > > - goto out;
> > > - }
> > > + if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> > > +buf & ~DP_TEST_SINK_START) < 0)
> > > + DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> > >
> > > - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
> > > - ret = -EIO;
> > > - goto out;
> > > - }
> > > + hsw_enable_ips(intel_crtc);
> > > +}
> > > +
> > > +static int intel_dp_sink_crc_start(struct intel_dp *intel_dp)
> > > +{
> > > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > + struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
> > > + u8 buf;
> > > +
> > > + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0)
> > > + return -EIO;
> > > +
> > > + if (!(buf & DP_TEST_CRC_SUPPORTED))
> > > + return -ENOTTY;
> > > +
> > > + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0)
> > > + return -EIO;
> > > +
> > > + hsw_disable_ips(intel_crtc);
> > >
> > > if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> > > - buf | DP_TEST_SINK_START) < 0) {
> > > - ret = -EIO;
> > > - goto out;
> > > +buf | DP_TEST_SINK_START) < 0) {
> > > + hsw_enable_ips(intel_crtc);
> > > + return -EIO;
> > > }
> > >
> > > + return 0;
> > > +}
> > > +
> > > +int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
> > > +{
> > > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > + struct drm_device *dev = dig_port->base.base.dev;
> > > + struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
> > > + u8 buf;
> > > + int test_crc_count;
> > > + int attempts = 6;
> > > + int ret;
> > > +
> > > + ret = intel_dp_sink_crc_start(intel_dp);
> > > + if (ret)
> > > + return ret;
> > > +
> > > if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0) {
> > > ret = -EIO;
> > > goto stop;
> > > @@ -4014,23 +4038,10 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp,
> > > u8 *crc)
> > > goto stop;
> > > }
> > >
> > > - if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) {
> > > + if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0)
> > > ret = -EIO;
> > > - goto stop;
> > > - }
> >
Re: [Intel-gfx] [PATCH 1/2 v2] drm/i915: Allow parsing of variable size child device entries from VBT
On Wed, Aug 05, 2015 at 06:32:01PM +0300, David Weinehall wrote: > On Wed, Aug 05, 2015 at 10:59:00AM +0200, Daniel Vetter wrote: > > On Tue, Aug 04, 2015 at 04:55:52PM +0300, David Weinehall wrote: > > > VBT version 196 increased the size of common_child_dev_config. The parser > > > code assumed that the size of this structure would not change. > > > > > > The modified code now copies the amount needed based on the VBT version, > > > and emits a debug message if the VBT version is unknown (too new); > > > since the struct config block won't shrink in newer versions it should > > > be harmless to copy the maximum known size in such cases, so that's > > > what we do, but emitting the warning is probably sensible anyway. > > > > > > In the longer run it might make sense to modify the parser code to > > > use a version/feature mapping, rather than hardcoding things like this, > > > but for now the variants are fairly managable. > > > > > > v2: Stricter size checks > > > > > > Signed-off-by: David Weinehall > > > > Since Chris mentioned that this should fix a regression I applied it to > > drm-intel-fixes. > > Great! Will you merge the other patch in the series to the nightly > build? I only merged this fast-tracked because it fixes a regression. For the other patch normal review rules still apply (i.e. I won't do it). -Daniel -- 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] [RFC 2/2] drm/i915: Moved the cache flush outside the 'struct_mutex' lock
On Sun, May 04, 2014 at 04:48:25PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> Moved the cache flush of the preallocated shmem pages outside
> the span of 'struct_mutex' lock. This shall not lead to any
> redundancy as the cache flush of the newly allocated pages
> will be done anyways when same buffer is submitted to GPU or
> when the domain of the object is changed from CPU to GTT
> in Gem page fault handler.
>
> Signed-off-by: Akash Goel
> ---
> drivers/gpu/drm/i915/i915_gem.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b19ccb8..7ab2635 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1936,8 +1936,11 @@ i915_gem_object_shmem_preallocate(struct
> drm_i915_gem_object *obj)
> if (IS_ERR(page)) {
> DRM_DEBUG_DRIVER("Failure for obj(%p), size(%x) at
> page(%d)\n",
> obj, obj->base.size, i);
> - break;
> + return;
> }
> + /* Flush the cpu cache for the page now itself */
> + drm_clflush_pages(&page, 1);
> +
> /* Decrement the extra ref count on the returned page,
> otherwise when 'get_pages_gtt' will be called later on
> in the regular path, it will also increment the ref count,
> @@ -1945,6 +1948,14 @@ i915_gem_object_shmem_preallocate(struct
> drm_i915_gem_object *obj)
> page_cache_release(page);
> }
>
> + /*
> + * Reset the CPU domain now itself, so as to avoid the cache
> + * flush later (under 'struct_mutex' lock), as the all pages
> + * have been cache flushed.
> + * Hope this is safe enough to be done here.
> + */
> + obj->base.write_domain = 0;
So cache-domain-management is under the struct_mutex, for good reason.
However, if we follow the idea to move this to create2, then adding a
flag to also do the clflush upon allocation seems fine. Note that I
don't think doing it by default is a good match for everything, since my
code and also the kernel already takes advantage of the fact that fresh
buffers are in the CPU cache domain and uses that to do any initial
transfers in the CPU domain.
So we have I915_CREATE_POPULATE, I915_CREATE_COHERENT ?
-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 v3.1 04/13] drm/i915: Convert connector checking to atomic, v3.
Right now dpms callbacks can still fiddle with the connector state,
but it can only turn connectors off.
This is remediated by only checking crtc->state->active when the
connector is active, and ignore crtc->state->active when the
connector is off.
connectors_active is no longer checked, and will be removed later
in this series together with dpms.
Another check for !encoder->crtc is performed by check_encoder_state
too, so it can be removed.
Changes since v1:
- Add commit message.
- rename state to old_state.
- Move deletion of mst_port check to mst patch.
Changes since v2:
- Fix a null pointer dereference on MST now hw readout is fixed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveira
---
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 77b4da7e698c..9baddc16b285 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6360,38 +6360,36 @@ static void intel_encoder_dpms(struct intel_encoder
*encoder, int mode)
* internal consistency). */
static void intel_connector_check_state(struct intel_connector *connector)
{
+ struct drm_crtc *crtc = connector->base.state->crtc;
+
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
+ connector->base.base.id,
+ connector->base.name);
+
if (connector->get_hw_state(connector)) {
- struct intel_encoder *encoder = connector->encoder;
- struct drm_crtc *crtc;
- bool encoder_enabled;
- enum pipe pipe;
+ struct drm_encoder *encoder = &connector->encoder->base;
+ struct drm_connector_state *conn_state = connector->base.state;
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
- connector->base.base.id,
- connector->base.name);
+ I915_STATE_WARN(!crtc,
+"connector enabled without attached crtc\n");
- I915_STATE_WARN(connector->base.dpms == DRM_MODE_DPMS_OFF,
-"wrong connector dpms state\n");
- I915_STATE_WARN(connector->base.encoder != &encoder->base,
-"active connector not linked to encoder\n");
+ if (!crtc)
+ return;
- if (encoder) {
- I915_STATE_WARN(!encoder->connectors_active,
-"encoder->connectors_active not set\n");
+ I915_STATE_WARN(!crtc->state->active,
+ "connector is active, but attached crtc isn't\n");
- encoder_enabled = encoder->get_hw_state(encoder, &pipe);
- I915_STATE_WARN(!encoder_enabled, "encoder not
enabled\n");
- if (I915_STATE_WARN_ON(!encoder->base.crtc))
- return;
+ if (!encoder)
+ return;
- crtc = encoder->base.crtc;
+ I915_STATE_WARN(conn_state->best_encoder != encoder,
+ "atomic encoder doesn't match attached encoder\n");
- I915_STATE_WARN(!crtc->state->enable,
- "crtc not enabled\n");
- I915_STATE_WARN(!to_intel_crtc(crtc)->active, "crtc not
active\n");
- I915_STATE_WARN(pipe != to_intel_crtc(crtc)->pipe,
-"encoder active on the wrong pipe\n");
- }
+ I915_STATE_WARN(conn_state->crtc != encoder->crtc,
+ "attached encoder crtc differs from connector crtc\n");
+ } else {
+ I915_STATE_WARN(!crtc && connector->base.state->best_encoder,
+ "best encoder set without crtc!\n");
}
}
@@ -12699,20 +12697,23 @@ static void check_wm_state(struct drm_device *dev)
}
static void
-check_connector_state(struct drm_device *dev)
+check_connector_state(struct drm_device *dev,
+ struct drm_atomic_state *old_state)
{
- struct intel_connector *connector;
+ struct drm_connector_state *old_conn_state;
+ struct drm_connector *connector;
+ int i;
- for_each_intel_connector(dev, connector) {
- struct drm_encoder *encoder = connector->base.encoder;
- struct drm_connector_state *state = connector->base.state;
+ for_each_connector_in_state(old_state, connector, old_conn_state, i) {
+ struct drm_encoder *encoder = connector->encoder;
+ struct drm_connector_state *state = connector->state;
/* This also checks the encoder/connector hw state with the
* ->get_hw_state callbacks. */
- intel_connector_check_state(connector);
+ intel_connector_check_state(to_intel_connector(connector));
I915_STATE_WARN(state->best_encode
[Intel-gfx] [PATCH v3.1 2/3] drm/i915: Update atomic state when removing mst connector, v3.
Fully remove the MST connector from the atomic state, and remove the
early returns in check_*_state for MST connectors.
With atomic the state can be made consistent all the time.
Thanks to Sivakumar Thulasimani for the idea of using
drm_atomic_helper_set_config.
Changes since v1:
- Remove the MST check in intel_connector_check_state too.
Changes since v2:
- Use drm_atomic_helper_set_config.
Signed-off-by: Maarten Lankhorst
Cc: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
drivers/gpu/drm/i915/intel_dp_mst.c | 13 -
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5e40b7e7013a..77b4da7e698c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6370,10 +6370,6 @@ static void intel_connector_check_state(struct
intel_connector *connector)
connector->base.base.id,
connector->base.name);
- /* there is no real hw state for MST connectors */
- if (connector->mst_port)
- return;
-
I915_STATE_WARN(connector->base.dpms == DRM_MODE_DPMS_OFF,
"wrong connector dpms state\n");
I915_STATE_WARN(connector->base.encoder != &encoder->base,
@@ -12749,13 +12745,6 @@ check_encoder_state(struct drm_device *dev)
encoder->base.crtc,
"connector's crtc doesn't match encoder crtc\n");
}
- /*
-* for MST connectors if we unplug the connector is gone
-* away but the encoder is still connected to a crtc
-* until a modeset happens in response to the hotplug.
-*/
- if (!enabled && encoder->base.encoder_type ==
DRM_MODE_ENCODER_DPMST)
- continue;
I915_STATE_WARN(!!encoder->base.crtc != enabled,
"encoder's enabled state mismatch "
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index ff01569158ea..91ad17110c2f 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -467,9 +467,20 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
{
struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_device *dev = connector->dev;
+
/* need to nuke the connector */
drm_modeset_lock_all(dev);
- intel_connector_dpms(connector, DRM_MODE_DPMS_OFF);
+ if (connector->state->crtc) {
+ struct drm_mode_set set;
+ int ret;
+
+ memset(&set, 0, sizeof(set));
+ set.crtc = connector->state->crtc,
+
+ ret = drm_atomic_helper_set_config(&set);
+
+ WARN(ret, "Disabling mst crtc failed with %i\n", ret);
+ }
drm_modeset_unlock_all(dev);
intel_connector->unregister(intel_connector);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3.1 1/3] drm/i915: Fix broken mst get_hw_state.
This function always returned false because intel_connector->encoder
is always NULL. Instead use the attached encoder from atomic.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp_mst.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index e3a5864160fa..ff01569158ea 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -395,9 +395,12 @@ 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) {
+ struct intel_encoder *encoder;
+
+ encoder = to_intel_encoder(connector->base.state->best_encoder);
+ if (encoder) {
enum pipe pipe;
- if (!connector->encoder->get_hw_state(connector->encoder,
&pipe))
+ if (!encoder->get_hw_state(encoder, &pipe))
return false;
return true;
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3.1 3/3] drm/i915: Don't try to remove MST cleanly when force removed.
Physically disconnecting a DP connector with an active MST stream
can lead to a kernel panic in intel_mst_disable_dp when calling
drm_dp_update_payload_part1. Examining the code it seems that the
port is freed while work to remove the connector is scheduled.
This probably means it's fine to skip call all the mst helper calls
and only attempt to disable the real encoder.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp_mst.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 91ad17110c2f..19c9e49d74e0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -110,6 +110,9 @@ static void intel_mst_disable_dp(struct intel_encoder
*encoder)
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
+ if (!intel_mst->port)
+ return;
+
drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr, intel_mst->port);
ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
@@ -126,12 +129,14 @@ static void intel_mst_post_disable_dp(struct
intel_encoder *encoder)
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
- /* this can fail */
- drm_dp_check_act_status(&intel_dp->mst_mgr);
- /* and this can also fail */
- drm_dp_update_payload_part2(&intel_dp->mst_mgr);
+ if (intel_mst->port) {
+ /* this can fail */
+ drm_dp_check_act_status(&intel_dp->mst_mgr);
+ /* and this can also fail */
+ drm_dp_update_payload_part2(&intel_dp->mst_mgr);
- drm_dp_mst_deallocate_vcpi(&intel_dp->mst_mgr, intel_mst->port);
+ drm_dp_mst_deallocate_vcpi(&intel_dp->mst_mgr, intel_mst->port);
+ }
intel_dp->active_mst_links--;
intel_mst->port = NULL;
@@ -471,9 +476,13 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
/* need to nuke the connector */
drm_modeset_lock_all(dev);
if (connector->state->crtc) {
+ struct drm_encoder *encoder = connector->state->best_encoder;
+ struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
struct drm_mode_set set;
int ret;
+ intel_mst->port = NULL;
+
memset(&set, 0, sizeof(set));
set.crtc = connector->state->crtc,
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/2] drm/i915: Pre-allocation of shmem pages of a GEM object
On Sun, May 04, 2014 at 04:48:24PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> This patch could help to reduce the time, 'struct_mutex' is kept
> locked during either the exec-buffer path or Page fault
> handling path as now the backing pages are requested from shmem layer
> without holding the 'struct_mutex'.
I'm not keen on having an extra pass inside execbuffer for what should
be relatively rare, but in discussion the idea of adding a flag to
create2 (I915_CREATE_POPULATE) should cover the usecase nicely (having
to pay the shmemfs allocation+zero price without holding struct_mutex).
> +void
> +i915_gem_object_shmem_preallocate(struct drm_i915_gem_object *obj)
This is unlocked. We have to be loud and clear about that
static void __i915_gem_object_shmemfs_populate(obj)
> +{
> + int page_count, i;
> + struct address_space *mapping;
> + struct page *page;
> + gfp_t gfp;
> +
> + if (obj->pages)
> + return;
if (READ_ONCE(obj->pages) return;
> + if (obj->madv != I915_MADV_WILLNEED) {
> + DRM_ERROR("Attempting to preallocate a purgeable object\n");
Ideally if (READ_ONCE(obj->madv)...
However, that requires a patch to move madv to unsigned obj->flags.
A user controllable *ERROR*? No, just make it debug.
> + return;
> + }
> +
> + if (obj->base.filp) {
> + int ret;
> + struct inode *inode = file_inode(obj->base.filp);
> + struct shmem_inode_info *info = SHMEM_I(inode);
> + if (!inode)
> + return;
Assume it exists. If it doesn't it is an internal bug so we should just
GPF out of here.
> + /* The alloced field stores how many data pages are allocated
> + * to the file. If already shmem space has been allocated for
> + * the object, then we can simply return */
> + spin_lock(&info->lock);
> + ret = info->alloced;
> + spin_unlock(&info->lock);
> + if (ret > 0) {
> + DRM_DEBUG_DRIVER("Already shmem space alloced for obj
> %p, %d pages\n",
> + obj, ret);
> + return;
> + }
I'm convinced this is of much use though. If the page is already
allocated the shmem_read_mapping_page_gfp should be quick. Given the
suggestion that we move this to create, it is clear that this won't be
an issue.
> + } else
> + return;
> +
> + BUG_ON(obj->pages_pin_count);
Requires struct_mutex; ignore.
> +
> + /* Assert that the object is not currently in any GPU domain. As it
> + * wasn't in the GTT, there shouldn't be any way it could have been in
> + * a GPU cache
> + */
> + BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
> + BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);
Requires struct_mutex; ignore.
> + trace_i915_gem_obj_prealloc_start(obj, obj->base.size);
You only need to pass obj to the tracer, it can work out the size
itself.
> + page_count = obj->base.size / PAGE_SIZE;
> +
> + /* Get the list of pages out of our struct file
> + * Fail silently without starting the shrinker
> + */
> + mapping = file_inode(obj->base.filp)->i_mapping;
> + gfp = mapping_gfp_mask(mapping);
> + gfp |= __GFP_NORETRY | __GFP_NOWARN | __GFP_NO_KSWAPD;
> + gfp &= ~(__GFP_IO | __GFP_WAIT);
Interesting. Disabling shrinker/oom for these pages - we will hit it
later of course. But for the purposes of a quick preallocation, seems
fine.
> + for (i = 0; i < page_count; i++) {
> + page = shmem_read_mapping_page_gfp(mapping, i, gfp);
> + if (IS_ERR(page)) {
> + DRM_DEBUG_DRIVER("Failure for obj(%p), size(%x) at
> page(%d)\n",
> + obj, obj->base.size, i);
> + break;
> + }
> + /* Decrement the extra ref count on the returned page,
> +otherwise when 'get_pages_gtt' will be called later on
> +in the regular path, it will also increment the ref count,
> +which will disturb the ref count management */
> + page_cache_release(page);
> + }
> +
> + trace_i915_gem_obj_prealloc_end(obj);
> +}
-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] [SKL-DMC-BUGFIX 3/5] drm/i915/skl: Do not disable cdclk PLL if csr firmware is present
While display engine entering into low power state no need to disable
cdclk pll as CSR firmware of dmc will take care. If pll is already
enabled firmware execution sequence will be blocked. This is one
of the criteria for dmc to work properly.
v1: Initial version.
v2: Based on review comment from Daniel added code commnent.
Cc: Daniel Vetter
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-bt: Vathsala Nagaraju
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index af0bcfe..1f8d704 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5675,10 +5675,16 @@ void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
if (I915_READ(DBUF_CTL) & DBUF_POWER_STATE)
DRM_ERROR("DBuf power disable timeout\n");
- /* disable DPLL0 */
- I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) & ~LCPLL_PLL_ENABLE);
- if (wait_for(!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK), 1))
- DRM_ERROR("Couldn't disable DPLL0\n");
+ /*
+* DMC assumes ownership of LCPLL and will get confused if we touch it.
+*/
+ if (dev_priv->csr.dmc_payload) {
+ /* disable DPLL0 */
+ I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) &
+ ~LCPLL_PLL_ENABLE);
+ if (wait_for(!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK), 1))
+ DRM_ERROR("Couldn't disable DPLL0\n");
+ }
intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
}
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/atomic: Reject events for inactive crtc's.
Hey,
Op 06-08-15 om 11:47 schreef Daniel Stone:
> Hi,
>
> On 30 July 2015 at 08:03, Maarten Lankhorst
> wrote:
>> This will cause drm_atomic_helper_page_flip and drm_mode_atomic_ioctl to
>> fail with -EINVAL if a event is requested on a inactive crtc.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index d719ce0b10a0..679577e8e02d 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -476,6 +476,12 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
>> return -EINVAL;
>> }
>>
>> + if (!state->active && state->event) {
>> + DRM_DEBUG_ATOMIC("[CRTC:%d] requesting event and not
>> active\n",
>> +crtc->base.id);
>> + return -EINVAL;
>> + }
> Hmm, even if disabling? Maybe (!crtc->state->active && !state->active)
> && state->event.
How do you want to send a vblank event after disabling?
I think the only thing that makes sense would be not creating events when
crtc_state->enable = false,
so when a crtc is removed and an event is requested you won't return -EINVAL.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915/skl: Making DC6 entry is the last call in suspend flow.
Mmio register access after dc6/dc5 entry is not allowed when
DC6 power states are enabled according to bspec (bspec-id 0527),
so enabling dc6 as the last call in suspend flow.
Before triggering dc6 a condition check added to check firmware
loading status. Removed the set call for firmware loading state
to uninitilaze. As dmc will handle firmware loading in dc6 exit
flow, so we do not need the uninitialize call at all.
v1: Initial version.
v2: commit message updated based on comment from Vathsala.
v3: Added explanation in commit description for removed
intel_csr_load_status_set call in skl_suspend_complete()
(Suggested by Daniel).
Cc: Daniel Vetter
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/i915/i915_drv.c | 12 ++--
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 33 -
3 files changed, 16 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0d6775a..e1d0102 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1017,14 +1017,11 @@ static int skl_suspend_complete(struct drm_i915_private
*dev_priv)
{
/* Enabling DC6 is not a hard requirement to enter runtime D3 */
- /*
-* This is to ensure that CSR isn't identified as loaded before
-* CSR-loading program is called during runtime-resume.
-*/
- intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
-
skl_uninit_cdclk(dev_priv);
+ if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
+ skl_enable_dc6(dev_priv);
+
return 0;
}
@@ -1071,6 +1068,9 @@ static int skl_resume_prepare(struct drm_i915_private
*dev_priv)
{
struct drm_device *dev = dev_priv->dev;
+ if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
+ skl_disable_dc6(dev_priv);
+
skl_init_cdclk(dev_priv);
intel_csr_load_program(dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 47cef0e..06f346f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1117,6 +1117,8 @@ void bxt_enable_dc9(struct drm_i915_private *dev_priv);
void bxt_disable_dc9(struct drm_i915_private *dev_priv);
void skl_init_cdclk(struct drm_i915_private *dev_priv);
void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
+void skl_enable_dc6(struct drm_i915_private *dev_priv);
+void skl_disable_dc6(struct drm_i915_private *dev_priv);
void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6393b76..c660245 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -532,7 +532,7 @@ static void assert_can_disable_dc6(struct drm_i915_private
*dev_priv)
"DC6 already programmed to be disabled.\n");
}
-static void skl_enable_dc6(struct drm_i915_private *dev_priv)
+void skl_enable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -549,7 +549,7 @@ static void skl_enable_dc6(struct drm_i915_private
*dev_priv)
POSTING_READ(DC_STATE_EN);
}
-static void skl_disable_dc6(struct drm_i915_private *dev_priv)
+void skl_disable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -610,10 +610,10 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
!I915_READ(HSW_PWR_WELL_BIOS),
"Invalid for power well status to be enabled,
unless done by the BIOS, \
when request is to disable!\n");
- if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev)) &&
- power_well->data == SKL_DISP_PW_2) {
+ if (power_well->data == SKL_DISP_PW_2) {
+ if (GEN9_ENABLE_DC5(dev))
+ gen9_disable_dc5(dev_priv);
if (SKL_ENABLE_DC6(dev)) {
- skl_disable_dc6(dev_priv);
/*
* DDI buffer programming unnecessary
during driver-load/resume
* as it's already done during modeset
initialization then.
@@ -621,8 +621,6 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
*/
if
(!dev_priv->power_domains.initializing)
intel_prepare_ddi(dev);
-
Re: [Intel-gfx] [PATCH 3/4] ALSA: hda - display audio call ncts callback
On Thu, 06 Aug 2015 08:52:56 +0200,
libin.y...@intel.com wrote:
>
> From: Libin Yang
>
> On some Intel platforms, display audio need set N/CTS
> manually at some TMDS frequencies.
>
> Signed-off-by: Libin Yang
> ---
> sound/pci/hda/patch_hdmi.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index a97db5f..4bd11ff 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -1786,6 +1786,8 @@ static int generic_hdmi_playback_pcm_prepare(struct
> hda_pcm_stream *hinfo,
> int pin_idx = hinfo_to_pin_index(codec, hinfo);
> struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx);
> hda_nid_t pin_nid = per_pin->pin_nid;
> + struct snd_pcm_runtime *runtime = substream->runtime;
> + struct i915_audio_component *acomp = codec->bus->core.audio_component;
> bool non_pcm;
> int pinctl;
>
> @@ -1802,6 +1804,11 @@ static int generic_hdmi_playback_pcm_prepare(struct
> hda_pcm_stream *hinfo,
> intel_not_share_assigned_cvt(codec, pin_nid, per_pin->mux_idx);
> }
>
> + if (is_haswell_plus(codec)) {
> + if (acomp && acomp->ops && acomp->ops->set_ncts)
> + acomp->ops->set_ncts(acomp->dev, per_pin->pin_nid - 4,
Please describe more how "pin_nid - 4" is supposed to work. Also...
> + 0, runtime->rate);
... this implies that no MST support included?
Overall, it'd be appreciated if you put more information text in
changelog or comment. it series looks like a black magic to me unless
clearly explained.
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [SKL-DMC-BUGFIX 5/5] drm/i915/skl: Removed csr firmware load in resume path
On 8/4/2015 5:03 PM, Animesh Manna wrote:
On 8/4/2015 4:50 PM, Sunil Kamath wrote:
On Monday 03 August 2015 09:55 PM, Animesh Manna wrote:
As csr firmware is taking care of loading the firmware,
so no need for driver to load again.
Cc: Daniel Vetter
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vathsala Nagaraju
---
drivers/gpu/drm/i915/i915_drv.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index e1d0102..02019e9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1066,13 +1066,10 @@ static int bxt_resume_prepare(struct
drm_i915_private *dev_priv)
static int skl_resume_prepare(struct drm_i915_private *dev_priv)
{
-struct drm_device *dev = dev_priv->dev;
-
if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
skl_disable_dc6(dev_priv);
skl_init_cdclk(dev_priv);
-intel_csr_load_program(dev);
Same comment as before.
The context save and restore program is reset on cold boot, warm
reset, PCI function level reset, and hibernate/suspend.
Need valid reason to do this change. If reading DC5/DC6 counters is a
concern, lets use this as just debug patch.
Dont hurry on this patch.
Need to close on the above opens.
- Sunil
Agree, I want to add this patch as part of this patch series, already
started communication with firmware team.
Waiting for suggestion, will followup and proceed further based on
suggestion.
Regards,
Animesh
Firmware team confirmed that one time firmware loading during driver loading is
sufficient, no need
to load firmware in csr-address-space every suspend (dc6 entry) - resume (dc6
exit) flow, dmc will
take care of it.
- Animesh
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/atomic: Reject events for inactive crtc's.
Hi,
On 30 July 2015 at 08:03, Maarten Lankhorst
wrote:
> This will cause drm_atomic_helper_page_flip and drm_mode_atomic_ioctl to
> fail with -EINVAL if a event is requested on a inactive crtc.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d719ce0b10a0..679577e8e02d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -476,6 +476,12 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
> return -EINVAL;
> }
>
> + if (!state->active && state->event) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d] requesting event and not
> active\n",
> +crtc->base.id);
> + return -EINVAL;
> + }
Hmm, even if disabling? Maybe (!crtc->state->active && !state->active)
&& state->event.
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP
On 8/6/2015 1:04 AM, Benjamin Tissoires wrote:
On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
identify both lane count and reversal state without touching anything in the
link training code. i am yet to upstream my changes for CHT that i can share
if required that does the same in intel_dp_detect without touching any line
in link training path.
With my current limited knowledge of the dp hotplug (and i915 driver) I
am not sure we could detect the reversed state without trying to train 1
lane only. I'd be glad to look at your changes and test them on my
system if you think that could help having a cleaner solution.
Cheers,
Benjamin
No, what i recommended was to do link training but in intel_dp_detect. Since
USB Type C cable
also has its own lane count restriction (it can have different lane count
than the one supported
by panel) you might have to figure that out as well. so both reversal and
lane count detection
can be done outside the modeset path and keep the code free of type C
changes outside
detection path.
Please find below the code to do the same. Do not waste time trying to apply
this directly on
nightly since this is based on a local tree and because this is pre- atomic
changes code, so you
might have to modify chv_upfront_link_train to work on top of the latest
nightly code. we
are supposed to upstream this and is in my todo list.
[original patch snipped...]
Hi Sivakumar,
So I managed to manually re-apply your patch on top of
drm-intel-nightly, and tried to port it to make Broadwell working too.
It works OK if the system is already boot without any external DP used.
In this case, the detection works and I can see my external monitor
working properly.
However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
understand why. I think I enabled all that is mentioned in the PRM to be
able to train the DP link, but I am obviously missing something else.
Can you have a look?
My patch is now:
@@ -4495,7 +4499,9 @@ intel_dp_detect(struct drm_connector *connector, bool
force)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *intel_encoder = &intel_dig_port->base;
+ struct drm_crtc *crtc = intel_dig_port->base.base.crtc;
struct drm_device *dev = connector->dev;
+ struct intel_crtc *intel_crtc;
enum drm_connector_status status;
enum intel_display_power_domain power_domain;
bool ret;
@@ -4540,6 +4546,18 @@ intel_dp_detect(struct drm_connector *connector, bool
force)
if (intel_encoder->type != INTEL_OUTPUT_EDP)
intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
+
+ if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT &&
+ (IS_BROADWELL(dev) || IS_CHERRYVIEW(dev))) {
+ /* Do not handle connected boot scenario where panel is enabled
+* by GOP/VBIOS.
+*/
+ if ((connector->status != connector_status_connected) &&
+ !(intel_encoder->connectors_active &&
+ crtc && crtc->enabled))
+ intel_upfront_link_train(dev, intel_dp, NULL);
+ }
+
here you are calling intel_upfront_link_train only if display is plugged
in and there is no crtc associated with it.
hence your code is working on hotplug. modify the above to consider
scenario when crtc is set and enabled
which happens when you plug in dp and boot the system. a good pointer is
the original code :)
+if (intel_encoder->connectors_active &&
+crtc && crtc->enabled) {
+intel_crtc = to_intel_crtc(crtc);
+DRM_DEBUG_KMS("Disabling crtc %c for upfront link training\n",
+pipe_name(intel_crtc->pipe));
+intel_crtc_control(crtc, false);
+}
But again, all these are experimental :), any point you touch crtc it is
not in line with the new "atomic"
thinking and will not be allowed upstream till it is fixed as per the
new way :).
status = connector_status_connected;
/* Try to read the source of the interrupt */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6..fcc95d5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1163,6 +1163,13 @@ bool intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
void intel_dp_start_link_train(struct intel_dp *intel_dp);
void intel_dp_complete_link_train(struct intel_dp *intel_dp);
void intel_dp_stop_link_train(struct intel_dp *intel_dp);
+bool intel_upfront_link_train(struct drm_device *dev,
+ struct intel_dp *intel_dp,
+ s
Re: [Intel-gfx] [alsa-devel] [PATCH 2/4] drm/i915: implement set_ncts callback
On Thu, 06 Aug 2015 08:52:55 +0200,
libin.y...@intel.com wrote:
>
> From: Libin Yang
>
> Display audio may not work at some frequencies
> with the HW provided N/CTS.
>
> This patch sets the proper N value for the
> given audio sample rate at the impacted frequencies.
> At other frequencies, it will use the N/CTS value
> which HW provides.
>
> Signed-off-by: Libin Yang
> ---
> drivers/gpu/drm/i915/i915_reg.h| 2 +
> drivers/gpu/drm/i915/intel_audio.c | 93
> ++
> 2 files changed, 95 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3a77678..0b1cd72 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7010,6 +7010,8 @@ enum skl_disp_power_wells {
> _HSW_AUD_MISC_CTRL_A, \
> _HSW_AUD_MISC_CTRL_B)
>
> +#define HSW_AUD_PIPE_CONN_SEL_CTRL 0x650ac
> +
> #define _HSW_AUD_DIP_ELD_CTRL_ST_A 0x650b4
> #define _HSW_AUD_DIP_ELD_CTRL_ST_B 0x651b4
> #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index dc32cf4..f1148cd 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -68,6 +68,28 @@ static const struct {
> { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> };
>
> +static const struct {
> + int sample_rate;
> + int clock;
> + int n;
> + int cts;
> +} aud_ncts[] = {
> + { 44100, DIV_ROUND_UP(297000 * 1000, 1001), 4459, 234375 },
> + { 44100, 297000, 4704, 247500 },
As these two clock values are referred repeatedly in other places,
it'd be better to define constants.
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr firmware
On 8/5/2015 2:31 PM, Daniel Vetter wrote:
On Tue, Aug 04, 2015 at 11:25:40AM +0530, Animesh Manna wrote:
On 8/4/2015 9:16 AM, Nagaraju, Vathsala wrote:
"This patch contains the changes to remove the byte swapping logic introduced with
old dmc firmware."
Which version of DMC need reversal logic? Atleast , 4,1.16,1.18 follow the
same format.
Packaging of firmware binary completely changed after api version 1.0, so by
old firmware I want to mean
the initial version before dmc 1.0.
This kind of information really must be included in the commit message.
Very likely someone with old firmware will bisect to this commit, and if
you don't include that people need latest dmc firmware there will be
confusion.
Commit message _must_ be complete and contain everything that was
discussed while reviewing and developing a patch.
I added a note while merging the patch.
-Daniel
Thanks Daniel. Sure, will follow your suggestion in future.
-Animesh
-Original Message-
From: Manna, Animesh
Sent: Monday, August 3, 2015 9:56 PM
To: intel-gfx@lists.freedesktop.org
Cc: Manna, Animesh; Vetter, Daniel; Lespiau, Damien; Deak, Imre; Kamath, Sunil;
Nagaraju, Vathsala
Subject: [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr
firmware
This patch contains the changes to remove the byte swapping logic introduced
with old dmc firmware.
While debugging PC10 entry issue for skylake found with latest dmc firmware
version 1.18 without byte swapping dmc is working fine and able to enter PC10.
v1: Initial version.
v2: Corrected firmware size during memcpy(). (Suggested by Sunil)
Cc: Daniel Vetter
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vathsala Nagaraju
---
drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_csr.c |
16
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b94ada9..9d0ee58 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -742,7 +742,7 @@ enum csr_state {
struct intel_csr {
const char *fw_path;
- __be32 *dmc_payload;
+ uint32_t *dmc_payload;
uint32_t dmc_fw_size;
uint32_t mmio_count;
uint32_t mmioaddr[8];
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 6d8a7bf..ba1ae03 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -244,7 +244,7 @@ void intel_csr_load_status_set(struct drm_i915_private
*dev_priv, void intel_csr_load_program(struct drm_device *dev) {
struct drm_i915_private *dev_priv = dev->dev_private;
- __be32 *payload = dev_priv->csr.dmc_payload;
+ u32 *payload = dev_priv->csr.dmc_payload;
uint32_t i, fw_size;
if (!IS_GEN9(dev)) {
@@ -256,7 +256,7 @@ void intel_csr_load_program(struct drm_device *dev)
fw_size = dev_priv->csr.dmc_fw_size;
for (i = 0; i < fw_size; i++)
I915_WRITE(CSR_PROGRAM_BASE + i * 4,
- (u32 __force)payload[i]);
+ payload[i]);
for (i = 0; i < dev_priv->csr.mmio_count; i++) {
I915_WRITE(dev_priv->csr.mmioaddr[i],
@@ -279,7 +279,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
char substepping = intel_get_substepping(dev);
uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
uint32_t i;
- __be32 *dmc_payload;
+ uint32_t *dmc_payload;
bool fw_loaded = false;
if (!fw) {
@@ -375,15 +375,7 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
}
dmc_payload = csr->dmc_payload;
- for (i = 0; i < dmc_header->fw_size; i++) {
- uint32_t *tmp = (u32 *)&fw->data[readcount + i * 4];
- /*
-* The firmware payload is an array of 32 bit words stored in
-* little-endian format in the firmware image and programmed
-* as 32 bit big-endian format to memory.
-*/
- dmc_payload[i] = cpu_to_be32(*tmp);
- }
+ memcpy(dmc_payload, &fw->data[readcount], nbytes);
/* load csr program during system boot, as needed for DC states */
intel_csr_load_program(dev);
--
2.0.2
___
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
