* [PATCH 1/3] dt-bindings: Add Ilitek vendor ID @ 2017-08-13 11:44 Linus Walleij [not found] ` <20170813114448.20179-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 0 siblings, 1 reply; 9+ messages in thread From: Linus Walleij @ 2017-08-13 11:44 UTC (permalink / raw) To: Thierry Reding, dri-devel; +Cc: devicetree Ili Technology Corporation (Ilitek) is a vendor of display drivers and touch input controllers for embedded devices. Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index daf465bef758..3e7e33484e5b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -147,6 +147,7 @@ i2se I2SE GmbH ibm International Business Machines (IBM) idt Integrated Device Technologies, Inc. ifi Ingenieurburo Fur Ic-Technologie (I/F/I) +ilitek Ili Technology Corporation img Imagination Technologies Ltd. infineon Infineon Technologies inforce Inforce Computing -- 2.13.4 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 9+ messages in thread
[parent not found: <20170813114448.20179-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]
* [PATCH 2/3] drm/panel: Add DT bindings for Ilitek ILI9322 [not found] ` <20170813114448.20179-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> @ 2017-08-13 11:44 ` Linus Walleij [not found] ` <20170813114448.20179-2-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2017-08-17 20:35 ` [PATCH 1/3] dt-bindings: Add Ilitek vendor ID Rob Herring 1 sibling, 1 reply; 9+ messages in thread From: Linus Walleij @ 2017-08-13 11:44 UTC (permalink / raw) To: Thierry Reding, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW Cc: Linus Walleij, devicetree-u79uwXL29TY76Z2rM5mHXA This adds device tree bindings for the Ilitek ILI9322 320x240 TFT panel driver. Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> --- .../bindings/display/panel/ilitek,ili9322.txt | 120 +++++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt new file mode 100644 index 000000000000..d619b1ad14a6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt @@ -0,0 +1,120 @@ +Ilitek ILI9322 TFT panel driver with SPI control bus + +This is a driver for 320x240 TFT panels, accepting a variety of input +streams that get adapted and scaled to the panel. The panel output has +960 TFT source driver pins and 240 TFT gate driver pins, VCOM, VCOML and +VCOMH outputs. + +Required properties: + - compatible: "ilitek,ili9322" + - reg: address of the panel on the SPI bus + +Optional properties: + - width-mm: physical panel width [mm] + - height-mm: physical panel height [mm] + - vcc-supply: core voltage supply, see regulator/regulator.txt + - iovcc-supply: voltage supply for the interface input/output signals, + see regulator/regulator.txt + - vci-supply: voltage supply for analog parts, see regulator/regulator.txt + - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt + - ilitek,vreg1out-microvolt: the output in microvolts for the VREGOUT1 + regulator used to drive the physical display. Valid ranges are 3600 thru + 6000 in 100 microvolt increments. If not specified, hardware defaults will + be used (4.5V). + - ilitek,vcom-amplitude-percent: the percentage of VREGOUT1 used for the + peak-to-peak amplitude of the communcation signals to the physical display. + Valid ranges are 70 thru 132 percent in increments if two percent. Odd + percentages will be truncated. If not specified, hardware defaults will be + used (114%). + - ilitek,vcom-high-percent: the percentage of VREGOUT1 used for the peak + voltage on the communications link. Valid ranges are 37 thru 100 percent. + If not specified, hardware defaults will be used (91%). + - ilitek,gamma-correction-neg: a set of 8 nybbles describing negative + gamma correction for voltages V1 thru V8. Valid range 0..15 + - ilitek,gamma-correction-pos: a set of 8 nybbles describing positive + gamma correction for voltages V1 thru V8. Valid range 0..15 + These adjust what grayscale voltage will be output for input data V1 = 0, + V2 = 16, V3 = 48, V4 = 96, V5 = 160, V6 = 208, V7 = 240 and V8 = 255. + The curve is shaped like this: + + ^ + | V8 + | V7 + | V6 + | V5 + | V4 + | V3 + | V2 + | V1 + +-----------------------------------------------------------> + 0 16 48 96 160 208 240 255 + + The negative and postive gamma values adjust the V1 thru V8 up/down + according to the datasheet specifications. This is a property of the + physical display connected to the display controller and may vary. + If defined, both arrays must be supplied in full. If the properties + are not supplied, hardware defaults will be used. + + - ilitek,entry-mode: the panel can be connected to various input streams + and four of them can be selected by electronic straps on the display. + However it is possible to select another mode or override the + electronic default with this property. Valid values: + 0: 8 bit serial RGB through + 1: 8 bit serial RGB aligned + 2: 8 bit serial RGB dummy 320x240 + 3: 8 bit serial RGB dummy 360x240 + 4: disabled + 5: 24 bit parallel RGB through + 6: 24 bit parallel RGB aligned + 7: 24 bit YUV 640Y 320CbCr + 8: 24 bit YUV 720Y 360CbCr + 9: disabled + 10: 8 bit ITU-R BT.656 720Y 360CbCr + 11: 8 bit ITU-R BT.656 640Y 320CbCr + + The following optional properties only apply to RGB and YUV input modes and + can be omitted for BT.656 input modes: + + - flip-horizontal: flip the image horizontally (right-to-left scan) + - flip-vertical: flip the image vertically (down-to-up scan) + - pixelclk-active: see display/panel/display-timing.txt + - de-active: see display/panel/display-timing.txt + - hsync-active: see display/panel/display-timing.txt + - vsync-active: see display/panel/display-timing.txt + +The panel must obey the rules for a SPI slave device as specified in +spi/spi-bus.txt + +The device node can contain one 'port' child node with one child +'endpoint' node, according to the bindings defined in +media/video-interfaces.txt. This node should describe panel's video bus. + +Example: + +panel: display@0 { + compatible = "ilitek,ili9322"; + reg = <0>; + /* 50 ns min period = 20 MHz */ + spi-max-frequency = <20000000>; + spi-cpol; /* Clock active low */ + /* Panel LM918A01-1A SY-B4-091116-E0199 */ + width-mm = <65>; + height-mm = <50>; + ilitek,entry-mode = <11>; + ilitek,vreg1out-microvolt = <4600>; + ilitek,vcom-high-percent = <91>; + ilitek,vcom-amplitude-percent = <114>; + ilitek,gamma-correction-neg = <0xa>, <0x5>, <0x7>, + <0x7>, <0x7>, <0x5>, <0x1>, <0x6>; + ilitek,gamma-correction-pos = <0x7>, <0x7>, <0x3>, + <0x2>, <0x3>, <0x5>, <0x7>, <0x2>; + vcc-supply = <&vdisp>; + iovcc-supply = <&vdisp>; + vci-supply = <&vdisp>; + + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; +}; -- 2.13.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 9+ messages in thread
[parent not found: <20170813114448.20179-2-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]
* Re: [PATCH 2/3] drm/panel: Add DT bindings for Ilitek ILI9322 [not found] ` <20170813114448.20179-2-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> @ 2017-08-17 20:44 ` Rob Herring 2017-09-02 21:17 ` Linus Walleij 0 siblings, 1 reply; 9+ messages in thread From: Rob Herring @ 2017-08-17 20:44 UTC (permalink / raw) To: Linus Walleij Cc: Thierry Reding, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, devicetree-u79uwXL29TY76Z2rM5mHXA On Sun, Aug 13, 2017 at 01:44:47PM +0200, Linus Walleij wrote: > This adds device tree bindings for the Ilitek ILI9322 > 320x240 TFT panel driver. > > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > --- > .../bindings/display/panel/ilitek,ili9322.txt | 120 +++++++++++++++++++++ > 1 file changed, 120 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt > > diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt > new file mode 100644 > index 000000000000..d619b1ad14a6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt > @@ -0,0 +1,120 @@ > +Ilitek ILI9322 TFT panel driver with SPI control bus > + > +This is a driver for 320x240 TFT panels, accepting a variety of input > +streams that get adapted and scaled to the panel. The panel output has > +960 TFT source driver pins and 240 TFT gate driver pins, VCOM, VCOML and > +VCOMH outputs. > + > +Required properties: > + - compatible: "ilitek,ili9322" > + - reg: address of the panel on the SPI bus > + > +Optional properties: > + - width-mm: physical panel width [mm] > + - height-mm: physical panel height [mm] > + - vcc-supply: core voltage supply, see regulator/regulator.txt > + - iovcc-supply: voltage supply for the interface input/output signals, > + see regulator/regulator.txt > + - vci-supply: voltage supply for analog parts, see regulator/regulator.txt > + - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt > + - ilitek,vreg1out-microvolt: the output in microvolts for the VREGOUT1 > + regulator used to drive the physical display. Valid ranges are 3600 thru > + 6000 in 100 microvolt increments. If not specified, hardware defaults will > + be used (4.5V). > + - ilitek,vcom-amplitude-percent: the percentage of VREGOUT1 used for the > + peak-to-peak amplitude of the communcation signals to the physical display. > + Valid ranges are 70 thru 132 percent in increments if two percent. Odd > + percentages will be truncated. If not specified, hardware defaults will be > + used (114%). > + - ilitek,vcom-high-percent: the percentage of VREGOUT1 used for the peak > + voltage on the communications link. Valid ranges are 37 thru 100 percent. > + If not specified, hardware defaults will be used (91%). > + - ilitek,gamma-correction-neg: a set of 8 nybbles describing negative > + gamma correction for voltages V1 thru V8. Valid range 0..15 > + - ilitek,gamma-correction-pos: a set of 8 nybbles describing positive > + gamma correction for voltages V1 thru V8. Valid range 0..15 > + These adjust what grayscale voltage will be output for input data V1 = 0, > + V2 = 16, V3 = 48, V4 = 96, V5 = 160, V6 = 208, V7 = 240 and V8 = 255. > + The curve is shaped like this: > + > + ^ > + | V8 > + | V7 > + | V6 > + | V5 > + | V4 > + | V3 > + | V2 > + | V1 > + +-----------------------------------------------------------> > + 0 16 48 96 160 208 240 255 > + > + The negative and postive gamma values adjust the V1 thru V8 up/down > + according to the datasheet specifications. This is a property of the > + physical display connected to the display controller and may vary. > + If defined, both arrays must be supplied in full. If the properties > + are not supplied, hardware defaults will be used. Normally, we the physical panel is described which would imply all these settings. Are there lots of panels with this controller that would justify all these settings? > + > + - ilitek,entry-mode: the panel can be connected to various input streams > + and four of them can be selected by electronic straps on the display. > + However it is possible to select another mode or override the > + electronic default with this property. Valid values: > + 0: 8 bit serial RGB through > + 1: 8 bit serial RGB aligned > + 2: 8 bit serial RGB dummy 320x240 > + 3: 8 bit serial RGB dummy 360x240 > + 4: disabled > + 5: 24 bit parallel RGB through > + 6: 24 bit parallel RGB aligned > + 7: 24 bit YUV 640Y 320CbCr > + 8: 24 bit YUV 720Y 360CbCr > + 9: disabled > + 10: 8 bit ITU-R BT.656 720Y 360CbCr > + 11: 8 bit ITU-R BT.656 640Y 320CbCr To some extent, we have some standard bindings to describe this. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/3] drm/panel: Add DT bindings for Ilitek ILI9322 2017-08-17 20:44 ` Rob Herring @ 2017-09-02 21:17 ` Linus Walleij 2017-09-20 11:56 ` Linus Walleij 0 siblings, 1 reply; 9+ messages in thread From: Linus Walleij @ 2017-09-02 21:17 UTC (permalink / raw) To: Rob Herring Cc: Thierry Reding, open list:DRM PANEL DRIVERS, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On Thu, Aug 17, 2017 at 10:44 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > On Sun, Aug 13, 2017 at 01:44:47PM +0200, Linus Walleij wrote: >> This adds device tree bindings for the Ilitek ILI9322 >> 320x240 TFT panel driver. >> >> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> (...) >> +Optional properties: >> + - width-mm: physical panel width [mm] >> + - height-mm: physical panel height [mm] >> + - vcc-supply: core voltage supply, see regulator/regulator.txt >> + - iovcc-supply: voltage supply for the interface input/output signals, >> + see regulator/regulator.txt >> + - vci-supply: voltage supply for analog parts, see regulator/regulator.txt >> + - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt >> + - ilitek,vreg1out-microvolt: the output in microvolts for the VREGOUT1 >> + regulator used to drive the physical display. Valid ranges are 3600 thru >> + 6000 in 100 microvolt increments. If not specified, hardware defaults will >> + be used (4.5V). >> + - ilitek,vcom-amplitude-percent: the percentage of VREGOUT1 used for the >> + peak-to-peak amplitude of the communcation signals to the physical display. >> + Valid ranges are 70 thru 132 percent in increments if two percent. Odd >> + percentages will be truncated. If not specified, hardware defaults will be >> + used (114%). >> + - ilitek,vcom-high-percent: the percentage of VREGOUT1 used for the peak >> + voltage on the communications link. Valid ranges are 37 thru 100 percent. >> + If not specified, hardware defaults will be used (91%). >> + - ilitek,gamma-correction-neg: a set of 8 nybbles describing negative >> + gamma correction for voltages V1 thru V8. Valid range 0..15 >> + - ilitek,gamma-correction-pos: a set of 8 nybbles describing positive >> + gamma correction for voltages V1 thru V8. Valid range 0..15 >> + These adjust what grayscale voltage will be output for input data V1 = 0, >> + V2 = 16, V3 = 48, V4 = 96, V5 = 160, V6 = 208, V7 = 240 and V8 = 255. >> + The curve is shaped like this: >> + >> + ^ >> + | V8 >> + | V7 >> + | V6 >> + | V5 >> + | V4 >> + | V3 >> + | V2 >> + | V1 >> + +-----------------------------------------------------------> >> + 0 16 48 96 160 208 240 255 >> + >> + The negative and postive gamma values adjust the V1 thru V8 up/down >> + according to the datasheet specifications. This is a property of the >> + physical display connected to the display controller and may vary. >> + If defined, both arrays must be supplied in full. If the properties >> + are not supplied, hardware defaults will be used. > > Normally, we the physical panel is described which would imply all these > settings. Are there lots of panels with this controller that would > justify all these settings? The datasheet for the ili9322 just says it "drives panels" essentially. Googling around gives at hand that it is used pretty frequently in Shenzhen China for adapting different off-the-shelf panels to different inputs. I can't really answer how many of these products that run one or another OS using device tree to describe the configuration. It feels more like I'm paving the road for others to travel. Probably other Ilitek panel adapters will need something similar. >> + - ilitek,entry-mode: the panel can be connected to various input streams >> + and four of them can be selected by electronic straps on the display. >> + However it is possible to select another mode or override the >> + electronic default with this property. Valid values: >> + 0: 8 bit serial RGB through >> + 1: 8 bit serial RGB aligned >> + 2: 8 bit serial RGB dummy 320x240 >> + 3: 8 bit serial RGB dummy 360x240 >> + 4: disabled >> + 5: 24 bit parallel RGB through >> + 6: 24 bit parallel RGB aligned >> + 7: 24 bit YUV 640Y 320CbCr >> + 8: 24 bit YUV 720Y 360CbCr >> + 9: disabled >> + 10: 8 bit ITU-R BT.656 720Y 360CbCr >> + 11: 8 bit ITU-R BT.656 640Y 320CbCr > > To some extent, we have some standard bindings to describe this. I don't find any. Maybe I'm looking in the wrong places :( These are closest associated with the DRM "media bus formats" in Linux include/uapi/linux/media-bus-format.h such as: #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE 0x1003 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE 0x1004 #define MEDIA_BUS_FMT_RGB565_1X16 0x1017 #define MEDIA_BUS_FMT_BGR565_2X8_BE 0x1005 #define MEDIA_BUS_FMT_BGR565_2X8_LE 0x1006 #define MEDIA_BUS_FMT_RGB565_2X8_BE 0x1007 #define MEDIA_BUS_FMT_RGB565_2X8_LE 0x1008 #define MEDIA_BUS_FMT_RGB666_1X18 0x1009 #define MEDIA_BUS_FMT_RBG888_1X24 0x100e #define MEDIA_BUS_FMT_RGB666_1X24_CPADHI 0x1015 #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG 0x1010 (...) We can surely regard this bus format list as standard and copy and extend it in DT (it does not have ITU-R formats for the moment) but I don't know if that is wise. Also the input modes of ili9322 is coupled with resolution so it would need two more cells or so for resolution so I feel it would over-complicate things for these 12 enumerators. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/3] drm/panel: Add DT bindings for Ilitek ILI9322 2017-09-02 21:17 ` Linus Walleij @ 2017-09-20 11:56 ` Linus Walleij 2017-09-24 20:36 ` Rob Herring 0 siblings, 1 reply; 9+ messages in thread From: Linus Walleij @ 2017-09-20 11:56 UTC (permalink / raw) To: Rob Herring, Thierry Reding Cc: devicetree@vger.kernel.org, Lee Jones, open list:DRM PANEL DRIVERS On Sat, Sep 2, 2017 at 11:17 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Thu, Aug 17, 2017 at 10:44 PM, Rob Herring <robh@kernel.org> wrote: >> On Sun, Aug 13, 2017 at 01:44:47PM +0200, Linus Walleij wrote: > >>> This adds device tree bindings for the Ilitek ILI9322 >>> 320x240 TFT panel driver. >>> >>> Cc: devicetree@vger.kernel.org >>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> > (...) >>> +Optional properties: >>> + - width-mm: physical panel width [mm] >>> + - height-mm: physical panel height [mm] >>> + - vcc-supply: core voltage supply, see regulator/regulator.txt >>> + - iovcc-supply: voltage supply for the interface input/output signals, >>> + see regulator/regulator.txt >>> + - vci-supply: voltage supply for analog parts, see regulator/regulator.txt >>> + - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt >>> + - ilitek,vreg1out-microvolt: the output in microvolts for the VREGOUT1 >>> + regulator used to drive the physical display. Valid ranges are 3600 thru >>> + 6000 in 100 microvolt increments. If not specified, hardware defaults will >>> + be used (4.5V). >>> + - ilitek,vcom-amplitude-percent: the percentage of VREGOUT1 used for the >>> + peak-to-peak amplitude of the communcation signals to the physical display. >>> + Valid ranges are 70 thru 132 percent in increments if two percent. Odd >>> + percentages will be truncated. If not specified, hardware defaults will be >>> + used (114%). >>> + - ilitek,vcom-high-percent: the percentage of VREGOUT1 used for the peak >>> + voltage on the communications link. Valid ranges are 37 thru 100 percent. >>> + If not specified, hardware defaults will be used (91%). >>> + - ilitek,gamma-correction-neg: a set of 8 nybbles describing negative >>> + gamma correction for voltages V1 thru V8. Valid range 0..15 >>> + - ilitek,gamma-correction-pos: a set of 8 nybbles describing positive >>> + gamma correction for voltages V1 thru V8. Valid range 0..15 >>> + These adjust what grayscale voltage will be output for input data V1 = 0, >>> + V2 = 16, V3 = 48, V4 = 96, V5 = 160, V6 = 208, V7 = 240 and V8 = 255. >>> + The curve is shaped like this: >>> + >>> + ^ >>> + | V8 >>> + | V7 >>> + | V6 >>> + | V5 >>> + | V4 >>> + | V3 >>> + | V2 >>> + | V1 >>> + +-----------------------------------------------------------> >>> + 0 16 48 96 160 208 240 255 >>> + >>> + The negative and postive gamma values adjust the V1 thru V8 up/down >>> + according to the datasheet specifications. This is a property of the >>> + physical display connected to the display controller and may vary. >>> + If defined, both arrays must be supplied in full. If the properties >>> + are not supplied, hardware defaults will be used. >> >> Normally, we the physical panel is described which would imply all these >> settings. Are there lots of panels with this controller that would >> justify all these settings? > > The datasheet for the ili9322 just says it "drives panels" essentially. > Googling around gives at hand that it is used pretty frequently in > Shenzhen China for adapting different off-the-shelf panels to > different inputs. > > I can't really answer how many of these products that run one or > another OS using device tree to describe the configuration. It feels more > like I'm paving the road for others to travel. > > Probably other Ilitek panel adapters will need something similar. > >>> + - ilitek,entry-mode: the panel can be connected to various input streams >>> + and four of them can be selected by electronic straps on the display. >>> + However it is possible to select another mode or override the >>> + electronic default with this property. Valid values: >>> + 0: 8 bit serial RGB through >>> + 1: 8 bit serial RGB aligned >>> + 2: 8 bit serial RGB dummy 320x240 >>> + 3: 8 bit serial RGB dummy 360x240 >>> + 4: disabled >>> + 5: 24 bit parallel RGB through >>> + 6: 24 bit parallel RGB aligned >>> + 7: 24 bit YUV 640Y 320CbCr >>> + 8: 24 bit YUV 720Y 360CbCr >>> + 9: disabled >>> + 10: 8 bit ITU-R BT.656 720Y 360CbCr >>> + 11: 8 bit ITU-R BT.656 640Y 320CbCr >> >> To some extent, we have some standard bindings to describe this. > > I don't find any. Maybe I'm looking in the wrong places :( > > These are closest associated with the DRM "media bus formats" > in Linux include/uapi/linux/media-bus-format.h > such as: > > #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 > #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE 0x1003 > #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE 0x1004 > #define MEDIA_BUS_FMT_RGB565_1X16 0x1017 > #define MEDIA_BUS_FMT_BGR565_2X8_BE 0x1005 > #define MEDIA_BUS_FMT_BGR565_2X8_LE 0x1006 > #define MEDIA_BUS_FMT_RGB565_2X8_BE 0x1007 > #define MEDIA_BUS_FMT_RGB565_2X8_LE 0x1008 > #define MEDIA_BUS_FMT_RGB666_1X18 0x1009 > #define MEDIA_BUS_FMT_RBG888_1X24 0x100e > #define MEDIA_BUS_FMT_RGB666_1X24_CPADHI 0x1015 > #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG 0x1010 > (...) > > We can surely regard this bus format list as standard and > copy and extend it in DT (it does not have ITU-R formats for > the moment) but I don't know if that is wise. > > Also the input modes of ili9322 is coupled with resolution so > it would need two more cells or so for resolution so I feel > it would over-complicate things for these 12 enumerators. Can we proceed with these patches? Any opinion from DT or panel maintainers? Yours, Linus Walleij _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/3] drm/panel: Add DT bindings for Ilitek ILI9322 2017-09-20 11:56 ` Linus Walleij @ 2017-09-24 20:36 ` Rob Herring 2017-09-30 23:42 ` Linus Walleij 0 siblings, 1 reply; 9+ messages in thread From: Rob Herring @ 2017-09-24 20:36 UTC (permalink / raw) To: Linus Walleij Cc: devicetree@vger.kernel.org, Thierry Reding, Lee Jones, open list:DRM PANEL DRIVERS On Wed, Sep 20, 2017 at 6:56 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Sat, Sep 2, 2017 at 11:17 PM, Linus Walleij <linus.walleij@linaro.org> wrote: >> On Thu, Aug 17, 2017 at 10:44 PM, Rob Herring <robh@kernel.org> wrote: >>> On Sun, Aug 13, 2017 at 01:44:47PM +0200, Linus Walleij wrote: >> >>>> This adds device tree bindings for the Ilitek ILI9322 >>>> 320x240 TFT panel driver. >>>> >>>> Cc: devicetree@vger.kernel.org >>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> >> (...) >>>> +Optional properties: >>>> + - width-mm: physical panel width [mm] >>>> + - height-mm: physical panel height [mm] >>>> + - vcc-supply: core voltage supply, see regulator/regulator.txt >>>> + - iovcc-supply: voltage supply for the interface input/output signals, >>>> + see regulator/regulator.txt >>>> + - vci-supply: voltage supply for analog parts, see regulator/regulator.txt >>>> + - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt >>>> + - ilitek,vreg1out-microvolt: the output in microvolts for the VREGOUT1 >>>> + regulator used to drive the physical display. Valid ranges are 3600 thru >>>> + 6000 in 100 microvolt increments. If not specified, hardware defaults will >>>> + be used (4.5V). >>>> + - ilitek,vcom-amplitude-percent: the percentage of VREGOUT1 used for the >>>> + peak-to-peak amplitude of the communcation signals to the physical display. >>>> + Valid ranges are 70 thru 132 percent in increments if two percent. Odd >>>> + percentages will be truncated. If not specified, hardware defaults will be >>>> + used (114%). >>>> + - ilitek,vcom-high-percent: the percentage of VREGOUT1 used for the peak >>>> + voltage on the communications link. Valid ranges are 37 thru 100 percent. >>>> + If not specified, hardware defaults will be used (91%). >>>> + - ilitek,gamma-correction-neg: a set of 8 nybbles describing negative >>>> + gamma correction for voltages V1 thru V8. Valid range 0..15 >>>> + - ilitek,gamma-correction-pos: a set of 8 nybbles describing positive >>>> + gamma correction for voltages V1 thru V8. Valid range 0..15 >>>> + These adjust what grayscale voltage will be output for input data V1 = 0, >>>> + V2 = 16, V3 = 48, V4 = 96, V5 = 160, V6 = 208, V7 = 240 and V8 = 255. >>>> + The curve is shaped like this: >>>> + >>>> + ^ >>>> + | V8 >>>> + | V7 >>>> + | V6 >>>> + | V5 >>>> + | V4 >>>> + | V3 >>>> + | V2 >>>> + | V1 >>>> + +-----------------------------------------------------------> >>>> + 0 16 48 96 160 208 240 255 >>>> + >>>> + The negative and postive gamma values adjust the V1 thru V8 up/down >>>> + according to the datasheet specifications. This is a property of the >>>> + physical display connected to the display controller and may vary. >>>> + If defined, both arrays must be supplied in full. If the properties >>>> + are not supplied, hardware defaults will be used. >>> >>> Normally, we the physical panel is described which would imply all these >>> settings. Are there lots of panels with this controller that would >>> justify all these settings? >> >> The datasheet for the ili9322 just says it "drives panels" essentially. >> Googling around gives at hand that it is used pretty frequently in >> Shenzhen China for adapting different off-the-shelf panels to >> different inputs. >> >> I can't really answer how many of these products that run one or >> another OS using device tree to describe the configuration. It feels more >> like I'm paving the road for others to travel. Not really a road I want to pave and encourage others. >> Probably other Ilitek panel adapters will need something similar. >> >>>> + - ilitek,entry-mode: the panel can be connected to various input streams >>>> + and four of them can be selected by electronic straps on the display. >>>> + However it is possible to select another mode or override the >>>> + electronic default with this property. Valid values: >>>> + 0: 8 bit serial RGB through >>>> + 1: 8 bit serial RGB aligned >>>> + 2: 8 bit serial RGB dummy 320x240 >>>> + 3: 8 bit serial RGB dummy 360x240 >>>> + 4: disabled >>>> + 5: 24 bit parallel RGB through >>>> + 6: 24 bit parallel RGB aligned >>>> + 7: 24 bit YUV 640Y 320CbCr >>>> + 8: 24 bit YUV 720Y 360CbCr >>>> + 9: disabled >>>> + 10: 8 bit ITU-R BT.656 720Y 360CbCr >>>> + 11: 8 bit ITU-R BT.656 640Y 320CbCr >>> >>> To some extent, we have some standard bindings to describe this. >> >> I don't find any. Maybe I'm looking in the wrong places :( I guess bus-width is all we have. Normally, this is all implied by the compatible strings of either the controller, panel or both. Another way to look at it is, we already have support for lots of panels and controllers. If those haven't needed to specify this information, then why do you? >> >> These are closest associated with the DRM "media bus formats" >> in Linux include/uapi/linux/media-bus-format.h >> such as: >> >> #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 >> #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 >> #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 >> #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE 0x1003 >> #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE 0x1004 >> #define MEDIA_BUS_FMT_RGB565_1X16 0x1017 >> #define MEDIA_BUS_FMT_BGR565_2X8_BE 0x1005 >> #define MEDIA_BUS_FMT_BGR565_2X8_LE 0x1006 >> #define MEDIA_BUS_FMT_RGB565_2X8_BE 0x1007 >> #define MEDIA_BUS_FMT_RGB565_2X8_LE 0x1008 >> #define MEDIA_BUS_FMT_RGB666_1X18 0x1009 >> #define MEDIA_BUS_FMT_RBG888_1X24 0x100e >> #define MEDIA_BUS_FMT_RGB666_1X24_CPADHI 0x1015 >> #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG 0x1010 >> (...) >> >> We can surely regard this bus format list as standard and >> copy and extend it in DT (it does not have ITU-R formats for >> the moment) but I don't know if that is wise. >> >> Also the input modes of ili9322 is coupled with resolution so >> it would need two more cells or so for resolution so I feel >> it would over-complicate things for these 12 enumerators. > > Can we proceed with these patches? > > Any opinion from DT or panel maintainers? You have my opinion. I don't think Thierry's will be different. My suggestion is to move the settings you need into the panel driver and out of DT. We can always move things to DT later if it makes sense. Rob _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/3] drm/panel: Add DT bindings for Ilitek ILI9322 2017-09-24 20:36 ` Rob Herring @ 2017-09-30 23:42 ` Linus Walleij [not found] ` <CACRpkdaP42pRR=M-QPQr5k-KDau-5zkA0UVY8O9DYf8czcY3Rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 9+ messages in thread From: Linus Walleij @ 2017-09-30 23:42 UTC (permalink / raw) To: Rob Herring Cc: devicetree@vger.kernel.org, Thierry Reding, Lee Jones, open list:DRM PANEL DRIVERS On Sun, Sep 24, 2017 at 10:36 PM, Rob Herring <robh@kernel.org> wrote: > On Wed, Sep 20, 2017 at 6:56 AM, Linus Walleij <linus.walleij@linaro.org> wrote: >> On Sat, Sep 2, 2017 at 11:17 PM, Linus Walleij <linus.walleij@linaro.org> wrote: >>>> Normally, we the physical panel is described which would imply all these >>>> settings. Are there lots of panels with this controller that would >>>> justify all these settings? >>> >>> The datasheet for the ili9322 just says it "drives panels" essentially. >>> Googling around gives at hand that it is used pretty frequently in >>> Shenzhen China for adapting different off-the-shelf panels to >>> different inputs. >>> >>> I can't really answer how many of these products that run one or >>> another OS using device tree to describe the configuration. It feels more >>> like I'm paving the road for others to travel. > > Not really a road I want to pave and encourage others. It's good when maintainers say "no"! :) >>>>> + - ilitek,entry-mode: the panel can be connected to various input streams >>>>> + and four of them can be selected by electronic straps on the display. >>>>> + However it is possible to select another mode or override the >>>>> + electronic default with this property. Valid values: >>>>> + 0: 8 bit serial RGB through >>>>> + 1: 8 bit serial RGB aligned >>>>> + 2: 8 bit serial RGB dummy 320x240 >>>>> + 3: 8 bit serial RGB dummy 360x240 >>>>> + 4: disabled >>>>> + 5: 24 bit parallel RGB through >>>>> + 6: 24 bit parallel RGB aligned >>>>> + 7: 24 bit YUV 640Y 320CbCr >>>>> + 8: 24 bit YUV 720Y 360CbCr >>>>> + 9: disabled >>>>> + 10: 8 bit ITU-R BT.656 720Y 360CbCr >>>>> + 11: 8 bit ITU-R BT.656 640Y 320CbCr >>>> >>>> To some extent, we have some standard bindings to describe this. >>> >>> I don't find any. Maybe I'm looking in the wrong places :( > > I guess bus-width is all we have. Normally, this is all implied by the > compatible strings of either the controller, panel or both. > > Another way to look at it is, we already have support for lots of > panels and controllers. If those haven't needed to specify this > information, then why do you? It's a question about devicetree vs driver configuration data altogether. An intuitive thing, gray area. Your intuition is likely better. I feel the same about the people who push too much pin control data into the device tree instead of the driver so I understand the issue. (If it is that.) >>> Also the input modes of ili9322 is coupled with resolution so >>> it would need two more cells or so for resolution so I feel >>> it would over-complicate things for these 12 enumerators. >> >> Can we proceed with these patches? >> >> Any opinion from DT or panel maintainers? > > You have my opinion. I don't think Thierry's will be different. > > My suggestion is to move the settings you need into the panel driver > and out of DT. We can always move things to DT later if it makes > sense. Sure thing. I will take the approach of compatible string like this: compatible = "ilitek,ili9322", "dlink,dir685-panel"; And use the latter compatible to set up all the stuff in the panel driver, what about that? Yours, Linus Walleij _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <CACRpkdaP42pRR=M-QPQr5k-KDau-5zkA0UVY8O9DYf8czcY3Rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH 2/3] drm/panel: Add DT bindings for Ilitek ILI9322 [not found] ` <CACRpkdaP42pRR=M-QPQr5k-KDau-5zkA0UVY8O9DYf8czcY3Rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2017-10-01 15:15 ` Rob Herring 0 siblings, 0 replies; 9+ messages in thread From: Rob Herring @ 2017-10-01 15:15 UTC (permalink / raw) To: Linus Walleij Cc: Thierry Reding, open list:DRM PANEL DRIVERS, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Lee Jones On Sat, Sep 30, 2017 at 6:42 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > On Sun, Sep 24, 2017 at 10:36 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: >> On Wed, Sep 20, 2017 at 6:56 AM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >>> On Sat, Sep 2, 2017 at 11:17 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > >>>>> Normally, we the physical panel is described which would imply all these >>>>> settings. Are there lots of panels with this controller that would >>>>> justify all these settings? >>>> >>>> The datasheet for the ili9322 just says it "drives panels" essentially. >>>> Googling around gives at hand that it is used pretty frequently in >>>> Shenzhen China for adapting different off-the-shelf panels to >>>> different inputs. >>>> >>>> I can't really answer how many of these products that run one or >>>> another OS using device tree to describe the configuration. It feels more >>>> like I'm paving the road for others to travel. >> >> Not really a road I want to pave and encourage others. > > It's good when maintainers say "no"! :) Only other maintainers think so. :) >>>>>> + - ilitek,entry-mode: the panel can be connected to various input streams >>>>>> + and four of them can be selected by electronic straps on the display. >>>>>> + However it is possible to select another mode or override the >>>>>> + electronic default with this property. Valid values: >>>>>> + 0: 8 bit serial RGB through >>>>>> + 1: 8 bit serial RGB aligned >>>>>> + 2: 8 bit serial RGB dummy 320x240 >>>>>> + 3: 8 bit serial RGB dummy 360x240 >>>>>> + 4: disabled >>>>>> + 5: 24 bit parallel RGB through >>>>>> + 6: 24 bit parallel RGB aligned >>>>>> + 7: 24 bit YUV 640Y 320CbCr >>>>>> + 8: 24 bit YUV 720Y 360CbCr >>>>>> + 9: disabled >>>>>> + 10: 8 bit ITU-R BT.656 720Y 360CbCr >>>>>> + 11: 8 bit ITU-R BT.656 640Y 320CbCr >>>>> >>>>> To some extent, we have some standard bindings to describe this. >>>> >>>> I don't find any. Maybe I'm looking in the wrong places :( >> >> I guess bus-width is all we have. Normally, this is all implied by the >> compatible strings of either the controller, panel or both. >> >> Another way to look at it is, we already have support for lots of >> panels and controllers. If those haven't needed to specify this >> information, then why do you? > > It's a question about devicetree vs driver configuration data altogether. > An intuitive thing, gray area. Your intuition is likely better. > > I feel the same about the people who push too much pin control > data into the device tree instead of the driver so I understand the > issue. (If it is that.) Yes, that's it. We don't want bindings that try to parameterize *everything* in "generic" bindings. >>>> Also the input modes of ili9322 is coupled with resolution so >>>> it would need two more cells or so for resolution so I feel >>>> it would over-complicate things for these 12 enumerators. >>> >>> Can we proceed with these patches? >>> >>> Any opinion from DT or panel maintainers? >> >> You have my opinion. I don't think Thierry's will be different. >> >> My suggestion is to move the settings you need into the panel driver >> and out of DT. We can always move things to DT later if it makes >> sense. > > Sure thing. I will take the approach of compatible string like this: > > compatible = "ilitek,ili9322", "dlink,dir685-panel"; > > And use the latter compatible to set up all the stuff in the panel > driver, what about that? Sounds good, but you need to reverse the order here. Most specific first. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3] dt-bindings: Add Ilitek vendor ID [not found] ` <20170813114448.20179-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2017-08-13 11:44 ` [PATCH 2/3] drm/panel: Add DT bindings for Ilitek ILI9322 Linus Walleij @ 2017-08-17 20:35 ` Rob Herring 1 sibling, 0 replies; 9+ messages in thread From: Rob Herring @ 2017-08-17 20:35 UTC (permalink / raw) To: Linus Walleij Cc: Thierry Reding, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, devicetree-u79uwXL29TY76Z2rM5mHXA On Sun, Aug 13, 2017 at 01:44:46PM +0200, Linus Walleij wrote: > Ili Technology Corporation (Ilitek) is a vendor of display drivers > and touch input controllers for embedded devices. > > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-10-01 15:15 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-08-13 11:44 [PATCH 1/3] dt-bindings: Add Ilitek vendor ID Linus Walleij [not found] ` <20170813114448.20179-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2017-08-13 11:44 ` [PATCH 2/3] drm/panel: Add DT bindings for Ilitek ILI9322 Linus Walleij [not found] ` <20170813114448.20179-2-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2017-08-17 20:44 ` Rob Herring 2017-09-02 21:17 ` Linus Walleij 2017-09-20 11:56 ` Linus Walleij 2017-09-24 20:36 ` Rob Herring 2017-09-30 23:42 ` Linus Walleij [not found] ` <CACRpkdaP42pRR=M-QPQr5k-KDau-5zkA0UVY8O9DYf8czcY3Rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-10-01 15:15 ` Rob Herring 2017-08-17 20:35 ` [PATCH 1/3] dt-bindings: Add Ilitek vendor ID Rob Herring
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).