[PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver

Shirish S shirish at chromium.org
Thu Oct 3 04:28:37 CEST 2013


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/20131003/ffb7445e/attachment-0001.html>


More information about the dri-devel mailing list