Hi Thierry,
在 2015/8/25 17:12, Thierry Reding 写道:
On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote:
On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxxx> wrote:
On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang <ykk@xxxxxxxxxxxxxx> wrote:
+ -analogix,color-depth:
+ number of bits per colour component.
+ COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
drop the vendor prefix.
Please think about this some more. What does "color-depth" mean? Does it
mean the number of bits per colour _component_, or does it mean the total
number of bits to represent a particular colour. It's confusing as it
stands.
Then "component-color-bpp" perhaps?
There should be no need to have this in DT at all. The BPC is a property
of the attached panel and it should come from the panel (either the
panel driver or parsed from EDID if available).
Actually I have send an email about this one to you in version 2, just
past from that email:
"samsung,color_space" and "samsung,color-depth"
The drm_display_info's color_formats and bpc indicate the monitor
display ability, but
the edp driver could not take it as input video format directly.
For example, with my DP TV I would found "RGB444 & YCRCB422 & & YCRCB444"
support in drm_display_info.color_formats and 16bit bpc support, but
RK3288 crtc
driver could only output RGB & ITU formats, so finally
analogix_dp-rockchip driver
config crtc to RGBaaa 10bpc mode.
In this sutiation, the analogix_dp core driver would pazzled by the
drm_display_info,
can't chose the right color_space and bpc.
And this is the place that confused me, wish you could give some ideas
about this one :-)
- Yakir
When we adopted the graph bindings for iMX DRM, I thought exactly at that
time "it would be nice if this could become the standard for binding DRM
components together" but I don't have the authority from either the DT
perspective or the DRM perspective to mandate that. Neither does anyone
else. That's the _real_ problem here.
I've seen several DRM bindings go by which don't use the of-graph stuff,
which means that they'll never be compatible with generic components
which do use the of-graph stuff.
It goes beyond bindings IMO. The use of the component framework or not
has been at the whim of driver writers as well. It is either used or
private APIs are created. I'm using components and my need for it
boils down to passing the struct drm_device pointer to the encoder.
Other components like panels and bridges have different ways to attach
to the DRM driver.
I certainly support unification, but it needs to be reasonable. There
are cases where a different structure for the binding work better than
another and I think this always needs to be evaluated on a case by case
basis.
Because of that I think it makes sense to make all these framework bits
opt-in, otherwise we could easily end up in a situation where drivers
have to be rearchitected (or even DT bindings altered!) in order to be
able to reuse code.
Thierry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
