On Mon, Jan 23, 2023 at 12:15:04PM +0200, Jani Nikula wrote:
> On Fri, 20 Jan 2023, Ville Syrjälä wrote:
> > On Thu, Jan 19, 2023 at 06:18:58PM +0200, Jani Nikula wrote:
> >> diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c
> >> b/drivers/gpu/drm/i915/disp
me to
> struct intel_panel, and name it fixed_edid. That's what it is, a fixed
> EDID for the panels.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c| 2 +-
> .../gpu/drm/i915/displ
On Thu, Jan 19, 2023 at 06:19:00PM +0200, Jani Nikula wrote:
> Simplify validation and use by converting to drm_edid.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 10 ++-
>
On Thu, Jan 19, 2023 at 06:18:59PM +0200, Jani Nikula wrote:
> Try to use struct drm_edid where possible, even if having to fall back
> to looking into struct edid down low via drm_edid_raw().
>
> v2: Rebase
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Revie
n LVDS init (Ville)
>
> v2: Don't leak opregion fallback EDID (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> .../gpu/drm/i915/display/intel_connector.c| 4 +-
> .../drm/i915/display/intel_display_types.h| 4 +-
> drivers/gpu/dr
logic is not exactly the same, but since it was somewhat heuristic
> to begin with, assume this is close enough.
>
> v2:
> - Simplify to only check HDMI_Video_present bit (Ville)
> - Drop cea_db_raw_size() helper (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
On Wed, Jan 04, 2023 at 12:05:33PM +0200, Jani Nikula wrote:
> Realize that drm_edid_connector_update() and
> _drm_connector_update_edid_property() are now the same thing. Drop the
> latter.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
&g
ting the connector and adding the
>probed modes.
>
> Fortunately, the change is easy, because no driver has actually adopted
> drm_edid_connector_update(). Not even i915, and that's mainly because of
> the problem described above.
>
> Cc: Imre Deak
> Cc: Ville
On Wed, Jan 04, 2023 at 12:05:31PM +0200, Jani Nikula wrote:
> By moving update_display_info() out of _drm_edid_connector_update() we
> make the function purely about adding modes. Rename accordingly.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by
On Wed, Jan 04, 2023 at 12:05:30PM +0200, Jani Nikula wrote:
> The BPC quirks are closer to home in update_display_info().
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 26 +-
>
r another time.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 28 +---
> 1 file changed, 13 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/
On Wed, Jan 04, 2023 at 12:05:28PM +0200, Jani Nikula wrote:
> Now that quirks are stored in display info, we can just look them up
> using the connector instead of having to pass them around.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
>
uirks) from updating display info.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 42 ++---
> include/drm/drm_connector.h | 5 +
> 2 files changed, 26 insertions(+), 21 d
all data blocks regardless of where they're
specified. Anyways, just food for thought in the future.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 39 +++---
> 1 file changed, 36 insertions(+), 3
> is zero". We assume this to hold when skipping the latency fields, and
> ignore non-zero I_Latency_Fields_Present if Latency_Fields_Present is
> zero.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_e
quot;.
>
> - Don't claim latency fields are present if the data block isn't big
> enough to hold them.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 27 +++
> 1
On Wed, Jan 04, 2023 at 12:05:23PM +0200, Jani Nikula wrote:
> Separate the parsing of display info and modes from the CTA
> Y420VDB. This is prerequisite work for overall better separation of the
> two parsing steps.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> -
> add modes. This allows us to drop the intermediate y420_cmdb_map from
> display info, and replace it with a local variable.
>
> This is prerequisite work for overall better separation of the two
> parsing steps (updating display info and adding modes).
>
> Cc: Ville Syrj
On Wed, Jan 04, 2023 at 12:05:21PM +0200, Jani Nikula wrote:
> Rename the local variable to info for consistency.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 8
> 1 file changed, 4 inser
that stuff
correctly, but looks like it'll be much easier to remedy now.
Reviewed-by: Ville Syrjälä
>
> We try to avoid using VICs from the later specs in the AVI infoframes to
> avoid upsetting sinks that conform to earlier specs.
>
> However, it seems reasonable to do th
t;, so err
> on the safe side.
>
> Start parsing them now, convert users in follow-up to have fewer moving
> parts in one go.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_connect
ely scenarios of a) multiple HDMI VSDBs,
> and b) HDMI VSDB 3D modes using VIC indexes that span across multiple
> CTA VDBs, and the combination of the two.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Cool. Takes care of my previously stated concern of
multiple CTA/HDMI
for before the regression either.
>
> Fixes: 537d9ed2f6c1 ("drm/edid: convert add_cea_modes() to use cea db iter")
> Cc: # v6.0+
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 22 ++
> 1 file changed, 10 insertions
ne the
> filtering, to use the proper VIC for aspect ratio handling, and the 0
> VIC for the infoframe video code as needed.
>
> Reported-by: William Tseng
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6153
> References:
> https://lore.kernel.org/r/2022092
On Fri, Jan 13, 2023 at 04:11:48PM +0100, Sam Ravnborg wrote:
> Hi Ville,
> On Wed, Jan 11, 2023 at 06:08:42PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 11, 2023 at 02:01:58PM +0100, Thomas Zimmermann wrote:
> > > Include in source files that need it. Some of DRM's
orted pixel format %p4cc / modifier
> 0x%llx\n",
> + &r->pixel_format, r->modifier[0]);
> + return -EINVAL;
> + }
Like I said this is still wrong for the !modifiers case.
> +
> return 0;
> }
>
> --
> 2.39.0
--
Ville Syrjälä
Intel
"requested Y/RGB source size %dx%d outside limits
> (min: %dx1 max: %dx%d)\n",
> w, h, min_width, max_width, max_height);
> --
> 2.39.0.314.g84b9a713c41-goog
--
Ville Syrjälä
Intel
On Thu, Jan 12, 2023 at 11:07:59AM -0300, Maíra Canal wrote:
> Hi,
>
> On 1/12/23 09:43, Ville Syrjälä wrote:
> > On Mon, Jan 09, 2023 at 07:58:06AM -0300, Maíra Canal wrote:
> >> Now that framebuffer_check() verifies that the format is properly
> >> supported, t
;modifier path.
> /*
>* gen2/3 display engine uses the fence if present,
>* so the tiling mode must match the fb modifier exactly.
> --
> 2.39.0
--
Ville Syrjälä
Intel
diff --git a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> index a8a98c91b13c..866d1bf5530e 100644
> --- a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> +++ b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> --
> 2.39.0
--
Ville Syrjälä
Intel
mann
Reviewed-by: Ville Syrjälä
> ---
> include/drm/drm_fb_helper.h | 5 -
> include/drm/drm_modeset_helper_vtables.h | 6 +-
> 2 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
&
gt; #include
> #include
^ bunch of other unnecessary headers there as well.
Reviewed-by: Ville Syrjälä
>
> -#include
> -
> #include
> #include
> #include
> --
> 2.39.0
--
Ville Syrjälä
Intel
ason.
> >
> > Also, I still haven't found that fake timer machinery, but maybe I just
> > don't know what I'm looking for.
>
> I ... didn't find it either. I'm honestly not sure whether this works for
> intel, or whether we do something silly li
exception.
That was the approach I tried originally but there were a bunch of
problems with various drivers it at the time. Dunno if all of those
got sorted out or not. IIRC the idea floating around for ancient
drivers was to skip the check based on plane->format_default. Looks
like we're already using that approach in the setcrtc ioctl.
--
Ville Syrjälä
Intel
On Tue, Dec 20, 2022 at 02:52:01PM +0200, Jani Nikula wrote:
> On Tue, 20 Dec 2022, Ville Syrjälä wrote:
> > On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
> >> By moving update_display_info() out of _drm_edid_connector_update() we
> >> make the functio
the mode parsing functions.
> Rename accordingly.
>
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 25 -
> 1 file changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/g
On Mon, Nov 28, 2022 at 01:10:58AM -0800, Ceraolo Spurio, Daniele wrote:
>
>
> On 11/25/2022 5:54 AM, Ville Syrjälä wrote:
> > On Thu, Nov 10, 2022 at 04:56:51PM -0800, Daniele Ceraolo Spurio wrote:
> >> The fence is always initialized in huc_init_early, but the cleanup
c.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -718,6 +718,7 @@ int intel_uc_runtime_resume(struct intel_uc *uc)
>
> static const struct intel_uc_ops uc_ops_off = {
> .init_hw = __uc_check_hw,
> + .fini = __uc_fini, /* to clean-up the init_early initialization */
> };
>
> static const struct intel_uc_ops uc_ops_on = {
> --
> 2.37.3
--
Ville Syrjälä
Intel
On Wed, Nov 23, 2022 at 03:09:32PM +0200, Jani Nikula wrote:
> The file uses bool and struct completion, include the relevant headers.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> include/drm/drm_audio_component.h | 3 +++
> 1 file changed, 3 inser
0d0 ("drm/i915: Simplify internal helper function signature")
> Reported-by: Ville Syrjälä
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt
com/
>
> https://gitlab.freedesktop.org/drm/intel/-/issues/7546
>
> > drivers/gpu/drm/i915/gt/selftest_execlists.c:88:
> > flush_scheduled_work();
>
> Removed by commit 7d33fd02dd94 ("drm/i915/selftests: Remove
> flush_scheduled_work() from live_e
On Tue, Nov 15, 2022 at 06:31:31PM +0200, Jani Nikula wrote:
> On Fri, 07 Oct 2022, Ville Syrjälä wrote:
> > On Thu, Oct 06, 2022 at 06:11:37PM +0300, Ville Syrjälä wrote:
> >> On Thu, Oct 06, 2022 at 11:33:14AM +0200, Simon Rettberg wrote:
> >> > Current dual mode a
s
BROKEN so that we can test some more experimental stuff which is
hidden behind BROKEN for normal users.
> + depends on BROKEN # chicken-egg initial enable problem
> depends on DRM
> depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> depends on JUMP_LABEL
> --
> 2.38.1
--
Ville Syrjälä
Intel
On Tue, Nov 08, 2022 at 05:13:37PM -0500, Alex Deucher wrote:
> On Tue, Nov 8, 2022 at 10:54 AM Daniel Vetter wrote:
> >
> > On Mon, Nov 07, 2022 at 09:25:38PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Repost of the stragglers fr
m = &eb->i915->drm;
We've said a firm "no" to drm_device pointers in display code at
least. If we want a local device pointer we always make it a 'i915'.
Otherwise you end up with annoying aliases all over the place.
--
Ville Syrjälä
Intel
iations of RGB
> > >> formats [1].
> > >
> > > Sure, but the driver can convert the format into whatever the hw
> > > wants. A 1x1 color conversion is not going to be problematic ;-)
> >
> > Hi Rob,
> >
> > Hm... that's also a fair point. Just wondering, is there any advantage
> > of having the driver convert the format, other than not having to
> > implement an extra format property?
> >
> > (In case we end up wrapping everything into a prop blob or something)
> >
>
> It keeps the uabi simpler.. for obvious reasons you don't want the
> driver to do cpu color conversion for an arbitrary size plane, which
> is why we go to all the complexity to expose formats and modifiers for
> "real" planes, but we are dealing with a single pixel value here,
> let's not make the uabi more complex than we need to. I'd propose
> making it float32[4] if float weren't a pita for kernel/uabi, but
> u16[4] or u32[4] should be fine, and drivers can translate that easily
> into whatever weird formats their hw wants for solid-fill.
u16[4] fits into a single u64 property value.
That was the plan for the background prop as well:
https://lore.kernel.org/all/20190703125442.gw5...@intel.com/T/
--
Ville Syrjälä
Intel
+-
> include/drm/drm_blend.h | 2 +
> include/drm/drm_plane.h | 28 ++
> 10 files changed, 188 insertions(+), 76 deletions(-)
>
> --
> 2.38.0
--
Ville Syrjälä
Intel
On Mon, Nov 07, 2022 at 04:40:41PM +0100, Stanislaw Gruszka wrote:
> On Mon, Nov 07, 2022 at 05:10:48PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 07, 2022 at 03:45:00PM +0100, Stanislaw Gruszka wrote:
> > > index 8214a0b1ab7f..e3a1243dd2ae 100644
> > > --- a/drivers/gp
to things is a terrible idea.
IMO the correct fix would be to not return some
half-constructed garbage from drm_minor_alloc().
So basically should at least partically revert
commit f96306f9892b ("drm: manage drm_minor cleanup with drmm_")
>
> spin_lock_irqsave(&drm_minor_lock, flags);
> idr_remove(&drm_minors_idr, minor->index);
> --
> 2.25.1
--
Ville Syrjälä
Intel
Yeah, it makes sense
>
> I'd ask for a small cosmetic change then, could you add the assignments
> where they are actually needed instead of at the top of the function?
>
> Something like
>
> if (!connector)
> return 0;
Dunno why you want to keep around dead code like that.
I'd just nuke the bogus null check.
>
> +drm = connector->dev;
> ret = drm_modeset_lock(&drm->mode_config.connection_mutex, ctx);
>
> ...
>
> +vc4_hdmi = connector_to_vc4_hdmi(connector);
> if (!vc4_hdmi_supports_scrambling(vc4_hdmi))
>
> ...
>
> Changing the prototype of vc4_hdmi_supports_scrambling to take a struct
> vc4_hdmi pointer would also help, it's much more convenient.
>
> Maxime
--
Ville Syrjälä
Intel
On Tue, Nov 01, 2022 at 10:29:24PM +, Vivi, Rodrigo wrote:
> On Sat, 2022-10-29 at 02:41 +0300, Ville Syrjälä wrote:
> > On Fri, Oct 28, 2022 at 02:22:33PM -0400, Rodrigo Vivi wrote:
> > > Hi Dave and Daniel,
> > >
> > > Here goes the first c
On Mon, Oct 31, 2022 at 08:20:54PM -0400, Jason Baron wrote:
>
>
> On 10/31/22 6:11 PM, jim.cro...@gmail.com wrote:
> > On Mon, Oct 31, 2022 at 7:07 AM Ville Syrjälä
> > wrote:
> >> On Sun, Oct 30, 2022 at 08:42:52AM -0600, jim.cro...@gmail.com wrote:
> >>
gt; so. Who did it and why? Hardware is thinkpad x220, and this breaks my
> > > scripts :-(.
> >
> > Are you sure you didn't just switch from intel ddx to modesetting ddx?
>
> How do I tell?
You can read through your Xorg log file.
Or you can do something like this:
lsof -p $(pidof X) | grep _drv.so
--
Ville Syrjälä
Intel
-output VGA-1 --mode 1280x1024 --below HDMI-1
>
> Notice the change from HDMI1 to HDMI-1. I believe that's new in 6.1 or
> so. Who did it and why? Hardware is thinkpad x220, and this breaks my
> scripts :-(.
Are you sure you didn't just switch from intel ddx to modesetting ddx?
--
Ville Syrjälä
Intel
On Sun, Oct 30, 2022 at 08:42:52AM -0600, jim.cro...@gmail.com wrote:
> On Thu, Oct 27, 2022 at 2:10 PM Ville Syrjälä
> wrote:
> >
> > On Thu, Oct 27, 2022 at 01:55:39PM -0600, jim.cro...@gmail.com wrote:
> > > On Thu, Oct 27, 2022 at 9:59 AM Ville Syrjälä
> >
we figure out how we actually want to do it.
--
Ville Syrjälä
Intel
pace that breaks without
the alpha formats? That would already be broken on many devices.
--
Ville Syrjälä
Intel
On Thu, Oct 27, 2022 at 01:55:39PM -0600, jim.cro...@gmail.com wrote:
> On Thu, Oct 27, 2022 at 9:59 AM Ville Syrjälä
> wrote:
> >
> > On Thu, Oct 27, 2022 at 09:37:52AM -0600, jim.cro...@gmail.com wrote:
> > > On Thu, Oct 27, 2022 at 9:08 AM Jason Baron wrote:
> &g
On Thu, Oct 27, 2022 at 09:37:52AM -0600, jim.cro...@gmail.com wrote:
> On Thu, Oct 27, 2022 at 9:08 AM Jason Baron wrote:
> >
> >
> >
> > On 10/21/22 05:18, Jani Nikula wrote:
> > > On Thu, 20 Oct 2022, Ville Syrjälä wrote:
> > >> On Sat,
_mutex);
> +
> + if (connector->edid_override)
> + override = drm_edid_duplicate(connector->edid_override->edid);
> +
> + mutex_unlock(&connector->edid_override_mutex);
I was first thinking we'd use connection_mutex or something for this,
bu
RM_DEBUG_KMS.
>
> Rewrite tile debug logging to one line while at it.
>
> v2:
> - Use [CONNECTOR:%d:%s] throughout (Ville)
> - Tile debug logging revamp
> - Pass connector around a bit more
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
&g
On Mon, Oct 24, 2022 at 03:33:42PM +0300, Jani Nikula wrote:
> Conform to device specific logging.
>
> v2: Include [CONNECTOR:%d:%s] (Ville)
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid_load.c | 12
> 1 fi
ms_rmfb
> > igt@kms_scaling_modes
> > igt@kms_sequence
> > igt@kms_setmode
> > igt@kms_sysfs_edid_timing
> > igt@kms_tv_load_detect
> > igt@kms_universal_plane
> > igt@kms_vblank
> > igt@kms_vrr
> > igt@kms_writeback
> >
> > Most of them are skipped on vc4 right now, but I could see that some of
> > them fail already (kms_rmfb, core_hotunplug), so it proves to be useful
> > already.
> >
> > What do you think? Is there some more tests needed, or did I include
> > some tests that shouldn't have been there?
> >
> > Thanks!
> > Maxime
--
Ville Syrjälä
Intel
verride EDID, check for connector forcing in the fallback.
>
> v2: Simply use !connector->force (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +
> 1 file changed, 1
ment that
> patchwork interpreted as a new patch in the series [1], and changed the
> series submitter too.
>
> Sorry about that. It's a known issue that I sometimes forget to work
> around when replying with diffs.
I just permenently stuck a 'my_hdr X-Patchwork-Hint: comment'
into my .muttrc to avoid that.
--
Ville Syrjälä
Intel
commits of V6 on which Dan gave his Reviewed-by.
> >
> > If these are good to apply, I'll rebase and repost the rest separately.
>
> All now queued up, thanks.
This stuff broke i915 debugs. When I first load i915 no debug prints are
produced. If I then go fiddle around in /sys/module/drm/parameters/debug
the debug prints start to suddenly work.
--
Ville Syrjälä
Intel
ling which threads
> will now use instead of relying on kthread_should_stop().
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Ville Syrjälä
> ---
> .../drm/i915/gem/selftests/i915_gem_context.c | 118
> drivers/gpu/drm/i915/gt/selftest_execlists.c | 48 ++--
> drivers/gpu
On Thu, Oct 20, 2022 at 11:57:06AM +0300, Jani Nikula wrote:
> On Wed, 19 Oct 2022, Ville Syrjälä wrote:
> > On Thu, Oct 13, 2022 at 10:24:54PM +0300, Ville Syrjälä wrote:
> >> On Thu, Oct 13, 2022 at 09:41:21PM +0300, Ville Syrjälä wrote:
> >> > On Tue, Oct 11,
pulse width\n");
> + drm_dbg_kms(dev, "Incorrect Detailed timing. Wrong Hsync/Vsync
> pulse width\n");
> return NULL;
> }
>
> @@ -4643,7 +4643,7 @@ static int add_hdmi_mode(struct drm_connector
> *connector, u8 vic)
> struct drm_display_mode *newmode;
>
> if (!drm_valid_hdmi_vic(vic)) {
> - DRM_ERROR("Unknown HDMI VIC: %d\n", vic);
> + drm_err(connector->dev, "Unknown HDMI VIC: %d\n", vic);
Quit a lot of these could also do the full [CONNECTOR:...]
thing it seems.
--
Ville Syrjälä
Intel
DRM_ERROR("Requesting EDID firmware \"%s\" failed
> (err=%d)\n",
> - name, err);
> + drm_err(connector->dev,
> + "Requesting EDID firmware \"%s\" failed
> (err=%d)\n",
> + name, err);
> return ERR_PTR(err);
> }
>
> --
> 2.34.1
--
Ville Syrjälä
Intel
On Tue, Oct 11, 2022 at 04:49:47PM +0300, Jani Nikula wrote:
> The EDID loader is internal to drm, not for drivers.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_crtc_internal.h | 11 +++
> drivers/gpu/drm/drm_ed
On Tue, Oct 11, 2022 at 04:49:45PM +0300, Jani Nikula wrote:
> Follow the usual naming convention by file name.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 10 +-
> drivers/gpu/drm/drm_edid_load.c | 2
_force force;
> +
> /**
> - * @override_edid: has the EDID been overwritten through debugfs for
> - * testing? Do not modify outside of drm_edid_override_set() and
> - * drm_edid_override_reset().
> + * @edid_override: Override EDID set via debugfs.
> + *
> + * Do not modify or access outside of the drm_edid_override_* family of
> + * functions.
>*/
> - bool override_edid;
> + const struct drm_edid *edid_override;
> +
> /** @epoch_counter: used to detect any other changes in connector,
> besides status */
> u64 epoch_counter;
>
> --
> 2.34.1
--
Ville Syrjälä
Intel
be converted to call drm_edid_connector_update().
All the function names around that stuff still make my head spin,
but hopefully it'll clear up eventually when all the cruft has
disappeared.
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Jani Nikula
> ---
> drivers/g
load_firmware(struct drm_connector
> *connector)
> if (*last == '\n')
> *last = '\0';
>
> - edid = edid_load(connector, edidname);
> + drm_edid = edid_load(connector, edidname);
> +
> kfree(fwstr);
>
> - return edid;
> + return drm_edid;
> }
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index dc7467d25cd8..8138613f4e4e 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -388,11 +388,11 @@ int drm_av_sync_delay(struct drm_connector *connector,
> const struct drm_display_mode *mode);
>
> #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
> -struct edid *drm_edid_load_firmware(struct drm_connector *connector);
> +const struct drm_edid *drm_edid_load_firmware(struct drm_connector
> *connector);
> int __drm_set_edid_firmware_path(const char *path);
> int __drm_get_edid_firmware_path(char *buf, size_t bufsize);
> #else
> -static inline struct edid *
> +static inline const struct drm_edid *
> drm_edid_load_firmware(struct drm_connector *connector)
> {
> return ERR_PTR(-ENOENT);
> --
> 2.34.1
--
Ville Syrjälä
Intel
On Tue, Oct 11, 2022 at 04:49:44PM +0300, Jani Nikula wrote:
> Stop passing around something that's readily available in
> connector->name.
>
> Signed-off-by: Jani Nikula
Weird. Did we not have a connector in there at some point or something?
Shrug.
Review
) !=
> drm_edid->size)
> + return false;
I Was consfued about the HF-EEODB crap for a bit but
__drm_edid_block_count() does include that.
So looks sane
Reviewed-by: Ville Syrjälä
> +
> + for (i = 0; i < drm_edid_block_count(drm_edid); i++) {
by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 8baa46dc2537..616c1cdc7507 100644
> ---
On Tue, Oct 11, 2022 at 04:49:39PM +0300, Jani Nikula wrote:
> Add a function to dump the override EDID in debugfs. This hides the
> override EDID management better in drm_edid.c.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_cr
On Tue, Oct 11, 2022 at 04:49:38PM +0300, Jani Nikula wrote:
> It's useful debugging information to know if and when an override EDID
> was set or reset.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 6 ++
> 1
verride EDID, check for connector forcing in the fallback.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/dis
On Thu, Oct 13, 2022 at 10:24:54PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 13, 2022 at 09:41:21PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 11, 2022 at 04:49:35PM +0300, Jani Nikula wrote:
> > > For normal connector detect, there's really no point in trying dual m
On Fri, Oct 14, 2022 at 11:14:43AM +0300, Jani Nikula wrote:
> On Thu, 13 Oct 2022, Ville Syrjälä wrote:
> > On Thu, Oct 13, 2022 at 09:41:21PM +0300, Ville Syrjälä wrote:
> >> On Tue, Oct 11, 2022 at 04:49:35PM +0300, Jani Nikula wrote:
> >> > For normal connector d
On Wed, Oct 19, 2022 at 11:53:26AM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 19, 2022 at 11:54:42AM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 18, 2022 at 07:34:03PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > Com
On Wed, Oct 19, 2022 at 01:35:26PM +0200, Rafael J. Wysocki wrote:
> On Wed, Oct 19, 2022 at 11:02 AM Ville Syrjälä
> wrote:
> >
> > On Tue, Oct 18, 2022 at 07:34:03PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> >
On Tue, Oct 18, 2022 at 12:07:43PM +0200, Jonas Ådahl wrote:
> On Tue, Oct 18, 2022 at 12:58:53PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 18, 2022 at 11:27:19AM +0200, Jonas Ådahl wrote:
> > > On Tue, Oct 18, 2022 at 12:14:09PM +0300, Ville Syrjälä wrote:
> > > >
On Tue, Oct 18, 2022 at 11:27:19AM +0200, Jonas Ådahl wrote:
> On Tue, Oct 18, 2022 at 12:14:09PM +0300, Ville Syrjälä wrote:
> > On Mon, Oct 17, 2022 at 03:31:57PM +, Simon Ser wrote:
> > > This reverts commit 981f09295687f856d5345e19c7084aca481c1395.
> > >
>
truct drm_connector
> *connector)
> mutex_destroy(&connector->mutex);
>
> memset(connector, 0, sizeof(*connector));
> +
> + if (dev->registered)
> + drm_sysfs_hotplug_event(dev);
> }
> EXPORT_SYMBOL(drm_connector_cleanup);
>
> --
> 2.38.0
>
--
Ville Syrjälä
Intel
back_connectors &&
> (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK))
> --
> 2.38.0
>
--
Ville Syrjälä
Intel
On Thu, Oct 13, 2022 at 09:41:21PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 11, 2022 at 04:49:35PM +0300, Jani Nikula wrote:
> > For normal connector detect, there's really no point in trying dual mode
> > detect if the connector is disconnected. We can simplify the de
this will also skip dual mode detect if the
> connector is force connected and a) there's no EDID of any kind, normal
> or override/firmare or b) there's EDID but it does not indicate
> digital. These are corner cases no matter what, and arguably forcing
> should not be limite
lc->s;
> >
> > - xpixpllcm = pixpllcm | ((pixpllcn & BIT(8)) >> 1);
> > + xpixpllcm = pixpllcm | BIT(7);
>
> Thanks for figuring this out. G200SE apparently is special compared to
> the other models. The old MGA docs only list this bit as .
> Really makes me wonder why this is different.
Could measure eg. the vblank interval with and without that bit set
and see what effect it has. Assuming the PLL locks without the bit
of course.
--
Ville Syrjälä
Intel
I wanted to make drm fourcc endianness explicit.
Simply assuming host endianness would end in tears on big endian
as soon as you need to access stuff with two bpps at the same time.
Much better to just switch off those useless byte swappers and
swap by hand when necessary.
--
Ville Syrjälä
Intel
> >> > same ip
> >> > + * version and release.
> >> > + */
> >> > +RUNTIME_INFO(i915)->media.ip.ver =
> >> > +RUNTIME_INFO(i915)->graphics.ip.ver;
> >> &
On Thu, Oct 06, 2022 at 06:11:37PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 06, 2022 at 11:33:14AM +0200, Simon Rettberg wrote:
> > Current dual mode adaptor ("DP++") detection code assumes that all
> > adaptors support i2c sub-addressing for read operations from the
>
On Fri, Oct 07, 2022 at 09:58:31AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 07.10.22 um 09:15 schrieb Ville Syrjälä:
>
> >>
> >> For the absolute size of fbdev memory, I think we should introduce a
> >> module parameter in drm_fb_helper, which an op
On Fri, Oct 07, 2022 at 09:17:50AM +0200, Javier Martinez Canillas wrote:
> On 10/7/22 09:07, Ville Syrjälä wrote:
> > On Thu, Oct 06, 2022 at 10:28:12PM +0200, Javier Martinez Canillas wrote:
> >> On 10/5/22 13:40, Thomas Zimmermann wrote:
> >>> Ren
need
> >> to be reworked as well.
> >
> > That sounds good. In a similar fashion to drm_fbdev_overalloc another,
> > rather hacky
> > but vastly simpler approach, would be to basically allow the drivers to
> > specify the
> > maximum size of fb to support in drm_fbdev_generic_setup. This would just
> > directly
> > set the drm_fb_helper_surface_size::surface_width and surface_height with
> > the end
> > result being that drm_client_framebuffer_create would be called with those
> > values
> > and xres_virtual/yres_virtual would be set to them. Resizing would
> > basically just
> > work then, right? Of course at the cost of possibly large allocation, e.g.
> > 4k fb
> > even when only 800x600 is actually used.
>
> For the absolute size of fbdev memory, I think we should introduce a
> module parameter in drm_fb_helper, which an option to set a default
> value in the kernel config. It would benefit all drivers that use fbdev
> emulation and work how overalloc works.
>
> If no size is given, the current approach would be used.
>
> I don't think resizing would work immediately. There isn't anything in
> the check_var and set_par functions that implements the necessary atomic
> check and commit.
set_par() is the thing tht does the commit.
--
Ville Syrjälä
Intel
e code convention is to drop the curly braces when you
> have a single statement inside the a loop ?
This has two.
>
> Feel free to ignore it though. I particularly don't agree with that
> convention anyways, because I think that makes the code more error
> prone. But still thought
t; * Set the state of the TMDS output buffers in the adaptor. For
> - * type2 this is set via the DP_DUAL_MODE_TMDS_OEN register. As
> - * some type 1 adaptors have problems with registers (see comments
> - * in drm_dp_dual_mode_detect()) we avoid touching the register,
> - * making this function a no-op on type 1 adaptors.
> + * type2 this is set via the DP_DUAL_MODE_TMDS_OEN register.
> + * Type1 adaptors do not support any register writes.
> *
> * Returns:
> * 0 on success, negative error code on failure
> --
> 2.35.1
--
Ville Syrjälä
Intel
301 - 400 of 1528 matches
Mail list logo
