Maxime Ripard writes:
Hello Maxime,
> container_of_const() allows to preserve the pointer constness and is
> thus more flexible than inline functions.
>
> Let's switch all our instances of container_of() to
> container_of_const().
>
> Signed-off-by: Maxime Ripard
> ---
[...]
> -static inline
From: Alexander Usyskin
Add GSC proxy driver. It to allows messaging between GSC component
on Intel graphics card and CSE device.
Cc: Alan Previn
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Acked-by: Greg Kroah-Hartman
---
v2:
The GSC uC needs to communicate with the CSME to perform certain
operations. Since the GSC can't perform this communication directly
on platforms where it is integrated in GT, i915 needs to transfer the
messages from GSC to CSME and back.
The proxy flow is as follow:
1 - i915 submits a request to
The GSC notifies us of a proxy request via the HECI2 interrupt. The
interrupt must be enabled both in the HECI layer and in our usual gt irq
programming; for the latter, the interrupt is enabled via the same enable
register as the GSC CS, but it does have its own mask register. When the
interrupt
From: Alexander Usyskin
GSC Proxy component is used for communication between the
Intel graphics driver and MEI driver.
Cc: Alan Previn
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Acked-by: Greg Kroah-Hartman
---
v2: Improve
On platforms where the GSC is part of GT, it needs to communicate with
CSME for some of its operations. However, there is no direct HW
communication channel, so the i915 and mei drivers must carry the
messages back and forth between the 2 units. The protocol is fully
described in the i915 patch
On 21/04/2023 02:25, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 38 ++-
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
---
Stop using _sspp_subblk_offset() to get offset of the scaler_blk. Inline
this function and use ctx->cap->sblk->scaler_blk.base directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 27 +++--
1 file changed, 9 insertions(+), 18 deletions(-)
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.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 43
Rework dpu_hw_sspp.c to access sblk base address directly rather than
getting the sblk address through indirect function call.
Dmitry Baryshkov (3):
drm/msm/dpu: drop SSPP's SRC subblock
drm/msm/dpu: access QSEED registers directly
drm/msm/dpu: access CSC/CSC10 registers directly
On 4/21/2023 1:53 PM, Marijn Suijten wrote:
The Resource Manager already iterates over all available blocks from the
catalog, only to pass their ID to a dpu_hw_xxx_init() function which
uses an _xxx_offset() helper to search for and find the exact same
catalog pointer again to initialize the
On 22/04/2023 02:16, Kuogee Hsieh wrote:
On 4/21/2023 4:11 PM, Dmitry Baryshkov wrote:
On 22/04/2023 02:08, Kuogee Hsieh wrote:
On 4/21/2023 3:16 PM, Dmitry Baryshkov wrote:
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee
On 4/21/2023 4:11 PM, Dmitry Baryshkov wrote:
On 22/04/2023 02:08, Kuogee Hsieh wrote:
On 4/21/2023 3:16 PM, Dmitry Baryshkov wrote:
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add
On 22/04/2023 02:08, Kuogee Hsieh wrote:
On 4/21/2023 3:16 PM, Dmitry Baryshkov wrote:
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with
On 22/04/2023 01:47, Abhinav Kumar wrote:
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.
On 22/04/2023 01:47, Abhinav Kumar wrote:
Since Gamma Correction (GC) block is currently unused, drop
related code from the dpu hardware catalog otherwise this
becomes a burden to carry across chipsets in the catalog.
Signed-off-by: Abhinav Kumar
---
On 4/21/2023 3:16 PM, Dmitry Baryshkov wrote:
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary
sub-block and feature flag
From: John Harrison
Dan Carpenter pointed out that 'err' was not being set in the case
where the GuC firmware version range check fails. Fix that.
Note that while this is bug fix for a previous patch (see Fixes tag
below). It is an exceedingly low risk bug. The range check is
asserting that the
Since Gamma Correction (GC) block is currently unused, drop
related code from the dpu hardware catalog otherwise this
becomes a burden to carry across chipsets in the catalog.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 +---
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.
Signed-off-by: Abhinav Kumar
---
On 22/04/2023 01:34, Abhinav Kumar wrote:
On 4/20/2023 3:52 PM, Dmitry Baryshkov wrote:
On 20/04/2023 22:56, Marijn Suijten wrote:
On 2023-04-20 22:51:22, Dmitry Baryshkov wrote:
On 20/04/2023 22:47, Abhinav Kumar wrote:
On 4/20/2023 11:01 AM, Dmitry Baryshkov wrote:
On 20/04/2023
On 4/20/2023 3:52 PM, Dmitry Baryshkov wrote:
On 20/04/2023 22:56, Marijn Suijten wrote:
On 2023-04-20 22:51:22, Dmitry Baryshkov wrote:
On 20/04/2023 22:47, Abhinav Kumar wrote:
On 4/20/2023 11:01 AM, Dmitry Baryshkov wrote:
On 20/04/2023 04:36, Konrad Dybcio wrote:
On 20.04.2023
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
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)
On Fri, Apr 14, 2023 at 06:07:46PM +0200, Guillaume Ranquet wrote:
> The ret variable in mtk_hdmi_pll_calc() was used unitialized as reported
> by the kernel test robot.
>
> Fix the issue by removing the variable altogether and testing out the
> return value of mtk_hdmi_pll_set_hw()
>
> Fixes:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
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
On 22/04/2023 00:30, Kuogee Hsieh wrote:
On 4/21/2023 2:13 PM, Dmitry Baryshkov wrote:
On 22/04/2023 00:07, Kuogee Hsieh wrote:
On 4/20/2023 5:27 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
During DSC preparation, add run time calculation to figure out what
usage
On 4/21/2023 2:13 PM, Dmitry Baryshkov wrote:
On 22/04/2023 00:07, Kuogee Hsieh wrote:
On 4/20/2023 5:27 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
During DSC preparation, add run time calculation to figure out what
usage modes, split mode and merge mode, is going
On 2023-02-28 03:34, Christian König wrote:
Avoids quite a bit of logic and kmalloc overhead.
Not sure what's the status of this patch series. In general I'm in
favour. I think it could help with some tricky locking cases for the
work we're doing for validating GEM objects in KFD contexts.
On 22/04/2023 00:07, Kuogee Hsieh wrote:
On 4/20/2023 5:27 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, 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.
Signed-off-by: Kuogee Hsieh
---
On 4/20/2023 5:27 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, 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.
Signed-off-by: Kuogee Hsieh
---
The Resource Manager already iterates over all available blocks from the
catalog, only to pass their ID to a dpu_hw_xxx_init() function which
uses an _xxx_offset() helper to search for and find the exact same
catalog pointer again to initialize the block with, fallible error
handling and all.
Some of these members were initialized while never read, while others
were not even assigned any pointer value at all. Drop them to save some
space, and above all confusion when looking at or accidentally
dereferencing these members.
Signed-off-by: Marijn Suijten
Reviewed-by: Abhinav Kumar
The WB debug log mask ended up never being assigned, leading to writes
to this block to never be logged even if the mask is enabled in
dpu_hw_util_log_mask via debugfs.
Fixes: 84a33d0fd921 ("drm/msm/dpu: add dpu_hw_wb abstraction for writeback
blocks")
Signed-off-by: Marijn Suijten
Reviewed-by:
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 init and for loop. Remove all that machinery to
drop quite some lines
On 2023-04-20 09:11:18, Yang, Fei wrote:
> > On 20/04/2023 12:39, Andi Shyti wrote:
> >> Hi Fei,
> >>
> >>> To comply with the design that buffer objects shall have immutable
> >>> cache setting through out their life cycle, {set, get}_caching ioctl's
> >>> are no longer supported from MTL onward.
Use the new efficient frequency toggling interface. Also
create a helper function to restore the frequencies after
the test is done.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/selftest_slpc.c | 42 ++---
1 file changed, 37 insertions(+), 5 deletions(-)
diff
SLPC enables use of efficient freq at init by default. It is
possible for GuC to request frequencies that are higher than
the 'software' max if user has set it lower than the efficient
level.
Scenarios/tests that require strict fixing of freq below the efficient
level will need to disable it
-for-DSC-encoder-v1-2-engine/20230421-072925
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/1682033114-28483-2-git-send-email-quic_khsieh%40quicinc.com
patch subject: [PATCH v1 1/5] drm/msm/dpu: add support for DSC encoder v1.2
engine
config
In the process of renaming all instances of 'dev_priv' to 'i915',
start using 'i915' within the i915_drv.h file.
Signed-off-by: Andi Shyti
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/i915_drv.h | 458
1 file changed, 229 insertions(+), 229 deletions(-)
for_each_engine() loops through engines in the GT, not in
dev_priv. Because it's misleading, call it "gt__" instead of
"dev_priv__".
Signed-off-by: Andi Shyti
Reviewed-by: Rodrigo Vivi
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2
Hi,
just another "Friday patch". While reviewing some patches from
Tejas I found a bit confusing the use of dev_priv__ inside the
for_each_engine(), perhaps it should be moved inside the gt/?
As I was at it I made the /dev_priv/i915/ change which is still
harmless. Next in queue is to change the
On 4/21/2023 7:56 AM, 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 multiple times
From: Fei Yang
Media GT has a different base for MOCS register, need to apply
gsi_offset to the mmio address if not using the intel_uncore_r/w
functions for register access.
Cc: Matt Roper
Signed-off-by: Fei Yang
Reviewed-by: Matt Roper
Signed-off-by: Andi Shyti
---
From: Madhumitha Tolakanahalli Pradeep
On MTL, GT can no longer allocate on LLC - only the CPU can.
This, along with programming new register bits that MTL
requires calls for a MOCS/PAT table update.
Also the PAT index registers are multicasted for primary GT,
and there is an address jump from
Hi,
just extracting this patch from Fei's series.
Andi
Changelog:
==
v1 -> v2:
Taken from Fei's new series: https://patchwork.freedesktop.org/series/115980/
- Removed unnecessary defines
- Place the selftest patches in a different patch
Fei Yang (1):
drm/i915/mtl: fix mocs selftest
On 21/04/2023 20:46, Abhinav Kumar wrote:
On 4/20/2023 3:25 PM, Dmitry Baryshkov wrote:
The regdma is currently not used by the current driver. We have no way
to practically verify that the regdma is described correctly. Drop it
now.
Signed-off-by: Dmitry Baryshkov
---
As Marijn noted,
On Fri, Apr 21, 2023 at 10:38:01AM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> To comply with the design that buffer objects shall have immutable
> cache setting through out their life cycle, {set, get}_caching ioctl's
> are no longer supported from MTL onward. With that change caching
On 21/04/2023 10:35, Marijn Suijten wrote:
On 2023-04-21 01:25:58, Dmitry Baryshkov wrote:
Stop mapping the regdma region. The driver does not support regdma.
Signed-off-by: Dmitry Baryshkov
Should you add a third patch to remove this from dt-bindings?
(msm8998 has it in both dpu and mdss
On 4/20/2023 3:25 PM, Dmitry Baryshkov wrote:
Stop mapping the regdma region. The driver does not support regdma.
Signed-off-by: Dmitry Baryshkov
---
As pointed out by Marijn, the binding can be dropped too but for this
change,
Reviewed-by: Abhinav Kumar
On 4/20/2023 3:25 PM, Dmitry Baryshkov wrote:
The regdma is currently not used by the current driver. We have no way
to practically verify that the regdma is described correctly. Drop it
now.
Signed-off-by: Dmitry Baryshkov
---
As Marijn noted, perhaps we can drop even
On Fri, Apr 21, 2023 at 10:37:55AM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> Media GT has a different base for MOCS register, need to apply
> gsi_offset to the mmio address if not using the intel_uncore_r/w
> functions for register access.
>
> Cc: Matt Roper
> Signed-off-by: Fei
On Fri, Apr 21, 2023 at 10:27:22AM -0700, Yang, Fei wrote:
>> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote:
>>> From: Fei Yang
>>>
>>> PTE encode functions are platform dependent. This patch implements
>>> PTE functions for MTL, and ensures the correct
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a
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 in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent,
From: Fei Yang
PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.
Cc: Chris Wilson
Cc: Matt Roper
Signed-off-by:
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE encode.
Signed-off-by: Fei Yang
Reviewed-by: Andrzej
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.
Preparing the transition by
From: Fei Yang
The series includes patches needed to enable MTL.
Also add new extension for GEM_CREATE uAPI to let
user space set cache policy for buffer objects.
v2: addressing review comments and checkpatch warnings
v3: make mtl_ggtt_pte_encode static
v4: addressing more comments from Matt
From: Fei Yang
The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
From: Madhumitha Tolakanahalli Pradeep
On MTL, GT can no longer allocate on LLC - only the CPU can.
This, along with programming new register bits that MTL
requires calls for a MOCS/PAT table update.
Also the PAT index registers are multicasted for primary GT,
and there is an address jump from
From: Fei Yang
Media GT has a different base for MOCS register, need to apply
gsi_offset to the mmio address if not using the intel_uncore_r/w
functions for register access.
Cc: Matt Roper
Signed-off-by: Fei Yang
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 3 ++-
1 file changed, 2
> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> PTE encode functions are platform dependent. This patch implements
>> PTE functions for MTL, and ensures the correct PTE encode function
>> is used by calling pte_encode function pointer instead of the
On 21/04/2023 19:27, Mark Yacoub wrote:
From: Mark Yacoub
Nit: is there a reason for this header? My first impression is that it
matches your outgoing name & email address and as such is not necessary.
Nit#2: subject should mention 'Key', as you are creating a property for
the key.
On 21/04/2023 18:51, Doug Anderson wrote:
>>> ...and, again, it matches the order that I thought was right. In other
>>> words, the patch file generated says:
>>>
Signed-off-by: Richard Leitner
Acked-by: Krzysztof Kozlowski
>>
>> We talk about `b4 trailers`, because the tag is applied
Hi,
On Fri, Apr 21, 2023 at 9:45 AM Krzysztof Kozlowski
wrote:
>
> On 21/04/2023 18:37, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Apr 21, 2023 at 9:26 AM Krzysztof Kozlowski
> > wrote:
> >>
> >> On 21/04/2023 18:15, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Mon, Mar 13, 2023 at 12:51 AM
On 21/04/2023 18:37, Doug Anderson wrote:
> Hi,
>
> On Fri, Apr 21, 2023 at 9:26 AM Krzysztof Kozlowski
> wrote:
>>
>> On 21/04/2023 18:15, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Mon, Mar 13, 2023 at 12:51 AM wrote:
From: Richard Leitner
Add Innolux G070ACE-L01 7" WVGA
Hi,
On Fri, Apr 21, 2023 at 9:26 AM Krzysztof Kozlowski
wrote:
>
> On 21/04/2023 18:15, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Mar 13, 2023 at 12:51 AM wrote:
> >>
> >> From: Richard Leitner
> >>
> >> Add Innolux G070ACE-L01 7" WVGA (800x480) TFT LCD panel compatible
> >> string.
> >>
>
From: Mark Yacoub
[Why]
To support protected content, the driver requires a key.
Currently, it's being injected from debugfs, which is not super useful
to run a user space in the wild.
[How]
When the key is needed, fetch the "Content Protection Property" on the
connector and get the key blob.
From: Mark Yacoub
[Why]
To enable Protected Content, some drivers require a key to be injected
from user space to enable HDCP on the connector.
[How]
Create new "Content Protection Property" of type "Blob"
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/drm_atomic_uapi.c | 9 +
From: Mark Yacoub
[Why]
User space might need to inject data into the kernel without allowing it
to be read again by any user space.
An example of where this is particularly useful is secret keys fetched
by user space and injected into the kernel to enable content protection.
[How]
Create a
From: Mark Yacoub
Hi all,
Following up to my HDCP patches[1], this series introduces a new connector prop
that is required to push the key from user space to a driver that requires a
key from user space to enable HDCP on a connector.
Patch 1 is the WO blob patch to protect the key
Patch 2 is
On 21/04/2023 18:15, Doug Anderson wrote:
> Hi,
>
> On Mon, Mar 13, 2023 at 12:51 AM wrote:
>>
>> From: Richard Leitner
>>
>> Add Innolux G070ACE-L01 7" WVGA (800x480) TFT LCD panel compatible
>> string.
>>
>> Acked-by: Krzysztof Kozlowski
>> Signed-off-by: Richard Leitner
>
> nit: as I
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by the Media tile update the whole
cache line, even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
to different locations within a single cache
Hi,
On Mon, Mar 13, 2023 at 12:51 AM wrote:
>
> From: Richard Leitner
>
> Add InnoLux G070ACE-L01 7" 800x480 TFT LCD with WLED backlight panel
> support. Timing data was extracted from datasheet and vendor provided
> EDID file.
>
> Signed-off-by: Richard Leitner
> ---
>
Hi,
On Mon, Mar 13, 2023 at 12:51 AM wrote:
>
> From: Richard Leitner
>
> Add Innolux G070ACE-L01 7" WVGA (800x480) TFT LCD panel compatible
> string.
>
> Acked-by: Krzysztof Kozlowski
> Signed-off-by: Richard Leitner
nit: as I understand it, ordering of tags is usually supposed to be
From: Mark Yacoub
[Why]
To enable Protected Content, some drivers require a key to be injected
from user space to enable HDCP on the connector.
[How]
Create new "Content Protection Property" of type "Blob"
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/drm_atomic_uapi.c | 9 +
From: Mark Yacoub
[Why]
To support protected content, the driver requires a key.
Currently, it's being injected from debugfs, which is not super useful
to run a user space in the wild.
[How]
When the key is needed, fetch the "Content Protection Property" on the
connector and get the key blob.
From: Mark Yacoub
Hi all,
Following up to my HDCP patches[1], this series introduces a new connector prop
that is required to push the key from user space to a driver that requires a
key from user space to enable HDCP on a connector.
Patch 1 is the DRM code that creates this prop.
Patch 2 is
On 4/20/2023 10:34 PM, Alan Previn wrote:
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
On 21.04.2023 15:46, Andi Shyti wrote:
In the process of renaming all instances of 'dev_priv' to 'i915',
start using 'i915' within the 'drm_i915_file_private' structure.
Signed-off-by: Andi Shyti
---
Reviewed-by: Andrzej Hajda
Regards
Andrzej
On 21.04.2023 15:46, Andi Shyti wrote:
for_each_gt() loops through engines in the GT, not in dev_priv.
Because it's misleading, call it "gt__" instead of "dev_priv__".
Signed-off-by: Andi Shyti
With fixes mentioned by Rodrigo.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
Hi, Angelo:
AngeloGioacchino Del Regno 於
2023年4月19日 週三 下午2:16寫道：
>
> Il 21/03/23 12:14, AngeloGioacchino Del Regno ha scritto:
> > The documentation for some of the driver structures in mediatek-drm
> > was set to be kerneldoc but some code additions didn't actually update
> > the comments
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 multiple times during startup. On X13s platform this resulted in
6 to 9
On Fri, Apr 21, 2023 at 10:07:28AM -0400, Rodrigo Vivi wrote:
> On Fri, Apr 21, 2023 at 03:46:54PM +0200, Andi Shyti wrote:
> > In the process of renaming all instances of 'dev_priv' to 'i915',
> > start using 'i915' within the 'drm_i915_file_private' structure.
>
> The patch looks good but the
On Fri, Apr 21, 2023 at 4:59 AM Tvrtko Ursulin
wrote:
>
>
> On 21/04/2023 12:45, Emil Velikov wrote:
> > On Fri, 21 Apr 2023 at 12:23, Tvrtko Ursulin
> > wrote:
> >
> >> On 21/04/2023 11:26, Emil Velikov wrote:
> >>> On Wed, 12 Apr 2023 at 23:43, Rob Clark wrote:
> >>>
> +/**
> + *
On Fri, Apr 21, 2023 at 2:33 AM Emil Velikov wrote:
>
> Greeting all,
>
> Sorry for the delay - Easter Holidays, food coma and all that :-)
>
> On Tue, 18 Apr 2023 at 15:31, Rob Clark wrote:
> >
> > On Tue, Apr 18, 2023 at 1:34 AM Daniel Vetter wrote:
> > >
> > > On Tue, Apr 18, 2023 at
Hi Rodrigo,
On Fri, Apr 21, 2023 at 10:05:07AM -0400, Rodrigo Vivi wrote:
> On Fri, Apr 21, 2023 at 10:00:29AM -0400, Rodrigo Vivi wrote:
> > On Fri, Apr 21, 2023 at 03:46:53PM +0200, Andi Shyti wrote:
> > > for_each_gt() loops through engines in the GT, not in dev_priv.
> >
> > typo here? ^
> >
On 21.04.2023 16:21, Eric Dumazet wrote:
On Fri, Apr 21, 2023 at 1:35 PM Andrzej Hajda wrote:
In case the library is tracking busy subsystem, simply
printing stack for every active reference will spam log
with long, hard to read, redundant stack traces. To improve
readabilty following
On Fri, Apr 21, 2023 at 1:35 PM Andrzej Hajda wrote:
>
> To have reliable detection of leaks, caller must be able to check under the
> same
> lock both: tracked counter and the leaks. dir.lock is natural candidate for
> such
> lock and unlocked print helper can be called with this lock taken.
>
On Fri, Apr 21, 2023 at 1:35 PM Andrzej Hajda wrote:
>
> Library can handle allocation failures. To avoid allocation warnings
> __GFP_NOWARN has been added everywhere. Moreover GFP_ATOMIC has been
> replaced with GFP_NOWAIT in case of stack allocation on tracker free
> call.
>
> Signed-off-by:
On Fri, Apr 21, 2023 at 1:35 PM Andrzej Hajda wrote:
>
> In case the library is tracking busy subsystem, simply
> printing stack for every active reference will spam log
> with long, hard to read, redundant stack traces. To improve
> readabilty following changes have been made:
> - reports are
On Fri, 21 Apr 2023 13:35:04 +0200 Andrzej Hajda wrote:
> Gently ping for network developers, could you look at ref_tracker patches,
> as the ref_tracker library was developed for network.
Putting Eric in the To: field, I know email so hard and confusing...
On Fri, Apr 21, 2023 at 03:46:54PM +0200, Andi Shyti wrote:
> In the process of renaming all instances of 'dev_priv' to 'i915',
> start using 'i915' within the 'drm_i915_file_private' structure.
The patch looks good but the commit message seems off to me...
One thing we need to take care with
On Fri, Apr 21, 2023 at 10:00:29AM -0400, Rodrigo Vivi wrote:
> On Fri, Apr 21, 2023 at 03:46:53PM +0200, Andi Shyti wrote:
> > for_each_gt() loops through engines in the GT, not in dev_priv.
>
> typo here? ^
>
> with that fixed:
oh, in the commit subject as well...
>
> Reviewed-by: Rodrigo
On Fri, Apr 21, 2023 at 03:46:53PM +0200, Andi Shyti wrote:
> for_each_gt() loops through engines in the GT, not in dev_priv.
typo here? ^
with that fixed:
Reviewed-by: Rodrigo Vivi
> Because it's misleading, call it "gt__" instead of "dev_priv__".
>
> Signed-off-by: Andi Shyti
> ---
>
In the process of renaming all instances of 'dev_priv' to 'i915',
start using 'i915' within the 'drm_i915_file_private' structure.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_drv.h | 458
1 file changed, 229 insertions(+), 229 deletions(-)
diff
for_each_gt() loops through engines in the GT, not in dev_priv.
Because it's misleading, call it "gt__" instead of "dev_priv__".
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
Hi,
just another "Friday patch". While reviewing some patches from
Tejas I found a bit confusing the use of dev_priv__ inside the
for_each_engine(), perhaps it should be moved inside the gt/?
As I was at it I made the /dev_priv/i915/ change which is still
harmless. Next in queue is to change the
Thomas Zimmerman writes:
>
> Am 21.04.23 um 13:32 schrieb Linux regression tracking (Thorsten
> Leemhuis):
>>
>> Pierre, Tomas, Javier, et. al: how many "legacy BIOSes" do we suspect
>> are affected by this?
So far, two:
1) my Gateway laptop (Intel(R) Core(TM) Duo CPU,
Phoenix BIOS 83.08
1 - 100 of 152 matches
Mail list logo
