Hi, I have uploaded patch set 2, with only required registers being moved to dt file. Thanks, Shirish S
On Thu, Oct 3, 2013 at 7:58 AM, Shirish S <shirish at chromium.org> wrote: > Hi, > First of all sorry for the late response, > > > On Tue, Oct 1, 2013 at 10:09 AM, Inki Dae <inki.dae at samsung.com> wrote: > >> >> >> > -----Original Message----- >> > From: Sylwester Nawrocki [mailto:sylvester.nawrocki at gmail.com] >> > Sent: Monday, September 30, 2013 7:09 AM >> > To: Inki Dae >> > Cc: Rahul Sharma; devicetree at vger.kernel.org; linux-samsung-soc; >> > sw0312.kim; sunil joshi; dri-devel; kgene.kim; Shirish S; Sylwester >> > Nawrocki; Rahul Sharma; Stephen Warren; Mark Rutland; Kumar Gala; Pawel >> > Moll; Rob Herring; Sean Paul >> > Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to >> hdmiphy >> > driver >> > >> > 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. >> > >> >> Ah, I missed checking text mode. Sorry about this. :) >> >> >> >> > It often helps to Cc a DT binding maintainer directly. >> > >> >> Good idea. >> >> > Then, you consider moving the HDMI phy configuration to the device tree. >> > As Sean suggested in this thread: >> > >> >> Right. >> >> > ">> +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 >> >> Right, but the user manual doesn't describe that enough so we might need >> to >> inquire for what it means to design team. >> >> > 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 you your opinion. However, we need to make sure how we take care of >> the PHY configuration values. So I will have two steps to merge this pages >> set. >> >> To Rahul, >> Could you post only your patch set regardless of Shirish's patch? I will >> merge your patch set first because as is, Exynos drm hdmi driver is >> broken. >> And, we need more discussions about Shirish patch. So I will not merge >> this >> patch until we have a consensus about it. >> >> To Shirish, >> For your patch, it seems that you need to make sure to figure out exact >> meaning of each byte of the PHY configuration values first. Maybe you need >> to inquire for that to hardware or design team. And please separate the >> values into common and specific parts if needed. >> >> Agreed, I shall request our hardware team to provide description about > the phy values, and will update the patch, once i receive the same. > > >> >> Thanks, >> Inki Dae >> >> > -- >> > Thanks, >> > Sylwester >> >> Thanks, > Shirish S > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131028/a1be2188/attachment-0001.html>