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:7.012 / U:1.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site