<div dir="ltr">Hi,Doug<div> Thanks for your help. I had send v4 patch <a href="https://patchwork.kernel.org/project/dri-devel/patch/20210830023849.258839-4-yangcong5@huaqin.corp-partner.google.com/">https://patchwork.kernel.org/project/dri-devel/patch/20210830023849.258839-4-yangcong5@huaqin.corp-partner.google.com/</a>. Please help to review.</div><div><br></div><div>yangcong</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 27, 2021 at 10:42 PM Doug Anderson <<a href="mailto:dianders@google.com">dianders@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Fri, Aug 27, 2021 at 1:24 AM yangcong<br>
<<a href="mailto:yangcong5@huaqin.corp-partner.google.com" target="_blank">yangcong5@huaqin.corp-partner.google.com</a>> wrote:<br>
><br>
> Add driver for BOE tv110c9m-ll3 and Inx hj110iz-01a panel<br>
> both of those are 10.95" 1200x2000 panel.<br>
<br>
Your commit message would be a good place to note design choices you<br>
made in your patch. Maybe you might say:<br>
<br>
Support for these two panels fits in nicely with the existing<br>
panel-boe-tv101wum-nl6 driver as suggested by Sam [1]. The main things<br>
we needed to handle were:<br>
a) These panels need slightly longer delays in two places. Since these<br>
new delays aren't much longer, let's just unconditionally increase<br>
them for the driver.<br>
b) One of these two panels doesn't support DSI HS mode so this patch<br>
adds a flag for a panel to disable that.<br>
<br>
[1] <a href="https://lore.kernel.org/r/YSPAseE6WD8dDRuz@ravnborg.org/" rel="noreferrer" target="_blank">https://lore.kernel.org/r/YSPAseE6WD8dDRuz@ravnborg.org/</a><br>
<br>
If you send a new version, maybe you could include prose similar to that?<br>
<br>
> + _INIT_DCS_CMD(0x4D, 0x21),<br>
> + _INIT_DCS_CMD(0x4E, 0x43),<br>
> + _INIT_DCS_CMD(0x51, 0x12),<br>
> + _INIT_DCS_CMD(0x52, 0x34),<br>
> + _INIT_DCS_CMD(0x55, 0x82, 0x02),<br>
> + _INIT_DCS_CMD(0x56, 0x04),<br>
> + _INIT_DCS_CMD(0x58, 0x21),<br>
> + _INIT_DCS_CMD(0x59, 0x30),<br>
> + _INIT_DCS_CMD(0x5A, 0xBA), //9A<br>
<br>
nit: the "//9A" above seems like it's leftover from something. Remove?<br>
<br>
> + _INIT_DCS_CMD(0x1F, 0xBA),//9A<br>
> + _INIT_DCS_CMD(0x20, 0xA0),<br>
> +<br>
> + _INIT_DCS_CMD(0x26, 0xBA),//9A<br>
> + _INIT_DCS_CMD(0x27, 0xA0),<br>
> +<br>
> + _INIT_DCS_CMD(0x33, 0xBA),//9A<br>
> + _INIT_DCS_CMD(0x34, 0xA0),<br>
> +<br>
> + _INIT_DCS_CMD(0x3F, 0xE0),<br>
> +<br>
> + _INIT_DCS_CMD(0x40, 0x00),<br>
> +<br>
> + _INIT_DCS_CMD(0x44, 0x00),<br>
> + _INIT_DCS_CMD(0x45, 0x40),<br>
> +<br>
> + _INIT_DCS_CMD(0x48, 0xBA),//9A<br>
> + _INIT_DCS_CMD(0x49, 0xA0),<br>
> +<br>
> + _INIT_DCS_CMD(0x5B, 0x00),<br>
> + _INIT_DCS_CMD(0x5C, 0x00),<br>
> + _INIT_DCS_CMD(0x5D, 0x00),<br>
> + _INIT_DCS_CMD(0x5E, 0xD0),<br>
> +<br>
> + _INIT_DCS_CMD(0x61, 0xBA),//9A<br>
> + _INIT_DCS_CMD(0x62, 0xA0),<br>
<br>
More random //9A to remove above?<br>
<br>
<br>
> @@ -515,7 +1363,7 @@ static int boe_panel_unprepare(struct drm_panel *panel)<br>
> regulator_disable(boe->pp3300);<br>
> } else {<br>
> gpiod_set_value(boe->enable_gpio, 0);<br>
> - usleep_range(500, 1000);<br>
> + usleep_range(1000, 2000);<br>
> regulator_disable(boe->avee);<br>
> regulator_disable(boe->avdd);<br>
> usleep_range(5000, 7000);<br>
> @@ -556,7 +1404,7 @@ static int boe_panel_prepare(struct drm_panel *panel)<br>
> if (ret < 0)<br>
> goto poweroffavdd;<br>
><br>
> - usleep_range(5000, 10000);<br>
> + usleep_range(10000, 15000);<br>
<br>
nit: how about using the range 10000, 11000? Last I looked at<br>
usleep_range() it almost always ended up at the longer of the two<br>
times, so that will shave 4 ms off and get us nearly to where we were<br>
without your change. The whole point of the range is to make the<br>
system more power efficient for frequent operations (wakeup<br>
combining), but that really doesn't matter for something as infrequent<br>
as turning on a LCD.<br>
<br>
Other than nits this looks fine to me and I'd be happy to add my<br>
Reviewed-by to a version with nits fixed. I'm not really an expert on<br>
MIPI panels but the convention of a big stream of binary commands<br>
seems to match what other panels in this driver do, even if their<br>
table of binary data isn't quite as long as yours (are all of yours<br>
actually needed?). I'm happy to land this in drm-misc-next with Sam or<br>
Thierry's Ack, too.<br>
<br>
<br>
-Doug<br>
</blockquote></div>