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@xxxxxxxxxxxx> wrote:
Hi,First of all sorry for the late response,Thanks,On Tue, Oct 1, 2013 at 10:09 AM, Inki Dae <inki.dae@xxxxxxxxxxx> wrote:
> -----Original Message-----
> From: Sylwester Nawrocki [mailto:sylvester.nawrocki@xxxxxxxxx]
> Sent: Monday, September 30, 2013 7:09 AM
> To: Inki Dae
> Cc: Rahul Sharma; devicetree@xxxxxxxxxxxxxxx; 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:Ah, I missed checking text mode. Sorry about this. :)
> >> 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.
>
Good idea.
> It often helps to Cc a DT binding maintainer directly.
>
Right.
> Then, you consider moving the HDMI phy configuration to the device tree.
> As Sean suggested in this thread:
>
Right, but the user manual doesn't describe that enough so we might need to
> ">> +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
inquire for what it means to design team.
Thanks you your opinion. However, we need to make sure how we take care of
> 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.
>
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
Shirish S
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
