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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux