On 09/28/2013 06:10 PM, Inki Dae wrote:
Any opinion from Device-Tree folks?
IMO, we should have same consensus on Shirish patches before proceeding.
Rahul, it seems that DT people have no interest in this issue. So let's
have a consensus about this issue internally.
To Mr. Kyungmin, Sylwester, Kukjin Kim, and Tomasz,
How about keeping hdmiphy config data in each board dts file?
Please don't use HTML and quote only relevant part of e-mails. Otherwise
there are good chances your messages end up in people's spam box.
It often helps to Cc a DT binding maintainer directly.
Then, you consider moving the HDMI phy configuration to the device tree.
As Sean suggested in this thread:
">> +static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 27000000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
+ },
+ },
[trimmed couple more entries]
+};
Are you aware of the effort to move these to dt? Since these are
board-specific values, it seems incorrect to apply them universally.
Shirish has uploaded a patch to the chromium review site to push these
into dt (https://chromium-review.googlesource.com/#/c/65581). Maybe
you can work that into your patch set?"
The configuration data is 64 bytes of the register values IIUC. Would it be
possible to figure out exact meaning of each byte ? Do all of these bytes
need to be changed per board ? Perhaps we can have per SoC static tables in
the PHY driver and be overwriting only some of the bytes with values read
from device tree ?
AFAIR firmware-like binary blobs (register address/value pairs) are not
supposed to be stored in DT.
If there is no detailed documentation for theese PHY configuration tables
I guess there is no choice but to put these raw 64 bytes in DT. Presumably
this should be a an required property defined only by board dts, since those
values are PCB design dependent.
However, if not all boards need tweaking this configuration data, then it
could make sense to define recommended per-SoC tables in the driver and
overwrite from DT only if it is specified there for a specific board.
If we can come up with universal configuration for a SoC and selected pixel
clock frequency then it could likely be better to store that in the driver
rather than in DT.
--
Thanks,
Sylwester
--
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
