Hi,
Here's the first drm-misc-next PR for 6.5
Please note that I'll be off for about a month starting next week, and
Thomas has kindly agreed to fill in.
Thanks!
Maxime
drm-misc-next-2023-05-11:
drm-misc-next for 6.5:
UAPI Changes:
Cross-subsystem Changes:
- arch: Consolidate
Core Changes:
On Sun, 30 Apr 2023 19:23:46 +0800, XuDong Liu wrote:
> Smatch reports:
> drivers/gpu/drm/sun4i/sun4i_tcon.c:805 sun4i_tcon_init_clocks() warn:
> 'tcon->clk' from clk_prepare_enable() not released on lines: 792,801.
>
> In the function sun4i_tcon_init_clocks(), tcon->clk and tcon->sclk0 are
> not
Hi
Am 10.05.23 um 20:20 schrieb Sui Jingfeng:
Hi, Thomas
I love your patch, yet something to improve:
On 2023/5/10 19:05, Thomas Zimmermann wrote:
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
Reviewed-by: Sam Ravnborg
Reviewed-by:
A friendly ping to merge this PR. The patches appear to be missing from
drm-fixes.
Am 26.04.23 um 07:59 schrieb Maarten Lankhorst:
Hi Dave, Daniel,
drm-misc-fixes pull request for rc1. drm-misc-next-fixes coming up.. next
~Maarten
drm-misc-fixes-2023-04-26:
drm-misc-fixes for v6.4-rc1:
- Fix
Hi
Am 10.05.23 um 19:25 schrieb Pierre Asselin:
Thomas Zimmerman writes:
I found this casting mess even more unreadable. I went back to v2, fixed
the style issues and committed the patch as v4 (still under your name).
https://cgit.freedesktop.org/drm/drm-tip/commit?id=1b617bc93178912fa36f87a
Hi,
On Sun, 07 May 2023 20:26:38 +0300, Dmitry Baryshkov wrote:
> Using current settings causes panel flickering on APQ8074 dragonboard.
> Adjust panel settings to follow the vendor-provided mode. This also
> enables MIPI_DSI_MODE_VIDEO_SYNC_PULSE, which is also specified by the
> vendor dtsi for
Hi,
On Mon, 08 May 2023 16:38:24 +0800, Liu Ying wrote:
> This patch series aims to add BOE EV121WXM-N10-1850 panel support
> in the DRM simple panel driver.
>
> Patch 1/2 adds dt-bindings support for the panel.
> Patch 2/2 adds the panel support in the DRM simple panel driver.
>
> v1->v2:
> * A
Hi
On 2023/5/11 15:55, Thomas Zimmermann wrote:
Hi
Am 10.05.23 um 20:20 schrieb Sui Jingfeng:
Hi, Thomas
I love your patch, yet something to improve:
On 2023/5/10 19:05, Thomas Zimmermann wrote:
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd
Hi Dinh,
On Tue, May 09, 2023 at 12:37:39PM -0500, Dinh Nguyen wrote:
> Hi Maxime,
>
> On 5/4/23 12:04, Maxime Ripard wrote:
> > Hi Dinh,
> >
> > On Thu, Apr 27, 2023 at 02:09:48PM -0500, Dinh Nguyen wrote:
> > > Hi Maxime,
> > >
> > > On 4/25/23 09:48, Maxime Ripard wrote:
> > > > Hi Dinh,
> >
On Wed, May 10, 2023 at 9:59 AM Jonas Ådahl wrote:
>
> On Tue, May 09, 2023 at 08:22:30PM +, Simon Ser wrote:
> > On Tuesday, May 9th, 2023 at 21:53, Dave Airlie wrote:
> >
> > > There are also other vendor side effects to having this in userspace.
> > >
> > > Will the library have a loader?
Hey,
On 2023-05-10 20:46, Tejun Heo wrote:
> Hello,
>
> On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote:
>> The misc controller is not granular enough. A single computer may have any
>> number of
>> graphics cards, some of them with multiple regions of vram inside a single
>> c
Hi Dave, Daniel,
Next pull request, with the previous one included too:
drm-misc-fixes-2023-05-11:
drm-misc-fixes for v6.4-rc2:
- More DSC macro fixes.
- Small mipi-dsi fix.
- Scheduler timeout handling fix.
---
drm-misc-fixes for v6.4-rc1:
- Fix DSC macros.
- Fix VESA format for simplefb.
- Pr
On 10/05/2023 19:46, Tejun Heo wrote:
Hello,
On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote:
The misc controller is not granular enough. A single computer may have any
number of
graphics cards, some of them with multiple regions of vram inside a single card.
Extending th
Add Tile4 type ccs modifiers with aux buffer needed for MTL
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Signed-off-by: Juha-Pekka Heikkila
---
include/uapi/drm/drm_fourcc.h | 43 +++
1 file changed, 43 insertions(+)
diff --git a/include/uapi/drm/drm_four
Hi
Am 10.05.23 um 17:54 schrieb Arnd Bergmann:
On Wed, May 10, 2023, at 16:27, Thomas Zimmermann wrote:
Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
On Wed, May 10, 2023, at 16:03, kernel test robot wrote:
I think that's a preexisting bug and I have no idea what the
correct solution is. Loo
On 09/05/2023 18:12, Yang, Fei wrote:
> On 09/05/2023 00:48, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> Currently the KMD is using enum i915_cache_level to set caching
policy for
>> buffer objects. This is flaky because the PAT index which really
controls
>> the caching behavior
(ping)
Hi,
I thought these patches would go through the fbdev tree, but I could not
find them v6.4-rc1. Please review the remaining ones, so that I can
merge them via drm-misc.
Best regards
Thomas
Am 31.03.23 um 11:22 schrieb Thomas Zimmermann:
The trailing whitespaces are annoying. So rem
Hi Dave & Daniel,
Here goes drm-intel-fixes for v6.4-rc2.
Important fix to taint kernel when force_probe is used, two display
fixes (null deref/div-by-zero) and a GuC error capture register list
correction.
Regards, Joonas
PS. Again had to remove one commit with incorrect Fixes: tag so check CI
Hi
Am 10.05.23 um 15:10 schrieb Jocelyn Falempe:
When mgag200 switched from simple KMS to regular atomic helpers,
the initialization of the gamma settings was lost.
This leads to a black screen, if the bios/uefi doesn't use the same
pixel color depth.
v2: rebase on top of drm-misc-fixes, and ad
On Wed, May 10, 2023 at 03:54:41PM -0700, Jessica Zhang wrote:
> Add helpers to calculate det_thresh_flatness and initial_scale_value as
> these calculations are defined within the DSC spec.
>
> Signed-off-by: Jessica Zhang
> Signed-off-by: Dmitry Baryshkov
> Reviewed-by: Marijn Suijten
> Signe
Hi Arnd,
CC Artur, who's working on HP Jornada 680.
On Wed, May 10, 2023 at 5:55 PM Arnd Bergmann wrote:
> On Wed, May 10, 2023, at 16:27, Thomas Zimmermann wrote:
> > Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
> >> On Wed, May 10, 2023, at 16:03, kernel test robot wrote:
>
> >> I think that's
On Thu, May 11, 2023, at 14:35, Geert Uytterhoeven wrote:
> CC Artur, who's working on HP Jornada 680.
>
> On Wed, May 10, 2023 at 5:55 PM Arnd Bergmann wrote:
>> On Wed, May 10, 2023, at 16:27, Thomas Zimmermann wrote:
>> > Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
>> >> On Wed, May 10, 2023, a
Hi Thomas,
On 5/11/23 14:08, Thomas Zimmermann wrote:
I thought these patches would go through the fbdev tree, but I could
not find them v6.4-rc1. Please review the remaining ones, so that I
can merge them via drm-misc.
Sorry, I thought you had planned to take them through drm-misc anyway,
so
Hi
Am 11.05.23 um 14:51 schrieb Helge Deller:
Hi Thomas,
On 5/11/23 14:08, Thomas Zimmermann wrote:
I thought these patches would go through the fbdev tree, but I could
not find them v6.4-rc1. Please review the remaining ones, so that I
can merge them via drm-misc.
Sorry, I thought you had p
On 5/11/23 09:55, Thomas Zimmermann wrote:
Hi
Am 10.05.23 um 20:20 schrieb Sui Jingfeng:
Hi, Thomas
I love your patch, yet something to improve:
On 2023/5/10 19:05, Thomas Zimmermann wrote:
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergma
On 5/11/23 14:53, Thomas Zimmermann wrote:
Hi
Am 11.05.23 um 14:51 schrieb Helge Deller:
Hi Thomas,
On 5/11/23 14:08, Thomas Zimmermann wrote:
I thought these patches would go through the fbdev tree, but I could
not find them v6.4-rc1. Please review the remaining ones, so that I
can merge the
Hi Helge,
On Thu, May 11, 2023 at 3:05 PM Helge Deller wrote:
> On 5/11/23 09:55, Thomas Zimmermann wrote:
> > But the work I do within fbdev is mostly for improving DRM.
>
> Sure.
>
> > For the
> > other issues in this file, I don't think that matroxfb should even be
> > around any longer. Fbdev
Hi
Am 10.05.23 um 17:54 schrieb Arnd Bergmann:
On Wed, May 10, 2023, at 16:27, Thomas Zimmermann wrote:
Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
On Wed, May 10, 2023, at 16:03, kernel test robot wrote:
I think that's a preexisting bug and I have no idea what the
correct solution is. Loo
On 11/05/2023 14:26, Thomas Zimmermann wrote:
Hi
Am 10.05.23 um 15:10 schrieb Jocelyn Falempe:
When mgag200 switched from simple KMS to regular atomic helpers,
the initialization of the gamma settings was lost.
This leads to a black screen, if the bios/uefi doesn't use the same
pixel color dept
Previous batches of SPDX conversion missed bond_main.c and bonding_priv.h
because these files doesn't mention intended GPL version. Add SPDX identifier
to these files, assuming GPL 1.0+.
Cc: Thomas Davis
Cc: Christophe JAILLET
Cc: Stephen Hemminger
Signed-off-by: Bagas Sanjaya
---
drivers/net
Replace unversioned GPL notice boilerplate on dsp_* with SPDX identifier
for GPL 1.0+. These files missed previous SPDX conversion batches
due to not specifying GPL version.
Cc: Stephen Hemminger
Signed-off-by: Bagas Sanjaya
---
drivers/isdn/mISDN/dsp_audio.c| 4 +---
drivers/isdn/mISDN/dsp
Replace GPL boilerplate notice on remaining files with appropriate SPDX
tag. For files mentioning COPYING, use GPL 2.0; otherwise GPL 1.0+.
Cc: David A. Hinds
Cc: Donald Becker
Cc: Peter De Schrijver
Cc: Greg Ungerer
Cc: Simon Horman
Signed-off-by: Bagas Sanjaya
---
drivers/net/ethernet/839
I trigger this patch series because of Didi's GPL full name fixes
attempt [1], for which all of them had been NAKed. In many cases, the
appropriate correction is to use SPDX license identifier instead.
Often, when replacing license notice boilerplates with their equivalent
SPDX identifier, the not
Remove the license boilerplate as there is already SPDX license
identifier which fulfills the same intention as the boilerplate.
Cc: Dan Carpenter
Signed-off-by: Bagas Sanjaya
---
drivers/staging/wlan-ng/hfa384x.h | 21 -
drivers/staging/wlan-ng/hfa384x_usb.c |
Add SPDX identifier on remaining files untouched during previous
rounds of SPDX conversion while replacing boilerplate notice if any.
Cc: Maxime Bizon
Cc: David A. Hinds
Cc: John G. Dorsey
Signed-off-by: Bagas Sanjaya
---
drivers/pcmcia/bcm63xx_pcmcia.c | 5 +
drivers/pcmcia/cirrus.h
Many watchdog drivers's source files has already SPDX license
identifier, while some remaining doesn't.
Convert notices on remaining files to SPDX identifier.
Cc: Ray Lehtiniemi
Cc: Alessandro Zummo
Cc: Andrey Panin
Cc: Oleg Drokin
Cc: Marc Zyngier
Cc: Jonas Jensen
Cc: Sylver Bruneau
Cc: A
Replace unversioned GPL license notice with appropriate SPDX
identifier, which is GPL 1.0+.
Signed-off-by: Bagas Sanjaya
---
include/linux/synclink.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/synclink.h b/include/linux/synclink.h
index f1405b1c71ba15..2c
Replace unversioned GPL boilerplate notice on remaining i825xx files
with appropriate SPDX identifier. For files that contains "extension to
Linux kernel", use GPL 2.0, otherwise GPL 1.0+.
Cc: Donald Becker
Cc: Michael Hipp
Cc: Simon Horman
Signed-off-by: Bagas Sanjaya
---
drivers/net/etherne
There is already SPDX tag which does the job, so remove the redundant
notice.
Cc: Christophe JAILLET
Signed-off-by: Bagas Sanjaya
---
drivers/char/agp/amd64-agp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
index ce8651436609fc.
Except Kconfig and Makefile, all source files for UDF filesystem doesn't
bear SPDX license identifier. Add appropriate license identifier while
replacing boilerplates.
Cc: Thomas Gleixner
Signed-off-by: Bagas Sanjaya
---
fs/udf/balloc.c| 6 +-
fs/udf/dir.c | 6 +-
fs/udf/dir
On Thu, May 11, 2023, at 15:22, Artur Rojek wrote:
> On 2023-05-11 14:35, Geert Uytterhoeven wrote:
>>
>> CC Artur, who's working on HP Jornada 680.
> Thanks for CC'ing me - I faced this exact issue while working on my
> (still not upstreamed) hd6446x PCMCIA controller driver. The PCMCIA
> subsyst
Hi Dave, Daniel,
Fixes for 6.4.
The following changes since commit ac9a78681b921877518763ba0e89202254349d1b:
Linux 6.4-rc1 (2023-05-07 13:34:35 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.4-2023-05-11
for you to fetch
On Thu, May 11, 2023 at 08:34:00PM +0700, Bagas Sanjaya wrote:
> Replace GPL boilerplate notice on remaining files with appropriate SPDX
> tag. For files mentioning COPYING, use GPL 2.0; otherwise GPL 1.0+.
Reviewed-by: Simon Horman
On Thu, May 11, 2023 at 08:33:58PM +0700, Bagas Sanjaya wrote:
> Replace unversioned GPL notice boilerplate on dsp_* with SPDX identifier
> for GPL 1.0+. These files missed previous SPDX conversion batches
> due to not specifying GPL version.
Reviewed-by: Simon Horman
On Thu, May 11, 2023 at 08:33:59PM +0700, Bagas Sanjaya wrote:
> Previous batches of SPDX conversion missed bond_main.c and bonding_priv.h
> because these files doesn't mention intended GPL version. Add SPDX identifier
> to these files, assuming GPL 1.0+.
Reviewed-by: Simon Horman
On Tue, May 9, 2023 at 9:37 AM Rob Clark wrote:
>
> From: Rob Clark
>
> When the special handling of qcom,adreno-smmu was moved into
> qcom_smmu_create(), it was overlooked that we didn't have all the
> required entries in qcom_smmu_impl_of_match. So we stopped getting
> adreno_smmu_priv on sc71
Hi
Am 11.05.23 um 15:05 schrieb Helge Deller:
On 5/11/23 09:55, Thomas Zimmermann wrote:
Hi
Am 10.05.23 um 20:20 schrieb Sui Jingfeng:
Hi, Thomas
I love your patch, yet something to improve:
On 2023/5/10 19:05, Thomas Zimmermann wrote:
Fix coding style. No functional changes.
Signed-off
On Thu, May 11, 2023 at 08:34:03PM +0700, Bagas Sanjaya wrote:
> Remove the license boilerplate as there is already SPDX license
> identifier which fulfills the same intention as the boilerplate.
Reviewed-by: Simon Horman
On Thu, May 11, 2023 at 08:33:57PM +0700, Bagas Sanjaya wrote:
> There is already SPDX tag which does the job, so remove the redundant
> notice.
>
> Cc: Christophe JAILLET
> Signed-off-by: Bagas Sanjaya
Reviewed-by: Simon Horman
On Thu, May 11, 2023 at 08:34:01PM +0700, Bagas Sanjaya wrote:
> Replace unversioned GPL boilerplate notice on remaining i825xx files
> with appropriate SPDX identifier. For files that contains "extension to
> Linux kernel", use GPL 2.0, otherwise GPL 1.0+.
>
> Cc: Donald Becker
> Cc: Michael Hip
On Thu, May 11, 2023 at 08:34:04PM +0700, Bagas Sanjaya wrote:
> Many watchdog drivers's source files has already SPDX license
> identifier, while some remaining doesn't.
>
> Convert notices on remaining files to SPDX identifier.
Reviewed-by: Simon Horman
On Thu, May 11, 2023 at 08:34:06PM +0700, Bagas Sanjaya wrote:
> Replace unversioned GPL license notice with appropriate SPDX
> identifier, which is GPL 1.0+.
>
> Signed-off-by: Bagas Sanjaya
Reviewed-by: Simon Horman
On Thu, May 11, 2023 at 08:34:05PM +0700, Bagas Sanjaya wrote:
> Except Kconfig and Makefile, all source files for UDF filesystem doesn't
> bear SPDX license identifier. Add appropriate license identifier while
> replacing boilerplates.
>
> Cc: Thomas Gleixner
> Signed-off-by: Bagas Sanjaya
Rev
On Thu, May 11, 2023 at 08:34:02PM +0700, Bagas Sanjaya wrote:
> Add SPDX identifier on remaining files untouched during previous
> rounds of SPDX conversion while replacing boilerplate notice if any.
Reviewed-by: Simon Horman
On Tue, 9 May 2023 at 19:37, Rob Clark wrote:
>
> From: Rob Clark
>
> When the special handling of qcom,adreno-smmu was moved into
> qcom_smmu_create(), it was overlooked that we didn't have all the
> required entries in qcom_smmu_impl_of_match. So we stopped getting
> adreno_smmu_priv on sc7180
On Wed, May 10, 2023 at 04:19:32PM +0200, Thomas Hellström wrote:
> If a vma was destroyed with the bo evicted, it might happen that we forget
> to remove it from the notifer::rebind_list. Fix to make sure that really
> happens.
>
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/xe/xe_v
On Thu, May 11, 2023 at 7:51 AM Dmitry Baryshkov
wrote:
>
> On Tue, 9 May 2023 at 19:37, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > When the special handling of qcom,adreno-smmu was moved into
> > qcom_smmu_create(), it was overlooked that we didn't have all the
> > required entries in qco
On Wed, May 10, 2023 at 04:19:31PM +0200, Thomas Hellström wrote:
> the vma::rebind_link is protected by the vm's resv, but we was
> modifying it without. Fix this by use the vma::userptr_link instead
> for the tmp_evict list. The vma::userptr_link is protected by the
> vm lock.
>
> Signed-off-by:
From: Rob Clark
When the special handling of qcom,adreno-smmu was moved into
qcom_smmu_create(), it was overlooked that we didn't have all the
required entries in qcom_smmu_impl_of_match. So we stopped getting
adreno_smmu_priv on sc7180, breaking per-process pgtables.
Fixes: 30b912a03d91 ("iomm
From: Rob Clark
Otherwise it is not always obvious if a dt or iommu change is causing us
to fall back to global pgtable.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_iommu.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/driv
On Thu, May 11, 2023 at 08:34:04PM +0700, Bagas Sanjaya wrote:
> Many watchdog drivers's source files has already SPDX license
> identifier, while some remaining doesn't.
>
> Convert notices on remaining files to SPDX identifier.
>
> Cc: Ray Lehtiniemi
> Cc: Alessandro Zummo
> Cc: Andrey Panin
On Wed, May 10, 2023 at 04:55:04PM -0700, Stephen Boyd wrote:
> Quoting Kuogee Hsieh (2023-05-10 13:31:04)
> > The internal_hpd flag was introduced to handle external DP HPD derived from
> > GPIO
> > pinmuxed into DP controller.
>
> Was it? It looks more like it was done to differentiate between
On 5/11/23 16:54, Matthew Brost wrote:
On Wed, May 10, 2023 at 04:19:32PM +0200, Thomas Hellström wrote:
If a vma was destroyed with the bo evicted, it might happen that we forget
to remove it from the notifer::rebind_list. Fix to make sure that really
happens.
Signed-off-by: Thomas Hellström
On Wed, May 10, 2023 at 05:39:07PM -0700, Abhinav Kumar wrote:
>
>
> On 5/10/2023 4:55 PM, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2023-05-10 13:31:04)
> > > The internal_hpd flag was introduced to handle external DP HPD derived
> > > from GPIO
> > > pinmuxed into DP controller.
> >
> > W
On Thu, May 11, 2023 at 07:24:46AM +0300, Dmitry Baryshkov wrote:
> On Wed, 10 May 2023 at 23:31, Kuogee Hsieh wrote:
> >
> > The internal_hpd flag was introduced to handle external DP HPD derived from
> > GPIO
> > pinmuxed into DP controller. HPD plug/unplug interrupts cannot be enabled
> > unt
On 11/05/2023 18:53, Bjorn Andersson wrote:
On Thu, May 11, 2023 at 07:24:46AM +0300, Dmitry Baryshkov wrote:
On Wed, 10 May 2023 at 23:31, Kuogee Hsieh wrote:
The internal_hpd flag was introduced to handle external DP HPD derived from GPIO
pinmuxed into DP controller. HPD plug/unplug interru
Hi Fei,
Pushed to drm-intel-gt-next.
There was a "pinky" promise that Tvrtko asked you (and I feel
involved, as well) to make. Let's make sure to follow up on that.
Andi
On Tue, May 09, 2023 at 09:51:58AM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> This patch set was posted at
> htt
On 5/9/23 13:27, Zongjie Li wrote:
Smatch complains that:
arcfb_probe() warn: 'irq' from request_irq() not released on lines: 587.
Fix error handling in the arcfb_probe() function. If IO addresses are
not provided or framebuffer registration fails, the code will jump to
the err_addr or err_regis
On 10/05/2023 23:31, Kuogee Hsieh wrote:
There is bug report on exteranl DP display does not work.
This patch add below two patches to fix the problem.
1) enable HDP plugin/unplugged interrupts to hpd_enable/disable
2) add mutex to protect internal_hpd against race condition between different
th
On 5/11/23 15:10, Geert Uytterhoeven wrote:
Hi Helge,
On Thu, May 11, 2023 at 3:05 PM Helge Deller wrote:
On 5/11/23 09:55, Thomas Zimmermann wrote:
But the work I do within fbdev is mostly for improving DRM.
Sure.
For the
other issues in this file, I don't think that matroxfb should even
When we are talking about being 'prescriptive' in the API, are we
outright saying we don't want to support arbitrary 3D LUTs, or are we
just offering certain algorithms to be 'executed' for a plane/crtc/etc
in the atomic API? I am confused...
There is so much stuff to do with color, that I don't t
On 5/10/2023 9:52 PM, Dmitry Baryshkov wrote:
On 11/05/2023 01:07, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but
not
used at dpu_hw_dsc
On 5/11/23 16:27, Thomas Zimmermann wrote:
But the work I do within fbdev is mostly for improving DRM.
Sure.
For the
other issues in this file, I don't think that matroxfb should even be
around any longer. Fbdev has been deprecated for a long time. But a
small number of drivers are still in u
On 4/27/23 05:08, Zheng Wang wrote:
A use-after-free bug may occur if init_imstt invokes framebuffer_release
and free the info ptr. The caller, imsttfb_probe didn't notice that and
still keep the ptr as private data in pdev.
If we remove the driver which will call imsttfb_remove to make cleanup,
On 11/05/2023 20:00, Kuogee Hsieh wrote:
On 5/10/2023 9:52 PM, Dmitry Baryshkov wrote:
On 11/05/2023 01:07, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is
Quoting Pin-yen Lin (2023-05-09 20:41:54)
> On Sat, Apr 29, 2023 at 12:47 PM Stephen Boyd wrote:
> >
> > Good point. I'm suggesting to make the drm bridge chain into a tree. We
> > need to teach drm_bridge core about a mux, and have some logic to
> > navigate atomically switching from one output t
On Wed, 10 May 2023 11:36:06 -0700, Ashutosh Dixit wrote:
>
> Loading i915 on UBSAN enabled kernels (CONFIG_UBSAN/CONFIG_UBSAN_BOOL)
> causes the following warning:
>
> UBSAN: invalid-load in drivers/gpu/drm/i915/gt/uc/intel_uc.c:558:2
> load of value 255 is not a valid value for type '_Bool'
>
This series adds the DPU side changes to support DSC 1.2 encoder. This
was validated with both DSI DSC 1.2 panel and DP DSC 1.2 monitor.
The DSI and DP parts will be pushed later on top of this change.
This seriel is rebase on [1], [2] and catalog fixes from rev-4 of [3].
[1]: https://patchwork.fr
From: Abhinav Kumar
There are some platforms has DSC blocks but it is not declared at catalog.
For completeness, this patch adds DSC blocks for platforms which missed
them.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h |
Disabling the crossbar mux between DSC and PINGPONG currently
requires a bogus enum dpu_pingpong value to be passed when calling
dsc_bind_pingpong_blk() with enable=false, even though the register
value written is independent of the current PINGPONG block. Replace
that `bool enable` parameter with
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine was moved to INTF with the help of the flush mechanism.
Add a DPU_PINGPONG_DSC feature bit to restrict the availability of
dpu_hw_pp_setup_dsc() and dpu_hw_
DPU < 7.0.0 has DPU_PINGPONG_DSC feature bit set to indicate it requires
both dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() to be
executed to complete DSC configuration if DSC hardware block is present.
Hence test DPU_PINGPONG_DSC feature bit and assign DSC related functions
to the ops
Unset DSC_ACTIVE bit at dpu_hw_ctl_reset_intf_cfg_v1(),
dpu_encoder_unprep_dsc() and dpu_encoder_dsc_pipe_clr() functions
to tear down DSC data path if DSC data path was setup previous.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but not
used at dpu_hw_dsc_config_1_2()
-- unrolling thresh loops
Changes in v4:
-- delete DPU_DSC_HW_REV_1_1
-- delete
Current DSC flush update is piggyback inside dpu_hw_ctl_intf_cfg_v1().
This patch separates DSC flush away from dpu_hw_ctl_intf_cfg_v1() by
adding dpu_hw_ctl_update_pending_flush_dsc_v1() to handle both per
DSC engine and DSC flush bits at same time to make it consistent with
the location of flush
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
feature flag information. Each display compression engine (DCE) contains
dual hard slice DSC encoders so both share same base address but with
its own different sub block address.
changes in v4:
-- delet
Statically allocated array of pointers to hwmon_channel_info can be made
const for safety.
Reviewed-by: Lyude Paul
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_h
Statically allocated array of pointers to hwmon_channel_info can be made
const for safety.
Acked-by: Jani Nikula
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/
Quoting Bjorn Andersson (2023-05-11 08:44:16)
> On Wed, May 10, 2023 at 05:39:07PM -0700, Abhinav Kumar wrote:
> >
> >
> > On 5/10/2023 4:55 PM, Stephen Boyd wrote:
> > > Quoting Kuogee Hsieh (2023-05-10 13:31:04)
> > > > The internal_hpd flag was introduced to handle external DP HPD derived
> > >
On Thu, May 11, 2023 at 04:56:47PM +, Joshua Ashton wrote:
> When we are talking about being 'prescriptive' in the API, are we
> outright saying we don't want to support arbitrary 3D LUTs, or are we
> just offering certain algorithms to be 'executed' for a plane/crtc/etc
> in the atomic API? I
On Thursday, May 11th, 2023 at 18:56, Joshua Ashton wrote:
> When we are talking about being 'prescriptive' in the API, are we
> outright saying we don't want to support arbitrary 3D LUTs, or are we
> just offering certain algorithms to be 'executed' for a plane/crtc/etc
> in the atomic API? I am
On 07/05/23 17:28, Maíra Canal wrote:
> Create a new fixed-point helper to allow us to return the rounded value
> of our fixed-point value.
>
> Signed-off-by: Maíra Canal
> ---
>
> v1 -> v2:
> https://lore.kernel.org/dri-devel/20230425153353.238844-1-mca...@igalia.com/T/
>
> * New patch
> *
From: Chong Li
[ Upstream commit 38eecbe086a4e52f54b2bbda8feba65d44addbef ]
[WHY]
Function "amdgpu_irq_update()" called by "amdgpu_device_ip_late_init()" is an
atomic context.
We shouldn't access registers through KIQ since "msleep()" may be called in
"amdgpu_kiq_rreg()".
[HOW]
Move functi
From: Wesley Chalmers
[ Upstream commit 474f01015ffdb74e01c2eb3584a2822c64e7b2be ]
[WHY]
Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a
pipe commit can cause underflow.
[HOW]
Move DMUB p-state delegate into optimze_bandwidth; enabling FAMS sets
optimized_required.
This
From: Hersen Wu
[ Upstream commit 025ce392b5f213696ca0af3e07735d0fae020694 ]
[Why]
when amdgpu_dm_update_connector_after_detect is called
two times successively with valid sink, memory allocated of
aconnector->timing_requested for the first call is not free.
this causes memeleak.
[How]
allocate
From: lyndonli
[ Upstream commit 4eea7fb980dc44545a32eec92e2662053b34cd9d ]
Below call trace and errors are observed when reloading
amdgpu driver with the module parameter reset_method=3.
It should do a default reset when loading or reloading the
driver, regardless of the module parameter reset
From: Chong Li
[ Upstream commit 38eecbe086a4e52f54b2bbda8feba65d44addbef ]
[WHY]
Function "amdgpu_irq_update()" called by "amdgpu_device_ip_late_init()" is an
atomic context.
We shouldn't access registers through KIQ since "msleep()" may be called in
"amdgpu_kiq_rreg()".
[HOW]
Move functi
From: Wesley Chalmers
[ Upstream commit 474f01015ffdb74e01c2eb3584a2822c64e7b2be ]
[WHY]
Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a
pipe commit can cause underflow.
[HOW]
Move DMUB p-state delegate into optimze_bandwidth; enabling FAMS sets
optimized_required.
This
From: lyndonli
[ Upstream commit 4eea7fb980dc44545a32eec92e2662053b34cd9d ]
Below call trace and errors are observed when reloading
amdgpu driver with the module parameter reset_method=3.
It should do a default reset when loading or reloading the
driver, regardless of the module parameter reset
From: Chong Li
[ Upstream commit 38eecbe086a4e52f54b2bbda8feba65d44addbef ]
[WHY]
Function "amdgpu_irq_update()" called by "amdgpu_device_ip_late_init()" is an
atomic context.
We shouldn't access registers through KIQ since "msleep()" may be called in
"amdgpu_kiq_rreg()".
[HOW]
Move functi
1 - 100 of 159 matches
Mail list logo
