| Message ID | 20170813114448.20179-2-linus.walleij@linaro.org |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
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> > --- > .../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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Sep 30, 2017 at 6:42 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > 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"! :) 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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>; + }; + }; +};
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> --- .../bindings/display/panel/ilitek,ili9322.txt | 120 +++++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt