On Wed, Sep 20, 2017 at 6:56 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Sat, Sep 2, 2017 at 11:17 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> On Thu, Aug 17, 2017 at 10:44 PM, Rob Herring <robh@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx >>>> Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx> >> (...) >>>> +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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
