Acked-by: Iago Toral Quiroga
On Fri, 2022-04-29 at 18:33 -0100, Melissa Wen wrote:
> I've been contributing to v3d through improvements, reviews, testing,
> debugging, etc. So, I'm adding myself as a co-maintainer of the V3D
> driver.
>
> Signed-off-by: Melissa Wen
> ---
> MAINTAINERS | 1 +
>
Adding support for writeback transcoder to start capturing frames using
interrupt mechanism
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_acpi.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 89 +-
Adding WD Types, WD transcoder to enum list and WD Transcoder offsets
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display.h | 6 ++
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/i915_reg.h| 2 ++
3 files
Changes to create a i915 private pipeline to enable the WD transcoder
without relying on the current drm_writeback framework.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/display/intel_display_types.h| 4 +
A patch series was floated in the drm mailing list which aimed to change
the drm_connector and drm_encoder fields to pointer in the
drm_connector_writeback structure, this received a huge pushback from
the community but since i915 expects each connector present in the
drm_device list to be a
Add missing break statement for dpu_hw_ctl_update_pending_flush_wb().
Otherwise this leads to below build warning.
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c:273:2:
warning: unannotated fall-through between switch labels
default:
^
On Fri, 2022-04-29 at 19:34 -0400, Lyude Paul wrote:
> Cool! Tested this on three different laptops, and it seems to work
> great on
> all of them. so, this series is:
>
> Tested-by: Lyude Paul
Thank you all for review/testing support. I will come back with updated
patch set later.
>
> Would
g:no-previous-prototype-for-function-amdgpu_discovery_get_mall_info
| `--
drivers-gpu-drm-amd-amdgpu-soc21.c:warning:no-previous-prototype-for-function-soc21_grbm_select
|-- riscv-randconfig-c006-20220501
| `--
mm-page_io.c:warning:Value-stored-to-page-during-its-initialization-is-ne
Looks like our new CI has given all the answers we need :) which is a
great win for the CI in my opinion.
Take a look at this report :
https://gitlab.freedesktop.org/drm/msm/-/jobs/22015361
This issue seems to be because this change
Adding one more item:
On 5/1/2022 4:41 PM, Dmitry Baryshkov wrote:
Hi Rob,
This is a pull request over the patches accumulated, reviewed and tested for
the 5.19 merge window. This pull request contains following changes:
- DPU: DSC (Display Stream Compression) support
- DPU: Writeback
On 5/1/2022 1:06 PM, Marijn Suijten wrote:
On 2022-04-30 12:25:57, Abhinav Kumar wrote:
On 4/30/2022 11:58 AM, Marijn Suijten wrote:
On 2022-04-30 20:55:33, Dmitry Baryshkov wrote:
The downstream uses read-modify-write for updating command mode
compression registers. Let's follow this
On 4/29/22 23:23, Marek Vasut wrote:
The LCDIF controller as present in i.MX28/i.MX6SX/i.MX8M Mini/Nano has
CRC_STAT register, which contains CRC32 of the frame as it was clocked
out of the DPI interface of the LCDIF. This is most likely meant as a
functional safety feature.
Unfortunately,
Hi Rob,
This is a pull request over the patches accumulated, reviewed and tested for
the 5.19 merge window. This pull request contains following changes:
- DPU: DSC (Display Stream Compression) support
- DPU: inline rotation support on SC7280
- DPU: update DP timings to follow vendor
Hi, Matthias:
Matthias Brugger 於 2022年4月22日 週五 下午8:42寫道：
>
>
>
> On 19/04/2022 11:41, jason-jh.lin wrote:
> > After mmsys and drm change DITHER enum to DDP_COMPONENT_DITHER0,
> > mmsys header can remove the useless DDP_COMPONENT_DITHER enum.
> >
> > Signed-off-by: jason-jh.lin
> > Reviewed-by:
On 01/05/2022 23:41, Marijn Suijten wrote:
On 2022-04-30 22:28:42, Dmitry Baryshkov wrote:
On 30/04/2022 21:58, Marijn Suijten wrote:
On 2022-04-30 20:55:33, Dmitry Baryshkov wrote:
The downstream uses read-modify-write for updating command mode
compression registers. Let's follow this
On Tue, Apr 19, 2022 at 6:42 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The mach/mfp.h header is only used by this one driver
> for hardcoded gpio numbers. Change that to use a lookup
> table instead.
>
> Cc: Dmitry Torokhov
> Cc: linux-in...@vger.kernel.org
> Acked-by: Robert Jarzmik
On Tue, Apr 19, 2022 at 6:42 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This driver hardcodes gpio numbers without a header file.
> Use lookup tables instead.
>
> Cc: Marek Vasut
> Acked-by: Dmitry Torokhov
> Acked-by: Robert Jarzmik
> Reviewed-by: Linus Walleij
> Cc:
On Tue, Apr 19, 2022 at 6:41 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The magician audio driver creates a codec device and gets
> data from a board specific header file, both of which is
> a bit suspicious. Move these into the board file itself,
> using a gpio lookup table.
>
>
On Tue, Apr 19, 2022 at 6:41 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The audio device is allocated by the audio driver, and it uses a gpio
> number from the mach/z2.h header file.
>
> Change it to use a gpio lookup table for the device allocated by the
> driver to keep the header file
On Tue, Apr 19, 2022 at 6:41 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The three eseries machines have very similar drivers for audio, all
> using the mach/eseries-gpio.h header for finding the gpio numbers.
>
> Change these to use gpio descriptors to avoid the header file
> dependency.
On Tue, Apr 19, 2022 at 6:41 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The audio driver should not use a hardwired gpio number
> from the header. Change it to use a lookup table.
>
> Acked-by: Mark Brown
> Cc: alsa-de...@alsa-project.org
> Signed-off-by: Arnd Bergmann
Looks good to
On Tue, Apr 19, 2022 at 6:41 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The audio driver should not use a hardwired gpio number
> from the header. Change it to use a lookup table.
>
> Cc: Philipp Zabel
> Cc: Paul Parsons
> Acked-by: Mark Brown
> Acked-by: Robert Jarzmik
> Cc:
On Tue, Apr 19, 2022 at 6:41 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The audio driver should not use a hardwired gpio number
> from the header. Change it to use a lookup table.
>
> Acked-by: Mark Brown
> Cc: alsa-de...@alsa-project.org
> Acked-by: Robert Jarzmik
> Signed-off-by:
On Tue, Apr 19, 2022 at 6:40 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The audio driver should not use a hardwired gpio number
> from the header. Change it to use a lookup table.
>
> Acked-by: Mark Brown
> Acked-by: Robert Jarzmik
> Cc: alsa-de...@alsa-project.org
> Signed-off-by:
On 2022-04-30 22:28:42, Dmitry Baryshkov wrote:
> On 30/04/2022 21:58, Marijn Suijten wrote:
> > On 2022-04-30 20:55:33, Dmitry Baryshkov wrote:
> >> The downstream uses read-modify-write for updating command mode
> >> compression registers. Let's follow this approach. This also fixes the
> >>
On 2022-04-30 12:25:57, Abhinav Kumar wrote:
>
>
> On 4/30/2022 11:58 AM, Marijn Suijten wrote:
> > On 2022-04-30 20:55:33, Dmitry Baryshkov wrote:
> >> The downstream uses read-modify-write for updating command mode
> >> compression registers. Let's follow this approach. This also fixes the
>
Remove dividers that are not recommended for DSI DPHY mode when setting
up the clock tree for the DSI pixel clock.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git
Complete the move of DSC data pointer from struct drm_panel to struct
mipi_dsi_device.
Signed-off-by: Dmitry Baryshkov
---
include/drm/drm_panel.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index d279ee455f01..1ba2d424a53f 100644
Now that struct mipi_dsi_device provides DSC data, fetch it from the
mentioned struct rather than from the struct drm_panel itself. This
would allow supporting MIPI DSI bridges handling DSC on their input
side.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 25
The commit 0f40ba48de3b ("drm/msm/dsi: Pass DSC params to drm_panel")
added a pointer to the DSC data to the struct drm_panel. However DSC
support is not limited to the DSI panels. MIPI DSI bridges can also
consume DSC command streams. Thus add struct drm_dsc_config pointer to
the struct
To properly support DSC the sink driver (panel) has to pass DSC pps data
to the source (DSI host). The commit 0f40ba48de3b ("drm/msm/dsi: Pass
DSC params to drm_panel") added a pointer to the DSC data to the struct
drm_panel. However this is not the ideal solution.
First, this leaves
From: Mauro Carvalho Chehab
> Sent: 30 April 2022 14:38
>
> Em Sat, 30 Apr 2022 14:04:59 +0200
> Greg KH escreveu:
>
> > On Sat, Apr 30, 2022 at 11:30:58AM +0100, Mauro Carvalho Chehab wrote:
>
> > Did you run checkpatch on this? Please do :)
> >
> > > +
> > > + if (mod == this)
> > > +
Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
This allows us to drop final bits of struct mdp5_cfg_platform which
remained from the pre-DT days.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 16
Follow the lead of MDP5 driver and check both DPU and MDSS devices for
the IOMMU specifiers.
Historically DPU devices had IOMMU specified in the MDSS device tree
node, but as some of MDP5 devices are being converted to the supported
by the DPU driver, the driver should adapt and check both
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
On Qualcomm platforms the IOMMU can be specified either for the MDP/DPU
device or for its
This series started from the applied and then reverted [2] patch by
Robin Murphy [1]. After the MDSS rework [3] has landed it is now
possible to reapply the extended version of the original patch. While we
are at it, also rework the IOMMU init code for DPU and MDP5 drivers.
For MDP5 this moves
Dear Richard,
Am 29.04.22 um 18:06 schrieb Richard Gong:
Active State Power Management (ASPM) feature is enabled since kernel 5.14.
There are some AMD Volcanic Islands (VI) GFX cards, such as the WX3200 and
RX640, that do not work with ASPM-enabled Intel Alder Lake based systems.
Using these
Dear Richard,
Sorry for the late reply.
Am 26.04.22 um 15:53 schrieb Gong, Richard:
On 4/21/2022 12:35 AM, Paul Menzel wrote:
Am 21.04.22 um 03:12 schrieb Gong, Richard:
On 4/20/2022 3:29 PM, Paul Menzel wrote:
Am 19.04.22 um 23:46 schrieb Gong, Richard:
On 4/14/2022 2:52 AM, Paul
38 matches
Mail list logo
