[PATCH 1/2] drm: Pretty print mode flags

2019-06-20 Thread Ville Syrjala
From: Ville Syrjälä Decode the mode flags when printing the modeline so that I no longer have to decode the hex number myself. To do this neatly I made the caller provide a temporary on stack buffer where we can produce the results. I choce 64 bytes as a reasonable size for this. The worst case

[PATCH v2 2/2] drm: Dump mode picture aspect ratio

2019-06-20 Thread Ville Syrjala
From: Ville Syrjälä Currently the logs show nothing about the mode's aspect ratio. Include that information in the normal mode dump. v2: Don't print anything for NONE (Ilia) Cc: Ilia Mirkin Signed-off-by: Ville Syrjälä --- drivers/video/hdmi.c| 3 ++- include/drm/drm_modes.h | 6 --

[PATCH] drm: Dump mode picture aspect ratio

2019-06-20 Thread Ville Syrjala
From: Ville Syrjälä Currently the logs show nothing about the mode's aspect ratio. Include that information in the normal mode dump. Cc: Ilia Mirkin Signed-off-by: Ville Syrjälä --- drivers/video/hdmi.c| 3 ++- include/drm/drm_modes.h | 4 ++-- include/linux/hdmi.h| 3 +++ 3 files

[PATCH 4/5] drm/i915: Do not override mode's aspect ratio with the prop value NONE

2019-06-20 Thread Ville Syrjala
From: Ville Syrjälä HDMI_PICTURE_ASPECT_NONE means "Automatic" so when the user has that selected we should keep whatever aspect ratio the mode already has. Also no point in checking for connector->is_hdmi in the SDVO code since we only attach the property to HDMI connectors. Cc: Ilia Mirkin

[PATCH 5/5] drm/i915: Drop redundant aspec ratio prop value initialization

2019-06-20 Thread Ville Syrjala
From: Ville Syrjälä HDMI_PICTURE_ASPECT_NONE is zero and the connector state is kzalloc()'d so no need to initialize conn_state->picture_aspect_ratio with it. Cc: Ilia Mirkin Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_hdmi.c | 1 -

[PATCH 3/5] drm: WARN on illegal aspect ratio when converting a mode to umode

2019-06-20 Thread Ville Syrjala
From: Ville Syrjälä WARN if the incoming drm_display_mode has an illegal aspect ratio when converting it to a user mode. This should never happen unless the driver made a mistake and put an invalid value into the aspect ratio. Cc: Ilia Mirkin Signed-off-by: Ville Syrjälä ---

[PATCH 2/5] drm: Do not accept garbage mode aspect ratio flags

2019-06-20 Thread Ville Syrjala
From: Ville Syrjälä Don't let userspace feed us any old garbage in the mode aspect ratio flags. Cc: Ilia Mirkin Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_modes.c

[PATCH 1/5] drm: Do not use bitwise OR to set picure_aspect_ratio

2019-06-20 Thread Ville Syrjala
From: Ville Syrjälä enum hdmi_picture_aspect is not a bitmask, so don't use bitwise OR to populate it. Cc: Ilia Mirkin Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c

[PATCH 0/5] drm: Aspect ratio fixes

2019-06-20 Thread Ville Syrjala
From: Ville Syrjälä Ilia pointed out some oddball crap in the i915 aspect ratio handling. While looking at that I noticed a bunch of fail in the core as well. This series aims to fix it all. Cc: Ilia Mirkin Ville Syrjälä (5): drm: Do not use bitwise OR to set picure_aspect_ratio drm: Do

[RFC][PATCH 2/2] drm/i915: Populate PATH prop for every connector

2019-06-13 Thread Ville Syrjala
From: Ville Syrjälä Userspace may want stable identifiers for connectors. Let's try to provide that via the PATH prop. I tried to make these somewhat abstract by using just "port_type:index" type of approach, where we derive the index from the physical instance of that hw block, so it should

[RFC][PATCH 0/2] drm: PATH prop for all connectors?

2019-06-13 Thread Ville Syrjala
From: Ville Syrjälä Here's a possible apporoach for providing userspace with some stable connector identifiers. Combine with the bus name of the GPU and you should have some kind of real physical path description. Unfortunately the ship has sailed for MST connectors because userspace is already

[RFC][PATCH 1/2] drm: Improve PATH prop docs

2019-06-13 Thread Ville Syrjala
From: Ville Syrjälä The PATH blob is already being parsed by userspace for MST connectors so the layout of the blob is now uabi. Let's document what it should look like. Also add a clear note saying non-MST connectors can have a PATH prop too. Cc: Daniel Vetter Cc: Pekka Paalanen Cc: Ilia

