Re: [PATCH 3/3] i2c-s3c2410: Add HDMIPHY quirk for S3C2440

From: Wolfram Sang
Date: Mon Apr 23 2012 - 06:01:18 EST

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).


> 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:
> 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 ;))



Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | |

Attachment: signature.asc
Description: Digital signature