| Message ID | 20220407200205.28838-2-javierm@redhat.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | drm/solomon: Add SSD130x OLED displays SPI support | expand |
On Thu, Apr 07, 2022 at 10:02:00PM +0200, Javier Martinez Canillas wrote: > The current compatible strings for SSD130x I2C controllers contain an -fb > suffix, this seems to indicate that are for a fbdev driver. But the DT is > supposed to describe the hardware and not Linux implementation details. True, but compatible is just an identifier. There's no reason to deprecate unless the binding as a whole needs to be redone. I imagine you also want 2 compatibles for 2 drivers. That's saying you should change your firmware to switch drivers. The fact that we have 2 drivers for the same h/w is a kernel problem. Don't bring DT into it. > Let's deprecate those compatible strings and add a new enum that contains > compatible strings that don't have a -fb suffix. These will be matched by > the ssd130x-i2c DRM driver. > > Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> > --- > > .../bindings/display/solomon,ssd1307fb.yaml | 36 ++++++++++++------- > 1 file changed, 24 insertions(+), 12 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > index ade61d502edd..46207f2c12b8 100644 > --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > @@ -12,12 +12,24 @@ maintainers: > > properties: > compatible: > - enum: > - - sinowealth,sh1106-i2c > - - solomon,ssd1305fb-i2c > - - solomon,ssd1306fb-i2c > - - solomon,ssd1307fb-i2c > - - solomon,ssd1309fb-i2c > + oneOf: > + # Deprecated compatible strings > + - items: > + - enum: > + - solomon,ssd1305fb-i2c > + - solomon,ssd1306fb-i2c > + - solomon,ssd1307fb-i2c > + - solomon,ssd1309fb-i2c > + deprecated: true > + > + # SSD130x I2C controllers > + - items: > + - enum: > + - sinowealth,sh1106-i2c > + - solomon,ssd1305-i2c > + - solomon,ssd1306-i2c > + - solomon,ssd1307-i2c > + - solomon,ssd1309-i2c There's also no reason to put the bus interface into the compatible as the same compatible will work on different buses. But since you want to add SPI, just using the 'i2c' one will confuse people. For that reason you could add 'solomon,ssd1305', etc. for both SPI support and I2C DRM. (You should also support the 'fb-i2c' variant in DRM IMO, but doubtful that I'll review that.) Rob
Hello Rob, On 4/8/22 20:22, Rob Herring wrote: > On Thu, Apr 07, 2022 at 10:02:00PM +0200, Javier Martinez Canillas wrote: >> The current compatible strings for SSD130x I2C controllers contain an -fb >> suffix, this seems to indicate that are for a fbdev driver. But the DT is >> supposed to describe the hardware and not Linux implementation details. > > True, but compatible is just an identifier. There's no reason to > deprecate unless the binding as a whole needs to be redone. > > I imagine you also want 2 compatibles for 2 drivers. That's saying you > should change your firmware to switch drivers. The fact that we have 2 > drivers for the same h/w is a kernel problem. Don't bring DT into it. > No, that's not what I meant. In fact, we currently have two drivers that match against the same set of compatible strings. These drivers are: * drivers/video/fbdev/ssd1307fb.c * drivers/gpu/drm/solomon/ssd130x-i2c.c what I don't personally like about the current compatible strings is that the *driver* name was encoded on those, rather than the IC names. So for instance there's a "solomon,ssd1307fb-i2c" (notice the fb suffix) instead of just "solomon,ssd1307-i2c" or "solomon,ssd1307". When I ported the fbdev driver to DRM, I considered using different values for the compatible strings but decided to just use the same for backward compatibility. But now I want to add compatible strings for OLED controllers that use a SPI interface instead, and I don't really want to add a compatible string "solomon,ssd1307fb-spi" but just without the "fb". I want the SPI compatible strings to be consistent with the I2C ones though, hence the deprecation so new DTS could just use the ones without a "fb". Now, if you say that I can't do add new ones for I2C, then I will just add "solomon,ssd1307fb-spi" and similar even though I don't like the "fb" there. And just to make clear, the DRM driver will continue matching against both compatible strings, but the fbdev will only match the old "fb" ones. [snip] >> + >> + # SSD130x I2C controllers >> + - items: >> + - enum: >> + - sinowealth,sh1106-i2c >> + - solomon,ssd1305-i2c >> + - solomon,ssd1306-i2c >> + - solomon,ssd1307-i2c >> + - solomon,ssd1309-i2c > > There's also no reason to put the bus interface into the compatible as > the same compatible will work on different buses. But since you want to > add SPI, just using the 'i2c' one will confuse people. For that reason > you could add 'solomon,ssd1305', etc. for both SPI support and I2C DRM. That's not really true. There's a reason to add per bus compatible strings at least in Linux. And is that there's no information about the bus types in module aliases that are reported to user-space for module auto-loading. For example, $ cat /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-003c/modalias of:NoledT(null)Csolomon,ssd1306fb-i2c $ cat /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-003c/uevent DRIVER=ssd130x-i2c OF_NAME=oled OF_FULLNAME=/soc/i2c@7e804000/oled@3c OF_COMPATIBLE_0=solomon,ssd1306fb-i2c OF_COMPATIBLE_N=1 MODALIAS=of:NoledT(null)Csolomon,ssd1306fb-i2c and $ modinfo ssd130x-i2c | grep alias alias: of:N*T*Csolomon,ssd1309fb-i2cC* alias: of:N*T*Csolomon,ssd1309fb-i2c alias: of:N*T*Csolomon,ssd1307fb-i2cC* alias: of:N*T*Csolomon,ssd1307fb-i2c alias: of:N*T*Csolomon,ssd1306fb-i2cC* alias: of:N*T*Csolomon,ssd1306fb-i2c alias: of:N*T*Csolomon,ssd1305fb-i2cC* alias: of:N*T*Csolomon,ssd1305fb-i2c alias: of:N*T*Csinowealth,sh1106-i2cC* alias: of:N*T*Csinowealth,sh1106-i2c this module will match against any MODALIAS uevent that has one of the listed compatible strings in "C" and any node name in "N". But also for any type "T". And even if the module alias was more restrictive and say only matched against 'of:N*Ti2cCsolomon,ssd1307fb-i2c', the type information is not filled by the bus drivers. So, if we just had a "solomon,ssd1307" compatible string, then a device registered through OF could lead to the wrong kernel module to be loaded. In other words, it's true that having a single compatible strings for all bus drivers will work for device -> driver matching but may not work for module auto-loading. > (You should also support the 'fb-i2c' variant in DRM IMO, but doubtful > that I'll review that.) > As mentioned above, it does even after adding support for the new strings, for backward compatibility. > Rob >
On 4/8/22 21:19, Javier Martinez Canillas wrote: [snip] >> >> There's also no reason to put the bus interface into the compatible as >> the same compatible will work on different buses. But since you want to >> add SPI, just using the 'i2c' one will confuse people. For that reason >> you could add 'solomon,ssd1305', etc. for both SPI support and I2C DRM. > > That's not really true. There's a reason to add per bus compatible strings > at least in Linux. And is that there's no information about the bus types > in module aliases that are reported to user-space for module auto-loading. > Forgot to mention that in this particular case it will work but just because the SPI subsystem always report a module alias of the form "spi:device" even for devices that are registered through OF. So having a single "solomon,ssd1306" would work because for I2C the module alias will be "of:NoledT(null)Csolomon,ssd1306" and for SPI it will be "spi:ssd1306". But if ever the SPI subsystem is fixed to report proper OF module aliases things will break. And since the DT bindings is an ABI, it's safer to have "-i2c" and "-spi" compatible strings variants.
Hi Javier, On Thu, Apr 7, 2022 at 10:03 PM Javier Martinez Canillas <javierm@redhat.com> wrote: > The current compatible strings for SSD130x I2C controllers contain an -fb > suffix, this seems to indicate that are for a fbdev driver. But the DT is > supposed to describe the hardware and not Linux implementation details. > > Let's deprecate those compatible strings and add a new enum that contains > compatible strings that don't have a -fb suffix. These will be matched by > the ssd130x-i2c DRM driver. > > Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> > --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > @@ -12,12 +12,24 @@ maintainers: > > properties: > compatible: > - enum: > - - sinowealth,sh1106-i2c > - - solomon,ssd1305fb-i2c > - - solomon,ssd1306fb-i2c > - - solomon,ssd1307fb-i2c > - - solomon,ssd1309fb-i2c > + oneOf: > + # Deprecated compatible strings > + - items: > + - enum: > + - solomon,ssd1305fb-i2c > + - solomon,ssd1306fb-i2c > + - solomon,ssd1307fb-i2c > + - solomon,ssd1309fb-i2c Please drop the "-i2c" suffixes, too. We already have plenty of IIO sensors and audio codecs using the same compatible value for spi and i2c, cfr. 'git grep compatible -- "*-[si][p2][ic].c"' Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hello Geert, On 4/11/22 15:47, Geert Uytterhoeven wrote: > Hi Javier, > > On Thu, Apr 7, 2022 at 10:03 PM Javier Martinez Canillas > <javierm@redhat.com> wrote: >> The current compatible strings for SSD130x I2C controllers contain an -fb >> suffix, this seems to indicate that are for a fbdev driver. But the DT is >> supposed to describe the hardware and not Linux implementation details. >> >> Let's deprecate those compatible strings and add a new enum that contains >> compatible strings that don't have a -fb suffix. These will be matched by >> the ssd130x-i2c DRM driver. >> >> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> > >> --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml >> +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml >> @@ -12,12 +12,24 @@ maintainers: >> >> properties: >> compatible: >> - enum: >> - - sinowealth,sh1106-i2c >> - - solomon,ssd1305fb-i2c >> - - solomon,ssd1306fb-i2c >> - - solomon,ssd1307fb-i2c >> - - solomon,ssd1309fb-i2c >> + oneOf: >> + # Deprecated compatible strings >> + - items: >> + - enum: >> + - solomon,ssd1305fb-i2c >> + - solomon,ssd1306fb-i2c >> + - solomon,ssd1307fb-i2c >> + - solomon,ssd1309fb-i2c > > Please drop the "-i2c" suffixes, too. > We already have plenty of IIO sensors and audio codecs using the > same compatible value for spi and i2c, cfr. > 'git grep compatible -- "*-[si][p2][ic].c"' > Yes, I know but was worried about the potential issues that mentioned in a previous email in this thread. But after the discussion we had over IRC, I think that is safe to assume that the SPI subsystem won't change how the modaliases are reported, so there won't be conflict between I2C and SPI. And if that is ever changed, there's a plan to add the bus type to the data reported by the modalias uevent so user-space could figure out what to load. So I'll go ahead with Rob and yours suggestion, and just deprecate the old ones and drop both the "fb" and "-i2c" part of the compatible strings, to use the same compatible strings for both the I2C and SPI drivers. After all, that's the correct way to describe the hardware and not encode any Linux implementation details in the DT binding.
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index ade61d502edd..46207f2c12b8 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -12,12 +12,24 @@ maintainers: properties: compatible: - enum: - - sinowealth,sh1106-i2c - - solomon,ssd1305fb-i2c - - solomon,ssd1306fb-i2c - - solomon,ssd1307fb-i2c - - solomon,ssd1309fb-i2c + oneOf: + # Deprecated compatible strings + - items: + - enum: + - solomon,ssd1305fb-i2c + - solomon,ssd1306fb-i2c + - solomon,ssd1307fb-i2c + - solomon,ssd1309fb-i2c + deprecated: true + + # SSD130x I2C controllers + - items: + - enum: + - sinowealth,sh1106-i2c + - solomon,ssd1305-i2c + - solomon,ssd1306-i2c + - solomon,ssd1307-i2c + - solomon,ssd1309-i2c reg: maxItems: 1 @@ -148,7 +160,7 @@ allOf: properties: compatible: contains: - const: solomon,ssd1305fb-i2c + const: solomon,ssd1305-i2c then: properties: solomon,dclk-div: @@ -160,7 +172,7 @@ allOf: properties: compatible: contains: - const: solomon,ssd1306fb-i2c + const: solomon,ssd1306-i2c then: properties: solomon,dclk-div: @@ -172,7 +184,7 @@ allOf: properties: compatible: contains: - const: solomon,ssd1307fb-i2c + const: solomon,ssd1307-i2c then: properties: solomon,dclk-div: @@ -186,7 +198,7 @@ allOf: properties: compatible: contains: - const: solomon,ssd1309fb-i2c + const: solomon,ssd1309-i2c then: properties: solomon,dclk-div: @@ -203,14 +215,14 @@ examples: #size-cells = <0>; ssd1307: oled@3c { - compatible = "solomon,ssd1307fb-i2c"; + compatible = "solomon,ssd1307-i2c"; reg = <0x3c>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7>; }; ssd1306: oled@3d { - compatible = "solomon,ssd1306fb-i2c"; + compatible = "solomon,ssd1306-i2c"; reg = <0x3c>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7>;
The current compatible strings for SSD130x I2C controllers contain an -fb suffix, this seems to indicate that are for a fbdev driver. But the DT is supposed to describe the hardware and not Linux implementation details. Let's deprecate those compatible strings and add a new enum that contains compatible strings that don't have a -fb suffix. These will be matched by the ssd130x-i2c DRM driver. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> --- .../bindings/display/solomon,ssd1307fb.yaml | 36 ++++++++++++------- 1 file changed, 24 insertions(+), 12 deletions(-)