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/ |
Attachment:
signature.asc
Description: Digital signature
