On Wed, Apr 01, 2015 at 07:59:32PM -0700, Chandra Konduru wrote:
> skylake scaler structure definitions. scalers live in crtc_state as
> they are pipe resources. They can be used either as plane scaler or
> panel fitter.
>
> scaler assigned to either plane (for plane scaling) or crtc (for panel
> fitting) is saved in scaler_id in plane_state or crtc_state respectively.
>
> scaler_id is used instead of scaler pointer in plane or crtc state
> to avoid updating scaler pointer everytime a new crtc_state is created.
>
> v2:
> -made single copy of min/max values for scalers (Matt)
>
> v3:
> -updated commentary for scaler_id (me)
>
> Signed-off-by: Chandra Konduru <chandra.konduru@xxxxxxxxx>
It seems like some of the things that were called out in the previous
review cycle still haven't been addressed here. Repeating them below.
> ---
...
> +struct intel_scaler {
> + int id;
> + int in_use;
> + uint32_t mode;
> + uint32_t filter;
As we noted in the last round of review, filter is constant in this
patch series, so we don't need this field for now. We should only add
this field if/when we decide to actually expose the other hardware
filter types.
> +};
> +
> +struct intel_crtc_scaler_state {
> +#define INTEL_MAX_SCALERS 2
> +#define SKL_NUM_SCALERS INTEL_MAX_SCALERS
> + /* scalers available on this crtc */
> + int num_scalers;
This is an unchanging hardware trait, not dynamic state, so we noted
that this should move to the CRTC itself. The goal is to keep the state
structure to things that truly are dynamic (and not trivial to
recalculate from other state).
> + struct intel_scaler scalers[INTEL_MAX_SCALERS];
> +
> + /*
> + * scaler_users: keeps track of users requesting scalers on this crtc.
> + *
> + * If a bit is set, a user is using a scaler.
> + * Here user can be a plane or crtc as defined below:
> + * bits 0-30 - plane (bit position is index from drm_plane_index)
> + * bit 31 - crtc
> + *
> + * Instead of creating a new index to cover planes and crtc, using
> + * existing drm_plane_index for planes which is well less than 31
> + * planes and bit 31 for crtc. This should be fine to cover all
> + * our platforms.
> + *
> + * intel_atomic_setup_scalers will setup available scalers to users
> + * requesting scalers. It will gracefully fail if request exceeds
> + * avilability.
> + */
> +#define SKL_CRTC_INDEX 31
> + unsigned scaler_users;
> +
> + /* scaler used by crtc for panel fitting purpose */
> + int scaler_id;
> +
> + /*
> + * Supported scaling ratio is represented as a range in [min max]
> + * variables. This range covers both up and downscaling
> + * where scaling ratio = (dst * 100)/src.
> + * In above range any value:
> + * < 100 represents downscaling coverage
> + * > 100 represents upscaling coverage
> + * = 100 represents no-scaling (i.e., 1:1)
> + * e.g., a min value = 50 means -> supports upto 50% of original image
> + * a max value = 200 means -> supports upto 200% of original image
> + *
> + * if incoming flip requires scaling in the supported [min max] range
> + * then requested scaling will be performed.
> + */
> + uint32_t min_hsr;
> + uint32_t max_hsr;
> + uint32_t min_vsr;
> + uint32_t max_vsr;
> + uint32_t min_hvsr;
> + uint32_t max_hvsr;
We noted these could be dropped in the last review cycle.
> +
> + uint32_t min_src_w;
> + uint32_t max_src_w;
> + uint32_t min_src_h;
> + uint32_t max_src_h;
> + uint32_t min_dst_w;
> + uint32_t max_dst_w;
> + uint32_t min_dst_h;
> + uint32_t max_dst_h;
And we noted that these should just be #define's.
> +};
> +
> struct intel_crtc_state {
> struct drm_crtc_state base;
>
> @@ -391,6 +479,8 @@ struct intel_crtc_state {
>
> bool dp_encoder_is_mst;
> int pbn;
> +
> + struct intel_crtc_scaler_state scaler_state;
> };
>
> struct intel_pipe_wm {
> --
> 1.7.9.5
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
