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: 1f7f9ab7 ("drm/komeda: Add engine clock requirement check for the downscaling")
Cc: Lowry Li (Arm Technology China) <lowry.li@arm.com>
Cc: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190705121006.26085-1-daniel.vetter@ffwll.ch