lkml.org 
[lkml]   [2012]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] i2c-s3c2410: Add HDMIPHY quirk for S3C2440
Hi Karol,

> >>> ... and this one, if we declare a new compatible-entry for exynos4?
> >>
> >> It is not strictly related to Exynos4 SoCs. Exynos4 SoC has 8 standard s3c2440 style
> >> i2c controllers and one additional, internal controller for HDMIPHY, which needs
> >> some workarounds in the driver. Maybe the quirk should be named 'broken timeout
> >> detection'
> >
> > I was wondering since you do what I suggested for platform devices already:
> >
> > + .name = "s3c2440-hdmiphy-i2c",
> > + .driver_data = QUIRK_S3C2440 | QUIRK_HDMIPHY | QUIRK_NO_GPIO,
>
>
> Here I've done it this way for compatibility with legacy driver and
> board(s).

Understood.

> Device tree is new interface, and I thought that it would be better
> to describe things explicitly and separately from device type.
>
> Right now these properties are used only on S3C2440, but I don't
> consider it highly unlikely to see these on S3C**** in future.

My experience also says that it easily can get even worse :(

> Tomasz had similar doubts when I've posted patch that checked these
> quirks only for S3C2440:
>
> http://permalink.gmane.org/gmane.linux.drivers.i2c/10305
>
> Thus, I've chosen properties and not separate type.

I understand this reasoning. I still differ, though. Think about my
above example about things getting worse. Then, you'd need another
quirk-property for $FLAW. Later, $FLAW is still there, but the timeout
issue was fixed. That would mean, the poor device-tree making person has
to know which quirks to select for this version of the controller. Just
specifying that it is the HDMI-phy and not a regular I2C controller is
much more convenient, and the driver will figure the rest.

> It's easy to introduce compat string (see below), but given above
> I'm afraid that we might end up adding -hdmiphy- variant for every
> new version of i2c controller.

I'd be fine with that, given that the upcoming hdmiphy versions will not
need all the same set of quirk-flags. I think we want that "quirk lookup
table" fixed in the driver and not encoded in the device tree where
people could get it wrong. Also, the quirks are nothing a board maker
can select from; it is implicit as soons as you want the HDMIPHY on that
SoC, thus the compatible-entry should be enough of a description.

I am not the ultimate expert about bindings, though, and am open for
corrections (I feel kinda confident on this issue, though ;))

Regards,

Wolfram

--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2012-04-23 12:05    [W:0.147 / U:0.344 seconds]
©2003-2014 Jasper Spaans. Advertise on this site