[PATCH 2/4] drm: Refuse to create zero width/height cmdline modes

2019-06-07 Thread Ville Syrjala
From: Ville Syrjälä If the user specifies zero width/height cmdline mode i915 will blow up as the fbdev path will bypass the regular fb sanity check that would otherwise have refused to create a framebuffer with zero width/height. The reason I thought to try this is so that I can force a

[PATCH 4/4] drm/i915: Throw away the BIOS fb if has the wrong depth/bpp

2019-06-07 Thread Ville Syrjala
From: Ville Syrjälä Respect the user's choice of depth/bpp for the fbdev framebuffer and throw out the fb we inherited from the BIOS if it doesn't match. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_fbdev.c | 11 +++ 1 file changed, 11 insertions(+) diff --git

[PATCH 1/4] drm/fb-helper: Do not assume drm_mode_create_from_cmdline_mode() can't fail

2019-06-07 Thread Ville Syrjala
From: Ville Syrjälä drm_mode_create_from_cmdline_mode() can return NULL, so the caller should check for that. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_fb_helper.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c

[PATCH 3/4] drm/fb-helper: Set up gamma_lut during restore_fbdev_mode_atomic()

2019-06-07 Thread Ville Syrjala
From: Ville Syrjälä i915 will now refuse to enable a C8 plane unless the gamma_lut is already enabled (to avoid scanning out whatever garbage got left in the hw LUT previously). So in order to make the fbdev code work with C8 we need to program the gamma_lut already during

[PATCH 2/2] drm/edid: Ignore "DFP 1.x" bit for EDID 1.2 and earlier

2019-05-29 Thread Ville Syrjala
From: Ville Syrjälä From VESA EDID implementation guide v1.0: "For EDID version 1 revision 2 or earlier data structures when offset 14h bit 7 is set to one, the value of bits 6-0 are undefined, and therefore cannot be interpreted to mean anything." And since EDID 1.4 redefines that bit let's

[PATCH 1/2] drm/edid: Clean up DRM_EDID_DIGITAL_* flags

2019-05-29 Thread Ville Syrjala
From: Ville Syrjälä Give the "DFP 1.x" bit a proper name, and clean up the rest of the bits defines as well. Cc: Mario Kleiner Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 2 +- include/drm/drm_edid.h | 32 +--- 2 files changed, 18

[PATCH 1/2] drm/dp: Add DP_DPCD_QUIRK_NO_SINK_COUNT

2019-05-28 Thread Ville Syrjala
From: Ville Syrjälä CH7511 eDP->LVDS bridge doesn't seem to set SINK_COUNT properly causing i915 to detect it as disconnected. Add a quirk to ignore SINK_COUNT on these devices. Cc: David S. Cc: Peteris Rudzusiks Tested-by: Peteris Rudzusiks Bugzilla:

[PATCH 2/2] drm/i915: Skip SINK_COUNT read on CH7511

2019-05-28 Thread Ville Syrjala
From: Ville Syrjälä CH7511 doesn't update SINK_COUNT properly so in order to detect the device as connected we have to ignore SINK_COUNT. In order to have access to the quirk list early enough we must move the drm_dp_read_desc() call to happen earlier. We can also skip re-reading this on eDP

[PATCH] drm/sun4i: Eliminate pointless on stack copy of drm_display_info

2019-03-26 Thread Ville Syrjala
From: Ville Syrjälä Just use a pointer to the display_info rather than make a copy on stack. Cc: Maxime Ripard Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c

[PATCH 2/4] drm: Fix tabs vs. spaces

2019-03-26 Thread Ville Syrjala
From: Ville Syrjälä A set of 8 spaces has snuck in. Replace with a tab, and toss in an extra newline while at it. Signed-off-by: Ville Syrjälä --- include/drm/drm_connector.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_connector.h

[PATCH 4/4] drm/uapi: Remove unused DRM_DISPLAY_INFO_LEN

2019-03-26 Thread Ville Syrjala
From: Ville Syrjälä Remove the unused DRM_DISPLAY_INFO_LEN from the uapi headers. I presume the original plan was to expose the display name via getconnector, but looks like that never happened. So we have the define for the length of the string but no string anywhere. A quick scan didn't seem

[PATCH 3/4] drm: Kill drm_display_info.name

