505f6cff88
Properties are uapi like anything else, with all the usual rules
regarding review, testcases, open source userspace ... Furthermore
driver-private kms properties are highly discouraged, over the past
few years we've realized we need to make a serious effort at better
standardizing this stuff.
From the discussion with Liviu the solution for these here needs
multiple pieces:
- For being able to reliably read the memory clock we need a DT
property, plus maybe DT override snippets to fix it if it's wrong.
- For exposing plane limitations to userspace there's TEST_ONLY. There
is a bit a gap in telling userspace better that scaling doesn't work
due to limits (atm a good strategy is to retry again without scaling
when adding a plane didn't work the first time around). But that
needs a more generic solution, not exposing something extremely
komeda specific.
- If this is needed by validation tools, you can still expose it in
debugfs. We have an entire nice infrastructure for debug printing of
kms objects already, see the various atomic_print_state callbacks
and infrastructure around them.
Fixes:
|
||
|---|---|---|
| .. | ||
| display | ||
| hdlcd_crtc.c | ||
| hdlcd_drv.c | ||
| hdlcd_drv.h | ||
| hdlcd_regs.h | ||
| Kconfig | ||
| Makefile | ||
| malidp_crtc.c | ||
| malidp_drv.c | ||
| malidp_drv.h | ||
| malidp_hw.c | ||
| malidp_hw.h | ||
| malidp_mw.c | ||
| malidp_mw.h | ||
| malidp_planes.c | ||
| malidp_regs.h | ||