On Wed, 27 Oct 2021, "Navare, Manasi" wrote:
> On Wed, Oct 27, 2021 at 04:59:00PM +0300, Jani Nikula wrote:
>> The PPS, RC_RANGE_PARAM, and RC_BUF_THRESH logging are clearly for
>> debugging, and should not be info level messages.
>>
>> Signed-off-by: Jani Ni
rivers/gpu/drm/i915/gt/intel_timeline.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h | 8
drivers/gpu/drm/i915/i915_trace.h| 7 ++-
drivers/gpu/drm/i915/intel_dram.c| 30 ++
5 files changed, 9 insertions(+), 43 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
>
> @@ -1161,9 +1161,7 @@ gen11_dsi_enable_port_and_phy(struct intel_encoder
> *encoder,
> /* Step (4h, 4i, 4j, 4k): Configure transcoder */
> gen11_dsi_configure_transcoder(encoder, crtc_state);
>
> - /* Step 4l: Gate DDI clocks */
> - if (DISPLAY_VER(dev_priv) == 11)
> -
On Thu, 28 Oct 2021, Ville Syrjälä wrote:
> On Thu, Oct 28, 2021 at 01:29:21PM +0300, Jani Nikula wrote:
>>
>> Hi Dave & Daniel -
>>
>> Certainly more than I'd like at this stage, but it's mostly Cc: stable
>> material, and the tracepoint change
sequence.
BR,
Jani.
>
> Thanks,
> Vandita
>
>>
>> BR,
>> Jani.
>>
>>
>> >/* enable DDI buffer */
>> >gen11_dsi_enable_ddi_buffer(encoder);
>> >
>> > @@ -1161,9 +1161,7 @@ gen11_dsi_enable_port_and_phy(struct
>> intel_encoder *encoder,
>> >/* Step (4h, 4i, 4j, 4k): Configure transcoder */
>> >gen11_dsi_configure_transcoder(encoder, crtc_state);
>> >
>> > - /* Step 4l: Gate DDI clocks */
>> > - if (DISPLAY_VER(dev_priv) == 11)
>> > - gen11_dsi_gate_clocks(encoder);
>> > + gen11_dsi_gate_clocks(encoder);
>> > }
>> >
>> > static void gen11_dsi_powerup_panel(struct intel_encoder *encoder)
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
Add name to the audio sub-struct in drm_i915_private, and remove the
tautologies and other inconsistencies in the member names.
v2: Call the mutex member mutex, not lock. (Ville)
Cc: Dave Airlie
Reviewed-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Signed-off-by: Jani Nikula
---
drivers
Add a standalone definition of struct intel_audio_private, and note that
all of it is private to intel_audio.c.
v2: Rebase
Cc: Dave Airlie
Reviewed-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 45
It's all internal to intel_audio.c.
Cc: Dave Airlie
Reviewed-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_audio.c | 9 +
drivers/gpu/drm/i915/i915_drv.h| 10 +-
2 files changed, 10 inser
Unify audio init/cleanup paths wrt LPE audio, and base the logic on the
return values from LPE audio calls. Move the platform device check on
cleanup to intel_lpe_audio.c, thereby limiting all audio.lpe substruct
access to that file.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display
Follow the filename based prefix naming.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_audio.c | 4 ++--
drivers/gpu/drm/i915/display/intel_audio.h | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a
On Fri, 22 Oct 2021, Lucas De Marchi wrote:
> On Fri, Oct 22, 2021 at 07:27:55PM +0300, Jani Nikula wrote:
>>With an anonymous struct, this can be pure hierarchical organization
>>without code changes.
>
> start reading from patch 1 left me confused. A sentence here that ne
On Fri, 22 Oct 2021, Jani Nikula wrote:
> On Fri, 22 Oct 2021, Ville Syrjälä wrote:
>> On Fri, Oct 22, 2021 at 07:27:57PM +0300, Jani Nikula wrote:
>>> Add a standalone definition of struct intel_audio_private, and note that
>>> all of it is private to intel_audio.
; val = intel_de_read(dev_priv, ICL_PORT_CL_DW10(phy));
> val &= ~PWR_DOWN_LN_MASK;
> - val |= lane_mask << PWR_DOWN_LN_SHIFT;
> + val |= lane_mask;
> intel_de_write(dev_priv, ICL_PORT_CL_DW10(phy), val);
> }
--
Jani Nikula, Intel Open Source Graphics Center
With an anonymous struct, this can be pure hierarchical organization
without code changes. We'll follow up with adding a name to the
sub-struct separately.
Cc: Dave Airlie
Reviewed-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_
/dc_stream.h | 13 +
> drivers/gpu/drm/drm_dp_mst_topology.c | 42 ++-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> drivers/gpu/drm/radeon/radeon_dp_mst.c | 4 +-
> include/drm/drm_dp_mst_helper.h | 5 +-
> 13 files changed, 425 insertions(+), 16 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
On Fri, 29 Oct 2021, Jani Nikula wrote:
> On Wed, 27 Oct 2021, Lyude Paul wrote:
>> topic/amdgpu-dp2.0-mst-2021-10-27:
>> UAPI Changes:
>> Nope!
>>
>> Cross-subsystem Changes:
>> drm_dp_update_payload_part1() takes a new argument for specifying what the
&
L(0), val);
> + }
> + }
First off, usually if you have a clean, generic, high level function,
it's a hint you shouldn't stick low level register access there.
If you plug in two external displays and then unplug one of them, you
end up disabling the
er port/phy enabling (step 4m in gen11 mode set sequence)
Gen12, bspec 49204, 49188 and 55316:
- start with clocks gated at mapping
- gate *if* not already gated (steps 4c and 4i in gen12 mode set sequence)
It may be that your patch is correct, but IMO it does not match bspec.
BR,
Jani.
>
> Thanks
> Vandita
>>
>> BR,
>> Jani.
>>
>>
>>
>> >
>> > Thanks,
>> > Vandita
>> >
>> >>
>> >> BR,
>> >> Jani.
>> >>
>> >>
>> >> > /* enable DDI buffer */
>> >> > gen11_dsi_enable_ddi_buffer(encoder);
>> >> >
>> >> > @@ -1161,9 +1161,7 @@ gen11_dsi_enable_port_and_phy(struct
>> >> intel_encoder *encoder,
>> >> > /* Step (4h, 4i, 4j, 4k): Configure transcoder */
>> >> > gen11_dsi_configure_transcoder(encoder, crtc_state);
>> >> >
>> >> > - /* Step 4l: Gate DDI clocks */
>> >> > - if (DISPLAY_VER(dev_priv) == 11)
>> >> > - gen11_dsi_gate_clocks(encoder);
>> >> > + gen11_dsi_gate_clocks(encoder);
>> >> > }
>> >> >
>> >> > static void gen11_dsi_powerup_panel(struct intel_encoder *encoder)
>> >>
>> >> --
>> >> Jani Nikula, Intel Open Source Graphics Center
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
On Tue, 31 Aug 2021, Jani Nikula wrote:
> v2 of https://patchwork.freedesktop.org/series/94161/ with the VESA OUI
> check and an OUI helper patch added.
Maarten, Maxime, Thomas - may I have an ack for merging this via
drm-intel? I think at this time we can get the merge to drm-next and
bac
;
> ctrl |= INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE;
> intel_dp_aux_hdr_set_aux_backlight(conn_state, level);
> } else {
--
Jani Nikula, Intel Open Source Graphics Center
r, sort the includes
> alphabetically.
I didn't do a detailed review, maybe someone should, but superficially
seems good. On the series,
Acked-by: Jani Nikula
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/Makefile | 2 +-
> drivers/
able second
> VDSC engine, based
> on that condition. As I understand that one is about DSC config calculation,
> based on CDCLK
> which was calculated.
Point is, at the time compute_config gets called, what guarantees are
there that cdclk_state->actual.cdclk contains anything useful? This is
the design we have.
> If we bump up CDCLK, to avoid this, will we even then use a second VDSC ever?
I think we'll eventually need better logic than unconditionally bumping
to max, and it needs to take *both* the cdclk and the number of dsc
engines into account. The referenced bspec only has the vdsc clock
perspective, not overall perspective.
BR,
Jani.
> Another thing is that probably enabling second VDSC is cheaper in terms of
> power consumption,
> than bumping up the CDCLK.
>
> Stan
>
>> >
>> > Okay , So you suggest that we set the cd clock to max when we have such
>> > requirement, than enabling the second engine?
>>
>> That seems like the easiest solution. Another option might be to come up
>> with some lower dotclock limit for the use of the second vdsc. But not
>> sure we know where the tipping point is wrt. powr consumption.
>>
>> --
>> Ville Syrjälä
>> Intel
--
Jani Nikula, Intel Open Source Graphics Center
On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
wrote:
> On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
>> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
>> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
>> > w
On Tue, 14 Sep 2021, Lucas De Marchi wrote:
> On Tue, Sep 14, 2021 at 12:16:13PM +0300, Jani Nikula wrote:
>>On Wed, 08 Sep 2021, Lucas De Marchi wrote:
>>> We shouldn't be using debugfs_ namespace for this functionality. Rename
>>> debugfs_gt.[ch] to int
g; Navare,
>> Manasi D
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
>> engine for higher moderates
>>
>> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
>> wrote:
>> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovski
t;>
>
> Ping, could this be picked up for an -rc as these are very clearly bugs?
Thanks for the patches and review. Pushed to drm-intel-gt-next and
cherry-picked to drm-intel-fixes, header to -rc2.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
trs, so the wrappers are a bit complicated by that.
>
> Suggested by Jani.
>
> v2: fixup warnings in wrong place error.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 187 ---
>
On Fri, 10 Sep 2021, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds wrappers around all the vtable callers so they are in
> one place.
>
> Suggested by Jani.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915
On Fri, 10 Sep 2021, Dave Airlie wrote:
> From: Dave Airlie
>
> This wraps the fdi link training vfunc to make it clearer.
>
> Suggested by Jani.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2
On Fri, 10 Sep 2021, Dave Airlie wrote:
> From: Dave Airlie
>
> These are the watermark api between display and pm.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 35 -
> drivers
This is Dave's series [1] with patch 2 (drm/i915/uncore: constify the
register vtables.) dropped because it conflicts between drm-intel-next
and drm-intel-gt-next. I want to get proper CI results on this before
merging. We can do the leftover patch afterwards. Everything else is
unmodified.
BR,
Ja
From: Dave Airlie
constify it while here. drop the put function since it was never
overloaded and always has done the same thing, no point in
indirecting it for show.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_uncore.c | 70
From: Dave Airlie
The i845_update_wm code was always calling the i845 variant,
and the i9xx_update_wm had only a choice between i830 and i9xx
paths, hardly worth the vfunc overhead.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915
From: Dave Airlie
The crtc was never being used here.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 10 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c
v2: fixup warnings in wrong place error.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 187 ---
drivers/gpu/drm/i915/intel_pm.c | 39
drivers/gpu/drm/i915/intel_p
From: Dave Airlie
This wraps the fdi link training vfunc to make it clearer.
Suggested by Jani.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_fdi.c | 8
From: Dave Airlie
This adds wrappers around all the vtable callers so they are in
one place.
Suggested by Jani.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_cdclk.c| 47 +++
drivers/gpu/drm/i915
From: Dave Airlie
This function is only used inside intel_pm.c
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 9 ++-
drivers/gpu/drm/i915/intel_pm.c | 48 -
2 files changed, 32
From: Dave Airlie
These are the watermark api between display and pm.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 35 -
drivers/gpu/drm/i915/i915_drv.h | 24
From: Dave Airlie
These are only used internally in the color module
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_color.c | 64 +++---
drivers/gpu/drm/i915/i915_drv.h| 39 +++--
2
From: Dave Airlie
These are only used internally in the audio code
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_audio.c | 24 +++---
drivers/gpu/drm/i915/i915_drv.h| 19 +++--
2
From: Dave Airlie
This moves all the cdclk related functions into their own vtable.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 142 ++---
drivers/gpu/drm/i915/i915_drv.h| 8
From: Dave Airlie
This provide a service from irq to display, so make it separate
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 9 -
drivers
From: Dave Airlie
It may make sense to merge this with display again later,
however the fdi use of the vtable is limited to only a
few generations.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fdi.c | 8
From: Dave Airlie
this single function might be possible to merge later, but
for now it's simple to just split it out.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
drivers/gpu/drm/i915/di
From: Dave Airlie
Put the vtable into ro memory.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fdi.c | 20
drivers/gpu/drm/i915/i915_drv.h | 2 +-
2 files changed, 17 insertions(+), 5
From: Dave Airlie
Use a macro to avoid mistakes, this type of macro is only used
in a couple of places.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 4 +--
drivers/gpu/drm/i915/i915_drv.h | 2
From: Dave Airlie
This clarifies quite well what functions get used on what platforms
instead of having to decipher the old tree.
v2: fixed IVB mistake (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_color.c | 138
From: Dave Airlie
Move the functions into read-only tables.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_audio.c | 43 ++
drivers/gpu/drm/i915/i915_drv.h| 2 +-
2 files changed, 28
From: Dave Airlie
This is a bit of a twisty one since each platform is slightly
different, so might take some more review care.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 300 ++---
drivers
From: Dave Airlie
Most the dpll vtable into read-only memory.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +--
drivers/gpu/drm/i915/display/intel_dpll.c| 48
drivers/gpu/drm
From: Dave Airlie
Make nice clear tables instead of having things in two places.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 81
drivers/gpu/drm/i915/i915_drv.h | 2 +-
2
From: Dave Airlie
I used a macro to avoid making any really silly mistakes here.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 78 +++--
2 files
From: Dave Airlie
There was some excess comments and an unused vtbl ptr.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu
From: Dave Airlie
Use a nop table for the cases where CxSR doesn't init properly.
v2: use a nop table (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 34 -
drivers/gpu/drm/i915/i915_
On Tue, 14 Sep 2021, Lyude Paul wrote:
> On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote:
>> On Mon, 13 Sep 2021, Vasily Khoruzhick wrote:
>> > Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to
>> > control brightness, apparently needs a
On Tue, 14 Sep 2021, Vasily Khoruzhick wrote:
> On Tue, Sep 14, 2021 at 3:31 PM Jani Nikula
> wrote:
>>
>> On Tue, 14 Sep 2021, Lyude Paul wrote:
>> > On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote:
>> >> On Mon, 13 Sep 2021, Vasily Khoruzhick w
| 5 +
> drivers/gpu/drm/i915/intel_runtime_pm.c | 20 +---
For the i915 parts,
Acked-by: Jani Nikula
for merging via whichever tree suits you best.
> include/linux/stackdepot.h | 3 +++
> lib/stackdepot.c|
On Mon, 13 Sep 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Suck the "do we need bigjoiner?" checks into a helper instead of
> duplicating them in two differentt places.
Could've called it intel_dp_need_bigjoiner() but meh.
Reviewed-by: Jani Nikula
>
On Mon, 13 Sep 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> hsw_crtc_compute_clock() has become spaghetti. Flatten
> it a bit to make it at least semi-legible.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/d
e the PCH transcoder related stuff already has a
> _pch_ in their name. So shouldn't be possible to confuse them.
Wondering about flipping the names to intel_transcoder_enable and
intel_transcoder_disable, with a potential move to a separate file.
Reviewed-by: Jani Nikula
>
>
On Mon, 13 Sep 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pass the crtc+cpu_transcoder rather than the crtc state to
> intel_dsc_power_domain(). This should allow us to reuse it
> during readout as well.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Ville Syrjälä
On Mon, 13 Sep 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Extract the "panel transcoder" bitmask into a helper. We'll
> have a couple of uses for this later.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gp
ruct
> intel_atomic_state *state,
> goto claimed;
>
> DRM_DEBUG_KMS("[CRTC:%d:%s] Used as slave for big joiner\n",
> - slave->base.base.id, slave->base.name);
> + slave_crtc->base.base.id, slave_crtc->base.name);
>
> return copy_bigjoiner_crtc_state(slave_crtc_state, new_crtc_state);
>
> claimed:
> DRM_DEBUG_KMS("[CRTC:%d:%s] Slave is enabled as normal CRTC, but "
> "[CRTC:%d:%s] claiming this CRTC for bigjoiner.\n",
> - slave->base.base.id, slave->base.name,
> - master->base.base.id, master->base.name);
> + slave_crtc->base.base.id, slave_crtc->base.name,
> + master_crtc->base.base.id, master_crtc->base.name);
> return -EINVAL;
> }
--
Jani Nikula, Intel Open Source Graphics Center
it.
Please file a bug over at [1], add drm.debug=14 module parameter, and
attach dmesg from boot to hitting the issue.
BR,
Jani.
[1] https://gitlab.freedesktop.org/drm/intel/issues/new
--
Jani Nikula, Intel Open Source Graphics Center
On Wed, 15 Sep 2021, Ville Syrjälä wrote:
> On Wed, Sep 15, 2021 at 01:16:58PM +0300, Jani Nikula wrote:
>> On Mon, 13 Sep 2021, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > PIPECONF becamse TRANSCONF when HSW introduced the EDP transcoder.
>
On Mon, 13 Sep 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the _if_enabled() counterpart to with_intel_display_power().
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
Looks like there's plenty of code that could use this.
> ---
> dr
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index d328bb95c49b..8e6f48d1eb7b 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -133,6 +133,7 @@ enum intel_ppgtt_type {
>
,0 +1,15 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#ifndef __INTEL_PXP_TYPES_H__
> +#define __INTEL_PXP_TYPES_H__
> +
> +struct intel_context;
> +
> +struct intel_pxp {
> + struct intel_context *ce;
> +};
> +
> +#endif /* __INTEL_PXP_TYPES_H__ */
--
Jani Nikula, Intel Open Source Graphics Center
ference other sections. I've always wondered!
You may find this helpful:
https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
t; void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup *lookup);
> void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup
> *lookup);
>
> +#if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) && IS_ENABLED(CONFIG_X86)
> +void drm_privacy_screen_lookup_init(void);
> +void drm_privacy_screen_lookup_exit(void);
> +#else
> static inline void drm_privacy_screen_lookup_init(void)
> {
> }
> static inline void drm_privacy_screen_lookup_exit(void)
> {
> }
> +#endif
>
> #endif
--
Jani Nikula, Intel Open Source Graphics Center
E_DEFER returns.
Looks like the earliest/cleanest point for checking this is in
intel_modeset_init_noirq(), i.e. first display init call. But I admit it
gives me an uneasy feeling to return -EPROBE_DEFER at that stage. The
only -EPROBE_DEFER return we currently have is the vga switcheroo stuff
you see in the
| 1 +
>>> drivers/gpu/drm/drm_atomic_uapi.c | 4 +
>>> drivers/gpu/drm/drm_connector.c | 214 +
>>> drivers/gpu/drm/drm_drv.c | 4 +
>>> drivers/gpu/drm/drm_privacy_screen.c | 468 +++
>>> drivers/gpu/drm/drm_privacy_screen_x86.c | 86
>>> drivers/gpu/drm/i915/display/intel_display.c | 5 +
>>> drivers/gpu/drm/i915/display/intel_dp.c | 10 +
>>> drivers/gpu/drm/i915/i915_pci.c | 12 +
>>> drivers/platform/x86/Kconfig | 2 +
>>> drivers/platform/x86/thinkpad_acpi.c | 131 --
>>> include/drm/drm_connector.h | 56 +++
>>> include/drm/drm_privacy_screen_consumer.h | 65 +++
>>> include/drm/drm_privacy_screen_driver.h | 84
>>> include/drm/drm_privacy_screen_machine.h | 46 ++
>>> 19 files changed, 1175 insertions(+), 42 deletions(-)
>>> create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
>>> create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
>>> create mode 100644 include/drm/drm_privacy_screen_consumer.h
>>> create mode 100644 include/drm/drm_privacy_screen_driver.h
>>> create mode 100644 include/drm/drm_privacy_screen_machine.h
>>>
>>
>
--
Jani Nikula, Intel Open Source Graphics Center
bles or NULL pointers.
>> You'll probably want more info from me: please ask, but I'm slow.
>
> Kernel logs with drm.debug=0xe, with the broken black screen state,
> would probably answer a lot of questions if you could gather it from
> both machines?
And for that, I think it's best to file separate bugs at [1] and attach
the logs there. It helps keep the info in one place. Thanks.
BR,
Jani.
[1] https://gitlab.freedesktop.org/drm/intel/issues/new
>
> Regards,
>
> Tvrtko
--
Jani Nikula, Intel Open Source Graphics Center
right solution is, but it's very
obvious to me that we absolute can't go deleting gmbus adapters from DSI
code.
BR,
Jani.
>
> Cc: Jani Nikula
> Cc: Vandita Kulkarni
> Cc: Cooper Chiou
> Cc: William Tseng
> Signed-off-by: Lee Shawn C
> ---
> drivers/gpu/dr
: This defect has an elevated risk because the
>> source argument is a parameter of the current function.
>> 1326strcpy(c->name, name);
>>
>> Fix any possible overflows by using strncpy(). Zero fill the name buffer to
>> guarantee ASCII string NULL t
On Wed, 15 Sep 2021, Rodrigo Vivi wrote:
> On Wed, Sep 15, 2021 at 04:53:35PM +0300, Jani Nikula wrote:
>> On Fri, 10 Sep 2021, Daniele Ceraolo Spurio
>> wrote:
>> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
>> > b/drivers/gpu/drm/i915/pxp/inte
On Thu, 16 Sep 2021, "Lee, Shawn C" wrote:
> On Thu, 16 Sep 2021, Jani Nikula wrote:
>>On Thu, 16 Sep 2021, Lee Shawn C wrote:
>>> Gmbus driver would setup all Intel i2c GMBuses. But DDC bus may
>>> configured as gpio and reserved for MIPI driver to con
1 +++--
8 files changed, 42 insertions(+), 24 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
nterface
> if LFP display was configured to support MIPI panel.
> v3: fix sparse warning
>
> Cc: Jani Nikula
> Cc: Vandita Kulkarni
> Cc: Cooper Chiou
> Cc: William Tseng
> Signed-off-by: Lee Shawn C
> ---
> drivers/gpu/drm/i915/display/intel_gmbus.c | 18 +++
'drivers/gpu/drm' failed
> make[2]: *** [drivers/gpu/drm] Error 2
> scripts/Makefile.build:540: recipe for target 'drivers/gpu' failed
> make[1]: *** [drivers/gpu] Error 2
> Makefile:1868: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
>
>
--
Jani Nikula, Intel Open Source Graphics Center
y 0-day and
> yamllint and incorporated early review feedback from the dt/dts reviews.
>
> Please take a look,
I'll try to ping folks to get someone to review the i915 parts, but the
general idea of moving common HDCP code from i915 to drm is, I hope
obviously,
Acked-by: Jani Nikula
&
On Thu, 09 Sep 2021, Jani Nikula wrote:
> v3 of https://patchwork.freedesktop.org/series/93800/ with minor tweaks
> and the already merged patches obviously dropped.
>
> Jani Nikula (13):
> drm/dp: add DP 2.0 UHBR link rate and bw code conversions
> drm/dp: use more of the
On Fri, 17 Sep 2021, Matthew Brost wrote:
> On Fri, Sep 17, 2021 at 02:26:48PM -0700, Hugh Dickins wrote:
>> On Thu, 16 Sep 2021, Jani Nikula wrote:
>> > On Thu, 16 Sep 2021, Tvrtko Ursulin wrote:
>> > > On 16/09/2021 05:37, Hugh Dickins wrote:
>> > &
t;> with RSI: 814d408b pointing to sw_fence_dummy_notify().
>> I've been building with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, and that
>> function needs to be 4-byte aligned.
>>
>> v2:
>> (Jani Nikula)
>>- Change BUG_ON to WARN_ON
>
> However in th
On Fri, 17 Sep 2021, Lucas De Marchi wrote:
> On Mon, May 17, 2021 at 02:57:33PM +0300, Jani Nikula wrote:
>>On Mon, 12 Apr 2021, Matthew Auld wrote:
>>> From: Anshuman Gupta
>>>
>>> Sanitize OPROM header, CPD signature and OPROM PCI version.
>&g
esktop.org; Gupta, Anshuman
>>
>> Subject: Re: [Intel-gfx] [PATCH 14/19] drm/i915/oprom: Basic sanitization
>>
>> On Fri, 17 Sep 2021, Lucas De Marchi wrote:
>> > On Mon, May 17, 2021 at 02:57:33PM +0300, Jani Nikula wrote:
>> >>On Mon, 12 Apr 2021,
+ |
> + * | 0 | 31:0 |
> |
> + * +---+---+
> |
> + * |...| | [Embedded `HXG Message`_]
> |
> + * +---+---+
> |
> + * | n | 31:0 |
> |
> *
> +---+---+--+
> */
>
>
> base-commit: 242f4c77b1c8cebfdfa0ad5b40e2e4ae0316e57d
--
Jani Nikula, Intel Open Source Graphics Center
100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -814,6 +814,11 @@ struct lfp_brightness_level {
> u16 reserved;
> } __packed;
>
> +/*
> + * Changing struct bdb_lfp_backlight_data might affect its
> +
On Fri, 17 Sep 2021, Maxime Ripard wrote:
> On Fri, Sep 17, 2021 at 03:54:23PM +0300, Jani Nikula wrote:
>> On Thu, 09 Sep 2021, Jani Nikula wrote:
>> > v3 of https://patchwork.freedesktop.org/series/93800/ with minor tweaks
>> > and the already merged patches obviou
On Fri, 17 Sep 2021, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 03:52:04PM +0300, Jani Nikula wrote:
>> There's a new register pair for 128b/132b mode where you need to set the
>> pixel clock in Hz.
>>
>> v2: Fix UHBR rate check, use intel_dp_is_uhbr() help
data in memory. People are generally well aware of the
consequences of changing the size, and this is the only such mistake I
can recall.
BR,
Jani.
>
>
>>
>> > struct bdb_lfp_backlight_data {
>> > u8 entry_size;
>> > struct lfp_backlight_data_entry data[16];
>>
--
Jani Nikula, Intel Open Source Graphics Center
Prefer i915 over drm pointer.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 1bc33766ed39
On Tue, 21 Sep 2021, Nathan Chancellor wrote:
> On Thu, Sep 09, 2021 at 03:51:55PM +0300, Jani Nikula wrote:
>> DP 2.0 brings some new DPCD addresses for PHY repeaters.
>>
>> Cc: dri-de...@lists.freedesktop.org
>> Reviewed-by: Manasi Navare
>> Signed-off-by: Ja
lease, thank you.
Acked-by: Jani Nikula
BR,
Jani.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
> drivers/gpu/drm/i915/i915_request.c | 4 ++--
> dri
Another round of Dave's series [1], just a rebase and resend now that CI
looks healthier.
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/94459/
Dave Airlie (24):
drm/i915/uncore: split the fw get function into separate vfunc
drm/i915/pm: drop get_fifo_size vfunc.
drm/i915: make up
From: Dave Airlie
constify it while here. drop the put function since it was never
overloaded and always has done the same thing, no point in
indirecting it for show.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_uncore.c | 70
From: Dave Airlie
The i845_update_wm code was always calling the i845 variant,
and the i9xx_update_wm had only a choice between i830 and i9xx
paths, hardly worth the vfunc overhead.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915
From: Dave Airlie
The crtc was never being used here.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 10 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c
v2: fixup warnings in wrong place error.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 187 ---
drivers/gpu/drm/i915/intel_pm.c | 39
drivers/gpu/drm/i915/intel_p
301 - 400 of 17407 matches
Mail list logo
