From: Doug Anderson <dianders@chromium.org> To: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: quic_kalyant <quic_kalyant@quicinc.com>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, "Sankeerth Billakanti \(QUIC\)" <quic_sbillaka@quicinc.com>, quic_vproddut <quic_vproddut@quicinc.com>, David Airlie <airlied@linux.ie>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Stephen Boyd <swboyd@chromium.org>, LKML <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, "Kuogee Hsieh \(QUIC\)" <quic_khsieh@quicinc.com>, Sean Paul <sean@poorly.run>, Sean Paul <seanpaul@chromium.org>, "dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>, "Aravind Venkateswaran \(QUIC\)" <quic_aravindh@quicinc.com>, "bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>, freedreno <freedreno@lists.freedesktop.org> Subject: Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus Date: Thu, 7 Apr 2022 13:47:55 -0700 [thread overview] Message-ID: <CAD=FV=UmU_BVUaL_X75yOEvQPtGUBTR5-jiVWBHq7uSRt6HM4Q@mail.gmail.com> (raw) In-Reply-To: <c4f086ce-c56f-f7c9-4092-7f2432330d50@quicinc.com> Hi, On Thu, Apr 7, 2022 at 1:11 PM Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > Hi Doug and Dmitry > > Sorry, but I caught up on this email just now. > > Some comments below. > > Thanks > > Abhinav > On 4/7/2022 10:07 AM, Doug Anderson wrote: > > Hi, > > > > On Thu, Apr 7, 2022 at 7:19 AM Sankeerth Billakanti (QUIC) > > <quic_sbillaka@quicinc.com> wrote: > >> > >> Hi Dmitry and Doug, > >> > >>> Hi, > >>> > >>> On Tue, Apr 5, 2022 at 10:36 AM Dmitry Baryshkov > >>> <dmitry.baryshkov@linaro.org> wrote: > >>>> > >>>> On 05/04/2022 20:02, Doug Anderson wrote: > >>>>> Hi, > >>>>> > >>>>> On Tue, Apr 5, 2022 at 5:54 AM Dmitry Baryshkov > >>>>> <dmitry.baryshkov@linaro.org> wrote: > >>>>>>> 3. For DP and eDP HPD means something a little different. > >>>>>>> Essentially there are two concepts: a) is a display physically > >>>>>>> connected and b) is the display powered up and ready. For DP, the > >>>>>>> two are really tied together. From the kernel's point of view you > >>>>>>> never "power down" a DP display and you can't detect that it's > >>>>>>> physically connected until it's ready. Said another way, on you > >>>>>>> tie "is a display there" to the HPD line and the moment a display > >>>>>>> is there it's ready for you to do AUX transfers. For eDP, in the > >>>>>>> lowest power state of a display it _won't_ assert its "HPD" > >>>>>>> signal. However, it's still physically present. For eDP you simply > >>>>>>> have to _assume_ it's present without any actual proof since you > >>>>>>> can't get proof until you power it up. Thus for eDP, you report > >>>>>>> that the display is there as soon as we're asked. We can't _talk_ > >>>>>>> to the display yet, though. So in get_modes() we need to be able > >>>>>>> to power the display on enough to talk over the AUX channel to it. > >>>>>>> As part of this, we wait for the signal named "HPD" which really means > >>> "panel finished powering on" in this context. > >>>>>>> > >>>>>>> NOTE: for aux transfer, we don't have the _display_ pipe and > >>>>>>> clocks running. We only have enough stuff running to do the AUX > >>> transfer. > >>>>>>> We're not clocking out pixels. We haven't fully powered on the > >>>>>>> display. The AUX transfer is designed to be something that can be > >>>>>>> done early _before_ you turn on the display. > >>>>>>> > >>>>>>> > >>>>>>> OK, so basically that was a longwinded way of saying: yes, we > >>>>>>> could avoid the AUX transfer in probe, but we can't wait all the > >>>>>>> way to enable. We have to be able to transfer in get_modes(). If > >>>>>>> you think that's helpful I think it'd be a pretty easy patch to > >>>>>>> write even if it would look a tad bit awkward IMO. Let me know if > >>>>>>> you want me to post it up. > >>>>>> > >>>>>> I think it would be a good idea. At least it will allow us to > >>>>>> judge, which is the more correct way. > >>>>> > >>>>> I'm still happy to prototype this, but the more I think about it the > >>>>> more it feels like a workaround for the Qualcomm driver. The eDP > >>>>> panel driver is actually given a pointer to the AUX bus at probe > >>>>> time. It's really weird to say that we can't do a transfer on it > >>>>> yet... As you said, this is a little sideband bus. It should be able > >>>>> to be used without all the full blown infra of the rest of the driver. > >>>> > >>>> Yes, I have that feeling too. However I also have a feeling that just > >>>> powering up the PHY before the bus probe is ... a hack. There are no > >>>> obvious stopgaps for the driver not to power it down later. > >>> > > Lets go back to why we need to power up the PHY before the bus probe. > > We need to power up PHY before bus probe because panel-eDP tries to read > the EDID in probe() for the panel_id. Not get_modes(). > > So doug, I didnt follow your comment that panel-eDP only does EDID read > in get_modes() > > panel_id = drm_edid_get_panel_id(panel->ddc); > if (!panel_id) { > dev_err(dev, "Couldn't identify panel via EDID\n"); > ret = -EIO; > goto exit; > } > > If we do not need this part, we really dont need to power up the PHY > before the probe(). The hack which dmitry was referring to. Right. ...so we _could_ remove the above from the panel-edp probe and defer it to get_modes() and it wouldn't be that hard. ...but: 1. It feels like a hack to work around the Qualcomm driver. The way the AUX bus is designed is that a pointer to the AUX bus is passed to the panel-edp probe. It seems kinda strange to say that the panel isn't allowed to do transfers with the pointer that's passed in. 2. There's a second place where we might do an AUX transfer at probe time which is when we're using the DP AUX backlight. There we call drm_panel_dp_aux_backlight(). Conceivably this too could be deferred until the get_modes(), but now it feels even more like a hack. We're going to be registering the backlight in the first call to get_modes()? That's, ummm, unexpected. We could look at perhaps breaking the "DP AUX backlight" in two parts also, but that gets involved. I think we're supposed to know the number of backlight levels at device init time for backlight devices and we need an AUX transfer to that. So the answer is that we could probably make it work, but it seems like an uglier solution than just making the Qualcomm driver able to do AUX transfers when it should be able to. > So this is boiling down to why or how panel-eDP was originally designed. > > >>> This is why I think we need to move to Runtime PM to manage this. Basically: > >>> > >>> 1. When an AUX transfer happens, you grab a PM runtime reference that > >>> _that_ powers up the PHY. > > This will not be trivial and needs to be scoped out as sankeerth said > but if the above is the only concern, why do we need to do this? There > seems to be an explanation why we are doing this and its not a hack. > > How would Dmitry's rework address this? We need some RFC to conclude on > that first. > > >>> > >>> 2. At the end of the AUX transfer function, you do a "put_autosuspend". > >>> > >>> Then it becomes not a hack, right? > >>> > >>> > >> > >> pm runtime ops needs to be implemented for both eDP and DP. This change > >> take good amount of planning and code changes as it affects DP also. > >> > >> Because this patch series consist of basic eDP changes for SC7280 bootup, > >> shall we take this pm_runtime implementation in subsequent patch series? > > > > Dmitry is the real decision maker here, but in my opinion it would be > > OK to get something landed first that worked OK and wasn't taking us > > too far in the wrong direction and then we could get a follow up patch > > to move to pm_runtime. > > I would say the discussion changed into a direction of implementing > pm-runtime because the current patch series does what it takes to adhere > to panel-eDP's design along with aux bus requirements of PHY needing to > be on. > > So doug, to answer your questions here: > > "So I guess the net result is maybe we should just keep it where it is. > Long term I'd be interested in knowing if there's a reason why we > can't structure the driver so that AUX transfers can happen with less > intertwining with the rest of the code, but that can happen later. I > would expect that you'd basically just need clocks and regulators on > and maybe your PHY on." > > Yes PHY needs to be absolutely on and configured before aux transfers. > > If we want to change that up to stop reading the panel_id in the panel > probe() and do it later, perhaps some of the changes done here are not > needed. > > It only seems reasonable that we first prototype that in a separate > patch even a RFC perhaps and take this further as these set of changes > are needed for basic display functionality on sc7280 chromebooks. > > Let us know what are the concerns with doing it in a follow up change. As per above, I'm not objecting to it being a follow-up change, but I do believe it's the right design and will lead to an overall cleaner solution. I think I even mentioned in my reviews that the current patch series seems to "scattershot" enable resources and that's how we end up with patches like patch #5 in this series ("drm/msm/dp: prevent multiple votes for dp resources"). IMO there should be be a 1-to-1 mapping between "turn on resources" and "turn off resources" and it should be reference counted. So if your codepath turned on resources then it's up to your codepath to turn resources off when done. If a seconde code path might be running at the same time then it should also turn on/off resources itself. ...and it should all be managed by pm_runtime which is _exactly designed_ for this specific use case. -Doug
WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@chromium.org> To: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: "Sankeerth Billakanti (QUIC)" <quic_sbillaka@quicinc.com>, quic_kalyant <quic_kalyant@quicinc.com>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, quic_vproddut <quic_vproddut@quicinc.com>, David Airlie <airlied@linux.ie>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, "Kuogee Hsieh (QUIC)" <quic_khsieh@quicinc.com>, freedreno <freedreno@lists.freedesktop.org>, dri-devel <dri-devel@lists.freedesktop.org>, "bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>, Sean Paul <seanpaul@chromium.org>, "dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>, "Aravind Venkateswaran (QUIC)" <quic_aravindh@quicinc.com>, Stephen Boyd <swboyd@chromium.org>, Sean Paul <sean@poorly.run>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus Date: Thu, 7 Apr 2022 13:47:55 -0700 [thread overview] Message-ID: <CAD=FV=UmU_BVUaL_X75yOEvQPtGUBTR5-jiVWBHq7uSRt6HM4Q@mail.gmail.com> (raw) In-Reply-To: <c4f086ce-c56f-f7c9-4092-7f2432330d50@quicinc.com> Hi, On Thu, Apr 7, 2022 at 1:11 PM Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > Hi Doug and Dmitry > > Sorry, but I caught up on this email just now. > > Some comments below. > > Thanks > > Abhinav > On 4/7/2022 10:07 AM, Doug Anderson wrote: > > Hi, > > > > On Thu, Apr 7, 2022 at 7:19 AM Sankeerth Billakanti (QUIC) > > <quic_sbillaka@quicinc.com> wrote: > >> > >> Hi Dmitry and Doug, > >> > >>> Hi, > >>> > >>> On Tue, Apr 5, 2022 at 10:36 AM Dmitry Baryshkov > >>> <dmitry.baryshkov@linaro.org> wrote: > >>>> > >>>> On 05/04/2022 20:02, Doug Anderson wrote: > >>>>> Hi, > >>>>> > >>>>> On Tue, Apr 5, 2022 at 5:54 AM Dmitry Baryshkov > >>>>> <dmitry.baryshkov@linaro.org> wrote: > >>>>>>> 3. For DP and eDP HPD means something a little different. > >>>>>>> Essentially there are two concepts: a) is a display physically > >>>>>>> connected and b) is the display powered up and ready. For DP, the > >>>>>>> two are really tied together. From the kernel's point of view you > >>>>>>> never "power down" a DP display and you can't detect that it's > >>>>>>> physically connected until it's ready. Said another way, on you > >>>>>>> tie "is a display there" to the HPD line and the moment a display > >>>>>>> is there it's ready for you to do AUX transfers. For eDP, in the > >>>>>>> lowest power state of a display it _won't_ assert its "HPD" > >>>>>>> signal. However, it's still physically present. For eDP you simply > >>>>>>> have to _assume_ it's present without any actual proof since you > >>>>>>> can't get proof until you power it up. Thus for eDP, you report > >>>>>>> that the display is there as soon as we're asked. We can't _talk_ > >>>>>>> to the display yet, though. So in get_modes() we need to be able > >>>>>>> to power the display on enough to talk over the AUX channel to it. > >>>>>>> As part of this, we wait for the signal named "HPD" which really means > >>> "panel finished powering on" in this context. > >>>>>>> > >>>>>>> NOTE: for aux transfer, we don't have the _display_ pipe and > >>>>>>> clocks running. We only have enough stuff running to do the AUX > >>> transfer. > >>>>>>> We're not clocking out pixels. We haven't fully powered on the > >>>>>>> display. The AUX transfer is designed to be something that can be > >>>>>>> done early _before_ you turn on the display. > >>>>>>> > >>>>>>> > >>>>>>> OK, so basically that was a longwinded way of saying: yes, we > >>>>>>> could avoid the AUX transfer in probe, but we can't wait all the > >>>>>>> way to enable. We have to be able to transfer in get_modes(). If > >>>>>>> you think that's helpful I think it'd be a pretty easy patch to > >>>>>>> write even if it would look a tad bit awkward IMO. Let me know if > >>>>>>> you want me to post it up. > >>>>>> > >>>>>> I think it would be a good idea. At least it will allow us to > >>>>>> judge, which is the more correct way. > >>>>> > >>>>> I'm still happy to prototype this, but the more I think about it the > >>>>> more it feels like a workaround for the Qualcomm driver. The eDP > >>>>> panel driver is actually given a pointer to the AUX bus at probe > >>>>> time. It's really weird to say that we can't do a transfer on it > >>>>> yet... As you said, this is a little sideband bus. It should be able > >>>>> to be used without all the full blown infra of the rest of the driver. > >>>> > >>>> Yes, I have that feeling too. However I also have a feeling that just > >>>> powering up the PHY before the bus probe is ... a hack. There are no > >>>> obvious stopgaps for the driver not to power it down later. > >>> > > Lets go back to why we need to power up the PHY before the bus probe. > > We need to power up PHY before bus probe because panel-eDP tries to read > the EDID in probe() for the panel_id. Not get_modes(). > > So doug, I didnt follow your comment that panel-eDP only does EDID read > in get_modes() > > panel_id = drm_edid_get_panel_id(panel->ddc); > if (!panel_id) { > dev_err(dev, "Couldn't identify panel via EDID\n"); > ret = -EIO; > goto exit; > } > > If we do not need this part, we really dont need to power up the PHY > before the probe(). The hack which dmitry was referring to. Right. ...so we _could_ remove the above from the panel-edp probe and defer it to get_modes() and it wouldn't be that hard. ...but: 1. It feels like a hack to work around the Qualcomm driver. The way the AUX bus is designed is that a pointer to the AUX bus is passed to the panel-edp probe. It seems kinda strange to say that the panel isn't allowed to do transfers with the pointer that's passed in. 2. There's a second place where we might do an AUX transfer at probe time which is when we're using the DP AUX backlight. There we call drm_panel_dp_aux_backlight(). Conceivably this too could be deferred until the get_modes(), but now it feels even more like a hack. We're going to be registering the backlight in the first call to get_modes()? That's, ummm, unexpected. We could look at perhaps breaking the "DP AUX backlight" in two parts also, but that gets involved. I think we're supposed to know the number of backlight levels at device init time for backlight devices and we need an AUX transfer to that. So the answer is that we could probably make it work, but it seems like an uglier solution than just making the Qualcomm driver able to do AUX transfers when it should be able to. > So this is boiling down to why or how panel-eDP was originally designed. > > >>> This is why I think we need to move to Runtime PM to manage this. Basically: > >>> > >>> 1. When an AUX transfer happens, you grab a PM runtime reference that > >>> _that_ powers up the PHY. > > This will not be trivial and needs to be scoped out as sankeerth said > but if the above is the only concern, why do we need to do this? There > seems to be an explanation why we are doing this and its not a hack. > > How would Dmitry's rework address this? We need some RFC to conclude on > that first. > > >>> > >>> 2. At the end of the AUX transfer function, you do a "put_autosuspend". > >>> > >>> Then it becomes not a hack, right? > >>> > >>> > >> > >> pm runtime ops needs to be implemented for both eDP and DP. This change > >> take good amount of planning and code changes as it affects DP also. > >> > >> Because this patch series consist of basic eDP changes for SC7280 bootup, > >> shall we take this pm_runtime implementation in subsequent patch series? > > > > Dmitry is the real decision maker here, but in my opinion it would be > > OK to get something landed first that worked OK and wasn't taking us > > too far in the wrong direction and then we could get a follow up patch > > to move to pm_runtime. > > I would say the discussion changed into a direction of implementing > pm-runtime because the current patch series does what it takes to adhere > to panel-eDP's design along with aux bus requirements of PHY needing to > be on. > > So doug, to answer your questions here: > > "So I guess the net result is maybe we should just keep it where it is. > Long term I'd be interested in knowing if there's a reason why we > can't structure the driver so that AUX transfers can happen with less > intertwining with the rest of the code, but that can happen later. I > would expect that you'd basically just need clocks and regulators on > and maybe your PHY on." > > Yes PHY needs to be absolutely on and configured before aux transfers. > > If we want to change that up to stop reading the panel_id in the panel > probe() and do it later, perhaps some of the changes done here are not > needed. > > It only seems reasonable that we first prototype that in a separate > patch even a RFC perhaps and take this further as these set of changes > are needed for basic display functionality on sc7280 chromebooks. > > Let us know what are the concerns with doing it in a follow up change. As per above, I'm not objecting to it being a follow-up change, but I do believe it's the right design and will lead to an overall cleaner solution. I think I even mentioned in my reviews that the current patch series seems to "scattershot" enable resources and that's how we end up with patches like patch #5 in this series ("drm/msm/dp: prevent multiple votes for dp resources"). IMO there should be be a 1-to-1 mapping between "turn on resources" and "turn off resources" and it should be reference counted. So if your codepath turned on resources then it's up to your codepath to turn resources off when done. If a seconde code path might be running at the same time then it should also turn on/off resources itself. ...and it should all be managed by pm_runtime which is _exactly designed_ for this specific use case. -Doug
next prev parent reply other threads:[~2022-04-07 20:48 UTC|newest] Thread overview: 140+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-30 16:02 [PATCH v6 0/8] Add support for the eDP panel over aux_bus Sankeerth Billakanti 2022-03-30 16:02 ` Sankeerth Billakanti 2022-03-30 16:02 ` [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus Sankeerth Billakanti 2022-03-30 16:02 ` Sankeerth Billakanti 2022-03-30 23:19 ` Dmitry Baryshkov 2022-03-30 23:19 ` Dmitry Baryshkov 2022-03-31 0:33 ` Doug Anderson 2022-03-31 0:33 ` Doug Anderson 2022-03-31 23:22 ` Doug Anderson 2022-03-31 23:22 ` Doug Anderson 2022-04-02 10:37 ` Dmitry Baryshkov 2022-04-02 10:37 ` Dmitry Baryshkov 2022-04-02 17:06 ` Doug Anderson 2022-04-02 17:06 ` Doug Anderson 2022-04-02 20:26 ` Dmitry Baryshkov 2022-04-02 20:26 ` Dmitry Baryshkov 2022-04-04 20:53 ` Doug Anderson 2022-04-04 20:53 ` Doug Anderson 2022-04-05 12:53 ` Dmitry Baryshkov 2022-04-05 12:53 ` Dmitry Baryshkov 2022-04-05 17:02 ` Doug Anderson 2022-04-05 17:02 ` Doug Anderson 2022-04-05 17:36 ` Dmitry Baryshkov 2022-04-05 17:36 ` Dmitry Baryshkov 2022-04-05 18:11 ` Doug Anderson 2022-04-05 18:11 ` Doug Anderson 2022-04-07 14:19 ` Sankeerth Billakanti (QUIC) 2022-04-07 14:19 ` Sankeerth Billakanti (QUIC) 2022-04-07 17:07 ` Doug Anderson 2022-04-07 17:07 ` Doug Anderson 2022-04-07 20:11 ` Abhinav Kumar 2022-04-07 20:11 ` Abhinav Kumar 2022-04-07 20:47 ` Doug Anderson [this message] 2022-04-07 20:47 ` Doug Anderson 2022-04-07 22:03 ` Abhinav Kumar 2022-04-07 22:03 ` Abhinav Kumar 2022-04-07 23:34 ` Doug Anderson 2022-04-07 23:34 ` Doug Anderson 2022-04-07 23:46 ` Dmitry Baryshkov 2022-04-07 23:46 ` Dmitry Baryshkov 2022-04-08 0:21 ` Doug Anderson 2022-04-08 0:21 ` Doug Anderson 2022-04-08 12:19 ` Dmitry Baryshkov 2022-04-08 12:19 ` Dmitry Baryshkov 2022-04-08 13:43 ` Doug Anderson 2022-04-08 13:43 ` Doug Anderson 2022-04-08 14:58 ` Dmitry Baryshkov 2022-04-08 14:58 ` Dmitry Baryshkov 2022-04-08 17:23 ` Abhinav Kumar 2022-04-08 17:23 ` Abhinav Kumar 2022-04-07 23:35 ` Dmitry Baryshkov 2022-04-07 23:35 ` Dmitry Baryshkov 2022-04-08 0:20 ` Doug Anderson 2022-04-08 0:20 ` Doug Anderson 2022-04-08 12:13 ` Dmitry Baryshkov 2022-04-08 12:13 ` Dmitry Baryshkov 2022-04-08 13:56 ` Doug Anderson 2022-04-08 13:56 ` Doug Anderson 2022-04-08 14:17 ` Dmitry Baryshkov 2022-04-08 14:17 ` Dmitry Baryshkov 2022-03-30 16:02 ` [PATCH v6 2/8] drm/msm/dp: wait for hpd high before aux transaction Sankeerth Billakanti 2022-03-30 16:02 ` Sankeerth Billakanti 2022-03-31 23:22 ` Doug Anderson 2022-03-31 23:22 ` Doug Anderson 2022-04-04 12:43 ` Sankeerth Billakanti (QUIC) 2022-04-04 12:43 ` Sankeerth Billakanti (QUIC) 2022-03-30 16:02 ` [PATCH v6 3/8] drm/msm/dp: Support only IRQ_HPD and REPLUG interrupts for eDP Sankeerth Billakanti 2022-03-30 16:02 ` Sankeerth Billakanti 2022-03-31 23:22 ` Doug Anderson 2022-03-31 23:22 ` Doug Anderson 2022-04-04 12:56 ` Sankeerth Billakanti (QUIC) 2022-04-04 12:56 ` Sankeerth Billakanti (QUIC) 2022-03-30 16:02 ` [PATCH v6 4/8] drm/msm/dp: avoid handling masked interrupts Sankeerth Billakanti 2022-03-30 16:02 ` Sankeerth Billakanti 2022-03-30 22:16 ` Dmitry Baryshkov 2022-03-30 22:16 ` Dmitry Baryshkov 2022-03-31 5:53 ` Sankeerth Billakanti (QUIC) 2022-03-31 5:53 ` Sankeerth Billakanti (QUIC) 2022-03-31 10:10 ` Dmitry Baryshkov 2022-03-31 10:10 ` Dmitry Baryshkov 2022-03-31 11:04 ` Sankeerth Billakanti 2022-03-31 11:04 ` Sankeerth Billakanti 2022-03-31 11:06 ` Dmitry Baryshkov 2022-03-31 11:06 ` Dmitry Baryshkov 2022-04-04 17:56 ` Sankeerth Billakanti (QUIC) 2022-04-04 17:56 ` Sankeerth Billakanti (QUIC) 2022-03-30 16:02 ` [PATCH v6 5/8] drm/msm/dp: prevent multiple votes for dp resources Sankeerth Billakanti 2022-03-30 16:02 ` Sankeerth Billakanti 2022-03-31 23:23 ` Doug Anderson 2022-03-31 23:23 ` Doug Anderson 2022-04-08 16:14 ` Dmitry Baryshkov 2022-04-08 16:14 ` Dmitry Baryshkov 2022-04-08 17:12 ` Sankeerth Billakanti 2022-04-08 17:12 ` Sankeerth Billakanti 2022-04-08 18:02 ` Dmitry Baryshkov 2022-04-08 18:02 ` Dmitry Baryshkov 2022-03-30 16:02 ` [PATCH v6 6/8] drm/msm/dp: remove unnecessary delay during boot Sankeerth Billakanti 2022-03-30 16:02 ` Sankeerth Billakanti 2022-03-31 23:23 ` Doug Anderson 2022-03-31 23:23 ` Doug Anderson 2022-04-04 13:52 ` Sankeerth Billakanti (QUIC) 2022-04-04 13:52 ` Sankeerth Billakanti (QUIC) 2022-04-04 21:13 ` Dmitry Baryshkov 2022-04-04 21:13 ` Dmitry Baryshkov 2022-04-07 12:40 ` Sankeerth Billakanti (QUIC) 2022-04-07 12:40 ` Sankeerth Billakanti (QUIC) 2022-03-30 16:02 ` [PATCH v6 7/8] drm/msm/dp: Support edp/dp without hpd Sankeerth Billakanti 2022-03-30 16:02 ` Sankeerth Billakanti 2022-03-31 23:23 ` Doug Anderson 2022-03-31 23:23 ` Doug Anderson 2022-04-04 18:32 ` Sankeerth Billakanti (QUIC) 2022-04-04 18:32 ` Sankeerth Billakanti (QUIC) 2022-04-04 21:15 ` Dmitry Baryshkov 2022-04-04 21:15 ` Dmitry Baryshkov 2022-04-07 12:41 ` Sankeerth Billakanti (QUIC) 2022-04-07 12:41 ` Sankeerth Billakanti (QUIC) 2022-03-30 16:02 ` [PATCH v6 8/8] drm/msm/dp: Handle eDP mode_valid differently from dp Sankeerth Billakanti 2022-03-30 16:02 ` Sankeerth Billakanti 2022-03-30 22:08 ` Dmitry Baryshkov 2022-03-30 22:08 ` Dmitry Baryshkov 2022-03-31 6:02 ` Sankeerth Billakanti (QUIC) 2022-03-31 6:02 ` Sankeerth Billakanti (QUIC) 2022-03-31 23:24 ` Doug Anderson 2022-03-31 23:24 ` Doug Anderson 2022-04-04 18:20 ` Sankeerth Billakanti (QUIC) 2022-04-04 18:20 ` Sankeerth Billakanti (QUIC) 2022-04-04 21:29 ` Dmitry Baryshkov 2022-04-04 21:29 ` Dmitry Baryshkov 2022-04-07 14:05 ` Sankeerth Billakanti (QUIC) 2022-04-07 14:05 ` Sankeerth Billakanti (QUIC) 2022-04-08 12:08 ` Dmitry Baryshkov 2022-04-08 12:08 ` Dmitry Baryshkov 2022-04-08 15:50 ` Sankeerth Billakanti 2022-04-08 15:50 ` Sankeerth Billakanti 2022-04-08 16:47 ` Dmitry Baryshkov 2022-04-08 16:47 ` Dmitry Baryshkov 2022-04-08 17:38 ` Sankeerth Billakanti 2022-04-08 17:38 ` Sankeerth Billakanti 2022-04-08 18:06 ` Dmitry Baryshkov 2022-04-08 18:06 ` Dmitry Baryshkov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAD=FV=UmU_BVUaL_X75yOEvQPtGUBTR5-jiVWBHq7uSRt6HM4Q@mail.gmail.com' \ --to=dianders@chromium.org \ --cc=airlied@linux.ie \ --cc=bjorn.andersson@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=dmitry.baryshkov@linaro.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=quic_abhinavk@quicinc.com \ --cc=quic_aravindh@quicinc.com \ --cc=quic_kalyant@quicinc.com \ --cc=quic_khsieh@quicinc.com \ --cc=quic_sbillaka@quicinc.com \ --cc=quic_vproddut@quicinc.com \ --cc=sean@poorly.run \ --cc=seanpaul@chromium.org \ --cc=swboyd@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.