On Sat, 23 Apr 2022 at 03:12, Abhinav Kumar wrote:
>
>
>
> On 4/22/2022 5:07 PM, Dmitry Baryshkov wrote:
> > On 23/04/2022 02:45, Kuogee Hsieh wrote:
> >> Current DP driver implementation has adding safe mode done at
> >> dp_hpd_plug_handle() which is expected to be executed under event
> >> threa
Hi Linus,
Maarten was away, so Maxine stepped up and sent me the drm-fixes
merge, so no point leaving it for another week. The big change is an
OF revert around bridge/panels, it may have some driver fallout, but
hopefully this revert gets them shook out in the next week easier.
Otherwise it's a b
On Fri 22 Apr 16:07 PDT 2022, Dmitry Baryshkov wrote:
> On 23/04/2022 01:32, Bjorn Andersson wrote:
[..]
> > diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c
> > b/drivers/gpu/drm/msm/dp/dp_drm.c
> > index 80f59cf99089..76904b1601b1 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> > +++ b/drivers/gp
The i.MX8MP contains two syscon registers which are responsible
for configuring the on-SoC DPI-to-LVDS serializer. Implement a
simple bridge driver for this serializer.
Reviewed-by: Sam Ravnborg
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Peng Fan
Cc
The i.MX8MP contains two syscon registers which are responsible
for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding
which represents this serializer as a bridge.
Acked-by: Sam Ravnborg
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Peng Fan
On 4/22/22 20:26, Sam Ravnborg wrote:
Hi Marek, I read the patch once more.
On Mon, Apr 18, 2022 at 04:51:04PM +0200, Marek Vasut wrote:
The i.MX8MP contains two syscon registers which are responsible
Here it says i.MX8MP
Fixed, this and the bindings.
On 4/22/22 20:39, Sam Ravnborg wrote:
On Sun, Apr 17, 2022 at 04:07:57AM +0200, Marek Vasut wrote:
Wrap FIFO reset and comments into mxsfb_reset_block(), this is a clean up.
No functional change.
Reviewed-by: Lucas Stach
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc
Quoting Sankeerth Billakanti (2022-04-22 02:11:06)
> 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 populate only
> the
Quoting Sankeerth Billakanti (2022-04-22 02:11:05)
> 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 to wait for the hpd
Fix kernel-doc warnings for a comment that should not use
kernel-doc notation:
dmub_psr.c:235: warning: This comment starts with '/**', but isn't a kernel-doc
comment. Refer Documentation/doc-guide/kernel-doc.rst
* Set PSR power optimization flags.
dmub_psr.c:235: warning: missing initial short
Quoting Sankeerth Billakanti (2022-04-22 02:11:04)
> The panel-edp enables the eDP panel power during probe, get_modes
> and pre-enable. The eDP connect and disconnect interrupts for the eDP/DP
> controller are directly dependent on panel power. As eDP display can be
> assumed as always connected,
Quoting Sankeerth Billakanti (2022-04-22 02:11:03)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index d7a19d6..055681a 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
Some nitpicks
Reviewed-by: Stephen
On 4/22/2022 5:07 PM, Dmitry Baryshkov wrote:
On 23/04/2022 02:45, Kuogee Hsieh wrote:
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow s
On 23/04/2022 02:45, Kuogee Hsieh wrote:
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_hand
Quoting Kuogee Hsieh (2022-04-22 16:45:23)
> Current DP driver implementation has adding safe mode done at
> dp_hpd_plug_handle() which is expected to be executed under event
> thread context.
>
> However there is possible circular locking happen (see blow stack trace)
> after edp driver call dp_hp
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is execu
han the
> one that removed mach/io.h.
>
> I had sx1 booting in qemu at least, with the omap1 multiplatform series only.
> If you have a custom config for this one, make sure you get the right
> DEBUG_LL address.
>
> > I'll do another round of bisects.
>
Here is the b
On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote:
> On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck wrote:
> > On 4/22/22 12:16, Arnd Bergmann wrote:
> > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck wrote:
> > >
> > > Which machine did you hit this on? Is this on hardware or in qem
Hi Liviu
Thank you for the feedback.
I have fixed the order of copyright years in all the changes in the next
version.
Thanks
Abhinav
On 4/21/2022 5:16 AM, Liviu Dudau wrote:
On Tue, Apr 19, 2022 at 06:45:56PM -0700, Abhinav Kumar wrote:
Add writeback blocks to the sm8250 DPU hardware cat
Add wb_idx to existing DRM prints in dpu_encoder and also
print the intf_mode so that its clear that for any INTF_CMD/VID
there will be a valid intf_idx and any INTF_WB_* there will be a
valid wb_idx.
Update the debugfs to add the same information. Here is a sample
output with this change:
root:/
Add writeback block information while capturing the display
snapshot.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/di
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 closing the fb which results in the
callback to drm_atomic_helper_dirtyfb() which internally
trigger
Change the DRM traces to include both the intf_mode
and wb_idx similar to the DRM prints in the previous change.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 -
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 26 ++
Introduce the dpu_encoder_phys_* for the writeback interface
to handle writeback specific hardware programming.
changes in v4:
- squash the encoder_phys_wb bits from [1]
- since its a trivial change of a previously acked change
preserving the ack
[1] https://patchwork.fr
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 interfaces.
changes in v4:
- none
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry
add dpu encoder APIs to prepare and cleanup writeback job
for the writeback encoder. These shall be invoked from the
prepare_wb_job/cleanup_wb_job hooks of the drm_writeback
framework.
changes in v3:
- none
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/
Introduce the dpu_writeback module which serves as the
interface between dpu operations and the drm_writeback.
This module manages the connector related operations for
dpu writeback.
changes in v2:
- start using drm_writeback_connector_init_with_encoder()
- drop unnecessary argume
On 23/04/2022 01:32, Bjorn Andersson wrote:
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
oob_hotplug_event() callback, by amending the dp_hpd module
Initialize dpu encoder and connector for writeback if the
target supports it in the catalog.
changes in v2:
- start initialing the encoder for writeback since we
have migrated to using drm_writeback_connector_init_with_encoder()
- instead of checking for WB_2 inside _dpu_km
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
changes in v4:
- squash dpu_encoder pieces from [1]
[1] https://patchwork.freedesktop.org/patch/483099/?series=102964&rev=2
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_enc
_dpu_plane_get_qos_lut() is not specific to just dpu_plane.
It can take any fill level and return the LUT matching it.
This can be used even for other modules like dpu_writeback.
Move _dpu_plane_get_qos_lut() to the common dpu_hw_util file
and rename it to _dpu_hw_get_qos_lut().
Signed-off-by: Ab
Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.
changes in v3:
- start using the common struct dpu_hw_cdp_cfg
- leave a comment about DPU non-DPU_
Add writeback blocks to the sm8250 DPU hardware catalog. Other
chipsets support writeback too but add it to sm8250 to prototype
the feature so that it can be easily extended to other chipsets.
changes in v4:
- fix the copyright year order
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry
Add changes to support writeback module in the dpu_hw_ctl
interface.
changes in v4:
- fix the copyright year order
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 52 --
drivers/gpu/drm/msm/disp/dpu
Rename dpu_hw_pipe_cdp_cfg to dpu_hw_cdp_cfg and move it
to dpu_hw_utils file so that other modules in addition to
SSPP such as writeback can use it as all the fields can
be used by writeback as well.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
Add writeback blocks to DPU resource manager so that
the encoders can directly request them through RM.
changes in v4:
- absorb dpu_rm.h header change from [1]
- since its a trivial change absorbed from an approved
patch, preserving the previous ack on this
[1] https://p
Add a reset_intf_cfg operation for dpu_hw_ctl to reset the
entire CTL path by disabling each component namely layer mixer,
3d-merge and interface blocks.
changes in v3:
- none
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 32
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware, a
For vendors drivers which pass an already allocated and
initialized encoder especially for cases where the encoder
hardware is shared OR the writeback encoder shares the resources
with the rest of the display pipeline introduce a new API,
drm_writeback_connector_init_with_encoder() which expects
an
This series adds support for writeback block on DPU. Writeback
block is extremely useful to validate boards having no physical displays
in addition to many other use-cases where we want to get the output
of the display pipeline to examine whether issue is with the display
pipeline or with the panel
Clients of drm_writeback_connector_init() initialize the
possible_crtcs and then invoke the call to this API.
To simplify things, allow passing possible_crtcs as a parameter
to drm_writeback_connector_init() and make changes to the
other drm drivers to make them compatible with this change.
chang
Quoting Arnd Bergmann (2022-04-19 09:37:59)
> From: Arnd Bergmann
>
> The get_sdram_rows() and get_memclkdiv() helpers need smemc
> register that are separate from the clk registers, move
> them out of the clk driver, and use an extern declaration
> instead.
>
> Cc: Michael Turquette
> Cc: Step
Quoting Arnd Bergmann (2022-04-19 09:37:58)
> diff --git a/include/linux/clk/pxa.h b/include/linux/clk/pxa.h
> new file mode 100644
> index ..e5516c608c99
> --- /dev/null
> +++ b/include/linux/clk/pxa.h
> @@ -0,0 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifdef CONFI
On 22/04/2022 13:42, Dmitry Baryshkov wrote:
On Fri, 22 Apr 2022 at 11:52, wrote:
From: Lv Ruyi
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
Reviewed-by: Dmitry Baryshkov
---
drivers/
On 22/04/2022 21:39, Stephen Boyd wrote:
Quoting cgel@gmail.com (2022-04-22 01:49:51)
From: Lv Ruyi
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
Chipsets")
Reporte
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
oob_hotplug_event() callback, by amending the dp_hpd module with the
missing logic.
Overall the solution
In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.
Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
state.
Also push the test
On 22/04/2022 22:45, Abhinav Kumar wrote:
Using intf_idx even for writeback interfaces is confusing
because intf_idx is of type enum dpu_intf but the index used
for writeback is of type enum dpu_wb.
In addition, this makes it easier to separately check the
availability of the two as its possible
On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck wrote:
> On 4/22/22 12:16, Arnd Bergmann wrote:
> > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck wrote:
> >
> > Which machine did you hit this on? Is this on hardware or in qemu?
> >
> qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail.
On Tue, Apr 5, 2022 at 10:57 AM Chia-I Wu wrote:
>
> On Tue, Apr 5, 2022 at 10:38 AM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > It would have been cleaner to have a flag to *request* the fence event.
> > But that ship has sailed. So add a flag so that userspace which doesn't
> > care abou
On Fri, Apr 22, 2022 at 08:22:32AM +0200, Christoph Hellwig wrote:
> Nit: why do some of these patches that don't touch the mdev code
> mdev in the subject?
I consider these APIs to be 'mdev apis' because only mdev drivers
should call them.
Jason
On 4/22/22 12:16, Arnd Bergmann wrote:
On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck wrote:
On Tue, Apr 19, 2022 at 06:37:22PM +0200, Arnd Bergmann wrote:
From: Arnd Bergmann
This revisits a series I sent a few years ago:
https://lore.kernel.org/lkml/20191018154052.1276506-1-a...@arndb.de/
On Fri, Apr 22, 2022 at 02:11:27AM +, Tian, Kevin wrote:
> > mutex_lock(&device->dev_set->lock);
> > - if (!--device->open_count && device->ops->close_device)
> > + vfio_assert_device_open(device);
> > + if (device->open_count == 1 && device->ops->close_device)
> > device
On Wed, 20 Apr 2022 08:13:47 +0300 Kalle Valo wrote:
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for feat
From: Daniele Ceraolo Spurio
Cc: Vinay Belgaumkar
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_pci.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gp
We're now ready to start exposing compute engines to userspace.
While we're at it, let's extend the kerneldoc description for the other
engine types as well.
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Vinay Belgaumkar
Cc: Jordan Justen
Cc: Szymon Morek
UMD (mesa): https://gitlab.freed
Now that the necessary GuC-based hardware workarounds have landed, we're
finally ready to actually enable compute engines for use by userspace.
All of the "under-the-hood" heavy lifting already landed a while back in
other series so all that remains now is to add I915_ENGINE_CLASS_COMPUTE
to the ua
From: Chunguang Xu
Fix typos in comment.
Signed-off-by: Chunguang Xu
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 29890d7..b986946 100644
--- a/dri
Change the DRM traces to include both the intf_mode
and wb_idx similar to the DRM prints in the previous change.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 -
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 26 ++
Add wb_idx to existing DRM prints in dpu_encoder and also
print the intf_mode so that its clear that for any INTF_CMD/VID
there will be a valid intf_idx and any INTF_WB_* there will be a
valid wb_idx.
Update the debugfs to add the same information. Here is a sample
output with this change:
root:/
Using intf_idx even for writeback interfaces is confusing
because intf_idx is of type enum dpu_intf but the index used
for writeback is of type enum dpu_wb.
In addition, this makes it easier to separately check the
availability of the two as its possible that there are boards
which don't have any
As promised here [1], this is a follow up change to separate out
wb_idx and intf_idx for better clarity in dpu_encoder.
This also helps to easily handle boards which do not have a physical
display but can still be validated using writeback interface.
In addition, this also takes care of adding wb
Am 22.04.22 um 18:13 schrieb Zack Rusin:
From: Zack Rusin
The buffer objects created by cotables were missing fence reservations.
They are created from vmw_validation_res_validate which makes them miss
the ttm_eu_reserve_buffers which is called from vmw_validation_bo_reserve.
Cotables are the
Am 22.04.22 um 18:13 schrieb Zack Rusin:
On Fri, 2022-04-22 at 11:21 +0200, Christian König wrote:
Am 22.04.22 um 11:20 schrieb Christian König:
When resources are allocated dynamically during an IOCTL we need to
make sure
that a fence slot is reserved so that the resulting fence can be
added i
On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck wrote:
>
> On Tue, Apr 19, 2022 at 06:37:22PM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > This revisits a series I sent a few years ago:
> >
> > https://lore.kernel.org/lkml/20191018154052.1276506-1-a...@arndb.de/
> >
> > All the other
On Fri, 22 Apr 2022 at 21:18, Abhinav Kumar wrote:
>
> Hi Dmitry
>
> On 4/22/2022 3:37 AM, Dmitry Baryshkov wrote:
> > On Fri, 22 Apr 2022 at 04:59, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 4/21/2022 5:22 PM, Dmitry Baryshkov wrote:
> >>> On Fri, 22 Apr 2022 at 02:07, Abhinav Kumar
> >>
Sparse reports these issues
coregv100.c:27:1: warning: symbol 'gv100_disp_core_mthd_base' was not declared.
Should it be static?
coregv100.c:43:1: warning: symbol 'gv100_disp_core_mthd_sor' was not declared.
Should it be static?
These variables are only used in coregv100.c. Single file use
vari
On Sun, Apr 17, 2022 at 04:07:57AM +0200, Marek Vasut wrote:
> Wrap FIFO reset and comments into mxsfb_reset_block(), this is a clean up.
> No functional change.
>
> Reviewed-by: Lucas Stach
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
> Cc: Laurent Pinchart
> Cc: Lucas Stach
> Cc: Peng
Quoting cgel@gmail.com (2022-04-22 01:49:51)
> From: Lv Ruyi
>
> The irq_of_parse_and_map() function returns 0 on failure, and does not
> return an negative value.
>
> Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
> Chipsets")
> Reported-by: Zeal Robot
> Signed-off
On Fri, Apr 22, 2022 at 03:36:14PM -0300, Fabio Estevam wrote:
> From: Heiko Schocher
>
> Add Startek KD070WVFPA043-C069A 7" TFT LCD panel support.
>
> Signed-off-by: Heiko Schocher
> Signed-off-by: Fabio Estevam
Acked-by: Sam Ravnborg
On Sun, Apr 17, 2022 at 04:08:00AM +0200, Marek Vasut wrote:
> Reorder mxsfb_crtc_mode_set_nofb() such that all functions which perform
> register IO are called from one single location in this function. This is
> a clean up. No functional change.
>
> Reviewed-by: Lucas Stach
> Signed-off-by: Mar
On Sun, Apr 17, 2022 at 04:07:59AM +0200, Marek Vasut wrote:
> Pull mode registers programming from mxsfb_enable_controller() into
> dedicated function mxsfb_set_mode(). This is a clean up. No functional
> change.
>
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
> Cc: Laurent Pinchart
> Cc:
From: Heiko Schocher
Add Startek KD070WVFPA043-C069A 7" TFT LCD panel support.
Signed-off-by: Heiko Schocher
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Put the panel entry in the correct order (Sam).
drivers/gpu/drm/panel/panel-simple.c | 33
1 file cha
From: Fabio Estevam
Add Startek KD070WVFPA043-C069A 7" TFT LCD panel compatible string.
Signed-off-by: Fabio Estevam
Acked-by: Sam Ravnborg
---
Changes since v1:
- None. Only added Sam's ack.
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions
On Sun, Apr 17, 2022 at 04:07:58AM +0200, Marek Vasut wrote:
> Replace mxsfb_get_fb_paddr() with drm_fb_cma_get_gem_addr() to correctly
> handle
> FB offset.
>
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
> Cc: Laurent Pinchart
> Cc: Lucas Stach
> Cc: Peng Fan
> Cc: Robby Cai
> Cc: Sa
Hi Marek,
On Mon, Apr 18, 2022 at 04:51:05PM +0200, Marek Vasut wrote:
> The i.MX8MP contains two syscon registers which are responsible
> for configuring the on-SoC DPI-to-LVDS serializer. Implement a
> simple bridge driver for this serializer.
>
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinch
On Tue, Apr 19, 2022 at 09:56:24PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Add Startek KD070WVFPA043-C069A 7" TFT LCD panel compatible string.
>
> Signed-off-by: Fabio Estevam
Acked-by: Sam Ravnborg
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
>
On Fri, Apr 22, 2022 at 12:22:42PM +0200, Marek Vasut wrote:
> Add DataImage FG040346DSSWBG04 4.3" 480x272 TFT LCD 24bit DPI panel
> support.
>
> Acked-by: Thomas Zimmermann
> Signed-off-by: Marek Vasut
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> To: dri-devel@lists.freedesktop.org
Acked-by:
On Fri, Apr 22, 2022 at 12:22:41PM +0200, Marek Vasut wrote:
> Add DataImage FG040346DSSWBG04 4.3" 480x272 TFT LCD 24bit DPI panel
> compatible string.
>
> Acked-by: Thomas Zimmermann
> Signed-off-by: Marek Vasut
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc: devicet...@vg
Hi Marek, I read the patch once more.
On Mon, Apr 18, 2022 at 04:51:04PM +0200, Marek Vasut wrote:
> The i.MX8MP contains two syscon registers which are responsible
Here it says i.MX8MP
> for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding
> which represents this serializer as a br
On Mon, Apr 18, 2022 at 04:51:04PM +0200, Marek Vasut wrote:
> The i.MX8MP contains two syscon registers which are responsible
> for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding
> which represents this serializer as a bridge.
>
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
Applied. Thanks!
Alex
On Fri, Apr 22, 2022 at 2:04 AM Haowen Bai wrote:
>
> After alloc fail, we do not need to kfree.
>
> Signed-off-by: Haowen Bai
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
On Tue, Apr 19, 2022 at 09:56:25PM -0300, Fabio Estevam wrote:
> From: Heiko Schocher
>
> Add Startek KD070WVFPA043-C069A 7" TFT LCD panel support.
>
> Signed-off-by: Heiko Schocher
> Signed-off-by: Fabio Estevam
> ---
> drivers/gpu/drm/panel/panel-simple.c | 33
Hi Dmitry
On 4/22/2022 3:37 AM, Dmitry Baryshkov wrote:
On Fri, 22 Apr 2022 at 04:59, Abhinav Kumar wrote:
On 4/21/2022 5:22 PM, Dmitry Baryshkov wrote:
On Fri, 22 Apr 2022 at 02:07, Abhinav Kumar wrote:
Hi Dmitry
Thanks for the review.
One question below.
On 4/21/2022 3:40 PM, Dmitr
On Fri, Apr 22, 2022 at 01:50:00AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, April 22, 2022 12:29 AM
> >
> > Every caller has a readily available vfio_device pointer, use that instead
> > of passing in a generic struct device. The struct vfio_device already
> > contain
Hi Doug
On 4/22/2022 9:10 AM, Doug Anderson wrote:
Hi,
On Fri, Apr 22, 2022 at 9:05 AM Abhinav Kumar wrote:
Hi Doug
For the lockdep error, the splat looks similar to what kuogee fixed
recently.
Can you please check if below patch is present in your tree?
https://patchwork.freedesktop.org/
Hi,
On Tue, Apr 19, 2022 at 09:08:48AM +0800, Liu Ying wrote:
> The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
> works with a Mixel MIPI DPHY + LVDS PHY combo to support either
> a MIPI DSI display or a LVDS display. So, this patch calls
> phy_set_mode() from nwl_dsi_mode_set()
On Fri, Apr 22, 2022 at 01:39:09AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, April 22, 2022 12:29 AM
> >
> > 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
Reviewed-by: Lyude Paul
Will push upstream in a moment
On Thu, 2022-04-21 at 09:30 -0400, Tom Rix wrote:
> Smatch reports this issue
> gv100.c:46:1: warning: symbol 'gv100_gsp' was not declared. Should it be
> static?
>
> gv100_gsp is only used in gv100.c so change its
> storage-class specifier
04097] [feeb000e] *pgd=
[1.404400] Internal error: Oops: 805 [#1] PREEMPT ARM
[1.404648] Modules linked in:
[1.404890] CPU: 0 PID: 22 Comm: pccardd Not tainted
5.18.0-rc3-next-20220422 #1
[1.405159] Hardware name: SHARP Borzoi
[1.405319] PC is at pcmcia_init_one+0xf8/0x2
On 2022-04-22 10:28, Melissa Wen wrote:
On 04/21, Harry Wentland wrote:
On 2022-04-21 15:20, Melissa Wen wrote:
On 04/21, Harry Wentland wrote:
On 2022-04-21 10:37, Melissa Wen wrote:
Hi all,
I'm examining how DRM color management properties (degamma, ctm, gamma)
are applied to AMD di
Hi Chenyang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v5.18-rc3 next-20220422]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
Hi Chenyang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v5.18-rc3 next-20220422]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
From: Zack Rusin
The buffer objects created by cotables were missing fence reservations.
They are created from vmw_validation_res_validate which makes them miss
the ttm_eu_reserve_buffers which is called from vmw_validation_bo_reserve.
Cotables are the only resources which create a buffer object
On Fri, 2022-04-22 at 11:21 +0200, Christian König wrote:
> Am 22.04.22 um 11:20 schrieb Christian König:
> > When resources are allocated dynamically during an IOCTL we need to
> > make sure
> > that a fence slot is reserved so that the resulting fence can be
> > added in the
> > end.
>
> I shoul
Hi,
On Fri, Apr 22, 2022 at 9:05 AM Abhinav Kumar wrote:
>
> Hi Doug
>
> For the lockdep error, the splat looks similar to what kuogee fixed
> recently.
>
> Can you please check if below patch is present in your tree?
>
> https://patchwork.freedesktop.org/patch/481396/
Indeed I did have that in
Hi Doug
For the lockdep error, the splat looks similar to what kuogee fixed
recently.
Can you please check if below patch is present in your tree?
https://patchwork.freedesktop.org/patch/481396/
Thanks
Abhinav
On 4/22/2022 8:55 AM, Doug Anderson wrote:
Hi,
On Fri, Apr 22, 2022 at 2:11 AM
Hi,
On Fri, Apr 22, 2022 at 2:11 AM Sankeerth Billakanti
wrote:
>
> The panel-edp enables the eDP panel power during probe, get_modes
> and pre-enable. The eDP connect and disconnect interrupts for the eDP/DP
> controller are directly dependent on panel power. As eDP display can be
> assumed as a
On Wed, Apr 20, 2022 at 10:52:58AM +0200, Javier Martinez Canillas wrote:
> Hello,
>
> The patches in this series are mostly changes suggested by Daniel Vetter
> to fix some race conditions that exists between the fbdev core (fbmem)
> and sysfb with regard to device registration and removal.
>
>
Hi,
On Mon, Mar 21, 2022 at 8:27 PM Vinod Polimera
wrote:
>
> Set mdp clock to max clock rate during probe/bind sequence from the
> opp table so that rails are not at undetermined state. Since we do not
> know what will be the rate set in boot loader, it would be ideal to
> vote at max frequency.
1 - 100 of 188 matches
Mail list logo