Quoting Pin-yen Lin (2023-04-20 02:10:46)
> On Thu, Apr 20, 2023 at 2:10 PM Stephen Boyd wrote:
> >
> > Quoting Stephen Boyd (2023-04-13 17:22:46)
> > > Quoting Pin-yen Lin (2023-04-13 02:50:44)
> > > >
> > > > Actually the `mode-switch` property here is mainly because
> > > >
On 29/04/2023 07:04, Abhinav Kumar wrote:
On 4/28/2023 8:21 PM, Dmitry Baryshkov wrote:
On Sat, 29 Apr 2023 at 05:50, Abhinav Kumar
wrote:
On 4/28/2023 6:41 PM, Dmitry Baryshkov wrote:
On 29/04/2023 04:08, Abhinav Kumar wrote:
On 4/28/2023 5:45 PM, Dmitry Baryshkov wrote:
On
On 29/04/2023 07:29, Abhinav Kumar wrote:
On 4/28/2023 7:42 PM, Dmitry Baryshkov wrote:
The driver doesn't support hsic/memcolor, pcc and igc SSPP subblocks.
Drop corresponding definitions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 8
On 4/28/2023 7:42 PM, Dmitry Baryshkov wrote:
The driver doesn't support hsic/memcolor, pcc and igc SSPP subblocks.
Drop corresponding definitions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 8
1 file changed, 8 deletions(-)
diff --git
On 4/28/2023 8:21 PM, Dmitry Baryshkov wrote:
On Sat, 29 Apr 2023 at 05:50, Abhinav Kumar wrote:
On 4/28/2023 6:41 PM, Dmitry Baryshkov wrote:
On 29/04/2023 04:08, Abhinav Kumar wrote:
On 4/28/2023 5:45 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Legacy DPU
Hi,
I have just tested this patch on a LoongArch(3a5000+ls7a2000 evb) machine,
both fbtest and the fbdev test of IGT finished.
fbtest say test001: ~ test013: PASSED,
After apply your patch, the warn log `accel_flags changed from 0 to 1`
disappeared while running it.
So,
Tested-by: Sui
On 4/28/2023 8:12 PM, Dmitry Baryshkov wrote:
On Sat, 29 Apr 2023 at 05:51, Abhinav Kumar wrote:
On 4/28/2023 7:46 PM, Dmitry Baryshkov wrote:
On Sat, 29 Apr 2023 at 02:45, Kuogee Hsieh wrote:
This series adds the DPU side changes to support DSC 1.2 encoder. This
was validated with
On Sat, 29 Apr 2023 at 05:50, Abhinav Kumar wrote:
>
>
>
> On 4/28/2023 6:41 PM, Dmitry Baryshkov wrote:
> > On 29/04/2023 04:08, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/28/2023 5:45 PM, Dmitry Baryshkov wrote:
> >>> On 29/04/2023 02:45, Kuogee Hsieh wrote:
> Legacy DPU requires PP hardware
On Sat, 29 Apr 2023 at 05:51, Abhinav Kumar wrote:
>
>
>
> On 4/28/2023 7:46 PM, Dmitry Baryshkov wrote:
> > On Sat, 29 Apr 2023 at 02:45, Kuogee Hsieh wrote:
> >>
> >> 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
Hey, all!
I am so excited to see other folks excited about extending VKMS. I
think it's a great project and has outstanding potential!
Life stuff made me AFK for the last few months, but I'm back now and
I've been wrapping up the work on the patchset Brandon linked.
The current WIP patches are
On 4/28/2023 7:46 PM, Dmitry Baryshkov wrote:
On Sat, 29 Apr 2023 at 02:45, Kuogee Hsieh wrote:
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
On 4/28/2023 6:41 PM, Dmitry Baryshkov wrote:
On 29/04/2023 04:08, Abhinav Kumar wrote:
On 4/28/2023 5:45 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Legacy DPU requires PP hardware block involved into setting up DSC
Nit: to be envolved
data path. This patch
On Sat, 29 Apr 2023 at 02:45, Kuogee Hsieh wrote:
>
> 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]
The driver doesn't support hsic/memcolor, pcc and igc SSPP subblocks.
Drop corresponding definitions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
On 29/04/2023 04:08, Abhinav Kumar wrote:
On 4/28/2023 5:45 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Legacy DPU requires PP hardware block involved into setting up DSC
Nit: to be envolved
data path. This patch add DDPU_PINGPONG_DSC feature bit to both
adds
On 29/04/2023 04:22, Abhinav Kumar wrote:
On 4/28/2023 5:52 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
During DSC preparation, add run time calculation to figure out what
usage modes, split mode and merge mode, is going to be setup.
This patch doesn't determine
Stop using _sspp_subblk_offset() to get offset of the csc_blk. Inline
this function and use ctx->cap->sblk->csc_blk.base directly.
As this was the last user, drop _sspp_subblk_offset() too.
Reviewed-by: Jeykumar Sankaran
Signed-off-by: Dmitry Baryshkov
---
Stop using _sspp_subblk_offset() to get offset of the scaler_blk. Inline
this function and use ctx->cap->sblk->scaler_blk.base directly.
Reviewed-by: Jeykumar Sankaran
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 27 +++--
1 file changed, 9
The src_blk declares a lame copy of main SSPP register space. It's
offset is always 0. It's length has been fixed to 0x150, while SSPP's
length is now correct. Drop the src_blk and access SSPP registers
without additional subblock lookup.
Signed-off-by: Dmitry Baryshkov
---
Rework dpu_hw_sspp.c to access sblk base address directly rather than
getting the sblk address through indirect function call.
Changes since v1:
- Dropped DPU_SSPP_SRC feature, making SRC-related functions mandatory
(suggested by Jeykumar)
Dmitry Baryshkov (3):
drm/msm/dpu: drop SSPP's SRC
On 4/28/2023 5:52 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
During DSC preparation, add run time calculation to figure out what
usage modes, split mode and merge mode, is going to be setup.
This patch doesn't determine the mode. It changes programming of DSC
On 4/28/2023 5:32 PM, John Harrison wrote:
On 4/28/2023 17:30, John Harrison wrote:
On 4/28/2023 17:26, Ceraolo Spurio, Daniele wrote:
On 4/28/2023 5:16 PM, John Harrison wrote:
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
For ppc64, gcc with W=1 reports
drivers/char/agp/uninorth-agp.c: In function 'uninorth_create_gatt_table':
drivers/char/agp/uninorth-agp.c:372:13: error: variable
'size' set but not used [-Werror=unused-but-set-variable]
372 | int size;
| ^~~~
This variable is not
On 29/04/2023 04:10, Abhinav Kumar wrote:
On 4/28/2023 5:30 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Reported-by: kernel test robot
What exactly was reported?
On 4/28/2023 5:30 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Reported-by: kernel test robot
What exactly was reported?
On 4/28/2023 5:45 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Legacy DPU requires PP hardware block involved into setting up DSC
Nit: to be envolved
data path. This patch add DDPU_PINGPONG_DSC feature bit to both
adds
PP_BLK and PP_BLK_TE so that both
On 4/28/2023 6:04 PM, Dmitry Baryshkov wrote:
On 29/04/2023 04:03, Abhinav Kumar wrote:
On 4/28/2023 5:35 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
From: Abhinav Kumar
In preparation of calling ping-pong DSC related functions only
for chipsets which have such
On 29/04/2023 04:03, Abhinav Kumar wrote:
On 4/28/2023 5:35 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
From: Abhinav Kumar
In preparation of calling ping-pong DSC related functions only
for chipsets which have such a design add the dsc blocks for the
chipsets for
On 4/28/2023 5:35 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
From: Abhinav Kumar
In preparation of calling ping-pong DSC related functions only
for chipsets which have such a design add the dsc blocks for the
chipsets for which DSC is present but was not added in
On 29/04/2023 02:45, Kuogee Hsieh wrote:
At current implementation, topology configuration is thrown away after
dpu_rm_reserve(). This patch save the topology so that it can be used
for DSC related calculation later.
Even if we delay the virtual wide planes patchset, please don't save the
On 29/04/2023 02:45, Kuogee Hsieh wrote:
During DSC preparation, add run time calculation to figure out what
usage modes, split mode and merge mode, is going to be setup.
This patch doesn't determine the mode. It changes programming of DSC
bits according to the mode being selected.
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Legacy DPU requires PP hardware block involved into setting up DSC
Nit: to be envolved
data path. This patch add DDPU_PINGPONG_DSC feature bit to both
adds
PP_BLK and PP_BLK_TE so that both dpu_hw_pp_setup_dsc() and
dpu_hw_pp_dsc_enable() will be
On 29/04/2023 02:45, Kuogee Hsieh wrote:
From: Abhinav Kumar
In preparation of calling ping-pong DSC related functions only
for chipsets which have such a design add the dsc blocks for the
chipsets for which DSC is present but was not added in the catalog.
Why/how is it prearing us for such
On 4/28/2023 17:30, John Harrison wrote:
On 4/28/2023 17:26, Ceraolo Spurio, Daniele wrote:
On 4/28/2023 5:16 PM, John Harrison wrote:
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Current DSC flush update is piggyback inside dpu_hw_ctl_intf_cfg_v1().
This patch separate DSC flush away from dpu_hw_ctl_intf_cfg_v1() by
Nit: separates
adding dpu_hw_ctl_update_pending_flush_dsc_v1() to handle both per
DSC engine and DSC flush bits
On 4/28/2023 17:26, Ceraolo Spurio, Daniele wrote:
On 4/28/2023 5:16 PM, John Harrison wrote:
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Reported-by: kernel test robot
What exactly was reported?
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/Makefile | 1 +
On 29/04/2023 02:45, Kuogee Hsieh wrote:
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
On 4/28/2023 5:16 PM, John Harrison wrote:
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available
On 4/28/2023 17:19, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
If the DEBUG_GEM config option is set then escalate the 'unexpected
firmware version' message from a notice to an error. This will ensure
that the CI system treats
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
If the DEBUG_GEM config option is set then escalate the 'unexpected
firmware version' message from a notice to an error. This will ensure
that the CI system treats such occurences as a failure and logs a bug
about it
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. So pull it out
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
It was noticed that duplicate entries in the firmware table could cause
an infinite loop in the firmware loading code if that entry failed to
load. Duplicate entries are a bug anyway and so should never happen.
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. So pull it out into a separate function that is only
called once
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
When reduced version firmware files were added (matching major
component being the only strict requirement), the minor version was
still tracked and a notification reported if it was older. However,
the patch version
At current implementation, topology configuration is thrown away after
dpu_rm_reserve(). This patch save the topology so that it can be used
for DSC related calculation later.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 32 ++---
1 file
Legacy DPU requires PP hardware block involved into setting up DSC
data path. This patch add DDPU_PINGPONG_DSC feature bit to both
PP_BLK and PP_BLK_TE so that both dpu_hw_pp_setup_dsc() and
dpu_hw_pp_dsc_enable() will be executed during DSC path setup.
Reported-by : Marijn Suijten
Current DSC flush update is piggyback inside dpu_hw_ctl_intf_cfg_v1().
This patch separate 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
In preparation of calling ping-pong DSC related functions only
for chipsets which have such a design add the dsc blocks for the
chipsets for which DSC is present but was not added in the catalog.
Signed-off-by: Abhinav Kumar
---
During DSC preparation, add run time calculation to figure out what
usage modes, split mode and merge mode, is going to be setup.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 56 -
1 file changed, 31 insertions(+), 25 deletions(-)
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.
Signed-off-by: Abhinav
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Reported-by: kernel test robot
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 34 ++-
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 [3].
[1]:
Inverse gamma correction blocks (IGC) are not used today so lets
remove the usage of DPU_DSPP_IGC in the DSPP flush to make it easier
to remove IGC from the catalog.
We can add this back when IGC is properly supported in DPU with
one of the standard DRM properties.
changes in v3:
- minor
Gamma Correction (GC) and Inverse Gamma Correction(IGC) is
currently unused. In addition dpu_dspp_sub_blks didn't even have an igc
member describing the block.
Drop related code from the dpu hardware catalog otherwise this becomes a
burden to carry across chipsets in the catalog.
changes in v3:
Since GC and IGC masks have now been dropped DSPP_MSM8998_MASK
is same as DSPP_SC7180_MASK. Since DSPP_SC7180_MASK is used more
than DSPP_MSM8998_MASK, lets drop the latter.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
---
Gamma correction blocks (GC) are not used today so lets remove
the usage of DPU_DSPP_GC in the dspp flush to make it easier
to remove GC from the catalog.
We can add this back when GC is properly supported in DPU with
one of the standard DRM properties.
changes in v3:
- drop the link tag
Hi Won,
Thanks for the patch, I have now merged to drm-misc-next
Regards
Manasi
On Mon, Apr 17, 2023 at 3:52 PM Manasi Navare wrote:
>
> On Tue, Mar 28, 2023 at 6:45 PM Won Chung wrote:
> >
> > Expose DRM connector id in device sysfs so that we can map the connector
> > id to the connector
Hi Won,
Thanks for the patch, patch now merged to drm-misc-next
Regards
Manasi
On Thu, Apr 27, 2023 at 9:58 AM Won Chung wrote:
>
> Create a symlink pointing to USB Type-C connector for DRM connectors
> when they are created. The link will be created only if the firmware is
> able to describe
On Thu, 27 Apr 2023 20:21:32 +0800, Jianhua Lu wrote:
> This fixes warning:
> sm8250-xiaomi-elish-csot.dtb: dsi@ae94000: Unevaluated properties are not
> allowed ('qcom,master-dsi', 'qcom,sync-dual-dsi' were unexpected)
>
>
Applied, thanks!
[1/1] dt-bindings: display/msm:
On Wed, 19 Apr 2023 16:41:07 +0200, Arnaud Vrac wrote:
> This series include misc fixes related to hardware resource allocations
> in the msm dpu driver, some specifically for msm8998 (including hw
> catalog fixes and cursor sspp support for cursor planes, instead of
> using Smart DMA pipes).
>
On Wed, 26 Apr 2023 01:11:08 +0200, Marijn Suijten wrote:
> Doing a for loop in every DPU HW block driver init to find a catalog
> entry matching the given ID is rather useless if the init function
> called by RM already has that catalog entry pointer, and uses exactly
> its ID to drive this
> On 27/04/2023 17:07, Yang, Fei wrote:
>>> On 26/04/2023 16:41, Yang, Fei wrote:
> On 26/04/2023 07:24, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> The first three patches in this series are taken from
>> https://patchwork.freedesktop.org/series/116868/
>> These
On Fri, 21 Apr 2023 15:56:57 +0100, Srinivas Kandagatla wrote:
> while binding the code always registers a audio driver, however there
> is no corresponding unregistration done in unbind. This leads to multiple
> redundant audio platform devices if dp_display_bind and dp_display_unbind
> happens
The new binaries that support the 2-step authentication have contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the meu
manifest of the GSC binary. The manifest consist of a partition header
followed by
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with meu
binaries being considered fully authenticated only after the GSC auth
step.
To report the
Follow the same logic as DG2, so just a meu binary with no version number.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
The full authentication via the GSC requires an heci packet submission
to the GSC FW via the GSC CS. The GSC has new PXP command for this
(literally called NEW_HUC_AUTH).
The intel_huc_auth fuction is also updated to handle both authentication
types.
Signed-off-by: Daniele Ceraolo Spurio
Cc:
On MTL, for obvious reasons, HuC is only available on the media tile.
We already disable SW support for HuC on the root gt due to the
absence of VCS engines, but we also need to update the getparam to point
to the HuC struct in the media GT.
Signed-off-by: Daniele Ceraolo Spurio
Cc: John
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary" and
"loaded by GSC", so the former case
Now that each FW has its own reserved area, we can keep them always
pinned and skip the pin/unpin dance on reset. This will make things
easier for the 2-step HuC authentication, which requires the FW to be
pinned in GGTT after the xfer is completed.
Given that we use dummy vmas for the pinning, we
This is a squash of the GSC proxy series, which is being reviewed
separately [1]. It's being included here because some of the patches in
this series depend on it. This is not a functional dependencies, the
patches just touch the same code and the proxy patches are planned to be
merged first, so
The HuC loading and authentication flow is once again changing and a new
"clear-media only" authentication step is introduced. The flow is as
follows:
1) The HuC is loaded via DMA - same as all non-GSC HuC binaries.
2) The HuC is authenticated by the GuC - this is the same step as
performed for
From: John Harrison
GuC based register dumps in error capture logs were basically broken
for virtual engines. This can be seen in igt@gem_exec_balancer@hang:
[IGT] gem_exec_balancer: starting subtest hang
[drm] GPU HANG: ecode 12:4:e1524110, in gem_exec_balanc [6388]
[drm] GT0: GUC: No
From: John Harrison
Don't use 'xe_lp*' prefixes for register lists that are common with
Gen8.
Don't add Xe only GSC registers to pre-Xe devices that don't
even have a GSC engine.
Fix Xe_LP name.
Don't use GEN9 as a prefix for register lists that contain all GEN8
registers.
Rename the
From: John Harrison
Remove 99% duplicated steered register list code. Also, include the
pre-Xe steered registers in the pre-Xe list generation.
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 112 +-
1 file changed, 29
From: John Harrison
The GuC error capture list creation was including Gen8 registers on Xe
platforms. While fixing that, it was noticed that there were other
issues. The platform naming was wrong, the naming of lists was
misleading, the steered register code was duplicated and steered
registers
From: John Harrison
A pair of pre-Xe registers were being included in the Xe capture list.
GuC was rejecting those as being invalid and logging errors about
them. So, stop doing it.
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
Fixes: dce2bd542337 ("drm/i915/guc: Add Gen9 registers
>> On 4/28/23 17:19, Yang, Fei wrote:
>>> On 4/28/23 07:47, fei.y...@intel.com wrote:
From: Fei Yang
The first three patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches are included here because the last patch
has
On Fri, Apr 28, 2023 at 5:56 PM Markus Elfring wrote:
>
> From: Markus Elfring
> Date: Sun, 16 Apr 2023 17:30:46 +0200
>
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “receive_timing_debugfs_show”.
>
>
Hi Thomas,
On Fri, Apr 28, 2023 at 04:18:38PM +0200, Thomas Zimmermann wrote:
> I'd be happy to have fb_() wrappers that are I/O helpers without
> ordering guarantees. I'd just wouldn't want them in
How about throwing them into a new drm_fb.h header file.
This header file could be the home for
On 4/27/2023 5:21 AM, Jianhua Lu wrote:
This fixes warning:
sm8250-xiaomi-elish-csot.dtb: dsi@ae94000: Unevaluated properties are not
allowed ('qcom,master-dsi', 'qcom,sync-dual-dsi' were unexpected)
Reviewed-by: Dmitry Baryshkov
Acked-by: Rob Herring
Signed-off-by: Jianhua Lu
---
The kinetic,ktz8866 is a I2C driver, so add the missing reg property.
And update example to make it clear.
Signed-off-by: Jianhua Lu
---
.../leds/backlight/kinetic,ktz8866.yaml | 29 ---
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git
On 4/28/23 17:19, Yang, Fei wrote:
> On 4/28/23 07:47, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> The first three patches in this series are taken from
>> https://patchwork.freedesktop.org/series/116868/
>> These patches are included here because the last patch
>> has dependency on the
From: Markus Elfring
Date: Sun, 16 Apr 2023 17:30:46 +0200
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “receive_timing_debugfs_show”.
Thus avoid the risk for undefined behaviour by moving the assignment
> On 4/28/23 07:47, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> The first three patches in this series are taken from
>> https://patchwork.freedesktop.org/series/116868/
>> These patches are included here because the last patch
>> has dependency on the pat_index refactor.
>>
>> This series
On Friday, April 28th, 2023 at 15:12, Pekka Paalanen
wrote:
> the subject says "define" but this is an enum. No big deal, but the
> thing I started wondering is how I am going to use these in userspace.
> There is no #define I could test to know if I need to provide a
> fallback definition.
Thomas Zimmermann writes:
> Use info->screen_buffer when reading and writing framebuffers in
> system memory. It's the correct pointer for this address space.
>
> The struct fb_info has a union to store the framebuffer memory. This can
> either be info->screen_base if the framebuffer is stored
Thomas Zimmermann writes:
> Use info->screen_buffer when reading and writing framebuffers in
> system memory. It's the correct pointer for this address space.
>
> The struct fb_info has a union to store the framebuffer memory. This can
> either be info->screen_base if the framebuffer is stored
Thomas Zimmermann writes:
> Use info->screen_buffer when reading and writing framebuffers in
> system memory. It's the correct pointer for this address space.
>
> The struct fb_info has a union to store the framebuffer memory. This can
> either be info->screen_base if the framebuffer is stored
Thomas Zimmermann writes:
> Use info->screen_buffer when reading and writing framebuffers in
> system memory. It's the correct pointer for this address space.
>
> The struct fb_info has a union to store the framebuffer memory. This can
> either be info->screen_base if the framebuffer is stored
On 26 4月 23 19:22:43, Cai Huoqing wrote:
> On 26 4月 23 17:28:02, Cai Huoqing wrote:
> > Using rhashtable to accelerate the search for userptr by address,
> > instead of using a list.
> >
> > Preferably, the lookup complexity of a hash table is O(1).
> >
> > This patch will speedup the method
> >
Using rhashtable to accelerate the search for userptr by address,
instead of using a list.
Preferably, the lookup complexity of a hash table is O(1).
This patch will speedup the method
hl_userptr_is_pinned by rhashtable_lookup_fast.
Signed-off-by: Cai Huoqing
---
v1->v2:
Use
Thomas Zimmermann writes:
> Use info->screen_buffer when reading and writing framebuffers in
> system memory. It's the correct pointer for this address space.
>
> The struct fb_info has a union to store the framebuffer memory. This can
> either be info->screen_base if the framebuffer is stored
On Fri, Apr 28, 2023 at 3:56 AM Tvrtko Ursulin
wrote:
>
>
> On 27/04/2023 18:53, Rob Clark wrote:
> > From: Rob Clark
> >
> > Add support to dump GEM stats to fdinfo.
> >
> > v2: Fix typos, change size units to match docs, use div_u64
> > v3: Do it in core
> > v4: more kerneldoc
> >
> >
Thomas Zimmermann writes:
> Use info->screen_buffer when reading and writing framebuffers in
> system memory. It's the correct pointer for this address space.
>
> The struct fb_info has a union to store the framebuffer memory. This can
> either be info->screen_base if the framebuffer is stored
Thomas Zimmermann writes:
> Use info->screen_buffer when reading and writing framebuffers in
> system memory. It's the correct pointer for this address space.
>
> The struct fb_info has a union to store the framebuffer memory. This can
> either be info->screen_base if the framebuffer is stored
Thomas Zimmermann writes:
> Use info->screen_buffer when reading and writing framebuffers in
> system memory. It's the correct pointer for this address space.
>
> The struct fb_info has a union to store the framebuffer memory. This can
> either be info->screen_base if the framebuffer is stored
On Fri, Apr 28, 2023 at 1:50 AM Christian König
wrote:
>
> Am 27.04.23 um 19:53 schrieb Rob Clark:
> > From: Rob Clark
> >
> > Fix a couple missing ':'s.
> >
> > Signed-off-by: Rob Clark
> > Reviewed-by: Rodrigo Vivi
>
> Reviewed-by: Christian König
>
> Since this is a pretty clear fix I
Thomas Zimmermann writes:
> Use info->screen_buffer when reading and writing framebuffers in
> system memory. It's the correct pointer for this address space.
>
> The struct fb_info has a union to store the framebuffer memory. This can
> either be info->screen_base if the framebuffer is stored
1 - 100 of 200 matches
Mail list logo
