| Message ID | 20250219115359.2320992-2-nemesa.garg@intel.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Introduce drm sharpness property | expand |
Hi Nemesa, kernel test robot noticed the following build warnings: [auto build test WARNING on next-20250219] [cannot apply to drm-xe/drm-xe-next drm-exynos/exynos-drm-next linus/master v6.14-rc3 v6.14-rc2 v6.14-rc1 v6.14-rc3] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Nemesa-Garg/drm-Introduce-sharpness-strength-property/20250219-200229 base: next-20250219 patch link: https://lore.kernel.org/r/20250219115359.2320992-2-nemesa.garg%40intel.com patch subject: [PATCH 1/6] drm: Introduce sharpness strength property config: s390-allyesconfig (https://download.01.org/0day-ci/archive/20250220/202502201640.Kv91RrH2-lkp@intel.com/config) compiler: s390-linux-gcc (GCC) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250220/202502201640.Kv91RrH2-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202502201640.Kv91RrH2-lkp@intel.com/ All warnings (new ones prefixed by >>): >> include/drm/drm_crtc.h:321: warning: Incorrect use of kernel-doc format: * @sharpness_strength >> include/drm/drm_crtc.h:398: warning: Function parameter or struct member 'sharpness_strength' not described in 'drm_crtc_state' >> include/drm/drm_crtc.h:1194: warning: Function parameter or struct member 'sharpness_strength_property' not described in 'drm_crtc' >> include/drm/drm_crtc.h:1194: warning: Excess struct member 'sharpness_strength_prop' description in 'drm_crtc' vim +321 include/drm/drm_crtc.h 65 66 /** 67 * struct drm_crtc_state - mutable CRTC state 68 * 69 * Note that the distinction between @enable and @active is rather subtle: 70 * Flipping @active while @enable is set without changing anything else may 71 * never return in a failure from the &drm_mode_config_funcs.atomic_check 72 * callback. Userspace assumes that a DPMS On will always succeed. In other 73 * words: @enable controls resource assignment, @active controls the actual 74 * hardware state. 75 * 76 * The three booleans active_changed, connectors_changed and mode_changed are 77 * intended to indicate whether a full modeset is needed, rather than strictly 78 * describing what has changed in a commit. See also: 79 * drm_atomic_crtc_needs_modeset() 80 */ 81 struct drm_crtc_state { 82 /** @crtc: backpointer to the CRTC */ 83 struct drm_crtc *crtc; 84 85 /** 86 * @enable: Whether the CRTC should be enabled, gates all other state. 87 * This controls reservations of shared resources. Actual hardware state 88 * is controlled by @active. 89 */ 90 bool enable; 91 92 /** 93 * @active: Whether the CRTC is actively displaying (used for DPMS). 94 * Implies that @enable is set. The driver must not release any shared 95 * resources if @active is set to false but @enable still true, because 96 * userspace expects that a DPMS ON always succeeds. 97 * 98 * Hence drivers must not consult @active in their various 99 * &drm_mode_config_funcs.atomic_check callback to reject an atomic 100 * commit. They can consult it to aid in the computation of derived 101 * hardware state, since even in the DPMS OFF state the display hardware 102 * should be as much powered down as when the CRTC is completely 103 * disabled through setting @enable to false. 104 */ 105 bool active; 106 107 /** 108 * @planes_changed: Planes on this crtc are updated. Used by the atomic 109 * helpers and drivers to steer the atomic commit control flow. 110 */ 111 bool planes_changed : 1; 112 113 /** 114 * @mode_changed: @mode or @enable has been changed. Used by the atomic 115 * helpers and drivers to steer the atomic commit control flow. See also 116 * drm_atomic_crtc_needs_modeset(). 117 * 118 * Drivers are supposed to set this for any CRTC state changes that 119 * require a full modeset. They can also reset it to false if e.g. a 120 * @mode change can be done without a full modeset by only changing 121 * scaler settings. 122 */ 123 bool mode_changed : 1; 124 125 /** 126 * @active_changed: @active has been toggled. Used by the atomic 127 * helpers and drivers to steer the atomic commit control flow. See also 128 * drm_atomic_crtc_needs_modeset(). 129 */ 130 bool active_changed : 1; 131 132 /** 133 * @connectors_changed: Connectors to this crtc have been updated, 134 * either in their state or routing. Used by the atomic 135 * helpers and drivers to steer the atomic commit control flow. See also 136 * drm_atomic_crtc_needs_modeset(). 137 * 138 * Drivers are supposed to set this as-needed from their own atomic 139 * check code, e.g. from &drm_encoder_helper_funcs.atomic_check 140 */ 141 bool connectors_changed : 1; 142 /** 143 * @zpos_changed: zpos values of planes on this crtc have been updated. 144 * Used by the atomic helpers and drivers to steer the atomic commit 145 * control flow. 146 */ 147 bool zpos_changed : 1; 148 /** 149 * @color_mgmt_changed: Color management properties have changed 150 * (@gamma_lut, @degamma_lut or @ctm). Used by the atomic helpers and 151 * drivers to steer the atomic commit control flow. 152 */ 153 bool color_mgmt_changed : 1; 154 155 /** 156 * @no_vblank: 157 * 158 * Reflects the ability of a CRTC to send VBLANK events. This state 159 * usually depends on the pipeline configuration. If set to true, DRM 160 * atomic helpers will send out a fake VBLANK event during display 161 * updates after all hardware changes have been committed. This is 162 * implemented in drm_atomic_helper_fake_vblank(). 163 * 164 * One usage is for drivers and/or hardware without support for VBLANK 165 * interrupts. Such drivers typically do not initialize vblanking 166 * (i.e., call drm_vblank_init() with the number of CRTCs). For CRTCs 167 * without initialized vblanking, this field is set to true in 168 * drm_atomic_helper_check_modeset(), and a fake VBLANK event will be 169 * send out on each update of the display pipeline by 170 * drm_atomic_helper_fake_vblank(). 171 * 172 * Another usage is CRTCs feeding a writeback connector operating in 173 * oneshot mode. In this case the fake VBLANK event is only generated 174 * when a job is queued to the writeback connector, and we want the 175 * core to fake VBLANK events when this part of the pipeline hasn't 176 * changed but others had or when the CRTC and connectors are being 177 * disabled. 178 * 179 * __drm_atomic_helper_crtc_duplicate_state() will not reset the value 180 * from the current state, the CRTC driver is then responsible for 181 * updating this field when needed. 182 * 183 * Note that the combination of &drm_crtc_state.event == NULL and 184 * &drm_crtc_state.no_blank == true is valid and usually used when the 185 * writeback connector attached to the CRTC has a new job queued. In 186 * this case the driver will send the VBLANK event on its own when the 187 * writeback job is complete. 188 */ 189 bool no_vblank : 1; 190 191 /** 192 * @plane_mask: Bitmask of drm_plane_mask(plane) of planes attached to 193 * this CRTC. 194 */ 195 u32 plane_mask; 196 197 /** 198 * @connector_mask: Bitmask of drm_connector_mask(connector) of 199 * connectors attached to this CRTC. 200 */ 201 u32 connector_mask; 202 203 /** 204 * @encoder_mask: Bitmask of drm_encoder_mask(encoder) of encoders 205 * attached to this CRTC. 206 */ 207 u32 encoder_mask; 208 209 /** 210 * @adjusted_mode: 211 * 212 * Internal display timings which can be used by the driver to handle 213 * differences between the mode requested by userspace in @mode and what 214 * is actually programmed into the hardware. 215 * 216 * For drivers using &drm_bridge, this stores hardware display timings 217 * used between the CRTC and the first bridge. For other drivers, the 218 * meaning of the adjusted_mode field is purely driver implementation 219 * defined information, and will usually be used to store the hardware 220 * display timings used between the CRTC and encoder blocks. 221 */ 222 struct drm_display_mode adjusted_mode; 223 224 /** 225 * @mode: 226 * 227 * Display timings requested by userspace. The driver should try to 228 * match the refresh rate as close as possible (but note that it's 229 * undefined what exactly is close enough, e.g. some of the HDMI modes 230 * only differ in less than 1% of the refresh rate). The active width 231 * and height as observed by userspace for positioning planes must match 232 * exactly. 233 * 234 * For external connectors where the sink isn't fixed (like with a 235 * built-in panel), this mode here should match the physical mode on the 236 * wire to the last details (i.e. including sync polarities and 237 * everything). 238 */ 239 struct drm_display_mode mode; 240 241 /** 242 * @mode_blob: &drm_property_blob for @mode, for exposing the mode to 243 * atomic userspace. 244 */ 245 struct drm_property_blob *mode_blob; 246 247 /** 248 * @degamma_lut: 249 * 250 * Lookup table for converting framebuffer pixel data before apply the 251 * color conversion matrix @ctm. See drm_crtc_enable_color_mgmt(). The 252 * blob (if not NULL) is an array of &struct drm_color_lut. 253 */ 254 struct drm_property_blob *degamma_lut; 255 256 /** 257 * @ctm: 258 * 259 * Color transformation matrix. See drm_crtc_enable_color_mgmt(). The 260 * blob (if not NULL) is a &struct drm_color_ctm. 261 */ 262 struct drm_property_blob *ctm; 263 264 /** 265 * @gamma_lut: 266 * 267 * Lookup table for converting pixel data after the color conversion 268 * matrix @ctm. See drm_crtc_enable_color_mgmt(). The blob (if not 269 * NULL) is an array of &struct drm_color_lut. 270 * 271 * Note that for mostly historical reasons stemming from Xorg heritage, 272 * this is also used to store the color map (also sometimes color lut, 273 * CLUT or color palette) for indexed formats like DRM_FORMAT_C8. 274 */ 275 struct drm_property_blob *gamma_lut; 276 277 /** 278 * @target_vblank: 279 * 280 * Target vertical blank period when a page flip 281 * should take effect. 282 */ 283 u32 target_vblank; 284 285 /** 286 * @async_flip: 287 * 288 * This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the legacy 289 * PAGE_FLIP IOCTL. It's not wired up for the atomic IOCTL itself yet. 290 */ 291 bool async_flip; 292 293 /** 294 * @vrr_enabled: 295 * 296 * Indicates if variable refresh rate should be enabled for the CRTC. 297 * Support for the requested vrr state will depend on driver and 298 * hardware capabiltiy - lacking support is not treated as failure. 299 */ 300 bool vrr_enabled; 301 302 /** 303 * @self_refresh_active: 304 * 305 * Used by the self refresh helpers to denote when a self refresh 306 * transition is occurring. This will be set on enable/disable callbacks 307 * when self refresh is being enabled or disabled. In some cases, it may 308 * not be desirable to fully shut off the crtc during self refresh. 309 * CRTC's can inspect this flag and determine the best course of action. 310 */ 311 bool self_refresh_active; 312 313 /** 314 * @scaling_filter: 315 * 316 * Scaling filter to be applied 317 */ 318 enum drm_scaling_filter scaling_filter; 319 320 /** > 321 * @sharpness_strength 322 * 323 * Used by the user to set the sharpness intensity. 324 * The value ranges from 0-255. 325 * Any value greater than 0 means enabling the featuring 326 * along with setting the value for sharpness. 327 */ 328 u8 sharpness_strength; 329 330 /** 331 * @event: 332 * 333 * Optional pointer to a DRM event to signal upon completion of the 334 * state update. The driver must send out the event when the atomic 335 * commit operation completes. There are two cases: 336 * 337 * - The event is for a CRTC which is being disabled through this 338 * atomic commit. In that case the event can be send out any time 339 * after the hardware has stopped scanning out the current 340 * framebuffers. It should contain the timestamp and counter for the 341 * last vblank before the display pipeline was shut off. The simplest 342 * way to achieve that is calling drm_crtc_send_vblank_event() 343 * somewhen after drm_crtc_vblank_off() has been called. 344 * 345 * - For a CRTC which is enabled at the end of the commit (even when it 346 * undergoes an full modeset) the vblank timestamp and counter must 347 * be for the vblank right before the first frame that scans out the 348 * new set of buffers. Again the event can only be sent out after the 349 * hardware has stopped scanning out the old buffers. 350 * 351 * - Events for disabled CRTCs are not allowed, and drivers can ignore 352 * that case. 353 * 354 * For very simple hardware without VBLANK interrupt, enabling 355 * &struct drm_crtc_state.no_vblank makes DRM's atomic commit helpers 356 * send a fake VBLANK event at the end of the display update after all 357 * hardware changes have been applied. See 358 * drm_atomic_helper_fake_vblank(). 359 * 360 * For more complex hardware this 361 * can be handled by the drm_crtc_send_vblank_event() function, 362 * which the driver should call on the provided event upon completion of 363 * the atomic commit. Note that if the driver supports vblank signalling 364 * and timestamping the vblank counters and timestamps must agree with 365 * the ones returned from page flip events. With the current vblank 366 * helper infrastructure this can be achieved by holding a vblank 367 * reference while the page flip is pending, acquired through 368 * drm_crtc_vblank_get() and released with drm_crtc_vblank_put(). 369 * Drivers are free to implement their own vblank counter and timestamp 370 * tracking though, e.g. if they have accurate timestamp registers in 371 * hardware. 372 * 373 * For hardware which supports some means to synchronize vblank 374 * interrupt delivery with committing display state there's also 375 * drm_crtc_arm_vblank_event(). See the documentation of that function 376 * for a detailed discussion of the constraints it needs to be used 377 * safely. 378 * 379 * If the device can't notify of flip completion in a race-free way 380 * at all, then the event should be armed just after the page flip is 381 * committed. In the worst case the driver will send the event to 382 * userspace one frame too late. This doesn't allow for a real atomic 383 * update, but it should avoid tearing. 384 */ 385 struct drm_pending_vblank_event *event; 386 387 /** 388 * @commit: 389 * 390 * This tracks how the commit for this update proceeds through the 391 * various phases. This is never cleared, except when we destroy the 392 * state, so that subsequent commits can synchronize with previous ones. 393 */ 394 struct drm_crtc_commit *commit; 395 396 /** @state: backpointer to global drm_atomic_state */ 397 struct drm_atomic_state *state; > 398 }; 399
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index 2765ba90ad8f..65eea6362fc0 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -418,6 +418,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc, set_out_fence_for_crtc(state->state, crtc, fence_ptr); } else if (property == crtc->scaling_filter_property) { state->scaling_filter = val; + } else if (property == crtc->sharpness_strength_property) { + state->sharpness_strength = val; } else if (crtc->funcs->atomic_set_property) { return crtc->funcs->atomic_set_property(crtc, state, property, val); } else { @@ -455,6 +457,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc, *val = 0; else if (property == crtc->scaling_filter_property) *val = state->scaling_filter; + else if (property == crtc->sharpness_strength_property) + *val = state->sharpness_strength; else if (crtc->funcs->atomic_get_property) return crtc->funcs->atomic_get_property(crtc, state, property, val); else { diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 46655339003d..1b7ce99cea5e 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -229,6 +229,25 @@ struct dma_fence *drm_crtc_create_fence(struct drm_crtc *crtc) * Driver's default scaling filter * Nearest Neighbor: * Nearest Neighbor scaling filter + * SHARPNESS_STRENGTH: + * Atomic property for setting the sharpness strength/intensity by userspace. + * + * The value of this property is set as an integer value ranging + * from 0 - 255 where: + * + * 0 means feature is disabled. + * + * 1 means minimum sharpness. + * + * 255 means maximum sharpness. + * + * User can gradually increase or decrease the sharpness level and can + * set the optimum value depending on content and this value will be + * passed to kernel through the Uapi. + * The setting of this property does not require modeset. + * The sharpness effect takes place post blending on the final composed output. + * If the feature is disabled, the content remains same without any sharpening effect + * and when this feature is applied, it enhances the clarity of the content. */ __printf(6, 0) @@ -940,6 +959,22 @@ int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc, } EXPORT_SYMBOL(drm_crtc_create_scaling_filter_property); +int drm_crtc_create_sharpness_strength_property(struct drm_crtc *crtc) +{ + struct drm_device *dev = crtc->dev; + struct drm_property *prop = + drm_property_create_range(dev, 0, "SHARPNESS_STRENGTH", 0, 255); + + if (!prop) + return -ENOMEM; + + crtc->sharpness_strength_property = prop; + drm_object_attach_property(&crtc->base, prop, 0); + + return 0; +} +EXPORT_SYMBOL(drm_crtc_create_sharpness_strength_property); + /** * drm_crtc_in_clone_mode - check if the given CRTC state is in clone mode * diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index caa56e039da2..ffcfe5c50dab 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -317,6 +317,16 @@ struct drm_crtc_state { */ enum drm_scaling_filter scaling_filter; + /** + * @sharpness_strength + * + * Used by the user to set the sharpness intensity. + * The value ranges from 0-255. + * Any value greater than 0 means enabling the featuring + * along with setting the value for sharpness. + */ + u8 sharpness_strength; + /** * @event: * @@ -1088,6 +1098,12 @@ struct drm_crtc { */ struct drm_property *scaling_filter_property; + /** + * @sharpness_strength_prop: property to apply + * the intensity of the sharpness requested. + */ + struct drm_property *sharpness_strength_property; + /** * @state: * @@ -1324,4 +1340,5 @@ static inline struct drm_crtc *drm_crtc_find(struct drm_device *dev, int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc, unsigned int supported_filters); bool drm_crtc_in_clone_mode(struct drm_crtc_state *crtc_state); +int drm_crtc_create_sharpness_strength_property(struct drm_crtc *crtc); #endif /* __DRM_CRTC_H__ */
Introduces the new crtc property "SHARPNESS_STRENGTH" that allows the user to set the intensity so as to get the sharpness effect. The value of this property can be set from 0-255. It is useful in scenario when the output is blurry and user want to sharpen the pixels. User can increase/decrease the sharpness level depending on the content displayed. v2: Rename crtc property variable [Arun] Add modeset detail in uapi doc[Uma] v3: Fix build issue Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> --- drivers/gpu/drm/drm_atomic_uapi.c | 4 ++++ drivers/gpu/drm/drm_crtc.c | 35 +++++++++++++++++++++++++++++++ include/drm/drm_crtc.h | 17 +++++++++++++++ 3 files changed, 56 insertions(+)