On Tue, Oct 24, 2023 at 01:22:17PM +0300, Imre Deak wrote:
> Add helpers drivers can use to calculate the BW allocation overhead -
> due to SSC, FEC, DSC and data alignment on symbol cycles - and the
> channel coding efficiency - due to the 8b/10b, 128b/132b encoding. On
> 128b/132b links the FEC
On Thu, Aug 24, 2023 at 06:21:20PM +0530, Ankit Nautiyal wrote:
> As per DP v1.4, a DP DSC Sink device shall support 8bpc in DPCD 6Ah.
> Apparently some panels that do support DSC, are not setting the bit for
> 8bpc.
>
> So always assume 8bpc support by DSC decoder, when DSC is claimed to be
>
On Wed, Aug 23, 2023 at 05:24:25PM +0530, Ankit Nautiyal wrote:
> Edid specific BPC constraints are stored in limits->max_bpp. Honor these
> limits while computing the input bpp for DSC.
>
> Signed-off-by: Ankit Nautiyal
Reviewed-by: Stanislav Lisovskiy
That is kind of funny, I can see this
On Thu, Aug 10, 2023 at 06:33:09PM +0530, Ankit Nautiyal wrote:
> Separate out functions for getting maximum and minimum input BPC based
> on platforms, when DSC is used.
>
> v2: Use HAS_DSC macro instead of platform check while getting min input
> bpc. (Stan)
>
> Signed-off-by: Ankit Nautiyal
On Fri, Jul 28, 2023 at 09:41:46AM +0530, Ankit Nautiyal wrote:
> Pull the code to get joiner constraints on maximum compressed bpp into
> separate function.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 54 ++---
> 1 file changed, 30
On Fri, Jul 28, 2023 at 09:41:41AM +0530, Ankit Nautiyal wrote:
> For DSC the min BPC is 8 for ICL+ and so the min pipe_bpp is 24.
> Check this condition for cases where bpc is forced by debugfs flag
> dsc_force_bpc. If the check fails, then WARN and ignore the debugfs
> flag.
>
> For MST case
On Fri, Aug 04, 2023 at 09:42:34AM +0530, Nautiyal, Ankit K wrote:
>
> On 8/2/2023 5:35 PM, Lisovskiy, Stanislav wrote:
> > On Fri, Jul 28, 2023 at 09:41:40AM +0530, Ankit Nautiyal wrote:
> > > Separate out functions for getting maximum and minimum input BPC based
> &g
On Fri, Jul 28, 2023 at 09:41:49AM +0530, Ankit Nautiyal wrote:
> Use checks for src and sink limits before computing compressed bpp for
> eDP.
>
> Signed-off-by: Ankit Nautiyal
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 20 +---
> 1
On Fri, Jul 28, 2023 at 09:41:50AM +0530, Ankit Nautiyal wrote:
> Currently for testing an output format with DSC, we just force the
> output format, without checking if it can be supported.
> This also creates an issue where there is a PCON which might need to
> convert from forced output format
On Fri, Jul 28, 2023 at 09:41:45AM +0530, Ankit Nautiyal wrote:
> Currently we check if the pipe_bpp selected is >= the
> min DSC bpc/bpp requirement. We do not check if it is <= the max DSC
> bpc/bpp requirement.
>
> Add checks for max DSC BPC/BPP constraints while computing the
> pipe_bpp when
On Fri, Jul 28, 2023 at 09:41:44AM +0530, Ankit Nautiyal wrote:
> Refactor code to separate functions for eDP and DP for computing
> pipe_bpp/compressed bpp when DSC is involved.
>
> This will help to optimize the link configuration for DP later.
>
> v2: Fix checkpatch warning.
>
>
On Fri, Jul 28, 2023 at 09:41:43AM +0530, Ankit Nautiyal wrote:
> The helper intel_dp_dsc_compute_bpp gives the maximum
> pipe bpp that is allowed with DSC.
>
> Rename the this to reflect that it returns max pipe bpp supported
> with DSC.
>
> Signed-off-by: Ankit Nautiyal
Reviewed-by:
On Fri, Jul 28, 2023 at 09:41:40AM +0530, Ankit Nautiyal wrote:
> Separate out functions for getting maximum and minimum input BPC based
> on platforms, when DSC is used.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 38 +++--
> 1 file
On Fri, Jul 28, 2023 at 09:41:39AM +0530, Ankit Nautiyal wrote:
> For MST the bpc is hardcoded to 8, and pipe bpp to 24.
> So avoid forcing DSC bpc for MST case.
>
> v2: Warn and ignore the debug flag than to bail out. (Jani)
>
> v3: Fix dbg message to mention forced bpc instead of bpp.
>
> v4:
On Fri, Jul 28, 2023 at 09:41:38AM +0530, Ankit Nautiyal wrote:
> DP DSC Receiver Capabilities are exposed via DPCD 60h-6Fh.
> Fix the DSC RECEIVER CAP SIZE accordingly.
>
> Fixes: ffddc4363c28 ("drm/dp: Add DP DSC DPCD receiver capability size define
> and missing SHIFT")
> Cc: Anusha Srivatsa
On Mon, Jul 24, 2023 at 05:49:11PM +0530, Nautiyal, Ankit K wrote:
> Hi Stan,
>
> Thanks for the reviews ans suggestions. Please my response inline:
>
>
> On 7/20/2023 2:59 PM, Lisovskiy, Stanislav wrote:
> > On Thu, Jul 13, 2023 at 04:03:32PM +0530, Ankit Nautiyal w
On Tue, Jul 25, 2023 at 11:22:52AM +0530, Nautiyal, Ankit K wrote:
>
> On 7/20/2023 2:46 PM, Lisovskiy, Stanislav wrote:
> > On Thu, Jul 13, 2023 at 04:03:33PM +0530, Ankit Nautiyal wrote:
> > > Currently we assume 2 Pixels Per Clock (PPC) while computing
> > > plane
On Thu, Jul 13, 2023 at 04:03:40PM +0530, Ankit Nautiyal wrote:
> To make way for fractional bpp support, avoid left shifting the
> output_bpp by 4 in helper intel_dp_dsc_get_output_bpp.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 10 +++---
>
On Thu, Jul 13, 2023 at 04:03:32PM +0530, Ankit Nautiyal wrote:
> In Bigjoiner check for DSC, bigjoiner interface bits for DP for
> DISPLAY > 13 is 36 (Bspec: 49259).
>
> v2: Corrected Display ver to 13.
>
> v3: Follow convention for conditional statement. (Ville)
>
> v4: Fix check for display
On Thu, Jul 13, 2023 at 04:03:34PM +0530, Ankit Nautiyal wrote:
> As per Bsepc:49259, Bigjoiner BW check puts restriction on the
> compressed bpp for a given CDCLK, pixelclock in cases where
> Bigjoiner + DSC are used.
>
> Currently compressed bpp is computed first, and it is ensured that
> the
On Thu, Jul 13, 2023 at 04:03:33PM +0530, Ankit Nautiyal wrote:
> Currently we assume 2 Pixels Per Clock (PPC) while computing
> plane cdclk and min_cdlck. In cases where DSC single engine
> is used the throughput is 1 PPC.
>
> So account for the above case, while computing cdclk.
>
> v2: Use
On Wed, May 24, 2023 at 03:38:42PM +0300, Ville Syrjälä wrote:
> On Tue, May 23, 2023 at 12:01:34PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 16, 2023 at 02:40:27PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 16, 2023 at 01:43:44PM +0300, Lisovskiy, Stanislav wrote:
&
On Tue, May 16, 2023 at 02:40:27PM +0300, Ville Syrjälä wrote:
> On Tue, May 16, 2023 at 01:43:44PM +0300, Lisovskiy, Stanislav wrote:
> > On Fri, May 12, 2023 at 11:54:16AM +0530, Ankit Nautiyal wrote:
> > > Currently, we take the max lane, rate and pipe bpp, to get the maximu
On Fri, May 12, 2023 at 11:54:16AM +0530, Ankit Nautiyal wrote:
> Currently, we take the max lane, rate and pipe bpp, to get the maximum
> compressed bpp possible. We then set the output bpp to this value.
> This patch provides support to have max bpp, min rate and min lanes,
> that can support
On Mon, May 15, 2023 at 05:44:51PM +0300, Ville Syrjälä wrote:
> On Fri, May 12, 2023 at 11:54:09AM +0530, Ankit Nautiyal wrote:
> > As per Bsepc:49259, Bigjoiner BW check puts restriction on the
> > compressed bpp for a given CDCLK, pixelclock in cases where
> > Bigjoiner + DSC are used.
> >
> >
On Wed, May 03, 2023 at 02:07:04PM +0300, Ville Syrjälä wrote:
> On Wed, May 03, 2023 at 10:36:42AM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 02, 2023 at 05:38:57PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The
On Tue, May 02, 2023 at 05:38:57PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The MST DSC code has a myriad of issues:
> - Platform checks are wrong (MST+DSC is TGL+ only IIRC)
> - Return values of .mode_valid_ctx() are wrong
> - .mode_valid_ctx() assumes bigjoiner might be used, but
On Tue, May 02, 2023 at 05:38:57PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The MST DSC code has a myriad of issues:
> - Platform checks are wrong (MST+DSC is TGL+ only IIRC)
> - Return values of .mode_valid_ctx() are wrong
> - .mode_valid_ctx() assumes bigjoiner might be used, but
On Thu, Nov 10, 2022 at 02:23:53PM -0800, Navare, Manasi wrote:
> On Thu, Nov 03, 2022 at 03:23:00PM +0200, Stanislav Lisovskiy wrote:
> > Fix intel_dp_dsc_compute_config, previously timeslots parameter
> > was used in fact not as a timeslots, but more like a ratio
> > timeslots/64, which of
On Tue, Sep 06, 2022 at 06:43:22PM +0300, Jani Nikula wrote:
> On Tue, 06 Sep 2022, Jani Nikula wrote:
> > On Mon, 05 Sep 2022, Stanislav Lisovskiy
> > wrote:
> >> Adding DP DSC register definitions, we might need for further
> >> DSC implementation, supporting MST and DP branch pass-through
On Sun, Sep 04, 2022 at 03:07:46PM +0300, Govindapillai, Vinod wrote:
> On Thu, 2022-09-01 at 13:11 +0300, Stanislav Lisovskiy wrote:
> > Whenever we are not able to get enough timeslots
> > for required PBN, let's try to allocate those
> > using DSC, just same way as we do for SST.
> >
> > v2:
On Mon, Aug 29, 2022 at 05:43:19PM +0300, Govindapillai, Vinod wrote:
> Hi Stan,
>
> I wonder if it is better if you reorder the 3 and 4 patches in this - move
> this 4/4 before the 3rd
> one and modify the 3rd one accordingly.
Was thiking about that, but decided to first introduce a new
On Thu, Aug 25, 2022 at 07:04:33PM +0300, Govindapillai, Vinod wrote:
> On Thu, 2022-08-25 at 18:17 +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Aug 25, 2022 at 05:58:19PM +0300, Govindapillai, Vinod wrote:
> > > Hi Stan,
> > >
> > > Some comments inline..
&
On Thu, Aug 25, 2022 at 05:58:19PM +0300, Govindapillai, Vinod wrote:
> Hi Stan,
>
> Some comments inline..
>
> On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> > Whenever we are not able to get enough timeslots
> > for required PBN, let's try to allocate those
> > using DSC, just
On Wed, Aug 10, 2022 at 04:02:08PM -0400, Lyude Paul wrote:
> Btw, what's the plan for this? Figured I'd ask since I noticed this on the ML,
> nd I'm now finishing up getting the atomic only MST patches I've been working
> on merged :)
Current plan is that I need to fix this, as current
On Wed, Aug 10, 2022 at 11:25:13AM +0300, Govindapillai, Vinod wrote:
> Hi Stan,
>
> Please find my comments inline
>
>
> On Mon, 2022-04-11 at 19:25 +0300, Stanislav Lisovskiy wrote:
> > Whenever we are not able to get enough timeslots
> > for required PBN, let's try to allocate those
> >
On Thu, Apr 14, 2022 at 08:33:35AM +0200, François Valenduc wrote:
> Le 14/04/22 à 08:31, Lisovskiy, Stanislav a écrit :
> > On Wed, Apr 13, 2022 at 08:12:20PM +0300, Jani Nikula wrote:
> > > On Wed, 13 Apr 2022, François Valenduc wrote:
> > > > Commit 15512021eb
On Wed, Apr 13, 2022 at 08:12:20PM +0300, Jani Nikula wrote:
> On Wed, 13 Apr 2022, François Valenduc wrote:
> > Commit 15512021eb3975a8c2366e3883337e252bb0eee5
> > (15512021eb3975a8c2366e3883337e252bb0eee5) causes a lof of white spots
> > to appears on the right upper corner of all console
On Thu, Mar 17, 2022 at 06:52:28PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 17, 2022 at 06:33:53PM +0200, Stanislav Lisovskiy wrote:
> > Whenever we are not able to get enough timeslots
> > for required PBN, let's try to allocate those
> > using DSC, just same way as we do for SST.
> >
> > Those
On Thu, Dec 09, 2021 at 09:15:24PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> Tile4 in bspec format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Moved Tile4 associating struct for
On Thu, Dec 09, 2021 at 09:15:24PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> Tile4 in bspec format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Moved Tile4 associating struct for
On Thu, Oct 28, 2021 at 02:53:34AM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> TileF(Tile4 in bspec) format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Fixed wrong case condition(Jani Nikula)
On Thu, Oct 21, 2021 at 07:56:23PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> TileF(Tile4 in bspec) format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Fixed wrong case condition(Jani Nikula)
On Thu, Jun 25, 2020 at 10:36:28AM +0200, Maarten Lankhorst wrote:
> Op 23-06-2020 om 20:57 schreef Kunal Joshi:
> > From: Stanislav Lisovskiy
> >
> > Added epoch counter checking to intel_encoder_hotplug
> > in order to be able process all the connector changes,
> > besides connection status.
On Wed, Jun 10, 2020 at 01:09:36PM +0300, Imre Deak wrote:
> On Wed, Jun 10, 2020 at 11:03:04AM +0300, Lisovskiy, Stanislav wrote:
> > On Mon, Jun 08, 2020 at 12:25:21AM +0300, Imre Deak wrote:
> > > During the initial MST probing an MST port's I2C device will be
> > >
On Mon, Jun 08, 2020 at 12:25:21AM +0300, Imre Deak wrote:
> During the initial MST probing an MST port's I2C device will be
> registered using the kdev of the DRM device as a parent. Later after MST
> Connection Status Notifications this I2C device will be re-registered
> with the kdev of the
On Mon, Jun 08, 2020 at 12:25:22AM +0300, Imre Deak wrote:
> Atm, a pending delayed destroy work during module removal will be
> canceled, leaving behind MST ports, mstbs. Fix this by using a dedicated
> workqueue which will be drained of requeued items as well when
> destroying it.
>
On Mon, Jun 08, 2020 at 12:25:20AM +0300, Imre Deak wrote:
> The WARN below triggers during the removal of an MST port. The problem
> is that the parent device's (the connector's kdev) sysfs directory is
> removed recursively when the connector is unregistered (even though the
> I2C device holds a
On Thu, 2020-01-16 at 17:58 -0800, José Roberto de Souza wrote:
> TGL timeouts when disabling MST transcoder and fifo underruns over
> MST
> transcoders are fixed when setting TRANS_DDI_MODE_SELECT to 0(HDMI
> mode) during the disable sequence.
>
> Although BSpec disable sequence don't require
On Thu, 2020-01-16 at 17:58 -0800, José Roberto de Souza wrote:
> This is a eDP function and it will always returns true for non-eDP
> ports.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
On Wed, 2020-01-29 at 15:24 -0800, José Roberto de Souza wrote:
> According to DP specification, DP_SINK_EVENT_NOTIFY is also a
> broadcast message but as this function only handles
> DP_CONNECTION_STATUS_NOTIFY I will only make the static
> analyzer that caught this issue happy by not calling
>
BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> - panel->backlight.max = 0x;
> - else
> - panel->backlight.max = 0xFF;
> + panel->backlight.max =
> intel_dp_aux_calc_max_backlight(connector);
> +
> + if (!panel->backlight.max)
> + return -ENODEV;
Can we just fallback to old way here, instead of failure?
I see previsouly intel_dp_aux_set_pwm_freq was called only
if we had DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP set and it's
failure didn't affect program flow that much. My concern is
that we have quite a lot of different hardware, so bailing
out that way could make our CI life a bit worse.
See intel_dp_aux_enable_backlight:
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
if (intel_dp_aux_set_pwm_freq(connector))
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
>
> panel->backlight.min = 0;
> panel->backlight.level = intel_dp_aux_get_backlight(connector);
Best Regards,
Lisovskiy Stanislav
On Mon, 2019-07-08 at 15:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Allow drivers to call drm_atomic_helper_check_modeset() without
> having the crtc helper funcs specified. i915 doesn't need those
> anymore.
>
> Signed-off-by: Ville Syrjälä
> ---
>
On Thu, 2019-09-05 at 13:01 +0200, Maarten Lankhorst wrote:
> Op 05-09-2019 om 12:37 schreef Stanislav Lisovskiy:
> > This counter will be used by drm_helper_probe_detect caller to
> > determine
> > if something else had changed except connection status,
> > like for example edid. Hardware
On Mon, 2019-07-08 at 15:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We need to insert stuff between the plane and crtc .atomic_check()
> drm_atomic_helper_check_planes() doesn't allow us to do that so
> stop using it and hand roll the loops instead.
>
> Signed-off-by: Ville
On Mon, 2019-07-08 at 15:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> i915 doesn't use the crtc_state->plane_changed flag for anything,
> so setting it is pointless.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 7 ---
> 1 file changed,
On Mon, 2019-07-08 at 15:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Allow drivers to call drm_atomic_helper_check_modeset() without
> having the crtc helper funcs specified. i915 doesn't need those
> anymore.
>
> Signed-off-by: Ville Syrjälä
> ---
>
On Wed, 2019-09-04 at 11:23 +0200, Daniel Vetter wrote:
>
> > Sure this will work, but still we need somehow to be able to
> > determine
> > this "if it's different" state. In your solution we just move that
> > comparison to drm_connector_update_edid_property, which is quite
> > fine
> > for me.
On Tue, 2019-09-03 at 17:49 +0200, Daniel Vetter wrote:
> On Tue, Sep 03, 2019 at 11:49:23AM +0000, Lisovskiy, Stanislav wrote:
> > On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote:
> > >
> > > > > In fact I was wrong - when it worked, it was using exactly
On Tue, 2019-09-03 at 11:49 +, Lisovskiy, Stanislav wrote:
> On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote:
> >
> > > > In fact I was wrong - when it worked, it was using exactly
> > > > those
> > > > patches :). With
On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote:
>
> > > In fact I was wrong - when it worked, it was using exactly those
> > > patches :). With clean drm-tip - it seems to work ocassionally
> > > and it
> > > doesn't update the actual display edid and other stuff, so even
> > > when
> > >
On Mon, 2019-08-19 at 09:05 +, Lisovskiy, Stanislav wrote:
> On Mon, 2019-08-19 at 08:35 +0100, Peres, Martin wrote:
> > On 19/08/2019 10:23, Lisovskiy, Stanislav wrote:
> > > On Wed, 2019-08-07 at 23:07 +0200, Daniel Vetter wrote:
> > > >
> > > >
On Mon, 2019-08-19 at 08:35 +0100, Peres, Martin wrote:
> On 19/08/2019 10:23, Lisovskiy, Stanislav wrote:
> > On Wed, 2019-08-07 at 23:07 +0200, Daniel Vetter wrote:
> > >
> > >
> > > So igt isn't valid userspace (it's just good testcases). Can we
>
On Wed, 2019-08-07 at 23:07 +0200, Daniel Vetter wrote:
> On Wed, Aug 07, 2019 at 07:43:18AM +0000, Lisovskiy, Stanislav wrote:
> > On Tue, 2019-08-06 at 19:43 +0200, Daniel Vetter wrote:
> > > On Tue, Aug 6, 2019 at 4:06 PM Lisovskiy, Stanislav
> > > wrote:
> >
On Tue, 2019-08-06 at 19:43 +0200, Daniel Vetter wrote:
> On Tue, Aug 6, 2019 at 4:06 PM Lisovskiy, Stanislav
> wrote:
> >
> > On Tue, 2019-08-06 at 15:51 +0200, Daniel Vetter wrote:
> > > On Tue, Aug 06, 2019 at 03:55:48PM +0300, Stanislav Lisovskiy
> > >
On Tue, 2019-08-06 at 15:51 +0200, Daniel Vetter wrote:
> On Tue, Aug 06, 2019 at 03:55:48PM +0300, Stanislav Lisovskiy wrote:
> > This series introduce to drm a way to determine if something else
> > except connection_status had changed during probing, which
> > can be used by other drivers as
On Fri, 2019-06-28 at 09:54 +0530, Ramalingam C wrote:
> On 2019-06-28 at 11:24:54 +0300, Stanislav Lisovskiy wrote:
> > Added edid checking to dp and hdmi edid setting functions, which
> > are called from detect hooks. The result currently is propagated
> > to calling layer using
On Thu, 2019-06-27 at 13:29 +0200, Daniel Vetter wrote:
> On Thu, Jun 27, 2019 at 10:00:14AM +0300, Stanislav Lisovskiy wrote:
> > This series introduce to drm a way to determine if something else
> > except connection_status had changed during probing, which
> > can be used by other drivers as
On Mon, 2019-04-15 at 15:36 +0300, Ville Syrjälä wrote:
> On Mon, Apr 15, 2019 at 10:58:47AM +0300, Stanislav Lisovskiy wrote:
> > There was an issue reported from end users, confirmed
> > also locally that when user executes xrandr --output
> > --rotate left/right, the other eDP screen gets
On Mon, 2019-04-15 at 12:40 +0200, Maarten Lankhorst wrote:
> Op 15-04-2019 om 10:00 schreef Stanislav Lisovskiy:
> > There was an issue reported from end users, confirmed
> > also locally that when user executes xrandr --output
> > --rotate left/right, the other eDP screen gets blank after
> >
On Thu, 2019-04-11 at 17:36 +0300, Gwan-gyeong Mun wrote:
> The hotplug detection routine of drm_helper_hpd_irq_event() can
> detect
> changing of status of connector, but it can not detect changing of
> edid.
>
> Following scenario requires detection of changing of edid.
>
> 1) plug display
t drm_connector *connector)
> > > drm_fb_helper_add_one_connector(_priv->fbdev-
> > > > helper,
> > >
> > > connector);
> > >
> > > + list_move(>head, >dev-
> > > > mode_config.connector_list);
> > >
> > > +
> > > drm_connector_register(connector);
> > > }
> > >
> >
> > --
> > Best Regards,
> >
> > Lisovskiy Stanislav
>
>
>
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, 2018-11-29 at 07:37 +, Lisovskiy, Stanislav wrote:
> On Wed, 2018-11-28 at 22:21 +0100, Daniel Vetter wrote:
> >
> > > I tried to read the bug and I have no idea what's going on here.
> > > Userspace
> > > is supposed to shut off outputs that are d
king connectors more
carefully - that fix I've also implemented for Intel DDX and attached
to the bug, however seems that this happens also for Wayland.
>
> For entertainment and other reasons, testing the below diff would be
> interesting.
>
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 4de247ddf05f..e1b66396c83b 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -499,6 +499,8 @@ static void
> intel_dp_register_mst_connector(struct drm_connector *connector)
> drm_fb_helper_add_one_connector(_priv->fbdev-
> >helper,
> connector);
>
> + list_move(>head, >dev-
> >mode_config.connector_list);
> +
> drm_connector_register(connector);
> }
>
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
can this cause some regression for other connector types?
That's why I was checking, that this is a DP connector, so that this
doesn't touch other connector types at least.
> >
> > if (drm_lease_held(file_priv, connector->base.id))
> > {
>
>
ty_pipes to zero and then not setting it back.
> _______
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_mst_branch_device(struct drm_dp_mst_
> mutex_lock(>lock);
> mstb = mgr->mst_primary;
>
> + if (!mstb)
> + goto out;
> +
> for (i = 0; i < lct - 1; i++) {
> int shift = (i % 2) ? 0 : 4;
> int port_num = (rad[i / 2
DRM_FORMAT_YVYU:
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 9600ccfc5b76..54f74a55e3fb 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1266,6 +12
ivers/gpu/drm/i915/intel_hdmi.c
> @@ -2103,11 +2103,16 @@ static const struct drm_encoder_funcs
> intel_hdmi_enc_funcs = {
> static void
> intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct
> drm_connector *connector)
> {
> + struct drm_i915_pr
30 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2103,11 +2103,16 @@ static const struct drm_encoder_funcs
> intel_hdmi_enc_funcs = {
> static void
> intel_hdmi_add_properties(struct intel_hdm
gt; static void
> intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct
> drm_connector *connector)
> {
> + struct drm_i915_private *dev_priv = to_i915(connector->dev);
> +
> intel_attach_force_audio_property(connector);
> intel_attach_broadcast_rgb_property(connector);
> intel_attach_aspect_ratio_property(connector);
> drm_connector_attach_content_type_property(connector);
> connector->state->picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_NONE;
> +
> + if (!HAS_GMCH_DISPLAY(dev_priv))
> + drm_connector_attach_max_bpc_property(connector, 8,
> 12);
> }
>
> /*
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 2018-10-03 at 08:07 +, Alexandru-Cosmin Gheorghe wrote:
> On Wed, Oct 03, 2018 at 06:39:00AM +0000, Lisovskiy, Stanislav wrote:
> > On Tue, 2018-10-02 at 15:28 +, Alexandru-Cosmin Gheorghe wrote:
> > > Hi,
> > >
> > > On Tue, Oct 02, 2018 at 0
'U',
> > 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > +#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U',
> > 'V') /* [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
> >
> > /*
> > * 2 plane RGB + A
> > --
> > 2.17.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, 2018-09-14 at 14:59 +, Alexandru-Cosmin Gheorghe wrote:
> On Fri, Sep 14, 2018 at 02:49:09PM +0000, Lisovskiy, Stanislav wrote:
> > On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote:
> > > Hi,
> > >
> > > > -Original Message-
&g
On Fri, 2018-09-14 at 20:05 +0300, Juha-Pekka Heikkilä wrote:
>
> Lisovskiy, Stanislav kirjoitti 14.9.2018 klo 17.30:
> > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote:
> > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav
> > > wrote:
>
On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote:
> Hi,
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> > Behalf
> > Of Lisovskiy, Stanislav
> > Sent: perjantai 14. syyskuuta 2018 17.31
> >
On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote:
> On Fri, Sep 14, 2018 at 01:36:32PM +0000, Lisovskiy, Stanislav wrote:
> > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote:
> > > Introduced new XYUV scan-in format for framebuffer and
> > > added sup
s changed, 20 insertions(+), 1 deletion(-)
>
Ping. There is an IGT patch which got Reviewed-by Ville.
This one left in order to get XYUV support.
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://
On Thu, 2018-08-30 at 11:15 -0700, Dhinakaran Pandiyan wrote:
> On Thu, 2018-08-30 at 13:57 +0100, Lisovskiy, Stanislav wrote:
> > On Wed, 2018-08-29 at 12:16 -0700, Dhinakaran Pandiyan wrote:
> > >
> > > On Wed, 2018-08-29 at 21:10 +0300, Ville Syrjälä wrote:
> &g
ase DRM_FORMAT_XYUV:
> >
> > That's not the right spot if we want the platform checks to match
> > your
> > choice of skl+.
> >
> > > case DRM_FORMAT_YUYV:
> > > case DRM_FORMAT_UYVY:
> > > case DRM_FORMAT_YVYU:
> > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > > b/drivers/gpu/drm/i915/intel_sprite.c
> > > index c286dda625e4..2ac9471974c2 100644
> > > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > > @@ -1420,6 +1420,7 @@ static bool
> > > skl_plane_format_mod_supported(struct drm_plane *_plane,
> > > case DRM_FORMAT_UYVY:
> > > case DRM_FORMAT_VYUY:
> > > case DRM_FORMAT_NV12:
> > > + case DRM_FORMAT_XYUV:
> > > if (modifier == I915_FORMAT_MOD_Yf_TILED)
> > > return true;
> > > /* fall through */
> > > --
> > > 2.17.0
> > >
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
an */
> >
> > #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U',
> > 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > +#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U',
> > 'V') /* [31:0] X:Y:
ll_init_work(struct work_struct *work)
> {
> struct drm_i915_private *dev_priv =
> @@ -552,7 +634,7 @@ static void i915_hpd_poll_init_work(struct
> work_struct *work)
>* in the middle of disabling polling
> */
>
rame values is done through
> - * drm_hdmi_get_content_type_from_property() and
> - * drm_hdmi_get_itc_bit_from_property().
> + * infoframe values is done through
> drm_hdmi_avi_infoframe_content_type().
> */
All right, thank you very much for spotting, there were so m
m/drm_mode_config.h| 5 ++
> include/uapi/drm/drm_mode.h | 7 ++
> 10 files changed, 174 insertions(+), 6 deletions(-)
>
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
nt drm_mode_create_scaling_mode_property(struct drm_device *dev);
> > +int drm_connector_attach_content_type_property(struct
> > drm_connector *dev);
> > int drm_connector_attach_scaling_mode_property(struct
> > drm_connector *connector,
> >u32
> > scaling_mode_mask);
> > int drm_connector_attach_content_protection_property(
> > struct drm_connector *connector);
> > int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> > +int drm_mode_create_content_type_property(struct drm_device *dev);
> > int drm_mode_create_suggested_offset_properties(struct drm_device
> > *dev);
> >
> > int drm_mode_connector_set_path_property(struct drm_connector
> > *connector,
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 8d89a9c3748d..4e264c4d8a9b 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -350,6 +350,12 @@ drm_load_edid_firmware(struct drm_connector
> > *connector)
> > }
> > #endif
> >
> > +bool
> > +drm_hdmi_get_itc_bit_from_property(unsigned int content_type);
> > +
> > +enum hdmi_content_type
> > +drm_hdmi_get_content_type_from_property(unsigned int
> > content_type);
> > +
> > int
> > drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> > *frame,
> > const struct
> > drm_display_mode *mode,
> > diff --git a/include/drm/drm_mode_config.h
> > b/include/drm/drm_mode_config.h
> > index 33b3a96d66d0..fb45839179dd 100644
> > --- a/include/drm/drm_mode_config.h
> > +++ b/include/drm/drm_mode_config.h
> > @@ -726,6 +726,11 @@ struct drm_mode_config {
> > * HDMI infoframe aspect ratio setting.
> > */
> > struct drm_property *aspect_ratio_property;
> > + /**
> > +* @content_type_property: Optional connector property to
> > control the
> > +* HDMI infoframe content type setting.
> > +*/
> > + struct drm_property *content_type_property;
> > /**
> > * @degamma_lut_property: Optional CRTC property to set
> > the LUT used to
> > * convert the framebuffer's colors to linear gamma.
> > diff --git a/include/uapi/drm/drm_mode.h
> > b/include/uapi/drm/drm_mode.h
> > index 50bcf4214ff9..cad9e09ffaee 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -94,6 +94,13 @@ extern "C" {
> > #define DRM_MODE_PICTURE_ASPECT_4_31
> > #define DRM_MODE_PICTURE_ASPECT_16_9 2
> >
> > +/* Content type options */
> > +#define DRM_MODE_CONTENT_TYPE_NO_DATA 0
> > +#define DRM_MODE_CONTENT_TYPE_GRAPHICS 1
> > +#define DRM_MODE_CONTENT_TYPE_PHOTO2
> > +#define DRM_MODE_CONTENT_TYPE_CINEMA 3
> > +#define DRM_MODE_CONTENT_TYPE_GAME 4
> > +
> > /* Aspect ratio flag bitmask (4 bits 22:19) */
> > #define DRM_MODE_FLAG_PIC_AR_MASK (0x0F<<19)
> > #define DRM_MODE_FLAG_PIC_AR_NONE \
> > --
> > 2.17.0
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, 2018-05-03 at 10:46 +, Lisovskiy, Stanislav wrote:
> On Thu, 2018-05-03 at 13:18 +0300, Jani Nikula wrote:
> > On Wed, 02 May 2018, StanLis <stanislav.lisovs...@intel.com> wrote:
> > > From: Stanislav Lisovskiy <stanislav.lisovs...@intel.com>
ent_type and from
the frame
encoding point of view those are still separate, so there is no
violation:
+ frame->content_type = HDMI_CONTENT_TYPE_GRAPHICS;
+ frame->itc = 0;
So we have a single property setting both at the same time, as
there is
On Wed, 2018-05-02 at 13:08 +0200, Daniel Vetter wrote:
> On Wed, May 02, 2018 at 09:08:11AM +0000, Lisovskiy, Stanislav wrote:
> > On Wed, 2018-05-02 at 10:15 +0200, Daniel Vetter wrote:
> > > >
> > >
> > > On Wed, May 02, 2018 at 08:09:24AM
On Wed, 2018-05-02 at 10:15 +0200, Daniel Vetter wrote:
> >
> On Wed, May 02, 2018 at 08:09:24AM +, Lisovskiy, Stanislav wrote:
> > On Mon, 2018-04-30 at 17:00 +0200, Daniel Vetter wrote:
> > > On Fri, Apr 27, 2018 at 10:40:00PM +0300, Ville Syrjälä wrote:
> >
f we're trying to document the uabi or the internals
> > here.
> > If we are interested in the uabi, then we should document the enum
> > value strings here. If on the other hand we're trying to document
> > the
> > internal details then we should keep the DRM_CONTENT_TYPE_* stuff.
> > Maybe we want both? The raw numbers I think we should just throw
> > out.
> > While they do have some specific meaning in the case (matching the
> > bits
> > in the infoframe), I'm not sure that's important enough to include
> > in
> > the docs. We could add a comment next to the
> > DRM_MODE_CONTENT_TYPE_*
> > definitions.
> >
> > Looks like the content protection prop is documenting the internals
> > only
> > as well. Hmm. Actually it looks like those things are defined in
> > the uapi
> > header. Oh and the scaling mode prop also does that. This is all
> > setting
> > a rather bad example for userspace. Or maybe we've given up on the
> > "the
> > string is the uabi" notion entirely?
>
> Wrt documenting uapi: That should imo also be in there, but I realize
> it
> makes it a bit a mess. The kerneldoc should definitely align with
> other
> property docs to make sure it all looks consistent (i.e. enumeration
> list
> with the same indentation as all the other properties).
>
> I guess it'd be good if we can aim for "the string is the uabi", but
> in
> practice people will hardcode. For cases where this is likely I think
> having the defines in the uapi header is probably better.
> -Daniel
So how should we proceed then? In fact those
definitions(DRM_MODE_CONTENT_TYPE_*) are already in
the uapi header(I've added them in the first patch), done
same way as aspect ratio:
* Picture aspect ratio options */
#define DRM_MODE_PICTURE_ASPECT_NONE0
#define DRM_MODE_PICTURE_ASPECT_4_3 1
#define DRM_MODE_PICTURE_ASPECT_16_92
/* HDMI content type and itc bit bound together for simplicity */
#define DRM_MODE_CONTENT_TYPE_NO_DATA 0
#define DRM_MODE_CONTENT_TYPE_GRAPHICS 4
#define DRM_MODE_CONTENT_TYPE_PHOTO 5
#define DRM_MODE_CONTENT_TYPE_CINEMA6
#define DRM_MODE_CONTENT_TYPE_GAME 7
Should I just throw out numbers from kernel doc for drm_connector.c? Or
may be add the enum string values? The thing is that other properties
documentation seems to be done in different manner, for example
"content protection" documents the defined enum values, while "scaling
mode" documents the strings themself.
So I would be happy to implement it correctly, however just need some
clue or hint here :)
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
1 - 100 of 112 matches
Mail list logo
