Make the description of @regs_range_array and @regs_range_array_size
to @user_regs_range_array and @user_regs_range_array_size to silence
the warnings:
drivers/accel/habanalabs/common/security.c:506: warning: Function parameter or
member 'user_regs_range_array' not described in 'hl_init_pb_range
For DSC the min BPC is 8 for ICL+ and so the min pipe_bpp is 24.
Check this condition for cases where bpc is forced by debugfs flag
dsc_force_bpc. If the check fails, then WARN and ignore the debugfs
flag.
For MST case the pipe_bpp is already computed (hardcoded to be 24),
and this check is not re
Currently the required dsc output bpp is set to be the largest
compressed bpp supported for max, lane, rate, and bpp.
The helper intel_dp_dsc_get_output_bpp gets the maximum supported
compressed bpp taking into account link configuration, input bpp,
bigjoiner considerations etc.
Similarly, the hel
For MST the bpc is hardcoded to 8, and pipe bpp to 24.
So avoid forcing DSC bpc for MST case.
v2: Warn and ignore the debug flag than to bail out. (Jani)
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c |
Currently, we take the max lane, rate and pipe bpp, to get the maximum
compressed bpp possible. We then set the output bpp to this value.
This patch provides support to have max bpp, min rate and min lanes,
that can support the min compressed bpp.
v2:
-Avoid ending up with compressed bpp, same as
To make way for fractional bpp support, avoid left shifting the
output_bpp by 4 in helper intel_dp_dsc_get_output_bpp.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 12
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
2 files changed, 5 insertio
From: Stanislav Lisovskiy
Currently we seem to be using wrong DPCD register for reading compressed bpps,
reading min/max input bpc instead of compressed bpp.
Fix that, so that we now apply min/max compressed bpp limitations we get
from DP Spec Table 2-157 DP v2.0 and/or correspondent DPCD registe
DP DSC Receiver Capabilities are exposed via DPCD 60h-6Fh.
Fix the DSC RECEIVER CAP SIZE accordingly.
Fixes: ffddc4363c28 ("drm/dp: Add DP DSC DPCD receiver capability size define
and missing SHIFT")
Cc: Anusha Srivatsa
Cc: Manasi Navare
Cc: # v5.0+
Signed-off-by: Ankit Nautiyal
---
include
DSC compressed bpp and slice counts are already getting printed at the
end of dsc compute config. Remove extra logs.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/
Currently there are many places where we use output_bpp for link bpp and
compressed bpp.
Lets use consistent naming:
output_bpp : The intermediate value taking into account the
output_format chroma subsampling.
compressed_bpp : target bpp for the DSC encoder.
link_bpp : final bpp used in the link.
In Bigjoiner check for DSC, bigjoiner interface bits for DP for
DISPLAY > 13 is 36 (Bspec: 49259).
v2: Corrected Display ver to 13.
v3: Follow convention for conditional statement. (Ville)
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
1 file changed, 2 inse
As per Bsepc:49259, Bigjoiner BW check puts restriction on the
compressed bpp for a given CDCLK, pixelclock in cases where
Bigjoiner + DSC are used.
Currently compressed bpp is computed first, and it is ensured that
the bpp will work at least with the max CDCLK freq.
Since the CDCLK is computed l
The final link bpp used to calculate the m_n values depend on the
output_format. Though the output_format is set to RGB for MST case and
the link bpp will be same as the pipe bpp, for the sake of semantics,
lets calculate the m_n values with the link bpp, instead of pipe_bpp.
Signed-off-by: Ankit
While using DSC the compressed bpp is computed assuming RGB output
format. Consider the output_format and compute the compressed bpp
during mode valid and compute config steps.
For DP-MST we currently use RGB output format only, so continue
using RGB while computing compressed bpp for MST case.
v
This series is an attempt to address multiple issues with DSC,
scattered in separate existing series.
Patches 1-3 are DSC fixes from series to Handle BPC for HDMI2.1 PCON
https://patchwork.freedesktop.org/series/107550/
Patches 4-5 are from series DSC fixes for Bigjoiner:
https://patchwork.freede
Hi Bagas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on ac9a78681b921877518763ba0e89202254349d1b]
url:
https://github.com/intel-lab-lkp/linux/commits/Bagas-Sanjaya/agp-amd64-Remove-GPL-distribution-notice/20230511-214307
base
Hi Bagas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on ac9a78681b921877518763ba0e89202254349d1b]
url:
https://github.com/intel-lab-lkp/linux/commits/Bagas-Sanjaya/agp-amd64-Remove-GPL-distribution-notice/20230511-214307
base
Hi Bagas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on ac9a78681b921877518763ba0e89202254349d1b]
url:
https://github.com/intel-lab-lkp/linux/commits/Bagas-Sanjaya/agp-amd64-Remove-GPL-distribution-notice/20230511-214307
base
Hi Bagas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on ac9a78681b921877518763ba0e89202254349d1b]
url:
https://github.com/intel-lab-lkp/linux/commits/Bagas-Sanjaya/agp-amd64-Remove-GPL-distribution-notice/20230511-214307
base
Hi Bagas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on ac9a78681b921877518763ba0e89202254349d1b]
url:
https://github.com/intel-lab-lkp/linux/commits/Bagas-Sanjaya/agp-amd64-Remove-GPL-distribution-notice/20230511-214307
base
Hi Bagas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on ac9a78681b921877518763ba0e89202254349d1b]
url:
https://github.com/intel-lab-lkp/linux/commits/Bagas-Sanjaya/agp-amd64-Remove-GPL-distribution-notice/20230511-214307
base
Hi Bagas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on ac9a78681b921877518763ba0e89202254349d1b]
url:
https://github.com/intel-lab-lkp/linux/commits/Bagas-Sanjaya/agp-amd64-Remove-GPL-distribution-notice/20230511-214307
base
Hi Bagas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on ac9a78681b921877518763ba0e89202254349d1b]
url:
https://github.com/intel-lab-lkp/linux/commits/Bagas-Sanjaya/agp-amd64-Remove-GPL-distribution-notice/20230511-214307
base
https://bugzilla.kernel.org/show_bug.cgi?id=217432
Bug ID: 217432
Summary: AMDGPU crash on shutdown
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
Status: NEW
Severity: normal
Priority: P3
On 5/12/23 03:17, Gurchetan Singh wrote:
...
> Can we get one of the Mesa MRs reviewed first? There's currently no
> virtio-intel MR AFAICT, and the amdgpu one is marked as "Draft:".
>
> Even for the amdgpu, Pierre suggests the feature "will be marked as
> experimental both in Mesa and virglrende
On Thu, 2023-05-11 at 18:35 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The GuC has a completely separate engine class enum when referring to
> register capture lists, which combines render and compute. The driver
> was using the 'normal' GuC specific engine class enum inste
pmu_needs_timer() keeps the timer running even when GT is parked,
ostensibly to sample requested/actual frequencies. However
frequency_sample() has the following:
/* Report 0/0 (actual/requested) frequency while parked. */
if (!intel_gt_pm_get_if_awake(gt))
return;
From: John Harrison
The GuC has a completely separate engine class enum when referring to
register capture lists, which combines render and compute. The driver
was using the 'normal' GuC specific engine class enum instead. That
meant that it thought it was defining a capture list for compute
engi
On Thu, May 11, 2023 at 05:38:11PM +0200, Thomas Hellström wrote:
>
> 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::r
On Fri, 12 May 2023 at 03:16, Kuogee Hsieh wrote:
>
>
> On 5/11/2023 8:57 AM, Dmitry Baryshkov wrote:
> > 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:
>
>
On Thu, 11 May 2023 20:33:56 +0700 Bagas Sanjaya wrote:
> 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
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/display/Kconfig
between commits:
78f0929884d4 ("powerpc/64: Always build with 128-bit long double")
70cc1b5307e8 ("Merge tag 'powerpc-6.4-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc
Thank you for the patches and the reviews. Pushed.
- Radhakrishna(RK) Sripada
> -Original Message-
> From: dri-devel On Behalf Of Alan
> Previn
> Sent: Thursday, May 11, 2023 4:18 PM
> To: intel-...@lists.freedesktop.org
> Cc: Teres Alexis, Alan Previn ; Ursulin,
> Tvrtko ; Juston Li ; d
On Mon, May 8, 2023 at 6:59 AM Rob Clark wrote:
> On Wed, May 3, 2023 at 10:07 AM Gurchetan Singh
> wrote:
> >
> >
> >
> > On Mon, May 1, 2023 at 8:38 AM Dmitry Osipenko <
> dmitry.osipe...@collabora.com> wrote:
> >>
> >> On 4/16/23 14:52, Dmitry Osipenko wrote:
> >> > We have multiple Vulkan co
On 5/11/2023 8:57 AM, Dmitry Baryshkov wrote:
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
pi
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.
Thus, immediately enable (or disable) KCR HW on PXP's init,
fini
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.
Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.
We use non-priv
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for PXP
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
1
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
While relooking at the ARB session creation flow in intel_pxp_start,
let's address missing UAPI documentation. Without actually changing
backward compatible behavior, update i915's drm-uapi comments
th
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the debugfs teardown timeouts to align with
new GSC-CS + firmware specs.
Now that we have 3 places that are selecting pxp timeouts
based on tee vs gsccs back-end, let's add a helper.
Signed-off-by: Alan Previn
Reviewed-by:
Because of the additional firmware, component-driver and
initialization depedencies required on MTL platform before a
PXP context can be created, UMD calling for PXP creation as a
way to get-caps can take a long time. An actual real world
customer stack has seen this happen in the 4-to-8 second ran
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.
Thus for MTL, we need
This series enables PXP on MTL. On ADL/TGL platforms, we rely on
the mei driver via the i915-mei PXP component interface to establish
a connection to the security firmware via the HECI device interface.
That interface is used to create and teardown the PXP ARB session.
PXP ARB session is created wh
On 2023-05-11 09:22:47, Dmitry Baryshkov wrote:
> On 11/05/2023 09:18, Marijn Suijten wrote:
> > On 2023-05-11 07:26:28, Dmitry Baryshkov wrote:
> >> On 11/05/2023 01:35, Jessica Zhang wrote:
> >>>
> >>>
> >>> On 5/9/2023 11:29 PM, Marijn Suijten wrote:
> On 2023-05-09 15:06:48, Jessica Zhang
On 2023-05-11 13:05:15, Abhinav Kumar wrote:
> > Don't think the DP series alone should point that out, as it heavily
> > depends on the relation between slice size and bpp parameters, and
> > whether those end up with a fractional part or not (are you able to test
> > and confirm all those combin
The pull request you sent on Fri, 12 May 2023 06:59:57 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-05-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cc3c44c9fda264c6d401be04e95449a57c1231c6
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On Friday, May 5th, 2023 at 15:30, Joshua Ashton wrote:
> > > AMD would expose the following objects and properties:
> > >
> > > Plane 10
> > > ├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary
> > > └─ "color_pipeline": enum {0, 42} = 0
> > > Color operation 42 (inpu
On 2023-05-11 07:23, Daniil Dulov wrote:
Pointer mqd_mem_obj can be deallocated in kfd_gtt_sa_allocate().
The function then returns non-zero value, which causes the second deallocation.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: d1f8f0d17d40 ("drm/amdkfd: Move non-
Hi Linus,
About the usual for this stage, bunch of amdgpu, a few i915 and a
scattering of fixes across the board,
Regards,
Dave.
drm-fixes-2023-05-12:
drm fixes for 6.4-rc2
dsc:
- macro fixes
simplefb:
- fix VESA format
scheduler:
- Scheduler timeout handling fix.
fbdev:
- Prohibit potential
On 5/10/2023 11:15 PM, Marijn Suijten wrote:
On 2023-05-10 14:03:14, Jessica Zhang wrote:
On 5/9/2023 11:33 PM, Marijn Suijten wrote:
On 2023-05-09 15:06:50, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Reviewed-by: D
On 5/10/2023 11:28 PM, Dmitry Baryshkov wrote:
On 11/05/2023 00:03, Jessica Zhang wrote:
On 5/9/2023 11:33 PM, Marijn Suijten wrote:
On 2023-05-09 15:06:50, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Reviewed-by: Dm
Hey,
On 2023-05-11 12:14, Tvrtko Ursulin wrote:
>
> 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 the
On Thu, May 11, 2023 at 01:37:13PM +0300, Juha-Pekka Heikkila wrote:
> Add Tile4 type ccs modifiers with aux buffer needed for MTL
>
Bspec: 49251, 49252, 49253
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula
Reviewed-by: Matt Atwood
> Signed-off-by: Juha-Pekka Heikkila
> ---
> include/
On 07/05/23 17:28, Maíra Canal wrote:
> Currently, the pixel conversion isn't rounding the fixed-point values
> before assigning it to the RGB coefficients, which is causing the IGT
> pixel-format tests to fail. So, use the drm_fixp2int_round() fixed-point
> helper to round the values when assig
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
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
> *
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 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
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
> > >
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/
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
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
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
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
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
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
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_
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
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 |
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
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'
>
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 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
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 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 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
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/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
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/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
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 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
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 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 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 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 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
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
1 - 100 of 159 matches
Mail list logo
