| Message ID | 20250213-mipi_cocci_multi-v1-0-67d94ff319cc@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/panel: Move to using mipi_dsi_*_multi() variants when available | expand |
Hi, On Thu, Feb 13, 2025 at 12:44 PM Anusha Srivatsa <asrivats@redhat.com> wrote: > > A lot of mipi API are deprecated and have a _multi() variant > which is the preferred way forward. This covers TODO in the > gpu Documentation:[1] > > An incomplete effort was made in the previous version > to address this[2]. It removed on the mipi_dsi_dcs_write_seq() > and mipi_dsi_generic_write_seq_multi() with the respective > replacemts and not the rest of the API. You didn't seem to take most of the suggestions I gave in response to your v1 [3]. Specifically: a) I asked that you CC Tejas. I've added him again. b) I asked that you CC me on the whole patch series, which you didn't do. I can find them, but I'd find it convenient in this case for them to be in my Inbox. The first patch conflicts with what Tejas already landed in drm-misc-next. See commit 8025f23728e9 ("drm/panel: xinpeng-xpp055c272: transition to mipi_dsi wrapped functions"). The second patch _also_ conflicts with what Tejas already landed. See commit f4dd4cb79f9e ("drm/panel: visionox-r66451: transition to mipi_dsi wrapped functions"). Later patches also also conflict. See commit 0d6c9edf9e5b ("drm/panel: ebbg-ft8719: transition to mipi_dsi wrapped functions"), commit ce8c69ec90ca ("drm/panel: samsung-s6e88a0-ams452ef01: transition to mipi_dsi wrapped functions"), and commit 7e3bf00047cd ("drm/panel: sharp-ls060t1sx01: transition to mipi_dsi wrapped functions"). Maybe you should sync up with drm-misc-next before submitting. I also questioned whether this really made sense to try to do with a Coccinelle script and I still don't think so. It looks like Dmitry has already reviewed the first few of your patches and has repeated my advice. If you want to help with the effort of addressing this TODO item then that's great, but I'll stop reviewing (and start silently deleting) any future submissions of yours that say that they're done entirely with a Coccinelle script unless you address this point and convince me that your Coccinelle script is really smart enough to handle all the corner cases. I'll also assert that you should review Tejas's submissions to see how these conversions are expected to go. [3] https://lore.kernel.org/r/CAD=FV=WkPefg00R_TAQQA6waRqGdD+3e84JXfPLk2i9BRzW6Yg@mail.gmail.com
On Fri, Feb 14, 2025 at 08:26:02AM -0800, Doug Anderson wrote: > Hi, > > On Thu, Feb 13, 2025 at 12:44 PM Anusha Srivatsa <asrivats@redhat.com> wrote: > > > > A lot of mipi API are deprecated and have a _multi() variant > > which is the preferred way forward. This covers TODO in the > > gpu Documentation:[1] > > > > An incomplete effort was made in the previous version > > to address this[2]. It removed on the mipi_dsi_dcs_write_seq() > > and mipi_dsi_generic_write_seq_multi() with the respective > > replacemts and not the rest of the API. > > You didn't seem to take most of the suggestions I gave in response to > your v1 [3]. Specifically: > > a) I asked that you CC Tejas. I've added him again. > > b) I asked that you CC me on the whole patch series, which you didn't > do. I can find them, but I'd find it convenient in this case for them > to be in my Inbox. > > The first patch conflicts with what Tejas already landed in > drm-misc-next. See commit 8025f23728e9 ("drm/panel: > xinpeng-xpp055c272: transition to mipi_dsi wrapped functions"). The > second patch _also_ conflicts with what Tejas already landed. See > commit f4dd4cb79f9e ("drm/panel: visionox-r66451: transition to > mipi_dsi wrapped functions"). Later patches also also conflict. See > commit 0d6c9edf9e5b ("drm/panel: ebbg-ft8719: transition to mipi_dsi > wrapped functions"), commit ce8c69ec90ca ("drm/panel: > samsung-s6e88a0-ams452ef01: transition to mipi_dsi wrapped > functions"), and commit 7e3bf00047cd ("drm/panel: sharp-ls060t1sx01: > transition to mipi_dsi wrapped functions"). Maybe you should sync up > with drm-misc-next before submitting. Yes, you should definitely work from drm-misc-next there, and sync with Tejas. > I also questioned whether this really made sense to try to do with a > Coccinelle script and I still don't think so. It looks like Dmitry has > already reviewed the first few of your patches and has repeated my > advice. If you want to help with the effort of addressing this TODO > item then that's great, but I'll stop reviewing (and start silently > deleting) any future submissions of yours that say that they're done > entirely with a Coccinelle script unless you address this point and > convince me that your Coccinelle script is really smart enough to > handle all the corner cases. I'll also assert that you should review > Tejas's submissions to see how these conversions are expected to go. I couldn't find that in your first answer though. What corner cases do you have in mind, and why do you think coccinelle can't handle them? Also, why do you think ignoring a contributor after a second mistake is a reasonable reaction? Anusha, most of those comments aren't the end of the discussion though. If you feel like something's not clear enough or ambiguous, feel free to ask for more details and keep the discussion going. Maxime
On Tue, Feb 18, 2025 at 10:55:49AM +0100, Maxime Ripard wrote: > On Fri, Feb 14, 2025 at 08:26:02AM -0800, Doug Anderson wrote: > > Hi, > > > > On Thu, Feb 13, 2025 at 12:44 PM Anusha Srivatsa <asrivats@redhat.com> wrote: > > > > > > A lot of mipi API are deprecated and have a _multi() variant > > > which is the preferred way forward. This covers TODO in the > > > gpu Documentation:[1] > > > > > > An incomplete effort was made in the previous version > > > to address this[2]. It removed on the mipi_dsi_dcs_write_seq() > > > and mipi_dsi_generic_write_seq_multi() with the respective > > > replacemts and not the rest of the API. > > > > You didn't seem to take most of the suggestions I gave in response to > > your v1 [3]. Specifically: > > > > a) I asked that you CC Tejas. I've added him again. > > > > b) I asked that you CC me on the whole patch series, which you didn't > > do. I can find them, but I'd find it convenient in this case for them > > to be in my Inbox. > > > > The first patch conflicts with what Tejas already landed in > > drm-misc-next. See commit 8025f23728e9 ("drm/panel: > > xinpeng-xpp055c272: transition to mipi_dsi wrapped functions"). The > > second patch _also_ conflicts with what Tejas already landed. See > > commit f4dd4cb79f9e ("drm/panel: visionox-r66451: transition to > > mipi_dsi wrapped functions"). Later patches also also conflict. See > > commit 0d6c9edf9e5b ("drm/panel: ebbg-ft8719: transition to mipi_dsi > > wrapped functions"), commit ce8c69ec90ca ("drm/panel: > > samsung-s6e88a0-ams452ef01: transition to mipi_dsi wrapped > > functions"), and commit 7e3bf00047cd ("drm/panel: sharp-ls060t1sx01: > > transition to mipi_dsi wrapped functions"). Maybe you should sync up > > with drm-misc-next before submitting. > > Yes, you should definitely work from drm-misc-next there, and sync with > Tejas. > > > I also questioned whether this really made sense to try to do with a > > Coccinelle script and I still don't think so. It looks like Dmitry has > > already reviewed the first few of your patches and has repeated my > > advice. If you want to help with the effort of addressing this TODO > > item then that's great, but I'll stop reviewing (and start silently > > deleting) any future submissions of yours that say that they're done > > entirely with a Coccinelle script unless you address this point and > > convince me that your Coccinelle script is really smart enough to > > handle all the corner cases. I'll also assert that you should review > > Tejas's submissions to see how these conversions are expected to go. > > I couldn't find that in your first answer though. What corner cases do > you have in mind, and why do you think coccinelle can't handle them? As can be seen from the reviews: - sleeps between DSI calls - properly propagating the error at the end of the function - making decision whether to create the context at the caller or the callee side. E.g. in patch 8 it is better to allocate context in hx8394_enable() and pass it to .init_sequence() instead of keeping some of error handling. > Also, why do you think ignoring a contributor after a second mistake is > a reasonable reaction? > > Anusha, most of those comments aren't the end of the discussion though. > If you feel like something's not clear enough or ambiguous, feel free to > ask for more details and keep the discussion going. From my side: feel free to ask for the details if any of the emails is not clear enough. At the same time, please review your patches before sending them. Returning 0 in case there was an error is an obvious issue.
On Tue, Feb 18, 2025 at 02:14:43PM +0200, Dmitry Baryshkov wrote: > On Tue, Feb 18, 2025 at 10:55:49AM +0100, Maxime Ripard wrote: > > On Fri, Feb 14, 2025 at 08:26:02AM -0800, Doug Anderson wrote: > > > Hi, > > > > > > On Thu, Feb 13, 2025 at 12:44 PM Anusha Srivatsa <asrivats@redhat.com> wrote: > > > > > > > > A lot of mipi API are deprecated and have a _multi() variant > > > > which is the preferred way forward. This covers TODO in the > > > > gpu Documentation:[1] > > > > > > > > An incomplete effort was made in the previous version > > > > to address this[2]. It removed on the mipi_dsi_dcs_write_seq() > > > > and mipi_dsi_generic_write_seq_multi() with the respective > > > > replacemts and not the rest of the API. > > > > > > You didn't seem to take most of the suggestions I gave in response to > > > your v1 [3]. Specifically: > > > > > > a) I asked that you CC Tejas. I've added him again. > > > > > > b) I asked that you CC me on the whole patch series, which you didn't > > > do. I can find them, but I'd find it convenient in this case for them > > > to be in my Inbox. > > > > > > The first patch conflicts with what Tejas already landed in > > > drm-misc-next. See commit 8025f23728e9 ("drm/panel: > > > xinpeng-xpp055c272: transition to mipi_dsi wrapped functions"). The > > > second patch _also_ conflicts with what Tejas already landed. See > > > commit f4dd4cb79f9e ("drm/panel: visionox-r66451: transition to > > > mipi_dsi wrapped functions"). Later patches also also conflict. See > > > commit 0d6c9edf9e5b ("drm/panel: ebbg-ft8719: transition to mipi_dsi > > > wrapped functions"), commit ce8c69ec90ca ("drm/panel: > > > samsung-s6e88a0-ams452ef01: transition to mipi_dsi wrapped > > > functions"), and commit 7e3bf00047cd ("drm/panel: sharp-ls060t1sx01: > > > transition to mipi_dsi wrapped functions"). Maybe you should sync up > > > with drm-misc-next before submitting. > > > > Yes, you should definitely work from drm-misc-next there, and sync with > > Tejas. > > > > > I also questioned whether this really made sense to try to do with a > > > Coccinelle script and I still don't think so. It looks like Dmitry has > > > already reviewed the first few of your patches and has repeated my > > > advice. If you want to help with the effort of addressing this TODO > > > item then that's great, but I'll stop reviewing (and start silently > > > deleting) any future submissions of yours that say that they're done > > > entirely with a Coccinelle script unless you address this point and > > > convince me that your Coccinelle script is really smart enough to > > > handle all the corner cases. I'll also assert that you should review > > > Tejas's submissions to see how these conversions are expected to go. > > > > I couldn't find that in your first answer though. What corner cases do > > you have in mind, and why do you think coccinelle can't handle them? > > As can be seen from the reviews: > > - sleeps between DSI calls > - properly propagating the error at the end of the function These two are legitimate feedback, but I don't see how coccinelle cannot deal with them. > - making decision whether to create the context at the caller or the > callee side. E.g. in patch 8 it is better to allocate context in > hx8394_enable() and pass it to .init_sequence() instead of keeping > some of error handling. Yeah, that one is definitely subjective, and is going to need manual review. Maxime
On Tue, Feb 18, 2025 at 04:52:53PM +0100, Maxime Ripard wrote: > On Tue, Feb 18, 2025 at 02:14:43PM +0200, Dmitry Baryshkov wrote: > > On Tue, Feb 18, 2025 at 10:55:49AM +0100, Maxime Ripard wrote: > > > On Fri, Feb 14, 2025 at 08:26:02AM -0800, Doug Anderson wrote: > > > > Hi, > > > > > > > > On Thu, Feb 13, 2025 at 12:44 PM Anusha Srivatsa <asrivats@redhat.com> wrote: > > > > > > > > > > A lot of mipi API are deprecated and have a _multi() variant > > > > > which is the preferred way forward. This covers TODO in the > > > > > gpu Documentation:[1] > > > > > > > > > > An incomplete effort was made in the previous version > > > > > to address this[2]. It removed on the mipi_dsi_dcs_write_seq() > > > > > and mipi_dsi_generic_write_seq_multi() with the respective > > > > > replacemts and not the rest of the API. > > > > > > > > You didn't seem to take most of the suggestions I gave in response to > > > > your v1 [3]. Specifically: > > > > > > > > a) I asked that you CC Tejas. I've added him again. > > > > > > > > b) I asked that you CC me on the whole patch series, which you didn't > > > > do. I can find them, but I'd find it convenient in this case for them > > > > to be in my Inbox. > > > > > > > > The first patch conflicts with what Tejas already landed in > > > > drm-misc-next. See commit 8025f23728e9 ("drm/panel: > > > > xinpeng-xpp055c272: transition to mipi_dsi wrapped functions"). The > > > > second patch _also_ conflicts with what Tejas already landed. See > > > > commit f4dd4cb79f9e ("drm/panel: visionox-r66451: transition to > > > > mipi_dsi wrapped functions"). Later patches also also conflict. See > > > > commit 0d6c9edf9e5b ("drm/panel: ebbg-ft8719: transition to mipi_dsi > > > > wrapped functions"), commit ce8c69ec90ca ("drm/panel: > > > > samsung-s6e88a0-ams452ef01: transition to mipi_dsi wrapped > > > > functions"), and commit 7e3bf00047cd ("drm/panel: sharp-ls060t1sx01: > > > > transition to mipi_dsi wrapped functions"). Maybe you should sync up > > > > with drm-misc-next before submitting. > > > > > > Yes, you should definitely work from drm-misc-next there, and sync with > > > Tejas. > > > > > > > I also questioned whether this really made sense to try to do with a > > > > Coccinelle script and I still don't think so. It looks like Dmitry has > > > > already reviewed the first few of your patches and has repeated my > > > > advice. If you want to help with the effort of addressing this TODO > > > > item then that's great, but I'll stop reviewing (and start silently > > > > deleting) any future submissions of yours that say that they're done > > > > entirely with a Coccinelle script unless you address this point and > > > > convince me that your Coccinelle script is really smart enough to > > > > handle all the corner cases. I'll also assert that you should review > > > > Tejas's submissions to see how these conversions are expected to go. > > > > > > I couldn't find that in your first answer though. What corner cases do > > > you have in mind, and why do you think coccinelle can't handle them? > > > > As can be seen from the reviews: > > > > - sleeps between DSI calls > > - properly propagating the error at the end of the function > > These two are legitimate feedback, but I don't see how coccinelle cannot > deal with them. Maybe it can. both issues were pointed out during review of the first series, there was no improvement here. I'd really ask to perform conversion of a single driver, so that the script (or post-script fixups) can be improved. I'd still expect that Anusha actually reviews the changed driver before posting it and verifies that there is no regression in the logic / error reporting. > > > - making decision whether to create the context at the caller or the > > callee side. E.g. in patch 8 it is better to allocate context in > > hx8394_enable() and pass it to .init_sequence() instead of keeping > > some of error handling. > > Yeah, that one is definitely subjective, and is going to need manual > review.
On Wed, Feb 19, 2025 at 11:11:33AM +0200, Dmitry Baryshkov wrote: > On Tue, Feb 18, 2025 at 04:52:53PM +0100, Maxime Ripard wrote: > > On Tue, Feb 18, 2025 at 02:14:43PM +0200, Dmitry Baryshkov wrote: > > > On Tue, Feb 18, 2025 at 10:55:49AM +0100, Maxime Ripard wrote: > > > > On Fri, Feb 14, 2025 at 08:26:02AM -0800, Doug Anderson wrote: > > > > > Hi, > > > > > > > > > > On Thu, Feb 13, 2025 at 12:44 PM Anusha Srivatsa <asrivats@redhat.com> wrote: > > > > > > > > > > > > A lot of mipi API are deprecated and have a _multi() variant > > > > > > which is the preferred way forward. This covers TODO in the > > > > > > gpu Documentation:[1] > > > > > > > > > > > > An incomplete effort was made in the previous version > > > > > > to address this[2]. It removed on the mipi_dsi_dcs_write_seq() > > > > > > and mipi_dsi_generic_write_seq_multi() with the respective > > > > > > replacemts and not the rest of the API. > > > > > > > > > > You didn't seem to take most of the suggestions I gave in response to > > > > > your v1 [3]. Specifically: > > > > > > > > > > a) I asked that you CC Tejas. I've added him again. > > > > > > > > > > b) I asked that you CC me on the whole patch series, which you didn't > > > > > do. I can find them, but I'd find it convenient in this case for them > > > > > to be in my Inbox. > > > > > > > > > > The first patch conflicts with what Tejas already landed in > > > > > drm-misc-next. See commit 8025f23728e9 ("drm/panel: > > > > > xinpeng-xpp055c272: transition to mipi_dsi wrapped functions"). The > > > > > second patch _also_ conflicts with what Tejas already landed. See > > > > > commit f4dd4cb79f9e ("drm/panel: visionox-r66451: transition to > > > > > mipi_dsi wrapped functions"). Later patches also also conflict. See > > > > > commit 0d6c9edf9e5b ("drm/panel: ebbg-ft8719: transition to mipi_dsi > > > > > wrapped functions"), commit ce8c69ec90ca ("drm/panel: > > > > > samsung-s6e88a0-ams452ef01: transition to mipi_dsi wrapped > > > > > functions"), and commit 7e3bf00047cd ("drm/panel: sharp-ls060t1sx01: > > > > > transition to mipi_dsi wrapped functions"). Maybe you should sync up > > > > > with drm-misc-next before submitting. > > > > > > > > Yes, you should definitely work from drm-misc-next there, and sync with > > > > Tejas. > > > > > > > > > I also questioned whether this really made sense to try to do with a > > > > > Coccinelle script and I still don't think so. It looks like Dmitry has > > > > > already reviewed the first few of your patches and has repeated my > > > > > advice. If you want to help with the effort of addressing this TODO > > > > > item then that's great, but I'll stop reviewing (and start silently > > > > > deleting) any future submissions of yours that say that they're done > > > > > entirely with a Coccinelle script unless you address this point and > > > > > convince me that your Coccinelle script is really smart enough to > > > > > handle all the corner cases. I'll also assert that you should review > > > > > Tejas's submissions to see how these conversions are expected to go. > > > > > > > > I couldn't find that in your first answer though. What corner cases do > > > > you have in mind, and why do you think coccinelle can't handle them? > > > > > > As can be seen from the reviews: > > > > > > - sleeps between DSI calls > > > - properly propagating the error at the end of the function > > > > These two are legitimate feedback, but I don't see how coccinelle cannot > > deal with them. > > Maybe it can. both issues were pointed out during review of the first > series, there was no improvement here. I'd really ask to perform > conversion of a single driver, so that the script (or post-script > fixups) can be improved. I'd still expect that Anusha actually reviews > the changed driver before posting it and verifies that there is no > regression in the logic / error reporting. Yeah, it makes sense, thanks! Maxime
On Wed, Feb 19, 2025 at 8:35 AM Maxime Ripard <mripard@kernel.org> wrote: > On Wed, Feb 19, 2025 at 11:11:33AM +0200, Dmitry Baryshkov wrote: > > On Tue, Feb 18, 2025 at 04:52:53PM +0100, Maxime Ripard wrote: > > > On Tue, Feb 18, 2025 at 02:14:43PM +0200, Dmitry Baryshkov wrote: > > > > On Tue, Feb 18, 2025 at 10:55:49AM +0100, Maxime Ripard wrote: > > > > > On Fri, Feb 14, 2025 at 08:26:02AM -0800, Doug Anderson wrote: > > > > > > Hi, > > > > > > > > > > > > On Thu, Feb 13, 2025 at 12:44 PM Anusha Srivatsa < > asrivats@redhat.com> wrote: > > > > > > > > > > > > > > A lot of mipi API are deprecated and have a _multi() variant > > > > > > > which is the preferred way forward. This covers TODO in the > > > > > > > gpu Documentation:[1] > > > > > > > > > > > > > > An incomplete effort was made in the previous version > > > > > > > to address this[2]. It removed on the mipi_dsi_dcs_write_seq() > > > > > > > and mipi_dsi_generic_write_seq_multi() with the respective > > > > > > > replacemts and not the rest of the API. > > > > > > > > > > > > You didn't seem to take most of the suggestions I gave in > response to > > > > > > your v1 [3]. Specifically: > > > > > > > > > > > > a) I asked that you CC Tejas. I've added him again. > > > > > > > > > > > > b) I asked that you CC me on the whole patch series, which you > didn't > > > > > > do. I can find them, but I'd find it convenient in this case for > them > > > > > > to be in my Inbox. > > > > > > > > > > > > The first patch conflicts with what Tejas already landed in > > > > > > drm-misc-next. See commit 8025f23728e9 ("drm/panel: > > > > > > xinpeng-xpp055c272: transition to mipi_dsi wrapped functions"). > The > > > > > > second patch _also_ conflicts with what Tejas already landed. See > > > > > > commit f4dd4cb79f9e ("drm/panel: visionox-r66451: transition to > > > > > > mipi_dsi wrapped functions"). Later patches also also conflict. > See > > > > > > commit 0d6c9edf9e5b ("drm/panel: ebbg-ft8719: transition to > mipi_dsi > > > > > > wrapped functions"), commit ce8c69ec90ca ("drm/panel: > > > > > > samsung-s6e88a0-ams452ef01: transition to mipi_dsi wrapped > > > > > > functions"), and commit 7e3bf00047cd ("drm/panel: > sharp-ls060t1sx01: > > > > > > transition to mipi_dsi wrapped functions"). Maybe you should > sync up > > > > > > with drm-misc-next before submitting. > > > > > > > > > > Yes, you should definitely work from drm-misc-next there, and sync > with > > > > > Tejas. > > > > > > > > > > > I also questioned whether this really made sense to try to do > with a > > > > > > Coccinelle script and I still don't think so. It looks like > Dmitry has > > > > > > already reviewed the first few of your patches and has repeated > my > > > > > > advice. If you want to help with the effort of addressing this > TODO > > > > > > item then that's great, but I'll stop reviewing (and start > silently > > > > > > deleting) any future submissions of yours that say that they're > done > > > > > > entirely with a Coccinelle script unless you address this point > and > > > > > > convince me that your Coccinelle script is really smart enough to > > > > > > handle all the corner cases. I'll also assert that you should > review > > > > > > Tejas's submissions to see how these conversions are expected to > go. > > > > > > > > > > I couldn't find that in your first answer though. What corner > cases do > > > > > you have in mind, and why do you think coccinelle can't handle > them? > > > > > > > > As can be seen from the reviews: > > > > > > > > - sleeps between DSI calls > > > > - properly propagating the error at the end of the function > > > > > > These two are legitimate feedback, but I don't see how coccinelle > cannot > > > deal with them. > > > > Maybe it can. both issues were pointed out during review of the first > > series, there was no improvement here. I'd really ask to perform > > conversion of a single driver, so that the script (or post-script > > fixups) can be improved. I'd still expect that Anusha actually reviews > > the changed driver before posting it and verifies that there is no > > regression in the logic / error reporting. > > Yeah, it makes sense, thanks! > Dmitry, Doug, Sorry for the late response, I was out. A lot of the confusion and effort could have been saved had I worked on the -misc branch. My bad. WIll keep the rest of the feedback in mind and address one driver at a time to avoid an overhaul of changes. Thanks for taking time out to guide me in the right direction! Anusha > Maxime >
A lot of mipi API are deprecated and have a _multi() variant which is the preferred way forward. This covers TODO in the gpu Documentation:[1] An incomplete effort was made in the previous version to address this[2]. It removed on the mipi_dsi_dcs_write_seq() and mipi_dsi_generic_write_seq_multi() with the respective replacemts and not the rest of the API. The Coccinelle patch used to mkae changes: @rule_1@ expression dsi_var; expression list es; identifier jdi; @@ static int jdi_write_dcdc_registers(struct jdi_panel *jdi) { +struct mipi_dsi_multi_context dsi_ctx1 = { .dsi = jdi->link1 }; +struct mipi_dsi_multi_context dsi_ctx2 = { .dsi = jdi->link2 }; <+... -mipi_dsi_generic_write_seq(jdi->link1,es); +mipi_dsi_generic_write_seq_multi(&dsi_ctx1,es); -mipi_dsi_generic_write_seq(jdi->link2,es); +mipi_dsi_generic_write_seq_multi(&dsi_ctx2,es); ...+> } @rule_2@ expression dsi_var; expression list es; identifier jdi; @@ struct mipi_dsi_device *dsi0 = pinfo->dsi[0]; struct mipi_dsi_device *dsi1 = pinfo->dsi[1]; +struct mipi_dsi_multi_context dsi_ctx0 = { .dsi = dsi0 }; +struct mipi_dsi_multi_context dsi_ctx1 = { .dsi = dsi1 }; <+... -mipi_dsi_dual_dcs_write_seq(dsi0, dsi1, es); +mipi_dsi_dual_dcs_write_seq(dsi_ctx0, dsi_ctx1, es); ...+> @rule_3@ identifier func; identifier r; type t; expression list es; position p; @@ t func(...) { <+... ( -mipi_dsi_dcs_write_seq(dsi_var,es); +mipi_dsi_dcs_write_seq_multi(&dsi_ctx,es); | -r = mipi_dsi_dcs_exit_sleep_mode(jdi->link1)@p; +mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx1); | -r = mipi_dsi_dcs_enter_sleep_mode(jdi->link1)@p; +mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx1); | -r = mipi_dsi_dcs_set_display_off(jdi->link1)@p; +mipi_dsi_dcs_set_display_off_multi(&dsi_ctx1); | .....//rest of the mipi APIs with _multi variant ) <+... -if(r < 0) { -... -} ...+> [1] -> https://docs.kernel.org/gpu/todo.html#transition-away-from-using-mipi-dsi-write-seq [2] -> https://patchwork.freedesktop.org/series/144446/ Signed-off-by: Anusha Srivatsa <asrivats@redhat.com> --- Anusha Srivatsa (20): drm/panel/xpp055c272: Move to using mipi_dsi_*_multi() variants drm/panel/visionox-r66451: Move to using mipi_dsi_*_multi() variants drm/panel/asus-tm5p5-n35596: Move to using mipi_dsi_*_multi() variants drm/panel/boe-bf060y8m-aj0: Move to using mipi_dsi_*_multi() variants drm/panel/dsi-cm: Move to using mipi_dsi_*_multi() variants drm/panel/sony-nt35521: Move to using mipi_dsi_*_multi() variants drm/panel/ebbg-ft8719: Move to using mipi_dsi_*_multi() variants drm/panel/himax-hx8394: Move to using mipi_dsi_*_multi() variants drm/panel/jdi-lpm102a188a: Move to using mipi_dsi_*_multi() variants drm/panel/jdi-lt070me05000: Move to using mipi_dsi_*_multi() variants drm/panel/novatek-nt36523: Move to using mipi_dsi_*_multi() variants drm/panel/raydium-rm67191: Move to using mipi_dsi_*_multi() variants drm/panel/samsung-s6d7aa0:Move to using mipi_dsi_*_multi() variants drm/panel/s6e88a0-ams452ef01: Move to using mipi_dsi_*_multi() variants drm/panel/samsung-sofef00: Move to using mipi_dsi_*_multi() variants drm/panel/ls043t1le01: Move to using mipi_dsi_*_multi() variants drm/panel/ls060t1sx01: Move to using mipi_dsi_*_multi() variants drm/panel/sony-td4353-jdi: Move to using mipi_dsi_*_multi() variants drm/panel: Remove deprecated functions Documentation: Update the documentation Documentation/gpu/todo.rst | 19 - drivers/gpu/drm/drm_mipi_dsi.c | 56 - .../gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c | 6 +- drivers/gpu/drm/panel/panel-boe-bf060y8m-aj0.c | 75 +- drivers/gpu/drm/panel/panel-dsi-cm.c | 44 +- drivers/gpu/drm/panel/panel-ebbg-ft8719.c | 45 +- drivers/gpu/drm/panel/panel-himax-hx8394.c | 389 +++-- drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c | 141 +- drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 81 +- drivers/gpu/drm/panel/panel-novatek-nt36523.c | 1678 ++++++++++---------- drivers/gpu/drm/panel/panel-raydium-rm67191.c | 60 +- drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c | 101 +- .../drm/panel/panel-samsung-s6e88a0-ams452ef01.c | 63 +- drivers/gpu/drm/panel/panel-samsung-sofef00.c | 54 +- drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 28 +- drivers/gpu/drm/panel/panel-sharp-ls060t1sx01.c | 34 +- drivers/gpu/drm/panel/panel-sony-td4353-jdi.c | 71 +- .../gpu/drm/panel/panel-sony-tulip-truly-nt35521.c | 6 +- drivers/gpu/drm/panel/panel-visionox-r66451.c | 156 +- drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c | 138 +- include/drm/drm_mipi_dsi.h | 47 - 21 files changed, 1432 insertions(+), 1860 deletions(-) --- base-commit: febbc555cf0fff895546ddb8ba2c9a523692fb55 change-id: 20250211-mipi_cocci_multi-440af15236c2 Best regards,