Message ID | 20230525093151.2338370-5-yangcong5@huaqin.corp-partner.google.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Support Starry-himax83102-j02 and Starry-ili9882t TDDI MIPI-DSI panel | expand |
Hi, On Thu, May 25, 2023 at 2:32 AM Cong Yang <yangcong5@huaqin.corp-partner.google.com> wrote: > > The Starry-ili9882 is a 10.51" WUXGA TFT panel. which fits in nicely with > the existing panel-boe-tv101wum-nl6 driver. From the datasheet,MIPI need > to keep the LP11 state before the lcm_reset pin is pulled high. So add > lp11_before_reset flag. > > Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com> > Reviewed-by: Douglas Anderson <dianders@chromium.org> > --- > .../gpu/drm/panel/panel-boe-tv101wum-nl6.c | 371 ++++++++++++++++++ > 1 file changed, 371 insertions(+) Applied to drm-misc-next: 8716a6473e6c drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel
On Thu, Jun 1, 2023 at 5:55 PM Doug Anderson <dianders@google.com> wrote: > On Thu, May 25, 2023 at 2:32 AM Cong Yang > <yangcong5@huaqin.corp-partner.google.com> wrote: > > > > The Starry-ili9882 is a 10.51" WUXGA TFT panel. which fits in nicely with > > the existing panel-boe-tv101wum-nl6 driver. From the datasheet,MIPI need > > to keep the LP11 state before the lcm_reset pin is pulled high. So add > > lp11_before_reset flag. > > > > Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com> > > Reviewed-by: Douglas Anderson <dianders@chromium.org> > > --- > > .../gpu/drm/panel/panel-boe-tv101wum-nl6.c | 371 ++++++++++++++++++ > > 1 file changed, 371 insertions(+) > > Applied to drm-misc-next: > > 8716a6473e6c drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel Sorry for noticing too late and coming after the fact and complaining. We must stop using the panel-boe-tv101wum-nl6.c driver as a one-stop-shop for Chromium panels. The Starry panel in particular hardware-wise has nothing in common with the other panels in this driver and I'm suspicious about patch 3/4 as well. Please check my patch breaking it out to a separate driver, and if you could check internally if you have a datasheet for Ilitek ILI9882t or can use your vendor leverage to get one to improve on the driver (such as define the DCS commands...) that would be great. There are good reasons for grouping the panel drivers into respective display controller such as fixing bugs in one place and if we ever want to properly support things such as gamma correction it will provide the proper per-display-controller approach. Yours, Linus Walleij
Hi, On Tue, Jul 4, 2023 at 12:47 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Thu, Jun 1, 2023 at 5:55 PM Doug Anderson <dianders@google.com> wrote: > > On Thu, May 25, 2023 at 2:32 AM Cong Yang > > <yangcong5@huaqin.corp-partner.google.com> wrote: > > > > > > The Starry-ili9882 is a 10.51" WUXGA TFT panel. which fits in nicely with > > > the existing panel-boe-tv101wum-nl6 driver. From the datasheet,MIPI need > > > to keep the LP11 state before the lcm_reset pin is pulled high. So add > > > lp11_before_reset flag. > > > > > > Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com> > > > Reviewed-by: Douglas Anderson <dianders@chromium.org> > > > --- > > > .../gpu/drm/panel/panel-boe-tv101wum-nl6.c | 371 ++++++++++++++++++ > > > 1 file changed, 371 insertions(+) > > > > Applied to drm-misc-next: > > > > 8716a6473e6c drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel > > Sorry for noticing too late and coming after the fact and complaining. > > We must stop using the panel-boe-tv101wum-nl6.c driver as a > one-stop-shop for Chromium panels. The Starry panel in particular > hardware-wise has nothing in common with the other panels in this > driver and I'm suspicious about patch 3/4 as well. > > Please check my patch breaking it out to a separate driver, and > if you could check internally if you have a datasheet for Ilitek > ILI9882t or can use your vendor leverage to get one to improve > on the driver (such as define the DCS commands...) that would > be great. > > There are good reasons for grouping the panel drivers into > respective display controller such as fixing bugs in one place > and if we ever want to properly support things such as > gamma correction it will provide the proper per-display-controller > approach. I mentioned in response to your patch #3 also [1], but closing the loop here as well. The original reason several panels all ended up in one driver was in response to Sam's feedback [2]. That was even documented when the first of the "Chromium" panels landed in commit 93ee1a2c0f08 ("drm/panel: support for BOE and INX video mode panel"). In my mind it's really a tradeoff and I'm happy to go with whatever consensus that others agree with. What I'm never super happy with, though, is changing the bikeshed color too often, so I'd be really curious to hear Sam's thoughts on the issue and whether he'd like to see this driver broken out into a dozen drivers. [1] https://lore.kernel.org/r/CAD=FV=Xkr3Qpd8m_6Xta_2jL_ezbxsmMyarbKXTXL+UJLG9xNw@mail.gmail.com [2] https://lore.kernel.org/all/YSPAseE6WD8dDRuz@ravnborg.org/
On Thu, Jul 6, 2023 at 11:25 PM Doug Anderson <dianders@google.com> wrote: > In my mind it's really a tradeoff and I'm happy to go with whatever > consensus that others agree with. What I'm never super happy with, > though, is changing the bikeshed color too often, so I'd be really > curious to hear Sam's thoughts on the issue and whether he'd like to > see this driver broken out into a dozen drivers. This is not question about a dozen drivers, to be clear. I just want to break out the drivers that have an identifiable display controller that differs from the others, especially this one. The rest of the drivers inside of this boe driver I can't really tell, they seem related? We don't know? So the Ilitek ILI9882t is an obvious break-out. For the rest, I guess I would be happier if the Chromium people could use their leverage with vendors to muscle out the details about display controller vendors and provide #defines for all magic commands, we all dislike these opaque firmware-looking jam tables. Cong already stated that he indeed has the datasheet for the ILI9882t controller at hand, had I come in earlier I would have asked for all of those sequences to be provided with proper #defines instead of 0xff 0x98 0x82 0x01... but I'm late to the show. Yours, Linus Walleij
Hi, On Thu, Jul 6, 2023 at 2:36 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Thu, Jul 6, 2023 at 11:25 PM Doug Anderson <dianders@google.com> wrote: > > > In my mind it's really a tradeoff and I'm happy to go with whatever > > consensus that others agree with. What I'm never super happy with, > > though, is changing the bikeshed color too often, so I'd be really > > curious to hear Sam's thoughts on the issue and whether he'd like to > > see this driver broken out into a dozen drivers. > > This is not question about a dozen drivers, to be clear. > > I just want to break out the drivers that have an identifiable > display controller that differs from the others, especially this one. > > The rest of the drivers inside of this boe driver I can't really tell, > they seem related? We don't know? > > So the Ilitek ILI9882t is an obvious break-out. I guess. To me it feels like the concept of breaking the driver into multiple sub-drivers and the idea of supporting ILI9882t more cleanly are orthogonal. You could still do your patch #4 and break out the page switching function without breaking up the driver. It feels to me fairly likely that many of the panels here are just as different from each other as the ILI9882t is from them. I guess it's not a dozen, but it feels like using the same "how different are they from each other" metric we'd end up with at least 5-6 new drivers. It seems clear to me that the panel that Sam first commented on is as different from the others in the BOE driver as the ILI9882t is. Certainly it has a pretty darn big unique command sequence for init... > For the rest, I guess I would be happier if the Chromium people > could use their leverage with vendors to muscle out the details > about display controller vendors and provide #defines for all > magic commands, we all dislike these opaque firmware-looking > jam tables. Yeah, I've grumbled about this with each new blob added. For instance: https://lore.kernel.org/r/CAD=FV=Uo-7rFWGiJG0oJ0ydosA4DxhFqiWGrab1zoZyxyPsOBg@mail.gmail.com/ Where I said: > I'm not really an expert on > MIPI panels but the convention of a big stream of binary commands > seems to match what other panels in this driver do, even if their > table of binary data isn't quite as long as yours (are all of yours > actually needed?) The problem is that it's hard for me to make a strong argument here when there is prior art of panels being supported with blob-sequences. In this case, I think you as an upstream developer have more leverage. I can help put pressure to make sure that upstream concerns are addressed, but I think it's on upstream to put their foot down and say that these blob sequences are not OK for new panels. In each case I landed a patch with a new blob sequence I tried to give the community time to respond and I tried to telegraph what I was going to do to make sure nobody was surprised... -Doug
On Thu, Jul 6, 2023 at 11:58 PM Doug Anderson <dianders@google.com> wrote: > > So the Ilitek ILI9882t is an obvious break-out. > > I guess. To me it feels like the concept of breaking the driver into > multiple sub-drivers and the idea of supporting ILI9882t more cleanly > are orthogonal. You could still do your patch #4 and break out the > page switching function without breaking up the driver. Yeah that's true. But with Ilitek in particular we have these nice precedents: drivers/gpu/drm/panel/panel-ilitek-ili9322.c drivers/gpu/drm/panel/panel-ilitek-ili9341.c drivers/gpu/drm/panel/panel-ilitek-ili9881c.c So it looks disorganized to me if this one Ilitek panel controller now goes inside another driver with other completely unrelated drivers. > It feels to me fairly likely that many of the panels here are just as > different from each other as the ILI9882t is from them. I guess it's > not a dozen, but it feels like using the same "how different are they > from each other" metric we'd end up with at least 5-6 new drivers. It > seems clear to me that the panel that Sam first commented on is as > different from the others in the BOE driver as the ILI9882t is. > Certainly it has a pretty darn big unique command sequence for init... It doesn't really matter until we can say certainly what display controller each of them is. It seems we can't, but for this one we can. > The problem is that it's hard for me to make a strong argument here > when there is prior art of panels being supported with blob-sequences. > In this case, I think you as an upstream developer have more leverage. > I can help put pressure to make sure that upstream concerns are > addressed, but I think it's on upstream to put their foot down and say > that these blob sequences are not OK for new panels. In each case I > landed a patch with a new blob sequence I tried to give the community > time to respond and I tried to telegraph what I was going to do to > make sure nobody was surprised... I would say it is not fair to block driver coming from hobbyists or minor vendors just trying to make something work. In general I think a working something is better than nothing so I wouldn't block anything. But with big companies who actually talk to Ilitek, Novotek and the other companies ending with -tek that make these display controllers I would certainly like to send the message that datasheets and proper defines would be appreciated, and say it is also for their best, because I mentioned proper gamma correction is possible if the driver author just invest time and works with the DRM community and that should be in their best interest. Feel free to pass this along the supply chain if you can. Yours, Linus Walleij
Hi all, On Thu, Jul 06, 2023 at 02:25:16PM -0700, Doug Anderson wrote: > Hi, > > On Tue, Jul 4, 2023 at 12:47 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > > > On Thu, Jun 1, 2023 at 5:55 PM Doug Anderson <dianders@google.com> wrote: > > > On Thu, May 25, 2023 at 2:32 AM Cong Yang > > > <yangcong5@huaqin.corp-partner.google.com> wrote: > > > > > > > > The Starry-ili9882 is a 10.51" WUXGA TFT panel. which fits in nicely with > > > > the existing panel-boe-tv101wum-nl6 driver. From the datasheet,MIPI need > > > > to keep the LP11 state before the lcm_reset pin is pulled high. So add > > > > lp11_before_reset flag. > > > > > > > > Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com> > > > > Reviewed-by: Douglas Anderson <dianders@chromium.org> > > > > --- > > > > .../gpu/drm/panel/panel-boe-tv101wum-nl6.c | 371 ++++++++++++++++++ > > > > 1 file changed, 371 insertions(+) > > > > > > Applied to drm-misc-next: > > > > > > 8716a6473e6c drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel > > > > Sorry for noticing too late and coming after the fact and complaining. > > > > We must stop using the panel-boe-tv101wum-nl6.c driver as a > > one-stop-shop for Chromium panels. The Starry panel in particular > > hardware-wise has nothing in common with the other panels in this > > driver and I'm suspicious about patch 3/4 as well. > > > > Please check my patch breaking it out to a separate driver, and > > if you could check internally if you have a datasheet for Ilitek > > ILI9882t or can use your vendor leverage to get one to improve > > on the driver (such as define the DCS commands...) that would > > be great. > > > > There are good reasons for grouping the panel drivers into > > respective display controller such as fixing bugs in one place > > and if we ever want to properly support things such as > > gamma correction it will provide the proper per-display-controller > > approach. > > I mentioned in response to your patch #3 also [1], but closing the > loop here as well. The original reason several panels all ended up in > one driver was in response to Sam's feedback [2]. That was even > documented when the first of the "Chromium" panels landed in commit > 93ee1a2c0f08 ("drm/panel: support for BOE and INX video mode panel"). If we should go with any sort of guideline then one-driver-per-controller. So we do not mix display controllers in one driver, but we can have different panels in one driver. Then there may be two almost identical controllers that can share the same driver, or there can be controllers used in two different ways so they warrant independent drivers. In other words this should be used with common sense. And if someone can help naming all the magic constant that would be super. Sam
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c index 0772d96e446c..720b77964fcf 100644 --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c @@ -1370,6 +1370,346 @@ static const struct panel_init_cmd starry_himax83102_j02_init_cmd[] = { {}, }; +static const struct panel_init_cmd starry_ili9882t_init_cmd[] = { + _INIT_DELAY_CMD(5), + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x01), + _INIT_DCS_CMD(0x00, 0x42), + _INIT_DCS_CMD(0x01, 0x11), + _INIT_DCS_CMD(0x02, 0x00), + _INIT_DCS_CMD(0x03, 0x00), + + _INIT_DCS_CMD(0x04, 0x01), + _INIT_DCS_CMD(0x05, 0x11), + _INIT_DCS_CMD(0x06, 0x00), + _INIT_DCS_CMD(0x07, 0x00), + + _INIT_DCS_CMD(0x08, 0x80), + _INIT_DCS_CMD(0x09, 0x81), + _INIT_DCS_CMD(0x0A, 0x71), + _INIT_DCS_CMD(0x0B, 0x00), + + _INIT_DCS_CMD(0x0C, 0x00), + _INIT_DCS_CMD(0x0E, 0x1A), + + _INIT_DCS_CMD(0x24, 0x00), + _INIT_DCS_CMD(0x25, 0x00), + _INIT_DCS_CMD(0x26, 0x00), + _INIT_DCS_CMD(0x27, 0x00), + + _INIT_DCS_CMD(0x2C, 0xD4), + _INIT_DCS_CMD(0xB9, 0x40), + + _INIT_DCS_CMD(0xB0, 0x11), + + _INIT_DCS_CMD(0xE6, 0x32), + _INIT_DCS_CMD(0xD1, 0x30), + + _INIT_DCS_CMD(0xD6, 0x55), + + _INIT_DCS_CMD(0xD0, 0x01), + _INIT_DCS_CMD(0xE3, 0x93), + _INIT_DCS_CMD(0xE4, 0x00), + _INIT_DCS_CMD(0xE5, 0x80), + + _INIT_DCS_CMD(0x31, 0x07), + _INIT_DCS_CMD(0x32, 0x07), + _INIT_DCS_CMD(0x33, 0x07), + _INIT_DCS_CMD(0x34, 0x07), + _INIT_DCS_CMD(0x35, 0x07), + _INIT_DCS_CMD(0x36, 0x01), + _INIT_DCS_CMD(0x37, 0x00), + _INIT_DCS_CMD(0x38, 0x28), + _INIT_DCS_CMD(0x39, 0x29), + _INIT_DCS_CMD(0x3A, 0x11), + _INIT_DCS_CMD(0x3B, 0x13), + _INIT_DCS_CMD(0x3C, 0x15), + _INIT_DCS_CMD(0x3D, 0x17), + _INIT_DCS_CMD(0x3E, 0x09), + _INIT_DCS_CMD(0x3F, 0x0D), + _INIT_DCS_CMD(0x40, 0x02), + _INIT_DCS_CMD(0x41, 0x02), + _INIT_DCS_CMD(0x42, 0x02), + _INIT_DCS_CMD(0x43, 0x02), + _INIT_DCS_CMD(0x44, 0x02), + _INIT_DCS_CMD(0x45, 0x02), + _INIT_DCS_CMD(0x46, 0x02), + + _INIT_DCS_CMD(0x47, 0x07), + _INIT_DCS_CMD(0x48, 0x07), + _INIT_DCS_CMD(0x49, 0x07), + _INIT_DCS_CMD(0x4A, 0x07), + _INIT_DCS_CMD(0x4B, 0x07), + _INIT_DCS_CMD(0x4C, 0x01), + _INIT_DCS_CMD(0x4D, 0x00), + _INIT_DCS_CMD(0x4E, 0x28), + _INIT_DCS_CMD(0x4F, 0x29), + _INIT_DCS_CMD(0x50, 0x10), + _INIT_DCS_CMD(0x51, 0x12), + _INIT_DCS_CMD(0x52, 0x14), + _INIT_DCS_CMD(0x53, 0x16), + _INIT_DCS_CMD(0x54, 0x08), + _INIT_DCS_CMD(0x55, 0x0C), + _INIT_DCS_CMD(0x56, 0x02), + _INIT_DCS_CMD(0x57, 0x02), + _INIT_DCS_CMD(0x58, 0x02), + _INIT_DCS_CMD(0x59, 0x02), + _INIT_DCS_CMD(0x5A, 0x02), + _INIT_DCS_CMD(0x5B, 0x02), + _INIT_DCS_CMD(0x5C, 0x02), + + _INIT_DCS_CMD(0x61, 0x07), + _INIT_DCS_CMD(0x62, 0x07), + _INIT_DCS_CMD(0x63, 0x07), + _INIT_DCS_CMD(0x64, 0x07), + _INIT_DCS_CMD(0x65, 0x07), + _INIT_DCS_CMD(0x66, 0x01), + _INIT_DCS_CMD(0x67, 0x00), + _INIT_DCS_CMD(0x68, 0x28), + _INIT_DCS_CMD(0x69, 0x29), + _INIT_DCS_CMD(0x6A, 0x16), + _INIT_DCS_CMD(0x6B, 0x14), + _INIT_DCS_CMD(0x6C, 0x12), + _INIT_DCS_CMD(0x6D, 0x10), + _INIT_DCS_CMD(0x6E, 0x0C), + _INIT_DCS_CMD(0x6F, 0x08), + _INIT_DCS_CMD(0x70, 0x02), + _INIT_DCS_CMD(0x71, 0x02), + _INIT_DCS_CMD(0x72, 0x02), + _INIT_DCS_CMD(0x73, 0x02), + _INIT_DCS_CMD(0x74, 0x02), + _INIT_DCS_CMD(0x75, 0x02), + _INIT_DCS_CMD(0x76, 0x02), + + _INIT_DCS_CMD(0x77, 0x07), + _INIT_DCS_CMD(0x78, 0x07), + _INIT_DCS_CMD(0x79, 0x07), + _INIT_DCS_CMD(0x7A, 0x07), + _INIT_DCS_CMD(0x7B, 0x07), + _INIT_DCS_CMD(0x7C, 0x01), + _INIT_DCS_CMD(0x7D, 0x00), + _INIT_DCS_CMD(0x7E, 0x28), + _INIT_DCS_CMD(0x7F, 0x29), + _INIT_DCS_CMD(0x80, 0x17), + _INIT_DCS_CMD(0x81, 0x15), + _INIT_DCS_CMD(0x82, 0x13), + _INIT_DCS_CMD(0x83, 0x11), + _INIT_DCS_CMD(0x84, 0x0D), + _INIT_DCS_CMD(0x85, 0x09), + _INIT_DCS_CMD(0x86, 0x02), + _INIT_DCS_CMD(0x87, 0x07), + _INIT_DCS_CMD(0x88, 0x07), + _INIT_DCS_CMD(0x89, 0x07), + _INIT_DCS_CMD(0x8A, 0x07), + _INIT_DCS_CMD(0x8B, 0x07), + _INIT_DCS_CMD(0x8C, 0x07), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x02), + _INIT_DCS_CMD(0x29, 0x3A), + _INIT_DCS_CMD(0x2A, 0x3B), + + _INIT_DCS_CMD(0x06, 0x01), + _INIT_DCS_CMD(0x07, 0x01), + _INIT_DCS_CMD(0x08, 0x0C), + _INIT_DCS_CMD(0x09, 0x44), + + _INIT_DCS_CMD(0x3C, 0x0A), + _INIT_DCS_CMD(0x39, 0x11), + _INIT_DCS_CMD(0x3D, 0x00), + _INIT_DCS_CMD(0x3A, 0x0C), + _INIT_DCS_CMD(0x3B, 0x44), + + _INIT_DCS_CMD(0x53, 0x1F), + _INIT_DCS_CMD(0x5E, 0x40), + _INIT_DCS_CMD(0x84, 0x00), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x03), + _INIT_DCS_CMD(0x20, 0x01), + _INIT_DCS_CMD(0x21, 0x3C), + _INIT_DCS_CMD(0x22, 0xFA), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x0A), + _INIT_DCS_CMD(0xE0, 0x01), + _INIT_DCS_CMD(0xE2, 0x01), + _INIT_DCS_CMD(0xE5, 0x91), + _INIT_DCS_CMD(0xE6, 0x3C), + _INIT_DCS_CMD(0xE7, 0x00), + _INIT_DCS_CMD(0xE8, 0xFA), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x12), + _INIT_DCS_CMD(0x87, 0x2C), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x05), + _INIT_DCS_CMD(0x73, 0xE5), + _INIT_DCS_CMD(0x7F, 0x6B), + _INIT_DCS_CMD(0x6D, 0xA4), + _INIT_DCS_CMD(0x79, 0x54), + _INIT_DCS_CMD(0x69, 0x97), + _INIT_DCS_CMD(0x6A, 0x97), + _INIT_DCS_CMD(0xA5, 0x3F), + _INIT_DCS_CMD(0x61, 0xDA), + _INIT_DCS_CMD(0xA7, 0xF1), + _INIT_DCS_CMD(0x5F, 0x01), + _INIT_DCS_CMD(0x62, 0x3F), + _INIT_DCS_CMD(0x1D, 0x90), + _INIT_DCS_CMD(0x86, 0x87), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x06), + _INIT_DCS_CMD(0xC0, 0x80), + _INIT_DCS_CMD(0xC1, 0x07), + _INIT_DCS_CMD(0xCA, 0x58), + _INIT_DCS_CMD(0xCB, 0x02), + _INIT_DCS_CMD(0xCE, 0x58), + _INIT_DCS_CMD(0xCF, 0x02), + _INIT_DCS_CMD(0x67, 0x60), + _INIT_DCS_CMD(0x10, 0x00), + _INIT_DCS_CMD(0x92, 0x22), + _INIT_DCS_CMD(0xD3, 0x08), + _INIT_DCS_CMD(0xD6, 0x55), + _INIT_DCS_CMD(0xDC, 0x38), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x08), + _INIT_DCS_CMD(0xE0, 0x00, 0x10, 0x2A, 0x4D, 0x61, 0x56, 0x6A, 0x6E, 0x79, 0x76, 0x8F, 0x95, 0x98, 0xAE, 0xAA, 0xB2, 0xBB, 0xCE, 0xC6, 0xBD, 0xD5, 0xE2, 0xE8), + _INIT_DCS_CMD(0xE1, 0x00, 0x10, 0x2A, 0x4D, 0x61, 0x56, 0x6A, 0x6E, 0x79, 0x76, 0x8F, 0x95, 0x98, 0xAE, 0xAA, 0xB2, 0xBB, 0xCE, 0xC6, 0xBD, 0xD5, 0xE2, 0xE8), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x04), + _INIT_DCS_CMD(0xBA, 0x81), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x0C), + _INIT_DCS_CMD(0x00, 0x02), + _INIT_DCS_CMD(0x01, 0x00), + _INIT_DCS_CMD(0x02, 0x03), + _INIT_DCS_CMD(0x03, 0x01), + _INIT_DCS_CMD(0x04, 0x03), + _INIT_DCS_CMD(0x05, 0x02), + _INIT_DCS_CMD(0x06, 0x04), + _INIT_DCS_CMD(0x07, 0x03), + _INIT_DCS_CMD(0x08, 0x03), + _INIT_DCS_CMD(0x09, 0x04), + _INIT_DCS_CMD(0x0A, 0x04), + _INIT_DCS_CMD(0x0B, 0x05), + _INIT_DCS_CMD(0x0C, 0x04), + _INIT_DCS_CMD(0x0D, 0x06), + _INIT_DCS_CMD(0x0E, 0x05), + _INIT_DCS_CMD(0x0F, 0x07), + _INIT_DCS_CMD(0x10, 0x04), + _INIT_DCS_CMD(0x11, 0x08), + _INIT_DCS_CMD(0x12, 0x05), + _INIT_DCS_CMD(0x13, 0x09), + _INIT_DCS_CMD(0x14, 0x05), + _INIT_DCS_CMD(0x15, 0x0A), + _INIT_DCS_CMD(0x16, 0x06), + _INIT_DCS_CMD(0x17, 0x0B), + _INIT_DCS_CMD(0x18, 0x05), + _INIT_DCS_CMD(0x19, 0x0C), + _INIT_DCS_CMD(0x1A, 0x06), + _INIT_DCS_CMD(0x1B, 0x0D), + _INIT_DCS_CMD(0x1C, 0x06), + _INIT_DCS_CMD(0x1D, 0x0E), + _INIT_DCS_CMD(0x1E, 0x07), + _INIT_DCS_CMD(0x1F, 0x0F), + _INIT_DCS_CMD(0x20, 0x06), + _INIT_DCS_CMD(0x21, 0x10), + _INIT_DCS_CMD(0x22, 0x07), + _INIT_DCS_CMD(0x23, 0x11), + _INIT_DCS_CMD(0x24, 0x07), + _INIT_DCS_CMD(0x25, 0x12), + _INIT_DCS_CMD(0x26, 0x08), + _INIT_DCS_CMD(0x27, 0x13), + _INIT_DCS_CMD(0x28, 0x07), + _INIT_DCS_CMD(0x29, 0x14), + _INIT_DCS_CMD(0x2A, 0x08), + _INIT_DCS_CMD(0x2B, 0x15), + _INIT_DCS_CMD(0x2C, 0x08), + _INIT_DCS_CMD(0x2D, 0x16), + _INIT_DCS_CMD(0x2E, 0x09), + _INIT_DCS_CMD(0x2F, 0x17), + _INIT_DCS_CMD(0x30, 0x08), + _INIT_DCS_CMD(0x31, 0x18), + _INIT_DCS_CMD(0x32, 0x09), + _INIT_DCS_CMD(0x33, 0x19), + _INIT_DCS_CMD(0x34, 0x09), + _INIT_DCS_CMD(0x35, 0x1A), + _INIT_DCS_CMD(0x36, 0x0A), + _INIT_DCS_CMD(0x37, 0x1B), + _INIT_DCS_CMD(0x38, 0x0A), + _INIT_DCS_CMD(0x39, 0x1C), + _INIT_DCS_CMD(0x3A, 0x0A), + _INIT_DCS_CMD(0x3B, 0x1D), + _INIT_DCS_CMD(0x3C, 0x0A), + _INIT_DCS_CMD(0x3D, 0x1E), + _INIT_DCS_CMD(0x3E, 0x0A), + _INIT_DCS_CMD(0x3F, 0x1F), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x04), + _INIT_DCS_CMD(0xBA, 0x01), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x0E), + _INIT_DCS_CMD(0x02, 0x0C), + _INIT_DCS_CMD(0x20, 0x10), + _INIT_DCS_CMD(0x25, 0x16), + _INIT_DCS_CMD(0x26, 0xE0), + _INIT_DCS_CMD(0x27, 0x00), + _INIT_DCS_CMD(0x29, 0x71), + _INIT_DCS_CMD(0x2A, 0x46), + _INIT_DCS_CMD(0x2B, 0x1F), + _INIT_DCS_CMD(0x2D, 0xC7), + _INIT_DCS_CMD(0x31, 0x02), + _INIT_DCS_CMD(0x32, 0xDF), + _INIT_DCS_CMD(0x33, 0x5A), + _INIT_DCS_CMD(0x34, 0xC0), + _INIT_DCS_CMD(0x35, 0x5A), + _INIT_DCS_CMD(0x36, 0xC0), + _INIT_DCS_CMD(0x38, 0x65), + _INIT_DCS_CMD(0x80, 0x3E), + _INIT_DCS_CMD(0x81, 0xA0), + _INIT_DCS_CMD(0xB0, 0x01), + _INIT_DCS_CMD(0xB1, 0xCC), + _INIT_DCS_CMD(0xC0, 0x12), + _INIT_DCS_CMD(0xC2, 0xCC), + _INIT_DCS_CMD(0xC3, 0xCC), + _INIT_DCS_CMD(0xC4, 0xCC), + _INIT_DCS_CMD(0xC5, 0xCC), + _INIT_DCS_CMD(0xC6, 0xCC), + _INIT_DCS_CMD(0xC7, 0xCC), + _INIT_DCS_CMD(0xC8, 0xCC), + _INIT_DCS_CMD(0xC9, 0xCC), + _INIT_DCS_CMD(0x30, 0x00), + _INIT_DCS_CMD(0x00, 0x81), + _INIT_DCS_CMD(0x08, 0x02), + _INIT_DCS_CMD(0x09, 0x00), + _INIT_DCS_CMD(0x07, 0x21), + _INIT_DCS_CMD(0x04, 0x10), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x1E), + _INIT_DCS_CMD(0x60, 0x00), + _INIT_DCS_CMD(0x64, 0x00), + _INIT_DCS_CMD(0x6D, 0x00), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x0B), + _INIT_DCS_CMD(0xA6, 0x44), + _INIT_DCS_CMD(0xA7, 0xB6), + _INIT_DCS_CMD(0xA8, 0x03), + _INIT_DCS_CMD(0xA9, 0x03), + _INIT_DCS_CMD(0xAA, 0x51), + _INIT_DCS_CMD(0xAB, 0x51), + _INIT_DCS_CMD(0xAC, 0x04), + _INIT_DCS_CMD(0xBD, 0x92), + _INIT_DCS_CMD(0xBE, 0xA1), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x05), + _INIT_DCS_CMD(0x86, 0x87), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x06), + _INIT_DCS_CMD(0x92, 0x22), + + _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x00), + _INIT_DCS_CMD(0x11), + _INIT_DELAY_CMD(120), + _INIT_DCS_CMD(0x29), + _INIT_DELAY_CMD(20), + {}, +}; + static inline struct boe_panel *to_boe_panel(struct drm_panel *panel) { return container_of(panel, struct boe_panel, base); @@ -1795,6 +2135,34 @@ static const struct panel_desc starry_himax83102_j02_desc = { .lp11_before_reset = true, }; +static const struct drm_display_mode starry_ili9882t_default_mode = { + .clock = 165280, + .hdisplay = 1200, + .hsync_start = 1200 + 32, + .hsync_end = 1200 + 32 + 30, + .htotal = 1200 + 32 + 30 + 32, + .vdisplay = 1920, + .vsync_start = 1920 + 68, + .vsync_end = 1920 + 68 + 2, + .vtotal = 1920 + 68 + 2 + 10, + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED, +}; + +static const struct panel_desc starry_ili9882t_desc = { + .modes = &starry_ili9882t_default_mode, + .bpc = 8, + .size = { + .width_mm = 141, + .height_mm = 226, + }, + .lanes = 4, + .format = MIPI_DSI_FMT_RGB888, + .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE | + MIPI_DSI_MODE_LPM, + .init_cmds = starry_ili9882t_init_cmd, + .lp11_before_reset = true, +}; + static int boe_panel_get_modes(struct drm_panel *panel, struct drm_connector *connector) { @@ -1971,6 +2339,9 @@ static const struct of_device_id boe_of_match[] = { { .compatible = "starry,himax83102-j02", .data = &starry_himax83102_j02_desc }, + { .compatible = "starry,ili9882t", + .data = &starry_ili9882t_desc + }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, boe_of_match);