2019-03-26 Thread Ville Syrjala
From: Ville Syrjälä drm_display_info.name is only ever set by a few panel drveirs but never actually used anywhere except in i915 debugfs code. Trash it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_debugfs.c| 1 - drivers/gpu/drm/panel/panel-arm-versatile.c

[PATCH 1/4] drm: Nuke unused drm_display_info.pixel_clock

2019-03-26 Thread Ville Syrjala
From: Ville Syrjälä drm_display_info.pixel_clock is unused. Let's get rid of it. Signed-off-by: Ville Syrjälä --- include/drm/drm_connector.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index bb3bd8e1633a..fcdca46e0c24

[PATCH] drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED

2019-03-22 Thread Ville Syrjala
From: Ville Syrjälä Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything. Its counterpart in f86EdidModes.c is properly hooked up but somehow that functionality was lost when it was copied into the kernel. The concensus seems to be that this quirk is a bit misguided anyway so let's

[PATCH 2/2] drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED

2019-02-27 Thread Ville Syrjala
From: Ville Syrjälä Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything. Its counterpart in f86EdidModes.c is properly hooked up but somehow that functionality was lost when it was copied into the kernel. Assuming that another preferred mode didn't sneak in somehow (is that even

[PATCH 1/2] drm/edid: If no preferred mode is found assume the first mode is preferred

2019-02-27 Thread Ville Syrjala
From: Ville Syrjälä Some monitors apparently forget to mark any mode as preferred in the EDID. In this particular case we have a very generic looking ID "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk doesn't seem particularly wise. Also the quirk we have

[PATCH] drm: Nuke drm_calc_{h,v}scale_relaxed()

2019-02-06 Thread Ville Syrjala
From: Ville Syrjälä The fuzzy drm_calc_{h,v}scale_relaxed() helpers are no longer used. Throw them in the bin. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_rect.c | 108 - include/drm/drm_rect.h | 6 --- 2 files changed, 114 deletions(-) diff

[PATCH] drm: Constify drm_color_lut_check()

2019-01-29 Thread Ville Syrjala
From: Ville Syrjälä drm_color_lut_check() doens't modify the passed in blob so let's make it const. Also s/uint32_y/u32/ while at it. Cc: Matt Roper Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_color_mgmt.c | 6 +++--- include/drm/drm_color_mgmt.h | 4 ++-- 2 files changed, 5

[PATCH v2 1/2] drm/dp/mst: Provide defines for ACK vs. NAK reply type

2019-01-22 Thread Ville Syrjala
From: Ville Syrjälä Make the code a bit easier to read by providing symbolic names for the reply_type (ACK vs. NAK). Also clean up some brace stuff while at it. v2: s/DP_REPLY/DP_SIDEBAND_REPLY/ (DK) Fix some checkpatch issues Signed-off-by: Ville Syrjälä Reviewed-by: Dhinakaran Pandiyan

[PATCH v2 2/2] drm/dp/mst: Provide better debugs for NAK replies

2019-01-22 Thread Ville Syrjala
From: Ville Syrjälä Decode the NAK reply fields to make it easier to parse the logs. v2: s/STR/DP_STR/ to avoid conflict with some header stuff (0day) Use drm_dp_mst_req_type_str() more (DK) Signed-off-by: Ville Syrjälä Reviewed-by: Dhinakaran Pandiyan ---

[PATCH 3/3] drm: Add a debug print for drm_modeset_backoff()

2019-01-21 Thread Ville Syrjala
From: Ville Syrjälä Logs can get confusing when some operations are done multiple times due to the ww mutex backoff. Add a debug print into drm_modeset_backoff() so that at least the reason for the odd looking logs will be obvious. Signed-off-by: Ville Syrjälä ---

[PATCH 1/3] drm: Add debug prints for the various object lookup errors

2019-01-21 Thread Ville Syrjala
From: Ville Syrjälä Only some of the drm mode object lookups have a corresponding debug print for the lookup failure. That makes logs a bit hard to parse when you can't see where the bad object ID is being used. Add a bunch more debug prints, and unify their appearance. Signed-off-by: Ville

[PATCH 2/3] drm: Sync errno values for property lookup errors

2019-01-21 Thread Ville Syrjala
From: Ville Syrjälä Use ENOENT consistently for the case where the requested property isn't found, and EINVAL for the case where the object has no properties whatsoever. Currenrly these are handled differently in the atomic and legacy codepaths. Signed-off-by: Ville Syrjälä ---

[PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well

2019-01-08 Thread Ville Syrjala
From: Ville Syrjälä Fill out the AVI infoframe quantization range bits using drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well. This changes the behaviour slightly as drm_hdmi_avi_infoframe_quant_range() will set a non-zero Q bit even when QS==0 iff the Q bit matched the

[PATCH 4/4] drm/edid: Add display_info.rgb_quant_range_selectable

2019-01-08 Thread Ville Syrjala
From: Ville Syrjälä Move the CEA-861 QS bit handling entirely into the edid code. No need to bother the drivers with this. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: amd-...@lists.freedesktop.org Cc: Eric Anholt (supporter:DRM DRIVERS FOR VC4) Signed-off-by:

[PATCH 3/4] drm/radeon: Use drm_hdmi_avi_infoframe_quant_range()

2019-01-08 Thread Ville Syrjala
From: Ville Syrjälä Fill out the AVI infoframe quantization range bits using drm_hdmi_avi_infoframe_quant_range() instead of hand rolling it. This changes the behaviour slightly as drm_hdmi_avi_infoframe_quant_range() will set a non-zero Q bit even when QS==0 iff the Q bit matched the default

[PATCH 1/4] drm/edid: Pass connector to AVI infoframe functions

2019-01-08 Thread Ville Syrjala
From: Ville Syrjälä Make life easier for drivers by simply passing the connector to drm_hdmi_avi_infoframe_from_display_mode() and drm_hdmi_avi_infoframe_quant_range(). That way drivers don't need to worry about is_hdmi2_sink mess. v2: Make is_hdmi2_sink() return true for sil-sii8620 Adapt

[PATCH v3 02/15] drm/i915: Don't try to use the hardware frame counter with i965gm TV output

2018-11-27 Thread Ville Syrjala
From: Ville Syrjälä On i965gm the hardware frame counter does not work when the TV encoder is active. So let's not try to consult the hardware frame counter in that case. Instead we'll fall back to the timestamp based guesstimation method used on gen2. Note that the pipe timings generated by

[PATCH v2 02/15] drm/i915: Don't try to use the hardware frame counter with i965gm TV output

2018-11-27 Thread Ville Syrjala
From: Ville Syrjälä On i965gm the hardware frame counter does not work when the TV encoder is active. So let's not try to consult the hardware frame counter in that case. Instead we'll fall back to the timestamp based guesstimation method used on gen2. Note that the pipe timings generated by

[PATCH v2 01/15] drm/vblank: Allow dynamic per-crtc max_vblank_count

2018-11-27 Thread Ville Syrjala
From: Ville Syrjälä On i965gm we need to adjust max_vblank_count dynamically depending on whether the TV encoder is used or not. To that end add a per-crtc max_vblank_count that takes precedence over its device wide counterpart. The driver can now call drm_crtc_set_max_vblank_count() to

[PATCH 2/2] drm/atomic-helper: WARN if fake_commit->hw_done is not completed as expected

2018-11-22 Thread Ville Syrjala
From: Ville Syrjälä For real commits we WARN if ->hw_done hasn't been completed by the time drm_atomic_helper_commit_cleanup_done() is called. Let's do the same for the fake commit. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic_helper.c | 4 +++- 1 file changed, 3 insertions(+),

[PATCH 1/2] drm/atomic-helper: Complete fake_commit->flip_done potentially earlier

2018-11-22 Thread Ville Syrjala
From: Ville Syrjälä Consider the following scenario: 1. nonblocking enable crtc 2. wait for the event 3. nonblocking disable crtc On i915 this can lead to a spurious -EBUSY from step 3 on account of non-enabled planes getting the fake_commit in step 1 and we don't complete the fake_commit->

[PATCH] drm/atomic: Fix the early return in drm_atomic_set_mode_for_crtc()

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä The early return in drm_atomic_set_mode_for_crtc() isn't quite right. It would mistakenly return and fail to update crtc_state->enable if someone actually tried to set a zeroed mode on a currently disabled crtc. I suppose that should never happen but better safe than sorry.

[PATCH 3/4] drm/edid: Add CTA-861-G modes with VIC >= 193

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä Add a second table to the cea modes with VIC >= 193. Cc: Hans Verkuil Cc: Shashank Sharma Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 151 - 1 file changed, 149 insertions(+), 2 deletions(-) diff --git

[PATCH 1/4] drm/edid: Add CTA-861-G modes with VIC < 128

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä Fill out our list of cea modes with the new stuff from CTA-861-G. We only do the modes with VIC < 128 here. Adding the higher numbered VICs will need some slight code refactoring first. Cc: Hans Verkuil Cc: Shashank Sharma Signed-off-by: Ville Syrjälä ---

[PATCH 2/4] drm/edid: Abstract away cea_edid_modes[]

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä We're going to need two cea mode tables (on for VICs < 128, another one for VICs >= 193). To that end replace the direct edid_cea_modes[] lookups with a function call. And we'll rename the array to edid_cea_modes_0[] to indicathe how it's to be indexed. Cc: Hans Verkuil Cc:

[PATCH 4/4] drm/edid: Throw away the dummy VIC 0 cea mode

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä Now that the cea mode handling is not 100% tied to the single array the dummy VIC 0 mode is pretty much pointles. Throw it out. Cc: Hans Verkuil Cc: Shashank Sharma Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 14 +- 1 file changed, 5

[PATCH 4/4] drm/edid: Add display_info.rgb_quant_range_selectable

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä Move the CEA-861 QS bit handling entirely into the edid code. No need to bother the drivers with this. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: amd-...@lists.freedesktop.org Cc: Eric Anholt (supporter:DRM DRIVERS FOR VC4) Signed-off-by:

[PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä Fill out the AVI infoframe quantization range bits using drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_sdvo.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff

[PATCH 3/4] drm/radeon: Use drm_hdmi_avi_infoframe_quant_range()

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä Fill out the AVI infoframe quantization range bits using drm_hdmi_avi_infoframe_quant_range() instead of hand rolling it. This changes the behaviour slightly as drm_hdmi_avi_infoframe_quant_range() will set a non-zero Q bit even when QS==0 iff the Q bit matched the default

[PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions

2018-11-20 Thread Ville Syrjala
From: Ville Syrjälä Make life easier for drivers by simply passing the connector to drm_hdmi_avi_infoframe_from_display_mode() and drm_hdmi_avi_infoframe_quant_range(). That way drivers don't need to worry about is_hdmi2_sink mess. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing)

[PATCH 14/15] drm/i915/tv: Fix >1024 modes on gen3

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä On gen3 we must disable the TV encoder vertical filter for >1024 pixel wide sources. Once that's done all we can is try to center the image on the screen. Naturally the TV mode vertical resolution must be equal or larger than the user mode vertical resolution or else we'd

[PATCH 15/15] drm/i915/tv: Filter out >1024 wide modes that would need vertical scaling on gen3

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä Since gen3 can't handle >1024 wide sources with vertical scaling let's not advertize such modes in the mode list. Less tempetation to the user to try out things that won't work. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_tv.c | 6 ++ 1 file changed, 6

[PATCH 10/15] drm/i915/tv: Make TV mode autoselection actually useable

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä The current code insists on picking a new TV mode when switching between component and non-component cables. That's super annoying. Let's just keep the current TV mode unless the new cable type actually disagrees with it. Signed-off-by: Ville Syrjälä ---

[PATCH 13/15] drm/i915/tv: Generate better pipe timings for TV encoder

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä To make vblank timestamps work better with the TV encoder let's scale the pipe timings such that the relationship between the TV active and TV blanking periods is mirrored in the corresponding pipe timings. Note that in reality the pipe runs at a faster speed during the TV

[PATCH 12/15] drm/i915/tv: Add 1080p30/50/60 TV modes

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä Add the missing 1080p TV modes. On gen4 all of them work just fine, whereas on gen3 only the 30Hz mode actually works correctly. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_tv.c | 90 +++-- 1 file changed, 86 insertions(+), 4

[PATCH 08/15] drm/i915/tv: Deobfuscate preferred mode selection

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä Rewrite the preferred mode selection to just check whether the TV modes is HD or SD. For SD TV modes we favor 480 line modes, for 720p we prefer 720 line modes, and for 1080i/p we prefer 1080 line modes. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_tv.c | 50

[PATCH 09/15] drm/i915/tv: Use drm_mode_set_name() to name TV modes

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä No point in storing the mode names in the array. drm_mode_set_name() will give us the same names without wasting space for these string constants. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_tv.c | 21 +++-- 1 file changed, 11 insertions(+),

[PATCH 11/15] drm/i915/tv: Nuke reported_modes[]

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä Remove the silly reported_modes[] array. I suppse once upon a time this actually had something to do with modes we reported to userspace. Now it is just the placeholder for the mode we use for load detection. We don't need it even for that, and instead we can just rely on the

[PATCH 07/15] drm/i915/tv: Nuke silly 0 inittialization of xpos/ypos

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä Just assign the margin values directly to xpos/ypos instead of first initializing to zero and then adding the values. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_tv.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 05/15] drm/i915/tv: Store the TV oversampling factor in the TV mode

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä Store the oversampling factor as a number in the TV modes. We shall want to arithmetic with this which is easier if it's a number we can use directly. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_tv.c | 42 ++--- 1 file changed,

[PATCH 04/15] drm/i915/tv: Fix tv mode clocks

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä The oversample clock is always supposed to be either 108 MHz or 148.5 MHz. Make it so. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_tv.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_tv.c

[PATCH 06/15] drm/i915/tv: Use bools where appropriate

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä 'component_only' is a bool. Initialize it like a bool. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_tv.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_tv.c

[PATCH 07/15] drm/i915/tv: Nuke silly 0 initialzation of xpos/ypos

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä Just assign the margin values directly to xpos/ypos instead of first initializing to zero and then adding the values. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_tv.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 03/15] drm/i915/tv: Fix interlaced ysize calculation

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä Fix the calculation of the vertical active period for interlaced TV modes. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_tv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c

[PATCH 00/15] drm/i915: Fix TV encoder support

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä Our TV encoder support isn't in the best shape. This series fixes it up quite a bit. The most important part is fixing the issues resulting from the lack of frame counter on i965gm which causes nasty flip_done timeouts when we attempt to do anything with the TV encoder

[PATCH 02/15] drm/i915: Don't try to use the hardware frame counter with i965gm TV output

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä On i965gm the hardware frame counter does not work when the TV encoder is active. So let's not try to consult the hardware frame counter in that case. Instead we'll fall back to the timestamp based guesstimation method used on gen2. Note that the pipe timings generated by

[PATCH 01/15] drm/vblank: Allow dynamic per-crtc max_vblank_count

2018-11-12 Thread Ville Syrjala
From: Ville Syrjälä On i965gm we need to adjust max_vblank_count dynamically depending on whether the TV encoder is used or not. To that end add a per-crtc max_vblank_count that takes precedence over its device wide counterpart. The driver can now call drm_crtc_set_max_vblank_count() to

[PATCH v2 3/3] drm/atomic: Use explicit old/new state in drm_atomic_plane_check()

2018-11-06 Thread Ville Syrjala
From: Ville Syrjälä Convert drm_atomic_plane_check() over to using explicit old vs. new plane states. Avoids the confusion of "what does plane->state mean again?". v2: Stick to the multi-stage logic in plane_switching_crtc() (Daniel) Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter

[PATCH 3/3] drm/atomic: Use explicit old/new state in drm_atomic_plane_check()

2018-11-01 Thread Ville Syrjala
From: Ville Syrjälä Convert drm_atomic_plane_check() over to using explicit old vs. new plane states. Avoids the confusion of "what does plane->state mean again?". Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c | 90 ++-- 1 file changed, 46

[PATCH 2/3] drm/atomic: Use explicit old/new state in drm_atomic_crtc_check()

2018-11-01 Thread Ville Syrjala
From: Ville Syrjälä Convert drm_atomic_crtc_check() over to using explicit old vs. new crtc states. Avoids the confusion of "what does crtc->state mean again?". Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c | 26 +++--- 1 file changed, 15 insertions(+), 11

[PATCH 1/3] drm/atomic: Use explicit old crtc state in drm_atomic_add_affected_planes()

2018-11-01 Thread Ville Syrjala
From: Ville Syrjälä Replace 'crtc->state' with the explicit old crtc state. Actually it shouldn't matter whether we use the old or the new crtc state here since any plane that has been removed from the crtc since the crtc state was duplicated will have been added to the atomic state already.

[PATCH v4 2/2] drm/i915: Eliminate the horrendous format check code

2018-10-29 Thread Ville Syrjala
From: Ville Syrjälä Replace the messy framebuffer format/modifier validation code with a single call to drm_any_plane_has_format(). The code was extremely annoying to maintain as you had to have a lot of platform checks for different formats. The new code requires zero maintenance. v2: Nuke the

[PATCH v4 1/2] drm: Add drm_any_plane_has_format()

2018-10-29 Thread Ville Syrjala
From: Ville Syrjälä Add a function to check whether there is at least one plane that supports a specific format and modifier combination. Drivers can use this to reject unsupported formats/modifiers in .fb_create(). v2: Accept anyformat if the driver doesn't do planes (Eric)

[PATCH v2 3/3] drm/i915: Clean up early plane debugs

2018-10-03 Thread Ville Syrjala
From: Ville Syrjälä Print the plane hw state readout results in the common format we already use for pipes and encoders. Also print some clearer debug messages when we disable planes during the early phases of state readout/sanitization. v2: Rebase Signed-off-by: Ville Syrjälä ---

[PATCH v2 2/3] drm/i915: Use the correct crtc when sanitizing plane mapping

2018-10-03 Thread Ville Syrjala
From: Ville Syrjälä When we decide that a plane is attached to the wrong pipe we try to turn off said plane. However we are passing around the crtc we think that the plane is supposed to be using rather than the crtc it is currently using. That doesn't work all that well because we may have to

[PATCH v2 1/3] drm/i915: Restore vblank interrupts earlier

2018-10-03 Thread Ville Syrjala
From: Ville Syrjälä Plane sanitation needs vblank interrupts (on account of CxSR disable). So let's restore vblank interrupts earlier. v2: Make it actually build v3: Add comment to explain why we need this (Daniel) Cc: sta...@vger.kernel.org Cc: Dennis Tested-by: Dennis Bugzilla:

[PATCH 2/3] drm/i915: Use the correct crtc when sanitizing plane mapping

2018-10-01 Thread Ville Syrjala
From: Ville Syrjälä When we decide that a plane is attached to the wrong pipe we try to turn off said plane. However we are passing around the crtc we think that the plane is supposed to be using rather than the crtc it is currently using. That doesn't work all that well because we may have to

[PATCH 3/3] drm/i915: Clean up early plane debugs

2018-10-01 Thread Ville Syrjala
From: Ville Syrjälä Print the plane hw state readout results in the common format we already use for pipes and encoders. Also print some clearer debug messages when we disable planes during the early phases of state readout/sanitization. Signed-off-by: Ville Syrjälä ---

[PATCH 1/3] drm/i915: Restore vblank interrupts earlier

2018-10-01 Thread Ville Syrjala
From: Ville Syrjälä Plane sanitation needs vblank interrupts (on account of CxSR disable). So let's restore vblank interrupts earlier. v2: Make it actually build Cc: sta...@vger.kernel.org Cc: Dennis Tested-by: Dennis Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637 Fixes:

[PATCH 2/5] drm/dp/mst: Validate REMOTE_I2C_READ harder

2018-09-28 Thread Ville Syrjala
From: Ville Syrjälä Make sure i2c msgs we're asked to transfer conform to the requirements of REMOTE_I2C_READ. We were only checking that the last message is a read, but we must also check that the preceding messages are all writes. Also check that the length of each message isn't too long.

[PATCH 3/5] drm/dp: Implement I2C_M_STOP for i2c-over-aux

2018-09-28 Thread Ville Syrjala
From: Ville Syrjälä Consult the I2C_M_STOP flag to determine whether to set the MOT bit or not. Makes it possible to send multiple messages in one go with stop+start generated between the messages (as opposed nothing or repstart depending on whether thr address/rw changed). Not sure anyone has

[PATCH 5/5] drm/dp/mst: Provide better debugs for NAK replies

2018-09-28 Thread Ville Syrjala
From: Ville Syrjälä Decode the NAK reply fields to make it easier to parse the logs. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_dp_mst_topology.c | 65 ++- include/drm/drm_dp_helper.h | 1 + 2 files changed, 65 insertions(+), 1 deletion(-)

[PATCH 1/5] drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers

2018-09-28 Thread Ville Syrjala
From: Ville Syrjälä We aren't supposed to force a stop+start between every i2c msg when performing multi message transfers. This should eg. cause the DDC segment address to be reset back to 0 between writing the segment address and reading the actual EDID extension block. To quote the E-DDC

[PATCH 4/5] drm/dp/mst: Provide defines for ACK vs. NAK reply type

2018-09-28 Thread Ville Syrjala
From: Ville Syrjälä Make the code a bit easier to read by providing symbolic names for the reply_type (ACK vs. NAK). Also clean up some brace stuff while at it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_dp_mst_topology.c | 26 +- include/drm/drm_dp_helper.h

[PATCH v2 07/18] video/hdmi: Handle the NTSC VBI infoframe

2018-09-21 Thread Ville Syrjala
From: Ville Syrjälä Add the code to deal with the NTSC VBI infoframe. I decided against parsing the PES_data_field and just leave it as an opaque blob, just dumping it out as hex in the log. Blindly typed from the spec, and totally untested. v2: Rebase Cc: Thierry Reding Cc: Hans Verkuil

[PATCH v2 06/18] video/hdmi: Handle the MPEG Source infoframe

2018-09-21 Thread Ville Syrjala
From: Ville Syrjälä Add the code to deal with the MPEG source infoframe. Blindly typed from the spec, and totally untested. v2: Rebase Cc: Thierry Reding Cc: Hans Verkuil Cc: linux-me...@vger.kernel.org Signed-off-by: Ville Syrjälä --- drivers/video/hdmi.c | 229

[PATCH v3 04/18] video/hdmi: Constify infoframe passed to the pack functions

2018-09-21 Thread Ville Syrjala
From: Ville Syrjälä Let's make the infoframe pack functions usable with a const infoframe structure. This allows us to precompute the infoframe earlier, and still pack it later when we're no longer allowed to modify the structure. So now we end up with a _check()+_pack_only() or _pack()

[PATCH 17/18] drm/i915: Check infoframe state in intel_pipe_config_compare()

2018-09-20 Thread Ville Syrjala
From: Ville Syrjälä Check the infoframes and infoframe enable state when comparing two crtc states. We'll use the infoframe logging functions from video/hdmi.c to show the infoframes as part of the state dump. TODO: Try to better integrate the infoframe dumps with drm state dumps v2:

[PATCH 18/18] drm/i915: Include infoframes in the crtc state dump

2018-09-20 Thread Ville Syrjala
From: Ville Syrjälä Dump out the infoframes in the normal crtc state dump. TODO: Try to better integrate the infoframe dumps with drm state dumps Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 26 ++ 1 file changed, 26 insertions(+)

[PATCH 10/18] drm/i915: Add the missing HDMI gamut metadata packet stuff

2018-09-20 Thread Ville Syrjala
From: Ville Syrjälä We have definitions and low level code for everything except the gamut metadata HDMI packet. Add the missing bits. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 4 +++- drivers/gpu/drm/i915/intel_hdmi.c | 12 2 files changed, 15

[PATCH 15/18] drm/i915/sdvo: Precompute HDMI infoframes

2018-09-20 Thread Ville Syrjala
From: Ville Syrjälä As with regular HDMI encoders, let's precompute the infoframes (actually just AVI infoframe for the time being) with SDVO HDMI encoders. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_sdvo.c | 58 +-- 1 file changed, 43

[PATCH 12/18] drm/i915: Store mask of enabled infoframes in the crtc state

2018-09-20 Thread Ville Syrjala
From: Ville Syrjälä Store the mask of enabled infoframes in the crtc state. We'll start with just the readout for HDMI encoder, and we'll expand this to compute the bitmask in .compute_config() later. SDVO will also follow later. Signed-off-by: Ville Syrjälä ---

[PATCH 14/18] drm/i915: Read out HDMI infoframes

2018-09-20 Thread Ville Syrjala
From: Ville Syrjälä Add code to read the infoframes from the video DIP and unpack them into the crtc state. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c | 17 drivers/gpu/drm/i915/intel_drv.h | 10 ++ drivers/gpu/drm/i915/intel_hdmi.c | 203

[PATCH 16/18] drm/i915/sdvo: Read out HDMI infoframes

2018-09-20 Thread Ville Syrjala
From: Ville Syrjälä Read the HDMI infoframes from the hbuf and unpack them into the crtc state. Well, actually just AVI infoframe for now but let's write the infoframe readout code in a more generic fashion in case we expand this later. Signed-off-by: Ville Syrjälä ---

[PATCH 11/18] drm/i915: Return the mask of enabled infoframes from ->inforame_enabled()

2018-09-20 Thread Ville Syrjala
From: Ville Syrjälä We want to start tracking which infoframes are enabled, so let's replace the boolean flag with a bitmask. We'll abstract the bitmask so that it's not platform dependent. That will allow us to examine the bitmask later in platform independent code. Signed-off-by: Ville

[PATCH 07/18] video/hdmi: Handle the NTSC VBI infoframe

2018-09-20 Thread Ville Syrjala
From: Ville Syrjälä Add the code to deal with the NTSC VBI infoframe. I decided against parsing the PES_data_field and just leave it as an opaque blob, just dumping it out as hex in the log. Blindly typed from the spec, and totally untested. Cc: Thierry Reding Cc: Hans Verkuil Cc:

[PATCH 13/18] drm/i915: Precompute HDMI infoframes

2018-09-20 Thread Ville Syrjala
From: Ville Syrjälä Store the infoframes in the crtc state and precompute them in .compute_config(). While precomputing we'll also fill out the inforames.enable bitmask appropriately. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ddi.c | 1 + drivers/gpu/drm/i915/intel_drv.h

  1   2   3   4   5   6   7   8   9   >