Hi Andreas,
Thanks for the comments.
On 4/14/22 3:15 AM, Andreas Kemnade wrote:
> Hi Samuel,
>
> for comparison, here is my submission for the IMX EPDC bindings:
>
> https://lore.kernel.org/linux-devicetree/20220206080016.796556-2-andr...@kemnade.info/
>
> On Wed, 13 Apr 2022 17:19:02 -0500
>
> From: Jason Gunthorpe
> Sent: Thursday, April 14, 2022 10:22 PM
>
> On Thu, Apr 14, 2022 at 09:51:49AM -0400, Matthew Rosato wrote:
> > On 4/12/22 11:53 AM, Jason Gunthorpe wrote:
> > > When the open_device() op is called the container_users is incremented
> and
> > > held incremented until
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 40354149f4d738dc3492d9998e45b3f02950369a Add linux-next specific
files for 20220414
Error/Warning reports:
https://lore.kernel.org/linux-mm/202203160358.yulpl6b4-...@intel.com
https
On 4/14/2022 5:36 PM, Dmitry Baryshkov wrote:
On 15/04/2022 02:17, Abhinav Kumar wrote:
On 2/4/2022 2:43 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
kms_writeback test cases also verify with a null fb for the
writeback connector job. In addition there are also
On 09/04/2022 05:36, Douglas Anderson wrote:
Let's add support for being able to read the HPD pin even if it's
hooked directly to the controller. This will allow us to get more
accurate delays also lets us take away the waiting in the AUX transfer
functions of the eDP controller drivers.
On 09/04/2022 05:36, Douglas Anderson wrote:
Sometimes it's useful for users of the DP AUX bus (like panels) to be
able to poll HPD. Let's add a callback that allows DP AUX busses
drivers to provide this.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Douglas Anderson
Reviewed-by: Dmitry
On 09/04/2022 05:36, Douglas Anderson wrote:
As talked about in the kerneldoc for "struct dp_aux_ep_client" in this
patch and also in the past in commit a1e3667a9835 ("drm/bridge:
ti-sn65dsi86: Promote the AUX channel to its own sub-dev"), to use the
DP AUX bus properly we really need two
On 15/04/2022 02:17, Abhinav Kumar wrote:
On 2/4/2022 2:43 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
kms_writeback test cases also verify with a null fb for the
writeback connector job. In addition there are also other
commit paths which can result in kickoffs
Sorry for multiple replies on this, I missed responding to one question.
On 4/14/2022 5:27 PM, Abhinav Kumar wrote:
On 4/14/2022 5:19 PM, Dmitry Baryshkov wrote:
On 15/04/2022 03:01, Abhinav Kumar wrote:
On 4/14/2022 4:25 PM, Dmitry Baryshkov wrote:
On 15/04/2022 00:50, Abhinav Kumar
On 4/14/2022 5:19 PM, Dmitry Baryshkov wrote:
On 15/04/2022 03:01, Abhinav Kumar wrote:
On 4/14/2022 4:25 PM, Dmitry Baryshkov wrote:
On 15/04/2022 00:50, Abhinav Kumar wrote:
On 2/4/2022 2:19 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add changes to
On 15/04/2022 01:16, Abhinav Kumar wrote:
On 2/4/2022 3:19 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Introduce the dpu_encoder_phys_* for the writeback interface
to handle writeback specific hardware programming.
Signed-off-by: Abhinav Kumar
Mostly looks ok,
On 15/04/2022 03:01, Abhinav Kumar wrote:
On 4/14/2022 4:25 PM, Dmitry Baryshkov wrote:
On 15/04/2022 00:50, Abhinav Kumar wrote:
On 2/4/2022 2:19 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add changes to support writeback module in the dpu_hw_ctl
interface. In
On Tue, Apr 12, 2022 at 03:59:55PM -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The latest GuC firmware drops the context descriptor pool in favour of
> passing all creation data in the create H2G. It also greatly simplifies
> the work queue and removes the process
Quoting Kuogee Hsieh (2022-04-14 14:51:19)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 01453db..baba95d 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -230,6 +231,18 @@ void
On 4/14/2022 4:25 PM, Dmitry Baryshkov wrote:
On 15/04/2022 00:50, Abhinav Kumar wrote:
On 2/4/2022 2:19 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add changes to support writeback module in the dpu_hw_ctl
interface. In addition inroduce a reset_intf_cfg op to
Quoting Douglas Anderson (2022-04-08 19:36:23)
> As talked about in the kerneldoc for "struct dp_aux_ep_client" in this
> patch and also in the past in commit a1e3667a9835 ("drm/bridge:
> ti-sn65dsi86: Promote the AUX channel to its own sub-dev"), to use the
> DP AUX bus properly we really need
On 15/04/2022 01:06, Kuogee Hsieh wrote:
On 4/8/2022 4:59 PM, Dmitry Baryshkov wrote:
On Fri, 8 Apr 2022 at 23:30, Kuogee Hsieh
wrote:
On 4/8/2022 5:27 AM, Dmitry Baryshkov wrote:
On 07/04/2022 00:28, Kuogee Hsieh wrote:
dp_hpd_plug_handle() is responsible for setting up main link and
On Thu, Apr 14, 2022 at 2:33 PM Dave Airlie wrote:
>
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-04-15
.. and since I'm now back home, I can confirm that my boot-time splat
I saw before is all gone.
It presumably went away with the previous pull request already, but I
hadn't
The pull request you sent on Fri, 15 Apr 2022 07:33:01 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-04-15
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/028192fea1de083f4f12bfb1eb7c4d7beb5c8ecd
Thank you!
--
Deet-doot-dot, I am a bot.
On 15/04/2022 00:50, Abhinav Kumar wrote:
On 2/4/2022 2:19 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add changes to support writeback module in the dpu_hw_ctl
interface. In addition inroduce a reset_intf_cfg op to reset
the interface bits for the currently active
On 2/4/2022 2:43 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
kms_writeback test cases also verify with a null fb for the
writeback connector job. In addition there are also other
commit paths which can result in kickoffs without a valid
framebuffer like while
Hi Marijn
Thank you for your suggestion.
I will address it and add your "Reported by".
Thanks
Abhinav
On 4/14/2022 3:26 PM, Marijn Suijten wrote:
On 2022-02-04 13:17:19, Abhinav Kumar wrote:
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
On 2022-02-04 13:17:19, Abhinav Kumar wrote:
> Make changes to dpu_encoder to support virtual encoder needed
> to support writeback for dpu.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 57
> +
> 1 file changed, 42
On 2/4/2022 2:34 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Initialize dpu encoder and connector for writeback if the
target supports it in the catalog.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 37 -
On 2/4/2022 3:19 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Introduce the dpu_encoder_phys_* for the writeback interface
to handle writeback specific hardware programming.
Signed-off-by: Abhinav Kumar
Mostly looks ok, see minor comments bellow.
---
On 4/8/2022 4:59 PM, Dmitry Baryshkov wrote:
On Fri, 8 Apr 2022 at 23:30, Kuogee Hsieh wrote:
On 4/8/2022 5:27 AM, Dmitry Baryshkov wrote:
On 07/04/2022 00:28, Kuogee Hsieh wrote:
dp_hpd_plug_handle() is responsible for setting up main link and send
uevent to notify user space framework
On 2/4/2022 3:36 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
This patch will change significantly if
Signed-off-by: Abhinav Kumar
---
On 2/4/2022 3:46 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add an API to reset the encoder related hw blocks to ensure
a proper teardown of the pipeline. At the moment this is being
used only for the writeback encoder but eventually we can start
using this for all
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at dp_display_bind()
Changes in v3:
-- disable all HDP
Hi,
On Thu, Apr 14, 2022 at 2:16 PM Dmitry Baryshkov
wrote:
>
> > Hmm, interesting. Probably for DRM_BRIDGE_OP_MODES that will work?
> > It's definitely worth confirming but from my reading of the code it
> > _probably_ wouldn't hurt.
> >
> > One thing someone would want to confirm would be what
On 2/4/2022 2:19 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add changes to support writeback module in the dpu_hw_ctl
interface. In addition inroduce a reset_intf_cfg op to reset
the interface bits for the currently active interfaces in
the ctl path.
On Thu, Apr 14, 2022 at 03:58:02PM +, Sean Paul wrote:
> On Tue, Apr 12, 2022 at 09:25:59AM -0400, Rodrigo Vivi wrote:
> > On Mon, Apr 11, 2022 at 08:47:32PM +, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > This patch updates the connector's property value in 2 cases which were
> >
On 15/04/2022 00:28, Abhinav Kumar wrote:
Hi Dmitry
Thanks for the review.
Finally got back to this series after getting acks on the drm_writeback
core changes.
On 2/4/2022 2:56 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add the dpu_hw_wb abstraction to program
Hey Linus,
Eggs season holidays are among us, and I think I'd expect some smaller
pulls for 2 weeks then, rc5 having a blow out, as this seems eerily
quiet. One i915 fix, amdgpu has a bunch and msm. I didn't see a misc
pull this week, so I expect that will catch up next week.
Dave.
On 15/04/2022 00:26, Kuogee Hsieh wrote:
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at
On 2/4/2022 3:43 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add writeback blocks to DPU resource manager so that
writeback encoders can request for writeback hardware blocks
through RM and their usage can be tracked.
Signed-off-by: Abhinav Kumar
[please excuse
Hi Dmitry
Thanks for the review.
Finally got back to this series after getting acks on the drm_writeback
core changes.
On 2/4/2022 2:56 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add the dpu_hw_wb abstraction to program registers related to the
writeback block.
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at dp_display_bind()
Changes in v3:
-- disable all HDP
On 12/04/2022 00:58, Rob Clark wrote:
From: Rob Clark
Prep for a following patch, where it gets a bit more complicated.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_gem.c | 2 +-
drivers/gpu/drm/msm/msm_gem.h | 1 +
On 12/04/2022 00:58, Rob Clark wrote:
From: Rob Clark
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_gem_vma.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
On 14/04/2022 23:09, Doug Anderson wrote:
Hi,
On Thu, Apr 14, 2022 at 12:40 PM Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-04-14 12:16:14)
I think it's too verbose and a bit incorrect.
Not sure which part you're asserting is incorrect, but shorter is OK w/ me too.
I was
Two stages are required to setup up main link to be ready to transmit
video stream.
Stage 1: dp_hpd_plug_handle() perform link training to set up main link
stage 2: user space framework (msm_dp_display_enable()) to enable pixel
clock and transfer main link to video ready state.
At current
On 04/11, Tales Lelo da Aparecida wrote:
> Fix a copypasta error, which resulted in checking repeatedly if the
> primary_composer->map[0] was null, instead of checking each
> plane_composer while composing planes.
>
> Signed-off-by: Tales Lelo da Aparecida
Hi Tales,
Nice catch!
I suggest you
Hello dri-devel & dim users,
I committed this patch to the drm-misc-next branch:
commit d6cd978f7e6b6f6895f8d0c4ce6e5d2c8e979afe
video: fbdev: fbmem: fix pointer reference to null device field
then I noticed that it was fixed already in another branch which led to this
error:
Merging
On 14/04/2022 23:19, Abhinav Kumar wrote:
On 4/14/2022 1:03 PM, Dmitry Baryshkov wrote:
On 14/04/2022 23:00, Abhinav Kumar wrote:
Hi Dmitry
On 4/14/2022 12:43 PM, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-04-14 12:20:31)
On 14/04/2022 19:40, Doug Anderson wrote:
Hi,
On Thu, Apr
On 4/14/2022 1:03 PM, Dmitry Baryshkov wrote:
On 14/04/2022 23:00, Abhinav Kumar wrote:
Hi Dmitry
On 4/14/2022 12:43 PM, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-04-14 12:20:31)
On 14/04/2022 19:40, Doug Anderson wrote:
Hi,
On Thu, Apr 14, 2022 at 5:19 AM Sankeerth Billakanti
On 3/16/2022 9:45 AM, Sankeerth Billakanti (QUIC) wrote:
Subject: Re: [RFC PATCH v2 4/5] drm/msm/dp: replace dp_connector with
drm_bridge_connector
Date: Wed, 23 Feb 2022 16:40:56 -0800
From: Kuogee Hsieh
To: Stephen Boyd , Dmitry Baryshkov
CC: Abhinav Kumar , Bjorn Andersson
, Rob Clark ,
On 3/16/2022 9:31 AM, Sankeerth Billakanti (QUIC) wrote:
Subject: [RFC PATCH v2 5/5] drm/msm/dp: remove extra wrappers and
public functions
Date: Sat, 12 Feb 2022 01:40:06 +0300
From: Dmitry Baryshkov
To: Bjorn Andersson , Rob Clark
, Sean Paul , Abhinav Kumar
, Kuogee Hsieh
CC: Stephen
Hi,
On Thu, Apr 14, 2022 at 12:40 PM Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-04-14 12:16:14)
> >
> > I think it's too verbose and a bit incorrect.
Not sure which part you're asserting is incorrect, but shorter is OK w/ me too.
> > This is a bit saner:
> > /*
> > * These ops
On Tue, 2022-04-12 at 12:53 -0300, Jason Gunthorpe wrote:
> Every caller has a readily available vfio_device pointer, use that
> instead
> of passing in a generic struct device. The struct vfio_device already
> contains the group we need so this avoids complexity, extra
> refcountings,
> and a
On 14/04/2022 23:00, Abhinav Kumar wrote:
Hi Dmitry
On 4/14/2022 12:43 PM, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-04-14 12:20:31)
On 14/04/2022 19:40, Doug Anderson wrote:
Hi,
On Thu, Apr 14, 2022 at 5:19 AM Sankeerth Billakanti
wrote:
This series adds support for generic eDP
Hi Dmitry
On 4/14/2022 12:43 PM, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-04-14 12:20:31)
On 14/04/2022 19:40, Doug Anderson wrote:
Hi,
On Thu, Apr 14, 2022 at 5:19 AM Sankeerth Billakanti
wrote:
This series adds support for generic eDP panel over aux_bus.
These changes are
On 14/04/2022 20:25, Kuogee Hsieh wrote:
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at
On Tue, 2022-04-12 at 12:53 -0300, Jason Gunthorpe wrote:
> The next patch wants the vfio_device instead. There is no reason to
> store
> a pointer here since we can container_of back to the vfio_device.
>
> Signed-off-by: Jason Gunthorpe
> ---
> drivers/s390/cio/vfio_ccw_cp.c | 44
Quoting Kuogee Hsieh (2022-04-14 10:25:37)
> Current DP driver implementation, event thread is kept running
> after DP display is unbind. This patch fix this problem by disabling
> DP irq and stop event thread to exit gracefully at dp_display_unbind().
>
> Changes in v2:
> -- start event thread at
Quoting Dmitry Baryshkov (2022-04-14 12:20:31)
> On 14/04/2022 19:40, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Apr 14, 2022 at 5:19 AM Sankeerth Billakanti
> > wrote:
> >>
> >> This series adds support for generic eDP panel over aux_bus.
> >>
> >> These changes are dependent on the following
On Tue, 2022-04-12 at 12:53 -0300, Jason Gunthorpe wrote:
> All callers have a struct vfio_device trivially available, pass it in
> directly and avoid calling the expensive vfio_group_get_from_dev().
>
> To support the unconverted kvmgt mdev driver add
> mdev_legacy_get_vfio_device() which will
Quoting Dmitry Baryshkov (2022-04-14 12:16:14)
>
> I think it's too verbose and a bit incorrect.
> This is a bit saner:
> /*
> * These ops do not make sense for eDP, since they are provided
> * by the panel-bridge corresponding to the attached eDP panel.
> */
>
> My question was whether we
Quoting Kuogee Hsieh (2022-04-14 09:34:55)
>
> On 4/13/2022 5:02 PM, Stephen Boyd wrote:
> > The subject is still misleading. It is fixing something. It may be
> > enhancing it as well but it is clearly fixing it first.
> >
[...]
> > I'd prefer this part to be a different patch. It can come after
On 14/04/2022 19:40, Doug Anderson wrote:
Hi,
On Thu, Apr 14, 2022 at 5:19 AM Sankeerth Billakanti
wrote:
This series adds support for generic eDP panel over aux_bus.
These changes are dependent on the following series:
On 14/04/2022 19:39, Doug Anderson wrote:
Hi,
On Thu, Apr 14, 2022 at 5:20 AM Sankeerth Billakanti
wrote:
@@ -1530,6 +1532,60 @@ void msm_dp_debugfs_init(struct msm_dp *dp_display,
struct drm_minor *minor)
}
}
+static int dp_display_get_next_bridge(struct msm_dp *dp)
+{
+
There are various SKUs of A619, ranging from 565 MHz to 850 MHz, depending
on the bin. Add support for distinguishing them, so that proper frequency
ranges can be applied, depending on the HW.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
Add support for the Adreno 619 GPU, as found in Snapdragon 690 (SM6350),
480 (SM4350) and 750G (SM7225).
Signed-off-by: Konrad Dybcio
---
Changes in v2:
- Don't reserve icache/dcache regions on legacy GMUs, as that
is apparently not necessary and simply a downstream leftover.
Leading spaces are not something checkpatch likes, and it says so when
they are present. Use tabs consistently to indent function body and
unwrap a 83-char-long line, as 100 is cool nowadays.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 17 -
1 file
Previous concern with using drm_clflush_sg was that we don't know what the
sg_table is pointing to, thus the usage of wbinvd_on_all_cpus to flush
everything at once to avoid paranoia.
To make i915 more architecture-neutral and be less paranoid, lets attempt to
use drm_clflush_sg to flush the
To align with the discussion in [1][2], this patch series drops all usage of
wbvind_on_all_cpus within i915 by either replacing the call with certain
drm clflush helpers, or reverting to a previous logic.
To align with the discussion in [1][2], this patch series drops all usage of
wbvind_on_all_cpus within i915 by either replacing the call with certain
drm clflush helpers, or reverting to a previous logic.
Previous concern with using drm_clflush_sg was that we don't know what the
sg_table is pointing to, thus the usage of wbinvd_on_all_cpus to flush
everything at once to avoid paranoia.
To make i915 more architecture-neutral and be less paranoid, lets attempt to
use drm_clflush_sg to flush the
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at dp_display_bind()
Changes in v3:
-- disable all HDP
On 14/04/2022 15:41, Thomas Hellström wrote:
Hi,
On 4/12/22 21:38, Robert Beckett wrote:
+struct ttm_resource *
+i915_gem_stolen_reserve_range(struct drm_i915_private *i915,
+ resource_size_t size,
+ u64 start, u64 end)
{
- int ret;
+ struct
On 4/13/2022 4:19 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-04-13 14:04:25)
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Hi,
On Thu, Apr 14, 2022 at 5:19 AM Sankeerth Billakanti
wrote:
>
> This series adds support for generic eDP panel over aux_bus.
>
> These changes are dependent on the following series:
> https://patchwork.kernel.org/project/linux-arm-msm/list/?series=613654=*
You're basically depending on the
Hi,
On Thu, Apr 14, 2022 at 5:20 AM Sankeerth Billakanti
wrote:
>
> The eDP controller does not have a reliable way keep panel
> powered on to read the sink capabilities. So, the controller
> driver cannot validate if a mode can be supported by the
> source. We will rely on the panel driver to
Hi,
On Thu, Apr 14, 2022 at 5:20 AM Sankeerth Billakanti
wrote:
>
> The source device should ensure the sink is ready before proceeding to
> read the sink capability or perform any aux transactions. The sink
> will indicate its readiness by asserting the HPD line. The controller
> driver needs
Hi,
On Thu, Apr 14, 2022 at 5:20 AM Sankeerth Billakanti
wrote:
>
> The panel-edp enables the eDP panel power during probe, get_modes
> and enable.
Technically the panel-edp powers on the panel in pre_enable()
> The eDP connect and disconnect interrupts for the eDP/DP
> controller are
Hi,
On Thu, Apr 14, 2022 at 5:20 AM Sankeerth Billakanti
wrote:
>
> @@ -1530,6 +1532,60 @@ void msm_dp_debugfs_init(struct msm_dp *dp_display,
> struct drm_minor *minor)
> }
> }
>
> +static int dp_display_get_next_bridge(struct msm_dp *dp)
> +{
> + int rc;
> + struct
On 4/13/2022 5:02 PM, Stephen Boyd wrote:
The subject is still misleading. It is fixing something. It may be
enhancing it as well but it is clearly fixing it first.
Quoting Kuogee Hsieh (2022-04-06 14:28:13)
dp_hpd_plug_handle() is responsible for setting up main link and send
uevent to
> -Original Message-
> From: Belgaumkar, Vinay
> Sent: Thursday, April 14, 2022 8:38 PM
> To: Gupta, Anshuman
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Use i915_probe_error
> instead of drm_err
>
>
>
On Thu, 14 Apr 2022, "Belgaumkar, Vinay" wrote:
> On 4/13/2022 11:41 PM, Anshuman Gupta wrote:
>> On 2022-04-13 at 04:18:52 +0530, Vinay Belgaumkar wrote:
>>> This will ensure we don't have false positives when we run
>>> error injection tests.
>>>
>>> Signed-off-by: Vinay Belgaumkar
>>> ---
>>>
On 14/04/2022 15:05, Thomas Hellström wrote:
On Tue, 2022-04-12 at 15:18 +, Robert Beckett wrote:
stolen/kernel buffers should not be mmapable by userland.
do not provide callbacks to facilitate this for these buffers.
Signed-off-by: Robert Beckett
---
On Tue, Apr 12, 2022 at 09:41:35AM -0400, Rodrigo Vivi wrote:
> On Mon, Apr 11, 2022 at 08:47:29PM +, Sean Paul wrote:
> > From: Sean Paul
> >
> > Rebased set from November. Fixed a nit from Stephen in the msm patch and
> > moved hdcp registers into the trogdor dtsi file to avoid differences
On Tue, Apr 12, 2022 at 09:25:59AM -0400, Rodrigo Vivi wrote:
> On Mon, Apr 11, 2022 at 08:47:32PM +, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch updates the connector's property value in 2 cases which were
> > previously missed:
> >
> > 1- Content type changes. The value should
Hi "jason-jh.lin",
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on robh/for-next krzk/for-next linus/master v5.18-rc2
next-20220414]
[If your patch is applied to the wrong git tree, kindly drop us a note
Hi.
On Thu, Apr 14, 2022 at 10:50 PM Michel Dänzer
wrote:
>
> On 2022-04-14 15:34, Alex Deucher wrote:
> > On Thu, Apr 14, 2022 at 4:44 AM Christian König
> > wrote:
> >> Am 14.04.22 um 09:37 schrieb Michel Dänzer:
> >>> On 2022-04-14 08:24, Christian König wrote:
> Am 13.04.22 um 18:14
Convert drm_find_cea_extension() to a predicate function to check if the
EDID has a CTA extension or a DisplayID CTA data block. This is mainly
to avoid adding new users that only find the first CTA extension.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 19
The DisplayID CTA data block version does not necessarily match the CTA
revision. Simplify by postponing drm_edid_to_eld() slightly, and reusing
the CTA revision extracted by drm_parse_cea_ext().
By not bailing out early in drm_edid_to_eld() we may end up filling
meaningless data to the ELD.
Convert drm_find_cea_extension() to EDID block iterator in color format
and CTA revision detection. Detect them in all CTA extensions.
Also parse CTA Data Blocks in DisplayID even if there's no CTA EDID
extension.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c |
Convert drm_find_cea_extension() to EDID block iterator in basic audio
detection. Detect basic audio in all CEA extensions.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git
During the transition, we accepted a void pointer for a poor C
programmer's version of polymorphism. Switch the functions to use struct
cea_db * to regain some more type safety.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 21 +
1 file
Iterate through all CTA data blocks across all CTA Extensions and
DisplayID data blocks.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c
All CTA data block iteration has now been converted to the new cea db
iterators.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 45 --
1 file changed, 45 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c
Use the cea db iterator for short audio descriptors. We'll still stop at
the first audio data block, but not at the first CTA Extension if that
doesn't have the info.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 34 +-
1 file
Iterate through all CTA data blocks across all CTA extensions and
DisplayID data blocks. This may gather more data than before, and if
there's duplicated data, some is overwritten by whichever comes last.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 64
On 4/13/2022 11:41 PM, Anshuman Gupta wrote:
On 2022-04-13 at 04:18:52 +0530, Vinay Belgaumkar wrote:
This will ensure we don't have false positives when we run
error injection tests.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 42
Iterate through all CEA data blocks.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index
Iterate through all CTA data blocks, not just the first CTA extension.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c
Iterate through all CTA EDID extension blocks and DisplayID CTA data
blocks to add CEA modes.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 67 ++
1 file changed, 31 insertions(+), 36 deletions(-)
diff --git
Use the cea db iterator for speaker allocation. We'll still stop at the
first speaker data block, but not at the first CTA extension if that
doesn't have the info.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 47 --
1 file
Add an iterator abstraction for going through all the EDID blocks.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 48 ++
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
Abstract helpers for matching vendor data blocks and extended tags, and
use them to simplify all the cea_db_is_*() functions.
Take void pointer as parameter to allow transitional use for both u8 *
and struct cea_db *.
v2: Remove superfluous parens (Ville)
Cc: Ville Syrjälä
Signed-off-by: Jani
1 - 100 of 180 matches
Mail list logo
