> bool enable = true;
> @@ -86,7 +85,6 @@ static int mitigations_set(const char *val, const struct
> kernel_param *kp)
> break;
> }
> }
> - kfree(str);
> if (err)
> return err;
>
> --
> 2.31.0
--
Ville Syrjälä
Intel
PA;
@@
F(...) {
<+...
ALLOC@PA(...)
...+>
}
@script:python depends on alloc@
ps << find.PS;
pa << alloc.PA;
@@
coccilib.report.print_report(ps[0], "struct")
coccilib.report.print_report(pa[0], "alloc")
That could of course miss a bunch more if they allocate
via some other function I didn't consider.
--
Ville Syrjälä
Intel
On Thu, Apr 08, 2021 at 06:34:06PM +0200, Takashi Iwai wrote:
> On Thu, 08 Apr 2021 09:51:18 +0200,
> Takashi Iwai wrote:
> >
> > On Wed, 07 Apr 2021 23:28:48 +0200,
> > Ville Syrjälä wrote:
> > >
> > > Oh, could you ask the bug reporter to attach a
On Wed, Apr 07, 2021 at 06:56:15PM +0200, Takashi Iwai wrote:
> On Wed, 07 Apr 2021 18:34:46 +0200,
> Ville Syrjälä wrote:
> >
> > On Fri, Apr 02, 2021 at 10:23:17AM +0200, Takashi Iwai wrote:
> > > intel_dsm_platform_mux_info() tries to parse the ACPI package data
&g
IVER("Connector id: 0x%016llx\n",
> (unsigned long long)connector_id->integer.value);
> DRM_DEBUG_DRIVER(" port id: %s\n",
> --
> 2.26.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
r);
> - drm_connector_update_edid_property(connector, edid);
> return edid;
> }
> EXPORT_SYMBOL(drm_get_edid);
> --
> 2.31.0.291.g576ba9dcdaf-goog
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
, we have intel_print_wm_latency() for debug logging and
> wm_latency_show() for debugfs, and there's a bunch of duplication and
> ugh.
There is all this ancient stuff in review limbo...
https://patchwork.freedesktop.org/series/50802/
--
Ville Syrjälä
Intel
void
> unused-but-set-variable warning */, 1))
In this case you can just switch the code to use
for_each_old_plane_in_state() instead.
>
> /**
> * for_each_oldnew_plane_in_state_reverse - iterate over all planes in an
> atomic
> --
> 2.27.0
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
c 28 48 89 54 24 18 48 89 74 24
> <4>[ 254.194312] RSP: 002b:7ffd9cc2c768 EFLAGS: 0246 ORIG_RAX:
> 0001
> <4>[ 254.194337] RAX: ffda RBX: 0004 RCX:
> 7f07d79691e7
> <4>[ 254.194352] RDX: 0004 RSI: 5
On Mon, Mar 01, 2021 at 07:20:59PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 01, 2021 at 11:59:46AM -0500, Steven Rostedt wrote:
> >
> > On my test box with latest v5.12-rc1, running with all trace events
> > enabled, I consistently trigger this warning.
> >
>
On Fri, Feb 26, 2021 at 09:30:08AM -0800, Randy Dunlap wrote:
> Include PPC_PMAC in the configs that use aty_ld_lcd() and
> aty_st_lcd() implementations so that the PM code may work
> correctly for PPC_PMAC.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Randy Dunlap
> Cc
c01064ab R08: 55d68f44ba60 R09:
> R10: 55d68f44ba60 R11: 0246 R12: 55d68f5e0010
> R13: 000e R14: 0000 R15: 55d68e2275c0
> ---[ end trace d18216ba28a2f0e8 ]---
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
On Thu, Feb 25, 2021 at 04:05:37PM -0800, Randy Dunlap wrote:
> Include PPC_PMAC in the configs that use aty_ld_lcd() and
> aty_st_lcd() implementations so that the PM code may work
> correctly for PPC_PMAC.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Randy Dunlap
> Cc
On Wed, Feb 24, 2021 at 11:59:45AM -0800, Randy Dunlap wrote:
> On 2/22/21 9:44 AM, Ville Syrjälä wrote:
> > On Sun, Feb 21, 2021 at 07:28:53PM -0800, Randy Dunlap wrote:
> >> Fix build errors when these functions are not defined.
> >>
> >> ../drivers/video
}
> +
> +u32 aty_ld_lcd(int index, const struct atyfb_par *par)
> +{
> + return 0;
> +}
> #endif /* defined(CONFIG_PMAC_BACKLIGHT) || defined
> (CONFIG_FB_ATY_GENERIC_LCD) */
>
> #ifdef CONFIG_FB_ATY_GENERIC_LCD
> ____
t;dev is there, could also use dev_dbg et al. in the mean time. They
> handle NULL dev gracefully too if the driver didn't set that.
Last I looked aux->dev was random. Some drivers point it at the
connector vs. some at the the pci/platform device.
--
Ville Syrjälä
Intel
in when passing it as an argument to
intel_get_hpd_pins(), but looks like that's not the case.
I guess we should unify this stuff by either removing both
these typedefs and adjusting intel_hpd_hotplug_enables()
accordingly, or we should use the typedef in intel_get_hpd_pins() as
well.
--
Ville Syrjälä
Intel
On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
> >
> > On 01/02/2021 23:13, Ville Syrjälä wrote:
> > > On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> > >> From: Hans Verkuil
>
On Fri, Feb 05, 2021 at 02:46:44PM +0100, Hans Verkuil wrote:
> On 05/02/2021 14:24, Ville Syrjälä wrote:
> > On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> >> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
> >>>
> >>> On 01/02/2021 23:1
he old
crtc to the state already.
>
> crtc_state->connector_mask &=
> ~drm_connector_mask(conn_state->connector);
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
break;
> +
> + default:
> + ret = -EINVAL;
> + break;
> + }
> +
> + return ret;
> +}
> +
> static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
> {
> if (dp_link_bw == 0 || dp_link_count == 0)
> --
> 2.28.0.681.g6f77f65b4e-goog
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
this message).
>
> Am running current kernel ie 5.11-rc5 (although it also was very very
> noisty in 5.10), Ubuntu mainline kernel builds, Lenovo P52 Thinkpad
> laptop. Could it be due to one of the more recent changes to
> drivers/gpu/drm/drm_vblank.c?
>
> Ideas how to workaround this?
>
> --
> Thanks,
>
> Steve
--
Ville Syrjälä
Intel
On Mon, Jan 25, 2021 at 11:52:18AM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> On Fri, Jan 22, 2021 at 02:15:07PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 21, 2021 at 05:35:33PM +0100, Maxime Ripard wrote:
> > > Some drivers are storing the plane->sta
struct drm_plane_state *new_state =
> drm_atomic_get_new_plane_state(state, plane);
> ...
> }
>
> @ include depends on adds_new_state @
> @@
>
> #include
>
> @ no_include depends on !include && adds_new_state @
> @@
>
> + #include
> #include
>
> Signed-off-by: Maxime Ripard
Looks great.
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel
is:
>
> intel_dp->source_rates[intel_dp->num_source_rates - 1].
>
> No need to do the if ladder here at all. If you like, you can add a
> helper:
>
> int intel_dp_max_source_rate(struct intel_dp *intel_dp)
> {
> return intel_dp->source_rates[intel_dp->num_source_rates - 1];
> }
Using the max source rate isn't super great either. A bit better
than the current mess though.
The correct fix would be to let the driver provide the actually
used link_rate+lane_count to the MST code during atomic_check(),
instead of trying to guess what the driver is going to use.
--
Ville Syrjälä
Intel
<... ...> style here? It's been a while since
I did any serious cocci so I'm getting a bit rusty on the details...
Otherwise looks great
Reviewed-by: Ville Syrjälä
> }
>
> @ adds_old_state @
> identifier plane_atomic_func.func;
> identifier plane, state;
>
iers;
> +
> + ret = drm_universal_plane_init(dev, >plane, heads, _wndw,
> format, nformat,
> +format_modifiers, type, "%s-%d", name,
> index);
> if (ret) {
> kfree(*pwndw);
> *pwndw = NULL;
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
> #define DRM_DEBUG_PRIME(fmt, ...)\
> - __drm_dbg(DRM_UT_PRIME, fmt, ##__VA_ARGS__)
> + __drm_dbg(cDRM_UT_PRIME, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_ATOMIC(fmt, ...) \
> - __drm_dbg(DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
> + __drm_dbg(cDRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_VBL(fmt, ...)
> \
> - __drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__)
> + __drm_dbg(cDRM_UT_VBL, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_LEASE(fmt, ...)\
> - __drm_dbg(DRM_UT_LEASE, fmt, ##__VA_ARGS__)
> + __drm_dbg(cDRM_UT_LEASE, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_DP(fmt, ...)
> \
> - __drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
> + __drm_dbg(cDRM_UT_DP, fmt, ## __VA_ARGS__)
>
>
> #define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) \
> @@ -531,7 +577,7 @@ void __drm_err(const char *format, ...);
> DEFAULT_RATELIMIT_INTERVAL, \
> DEFAULT_RATELIMIT_BURST); \
> if (__ratelimit(&_rs)) \
> - drm_dev_dbg(NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__); \
> + drm_dev_dbg(NULL, cDRM_UT_KMS, fmt, ##__VA_ARGS__); \
> })
>
> /*
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
iel Vetter
> Cc: Pankaj Bharadiya
> Cc: Chris Wilson
> Cc: Wambui Karuga
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_lpe_audio.c |4
> 1 file changed, 4 dele
> \
> - __drm_dbg(DRM_UT_KMS, fmt, ##__VA_ARGS__)
> + __drm_dbg(cDRM_UT_KMS, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_PRIME(fmt, ...)\
> - __drm_dbg(DRM_UT_PRIME, fmt, ##__VA_ARGS__)
> + __drm_dbg(cDRM_UT_PRIME, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_ATOMIC(fmt, ...) \
> - __drm_dbg(DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
> + __drm_dbg(cDRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_VBL(fmt, ...)
> \
> - __drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__)
> + __drm_dbg(cDRM_UT_VBL, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_LEASE(fmt, ...)\
> - __drm_dbg(DRM_UT_LEASE, fmt, ##__VA_ARGS__)
> + __drm_dbg(cDRM_UT_LEASE, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_DP(fmt, ...)
> \
> - __drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
> + __drm_dbg(cDRM_UT_DP, fmt, ## __VA_ARGS__)
>
>
> #define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) \
> @@ -531,7 +577,7 @@ void __drm_err(const char *format, ...);
> DEFAULT_RATELIMIT_INTERVAL, \
> DEFAULT_RATELIMIT_BURST); \
> if (__ratelimit(&_rs)) \
> - drm_dev_dbg(NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__); \
> + drm_dev_dbg(NULL, cDRM_UT_KMS, fmt, ##__VA_ARGS__); \
> })
>
> /*
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
gt; Any update. AFAICS, v5.10-rc3 is still buggy.
> >
>
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
--
Ville Syrjälä
Intel
On Mon, Nov 09, 2020 at 04:40:04PM +, Lee Jones wrote:
> On Mon, 09 Nov 2020, Ville Syrjälä wrote:
>
> > On Mon, Nov 09, 2020 at 04:12:58PM +, Lee Jones wrote:
> > > On Mon, 09 Nov 2020, Ville Syrjälä wrote:
> > >
> > > > On Thu, Nov 05,
On Mon, Nov 09, 2020 at 04:12:58PM +, Lee Jones wrote:
> On Mon, 09 Nov 2020, Ville Syrjälä wrote:
>
> > On Thu, Nov 05, 2020 at 02:45:12PM +, Lee Jones wrote:
> > > The stack is too full.
> > >
> > > Fixes the following W=1 kernel build wa
d_msg_req_encode_decode(struct drm_dp_sideband_msg_req_body *in)
> {
> - struct drm_dp_sideband_msg_req_body out = {0};
> + struct drm_dp_sideband_msg_req_body *out;
How big is it? And why is it that big?
--
Ville Syrjälä
Intel
Hz\n",
> dev_priv->max_dotclk_freq);
>
> intel_runtime_pm_put(_priv->runtime_pm, wakeref);
> - return ret;
> + return 0;
> }
>
> static int i915_ring_freq_table(struct seq_file *m, void *unused)
> --
> 2.6.2
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
On Fri, Oct 23, 2020 at 03:14:20PM +, Simon Ser wrote:
> On Thursday, October 22, 2020 12:14 PM, Ville Syrjälä
> wrote:
>
> > On Wed, Oct 21, 2020 at 08:13:43PM -0700, Randy Dunlap wrote:
> >
> > > Hi,
> > > With linux-next 20201021, when booting
> [0.561087]
>
>
> --
> ~Randy
> Reported-by: Randy Dunlap
> _______
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
On Fri, Oct 09, 2020 at 12:01:39PM +0200, Daniel Vetter wrote:
> On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
> wrote:
> >
> > On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized the
== 3)
> + bar_selection |= BIT(3);
>
> pci_iounmap(pdev, uncore->regs);
> + pci_release_selected_regions(pdev, bar_selection);
> }
>
> void intel_uncore_init_early(struct intel_uncore *uncore,
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
On Wed, Oct 07, 2020 at 09:44:09AM -0700, Rob Clark wrote:
> On Mon, Oct 5, 2020 at 5:15 AM Ville Syrjälä
> wrote:
> >
> > On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote:
> > > On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä
> > > wrote:
> > >
'V') /*
> [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
> #define DRM_FORMAT_YVYU fourcc_code('Y', 'V', 'Y', 'U') /*
> [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote:
> On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä
> wrote:
> >
> > On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote:
> > > On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote:
> > >
On Tue, Sep 29, 2020 at 01:26:09PM +0800, Rong Chen wrote:
>
>
> On 9/25/20 12:42 AM, Ville Syrjälä wrote:
> > On Thu, Sep 24, 2020 at 10:30:49PM +0800, kernel test robot wrote:
> >> Greeting,
> >>
> >> FYI, we noticed the following c
On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote:
> > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wrote:
> > >
> > > On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter wrote:
> > > >
&
s converting the other drivers over to use the
> > per-crtc kwork, and then dropping the 'commit_work` from atomic state.
> > I can add a patch to that, but figured I could postpone that churn
> > until there is some by-in on this whole idea.
>
> i915 has its own commit code, it's not even using the current commit
> helpers (nor the commit_work). Not sure how much other fun there is.
I don't think we want per-crtc threads for this in i915. Seems
to me easier to guarantee atomicity across multiple crtcs if
we just commit them from the same thread.
--
Ville Syrjälä
Intel
lse {
> + expected_mode = DRM_LSPCON_MODE_LS;
> + }
> +
> + if (lspcon_wait_mode(lspcon, expected_mode) == DRM_LSPCON_MODE_PCON)
> + return;
> +
> + if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON))
> + DRM_ERROR("LSPCON resume failed\n");
> + else
> + DRM_DEBUG_KMS("LSPCON resume success\n");
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
> b/drivers/gpu/drm/i915/display/intel_lspcon.h
> index 37cfddf8a9c5..169db35db13e 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.h
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
> @@ -15,8 +15,7 @@ struct intel_digital_port;
> struct intel_encoder;
> struct intel_lspcon;
>
> -bool lspcon_init(struct intel_digital_port *intel_dig_port);
> -void lspcon_resume(struct intel_lspcon *lspcon);
> +void lspcon_resume(struct intel_digital_port *intel_dig_port);
> void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
> void lspcon_write_infoframe(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state,
> --
> 2.17.1
--
Ville Syrjälä
Intel
l cmdline? Bump log_buf_len=
if necessary to capture the full log.
> intel_fbc_choose_crtc(dev_priv, state);
> ret = calc_watermark_data(state);
> if (ret)
> --
> 2.25.4
>
>
> ___________
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
On Tue, Sep 29, 2020 at 01:54:13PM -0400, Lyude Paul wrote:
> On Mon, 2020-09-28 at 16:01 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote:
> > > While I thought I had this correct (since it actually did reject modes
> > > lik
On Mon, Sep 28, 2020 at 08:20:59PM +0300, Jani Nikula wrote:
> On Mon, 28 Sep 2020, Ville Syrjälä wrote:
> > On Mon, Sep 28, 2020 at 07:15:43AM -0700, James Ausmus wrote:
> >> On Mon, Sep 28, 2020 at 04:43:11PM +0300, Jani Nikula wrote:
> >> > On Mon, 28 Sep 2020,
er Lake is JSP, not JSL. At least we have
> > PCH_JSP for Jasper Lake PCH.
>
> JSP == Point (the PCH), JSL == Lake
.PT was " Point", ..P stands just for " PCH" IIRC.
--
Ville Syrjälä
Intel
org/archives/dri-devel/2020-September/280276.html
>
> For more info.
>
> So, let's rewrite this using Ville's advice.
>
> Signed-off-by: Lyude Paul
> Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits
> for mode validation")
> Cc: Ville Syrjä
edid.c | 2 +-
> > net/core/dev.c | 4 ++--
> > 3 files changed, 8 insertions(+), 3 deletions(-)
> >
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
--
Ville Syrjälä
Intel
On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Sam
gt; +
> + /* Google Pixelbook */
> + { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
> };
>
> void intel_init_quirks(struct drm_i915_private *i915)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e4f7f6518945b..cc93bede4fab8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -525,6 +525,7 @@ struct i915_psr {
> #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> #define QUIRK_INCREASE_T12_DELAY (1<<6)
> #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
>
> struct intel_fbdev;
> struct intel_fbc_work;
> --
> 2.28.0.618.gf4bc123cb7-goog
--
Ville Syrjälä
Intel
ownstream_max_dotclock();
if (ds_clock && mode->clock > ds_clock)
return CLOCK_HIGH;
+ a bit more if you want to also deal with the TMDS
clock limits sensibly. That also requires some though
as to which bpc to use. In i915 we assume 8bpc when
calculating the TMDS clock since that's the minimum
DVI/HDMI supports.
--
Ville Syrjälä
Intel
ertions(+), 11 deletions(-)
> > >
> > > --
> > > 2.26.0.106.g9fadedd
> > >
> >
> > ___
> > amd-gfx mailing list
> > amd-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
EST_ULL()
> + ll_temp = div_s64(ll_temp, sum);
> coef[phase][i] = (int)ll_temp;
> }
> }
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
On Wed, Sep 09, 2020 at 02:26:11PM -0400, Lyude Paul wrote:
> On Wed, 2020-09-09 at 21:20 +0300, Ville Syrjälä wrote:
> > On Wed, Sep 09, 2020 at 12:33:09PM -0400, Lyude Paul wrote:
> > > We just added a new helper for DPCD retrieval to drm_dp_helper.c (which
> > >
gt; > > - ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
> > > DP_RECEIVER_CAP_SIZE);
> > > + ret = drm_dp_dpcd_read(mgr->aux, dpcd_offset, mgr->dpcd,
> > > DP_RECEIVER_CAP_SIZE);
> > > if (ret != DP_RECEIVER_CAP_SIZE) {
> > > DRM_DEBUG_KMS("failed to read DPCD\n");
> > > goto out_unlock;
> > > --
> > > 2.25.1
> > >
> > Add Lyude Paul
> >
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
t_by_minor(unsigned index)
>
> mutex_lock(_idr_mutex);
> aux_dev = idr_find(_idr, index);
> - if (!kref_get_unless_zero(_dev->refcount))
> + if (aux_dev && !kref_get_unless_zero(_dev->refcount))
Dejavu
https://lists.freedesktop.org/archives/dri-devel/2019-May/218855.html
https://lists.freedesktop.org/archives/dri-devel/2019-July/226168.html
I guess we just got stuck waiting for confirmation that it reproduces
with the bogus device node trick.
> aux_dev = NULL;
> mutex_unlock(_idr_mutex);
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
On Wed, Sep 02, 2020 at 09:09:11AM +, Simon Ser wrote:
> On Tuesday, September 1, 2020 3:26 PM, Daniel Vetter wrote:
>
> > On Tue, Sep 01, 2020 at 08:57:37AM +, Simon Ser wrote:
> >
> > > On Monday, August 31, 2020 3:48 PM, Ville Syrjälä
> > >
+ if (!mstb)
> + return -EREMOTEIO;
> +
> + if (remote_i2c_read_ok(msgs, num)) {
> + ret = drm_dp_mst_i2c_read(mstb, port, msgs, num);
> + } else if (remote_i2c_write_ok(msgs, num)) {
> + ret = drm_dp_mst_i2c_write(mstb, port, msgs, num);
> + } else {
> + DRM_DEBUG_KMS("Unsupported I2C transaction for MST device\n");
> + ret = -EIO;
> + }
> +
> drm_dp_mst_topology_put_mstb(mstb);
> return ret;
> }
> --
> 2.28.0.rc0.142.g3c755180ce-goog
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
On Fri, Aug 28, 2020 at 09:07:13AM +0800, crj wrote:
> Hi Ville Syrjälä,
>
> 在 2020/8/27 18:57, Ville Syrjälä 写道:
> > On Wed, Aug 26, 2020 at 10:23:28PM +0800, Algea Cao wrote:
> >> CEA 861.3 spec adds colorimetry data block for HDMI.
> >> Parsing the block
On Thu, Aug 27, 2020 at 01:04:54PM +0800, Kai Heng Feng wrote:
> Hi Ville,
>
> > On Aug 27, 2020, at 12:24 AM, Ville Syrjälä
> > wrote:
> >
> > On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
> >> LSPCON only supports 8 bpc for RGB/Y
6,13 @@ int vkms_crtc_init(struct drm_device *dev, struct
> > > drm_crtc *crtc,
> > > return ret;
> > > }
> > >
> > > + ret = drm_mode_crtc_set_gamma_size(crtc, 256);
> > > + if (ret) {
> > > + DRM_ERROR("Failed to set gamma size\n");
> > > + return ret;
> > > + }
> > > + drm_crtc_enable_color_mgmt(crtc, 0, false, 256);
> > > +
> > > drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> > >
> > > spin_lock_init(_out->lock);
> > > --
> > > 2.17.1
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
t; +#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
> +#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
> +#define DRM_EDID_CLRMETRY_ADB_RGB (1 << 4)
> +#define DRM_EDID_CLRMETRY_BT2020_CYCC (1 << 5)
> +#define DRM_EDID_CLRMETRY_BT2020_YCC (1 << 6)
> +#define DRM_EDID_CLRMETRY_BT2020_RGB (1 << 7)
> +#define DRM_EDID_CLRMETRY_DCI_P3 (1 << 15)
> +
> /* ELD Header Block */
> #define DRM_ELD_HEADER_BLOCK_SIZE4
>
> --
> 2.25.1
>
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
TPUT_FORMAT_YCBCR444;
> crtc_state->lspcon_downsampling = true;
> - }
> + } else
> + crtc_state->pipe_bpp = 24;
> }
>
> static bool lspcon_probe(struct intel_lspcon *lspcon)
> --
> 2.17.1
--
Ville Syrjälä
Intel
spin_unlock_irqrestore(>vblank_time_lock, irqflags_vblank);
> spin_unlock_irqrestore(>event_lock, irqflags);
> return false;
> }
>
> drm_update_vblank_count(dev, pipe, true);
>
> - spin_unlock(>vblank_time_lock);
> + spin_unlock_irqrestore(>vblank_time_lock, irqflags_vblank);
>
> wake_up(>queue);
>
> --
> 2.25.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
ead+0x50/0x3a0
> > ? process_one_work+0x370/0x370
> > kthread+0x11b/0x140
> > ? kthread_associate_blkcg+0x90/0x90
> > ret_from_fork+0x22/0x30
> > ---[ end trace 16486ad3c2627482 ]---
> > [ cut here ]
> >
> > Cheers,
> > --
> > Luis
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
On Thu, Jun 18, 2020 at 12:58:33AM +0800, Cyrus Lien wrote:
> On Tue, Jun 9, 2020 at 10:58 PM Ville Syrjälä
> wrote:
>
> > On Tue, Jun 09, 2020 at 03:57:04AM +0800, Cyrus Lien wrote:
> > > According to EDID spec, table 3.26, byte #6 and #8, which said "Minimum
> &
DRM_MODE_REFLECT_X |
> DRM_MODE_REFLECT_Y);
> if (err < 0)
> --
> 2.26.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
vsync <= vmax && vsync >= vmin);
> }
>
> --
> 2.25.1
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
g the latest kernel v4.4.224,
> See
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/?h=v4.4.224
See Documentation/process/stable-kernel-rules.rst on how to request
a stable backport.
--
Ville Syrjälä
Intel
> ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) &&
Whoops. Thanks for the fix. Pushed.
> dev_priv->ipc_enabled)
> latency += 4;
>
> --
> 2.26.2
--
Ville Syrjälä
Intel
izontal refresh rate, for debug output in human readable form. Not
> > -* used in a functional way.
> > -*
> > -* This value is in kHz.
> > -*/
> > - int hsync;
> > -
> > - /**
> > * @picture_aspect_ratio:
> > *
> > * Field for setting the HDMI picture aspect ratio of a mode.
> > --
> > 2.7.4
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel
On Tue, Oct 08, 2019 at 10:40:20AM +0800, sandy.huang wrote:
> Hi ville syrjala,
>
> 在 2019/9/30 下午6:48, Ville Syrjälä 写道:
> > On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
> >> These new format is supported by some rockchip socs:
> >>
> >
On Thu, Oct 03, 2019 at 05:05:28PM +0200, Rafael J. Wysocki wrote:
> On Thursday, October 3, 2019 4:08:28 PM CEST Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Since 4.20-rc1 my PIC machines no longer reboot/shutdown.
> > I bisected this down to commit 45975c7d2
nerally expect that you repgrogram everything
when doing a full modeset since the state was possibly
lost while the crtc was disabled.
> + }
> drm_mode_config_reset(dev);
>
> DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, err);
> --
> 2.22.0
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
On Wed, Aug 28, 2019 at 08:50:51PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 28, 2019 at 01:34:07PM -0400, Dan Streetman wrote:
> > It looks like this patch got lost at some point:
> > https://lore.kernel.org/patchwork/patch/902126/#1138115
> >
> > but it seems to stil
should be...
And IIRC I also posted a few other fixes for hid2hci tool which didn't
get any response from the crowd.
--
Ville Syrjälä
Intel
MODE_REFLECT_X |
> + DRM_MODE_REFLECT_Y);
> +
> drm_plane_enable_fb_damage_clips(plane);
>
> /* success! finalize initialization */
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
@@ static void intel_dp_set_drrs_state(struct
> drm_i915_private *dev_priv,
> return;
> }
>
> - dig_port = dp_to_dig_port(intel_dp);
> - encoder = _port->base;
> -
> if (!intel_crtc) {
> DRM_DEBUG_KMS("DRRS: intel_crtc not initialized\n");
> return;
>
>
--
Ville Syrjälä
Intel
T_MASK) {
> case TRANS_DDI_MODE_SELECT_HDMI:
> pipe_config->has_hdmi_sink = true;
> - intel_dig_port = enc_to_dig_port(>base);
>
> pipe_config->infoframes.enable |=
> intel_hdmi_infoframes_enabled(encoder, pipe_config);
>
>
--
Ville Syrjälä
Intel
ver unlikely) some broken userspace
might start to depend on the ability to create framebuffers
with crap modifiers, which could later break if you change
the way you handle the modifiers. Then you're stuck between
the rock and hard place because you can't break existing
userspace but you still want to change the way modifiers
are handled in the kernel.
Best not give userspace too much rope IMO. Two ways to go about
that:
1) drm_any_plane_has_format() (assumes your .format_mod_supported()
does its job properly)
2) roll your own
--
Ville Syrjälä
Intel
On Mon, Nov 26, 2018 at 02:01:22PM -0800, Paul E. McKenney wrote:
> On Wed, Nov 14, 2018 at 12:20:13PM -0800, Paul E. McKenney wrote:
> > On Tue, Nov 13, 2018 at 07:10:37AM -0800, Paul E. McKenney wrote:
> > > On Tue, Nov 13, 2018 at 03:54:53PM +0200, Ville Syrjälä wrot
On Fri, Mar 01, 2019 at 03:35:35PM -0300, Shayenne Moura wrote:
> Em sex, 1 de mar de 2019 às 12:26, Ville Syrjälä
> escreveu:
> >
> > On Fri, Mar 01, 2019 at 11:55:11AM -0300, Shayenne Moura wrote:
> > > Em qui, 28 de fev de 2019 às 11:03, Ville Syrjälä
> > &g
On Fri, Mar 01, 2019 at 11:55:11AM -0300, Shayenne Moura wrote:
> Em qui, 28 de fev de 2019 às 11:03, Ville Syrjälä
> escreveu:
> >
> > On Thu, Feb 28, 2019 at 11:11:07AM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura wrote:
&
ate_vblank_count(crtc);
> > + u64 frame = vblank->count;
> >
> > /* update frame_start only if a queued vkms_crc_work_handle()
> > * has read the data
> > --
> > 2.17.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
aul
> Cc: Imre Deak
> Cc: Daniel Vetter
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c2399acf17
requires that no one is hanging on to the
kref(s). The lifetime of the references isn't really clear
to me, but I'll take your word that it works.
Reviewed-by: Ville Syrjälä
> + }
> }
> }
> --
> 2.20.1
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
args->size = ALIGN(size, PAGE_SIZE);
> >
> > switch (args->bpp) {
> > case 16:
> > --
> > 2.9.3
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
On Fri, Jan 18, 2019 at 03:34:18PM +0100, Andrzej Hajda wrote:
> +CC: Hans
>
> On 17.01.2019 20:47, Ville Syrjälä wrote:
> > On Fri, Dec 14, 2018 at 01:10:16PM +0100, Christoph Manszewski wrote:
> >> Range setting makes sense for YCbCr and RGB buffers. Current
> >
> };
>
> int drm_plane_create_color_properties(struct drm_plane *plane,
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
ently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Changes since v1:
> * Add some new
ently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Signed-off-by: Lyude Paul
> Cc:
n all SNB machines").
Can you file a bug at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
and attach the full dmesg from the boot with drm.debug=0xe passed to the
kernel cmdline?
--
Ville Syrjälä
Intel
On Thu, Dec 06, 2018 at 08:28:07AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Dec 05, 2018 at 11:39:05PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 03:12:15PM +0100, Greg Kroah-Hartman wrote:
> > > 4.19-stable review patch. If anyone has any objections, please
On Thu, Dec 06, 2018 at 08:28:07AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Dec 05, 2018 at 11:39:05PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 03:12:15PM +0100, Greg Kroah-Hartman wrote:
> > > 4.19-stable review patch. If anyone has any objections, please
1 - 100 of 984 matches
Mail list logo
